Earl Grey 这篇写的是给妻子做的 Cuenta 应用，10 月 20 日发在 dev.to。我放进夹子之后一直没点开，后来看到评论区 Oleksandr 说「一个错误猜测一路带到最后」是全文最有价值的部分，才回来从头读。
这条在讲什么。作者妻子 E. 在圣巴巴拉做批发烘焙，四家咖啡馆客户。Cuenta 干的活很具体：按咖啡馆清点货架上剩的产品、录入当日配送、生成能打印或邮件发的发票、记谁欠多少钱。Devpost 的 Build With AI: Basics 黑客松要求从空文件夹开始，用官方 skill pack 按 1-start 到 6-ship 六个指令文件往下走。
我读到第七段才确定这值得推荐。不是产品多复杂，是作者把「访谈」和「手上动作」分得很清楚。动手写代码前，范围、PRD、技术规格三层文档逐层走，每一份批准了才进下一层。访谈阶段就发现两个问题：Vercel 服务器用 UTC 计时，圣巴巴拉下午 5:30 开的发票会被记成第二天日期；另一个是价格联动风险，发票如果引用当前单价，改产品价格会改写历史发票。最后改成每张发票自带价格副本，金额全部用整数分存。
这两个问题不点链接也猜得到结论。让我真正想推的是后面那个错误：各家咖啡馆的商品清单一事，最初是作者和 Claude 从一张样本发票里「某家出现饼干而别家没有」推出来的。这个猜测在访谈开始前就被当成既定结论带进去了，所以从头到尾没人向 E. 求证过。结果代码、测试、三份文档一致地忠实实现了这个错误计划。上线第二天作者按 E. 的实际操作方式手工走了一遍才发现：E. 其实只有一份通用菜单，任何咖啡馆都能点全部产品。
作者选择在截止前一周做完整修复——删掉按咖啡馆的商品表、改成共享菜单、同步改三处文档。没用几分钟的数据补丁把数字对上。这个决定我没有歧义，值得点开。
顺手跑了一下，准确说是我脑内走了一遍。他那个三方分工我也试过类似做法：Claude Code 负责写代码，另一个 Claude 会话写提示词和复查仓库，人只负责指挥、测试和决策。切片之间开新对话，上下文放 scope.md、prd.md、spec.md 和决策清单里。我自己的体验是这方法能保持文档干净，但太依赖文档本身诚实。
mattbusel 那句「检查者不能同时是建造者」我原先当成本文评论区说的，查了一下是上一篇文章里的，出处记错了。评论区作者自己的回复更实在：他是在按不同咖啡馆测试开票时发现各家商品不一致，才意识到流程假设有问题。跟原文说他从来没向 E. 求证对得上。
全文的时间线我过了一遍。10 月 17 日周六 16:30 从空文件夹开始，18:20 计划文档获批，18:48 首次提交，21:51 前切片 1 至 7 已部署；第二天 10:45 第 8 个切片通过测试，12:37 README 上线。约 20 小时、30 次提交，测试脚本驱动下完整流程跑 15.9 秒。这个速度不是重点，记一下就行。
不点链接也能带走的一句：访谈能提前发现时机、日期、价格这类「没问清楚」的问题，但发现不了「你想错了」的问题。想在开发前减少这种错误，得把假设单独列出来，别让它们和既定事实混在同一份简报里。