装过 Claude Code 这类编码助手的人，多半都干过同一件事：往里面塞一堆”技能”，指望它按你的规矩干活。可你很少知道这些技能到底在哪些工具上真的被跑过。
今天要评的 pstack-claude 正面回答了这个问题，答案是它自己写的：它一口气支持 13 个运行环境——Claude Code、Codex、Copilot、Pi、Muse 等等——但官方文档里，7 个环境自己标着”没验证”。它的持续集成（也就是每次改代码自动跑的那套检查）里，13 个环境只真正装过 1 个。
这个项目 4,179 星、MIT 许可，11 月 9 日当天还在提交代码。我把整个仓库拉下来，按它自己文档写的步骤装依赖、跑测试，2154 个测试全绿、0 失败。这一篇讲的不是”它好不好用”，而是它把哪些事验证了、哪些事只是写在了文档里。
它到底是什么
一句话：把一套给 AI 编码助手用的”操作手册”，翻译成 13 个不同工具都能读的格式。
原作者 Lauren Tan 在 Cursor 里写了一套技能（skill）。你可以把技能理解成一份份写好的工作流程，比如”改代码前先读哪些文件””提交前必须跑什么检查”。pstack-claude 把这一套搬到了别的工具上，还为每套工具各写一份翻译说明，告诉 AI 在这个工具里对应的按钮和模型叫什么。
它的体量：
| 部分 | 数量 | 说明 |
|---|---|---|
| 技能 | 67 个目录，3,076 行 | 其中 43 个是可用流程，24 个是一条条的”原则” |
| 参考文档 | 168 个文件，7,137 行 | 翻译说明、模型对照表 |
| 测试 | 46 个文件，9,775 行 | 比技能正文本身多 37% |
| 全仓 | 782 个文件 | 版本号 0.9.133 |
它对上游的态度也值得说一句：仓库里有一份清单，记着上游的三个来源各固定在哪个代码版本；还有一份 65 条的分叉登记表，每条都写了为什么改、从哪个版本开始改、有没有提给上游。这套记账方式，比大多数魔改版项目认真得多。
实测：我自己跑了一遍，也自己数了一遍
第一条证据，测试是真的能跑通的。我按它贡献指南里写的四步做完（装根依赖、装插件依赖、跑生成器、跑测试），结果是 2154 个测试通过、174 个跳过、0 失败，耗时 52 秒。
这里有个坑值得先说：我第一次只装了根依赖就跑，20 个测试挂了。原因不是项目坏了。它有个测试专门检查”在根目录裸跑测试，加载的文件必须和 CI 跑的一致”，而缺了插件目录那份依赖，两次加载的文件数就对不上。补上那一步，全绿。这个设计其实挺聪明：它把”你少装了一步”变成了一个会失败的测试。
第二条证据，13 个运行环境，证据密度差得很远。这是全篇的核心。我把它文档里对每个环境的说法逐条抄出来分类：
| 证据强度 | 运行环境 | 具体是什么 |
|---|---|---|
| 真装 CLI、进 CI | Pi | 唯一一个 CI 里真的装了它的包（固定在 1.1.0）并跑检查 |
| 人工冒烟（不在 CI） | Copilot、MiniMax、Grok | 有专门的冒烟脚本，但 CI 从不跑 |
| 合成环境验证 | OMP、Kimi、OpenCode 2 | 用一个假的模型服务验证”文件递到了”，真模型行为没测 |
| 文档自认未验证 | Antigravity、Prime Agent、Gemini CLI | 只写了安装路径，没写验证结果 |
| 纯描述安装方式 | Codex、Muse、Claude Code | 文档只给安装命令，没有验证结论 |
这个数字意味着什么：一个口号是”支持 13 个环境”的项目，实际被自动化验证过的只有 1 个。这不是虚假宣传，文档老实到了极点，甚至主动写”CI 不跑它””真模型行为仍未测试”。但它说明一件事：跨环境适配的成本，远远高于写一份翻译文档的成本。
第三条证据，三个冒烟脚本合计 611 行，CI 里 0 个在跑。其中 Copilot 那个 471 行，脚本开头就写明要验证 7 件事，包括钩子只触发一次、关掉开关后确实不触发，以及”一次要花掉大约 20 次高级请求额度”。这句话也解释了它为什么不在 CI 跑，它要真钱。文档里那句”CI 不跑它”，是诚实，也是缺口。
另一面：它的工程质量确实高于平均
挑完毛病，得说公道话。
它的生成器设计是我近期见过最讲究的之一：版本号、模型清单、各种清单表，全都从单一来源自动写入所有副本，CI 会检查提交上去的副本有没有过期。它还专门写了测试，去核对 README 里写的那几个数字（67 个技能、43 个公开技能、24 条原则）是不是和目录实际数量一致。换句话说，它连文档里的数字都当成会被自动化检查的契约。
它还有一条测试专门抓”技能之间互相点名、但点到的目录不存在”这类断链。这类问题在纯文档项目里几乎没人管，因为编译器看不见。
局限也很明确：技能本身是写给 AI 读的指令，好不好用取决于你用的那个模型听不听话。它把 13 个环境的翻译做得很细，但翻译对了和模型照着做了是两件事，而后者目前只有 Pi 有自动化证据。
放进坐标系里看
站内评过的几篇可以对照着看：deepagents 走的是给 Agent 搭框架，判断标准是测试条数和依赖清单能不能照装；SkillOpt 走的是把技能文档当成可训练参数，亮点是把覆盖率算成了具体数字。pstack-claude 的独特之处在于，它是分发层：把同一套方法翻译到十几个工具上，并老老实实标注每个工具被验证到了哪一步。
适合谁：同时用两三个编码助手、希望行为一致的团队；想给自己团队的提示词立规矩、又不想为每个工具重写一遍的人。
不适合谁：只用单一工具的个人，收益很小；以及需要承诺级稳定的场景。如果你的工作流依赖某个环境百分之百按预期工作，先去看它文档里那个环境是不是还标着未验证。
我的判断
值得放进观察清单，并且它的文档诚实度值得单独表扬。但要清楚它在卖什么：它卖的是翻译，不是保证。13 个环境里真正被自动化验证的只有 1 个，剩下的是用人工、合成环境或纯文档兜着，而它自己把这一点写在了明处。
如果你打算用它，建议先翻它的运行环境对照表，确认你用的那个环境落在哪一档证据上，再决定要不要把关键流程交给它。
关注 AI商业快讯，每天一篇 AI 热点深度解读。想先看同类工程质量的，可以翻我们评过的 deepagents 和 SkillOpt。