上一篇解决的是项目级问题这个项目是否适合引入 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 在任务中的职责比例。三、再把任务映射到 L0L5而不是一开始就追求 Agent完成任务分类以后再决定 AI 参与到什么程度。可以继续使用 L0L5 的参与度分级等级AI 参与方式典型场景L0不使用 AI最终验收、部分涉密或高风险操作L1个人辅助查询、解释、润色、方案讨论L2任务辅助需求拆分、测试用例、代码草稿L3流程参与自动测试、Code Review、文档流水线L4Agent 协同Dev Agent、Test Agent、PM AgentL5软件工厂多 Agent 连续完成研发流程这里最重要的一点是L0L5 不是升级路线而是参与等级。不是所有任务都应该从 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 类L1L2。4. DTO、Controller 和普通接口代码设计已经明确以后输入和输出都比较标准化。例如CreateShareRequest ShareConfigDTO ShareController ShareService ShareRecordMapper可以由 AI 编程工具或 Dev Agent 生成并结合自动编译和单元测试验证。建议B 类L3。5. 外链权限核心逻辑例如是否跨租户 是否允许匿名访问 密码是否正确 外链是否过期 管理员是否已经关闭分享 文件当前是否仍可访问这部分虽然也能由 AI 写但涉及数据安全一旦出现越权问题影响较大。建议C/B 类L2L3。AI 辅助实现但必须经过人工 Review、安全测试和权限场景验证。6. 单元测试和接口测试由于输入、预期结果相对明确可以让 AI 根据接口定义和业务规则批量生成测试。建议A/B 类L3。7. 上线决策即使所有自动测试都通过是否允许新功能进入生产环境仍然应该由项目和技术负责人确认。建议D 类L0。把整个需求重新排列后就会发现子任务分工等级需求材料整理AI 生成 人确认L2遗漏场景分析AI 辅助L2权限方案设计人主导 AI 推演L1L2DTO / ControllerAI / Agent 生成L3普通业务逻辑Agent ReviewL3权限核心逻辑人主导 AI 辅助L2L3单元测试AI 自动生成L3安全测试AI 辅助 人验证L2L3部署文档AI 生成 人确认L2上线决策人负责L0这说明一个需求并不存在统一的 AI 等级真正需要管理的是需求内部不同任务的人机分工。五、AI 应该真正进入 WBS 和项目计划如果 AI 已经承担真实项目工作就不应该继续停留在“开发人员会使用 AI。”这样的描述上。更合理的方式是把 AI 参与正式写入任务计划。例如增加一张 AI 任务登记表任务责任人AI 方式等级AI / Agent输出验证方式需求拆分BAAI 生成 确认L2BA Agent用户故事需求评审API 开发开发Agent 执行L3Dev AgentJava 代码UT Review权限核心逻辑架构/开发AI 辅助L2编程助手代码安全测试单元测试开发流程自动化L3Test AgentUT自动执行周报PMAgent 汇总L3PM Agent周报PM 确认这一步非常重要。因为只有进入计划以后项目经理才能继续管理任务是否完成AI 输出是否被采用人工审核是否结束返工是否增加最终成果是否可以进入项目基线。AI 才真正从个人工具变成项目资源。AI 任务进入项目计划的过程六、AI 分工不是一次确定后永远不变项目启动阶段形成的是第一版人机分工。随着工程条件变化同一个任务的 AI 参与度也可能调整。例如一个老项目刚开始时没有自动化测试普通接口代码只能采用AI 生成 人工 Review。后续团队补齐了单元测试、接口测试和 CI/CD就可能进一步升级为Dev Agent 修改代码 → 自动测试 → 人工 Review。反过来当项目从开发阶段进入生产上线阶段时Agent 的权限也可能收紧。因此可以持续记录几个简单指标指标关注点AI 输出采用率生成结果到底有多少能用人工修改率是否需要大量重写实际节省工时是否真的提效缺陷率是否引入更多质量问题验证成本审核是不是比生成更慢返工次数是否反复修改异常事件是否产生安全或权限问题如果一个任务AI 生成非常快 人工修改很多 缺陷持续增加 验证时间很长就应该降低 AI 的参与等级而不是继续提高自动化。七、不要把 AI 使用率变成 KPI当企业开始推动 AI 使用以后很容易出现一个新的管理误区AI 使用率越高项目越先进。这并不成立。一个项目真正的目标仍然是按范围、按周期、按成本和质量完成交付。如果人工两小时就能稳定完成而 AI 生成以后需要三小时检查和修改那么不使用 AI 完全合理。反过来如果某项重复工作原本需要两天AI 可以缩短到半天而且结果能够快速验证那么即使只是很普通的文档或测试任务也非常值得规模化。因此不应该问项目有多少任务使用 AI更应该问AI 到底给项目节省了多少有效成本同时有没有增加新的质量和风险。八、结语从“给人分任务”走向“设计人机分工”AI 加入软件项目以后任务分配正在发生一个非常明显的变化。过去项目经理主要回答谁来做现在还要继续回答谁来负责AI 做多少人做多少一个成熟的 AI 项目不应该追求“让 AI 做尽可能多的事情”而应该形成一种更加清晰的任务结构重复、标准化工作 → AI 多做可生成、可验证工作 → AI 生成人确认复杂判断型工作 → 人主导AI 辅助责任决策型工作 → 人负责再通过 L0L5把这种分工真正映射到项目计划。因此项目启动阶段识别 AI 任务的最终产物不应该是一份“AI 可以做什么”的能力清单而应该是一张清楚的人机任务分工表。AI 能力还会继续变化但项目管理真正需要稳定下来的是一种新的任务分配原则让 AI 承担最适合自动化和规模化的工作让人把更多精力放到业务判断、方案取舍、质量控制和最终责任上。上一篇回顾【AI时代软件项目管理系列】4. AI 时代的软件项目启动从立项评估到 AI 可行性分析-CSDN博客下一篇将进一步讨论如何设计 AI 参与项目的边界和责任机制当项目已经明确“哪些任务让 AI 做”以后紧接着就必须回答另一个问题AI 到底能够做到哪里例如 Dev Agent 是否允许直接修改代码能不能执行命令能不能访问数据库项目资料哪些可以进入模型上下文高风险操作是否需要人工确认AI 生成结果未经审核能否进入项目基线。数据边界、工具边界、执行权限、人工确认、审核机制和责任归属。因为真正成熟的人机协同不只是把任务分给 AI还要保证AI 有明确的工作范围人有明确的最终责任。
上一篇解决的是项目级问题这个项目是否适合引入 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 在任务中的职责比例。三、再把任务映射到 L0L5而不是一开始就追求 Agent完成任务分类以后再决定 AI 参与到什么程度。可以继续使用 L0L5 的参与度分级等级AI 参与方式典型场景L0不使用 AI最终验收、部分涉密或高风险操作L1个人辅助查询、解释、润色、方案讨论L2任务辅助需求拆分、测试用例、代码草稿L3流程参与自动测试、Code Review、文档流水线L4Agent 协同Dev Agent、Test Agent、PM AgentL5软件工厂多 Agent 连续完成研发流程这里最重要的一点是L0L5 不是升级路线而是参与等级。不是所有任务都应该从 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 类L1L2。4. DTO、Controller 和普通接口代码设计已经明确以后输入和输出都比较标准化。例如CreateShareRequest ShareConfigDTO ShareController ShareService ShareRecordMapper可以由 AI 编程工具或 Dev Agent 生成并结合自动编译和单元测试验证。建议B 类L3。5. 外链权限核心逻辑例如是否跨租户 是否允许匿名访问 密码是否正确 外链是否过期 管理员是否已经关闭分享 文件当前是否仍可访问这部分虽然也能由 AI 写但涉及数据安全一旦出现越权问题影响较大。建议C/B 类L2L3。AI 辅助实现但必须经过人工 Review、安全测试和权限场景验证。6. 单元测试和接口测试由于输入、预期结果相对明确可以让 AI 根据接口定义和业务规则批量生成测试。建议A/B 类L3。7. 上线决策即使所有自动测试都通过是否允许新功能进入生产环境仍然应该由项目和技术负责人确认。建议D 类L0。把整个需求重新排列后就会发现子任务分工等级需求材料整理AI 生成 人确认L2遗漏场景分析AI 辅助L2权限方案设计人主导 AI 推演L1L2DTO / ControllerAI / Agent 生成L3普通业务逻辑Agent ReviewL3权限核心逻辑人主导 AI 辅助L2L3单元测试AI 自动生成L3安全测试AI 辅助 人验证L2L3部署文档AI 生成 人确认L2上线决策人负责L0这说明一个需求并不存在统一的 AI 等级真正需要管理的是需求内部不同任务的人机分工。五、AI 应该真正进入 WBS 和项目计划如果 AI 已经承担真实项目工作就不应该继续停留在“开发人员会使用 AI。”这样的描述上。更合理的方式是把 AI 参与正式写入任务计划。例如增加一张 AI 任务登记表任务责任人AI 方式等级AI / Agent输出验证方式需求拆分BAAI 生成 确认L2BA Agent用户故事需求评审API 开发开发Agent 执行L3Dev AgentJava 代码UT Review权限核心逻辑架构/开发AI 辅助L2编程助手代码安全测试单元测试开发流程自动化L3Test AgentUT自动执行周报PMAgent 汇总L3PM Agent周报PM 确认这一步非常重要。因为只有进入计划以后项目经理才能继续管理任务是否完成AI 输出是否被采用人工审核是否结束返工是否增加最终成果是否可以进入项目基线。AI 才真正从个人工具变成项目资源。AI 任务进入项目计划的过程六、AI 分工不是一次确定后永远不变项目启动阶段形成的是第一版人机分工。随着工程条件变化同一个任务的 AI 参与度也可能调整。例如一个老项目刚开始时没有自动化测试普通接口代码只能采用AI 生成 人工 Review。后续团队补齐了单元测试、接口测试和 CI/CD就可能进一步升级为Dev Agent 修改代码 → 自动测试 → 人工 Review。反过来当项目从开发阶段进入生产上线阶段时Agent 的权限也可能收紧。因此可以持续记录几个简单指标指标关注点AI 输出采用率生成结果到底有多少能用人工修改率是否需要大量重写实际节省工时是否真的提效缺陷率是否引入更多质量问题验证成本审核是不是比生成更慢返工次数是否反复修改异常事件是否产生安全或权限问题如果一个任务AI 生成非常快 人工修改很多 缺陷持续增加 验证时间很长就应该降低 AI 的参与等级而不是继续提高自动化。七、不要把 AI 使用率变成 KPI当企业开始推动 AI 使用以后很容易出现一个新的管理误区AI 使用率越高项目越先进。这并不成立。一个项目真正的目标仍然是按范围、按周期、按成本和质量完成交付。如果人工两小时就能稳定完成而 AI 生成以后需要三小时检查和修改那么不使用 AI 完全合理。反过来如果某项重复工作原本需要两天AI 可以缩短到半天而且结果能够快速验证那么即使只是很普通的文档或测试任务也非常值得规模化。因此不应该问项目有多少任务使用 AI更应该问AI 到底给项目节省了多少有效成本同时有没有增加新的质量和风险。八、结语从“给人分任务”走向“设计人机分工”AI 加入软件项目以后任务分配正在发生一个非常明显的变化。过去项目经理主要回答谁来做现在还要继续回答谁来负责AI 做多少人做多少一个成熟的 AI 项目不应该追求“让 AI 做尽可能多的事情”而应该形成一种更加清晰的任务结构重复、标准化工作 → AI 多做可生成、可验证工作 → AI 生成人确认复杂判断型工作 → 人主导AI 辅助责任决策型工作 → 人负责再通过 L0L5把这种分工真正映射到项目计划。因此项目启动阶段识别 AI 任务的最终产物不应该是一份“AI 可以做什么”的能力清单而应该是一张清楚的人机任务分工表。AI 能力还会继续变化但项目管理真正需要稳定下来的是一种新的任务分配原则让 AI 承担最适合自动化和规模化的工作让人把更多精力放到业务判断、方案取舍、质量控制和最终责任上。上一篇回顾【AI时代软件项目管理系列】4. AI 时代的软件项目启动从立项评估到 AI 可行性分析-CSDN博客下一篇将进一步讨论如何设计 AI 参与项目的边界和责任机制当项目已经明确“哪些任务让 AI 做”以后紧接着就必须回答另一个问题AI 到底能够做到哪里例如 Dev Agent 是否允许直接修改代码能不能执行命令能不能访问数据库项目资料哪些可以进入模型上下文高风险操作是否需要人工确认AI 生成结果未经审核能否进入项目基线。数据边界、工具边界、执行权限、人工确认、审核机制和责任归属。因为真正成熟的人机协同不只是把任务分给 AI还要保证AI 有明确的工作范围人有明确的最终责任。
