用工作流驯服 AI

notion image
跟 AI 结对编程这事儿，大家都摸索过一阵子。一开始，我们总是习惯性地在对话框里敲下“帮我写个 XX 功能”，然后满心欢喜地看着它咔咔输出代码。但现实往往是，它写着写着就放飞自我，最后给你留下一堆跑不通的烂摊子。
痛定思痛后，我日常琢磨出了一套能让 AI 在整个开发流程里不偏离方向的实践方案。
核心理念其实就一句话：别跟 AI 聊天，用文档驱动它。
具体怎么操作呢？思路很简单：先用 OpenSpec 把需求和设计定死，绝不让它自由发挥；接着用 SuperPower 把控执行过程，按规矩写代码跑测试；最后挂上 proxy 智能路由，根据任务难度自动选模型，对于opus我会转发到GLM5.2，对于sonnet用kimi2.7，haiku用v4flash，减少API成本。
提到动态路由，我选择的项目是Proxy,
Fix: Narrow complex scenario keywords to prevent false-positive routing
Github
Fix: Narrow complex scenario keywords to prevent false-positive routing
Updated
Jul 6, 2026
，专门适配opencode的go计划，期间遇到了cc只会调用glm5.2的问题，最终分析发现在complex任务中，把tool调用也算入了complex任务，还有很多不相干的关键词，解决上面问题并且pr后。成功实现了低消费的动态路由，如下图：
notion image
这么一套组合拳走下来，AI 终于消停了，从一个到处埋雷和费钱的NPC，变成了一个能干活、好验证、还不怎么费钱的靠谱工具人。

工具选型：不选最贵的，只选最对的

AI Agent 框架：为啥我死磕 Claude Code？

市面上的 Agent 框架不少，我做过几轮横评：
  • Hermes Agent：啥都好，就是写代码拉胯，更适合干点自动化，重复的活。
  • OpenCode+Omo： Omo插件与OpenCode其他插件严重冲突导致功能失效，且长时间运行后模型会停止输出任何可见文本，使整个会话完全不可用。
  • AmpCode：不计成本，完全放权给AI
最后发现，还得是 Claude Code。它理解代码的深度和工程化能力确实没得挑，虽然前几天出现了在cc里面埋雷事件，但论能力，还是数一数二的，把它当“首席工程师”用，能自己看懂全局上下文自主干活，省心又省力。

工作流框架：GSD 太重，OpenSpec + SuperPower 刚刚好

试过了GSD，流程太重，中小项目用起来有种杀鸡用牛刀的憋屈感。后来换了 OpenSpec 和 SuperPower 的组合拳，瞬间清爽了。
这俩为啥必须一起用？因为它们完美互补：
  • OpenSpec 负责“想清楚”：把模糊的想法变成清晰的文档，做技术选型，写设计文档。也就是搞定“做什么”和“为什么做”。
  • SuperPower 负责“干漂亮”：写具体代码，搞测试驱动开发（TDD），做代码审查。也就是落实“怎么做”并保证质量。

省钱方案：proxy 智能路由真香

刚开始不懂事，直接拿智谱 GLM-5.1 跑规划，模型确实强，但光做一次规划就花了小三十块，眼看着账单数字往上飙，那叫一个肉疼。后来学乖了，轻量活儿改用 GLM-4.7，勉强拉回一点成本。
真正的转折点是我在 Linux.do 社区挖到了一个开源项目：routatic/proxy。它能把 Claude Code 的请求按场景智能分流到不同的国产模型上。启用流式场景路由后，一切自动化，它自己就能判断啥时候需要深度思考，啥时候只需简单补全。

实战流程：13步拿捏 AI

这套工作流最特殊的地方在于，它把开发拆成了 13 个步骤，每一步谁来做、为啥做都明明白白。装好工具后，Claude Code 里会多出一堆自定义命令。

挑几个关键步骤说说

从画图纸开始 (/opsx:propose)

输入这行命令，AI 会在项目目录下生成四份文档：proposal 讲要做什么，design 讲怎么做，tasks 拆任务，spec 定验收标准。说白了就是让 AI 帮你把脑子里模糊的想法变成白纸黑字——你还没写一行代码，需求文档就已经出来了。

最磨人的一步：跟 AI 对质 (/opsx:explore)

这一步是整个流程里投入产出比最高的，也是最烦的。AI 会像个不太信任你的架构师一样追着问："这个边界情况你考虑了吗？""如果外部服务挂了怎么办？""你的分页支持 offset 还是游标？"
你得一条条回答。
烦是真烦，但答完之后你会发现——之前那些"到时候再说"的模糊地带，全被堵死了。后面 AI 写代码的时候想自由发挥都没空间。

sp 命令的来历：市面上没有，自己造的

说到这里得坦白一件事：带 sp: 前缀的这些命令，市面上根本找不到。
OpenSpec 自带的命令管的是"想清楚"——propose、explore、archive 这些都是它原生的。但到了"动手干"这个阶段，我发现 OpenSpec 原生的 plan 太粗了，apply 更是压根没有 TDD 的概念。SuperPower 那边倒是有写代码的能力，但没有标准化的命令体系来约束开发范式。
所以后面的 plan、apply、verify、review、finish、archive 六个命令，全是我自己一个一个手搓出来的。每个命令都是一段精心设计的 prompt 模板，专门用来约束 AI 在对应阶段的行为。

规划要够细 (/sp:plan)

OpenSpec 原生的 plan 只是基于 tasks 粗略拆一下，远远不够。我在这个基础上重新实现了一个 plan 命令，它会生成一份 implementation-plan.md——里面不光有任务列表，还有任务之间的依赖关系、每个任务涉及的具体文件路径、可验收的完成标准、风险等级，甚至会分析哪些任务可以并行执行。
为什么要做到这个粒度？因为后面要用 TDD 开发，如果任务拆得不够细，AI 写测试的时候根本不知道该测什么。

TDD 红绿灯 (/sp:apply)

apply 命令是我花心思最多的一个。我专门把 TDD 的红-绿-重构范式写成了一套完整的 prompt，"教"给 AI 怎么走这个循环：每接一个任务，必须先写一个注定失败的测试（红灯），定义好"正确的行为是什么"；再写最简单的代码让测试通过（绿灯），不多写一行；最后在测试全绿的前提下重构优化。
不能跳步，不能偷懒。AI 想直接写实现代码？不行，先写测试。

验证提示词是从各路技术社区淘来的 (/sp:verify)

verify 命令解决的问题是：代码写完了，怎么确认它真的没问题？
我专门去一些技术平台——GitHub 的最佳实践讨论、各种 AI 编程社区——收集了一批专门用来验证代码质量的提示词，然后整合成了一个 verify 函数。它会自动检测项目类型（Java、Python、Go、Node 都认），然后跑对应的单元测试、检查日志里有没有 ERROR、跑回归测试确保没有破坏已有功能、还会对着 implementation-plan 里的边界情况逐条验证。
最终输出一份结构化的报告：PASS 还是 FAIL，哪里有问题，一目了然。

审查不能自己审自己 (/sp:review)

  1. 首先是关于怎么 “审查”
verify 过了不代表代码质量过关。review 命令做的是代码审查——对照 implementation-plan 里的验收标准，逐条检查代码有没有做到位。覆盖四个维度：正确性（逻辑有没有 bug）、可维护性（命名清不清晰、函数长不长）、安全性（有没有硬编码密钥、注入风险）、性能（有没有 N+1 查询、内存泄漏）。
审查结果分两级：Must Fix 是阻塞项，不修不能合并；Nice to Have 是建议，可以后续再改。
  1. 关于不能审自己
我是让cc专门启用一个subagent,调用Glm5模型做一个多层面的审查，避免同一个模型不断自身导致幻觉积累越来越多的问题（就像去ai味一样，ai参与越多越难去掉，还是需要人的参与与决策）

一键交付 (/sp:finish)

finish 命令干三件事：确认所有任务完成、测试通过；合并代码到目标分支；自动创建 PR（连描述模板都帮你填好了）。如果你用了 worktree 做隔离开发，它还会顺手清理残留的 worktree。

规格闭环 (/sp:archive)

最后的 archive 命令是我额外加的——OpenSpec 原生的 archive 只是把 spec 文件归档，但我觉得不够。我实现的版本会把归档的文档内容做一个总结，然后自动更新仓库里对应的开发文档或者开发日志。这样每次开发完，仓库里的文档永远是最新状态，不会出现"代码改了但文档没更新"的尴尬。
这就是我这套方案的完整面貌。六个 sp:* 命令，每个都是针对一个开发阶段的痛点设计的。OpenSpec 管"想清楚"，sp:* 管"干明白"，两者合在一起才构成一个从需求到交付的完整闭环。

当需求变了？别急着改代码！

开发最怕啥？需求变更。但在这套流程里，有个铁律：“文档先行，代码殿后”。就算只改个字段名，也别手贱去改代码，必须回到第 3 步重走 /opsx:explore。虽然看着繁琐，但这保证了每一次变更都有迹可循，不会把项目变成一锅粥。

真实案例：给 Apache SeaTunnel 补个Task

光说不练假把式。拿我最近搞的一个真实项目 seatunnel-hg-connector 举例。
相关pr链接：
[Fix][Connector-V2] Normalize edge id to String + Fix HugeGraph Source connector issues
Github
[Fix][Connector-V2] Normalize edge id to String + Fix HugeGraph Source connector issues
Updated
Sep 5, 2026
背景：Apache SeaTunnel 里的 HugeGraph 连接器只支持写，不支持读。我的任务就是补齐这个 Source 连接器。
走了一遍流程后，AI 在 /opsx:explore 阶段问出的几个问题直接问倒我了：
  • 顶点和边的字段映射要不要包含 id、label？
  • properties 过滤是白名单还是黑名单？空集合代表全要还是全不要？
  • limit 达到后是抛异常还是优雅地结束？
说实话，有些细节我一开始真没想清楚。逐一回答后，基线锁定，AI 直接把任务切成了 7 组共 27 个任务。
接下来 AI 严格按照 TDD 推进。第一版提交时，21 个单元测试一次通过，1814 行新增代码，干净利落。

但是，别高兴得太早。

AI 的自动化验证全绿，但后续还是暴露了三个问题：
  1. schema 推断的运行时类型对不齐，属性单值/集合处理出错。
  1. DATE 转换没用 UTC，时区导致数据偏移。
  1. 测试类命名不符合 CI 检查规则，被 CI 拦下。
这也印证了那条铁律：AI 的测试只验代码逻辑，验不了业务真实场景和项目级约束。该手动测的，该过 CI 的，一步都省不了。

踩坑吐血换来的四条铁律

  1. AI 测试全绿 ≠ 功能正确：时区、CI 规则这类项目级坑，AI 根本感知不到，必须人工兜底。
  1. 向后兼容是底线：重构共享类时，旧 API 必须打 @Deprecated 标签并委托，不然会悄悄搞崩老功能。
  1. 前期偷懒，后期还债：schema 推断的 cardinality 问题，就是因为 explore 阶段没问清楚，结果硬生生返工了一次。
  1. 改需求必须回退改文档：哪怕只改一个字段名，也要走 /opsx:explore 流程，保证可追溯。

写在最后

归到底，这套 AI 原生开发工作流的精髓就在于三个“管住”：
  • 用 OpenSpec 管住需求和设计
  • 用 SuperPower 管住执行和质量
  • 用 proxy 管住钱包
AI 的能力再强，它也只是个算力极高的执行者，真正决定项目成败的，还是制定规则、把控方向的人。这套流程的本质，就是把你从一个手忙脚乱复制粘贴的“提示词工程师”，变成一个运筹帷幄的架构师和项目经理。
未来，不是 AI 取代我们，而是会用 AI 的人，把不会用 AI 的人卷出局。
 
附件：
openspec.zip
19.7 KiB