> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/zi-yuan/epilogue.md).

# 后记

这本书从 2025 年深秋写起,2026 年仲夏定稿,前后横跨三个版本的 AI 编程工具迭代周期。回看整个过程,值得记下的不是"写完了"这件事本身,而是写作过程中那些被推翻、被重写、被客户和读者反复质疑的段落。这些段落留下的痕迹,比最终成书的文字更能说明这本书为什么是现在这个样子。

## 为什么写这本书

2025 年 9 月,作者接触到一个真实场景:一位产品经理想做一款行业研究 SaaS,预算只有传统外包报价的 1/8,期望 30 天内交付。他在 5 天内用 AI 工具完成了一个可演示的原型,功能完整度达到传统开发 3 周的水平;但当他把原型拿给真实用户试用时,用户在前 10 分钟内提出了 14 条反馈,其中 9 条与 AI 生成的代码直接相关——不是技术 bug,是"功能做出来了但不是用户要的"。这位产品经理在飞书里发了一段话:"我以为 AI 是程序员,现在发现 AI 是高级打字员——它能写,不能想。"

这个观察在 2025—2026 年间被作者在 12 个真实项目里反复验证。多数 AI 编程内容止步于"让 AI 生成一段代码",而真实业务关心的是"代码之后的事"——客户验收、资金到账、权限边界、异常兜底、回滚预案、长期维护。"代码"和"代码之后"之间,差一段需要工程纪律才能跨越的距离。这段距离,正是本书试图讲清楚的事。

写这本书的另一个动机,是作者观察到行业里一个被反复忽视的事实:信息差让非技术人走弯路。一位创业者用 AI 做出了一款产品,产品功能完整、UI 整洁、上线后却因合规问题被平台下架;另一位创业者用 AI 帮客户复刻了竞品,交付前夜被律师函告知"复刻即侵权";还有一位团队负责人,花了 3 个月让 AI 替团队写完所有文档,3 个月后回头看,文档里有一半的内容已与代码脱节。三个案例的共同特征是:做的人都以为自己在"用 AI 提效",结果在"看不见的边界"上踩了坑。

本书不是"AI 编程入门",也不是"工具对比评测",而是把"代码之后的事"按"案例—方法论—治理"三个层次整理成可被引用的工程纪律。读者拿到这本书,如果只是学会了"用 AI 生成代码",这本书没有完成它的使命;读者如果能在做任何 AI 项目之前,先问自己一句"代码之后会出什么问题",这本书就值得放在手边。

## 写作的三个阶段

这本书的写作,经历了三段互相推翻的迭代。

\*\*第一阶段(2025 年 10 月—2026 年 1 月)\*\*是按"AI 工具大全"的思路写的。作者收集了 30 多款 AI 编程工具、80 多篇论文、200 多篇社区文章,试图把"市面上所有能用的工具"按"功能—价格—适用场景"罗列。写到第 4 章时,作者意识到这条路径走不通——工具更迭的速度超过写作速度,任何"大全"在付印时都已过时。第一版草稿被全部推翻。

\*\*第二阶段(2026 年 2 月—4 月)\*\*是按"案例合集"的思路重写的。作者挑选了 12 个自己深度参与的真实项目,每个项目按"需求入场—关键决策—踩坑与解决—结果复盘"的结构展开,试图用案例本身传递方法论。这一版的问题是:案例之间缺乏统一的分析框架,读者读完整本书,可能"看了 12 个故事",但说不出"我下次做项目时该按什么步骤来"。第二版草稿在第 8 章写完后被再次推翻。

\*\*第三阶段(2026 年 5 月—7 月)\*\*是当前的版本。核心改动是把"案例"压回到"方法论的注脚",每一章先讲方法论再讲案例,案例里的所有具体数字、价格、错误率,都对应到方法论里可被引用的原则。这一版推翻的代价最大——前 11 章中有 6 章整体重写,第 2、5、11 章改了 5 遍以上,第 13 章(治理)的结构被推翻了 3 次。第 15 章的"四根杠杆"框架是最后一个月才定下来的——它原本是第 13 章的一节,被作者提为全书收束后,反而成了整本书最被读者反复引用的部分。

三次推翻留下的痕迹,目前可在第 2、3、5、6、8、11、13、15 这几章的字里行间找到——这些章节的行文节奏与其他章节略有不同,某些段落读起来有"先讲了 A 又讲 B,最后回到 A"的反复感。这是真实的工作痕迹,作者没有刻意抹去。

## 这本书的局限

写完这本书之后,作者必须坦言三件事,以免读者被误导。

第一,数据会过时。本书所有价格、版本、跑分、错误率,均截至 2026 年 7 月 31 日。AI 编程行业以 4 至 8 周为周期迭代模型,工具每周更新,读者拿到本书时,具体型号大概率已经更换。本书的目标不是罗列当前参数,而是给出分析格局的方法——参数会过时,方法不会。但如果读者试图把本书里的具体数字直接套用到自己的项目里,会失望。

第二,场景有边界。本书的 12 个真实项目集中在"中小团队、独立开发者、产品经理"三类读者画像,处理的问题以"做产品"和"改存量"为主。对于"大规模团队的代码治理""上市公司级别的合规审计""安全敏感行业的硬性要求"等场景,本书提供的工程纪律可作为起点,但远不能作为终点。这些场景的复杂度超出本书讨论范围,需要更专业的工程团队与法务支持。

第三,作者本人也是有限理性的。这本书的所有方法论,都来自作者在过去 3 年参与的约 30 个真实项目,样本量不足以支撑"普遍规律"的论断。本书给出的所有判断,读者应当套用本书自己在前言中确立的引用规范——任何"AI 让 X 提速 Y%"的宣称,先追问一句"时间是如何被记录的,样本是否经过选择",再决定是否采信。

## 给读者的话

这本书能完成它使命的前提,是读者不只是"读完",而是"用这一章做一遍"。作者有三个具体的建议。

第一,不要照搬案例。本书的 12 个案例,均带"现场还原""现场细节""现场案例"三类描述,这些描述不是为了让读者模仿,而是为了让读者理解"决策是怎么做出的"。读者的项目与书中项目几乎不可能完全相同,直接照搬反而会走弯路。正确用法是:读每个案例时,问自己一句"如果这件事发生在我身上,我会怎么决策",然后对比作者的做法,找出差异背后的判断逻辑。

第二,要按"工作方式"重新设计。本书讨论的工程纪律,需要按读者所在团队的具体情况重新设计。例如"7 天 MVP"的方法论,在大型团队里可能变成"3 个月 MVP",时间盒长度变了,但"关键路径优先""每日交付物可被验证"这些底层原则不变。读者不应把"7 天"这个具体数字照搬,而应把"时间盒驱动 + 关键路径优先"这个方法论按自己的场景重写。

第三,欢迎反馈。这本书不是终点,而是起点。读者在用本书做项目的过程中,会发现本书的某些方法论在你的场景里失效,某些工程纪律在你的团队里推不动——这些"失效"和"推不动"对作者而言,比书里的"成功案例"更有价值。每一次重印,作者都会把读者反馈的方法论修订纳入下一版。反馈渠道见本书配套的勘误页。

## 修订与勘误

本书每次重印时,会更新以下内容。

**数据更新**:价格、版本、跑分等时效敏感的数据,按"数据截止"时点更新。下一版的数据截止时点暂定为 2027 年 1 月 31 日。

**方法论修订**:根据读者反馈,调整失效或被推翻的工程纪律。修订记录会按"原表述—新表述—修订理由"三段式,集中发布在本书的勘误页。

**案例替换**:在保留方法论完整性的前提下,替换部分案例的具体内容,以反映"工程实践的最新形态"。案例替换不改变方法论,只改变"方法论被应用的具体场景"。

**勘误表**:任何印刷错误、引用错误、图表错误,均在勘误页集中列出。读者在阅读过程中发现的错误,可通过勘误页提供的反馈渠道提交,经作者核实后在下一版修订。

本书的写作,得到了许多真实客户、真实工程师、真实创业者的配合。他们在项目过程中允许作者记录现场细节、引用具体数字、保留真实错误。这些客户的名字不会出现在书中(出于商业保密考虑),但他们才是这本书真正的合著者。书中所有方法论的"现场还原""现场细节""现场案例"段落,均来自这些未被署名的合著者的真实工作记录。如果本书的某个段落让读者在工作中少踩了一次坑,这份功劳属于他们;如果本书的某个段落让读者在工作中多走了一段弯路,这份责任由作者一人承担。

愿这本书的每一位读者,都能在 AI 编程的时代里,成为自己项目的工程师,而不仅是 AI 提示词的搬运工。

— 完 —