前言

AI Coding 最容易给人一种错觉：既然代码几分钟就能生成，开发软件就只剩下不断向 AI 下指令。这个方法在第一天通常很顺，页面很快出现，功能似乎也能运行；但随着需求增加，AI 开始猜测技术栈、目录结构、模块职责和验收标准，第二周往往就进入返工阶段。

问题通常不在于 AI 不够强，而在于上下文不够稳定、意图不够明确、执行边界不够清晰。聊天记录会变长，会话可能中断，同一句“做一个网页翻译插件”也可以产生完全不同的实现。真正决定项目质量的，不是生成了多少行代码，而是能否把产品目标转换成 AI 可以持续理解、逐项执行并完成验收的规范。

本文通过一个 Chrome 英文文章翻译插件，完整演示如何用 SDD 推进真实项目：前五组提示词分别生成需求规范、技术架构、页面布局、任务拆分和项目规则；规范准备完成后，不再继续堆叠固定提示词，而是让 AI 读取 task.md，按任务编号依次实现、逐项验收，最终构建 dist 并导入浏览器测试。前五组文档提示词会完整保留，每组后面都讲解对应产物；编码阶段则重点解释 AI 如何按文档执行任务。

1. SDD 到底解决了什么问题

1.1 Vibe Coding 的问题不是生成速度

Vibe Coding 可以理解为“凭感觉与 AI 对话写代码”。开发者说出大致想法，AI 立即给出实现；遇到问题，再继续追加指令。这种方式适合一次性原型，但不适合需要持续维护的项目。

例如只说“帮我做一个用户认证系统”，AI 仍然需要自行猜测：

• 前端使用 React、Vue 还是原生 JavaScript。
• 后端采用 Node.js、Java、Python 还是云函数。
• 数据是真实数据库还是 Mock 数据。
• 登录状态如何保存，安全边界如何处理。
• 哪些功能属于当前范围，什么结果才算完成。

AI 猜对一次并不困难，难的是在几十轮对话中始终猜得一致。一旦新会话丢失历史背景，或不同任务使用了不同假设，项目就会出现重复代码、技术选型漂移、功能越界和难以验收等问题。

典型问题	表面现象	根本原因	实际成本
上下文丢失	新会话重复询问项目背景	决策只存在于聊天记录	重复沟通、实现不一致
AI 自行猜测	功能能跑但方案不符合预期	没有明确目标和约束	推倒重来
任务范围膨胀	做 A 时顺便修改 B、C	没有任务边界和停止条件	难以审查、难以回退
缺少验收标准	AI 说已完成，但无法判断质量	没有定义可观察结果	测试与修复成本升高
文档与代码脱节	需求变化后只有代码被修改	没有规范迭代机制	后续 Agent 继续使用旧上下文

1.2 SDD 的核心是先完成第一次创造

SDD 是 Spec-Driven Development 的缩写，通常译为规范驱动开发。这里的 Spec 不只是传统意义上的说明材料，而是驱动 AI 完成项目的持久化上下文。

SDD 的核心思想是：先把“做什么、为什么做、怎么做、按什么顺序做”写成可执行、可验证的规范，再让 AI 按照规范生成代码。

一个项目会经历两次创造：

创造阶段	需要完成的工作	主要产物	作用
第一次创造：心智创造	定义需求、设计方案、规划步骤、制定边界	proposal.md、design.md、layouts、task.md、项目规则	让 AI 获得稳定、明确的工程上下文
第二次创造：物理创造	按任务编码、测试、构建和验收	源码、测试结果、dist	把规范转换成可运行的软件

Vibe Coding 容易出问题，是因为它跳过了第一次创造，直接进入第二次创造。SDD 则把原本隐含在开发者大脑中的目标和判断显式化。代码生成成本越低，清晰、可执行、可验证的意图反而越稀缺。

1.3 三类核心规范如何协作

最基础的 SDD 流程由三类规范组成：

• proposal.md 负责回答“做什么”，明确产品需求、用户场景、范围和验收结果。
• design.md 负责回答“怎么做”，明确技术选型、系统架构、模块职责和数据流。
• task.md 负责回答“先做什么、后做什么”，把架构拆成 AI 可以逐项完成的小任务。

在真实项目中，还可以增加页面布局与项目规则。页面布局降低 AI 对界面结构的猜测，项目规则则限制技术栈、目录、代码风格和单次任务范围。整个链路如下：

产品想法
  ↓
proposal.md：需求与验收
  ↓
design.md：架构与技术决策
  ↓
docs/layouts：页面和模块布局
  ↓
task.md：按优先级拆分任务
  ↓
project_rules.md：限制 AI 的执行行为
  ↓
一次执行一个任务
  ↓
构建 dist 并导入 Chrome 验收
  ↓
把新需求继续同步回规范

2. 实战项目与开始前的准备

2.1 Chrome AI 翻译插件要解决什么问题

这个插件服务于阅读英文长文的场景。用户打开任意英文文章后，通过扩展提取页面的标题、作者、正文、原文链接和图片，再调用大模型翻译为中文 Markdown。翻译结果采用类似 ChatGPT 的打字机效果动态显示，并支持后续复制和使用。

这个项目看似只是“提取网页并调用模型”，实际包含多个不同领域的问题：

• 网页结构并不统一，如何识别主要文章内容是最关键的技术难点。
• 正文中的图片要保留，并转换为 Markdown 图片语法。
• 模型调用需要兼容 OpenAI SDK，同时能够切换到 Qwen 等模型。
• 流式响应需要转换成稳定的前端状态，驱动打字机展示。
• Chrome 扩展包含弹出页、配置页、内容脚本和后台逻辑，模块边界必须提前设计。
• 本地只保存最近一次翻译结果，不能在实现时自行扩展成历史记录系统。

这正是适合使用 SDD 的项目：目标并不复杂，但跨越了产品、浏览器扩展、网页解析、大模型调用、Markdown 渲染和本地存储多个边界。

2.2 为什么每一轮都要求“完成后立即停止”

开始前应创建项目目录与 Git 仓库，让规范和代码都进入版本控制。每完成一个可验收阶段，就检查本轮变更并建立提交点。这样即使 AI 产生幻觉或超出范围，也能定位变化并回到稳定状态。

同样重要的是管理 AI 会话。需求分析、架构设计、任务拆分和编码实现可以分别开启新会话，但每轮都要把当前阶段需要的规范路径写进提示词。新会话并不可怕，缺少可复用上下文才可怕。

提示词反复强调“当前只做这一件事，完成后立即停止”，原因是：

• 防止 AI 在需求还没确认时提前生成代码。
• 防止架构设计夹带未经确认的实现。
• 控制每轮上下文和改动范围，降低审查难度。
• 让开发者有机会在进入下一阶段前检查和修正规范。

3. 第一阶段：用 5 组提示词完成第一次创造

3.1 提示词 1：生成 proposal.md

第一轮只让 AI 分析需求并生成 docs/proposal.md。提示词如下，内容保持原样：

1.做一个基于Chrome浏览器的翻译插件，需求文档写入docs/proposal.md

以下是我的需求：
*用户在浏览任意英文网站，可以通过本插件将当前页面的主要文章内容提取出来，转换为Markdown格式并调用AI大模型进行翻译。
*翻译结果类似ChatGPT的打字机效果动态展示。
*原文中的图片需要被转换为Markdown的图片格式(`![alt](src)`)
*无需历史记录，仅需要在本地持久存储用户最近一次的翻译结果。
*最终的输出内容需要遵循以下格式
-----------
#[文章标题]

>**作者**：[作者名]
>**原文链接**:[原始文字URL]

[翻译后的正文]
-----------

当前只是在实现需求文档，请你在完成后，立即停止，需求文档不要有代码实现内容。

执行后会得到 docs/proposal.md。它不是代码实现方案，而是一份产品级契约，通常应该包含项目背景、目标用户、核心场景、功能需求、完整用户流程、数据保存范围、输出格式、异常情况、非功能要求、非目标和验收标准。

这组提示词有三个很重要的设计：

• 需求足够具体：不是笼统地说“做一个翻译插件”，而是明确正文提取、Markdown 转换、AI 翻译、打字机效果和本地持久化。
• 提供了精确输出示例：标题、作者、链接和译文的顺序都能直接作为验收标准。
• 明确停止边界：AI 只能生成需求规范，不能顺手初始化项目或编写组件。

检查项	proposal.md 中应该出现的结果
用户场景	用户在英文文章页打开插件并发起翻译
输入范围	当前页面的主要文章内容、图片和页面元信息
输出范围	固定格式的中文 Markdown
交互效果	翻译内容以打字机效果动态展示
持久化	只保存最近一次结果，不实现历史记录
非目标	不在需求阶段编写代码，不自行扩展额外功能
验收标准	每项需求都有可观察、可检查的完成条件

完成这一轮后，应先阅读 proposal.md，确认 AI 没有增加账号系统、云端历史记录、多语言管理等范围外功能。需求没有确认之前，不进入架构设计。

3.2 提示词 2：生成 design.md

需求确定后，第二轮把 proposal.md 作为输入，让 AI 设计技术架构。提示词如下：

2.
根据需求文档 `/Users/moss/Desktop/chrome-extension-en-translation/docs/proposal.md` ，完成技术架构设计文档，结果以markdown格式写入docs/design.md.
*内容提取是插件技术实现的关键和难点，请你先搜索寻找最适合的技术方案。
*翻译选择 OpenAI SDK 兼容的方式，方便切换模型，在我们的项目中会使用Qwen 模型
- 设定清晰的目录结构规范
*设定编码规范
*翻译后的内容使用md-wx组件呈现给用户，md-wx是npm的package，先安装，可以再React项目中快速引入使用，参考文档 `/Users/moss/Desktop/chrome-extension-en-translation/docs/md-wx-api-usage.md` 

当前只是在实现技术架构文档，请你完成后立即停止，技术架构文档不要有代码实现内容。

执行后会得到 docs/design.md。这一轮的关键不是罗列流行技术，而是把需求转换成有理由、有边界的工程决策。

正文提取被明确标记为技术难点，因此 AI 需要先调研可选方案，再比较正文识别准确率、图片保留能力、浏览器环境兼容性、清洗成本、包体积与维护情况。最终选型及放弃其他方案的理由都应该写入架构规范，避免编码阶段再次猜测。

design.md 还应该描述：

• Chrome 扩展中弹出页、配置页、内容脚本和后台模块分别负责什么。
• 页面内容从提取、转换、翻译到渲染的完整数据流。
• OpenAI SDK 兼容层如何隔离模型差异，从而接入 Qwen。
• 流式响应如何传递，如何驱动打字机展示与错误状态。
• md-wx 在 React 展示层中的职责，以及输入输出边界。
• 最近一次翻译结果保存在何处，什么时候写入和读取。
• 项目目录、命名规则、编码规范、权限与敏感信息处理原则。

proposal.md 中的问题	design.md 给出的技术回答
如何拿到主要文章	正文提取方案、清洗流程和失败降级
如何保留图片	DOM 到 Markdown 的转换规则
如何切换模型	OpenAI SDK 兼容的模型适配层
如何动态显示	流式响应、消息传递和前端状态管理
如何呈现 Markdown	React 与 md-wx 的渲染边界
如何保存最近结果	Chrome 本地存储的数据结构与生命周期

“不要有代码实现内容”仍然是必要边界。架构阶段可以出现模块图、目录树、数据流和接口职责，但不应该提前生成完整组件，否则架构尚未验收，代码就已经把错误决策固化下来。

3.3 提示词 3：生成页面布局

架构确认后，第三轮把页面结构转成 ASCII 布局。提示词如下：

3.根据 `/Users/moss/Desktop/chrome-extension-en-translation `plan` docs/proposal.md` `/Users/moss/Desktop/chrome-extension-en-translation/docs/design.md` 文档，规划实现的步骤，按页面、功能模块划分，用ASCll来了字符画出页面布局。结果安装页面粉文件，例如：示意图-页面.md ，页面内如果有多个模块，每个模块的布局设计在页面设计的文件体现。
结果以Markdown格式写入到docs。layouts目录下

执行后会在 docs/layouts 下得到按页面划分的布局说明，例如 示意图-弹出页.md 和 示意图-配置页.md。布局不需要追求视觉稿级别的精度，它的作用是明确页面由哪些模块组成、信息按什么层级排列、不同状态如何出现。

弹出页通常需要体现文章标题、作者与链接、提取状态、翻译状态、Markdown 展示区、复制操作和错误提示；配置页则需要体现服务地址、API Key、模型名、保存操作和校验反馈。如果同一页面有多个功能模块，每个模块都应在对应的页面布局中呈现。

ASCII 布局的价值在于便宜而明确：

没有布局规范	有布局规范
AI 自行决定按钮位置和模块层级	AI 按示意图实现结构
加载、空状态和错误状态容易遗漏	各状态提前占位
弹出页与配置页职责可能混在一起	页面职责清晰
完成后只能凭感觉判断	可以逐区域对照验收

这一轮仍然属于第一次创造。它没有生成 React 页面，却已经把页面结构转换成了后续任务可以引用的视觉契约。

3.4 提示词 4：生成 task.md

需求、架构和布局全部确定后，第四轮开始拆解任务。提示词如下：

4.根据需求文档 `/Users/moss/Desktop/chrome-extension-en-translation/docs/proposal.md` 、技术架构文档 `/Users/moss/Desktop/chrome-extension-en-translation/docs/design.md` 、页面布局 `/Users/moss/Desktop/chrome-extension-en-translation/docs/layouts/示意图-弹出页.md` `/Users/moss/Desktop/chrome-extension-en-translation/docs/layouts/示意图-配置页.md` ，完成任务拆分，结果以Markdown格式写入docs/task.md。

根据优先级对任务模块进行拆分，拆解要合理，任务需要的示意图页面或模块需要写清楚，每个任务模块都应该是独立了完成的，尽力减少依赖，完成后能看到一些效果。这个拆分后的任务我们是让AI分步骤去实现的。

执行后会得到 docs/task.md。它不是普通待办清单，而是 AI 后续编码时的执行路线图。好的任务拆分应该包含任务编号、目标、输入规范、允许修改的范围、依赖关系、预期产物、对应布局和验收标准。

“每个任务完成后能看到一些效果”非常关键。如果一个任务跨度太大，AI 可能连续改动几十个模块，开发者最后才发现方向错误。更合理的方式是让工程初始化、页面骨架、配置持久化、正文提取、模型调用、流式展示、Markdown 渲染和构建验收分别形成可检查的结果。

任务属性	合理拆分的表现
单一目标	一个任务只解决一个清晰问题
低依赖	能通过 Mock、适配层或静态状态独立展示
可观察	完成后能运行、看到页面或获得测试结果
可验收	明确什么情况算完成
可停止	达到本任务目标后不继续下一项
可回退	每个任务都适合形成独立 Git 检查点

task.md 的顺序还应该体现风险优先级。比如正文提取是核心难点，可以先做最小验证，避免所有页面都完成后才发现提取方案不可用。

3.5 提示词 5：生成 project_rules.md

任务清单解决“做哪些事”，项目规则解决“AI 做事时必须遵守什么”。第五轮提示词如下：

5.
项目规则制定 
 
根据架构文档 `/Users/moss/Desktop/chrome-extension-en-translation/docs/design.md` ，完成项目规则制定，这个规则是给 AI 看的，旨在让 AI 在当前项目开发中，能够按照规则来实现。主要包括代码风格、语言或框架、NPM 包管理、项目目录结构、项目规范等。结果以 Markdown 格式写入 ./trae/rules/project_rules.md 文件中。 

项目开发规则应该更侧重于高层面的指导原则，而不是具体的实现细节。 

以下是在别的项目中为 AI 设置的 “AI 助手任务执行规范“ 目的是让 AI 严格按照我们的规范来做，你可以将这个规范添加到我们的项目规范中。 

## AI 助手任务执行规范 

为确保开发过程的有序性和可控性，AI 助手必须严格遵循以下任务执行规范： 

### 任务范围控制 

- **严格按照任务拆分执行**: 必须严格按照 `docs/tasks.md` 中定义的任务范围执行，不得超出指定任务的边界。 
- **单一任务原则**: 每次只执行一个明确指定的任务（如"任务 1.1"、"任务 1.2"等），完成后等待用户确认再进行下一步。 
- **禁止自动扩展**: 不得基于技术架构文档或其他文档自行扩展任务范围，如果需要扩展需要通知用户确认。 

### 任务指令格式 

用户应使用以下格式明确指定任务： 

- **明确任务编号**: "请执行任务 X.X：[任务名称]" 
- **范围限制**: "只完成任务 X.X 中列出的具体任务，不要超出范围" 
- **停止指令**: "完成后等待我确认再进行下一步" 

### 执行验收标准 

- **任务完成确认**: 每个任务完成后，必须对照 `tasks.md` 中的验收标准进行自检。 
- **范围边界检查**: 确保所有创建的文件和代码都在指定任务范围内。 
- **等待用户确认**: 任务完成后使用 `finish` 工具总结完成情况，等待用户确认后再进行下一个任务。 

### 异常处理 

- **任务描述不清晰**: 如果任务描述不清晰，应先询问具体范围而不是自行决定。 
- **依赖关系处理**: 如果当前任务依赖其他未完成的任务，应明确指出依赖关系并等待用户指示。 
- **超出范围的代码**: 如果发现已创建超出任务范围的代码，应主动询问是否需要清理。

执行后会得到 ./trae/rules/project_rules.md。它相当于 AI 在该项目中的长期工作守则，主要规定技术栈、包管理工具、目录边界、代码风格、命名习惯、质量要求以及任务执行纪律。

提示词中特别强调了单一任务原则。这会阻止 Agent 看到完整架构后一次性实现所有模块。每次只做一个编号任务，完成后先对照验收标准自检，再向用户汇报并停止。这样做牺牲了一点表面速度，却显著提高了可控性。

这里还需要进行一次规范一致性检查：前面生成的是 docs/task.md，规则示例中出现了 docs/tasks.md。提示词本身保持不变，但正式执行前必须统一实际引用路径，否则 Agent 可能找不到任务规范。这个细节也说明，SDD 不是把内容写出来就结束，规范本身同样需要审查。

规则类别	project_rules.md 应承担的约束
技术边界	语言、框架、Chrome 扩展版本和核心依赖
工程边界	目录结构、模块职责、命名与导入规则
包管理	统一 npm 或其他指定工具，禁止混用锁定清单
质量要求	类型检查、Lint、构建和必要测试
任务纪律	一次只做一个任务，不自动扩展
异常处理	需求不清或依赖缺失时先停止并说明
完成汇报	对照验收标准自检，等待用户确认

到这里，SDD 的第一次创造已经完成。AI 已经知道产品是什么、架构如何设计、页面长什么样、任务如何排序以及执行时必须遵守哪些规则。

4. 第二阶段：按 task.md 依次执行开发任务

4.1 从文档产出切换到任务执行

前五轮完成后，项目已经拥有需求、架构、页面布局、任务清单和执行规则。此时 SDD 的第一次创造结束，接下来进入真正生成代码的第二次创造。这一阶段不需要继续照搬两段固定提示词，而是要把 task.md 当作执行入口，按照其中已经拆好的任务顺序逐项推进。

AI 每次开始工作前，先定位 task.md 中下一个尚未完成且依赖已经满足的任务，再读取与该任务有关的规范：

• proposal.md 提供产品目标与功能边界，防止实现偏离需求。
• design.md 提供技术栈、目录、模块职责和数据流，防止临时更换方案。
• docs/layouts 提供对应页面或模块的结构，防止 UI 自由发挥。
• task.md 提供当前任务的范围、产物、依赖和验收标准。
• project_rules.md 规定代码风格、包管理方式以及单一任务原则。

例如任务清单的第一项如果是“项目初始化和任务配置”，AI 就只完成工程脚手架、基础配置、约定目录和最小运行入口。它不能因为已经读过完整架构，就顺便实现正文提取、模型翻译或 Markdown 展示。第一项验收通过后，再从 task.md 读取下一项，而不是凭聊天记忆决定接下来做什么。

执行依据	AI 在当前任务中获得的信息
需求规范	这项功能最终服务于什么用户目标
架构规范	应放在哪个模块，采用什么技术边界
页面布局	要实现哪个页面、区域或交互状态
任务清单	本轮允许做什么，以及什么算完成
项目规则	如何编码、验证、汇报并停止

4.2 每个任务都要经过实现与验收闭环

任务执行不是让 AI 一口气把 task.md 全部做完，而是重复一个稳定的小循环。每轮只处理一个任务，完成后先验证、再确认，确认通过才进入下一项：

从 task.md 找到下一项任务
  → 检查依赖是否已经完成
  → 读取相关需求、架构、布局和项目规则
  → 只实现当前任务范围内的内容
  → 运行类型检查、Lint、测试或构建
  → 对照当前任务的验收标准自检
  → 查看 Git 变更并建立检查点
  → 等待用户确认
  → 返回 task.md 读取下一项任务

每项任务的产物并不相同。工程初始化阶段可能得到可运行的扩展骨架；页面任务会得到可以打开的弹出页或配置页；正文提取任务应得到可验证的文章结构；翻译任务应得到真实或可替换的流式结果；展示任务则需要按照布局呈现 Markdown。正因为每一步都有可观察结果，问题才能在最接近产生的位置被发现。

单项任务检查	应看到的结果
范围	只修改当前任务涉及的页面或模块
结构	与 design.md 约定的目录和职责一致
依赖	前置任务已经完成，没有绕过依赖
可观察性	能看到页面、状态、数据或测试结果
自检	满足 task.md 为当前任务定义的验收标准
停止条件	汇报完成情况，等待确认后再继续

只有当 task.md 中的任务全部完成并通过验收，才进入最终构建和浏览器测试。此时生成生产构建目录 dist，再通过 Chrome 的扩展管理页加载并进行真实网站验证。

当所有任务完成后，构建 dist 并导入 Chrome：

• 打开 Chrome 扩展管理页并启用开发者模式。
• 选择“加载已解压的扩展程序”，指向 dist。
• 打开真实英文文章，验证正文是否准确提取。
• 检查标题、作者、原文链接与图片是否符合 Markdown 格式。
• 验证 Qwen 模型配置、流式翻译和打字机展示。
• 刷新或重新打开扩展，确认最近一次结果能够恢复。
• 测试正文为空、接口失败、密钥错误和网络中断等异常状态。

验收场景	重点观察
正常英文文章	标题、作者、正文和图片提取是否完整
复杂网页	导航、广告、推荐内容是否被排除
流式翻译	内容是否持续追加，页面是否保持响应
Markdown 展示	md-wx 是否正确渲染标题、引用和图片
本地持久化	是否只保留最近一次翻译
模型切换	OpenAI 兼容配置是否能正确连接 Qwen
异常场景	是否给出明确反馈，而不是静默失败

浏览器验收是非常重要的一步。构建成功只说明工程可以打包，并不能证明扩展权限、内容脚本、跨上下文通信和真实网页解析全部正确。必须把 dist 放进实际浏览器环境，SDD 链路才算完成最后一次验证。

在这里加载未打包的扩展程序，然后选择dist文件：

最终效果

5. SDD 项目如何持续迭代

5.1 新需求要先回到规范

假设后续需要增加“保存最近十次翻译”功能，不能直接让 AI 修改存储逻辑。原需求明确规定只保存最近一次结果，新需求已经改变了产品边界，因此应该先更新 proposal.md，再同步调整 design.md、页面布局和 task.md，最后执行新增任务。

正确的变化链路是：

新需求
  → 修改 proposal.md 的范围与验收标准
  → 修改 design.md 的数据结构与模块职责
  → 修改 layouts 中的页面结构
  → 在 task.md 中新增或调整任务
  → 检查 project_rules.md 是否仍然适用
  → 按任务实现并重新进行浏览器验收

文档与代码必须保持一致。只改代码不改规范，会让下一次进入项目的 AI 继续按照旧目标工作。

5.2 Git、会话与验收共同形成安全网

SDD 解决“AI 应该做什么”，Git 解决“这一轮实际改了什么以及如何追溯”，测试与浏览器验收解决“结果是否真的可用”。三者结合后，AI Coding 才从即时对话变成可管理的工程流程。

工程机制	负责的问题
SDD 规范	固化需求、架构、任务与执行边界
独立 AI 会话	控制上下文规模，减少历史噪声
Git 检查点	追踪每轮变化，支持审查与回退
自动化检查	验证类型、规范、测试和构建
Chrome 实测	验证扩展在真实网页中的最终行为

每轮开始时明确输入规范和任务编号，每轮结束时检查改动、运行验证、记录结果并停止。项目越复杂，这套节奏越重要。它不会降低 AI 的能力，而是让 AI 的能力被放在一个可预测、可审查的轨道上。

总结

SDD 的价值不是让开发者写更多文档，而是用规范完成软件的第一次创造。proposal.md 把产品想法变成需求与验收，design.md 把需求变成技术架构，layouts 把页面结构变成视觉契约，task.md 把架构拆成可独立执行的步骤，project_rules.md 则约束 AI 的技术与行为边界。第二次创造开始后，AI 每次只完成一个任务，经过检查和确认再继续，最终构建 dist 并在 Chrome 中完成真实验收。

这套流程解决了 Vibe Coding 最常见的上下文丢失、AI 猜测、范围膨胀和难以验收问题。代码生成可以很快，但只有需求、架构、任务、规则、版本控制和测试共同形成闭环，生成速度才能真正转化为稳定的工程效率。