— 2026.10 · PROJECT MANAGEMENT

AI 项目管理：
先换思维，再换流程

不少 AI 项目最后不了了之，问题往往不出在技术上，而是我们还在用管理传统软件项目的那一套，去管一个性质完全不同的东西。换工具很快，换思维和流程才是真正难的地方。

确定性消失了

传统软件项目有一种让人安心的确定性：需求写清楚，功能做出来，测试通过，就算完成。按钮点下去，结果要么对，要么错。

AI 项目没有这份安心。同一个合同审查智能体，今天在一批合同上的判断准确率是 85%，明天换一批格式不同的合同，可能就掉到 70%。效果取决于数据质量、知识怎么组织、业务规则有没有说清楚，而这些在项目开始时往往都是未知数。项目经理要回答的问题，从“做完了没有”变成了“做得够不够好”，偏偏“够好”这件事，很多项目一开始就没有定义。

如果还按功能清单排期、按功能点验收，结局通常是这样的：系统按时上线，业务部门试用两周后说“不好用”，接下来就是漫长的优化和扯皮。

先换思维

在项目里，我最常和客户、也和自己的团队强调四个转变。

第一，目标要从交付功能变成交付效果。与其写“上线合同审查功能”，不如写清楚关键条款的识别准确率要达到多少，单份合同的审查时间要降到几分钟。

第二，需求的载体要从文档变成评测集。一份几十页的需求说明，远不如一百个带标准答案的真实样例来得清楚。评测集一旦定下来，“什么叫做好”就有了一把大家都认的尺子。

第三，上线只是开始。知识会过时，规则会调整，模型也会升级，没有持续运营，效果会一点点滑坡。

第四，学会和不确定性共处。项目计划要留出探索和迭代的余地，用阶段性的验证来降低风险，而不是一开始就承诺一个谁也保证不了的最终效果。

再改流程

思维换过来以后，流程自然要跟着变。我们现在的项目，大致按这样的节奏推进。

先做结构化的场景调研，把业务场景、知识来源、数据现状、合规要求和验收方式一次问清楚。在一个集团客户的项目里，我们的调研提纲覆盖了 9 个维度、22 个问题，不少原本要到后期才会冒出来的风险，在这一步就提前暴露了。

接着，和业务人员一起挑选真实样本、标注期望结果，搭起评测集，作为之后每一轮迭代的统一标尺。原型阶段就用真实文档和真实问题去跑，尽早发现知识缺口和互相打架的规则，别拿演示数据安慰自己。

里程碑也换了一种定法：不再是“完成某某功能”，而是“在评测集上达到某个准确率”，达标以后再扩大试点范围。下面这张图模拟了一个典型的推进过程，可以一轮一轮点开看：

最后，上线前就要讲清楚：谁来维护知识库，谁来处理用户反馈，多久复盘一次效果。这些事写进交付范围，上线才算真正落了地。

业务专家是关键角色

AI 项目对业务专家的依赖，比传统项目高得多。他们不能只在需求阶段露一次面，而要持续参与标注、评测和反馈。项目经理很重要的一项工作，就是在项目启动前争取到这部分投入，并让业务负责人明白：这不是在替供应商干活，而是在把自己团队的经验沉淀成可以复用的资产。

技术团队的构成也要调整。除了开发工程师，还得有人专门负责知识工程，也就是知识的整理、切分和维护，以及负责评测。这两类工作在传统项目里几乎不存在，却常常决定了最终效果的上限。

把丑话说在前面

最后说一点最现实的：预期管理。项目启动会上，我一般会先讲三件事。AI 做不到百分之百，所以要提前设计好人工复核的环节；效果是一轮轮迭代出来的，第一版只是起点；业务团队投入多少，直接决定了效果能做到多好。

这些话说出来不算漂亮，却能帮项目躲过后期最常见的那场信任危机。

写在最后

AI 改变的不只是我们写代码的方式，还有我们对“完成”的定义。对项目管理者来说，最大的转变也许就是坦然接受不确定性，再用评测、迭代和运营，一点点把它驯服。

工具每个季度都在换，这套思路会用得更久。