用途：把“防错”这一丰田生产方式里的理念落到软件与流程设计上。核心判断是：注释、文档、评审清单、CLAUDE.md 里写“不要做 X”都不是 poka-yoke，而是培训，会退化；装置不会。当用户说“poka-yoke this”“mistake-proof it”“让无效状态不可表示”“别再犯第三次”，或在设计接口、schema、状态机、审计代码隐患、事故复盘时使用。
两条轴。第一轴调控功能：控制（错误不可能发生，如类型不通过编译、NOT NULL/CHECK/唯一约束、必备参数、私有构造、PreToolUse 钩子拒绝、保护分支）优于警告（错误可发生但当场宣告，如编辑器 lint、CI 门禁、运行时断言、点名具体对象的确认框）优于检测（事后发现，如测试、监控、对账），而依赖人记住的文档属第 0 级，不算装置。第二轴设置功能：接触（形状不对就装不上，对应区分类型、branded ID、边界解析、单位类型、可辨识联合）、定值（计数确认，对应穷尽 match、必备字段、迁移已应用检查、行数守卫、校验和、启动时整体校验配置）、动步（确认上一步完成，对应 typestate、builder、状态机、幂等键、RAII/defer、事务）。
在源头检查优先于自检，自检优先于互检；尽量把装置推到最上游。用法：先界定谁对什么动作，再用三镜头扫描，把每个隐患写成“可能犯的错、后果、是否静默、现有防护”，最后提出负担得起的最高级装置并说明级别。若不指明对象，就看当前 diff 或讨论文件并先说明选择；确实没有就询问。改变接口前先提议再改，获批后实施；若明确要求写新代码则直接构建并说明设计掉了哪些隐患。措辞上只谈代码的供给性，不指责人。
限制：只能减少可预期的误用，无法证明设计正确，也覆盖不了未识别的隐患；最强控制可能受语言、平台或兼容性限制而不可用，此时须说明取舍并保留测试、监控与恢复路径；防护本身也可能错误或过宽，需对照真实调用方验证。该方法不替代领域评审、安全评审、测试、可观测性与事故响应。