AI 不是让程序员更强，而是让传统研发分工变得更脆弱

过去一段时间，我越来越不愿意用“AI 能把程序员效率提高多少”来讨论 AI 编程。

这个问题太小了。

真正发生的变化是：需求、设计、编码、测试、发布和运维之间原本清晰的分工，正在被 Agent 重新连接。传统研发组织依赖大量人工交接，而 Agent 最擅长处理的恰恰是这些交接中的上下文搬运、规则执行和重复判断。

在一次团队实践中，我们把数据库适配、插件开发、应用打包和日志排障等高频工作沉淀成可复用的 Skill。某些原本需要多轮查资料和反复试错的任务，被压缩到了约一到两天。但真正有价值的不是数字本身，而是下一位工程师不再从零开始。

事实边界：“一天、两天”来自一次团队实践，是项目口径，不代表行业普遍水平。

我把团队的 AI-DLC 能力分成五级。

1. L1 是个人辅助。 工程师会用聊天工具、IDE 或 CLI Agent，个人速度变快，但经验仍留在个人对话里。
2. L2 是团队试点。 团队开始共享提示词、案例和工具，但流程仍不稳定，换一个人可能又要重来。
3. L3 是流程融合。 需求有 Spec，仓库有 Rule，经验被封装为 Skill，测试和质量门禁能够自动运行。Agent 不只是生成代码，而是进入真实交付链路。
4. L4 是 Agentic 交付。 Agent 可以在明确边界内完成需求分析、实现、自测、提交 PR 和证据整理，人类负责高风险决策与最终审批。
5. L5 是组织级能力。 模型、知识、工具、权限、审计、成本和复盘统一治理，跨团队经验可以重复使用。

很多团队卡在 L1，却误以为自己已经完成 AI 转型。大家都在用 AI，演示也很漂亮，但换一个项目、一个仓库、一个负责人，效率又回到原点。

判断团队有没有真正升级，我只看四件事：

1. Agent 能不能拿到正确上下文？
2. Agent 的输出能不能被独立验证？
3. Agent 的动作能不能被追踪和回滚？
4. 这次经验能不能降低下一次同类任务的成本？

这四个问题比“选哪一个模型”更重要。

模型会越来越强，也会越来越便宜。真正稀缺的是把业务知识、工程规则、工具接口和质量标准组织起来的能力。未来优秀的工程师不只是写代码快，而是能够定义问题、设计约束、编排 Agent，并判断结果是否可信。

所以，小团队不必一开始就建设大而全的 AI 平台。更现实的路径是：先选一个高频、边界清晰、结果可验证的任务；为它补齐 Spec、Rule、Skill 和测试门禁；跑通一次从输入到交付的闭环；再把经验复制到下一个场景。

AI-DLC 是否成功，最终不是看生成了多少代码，而是看下一次遇到同类问题时，团队能不能更快、更稳、返工更少。

当答案是肯定的，AI 才不只是个人工具，而开始成为组织能力。