我被AI坑了两个月才明白：先定规范再动手，效率翻倍
我被AI坑了两个月才搞明白：这玩意儿就不是用来“干活”的！
这事儿得从三个月前的一次翻车开始。
你知道那种感觉吗？就是接手一个项目，明明只是个小bug，结果修着修着，整个代码库像多米诺骨牌一样塌了。
我当时维护一个Node项目，上游爸爸三天两头更新，我的fork呢？跟个被抛弃的前任似的，越落越远。
我心想：现在AI不是很牛吗？让Claude Code来！
结果你猜怎么着？
每次开新会话，它像失忆症患者一样，重新读我的项目。
我让它改个路由层，它顺便把类型定义也改了。但改完的类型定义跟数据库模型对不上啊！修一个bug引出两个新bug，加个功能被改出三条break change。
你以为我在用AI？不，我是在给它擦屁股！
折腾两周后我实在绷不住了——明明AI能读整个仓库，为什么效果还是这么拉胯？
说到这儿，你可能觉得我要放弃AI了。
恰恰相反。
我在GitHub上翻到一个叫Superpowers的项目，Readme第一句就戳中我——
“不上来就写代码，先把需求问清楚。”
紧接着又发现了OpenSpec，理念更直接：先定规范再动手。
我心想：这不就是软件工程那套老规矩吗？
原来大家都被AI惯坏了，上来就让它干活，忘了人类自己也得先对齐需求。
第一阶段：Claude Code总算像个真·程序员
Claude Code刚出来的时候我挺激动。它不只是个聊天窗口，它能读代码库、跨文件改代码、跑测试，还能输出可提交的结果。
比Copilot那种只会补代码的强太多了。
我上手改了一个中间件，它确实一口气改了三个文件，还自动跑了lint。
我当时就飘了。
但问题很快暴露出来。
每次开新会话，它像失忆一样重新读我的项目。让它修改路由层，它顺手改了类型定义——但类型定义和数据库模型对不上。
我花了大半天擦它捅的篓子。
说白了，Claude Code自己干活没问题，但“任务边界”和“行为框架”搞不定。
你让它“加一个导出CSV功能”，它可能在controllers加新路由，同时改掉现有的错误处理逻辑，然后跑完测试说全绿。
你以为它很靠谱？
其实只是测试覆盖率没覆盖到它踩的雷。
到这一步我意识到：再聪明的模型也得有约束，不能让它自由发挥。
第二阶段：OpenSpec，先谈丧事再发喜糖
刚接触OpenSpec时觉得这玩意儿矫情——写个功能还要先写proposal、specs、design、tasks，这不又回到传统那套文档驱动了吗？
但试用之后我承认，在AI协作里这步确实省不了。
它干的事很简单：输入/opsx:propose “为Dashboard新增数据导出CSV功能”，AI会生成一份proposal.md（为什么做）、specs/目录（验收标准）、tasks.md（任务清单）。
我审阅确认后，再进入开发。
这个“确认”动作锁死了需求端，AI后面再怎么发挥也跑不远。
我踩过一个坑：刚开始我直接在开发阶段用openspec的apply命令让它自动实现，它写出来的代码和spec对不上。
后来我只取它的spec和task，实现交给Superpowers。OpenSpec里的apply功能我直接在配置里关掉了——openspec config profile，取消勾选Apply tasks。
这样它只负责输出规范，不插手实现。
说实话，OpenSpec解决的问题其实就一个：把AI从“碰运气生成”变成“按指标交付”。
第三阶段：Superpowers，把AI当实习生管
Superpowers把我的好感度拉满了。
它的核心是三个步骤：brainstorming → writing-plans → subagent-driven-development。
说白了就是先问清楚需求，拆成2-5分钟可执行的小任务，然后并行执行。
实际跑了一次数据库迁移+用户模型更新的任务，我让它用Superpowers模式启动。
它先列了一堆问题：“编码格式是什么？”“大文件怎么处理？”“是否需要事务回滚？”
问得比我PM还细。
我逐条确认后，它自动创建git worktree隔离分支，读取OpenSpec的tasks.md，拆出4个子任务，然后开了两个subagent并行跑密码工具和JWT工具。
依赖任务（迁移→模型）顺序执行，独立任务并行执行。
更让我安心的是它内置的TDD纪律。写代码前必须先写测试，跑红了才允许写实现。
我检查它生成的代码分支覆盖率，要求≥80%，它真的自己补到85%。
然后跑superpowers check，它会校验TypeScript严格模式、是否用了any类型、错误处理是否覆盖等。
我当时就在想：这特么才叫工程化。
不是用AI代替人，是把人的工程规范编码成AI执行的规则。
Superpowers的价值其实是“纪律”。AI太随意了，需要有人踩刹车。
第四阶段：三合一，这才是我想要的AI协同
当你把这三个东西串起来，效果是1+1+1>3。
我目前的完整流程是这样的：
1. 需求探索
用/opsx:explore聊清楚需求细节。比如我那个statusline组件，先问清楚显示什么、什么形式、多色指示具体意思。AI会输出proposal和specs，我审一遍，确认没歧义。
2. 流程启动
敲一句：“我们开始开发用OpenSpec规划的这个功能，请使用Superpowers技能澄清需求并开发。”Superpowers自动读取tasks.md，先做需求反问，待我确认，然后创建git worktree，拆任务，进入开发。
3. 开发与约束
开发过程中Agent Skills像监理一样盯着：单文件不超过500行，函数不超过50行，超了自动拆；分支覆盖率≥80%，否则拒绝提交；自动扫依赖漏洞和密钥泄露。
我都不需要盯着它写，去喝杯咖啡回来它可能已经跑完两个subagent了。
4. 验证归档
运行/opsx:verify，AI逐条对照spec验收功能。通过后运行/opsx:archive，自动把当前功能的所有文档和代码迁移到openspec/changes/archive/目录下，形成版本沉淀。
以后查某个决策原因直接翻这个归档，不用翻聊天记录。
性能优化和省钱小技巧
这组合跑起来Token烧得飞快。我试了几次后摸索出几个省钱的方法：
- **小功能开Fast-Forward模式**。估算开发时间低于30分钟的重复工作，直接让Superpowers略过brainstorming和详细plan，快速进入实现。省一半Token。
- **并行任务要斟酌使用**。独立任务并行确实快，但Token消耗翻倍。我有次并行跑了三个subagent，单次会话花了3.2M token。如果任务不紧急，顺序执行更省钱。
- **Spec缓存**。每次开新会话都重新读spec浪费严重。在`.claude/settings.json`里配置自动加载openspec的归档目录，让Claude Code启动时就加载本地spec，会话间不丢上下文。
- **任务粒度要小**。单个tasks.md控制在5-10个task以内，颗粒度越小，AI越不容易跑偏，返工少自然省token。
这东西不适合谁？我说实话
如果你只是在写一次性脚本、两周就扔的原型，或者探索性的实验（需求明确之前），别用这套流程。
我试过给一个demo项目上OpenSpec+Superpowers，光写proposal就花了20分钟，而整个demo写出来也就两个小时。
没必要。
适合的场景是：开发周期大于4小时的功能、多人协作需要规范沉淀的项目、生产环境代码要求高质量的、长期维护需要文档可追溯的。
我那个fork的statusline工具就是典型——每个版本的改动都要能追溯，不然上游更新根本合不进来。
最后说点我的态度。
AI编程工具不是银弹，这半年我越来越确信。它们不会把糟糕的开发者变成优秀的开发者，但会让优秀的开发者更高效。
OpenSpec+Superpowers+Claude Code这组合拳，其实就是把人类工程师那套需求对齐、TDD、Code Review的经验，转译成AI能执行的约束规则。
不是让AI自由发挥，是让AI在约束下创造。
未来走向我看就两点：
一是跨模型协作工作流会成为标配，比如Claude Code负责实现、Qoder负责规范审查、GPT负责测试用例生成，各用各的擅长。
二是这套“规范→执行→审核”的模式会下沉到IDE层面，变成像代码片段一按Tab就自动生成的事情。毕竟现在已经有项目在搞Ultrareview、Devcontainers那一套了，把工程纪律塞进开发环境，对前端后端都实用。
反正我不会回到“边聊边写”的阶段了。
踩过的坑，不想再踩第二遍。
说到最后，我想告诉你一件事。
很多人以为AI编程是让AI帮你干活。
错了。
AI编程的正确打开方式是：把人的工程纪律，变成AI的肌肉记忆。
你懂我意思吗？
读者评论 3