从 Vibe Slop 到工程流水线：我用 OpenCode 搭了条自动化研发流水线，把 AI 编程从玄学变成了可交付的产品

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-05-31 19:42

✅点击上方🔺公众号🔺关注我✅

AI 写代码不是问题，没有流程才是问题。OpenSpec 负责规格，Superpowers 负责纪律，OMO 负责多 Agent 执行，OpenCode 把它们接到同一个工作台里。

过去一年，AI 编程工具变得很猛。你给一句需求，它能生成页面、接口、测试，甚至自己修 bug。

但真正把 AI 放进业务项目后，问题很快就来了：代码是写出来了，需求对不对？边界有没有漏？测试是不是后补的？改动会不会破坏旧接口？最后这份 diff 能不能交给同事 review？

这篇文章想回答的就是这个问题：当我们拿到一个业务需求后，能不能在 OpenCode 里跑出一条完整流程，让 AI 参与需求分析、设计、任务拆分、编码、代码审查、单元测试，最后交付一份可提交的代码和测试集？

我的答案是：可以，但不要把它做成”给 AI 一句话，然后祈祷它写对”的流程。

更靠谱的方式，是把 AI 编程拆成三层：

层级	工具	解决的问题
规范层	OpenSpec	把”要做什么”写清楚，避免需求只躺在聊天记录里
流程层	Superpowers	强制需求澄清、计划、TDD、代码审查，不让 AI 走捷径
执行层	oh-my-opencode / oh-my-openagent	用多个 Agent 分工搜索、规划、编码、验证和修复

如果你只用 AI 写代码，它只是一个速度很快的实习生。

如果你把规范、流程、测试和审查都接起来，它才开始像一个能交付的软件团队。

读完这篇文章，你至少可以带走三样东西：

一套 OpenCode + OpenSpec + Superpowers + OMO 的组合思路。
一条从业务需求到可提交代码的完整工作流。
一段可以直接复制到 OpenCode 里使用的自动化研发提示词。

这套方法最适合三类读者：

已经在用 OpenCode / Claude Code / Codex 做真实项目的人。
想把 AI 编程从”个人提效”变成”团队流程”的技术负责人。
经常被 AI 生成代码坑到，想建立需求、测试、审查护栏的开发者。

如果你只是想让 AI 帮你写一个一次性脚本，这套流程会显得太重。它真正适合的是那些需要维护、需要协作、需要交付的业务代码。

一、为什么“直接让 AI 写代码”不靠谱

大家看过太多这样的演示：

“帮我写一个 3D 网页 Demo。” “帮我做一个后台管理系统。” “帮我加一个用户登录功能。”

模型生成速度很快，页面也能跑起来。问题是，真实业务开发不是 Demo。

真实项目里，一个需求通常会牵扯这些东西：

现有代码结构
数据库表和历史数据
API 兼容性
权限边界
异常场景
单元测试
集成测试
代码审查
上线风险
后续维护成本

人类开发者在写代码前，通常会先看需求、做设计、拆任务、定测试策略。但轮到 AI 写代码时，这些步骤经常被跳过。

这就是很多 AI 编程失败的根源。

不是模型不会写代码，而是我们让它在缺少上下文、缺少约束、缺少验收标准的情况下写代码。它当然会跑偏。

举个简单例子：给订单模块增加一个”已部分发货”的状态。

如果直接让 AI 写代码，它可能会做这些事：

在枚举里加一个状态
在接口里返回这个状态
顺手改几个页面文案
补一个能通过的测试

看上去差不多，但真正的问题都还没问：这个状态能不能回退？会不会影响财务结算？老订单有没有这个状态？对账系统认不认？消息通知要不要发？BI 报表里的状态口径要不要变？

换成工作流驱动的做法，AI 需要先把这些问题写进 proposal 和 design，再拆成可验证任务：状态机规则、接口兼容、数据迁移、测试用例、归档规格。代码只是其中一步，不是全部。

这就是”让 AI 写代码”和”让 AI 参与交付”的区别。

二、正确思路：不要把 AI 当代码生成器，要把它当研发流水线

我更推荐的方式是：把 AI 编程做成一条自动化研发流水线。

从业务需求开始，到代码提交结束，中间每一步都有明确产物。

业务需求 ↓需求澄清 ↓OpenSpec 提案与规格 ↓概要设计 / 详细设计 ↓任务拆分 ↓TDD 编码 ↓代码审查 ↓测试验证 ↓规范归档 ↓可提交代码

这条链路里，AI 可以做大量工作，但人不能完全退出。

人应该在三个地方把关：需求和设计是否正确、任务拆分是否合理、最终代码是否可提交。

这不是”全自动无人驾驶”，而是”有工程护栏的自动化”。

这也是本文最重要的判断：AI 编程的核心竞争力，正在从”模型会不会写代码”，转向”工作流能不能约束模型”。

如果你在团队里落地，可以先用下面这张表判断自己处在哪个阶段：

当前做法	典型表现	最大风险	下一步
直接提示词写代码	一句话需求，AI 直接改文件	需求漂移、测试后补、难 review	先引入 OpenSpec
有文档但不更新	写了设计文档，代码改完后没人归档	文档快速腐烂	用 /opsx:sync 和 /opsx:archive
有测试但不 TDD	代码写完后补测试	测试只验证实现，不验证需求	引入 Superpowers TDD
有多个 Agent 但无边界	并行很热闹，冲突也很多	多 Agent 互相踩文件	按 Wave 和文件边界拆任务
有完整门禁	spec、测试、review 都进入流程	成本略高	固化为团队命令和模板

你不需要一步到位。真正能跑起来的流程，通常都是从小处开始的。

三、三层架构：OpenSpec、Superpowers、OMO 各干各的

这套方案的核心不是某一个工具，而是分层。

1. OpenSpec：规范层

OpenSpec 负责回答”做什么”。

可通过该文章详细了解OpenSpecClaude Code编码失控了？这个轻量级框架让大模型乖乖听话！

它会为每个变更创建一个独立目录：

openspec/├── specs/│ └── auth/│ └── spec.md└── changes/ └── add-user-login/ ├── proposal.md ├── design.md ├── tasks.md └── specs/ └── auth/ └── spec.md

这里有两个关键点。

第一，specs/ 是当前系统行为的真相来源。

第二，changes/ 是这次变更的临时空间。每个需求都有自己的 proposal、design、tasks 和增量规格。

这很像 Git 的分支模型：

specs/

像 main 分支
changes/add-user-login/

像 feature 分支
/opsx:archive

像合并分支

好处是明显的：需求、设计、任务和代码不会散落在聊天记录里。

2. Superpowers：流程层

Superpowers 负责回答”怎么做才不乱”。

可通过该文章详细了解你的AI编程搭档，有了”超能力”——Superpowers Skills技能库完全指南

它不是写代码的工具，而是一套强制工作流。典型路径是：

brainstorming→ writing-plans→ test-driven-development→ subagent-driven-development→ requesting-code-review→ verification-before-completion→ finishing-a-development-branch

它最重要的规则是 TDD：

没有先失败的测试，就不应该写生产代码。

这个规则听起来很硬，但很有必要。AI 最容易犯的错，就是先把实现写出来，再补几个”看起来会通过”的测试。那种测试只能证明代码符合它自己刚写出的实现，不能证明需求被正确实现。

3. oh-my-opencode / oh-my-openagent：执行层

OMO 负责回答”谁来做”。

可通过该文章详细了解Oh-My-OpenCode 4.0重磅更新：OpenCode神器插件，一行配置拉起 8 个 Agent组队干活

它把 OpenCode 从单个助手扩展成一组 Agent：

Sisyphus：主编排器
Prometheus：需求访谈和规划
Atlas：按计划执行
Oracle：架构和疑难问题咨询
Librarian：查官方文档和开源实现
Explore：快速扫描代码库
Momus：计划和质量审查
Hephaestus / Sisyphus-Junior：执行具体任务

一个复杂需求，不应该由一个 Agent 从头干到尾。更合理的方式是：

Explore 先找项目里的相似实现
Librarian 查外部文档
Prometheus 生成计划
Momus 挑计划的问题
Atlas 或 Sisyphus 调度执行
Oracle 处理难点
review agent 做审查

这才像一个小型研发团队。

四、完整工作流应该怎么跑

下面是一条我认为比较稳的路径。

先说明一点：不是所有需求都要跑满全流程。工具链越强，越容易把简单事情做重。我的建议是按风险分层：

需求类型	推荐模式	是否需要 OpenSpec	是否需要多 Agent	人工确认点
小 bugfix	轻量模式	可选	不需要	最终 diff 和测试
单模块功能	标准模式	需要	少量使用 Explore / Librarian	proposal、tasks、最终 review
跨模块业务需求	严格模式	必须	需要 Prometheus / Momus / Sisyphus	proposal、design、tasks、review、archive
架构重构 / 上线前高风险改动	高安全模式	必须	需要 Oracle 和交叉模型审查	每个阶段都要确认

简单说：风险越高，越要前置设计；影响面越大，越要多 Agent 审查。

阶段 0：项目初始化

先安装基础工具：

npm install -g opencode-ainpm install -g @fission-ai/openspec@latest

在项目中初始化：

opencode/init openspec initopenspec configprofileopenspec update

如果使用 OMO：

bunx oh-my-openagent install

如果你的环境里还没有完成新旧包名迁移，可以改用旧入口：

bunx oh-my-opencode install

安装后建议跑一次诊断。不同版本命令名可能略有变化，以当前官方 README 为准：

bunx oh-my-openagentdoctor —verbose# 或bunx oh-my-opencodedoctor —verbose

然后在项目里准备好几个基础文件：

AGENTS.mdopencode.jsonopenspec/config.yaml.opencode/commands/.opencode/skills/

AGENTS.md 很重要。它相当于“写给 AI 的项目说明书”。

里面至少应该写清楚：

## 工作流规则

非平凡业务需求必须先走 OpenSpec。- 没有 proposal.md、design.md、tasks.md，不得写生产代码。- 编码必须遵循 TDD。- 每个任务完成后必须运行相关测试。- 完成前必须执行 OpenSpec verify 和代码审查。- 不得删除失败测试来换取通过。

阶段 1：需求澄清

如果需求很模糊，先不要写 OpenSpec，也不要写代码。

先让 Prometheus 或 Superpowers brainstorming 介入。

可以这样问：

请先帮我澄清这个业务需求，不要写代码。需求：[粘贴业务需求] 请重点确认：1. 业务目标2. 用户路径3. 范围内和范围外4. 数据模型影响5. API 影响6. 权限和安全要求7. 异常场景8. 验收标准

需求澄清阶段省下的时间，通常会在编码阶段几倍返还。

阶段 2：生成 OpenSpec 变更

需求清楚后，创建变更：

/opsx:propose add-user-login

执行后，OpenSpec 会生成：

openspec/changes/add-user-login/├── proposal.md├── design.md├── tasks.md└── specs/

这时候不要急着实现。

先看 proposal.md：

业务目标是否对
范围是否收住
验收标准是否具体

再看 design.md：

模块划分是否符合现有架构
API 和数据模型是否合理
是否考虑权限、安全和兼容性
测试策略是否可执行

最后看 tasks.md：

任务是不是太大
有没有不可验证的任务
有没有“后续完善”这种占位内容
有没有标清依赖关系

阶段 3：任务细化

OpenSpec 生成的 tasks.md 往往只是第一版。真正执行前，应该再用 Superpowers 的 writing-plans 细化。

一个好的任务应该长这样：

### Task 1: 添加登录参数校验 **Files**- Modify: `src/auth/login.ts`- Test: `tests/auth/login.test.ts` **Steps**- [ ] 写一个失败测试：邮箱格式非法时返回 400- [ ] 运行测试，确认失败- [ ] 实现最小校验逻辑- [ ] 运行测试，确认通过- [ ] 重构重复逻辑

注意，这里不是一句“实现登录参数校验”。

它必须告诉 Agent：

改哪个文件
测哪个行为
如何确认失败
如何确认通过

AI 的任务越具体，输出越稳定。

五、编码阶段：不要让一个 Agent 闷头干到底

到了编码阶段，才轮到 OMO 发挥作用。

如果需求比较小，可以直接：

ulw 按 openspec/changes/add-user-login/tasks.md 实现，严格 TDD，完成后运行测试、OpenSpec verify 和 code review。

如果需求比较大，建议走严格模式：

Prometheus 生成计划→ Momus 审查计划→ /start-work→ Atlas 按计划执行

执行时应该遵循这个顺序：

1. Explore 搜索现有实现2. Librarian 查外部文档3. 写失败测试4. 运行测试确认失败5. 写最小实现6. 运行测试确认通过7. 重构8. 运行 lint / typecheck / 单元测试9. 更新 tasks.md

这里有一个容易踩坑的点：并行不是乱并行。

只有无依赖任务才适合并行。比如：

Wave 1：- 数据模型- 测试 fixture- API 类型定义 Wave 2：- 登录接口- Token 服务- 用户查询逻辑 Wave 3：- 集成测试- 错误场景测试- 文档和清理

如果两个 Agent 同时改同一个核心文件，冲突概率会很高。并行的前提是边界清楚。

六、代码审查不能只看“有没有报错”

很多人用 AI 写代码时，最后只跑一下测试：

npm test

测试通过，就结束了。

这不够。

AI 生成代码常见的问题不是语法错误，而是：

实现了需求之外的东西
漏掉边界条件
引入过度抽象
错误处理太随意
权限检查不完整
测试覆盖的是实现细节，不是业务行为
兼容性被破坏

所以代码审查至少要看这几类问题：

1. 是否满足 proposal.md2. 是否满足 specs3. 是否只实现了范围内的需求4. 是否有对应测试5. 是否破坏兼容性6. 是否有安全风险7. 是否容易维护8. 是否有无意义抽象

可以执行：

/opsx:verify add-user-login/review

如果条件允许，我建议再换一个模型做交叉审查。比如实现用 Claude，审查用 GPT；实现用 Kimi，审查用 GLM 或 Gemini。

不同模型犯错方式不一样，交叉审查经常能发现盲点。

七、最后一步：归档，不然文档一定会腐烂

代码完成后，很多人会停在这里。

但如果使用 OpenSpec，还应该执行：

/opsx:sync add-user-login/opsx:archive add-user-login

这一步的意义是：把这次变更的增量规格合并回主规格。

否则你会得到一个很常见的结果：

代码已经变了
需求文档还是旧的
下次 AI 再读项目时，读到的是过时上下文

这就是文档腐烂。

OpenSpec 的 archive 机制，就是为了减少这种腐烂。

八、我建议的最小可行版本

如果你想在团队里落地，不要一开始就追求全自动。

先做最小闭环。

第一步：只启用 OpenSpec

目标是让每个需求都有：

proposal.mddesign.mdtasks.mdspecs delta

先把“需求不落地到文档”的问题解决。

第二步：引入 Superpowers

重点用三个能力：

brainstormingwriting-planstest-driven-development

先把“没设计、没测试就写代码”的问题解决。

第三步：引入 OMO

先使用：

ExploreLibrarianOracleSisyphus

先开两三个 Agent，跑通一个需求，再逐步增加。

第四步：建立质量门禁

每个需求完成前必须跑：

openspec validate —strictnpm testnpm runlintnpm runtypecheck

不同项目换成自己的命令。

第五步：沉淀团队模板

把稳定下来的流程写进：

AGENTS.md.opencode/commands/auto-dev.mdopenspec/config.yaml

这样新需求来了，不用重新解释一遍。

我建议团队第一次试点时，就选一个中等复杂度需求：不要太小，小到体现不出流程价值；也不要太大，大到所有问题混在一起。比如“给现有订单模块增加一个新的状态流转规则”，就比“重构整个订单系统”更适合做第一轮试验。

试点成功的标准也要提前定好：

[ ] 需求有 proposal.md[ ] 设计有 design.md[ ] 每个任务都有验证方式[ ] 至少一个核心行为是测试先行[ ] 代码审查发现的问题被记录并修复[ ] 最终 specs 被 sync/archive[ ] 交付物可以被另一个开发者接手

这比“AI 有没有一次写对”重要得多。一次写对通常是运气；流程稳定，才是能力。

还要接受一个现实：这套流程会增加前置成本。

你会多花时间写 proposal、看 design、审 tasks，也会多消耗一些 token。对于单行修复、一次性脚本、临时数据处理，这套流程不划算。直接让 AI 写，人工看一眼就够了。

但如果需求满足下面任意一条，就值得走标准流程：

涉及数据库或历史数据
涉及权限、计费、交易、风控
涉及多个模块或多个系统
需要别人 review 或长期维护
失败会影响线上用户

换句话说，越靠近真实业务，越应该把流程跑起来。

九、一个可以直接复制的工作流提示词

下面这段可以作为日常入口。

请按严格自动化研发流程处理这个需求。流程要求： 1. 先用 Explore 和 Librarian 收集代码库上下文和外部资料。 2. 如果需求不清楚，先用 Prometheus / brainstorming 澄清，不要写代码。 3. 用 OpenSpec 创建 change，生成 proposal.md、design.md、specs 和 tasks.md。 4. 等我确认 proposal/design/tasks 后，再进入实现。 5. 用 Superpowers writing-plans 细化任务。6. 编码必须严格 TDD：先写失败测试，再写实现。 7. 可以使用 OMO 并行执行无依赖任务，但必须明确文件边界。8. 每个任务完成后运行相关测试。 9. 全部完成后运行 lint、typecheck、完整测试和 OpenSpec verify。 10. 使用 code review 检查 Critical / Important 问题，并修复。 11. 最后执行 sync/archive，输出可提交 diff、测试报告和风险说明。业务需求如下： [在这里粘贴需求]

这个提示词的作用是约束流程，不是催 AI 多产出。

十、几个容易忽略的坑

1. 不要让 AI 自己决定需求范围

AI 很喜欢“顺手优化”。你让它做登录，它可能顺手改注册；你让它改一个接口，它可能重构半个模块。

解决办法：proposal.md 里必须写清楚范围内和范围外。

2. 不要让测试变成装饰品

测试必须先失败，再通过。

如果测试是实现后补的，它很可能只是在确认当前代码长什么样。

3. 不要迷信并行

并行适合搜索、调研、独立模块开发。

不适合多个 Agent 同时改同一个核心抽象。

4. 不要把 OpenSpec 当文档生成器

OpenSpec 的价值不是生成几份 Markdown。

它的价值是让规格成为项目上下文的一部分，并且在 archive 后继续影响下一次开发。

5. 不要跳过人工确认

越是自动化，越需要关键节点确认。

真正危险的不是 AI 犯错，而是 AI 很自信地犯错。

十一、项目模板：最后要落到这些文件里

如果让我给这套工作流做一个最终版本，我不会只停留在口头约定，而会把它落到项目文件里。

核心结构是：

OpenCode ├── OpenSpec：需求、设计、规格、任务 ├── Superpowers：计划、TDD、审查、完成验证 └── OMO：多 Agent 搜索、执行、修复、咨询

项目目录可以这样组织：

project/├── AGENTS.md├── opencode.json├── openspec/│ ├── config.yaml│ ├── specs/│ └── changes/└── .opencode/ ├── commands/ │ ├── auto-dev.md │ ├── verify-all.md │ └── review-ready.md └── skills/ └── auto-dev/ └── SKILL.md

opencode.json 可以类似这样：

{“$schema”: “https://opencode.ai/config.json”,“plugin”: [“oh-my-openagent”,“superpowers@git+https://github.com/obra/superpowers.git” ]}

实际配置要以你本机插件版本和官方文档为准。尤其是 oh-my-opencode / oh-my-openagent 正在经历命名迁移，最好用 doctor 命令检查安装状态。