一个下午写完，一个星期改需求
一位有九年经验的后端工程师接到一个需求：给客户的订单系统加一个"批量退款"功能，产品文档写得很清楚，四页，附流程图。他把文档交给编程助手，一个下午，功能写完了，测试通过，代码评审两个同事都点了通过。他有点恍惚——这个功能按以前的经验要三天。
上线第二天，客服部门打来电话：有三笔退款退到了已经注销的支付账户，钱不知去向。他查了一下，代码没有错，文档里写的就是"按原支付渠道退回"。文档没有写注销账户怎么办，因为写文档的人不知道有这种情况；助手更不知道，它照文档写。他花了一个星期，不是改代码，是改需求：和客服、财务、支付渠道三方一起，把"原支付渠道退回"这一条改成了六条——账户注销的、渠道停服的、部分退款的、跨币种的、超过退款期限的、重复提交的。改完之后，助手用一个下午把六条全实现了。
第一个绿色的构建，出现在需求被改了六条之后。
这本书是为那六条写的：当代码可以在一个下午写完、写对，程序员的价值还在不在代码里？如果不在，在哪里？能不能数出来？
四十年的账：编程是把需求翻译成实现
软件工程对"程序员在做什么"有一个流传最广的画像：接收需求，设计，编码，测试，交付。程序员的核心能力是实现——把说清楚的事变成能跑的代码。培训、面试、职级，都围绕实现力：算法题、系统设计、代码质量。这套画像功劳很大，它把软件生产从手艺变成了工程。
但它背后有一个从来没被认真检查的假设：需求是给定的，程序员的工作是把它实现出来；实现得对、实现得快，就是好程序员。
这个假设四十年前就被一位计算机科学家正面质疑过。诺尔一九八五年的《编程即理论建构》说：一个程序的真正产物不是代码，是程序员脑子里关于这个程序的理论——为什么这么设计、哪些情况被考虑过、改动时什么会崩。代码只是理论的一份不完整记录，理论丢了，代码就成了没人敢动的遗产。本书完全接受这个判断，但要指出：他讲的理论在人脑里，不可观测；本书要做的是把它变成可以数的东西——需求在第一次跑通之前被改了几条。
那一层已经被占了
先看能核的数据。
编程助手的早期对照实验普遍显示，使用助手的开发者完成给定任务明显更快。这一层的结论争议不大。争议在另一层：二〇二五年有一项对经验丰富的开源开发者的随机对照研究报告，在他们熟悉的代码库上，用助手反而更慢——因为他们要花时间检查、修正、把助手的输出和自己脑子里的那套理论对上。两组结果方向相反，恰好说明了同一件事：在需求清楚的地方，机器写得比人快；在需求不清楚的地方，慢的不是写，是改需求。
更要紧的一组数据来自一项自然实验：代码托管平台向排名靠前的开源维护者免费开放助手，十八万七千多位开发者两年的逐周记录。拿到助手的人，编码活动增加百分之十二点三七，项目管理活动减少百分之二十四点九三；他们接触新编程语言的累计量增加了近百分之二十二；机制是从协作转向自主、从利用转向探索。也就是说，助手让人写得更多、试得更多、管得更少。
这三组数据合起来，把本书的起点钉死了：实现这一层，机器已经拿走了；程序员在这一层上剩下的只有慢。
为什么是现在
编程不是第一次遇到工具变革。高级语言、集成开发环境、开源框架、云服务，每一次都让"写出来"更容易，程序员每一次都被重新定价，然后稳定下来。这一次为什么不一样？
第一，实现不再稀缺。一个功能从文档到能跑的代码，成本趋近于零，一个下午一个。围绕实现力设计的一切——算法面试、编码规范、代码量考核——都失去了定价对象。
第二，价值结算的地方挪了。从前一位程序员的价值在"写得对、写得快"这一格结算，职级、薪酬从这一格发出。现在这一格谁都能占，价值只能往别处走——往"需求该改哪几条才能真的跑起来"那一格走。绩效还在按交付打分，客户已经在按谁改对了需求付钱。
第三，工具从条件变成了变量。编译器是条件，人人一样，比的是人；助手是变量，喂什么上下文、用哪一版、怎么提示，出来的代码天差地别，且半年一换。当工具本身成了开发里最不稳定的一项，"写得对"就不再能归功于写的人。
三条并起来看：不是工具更强了，是它把"把需求翻译成实现"整个从程序员手里拿走了，而职级表还在为这件事定价。
死的是什么，没死的是什么
死的不是编程，不是软件，是一个位置："我把它实现出来了"这个位置。
它死得其所。助手一个下午写完批量退款的时候，它做的不是从需求文档里把"正确实现"取出来——正确实现不是躺在文档里的东西，文档里根本没有注销账户那一条。它是当场造的：从文档、从它读过的几百万个退款模块，生成一份能跑的代码。这件事暴露了一个事实：程序员从来也是这么做的——需求从来没有完整过，代码一直是在"文档没写的地方"被造出来的，只是从前造它的和写它的是同一个人，他把这叫作"实现"。助手让他看清了：实现从来是建构，不是翻译。
那么没死的是什么？是助手没做、也做不了的那一件：那六条。"原支付渠道退回"改成六条，不是代码的事，是给客服打电话、和财务对账期、查支付渠道的协议——是发现"这个需求在真实世界里跑不起来"，并把它改到能跑。这六条不在文档里，也不在任何代码库里，它们是在这个客户、这些渠道、这批注销账户的具体处境里长出来的。
有一门行当把"图纸在施工中被改"做成了正式制度。建筑工程有设计变更单：施工中发现图纸与现场不符，必须由设计方签发变更，记录改了什么、为什么改、影响多少造价与工期；一个项目的变更单数量与金额，是评价设计质量的正式指标。建筑业早就知道，图纸永远不完整，真正的设计有一半发生在施工中，而且必须有人签字。软件工程在这一点上落后于建筑业：需求变更在大多数团队里是"沟通"，不是记录，改了几条、为什么改、谁定的，事后没人说得清。
最强的反方
本书必须正面回答一个反方，它正在成为最流行的一句话。
"不必学编程"论说：既然机器写得又快又对，就让机器写；人只要会描述想要什么，剩下的交给助手；编程作为一门技艺，和汇编语言一样，将成为少数人的事。
这个反方对本书的一半是对的：实现这一层确实可以整段交出去，而且应该。它错在另一半：它以为"描述想要什么"是件容易的事，是需求方本来就会的。那位工程师改的六条，客服说不出，产品经理没想到，财务只知道自己那一段——把它们变成一份能跑的规格，需要一个既懂支付渠道协议、又懂账户状态机、又能把"部分退款跨币种"翻译成一个可判定条件的人。这个人现在叫程序员，将来也许换个名字，但这件事不会消失。本书的赌注在这里：如果由机器独立完成的软件，两年内的维护成本与人写的没有差别，本书第三卷作废。
往上走的四级台阶
本书把程序员的工作分成四层。
第零层：写代码。把文档变成实现。这一层已经被助手占了，占得更快。谁把自己的价值放在这一层，谁就在等下一次降薪。
第一层：审核助手的代码。很多团队现在把资深工程师改成了"AI 代码的评审人"。这一层正在死：助手的自检与测试生成比人的评审稳定，而评审仍是在同一份代码上打转，它不生产那六条。
第二层：判断需求该改哪几条才能真的跑起来。文档说"原支付渠道退回"——在这个客户、这些渠道、这批账户上，这一条要拆成几条？哪几条现在必须定，哪几条可以先留着？这一层的活是粗粒度的：不再管每一行代码怎么写，管的是这份规格在真实世界里的哪些地方会断。助手给实现、给测试、给"文档没有覆盖的情况"清单，但"这一条改成六条、就这么定"由人定——不是助手能力不够，是它不在这个位置上：它不需要给客服打那个电话，也不需要在事故复盘会上解释为什么当初没想到注销账户。
第三层：为第一次跑通认账，并把改需求的权力立成规矩。这一层的程序员不再回答"这个功能写好了没有"，而是回答"在我们组，需求在第一次跑通之前被改了几条、谁改的、凭什么改，记在哪里，出了事故追到哪一条"。这是程序员能站的最高一层，也是助手绝对到不了的一层，因为它需要一个会被凌晨三点的告警叫醒、会在复盘会上被问"你当时怎么想的"、有下一个需求可以拒绝的人。
在第二、三层上，助手是必要的：没有它把第零层穷尽，第二层不存在——正因为文档里写了的都已经被实现了，文档没写的那六条才显出来。人也是必要的：没有人打电话、对账期、查协议，六条永远不会被写出来。缺一不可。本书把程序员与助手在第二、三层上的搭配叫作人机协同的规格单元——在第零层助手只是工具，到第二层它是这个单元不可拆的一半：正是它把文档写的都实现了，人才看得见文档没写的。
回到那位工程师。他后来做的事是这样的：他不再把需求文档直接交给助手，他先让助手实现一遍，然后专门看"它猜了什么"——助手在文档没写的地方做了哪些默认选择。批量退款那次，助手在注销账户的情况上默认了"照退"；他把每一处默认都拉出来，逐条问客服和财务"这样行不行"，行的写进规格，不行的改。三个月后他们组立了一条规矩：任何功能的第一个绿色构建之前，必须交一份"需求变更清单"——列出从原文档到可运行版本之间改了哪几条、为什么改、谁定的。这份清单进代码库，和代码一起被评审。第二、三层长这样。
一把尺：第一次跑通之前，需求改了几条
主张说完了，得给一把尺。
本书提出的尺叫首绿变更数：一个功能从最初的需求描述到第一次全部测试通过之间，需求被改写的条目数——每一条须附：不改会怎样跑不起来、谁定的改法。它是建筑业设计变更单在软件里的对应物，也是"技术债"这个模糊概念的上游可数版本：变更在前，债在后。取值材料是需求文档的版本记录、评审记录、构建日志，一次取值约一周。
有了尺，就能写下这本书什么时候算错。如果由助手独立完成的软件，两年内的维护成本与人写的软件没有差别，那么本书第三卷作废。
还有一个更硬的检验，本书没做，但把设计写出来了：同一份含糊的需求，三个组各自交出可运行版本——第一组只有助手，第二组只有工程师且不用助手，第三组是规格单元——计首绿变更数与两年维护成本。本书的主张成立，当且仅当前两组都不如第三组。没有人做过这个实验，包括本书作者。全书的尺只有取法与设计，没有一把取过值。
举一个数法。翻批量退款功能的记录：原需求一条"按原支付渠道退回"；第一次全部测试通过时，规格里对应的是六条，每条附了"不改会怎样"——注销账户照退则资金流失，渠道停服照退则接口报错，部分退款不拆则金额错，跨币种不换则汇损，超期不拦则违反渠道协议，重复提交不去重则双退——和定这条的人。首绿变更数记六。另一个功能"导出报表"，原需求三条，首绿时仍是三条，变更数记零，两年里没有出过事故。本书要问的是：把一批功能排开，首绿变更数高的功能，两年维护成本是不是更低——因为该改的在跑通之前改了，而不是在事故之后。这个问题此前没有人这样问过，因为此前"需求改了几条"从来没有被当成和代码一起评审的东西。
这把尺会怎样被做假
首绿变更数一旦进了考核，工程师会做什么，不难预见：故意把需求写含糊，再把它"改"出十条，变更数漂亮，一条也不是真的。本书事先写了升级条款：每一条变更必须附"不改则跑不起来"的证据——一个会失败的测试用例，或一份会出错的对账；附不出来的不计。若在这个口径下变更数与维护成本脱钩，这把尺已被驯化，尺子那一节须重写。
一本主张"程序员的价值在改对需求"的书，若自己立的尺被人改需求改出来了，它就自己打了自己一次。
本书不做什么
本书不讲智能体怎么造——本社此前有专书。本书不讲创业：本丛书另有一本，盯的是"第一次付钱"，本书盯的是"第一次跑通"，两本各写一节分工。本书不讲团队协作，那是《组织》的题目，本书只管一个人的席位。本书也不讲编程教育的整体改革，只在第四卷给出一条：从考实现力改为考改写力——给一份含糊的需求，看谁能把它变成可运行、可判定的东西。
各卷概览
第一卷 列一张表：从汇编到框架，软件工程里历代被当作"实现"的东西，逐条写明它是被谁、在什么时候、用什么方式当场造出来过一次。
第二卷 是实证：三组方向不同的对照实验，十八万开发者的两年，建筑业的变更单制度，四十年前那篇《编程即理论建构》。
第三卷 写四级台阶与规格单元：助手"猜了什么"怎么拉出来，需求变更清单怎么写，机器供什么、人供什么。
第四卷 写制度：职级与薪酬从实现力转向改写力，变更清单与代码一起评审，开源生态把维护与改写计入贡献；附改写型岗位的能力表与课程样例。
第五卷 写尺与判据：首绿变更数的取法、三组对照的设计、作废条件。
第六卷 写这本书自己的死法。
给读者的话
这本书是为三种人写的。第一种是那位工程师，他需要知道一个下午写完不是他的价值缩水，是他的价值终于从代码里被剥出来了——那六条才是他。第二种是技术管理者和做职级体系的人，他们手里握着"为什么付钱"的表，第四卷为他们而写。第三种是正在学编程的人，他们需要知道该学的不是写得快，是看得出文档没写什么。
作者对本书的态度写在第五卷：它可能是错的，错的条件已经写明。若有一天有人拿着一批项目的两年维护记录告诉我，首绿变更数与维护成本无关，那一天它就没白写——它被一份可复核的构建日志推翻了，而那正是它主张软件该有的样子。