claude code 最常用的几个指令

开场个人观察

前面已经写过一篇比较完整的 Claude Code 常用指令整理，那篇更像一张命令地图；这篇我想写得更贴近日常项目使用：如果只记几个最常用的指令，应该先记哪些？每个指令到底在项目里怎么用？

Claude Code 的指令很多。官方命令页也提醒，输入 / 可以看到当前环境可用的命令，命令必须放在消息开头才会被识别；并且不是每个命令都会出现在每个人的环境里，平台、计划、版本和登录状态都会影响可见范围。所以我不建议一上来背完整命令表。

我的做法是先掌握一条主线：项目初始化用 /init 和 /memory，复杂任务用 /plan，长会话用 /context 和 /compact，验收用 /diff 和 /code-review，方向错了用 /rewind。这几个指令能覆盖大多数日常开发场景。

Claude Code最常用指令工作流

核心观点

Claude Code 指令的作用，不是让你少写自然语言，而是让会话进入正确模式。一个真实开发任务通常不是“问一句、答一句”，而是要经历理解项目、制定计划、修改文件、验证结果、审查风险几个阶段。

如果没有指令，你当然也可以用自然语言表达这些意图，比如“先不要改代码，先给计划”。但指令的好处是更稳定、更明确，也更适合形成习惯。

我会把最常用指令分成四类：

第一类是项目记忆：/init、/memory。

第二类是任务控制：/plan、/model、/effort。

第三类是上下文管理：/context、/compact、/clear。

第四类是验收和恢复：/diff、/code-review、/rewind。

不用一口气全记住。先把这四类放进开发流程里，用几次之后自然就熟了。

Claude Code常用指令项目用法速查

实践方法

1. /init：新项目第一步

/init 适合在第一次进入项目时使用。它通常会帮助生成项目级说明，比如 CLAUDE.md，让 Claude Code 了解项目结构、常用命令和开发约定。

我会这样用：

1
/init

生成之后不要直接结束。你应该手工检查里面的内容，把真实规则补进去：

1
2
3
4
5
- 安装依赖使用 npm install --no-package-lock。
- 文章源文件在 source/_posts。
- 图片放在 source/images。
- public 是生成目录，不要手动写业务内容。
- 修改文章后要生成静态站并检查 archives 页面。

/init 的价值不在生成那一刻，而在后面每次任务都能复用这些项目规则。

2. /memory：把重复提醒沉淀下来

如果你发现自己反复对 Claude Code 说同一句话，比如“不要升级依赖”“先看 diff”“生成后检查归档页”，就应该考虑用 /memory 管理项目记忆。

我会在一次任务结束后补一句：

1
/memory

然后把稳定规则整理进去。注意，记忆文件不适合放一次性需求。比如“今天新增一篇文章”不该写进去；“新增文章必须包含 title/date/tags”才适合写进去。

3. /plan：复杂任务先停一下

/plan 是我最常用的指令之一。只要任务会改多个文件、涉及配置、可能影响线上页面，我都会先让它计划。

示例：

1
/plan 把博客里最近几篇文章日期从 6 月 10 日改成 5 月份随机日期，再新增一篇 6 月 1 日文章。先列出要改的源文件、图片文件、生成和部署验证步骤。

好的计划应该包含四件事：会看哪些文件、会改哪些文件、怎么验证、风险在哪里。如果计划里出现“顺便升级 Hexo”这种越界动作，就要立刻纠正。

4. /model 和 /effort：控制成本和思考深度

不是所有任务都需要最高强度。改错别字、补一段说明、生成一张简单流程图，可以用较低成本；跨模块重构、排查线上问题、做安全审查，就值得提高推理强度。

你可以在任务前调整模型或思考深度：

1
2
/model
/effort

我的习惯是：普通写作和小修用默认设置；涉及发布、权限、数据变更、复杂回归时，再提高投入。这样不会为了小任务浪费太多资源。

5. /context：看看会话被什么占满了

长会话最怕的是上下文越来越乱。你已经换了三个任务，但对话里还塞着前一个任务的日志、diff、错误输出，Claude Code 就可能开始抓错重点。

这时可以用：

1
/context

它的作用是让你看清上下文占用。如果当前任务已经和前面的内容关系不大，就应该压缩或清空，而不是继续往上堆。

6. /compact：把长会话压成可继续的摘要

如果任务还没完，但上下文太长，我会用 /compact。关键是不要只输入一个裸命令，而是告诉它保留哪些东西：

1
/compact 请保留当前目标、已经修改的文件、尚未完成的验证、遇到的错误和下一步计划。

这样压缩后继续工作，方向更不容易丢。它适合长任务，不适合完全换题。如果你要做一个全新的任务，/clear 往往更合适。

7. /diff：验收前先看真实改动

/diff 是防止 AI 编程失控的核心指令。Claude Code 的总结可能写得很漂亮，但真正要 review 的是文件改动。

我一般会在实现后说：

1
/diff

然后重点看这几类问题：

是否改了无关文件；

是否误动配置、锁文件、部署脚本；

是否把临时路径、token、内部地址写进代码；

是否只改了正文但忘了生成资源；

是否删除了历史页面。

不要把 /diff 当成形式。它是开发者重新拿回控制权的地方。

8. /code-review：提交前再过一遍

/code-review 适合在提交前使用。官方命令说明里提到，它会检查 diff 中的正确性问题和可清理点。我的理解是，它像一次额外 review，但不能替代你自己看关键逻辑。

可以这样用：

1
/code-review

如果是高风险改动，可以补充要求：

1
/code-review 请重点看权限、数据删除、异常分支、测试缺口和是否改到无关文件。

对于博客项目，我会让它重点看 front matter、图片路径、生成页面、归档链接和中文编码。

9. /rewind：方向错了及时回退

很多人用 AI 工具时会有一个坏习惯：发现方向错了，还继续让它“修一下”。补丁叠补丁之后，diff 会越来越难看。

这时应该考虑：

1
/rewind

它的意义是回到一个更干净的检查点。特别是当 Claude Code 改了太多无关文件、误解了需求、或者尝试升级依赖导致项目乱掉时，及时回退比继续修补更稳。

10. /clear 和 /resume：切换任务与找回会话

如果当前任务已经结束，准备开始另一个独立任务，可以用：

1
/clear

它会开启更干净的上下文。之后如果需要找回旧会话，可以用：

1
/resume

我的习惯是：同一任务用 /compact 延续，不同任务用 /clear 切开。这样不容易把两个任务的上下文混在一起。

踩坑提醒

第一个坑，是把命令当成魔法。比如用了 /plan，不代表计划一定正确；用了 /code-review，不代表没有 bug。命令只是让流程更清楚，最终判断还在开发者手上。

第二个坑，是不看本机可用命令。Claude Code 文档明确说，不是每个命令都会在每个环境出现。最稳的方法是在自己的会话里输入 /，看当前真实可用列表。

第三个坑，是在长会话里不断换任务。AI 会尽量利用已有上下文，但旧上下文不一定对新任务有帮助。任务之间要么压缩，要么清空。

第四个坑，是把项目规则只写在聊天里。只在当前会话里说过的规则，很容易下一次就忘。长期规则应该进入 CLAUDE.md、memory、项目文档或 skill。

第五个坑，是跳过验证。无论用什么指令，最后都要落到测试、构建、页面检查、人工 review 上。没有验证的“完成”，只是文字上的完成。

总结

如果只记 Claude Code 的几个常用指令，我会按这个顺序记：/init、/memory、/plan、/context、/compact、/diff、/code-review、/rewind。

它们对应的不是孤立功能，而是一条项目开发主线：建立记忆，计划任务，管理上下文，检查改动，必要时回退。把这条主线用熟，比背完整命令表更有价值。

参考资料

项目使用Codex有哪些注意事项

开场个人观察

前面写过一篇《Codex提高软件编程效率的10个技巧》，偏方法论；这篇更像一张检查单：项目真正接入 Codex 时，有哪些地方要先想清楚。

Codex 这类 coding agent 的能力很强。OpenAI 官方把 Codex 描述为用于软件开发的 coding agent，可以帮助写代码、理解陌生代码库、review 代码、调试问题和自动化开发任务。问题也正在这里：它能做的事情越多，项目越需要明确边界。

如果只是让它写一段 demo，风险不大；如果让它进入真实仓库、读取配置、修改文件、运行命令，情况就完全不同了。我的原则是：先把权限、上下文、验证、审查、回滚想清楚，再谈效率提升。

项目使用Codex注意事项流程图

核心观点

项目使用 Codex，要守住四条线：权限线、上下文线、验证线、责任线。

权限线，是指它能读什么、能写什么、能运行什么命令。不要因为方便就给过大的权限。

上下文线，是指你要告诉它项目规则、任务边界、验收标准。上下文不给清楚，它只能猜。

验证线，是指所有输出都要能被测试、构建、手工检查或 review 证明。

责任线，是指最终合并和发布的人仍然是开发者，不是 AI。

Codex 可以提高速度，但不能替代工程纪律。相反，越是用 AI，越需要清楚的工程纪律。

Codex项目审查指引

实践方法

第一步，给项目准备 AGENTS.md 或类似规则文件。里面不需要写太多废话，重点写长期有效规则：

1
2
3
4
5
6
7
8
# Project Rules

- Source posts are under source/_posts.
- Static images are under source/images.
- public is generated output; do not hand-edit it unless generation is blocked.
- After changing posts, generate the site and verify public/archives/index.html.
- Do not modify deployment config unless explicitly requested.
- New Markdown files must use title/date/tags front matter.

这类规则能减少重复沟通。Codex 官方最佳实践也强调，把项目特定指令写进 AGENTS.md 这类文件，可以帮助 agent 按项目约定工作。

第二步，把任务写小。不要说：

1
帮我把博客项目整体优化一下。

更好的写法是：

1
2
3
新增一篇 2026 年 AI 技术文章，文件放在 source/_posts，图片放在 source/images。
生成静态站后确认 archives 页面出现新标题。
不要修改旧文章内容，不要升级 Hexo 版本。

第三步，让 Codex 先说明计划。真实项目里，我通常会写：

1
先不要编辑文件。请先说明你准备查看哪些文件、准备新增或修改哪些文件、验证命令是什么、可能风险是什么。

这个步骤能提前发现误解。比如它准备升级依赖、删除 public、重构主题，而你的需求只是新增文章，这时就要立刻纠偏。

第四步，要求它自己验证，但不要只相信它的总结。比如：

1
完成后请运行生成命令，检查归档页是否包含新标题，并说明验证结果。如果命令失败，请贴出关键错误和你的处理方式。

第五步，人工看 diff。尤其注意：

是否改了无关文件；

是否改了部署配置；

是否把密钥、token、内部地址写进文章或配置；

是否误删生成文件；

是否绕过了测试失败；

是否用“应该可以”代替真实验证。

第六步，发布前确认回滚路径。对于博客这类项目，至少要知道源文章在哪、生成结果在哪、发布仓库提交是哪一个。如果线上异常，可以回退到上一版发布提交。

踩坑提醒

第一个坑，是把仓库里的所有东西都当成可改。真实项目里，生成目录、锁文件、迁移脚本、部署配置、密钥模板都需要区别对待。Codex 不一定天然知道哪些文件是“碰不得”的，要写进规则。

第二个坑，是让它在没有验证命令的情况下提交结论。比如“已完成，应该能运行”。这类话没有工程价值。要么跑了命令，要么说明没跑以及为什么没跑。

第三个坑，是忽略依赖和环境差异。老项目尤其明显：Node 版本、包管理器、旧框架、编码问题，都可能让生成命令失败。遇到这类问题，不要急着升级全家桶，先找最小兼容方案。

第四个坑，是把 AI 输出直接发布。文章、代码、配置都一样，最后要有人读一遍。AI 可能写错事实、误解业务、过度自信，也可能把本地临时信息写进正文。

第五个坑，是没有沉淀经验。每次遇到一个项目级规则，都应该考虑写进 AGENTS.md、README、skill 或检查清单。否则下次还会重复踩。

总结

项目使用 Codex，最重要的不是“让它多做点”，而是“让它在清楚边界内稳定做事”。权限要收住，上下文要写清，验证要真实，review 要保留。

我比较推荐的节奏是：先从低风险任务开始，比如文档、测试、脚本、小 bug；等项目规则沉淀得足够清楚，再让 Codex 参与更复杂的开发任务。这样既能享受效率提升，也不至于把项目交给一团不可控的自动化。

参考资料

openspec + superpowers这套组合怎么让大需求更好落地

开场个人观察

大需求最怕两种状态：一种是只有一句话，比如“重构库存中心”；另一种是文档写了几十页，但没有人能把它拆成真正可执行、可验证、可回滚的任务。AI 编程助手能提高编码速度，但如果需求、计划和验收都没有站稳，它只会更快地把混乱扩散到更多文件里。

我现在更愿意把 OpenSpec/OPSX 和 Superpowers 组合起来用。OpenSpec 负责把变更放进一个可追踪的规格流程里，Superpowers 负责把 AI 的开发过程约束成成熟工程师会做的动作：澄清、计划、测试、执行、调试、审查、收尾。

简单说，OpenSpec 管“这次变更是什么”，Superpowers 管“这次变更怎么稳定做完”。

openspec加superpowers组合落地大需求

核心观点

这套组合不是两个口号叠在一起，而是两层控制。

第一层是 OpenSpec/OPSX。它用 /opsx:propose、/opsx:apply、/opsx:sync、/opsx:archive 把一次需求变成一个完整 change。这个 change 里应该有 proposal、design、tasks、specs，能说明目标、非目标、接口、数据、流程、异常、测试和验收。

第二层是 Superpowers。它不是一个万能 /superpowers 命令，而是一组具体 skill，例如 brainstorming、writing-plans、test-driven-development、systematic-debugging、requesting-code-review、verification-before-completion。这些 skill 的作用，是让 AI 不要跳步。

组合之后，大需求的节奏会变成：

1
2
3
4
5
先 propose，把需求规格化。
再用 brainstorming 和 writing-plans 审需求、拆计划。
然后 apply，但执行时必须按 plans 小步推进。
每个切片用 TDD、debugging、code review 控制质量。
完成后 sync 规格，再 archive 归档。

这比一句“帮我实现这个大需求”稳很多。

指令和技能速查

OpenSpec 常用指令：

1
/opsx:propose <change-name>

用途：创建一个 change，生成 proposal、design、tasks、specs。大需求的第一步一定应该是它。

1
/opsx:apply <change-name>

用途：按 change 下的 artifacts 实现代码。这里不要让 AI 自由发挥，要要求它严格对照 tasks。

1
/opsx:sync <change-name>

用途：实现和验证完成后，把 delta specs 同步回主规格。

1
/opsx:archive <change-name>

用途：归档完成的 change，保留历史。

OpenSpec 还有一些辅助命令：

1
2
3
4
5
/opsx:explore
/opsx:new
/opsx:continue
/opsx:ff
/opsx:verify

需求不清楚时先用 /opsx:explore，只想建脚手架可以用 /opsx:new，生成过程没有完可以用 /opsx:continue，想快速补齐 artifacts 可以用 /opsx:ff，实现后检查规格符合度可以用 /opsx:verify。

Superpowers 常用 skill：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
using-superpowers
brainstorming
writing-plans
executing-plans
subagent-driven-development
test-driven-development
systematic-debugging
verification-before-completion
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
dispatching-parallel-agents
writing-skills

实际使用时，可以直接这样点名：

1
请使用 brainstorming skill，先澄清这个需求，不要写代码。
1
2
请使用 writing-plans skill，把 OpenSpec 的 tasks 拆成 2 到 5 分钟一项的小任务。
每个任务必须包含文件路径、修改内容、验证方式。
1
2
请使用 test-driven-development skill，实现库存差异处理。
先写失败测试，确认失败后再写最小实现。
1
2
请使用 systematic-debugging skill 分析这个测试失败。
先看日志和断言，不要直接猜原因。
1
2
请使用 requesting-code-review skill 审查当前 diff。
按严重程度列出问题，重点看事务、幂等、并发、兼容性、测试缺口。
1
2
请使用 verification-before-completion skill 确认这个 change 是否真的完成。
必须列出已运行的测试、未覆盖风险和人工验收点。

如果工具环境里没有把这些 skill 暴露成 slash command，也没有关系。直接在提示词里写“请使用 xxx skill”通常也能让 AI 按对应流程执行。关键是不要只说“用 superpowers”，而要点名具体 skill。

一个完整流程

我会把大需求拆成 8 个阶段。

第一阶段，用 /opsx:explore 或 brainstorming 澄清需求。

需求刚开始通常是不完整的。比如“采购到货差异处理”这句话，背后可能有少到、多到、质检不合格、退供应商、让步接收、补货、财务暂估、报表口径等一堆问题。

可以这样开始：

1
2
3
4
5
6
7
8
9
10
11
12
/opsx:explore

需求：供应链系统增加采购到货差异处理。
请先探索需求，不要写代码。

请结合 brainstorming skill，先问清楚：
1. 差异类型有哪些；
2. 哪些差异影响库存；
3. 哪些差异影响财务暂估；
4. 哪些状态允许修改；
5. 哪些场景需要审批；
6. 哪些报表口径会受影响。

第二阶段，用 /opsx:propose 生成 change。

1
2
3
4
5
6
7
8
9
10
11
12
/opsx:propose purchase-receipt-discrepancy

需求：
供应链系统增加采购到货差异处理。
采购单数量和实际到货数量可能不一致，存在少到、多到、质检不合格。
系统需要记录差异、处理差异，并影响库存、财务暂估和报表。

项目匹配要求：
- 先读取 AGENTS.md、README.md、pom.xml；
- 读取采购、到货、质检、库存、财务暂估、报表相关模块；
- 参考现有 Controller、Service、Mapper、DTO、异常码、测试写法；
- 只生成 proposal/design/tasks/specs，不写业务代码。

这个阶段的目标不是代码，而是让 change 说清楚这些内容：

1
2
3
4
5
6
7
8
9
10
业务目标：为什么要做差异处理。
非目标：本阶段不做哪些事情。
状态流转：采购单、到货单、质检单、差异单各自怎么变化。
接口设计：登记到货、确认差异、关闭差异、查询差异。
数据模型：到货单、到货明细、差异记录、处理记录。
库存影响：合格品入库、不合格品待处理、多到少到如何记录。
财务影响：暂估数量、应付数量、冲销逻辑。
报表口径：到货率、差异率、不合格率如何计算。
异常流程：重复提交、并发处理、状态不允许、下游失败。
验收标准：每类差异都能追踪、回滚、查询、统计。

第三阶段，用 requesting-code-review 审 propose 结果。

1
2
3
4
5
6
7
8
请使用 requesting-code-review skill 审查 openspec/changes/purchase-receipt-discrepancy。
重点检查：
1. proposal 是否把目标和非目标写清楚；
2. design 是否覆盖库存、财务、报表三类影响；
3. tasks 是否过大，是否能拆成小步；
4. specs 是否有可验证的验收标准；
5. 有没有遗漏权限、幂等、事务、并发、历史数据兼容；
6. 有哪些问题必须在 apply 前确认。

这一步很重要。很多大需求失败，不是实现失败，而是 proposal 阶段就已经漏掉了关键业务。

第四阶段，用 writing-plans 把 tasks 拆细。

OpenSpec 生成的 tasks.md 有时还是偏粗。比如“实现库存差异逻辑”这个任务就太大。应该继续拆：

1
2
3
4
5
6
7
请使用 writing-plans skill 细化 tasks.md。
要求：
1. 每个任务控制在 2 到 5 分钟可完成；
2. 每个任务写明具体文件路径；
3. 每个任务写明验证命令或检查方式；
4. 先做数据结构和测试，再做业务实现；
5. 任务之间必须能独立 review。

拆完后可能变成：

1
2
3
4
5
6
7
8
9
10
任务1：补充差异类型枚举和状态枚举。
任务2：新增差异记录表迁移脚本。
任务3：新增差异记录 Entity/DTO/Mapper。
任务4：为登记到货接口补充少到测试。
任务5：实现少到差异记录。
任务6：为多到场景补充测试。
任务7：实现多到差异处理。
任务8：补充不合格品待处理区逻辑。
任务9：补充财务暂估数量影响。
任务10：补充报表统计口径测试。

第五阶段，用 /opsx:apply 执行，但让 Superpowers 控制节奏。

1
2
3
4
5
6
7
8
9
10
/opsx:apply purchase-receipt-discrepancy

请结合 executing-plans skill 执行。
要求：
- 严格按照 tasks.md 顺序；
- 每次只完成一个任务；
- 每个任务结束后展示 diff；
- 不做无关重构；
- 不引入项目没有使用的新依赖；
- 测试失败时切换到 systematic-debugging skill。

如果是高风险模块，我会更明确地要求 TDD：

1
2
请使用 test-driven-development skill 执行任务4到任务7。
每个业务场景必须先写失败测试，再写最小实现。

第六阶段，失败时用 systematic-debugging。

不要让 AI 一看到失败就乱改。比如测试报“库存数量不一致”，可能是事务没提交，可能是测试数据错了，也可能是业务口径错了。要让它先收集证据：

1
2
3
4
5
6
7
8
9
10
请使用 systematic-debugging skill 分析当前失败测试。
不要直接改代码。

请输出：
1. 失败测试名称；
2. 期望值和实际值；
3. 相关日志；
4. 可能根因；
5. 还需要查看哪些文件；
6. 最小修复方案。

第七阶段，每个切片后都做 requesting-code-review。

1
2
3
4
5
6
7
8
9
请使用 requesting-code-review skill 审查当前 diff。
重点看：
1. 是否符合 OpenSpec 的 proposal/design/tasks/specs；
2. 是否只修改了本切片范围；
3. 事务边界是否正确；
4. 幂等记录是否和业务写入一致；
5. 并发场景是否可能重复处理差异；
6. 报表口径是否和 specs 一致；
7. 测试是否覆盖异常和回滚。

这一轮 review 要敢于阻塞。如果出现新依赖、无关重构、状态机绕过、没有测试的核心逻辑，就应该停下来修正。

第八阶段，完成后 /opsx:verify、/opsx:sync、/opsx:archive。

1
/opsx:verify purchase-receipt-discrepancy

先确认实现符合 specs。然后：

1
2
3
4
5
6
7
请使用 verification-before-completion skill 做完成前检查。
列出：
1. 已完成的验收标准；
2. 已运行的测试；
3. 未自动化覆盖的人工验收点；
4. 剩余风险；
5. 是否可以 sync 和 archive。

确认后再执行：

1
2
/opsx:sync purchase-receipt-discrepancy
/opsx:archive purchase-receipt-discrepancy

最后可以用：

1
2
请使用 finishing-a-development-branch skill 收尾。
整理变更摘要、测试结果、风险说明和后续维护建议。

Java 大需求的切片原则

对 Java 后端来说，大需求切片不能只按“前端页面、后端接口、数据库”这种粗粒度拆。更好的方式是按可验收业务能力拆。

状态先行。先把枚举、状态机、允许操作、禁止操作定义清楚。状态错了，后面所有逻辑都会错。

数据先行。表结构、唯一索引、幂等键、流水表要先设计好。尤其是库存、财务、支付这类业务，后补数据模型通常代价很高。

测试先行。每个业务切片至少有成功、失败、重复、并发、回滚这些测试或验证清单。

接口兼容。新增字段、枚举值、响应结构要考虑前端和其他服务是否受影响。

事务边界单独审。哪些操作必须同事务，哪些可以异步补偿，哪些必须写流水，需要在 design 阶段写清楚。

报表口径单独审。大需求经常影响统计，不要等上线后才发现报表数字对不上。

每个切片都能回滚。数据库字段、消息消费、定时任务、缓存更新都要考虑灰度和回退。

供应链案例：采购到货差异处理

这个需求可以拆成三个阶段。

第一阶段，只做差异可记录。

范围包括：差异类型、差异单、差异明细、登记到货时生成差异记录。这个阶段不直接影响财务，只保证业务事实能记录。

适合的指令：

1
2
3
/opsx:propose purchase-receipt-discrepancy-recording
请使用 brainstorming skill 澄清差异类型和状态。
请使用 writing-plans skill 把记录差异拆成小任务。

第二阶段，做库存影响。

范围包括：合格品入库、不合格品进入待处理区、多到数量是否允许入库、少到是否保留待到货数量。

适合的指令：

1
2
请使用 test-driven-development skill 实现库存影响。
先写少到、多到、不合格、重复登记、并发登记的测试。

第三阶段，做财务和报表。

范围包括：暂估数量、应付数量、差异率、不合格率、供应商履约统计。

适合的指令：

1
2
请使用 requesting-code-review skill 审查财务暂估和报表口径。
重点检查历史数据兼容、SQL 性能、分页导出、租户和数据权限。

这样拆的好处是，每个阶段都有业务价值，也都有明确边界。第一阶段即使先上线，也不会破坏库存和财务；第二阶段上线后库存闭环；第三阶段再补齐统计和经营分析。

踩坑提醒

第一个坑，是还在探索需求时就 /opsx:apply。大需求前期应该多用 /opsx:explore、brainstorming 和 /opsx:propose，不要急着写代码。

第二个坑，是只写 OpenSpec，不用 Superpowers 审。proposal 看起来完整，不代表任务可执行。一定要用 requesting-code-review 和 writing-plans 去审 artifacts。

第三个坑，是 Superpowers 只说不用点名。不要写“请使用 superpowers 帮我处理”，要写“请使用 systematic-debugging skill”或“请使用 test-driven-development skill”。

第四个坑，是任务切片太大。凡是一个任务里同时出现 Controller、Service、Mapper、表结构、消息、报表、测试，基本都应该继续拆。

第五个坑，是没有完成前验证。大需求最后必须用 /opsx:verify 和 verification-before-completion 兜底，确认不是“代码写完了”，而是“需求真的完成了”。

总结

OpenSpec/OPSX 和 Superpowers 组合起来，真正解决的是大需求的两个问题：规格不清和执行失控。

OpenSpec 用 /opsx:propose、/opsx:apply、/opsx:verify、/opsx:sync、/opsx:archive 管住变更生命周期。Superpowers 用 brainstorming、writing-plans、test-driven-development、systematic-debugging、requesting-code-review、verification-before-completion 管住开发过程。

对 Java 系统来说，这套组合特别适合订单、库存、采购、财务、报表、权限、消息消费这类跨模块需求。AI 可以写代码，但大需求要先有规格，再有计划，再有测试和审查。否则速度越快，风险越大。

参考资料

什么是Skill，以及如何生成自己的Skill

开场个人观察

用 AI 编程工具一段时间后，我发现一个很现实的问题：很多提示词会被反复复制。比如“请先读代码不要修改”“请按这个格式输出审查结果”“请运行这些验证命令”“请用我们项目的发布流程”。这些话每次都粘一遍，既麻烦，也容易漏。

Skill 就是为了解决这类问题而出现的。它把一套可复用的工作流程、检查清单、领域知识或工具调用方式，包装成一个可以被 AI 按需加载的能力。你可以把它理解成“给 AI 用的操作手册”，但它比普通文档更强调触发条件和执行步骤。

Claude Code 官方文档里说，skills 通过 SKILL.md 扩展 Claude 的能力，可以在相关时自动使用，也可以通过 /skill-name 直接调用。Codex 这边也有类似的技能机制：一个 skill 通常包含说明文件，以及可选的脚本、参考资料和资源文件。两者的共同点是：把重复经验沉淀为可复用流程。

Skill生命周期

核心观点

Skill 不是越大越好，而是越清楚越好。一个好的 skill 应该回答四个问题：

第一，它解决什么重复问题？

第二，什么时候应该使用它？

第三，使用它时要按什么步骤执行？

第四，输出结果应该如何验证？

如果一个 skill 只是把一大堆资料塞进去，反而会降低效果。因为 AI 每次使用时会消耗上下文，描述越含糊，越容易触发错误；内容越臃肿，越容易淹没真正关键的步骤。

我更喜欢把 skill 做成“小而稳”的工具。比如：

supply-chain-inventory-review：专门审查供应链系统里的库存预占、释放、扣减和流水一致性。

api-review：专门审查接口改动，包括鉴权、错误码、兼容性、日志、测试。

release-check：专门做发版前检查，包括 diff、测试、配置、回滚方案。

这些 skill 都有明确边界，比“我的万能开发助手”更容易生效。

Skill目录结构指引

实践方法

一个最小 skill 通常可以从一个文件夹开始：

1
2
my-skill/
  SKILL.md

SKILL.md 里最重要的是 front matter 和正文说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
---
name: supply-chain-inventory-review
description: Use when reviewing inventory reservation, release, deduction, or stock ledger changes in a Java supply chain system.
---

# Supply Chain Inventory Review

Use this skill when a change touches inventory reservation, inventory release, stock deduction, stock ledger, purchase receipt, shipment, or order fulfillment logic.

## Workflow

1. Read the related Controller, Service, Mapper, DTO, database scripts, and tests.
2. Identify the business scenario: order reservation, payment confirmation, timeout release, shipment deduction, purchase receipt, or adjustment.
3. Check whether idempotency, transaction boundaries, concurrency control, and stock ledger records are defined.
4. List risks before suggesting code changes.
5. Require tests for success, duplicate requests, insufficient stock, concurrent requests, and rollback.
6. Review the final diff against the risk list.

## Rules

- Do not introduce a new lock mechanism unless the existing project pattern cannot satisfy the scenario.
- Do not change stock quantity without a matching stock ledger record.
- Do not treat idempotency as only a frontend concern.
- Any change to stock quantity must explain transaction and rollback behavior.

这里的 description 很关键。它不是给人看的简介，而是帮助 AI 判断什么时候应该加载这个 skill。写得太窄，可能触发不了；写得太宽，又会到处乱触发。

如果流程需要稳定执行脚本，可以加 scripts/：

1
2
3
4
my-skill/
  SKILL.md
  scripts/
    validate_front_matter.js

如果有较长参考资料，可以放到 references/，并在 SKILL.md 里说明什么时候读。这样平时不占上下文，只有需要时才加载。

如果有模板、示例图片、配置样板，可以放到 assets/。例如写报告、生成幻灯片、创建博客配图时，这个目录很有用。

我的生成步骤一般是：

1
2
3
4
5
6
1. 先把重复任务写成普通提示词。
2. 连续使用几次后，找出稳定不变的步骤。
3. 把步骤整理成 SKILL.md。
4. 用一个真实任务测试它。
5. 如果触发太频繁，就收窄 description。
6. 如果经常忘步骤，就把规则写得更明确。

把重复工作流沉淀成 skill

真正值得沉淀成 skill 的，不是一次性任务，而是反复出现、容易漏步骤、出错代价高的工作流。Java 供应链系统里最典型的例子，就是库存相关需求。

比如系统里经常会有这些需求：

1
2
3
4
5
6
7
下单时预占库存。
支付成功后确认扣减。
支付超时后释放库存。
取消订单后释放库存。
采购到货后增加库存。
发货出库后扣减库存。
盘点差异后调整库存。

这些需求看起来场景不同，但底层检查点很相似：库存数量不能错，流水必须完整，重复请求不能重复扣减，并发不能超卖，异常时不能留下半条数据。

第一次遇到这类需求时，可以先写普通提示词：

1
2
3
4
5
6
7
8
请先审查这个库存预占需求，不要写代码。
重点检查：
1. 库存数量字段如何变化；
2. 是否需要库存流水；
3. 是否有幂等 key；
4. 并发请求是否会超卖；
5. 事务失败是否会回滚；
6. 需要哪些测试用例。

如果第二次、第三次还在复制同样的话，就说明它适合沉淀成 skill。沉淀时不要急着写成很大的“供应链系统全能助手”，而是先做一个边界清楚的 skill，比如 supply-chain-inventory-review。

这个 skill 可以这样设计：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
---
name: supply-chain-inventory-review
description: Use when reviewing Java supply chain changes that modify inventory reservation, release, deduction, receipt, adjustment, or stock ledger records.
---

# Supply Chain Inventory Review

## When to use

Use this skill when a change touches inventory quantity, stock ledger, reservation records, purchase receipt, shipment deduction, or inventory adjustment.

## Steps

1. Identify the business action: reserve, release, deduct, receive, adjust, or reverse.
2. Find the existing inventory tables, ledger tables, Mapper/XML, Service, and tests.
3. Check idempotency: request key, order number, message key, or business unique index.
4. Check concurrency: optimistic lock, conditional update, row lock, Redis lock, or message serialization.
5. Check transaction boundary: which records must commit or roll back together.
6. Check ledger consistency: every quantity change must have a matching ledger reason.
7. Check tests: success, insufficient stock, duplicate request, concurrent request, rollback, and invalid state.
8. Review diff and report any unrelated refactor.

## Output

Return:
- business scenario summary
- affected files and tables
- risk list
- required tests
- review conclusion

这个例子里，skill 保存的不是某个需求的答案，而是“审查库存变更时必须走的流程”。以后不管是预占库存、释放库存，还是采购到货入库，都可以复用这套检查方式。

更进一步，还可以把它拆成多个小 skill：

1
2
3
supply-chain-inventory-review：审库存数量、流水、幂等、并发。
supply-chain-report-review：审报表口径、SQL 性能、导出权限。
supply-chain-order-state-review：审订单状态机、允许操作、异常流转。

这样做的好处是，每个 skill 都很清楚，触发条件也更准确。AI 不需要一次加载一大堆供应链知识，只在相关场景加载对应流程。

我判断一个重复流程能不能变成 skill，通常看三个问题：

1
2
3
这件事是否每次都要重复说？
这件事漏掉以后是否容易出事故？
这件事是否能写成稳定步骤和检查清单？

如果三个答案都是“是”，就值得沉淀。

踩坑提醒

第一个坑，是把 skill 写成百科。Skill 不是知识库全文，它应该优先保存流程、约束和关键判断。长资料可以放 references，需要时再读。

第二个坑，是 description 写得太虚。比如“帮助开发”这种描述几乎没有意义。更好的写法是“Use when reviewing API changes for authentication, compatibility, error handling, and tests.”

第三个坑，是没有真实任务验证。一个 skill 看起来写得很好，不代表实际会触发，也不代表输出稳定。一定要拿真实项目试一次。

第四个坑，是把易变信息写死。比如某个临时分支、一次性需求、当天的部署地址，不适合写进长期 skill。Skill 应该保存长期有效的规则。

第五个坑，是让 skill 绕过人工判断。Skill 可以让 AI 更熟悉流程，但不能替你承担最终责任。尤其是部署、删除数据、改权限、处理密钥，仍然要有人确认。

总结

Skill 的本质，是把反复出现的 AI 协作经验产品化。它不神秘，也不一定复杂。只要你发现自己第三次复制同一段提示词，就可以考虑把它做成一个 skill。

我判断一个 skill 是否值得保留，通常看三个标准：是否减少重复输入，是否降低错误概率，是否让输出更容易验收。满足这三点，就值得沉淀。

参考资料

利用superpowers让Spec Coding更准确

开场个人观察

前面写 OpenSpec/OPSX 的时候，我把重点放在“先把需求写成规格，再让 AI 按规格实现”。但真实项目里还有另一类问题：spec 写得差不多了，AI 也开始改代码了，可过程还是容易跑偏。比如一次性改太多文件、没有先写测试、遇到失败就绕过、没有复盘 diff、没有把经验沉淀下来。

这就是我重新理解 superpowers 的原因。它不是一句“请发挥超级能力”的提示词，而是一套更偏工程实践的开发方法论。参考 obra/superpowers 的定位，它更像是把成熟开发者的工作习惯拆成一组可调用的 skills：需求澄清、计划、测试驱动、调试、代码审查、执行计划、提交纪律、协作沟通等。

如果说 OpenSpec 负责回答“我们要做什么”，那么 Superpowers 更关注“我们怎样稳定地把它做完”。这篇记录一下我会怎么把 Superpowers 用在 Java 后端项目的 Spec Coding 里，尤其是订单、库存、支付、结算、报表这种高风险业务。

superpowers增强Spec Coding

核心观点

我现在不把 superpowers 理解成单个命令，而是理解成一套“开发过程护栏”。它的目标不是让 AI 写得更快，而是让 AI 在关键节点停下来做正确动作。

第一层是澄清。需求不清楚时，不急着写代码，先把目标、非目标、约束、验收标准问明白。

第二层是计划。复杂任务不能直接开写，要先拆成小步，每一步都有可验证结果。

第三层是测试。高风险逻辑优先写测试或至少先写测试清单，避免只覆盖 happy path。

第四层是调试。出错时按证据排查，不靠猜，不反复试错，不把失败测试删掉。

第五层是审查。每轮改完都看 diff，检查是否越界、是否引入不必要重构、是否破坏兼容。

第六层是沉淀。做完后把决策、坑点、可复用经验记录下来，下次不从零开始。

这几层能力组合起来，才是 Superpowers 真正有价值的地方。

Superpowers 技能指令速查

Superpowers 安装以后，通常不是靠一个 /superpowers 命令来完成所有事情，而是让 agent 在合适场景自动触发对应 skill。实际使用时，也可以直接点名 skill，让 Codex 或 Claude Code 按这个 skill 的流程工作。

我会把它理解成这些“技能指令”：

1
using-superpowers

用途：让 agent 先说明 Superpowers 的技能系统怎么工作，适合刚安装完验证是否生效。

1
brainstorming

用途：需求还很粗时使用。它会先问问题、澄清目标、探索方案，而不是马上写代码。

1
writing-plans

用途：设计确认后生成实现计划。计划要拆成小任务，写清楚文件路径、修改点和验证步骤。

1
executing-plans

用途：按已经写好的计划执行。适合一个人机协作的节奏：做一批任务，停下来检查，再继续。

1
subagent-driven-development

用途：让子 agent 按任务并行或分阶段推进，并进行两段式检查：先看是否符合 spec，再看代码质量。

1
test-driven-development

用途：强制 RED-GREEN-REFACTOR。先写失败测试，看它真的失败，再写最小代码让测试通过，最后重构。

1
systematic-debugging

用途：遇到 bug 或测试失败时使用。要求先收集证据、定位根因，再做最小修复，避免靠猜。

1
verification-before-completion

用途：完成前确认“真的修好了”。不能只说看起来可以，要跑测试、看输出、验证关键路径。

1
requesting-code-review

用途：改完一轮后请求代码审查。重点看计划符合度、边界场景、测试缺口、是否有越界修改。

1
receiving-code-review

用途：收到 review 反馈后使用。它会帮助逐条处理问题，而不是只挑简单的改。

1
using-git-worktrees

用途：为一个较大任务创建隔离工作区，避免污染主工作区，适合多任务并行或风险较高的改动。

1
finishing-a-development-branch

用途：任务完成后收尾。检查测试、整理变更、决定合并、开 PR、保留或清理 worktree。

1
dispatching-parallel-agents

用途：把独立任务分给多个 agent 并行做，比如一个查接口影响，一个查数据库影响，一个补测试。

1
writing-skills

用途：把你自己的流程沉淀成新 skill。比如把“Java 库存接口审查清单”写成团队 skill。

实际对话时，可以这样点名：

1
请使用 brainstorming skill，先澄清这个库存预占需求，不要写代码。
1
2
请使用 writing-plans skill，基于已经确认的设计生成实现计划。
每个任务要包含文件路径、修改内容、验证命令。
1
2
请使用 test-driven-development skill，实现批量库存预占。
必须先写失败测试，再写最小实现。
1
2
请使用 systematic-debugging skill 分析这个失败测试。
先给证据和根因假设，不要直接改代码。
1
2
请使用 requesting-code-review skill 审查当前 diff。
按严重程度列出问题，重点看事务、幂等、并发、兼容性和测试缺口。

如果你的客户端支持 slash command，具体触发形式可能会包装成斜杠命令；如果不支持，直接在提示词里写“请使用 xxx skill”也能表达同样意图。关键是点名具体 skill，而不是只说“用 superpowers”。

Superpowers 和 OpenSpec 的关系

OpenSpec/OPSX 更偏规格管理。比如：

1
2
3
4
/opsx:propose add-inventory-reservation
/opsx:apply add-inventory-reservation
/opsx:sync add-inventory-reservation
/opsx:archive add-inventory-reservation

这条链路解决的是“变更如何被定义、实现、同步、归档”。它适合让需求有结构、有历史、有验收。

Superpowers 更偏过程控制。它解决的是：

1
2
3
4
5
6
实现前是否先澄清？
有没有按小步计划推进？
有没有先补测试？
失败时有没有按证据调试？
改完是否审查 diff？
完成后有没有总结经验？

所以我更推荐把两者组合起来：

1
2
OpenSpec 负责定义变更。
Superpowers 负责约束执行过程。

在 Java 项目里，这个组合尤其有用。因为 Java 后端的麻烦经常不在代码语法，而在业务边界、数据库一致性、并发、事务、历史数据和系统间调用。

一个可落地的 7 步流程

参考 Superpowers 的实践思路，我会把一次 AI 辅助开发拆成 7 步。

第一步，理解任务，对应 brainstorming。

让 AI 先读需求、读项目规则、读同类代码。对 Java 项目来说，至少要看 AGENTS.md、README.md、pom.xml、同类 Controller、Service、Mapper、测试用例。不要让它一上来就改文件。

可以这样提示：

1
2
3
4
5
6
7
请先理解任务，不要改代码。
读取 AGENTS.md、README.md、pom.xml，以及订单模块已有的 Controller、Service、Mapper、测试。
请总结：
1. 这个需求涉及哪些模块；
2. 现有代码风格是什么；
3. 可能影响哪些接口、表、状态机；
4. 还有哪些问题需要确认。

第二步，提出计划，对应 writing-plans。

计划要小步、可验证。不要只写“实现业务逻辑”，而要写到具体层次：

1
2
3
4
5
6
请生成执行计划，不要改代码。
要求：
1. 每一步只改一类文件；
2. 每一步说明验证方式；
3. 标出事务、幂等、并发、兼容性风险；
4. 不做和需求无关的重构。

第三步，先写测试或测试清单，对应 test-driven-development。

很多 Java 项目历史包袱重，不一定能完全 TDD，但至少要先列出测试清单。比如库存预占，不应该只测成功：

1
2
3
4
5
6
7
8
9
测试清单：
1. 单 SKU 预占成功；
2. 多 SKU 全部预占成功；
3. 部分 SKU 库存不足；
4. 同一订单重复请求不重复扣减；
5. 并发请求同一 SKU 不超卖；
6. 数据库异常时事务回滚；
7. 参数为空、数量为负数、SKU 不存在时返回校验错误；
8. 旧接口字段保持兼容。

第四步，小步实现，对应 executing-plans 或 subagent-driven-development。

每次只让 AI 做一个小任务。比如先改 DTO，再改 Service，再改 Mapper，再补测试。不要一句“全部实现”，否则它很容易跨模块乱改。

1
2
3
现在只做第一步：新增请求 DTO 和响应 DTO。
不要修改 Service、Mapper、数据库脚本。
完成后展示 diff，并说明是否符合计划。

第五步，基于证据调试，对应 systematic-debugging。

测试失败时，不要让 AI 直接猜。要让它先读错误日志、定位失败断言、说明假设，再做最小修复。

1
2
3
4
5
6
7
测试失败了。请先分析失败日志，不要马上改代码。
输出：
1. 失败测试名称；
2. 期望值和实际值；
3. 最可能的原因；
4. 需要查看的文件；
5. 最小修复方案。

第六步，审查 diff，对应 requesting-code-review。

这一点非常关键。AI 很容易顺手改命名、调格式、移动代码、引入新依赖。审查 diff 要看三件事：有没有完成需求，有没有越界，有没有留下风险。

1
2
3
4
5
6
7
8
请审查当前 diff。
重点检查：
1. 是否只修改了计划内文件；
2. 是否引入新依赖或新框架；
3. 事务边界是否正确；
4. 幂等和并发是否覆盖；
5. 是否有兼容性风险；
6. 测试是否覆盖异常场景。

第七步，总结和沉淀，对应 verification-before-completion 和 finishing-a-development-branch。

做完以后，不只是提交代码。应该把这次的决策、坑点、命令、测试经验沉淀下来。对长期项目来说，这一步会让 AI 后续越来越贴合项目。

1
2
3
4
5
6
7
请总结这次变更：
1. 业务决策；
2. 技术决策；
3. 关键风险；
4. 测试覆盖；
5. 后续维护注意事项；
6. 哪些内容适合补充到 AGENTS.md 或项目文档。

我常用的技能组合

Superpowers 的价值在于把“好习惯”变成可以重复调用的技能。我在 Java 项目里会重点用这些能力。

任务澄清：适合需求刚开始时使用。让 AI 主动问缺失信息，不要把不确定性藏到代码里。

分步计划：适合任何超过 30 分钟的任务。计划必须能映射到文件、测试和验收标准。

测试驱动：适合库存、支付、结算、权限、状态机。能先写测试就先写测试，不能先写测试也要先写测试清单。

系统性调试：适合测试失败、线上 bug 复现、SQL 慢查询。要求 AI 先收集证据，再给修复方案。

代码审查：适合每轮实现后使用。重点看越界修改、隐藏风险、兼容性和测试缺口。

执行计划：适合大需求。把大任务拆成多个可提交的小任务，每个任务都能独立回滚。

文档沉淀：适合完成后使用。把项目约定、接口口径、踩坑经验补到文档里。

这些技能听起来朴素，但它们正是普通开发者日常最容易省略的步骤。AI 写代码越快，越需要这些步骤把节奏稳住。

Java 项目里的具体用法

以“库存预占接口支持批量 SKU”为例，我会这样组合 OpenSpec 和 Superpowers。

第一轮，先用 OpenSpec 定义变更：

1
2
3
4
5
6
7
8
9
10
11
12
/opsx:propose batch-inventory-reservation

需求：
库存预占接口支持批量 SKU。
同一订单请求必须幂等。
库存不足时返回明细级失败原因。

项目匹配要求：
- 读取库存模块现有扣减、释放、流水表和库存锁实现；
- 找出项目使用数据库乐观锁、Redis 锁还是 MQ 异步扣减；
- 参考已有异常码、日志格式、事务注解和测试写法；
- 只生成 proposal/design/tasks/specs，不写业务代码。

第二轮，用具体 skill 审这个变更：

1
2
3
4
5
6
7
8
请使用 requesting-code-review skill 审查 openspec/changes/batch-inventory-reservation。
重点输出：
1. 需求是否清楚；
2. 是否遗漏异常流程；
3. 是否遗漏幂等、并发、事务、回滚；
4. tasks 是否能小步执行；
5. 测试是否覆盖成功、失败、重复、并发、回滚；
6. 哪些问题必须在 apply 前确认。

第三轮，再进入实现：

1
2
3
4
5
6
7
8
9
/opsx:apply batch-inventory-reservation

请结合 executing-plans skill 执行。
执行要求：
- 严格按照 tasks.md 小步实现；
- 每完成一个步骤先展示 diff；
- 测试失败时先分析日志，不要猜；
- 不做无关重构；
- 不引入项目没有使用的新框架。

第四轮，改完后做 diff 审查：

1
2
3
4
5
6
7
8
请使用 requesting-code-review skill 检查当前 diff。
重点看：
1. 是否符合 proposal/design/tasks/specs；
2. 是否有超卖风险；
3. 幂等记录是否和库存事务一致；
4. 异常时是否会留下脏数据；
5. 是否兼容旧接口；
6. 测试是否覆盖明细级失败原因。

第五轮，验证通过后同步归档：

1
2
/opsx:sync batch-inventory-reservation
/opsx:archive batch-inventory-reservation

这样一套下来，AI 不再只是“帮我写个接口”，而是在规格、计划、实现、测试、审查、沉淀之间形成闭环。

三条使用铁律

第一条，不清楚就先问，不要让 AI 猜。

比如“库存不足怎么处理”这句话就不够清楚。是整个请求失败，还是允许部分成功？失败原因要不要返回到明细级？是否要写库存流水？是否要发 MQ？这些如果不问清楚，后面代码一定返工。

第二条，大任务必须拆小步。

一个需求如果同时改 Controller、Service、Mapper、表结构、消息消费、定时任务、测试，AI 很容易失控。拆小步以后，每一步都能审查 diff，也方便回滚。

第三条，测试和 diff 是最后防线。

不要相信“代码看起来对”。对于 Java 后端，至少要跑相关测试；没有测试也要做手工验证清单。diff 里如果出现无关重构、新依赖、无说明的表结构变化，都要停下来审。

踩坑提醒

第一个坑，是把 Superpowers 当成夸张提示词。比如“请用超级能力帮我写代码”，这种没有实际约束。要明确指定它做澄清、计划、测试、调试、审查。

第二个坑，是只在编码后使用。Superpowers 最有价值的时机其实是编码前：需求不清楚先问，风险不明确先列，计划不稳定先拆。

第三个坑，是让它一次性自由发挥。AI 最擅长补全，但补全太多就可能越界。越复杂的需求，越应该让它分阶段交付。

第四个坑，是不让它看真实项目。没有 pom.xml、同类代码、Mapper XML、测试用例，AI 很容易写出“标准答案”，但不是你项目里的答案。

第五个坑，是跳过复盘。一次需求做完后，如果没有把经验沉淀到 AGENTS.md、OpenSpec specs 或项目文档，下次还会踩同样的坑。

总结

Superpowers 不是让 AI 变神，而是把成熟开发者的工作纪律装进 AI 协作流程里。它提醒我们：先澄清，再计划；先测试，再实现；先看证据，再调试；先审 diff，再合并；最后把经验沉淀下来。

在 Java 项目里，我最推荐把 OpenSpec 和 Superpowers 组合起来：OpenSpec 管规格，Superpowers 管过程。前者让需求变清楚，后者让实现不跑偏。

真正有建设性的 AI 编程，不是让模型替你一路狂写，而是让它在每个关键节点都能停下来问一句：这个需求清楚吗？这个计划可验证吗？这个改动安全吗？这个测试够吗？

参考资料