夜雨聆风
AI 写代码为什么总跑偏?6 款工具帮你治根
当 AI 能写代码，瓶颈就转移到了”说清楚要什么”这件事上。
有多少人有过这种经历：
你告诉 AI “帮我做一个用户登录功能”，几分钟后它交出了一份代码，看上去挺像那么回事。但一跑起来，你发现它用了一个你从没用过的认证库，session 的处理方式和项目里其他地方完全不一致，错误提示是英文的，而你的产品面向中文用户……
你没有说错任何话。问题出在你没说的那些事上。
这正是当下 AI 编程最核心的矛盾：模型越来越强，但”说清楚要什么”这件事，从来没有变容易过。
01 Vibe Coding 是怎么流行起来的
2025 年初，Andrej Karpathy 的一条推文让”vibe coding”这个词火了。
他描述的状态是：开发者不再一行行看代码，而是用自然语言描述感觉，让 AI 生成，哪里不对再改。整个过程像在”和 AI 合作即兴创作”。
这种方式有它的合理性。对于想快速跑通一个想法的人来说，它极大降低了起步门槛——不懂某个框架没关系，不熟悉某个 API 没关系，先跑起来再说。
大量 demo 和 side project 因此得以在几小时内成型。
但问题也随之而来。
当项目从 demo 走向生产，当代码库从几百行膨胀到几万行，当同一个功能开始牵扯三四个模块的时候，”凭感觉”的指令就开始系统性地失效。
02 真正的问题：不是 AI 太笨，是指令太模糊
很多人在遇到问题时，第一反应是换一个更强的模型。
但换了之后发现：还是跑偏。
原因在于，这类问题的根源不是模型推理能力不够，而是输入本身存在结构性缺失。
一句”加个商品管理功能”，背后隐藏的决策多达十几个：操作应不应该是幂等的？权限由谁控制？报错怎么处理？接口设计遵循什么规范？数据存在哪一层？
这些问题没有标准答案，得看你的项目上下文。但它们都没有出现在你的 prompt 里。
AI 不会追问你，它只会做出选择——根据自己的训练数据，挑一个看起来最合理的答案。这些选择有时恰好对，但经常错，而且你很难预判它会在哪里出错。
这不是模型的问题，这是沟通的问题。 准确说，是缺乏一套结构化的方式，来把你”心里默认的上下文”传递给 AI。
03 行业在往哪里走
如果你观察 2025 年下半年以来涌现的 AI 编程工具，会发现一件有趣的事：
它们在解决同一个问题。
Amazon 在 7 月发布了专门的 AI IDE Kiro，核心特性是自动将需求拆解为规格文档、设计文档和任务清单。GitHub 推出了 Spec Kit，把”先写规格再动手”封装成可复用的工具链。独立开发者 Jesse Vincent 的 Superpowers 插件在短短几个月内收获了近十万 Star，它做的事情是把工程纪律强制注入 AI 的工作流程。还有 GSD，一套极简的五命令系统，三个月内登上了 GitHub 全球趋势榜……
这些工具来自不同的团队，面向不同的受众，但它们的出发点高度一致：
在 AI 动手写代码之前，先把”要做什么”和”怎么做”清晰定义出来。
这套思路有一个名字：Spec Driven Development，简称 SDD。
04 SDD 是什么，怎么运转
SDD 不是某个特定工具，而是一套工作方法。
它把 AI 编程的过程分成四个阶段，每个阶段解决一类问题：
第一阶段：写规格（Spec）
规格只回答一个问题：这个功能要做什么？
它用非技术语言描述，覆盖使用场景、边界条件和验收标准。”用户可以通过邮箱和密码登录，三次失败后账号锁定十分钟”——这是规格。
注意，规格不涉及实现方式。它的作用是把你脑子里的业务逻辑外显出来，让 AI 和你站在同一个理解起点上。
第二阶段：写计划（Plan）
计划回答的是：技术上怎么做？
这里才开始注入具体的技术决策：用什么库、遵循项目里哪些已有模式、数据模型如何设计、测试策略是什么。这一步是开发者专业判断力真正发挥作用的地方——不是体现在写代码上，而是体现在做架构决策上。
第三阶段：拆任务（Tasks）
把计划拆成一个个小而具体的执行单元，每个任务能在一次 AI 会话中完成，并产出可验证的结果。
任务粒度至关重要：太大，AI 需要自己补充决策，歧义重新回来；太细，流程变得繁琐，得不偿失。
第四阶段：逐任务实现（Implement）
AI 拿到一个任务，任务里已经包含了所有必要的上下文，直接执行，不需要猜测，不需要跨任务寻找信息。
这时候 AI 的产出质量会高得多，因为它面对的是一个有明确答案的问题，而不是一个开放性问题。
05 不是所有场景都需要 SDD
SDD 有一个不小的代价：它会消耗更多 token，也需要你在编码前多投入时间。对于小改动来说，这个成本不合算。
这就引出了一个实际问题：什么时候用 Plan Mode，什么时候上完整 SDD？
下面是一套判断框架：
直接 Prompt 就够了
-
• 改一行配置 -
• 修复一个有明确错误日志的小 bug -
• 单文件内的小调整 -
• 你能在一句话里说清楚所有边界条件
这类任务，结构化流程只会增加摩擦。
用 Plan Mode
适合中等复杂度的任务：涉及 2 到 5 个文件，步骤有一定顺序，但整体边界是清晰的。
Plan Mode 的价值在于让 AI 在动手前先”想一遍”——把步骤列出来，你确认没问题，再执行。这能避免 AI 走弯路，也给你一个检查逻辑是否正确的机会。
升级到 SDD 的信号：当你看完 AI 生成的 Plan 后，发现里面有几个你需要决策的技术选项，而你之前根本没想到这些分叉——这说明问题的复杂度已经超出了 Plan Mode 能覆盖的范围。
用完整 SDD
-
• 全新功能，横跨多个模块或业务域 -
• 历史债务较多的老项目里做改动 -
• 需要多个 AI 并行工作的任务 -
• 团队协作，需要决策可追溯 -
• 任何”你以为显而易见，但实际上暗藏大量假设”的需求
一个实用的判断口诀：如果你在描述需求的过程中，不断冒出”哦对，还有这个……还有那个……”，那就上 SDD。这些不断冒出来的”还有”，正是导致 AI 跑偏的根源。
06 六款工具横评
Kiro（Amazon）
一句话定位：原生 SDD 的 AI IDE
Kiro 是 Amazon 在 2025 年 7 月推出的 VS Code 分支，把 SDD 工作流深度集成进了 IDE 本身。
你给它一段自然语言描述，它会自动生成三份文档：用 EARS 格式写的需求文档（requirements.md）、包含架构图和技术决策的设计文档（design.md），以及按依赖顺序排好的任务列表（tasks.md）。整个过程是交互式的，AI 会主动追问缺失信息，而不是默默做假设。
Kiro 还有一个叫 Hooks 的机制：当项目里的文件发生变更时，自动触发预设的 agent 动作，比如代码改了就自动更新对应的设计文档。这让规格文档真正做到了和代码同步演化，而不是开发完就落灰。
定价上，Free 套餐每月 50 次，Pro 套餐 19 美元/月 1000 次，Pro+ 套餐 39 美元/月 3000 次。
适合谁：需要完整 SDD 闭环的团队；重视文档可追溯性的企业项目；AWS 生态用户。
不适合谁：只需要快速实验的个人开发者；小改动高频次的维护型工作。
GitHub Spec Kit
一句话定位：开源 SDD 工具包，和哪个 AI 都能配
Spec Kit 的设计哲学是”AI 无关”——它不绑定任何特定的 coding agent，和 Claude Code、Copilot、Gemini CLI、Cursor 等主流工具都能配合使用。
它提供了一套 CLI 工具和命令模板，把开发过程组织成六个有序阶段：从立项原则（constitution）到功能规格（specify），再到技术方案（plan）、任务拆解（tasks）、代码实现（implement），最后到代码提交（pr）。每个阶段都设有人工确认节点，开发者始终掌握方向盘。
其中”Constitution”的概念值得单独说一下——它相当于项目的架构宪法，规定了哪些设计原则是不可违反的，比如”所有新功能必须作为独立模块开发”。这份文件会在每次 AI 生成内容时被引用，确保产出物天然符合你的架构偏好。
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai claude适合谁：多工具混用的团队；需要在现有 GitHub 工作流中嵌入规范的项目；开源项目的外部贡献管理。
不适合谁：需要 IDE 级集成体验的用户；对已有大型代码库支持有限。
OpenSpec（Fission AI）
一句话定位：以”变更提案”为单位管理开发历史
OpenSpec 的核心设计理念是把每一次功能变更都当作一个正式提案来管理。
你用一条命令发起提案，它会自动生成一个结构化的文件夹，包含变更原因、功能需求、技术设计和任务清单。AI 按任务逐步实现，完成后将整个提案归档，变更历史清晰可查。
这套机制对需要审计追踪的场景特别有价值。三个月前某个功能是谁提议的、当时的设计理由是什么、最终实现了哪些任务——全都有迹可循。
/opsx:propose add-dark-mode → 生成规格文件夹/opsx:apply → AI 逐任务实现/opsx:archive → 归档到变更历史适合谁：有合规要求的企业项目；希望保持清晰迭代历史的中小团队；产品功能频繁迭代但需要可追溯的场景。
不适合谁：快速原型阶段；对流程开销敏感的独立开发者。
Ralph Wiggum Plugin
一句话定位：让 AI 自己循环，直到把任务做完
这个插件的名字来自《辛普森一家》里屡败屡战的 Ralph Wiggum，取的是”失败了就重来”的精神。
它的核心机制是：每次循环启动一个全新的 AI 进程，让它从磁盘上读取当前任务的规格，完成后干净退出，然后自动进入下一个任务。这和”在同一个会话里让 AI 一直跑”有本质区别——全新进程意味着干净的上下文，不会因为会话过长导致 AI 开始遗忘或混淆信息。
你设定好最大迭代次数，它会自动处理完所有任务，期间不需要人工干预。
/ralph-loop "实现购物车模块" --completion-promise "COMPLETE" --max-iterations 20适合谁：有完整规格文档的功能开发；需要长时间无人值守运行的批量任务；CI/CD 流程中的自动化修复。
不适合谁：需求还没想清楚的探索阶段——规格不清晰时，循环只会在错误的方向上越走越远。
Superpowers
一句话定位：把工程规范变成 AI 无法绕过的约束
Superpowers 由 Perl 语言核心维护者 Jesse Vincent 在 2025 年 10 月发布，三个月内在 GitHub 上积累了超过九万 Star。
它的核心思路是：与其在 prompt 里反复强调”你要写测试””你要遵循现有代码风格”，不如把这些要求直接编码成系统级约束，让 AI 根本没有机会绕过它们。
具体来说，它把开发流程拆成五个阶段：首先通过提问澄清需求边界，生成设计文档；然后自动创建独立的 git 分支，隔离开发风险；接下来生成细粒度的任务计划，每个任务限定在 2 到 5 分钟内完成；然后用子 agent 并行执行，每个子 agent 都经过两轮审查——先验证是否符合规格，再审查代码质量；最后进行系统性代码复查。
TDD 在 Superpowers 里不是建议，是强制执行的：测试必须在实现代码之前存在，否则任务不被接受。
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace适合谁：对代码质量和工程规范有严格要求的生产项目；需要标准化团队 AI 编程实践的工程团队。
不适合谁：快速原型验证；需求频繁变动的探索期项目。
GSD（Get Shit Done）
一句话定位：独立开发者的极简 SDD 系统
GSD 是哥斯达黎加的独立开发者 Lex Christopherson 做的，他的自我描述是”一个做音乐的程序员，不想玩企业剧场”。
GSD 的理念非常直接：把所有结构化的复杂度藏在系统内部，对外只暴露五个命令，整个流程不需要理解任何框架概念。
/gsd:new-project → 提问提取需求，生成项目路线图/gsd:discuss-phase N → 深入讨论第 N 阶段的细节/gsd:plan-phase N → 生成原子任务计划，每个任务独立提交/gsd:execute-phase N → 子 agent 执行，自动验证结果/gsd:verify-work N → 人工确认后进入下一阶段在技术实现上，它给每个任务分配一个拥有 200k token 干净上下文的子 agent，任务完成后自动生成一个独立的 git commit。这意味着整个开发过程完全可回溯——你可以用 git bisect 精确定位任何一个引入问题的任务。
它支持 Claude Code、Gemini CLI、Codex、Copilot、Cursor 等六大主流平台，2026 年初在 GitHub 上已积累超过三万五千 Star，仍在高速增长。
npx get-shit-done-cc --claude --global适合谁：独立开发者和小团队；Claude Code 的重度用户；想尝试 SDD 但不想引入复杂工具链的开发者。
不适合谁：需要团队级权限管理和审批流程的企业场景。
07 如何选
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这六个工具并不互斥，组合使用反而是常见的玩法：用 GSD 或 Spec Kit 定义规格，用 Ralph Wiggum 执行，用 Superpowers 把关质量。
08 最后说一句
Vibe Coding 没有消亡，它只是找到了自己真正适合的位置——快速验证想法、制作原型、一次性脚本。
而当你需要的不是”跑起来的代码”，而是”经得起维护的系统”时，投入时间把需求说清楚，反而是效率最高的路径。
先从 Plan Mode 开始习惯”先想后做”的节奏。等你发现 Plan Mode 开始驾驭不了你面对的复杂度时，SDD 的大门自然就开了。
如果你对 SDD 有迫切需求，又希望上手简单，那推荐先尝试 Kiro，它可以让你找到 Spec Driven Development（SDD） 的最佳手感。
AI 在持续进化，但如何和它协作——这件事，还是得我们自己想清楚。
09 给正在转型的程序员：最难的关不是学工具
我们公司内部推行 AI Coding 有一段时间了，踩过很多坑，也观察到了一个始终绕不开的现象：
那些用 AI 用得好的程序员，往往不是技术最强的，而是最会”定义问题”的。
这听起来有点反直觉。毕竟我们学了这么多年编程，核心训练都是”怎么解决问题”——算法、数据结构、设计模式……没有人系统教过我们怎么把一个模糊的需求变成一份清晰的规格。
这个能力，过去隐藏在资深工程师和产品经理的日常沟通里，属于”经验沉淀”，很少被显式训练。但现在，它成了 AI Coding 效率的直接瓶颈。
你的技术直觉是资产，也可能是障碍
有经验的程序员有一个共同的习惯：看到需求，大脑会自动跳到实现层——这个功能大概要改哪几个文件，用什么数据结构，可能有什么性能问题。
这种直觉极其宝贵。但在 AI Coding 的语境里，它有时会变成一种干扰。
你跳过了功能层，直接进入实现层，告诉 AI “用 Redis 做缓存，TTL 设成三十分钟”，却没有先说清楚这个功能在用户视角下应该如何运转，边界情况有哪些，什么情况下缓存不应该生效。
结果是：AI 很忠实地执行了你的技术指令，但功能的行为不是你期望的那样。
转型的第一个功课，不是学会用工具，而是练习把”技术直觉”翻译成”行为描述”。 在想”怎么实现”之前，先把”它应该做什么”说清楚。
文档能力的本质，是结构化思维
很多程序员一听”写文档”就头皮发麻，觉得那是产品经理或技术Leader的工作。
但写规格文档和写产品文档不是一回事。
写规格文档要回答的核心问题是：这个功能在什么条件下，做什么事，产生什么结果，哪些情况属于例外。
这本质上是一种结构化思维的训练——把脑子里混沌的”我想要这个”拆解成可以被验证的陈述。
有一个非常实用的练习：在开始写规格之前，先完成这个句子——
“我怎么知道这个功能做好了？”
如果你能给出三条以上具体的、可验证的回答，你的规格就有了雏形。如果你说不出来，说明需求还不够清晰，这时候让 AI 动手，大概率会跑偏。
几条实用建议
从小需求开始练习写 Spec，而不是直接用 SDD 做大项目。
挑一个你熟悉的小功能，试着用两百字把它的行为描述清楚——包括正常路径和异常路径。然后把这份描述交给 AI，看它的理解和你的预期有多大偏差。偏差越大，说明你的描述里隐藏着越多的隐性假设。这个练习做几次，你对”什么叫说清楚”会有非常直观的感受。
把”让 AI 帮你找漏洞”变成习惯。
写完一份规格草稿，不要急着让 AI 去实现，先让它扮演一个挑剔的工程师，问它：”这份规格有哪些地方你需要做假设才能继续？”AI 反问你的每一个问题，都是你规格里的一个盲区。
不要把返工归因于 AI 不够聪明。
当 AI 的输出不符合预期时，先问自己：我有没有在规格里描述这个边界情况？我的技术决策有没有写进计划里？很多时候你会发现，问题出在输入端，而不是模型本身。这个归因习惯的转变，是真正提升 AI Coding 效率的起点。
接受”先想后做”带来的不适感。
程序员喜欢动手。坐下来写文字，而不是写代码，在心理上会有一种”没有在干正事”的感觉。这种感觉是正常的，但它是错觉。花二十分钟把规格写清楚，能省下两小时的反复调整——这个账是算得过来的，但你得亲身经历几次之后才会真的相信。
最后一句告诫
AI 把”写代码”这件事的门槛大幅降低了，但它同时把”定义问题”这件事的重要性大幅提升了。
过去，定义问题是产品经理、少数架构师以及技术 lead 的专属技能。现在，它成了每一个想用好 AI 的开发者都需要具备的基础能力。
这不是一个坏消息。这意味着那些愿意在这个方向上投入的工程师，会获得远超工具使用层面的竞争优势。
AI 替代的是执行，替代不了判断。学会定义问题，就是学会保住自己最核心的位置。
如果这篇文章对你有帮助，欢迎关注和转发。