怎么把 OpenSpec 和 Superpowers 真正组合成一套企业级 AI 编码工作流我为什么会写这一系列的文章

我为什么会写这一系列的文章

过去几个月，我一直在探索如何让 AI 编码助手更可靠。在公司内部也做了很多针对团队合作模式下如何进行Agentic Coding开发的尝试。
国内国外网上的文章、资料、视频也看了很多，基本都在讲如何高质量的完成一个功能？如何让AI开发之后能自行测试验证？质量也都很高，确实受益匪浅，但当你在生产环境中实际使用就会发现：

实际写出的代码很容易和初衷偏差过大
工程底子太差没有什么架构设计，导致实现的代码维护性太差
弱模型（比如Cursor的auto）实现计划的时候丢失或者实现错误
上次写了一个功能，本来可以复用，结果又造了个轮子
合作开发一个Feature，互相不知道设计思路、开发进度....

诸多问题在前面的文章中也说过了，这里不再赘述，那难道说Agentic Coding就只能节省我们的时间用来去摸鱼？

如果只是写一些hobby project，那自然没问题，能省则省。但如果你对研发和架构之道有自己的追求，Agentic Coding能够让你把更多的时间投入到架构设计和研发本身，而不是去花费体力去做基础开发和实现。

我对于团队的要求很简单，Agentic Coding节省的是编写代码、单元测试、E2E测试等工作的体力，但是需要花费更多的心力去设计架构、规范行为、做好文档和知识传递。

在思考和实践的过程中，Superpowers的工具链和OpenSpec的流程设计给了我很多启发。

前面几篇文章介绍了OpenSpec和Superpowers的基本使用方法、使用经验和详细的能力对比，这篇文章以企业的视角来说一下如何将它们结合起来，形成一套完整的企业级AI编码工作流。

对于融合我的演进思路

上面说了那么多 Agentic Coding 在团队协作中的痛点，核心其实就是两个：想不清楚和做不干净。

想不清楚，是因为 AI 拿到一个需求就直接开干，不去管项目现有架构、历史设计、团队规范。
做不干净，是因为写完代码就算完了，没有测试保障、没有代码审查、没有可追溯的记录。

OpenSpec 和 Superpowers 各自解决了一个方面，但都不完整。

1. OpenSpec：想得清楚，但做的时候“粗心大意”

OpenSpec 是 change-centric 的——围绕"变更"来组织开发流程。每个功能需求都会经历 proposal → design → specs → tasks → apply → verify → archive 的完整生命周期，所有产物都有文档留存，团队里谁都能看懂这个功能为什么这么做、做了什么、怎么做的。而且提供的explore的skill我觉得特别好用，五星推荐，可以查看我之前的文章。

但是当你实际按照OpenSpec官方的指导创建了change之后就会发现以下几个问题：

每个任务都比较清晰，但是具体应该怎么实现还需要结合spec来执行之前再想？
测试的任务只要求测，但是并不包含测试计划。
任务列表整体结构类似流程帐，完全无法确定它会怎么执行。

这里给大家看一个改造之前生成的task中的一段

...
## 2. 修复向量删除策略

- [ ] 2.1 修复 `.../generater.ts`
  - [ ] 2.1.1 分析当前 `rebuild` 函数的向量删除逻辑
  - [ ] 2.1.2 添加 `rebuildingModel` 检查（关键修复）
  - [ ] 2.1.3 仅在模型重建场景保留旧向量
  - [ ] 2.1.4 其他场景（如果有）应立即删除旧向量
  - [ ] 2.1.5 添加日志输出，标识当前处理场景
  - [ ] 2.1.6 测试模型重建场景（验证旧向量保留）
  - [ ] 2.1.7 测试非重建场景（验证旧向量删除）
...

你可以用 OpenSpec 规划得漂漂亮亮，tasks.md 里列出N个任务，但到了apply阶段，AI 可能：

跳过测试直接写实现
代码风格五花八门
改了 A 功能，B 功能的测试挂了但没发现
写着写着偏离了 design.md 的设计

2. Superpowers：做得干净，但缺乏大局观

Superpowers 是 behavior-centric 的——用行为约束来保障代码质量。强制 TDD（先写失败测试再写实现）、自动 code review、git worktree 隔离环境、子代理并行开发。
其中也有一个大概的执行路径，思考（brainstorming）-> 计划（write-plan）-> TDD执行 -> -> code-review -> finish，跟标准的TDD开发流程基本上是一致的。如果你是个经验丰富的开发人员，知道什么时候执行什么，什么场景用什么skill，那你会把它用的很好（别指望AI会保证自己发现对应的Skill然后加载执行）。
SuperPowers的设计理念真的特别精彩，比如“技能调用的1%原理”、“七大说服原理”、“给小白创建任务”等。非常推荐仔细阅读，且阅读2遍以上。其中很多道理对于做Harness Engneering很有帮助。（最近一直在读代码和文章了解这方面，也一直在实践，欢迎大家一起讨论。）

但是，对，我要说但是了。但是Superpower积累的知识是按迭代的，每一轮生成的design和plan文档更类似于产品给你的Prd和技术写的详细设计，但是如果你想知道某个功能是怎么定义的，需要横向翻阅大量的文档来找到其中某几个修改过这个功能的文档，而且还不知道是否对了，不要以为你写了文档AI就会记住，就会找到，就会正确用。
在这种情况下，你对于某个功能的开发很可能逐渐的偏离，当发布之后发现这里有影响，那里功能出现冲突。我不止一次遇到：

完整的了解项目里对应的功能模块都做了什么设计？
之前的变更做了什么决策，为什么这么做？
找不全某个功能模块到底做了什么？

这意味着每次开始新功能，AI 都像是一个新入职的员工，只知道做过的功能或者某些看到的功能，然后直接开始开发，视野特别窄。

3. OpenSpecPowers（魔改版）

OpenSpecPowers是我造的概念，其实就是把两者按照公司级的角度做了一次融合。（顺带一提，OpenSpecPowers这个技能库我正在写，等测试稳定了之后会开源出来，敬请期待！）。
我把OpenSpec和Superpower在流程上做了整合，流程按照OpenSpec来，并用SuperPower来武装OpenSpec。通过修改OpenSpecPowers创建的工件会完整的呈现出文档引用，当实现需要的时候直接读取，而不是再去搜索

proposal.md

## Why

Users may paste image URLs inside plain text instead of sending structured `image_url` blocks. The agent should make current-turn image inputs visible to the model while avoiding repeated historical image context, which increases visual-input cost and stale URL failures.

Related design context: 
- `docs/superpowers/specs/2026-04-02-deepagents-context-engineering-design.md`
- `docs/superpowers/specs/2026-04-04-threads-prepare-submit-design.md`
- `docs/plans/2026-04-03-agent-image-message-support-design.md`
- `openspec/specs/model-image-url-sanitization/spec.md`.
...

design.md

## Context

Image input currently works when clients send explicit `image_url` blocks or `imageUrls`, but user-entered plain text can still contain image URLs. Sending every historical image block on every model call is also wasteful: it repeats visual input, increases stale URL failures, and makes cost less predictable.
More details read from `docs/superpowers/specs/2026-04-02-deepagents-context-engineering-design.md`
...

task.md

# Tasks — agent-message-sink-middleware

> 实现须遵循 TDD；参考设计：[`design.md`](./design.md)，规格：[`specs/agent-message-sink/spec.md`](./specs/agent-message-sink/spec.md)。
>
> 任务 1、2 可并行；任务 3 依赖任务 1；任务 4 依赖任务 1+2+3；任务 5 依赖任务 4。

## 1. MessageSink 协议 + RunContext + MessageWriteMiddleware（核心）

- [x] 1.1 **RED**：写失败单元测试 `xxx`：
  - mock `AgentState`（messages 末尾为 `AIMessage`），调用 `aafter_model`，验证 `mock_sink.on_ai_message` 被调用且入参为该 AIMessage
  - mock sink 为 None，验证 `aafter_model` 不抛异常（WARNING 日志）
  - mock sink 的 `on_ai_message` 抛异常，验证 `aafter_model` 捕获后 Agent 不中断
  - mock 工具调用 handler 返回 `ToolMessage`，调用 `awrap_tool_call`，验证 `mock_sink.on_tool_message` 被调用
  - handler 返回 `Command`，验证 sink 不被调用

- [x] 1.2 **GREEN**：实现 `xxx`：
  - `MessageSink` Protocol（`on_ai_message / on_tool_message` 均为 async）
  - `RunContext` dataclass（`message_sink: MessageSink | None = None`）
  - `MessageWriteMiddleware(AgentMiddleware)`：`aafter_model` + `awrap_tool_call` 实现，含异常捕获和 WARNING/ERROR 日志
  - `_get_sink(runtime: Runtime) -> MessageSink | None` 辅助函数

- [x] 1.3 **REFACTOR**：确认 `_get_sink` 边界测试（runtime.context 为 None、context 无 message_sink 字段）

对比OpenSpec原来的change发现差别了吗？不一样的地方只要有三点：

文档之间的依存关系会完整的存储在文档内部，不再依靠SKILL提示，不再依靠AI自己Grep搜索
OpenSpec的组织形式完全变了，不再是要做什么，而是怎么做，做的时候要用TDD来实现
任务之间的依存关系和并行关系在任务开始之前已经分析规划好了

如果做到这种效果呢？可以按照下面四个阶段来逐步实现。

阶段 1：从想法到可写进 OpenSpec 的输入

这个阶段的目标是把想法搞清楚，当然这个想法可能是一个idea，一份PRD，一个架构变更需求，甚至是新建一个项目。这个阶段主要靠的就是openspec的explore和superpowers的brainstorming。

flowchart TB
  I[想法 / 问题 / 需求] --> B[Superpowers: brainstorming]
  B --> E{需要可执行拆分?}
  E -->|是| P[Superpowers: writing-plans<br/>依赖 / 并行 / 验收点]
  E -->|否| R[结论足够写 proposal]
  P --> R
  B -.->|可选| X[opsx:explore + 读 openspec/specs<br/>与历史 changes 对齐现状]
  X --> B

explore：负责探索想法和代码，你可以用各种方式来给explore提供子弹（代码、文章、数据库数据、ELK日志等等）来讨论和思考，直到挖掘到你满意为止。

在公司里为了让explore发挥到最大价值，我们把所有程序能碰到的设计全做了CLI包装让AI可用，同时我也写了一个记忆插件，团队中每个人的日常执行的动作都会产生一些行为记忆，还有一种三体人模式，直接共享记忆。
brainstorming：负责探索的内容细化为设计文档。得益于Superpowers的强大，当你的探索中存在一些开放问题或者没考虑到的问题都会帮你一一澄清，然后落地到到你的设计文档中。
write-plan：这个技能会按照TDD的方案，把执行者当做小白来，创建尽量细化的任务。这里创建的任务非常适合派发给子Agent执行。因为每个子Agent其实都是干净的上下文，任务越清晰，子Agent执行的效果越好。

这个节点的执行顺序是 explore -> brainstorming -> write-plan，接下来唠点点干货。

能不能跳过？

团队第一次接触这个阶段的时候一定会觉得太麻烦、太复杂、有这个时间都干完了。确实，但是这个其实是在赌博，复杂性是在变化的，一个简单的问题，一旦被复杂的能力依赖很可能就演变成了一个重要的兼容点。问题往往就发生在你自信的觉得“这个一定没问题”。
这样答案自然就有了：这个阶段可以跳过。

当你的问题是清晰明确的，你对代码了若指掌，这个阶段完全可以跳过。这种情况往往是我刚写了个功能要继续修改。
除了上面的情况我建议无论是多小的功能至少保留explor来验证想法，看看有没有漏洞。

一些实用的经验

设计性的问题先用Explore：设计性的问题往往需要从点到面的讨论，其中需要讨论的大部分都是决策性的问题。如果你所有信息都比较明确可以直接进入。就算不是设计性的问题也推荐你找AI一起探索下。
固定性的问题直接进入brainstorm：迭代现有功能，且功能设计清晰、任务明确。这个时候你需要的不是再探索，而是一份详细设计，直接使用头脑风暴即可，但是这里要注意，一定要告诉AI，执行头脑风暴的时候参考OpenSpec的历史文档，因为你开发的功能很可能已经经历过规格变化或者影响了历史上的功能开发。推荐给大家一段规则，这个是我要求团队中所有成员必须写进Cod ing工具中的一段

## 1. **superpowers:brainstorming**技能触发的改进要求
> 进行BrainStorming的时候应该善于使用`opsx:explore`技能的架构探索能力和OpenSpec历史积累的specs/changes文档来辅助`brainstorming`技能来做详细设计。

- 调用 brainstorming 技能的时候要充分的了解当前的项目的架构和历史设计，除了查阅Superpower生成历史设计、实现文档。还应该：
  - 充分参考OpenSpec的specs文档和changes中的设计来辅助进行BrainStorming的思考和决策。
  - 充分使用`opsx:explore`技能的架构探索能力来了解和思考当前项目既有的架构和设计。
- OpenSpec的`openspec/specs`目录中存放了当前项目中不同功能的规格说明书，每个spec中的`Purpose`，`Requirements`都充分的描述了对应功能的信息，可以参考这些信息来辅助进行BrainStorming的思考和决策。目录结构类似：
\`\`\`
openspec/specs/  
├── feature1/  
│ └── spec.md  
├── feature2/  
│ └── spec.md  
└── ...
\`\`\`
- OpenSpec的`openspec/changes`目录中存放了当前项目中不同功能的变更记录，分为进行中的和已经完成归档的。
- 进行中的直接在`openspec/changes/`目录以单个change文件夹的形式存在，已经完成归档的直接在`openspec/changes/archive/`目录下查看。
- 无论是进行中的还是已经完成归档的change，其目录结构都是类似的，都包含了`proposal`，`design`，`tasks`，`specs`等目录，可以参考这些信息来辅助进行BrainStorming的思考和决策。
目录结构类似：
\`\`\`
openspec/changes/  
├── change1/  
│ ├── proposal.md  
│ ├── design.md  
│ ├── tasks.md  
│ └── specs/  
│ └── ...  
├── .../  
│ └── ...  
├── archive/  
│ └── 年-月-日-需求目标/  
│ ├── proposal.md  
│ ├── design.md  
│ ├── tasks.md  
│ └── specs/  
│ └── ...  
└── ...

\`\`\`

阶段 2：OpenSpec 工件链（顺序与闸门）

经历过阶段1之后这里的情况会变得很简单，顺着执行即可。如果没有阶段一，这里对于每个工件都要提出额外的要求。OpenSpec的工具链之前分享过，可以查看这篇文章。

这个阶段的目标是把「要做什么、怎么设计、规格增量、任务清单」固化成 change；design 未收敛前不写 specs；若有 Superpowers 设计/计划文档，在对应工件里写明引用路径。先看看流程的示意图

flowchart LR
  N[opsx:new / ff 起 change] --> PR[proposal]
  PR --> DS[design<br/>收敛 Open Questions]
  DS --> SP[specs]
  SP --> TK[tasks]

  DS -.->|闸门| G{Open Questions<br/>已回答?}
  G -->|否| DS
  G -->|是| SP

  PR -.->|引用| D1[Superpowers design]
  DS -.->|引用| D1
  SP -.->|引用| D1
  TK -.->|引用| P1[Superpowers plan]

  PR & DS & SP & TK -.-> R[Sub Agent: 工件 review]

改造之前团队实际使用OpenSpec的时候发现Coding Agent在传统的OpenSpec执行中一旦涉及到其他Spec或者任务的时候会粗暴的全工程grep，尤其是进入sub agent没有了前文之后。虽然靠sub agent控制了上下文窗口，但是Token是真的爆炸啊。

我在这里的设计参考了Skill的渐进式披露，让不同阶段的工件充分的引用brainstorming中不同阶段的产物，一旦需要资料引用，直接读取，而且Task中的任务在创建的时候要求按照SuperPowers生成的plan文件来创建任务详情，所以也间接服用了“小白式”任务的书写风格，Sub Agent迷失的情况变得少了很多，下面继续上干货。

没有第一阶段的时候怎么控制

没有第一阶段其实只是缺少了SuperPower的设计产物，但是你并不缺失SuperPowers这个技能库，依然可以按照阶段流程图中对不同阶段的要求来让AI参考SuperPowers提供的设计理念。只不过你依然告诉清楚AI你要干什么（相信我，虽然这种方式可行，执行几次之后你就会发现，真的不如在第一阶段好好说话。[微笑]）。这个时候就使用OpenSpec的new+continue的方式创建就好了

new：阐述清楚你要做什么，自己起一个适合这个change的名字（也可以不起，AI会给你）。
continue：重点来了，对于每个阶段的Continue你都应该按照我的流程图中的引用要求，可以参考我给团队定制的规则。

## 1. **opsx:new**技能触发的改进要求
> **opsx:new**负责新建变更，触发的是否如果上下文中决定Feature Change的名称。 

## 2. **opsx:continue**技能触发的改进要求
> **opsx:continue**会逐步的推进Feature Change中的工件创建。不同的工件**必须**要参考Superpowers的设计和实现文档，而且**必须**要在工件文档中注明Superpowers的设计和实现文档的引用，按照markdown的文档的格式标记。

### Proposal工件**必须**要参考并引用Superpowers设计文档
  - 按照**opsx:continue**技能的要求从Superpowers设计文档提取`Why and what`创建工件内容
  - Proposal工件中标注引用的Superpowers设计文档位置
### Specs工件和Design工件按照OpenSpec的要求在创建了Proposal工件之后可以继续推进，但是**必须**要参考并引用Superpowers设计文档
  - 执行**opsx:continue**技能时从Superpowers设计文档提取Specs工件和Design工件各自需要的信息，创建工件的对应内容
  - Specs工件和Design工件各自的markdown文档中也必须标注引用的Superpowers设计文档位置
  - 如果Specs工件和Design工件之间没有强依赖可以创建两个Subagent并行创建两个工件
### Tasks工件按照OpenSpec的要求根据牵制的工件推进，但是**必须**要参考并引用Superpowers实现文档
  - 执行**opsx:continue**技能时从Superpowers实现文档中提取任务设计信息，创建工件内容
  - 工件的markdown文档中也必须标注引用的Superpowers实现文档的位置

第一阶段充分讨论后的执行

第一阶段充分讨论之后你可以直接按照图中的方案和接的refer，直接opsx:ff了。但是依然要给你的工具说明每个阶段要怎么使用SuperPowers的工具，比如在Claude Code的CLAUD.md、Cursor的rule、Codex的AGENTS.md等

阶段 3：实现与验证（`opsx:apply`）

恭喜你，进入这个阶段之后你可以直接开始实现了，目标很简单按 tasks.md 执行；TDD；可并行用子代理；有证据再声称完成；合并前做 code review（P0/P1 必处理）。

flowchart TB
  T[读 tasks.md<br/>依赖 / 并行] --> W{可并行块?}
  W -->|是| PA[subagent-driven-development]
  W -->|否| TD[RED-GREE-REFACTOR]
  PA --> TD
  TD --> V[跑测试 / 必要时的集成或手工验证]
  V --> CR[code review<br/>P0/P1 必修]
  CR --> F{任务是否清零?}
  F -->|否| T
  F -->|是| OK[进入归档准备]

特别要注意（注意，我说的是特别要注意）

尽量给Apply提供执行计划：这个特别看模型的能力，我给团队定制的规则中在第一阶段执行之后就随便要求Apply之前要给出一个引导提示词，因为团队中并不是每个人都有高级模型的，我们Team推进大家使用Cursor，所以大部分时间大家都使用Auto模式。模版可以按照这样。

- **change创建完成之后为opsx:apply提供引导执行的Prompt**，引导话术可以按照下面的形式提供，根据Task的实际设计情况结合superpowers:subagent-driven-development来规划执行引导的Prompt。比如：
\`\`\`
/opsx:apply 开始实现xxx-change，按 tasks.md 章节顺序：

Phase 0 → Phase 1+Phase 2 串行 → Phase 3 → Phase 4 → Phase 5 → Phase 6 收口
Phase 0/1/2 适合 superpowers:subagent-driven-development 派单（重命名 + 纯函数）
Phase 3/4 适合主线 TDD（单文件高内聚）
Phase 5 含手工 e2e（截图归档）
Phase 6 必须派 code-reviewer 子代理 review，P0/P1 必修
\`\`\`

上下文窗口的问题：这个问题对实现效果真的特别重要，尤其如果使用的是普通模型。前面两个阶段尽量在一个上下文中实现，当然如果explor讨论的比较多很可能也有多个。不过最重要的是执行apply的时候一定要新开一个上下文，使用1中创建出来的执行计划的引导词来执行。设置是每个大的Task Phrase都创建一个窗口来调用Apply。看你怎么引导Agent了。
代码review：团队内部我创建了针对性的review skill，所以在每次执行的时候在Agent的设定中要求必须review，且必须使用sub agent的模式执行review。大家在这个时候可以自行找review的库或者自己找一个
窗口切换的上下文传递问题：在写特别大的Feature的时候会多次切换上下文，当然，如果有条件尽量拆分开，用多个Agent实现，也可以让其他同事一起开发。但是如果你真的遇到这种情况为了防止一些实现过程的经验丢失（比如工程启动的方式、调试的问题等），所以处理上有几种方式既能方式上下文压缩导致随机丢失信息，也能得到更好的上下文体验。
1. Cursor：新建Agent，用@Past Chat的形式引用历史会话，告诉Agent先启动Sub Agent总结，同时提示Agent根据实际情况查看过往会话。
2. Claude Code：Claude Code天然有Team模式，这个是最方便的，直接告诉Claude Code创建Team的时候独立一个TeamLeader，告诉每个Agent执行的时候出现踩过的坑用内置的mailbox给TeamLead通信，遇到问题可以先询问TeamLeader。
3. 其他：OpenCode、PICoding等我没太多研究，一种通用的方案就是自己写一个handoff的skill，主动调用一下，让AI把这个上下文中重要的内容Dump到临时文件中。新Session中引用即可。
  这个阶段的经验完全取决于你个人，这里的经验是我觉的明显提升了我的每个change的实现质量。当然你可能觉得太啰嗦，那就直接Apply吧。就像SuperPowers也有不少人说它只是一种Coding巫术。

阶段 4：归档（`opsx:archive`）

我觉得规格驱动开发对团队贡献最大的就是Spec的Delta和Merge。对功能模块所有的知识维护几乎都在这里。这个阶段的目标就是最终验证通过，把开发中的Change和设计文档归入archived目录中，方便以后查阅。

flowchart TB
  Z[最终验证:相关测试全绿] --> AR[opsx:archive]
  AR --> CP[复制superpowers文档]
  CP --> LK[修正工件内链接路径]
  LK --> SY{需要把 delta 合回主 specs?}
  SY -->|是| SYNC[openspec-sync-specs 等]
  SY -->|否| DONE[归档结束]
  SYNC --> DONE

如果你仔细看这个流程会发现跟OpenSpec的标准归档流程有一个差别归档了superpowers的文档。原因是工程的知识积累和传承都靠OpenSpec的标准来传递而不是SuperPowers。这也是我觉得SuperPowers做的唯一缺点。

SuperPowers的管理更偏向文档，而文档是给人看的，当你去看一个SuperPowers的文档的时候确实很方便，对于一次的修改的内容都在其中，所以管理的粒度是一次实现。

也许你认为“这很好啊，每次看的时候都很方便”，其实这是错的，AI不会跟人一样文档之间线索越多、内容越偏代码化AI用起来会越舒服，下面这段甚至可以直接生成测试用例让AI执行。

#### Scenario: Normalized message persisted

- **WHEN** `xxx` 将 AIMessage content 从 JSON 转换为纯文本
- **AND** `MessageWriteMiddleware.aafter_model` 随后触发
- **THEN** `message_sink` 收到的 AIMessage content 为纯文本，`additional_kwargs` 含协议字段

而OpenSpec是面向功能模块的，而且Spec的编写格式更适合AI读取。另外一个模块可能经历过多次改进，而一个迭代也可能改动多个模块，所以当你规划一个迭代的时候你不仅要了解你要修改哪些模块（spec），也要知道还有什么change在改动这个模块，设计上是否有冲突、是否可以复用。

当然OpenSpec也不是没有缺陷，这几个我觉得最重要的缺陷：

Archived Change爆炸：一个持续演进的工程会有大量的文档，这不仅导致AI扫描文件困难，维护工程成本也会逐渐变高。
Specs缺少管理和概览：Specs下其实放的都是对不同模块的规格说明，这些模块完全有AI自动发挥，这样一个工程长期执行会导致这里的功能模块出现脑裂的情况，越来越难维护。
跨工程的的规格管理：这个其实不只是OpenSpec的问题，再一个企业内的成熟产品上使用Agentic Coding工具其实都会遇到这个问题。

不过瑕不掩瑜，这几个问题也是可以处理的，按照规格驱动开发和分治的思路持续演进都是可以解决的。

另外在给大家提个醒，不要试图自己去读OpenSpec的change，你翻文档绝对翻不过AI，多食用explore技能，整个OpenSpec目录当知识库去做RAG就好了。

写在最后的

额外啰嗦几句

这个流程并不是所有模型都能完美的遵循指令，这就需要在AI做不到的时候你来帮他做到
受限篇幅还有很多太细节的地方并没完全写出来，大家多摸索多讨论吧。比如每个工件创建之后再现有的流程中都会启动sub agent执行review，别把review的概念限制在代码层面，AI时代要敢想。
另外要注意代码责任的划分，AI帮你设计、规划、实现之后并不代表这份代码不需要你负责了，以AI生成代码的速度靠人力是根本review不过来的，这个OpenAI、Anthropic等公司都早已经意识到了，所以你要投入更多精力在这些生产验证环节。

至此，企业级Agentic Coding的经验分享就都写完了，剩下的篇幅想唠几句。按照企业的概念就是有事忙的人员可以先撤退了。

我看到很多人说AI时代来了，程序员要失业了、质管要失业了、这要失业了那要失业了，这在我看来和以前的贩卖焦虑差别不大。
诚然一波浪潮来了之后一定会拍倒一批人，这并不是AI来临造成的，而是人类演进的方向就是人均可分配资产提高。哪怕是再穷的山区再中国的脱贫脚步下也在一步步的提高生活、教育和医疗水平。
以前在听过腾讯一个什么BG的老大说过一句话挺有道理的：做技术的人只有两个方向要么你不听的革自己的命，要么别人革你的命。所以不要焦虑，自己刷新自己的认知跟上时代的节奏，剩下的我就交给时间吧。

好啦，有点矫情了，最近有些忙，一只在捣鼓Harness Engineering相关的内容，忙过这段时候再整理整理自己的心得跟大家讨论。

怎么把 OpenSpec 和 Superpowers 真正组合成一套企业级 AI 编码工作流