用 Open Steps 技能包让智能体用大白话汇报进度

Open Steps 的作者 Pavlo Kharmanskyi 是一位产品侧的建造者：二十年做产品，公司里有 50 多名开发者。他做这个技能包，是因为撞上了一堵具体的墙——智能体活干得不错，然后用提交哈希和术语向他汇报，一个不读代码的人真的判断不出活做完了没有。Open Steps 就是他的解法：八个 skill，在关键时刻改变智能体对你说的话，并在过去一句「做完了」就算过关的地方要求证据。

为什么这个 Skill 重要

八个 skill 首尾相接成一个循环。os-whats-next 挑下一项任务，os-step-by-step 给不懂技术的人写分步说明，os-done-or-not 汇报结果，os-check-work 不轻信另一个会话的汇报、把每条说法重新核实，os-ask-simple 把提问翻译成大白话并附上代价和一个标明的建议，os-what-could-go-wrong 让一个没参与决策的新智能体对难以回头的事做事前推演，os-say-simple 改写任何术语味道的文字，os-big-picture 维护一份常驻的 BIG-PICTURE.md，记录每个功能做到哪一步。

两个设计决定让这些汇报值得信任。实测与假设分开——每个「是」都要给出依据，没查到的就写「未检查」。大白话规则借鉴自 ASD-STE100，那份为航空手册写的简化英语——README 特意用词是「借鉴」，这里没有任何东西经过该标准认证。

安装

先克隆仓库；技能包需要 git，gh（可选）能解锁 pull request 检查：

git clone https://github.com/kharmanskyi/open-steps.git

在 Claude Code 上，一条命令装好插件并接好两个钩子：

claude plugin marketplace add ./open-steps && claude plugin install open-steps@open-steps

然后把路由规则段——一张写明每个 skill 必须在什么时刻触发的短表——加进你的常驻指令：

grep -q 'os-done-or-not' ~/.claude/CLAUDE.md 2>/dev/null || cat open-steps/docs/routing-block.md >> ~/.claude/CLAUDE.md

在 Codex CLI、Cursor CLI 和 Gemini CLI 上，一条复制命令为三个工具都装好 skill，再按 README 的说明给每个工具加几行钩子设置：

mkdir -p ~/.agents/skills && cp -R open-steps/skills/os-* ~/.agents/skills/

用 claude plugin details open-steps 或 bash open-steps/doctor.sh 检查——doctor 看不到的地方会写「未检查」，而不是猜。在 Claude Code 上更新要两步（先在克隆里 git pull，再 claude plugin update open-steps@open-steps）；插件从你的本地克隆更新，不是从 GitHub。

实战：「做完了吗？」

1. 照常和智能体干活。会话收尾时——或者你主动问——os-done-or-not 会触发，产出一屏汇报：做完没有、需要你做什么、有没有新的欠账、能不能收工。README 自己的前后对比示例，把一段满是 JWT 和 p95 的术语段落，变成了「人们又能登录了」加一张表格——坏消息独占一行。
2. 另一个会话声称做完了某件事时，别直接接手，先跑 os-check-work——它会把每条说法与实际发生的事核对。
3. 在敲定任何难以回头的事之前——迁移、上线、采购——让 os-what-could-go-wrong 假定这个决定已经失败，由一个全新的智能体倒推原因。
4. 汇报保存在 ~/.claude/open-steps/reports/<project>/，在你的仓库之外，所以永远不会进入提交，卸载技能包也依然保留。两个钩子负责记账：session-start 在会话开始时展示路由表和你上次的汇报；stop-report 在真实改动落地时要求补一份汇报。

安装前有一个行为必须知道：当一个 pull request 检查全部通过、评审已经批准，技能包会再核实一次然后合并它——在 Claude Code 上不弹权限确认。有两种情况会阻止合并：某条说法没有通过核实，或者任务上注明只在收到指令时合并（想要手动控制，就把这条注记写进常驻指令文件）。

技巧

• 技能包公布了自己的触发率评测：25 句日常短语，每句跑三次，覆盖 Haiku 4.5、Sonnet 5.5 和 Opus 5.5，测量于 2026-10-05——Haiku 触发率 89%，Sonnet 和 Opus 均为 100%，其中 os-step-by-step 最弱，Haiku 上只有 3/9。README 明说每句三次只是冒烟测试，不是基准测试。
• 钩子行为可调：OPEN_STEPS_DISABLE 关闭停止钩子，OPEN_STEPS_MAX_REPORT_LINES 限制开始钩子注入的汇报行数（默认 80），OPEN_STEPS_COOLDOWN 控制汇报请求的间隔（默认 900 秒）。
• skill 描述是命令，不是摘要——开头就是「ALWAYS invoke this skill」——而且 README 说明评测并没有把这种写法与其他措辞做对比。
• Claude Code 上预批准的工具按 skill 逐一划定（写汇报、gh pr 读取、合并命令）；据各自文档，Codex CLI、Cursor CLI 和 Gemini CLI 会忽略这个字段——README 标注这一部分尚未测试。
• Claude Code 还有一个可选的「Answer first」输出风格；默认关闭，因为开启会替换掉你已经选好的风格。

何时不用这个 Skill

README 的 Limits 一节写得很明确：回答质量和事前推演的新智能体只在 Claude Code 上测量过——同样的触发短语也由贡献者在 Codex、Cursor 和 Gemini CLI 上运行过，结果见仓库的 evals/README.md。如果你以读 diff 为生，一屏大白话汇报可能是你不需要的一层；这个技能包面向的是无法直接验证智能体工作的人。另外，无论防护多严，自动合并都是对合并权限的真实让渡——如果你的项目要求人工合并 PR，请在第一次会话之前就写好「只在收到指令时合并」的注记，而不是之后。

查看 排行榜 了解更多 skill。