作者：vivo IT 技术团队- Fan Jiaojiao
在存量项目的增量开发中，AI 常常面临理解偏差、执行不稳、需要频繁纠正等问题。本文介绍自建的「OpenSpec 规范层 + AI Workflows 执行层」体系，通过一套「规范 + 技能 + 钩子」机制，对 AI 的理解、执行和校验进行系统化约束与增强，显著提升开发协作中的准确率与稳定性，让 AI 从“需要反复纠正的实习生”逐步成长为“可信赖的开发搭档”，文中附完整实战案例。

1分钟看图掌握核心要点👇

一、写在前面：为什么要做这件事

1.1 我的背景

从 Vue 2 转到 Vue 3.5 + <script setup> + TypeScript + Pinia + Vant 4 + vue-i18n 的全家桶时，说实话，Composition API 和 TypeScript 的组合确实让我花了不少时间去适应。

但恰恰是这种"不够熟练"，让我更深刻地感受到 AI 辅助开发的价值—— AI 补齐了我在 Vue 3 新特性和 TS 类型体操上的短板，让我能把精力集中在业务逻辑和架构设计上。

但同样因为"不够熟练"，我也更早碰到了 AI 协作的天花板：

• AI 生成的 TS 代码我没法一眼判断好坏，需要一套规范来兜底
• 我不熟悉项目中已有的工具函数和组件，AI 也不知道，经常重复造轮子
• 涉及国际化、状态管理这类项目约定时，AI 和我一样“不知道该怎么做才对”

这逼着我去思考：怎样才能让 AI 不仅写出能跑的代码，还能写出符合项目规范的代码？

如果你正在用 AI 辅助编码，大概率遇到过这些问题：

• 每次都要重新教 AI：上次聊过的项目规范、技术栈约束，下次开新会话就全忘了
• AI 总在“自由发挥”：不遵守项目的目录结构、命名规范、国际化流程
• 复杂功能 AI 做不好：涉及多文件、多模块的增量开发，AI 经常丢三落四
• 缺乏质量保障：AI 生成的代码没有经过系统性的检查和规范验证
• 知识无法复用：这次踩的坑、总结的经验，下次还得重新踩一遍

1.2 存量项目做增量需求：这才是真正的难题

上面说的痛点，在新项目里还能忍一忍。但在存量项目上做增量开发，这些问题会被放大好几倍——而我们大多数人的日常工作恰恰就是这种场景：很少从零开始，更多是在已有代码上添砖加瓦。

常见的困境：

拿我实际做的 vivo+ 积分券功能来说，它涉及 10+ 文件修改，并且要跟已有的零售开单流程、整单优惠组件、会员体系无缝衔接。如果直接让 AI 开写，它完全不知道：

• 项目已经有了 useFullscreenDialog 组合式函数，弹窗应该复用而不是重写
• 已有的 WholeDiscount.vue 组件是积分券入口的正确位置
• 国际化词条应该放在 zhLang.ts 而不是单独建文件
• 串码商品和非串码商品的选择逻辑完全不同，需要理解业务规则

所以，我需要一套体系来「教会 AI 理解项目上下文」，而不是每次都靠对话补充。

1.3 思考

我开始思考一个问题： 能不能像培养团队成员一样培养 AI？

一个新人加入团队，我们会给他：

• 项目文档（了解业务）
• 开发规范（知道怎么写）
• Code Review（保证质量）
• 经验传承（避免重复踩坑）

那 AI 呢？我们能不能也给它一套「标准化的知识体系」，让它：

• 读规范 → 理解要做什么
• 用技能 → 知道怎么做
• 触发钩子 → 自动检查质量
• 积累经验 → 越用越好

这就是 AI Workflows 的起点。

1.4 选择规范驱动而非 Prompt 驱动的原因

最初我也尝试过写很长的 System Prompt，但很快发现了问题：

说起来直白：把经验变成可执行的规范，把规范变成 AI 能理解的技能，把技能编排成可重复的工作流。

而 OpenSpec 就是这个体系中「规范」的具体载体——它用三层文档（proposal → design → tasks）把模糊的需求变成 AI 可以逐步执行的结构化指令。OpenSpec 没有 AI Workflows，规范就是一堆静态文档；AI Workflows 没有 OpenSpec，执行就没有依据。

二、先搞清楚核心概念

2.1 规范驱动开发 (Specification-Driven Development)

基本思路：在写任何代码之前，先完成结构化的规范文档。

传统方式：需求 → 编码 → 发现问题 → 返工  
规范驱动：需求 → 结构化提案 → 技术设计 → 任务拆解 → 编码

这不是 Waterfall 的复辟，而是在 AI 协作场景下的一种 对齐机制：

• 让 AI 和人对"做什么"达成共识
• 让 AI 在明确的边界内发挥能力
• 让人能快速审查 AI 的理解是否正确

2.2 为什么是"规范"而不是"对话"

与 AI 对话式开发的区别：

回过头来看，AI 辅助开发最大的瓶颈其实不是 AI 的代码能力，而是 上下文怎么给到它。对话式开发是"即时传递"——每次会话从零开始，上下文靠口述；规范驱动开发是"结构化注入"——把项目知识编码成 AI 能理解的数据结构，按需加载，一次写好，长期生效。这就像"口头交代"和"书面文档"的差别。

三、系统架构

3.1 整体架构图

3.2 目录结构

ai-workflows/  
├── workflows/                   # 工作流定义（4 种场景）  
│   ├── feature-development.md   # 功能开发  
│   ├── bug-fix.md               # Bug 修复  
│   ├── hotfix.md                # 紧急修复  
│   └── refactor.md              # 代码重构  
├── skills/                      # 技能库（33 个技能，4 大分类）  
│   ├── project/                 # 项目级技能（8 个）  
│   │   ├── vue3-component/      # Vue3 组件开发  
│   │   ├── vue3-store/          # Pinia Store 状态管理  
│   │   ├── api-service/         # API 接口服务  
│   │   ├── i18n/                # 国际化管理  
│   │   └── style/              # 样式与主题 ...  
│   ├── business/                # 业务级技能（19 个）  
│   │   ├── retail-ordering/     # 零售开单  
│   │   ├── home-page/           # 首页  
│   │   └── ...                  # 各业务模块  
│   ├── workflow/                # 工作流技能（4 个）  
│   │   └── cross-module/        # 跨模块协作 ...  
│   └── quality/                 # 质量保障技能（2 个）  
│       ├── code-review/         # 代码审查  
│       └── regression-test/     # 回归测试  
├── hooks/                       # 钩子系统（17 个钩子）  
│   ├── config.yaml              # Hook 配置  
│   ├── before-message/          # 消息前（6 个）  
│   ├── after-message/           # 消息后（3 个）  
│   ├── after-edit/              # 编辑后（3 个）  
│   └── skill-loaded/            # 技能加载后（2 个）  
├── templates/                   # 模板库  
│   ├── vue/                     # Vue 组件模板  
│   ├── api/                     # API 模板  
│   ├── store/                   # Store 模板  
│   └── i18n/                    # 国际化模板  
└── schemas/                     # 数据模式定义

这套架构的核心思路是"关注点分离"：OpenSpec 管"输入"（需求的结构化），AI Workflows 管"执行"（能力的组合化）。两层解耦之后，更换 AI Workflows 的实现方式不会影响规范层的定义，不同项目之间也可以共享同一套 project 技能，各自补充 business 技能就行。

四、OpenSpec：变更管理系统

4.1 什么是 OpenSpec

OpenSpec 是变更管理的 规范层，每个功能开发、Bug 修复都是一个 "Change"：

openspec/changes/  
├── vivo-plus-coupon/  
│   ├── proposal.md      # 为什么做、做什么、验收标准  
│   ├── design.md        # 怎么做、架构、API、组件设计  
│   └── tasks.md         # 任务拆解、优先级、依赖关系  
└── another-feature/  
    ├── proposal.md  
    ├── design.md  
    └── tasks.md

4.2 三层文档的设计哲学

为什么是三层而不是一层？

• 渐进式细化：从宏观到微观，每层都可以独立审查
• 关注点分离：产品只需关注 proposal，开发只需确认 design
• AI 友好：tasks.md 直接告诉 AI "现在做第几个任务"，减少歧义

4.3 工作流程

五、AI Workflows：执行层

5.1 组件总览

5.2 Skills 技能系统

技能是 AI Workflows 中最有意思的部分。它把人的开发经验结构化为 AI 可执行的指南。

技能结构：

# SKILL.md  
  
## 适用场景  
  
- 关键词识别："组件"、"vue"、"页面"  
  
## 工作流程  
  
1. 检查目标文件是否存在  
2. 分析当前代码结构  
3. 按模板生成/修改代码  
4. 检查国际化和类型定义  
  
## 不适用场景  
  
- 纯样式修改 → 使用 project/style  
  
## 关键检查清单  
  
- [] TypeScript 类型完整  
- [] 国际化词条复用  
- [] 组件 scoped 样式

技能分为四类：

5.3 Hooks 钩子系统

钩子是 被动触发的质量守卫，在关键时刻自动介入：

其中几个重要的：

• ensure-user-review：阻止 AI 在规范文档未审查前开始写代码
• recommend-workflow：根据用户意图自动推荐合适的工作流
• auto-format-code：编辑后自动格式化

六、核心组件如何协同工作

6.1 OpenSpec 与 AI Workflows 如何联动

这是整个体系最核心的部分。那么： OpenSpec 和 AI Workflows 到底什么关系？

一句话总结： OpenSpec 定义“做什么”，AI Workflows 指导“怎么做”。

完整协同流程：

用户发起需求  
    │  
    ▼  
[Hook: recommend-workflow] → 推荐 feature-development 工作流  
    │  
    ▼  
AI 读取 workflows/feature-development.md → 获取步骤  
    │  
    ▼  
AI 使用 templates/ → 创建 OpenSpec 规范文档  
    │   ├── proposal.md    (为什么做、做什么、验收标准)  
    │   ├── design.md      (架构、API、组件设计)  
    │   └── tasks.md       (任务拆解、优先级)  
    │  
    ▼  
[Hook: ensure-user-review] → 等待用户审查 OpenSpec 文档  
    │  
    ▼  
用户审查通过  
    │  
    ▼  
AI 加载 skills/business/retail-ordering → 理解业务上下文  
AI 加载 skills/project/vue3-component   → 按任务逐步实现  
    │  
    ▼  
[Hook: after-edit/auto-format-code] → 自动格式化  
[Hook: after-edit/run-linter]      → 自动检查  
    │  
    ▼  
所有 tasks 完成 → 归档 Change

6.2 多技能如何协同

一个复杂功能往往需要多个技能协同：

vivo+ 积分券功能  
├── OpenSpec (规范层 - 独立工具)  
│   ├── proposal.md    → 明确业务目标和验收标准  
│   ├── design.md      → 定义 API、组件结构、数据流  
│   └── tasks.md       → 拆解为 10 个可执行任务  
└── AI Workflows(执行层)  
    ├── Workflows      → 编排执行步骤（feature-development.md）  
    ├── Skills         → 封装领域经验（retail-ordering、vue3-component、i18n...）  
    ├── Hooks          → 关键节点自动检查（ensure-user-review、auto-format-code...）  
    └── Templates      → 标准化代码/文档格式（Vue 组件模板、API 模板...）

理解这套体系，不用死记每个组件的定义，关键是理解它们之间的信息流动：

用户输入 → Hooks 触发推荐 → Workflows 编排步骤 → Skills 提供执行能力 → Templates 保证输出格式 → Hooks 再检查结果。

这是一个"输入 → 编排 → 执行 → 输出 → 验证"的闭环。每个组件解决一个特定的瓶颈：

• Hooks 管"什么时候用什么"
• Workflows 管"先做什么后做什么"
• Skills 管"具体怎么做"
• Templates 管"做成什么样"

正因如此，这套体系——而不是任何单一组件——才能让 AI 从"需要反复纠正的实习生"变成"可信赖的开发搭档"。

七、完整实战案例：vivo+ 积分券

7.1 需求背景

这个功能是在零售下单确认页加 vivo+ 积分券——会员验证通过后，可以选多倍积分券关联到商品上。听着不复杂，但真正动手前有几个绕不过去的坎：

• 涉及面广：10+ 文件要改，从整单优惠组件到商品行、从 Store 到 API、从类型定义到国际化词条
• UI 惯例问题：我给了 Figma 交互稿，但 AI 拿到后没去翻项目里已有的弹窗组件是怎么实现的，自己生成了一套新的——跟项目惯例对不上
• 业务规则绕：串码商品要逐台校验 IMEI，非串码商品直接选数量；同个商品不能被多张券同时选中；跨券切换还要弹确认框
• 不能破坏已有逻辑：积分券要跟已有的官网优惠互斥，会员切换或订单来源变化时得自动清空已选券

这些不是"AI 不够聪明"的问题，是"AI 不知道项目里有什么、不知道业务规则是什么"的问题。而这正是这套体系要解决的。

7.2 规范阶段：先把"做什么"写清楚

动手写代码之前，先写规范文档。我给 AI 的需求跟平时一样——需求背景、功能要点、Figma 设计稿链接、参考的已有组件，都写清楚了：

"在零售下单确认页加 vivo+ 积分券功能。整单优惠区域加入口，点击弹出选择弹窗，支持 2 倍/5 倍券，每个券只能选一个商品，跨券切换要确认，设计稿及具体功能点见附件。帮我分析代码结构，给出开发方案。"

AI 加载了 retail-ordering 业务技能后，第一轮就找到了 WholeDiscount.vue、ProductInfo.vue 等关键文件，分析完现有代码结构后，生成了 proposal.md、design.md 和 tasks.md（15 个拆解任务）。我没有一行一行地指导——技能让 AI 知道这个模块的代码在哪里、数据怎么流、枚举叫什么名字，它自己就能把方案写出来。

规范阶段有两个时刻让我觉得这套东西确实省事了：

API 中途变更。后端通知接口设计变了——原来计划多个接口分别查，改成一个接口传 skuCodeList 数组。我只说了一句"API 改为只有一个接口，传商品 skuCode 列表"，AI 自己去 design.md 里更新了接口设计，然后改了三处代码：API 函数签名、调用方、类型定义。没多动任何一个文件——因为 design.md 把影响范围写清楚了。

国际化零重复词条。我说"先检查 zhLang 中有没有定义"，AI 按 i18n 技能的流程先扫了一遍 zhLang.ts，确认没有积分券相关词条后才新增，命名跟着项目规范走，然后在业务模块里通过 getLanguage() 引用。整个过程零重复词条。

7.3 实现阶段

规范文档就绪后进入代码实现。前面已经说过，技能帮 AI 省掉了大量"对齐信息"的来回——不需要问弹窗用什么组件、词条放在哪、枚举叫什么。实际写代码的时候，对话聚焦在真正的决策上。

这里讲几个关键节点：

架构对齐。最初 AI 把积分券的显示逻辑、弹窗状态都放在了 WholeDiscount.vue 里。vue3-component 技能里有一条规则："实现组件前先检查项目中类似功能的组件是怎么写的"。AI 读取了 OfficialWebsite.vue 后发现，项目惯例是把优惠组件做成自包含的——于是主动把入口显示、已选列表、弹窗管理、Store 更新全部收敛到 VivoPlusCoupon.vue 内部，WholeDiscount.vue 只保留一行调用。

这个决策是战略性的，不是补救性的——AI 不是因为写错了才改，而是因为技能里的规则让它"先看再写"。

串码与非串码商品的分支处理。积分券选中商品后，串码商品需要逐台输入 IMEI 码校验，非串码商品直接选数量就行。这个区分是业务规则，不是 UI 偏好——如果 AI 把所有商品都当成选数量来处理，串码商品的逐台校验流程就漏了。retail-ordering 业务技能里记录了串码商品的 IMEI 校验逻辑和 ImeiControlFlagEnum 枚举，AI 在读现有商品行组件时就已经知道这两种商品的存在，分支判断一开始就写对了，没有等联调才发现漏了场景。

设计稿还原。以前让 AI 还原设计稿，间距、字号、颜色全靠"估"——看着截图猜，猜不准就得来回调。这次通过 MCP 工具直接读取 Figma 设计数据，AI 拿到的是精确的数值而不是从截图里估出来的大概值，样式一次写对，省掉了反复调整的循环。

7.4 这套体系到底改变了什么

7.5 案例的关键数字

• 12 项功能验收标准全部通过，tasks.md 拆解了 15 个任务
• 10+ 文件修改和新增，涵盖组件、Store、API、国际化、类型定义
• 0 个重复词条——i18n 技能的"先检查再创建"被严格执行
• retail-ordering 业务技能从这次实践中沉淀了 13 个核心子技能，后续同模块的需求 AI 不再需要重新理解上下文

7.6 案例反思：协作体验的变化

前面讲了规范怎么写、代码怎么实现。换个角度——作为开发者，用这套体系跟 AI 协作，体验上到底有什么不同？

安全感：知道 AI 不会乱动

以前跟 AI 协作开发，最怕的不是它写不对，而是不知道它还会改哪里。一个接口变更，它可能"热心"地把调用方的写法也重构了；一个样式调整，它可能顺手改了组件结构。每次提交前都要花时间排查"AI 都动了哪些文件"。

这次开发 vivo+ 积分券，印象最深的是：AI 改动的范围跟我预期的一致。API 变更时它只改了 API 层的三个点就停下来等我确认，没有继续"优化"其他文件——以前这种时候我得花 20 分钟排查它额外动了什么。弹窗直接复用了项目封装而不是自己造一套。这种"知道 AI 不会乱动"的安全感，跟以前那种"不确定 AI 会动哪里"的不安感，差别很大。

心智负担：不用每次都重新教

没有这套体系时，每次开新会话都要重新解释一遍项目：枚举在哪、组件怎么组织、弹窗用什么封装。同一个功能，换个会话就得重来。这些解释本身不难，但累积起来很消耗——你得时刻想着"AI 现在知不知道这个？"

现在这些知识写在技能里，每次自动加载。同一个 vivo+ 积分券功能，我分三次会话完成不同部分，每个会话 AI 都知道 WholeDiscount.vue 在哪、OrderSourceEnum 是什么、国际化词条该放在哪——不用重新教。注意力可以集中在真正的决策上：这个交互逻辑怎么设计、这个边界条件怎么处理。写代码变成了决策的执行，而不是信息的搬运。

没犯本该犯的错

回看这次开发，让我印象最深的不是 AI 多厉害，而是它"没犯本该犯的错"。6.4 表格中列出的每一项——零重复词条、弹窗直接复用、API 精准响应——本质上都是 AI 在"不知道"的情况下本可以犯的错，但因为技能里有规则，它没犯。

还有几次，Hook 在关键时刻拦住了 AI 的"自作主张"——这些故事放在第 7 章详细讲。

这些都不算轰动性的成绩，但它们说明了一个共同的东西：AI 协作的价值不在于写得多快，而在于少犯错、少偏离项目约定、少让你事后收拾残局。

八、经验沉淀与持续优化

搭建完体系只是第一步。真正让它产生长期价值的，是在实践中不断打磨、对技能做持续迭代。分享一下我在这个过程中体会最深的几点。

8.1 从踩坑到技能：一个技能的诞生

以"国际化 i18n"技能为例，它的诞生源于一次典型的事故。

在做会员注册功能时，AI 在组件里硬编码了"请输入手机号"。我当时没注意到，代码合入后，国际化测试才发现这个问题——在英文环境下这个文案还是中文。更糟的是，AI 在另一个组件里又新建了完全重复的词条 PLEASE_INPUT_PHONE。

这次事故让我意识到： 国际化问题不是 AI 的错，而是我没有告诉它"正确的做法"。

于是我写下了 skills/project/i18n/SKILL.md，核心只有 4 条规则：

• 先检查 zhLang.ts 是否已有词条
• 已有 → 直接复用
• 没有 → 按规范新增（驼峰命名、语义化、按功能分组）
• 在业务模块中通过 getLanguage() 引用

从那以后，所有涉及国际化的修改，AI 都会先执行这个流程。 一次事故 → 一条规则 → 一个技能 → 长期生效。

最好的技能不是"设计"出来的，而是"事故"逼出来的。每当你发现 AI 做错了什么，问自己：如果有一条规则能避免这个错误，这条规则是什么？然后把它写成技能。

8.2 技能不是写完就完了：vue3-component 的三次迭代

vue3-component 技能记录的是怎么写一个 Vue 组件。最开始写得很简单：分析需求、定位文件、生成代码。感觉够用了。

用了几次之后发现问题。有一次我让 AI 调整一个按钮的颜色，它加载了 vue3-component 技能，创建了一个新的包装组件——完全没必要，直接改 CSS 就行。技能没有说清楚哪些情况不适用，于是我加了一节「不适用场景」：

## 不适用场景
- 纯样式修改 → 使用 project/style
- 只改文案不涉及逻辑 → 直接在组件中修改
- Store 数据修改 → 使用 project/vue3-store

加上这节后，类似的乌龙少了很多。

又过了一段时间，发现新问题：AI 生成的组件有时会漏掉国际化——文案直接写死，没有走 $t()。不是 AI 不会，而是没有人让它检查。于是加了一张强制检查清单：

## 关键检查清单
- [ ] 组件内文案是否使用了 `$t()` 或 `t()` 进行国际化？
- [ ] 弹窗是否参考了已有的 fullscreen-dialog 组件？
- [ ] TypeScript 类型是否完整（无 `any`）？

加了这张清单之后，国际化遗漏的问题基本消失了。

这个过程说明了一个规律：不用一开始就追求写一个完美的技能。AI 每犯一次拦不住的错，就往技能里加一条。时间久了，技能就从一份指南变成了一张防错清单。

8.3 那些被 Hook 拦住的「事故」

如果说 Skills 是"教 AI 正确做事"，那 Hooks 就是"防止 AI 做错事"。以下是两个真实案例：

案例一：一次被拦住的"擅自行动"

有一次，我在对话中描述了一个新功能的想法，还没想好具体方案。AI 因为加载了 feature-development 工作流，直接开始创建 proposal.md 并计划写代码。但 ensure-user-review Hook 检测到我没有说"确认通过"，直接阻止了 AI 的文件创建操作。

[Hook: ensure-user-review] 检测到未确认，已阻止以下操作：
✗ create_file: proposal.md
✗ replace_in_file: src/views/...
AI 必须等待用户"确认通过"后才能继续。

如果当时 AI 擅自修改了代码，我需要花时间审查和回滚。这个 Hook 帮我省了至少 30 分钟。

案例二：格式化拯救了一次 Code Review

AI 生成了一个较长的业务方法，代码逻辑正确，但缩进混乱、有 3 个未使用的 import、变量命名风格不统一。after_edit/auto-format-code 自动执行了 prettier 和 eslint --fix，修复了所有格式问题。同事 Code Review 时只关注了逻辑，没有因为格式问题打回。

Hooks 的价值在于"无感知保障"——你不需要记得手动格式化、手动检查，它们自动在关键时刻执行。就像汽车的 ABS 系统，你感觉不到它的存在，但它可能已经帮你避免了一次事故。

8.4 协作模式的转变：从"纠正"到"确认"

使用这套体系前后，我和 AI 的协作模式发生了质的变化：

之前（对话式开发）：

我：描述需求 → AI 生成代码 → 我发现 3 个问题 → 我纠正 → AI 修改 → 我发现新问题 → 再纠正 → AI 再修改 → 勉强可用

这是一种 "纠正模式"——我的角色是纠错者，AI 的角色是被纠正者。每一轮对话都在弥补 AI 对项目知识的缺失。

之后（规范驱动）：

我：描述需求 → AI 加载技能理解上下文 → AI 生成 proposal → 我审查确认 → AI 按任务实现 → Hook 自动检查 → 代码可用

这是一种 "确认模式"——我的角色是决策者和审查者，AI 的角色是执行者。AI 因为有了技能的知识储备，输出的代码已经符合项目规范，我只需要确认"方向对不对"，而不是纠正"细节错没错"。

这种转变意味着什么：

这便是这套体系最实际的意义：它让 AI 辅助开发从一种"消耗性"活动（不断纠错）变成一种"增益性"活动（专注业务）。

九、从零搭建：两周实践指南

前文介绍了体系设计，但多数人可能更关心： 怎么落地？投入多少时间？门槛多高？ 本节给出一个经过验证的两周实践路径。

9.1 最小可行搭建

目标：让 AI 能在至少一个场景下"不用教第二遍"。

第一阶段：

• 创建目录结构——按照 2.2 节的目录结构创建空文件夹。这一步不需要内容，但结构要对。
• 编写第一个 project 技能——选择你的项目中最容易出错的一个环节。我的选择是"国际化"，因为它规则明确（检查 → 复用 → 新增）、价值立竿见影（避免词条重复）。
• 配置 ensure-user-review Hook——这是性价比最高的 Hook，只需定义确认关键词和阻止操作。
• 编写 AGENT.md——告诉 AI 这套体系的存在和基本使用方式。

第二阶段：

• 用这套体系完成一个真实的简单修改——比如"修改会员验证的验证码从 4 位改为 6 位"。重点不是这个功能本身，而是验证体系是否起作用：AI 是否加载了技能？生成的代码是否符合规范？Hook 是否正确触发？
• 根据反馈调优——第一次使用一定会发现各种小问题，记录下来，但不要急于修改技能。

我的实际经历：第一阶段搭完国际化技能后，第二阶段用一个真实测试验证，AI 自动去 zhLang.ts 检查词条、按规范新增——那一刻我知道这个方向是对的。

9.2 运行第一个完整功能

目标：用 feature-development 工作流完成一个涉及 5+ 文件的增量功能。

建议步骤：

• 选择一个真实但不紧急的功能——不要用紧急需求做实验。理想选择是"一直想做但优先级不高"的小功能。
• 严格走完完整流程——proposal → design → tasks → 审查 → 实现，一步不少。第一遍走完比走快更重要。
• 记录所有"如果 AI 知道就好了"的时刻——转化为新的 business 技能或技能检查项。

vivo+ 积分券功能开发中，我沉淀了 3 个 business 技能：

• retail-ordering：零售下单的业务流程、核心组件、数据流
• vivo-plus-coupon：积分券的业务规则、串码/非串码选择逻辑
• whole-discount：整单优惠的组件入口和互斥规则

9.3 从"能用"到"好用"

目标：让体系从"辅助我"变成"团队能用"。

关键动作：

• 技能查漏补缺——对照项目规范文档，检查是否每个关键约定都有对应技能。至少保证：组件开发、API 开发、国际化、Store 管理这四个 project 技能覆盖完整。
• 增加 after-edit Hook——auto-format-code 和 run-linter 这两个 Hook 的配置只需 30 分钟，但每天能帮你省 10-15 分钟的格式化时间。
• 沉淀踩坑经验——把 第一阶段中记录的"如果 AI 知道就好了"转化成技能检查项。到 第二阶段结束时，每个技能至少经历过一次迭代。
• 编写使用指南——花 1 小时写一个简短的 README，告诉团队成员：有哪些技能、怎么触发、有哪些 Hook 在保护代码质量。

9.4 持续打磨：让知识库活起来

体系搭好之后，它的价值取决于你是不是坚持维护下去。

几条 建议：

• 每个功能至少沉淀一个经验——完成一个功能后，问自己：下次做类似功能，AI 还需要知道什么？把它写进技能。
• 技能要定期"瘦身"——技能太长（超过 200 行）反而会让 AI 忽略关键信息。我的经验是控制在 100-150 行，超过就拆分。
• 删除过时的内容——废弃的 API、移除的组件，及时从技能中删除。过时的知识比没有知识更危险。

十、总结与展望

10.1 实际效果

经过多次功能的实践验证：

10.2 写在最后

AI Workflows 不是让 AI 更聪明，而是给 AI 提供了"正确做事的方法论"。

就像给一个能力很强但不了解项目的开发者，配齐了：

• 项目知识库（Skills）
• 开发流程指南（Workflows）
• 质量检查清单（Hooks）
• 代码模板（Templates）

10.3 下一步

后续希望做的几件事：

• 让 AI 完成任务后能自动提取经验沉淀为技能，而不需要手动整理
• 把 project/ 技能包做成可以跨项目复用的标准模块
• 探索同类技术栈的项目之间是否能共享 skills 生态
• 记录每个技能的使用数据，用数据驱动技能的迭代优化

附录

A. 技术栈

本实战案例基于以下技术栈：

• Vue 3.5 + <script setup> + TypeScript 5.x
• Vite 6 + Pinia 3 + vue-i18n 11
• Vant 4 + TailwindCSS 3
• pnpm + ESLint 9 + Vitest

B. FAQ

Q: 前期投入大吗？

A: 基础设施 1-2 天即可搭建。核心价值在于 持续沉淀——每完成一个功能，团队知识库就增长一点。前 3 个功能可能感觉投入产出比一般，从第 4 个功能开始效果显著提升。

Q: 适合什么规模的项目？

A: 建议中大型项目（10+ 页面、多人协作）。小项目直接对话式开发更高效。

Q: 技能会不会过时？

A: 会。但技能是 Markdown 文件，更新成本很低。建议在每次使用后检查是否需要更新。

Q: 和 RAG 有什么区别？

A: RAG 是被动检索，AI Workflows 是主动编排。RAG 回答"这个知识在哪"，AI Workflows 回答"现在应该做什么"。两者可以互补。

本文基于一个真实的 Vue 3 + TypeScript 零售 H5 项目的 AI 协作开发实践总结。希望这套方法和思路对你有所启发。