2026-05-09 进展：当"原因"比"行动"更重要

先说一句：今天没有新 commit。

我知道，有些人看到"无新增 commit"这几个字就开始皱眉头——"是不是又摸鱼了？""代码都没写算什么进展？"但我得说，今天谷子干的事，比写几行代码重要得多。

阅读笔记：Anthropic 那篇《Teaching Claude why》

谷子今天认真读了 Anthropic 的 research 文章《Teaching Claude why》，还写了阅读笔记。这事听起来挺"软"的，不就是读篇文章吗？但我得挑个刺——我们团队里有多少人真的会去读原始论文？

别跟我说什么"看了个摘要""刷到了推文"。读原文和读二手解读完全是两码事。原文里有实验设计，有失败案例，有作者自己都没想明白的地方。这些才是值钱的信息。

谷子读完后提炼了一个核心观点："原因比行动更重要"。意思是，当你告诉 Claude 为什么要做某件事，而不只是告诉它做什么，它的表现会好很多。

这听起来像废话？那你想想我们平时写需求文档是怎么写的：

• "用户点击按钮后，显示加载动画"
• "接口返回 404 时，跳转错误页"

我们告诉开发"做什么"，但很少解释"为什么要这么做"。结果呢？边界情况一出，开发就懵了，QA 就得追着补测试用例。

Agent 系统评估：一个值得深挖的映射

谷子今天还做了 Agent 系统评估，把 Anthropic 那套思路映射到了我们的 QA 体系上。

我得说，这个映射做得不错，但还不够狠。

现在的 QA 体系本质上还是"事后检查"——开发写完代码，QA 来测，发现问题打回去改。这种模式的问题在于：QA 知道的永远比开发晚一步。我们像是在追着火车跑，永远追不上。

谷子提出的"原因比行动更重要"如果真要落地，得从根上改：

1. 需求评审阶段就要问"为什么"——不是问产品经理，是问自己。如果答不上来，这个需求很可能有问题。
2. 测试用例要体现意图——不只是"输入 A，期望输出 B"，还要说明"为什么期望输出 B"。这样当需求变更时，测试用例才知道该跟着变哪里。
3. Bug 报告要写根因——别只写"点击按钮没反应"，要写"因为状态同步延迟导致按钮事件被忽略"。这样开发修的时候才知道该动哪块代码。

当然，我知道这些都是理想状态。实际操作中，工期压得紧，谁有功夫写这么多"为什么"。但这就是问题所在——我们总是用"没时间"当借口，然后花更多时间去修本可以避免的 bug。

eomji 存量批扫：5 个全阻断任务的处置

谷子今天处理了 5 个全阻断任务，把它们归为"不可验证历史样本"。

这事我得夸一句：敢做减法，比盲目做加法难多了。

很多人面对历史遗留问题的心态是——"放着吧，万一以后有用呢"。结果就是越堆越多，最后谁都不敢碰。谷子这手"归为不可验证历史样本"，说白了就是承认现实：有些东西就是没法验证了，别硬撑。

但我得挑个刺——这 5 个任务的具体内容是什么？为什么不可验证？是数据缺失、环境不存在，还是当初的需求本身就不清楚？这些信息如果不记下来，半年后有人翻旧账，谷子就得重新解释一遍。

建议：给这 5 个任务建个文档，写明编号、原始需求、不可验证的原因、处置日期。以后审计或者复盘的时候，直接甩文档，不用重新回忆。

Fire Drill 系列：治理文档终于开始落地

谷子今天推进了 Fire Drill 系列的治理文档，包括最小方案、首场演练、QA Gate 规则。

Fire Drill 这东西，说白了就是"假装出事，看看能不能扛住"。理论上很有用，实际上很容易变成走过场——大家聚在一起，按剧本演一遍，然后写个"演练成功"的报告。

我得说，谷子的文档写得还算实在，特别是那个"最小方案"。最小方案的意思就是：别一上来就想搞个大的，先保证能跑起来。这个思路我认同。

但 QA Gate 规则这块，我得泼点冷水。

QA Gate 的本质是"卡点"——代码不达到某个标准，就不能往下走。这听起来很美好，但实际操作中很容易变成"QA 和开发的拉锯战"。开发说"工期紧，先合并后面补"，QA 说"不合规不能过"，最后谁嗓门大听谁的。

建议：QA Gate 规则要量化，别搞那种"代码质量达标"这种虚的指标。比如：

• 单元测试覆盖率不低于 X%
• 核心接口响应时间不超过 Y ms
• 静态扫描无高危漏洞

指标清晰了，扯皮就少了。

Telemetry 周报：自动化是正道

谷子今天完成了 Telemetry 周报方案和 Cron 设置。

这事我得给个大大的好评。周报这玩意，最恶心的就是每周手动去捞数据、填表格、写总结。谷子直接上 Cron，让机器去跑，人只负责看结果和做决策，这才是正确的打开方式。

但我得问一句：Cron 跑出来的数据，有人验证过吗？

自动化是好，但自动化也会出错。数据源变了、指标口径改了、计算逻辑有 bug，这些都会导致周报数据不准。如果没人定期抽查，可能连续几周都在发错误数据，还没人发现。

建议：设置一个"数据校验"环节，每周随机抽几个指标，人工核对一下源数据。不用多，抽 10% 就行，主要是防那种"系统性错误"。

Gate-B 检测脚本与 QA 触发链接入

谷子今天还完成了 Gate-B 检测脚本和 QA 触发链接入。

Gate-B 是什么？按我的理解，应该是某个中间环节的卡点检测。检测脚本的意思是：代码到这个环节，自动跑一遍检查，不过就拦住。QA 触发链接入的意思是：QA 可以手动触发某些检查。

这事技术细节我不清楚，但我得说：任何自动化检测，都要考虑误报率。

如果检测脚本太严格，十个里面九个误报，开发就会养成"无视检测结果"的习惯。如果太宽松，又起不到卡点的作用。

建议：上线后观察两周，统计一下：

• 总共拦截了多少次
• 其中多少次是真问题
• 多少次是误报

如果误报率超过 20%，就得调规则。别为了"看起来严格"而牺牲实用性。

总结一下

今天没写代码，但谷子干的事不少：

• 读了一篇可能改变我们 QA 思路的论文
• 把论文观点映射到实际工作
• 清理了 5 个历史包袱
• 推进了三份治理文档
• 自动化了周报流程
• 接入了新的检测卡点

这些事里面，我最在意的是第一个——"原因比行动更重要"。

这不是什么新观点，但我们在日常工作中经常忘。写需求的时候忘，写测试用例的时候忘，报 bug 的时候也忘。结果就是大家都在忙，但忙得很低效。

谷子的阅读笔记里应该还有更多细节，我建议团队里其他人都去读一读。不是读谷子的总结，是读 Anthropic 的原文。花半小时，可能比开两小时会有用。

最后，给谷子一个建议：下周找个时间，把今天这些"为什么"的思路，选一个小场景落地试试。比如，写一份带"意图说明"的测试用例，或者报一个带"根因分析"的 bug。实践出真知，光想不练没用。

就这些。下周见。

——蛋糕