将丰田精益生产体系移植到Claude Code的开源工具Andon发布

我在制造业工作了15年，最终负责生产运营。我学到的关于系统改进的大部分知识来自精益生产和六西格玛的应用（可能更接近Paul Akers而非丰田）。

现在，我几乎完全通过Claude Code运营一家公司，并且不断发现大量旧的制造业思维仍然适用。

安灯（Andon）源于一次具体的失败。

一个代理发现了一个bug并在五个地方修复了它。它告诉我问题已修复。

但事实并非如此。

还有九个实例存在于代理未打开的文件中。

我尝试改进提示词，但那并不是真正的问题。

在制造业中，如果同样的缺陷可能反复发生，你不会一直提醒操作员要更小心。
你会改变流程。

所以我开始对代理采取同样的做法。

每一次有意义的失败都会被记录、理解，并转化为某种对策，使系统更不容易再次犯同样的错误。

我从该系统中剥离了私人内容，并将可复用的部分放入一个名为Andon的仓库中，以丰田生产线上的拉绳命名。

可能最有用的部分是停止钩子（Stop hook）。

当代理说“完成”、“已发布”或“已验证”之类的话时，钩子会检查是否有新鲜的验证证据。如果没有，会话不会只是安静地结束。它会以警告模式启动，一旦你信任它，可以将其提升为阻止模式。

你可以直接从仓库运行示例。无需安装。README中包含命令以及你应该看到的输出。

其余部分是模块化的。如果只需要基本记忆文件，有一个简单的记忆文件；还有指令和错误日志、钩子，以及用于运行并行代理会话的更大设置。

这是刻意设计的无聊基础设施：Markdown、两个仅使用标准库的Python钩子，以及一个小型日志辅助工具。无依赖。

如果记忆是你唯一想解决的问题，请使用claude-reflect或claude-mem。它们是不错的工具。

Andon针对的是另一个问题：如何让代理系统从已经失败的方式中进行操作性学习？

这是一个老问题。制造业花了几十年时间研究如何防止缺陷复发。我正在尝试看看有多少知识可以转移到代理上。

MIT许可且免费：
github.com/PrimeFoldTools/andon

仓库中还有一个缺陷台账。如果代理以有趣的方式让你受损，请发送失败案例：缺陷 → 根本原因 → 对策 → 结果。

这些是我最希望收到的PR。

―― 高票评论(帖子共 49 条讨论)――

[+84] u/dmcnaughton1: https://preview.redd.it/jysjef4j2boh1.png?width=500&format=png&auto=webp&s=7278b97c144021d9e01ba5185b61a69e74a2f342

[+38] u/AdBest7581: 嘿，这个想法非常好。我认为这是将质量工程的概念应用于AI。在这里，你使用了CAPA的概念，并应用一个证伪器来评估纠正措施的有效性。
在我看来，优先考虑可执行的证伪器比让AI阅读自己的代码并告诉你没问题更好，就像要求工艺工程师提供纠正措施有效性的证据而不是相信他们的话一样。

顺便说一句，一个干净且结构化的bug、需求和架构决策记录日志，也可以帮助你确保项目一方的纠正措施不会破坏另一部分（特别是如果纠正措施落在许多进程共享的低层函数上）。

恭喜你的项目。听起来非常棒！

[+9] u/apost8n8: 我希望的是Claude能自动做到这一点？似乎让提示词花一秒钟来确定如何最准确高效地回答并不疯狂。我猜我们很快就会达到那个阶段，这种管理系统很快就会自动化，但目前这些东西确实有影响：

[+1] u/btc6000: 我做了类似的事情，使用RAID加变更日志。另外我有一个原则：如果Claude犯同样的错误/治理失败三次，我们就通过编程强制执行。

[+1] u/acedelaf: 谢谢，我会试试

[+1] u/amirfish: 干得好，把它变成了一个流程而不是提示词调整。你描述的失败模式——代理说已修复，但实际上没有——是我在并行运行这些会话时经常看到的：对策存在于学习到它的对话中，而不是下一个会话能看到的地方。Andon的日志会被在不同工作树中生成的新会话读取吗，还是停止钩子只在遇到bug的同一线程内强制执行？

[+1] u/TwistHonest6379: 好的，我对精益生产和六西格玛有一些经验。查看仓库后，我无法确定它到底是精益还是六西格玛？在我看来，它更像是精益而非六西格玛。而且它是DMAIC还是DMADV？顺便说一句，我非常欣赏这种跳出框框的思考。👏

[+1] u/ianreboot: 我有一个钩子检查相同的证据。我抓到过代理将验证视为已从其自身状态运行过，然后关闭而从未打开更改过的文件。钩子现在自己运行grep或测试，所以通过的是实际运行的检查。

[+1] u/xia03: Claude的推理是有缺陷的。它经常找到根本原因，写一个糟糕的单元测试，让它通过并宣布胜利。但它很容易搞错根本原因。试图修复这个问题就像告诉一个无法逻辑思考的人要逻辑思考。我有点怀疑给它方法论是否能可靠地工作。

[+1] u/jesssoul: 除非你是在字面上编写一个新的Claude，否则这最多只能在一个会话中坚持，然后在后续会话中令人恼火地退化，无论你做多少次，永远不会像第一次那样好。

[+1] u/TryCool2339: 感谢你发表了如此有实质内容和有趣的帖子！这个子版块充斥着只想抱怨Opus 5声音的人，以及不理解始终连接连接器的token影响的人。

感谢你为社区贡献了这样一个强大的复利想法。我不知道如何实现它，但我期待弄清楚。

[+1] u/victorc25: 我已经使用类似的东西大约一年了。我看到了一个问题，你的缺陷层无法扩展。在达到一定数量的问题后，它将变得不可读，Claude将开始只通过Python PTC追加，所以它将停止正常工作。