【AI时代软件项目管理系列】6.AI 参与软件项目，边界和责任怎么定？从“能做”到“可控执行”

上一篇讨论了项目启动阶段如何给 AI 分任务：重复、标准化工作可以让 AI 多做，可生成、可验证的工作可以采用“AI 生成 + 人确认”，复杂判断仍由人主导，责任决策则继续由人承担。

但当任务真的交给 AI，特别是从普通聊天工具进一步发展到能够访问代码、调用工具和执行操作的 Agent 后，一个更现实的问题随之出现：AI 可以参与，但到底可以参与到哪一步？

例如 Dev Agent 可以读取整个代码仓库吗？能不能直接修改主分支？可以连接测试数据库吗？发现一个权限问题以后，能不能自己修改数据库？PM Agent 可以自动创建项目任务，那么能不能直接调整里程碑？AI 生成的代码通过测试以后，能不能自动发布？这些问题已经不是“模型能力”问题，而是项目治理问题。

对于正式的软件项目来说，成熟的人机协作并不是简单地给 Agent 更多权限，而是让每一种 AI 能力都运行在明确的边界内：能看什么、能做什么、做到哪一步、谁来确认、出了问题谁负责。

一、AI 的能力越强，越不能只靠“大家注意安全”

AI 作为个人助手时，风险相对有限。例如用 AI 整理会议纪要、解释一段代码或者润色文档，主要风险集中在输入信息和输出质量上。但当 AI 进一步获得工具调用能力后，情况就不同了。一个 Dev Agent 可能具备：读取代码+搜索项目知识库+修改文件+执行构建+运行测试+调用 Git+操作 Issue+调用业务 API。如果再进一步连接数据库、部署平台或生产环境，它就不只是“生成建议”，而是在对真实项目产生状态变化。因此，可以把 AI 的参与大致区分为两类：1.生成型 AI➜产生建议 / 文档 / 代码➜结果不自动生效和2.执行型 Agent➜调用工具 / 修改数据 / 改变系统状态➜可能直接影响项目。两者需要的管理机制完全不同。普通 AI 最重要的是输入和输出边界，Agent 还必须增加工具、权限和执行边界。所以，项目启动阶段不能只形成一句：“允许团队使用 AI。”而应该进一步明确：允许哪一种 AI，在什么范围内，以什么权限参与哪些任务。

二、第一条边界：AI 能“看到”什么

AI 要完成任务，需要上下文。但上下文越完整，并不意味着所有项目资料都应该无条件交给模型。一个软件项目可能同时存在：

• 需求规格说明书；
• 架构设计；
• 源代码；
• 数据库结构；
• 测试数据；
• 客户业务资料；
• 项目合同；
• 生产日志；
• 用户个人信息；
• Access Key、Token、密码等敏感凭证。

因此，第一个需要明确的是数据与上下文边界。可以按照项目资料的敏感程度进行简单分级：

这里真正需要控制的不是“AI 有没有读取能力”，而是：当前任务是否真的需要这些信息。例如，一个 Doc Agent 生成用户手册，只需要产品功能、页面说明和操作流程，并没有必要访问数据库。一个 Test Agent 生成接口测试，需要接口定义和测试数据，却不应该因此自动获得生产数据库权限。因此，AI 的上下文最好遵循一个很重要的原则：按任务提供最小必要上下文，而不是为了让 AI 更聪明，把整个项目都交给它。

这四层可以贯穿整个项目：数据决定 AI 能看到哪里，工具决定能触达到哪里，权限决定能执行到哪里，审核决定结果能不能正式生效。

三、第二条边界：Agent 能调用哪些工具

Agent 与普通 AI 最大的区别之一，是它能够使用工具。工具本身没有问题，真正的风险在于：一个 Agent 获得了多少工具，以及这些工具拥有什么权限。例如一个 Dev Agent 可能连接：Git Repository、Issue 系统、代码搜索、构建工具、测试工具、数据库、CI/CD、服务器 Shell。如果全部开放，Agent 理论上就可能完成：修改代码➜提交代码➜修改数据库➜触发构建➜部署应用。这虽然接近“自动开发”，但也意味着单个 Agent 拥有了一条完整的高风险执行链。更合理的做法是按照角色配置工具。例如：

这里的核心仍然是：Agent 应该获得完成当前职责所需的工具，而不是获得项目里所有可用工具。这和传统 RBAC 权限设计其实非常类似。只是过去授权对象主要是：

用户
→ 角色
→ 权限

AI Agent 加入以后需要扩展为：

人
+
Agent
      ↓
角色
      ↓
工具权限
      ↓
资源范围
      ↓
允许操作

四、第三条边界：能调用工具，不代表可以直接执行

工具权限还需要继续细分。因为“读取 Git 仓库”和“向主分支提交代码”，风险完全不同；“查询数据库”和“执行 DELETE”，也不能使用相同权限。因此，对 Agent 最实用的控制方式，是按照操作风险继续划分执行等级。可以设计成四级：

很多团队真正应该大量使用的，其实是 E1～E3，而不是一开始就追求 E4。例如 Dev Agent：

读取代码             E1
      ↓
生成修改方案          E2
      ↓
修改工作分支          E3
      ↓
自动运行测试          E3
      ↓
创建 Pull Request     E3
      ↓
人工 Review
      ↓
合并主分支            人负责

这样已经能够节省大量开发工作，但仍然把关键状态变化控制在人手里。所以需要区分：Agent 可以执行任务和Agent 可以自主决定任务结果生效这是完全不同的两件事。

五、真正关键的是“不可逆操作”

AI 边界设计不需要把每一个工具调用都审批，否则 Agent 很快退化成一个操作极其繁琐的助手。真正值得设置人工门禁的，是高影响或不可逆操作。例如：

• 删除数据；
• 修改生产数据库；
• 合并主分支；
• 发布生产版本；
• 修改权限模型；
• 调整项目范围；
• 修改项目里程碑；
• 给客户发送正式结论；
• 批量通知用户；
• 执行资金或合同相关操作。

可以采用一个很简单的判断：

低影响 + 可回退
       ↓
允许 Agent 自动执行
高影响 / 难回退
       ↓
必须人工确认

这样项目治理不会因为 AI 而变得过于繁琐，又能守住真正重要的控制点。

六、第四条边界：AI 生成物什么时候才算“项目成果”

这是软件项目中非常容易混淆的一点。AI 生成了一份需求文档，并不代表需求已经确定；Dev Agent 写完代码，并不代表开发完成；Test Agent 执行完测试，也不代表质量已经达到标准；PM Agent 给出“项目风险较低”，更不代表项目经理可以取消风险跟踪。应该建立非常明确的关系：AI Output➜候选成果➜验证 / Review➜人工确认➜正式项目成果➜进入项目基线。也就是说：AI 产出默认是候选结果，而不是项目基线。只有经过项目规定的审核、测试或审批以后，才能成为正式成果。这一点尤其重要，因为 Agent 越自动化，产生内容的速度越快。如果缺少基线机制，项目很容易同时存在大量：

• AI 初稿；
• 人工修改稿；
• Agent 新版本；
• 测试版本；
• 未确认方案。

最终反而不知道哪一个才是正式版本。AI 生成内容必须进入统一项目基线，本身也是人机混合项目保持整体一致性的关键。

七、责任机制不能只写一句“人工负责”

明确“最终责任由人承担”只是第一步。系列本身也明确要求 AI 可以建议、生成和辅助，但最终责任必须由人承担。真正落到项目中，还需要继续回答：到底由哪个人负责？例如：

这种设计有两个价值。第一，避免出现：“这段代码是 AI 写的，所以没人负责”；第二，也避免另一种极端：“所有 AI 结果都由项目经理负责”。项目经理负责整个项目治理，并不意味着他需要承担每个专业成果的技术责任。更合理的是：AI 的专业输出，仍然回到对应的人工专业责任链。已有角色设计中也采用了相同结构：PM Agent 对应项目经理、BA Agent 对应业务分析师、Architect Agent 对应架构师、Dev Agent 对应开发负责人、Test Agent 对应测试负责人。

八、可以借用 RACI，但增加一个 AI 角色

传统项目常用 RACI：

• R：Responsible，执行；
• A：Accountable，最终负责；
• C：Consulted，协商；
• I：Informed，知会。

AI 加入以后，可以增加一个角色：X：AI / Agent Execution。于是一个任务可能变成：

这里要强调：AI 可以成为执行角色，但不进入最终责任角色 A。这比单纯写“人工最终负责”更加容易落地。

AI 参与项目的责任闭环

编辑

这个闭环的重点不是“每一步都人工审批”，而是让AI 执行、自动验证、人工责任和项目基线形成完整链路。

九、以“离职成员文件交接”为例，看看边界如何落地

以企业云文档系统中的“离职成员文件交接”为例。需求看起来并不复杂：员工离职后，将其拥有的企业文件交接给指定成员，并取消原账号访问权限。如果让 Agent 自动开发，它首先可能需要：

• 阅读组织架构代码；
• 阅读用户与部门模型；
• 查询文件 Owner 关系；
• 查看权限继承逻辑；
• 修改交接服务；
• 生成迁移 SQL；
• 编写测试；
• 执行测试数据迁移。

如果只告诉 Agent：“完成离职文件交接功能。”权限很容易过大。更合理的边界可以设计成下面这样。

数据边界

Agent 可以读取：用户模型、组织关系、文件权限设计、相关代码、脱敏测试数据。但不能读取：真实客户文件内容、生产成员个人信息、密钥和数据库密码。

工具边界

Dev Agent 可以：读取代码仓库、修改开发分支、执行 Maven / Gradle、运行测试、读取测试数据库。不能：连接生产数据库、直接修改正式环境、执行生产部署

执行边界

Agent 可以自动：修改代码、生成迁移脚本、生成单元测试、执行测试、创建 Pull Request。但：数据库迁移脚本不能因为测试通过就自动进入生产。

输出边界

最终流程应该是：Dev Agent➜代码 + SQL➜自动测试➜开发 Review➜权限场景测试➜数据库变更审核➜人工批准➜发布。

这里 AI 已经承担了大量开发工作，但真正高风险的节点仍然被保留下来。这就是“AI 参与”与“AI 失控”之间最重要的区别。

十、项目启动阶段最好形成一张 AI 权限与责任矩阵

这篇文章最终可以落到一个项目经理能够直接使用的模板。

这张表真正解决了六个问题：谁➜可以看什么➜可以调用什么➜可以执行什么➜什么不能做➜最终谁负责。只要这六件事情清楚，很多所谓“AI 治理”问题其实就已经有了基础。

十一、边界不是越严越好，而应该与风险匹配

AI 治理很容易走向两个极端。一个极端是：Agent 什么都可以做，结果是风险不可控。另一个极端是：Agent 每做一步都必须人工确认，结果是自动化价值几乎消失。更合理的方式应该是：

Agent 执行策略
                    │
          ┌─────────┴─────────┐
          │                   │
     低风险任务            高风险任务
          │                   │
       可验证               难验证
          │                   │
       可回退               不可逆
          │                   │
          ▼                   ▼
   提高自主执行程度       收紧执行权限
          │                   │
 自动执行 / 自动验证     人工确认 / 审批门禁
 自动提交候选结果         审计留痕 / 人工负责

风险越低、验证越容易、回退能力越强，Agent 可以获得越高的自主权；风险越高、结果越难验证、操作越不可逆，越需要收紧权限并增加人工门禁。

所以 AI 边界本质上不是限制 AI，而是在设计一条：自动化效率与项目风险之间的平衡线。Agent 的执行能力越强，这条线越重要。

十二、结语：真正成熟的 AI 项目，不是 Agent 权限最大，而是边界最清楚

从前面的几篇文章可以看到，项目启动阶段正在多出一套过去没有的管理动作。先判断项目是否具备 AI 可行性，再确定哪些任务交给 AI；任务确定以后，还要继续明确 AI 的数据、工具、执行和输出边界，并把每一项 AI 工作重新接回人工责任链。因此，一个真正可控的 AI 项目应该形成这样的逻辑：任务➜AI / Agent➜最小必要数据➜最小必要工具➜受控执行权限➜自动验证➜人工责任人➜项目基线。项目经理不需要审核 Agent 的每一次思考，也不应该管理每一次模型调用。真正应该管理的是那些会影响项目结果的关键边界：AI 能看到哪里、能操作到哪里、什么结果可以正式生效，以及最终谁承担责任。所以，AI 项目治理的目标并不是：让 Agent 什么都不能做。也不是：让 Agent 什么都可以做。而是：让 AI 在明确边界内尽可能高效地执行，同时让关键决策、质量和最终责任始终有人承担。AI Agent 可以承担越来越多执行工作，但它本身不是项目责任主体；最终确认、审核和交付责任仍然必须落到人。

上一篇回顾：

https://developer.aliyun.com/article/1757646?spm=a2c6h.13148508.setting.16.14634f0e6HvtUA

下一篇：AI 工具选型为什么也应该纳入项目启动范围？

当任务、人机分工、权限边界和责任机制都基本明确以后，下一个问题自然变成：到底应该用什么 AI？通用大模型、AI 编程工具、RAG 知识库、Agent 平台和私有化模型解决的并不是同一种问题；即使模型能力相近，在数据策略、企业权限、审计能力、工具集成、成本和部署方式上也可能完全不同。

因此，下一篇将从项目管理而不是单纯“模型排行榜”的角度讨论：AI 工具选型如何进入项目启动流程，以及企业项目应该如何从能力、成本、安全、部署、稳定性和可替换性等方面进行评估。