【AI时代软件项目管理系列】5. 项目启动阶段如何给 AI 分任务？从任务清单到 L0～L5 参与度设计

​上一篇解决的是项目级问题：这个项目是否适合引入 AI，以及数据、工具、工程和治理条件是否具备。一旦确定项目可以使用 AI，下一步就不能继续停留在“要不要用”的讨论上，而要进入更具体的任务层：项目中到底哪些工作交给 AI，哪些由 AI 辅助，哪些仍然必须由人负责？

这其实是 AI 时代新增的一次任务分工。过去项目经理主要考虑“谁来做”，现在还需要进一步考虑“由人做、AI 辅助做，还是交给 Agent 执行”，并把这种分工真正落实到 WBS、迭代计划和责任体系中。

一、先拆任务，再讨论 AI

项目启动阶段很容易出现一种顺序错误：先选了大模型、编程工具或 Agent 平台，然后再寻找可以使用它们的场景。更合理的方式应该反过来。先按照项目生命周期，把真实工作拆出来。例如一个典型的软件项目，可以形成这样的任务地图：

需求阶段
├─ 访谈材料整理
├─ 会议纪要
├─ 需求归纳
├─ 用户故事拆分
├─ 验收标准整理
└─ 业务规则确认

设计阶段
├─ 技术调研
├─ 方案比较
├─ 数据模型设计
├─ API 设计
├─ 安全方案
└─ 架构评审

开发阶段
├─ DTO / Mapper
├─ CRUD
├─ 接口实现
├─ 核心业务逻辑
├─ 单元测试
└─ 代码 Review

测试阶段
├─ 测试用例
├─ 测试数据
├─ 自动化脚本
├─ 缺陷分析
└─ 回归测试

项目管理
├─ 周报
├─ 会议纪要
├─ 风险汇总
├─ 进度分析
└─ 交付材料

只有任务清单先明确，AI 才能真正成为一种项目资源。否则很容易变成：有了 AI 工具以后，到处寻找“可以用 AI 的地方”。而不是：根据项目任务特点，决定哪里值得使用 AI。

二、不要简单分成“适合 AI”和“不适合 AI”

实际项目中，大多数工作并不是非黑即白。更实用的方式，是按照 AI 在任务中的角色，把工作分成四类。

A 类：AI 可以承担主要执行工作

这类任务通常重复度高、规则明确、输出标准化，而且结果很容易检查。例如：会议纪要初稿；文档格式整理；DTO、Mapper；测试数据生成；日志摘要；常规 SQL；项目数据汇总。

这类任务的核心特点是：人没有必要把时间继续花在重复生产上。AI 可以完成主要工作，人只需要进行快速检查。

B 类：AI 生成，人负责确认

这一类是软件项目中最常见的人机协作方式。例如：用户故事拆分；验收标准初稿；API 草稿；普通接口代码；单元测试；测试用例；用户手册；项目周报。

AI 可以显著缩短“从 0 到 1”的时间，但结果仍然需要专业人员确认。例如 Test Agent 根据需求生成 80 条测试用例，并不意味着测试工作已经完成。测试人员仍然需要判断：是否覆盖关键业务；边界条件是否充分；哪些属于无意义重复；是否遗漏高风险场景。所以这类任务更适合：AI 负责生产，人负责验收。

C 类：人主导，AI 辅助分析

任务复杂度继续提高以后，人和 AI 的关系会发生变化。AI 不再是主要生产者，而更像分析助手。例如：复杂业务建模；架构设计；数据模型设计；遗留系统改造；性能问题分析；复杂缺陷根因定位；安全方案设计。这类任务往往没有唯一正确答案，而且高度依赖业务经验、历史约束和技术取舍。AI 很适合：提供备选方案；发现遗漏；总结影响范围；辅助推演；检索历史信息。但最终的判断仍然应该由专业人员完成。

D 类：原则上由人负责

还有一些工作，即使 AI 能够辅助，也不应该把最终决定交给 AI。例如：项目范围确认；核心业务规则批准；架构最终决策；安全例外审批；生产上线决策；重大风险处理；客户验收；合同变更确认。这些任务的关键不是“AI 能不能分析”，而是它们本身带有明确的业务责任和管理责任。因此：AI 可以提供信息，但不能替代责任主体。

项目任务的人机分工模型

这张图比单纯判断“适不适合 AI”更接近真实项目，因为真正需要设计的是人和 AI 在任务中的职责比例。

三、再把任务映射到 L0～L5，而不是一开始就追求 Agent

完成任务分类以后，再决定 AI 参与到什么程度。可以继续使用 L0～L5 的参与度分级：

这里最重要的一点是：L0～L5 不是升级路线，而是参与等级。不是所有任务都应该从 L1 不断升级到 L5。例如：

会议纪要            L2
用户故事拆分        L2
普通接口开发        L3
自动化测试          L3
局部代码 Agent      L4
架构最终决策        L1
生产上线审批        L0
项目最终验收        L0 / L1

一个成熟项目的特点，不是 L4、L5 越多越好，而是每类任务都处于合理的参与等级。

四、同一个需求内部，也可能存在完全不同的 AI 分工

以一个企业云文档项目为例。假设需求是：增加企业文件外链分享功能，支持访问密码、有效期、下载控制，并允许企业管理员统一关闭外链。如果把它当成一个整体任务，然后简单定义“由 Dev Agent 开发”，风险会很高。真正的项目任务应该继续拆分。

1. 需求材料整理

根据客户访谈、会议纪要和已有权限规则，AI 可以整理出：外链是否需要密码；是否允许匿名访问；是否支持下载；是否设置失效时间；哪些文件禁止分享；管理员能否统一关闭；是否记录访问日志。这类工作非常适合 AI 完成初稿。

建议：B 类，L2。AI 负责整理，产品和客户负责确认。

2. 遗漏场景分析

AI 可以继续从已有需求中寻找遗漏，例如：外链失效以后如何处理；源文件删除以后链接是否继续有效；成员离职后创建的分享如何处理；租户管理员关闭外链以后历史链接怎么办。这类任务 AI 很适合提供补充建议，但不能自动改变需求范围。

建议：B/C 类，L2。

3. 权限方案设计

外链分享会涉及：

原文件权限
+
租户隔离
+
外链 Token
+
有效期
+
下载策略
+
审计日志
+
管理员策略

AI 可以分析不同方案的优缺点，但架构师需要结合现有权限模型做最终设计。

建议：C 类，L1～L2。

4. DTO、Controller 和普通接口代码

设计已经明确以后，输入和输出都比较标准化。例如：

CreateShareRequest
ShareConfigDTO
ShareController
ShareService
ShareRecordMapper

可以由 AI 编程工具或 Dev Agent 生成，并结合自动编译和单元测试验证。

建议：B 类，L3。

5. 外链权限核心逻辑

例如：

是否跨租户
是否允许匿名访问
密码是否正确
外链是否过期
管理员是否已经关闭分享
文件当前是否仍可访问

这部分虽然也能由 AI 写，但涉及数据安全，一旦出现越权问题影响较大。

建议：C/B 类，L2～L3。AI 辅助实现，但必须经过人工 Review、安全测试和权限场景验证。

6. 单元测试和接口测试

由于输入、预期结果相对明确，可以让 AI 根据接口定义和业务规则批量生成测试。

建议：A/B 类，L3。

7. 上线决策

即使所有自动测试都通过，是否允许新功能进入生产环境，仍然应该由项目和技术负责人确认。

建议：D 类，L0。

把整个需求重新排列后，就会发现：

这说明：一个需求并不存在统一的 AI 等级，真正需要管理的是需求内部不同任务的人机分工。

五、AI 应该真正进入 WBS 和项目计划

如果 AI 已经承担真实项目工作，就不应该继续停留在：“开发人员会使用 AI。”这样的描述上。更合理的方式，是把 AI 参与正式写入任务计划。例如增加一张 AI 任务登记表：

这一步非常重要。因为只有进入计划以后，项目经理才能继续管理：任务是否完成；AI 输出是否被采用；人工审核是否结束；返工是否增加；最终成果是否可以进入项目基线。AI 才真正从个人工具变成项目资源。

AI 任务进入项目计划的过程

六、AI 分工不是一次确定后永远不变

项目启动阶段形成的是第一版人机分工。随着工程条件变化，同一个任务的 AI 参与度也可能调整。例如一个老项目刚开始时没有自动化测试，普通接口代码只能采用：AI 生成 + 人工 Review。后续团队补齐了单元测试、接口测试和 CI/CD，就可能进一步升级为：Dev Agent 修改代码 → 自动测试 → 人工 Review。反过来，当项目从开发阶段进入生产上线阶段时，Agent 的权限也可能收紧。因此，可以持续记录几个简单指标：

如果一个任务：

AI 生成非常快
+
人工修改很多
+
缺陷持续增加
+
验证时间很长

就应该降低 AI 的参与等级，而不是继续提高自动化。

七、不要把 AI 使用率变成 KPI

当企业开始推动 AI 使用以后，很容易出现一个新的管理误区：AI 使用率越高，项目越先进。这并不成立。一个项目真正的目标仍然是：按范围、按周期、按成本和质量完成交付。如果人工两小时就能稳定完成，而 AI 生成以后需要三小时检查和修改，那么不使用 AI 完全合理。

反过来，如果某项重复工作原本需要两天，AI 可以缩短到半天，而且结果能够快速验证，那么即使只是很普通的文档或测试任务，也非常值得规模化。因此，不应该问：项目有多少任务使用 AI？更应该问：AI 到底给项目节省了多少有效成本，同时有没有增加新的质量和风险。

八、结语：从“给人分任务”走向“设计人机分工”

AI 加入软件项目以后，任务分配正在发生一个非常明显的变化。过去项目经理主要回答：谁来做？现在还要继续回答：谁来负责，AI 做多少，人做多少？一个成熟的 AI 项目不应该追求“让 AI 做尽可能多的事情”，而应该形成一种更加清晰的任务结构：

重复、标准化工作 → AI 多做 可生成、可验证工作 → AI 生成，人确认 复杂判断型工作 → 人主导，AI 辅助 责任决策型工作 → 人负责

再通过 L0～L5，把这种分工真正映射到项目计划。因此，项目启动阶段识别 AI 任务的最终产物，不应该是一份“AI 可以做什么”的能力清单，而应该是一张清楚的：人机任务分工表。AI 能力还会继续变化，但项目管理真正需要稳定下来的，是一种新的任务分配原则：让 AI 承担最适合自动化和规模化的工作，让人把更多精力放到业务判断、方案取舍、质量控制和最终责任上。

上一篇回顾：

【AI时代软件项目管理系列】4. AI 时代的软件项目启动：从立项评估到 AI 可行性分析-腾讯云开发者社区-腾讯云

下一篇将进一步讨论：如何设计 AI 参与项目的边界和责任机制？

当项目已经明确“哪些任务让 AI 做”以后，紧接着就必须回答另一个问题：AI 到底能够做到哪里？

例如 Dev Agent 是否允许直接修改代码，能不能执行命令，能不能访问数据库；项目资料哪些可以进入模型上下文；高风险操作是否需要人工确认；AI 生成结果未经审核能否进入项目基线。数据边界、工具边界、执行权限、人工确认、审核机制和责任归属。因为真正成熟的人机协同，不只是把任务分给 AI，还要保证：AI 有明确的工作范围，人有明确的最终责任。

​