团队最容易走向两个极端

当 AI 真正进入研发流程之后，团队通常不会卡在“要不要用”，而会卡在“到底怎么分工”。

最常见的是两个极端。一个是把 AI 当成外包商，默认只要 prompt 足够清楚，大部分工作都可以整包丢出去。另一个是因为担心幻觉、漏洞和技术债，干脆只允许它做最边角的琐事，结果团队既没有吃到提效红利，也没有真正积累新的协作能力。

这两个极端的问题一样：先替工具下了结论，却没有先把任务拆开。

OpenAI 在 agent 实践指南里强调，能否让 agent 稳定工作，关键不是“模型够不够强”，而是先判断任务是不是复杂决策、是不是高风险动作、是不是需要人工接管。NIST 的 AI RMF 和 GenAI Profile 也在强调同一件事：风险管理不是上线前的勾选清单，而是一套贯穿设计、开发、部署和使用全过程的分级方法。

放回软件研发，更稳的起点不是问“AI 能不能做”，而是问“这类任务该用什么协作关系做”。

先用四个问题给任务分层

真正有用的，不是先讨论工具强不强，而是先回答四个问题。

  • 证据成本高不高：这件事完成之后，团队要付出多大代价才能验证它是否正确。
  • 可逆性强不强：做错了之后，是不是容易撤回、修正和回滚。
  • 影响半径大不大：这次改动会不会牵动核心链路、权限边界、财务和安全后果。
  • 学习价值高不高：这件事是不是团队成员必须亲自经历，才能长出长期判断力。

这四个问题对应的是四个基本动作：先看证据，再看后果，再看边界，最后看认知收益。它们比“这个模型最近很强”更适合决定分工。

比如补一个低风险回归测试，证据成本低、可逆性强、影响半径小、学习价值也不高，这就很适合深度委托给 AI。可如果是重构支付状态机、改权限模型、设计跨团队数据契约，四个维度里至少会亮两三个红灯，这类任务就不应该再用同一种协作方式处理。

四种协作方式

基于这四个问题，人机协作更适合分成四种方式，而不是只分“用 AI”或“不用 AI”。

第一种：低风险委托

这一类任务的特征是，证据成本低，可逆性强，影响半径小，而且即使交给 AI 也不会明显伤害人的长期能力。

典型例子包括补样板代码、生成脚手架、修简单样式、补低风险测试、整理日志、写文档初稿、批量做格式化和轻量重构。

这里适合把 AI 当成执行器。人负责给范围和验收条件，AI 负责生成，人只做快速抽检和自动化验证。过度手工介入只会把流程拖回“先让 AI 写，再由人完整重写一遍”。

第二种：规格驱动协作

这一类任务的特点是，结果可以验证，但验证并不免费，影响半径也已经开始扩张。

比如做一个新接口、补一段业务流程、重写一个组件、改一条数据同步链路。这里更合适的做法，不是把任务一句话扔给 AI，而是先把规格写清楚，再由 AI 生成，再由自动化和人工一起验。

OpenAI 的指南里反复强调 eval 和 guardrails 的位置，这一层正好对应。人应该先把目标、输入输出、不能碰的边界、失败条件和回退方案写成规格。AI 负责把规格翻译成实现。机器负责做第一轮编译、测试、静态检查和回归。人最后只盯关键差异，而不是从零盯完整产出。

第三种：并肩学习

这一类任务最容易被忽视，但它对团队长期能力最重要。它们未必最危险，却有很高学习价值。

Anthropic 在 2026-01-29 的技能形成研究里发现，用 AI 的组虽然完成任务略快，但得分显著更低，尤其是在调试理解上差距更大。很多看起来“可以外包给 AI”的工作，恰恰是新人和转岗者长基本功的关键场景。

因此，遇到新框架、新库、新基础设施、新架构约束时，更好的关系往往不是委托，而是并肩。让人先自己写骨架，或者自己先给出一版理解，再让 AI 做解释、对照、举反例、给重构建议，最后再由人亲手收尾。AI 在这里更像陪练，而不是代写员。

这一段慢一点，通常更划算。团队靠它保住看懂系统、诊断错误和独立判断的能力。

第四种：高风险审议

最后一类任务，是那些证据成本高、影响半径大、可逆性差的动作。

比如发布策略改动、权限放宽、删除数据、账务逻辑、关键安全配置、跨系统状态迁移，或者任何一类“错一次就代价很高”的变更。

OpenAI 的指南把 high-risk actions 和 human intervention 单独拿出来讲，NIST 也强调风险要贯穿整个生命周期。这类任务里，AI 最多适合做方案准备、差异分析、测试建议和异常排查，不适合成为最后拍板者。最终判断权必须留在人手里，而且最好保留显式审批痕迹。

越接近不可逆动作，AI 越应该退到参谋位，而不是执行位。

把它放进流程

这四种方式要真正起作用，得嵌进团队流程。

需求阶段先判影响半径和学习价值。设计阶段先判证据成本。实现阶段再决定委托深度。验证阶段决定是否需要人工复核。上线阶段再按可逆性决定谁有放行权。

一个更落地的做法，是在任务单或 PR 模板里补四个字段。

  • 验证方式是什么。
  • 失败后能否直接回滚。
  • 影响范围涉及哪些系统和角色。
  • 这次任务是否属于团队希望保留的人类训练样本。

这四个字段长期存在，团队就不必反复争论“到底信不信 AI”，而会直接落到“这次该用哪种协作方式”。

真正该看的，不是 token，而是团队有没有变得更稳

很多组织现在开始把 AI 使用量写进绩效，可如果指标只剩 token、调用次数和自动生成比例，团队很快会把目标做歪。

更值得追的指标，其实是这些。

  • AI 参与的改动，合入后回滚率有没有上升。
  • AI 生成代码的解释覆盖率有没有下降。
  • 自动化验证通过后，人工复核仍然能发现多少关键问题。
  • 新人是否越来越依赖 AI，却越来越不会自己调试和拆问题。

Anthropic 关于内部工作的研究里提到，工程师因为 AI 变得更全栈、迭代更快、可以处理更多原本顾不上的任务；但 Stack Overflow 的调查又提醒我们，团队协作层面的改善远弱于个人效率提升，只有 17% 的 agent 使用者认为它明显改善了团队协作。瓶颈不再只是个人会不会用工具，而是团队有没有形成一套共同的分工语言。

最后该训练的，不是更会许愿，而是更会判断

AI 时代的软件研发，不会因为工具更强，就自动变成“谁更会许愿谁就赢”。更值钱的能力，是把任务分级、把风险写清、把验证做实、把学习机会留下来。

别把 AI 当外包商。外包商的默认关系，是你把结果买回来；更成熟的人机协作，是你知道什么时候该让它自己跑，什么时候该让它并肩走，什么时候只能让它做参谋。