从 0 到工程级项目：我们的 Vibe Coding 工作方法

基于 ForceTrack 从产品构思、PRD、技术方案、分阶段开发，到数据迁移、验收、体验优化和 Repo Wiki 的完整协作过程整理。

1. 什么是工程级 Vibe Coding

Vibe Coding 不是“用自然语言让 AI 一次性生成整个项目”。我们的工作方式是： 人负责目标、范围、取舍与验收，AI 负责调研、实现、验证与记录；双方通过可审查的工程产物持续校准。 可以将它理解为：

工程级 Vibe Coding
= 自然语言协作
+ 明确的产品决策
+ 可追踪的技术契约
+ 分阶段实现
+ 自动化验证
+ 人工验收
+ 可回溯的交付记录

其中：

Vibe 提高需求表达、方案探索和迭代速度。
Coding 把产品决策转化为真实运行的代码。
Engineering 保证代码可维护、可迁移、可验证、可交付。

没有 Engineering，Vibe Coding 很容易变成“看起来能跑，但无法长期维护”的 Demo。

2. 人与 AI 的职责边界

2.1 人负责什么

定义产品要解决的问题。
判断目标用户和使用场景。
确定优先级与范围边界。
选择技术方案中的关键取舍。
确认每个阶段是否验收通过。
决定何时提交、合并和发布。
对最终产品体验负责。

2.2 AI 负责什么

将模糊想法整理为结构化需求。
调研参考产品和技术资料。
检查仓库、代码、测试和 Git 状态。
输出 PRD、技术方案和任务拆分。
在约束范围内完成实现。
运行静态检查、单元测试、E2E 和构建。
分析失败原因并实施最小修复。
记录改动、验证结果和剩余风险。

2.3 双方共同负责什么

澄清歧义。
控制范围。
评估方案。
识别风险。
处理需求变化。
判断结果是否真正满足预期。

AI 可以主动执行，但不能替代产品决策和最终验收。

3. 从 0 到工程级项目的完整流程

想法
  ↓
产品定位与范围
  ↓
PRD
  ↓
技术方案
  ↓
任务拆分与验收门
  ↓
工程基础
  ↓
核心业务闭环
  ↓
增量开发与逐阶段验收
  ↓
范围扩展与数据迁移
  ↓
体验、引导和视觉一致性
  ↓
总体验收
  ↓
Git 交付与项目文档

这套流程的核心不是一次性规划所有细节，而是：

先建立稳定边界 → 小步实现 → 每步验证 → 根据证据调整 → 最终形成完整工程

4. 阶段一：先定义产品，不急着写代码

项目开始时，先回答五个问题：

谁会使用这个产品？
用户最核心的问题是什么？
产品最重要的使用闭环是什么？
与现有产品相比，有什么差异？
这一版本明确不做什么？

推荐用一句话描述产品：

为【目标用户】提供一个【产品类型】，
帮助他们完成【核心任务】，
通过【关键差异】解决【现有痛点】。

4.1 本阶段产物

一句话产品定位。
目标用户。
核心场景。
关键差异。
MVP 范围。
非目标范围。
成功标准。

4.2 阶段验收门

在用户确认产品定位和范围前，不进入实现。这一步非常重要。“先聊”表示当前目标是共同决策，不代表已经授权修改代码。

5. 阶段二：编写可验收的 PRD

PRD 不能只列页面和功能，它必须说明为什么做、做成什么样、如何判断完成。推荐结构：

# PRD
 
## 1. 背景与问题
 
## 2. 产品目标
 
## 3. 非目标
 
## 4. 用户角色
 
## 5. 核心使用流程
 
## 6. 功能需求
 
## 7. 数据与状态规则
 
## 8. 异常与边界情况
 
## 9. 非功能要求
 
## 10. 验收标准
 
## 11. 后续版本

5.1 需求必须可观察

推荐表达方式：

当【前置条件】成立，
用户执行【操作】，
系统应产生【可观察结果】，
刷新或重新进入后【持久化结果】应保持一致。

不要写：

支持任务管理。

应写：

用户可以创建、编辑和删除任务。
任务必须包含标题和状态。
创建后任务立即出现在对应列表中。
页面刷新后任务仍然存在。

5.2 明确非目标

非目标能够阻止范围不断膨胀。例如：

本版本不实现完整权限系统。
不支持多人实时协作。
不支持复杂报表。
不实现自定义工作流。
不实现无限层级的项目结构。

明确“不做什么”，与明确“做什么”同样重要。

6. 阶段三：先设计技术契约，再设计页面

技术方案的目标不是展示技术名词，而是提前固定项目中最容易返工的边界。至少需要明确：

技术栈和版本。
目录与模块边界。
领域实体和业务规则。
状态管理方式。
Repository 和持久化边界。
数据 Schema 与版本。
路由结构。
UI 组件边界。
错误恢复策略。
测试策略。
构建和交付方式。
每个阶段的验收标准。

6.1 推荐分层

UI / Page
    ↓
Application / Provider / Use Case
    ↓
Domain / Reducer / Business Rule
    ↓
Repository Interface
    ↓
Infrastructure / LocalStorage / API

UI 不应该直接读写 LocalStorage，也不应该重复实现领域规则。

6.2 领域规则要先于 UI

例如：

一个系统最多只能有一个进行中的 Sprint。
空 Sprint 不能启动。
Sprint 完成时，已完成任务和未完成任务有不同归属。
Board 顺序与 Backlog 排名属于不同概念。
删除成员时，需要明确如何处理已有任务引用。
数据损坏时，需要保留恢复记录。

这些规则如果只写在按钮事件里，后续页面、测试和迁移很容易出现不一致。

6.3 技术方案也要写非目标

例如：

暂不接入后端数据库。
暂不实现身份认证。
暂不支持并行 Sprint。
Timeline 暂不支持拖拽和缩放。
不在当前任务中提前实现后续页面。

7. 阶段四：把项目拆成相对独立的 Task

一个好的 Task 应满足：

目标单一。
输入和输出明确。
与其他 Task 的依赖清楚。
可以独立测试。
可以独立评审。
完成后项目仍处于可运行状态。
不提前侵入后续范围。

一个典型拆分方式：

Task	内容	主要验收
T0	工程脚手架与基础 UI	开发、测试、构建命令可运行
T1	领域模型与 Repository	业务规则和持久化单测通过
T2	路由、主题、国际化	刷新、切换、持久化正确
T3	核心 CRUD	创建、编辑、删除闭环
T4	核心交互	拖拽、键盘操作和状态持久化
T5	数据升级与共享 Selectors	旧数据无损迁移
T6-T8	业务页面与关联能力	页面行为满足 PRD
T9	回归验收与证据整理	检查、测试、文档全部完成

7.1 每个 Task 必须包含

## Task N
 
### 目标
 
### 范围
 
### 非范围
 
### 前置依赖
 
### 涉及模块
 
### 业务规则
 
### 实现要求
 
### 自动化测试
 
### 人工验收
 
### 完成定义

7.2 使用阶段验收门

完成一个 Task 后，先提供验证结果，再由用户确认是否进入下一阶段：

Task N 验收通过，执行 Task N+1。

这样可以避免前一阶段存在问题时，错误继续扩散到后续任务。

8. 阶段五：建立工程基础

工程基础不是“初始化一个前端项目”这么简单。至少包括：

固定依赖版本。
格式化、Lint、类型检查。
单元测试和浏览器测试。
Production Build。
路由和错误页面。
主题与设计 Token。
国际化资源。
Repository 和存储适配层。
测试数据与 Fixture。
README 和基础开发命令。
Git 分支与提交规范。

推荐建立统一质量入口：

pnpm check
pnpm test:e2e
git diff --check

其中 check 可以统一执行：

格式检查 → ESLint → TypeScript → 单元测试 → Production Build

这样，“检查通过”具有固定含义，不再依赖口头描述。

9. 阶段六：使用固定的任务执行循环

每个 Task 都使用同一套循环。

9.1 Inspect：先检查现状

开始修改前检查：

当前 PRD。
当前技术方案。
已有实现。
测试覆盖。
Git 状态。
上一个 Task 的契约。
用户已有但尚未提交的改动。

9.2 Audit：建立差距表

将现状分类为：

状态	含义	处理方式
符合	已实现且有证据	保留
部分符合	主体存在但缺少行为	补齐
缺失	尚未实现	新增
不符合	与技术契约冲突	最小修改
无法确认	缺少验证证据	增加检查
原则是：
先证明哪里有缺口，再修改；不要因为开启了新 Task，就重写已经合规的部分。

9.3 Implement：在范围内实现

只修改当前 Task 的范围。
复用现有领域契约。
保持依赖方向。
不把业务规则重复写进不同页面。
可见控件通过统一设计系统实现。
新文件和关键方法添加“目的或原因”注释。
不写重复语法的无效注释。
不覆盖或删除用户已有的有效工作。

9.4 Verify：分层验证

按风险从小到大运行：

格式和静态检查
→ 相关单元测试
→ 全量单元测试
→ Production Build
→ 相关 E2E
→ 全量 E2E
→ 人工视觉和交互检查

9.5 Report：输出任务交付卡

## Task N 交付结果
 
### 已完成
 
- ...
 
### 修改范围
 
- ...
 
### 自动化验证
 
- `pnpm check`：通过
- 单元测试：100/100 通过
- E2E：8/8 通过
- Production Build：通过
 
### 代码检查
 
- ...
 
### 人工验证
 
- ...
 
### 已知限制
 
- ...
 
### Git 状态
 
- 未提交 / 已提交 / 已合并

9.6 Gate：等待阶段确认

只有当前 Task 的验收门通过后，才进入下一阶段。

10. 阶段七：正确处理范围变化

工程项目一定会发生需求扩展。错误做法是直接把新字段塞进旧模型，然后让所有页面一起适配。这样很容易破坏现有数据、测试和行为。

10.1 重新审计

检查：

哪些现有功能已经满足新方案。
哪些需要修改。
哪些需要迁移。
哪些旧行为必须保留。
哪些测试仍代表旧契约。
哪些文档已经过期。

10.2 建立兼容性矩阵

对象	旧版本	新版本	迁移要求
Schema	V1	V2	保留旧类型作为只读输入
Storage Key	tasks:v1	tasks:v2	V2 优先，缺失时迁移
排序	position	position + rank	两种语义不能混用
Fixture	V1 数据	V2 数据	分开维护
UI	基础 Board	Board + Sprint	旧数据仍可打开

10.3 先写迁移和回归测试

迁移必须回答：

什么时候触发？
是否会重复触发？
旧数据是否保留？
ID、编号、顺序、状态和日期是否保持？
新数据损坏时如何恢复？
合法空数据是否会被误判并重新初始化？
迁移成功后写入哪个版本？
旧存储是否继续保留？

10.4 再接入新 UI

先完成：

Domain → Repository → Migration → Reducer → Selector → Test → UI

这样 UI 只是消费稳定契约，不负责修复数据。

11. 阶段八：功能完成后再做体验层

体验优化不能替代功能正确性。推荐顺序：

业务正确 → 数据可靠 → 自动化测试 → 页面可用 → 新手引导 → 视觉一致性 → 响应式和可访问性

11.1 新手引导

只覆盖关键路径。
与页面真实状态联动。
目标元素不存在时安全跳过。
自动完成的步骤不能阻塞用户。
跨页面跳转后能够继续。
用户可以跳过。
用户可以重新启动。
移动端和桌面端都需要验证。

11.2 点对点视觉修复

收到截图后，不做模糊的“整体优化”，而是记录：

观察到的异常：
预期效果：
可能影响的组件：
允许修改的范围：
验证视口：

随后定位具体组件和 CSS，实施最小修复。

11.3 页面一致性审查

统一检查：

字体层级。
标题间距。
卡片圆角和阴影。
按钮高度。
表单控件尺寸。
空状态。
Hover、Focus 和 Disabled 状态。
桌面与移动视口。
相同语义是否使用同一个设计 Token。
同类组件是否具有一致的视觉表达。

12. Skill 的选择与使用记录

工程级 Vibe Coding 不要求所有工作都由通用提示词完成。遇到专业领域任务时，应先选择匹配的 Skill，读取它的工作规范，再结合当前项目执行。 Skill 的作用是提供专业方法和检查框架，不能代替实际实现与验收。

12.1 项目开发中使用的 Skill

Skill	使用阶段	主要作用	验证方式
ux-heuristics	多项目能力与 UI 优化	从可发现性、一致性、反馈、容错和用户心智模型等角度审查交互	实际页面检查、浏览器交互和相关测试
react-joyride	新手引导	设计引导步骤、跨页面衔接、目标元素定位、跳过和重新启动机制	单元测试、E2E、桌面及移动端人工检查
visual-design-foundations	样式修复与页面一致性审查	检查字体、间距、色彩、层级、控件尺寸、圆角、阴影和状态反馈	多页面、多视口截图与浏览器人工审查

12.2 本文整理中使用的 Skill

Skill	使用目的	验证方式
pdf	读取并检查《Codex 聊天记录.pdf》，还原项目阶段、任务顺序和 Skill 使用过程	文本抽取、25 页页面渲染及视觉核对

pdf Skill 用于整理协作证据，不属于 ForceTrack 产品代码中的运行时能力。

12.3 Skill 的选择原则

出现专业任务
→ 查找对应 Skill
→ 阅读完整 Skill 规范
→ 明确 Skill 影响的工作范围
→ 按规范执行
→ 使用项目自身的测试和验收再次验证
→ 在交付记录中说明使用结果

不应为了展示“使用了很多 Skill”而强行调用无关能力。 Skill 数量不是质量指标，是否解决了真实问题才是。

12.4 Skill 在工程流程中的位置

产品与范围决策
    ↓
PRD / 技术方案
    ↓
识别专业任务
    ↓
选择并读取对应 Skill
    ↓
结合仓库现状制定实现方案
    ↓
修改代码
    ↓
项目级自动化验证
    ↓
人工体验验收
    ↓
记录 Skill 的用途和结果

核心原则： Skill 负责提供专业方法，技术方案负责约束边界，代码和测试负责证明结果。

12.5 Skill 使用记录模板

## Skill 使用记录
 
### Skill
 
`react-joyride`
 
### 使用原因
 
项目需要增加可跳过、可重新启动、支持跨页面导航的新手引导。
 
### 影响范围
 
- Onboarding Provider
- 页面 Header
- Backlog 与 Board 导航
- 引导目标元素配置
 
### Skill 提供的方法
 
- 引导步骤设计
- Target 生命周期处理
- 跨页面状态衔接
- 跳过、完成与重启机制
 
### 项目内实际验证
 
- 单元测试：通过
- E2E：通过
- 桌面视口：已检查
- 移动视口：已检查
 
### 已知限制
 
- Skill 提供的是实现指导。
- 最终正确性仍以项目测试和真实交互为准。

13. 阶段九：建立可信的验收证据

“完成了”不是验收证据。验收结果必须分成四类：

类型	可以证明什么	例子
自动化验证	程序可重复检查的行为	单测、E2E、构建
代码检查	架构和实现边界	Repository 隔离、迁移逻辑
人工验证	视觉、体验和真实交互	拖拽手感、响应式、引导流程
尚未验证	当前无法证明的内容	未部署环境、未录制流程

推荐记录：

## Acceptance Evidence
 
### Automated
 
- [x] Format
- [x] Lint
- [x] Typecheck
- [x] Unit tests
- [x] Production build
- [x] Chromium E2E
 
### Code Inspection
 
- [x] UI 未直接访问存储
- [x] 领域规则集中管理
- [x] 旧数据迁移保持兼容
 
### Manual
 
- [x] 1280 × 720 核心流程
- [x] 移动端布局
- [x] 键盘操作
- [ ] 部署环境最终验证
 
### Skill Usage
 
- [x] 记录 Skill 名称
- [x] 记录使用原因
- [x] 记录影响范围
- [x] 使用项目测试验证结果
 
### Known Limitations
 
- ...

不能把“代码看起来支持”写成“功能已经验证”。也不能因为测试命令退出码为 0，就隐瞒未配置覆盖率阈值、未进行部署验证等限制。

14. 阶段十：把 Git 交付纳入完成定义

真正的交付不是代码留在工作区。完整流程是：

确认改动范围 → 检查工作区 → 运行最终质量门 → Commit → Push → 创建 PR → 审查 PR 差异 → Merge → 更新本地分支 → 验证本地与远端一致

14.1 提交前确认

是否存在用户自己的未提交改动。
当前 Task 是否混入无关文件。
技术文档与实现是否一致。
测试结果是否来自当前提交。
分支是否基于正确的目标分支。
是否误删或覆盖已有工作。
是否记录了使用过的专业 Skill。

14.2 合并后确认

PR 状态确实为 merged。
本地目标分支等于远端目标分支。
工作区干净。
不再需要的远端分支已清理。
文档中的完成状态与实际一致。
最终提交仍然通过质量门。

15. 阶段十一：补齐项目知识和来源记录

工程级项目至少保留这些文档：

README.md
PRD.md
TECHNICAL_DESIGN.md
ACCEPTANCE.md
Repo Wiki / Architecture Guide
Skill Usage Record

15.1 README

面向第一次打开仓库的人：

项目是什么。
如何安装和运行。
如何执行测试。
当前包含哪些功能。
已知限制是什么。

15.2 技术方案

面向开发者：

架构。
数据模型。
模块边界。
关键业务规则。
迁移策略。
测试策略。
Task 和验收门。

15.3 Acceptance

面向评审者：

每项需求的验证方式。
自动化测试结果。
人工验证项目。
未验证内容。
已知风险。

15.4 Repo Wiki

面向后续维护和展示：

项目结构。
核心数据流。
关键设计决策。
为什么这样设计。
哪些是初始能力，哪些是后续增加。
常见开发和排错路径。
项目中使用过哪些 Skill，以及它们解决了什么问题。

16. 我们的实际协作模式

ForceTrack 的协作过程可以概括为：

先讨论产品方向和 MVP。
编写 PRD。
编写技术方案并明确验收标准。
将方案拆分为相对独立的 Task。
从工程脚手架、领域模型和 Repository 开始。
再实现路由、主题、国际化、CRUD 和 Board。
每个 Task 完成后独立检查、验收和合入。
扩展 Jira 能力时，先审计已完成部分，不重复开发。
通过 V1 → V2 迁移保护已有数据。
使用共享 Selector 避免页面重复计算业务状态。
完成 Backlog、Sprint、Summary、Timeline 和成员能力。
补充总体验收和技术方案。
增加多项目能力。
使用 ux-heuristics 审查交互逻辑。
使用 react-joyride 实现新手引导。
根据截图点对点修复样式异常。
使用 visual-design-foundations 执行页面一致性审查。
最后创建 Repo Wiki，沉淀项目知识。
使用 pdf Skill 整理和核对协作记录。

这条路径体现了一个重要原则：项目不是被 AI 一次生成出来的，而是由用户持续做决策，AI 按工程约束逐阶段实现、验证和交付出来的。

17. 常见失败模式

17.1 需求还没确认就开始实现

后果：方向快速偏移，代码越多，返工越大。解决：产品定位、范围和验收标准确认后再进入实现。

17.2 使用“继续”“全部优化”等模糊指令

后果：范围不可控，聊天记录无法体现专业决策。解决：每轮指令明确目标、范围、非范围和验收条件。

17.3 开始新 Task 就重写已有代码

后果：破坏已验证功能，也抹掉用户已有工作。解决：先做差距审计，只修改真实缺口。

17.4 数据模型升级但没有迁移边界

后果：旧数据损坏、字段混用、存储 Key 写错。解决：保留明确的旧版本类型，先写迁移和回归测试。

17.5 只验证正常路径

后果：真实使用中的空数据、刷新、重复操作和异常恢复失败。解决：覆盖首次使用、合法空状态、损坏数据、刷新持久化和边界规则。

17.6 把测试通过等同于体验完成

后果：功能正确，但引导、响应式、可访问性和视觉层级仍有问题。解决：自动化验收和人工体验验收分开记录。

17.7 使用 Skill 后不做项目验证

后果：Skill 的通用建议可能与当前代码结构不完全匹配。解决：Skill 只提供方法，结果仍须通过项目自身的单测、E2E 和人工验收。

17.8 为了展示而滥用 Skill

后果：流程变复杂，却没有提高质量。解决：只有专业任务确实匹配时才使用 Skill，并记录具体作用。

17.9 只 Commit，不验证远端状态

后果：代码可能未推送、PR 未合并或本地与远端不一致。解决：把 Push、PR、Merge 和远端一致性检查纳入 DoD。

18. 可直接复用的 Prompt

18.1 项目启动

先不要写代码。
 
请和我一起明确：
1. 产品定位；
2. 目标用户；
3. 核心场景；
4. MVP 范围；
5. 明确不做的内容；
6. 可测试的成功标准。
 
存在不确定项时列出方案和取舍，由我确认后再进入实现。

18.2 编写技术方案

基于已确认的 PRD 输出工程级技术方案。
 
需要包含：
- 技术栈与版本；
- 目录和模块边界；
- 领域模型；
- Repository 与持久化；
- 状态管理；
- 路由；
- UI 组件规范；
- 错误恢复；
- 测试策略；
- 数据迁移；
- Task 拆分；
- 每个 Task 的验收标准。
 
同时识别哪些专业任务适合使用已有 Skill，
说明使用原因，但暂时不要修改代码。

18.3 执行 Task

执行 TECHNICAL_DESIGN.md 的 Task N。
 
开始前先检查：
- 当前仓库和 Git 状态；
- 已有实现是否符合技术方案；
- 上一个 Task 的契约；
- 现有测试；
- 当前任务是否适合使用某个专业 Skill。
 
先输出符合、部分符合、缺失、不符合、无法确认的差距表。
 
保留合规实现，只修改真实缺口。
 
如果使用 Skill，需要记录：
1. Skill 名称；
2. 使用原因；
3. 影响范围；
4. Skill 如何影响实现；
5. 项目内的最终验证结果。
 
完成后分别报告：
- 自动化验证；
- 代码检查；
- 人工验证；
- 已知限制。

18.4 修复问题

观察到的问题：
【现象】
 
预期行为：
【预期】
 
影响范围：
【页面、组件或流程】
 
请先定位根因，不要进行无关重构。
 
如存在与该问题匹配的专业 Skill，可以使用，
但需要说明 Skill 的作用和修改边界。
 
实施最小修复，并增加能够复现该问题的测试。
 
最后说明：
- 根因；
- 修改边界；
- 使用的 Skill；
- 自动化验证；
- 人工验证；
- 已知限制。

18.5 总体验收

按照 PRD 和 TECHNICAL_DESIGN.md 对当前项目执行总体验收。
 
逐项标记：
- 已通过；
- 部分通过；
- 未通过；
- 无法验证。
 
证据必须区分：
1. 自动化测试；
2. 代码检查；
3. 人工交互验证；
4. 尚未验证项。
 
同时汇总项目使用过的 Skill：
- 名称；
- 使用阶段；
- 解决的问题；
- 影响范围；
- 最终验证证据。
 
不要把推测写成已验证结论。

18.6 需求变更

需求发生变化，暂时不要直接修改代码。
 
请先：
1. 审计已有实现；
2. 标记符合、部分符合、缺失和冲突项；
3. 识别数据、Schema、Storage Key 和测试迁移风险；
4. 说明哪些旧行为必须保留；
5. 更新技术方案和验收标准；
6. 重新拆分 Task；
7. 判断是否需要使用专业 Skill。
 
我确认方案后再执行。

19. 工程级 Vibe Coding Definition of Done

一个项目只有满足以下条件，才可以称为工程级交付。

19.1 产品

产品定位清楚。
MVP 和非目标范围明确。
核心用户流程完整。
每个需求可验收。
关键取舍由用户确认。

19.2 架构

领域规则有明确归属。
UI、业务和基础设施边界清楚。
数据结构有版本。
升级过程有迁移策略。
没有重复实现同一业务规则。
旧数据和旧行为得到兼容保护。

19.3 实现

Task 范围独立。
已有合规工作被保留。
可见组件遵循统一设计系统。
关键设计原因有必要注释。
异常和空状态得到处理。
没有混入无关重构。

19.4 Skill

专业任务使用了匹配的 Skill。
使用 Skill 前读取了对应规范。
记录了 Skill 名称和使用原因。
记录了 Skill 的影响范围。
没有为了数量调用无关 Skill。
Skill 产生的结果经过项目级验证。

19.5 验证

Format、Lint、Typecheck 通过。
单元测试通过。
Production Build 通过。
核心 E2E 通过。
刷新和持久化行为通过。
响应式、键盘和视觉行为经过人工检查。
未验证内容被如实记录。
测试限制和覆盖率情况被如实说明。

19.6 交付

技术文档与代码一致。
Acceptance Evidence 完整。
Skill Usage Record 完整。
Commit 范围清晰。
PR 已审查和合并。
本地与远端状态一致。
README 和 Repo Wiki 足以支持后续维护。

20. 结论

高质量 Vibe Coding 的关键，不是给 AI 一条更长的 Prompt，也不是使用尽可能多的 Skill，而是建立一套稳定的协作协议：

先决策，再实现；
先定义契约，再设计页面；
先审计，再修改；
专业任务选择匹配的 Skill；
Skill 结果必须由项目测试证明；
小步执行，逐步验收；
失败必须解释根因；
完成必须提供证据；
代码、文档和远端状态必须一致。

当自然语言协作被 PRD、技术方案、Task、Skill、测试、验收门和 Git 交付约束起来，Vibe Coding 才会从快速 Demo 生成，真正升级为可维护、可验证、可持续迭代的工程方法。最终可以将我们的工作方式概括为：

用户主导方向和判断，AI 提高分析与执行效率，Skill 提供专业方法，工程契约控制边界，测试与验收负责证明结果。