arXiv 前几天挂出一篇论文，标题里有个词我觉得值得单独收一期：规范悖论。
简单说，AI 自动写代码的能力越强，对人这边的要求反而越高。
听着像绕口令，其实是这几周我一直在琢磨的事。这期就讲它。
论文说了什么
两位研究者，8 月 17 日提交的。核心论点一句话讲清楚：AI 只是把写代码这个环节变轻了，软件开发本身的复杂性一点没少，只是搬家了。
搬到哪了。搬到领域理解、需求获取、写规范、验证、维护这些环节去了。
这个判断我认。而且它不是新发现，论文自己也点破了。软件工程历史上每隔几年就有人宣称找到了消除软件开发固有难题的方案，每次都没有。这次大概率也一样。
为什么值得收
因为它是把一个大家隐约感觉到的事，讲成了一个能记住的短语。
过去两年，“程序员要失业”和“AI 写的代码不能看”两种说法轮流上桌。论文的意思是，两边都吵错了地方。真正变化的不是还需不需要人，是需要人在哪个环节出力。
写代码这件事，本质上是把明确的需求翻译成机器语言。翻译这个活，AI 干得越来越像样。想清楚到底要什么，目前还是人的活。而且 AI 越能干，前面那个环节的分量越重。
这就是悖论所在。工具越强，你那句“帮我做个东西”就越是不能含糊。
论文点名的四个风险，白话版
自动化偏见：AI 给了答案，人就不太愿意再质疑。哪怕它理解错了需求，错的答案看起来也像对的。
歧义传播：你需求里一句模糊的话，AI 不会替你澄清，它会替你脑补，然后把脑补一路写进代码里。
规范过拟合：规范写得死死的，AI 就照着死死的做，做出来一个字面正确、实际难用的东西。
规范债务：规范没人维护、越积越旧，代码却一直在 AI 手里快速往前跑。两边越离越远。
这四条里，歧义传播最值得普通人记住。它是从第一天就会发生的，而且发生的时候没有任何报错。AI 不会跟你说“你刚才那句我没听懂”，它只会给你一个能跑的东西。
对用 AI 写代码的普通人意味着什么
意味着 prompt 不是玄学，是规范工程的白话版。
我之前收过一次类似的说法，这次论文算是个更硬的版本。用 AI 写代码，真正决定结果的不是模型多强，是你能不能把要什么讲清楚。具体、分步、给例子，这三条老建议，背后对应的就是论文说的那些环节。
还有一个账要算。以前学编程，学习曲线的大头在语法和工具上。现在那部分被压平了，但复杂性没有消失，它转移到了会提问和会验证上。表面门槛降了，真要做好，要懂的东西反而换了个方向。这不是坏消息，但得知道。
一处我不太确定的地方
论文主张整个范式从代码中心转向规范驱动。这个方向我同意一半。
同意的那一半：对专业软件团队，这大概率是对的。需求工程重新变回核心，这个判断我押它成立。
犹豫的那一半：普通人写个脚本、做个小页面，先专门写一套规范再让 AI 生成，这个流程会不会太重。我自己的体验是不用的，把话说清楚就够了，不用上升到“工程”。但也许是我项目太小，没到那个量级。这条先放在这里，想明白再补。
顺手补一句
上期提过某个工具的免费额度，后来发现有个坑。额度重置的规则比界面写的复杂，实际可用量比宣传的少一截。用免费额度起步的思路不变，但别按它标出来的数字做计划，留点余量。
本周就这些。
上面任何一条你试过、或者觉得我讲错了，欢迎告诉我。那篇论文我只啃了大半，剩下那部分啃完了再来补。
下周见。