编者按

2025年12月31日，在2025年第四届"运筹学与人工智能在业界的前沿应用"研讨会（OR企业&高校分论坛）上，深圳市大数据研究院副研究员王源博士分享了三年项目落地的实战经验。他提出三个核心观点：需求梳理是项目成功的基础、业务逻辑与算法结构必须分离、解决问题需要多元化手段。通过飞行员排班问题的案例，展示了算法、业务、管理、流程四种不同的解决路径，为运筹学从学术走向产业提供了实践参考。

1 引言

王源博士在开场时表达了对运筹学从业者的敬意。他强调，今天分享的主题不是高大上的理论算法，而是一位刚从博士毕业、做了3到4年落地项目的初步经验分享。

王源博士来自深圳市大数据研究院，主要从事运筹优化与仿真计算研究，专注于运筹学方法在实际场景中的应用。研究院在过去几年中承接了华为、南方航空、政府等多个领域的实际项目，正是在这些丰富多样的项目实践中，王源博士积累了宝贵的实战经验和深刻的感悟。

2 三个核心要点

基于丰富的项目实践经验，王源博士总结了三个核心要点：

项目需求的准确理解和清晰梳理是项目成功的关键基础。业务逻辑与算法结构的合理分离是应对需求变化的重要保障。解决实际业务问题必须采用综合性的多元化手段，不能局限于单一的算法思维。

这三个要点不是孤立的技术问题，而是在无数次项目实践中反复遭遇挫折、不断反思总结后提炼出的核心认知。它们代表了从学术研究思维向产业应用思维转变过程中必须跨越的几道关键门槛。

2.1 项目需求梳理的关键性与复杂性

2.1.1 需求理解的困难

刚从学校毕业时，王源博士曾认为梳理项目需求相对简单——与甲方充分沟通，问清楚需求即可。但实践让他意识到需求梳理远比想象中复杂和困难，这是一个涉及沟通、认知、管理等多方面的综合性挑战。需求难以搞清楚的几个核心原因：

甲方表述不清晰：业务人员本身可能对自己的需求认识并不完全清晰。他们知道现状有问题，知道希望改进，但要精确描述问题的本质、期望效果、约束条件，往往超出了业务人员的能力范围。很多时候，他们需要在与技术团队的反复交流中，才能逐步明确自己真正想要的是什么。利益相关方理解不同：在一个项目中，可能涉及多个部门或多个层级的人员，每个人站在自己的角度，对项目的目标、优先级、实现方式都有不同的看法。技术团队如果不能识别和协调这些差异，就可能陷入无所适从的境地。受组织或领导偏好影响：有时候项目的真实目标并不完全是技术文档中写的那样，可能背后有更深层次的考量。领导的一句话可能完全改变项目的方向，而这种改变未必会以正式的需求变更形式体现出来。技术团队需要有足够的敏感性去察觉这些隐含的信息。

2.1.2 需求不清的后果

需求搞不清楚会带来严重的后果，这远远不是简单的多花点时间就能弥补的问题。

最直接的后果是大量返工：团队基于最初理解的需求辛苦工作了一段时间，甚至可能已经取得了阶段性成果，但突然发现理解错了，或者需求变了，之前所做的工作大部分甚至全部都白费了。更糟糕的是，这种返工往往不是一次性的，而是反复发生，团队陷入了一个不断返工的恶性循环。对团队士气的严重打击：技术人员辛苦加班完成的工作成果突然被告知方向不对，需要全部推翻，这种挫败感是难以言表的。长此以往，团队会变得疲惫和消极，怀疑自己工作的价值，影响整个项目的氛围和效率。

在实际项目中，需求不清导致的返工几乎是不可避免的。无论团队多么优秀，多么努力，都很难完全避免。这是项目管理中的一个客观规律，必须正视并学会应对，而不是幻想可以通过某种方法彻底消除。

2.1.3 需求的动态演变特性

除了最初理解需求的困难，另一个更加现实的问题是需求本身就是动态变化的：

外部环境变化：业务形态、市场环境、竞争对手等因素的变化，会迫使甲方调整自己的目标和需求。内部认识深化：在项目推进过程中，甲方对问题的认识也在不断深化。当他们看到技术团队做出的初步成果后，可能会产生新的想法，发现新的需求，或者意识到原来的某些要求不合理需要调整。项目执行特点：很多项目并不是从一开始就有一个清晰完整的战略规划，把所有细节都规定好了。相反，更常见的情况是"摸着石头过河"——先做一步看看效果，再决定下一步怎么走。在这种情况下，需求的不确定性和动态性就更加明显。

在算法类项目中需求的动态变化几乎是一定会发生的事情，技术团队必须接受这个现实

2.2 业务逻辑与算法结构的分离

2.2.1 从学术到工业的认知转变

在博士期间和刚毕业时，王源博士做了大量的算法研究工作，熟练掌握了各种运筹优化方法，从基础的线性规划到复杂的启发式算法，从经典的分支定界到前沿的强化学习。那时候，他和很多学术界的研究者一样，主要关注的是算法本身的性能：求解质量够不够好，运行时间够不够快，能不能在某个benchmark上刷出新的记录。至于算法如何与实际业务结合，如何应对业务的变化，这些问题在学术研究中确实不需要过多考虑。毕竟，学术研究往往假设问题是相对固定和明确的。

但当他真正开始做产业落地项目后，很快发现业务逻辑与算法结构的关系是一个极其重要但在学术界很少被讨论的问题。这个问题不解决好，再优秀的算法也难以在实际项目中发挥价值。

2.2.2 紧耦合带来的问题

将业务逻辑与算法结构紧密耦合在一起会带来的后果：

系统脆弱性和维护困难：当业务逻辑和算法代码混杂在一起，缺乏清晰的模块边界时，两者就失去了独立性。我们前面提到业务逻辑是会频繁变化的，如果业务逻辑和算法逻辑耦合在一起，这就意味着业务逻辑的任何一个变化都会被传导到算法模块中，使得系统变得极其脆弱且难以维护。响应需求变化的高成本：每一次需求变化，不仅要调整业务逻辑，还要相应地修改算法实现，甚至可能需要重新设计整个技术方案。这样一来，响应需求变化的成本和周期都变得难以接受。客户提出一个看似简单的需求调整，技术团队却需要花费大量时间去修改代码、重新测试，项目的灵活性和敏捷性荡然无存。阻碍系统演进和升级：由于业务逻辑和算法实现深度耦合，任何一个部分的演进都需要考虑对另一部分的影响，这大大增加了系统升级和技术更新的复杂度。

2.2.3 解耦的解决方案与实践意义

面对这一挑战，王源博士提出了业务逻辑与算法结构分离的解决方案：

清晰的分离架构：将业务层和算法层清晰地分离开来，两者之间通过一个标准化的接口进行通信和对接。这个接口定义了业务层需要向算法层提供什么样的输入，以及算法层会返回什么样的输出，但并不关心双方各自内部是如何实现的。应对需求变化的优势：当业务需求发生变化时，团队主要在业务层进行调整，通过修改业务建模和业务逻辑来适应新的需求，而算法层可以保持相对稳定，不需要或只需要很少的改动。这样一来，应对需求变化的工作量大大减少，响应速度显著提升。支持独立演进：当需要优化算法性能时，也可以在算法层进行改进，只要保持接口不变，业务层就不受影响。这种独立性让系统各个模块都能够独立演进，互不牵制。

王源博士进一步指出，这种分离的思想在计算机科学中有一个经典的设计原则："任何问题都可以通过增加一个抽象层来解决"。多加一层，就可以隔离变化，降低耦合。

抽象层的价值：在运筹优化项目中应用这一原则，就是在业务和算法之间增加一个抽象层——标准化的接口层。这一层定义了双方交互的契约，提供了缓冲和隔离。虽然增加了一层看似增加了复杂性，但实际上大大提升了系统的可维护性、可扩展性和健壮性。实践中的挑战与投入：虽然这个道理听起来简单朴素，但在实践中真正做到并不容易。它需要在项目初期就有意识地进行架构设计，需要克服"能跑就行"的短视思维，需要投入额外的精力去设计和维护接口规范。但长远来看，这种投入是非常值得的，它能够让项目在面对不可避免的需求变化时保持足够的灵活性和生命力。

2.3 综合运用多元化手段解决实际问题

2.3.1 算法思维的局限性

作为一个受过系统运筹优化训练的研究者，王源博士掌握的技能主要集中在算法层面，因此在遇到实际问题时，第一反应总是想用算法去解决。这种"手里拿着锤子，看什么都像钉子"的思维定势，是许多技术人员的通病。

学术与产业环境的差异：

学术环境：这种思维方式是完全合理的。学术研究本身就是要开发新的算法，证明算法的有效性，因此聚焦于算法是应该的。产业环境：实际情况完全不同。实际系统是复杂的，涉及技术、管理、人员、流程等多个维度，单纯依靠算法往往无法真正解决问题，甚至可能是效率最低的解决方案。

报告人强调，要真正解决业务实际问题，必须跳出单一的算法思维，采用综合性的、多元化的手段。这需要视野的拓展，需要对业务运作方式的深入理解，也需要与不同背景的人员进行协作。

2.3.2 飞行员排班问题的多元化解决方案

王源博士举了一个非常贴近实际的例子：飞行员排班问题。

场景设定：通过运筹优化算法，系统为航空公司生成了一个优化的飞行员排班计划，合理安排了每位飞行员在未来一段时间内执行的航班任务。这个计划在理论上是最优或接近最优的，满足了各种约束条件，达到了优化目标。现实挑战：假设某位飞行员临时有事需要请假，他就无法执行原计划中分配给他的航班任务。这就是一个典型的干扰事件，它打破了优化计划的完美性，需要系统做出响应。

面对这样一个看似简单的问题，实际上有多种完全不同的解决思路。王源博士详细分析了四种典型的解决方案，每一种都有其特定的适用场景和优缺点：（1）方案一：算法建模方法作为受过专业训练的运筹优化研究者，第一反应自然是用算法来解决。请假这类事件可以被视为一种不确定性或随机扰动，那么就可以在建模时引入随机性，将其建立成一个随机规划模型或鲁棒优化模型。具体做法：将飞行员请假用概率分布来描述。比如根据历史数据统计，某位飞行员在任意一天请假的概率是5%，或者在某些特殊时期(如节假日前后)请假概率会上升到10%。在此基础上，建立随机规划模型，求解在期望意义下或在最坏情况下都表现较好的排班方案。优点：理论上严谨，能够系统性地考虑不确定性，得到在概率意义上稳健的解。缺点：模型复杂度大幅增加，求解难度显著提升，需要大量历史数据支持，而且实际效果未必有保障。（2）方案二：业务运作手段跳出纯算法的思维，从业务运作的角度看，其实有更简单直接的方法：设置预备队。实践应用：就像体育比赛中有替补队员一样，航空公司可以安排一些处于待命状态的飞行员作为预备队。当有人临时请假时，由预备队成员顶上即可。这种方法在许多生产线上也很常见，比如流水线工人配备一定比例的替补，确保有人请假时不影响生产。生活化示例：如果你作为老师突然有事不能上课，你的第一反应一定是找个同事帮你代课，而不是坐下来建立一个随机规划模型。（3）方案三：管理激励手段从管理学的角度，还可以通过激励机制来降低请假的发生频率，这是一种预防性的策略。常见做法：设立全勤奖，鼓励员工减少请假。通过经济激励或其他形式的奖励，可以在一定程度上影响员工的行为，减少干扰事件的发生。本质与效果：这种方法的本质是通过改变人的行为模式来减少问题的发生，而不是在问题发生后去解决它。虽然不可能完全消除请假，但可以让请假率保持在一个较低的、可接受的水平。（4）方案四：系统流程优化第四种方法更加综合，体现了系统性思维。核心思想是通过优化整个工作流程，从源头上减少问题的发生。具体实施：可以让算法提前更长的时间(比如一周或两周，甚至更久)发布排班计划，告知每位飞行员他们在未来一段时间内要执行的任务。这样，飞行员可以提前规划自己的个人生活，如果有重要的私事需要处理，可以提前安排，避免临时请假。核心价值：这种方法的价值在于预防而非应对。通过给飞行员更多的时间进行个人规划，大幅降低了临时请假的概率。虽然不可能完全杜绝临时情况，但可以让这种干扰大大减少，从而降低对排班系统的冲击。

2.3.3 多元化手段的综合运用策略

通过这个案例，王源博士展示了四种完全不同的解决思路，它们分别来自算法、业务、管理和系统四个维度。

组合应用而非相互排斥：在实际应用中，这些方法并不是相互排斥的，而是可以组合使用的。比如，可以设置预备队作为基本保障(业务手段)，同时建立全勤奖励机制减少请假频率(管理手段)，并且提前发布排班计划让飞行员有充分的规划时间(系统手段)。如果这些手段还不够，或者针对某些特别重要的时期(如春运)，再考虑使用随机规划等算法手段进一步优化。选择标准的多元化：在实际项目中选择什么样的手段，应该基于问题的性质、资源的约束、实施的难易程度等多方面因素综合考虑，而不是一味追求技术的复杂性或先进性。有时候，最简单的方法反而是最有效的方法。关键认知转变：我们要解决的是实际系统中的业务问题，而不是展示复杂的算法。只要能够有效地解决问题，无论采用什么手段都是合理的。过度依赖算法，把简单问题复杂化，既浪费资源，又可能达不到预期效果。

3 总结与启示

3.1 三个核心要点

在分享的最后，王源博士再次强调了三个核心要点：

项目需求的梳理是一切工作的基础，必须投入足够的精力和重视。不要低估这项工作的难度，要接受需求会持续变化的现实，建立应对机制。业务逻辑与算法结构的分离是保持系统灵活性的关键。通过合理的架构设计，可以让系统在面对频繁的需求变化时仍能保持良好的适应性。解决实际业务问题需要多元化的综合手段。不要局限于单一的算法思维，要学会从业务、管理、系统等多个角度思考问题，选择最合适的解决方案。

3.2 从学术到产业的思维转变

这三个要点背后，实际上反映的是从学术研究思维向产业应用思维的根本性转变。

学术界：问题相对明确和固定，算法本身是关注的核心，理论的严谨性和性能的优越性是主要追求。产业界：需求模糊和动态，系统的可维护性和可扩展性比单纯的算法性能更重要，实用性和综合效果比理论完美性更有价值。

报告人用自己多年的实践经历告诉大家，这种思维转变不是一蹴而就的，需要在实际项目中不断碰壁、反思、调整和成长。

3.3 实践导向

技术的本质是手段：技术不是目的，而是手段。再高深的算法，如果不能解决实际问题，或者解决问题的成本过高，就没有实际价值。相反，有时候一个看似简单的业务调整或管理手段，却能够高效地解决看似复杂的问题。技术人员的新要求：这种价值观要求技术人员放下对技术本身的执念，真正深入到业务中去，理解业务的逻辑和痛点，从业务的角度思考技术的价值。只有这样，才能真正做出有价值的、能够落地的、能够为客户创造实际价值的解决方案。