当机器会写代码

一份作业拿了满分，背后可能是一个真懂行的人，也可能是一个只会转发题目的人。这一章讲怎么把两者分开。

一、作品不再证明能力

三年前，交上去的一份程序只要跑得起来，就说明写它的人掌握了知识。作品是能力留下的痕迹，痕迹越清楚，能力越可信。这条对应关系维持了很久，久到我们把它当成了常识：能做出程序，就等于学会了。

机器会写代码之后，这条对应关系断了。同一份能跑的程序，背后可能是两种人。一种人真的想过输入有哪些情况、输出该长什么样、边界条件怎么处理；另一种人只是把题目转贴过去，再把答案转贴回来。两种情况交出来的东西，从外观上一模一样：能运行、格式整齐、代码行数还不少。

这条对应关系为什么会断，可以这样看。以前写代码的每一步都要人自己走：查文档、试写法、跑一遍看报错、改掉再跑。走完这一趟，人自然就知道哪里有坑。现在这一趟由机器走完了，人只看到了开头和结尾。中间那些「试了三次才对」「这里必须加一个判断」的经验，全都没有留在人身上。

于是有一批问题浮现出来，问得不客气，但是真实：

• 我的大学是 AI 帮我上完的，最后我什么都没学会，怎么办？
• 老老实实学了四年，毕业时发现训练的那些技能不值钱了，怎么办？
• 为了刷出一份完美简历，把生活过成一场漫长的资格赛，最后又得到了什么？

这三个问题没法靠「把下一门课考好」来回答。它们指向的是同一件事：当写代码这件事本身变便宜，什么还值得花时间去练。

二、意图、规格、实现：缺口落在中间那一段

把任何一件「让机器去做」的事情拆开，都能拆成三段。

• Intent（意图）：你真正想要什么。
• Spec（规格）：写下来的、可以逐条检查的要求。
• Impl（实现）：真正跑起来的那段代码。

flowchart LR
  I["意图：你真正想要什么"] -->|"这一步需要产品判断"| S["规格：写清楚的可检验要求"]
  S -->|"这一步需要设计与实现"| P["实现：真正运行的代码"]

拿点外卖举例：你想「吃顿好的」是意图；「四十分钟内送到、辣度按我上次的记录、不要香菜」是规格；外卖软件里跑着的那些代码是实现。麻烦在于，每一步之间都有一道缺口。「吃顿好的」可以变成几百种不同的规格，写下哪一种取决于你没说出口的偏好；同一份规格也允许无数种实现。模型拿到任务之后，会把这些没说清楚的地方统统自己猜着填上。它填得很快、很一致，也经常正好是你没要的那个。

看一个具体的例子。有人让 AI「做个选课系统」，半小时后得到一个能跑的网页，但是没做人数上限。用这三段一读就明白了：意图是清楚的，可「选课」这个词里藏着一堆没说出口的约束，人数上限、先修课检查、时间冲突怎么办，这些属于规格，被跳过了。模型直接从意图跳到了实现，用它自己的默认选择填补空白。它没有违反任何明确指令，因为根本没有明确指令可违反。

规格要写到什么程度？有一个成本上的理由值得记住：办活动的开销大头永远在后面。方案改一版十分钟，场地订金交了退不回来。写代码同理，规格改一遍几分钟，四十个文件改完再推翻要一整天。把规格写清楚这件事，越早做越便宜。

三、三种能力：信息差、承担责任、组织协作

写代码变便宜之后，还值钱的东西可以归成三样，说法有点扎人，但很好记。

1. 信息差：知道计算机世界里有什么东西、知道哪里能找到答案。别人卡三天的问题，你知道该去查哪份文档、该看哪个日志。
2. 承担责任：做了决定之后，有人要为后果负责。改一个数据库字段，可能让第二天的成绩录入全部对不上；敢拍这个板的人，得知道后果有多重。
3. 组织协作：把人、工具和反馈组织起来，最终真的做成一件事。这一项最稀缺，也最难速成。

第三样东西听起来空洞，拆开就很具体。一个小组五个人、外加几个智能体同时在改一个项目，谁先做、谁后做、接口谁定、冲突怎么合、做完了谁验，这些安排决定项目能不能收尾。同一个模型，配上不同的安排，实际产出可能差出好几倍。这一章后面几页讲外壳、讲上下文、讲拆任务，讲的都是这件事的具体做法。

这三样东西都能在日常里练，不需要等到工作。信息差可以靠做实验补：同一件事换一种问法再问一遍，看结果差在哪。承担责任可以靠写记录补：每次决定都在实验日志里写一句「我当时以为会怎样、实际怎样」，错了也照样写。组织协作可以靠小组作业补：主动去定接口、排先后、收结果，做完之后回头看哪一步最容易卡住。

四、AI slop：判断标准是「修改有没有局部性」

生产变便宜之后，次品也会按比例变多。批量生成、看起来像样、实际质量很低的产物，有一个专门的叫法：AI slop（AI 泔水，原本指喂猪的泔水，后来泛指低成本批量生产的低质内容）。用在代码上，典型症状有这么几条：

• 复制粘贴式的重复代码，每一处都略微不同，改一处漏三处；
• 大量用异常捕获把错误直接吞掉，出了问题没有任何线索；
• 过度防御，为一个不可能是空值的变量写五行判空；
• 命名含糊，出现 data2、temp_result、handle_stuff 这类名字；
• 注释和代码对不上，或者注释只是在复述代码；
• 测试只覆盖顺利路径，出错的分支完全没有测；
• 为了一个小功能引入三个第三方库。

这些东西危险的地方在于它们看起来是对的：能运行、能通过自动检查、代码行数还很多，让人误以为完成度很高。等到第二个需求进来，你才发现改一处要动十处。

所以判断一份产出，有一个很好用的标准：修改有没有局部性。好的工程，改一个地方只需要动一个地方；坏掉的那种，改一个地方牵动全身，每次需求变化都要把整个系统重新解释一遍。越挣扎陷得越深，这正是《人月神话》里说的焦油坑。AI 生成得越快，掉进焦油坑的速度也越快。

五、二维码 Excel：一次完整的翻车

有一个案例值得从头看到尾，因为它把上面几件事全串起来了。

任务是：只用 Excel 公式，把一段几千字的字符串编码成分帧显示的二维码。要求听起来够具体了，可里面藏着一堆没说清楚的选择：一帧装多少内容？输入变了，公式要不要重建？「文件能打开」算完成，还是「真实扫码能还原原文」才算完成？这些都属于规格，但没有人把它写下来。

结果是这样的：有的模型思考了 25 分钟就撞上输出上限，前后花了 6 个小时才做出来；有的模型直接交了硬编码版本，只对当前这一个输入看起来正确，换一段字符串就全废。这就是 AI slop 的典型样子：演示的时候扫码能通过，换一段文字立刻露馅。

这个案例值得复盘的地方有三层。

1. 规格没写全，模型只能自己选。分帧大小、纠错等级、输入变化后怎么重建，每一个没写的选择都被它用默认值填了。
2. 验收标准定得太低。「文件能打开」这个标准，一份硬编码的结果也能满足。把标准换成「用手机扫出来，得到的文字与原文逐字相同」，硬编码当场就过不去。
3. 失败之后先换输入，再改代码。换一组输入就能区分「交付了一个计算过程」和「交付了一次表演」。

六、先用好，再理解原理：地板被抬高了

传统学习路线是先学会、再动手。现在顺序可以反过来：先让 AI 帮你做出一个能用的东西，再围绕真实遇到的问题去理解原理。过去这些任务意味着翻教程、记配置、搜报错，光是「准备开始」这一步就足够让人放弃；现在你可以先拿到一个能观察、能检查的结果，再倒回来学它背后的东西。

这个顺序可以拿学游泳来对照。以前教练先在岸上讲二十分钟动作要领，你听得云里雾里，下水还是呛。换一个顺序：先扶着浮板在水里漂十分钟，体会身体怎么浮起来，再上岸讲为什么手臂要那样划。同样是十分钟的讲解，后面这种讲的是你自己碰到过的问题。

这个顺序里有一件事不能省：验收。系统到底能不能启动？数据存对了没有？快捷键符合预期吗？这些都需要证据。学习的入口变了，判断结果的工作永远在你手里。一份漂亮的摘要，证明不了阅读已经发生；一次能跑的演示，证明不了需求被满足。

再把视角抬高一点。想象一个有天花板也有地板的房间：天花板代表最优秀的工程师能做到什么，地板代表一个刚入行的人至少要能做到什么。中间这段高度，就是一个人靠这门手艺吃饭的空间。

flowchart TB
  H["天花板：最优秀的人能做到什么，这一层没有变化"]
  F1["以前的地板：会写循环、会调用接口就能入行"]
  F2["今天的地板：能交付完整、可靠、可维护的系统"]
  H --> F1
  F1 -->|"基础部分被补齐，地板抬到这里"| F2

以前地板很低。会写一个循环、会照着文档调用别人写好的接口，就能找到一份工作。现在基础部分被机器补齐了，一个新手加上一个会自己动手的模型程序，产出可能接近三年前的中级工程师。于是「能跑起来的代码」不再稀缺，地板抬到了「能交付一个完整、可靠、可维护的系统」这一层。

外面还有一组公开数据能印证这条判断。有一个常用基准，做法是给模型一个真实开源代码仓库里的问题单，看它能不能自动交出一份通过测试的补丁。2024 年前后，顶尖模型在这个基准上的解决率大约在 10% 到 50% 之间；到 2025 年，最好的模型到了 77.2%。两年前需要一位资深工程师花一整天处理的任务，现在几十分钟就能拿到一版可用的补丁。面试门槛、代码评审标准、期望的交付速度，全都跟着往上移。

这条判断有两个推论。能力刚好停在新地板下面的人会被挤压；能力在地板之上的人，价值反而被放大，因为整个房间的可活动空间变大了。天花板那一层没有变化，往上顶仍然要靠自己。

把它换成一句能指导行动的话：现在拼的是「能不能交付」，从前拼的是「能不能写出来」。交付包含写出来，还多出三样东西——做完了有没有证据、别人接手改不改得动、出了问题查不查得到原因。这三样恰好都是机器的默认产出不保证的。

七、讲原则，不讲工具

工具的半衰期很短。下面这张表把最近五年「当时被当成必备」的做法排在一起，你能看出换代的节奏。

如果一门课教你某款工具的十二个快捷键，一个学期之后这些内容就过期了。如果它教你另外三件事——为什么上下文是最稀缺的资源、为什么工具的切分方式决定智能体靠不靠谱、为什么架构品味是机器最难替代的部分——那么下一个工具出现时，这三条照样成立。

每一条原则都能落到一个具体动作上。「上下文是最稀缺的资源」落到动作上，就是每开一个新会话之前先把目标、约束、证据、示例四样写在一张纸上。「工具的切分方式决定靠不靠谱」落到动作上，就是接新工具之前先问它暴露了几个操作、说明写没写清。「架构品味最难替代」落到动作上，就是每次改完问一句「下一个需求进来，我需要动几处」。

换成一个具体的练习方式：每上手一款新工具，都问一句「它为什么被设计成这样」，把答案记进一份实验日志。日志四栏就够：任务是什么、我用什么方式让 AI 做、结果哪里好哪里不对、下次改哪一句。三个月后，这份日志比任何一份网上教程都更贴合你自己的习惯。

自测