外观
创作缘起
这本书最初并不是因为我想写一本关于 AI Coding 的书。让我开始认真想这件事的，是一次和开发者的交流。
他问我，有没有比较成熟的全局规则，可以让 AI 自己尽量发现生成代码里的问题。他说，现在 AI 写的代码越来越多，他总觉得里面藏着问题，心里没底，但已经做不到把代码从头到尾再检查一遍了。他希望有一种方法，让 AI 自己完成更多检查，人只管那些必须人来判断的部分。
这是一个非常普遍的问题。我想了很久，怎么把它讲清楚。
他想解决的，恐怕不是怎么写一个更好的 Prompt。AI 写的代码越来越多，人又不可能像过去那样逐行审查，这两件事撞在一起，就会逼出一个绕不开的问题：
当代码的生产大量交给 AI 之后，我们用什么方式获得对软件的控制？
过去的软件开发里，这个矛盾并不突出。开发者自己理解需求、设计方案、写代码、调试、测试，代码就是他工作的主要产物。他是否理解自己写出的代码、能不能定位其中的问题，很大程度上决定了他对整个开发过程的掌控。就算他不喜欢读代码，也很难绕开，因为生产和控制在同一个人手里。
AI Coding 改变了这种关系。
AI 可以快速生成大量代码，可以修改多个文件、搜索整个代码库、运行测试，还可以围绕一个目标连续执行多个开发步骤。开发者于是能把越来越完整的任务交出去，形成了一种新的工作状态：需求由人提出，代码由 AI 生成，测试由 AI 执行，出了问题再交给 AI 修。人越来越少直接动手，却仍然要对最终结果负责。
过去那套建立在“亲自写、亲自读、亲自改”之上的控制方式，到这里就开始失效了。
如果 AI 一天能生成几千行、几万行代码，甚至连续运行几个小时，要求开发者把这些代码全部重读一遍，只是把成本从写代码搬到了审查代码。何况人读更多代码，未必能做出更好的判断。代码多起来以后，难的不是发现某一行语法错误，是判断 AI 有没有理解对问题、方案选得合不合理、有没有漏掉重要约束、是不是在错误的方向上越走越远，以及最后整个系统的行为到底符不符合预期。
这让我重新打量围绕 AI Coding 的大量讨论。大家热衷讨论的是：程序员未来应该学什么？
有人说前端开发会逐渐失去价值，应该转全栈；有人说传统软件开发没有前途了，应该去学 Agent；还有人开始讨论 AI Engineer、FDE、OPC 这些新职业。
这些判断各有道理，但我总觉得它们沿用了同一种思路：一种技能不值钱了，就去找另一种更值钱的技能。这个思路有个默认前提——职业本身没变，变的只是职业需要的技能。
可如果 AI 改变的不是某一项技能，而是软件生产的成本结构，问题就没这么简单了。
第一个应该搞清楚的问题是：AI 究竟改变了软件生产过程中的什么？
过去的软件开发有一套相对稳定的生产结构。需求提出之后，要有人理解问题、设计方案、写代码、调试、测试，最后完成交付。写代码只是其中一个环节，但长期以来一直是软件工程里重要的成本来源。一个开发者懂多少技术、能解决多复杂的问题、多快能完成实现，很大程度上决定他的生产能力。
AI 首先改变的，就是这一部分。
代码生成的成本在快速下降。过去要花几个小时的实现，现在可能很短时间就能完成；过去要多人协作的原型，一个人借助 AI 就能做出来；过去要不断搜索、修改、调试的任务，也开始能交给 Agent 持续执行。
软件生产的产能因此明显提高。但这里有个容易被忽略的事：生产力提高，不等于人的价值会同比例增长。
一个产品最终能不能产生价值，从来不只取决于代码写得快不快。需求对不对、问题值不值得解决、方案合不合理、系统可不可靠，这些约束都还在。AI 把其中一个约束大幅压低，其他约束就会显露出来。这就是后来我反复想的“约束迁移”。
AI Coding 不只让程序员写代码更快，它改变了软件生产各环节的相对成本。过去代码实现是瓶颈，所以编码能力值钱；实现越来越容易之后，问题定义、方案判断、Context 管理、验证、复杂度控制、结果判断，这些环节的分量开始上升。
换句话说，变化的不是代码还要不要写，而是什么东西变成了新的稀缺能力。
这件事也让我重新想“开发者的价值”这个问题。
过去，一个优秀开发者的能力很大程度体现在执行上：会设计代码、会用框架、会排查问题、处理得了复杂工程场景。这些构成了开发者长期以来的专业壁垒。而这些能力，AI 正在一项一项地获得。
如果还用过去的方式理解开发者，很容易得出一个简单的答案：原来的能力被 AI 替代了，就去学更高级的技术。这个答案解决不了问题。变化的是生产方式，我们不可能永远靠寻找下一项技能来应对，因为今天要学会的东西，明天可能就成了 AI 能直接完成的任务。需要重新理解的，是工作本身的结构。
过去我们习惯把程序员看成一个完整的生产单元：需求交给他，他负责从理解到实现，再到测试和交付。AI 出现之后，开发者的工作越来越多变成定义任务、提供上下文、调用 AI、观察结果、判断偏差、调整方向，然后让 AI 继续执行。他没有离开生产过程，只是从直接执行者，变成了任务的组织者、AI 的控制者和结果的判断者。
开发者要重新掌握的，因此不只是怎么把代码写出来，还有怎么让一个由人和 AI 组成的生产过程，持续朝着正确的结果收敛。
还有一个问题：AI 能执行任务，不等于它知道什么是正确的。 AI Coding 越强，这个问题越突出。
如果 AI 持续产出大量看起来合理的代码，却从一开始就理解错了问题，它完全可能基于错误的上下文做出错误判断，然后围着这个判断不断搜索和修改；也可能因为一次错误决策形成路径依赖，不停为之前的选择打补丁；也可能为了完成眼前的任务，引入不必要的复杂度。
长任务和 Agent 场景里，这种风险更明显。AI 不再只生成一次结果，而是根据自己的行动结果做下一轮判断。上一轮的代码、错误和中间结论，都会变成下一轮 Context 的一部分。一个很小的认知偏差，可能在连续执行中被不断放大。
到这一步，问题已经变成：怎么让 AI 在正确的问题、有效的上下文和明确的边界之内工作，并且能通过验证和反馈及时发现错误、修正方向。
这也是后来我们开始讨论 Context、Search、Agent、Workflow、Skill、Harness、Verification 和 Governance 的原因。这些概念分属不同层面，指向的是同一件事：执行越来越多交给 AI 之后，人怎么重新建立对生产过程的控制。
这个问题，后来又和我此前对《AI认知搜索理论》的研究连了起来。很多时候问题不只在模型能力，而在于模型是在特定 Context 里推理的。它看到什么信息、怎么组织这些信息、从哪里开始搜、怎么判断证据、什么时候停下来、能不能根据反馈修正自己，都影响最终结果。
Coding 把这种机制变得更直接。AI 的判断会变成真实的代码修改，代码修改又改变后续的 Context。开发过程实际上成了一个循环：
问题 → Context → 搜索与推理 → 行动 → 结果 → 验证 → 反馈 → 再次判断。
如果这个循环缺乏控制，AI 产能越强，错误扩散得越快；当循环有了清晰的边界、充分的证据、有效的验证和真实的反馈，AI 才有机会从一个代码生成工具，变成可靠的软件生产参与者。
这时我才意识到，最初那个看起来简单的问题——“有没有办法让 AI 自己审查代码，我不用把代码全看一遍”——碰到的是 AI Coding 最核心的变化之一。AI 承担越来越多的执行工作之后，人怎么对 AI 的工作结果形成可靠的判断。
这些线索连起来之后，我意识到 AI Coding 带来的变化远超一个开发工具。
它改变开发者个人的工作方式：过去主要亲自执行，现在越来越多时候要定义任务、组织 Context、驱动 AI、验证结果，并承担最终责任。
它改变软件工程本身：代码生产成本快速下降之后，需求分析、架构判断、验证、复杂度控制的重要性都在变，过去围绕写代码建立的许多工程流程要重新审视。
它还会影响软件组织。如果一个开发者能同时调度多个 AI Agent，过去围绕 PM、设计、前端、后端、测试建立起来的部分协作结构就不再天然成立。一个人能管理的生产规模扩大了，传统团队里关于角色、流程、任务拆分和管理控制的很多假设都会跟着改变。
所以我越来越不愿意把这件事叫“程序员学习 AI”。这个说法默认原来的工作方式没变，只是多了一个更强的工具。而我们面对的，是软件生产方式的变化，以及这种变化对人的工作和价值的重新分配。
所以这本书没有从某一个 AI Coding 工具讲起。工具会变，模型会变，Agent 的产品形态也会变。一本书如果把核心建立在某个工具的操作方法上，很快就会过时。我想留下的，是一套能帮开发者理解变化、判断变化，并在变化中重新组织自己工作的思考框架。
这本书回到的，是几个更基础的问题：
AI 能替你完成的代码工作越来越多，你该怎么重新理解 Coding？AI 能承担越来越完整的开发任务，你该把时间和注意力放在哪里？代码生产不再是主要瓶颈，哪些能力会变得更重要？一个人能调度多个 AI，怎么避免产能提升带来新的复杂度和失控？AI 成了软件生产系统里的重要执行者，你又该怎么定义自己的价值？
这几个问题最终汇成了这本书的核心：
AI 正在改变软件生产的方式。开发者要重新学的，是怎么在新的生产方式里工作。
它不是一本 AI Coding 工具手册，也不是一本预测程序员前途的职业指南。它想回答的是一个更底层的问题：
当“亲自写代码”这套工作方式的前提不再成立，开发者该怎么重新理解工作、组织工作，并在软件生产中找到自己的位置？
这就是这本书的创作缘起。