本文记录了我从使用 LLM 辅助开发，到完全依赖 AI 进行编码的演进历程。这段旅程分为四个阶段：
- 自动补全 —— AI 作为代码助手
- Prompt 工程 —— 学会与 AI 有效沟通
- **SDD（规范驱动开发） **—— 建立 AI 驱动的工作流
- Superpowers —— 追求极致效率
阶段一：自动补全
2024 年中，我初次接触 Cursor。彼时的大模型虽远不及今日智能，但 Cursor 的创新之处在于将 AI 能力直接集成到 IDE 中——无需再将代码复制到 Web 对话框，粘贴结果后再返回编辑器，大幅减少了上下文切换的摩擦。
这个阶段主要依赖 Cursor 的自动补全功能来提升编码效率，偶尔会借助对话功能生成通用函数。如此使用了数月。
Cursor 使用了一段时间后出现 too many free trial accounts used on this machine 的提示（本机已使用过多免费试用账号），无法继续"白嫖"。
后续有使用过 Copilot、Trae 和 CodeBuddy 等。
阶段二：Prompt 工程
2025 年初，公司提供了 Cursor Pro 账号。此时 AI 模型的能力已大幅提升，我开始尝试让 AI 编写功能函数，如数据转换类等。
发现 AI 在简单函数上表现出色后，我开始更广泛地将 AI 引入编程流程。然而 AI 的产出质量不稳定，必须通过精心设计的 Prompt 来引导，才能持续获得可用代码。
这个阶段主要用 AI 做两类任务：
1. 代码优化
让 AI 对我编写的函数进行优化检查。AI 在语义明确性和代码边界确认方面有较好的表现，大部分优化建议都可以采纳。
2. 功能拓展
项目迭代到一定阶段后，需求逐渐演变为在现有基础上进行改进和扩展。由于项目积累了较多组件，很多新功能本可以复用现有组件——但部分组件在设计之初只考虑单一业务场景，缺乏对复用性的前瞻考虑。
借助 AI 辅助完成组件的抽离与复用工作。AI 的表现整体不错，但在业务逻辑过于复杂时容易出错，仍需要较多的人工干预。
Cursor Rule
通过 Cursor Rule 来配置系统级提示词，使 AI 遵循固定的编码风格和规范，同时了解项目架构和技术栈。
引入 Cursor Rule 约束后，AI 生成代码的质量有了明显提升。
阶段三：SDD（规范驱动开发）
随着日益强大的 Claude 3.5 模型登场，AI 已经能够独立开发完整功能模块。与此同时，业界也涌现出了一批配套的规范、流程和开源工具。
PromptX + OpenSpec 的开发
公司内部有资深同事探索出了以下 AI 开发技巧：
- 使用 PromptX 打造 AI 角色，不同的角色负责不同的任务
- OpenSpec 让 AI 先生成 Proposal，然后根据对应 Proposal 去做代码的实现
经过一段时间的实践，我将这两个工具组合起来，形成了最初的 AI 开发工作流。
工作流
大概的流程是，通过 PromptX 创建多个角色负责不同的任务，并且通过扫描当前项目生成对应的知识库，不同的角色链接到不同的知识库中：
- 需求编写角色：分析 Prompt 了解需求，编写规范的需求文档
- 审核文档（人工）
- OpenSpec 助手：根据需求文档生成提案和分段任务
- 审核提案（人工）
- 代码编写助手：开始编写代码
- Code Review 助手：Review 代码
- 人工 Review 代码
- QA 助手：前端可以通过一些工具进行 Review（如 Cursor 自带的 Browser Tab），后端则通过单元测试
- 人工测试和提交代码
随着模型能力的增强，Opus 模型的出现，这个阶段已基本不在"古法编程"了（手敲代码）。
阶段四：Superpowers
上述工作流和模型能力的加强，极大提升了 AI 开发的体验。但 Token 消耗逐渐成为瓶颈。Opus 高昂的 Token 价格成了全面采用 AI 开发的重大阻碍。
成本问题
Opus 模型虽然强大，但高昂的 Token 费用让日常开发成本居高不下。一次完整的开发流程下来，开销相当可观。
开始使用 Coding Plan 等其他模型来控制成本，例如：在 Cursor 使用自定义的 API key，每百万 Token 被收取 $0.25 的过路费。
新工具探索
同时开始使用 Claude Code——一款 CLI 工具，直连模型，没有中间商赚差价。
Superpowers 的出现
Superpowers 这套 Skill 方法论套件随后进入了我的视野。它提供了一套完整的开发范式：
- Brainstorming —— 在动手前先思考，避免盲目开发
- Writing Plans —— 先写计划再执行，减少返工
- Test-Driven Development —— 测试驱动开发，保证代码质量
- Verification Before Completion —— 完成前验证，避免返工
- Dispatching Parallel Agents —— 并行多智能体，提升效率
当前状态
当前工作流如下：
- 使用 Codex + GPT-4.5 作为主要工具
- 结合 Superpowers 的方法论规范开发流程
- 在关键节点回归 Cursor（Opus），在简单任务上使用性价比更高的模型
总结与展望
回顾这段 Vibe Coding 探索之旅，从最初的自动补全辅助，到如今的 Superpowers 工作流，AI 编程能力经历了质的飞跃。
核心转变：
- 从"AI 辅助写代码"到"AI 主导开发流程"
- 从"关注单次效率"到"关注整体工作流"
未来方向：
- 优化 AI 角色分工与协作
- 在代码质量与开发速度之间寻找最佳平衡点
Vibe Coding 不是终点，而是一个全新的起点。
当前局限
全部使用 AI 开发，目前依旧存在一些局限：
1. 回归破坏
AI 在迭代新功能时，容易破坏现有的正常功能。
此时需要开发者向 AI 描述错误现象并要求修复——有时多轮对话都无法解决，只能升级到更强的模型，或者由开发者亲自介入调试。
2. 测试可信度
在完成功能前，AI 会自己编写测试用例，只有通过测试才算编码完成。但问题是：**AI 会"撒谎" **。
- 没通过的测试，它会说通过了
- 测试用例无法通过时，它会自动修改测试用例使其"能够通过"，而不是修复代码
此外，后端的某些 Bug 仅通过单元测试无法覆盖，比如内存中的数据状态异常、并发问题等。
3. 偷工减料
在完成一个需求时，AI 会通过注释的方式"欺骗"——说明某个函数有 XX 和 YY 能力，实际上这个函数只有 XX 能力，没有 YY 能力。
这种"文档与实现不一致"的问题，需要人工 Code Review 才能发现。
