上一章说，写代码里最先掉价的那部分，是「把想法翻译成代码」这道体力活——就像打字员的黄昏。但「写软件」从来不只是打字。你要是把它当成一整块黑箱，就永远看不清 AI 到底啃掉了哪块、哪块反而更贵了。所以这一章我们干一件事：把「写软件」拆开，摆到桌面上，一道工序一道工序地看。
这是一张地图。后面好几章会分别钻进某一道工序里讲透，这里我只负责把整条流水线画出来，并且在每道工序旁边老实标一句：这道，AI 现在能包办到什么份上？
先说清楚：软件不是一次性造出来的
我们借一个类比贯穿整章——开一家餐厅。不是「做一道菜」，是「开一家能持续出餐、还能改菜单的餐厅」。因为软件最像餐厅的地方在于：它不是做完就完了，它得天天营业、还得随时改。
把开餐厅拆开，大致是这么五道工序：
- 想清楚开什么店——开给谁吃、卖什么、解决谁的什么需求。（对应软件的需求：先搞明白到底要做什么。）
- 设计后厨和动线——菜单怎么配、厨房怎么布局、上菜流程怎么走。（对应架构：软件内部怎么分块、各块怎么配合。）
- 照着菜谱把菜炒出来——具体的颠勺、切配、火候。（对应实现：把方案真正写成能跑的代码。）
- 试吃和验菜——出锅前尝一口，咸淡对不对、有没有夹生。（对应测试与审查：验证做出来的东西对不对。）
- 长期经营——客人口味变了、供应商涨价了、招牌菜要改配方。（对应维护与演化：软件上线后长期地改、修、加。）
注意这五道不是排成一条直线走一遍就结束。真实的餐厅是天天在这五道之间来回跳的。软件也一样。但为了看清楚，我们先一道一道拆着看。
一道一道过：AI 现在能包办到哪
工序三：把菜炒出来（实现）——最先被打下来的
我先讲第三道，因为它最好懂，也是第一章已经点过的。
「照着菜谱炒菜」这道，恰恰是 AI 眼下最擅长的。你把要什么说清楚，它哗哗给你写出来；你说「这段用另一种写法」，它秒改。样板代码——那些几乎每个项目都长得差不多、纯粹是把想法翻译成机器听得懂的话的重复劳动——现在基本可以让 AI 代劳。
说人话：只要「要做什么」已经定死了，剩下的「怎么把它敲成代码」这道纯翻译工序，AI 干得又快又便宜。这就是上一章说的打字员在贬值。
但请你盯住这句话里的前提——「只要要做什么已经定死了」。这个前提，正是整张地图的分水岭。往它左边走，工序在变便宜；往它右边走，工序反而在变贵。我们接着往左右两边看。
工序四：试吃和验菜（测试/审查）——一半便宜，一半更贵
这道工序很有意思，它自己就被这条分水岭劈成了两半。
一半是机械的验：这段代码有没有明显写错、有没有漏掉常见的坑、格式规不规范、这个函数该配的自动检查有没有配全。这类「照着清单挑毛病」的活，AI 干得很好，甚至比人耐心——人尝到第二十盘菜早就麻了，它不会。
另一半是判断「这道菜到底该不该是这个味」。菜不咸不淡、技术上「没做错」，但它是不是客人想要的那道菜？这个软件功能跑通了，可它解决的是真问题吗？边界情况该报错还是该容忍？这半道，AI 帮不上根本的忙——因为它不知道你的客人是谁，也不承担客人骂上门的后果。
分界就在这：「对不对」里，能对照规则判定的那部分便宜了；需要对照真实意图和后果去判定的那部分，更贵了。
工序二：设计后厨（架构）——越往上越贵
后厨怎么布局，看起来像纯技术活，其实全是取舍——为了得到一样东西，主动放弃另一样。
比如：把出餐做快，往往意味着菜单不能太杂；菜单越花哨，后厨越难管、越容易出错。没有「全都要」的方案，只有「你更想要哪个、愿意为它牺牲哪个」的选择。软件设计从头到尾都是这种选择。
AI 能给你列出常见的几种后厨布局、告诉你每种的优劣——这很有用，相当于一个读过一万本菜谱的顾问。但「对我们这家店、这拨客人、这个预算，到底该选哪种、牺牲哪样」，这个拍板它替不了。因为取舍没有标准答案，它取决于你想要什么、怕丢什么——而「想要什么」不在 AI 的菜谱里，在你脑子里。
工序一：想清楚开什么店（需求）——最贵，而且贵得最狠
这是整条流水线的源头，也是分水岭最右边、最贵的一道。
难点根本不在写字。难在客人自己都说不清楚他要什么。他说「我想要个能提高效率的东西」，你要是照着字面做，准砸。你得反复追问、观察他真正卡在哪、把一句含糊的抱怨翻译成一条清清楚楚、能验收的需求。
为什么这道最贵？因为 AI 是个「你说清楚它就给你办」的机器，而这道工序的全部难度，恰恰在于「你还没法把话说清楚」的那个阶段。一个说不清的问题，喂给 AI，出来的只会是一个精致的、跑得飞快的、然而错误的答案。
把一个错的问题解得再漂亮，也还是错的。而只有人能站到 AI 前面，先判断这个问题问得对不对。
工序五：长期经营（维护）——被低估的贵
最后这道最容易被忽略，但软件生命里大部分时间和成本都花在这儿——上线只是开业第一天，之后是几年的经营。
维护贵在哪？贵在你得先搞懂这家店现在为什么是这样，才能安全地改它。这条动线为什么绕这么一圈？是当年偷懒，还是有个你没看见的理由？改一味调料，会不会连锁着毁掉三道招牌菜？
AI 能帮你读懂一段陌生代码在干嘛，这是实打实的省力。但「这个看着别扭的设计背后，藏着哪段没写进菜谱的历史和苦衷」——那些散落在人脑子里、聊天记录里、当年那场事故里的上下文，它接不住。改错了要背锅的，也不是它。
把地图收拢：分界线到底在哪
五道工序过完，那条反复出现的分水岭，可以用一句话钉死：
凡是「问题已经定清楚，只剩把它翻译成代码或对照规则检查」的工序，正在变便宜；凡是「需要定义问题、做出取舍、并且为后果负责」的工序，正在变贵。
你可以把五道工序按这条线排一排，从便宜到贵：
- 实现（炒菜）——最便宜，AI 基本能包。
- 测试/审查（验菜）——机械的一半便宜，判断味道的一半贵。
- 架构（设计后厨）——列选项便宜，拍板取舍贵。
- 维护（长期经营）——读懂便宜，扛住历史与后果贵。
- 需求（想清楚开什么店）——最贵，因为难在「话还说不清」的地方。
看出规律了吗？越靠近「敲键盘」的工序越便宜，越靠近「拿主意、担后果」的工序越贵。AI 摊薄的是流水线中间那段体力翻译，把两头——上游的「想清楚要什么」和下游的「扛住长期后果」——反而顶得更高、更显眼、更值钱。
这张地图就画到这。接下来的章节会分头钻进那几道变贵的工序里：第 3 章会盯着「会写代码为什么不等于会解决问题」（需求那一头），第 5 章讲那个在架构和验菜里都躲不开的「品味」，第 8 章专门拆后厨设计，第 9 章讲维护里最像侦探破案的那部分——调试。你现在手里有地图了，知道每一站为什么值得停。