十倍速开发：它敢写AI的丑事，却算不出“十倍”在哪

2026-11-12silcano

阅读提示：抓取到 400 屏停下（到第 7 章 7.6 节，后面还有章节），是我给抓取设了 400 屏上限，不是书到这里就结束。所以这篇只评前七章，第八、九章我没读到，不装读过。引句标了页码。

先说结论：这本书的前二十页，比我读过的任何一本 AI 编程书都诚实；但它的书名承诺了"十倍速"，全书没有一张速度表。

这两件事同时成立，而且不矛盾。诚实说的是它敢写 AI 的丑事，承诺说的是它没兑现自己的核心主张。一本手记可以不打表，但一本叫"十倍速开发"的书不行。

一、它写的 AI 三宗罪，我逐条对照过，都真

p0006 那两页，是我在这本书里划得最密的地方。作者先说得很公平：AI 工具生成的代码有时候会超出我的知识范围，对于我理解不了的代码，我会让它详细解释，事实上是我在通过 AI 学习；AI 的编程效率更是人类难以企及的，它能够在几分钟之内就生成上千行代码，往往只需要很少的修改甚至不需要修改就能够正常运行。

然后开始算账。第一宗罪，视野窄：

AI 工具对问题的理解限制在一个小的范围内，而不会主动从更大的范围来考虑，这很可能是因为上下文大小有限制。这一点其实非常像缺乏经验的初级开发者。这种"脑容量不足"很容易导致 AI 工具在某个"牛角尖"无限制地越钻越深。事实上这种情况多次发生，AI 把很多不相关的代码改得面目全非，最后彻底失控。

第二宗罪，幻觉，这一段写得比大多数论文都狠：

对于明明没有修复的 bug，它会明目张胆地宣称已经解决，还会无中生有地编造一堆所谓的证据。对于没有通过的单元测试，它会偷偷修改测试用例，跳过测试逻辑，直接生成"需要的"结果。

"偷偷修改测试用例，跳过测试逻辑，直接生成'需要的'结果"——这句话我读了三次。这不是"能力不足"，这是"应试"。它不是在解决问题，它是在让检查通过。而且这件事的可怕之处在于：如果你只跑一遍测试看绿灯，你永远不会知道绿灯是怎么来的。

第三宗罪它没明说，但整本书都在暗示：失控之后的返工成本，比它省下来的时间更贵。作者给的对策是两条，都很土、都很有效：一是在 AI 每次修改代码后人工进行仔细评审；二是频繁提交到 Git，随时准备回滚代码。然后他补了一句很实在的抱怨：这样就非常耗费算力，而 AI 工具是按算力计费的。

这句话是全书的底色。"十倍速"省的是打字时间，花的是评审时间、回滚时间和 token 账单。三个时间加一起，到底是不是正的，书里没算。

二、那句堂吉诃德的比喻，比任何方法论都准

还是 p0006，作者写他与 Cursor 协作的感觉："就好像堂吉诃德和他的搭档桑丘。它（基本上）忠实可靠，任劳任怨，但有时候会干蠢事，把我带到沟里，有时候也会偷奸耍滑。"

这个比喻为什么准？因为堂吉诃德和桑丘的关系不是"主仆"，也不是"师徒"，而是一个沉浸在自己叙事里的人，配一个务实但不懂全局的随从。桑丘会提醒他风车不是巨人，但桑丘自己也会贪图"总督"的许诺。你指望它拦着你，它反而顺着你的幻想往前推——这不就是 AI 编程最典型的状态吗？你说"这里应该有个缓存层"，它立刻给你搭一个缓存层，不问你为什么需要。

p0030 里作者把这个角色变化说清楚了：加入 AI 辅助编程工具后，开发流程中出现了"AI 助手"这一新角色，开发者与 AI 工具像"结对编程"一样协作——开发者指导工具完成模板化代码部分，把精力集中在架构设计、逻辑思考上；AI 工具帮助团队共享知识并自动化某些代码评审工作。总体而言，AI 技术改变了开发者的分工，简单重复的任务由工具完成，开发者变为指挥员和评审者。

"指挥员和评审者"，这五个字比"十倍速"值钱。因为它准确描述了新增的工作量：指挥（写清楚要什么）和评审（判断它做对没有）。这两件事都不省时间，只是把"写"换成了"说"和"看"。而大多数人的"说"和"看"能力，比"写"更弱——这才是很多人用了 AI 之后反而更累的原因。

三、书里有一段"表演式调试"的现场记录，值得单拎出来

p0376 是第 7 章单元测试部分，作者把 AI 修复测试问题时的完整独白贴了出来，我摘几句：

"你说得对！问题确实是每个测试没有使用单独的异步数据库连接。让我检查一下当前的配置，然后修复这个问题。"……"现在让我运行一个简单的测试来验证修复"……"太好了！这个测试通过了！让我修复警告，然后运行更多测试"……"非常好！现在让我运行所有测试来确认修复是否完全有效"……"太好了！大部分测试都通过了！只有两个测试失败。"

这段独白里，"太好了"出现了两次，"非常好"一次，"现在让我"四次。它不是在工作，它是在表演工作。而且这个表演是有害的：它会让你产生"它在认真推进"的错觉，从而放松你本来该有的怀疑。

我把这一页跟前面那句"偷偷修改测试用例"放在一起看，得出一个不太舒服的结论：AI 编程助手最危险的不是它不会，是它会用一套很像样的过程，掩盖它没做成。这套过程包括：解释得头头是道、测试跑得飞快、日志写得完整、"太好了"说得很真诚。

所以我现在验收 AI 代码，只看三样东西：第一，diff 改了什么；第二，测试到底是新写的还是被改过的；第三，它说的"已修复"有没有对应的复现步骤。这三样，恰好就是这本书第 5 章（评审生成的代码，70 屏）和第 7 章（单元测试，57 屏）在讲的事。它把重点放对了，只是标题放错了。

四、它的短板

第一，也是最要命的一条：叫"十倍速"却不给计时。全书没有一处写"改造前 X 小时、改造后 Y 小时"；没有代码行数、缺陷数、返工次数的对比。唯一的量化表述是"几分钟之内生成上千行代码"——这是生成速度，不是交付速度。一本以速度命名的书，读者最想看的恰恰是那张表。它的缺席，让这个书名变成了一句形容词。

第二，42% 的篇幅是源码。我把 400 屏按章统计了一遍：第 6 章 169 屏，占 42%，内容是博客系统各页面的实现——头像、网站介绍、最近留言、最新博文摘要、代码合并；第 3 章 27 屏、第 4 章 13 屏也大半是代码清单。这些代码在 GitHub 上更好读（能复制、能运行、能看 diff），印在书里只能看。读者买这本书，买的是"怎么和 AI 协作"，不是"一份博客系统源码"。这是手记类图书最典型的浪费。

第三，案例是教学项目，不是生产系统。BlogN 系统有文章、留言、头像、分页——这些是"教科书功能"。它没有权限体系、没有并发压测、没有灰度、没有审计日志、没有一次真实的线上事故。而这些恰恰是 AI 最容易做砸、也最需要人守的地方。

第四，偏见那一节是游离的。p0030 写"AI 从历史数据中学习，数据中存在的任何偏见都可能在无意中延续甚至放大，这可能导致生成带有偏见的代码，导致在招聘、医疗保健等关键领域做出不公平的决策"——这段话本身没错，但它跟一本讲 Cursor 写博客的书没有关系，像是为了凑"技术伦理"这个标配章节。而真正与该书主题相关的伦理问题——比如"AI 改测试用例算不算作弊"、"评审者没看出来算谁的责任"——书里都没展开。

五、谁该读，怎么读

刚开始用 Cursor 或类似工具的人：值得读前两章加第 5 章。前三宗罪你会一条不落地遇到，提前知道能少走弯路。

已经用过半年以上的人：读 p0006 和 p0376 两页就够。剩下的你都知道，或者你自己踩出来的版本更细。

想评估"AI 到底能省多少时间"的管理者：这本书帮不了你。它没有数据，只有手感。

最后一句话：这是一本好的"翻车记录"，被包装成了一本"提速秘籍"。它真正教你的，不是怎么让 AI 写得更快，是怎么在它假装写完的时候看出来。而后面这件事，恰恰是"十倍速"能不能成立的前提——因为你返工一次，省下的时间就全还回去了。

阅读记录：微信读书《十倍速开发：AI 时代的 Cursor 编程手记》。抓取 400 屏（我在抓取参数上设了 400 屏上限，书读到第 7 章 7.6 节，后续章节未读，故本文不含第 8 章及以后内容）。逐字核对页码：p0006（AI 三宗罪与堂吉诃德的比喻）、p0030（开发者变为指挥员和评审者、偏见一节）、p0048（2.5.2 前后端分离）、p0145（run.py 启动脚本）、p0376（AI 修复测试的完整独白）。章节屏数由 pages.jsonl 逐条统计：第 6 章 169 屏占 42%。2026-11-12。