现在很多团队用 AI 编程，场面有点像请了一个特别勤快的实习生。
他一天能交十个 PR，语气还很自信：“都测过了，可以合。”
问题是，等资深工程师打开一看，十个里面有四个能留，三个要返工，两个像半夜梦游写的，最后一个最好先别问它为什么改了鉴权逻辑。
这不是段子。4 月的一篇 SWE-chat 论文分析了 6000 个真实开源 coding agent 会话，里面有 6.3 万多条用户 prompt、35.5 万次工具调用。结论很刺眼：agent 生成的代码，最终只有 44% 进入用户 commit；用户也会在 44% 的轮次里纠正、打断或报告失败。
所以，AI 编程真正的问题不是“它会不会写”。它太会写了。
更值得问的是：写出来的东西，团队能不能放心留下来。
个人摸索不能自动复利
如果一个团队只是给每个人发一个 AI 工具账号，然后说“大家提高效率吧”，最后很容易变成提示词广场舞。
有人让 AI 直接改生产代码，有人让它先写计划，有人开五个 agent 并行冲刺，也有人把它当搜索引擎用。每个人都觉得自己摸到了门道，但这些门道很难复用。
Stack Overflow 最近采访了 Snowflake 工程 SVP Vivek Raghunathan。Snowflake 的做法，是先允许探索，再把有效经验沉淀成团队语言。他们总结出一组 AI design patterns，比如先用英文写 plan，再写代码；多 agent 并行时用 worktree 隔离；把排障和运维经验沉淀成 skill。
这个案例的重点，是它承认了一个现实：AI 编程如果只停留在个人手艺，就不会复利。
一个工程师今天摸到一个好用法，明天忘了；另一个工程师踩了同样的坑，下周再踩一次。团队看起来每天都在使用 AI，其实每天都在重新交学费。
团队要有自己的玩法
Snowflake 的案例里有几个数字很有意思：他们说工程师使用 coding agent 的周活已经很高，release validation 从 15 天压到 1 天，测试量也明显增加。数字本身不必照搬，但方向值得学。
AI 写代码像开水龙头。个人效率看的是水大不大，团队效率看的是有没有管道、过滤器和水表。
对普通团队来说，可以先从四件事开始。
第一，先写计划，再写代码。 不要一上来就让 AI “帮我实现这个功能”。先让它写 markdown plan，列出改哪些文件、风险在哪里、怎么验收。计划都说不清，代码越多越像装修队没图纸先砸墙。
第二，并行 agent 必须隔离。 多开几个 agent 可以提速，但不要让它们在同一个目录里抢方向盘。用 worktree、临时分支或沙箱把它们围起来。否则三个 agent 同时改同一块代码，最后像三个人在厨房一起炒一盘菜：火很旺，锅也可能没了。
第三，先定验收标准。 AI 最适合做能验证的任务。测试、lint、类型检查、回归样例、截图对比，这些环节会让 AI 的产出更容易留下来。没有验收标准的 AI 编程，就像没有安检的高铁站，热闹但吓人。
第四，把经验写成团队资产。 哪些 prompt 有效，哪些任务必须人工 review，哪些目录不能让 agent 碰，哪些错误一出现就该回滚，都应该进入规则、模板、skill 或 checklist。不要靠“我记得上次好像这样做过”。人脑缓存，比浏览器缓存还不可靠。
AI 编程的上半场，是个人学会怎么指挥模型。下半场，是团队学会怎么让经验复利。
以后真正拉开差距的，会是两件事：把更多代码安全留下，把更多教训变成下次自动生效的规则。
AI 可以把代码写得像开闸放水，但团队要负责修水渠。没有水渠，水越大，淹得越快。
