从 Vibe 到 Spec：把 AI 编程从“能写”升级到“可交付”的工程化工作流 2026-01-13 暂无评论 3 次阅读 # 从 Vibe 到 Spec：把 AI 编程从“能写”升级到“可交付”的工程化工作流 很多人用 AI 写代码时会遇到同一个困境：小功能看起来很快，但项目一复杂就开始“咔咔报错”，AI 改不动、自己也改不动。要让 AI 真正稳定产出，关键不是换更酷的工具，而是换一种更工程化的协作范式：**先对齐规范与计划（Spec），再开始动手实现**。 这篇文章把你给的两份材料合并整理成一套可复用的技术博客式方法论：用 **PRD 作为北极星**，用 **Spec/结构化计划**控制范围与上下文，用 **模块化规则 + 命令化工作流 + 上下文重置 + 系统演进**让 AI 越用越可靠。 --- ## 1. AI 编程范式的三阶段演进 ### 1) Tab Coding：补全式编程 - 特征：像“按 Tab 无限续写”的代码补全。 - 优点：快、轻量。 - 局限：对整体目标、架构与约束帮助有限。 ### 2) Vibe Coding：氛围编程 - 特征：边聊边改边写，“假装在编程”的流畅感很强。 - 优点：小项目/小改动很爽。 - 局限：逻辑一复杂，bug 变成“你改不动、AI 也改不动”。 ### 3) Spec Coding：规范先行，再编码 - 核心理念：**先产出规范与计划，再开始动手**。 - 工程价值：把现实世界里成熟团队的做法（需求澄清、架构设计、任务拆解、测试与验收）压缩成可复用的文档与流程，让 AI 以“同事”的方式落地交付，而不是以“网友”的方式给建议。 - 典型产物（材料中提到的三件套）： - `产品需求文档（PRD）`：定义范围、术语、验收标准（用户故事） - `技术设计文档（Tech Design）`：技术选型、接口、数据模型、错误处理策略 - `任务清单（Task List）`：按可迭代交付顺序拆解（架构→模型→状态→UI…） --- ## 2. PRD 优先：用“唯一北极星”管住范围与一致性 材料里反复强调一个要点：**PRD 是编码助手的北极星**。它最好是一份“唯一 Markdown 文档”，用来定义项目的完整工作范围与边界。 ### 从零开始（POC/MVP） PRD 通常要覆盖： - 目标用户与使命（你在解决谁的什么问题） - 明确“包含/不包含”（范围边界） - 功能模块拆分（API、UI、认证等） - 高层架构概览（不求细，但求统一口径） ### 在既有代码库上迭代 PRD 的职责会变化： - 记录“现在已经有什么能力” - 写清“下一步要构建什么” - 维持多轮迭代的连续对齐（避免做着做着跑偏） **经验法则**：不要一次让 AI 做太多。让 PRD 帮你把“大需求”切成“可独立交付的小模块”，逐个推进。 --- ## 3. 把规则写短，把上下文写对：模块化规则架构 很多人把全局规则（例如 `AGENTS.md` / `cloud.md`）写得过长，结果挤占上下文窗口，反而降低 AI 的有效推理空间。 更好的结构是： - **全局规则文件保持精简**（通用于任何任务） - 常用命令 - 测试策略/运行命令 - 日志与代码规范 - 项目结构导航（目录概览） - **把“任务类型相关”的长文档拆到 `reference/`** - `reference/api.md`：接口风格、鉴权、错误码、分页等（可很长） - `reference/frontend.md`：组件约定、状态管理、UI 规范 - `reference/deploy.md`：部署流程、环境变量、发布检查清单 - **在全局规则里用“引用/参考”按需引入** - 只有做相关任务时才加载对应参考文档 目标只有一个：**保护上下文窗口，把空间留给推理与自检**。 --- ## 4. 把一切命令化：把高频提示词变成可复用工作流 材料中的建议非常务实：**同一类提示你发超过两次，就把它命令化**。 你可以把“流程型提示词”沉淀成 Markdown 文档（或斜杠命令），例如： - 创建 PRD：`createproduct` - 新会话预热/加载上下文：`prime` - 结构化计划生成：`plan` - 执行实现：`execute` - 代码审查/提交：`review` / `commit` 长期收益： - 少重复输入 - 更一致的产出结构 - 更容易团队共享复用 --- ## 5. 关键技巧：规划与执行分离（上下文重置） 这是很多人忽略、但对质量影响巨大的点：**规划结束后，重新开启一个干净对话窗口再编码**。 原因很简单： - 规划阶段需要大量讨论与探索，会污染上下文 - 执行阶段最需要的是“干净空间”，让 AI 做推理、自我验证、按步骤实现 推荐的节奏： 1) 用 `prime` 让 AI 读到最关键的上下文（尤其是 PRD） 2) 让 AI 输出一份“结构化计划”（Markdown） 3) **清空上下文 / 重启对话** 4) 用 `execute` 把“计划文档”作为执行期几乎唯一输入，让 AI 按清单实现 这样做的本质是：**用文档把上下文“固化”，再用重置把执行“纯净化”**。 --- ## 6. 最重要的心法：系统演进（别只修 bug，要修导致 bug 的系统） 材料里把它称为“最重要的技巧”：把每一次 bug 当作增强协作系统的机会。 常见落点： - AI 总用错导入风格 → 在全局规则补一条明确规则 - AI 老忘跑测试 → 更新结构化计划模板，强制包含“测试/验证” - AI 不理解认证流程 → 新建 `reference/auth.md`，并在全局规则声明“涉及认证必须引用它” - 同类问题反复出现 → 优先改“规则/参考文档/命令”，而不是只改代码 一句话总结：**修复不止发生在代码层，也应该发生在流程与知识层。** --- ## 7. 推荐的“Spec 驱动”最小落地清单（可直接照抄） 你不需要新工具就能开始，先把产物与节奏跑顺： - 文档产物（最小集合） - `docs/prd.md`：唯一北极星 - `docs/tech-design.md`：关键设计决策与接口/模型 - `docs/plan/<feature>.md`：本次迭代的结构化计划与任务清单 - 规则与参考 - `AGENTS.md` 或 `cloud.md`：保持短（通用约束 + 引用索引） - `reference/`：按领域拆长文档（api/frontend/auth/deploy…） - 工作流节奏（每个功能都重复一遍） 1) 对齐：基于 PRD 明确“下一步做什么” 2) 规划：输出结构化计划（含验收/测试/任务拆分） 3) 重置：新对话只带计划文档 4) 执行：按任务清单实现、测试、修复 5) 演进：把踩坑反哺到规则/参考/命令 打赏: 微信, 支付宝 标签: none 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
微信
支付宝