ARTICLE · 1127305
AI 写代码之后,软件该怎么做?
很多团队这一两年都经历过同一件事：公司给每个程序员配了 AI 编程工具，大家交上来的代码明显多了，可产品上线的速度没怎么变。
代码去哪儿了？大部分躺在「等人审」的队列里。
这篇想讲清楚一件事：AI 让写代码变便宜了，但没让「说清楚要什么」和「确认做对了」变便宜。 所谓 AI 原生的研发流程，说白了就是围绕这两头，把人的时间重新排一遍。
打个比方：来了一支快得离谱的装修队
以前做软件，像请一位老师傅装修。师傅干得慢，一面墙砌三天，你有的是时间站在旁边看，哪里不对当场就说了。
现在来了一支新队伍：一小时砌完一面墙，24 小时不休息，从不抱怨。听起来是好事，但问题马上换了个样子：
- 图纸没画清楚，他们不会停下来问你
，会按最常见的样子直接砌。砌得又快又整齐，就是跟你想的不一样。 - 你验收不过来。
以前一天看一面墙，现在一天交来二十面，每面你都得检查有没有偷工减料。 - 他们不知道你家的规矩。
哪面墙里埋着水管、哪里不能打孔，没写在纸上的，他们一概不知道。
墙砌得再快，业主手里那张验收单还是只能一面一面地勾
这三条，对应的就是 AI 写代码之后最要紧的三件事：规格、验收、上下文。
瓶颈搬家了
软件开发大致是一条流水线：想清楚要什么 → 写代码 → 检查代码 → 上线。
过去最慢的是「写代码」那一段，所以几十年来，各种工具和方法都在帮人写得更快。
AI 一来，「写」这一段突然宽了好几倍，可后面「检查」那一段还是原来那几个人、那几双眼睛。流水线的速度由最窄的那一段决定，于是瓶颈从「写」搬到了「审」。
管子的粗细是示意，表示每段单位时间能处理多少代码
这时候会出现两种局面，都不好：
- 审得松
：没看懂的代码就合进去了，问题埋在里面，过几个月才炸。 - 审得严
：审代码的人成了全队最慢的一环，AI 再快也白搭。
所以只给写代码提速，结果往往是队列更长，整体并不快。
一个反直觉的实验：觉得快了，其实慢了
2025 年，研究机构 METR 做了一个很认真的实验。他们请了 16 位经验丰富的开源项目开发者，在自己维护多年的项目上做 246 个真实任务，随机决定每个任务能不能用 AI 工具（当时用的是 2025 年初的主流工具），然后掐表。
结果是这样的：
开工前，开发者们预计 AI 能让自己快 24%； 做完以后，他们自己感觉快了 20%； 实际掐表，用了 AI 的任务反而慢了 19%。
数据：METR 2025 年随机对照试验，16 位资深开源开发者、246 个真实任务
慢在哪儿？写提示、等结果、读 AI 写的东西、发现不对再改，这些时间加起来，把省下的全吃掉了。这批人对自己的代码库太熟，很多活自己动手本来就很快。
这个实验不是说 AI 没用。换成不熟悉的项目、新手、或者更新的工具，结论可能不一样。它真正值得记住的是另一点：人对「AI 让我快了多少」的体感很不靠谱。 评估 AI 工具，要掐表，不要问感觉。
四件新功课
既然瓶颈在两头，功夫也就该下在两头。下面四件事，是我认为一个团队真正用好 AI 必须补上的。
第一件：把需求写成规格
跟 AI 说「做个登录功能」，它不会追问你要手机验证码还是邮箱密码，多半直接挑一个最常见的做出来。做得很快，也很像样，就是可能不是你要的。
所以一句话的需求不够，得写成一份简短的规格，至少讲清四样：
- 目标
：用户用手机号加验证码登录； - 约束
：沿用公司现有的短信服务； - 验收标准
：验证码 5 分钟过期，输错 5 次锁定； - 不做什么
：这次不做第三方登录，不做找回密码。
最后一条最容易漏，也最重要。你不说「不做」，AI 很可能顺手帮你做了，还做出一堆你没打算维护的东西。
上半张：一句话，AI 自己挑；下半张：四样写清，就只剩一种做法
规格本质上是给 AI 的验收单。说不清，就验不了。
第二件：给 AI 喂对上下文
可以把 AI 想成一个天才实习生：聪明、手快，但每天都是第一天上班。它默认不记得昨天聊过什么，没参加过你们的会，也不知道团队里那些口口相传的规矩，比如「这个模块千万别动」「日期一律用这种格式」「上次就是在这里出的事故」。
它能遵守的，只有你这次放到它眼前的东西：需求、相关的代码文件、项目规则说明、报错信息。
灯光就是这次喂给 AI 的内容；右边虚线框里的，团队人人知道，但没写下来
所以 AI 原生的团队会多出一类活：把隐性知识写下来，放进代码仓库，跟代码一起维护，每次都喂给 AI。很多时候，把上下文补齐，比换一个更强的模型还管用。
这件事还有个附带好处：写给 AI 看的说明，新来的同事也能看。
第三件：先写测试，让 AI 自己转圈
测试就是一段自动检查代码对不对的程序，可以理解为「规格的可执行版本」。
AI 时代最省力的分工是这样的：
人先把测试写好，或者至少审过、认可了，这就是验收线； AI 写代码、跑测试、看报错、再改，自己一圈一圈地转； 测试全过了，才交给人看。
AI 在跑道上一圈圈地转，人只在终点门外等
人从「盯着每一行代码」解放出来，变成「定标准、看结果」。
这里要守住一条底线：AI 不许为了让测试通过，去改测试本身。 这事真会发生，就像学生为了考满分去改标准答案。测试是人定的线，只能人动。
第四件：分清哪些放手，哪些必须人点头
不是所有事都要人盯，也不是所有事都能放手。我建议按一个问题来划线：出错了，能不能撤回？
- 撤得回的，放手
：整理代码格式、补测试、改界面文字、查报错原因。错了改回来就是，成本很低。 - 影响面大的，AI 做、人审
：开发新功能、大范围重构、修改对外接口。 - 撤不回的，必须人亲手点头
：删除数据、修改权限、涉及支付、发布上线。AI 做得再顺手，最后那一下也得是人按。
从左到右，出错的代价越来越难挽回，人的介入也越来越深
注意划线的依据是后果，不是难度。一个很简单的「删掉这张表」，比一个很复杂的算法优化危险得多。
四个要提防的坑
流程补齐了，还有几个坑，很多团队是踩过才知道的。
一、理解债。 代码能跑，但团队里没有一个人真正看懂。平时风平浪静，一出故障，全队对着 AI 写的几千行代码发呆。技术债是「代码写得烂」，理解债是「代码没人懂」，后者在 AI 时代涨得更快。
二、自己给自己判卷。 代码是 AI 写的，测试也是 AI 写的。如果它对需求的理解从一开始就错了，代码和测试会错在同一个地方，测试照样全部通过。所以关键的测试，人至少要读一遍。
三、装上根本不存在的软件包。 AI 偶尔会「编」出一个听起来很合理、实际不存在的软件包名字。有人专门盯着这类名字抢先注册，在里面放恶意代码，你照着 AI 的建议一安装就中招。AI 推荐的依赖，装之前要核实它是真的、是正规的。
四、代码越堆越多。 生成代码几乎不要钱，于是代码量蹭蹭往上涨；可删代码、整理代码没人干。代码是负债不是资产，每多一行，将来就多一行要读、要改、要背锅。
这四个坑其实是一个解法：人得真读懂，真把关。
最后：人的位置挪到了两头
把整件事串起来，AI 原生的研发流程长这样：
想清楚要什么 → 写成规格 → 备好上下文 → AI 生成并自测 → 人审改动 → 上线、看数据 → 再回到「想清楚要什么」。
你会发现，环节一个都没少，变的是人站的位置。以前人主要在中间写代码；现在中间交给 AI，人挪到了两头：前面负责把要什么说清楚，后面负责确认真的做对了。
三个站位都还在，只是站在上面的换了
所以如果你在想「AI 会写代码了，程序员还要学什么」，我的回答是：学会把问题说清楚，学会判断结果对不对。这两样，AI 暂时替不了你。