从随性编码到规范流程：我的AI编程进化之路

最初借助AI写代码的方式就是纯粹对话——后来人们给这种风格起了个名字，叫vibe coding。提需求、等结果、发现偏差、再纠正、再等待，效率尚可，但总有几个痼疾难以回避。

首当其中的便是需求漂移。一个功能讨论到后半程，AI已然忘却了最初的目标，只保留最近几轮交互的内容。我不得不一次次将原始需求重新粘贴。

其次是代码水准起伏不定。状态在线时它能产出整洁优雅的实现，状态欠佳时则抛出一堆能运行却不堪入目的代码。测试环节基本由我兜底。

再者是Bug修复的恶性循环。修补一处，冒出两处。每次只做表面文章，深层根因无人追查。

后来接触到Superpowers，试用后效果不错，随即引入了OpenSpec与GStack。如今这套体系运转数月，交付质量显著提升。

下文分享我的实践经验，非官方指南。

OpenSpec对我而言只做一件事：将需求固化为文档，而非散落于对话记录中。

每个新功能我输入需求概要，它产出四份文档：proposal阐述目标、design规划方案、tasks拆解执行步骤、specs明确验收条件。

我耗费5到10分钟审阅，补充AI遗漏之处。例如上次开发优惠券，它疏漏了"每人限领三张"，我补充完善。确认无误后方才让AI进入编码阶段。

最直接的获益并非"需求明确"，而是"需求不丢失"。两周后回顾，当初决策依据何在，翻开specs即可查证。无需依赖记忆，不必翻找聊天记录。

另一优势在于AI工具切换自如。今日用Cursor，明日换Claude Code，规范文档始终留存于仓库，任何AI都能读取。

Superpowers的核心价值对我而言只有一点：硬性推行TDD。

启用后AI开发任何新功能都必须先撰写测试，再编写实现。起初我不适应，嫌进度慢。一个简单的函数，它要先写三四个用例，跑通失败后再逐步完善实现。

然而两周后我发现，经Superpowers产出的函数，后期几乎无需返工。以往"上线后陆续暴露边界条件问题"的情形大幅减少。

Bug修复的范式也随之转变。从前我报告Bug，AI直接臆测原因、修改代码。如今它先复现问题——编写能触发Bug的测试用例，确认失败后定位根因，修复后再验证确实解决。

最直观的感受是，修一个Bug引发新Bug的概率降低了约七八成。

GStack针对的是另一症结：AI以同一套模式应对所有阶段。

我最常用的是/review。每次AI完成一批代码，我执行一次review，它会罗列严重缺陷（事务缺失、竞态条件）与一般问题（日志缺失、异常处理不完善）。严重问题不解决不允许继续。

首次运行review时它捕获了一个并发隐患：两个请求同时操作同一资源，代码采用先查询后修改的模式，中间存在窗口期。人工审查未必能察觉，但review将其标记为严重缺陷。修正后该模块上线至今未曾复发。

/qa我通常在发布前执行。它会启动浏览器操作页面，截图并检查console报错。首次运行便发现一张404截图，这是我自己从未注意到的。此后每次部署前执行一遍，有问题在发布前即行修复。

/ship实现全自动，按发布清单执行完毕后发起PR。省去手写PR描述的工夫。

我的典型工作流如下：

以优惠券功能为例，从启动到PR合并仅耗时两天有余。以往同等规模的功能至少一周，上线后还要持续修复两周Bug。

这套方案并非放之四海而皆准。个人副业项目、一次性脚本，直接让AI编写即可，无需大费周章。

生产环境项目、多人协作场景、需要长期维护的代码库，则值得投入。

初期确实需要适应成本。TDD若不适应会觉得拖沓，但度过磨合期后收益清晰可见。核心收益不在于代码本身多优秀，而在于你无需时刻紧盯AI追问"测试写了没""这里有没有并发隐患"——工具强制其执行，你只需核验结果。

另外关于Superpowers，若研读其源码，本质就是一组Markdown文件，以SKILL.md定义了一套流程规范。它不绑定特定模型，Claude可用，OpenAI亦可用。我认为这种设计思路比依赖某家模型的特性更为稳妥。

以上便是全部。各团队实践方式或有差异，但底层逻辑共通：将流程从"人盯着AI做"转变为"工具强制AI做"，使人将精力倾注于决策而非执行。