还在靠人工Review保证代码风格一致？试试这个新思路

做开发的都遇到过这种情况——团队有个"不成文的规矩"，大家都知道，但没人写下来，全靠口头传承。时间一长，新人来了不知道，老员工也可能忘。这种隐性的团队规范，最难管。

有意思的是，六十年前日本制造业就碰到过类似问题。

pokayoke是个什么思路？

日本制造先驱Shigeo Shingo当年发明了这个词，本意是"防呆"——让错误变得不可能发生，或者一发生就被抓出来。

比如插座，只有一个方向能插进去，你想插反都插不了。再比如生产线上的传感器，零件歪了直接停机，根本不给你把残次品装进去的机会。

这套思路放在软件开发上，就是让代码规范变成自动执行的检查，而不是靠人自觉遵守。

pokayoke.codes 就是干这个的，而且是为AI辅助开发量身定制的版本。

它和Lint有什么区别？

Lint工具大家都在用——ESLint 检查死代码，Prettier 统一格式，TypeScript 拦类型错误。这些工具确实好用，但有个共同盲区：捕获不了团队脑子里那些隐性知识。

比如说：

• 你们的API命名有固定套路，但没写成文档
• 某个目录下的代码必须用特定的包，不许乱引入
• 文件夹结构是团队约定，但代码层面没有任何约束

这些规则Lint管不了，但偏偏对代码一致性影响很大。pokayoke 就是填这个坑的。

核心亮点：它是给AI看的

这个工具真正有意思的地方在于，它是专门为AI代理设计的。

现在的Copilot、Cursor这类工具确实能写代码，但要让它们遵守你团队的规矩，基本靠手动prompt——加一堆规则说明，然后祈祷它别忘、别瞎编。

pokayoke 换了个思路：把团队规范做成AI能直接读取和执行的规则。用 pokayoke agent SKILL.md 就能让AI自动了解项目规范，不用你每次都唠叨。

而且规则本身就是给AI写的，不是单纯给人看的文档——这点很关键。

如果你在做 Vibe Coding，AI负责大部分编码工作，那这种工具就是刚需。

不抢你现有工具的饭碗

有人可能担心：又来一个新工具，会不会跟现有的 ESLint、Prettier、Husky 打架？

不会。文档里专门强调了，pokayoke 是补充关系，不是替代。

它不管格式问题（那是 Prettier 的活），也不管通用代码质量（ESLint 会处理）。它只专注一件事：你项目特有的那些约束。

说白了，它是架在你现有工具链上面的一层定制验证，专门检查只有你们团队自己知道的规则。

怎么上手

用起来很简单：

npx skills add rorz/pokayoke

然后定义你团队的规则就行。规则本身是自解释的——人类能看懂，AI也能理解。

说点远的

pokayoke 背后其实反映了一个更大的趋势：随着AI编码助手逐渐成为主要协作者，我们需要新型工具来传达意图，而不只是检查语法。

传统Lint管代码长什么样，静态分析管有没有bug。但未来真正缺的，是让AI能理解"我们团队觉得什么是对的"，并且老老实实遵守。

从这个角度看，pokayoke 可能是最早一批为这种工作方式设计的工具。

值得留意。