第三篇 · 做出东西 / 第 9 章

真实案例：三个月，一个人

你的项目可能只有 5 张票，他的项目 26 张，坑是同一批。 这一章讲的是另一个项目——软考题库小程序，不是午饭登记； 你只需要看坑，不需要照搬它的规模。

预计阅读

20 分钟

前置

第 6–8 章

关键词

真实案例、复盘

读完这一章，你能

• 说清这个案例与你项目的规模差异，只迁移坑，不照搬做法；
• 把案例里的五个痛点分别对应到第 4、5 章的某个习惯；
• 用“已提交 ≠ 已完成”检查一次你手上的任务。

这个案例是什么

「大西瓜软考」——一个给软考考生用的刷题微信小程序，配后端和管理后台。 从第一行代码到正式上架，全程由一个人 + AI 完成。

另一个数字更值得注意：他写了 76 份开发日报。 平均每天一份，最多的一天写了 4 份。这个习惯不是他天生勤快—— 而是被逼出来的，原因你很快就会看到。

79 天时间线

五个真实的痛点时刻

下面这五件事，全部有日报原文可查。它们比任何理论都更能说明问题。

① 一个外行，两次否掉了 AI 的过度设计

做"学习报告"功能时，AI 给了一套方案：新增一个 kp_id（知识点编号）字段， 再新增一张 FeatureFlag 表（功能开关表：用来远程打开或关闭某个功能）。

这个人看了一眼，问了一句：

题库里已经有章节、小节、知识领域这三个标识了，用这三个还不能定位到知识点吗？

日报里老老实实记着："用户说得对，不需要新增 kp_id 字段。" 紧接着又是一条："不需要新增 FeatureFlag。"

② 上下文溢出了，所以他被迫写日报

从 5 月 30 日开始，几乎每一份日报的开头都写着同一句话：

"本日工作基于上一轮未完成的会话继续推进……因上下文溢出压缩后继续。"

连续两天出现，然后变成每天的常态。 这就是第 4 章讲的“变笨区”，在真实项目里的样子。

他的应对方式是被迫的、也是正确的——把 AI 的短期记忆，转成项目的长期记忆：

• 强制写日报（把上下文落到文件里）
• 把关键结论写进项目的 CLAUDE.md，每次会话自动加载
• 后来干脆规定：提交代码前必须先写日报，日报是提交的前置条件

③ 一天做完 26 个管理页面，然后花更多时间收拾

5 月 31 日那天，日报分了十三个部分。其中一项是： "管理后台全面增强：一口气新增 26 个页面"。 当天累计新增 16 个文件、修改 33 个文件。

结果呢？

半个多月后，他不得不启动 4 个 AI 并行审计这批页面，审出 10 个问题， 其中两个是致命的——有一个字段根本不存在，页面一打开就崩。

④「已完成」其实没有写进代码

这是全篇最值得警惕的一条。在他的日报里，出现了这样一段自己写的勘误：

"勘误：下文'第二轮修复'中的两处改动当时仅写入了方案文档， 实际未编码提交。该部分已在次日补实现。"

更早的一天，他还记下了另一个更狠的案例：一个兑换码复制功能， 代码从提交起就一直在仓库里，从来没被删过——但在真机上"可能从未真正工作过"。

而就在同一天，他正在庆祝"正式上架，全量发布成功"。

被这件事烫过之后，他自己写下了一条规则，写进了日报里：

"写日报时要区分「已提交」和「已完成」。"

⑤ 一个查不到的字典，让三个科目的题混在了一起

项目后来加了第三个科目。他在配置里写了一个对应关系：科目编号 3 对应"系规"。 但数据库里，系规的编号其实是 4。

于是代码是这样的：

prefix = COURSE_COLLECTION_MAP.get(course_id)   # 查 4 → 得到 None
if not prefix:
    return top_k_config                          # ⚠️ 悄悄回退到「搜索全部科目」

一个查不到的字典，没有报错，而是安静地退回到了"搜索全部科目"。 结果三个科目的教材内容全混在一起被检索。修好它只用改一个字符（3 → 4）， 但发现它花了好几天。

他踩的坑 → 五个习惯

把上面这些坑，和第 5 章的习惯对照一下，你会发现它们是严丝合缝对上的：

他自己总结出的规则

到后期，他已经不满足于"踩了坑记一笔"，而是开始把教训固化成规则， 写进项目的 AI 配置文件里，让 AI 每次开工都会读到。

他写的四条规则是这样的（这里做了通俗化改写）：

1. 先想清楚再动手

   不要假设、不要把困惑藏着、把权衡摊开来说。 如果有多种理解，全部列出来。如果不清楚，停下来，指出困惑，提问。

2. 能少写就少写

   用最少的代码解决问题，不做"以后可能会用到"的设计。 "如果你写了 200 行但可以写成 50 行，重写它。"

3. 只改必须改的

   每一行修改都应该能直接追溯到需求。只清理自己造成的混乱。

4. 用成功标准驱动

   先定义"怎么样算成功"，然后循环直到达成。 "强标准让你能独立循环；弱标准（比如『让它能跑』）需要不断澄清。"

全篇最值得学的一件事

如果这一章你只记住一件事，请记住这件。

上线前，他用多个 AI 做了一轮全功能审计，一共报出 88 个问题。

他没有直接开修。他做了一件很反直觉的事—— 又派了一批完全独立的 AI，专门去"翻案"：论证前面那些发现是错的。

结果：88 个里面有 6 个是假阳性（本来被报成问题，其实不是问题），被推翻了。 最严重那一档问题的准确率，从 33% 提升到 100%。

他自己写下的结论是：

"『看起来有 bug』≠『真的是 bug』——必须追踪完整的业务流程。"

"对抗性验证必不可少——即使很有把握的发现，让独立的人做翻案审查也能发现盲点。"

这个案例的诚实说明

为了不让这个故事被误读，有几点必须说清楚：

三句话带走

1. 规模不同，坑相同：先看他在哪一步翻车，再对照自己的项目。
2. 他被迫做的三件事——交接、切片、验证——正是第 5 章的三个习惯。
3. 最值钱的一条：不相信任何单方面的结论，包括 AI 的，也包括自己的。

自测：三个问题

为什么这一章开头要说“你的项目 5 张票，他的项目 26 张”？

为了让你只迁移坑，不照搬规模。他的 26 个页面、79 天和 10 万行代码是另一个项目的量级； 但“一口气做完”“已完成的幻觉”这些问题，和你手上的小项目是同一批。

“已完成”其实没写进代码，这件事对应第 5 章的哪个习惯？

习惯四：定义清楚「完成」，并亲手验证。代码写完了不等于功能实现了； 只有你能亲手点一遍的清单，才算验收标准。

为什么他不直接修那 88 个问题，而是又派一批 AI 去“翻案”？

因为“看起来有 bug”不等于“真的是 bug”。找问题的人容易替自己辩护， 独立的翻案者能推翻假阳性。这和“让 AI 审 AI 要换个干净会话”是同一个道理。

动手 10 分钟

打开你正在做的项目，找一张你认为“已经做完”的票，回答三个问题：

1. 它是“代码已提交”，还是“功能已在真实环境里跑通”？
2. 如果现在让你演示，你能在 2 分钟内点出正确结果吗？
3. 如果不能，缺的是哪一条验收清单？把它补上。

然后从这一章的五个痛点里挑一个最像你项目的，写下你准备用哪个习惯挡住它。

如果你看到 X，大概率是 Y

• 日报或总结末尾全是 ✅ → 大概率是 AI 写的“漂亮的结论”，不等于真实验证。抽一条亲手试。
• 一个配置查不到值，程序却继续跑 → 大概率是静默回退。让它改成报错，再决定怎么兜底。
• 一天做了很多页面，感觉特别顺 → 大概率是切得太大了。停下来，先验证最小的一片。
• “看起来有 bug” → 先追完整业务流程，再判断是不是真 bug；别直接开修。