【写在前面为什么要做这件事】在存量项目的增量开发中AI常常面临理解偏差、执行不稳、需要频繁纠正等问题。本文介绍自建的「OpenSpec规范层 AI Workflows执行层」体系通过一套「规范 技能 钩子」机制对AI的理解、执行和校验进行系统化约束与增强显著提升开发协作中的准确率与稳定性让AI从“需要反复纠正的实习生”逐步成长为“可信赖的开发搭档”文中附完整实战案例。【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开发只需确认designAI友好tasks.md直接告诉AI“现在做第几个任务”减少歧义。【4.3 工作流程】展示了OpenSpec的工作流程。【五、AI Workflows执行层】【5.1 组件总览】展示了AI Workflows的组件总览。【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.mdSkills → 封装领域经验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.md15个拆解任务。没有一行一行地指导——技能让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多厉害而是它“没犯本该犯的错”。表格中列出的每一项——零重复词条、弹窗直接复用、API精准响应——本质上都是AI在“不知道”的情况下本可以犯的错但因为技能里有规则它没犯。还有几次Hook在关键时刻拦住了AI的“自作主张”。这些都不算轰动性的成绩但它们说明了一个共同的东西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.xVite 6 Pinia 3 vue - i18n 11Vant 4 TailwindCSS 3pnpm 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回答“现在应该做什么”。两者可以互补。
【写在前面为什么要做这件事】在存量项目的增量开发中AI常常面临理解偏差、执行不稳、需要频繁纠正等问题。本文介绍自建的「OpenSpec规范层 AI Workflows执行层」体系通过一套「规范 技能 钩子」机制对AI的理解、执行和校验进行系统化约束与增强显著提升开发协作中的准确率与稳定性让AI从“需要反复纠正的实习生”逐步成长为“可信赖的开发搭档”文中附完整实战案例。【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开发只需确认designAI友好tasks.md直接告诉AI“现在做第几个任务”减少歧义。【4.3 工作流程】展示了OpenSpec的工作流程。【五、AI Workflows执行层】【5.1 组件总览】展示了AI Workflows的组件总览。【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.mdSkills → 封装领域经验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.md15个拆解任务。没有一行一行地指导——技能让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多厉害而是它“没犯本该犯的错”。表格中列出的每一项——零重复词条、弹窗直接复用、API精准响应——本质上都是AI在“不知道”的情况下本可以犯的错但因为技能里有规则它没犯。还有几次Hook在关键时刻拦住了AI的“自作主张”。这些都不算轰动性的成绩但它们说明了一个共同的东西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.xVite 6 Pinia 3 vue - i18n 11Vant 4 TailwindCSS 3pnpm 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回答“现在应该做什么”。两者可以互补。
)
