AI 写代码总跑偏?两个工具就够了

AI 写代码总跑偏？两个工具就够了

用 AI 写代码半年多，我踩过的坑比写过的功能还多。

最典型的一次：让 AI 给项目加个缓存层，它上来就写代码，写到一半开始重构整个存储模块。我喊停它还不乐意，说「这样更优雅」。

问题不是 AI 不行，是你让它自己管自己。

后来我搭了一套组合工作流，把这个问题彻底解决了。今天分享出来。

一、AI 编程的三个死穴，你中过几个？

用 AI 写代码的人越来越多，但痛点出奇一致：

① 需求漂移 — AI 在聊天记录里找需求，聊着聊着就忘了最初要做什么。你让它加缓存，它给你重构存储。

② 流程失控 — 上来就写代码，没有设计，没有测试，没有审查。代码跑通了，但一个月后没人看得懂。

③ 纪律缺失 — 同样的需求，今天的代码优雅，明天的潦草。质量像过山车，毫无一致性。

根源很简单：没有规范约束的 AI，就像没有图纸的施工队——能干，但干出来的东西你敢住？

二、解法很直接：一个管方向，一个管纪律

答案是两个工具接力：OpenSpec 定方向，Superpowers 带节奏。

OpenSpec：让 AI 在动工前先把话说清楚

它是个轻量级的 Spec-Driven Development 系统，核心就 4 条命令：

bash
/opsx:explore    # 先聊清楚需求/opsx:propose    # 一键生成 proposal + specs + design + tasks/opsx:apply      # 按任务清单逐个实现/opsx:archive    # 做完归档，沉淀为知识库

一条命令下去，自动生成标准化产物：

text
.openspec/changes/add-cache-layer/├── proposal.md    # 为什么要改？├── specs/│   └── cache/spec.md   # Given/When/Then 验收场景├── design.md      # 技术方案 + 为什么选这个方案└── tasks.md       # 复选框任务清单，做完一个勾一个

以后想回顾，打开 proposal.md 就知道当初的决策逻辑。 不用靠「我记得当时好像是……」。

Superpowers：让 AI 在写代码时有纪律

如果 OpenSpec 是设计图纸，Superpowers 就是施工规范。

它的核心理念就一句：Process over Prompt（流程大于提示词）。给你一套技能套装：

三、关键分工：头尾归 OpenSpec，中间归 Superpowers

两个工具不是竞争者，是接力队友：

一句话记住：

具体到 6 个阶段：

四、最精彩的环节：TDD 如何嵌入实施阶段

实施阶段工作量最大，也是 Superpowers 的核心战场。

tasks.md 告诉你做什么，TDD 告诉你怎么做。

一个任务的完整执行过程长这样：

text
tasks.md 里的一项：  - [ ] 实现缓存读写功能        ↓TDD 接管，三步走：        ↓  RED:    先写测试 → "cache.get('key') 应返回缓存值" → 跑，果然失败  GREEN:  写最少代码让测试通过 → 跑，过了  REFACTOR: 消除重复，优化结构 → 跑，还是全绿        ↓  ✅ 勾选 tasks.md → code-review 自动触发

每个任务都走这个循环。 质量方差被压缩到最小——不再有「今天手顺写得特别好」和「今天状态差写得烂」的区别。

五、完整流程一张图

6 个阶段 + 产物结构 + 技能嵌入点，一目了然：

四条铁律，踩过坑才总结出来的：

1. brainstorming 灵活嵌入 — propose 前做方案探索，或在之后做设计深化
2. 规格和代码双向同步 — 实现偏离规格时，必须同步更新文档，不许「文档过时」
3. 一份制品，一个真相源 — 所有东西在 openspec/changes/ 下，不搞多份计划
4. verify + code-review 互补 — 前者看「做没做对」，后者看「做没做好」

六、怎么开始？四周渐进式上手

别想一步到位。分四周来，不容易放弃：

Week 1 — 只装 OpenSpec

找一个简单功能，跑通整条命令链：explore → propose → apply → verify → archive。先感受「写代码前把需求定下来」的价值。

Week 2 — 加入 Superpowers

体会 brainstorming 的「先问再写」，尝试给一个任务走 TDD 三步循环。你会发现写代码的节奏完全变了。

Week 3 — 开启 Agent Skills

只开几个核心技能，观察代码覆盖率和结构约束的变化。别一次开太多，消化不了。

Week 4 — 完整跑通一个中等功能

把三件套串起来，关键检查项同步到 CI。这时候你会拥有一套可复制的标准流程。

七、进阶彩蛋：加入 GitNexus 的三工具联合流程

如果你的项目对代码影响有要求，可以再加第三个工具 GitNexus：

text
用户需求  → Capture — 需求摘要确认  → brainstorming — 多方案探索  → opsx-propose — 生成全部规格文档  → Review — 人工审查（7项清单）  → git-worktrees — 隔离开发环境  → writing-plans — 细化任务到2-5分钟粒度  → opsx-apply + TDD + GitNexus影响分析  → verify + review + commit  → opsx-archive — 归档沉淀

GitNexus 的独门绝技：编辑前自动跑影响分析。如果改动影响范围标记为危险级别，自动暂停要求确认——避免「修 A 炸 B」的经典事故。

八、组合用 vs 单独用，差距在哪？

多出来的文档不是负担。 它解决的是一个真实痛点：一个月后，你忘了当初为什么做这个设计决策。

最后的实话

这套组合不承诺让你写得「更快」。

它的价值在于三件事：

• 可预测 — 同样的流程跑 10 次，质量方差极小
• 可追溯 — 任何决策都有文档可查，不做「考古学家」
• 可复制 — 换功能、换项目、换人，同一套检查清单照用

AI 编程从「碰运气」到「工程化」，就差这一套工作流。

工具安装：

bash
npm install -g openspec          # OpenSpec CLInpx oh-my-claudecode install     # Superpowers 技能集npm install -g gitnexus          # GitNexus CLI（可选）