AI 写代码

这一轮能力跃升的主引擎是强化学习——让模型自己产生大量尝试，对的加强、错的削弱。这套办法的前提是有人（或有东西）能判断对错。

代码恰好是复杂认知任务里唯一一类判定几乎完全自动化的：编译器会报错，测试会红绿，程序跑起来结果对不对一目了然。裁判不要钱、不睡觉、不会累、判得还一致。

反过来看别的任务就明白了：一篇文案写得好不好、一个战略建议靠不靠谱，没有编译器。只能找人来评，而人评一条要几分钟、几十块，还两个人两个意见。训练规模上就差了几个数量级。

判断"AI 在某个领域会不会快速变强"，先问一句：这个领域的对错，机器能自动判定吗？ 能，就快；不能，就慢。这条规律的解释力比任何其他因素都强。

代码有一个别的领域几乎没有的奢侈品：出错的时候，系统会告诉你哪一行错了、错在哪、期待的是什么。

这个信号又快（秒级）、又准（定位到行）、又结构化（有类型有栈）。人类工程师就是靠它学会编程的，模型也一样——而且模型可以在一小时里经历人类几年才能碰到的报错量。

训练需要大量"这样问、那样答"的配对数据。大多数领域要花大价钱人工构造，代码领域是白捡的：

每一个 commit 都是一次"问题 → 改动"的记录，附带人写的说明；每一个 issue 加上修复它的 PR，就是一对完整的题目和答案；Stack Overflow 上是几千万条"我遇到这个错怎么办"。

再加上一点常被忽略的：代码是形式语言,歧义远小于自然语言。 同一个意思的中文有一百种写法且边界模糊，而一段代码的语义是确定的。

让模型自己动手做事（agent），最大的障碍是试错的代价。让它操作真实的银行账户、真实的生产设备，错一次就是事故。

代码不一样：在容器里跑、跑挂了重来、改错了 git 还原。 这是唯一一类可以让模型放开手脚练几百万次而不伤到任何人的复杂任务。

最后一条是经济上的：AI 编程的用户是开发者，而开发者是所有用户里最理想的那种——

他们付得起钱（软件行业工资高）、能自己验货（看得懂输出对不对）、容忍早期缺陷（习惯了工具不完美）、而且会主动反馈（提 issue 是本能）。于是收入最先在这里跑出来，投入随之集中过来，能力又变强——飞轮转起来了。

把五条连起来看:可自动判定对错 + 报错信号精确 + 数据天然配对 + 试错无代价 + 客户能验货。 你很难再找出第二个五项全中的领域——这就是为什么它跑得这么快，也说明这种速度不会自动复制到别的行业去。

"突飞猛进"是真的，但它集中在特定形状的任务上。分清楚这一点，比记住任何具体能力都重要。

公开评测（SWE-bench 之类）确实推动了进步，但有几个已知问题:题目可能进过训练数据（污染）、题型偏向能自动判定的那类（否则没法评）、分数接近饱和后区分度下降。

更实际的一点是:榜单测的是"能不能解出题"，你关心的是"在我们这个屎山里能不能干活"。 这两件事的相关性没有想象中高。

别信任何笼统的"能不能用"。拿你们自己仓库里三个真实的、已经关闭的 issue 让它做一遍，跟当初人写的方案比。这个测试花半天，但结论比看十篇评测都准。

以前一个需求的时间大头是把想法翻译成代码。现在这一步快了几倍，于是瓶颈移到了两头：前面是把上下文讲清楚，后面是判断产出对不对。

这意味着过去被认为"不产出"的那些活，现在是核心工作：把需求想清楚、把约束说明白、把验收标准定下来、把结果审仔细。

把任务交出去之前，先花两分钟回答三个问题:目标是什么、什么绝对不能改、怎么算做完了。 说不清这三条,说明你自己也没想清楚——这时候先别急着让它写。

这条决定了你该在哪儿用它、哪儿不该用。

在你懂的领域，它是纯粹的放大器：它写得快，你一眼看出哪里不对，改掉就能用，净赚。

在你不懂的领域，情况反过来:它写的东西你没有能力判断对错，而它的输出总是看起来很合理。你把看不懂的代码合进主干，等于往系统里埋了一个自己都不知道在哪的雷。

所以那句常见的说法"不懂编程也能做软件了"，在能跑起来的层面是真的，在能维护、能上线、出了事能修的层面是假的。

交付之前问自己一句:如果这段代码半夜出问题，我能不能自己修? 答不上来，就说明这段不该以现在这个状态合进去——要么读懂它，要么找懂的人审。

人写错代码，通常是粗心（漏个边界、写错变量名），错得比较"难看"，容易被看出来。

模型写错代码，通常是自信地合理但错：结构工整、命名规范、注释齐全，看上去比人写的还专业，但某个前提不成立。这种错更难被 review 抓到，因为它不触发你的警觉。

不存在的 API

名字和风格都很像真的，但那个方法／参数根本不存在，或者在你用的版本里不存在。

版本错配

用了新版的写法，而你们锁在老版本上。这类问题很常见。

不符合本项目约定

语言层面完全正确，但和你们的分层、错误处理、命名规范全不一样。

悄悄改了语义

让它"重构"，结果边界条件的行为变了，测试没覆盖到就溜过去了。

过度工程

三行能解决的事，给你一个工厂加策略模式加接口。

补丁式修复

它会顺着你的描述修表象。你说"这里报空指针"，它就加个判空——根因还在。

删掉"看起来没用"的东西

那行 sleep、那个看似多余的 try，可能是踩过坑加的。

测试写成同义反复

让它补测试，容易得到一堆"跑了但什么都没断言"的测试，覆盖率好看，防不住 bug。

把改动切小:一次一个关注点，diff 控制在你能一屏看完的量级。大改动拆成小改动,是目前最有效的防线——比任何审查技巧都管用。

AI 让写代码变快了，但它没让"判断代码对不对"变快——除非你有测试。

于是同样用 AI，两种项目的结局完全相反：有好测试的项目，AI 产出能被自动验证，迭代飞快；没有测试的项目，AI 只是让你更快地往里堆没人验证过的代码——技术债的积累速度跟着一起提升了。

如果你们测试很少，别急着大规模上 AI 改造存量代码。先在新代码和边缘工具上用，同时把关键路径的测试补起来。顺序错了，AI 放大的是风险不是效率。

模型不知道你们团队"心照不宣"的那些规矩：错误怎么处理、日志怎么打、目录怎么分、什么能改什么不能碰。这些东西过去靠口口相传和 code review 传递。

要用好 AI，就得把它们显式地写下来（放在项目里的规范文件、README、约定文档里）。有意思的是:这件事对新来的人类同事同样有价值——很多团队是被 AI 逼着，才第一次把隐性知识落成文字。

在仓库根目录放一个约定文件，写三类东西:这个项目是干什么的、有哪些不能碰的雷、代码风格和分层的规矩。 一页纸就够，但它会持续生效。