dantotsu

Dantotsu——缺陷分析

一种将单个缺陷转化为永久性质量改进的结构化方法。由前丰田工程师野村真澄提出，他曾用此方法将制造缺陷减少多达 98%。该方法经过改编，适用于软件领域；一个完全按此方法运行的小型项目，每 1,000 行代码约有 0.3 个缺陷——比行业平均水平低一到两个数量级，同时无需承担航空航天级流程所需的巨大前期规格编写工作。

缺陷 = 用户遇到的任何非预期行为；即实际发生的行为与预期行为之间的差距。

有两项原则直接沿用自制造业原版，其重要性胜过任何特定模板：

• 按缺陷在哪个环节漏出分类，而不是按严重程度分类。 按严重程度分流，旨在优化“先修复什么”；按阶段分类，旨在优化“流程的哪个部分存在漏洞”——这才是真正推动系统性改进的因素。
• 同时分析缺陷的发生和流出。 缺陷为何发生（预防），以及为何未能更早发现（检测），应分开分析。将两者混为一谈会丢失检测缺口的信号，而解决这类问题通常需要改进流程或工具，而不是修改代码。
• 依据事实验证假设，而不是凭感觉判断其是否合理。 连环追问中最大的风险并非缺乏专业知识，而是用“感觉自己已经理解”（"avoir compris"）取代真正理解（"comprendre"）。领域经验越丰富，这种情况反而越严重：有经验的读者会过快接受听起来合理的原因，恰恰因为它符合以往经验。在继续追问下一个“为什么”之前，应先根据可验证的信息（差异、日志、工单历史）核实推理链中的每个环节。

检测阶段

如果不确定缺陷是在哪个阶段被发现的，应询问用户——绝不要猜测。

阶段	发现缺陷的位置
A	本地环境（开发人员自己的计算机）
B	团队层面（CI 或代码审查）
C	验证环境（产品负责人发现问题）
D	Qualif/预发布环境（QA 发现问题）
E	生产环境（团队成员发现问题）
F	客户端（客户报告问题）

较晚的阶段（E、F）成本更高，也表明流程缺口比早期阶段（A、B）更大。

对于反复出现或跨团队的缺陷，应绘制行为或数据经过的路径，记录发现缺陷的位置，并按阶段直观呈现缺陷是否再次发生。根据当前基准设定可衡量的改进目标。这是将野村关于绘制质量信息流、按发现环节对缺陷分类，以及为软件团队可视化质量数据的指导加以改编（The Toyota Way of Dantotsu Radical Quality Improvement，预览版，第 1 章）。

工作流

首先检查缺陷是否正在造成持续损害。在进行下述分析之前，应在用户授权范围内优先采取遏制措施（热修复、回滚或临时解决方案）；不要为了完成分类或连环追问而延迟处理。将已采取的遏制措施与建议采取的措施分开记录。

然后按顺序完成以下分析步骤。在得出根因结论之前，先明确缺陷及其检测阶段。

1. 描述缺陷。 将缺陷表述为预期行为与实际行为的对比。如果用户提供的信息不足以准确描述，请提问，不要假设或虚构细节。
2. 确定检测阶段（上文 A–F）。如果未说明，请向用户询问。
3. 检查是否复发。 询问用户（或在有权限时查看可用的问题跟踪系统／历史记录），确认是否曾发生过相同缺陷，或根本模式相同的缺陷。复发缺陷意味着存在更深层的系统性根因，因此根除缺陷比一次性修复更重要。
4. 用 5 个为什么分析根因（发生原因）。 从第 1 步的缺陷描述开始，而不是从症状或猜测开始；反复追问“为什么”，每次都把上一个答案作为新的解释对象。直到答案指出具体可采取行动的问题（流程缺口、缺少检查、错误假设等），而不只是重复描述症状。通常追问 5 次，但次数并非硬性规定。
   • 如果追问链指向某个特定人员做出的决定（设计选择、遗漏检查、误解需求），且无法确认其考虑依据——例如作者无法联系，或没有保留对话历史／决策记录——就应将这一环视为未经确认的假设，而非结论。在输出中明确说明这一点，不要将其当作事实纳入追问链；如果可以联系作者，应在定稿前请其确认或更正。
   • 例外——源于迁移的缺陷： 将现有行为移植或重构时，根因往往在于待迁移的输入（原始来源），而非未记录的人为决策。此时，即使无法联系作者或没有对话历史，通常也能通过与原始来源比对来高置信度地追溯根因。
   • 追问链不只针对代码：相关时，也应检查底层需求说明或大型需求项的编写情况（验收标准含糊、未规定某个边缘情况等），将其作为潜在根因，而不只是检查实现代码。
5. 检查为何未能更早发现（流出原因）。 将实际检测阶段与最早可能发现缺陷的阶段进行比较。单独进行一轮简短的“为什么”分析，与第 4 步分开；漏检的根因通常是流程或工具缺口（缺少测试、没有 lint 规则、审查清单中缺少检查项），而不一定与缺陷本身的根因相同。
6. 提炼一条经验分享。 提出修复方案之前，先简短总结第 4–5 步发现的误解或缺口，写成便于分享的内容（PR／Jira 评论、Slack 消息、一页幻灯片），让未参与此事的同事能在一分钟内理解。根因如果只存在于某个人的脑海中，就无法防止下次再发生；真正传播经验的正是这一步。
7. 记录纠正措施。 记录已采取的遏制措施，并提出尚需完成的即时修复。区分已完成的行动、观察到的结果和建议措施；遏制措施不一定能防止复发。
8. 设计根除措施。 措施应比纠正措施更进一步：什么永久性改变（流程、工具、自动化检查、文档、培训）能从结构上杜绝整类缺陷再次发生——包括再次发生后直到较晚阶段才被发现的情况。优先采用微型防护措施：小型、自动化且可撤销的检查（单行 lint 规则、单个新增测试、通过 PR 模板链接的一段文档），而非大型重构。能实际落地的小型防护措施，胜过迟迟无法完成或会引入自身缺陷的全面修复。若某项措施只针对这一次问题，不要将其称为根除措施。
9. 分别验证预防效果并监控复发。 使用复现用例或回归检查，证明防护措施能够检测或预防原始缺陷；记录结果和所覆盖的场景。未经测试的措施应标记为“建议中”或“未经验证”。记录复发监控的时间范围，以及期间的工作量或复发机会；一段时间内没有发生问题只是观察结果，并不能证明缺陷已被根除。对于持续跟踪，明确负责人和审查时间点。

确定根除措施的优先级（可选，适用于定期开展的团队实践）

如果有多个备选根除措施需要分级排序，例如在定期团队会议上讨论，而不是当场决定，请为每个候选措施评分，并优先考虑自动化、风险低且范围局限于该缺陷领域的措施，而不是会影响无关服务的措施：

标准	检查内容
影响	它能否避免此类缺陷及类似缺陷再次出现？
复杂度 / 风险	它是否可能引入新 Bug 或导致无关代码不稳定？
工作量	每位开发者需要投入多少工作？
验证时间	能否自动快速验证，还是需要手动检查（较慢）？

每个周期只选少量得分最高、风险较低的措施，而不要一次性尝试所有候选措施——一次安排太多会导致救火式处理或大规模重构带来的不稳定，而这正是该方法旨在避免的。

团队节奏（可选，参考实践）

对于持续开展这项工作而非只做一次的团队，此调整方案采用以下做法：

• 每天分析一个 Bug 修复，由技术负责人负责：审查差异、记录根本原因，并检查代码库中是否存在类似的潜在缺陷。
• 每天进行一次简短同步（10–15 分钟，“Bug 修复分析咖啡会”），由团队共同提出应对措施——新增 lint 规则、补充边缘情况测试夹具，或开展小规模的修复驱动重构。将其定位为协作互助，而非命令下达：态度应是“我们一起来看看流程中哪些地方没有按预期进行，并共同找出应对措施”，而不是“不要做 X，改做 Y”。重点是引导大家发现自身疏漏，而不是追究责任。
• 在缺陷出现后的 24 小时内响应，以便趁着上下文还清晰时开展分析。

仅当用户要建立持续的团队实践时，才建议采用这种节奏，不要用于单个缺陷的复盘。

减少 A 类缺陷：“一次做对”（可选技巧）

若要专门减少在编码期间发现的 A 阶段缺陷，可以设置以下约束：每项功能只允许开发者进行一次手动测试 / 刷新尝试；如果第一次尝试失败，就将其视为 A 类缺陷。这会促使开发者提前设计并采用 TDD（通过快速运行终端测试来检查正确性，而不是反复手动点击）；而且，首次尝试就成功完成某项功能的团队可以公开表扬（例如通过 Slack 机器人点名表扬）。仅将此作为针对 A 类缺陷的专项技巧，不要将其作为适用于其他阶段的一般性根除措施。

注意事项

• AI Agent 可以可靠地追溯缺陷是从代码中的_何处_引入的，但无法知道某个人_为何_选择这样编写代码。如果作者无法确认，或没有保留决策记录／对话历史可供核对，那么这部分因果链就只是一个假设，无论表述得多么确定，都绝不能将其说成已确定的根本原因。这是一个硬性限制，而不是可以通过调整提示词来绕过的问题。
• 如果第 4 步或第 5 步发现，由于当时没有人记录理由，因而无法还原「为什么」，这本身就是一项发现：缺少决策记录是有效的根除措施候选项（要求今后对此类决策提供简短的书面理由），且应与解决当前缺陷的代码修复分开。
• 临时措施与根除措施不能混为一谈：临时措施解决本次问题；根除措施则防止同类缺陷再次发生。将两者放在不同的章节中，不要把临时措施伪装成根除措施。
• 5 Why 分析链必须从第 1 步中写明的缺陷描述开始，而不是从用户顺带提及的、更模糊的症状开始。
• 「为什么会发生」（第 4 步）和「为什么没有被发现」（第 5 步）是两个独立的深挖问题，不要将它们合并成一条分析链。
• 如果用户不确定缺陷发生在哪个阶段，或不确定缺陷描述是什么，请直接提问，而不是自行选择最可能的选项。
• 根除不等于「大规模重构」。优先选择能够弥补漏洞的最小自动化检查；规模过大的修复更可能被降低优先级，或引入自身缺陷。
• 按阶段分类，而不是按严重程度分类——不要重新引入低／中／高等级，因为这会使分析偏离真正要解决的问题。
• 最终报告应使用用户描述缺陷时所用的语言。
• 留意两种都会伪装成严谨的失误模式：「魔法思维」——认定必定存在一个能解释一切的单一根本原因，因此一旦出现_某个_看似合理的答案，分析链就此停止；以及**「因果关系泛化」**——将所有事情都视为彼此相关，并借此为几乎任何拟议行动辩护。两者都会跳过实际验证步骤；真正的 5 Why 分析链应保持聚焦，并持续用证据核对每个环节。

输出模板

对于单个缺陷分析，请使用 _template.md 中的结构化模板。该模板定义了完整的文档结构，包括元数据表、问题陈述、因果链、根本原因分析、检测失败原因、临时措施和根除措施，并在各章节中附有行内指导注释。

仅纳入有证据支持的原因。将未经确认的解释标记为假设，将缺失的信息标记为未知；不适用的小节应省略，不要为了填充内容而臆造错误认识或检测失败。

在「因果链」和「发生的根本原因」章节中，填写缺陷描述、复发检查、完整的 5 Why 分析链，以及「为什么未能更早发现」的分析（后者应放在「检测失败原因」中）。严格区分「临时措施」和「根除措施」。

如果用户还希望在文档中记录学习分享内容或优先级评分，请添加可选的 ## Learning to share 和 ## Prioritization 章节；默认不要添加，仅在用户提出要求或明确针对团队／重复发生的问题进行处理时添加。

如果用户希望将内容保存为文件，而不是直接展示，请将其写入 Markdown（.md）文件。

---

基准测试

场景：.benchmarks/scenarios/dantotsu-001-escape-stage.md · 运行：2026-08-31 · 日志：.benchmarks/runs/2026-08-31/dantotsu-001-escape-stage.json

模型	无工具	有工具	变化
claude-opus-4-8	67%	100%	+33%
claude-sonnet-4-6	83%	100%	+17%
claude-haiku-4-5	83%	100%	+17%

通过（运行于 2026-08-31）。提升幅度较小且一致；基线模型在没有辅助的情况下，已部分应用“优先进行阶段分类”规则。门槛见 .agents/skills/skill-optimizer/rules/release-gates.md。