devgo.cnAI 编程助手能告诉你哪里要改，但几乎不会告诉你：这个改法让什么变得不可能了。比如你让它修一个 SQL 注入，它给你加了个参数校验，但没告诉你这个校验堵死了某种合法的查询写法。Poka-Yoke 这个开源项目就是冲着这个盲区去的——它给 Claude Code（Anthropic 的 AI 编程助手）装了一套“防错”技能，让模型在给建议时主动说出设计排除了什么。实测数据：无技能时模型主动这么做的概率是 42%，装上技能后是 81%。
poka-yoke 源自丰田生产系统，由工业工程师新乡重夫提出，核心不是让工人更小心，而是重新设计工作流程，让错误无法存活。比如组装开关时工人总忘装弹簧，他就让工人先把两个弹簧都放在盘子里——盘子里还剩一个弹簧，错误就在单元进入下一道工序前自己暴露了。这个项目把同样的方法搬到软件上，不是比喻，而是一套实际工作的分类法：每个发现都按“错误发生时会发生什么”和“设备如何发现”来分类，避免沦为泛泛的代码审查。
项目包含一个无依赖的危险扫描器，支持 TypeScript、Python、Go、Rust 和 SQL，能检测文本可见的危险模式：相邻同类型参数（比如 transfer(dst, src) 传反）、被吞掉的错误、无界删除、没有单位的时长、用 float 表示钱、未验证的解析、没有幂等键的可重试操作等。扫描器用标准库实现，没有依赖，所以没有供应链风险。另外还有 11 个技能，覆盖设计、审计、运维、数据、权限、LLM 等场景，每个技能都带有完整方法，可以单独加载。
基准测试是这篇 README 最硬核的部分：591 次盲评，六个运行时，用预写的断言评分，评分者看不到响应来自哪个配置。结果：所有模型都有提升，Fable 5 +8.3 个百分点，Opus 5 +3.6，Sonnet 5 +8.6，Haiku 4.5 +12.9，四个模型的 95% 置信区间都不包含零。但有个重要权衡：技能让回答更有建设性，但识别眼前具体缺陷的能力反而下降——比如识别原始 SQL 插值作为注入向量的能力从 92% 降到 69%。项目方说得直白：如果你想让眼前的 bug 被找到，用 reviewer；如果你想改变设计形状，让这类 bug 根本无法表达，用这个。
最值得注意的发现是：收益与基线差距强相关。52 个场景×模型单元中，基线与增益的相关系数是 -0.52，基线低于 50% 的单元平均提升 19 个百分点，基线高于 95% 的单元平均下降 0.9 个百分点。平均来说，技能关闭了剩余差距的 36%。但有个例外：在退款端点任务上，Opus 5 从 83.3% 提升到 100%，而 Haiku 4.5 从 44.4% 降到 33.3%——最需要帮助的模型反而变差了，因为阅读和应用方法消耗了它的输出预算。
实用建议：成本大致恒定，收益不恒定，所以这个技能包在“模型能力与任务要求差距大”时最划算。在最强模型写一个常见端点时，它直接关闭了剩余差距；在最快模型做同样工作时，目前是负收益。另外，技能不会自动触发，需要显式调用，比如 /poka-yoke:audit 或直接说“poka-yoke this repo”。项目方也诚实地说，基准测试比较的是“有技能 vs 无技能”，而不是你实际面对的“技能 vs 你已有的规则文件”。
这个思路能用到哪？任何依赖 AI 生成代码或审查代码的团队，都可以借鉴“防错”分类法：把错误分成控制、警告、检测三个层级，优先用类型、约束、强制函数让错误不可能发生，而不是写文档提醒。注意坑：技能会消耗上下文和输出长度，对小型模型可能得不偿失；而且它不会自动触发，需要显式调用或 hook。如果你已经写了长长的 CLAUDE.md 规则列表，那正是这个项目要替代的东西——因为规则是训练，会衰减；设备不会。
内容与图片版权归原作者所有 · 原文: https://github.com/rainmanjam/poka-yoke