驾驭AI编程：真正的差距不在提示词，在你肯不肯做那四个动作

2026-11-09silcano

微信读书《驾驭AI编程：把AI用对的四个动作》· 抓取 384 屏 / 8 章 / 217 条目录
逐字核对 10 屏 · p0006 书名条核对为本书（作者李楠，2026 年 3 月于北京）· 全书读到末尾 · 2026-11-09
先说边界。384 屏读到书尾，meta 里 217 条目录、8 章，抓取完整。我逐字核对了 10 屏，抽样率约 2.6%。抽样不是随机翻：这本书的判断都压在「陷阱」和「动作」的对应关系上，所以我专挑作者举例、给数字、下结论的页面核对，看它举的例子撑不撑得住结论。

我先给结论：这本书真正的贡献不是发明了 CIVR 四个字，而是把「AI 会犯错」这句废话拆成了九个能提前拦的坑，并且承认了一件很多人不愿承认的事——AI 写代码变快之后，瓶颈从「写」挪到了「管」。它最硬的一页不是方法论，是那句「AI 说已修复，多半只是说我改了代码」。但它的问题也在这里：全书都在教你管，却始终没给你一条完整的项目线去练手，案例在 Java 和 Python 之间跳来跳去，读者拼不出一个从头到尾的样子。

先把作者的位置摆清楚。p0006 的前言末尾自述，书里内容来自三个层面：他一年半的项目实践、OpenAI／Anthropic／Stripe／Airbnb 等团队的公开工程经验，以及跟几十位一线开发者的交流。这三个来源决定了这本书的质地——它不是实验室报告，是一份带泥土味的经验总结。好处是例子都像真事；坏处是所有案例都做了匿名化，你没法核对，只能选择信或不信。

一、它先把「AI 会犯错」拆成九个能拦的坑

第 1 章的骨架是一串编号陷阱：Almost Right（差一点就对了）、The Unsaid（未言明的信息）、Frozen in Time（知识冻结）、The Confident Error（自信地犯错）、Context Rot（上下文腐烂）、Error Snowball（误差雪球）。名字起得很整齐，但真正让我停下来的是 p0040 解释 The Unsaid 时用的那个例子。

书里讲一个采购单场景：Agent 不知道这家供应商前一天升级了字段，也不知道「超时」和「售罄」是两件不能等同的事。在缺乏项目特定信息的情况下，它做了「统计上最常见的猜测」——把不认识的 JSON 按形状拼出最像采购单的结构，把超时按最熟悉的「无库存」语义解释。作者的评语是：「这种无中生有的幻觉，对真实业务来说就是一场灾难。」

这个例子的可怕之处不在「AI 编了」，而在它编得符合形状。字段名对得上、嵌套层级对得上、类型对得上，所以它会顺利通过格式校验，一路跑到业务逻辑里才炸。这解释了为什么「加个 JSON Schema 校验」这类防护在真实系统里经常失效——它防的是格式，不是语义。

同一页的【旁白】给了全书我认为最有价值的一个分类，作者说它来自和一位 AI 公司 CEO 的交流：人类知识可以分两种性质完全不同的类型。共识知识（数学、物理、通用编程模式）遵循自然规律，在训练数据里大量存在，是 AI 的优势领域，「1+1=2 的结论不会因会议投票而改变」；规范性知识（公司的编码规范、行业合规要求、API 版本升级后的破坏性变更）是「有人说了算」的规则，「贵公司的 Git 分支策略从 Git Flow 切换到 Trunk Based，AI 无法推断出新策略的具体形式。新策略不是从旧策略『推导』出来的，而是团队开会决定的」。

这个区分值得单独拎出来讲，因为它把「AI 为什么不懂我们公司」从抱怨变成了可操作的判断：凡是「有人拍板定的」，AI 一定不知道；凡是「有客观规律的」，AI 大概率比你好。你写提示词、写规范文件之前，先分清这一条属于哪类，效率会差好几倍。这也是我读完全书后认为最该记住的一页——比 CIVR 四个字母有用。

二、CIVR 不是 PDCA 换皮，差别在「执行者」

第 2 章提出 CIVR：约束（Constrain）、告知（Inform）、验证（Verify）、校准（Recalibrate）。作者自己在 p0090 先把最难听的问题问出来了——「这不就是 PDCA 换了个名字？」

他的回答我认，而且答得比大多数方法论书干脆：

CIVR 继承了 PDCA 的循环结构。但差异在于焦点：PDCA 围绕执行（do）转，四个环节的目的是让执行可控。CIVR 围绕一个不可预测的执行者转，AI 的执行你无法逐步控制，只能在输入端约束，在输出端独立验证。PDCA 更像是在稳定流程里持续改进；CIVR 先承认执行者会跑偏，再用约束、上下文、验证和校准把它拉回目标。

「先承认执行者会跑偏」——这句话是全书的方法论地基。传统项目管理假设执行者是可预测的（人也会犯错，但人的错有模式、有动机、可沟通），所以管理的重心在流程；AI 的错误没有动机、不成模式、还会自我辩解，所以管理重心必须前移到输入端和输出端。这不是换名词，是换假设。

紧接着 p0090 又给了一个我很欣赏的自我限制：CIVR 不替你判断。它明确说有两件事它不碰——任务选择（该不该让 AI 做这件事）和任务分解（一个大需求怎么拆成 AI 能处理的小任务）。任务选择给了三个维度：复杂度（AI 能处理的粒度）、可逆性（出错了能不能回滚）、验证成本（你能不能判断对错）；「三个都低的任务，放手让 AI 跑；任何一个高的，收紧控制或自己来」。

这个三维度是全书最好用的一个工具，比四个字母实在。举个书里的对照：一个涉及支付核心的紧急 hotfix，「也许你自己写更快更安全」；一个探索性的原型，「过早约束反而限制搜索空间」。同一套动作，两种用法，判断标准就是这三条。可惜作者只在这里给了一次，后面章节反复讲「约束」「验证」时，很少再回到这个坐标系——如果每章开头都用这三个维度定位一下，这本书的可操作性会上一个台阶。

三、告知这一章，是全书写得最狠的一章

第 4 章讲「告知」，我原以为会是「怎么把需求写清楚」那种老生常谈，结果 p0170 一页里连着给了三条反直觉的结论。

第一条，给例子比给规则更有效：「如果你想让 AI 遵循某种代码风格，『参考 utils/helpers.py 的风格』通常比一页规则更有效。结构化定义（schema、spec）的价值远超 1000 字的文字描述。」第二条，规则文件越短越好：「规则文件不是百科，写得越长，越需要分层和按需加载。」

第三条最狠，讲工具数量：「控制工具数量：不要把所有 MCP 服务器和工具都常驻打开。工具数量既是约束问题，也是告知问题。每个工具说明都会占用上下文，并增加模型选错工具的机会。」然后举了 Vercel 的例子：把内部一个数据查询 Agent 的工具砍到只剩一个（执行任意 bash 命令，靠 grep、cat 这类命令干活），任务准确率从约 80% 提升到 100%，步数、token 和耗时也全面下降，作者加的批注是「工具越少，职责越清晰，模型越容易选对」。

这一条值得所有在堆 MCP 的人抄下来贴在显示器上。当下主流叙事是「接得越多越强」——接数据库、接 Jira、接内部 API，每个都写一段说明。这本书从上下文成本和选择成本两个角度反过来说：每多一个工具，模型就多一个选错的机会，而选错的代价往往比不会做更大。80% 到 100% 这个跳幅，靠的不是更强的模型，是更少的选项。

同一页的【旁白】还泼了一盆冷水，而且泼得有理有据：作者引 Nine Two Three 在 2026 年 4 月的文章汇总的多组证据——清华 AGENTIF benchmark 显示真实 Agent 场景里的指令完美遵循率并不高；开发者社区也长期抱怨 .cursorrules 和 CLAUDE.md 会被模型忽略。他的结论是：「不是『告知没用』，而是告知必须配合约束（C）和验证（V）。单靠 Inform 可以把 CLAUDE.md 写漂亮，但并不能保证 AI 真的照做。」

这是全书最诚实的一段。市面上讲「上下文工程」的内容，九成停在「把规则写清楚、把文档喂进去」，而这里直接承认了写了也未必照做，所以要靠约束兜底、靠验证收口。一个作者愿意在自己的核心章节里说出「这一招单独用不管用」，可信度是加分的。

第 5 章的 p0200 用 Spec Coding 把「告知」推到极端：同一个支付回调，无 Spec 时直接发一句「写一个支付回调接口」，出来的代码跑得通，但注释里明明白白写着「没有验签、没有幂等、没有检查状态流转」。有 Spec 就是先把「什么算对」定义出来，再让 AI 写。这个对比的说服力不在代码本身，在于它演示了「能跑」和「对」之间那道缝有多宽——而这道缝，正好是第 5 章「验证」要处理的东西。

四、「已修复」不是修好了：验证为什么最难

p0240 是第 6 章讲校准的一页，但我觉得它同时是全书对「验证」最锋利的一刀。

它先说方法：让 AI 加调试语句，比让 AI 直接修 bug 更有效。可以让它「在函数入口和出口各加一行日志，打印参数和返回值」，跑一遍，把日志贴给 AI。理由是「把『AI 猜问题在哪』变成了『AI 看到问题在哪』」。数字不必精确，但体感差异很明显：盲猜时 AI 经常来回打转；给出真实日志和输入输出后，它更容易一次抓到关键。

然后是最关键的一句：

AI 说「已修复」时，你要警惕。已修复 很多时候只是「我改了代码」的意思，不等于「我验证了修复有效」。每一个「已修复」后面都需要一个验证动作。

这句话解释了为什么很多人用 AI 编程会有一种诡异体验：单次对话里它响应极快、态度极好、结论极确定，可项目整体却在变慢。因为「我改了代码」这个动作的成本被 AI 降到了接近零，而「验证改动有效」的成本一分没降——它还是得跑起来、得看日志、得复现那条路径。AI 把便宜的那一半做得更快，贵的那一半原地不动，于是贵的那一半在总时间里的占比越来越大。这就是为什么「AI 提效」在个人体验上成立，在团队交付上常常不成立。

更麻烦的是第 5 章提到的「理解债务」：验证通过不等于真正理解。测试绿了、CI 过了，代码进了主干，但没人能说清它为什么这么写。这笔债不会立刻爆，它会在三个月后某次改动时一起结算。书里还提了一个很扎心的观察——你的 review 耐心在退化。我认同这个判断，而且觉得它比任何「AI 生成代码占比」的统计都更能说明问题：当 diff 每天都是几百行、每行都「看起来对」，人的注意力必然会滑向「扫一眼就点通过」。

五、约束与告知在打架：p0280 那页最诚实

7.1 节讲 CIVR 之间的跳转，这一页（p0280）承认了一件方法论书通常不愿承认的事：四个动作之间会互相拆台。

它先给了第三种失控情况：你让 AI 加功能、加缓存、优化错误信息，每一轮都对，但五轮之后代码膨胀一倍、逻辑纠缠。这时「你不是在校准，是在用 R 做增量堆砌」，正确动作是回到 C 重新划定模块职责边界，让 AI 基于新约束重写。然后是 C 与 I 的张力：

你给了 AI 详细的上下文，如系统架构、数据流、业务规则、历史决策；同时又给出严格的约束，如只能改这个文件、函数签名不变、返回格式固定、不能引入新依赖。AI 输出确实「安全」。但它几乎没法利用上下文做判断：知道系统是事件驱动的，却不让碰消息队列代码；知道通知可以丢失，却被要求给通知模块加三层重试。约束太紧，局限了 AI 的解空间，反而可能找不到真正的解决方案。

紧接着一句总结，我认为是全书最好的一句：「约束应排除你不想要的东西，而非排除 AI 可能给出的更好方案。若约束把实现方案限定到只剩一种，你其实不需要 AI，自己写更快。AI 的价值在于你给定的边界内做出你没想到的设计选择。若边界紧到无选择空间，你付出的成本（准备上下文）却得不到收益（AI 利用上下文判断）。」

这段话之所以值钱，是因为它把「为什么很多人用 AI 用不出效果」说清楚了：不是模型不行，是约束写成了剧本。你把每一步都规定死了，AI 就只能当一个打字快的实习生，那它的价值当然只剩打字速度。这个悖论在团队里尤其常见——规范越严的团队，给 AI 留的空间越小，AI 的产出就越像「照抄规范」，于是大家得出结论「AI 也就这样」。

我要补一句书里没说透的：边界该留多宽，其实取决于你的验证能力。你能多快发现错误，就能放多宽。放得宽但验不动，等于赌；放得窄但验得动，等于白干。所以 C、I、V 三者不是并列的四个动作，V 的能力决定了 C 的松紧——这个动态关系书里只点了半句（「C 和 I 需平衡」），没有把 V 拉进来，是这一章的一个缺口。

六、落地那一章：它给了顺序，没给账本

p0310 是 7.5 节讲团队落地的节奏表，四步：基础设施 1 周（统一 AI 规则源、设 CI 硬规则、约定关键文件负责人、补齐工程基建）→ 第一个项目 1 个月（挑一个内部工具或新项目，全流程走 CIVR）→ 扩展 2–3 个月（推到存量项目，先从低风险模块开始）→ 核心攻坚 3 个月+（核心系统引入 AI，全量 CIVR＋人工审查）。

作者特别提醒「基础设施」这一步容易被低估：很多团队急着让 AI 写代码，连基本的工程基建都没到位——没有 CI 流水线，AI 写的代码提交了也没人自动检查；没有测试环境，改完只能在生产上验证；没有灰度发布，上线就是全量；没有自动回滚，出了问题靠人手动恢复。他的原话很重：「没有 CI 的团队引入 AI 编程，等于没有刹车的车踩油门。」

这个判断我完全同意，而且是这本书对行业最有用的一句提醒。因为它反着卖点说话：工具厂商卖的是「更快」，而这本书告诉你先修刹车。顺序也排得对——基建、单项目、存量、核心系统，风险递增、可逆性递减，跟 p0090 那个三维度判断是一套逻辑。

但这一步之后就虚了。表里只有「1 周／1 个月／2–3 个月／3 个月+」的时间轴，没有人数、没有预算、没有失败退出的判据。一个 Tech Lead 拿着这张表去立项，老板一定会问：几个人？花多少钱？做到第 2 个月没效果怎么停？这三个问题书里都没答。我能理解作者不想给不准的数字，但既然敢给时间表，就该给一个量级——哪怕是「两三个人、别超过两个月」，也比空白有用。

七、它的短板

这本书的结构工整得有点过头：8 章、4 个动作、9 个陷阱、每章末尾一张 checklist。工整是优点，也是它最大的问题来源。

一、没有一条贯穿全书的项目线。这是最影响使用体验的一条。第 3 章的软约束例子落在 Java/Spring（锁 2.7.x、MyBatis 参数化查询、实体用 Lombok @Data），第 5 章的 Spec Coding 例子又跳到 Python 的支付回调（@app.post("/payment/callback")），第 7 章讲存量系统改造，用的又是另一套语境。每个例子单看都挺好，但拼不起来——读者读完知道「每个动作该做什么」，却不知道「一个项目从第一天到第三个月，这些动作按什么顺序落地、每一步的产物长什么样」。方法论书最需要的那张「全程样例」，这本书缺了。

二、关键数字全是转引，且不给口径。Vercel 那个 80%→100%，是转述别家内部优化；附录 B 那张证据表里的「2025 年检测到 2865 万个新增硬编码密钥」，来源标的是 GitGuardian。转引本身没错，学术写作也这么干，问题是全书几乎没有「作者自己测出来的数」。一本讲「验证」的书，自己的数据链却主要靠二手引用，这多少有点自相矛盾。更麻烦的是，这些数字被放在论证的关键位置上——「工具越少越准」这一节的力度，几乎全靠那个 100% 撑着，而它恰恰是最不可核对的。

三、checklist 之间重复。第 3 章末尾的约束清单里有「退路」「软约束」，第 4 章的告知清单里有「先降噪再喂」，第 5、6 章各有验证和校准清单。单张都合理，连着读会发现三张清单在互相覆盖：比如「限制改动范围」既是约束也是校准手段，「翻车记录」既是告知资产也是校准沉淀。四动作本来就是循环，硬拆成四张互不重叠的清单，必然有交叉，读者照着做时会重复劳动。

四、结论的确定性和证据的新鲜度不匹配。附录 B 那张时间线（p0360）自己写得很清楚：2024–2025 上半年是「单点博客、零星报道、个人吐槽，缺乏可引用的实证数据」；2025 下半年是「单一机构发布初步报告，但缺乏交叉验证」；2026 Q1–Q2 才进入「多家独立机构口径相互印证」的阶段。也就是说，这个领域的系统性证据只有半年多的历史。可正文的语气是定论式的——「AI 在维护/重构时风险显著更高」「Agent 代码本身很小，债务藏在其周围的基础设施里」，这些都是 2026 年的新结论，被当成不需要限定的常识在用。作者自己在附录里承认了证据的年轻，正文里却没有相应地降低确定性，这是方法论上的不一致。

五、第 8 章从工程滑向了预言。「建立你的护城河」这一章讲行业洗牌、组织变形、AI-native 公司、OPC 与产业风向图、旧练场消失。这些话题本身值得谈，但它和前七章的质地完全不同：前七章每句都能落到一次提交、一个 diff、一条日志上，第 8 章落到的是趋势判断。目录里没有一条关于岗位数量、薪酬变化、招聘结构的实证，判断却下得很实。读到这儿会有一种落差——像一本手术手册的最后二十页突然开始讲医学的未来。

六、对自己的方法缺少反例。全书 9 个陷阱、4 个动作，例子都是「用了这套就顺了」。有没有用了 CIVR 还是翻车的？有没有约束写好了、验证也做了、最后依然返工的？书里没有一例。而按作者自己的逻辑（p0280 承认四个动作会互相拆台），反例必然存在。一本讲「先承认执行者会跑偏」的书，对自己方法的失效边界反而没怎么承认，这是我觉得最可惜的地方。

八、适合谁，以及怎么用

最合适：已经用 AI 写过一段时间代码、但说不清为什么有时候好用有时候不好用的人。这本书最大的价值是给那种模糊的不适感命名——你觉得「不对劲」的地方，它多半有一个编号：AI 把超时解释成售罄（The Unsaid）、上一轮的错被下一轮继承（Error Snowball）、上下文越聊越脏（Context Rot）、说了已修复其实没验（Confident Error 的变体）。有了名字，你才能针对性地防。

次合适：要带团队落 AI 编程的 Tech Lead。第 7 章的落地节奏和「先修刹车」那句话，可以直接拿去做立项沟通：先把 CI、测试环境、灰度、回滚补齐，再谈提效。这个顺序能帮你挡掉一批「为什么我们上了 AI 反而更乱」的质疑。

不太合适的两类人。一是刚开始学编程的新人：这本书假设你已经知道什么叫幂等、什么叫事件驱动、什么叫灰度发布，它教你管 AI，不教你写代码。二是想找「提示词模板」的人：全书几乎没有可直接复制的提示词，它给的是判断标准，不是话术。

具体读法：先读 p0040（两类知识）和 p0090（CIVR 与 PDCA 的区别、任务选择三维度），再读 p0170（工具越少越准）和 p0240（已修复不等于修好），最后才回来看第 3 章的约束清单。这样排序的好处是，你先拿到四个能立刻用的判断（这活该不该给 AI、规范属于哪类知识、工具要不要砍、它说修好了要不要信），再回头补流程。反过来从第 1 章的陷阱清单读起，你会先记住九个名词，却不知道该先防哪一个。

读完最该做的一件事，不是写 checklist，是翻自己最近十次让 AI 改代码的记录，数一数有几次你真的验证了「已修复」。这个数字比书里任何一个百分比都更能告诉你，你的瓶颈在哪一环。

最后一句：这本书最值钱的地方，是它把「用 AI」从技巧问题改成了管理问题——你管的不是一个更聪明的工具，是一个会自信地跑偏、还会告诉你已经修好了的执行者；而它最该补的地方，是它自己也没敢承认：管得再好，验证那一环的成本，AI 一分都没替你省。