前言：判断权去了哪里

这本书的起点是一件具体的事：一个没有编程经验、纯粹是游戏玩家的朋友，想给游戏做一个 MOD（玩家自己给现有游戏加的功能扩展），让房间里的灯在游戏角色扣血时有反应。

AI 已经能在几分钟内生成一个看起来完整的程序。困难随之换了位置：代码出现得很快，判断它能不能用，仍然要由人负责。

常见的做法是继续追问 AI，让它解释、检查或者保证。这个办法把裁决权交回了同一个生成者。解释可以流畅，保证也可以肯定，程序仍然可能在真实输入下出错。

这本书提供另一条路径：先把「什么结果算对」写成可以检查的条件，再让 AI 写实现。判断依据放在实现之外，之后才谈自动生成、自主修复和部署。这套工作方式在书中称为验收先行。

这本书做一件事

全书围绕一个示范项目展开：把几家供应商格式不同的报价表，整理成统一结构的汇总表。这个项目来自真实的重复劳动，输入和输出容易观察，做错了也能恢复。

从这件小事出发，书中依次建立五个动作：找到值得解决的问题，写下可观察的结果和边界，先建立会失败的检查，让 AI 把实现改到检查通过，再把工具交给真实使用者验证。

书里不教提示词技巧，不处理支付、敏感个人信息和高并发场景，也不承诺读完就能成为职业程序员。这些边界在最后一章会落成一张项目分级图。

读这本书需要什么

• 能在电脑上安装软件、打开文件和使用浏览器。
• 能用自然语言把一件工作的步骤说清楚。
• 手上有一件重复发生、做错了能够恢复的事。

终端、Git、测试框架和部署这些概念，只在它们开始解决眼前问题时出现。

读完会留下什么

按章顺序做完，留下的是一组可以回看的证据，不是知识清单：

• 一个有人正在使用的小工具。
• 一组亲手裁决过的验收条件。
• 一次测试按预期失败、再从红到绿的完整记录。
• 一份能看出约束有没有被暗改的改动记录。
• 一张写清能力边界的清单。

这些证据共同回答一个问题：为什么这次修改可以接受。

关于写作方式

正文由作者与 AI 协作写成。书中命令、按钮和测试结果在对应平台实际运行后落笔，工具事实以官方文档为准。发现过期或错误，欢迎在关于页留下 Issue。