看到了 Trae 中文社区分享 Skill 的活动，刚好我自己正在使用一套自研的工作流 Skill，这是首发，分享给大家。
我使用过市面上大多数 AI 工作流，但体验往往达不到想要的效果。最初的思路来自 Kiro Spec 模式，但用下来发现它不够完美，于是我自己重新设计了一套，经过多个项目的实战测试和反复优化，发现特别好用，尤其适合我这种几乎没有编程基础的人。
本篇帖子不会逐个讲解 Skill 的内部实现，而是带你了解这套工作流的方法论和完整流程——为什么要这样做、每一步在解决什么问题、以及我在实际使用中积累的技巧。文章会比较长，但看完之后，你对 AI 编程的认知会完全不一样。
工作流和技巧会随着开发实践不断迭代，我也会持续分享给大家。如果你觉得有优化的地方，欢迎在 GitHub 上提交 PR——仅靠我一个人的视角远远不够，我需要大家的反馈和建议，才能把它打磨得更好。
个人介绍
我是一个几乎没有编程基础的人，只有初中学历。之前学过 Python 基础，但没深入下去——因为那时候正是 AI 编程爆火的时代，我辛辛苦苦写的程序，AI 只需要几分钟就能搞定。当时还没有什么 AI 编程工具，只能在网页上用，手动复制粘贴，后来才出来了 Cursor、Trae、Claude Code 这些。
我用 AI 写过多个程序和应用，今年还赚到了人生中第一个 1 万块，不算多，但我才 16 岁，真的很开心。目标是攒钱买 iPhone 18 Pro，因为我现在的手机真的太卡了 
要用就用好的，这是我的原则。
为什么要在自我介绍里说这些？我想证明一件事：每个人现在都有机会，你只需要去做。 但为什么很多人用 AI 开发到最后都做不出来？这就是本篇帖子要解决的问题。
开发顺序：大多数人是怎么失败的
假设你有一个想法：我想开发一个个人博客。
你会怎么跟 AI 说？大多数人要么直接丢一句"我想做个博客"，要么会补充一些功能点，比如"要有发布文章功能、用户注册功能"。
这其实只是开发的前两个阶段：做什么和有哪些功能。但后面还有更多阶段——注册用什么方式？邮箱还是手机号？手机号要对接什么接口？数据库怎么设计？
对于没有技术背景的人来说，越往后越不知道该怎么回答。而 AI 呢？它完全不了解你，你说"开发博客"，它知道要做博客，但不知道博客里具体要什么功能，它只能靠猜。猜出来的东西跟你的想法不一样，开发到后面越偏越远，最后整个项目就乱了。
根本原因就是：没有一个系统的规划流程。
工作流全景：先看地图再上路
在逐个介绍 Skill 之前，先给你一张全景图，让你知道整套工作流长什么样。
这套工作流一共 13 个 Skill，分成三层：
第一层：项目级（启动时用一次）
从一个模糊的想法到一个可以开始写代码的项目骨架，走完这 7 步：
需求澄清 → 产品概述 → 技术栈选型 → 目录结构 → 开发规范 → 路线图规划 → 项目初始化
每一步的输出都是下一步的输入，像流水线一样环环相扣。走完之后，specs/ 目录下会有一整套项目文档，项目目录也搭好了。
第二层：功能级（反复使用）
项目骨架搭好之后，就按照路线图一个功能一个功能地做。每个功能走这 4 步：
功能需求澄清 → 技术方案设计 → 任务规划 → 编码实现
路线图里有 10 个功能？那就跑 10 遍。如果已完成的功能需要改动，还有一个专门的迭代 Skill：
功能迭代变更 → 编码实现
第三层：通用（随时使用）
遇到 BUG 了？直接调 BUG 修复 Skill，不管你在哪个阶段都能用。
一句话总结：项目级走一遍打地基，功能级循环跑盖楼，通用级随叫随到修补丁。
让这套流程真正跑起来的两个核心机制
光有 13 个 Skill 还不够。如果 AI 不守规矩——该做需求分析的时候偷偷写代码，换个新窗口就把你的项目忘得一干二净——那再好的流程也白搭。
所以这套工作流有两个"看不见但一直在起作用"的核心机制，每个 Skill 执行时都会自动加载它们：
机制一：边界守卫（GUARDRAILS）
AI 有个本能：你问它什么，它都想帮你做。听起来是好事，但在工作流里这反而是最大的隐患。
比如你在用需求澄清 Skill 的时候随口说了句"这个功能大概怎么实现？“，AI 的本能反应是直接给你写代码。但这时候需求还没想清楚呢，代码写了也是白写，甚至会把你带偏——你会觉得"既然代码都写了，需求就这样吧”，结果后面全是坑。
边界守卫就是来管这个事的。它给每个 Skill 划了一条硬线：你在这个阶段只能做这个阶段的事。 需求阶段只能聊需求，设计阶段只能出方案，编码阶段才能写代码。AI 想越界？直接拦住，然后告诉你"现在不是做这个的时候，我们先把当前阶段想清楚"。
这不是 AI 不帮你，恰恰相反——在错误的阶段做错误的事才是帮倒忙。 边界守卫强制 AI 在正确的时间做正确的事。
机制二：项目上下文协议（PROJECT-CONTEXT）
AI 最大的问题是什么？没有记忆。 你在一个窗口里跟它聊了两小时，切到新窗口，它对你的项目一无所知。
没有这个协议会怎样？AI 在一个用 Next.js + TypeScript 的项目里给你写 Vue + JavaScript 代码；项目里明明有现成的工具函数，它又重新写了一个；开发规范里说用 Tailwind，它给你写了一堆内联样式。
项目上下文协议的规则很简单：每个 Skill 执行前，AI 必须先读取 specs/ 目录下的所有文档，建立对项目的完整认知。 不读完不许开始干活。
这就是为什么前面说"开新窗口不怕丢上下文"——因为不管开多少个新窗口，AI 每次都会被强制重新读取项目文档。你的技术栈、开发规范、已有的功能设计，它全都知道。文档在，记忆就在。
下面开始逐个介绍每个 Skill。
Skill 1：project-requirements-clarification（需求澄清）
这个 Skill 就是来解决"没有系统规划流程"这个问题的。
当你有一个模糊的想法时，它会通过苏格拉底式的引导提问，从多个维度帮你把想法挖透——核心价值是什么、目标用户是谁、关键特征有哪些，最终生成一份标准化的项目描述。
为什么是"引导式"而不是让你自己填表？因为对于不知道细节的人来说，你让他自己说，他说不出来。他需要有人引导，一步一步往下问，答案自然就出来了。
这个 Skill 最厉害的地方在于：它像一个好奇的合伙人在跟你聊天，而不是一个冷冰冰的填表机器。就像你跟合伙人说"我想做个博客"，合伙人肯定会追问你很多问题——AI 在这里扮演的就是这个角色。
而且你可以反复调用这个 Skill。比如第一次生成结果后，你觉得还不够完善，直接告诉 AI"我还想加更多功能"，它会用同样的引导方式继续帮你深挖。
我在开发新项目时百分之百会用这个 Skill，对新手来说强烈建议从这里开始。
示例
你发送的信息：
/project-requirements-clarification 我想开发一个个人博客
AI 回复的信息：
这个想法很有趣！我来帮你把它想清楚。先聊几个关键问题：
为什么想做博客？
- A：记录自己的技术学习过程，给自己看
- B：写文章吸引读者，打造个人品牌
- C：纯粹练手，学习全栈开发
- 或者其他原因？
先告诉我这个，后面我再问你目标用户和核心功能。一步一步来，不着急。
Skill 2：project-product-overview（产品概述）
需求澄清完成后，你手上有了一份项目描述。但这份描述更像是"聊天记录的总结"——信息有了，但还不够结构化，拿去做技术选型或架构设计还差点意思。
没有这个 Skill 会怎样？你可能直接拿着模糊的需求就开始让 AI 写代码了。写到一半发现：这个功能到底归哪个模块？验收标准是什么？目标用户到底是谁？然后你开始回头补，补着补着发现前面的代码跟新的规划对不上，又得改。
这个 Skill 做的事情，就是把需求澄清的结果升级为一份正式的产品文档。它会帮你明确：项目愿景是什么、核心价值在哪、目标用户是谁、系统分成哪几个核心板块、验收标准怎么定。
AI 在这里扮演的是首席产品官的角色。信息不够的地方，它会用引导式提问帮你补上——问法很具体，给你举例子让你选，不会问那种让人懵的开放式大问题。
最终输出一份 specs/产品概述.md，这份文档就是后面所有 Skill 的"地基"。
示例
你发送的信息：
/project-product-overview 请基于需求澄清的结果生成产品概述
AI 回复的信息：
我已经读取了你的项目描述，大部分信息很清晰，但有几个关键点需要补充：
1. 核心价值还不够明确
你的博客和市面上其他博客的最大区别是什么？
- A：主打 Markdown 写作体验，像 Typora 一样流畅
- B：主打 SEO 和流量获取，帮你把文章推出去
- C：主打极简部署，一键上线零运维
- 或者你有其他想法？
2. 验收标准需要量化
第一版上线的标准是什么？我建议至少定两条：
- 功能层面：比如"能发布文章、能按标签分类、有基础的阅读统计"
- 性能层面：比如"首页加载 < 2 秒"
请告诉我你的选择，我来生成完整的产品概述文档。
Skill 3：project-tech-stack（技术栈选型）
产品概述定了，下一个问题就是：用什么技术来做？
这一步很多人要么自己去搜"最火的前端框架"，要么直接跟 AI 说"你帮我选"。两种做法都有问题——追热门容易踩坑（新框架生态不全、文档不够、AI 训练数据少），全交给 AI 的话，它也不知道你的具体约束，容易推荐一个"技术上完美但你根本用不起来"的方案。
这个 Skill 的 AI 角色是 CTO，它做选型的逻辑是**“最合适"而不是"最热门”**。它会先读你的产品概述，分析项目规模、用户量级、实时性要求这些关键约束，然后主动给你推荐完整的技术组合——不是让你一个一个选，而是直接给你打包好的方案。
对于不懂技术的人来说，这里最贴心的设计是：当需要你做选择时，一定会给选项、给解释、给推荐。不会冷冰冰地问你"用什么数据库"，而是告诉你每个选项适合什么场景，然后说"我建议选这个，因为…"。
最终输出 specs/技术栈.md。
示例
你发送的信息：
/project-tech-stack 请进行技术选型
AI 回复的信息：
我已经读取了你的《产品概述》，这是一个个人博客项目，核心需求是 Markdown 写作 + SEO 友好 + 低运维成本。基于分析，我推荐以下方案：
推荐方案：Next.js + Supabase + Vercel
- 前端/后端：Next.js 14（App Router）—— SSR 天然对 SEO 友好，前后端一把梭，不需要单独维护后端
- 数据库：Supabase（PostgreSQL）—— 免费额度足够个人博客用，自带用户认证
- 部署：Vercel —— Next.js 的亲儿子，推上去就能跑，零运维
- 样式：Tailwind CSS —— 开发快，AI 写起来也最顺手
有一个细节需要确认：你需要评论功能吗？
- A：不需要，保持极简
- B：需要，用第三方服务（如 Giscus，基于 GitHub Discussions，零成本）
- C：需要，自建评论系统（工作量会增加不少）
- 我的建议：如果要做的话选 B，成本为零且不影响核心开发节奏。
Skill 4：project-structure（目录结构）
技术栈选好了，但你总不能直接开始写代码吧？代码放哪？文件怎么组织？模块之间怎么划分？
没有规划目录结构会怎样？一开始可能没感觉，文件少的时候随便放都行。但项目一大，你就会发现：组件和页面混在一起、工具函数散落在各个角落、一个功能的代码分散在五六个不相关的文件夹里。到后面不管是你还是 AI，想改一个功能都得满项目找文件。
这个 Skill 的 AI 角色是系统架构师。它会同时读取产品概述和技术栈文档，把"核心板块"映射成代码模块，再根据技术栈的最佳实践来设计目录。核心原则就一个：高内聚低耦合——相关的代码放在一起，不相关的严格隔离。
最终输出 specs/项目结构.md。
示例
你发送的信息：
/project-structure 请设计项目目录结构
AI 回复的信息：
基于技术栈（Next.js 14 + Supabase）和产品概述中的三个核心板块（内容管理、用户系统、阅读体验），我设计了以下目录结构：
blog-project/ ├── src/ │ ├── app/ # Next.js App Router 页面 │ │ ├── (auth)/ # 登录/注册相关页面 │ │ ├── (blog)/ # 博客前台页面 │ │ └── admin/ # 后台管理页面 │ ├── modules/ # 业务模块（核心） │ │ ├── auth/ # 用户认证 │ │ ├── posts/ # 文章管理 │ │ └── analytics/ # 阅读统计 │ ├── shared/ # 公共组件和工具 │ └── lib/ # 第三方服务封装 ├── specs/ # 项目规格文档 ├── docs/ # 开发文档 └── public/ # 静态资源设计思路：采用特性架构（Feature-based），每个
modules/下的模块是独立的业务单元。后续开发时，AI 只需要聚焦到对应的模块目录即可。你觉得这个结构 OK 吗？有需要调整的地方告诉我。
Skill 5：project-dev-standards（开发规范）
目录结构有了，但代码怎么写？变量怎么命名？Git 怎么提交？
这些如果不提前定好，后果就是——你让 AI 写了十个文件，每个文件的风格都不一样。有的用驼峰命名，有的用下划线；有的组件用箭头函数，有的用 function 声明；Git 提交信息更是五花八门。改起来的痛苦远比提前规定好要大得多。
这个 Skill 的 AI 角色是技术委员会，它会基于你的技术栈生成一份完整的开发规范，覆盖代码风格、命名约定、Git 工作流、错误处理，甚至包括 AI 协作协议——告诉 AI"你在这个项目里写代码必须遵守哪些规矩"。
这里有一个重要的设计：每条规则都具体到可以直接执行。不会出现"遵循最佳实践"这种废话，而是明确告诉你"组件文件用 PascalCase，工具函数用 camelCase"，并且附带正确写法和错误写法的对比。
最终输出 specs/开发规范.md。
示例
你发送的信息：
/project-dev-standards 请制定开发规范
AI 回复的信息：
已读取技术栈和项目结构文档，以下是定制的开发规范（节选）：
命名约定
元素 风格 示例 组件文件 PascalCase PostCard.tsx工具函数文件 camelCase formatDate.ts目录名 kebab-case user-profile/TypeScript 严格规则
// 错误 - 禁止使用 any const data: any = await fetchPost() // 正确 - 明确类型定义 const data: PostDetail = await fetchPost()Git 提交规范
feat(posts): 添加文章标签筛选功能 fix(auth): 修复登录状态丢失问题完整规范共 15 个章节，已全部生成。请确认后我保存到
specs/开发规范.md。
Skill 6：project-roadmap-planning（路线图规划）
到这一步，你已经有了产品概述、技术栈、目录结构、开发规范——"怎么做"已经很清楚了。但还有一个问题：先做什么？
这个问题比你想象的重要。很多人的做法是"想到啥做啥"，或者"从第一个页面开始做"。结果呢？做到用户管理的时候发现登录系统还没搭，做到文章详情页的时候发现数据模型还没定义。到处被依赖卡住。
这个 Skill 的 AI 角色是技术产品经理，它会做三件事：
- 分析模块依赖——哪些是地基（比如用户认证、公共组件），哪些是核心业务，哪些是锦上添花
- 划分里程碑——MVP 做什么、完整版做什么、增强版做什么
- 生成开发顺序——每个模块带具体的开发指令，做完一个勾一个
拿到路线图以后，你就不用纠结"接下来做什么"了，按顺序推进就行。
最终输出 specs/开发路线图.md。
示例
你发送的信息：
/project-roadmap-planning 请规划开发路线图
AI 回复的信息：
基于产品概述和项目结构，我分析了模块间的依赖关系，规划如下：
里程碑一：MVP（核心闭环）
- Phase 1.1：基础设施 ——
auth+shared（地基，所有业务模块都依赖它）- Phase 1.2：核心业务 ——
posts（文章的创建、编辑、发布、Markdown 渲染）- Phase 1.3：前台展示 —— 文章列表页、详情页、标签筛选（做完这步 MVP 就能用了）
里程碑二：完整版
- Phase 2.1：阅读统计（
analytics）- Phase 2.2：后台管理（
admin）里程碑三：增强版
- Phase 3.1：SEO 优化（sitemap、Open Graph）
- Phase 3.2：性能优化（图片懒加载、ISR）
建议从 Phase 1.1 开始，每完成一个 Phase 回来勾选进度。
Skill 7：project-initialization（项目初始化）
前面六个 Skill 全部是"规划"——生成的都是文档。到了第七个，终于要动手了。
这是整套工作流里唯一一个"执行类"Skill。它的职责很简单：严格按照前面生成的文档，创建项目骨架。 注意是"严格按照"——它不会做任何文档里没定义的事情，不会自作主张加个框架或者改个配置。
它会读取你的技术栈、项目结构、开发规范文档，然后：创建所有目录、生成配置文件（.gitignore、.env.example、README.md 等）、初始化 Git 仓库。做完后输出一份初始化记录。
如果项目目录里已经有代码了（比如你是在现有项目上用这套工作流），它会自动检测到并跳过，不会覆盖任何东西。
最终输出：项目骨架代码 + docs/开发记录/初始化记录.md。
示例
你发送的信息：
/project-initialization 初始化项目
AI 回复的信息：
开始执行项目初始化。
环境检查
- specs/技术栈.md … 已就绪
- specs/项目结构.md … 已就绪
- specs/开发规范.md … 已就绪
- 当前目录 … 空目录，可以初始化
- Node.js v20.11.0 … 已安装
执行中…
npm init -y… 完成- 安装核心依赖 … 完成（next, react, typescript, tailwindcss…）
- 创建目录结构（共 14 个目录）… 完成
- 生成配置文件 … 完成（.gitignore, .env.example, tsconfig.json…）
git init+ 首次提交 … 完成初始化完成。 详细日志已保存到
docs/开发记录/初始化记录.md。下一步：请按照
specs/开发路线图.md中的 Phase 1.1 开始开发。
功能级工作流：开发具体功能
项目初始化完成后，你手里有了一整套文档和项目骨架。接下来就进入真正的开发阶段了：一个功能一个功能地做。
功能级工作流的流程跟项目级很像——先澄清需求、再设计方案、再拆任务、最后写代码。但区别在于，它是针对单个功能的闭环，而且你会反复使用它。路线图里列了 10 个功能？那你就跑 10 遍这个流程。
听起来很机械？但这恰恰是它好用的原因——每个功能都经过完整的思考链条，不会出现"做到一半发现需求没想清楚"的情况。
Skill 8：feature-requirements-clarification（功能需求澄清）
你可能会想：前面不是已经做过需求澄清了吗？为什么还要再来一遍？
因为项目级的需求澄清是"全局视角"——你想做什么产品、有哪些大板块。但具体到某个功能，细节差得远。
比如你说"我想做个评论功能"，听起来很简单对吧？但你想过这些问题吗：谁能评论？评论能不能回复？要不要审核？评论被删了怎么处理？怎么算"做完了"？
这些你不想清楚，AI 就只能猜，猜出来的东西跟你脑子里想的完全不一样。
这个 Skill 扮演的是产品经理，全程不会出现任何技术术语——不聊数据库、不聊 API，只聊"用户要什么"、“流程是什么”、“边界在哪里”。最后输出一份功能需求文档到 specs/features/ 目录下。
示例
你发送的信息：
/feature-requirements-clarification 我想做一个评论功能
AI 回复的信息：
好的，我来帮你把评论功能的需求理清楚。先从场景开始聊：
评论主要出现在什么地方？
- A：文章详情页（读者对文章发表看法）
- B：商品页面（买家评价商品）
- C：其他场景
- 推荐：A，因为根据产品概述，你做的是内容平台
你先告诉我这个，我们再往下聊。
Skill 9：feature-tech-design（技术方案设计）
需求文档写好了，接下来该想"怎么实现"了。
没有这个 Skill 的时候，很多人直接让 AI 开始写代码。结果 AI 随便选了个实现方式，写到一半发现不合适又推倒重来。或者更糟——功能写完了，发现跟已有的代码架构冲突，改起来比重写还痛苦。
这个 Skill 扮演的是系统架构师，基于需求文档把 API 怎么设计、数据库表怎么建、核心逻辑怎么跑、异常怎么处理，全部想清楚写下来。而且它会逐条检查验收标准，确保每一条都有对应的技术实现。
如果某个点有多种方案，它会把选项列出来，告诉你优劣，然后给推荐——你不需要懂原理，看推荐理由然后说"行"就行。
示例
你发送的信息：
/feature-tech-design 评论功能
AI 回复的信息：
已读取需求文档
specs/features/评论功能.md，开始设计技术方案。关于评论的嵌套回复，有两种实现方式：
- 选项 A：邻接表模型（每条评论记录 parent_id）
- 优点：实现简单，查询直观
- 缺点：多层嵌套时递归查询性能差
- 选项 B：路径枚举模型（每条评论记录完整路径 path）
- 优点：查询性能好，排序方便
- 缺点：路径字段维护稍复杂
- 推荐：A，因为需求限制了最多 2 层嵌套，邻接表完全够用
确认后我继续设计数据库表结构和 API 接口。
Skill 10：feature-task-planning（任务规划）
技术方案有了，但你总不能直接丢给 AI 说"按技术方案写代码吧"。一个功能可能涉及十几个文件、五六个模块，让 AI 一口气全写了，它大概率会搞混、漏掉东西，因为上下文太长导致质量下降。
这个 Skill 扮演的是技术主管，把技术方案拆成一个个小任务——每个控制在 2 小时以内，单一职责，有明确的完成标准。而且会理清依赖关系：先建表，再写接口，再做页面。有风险的任务特别标出来，阻塞后续的关键任务优先安排。
拆完之后，你拿到的是一份像施工进度表一样的任务清单，按顺序交给下一个 Skill 执行就行。
示例
你发送的信息：
/feature-task-planning 评论功能
AI 回复的信息：
已读取技术方案和需求文档，拆解出 8 个开发任务，分 3 个阶段，预计总工时 320 分钟。
第 1 阶段：数据层（3 个任务）
- Task-01：创建 comments 表及索引 [30min]
- Task-02：实现评论数据访问层 CRUD [45min]
- Task-03：数据层单元测试 [30min]
第 2 阶段：接口层（3 个任务）
- Task-04：实现发布评论 API [45min] ← 依赖 Task-02
- Task-05：实现获取评论列表 API（含嵌套）[50min] ← 依赖 Task-02
- Task-06：接口层集成测试 [30min]
第 3 阶段：表现层（2 个任务）
- Task-07：评论列表组件 [50min] ← 依赖 Task-05
- Task-08：发布评论组件 [40min] ← 依赖 Task-04
需要调整优先级或合并/拆分某些任务吗？确认后我生成任务规划文档。
Skill 11：feature-implementation（编码实现）
终于到写代码的环节了。
前面铺垫了这么多——需求、技术方案、任务规划——到这一步其实是最轻松的。因为 AI 要做什么已经写得清清楚楚了，它不需要猜、不需要自由发挥，照着文档一个任务一个任务执行就行。
这个 Skill 扮演的是高级开发工程师。你只需要说"完成评论功能的任务 第 1 阶段"，它会自动读取任务规划，找到第 1 阶段的所有任务，按顺序执行。每完成一个任务，它会立刻写测试、跑测试，通过了才进入下一个。全部完成后，自动在任务规划文档里打勾，并生成阶段完成报告。
为什么一个阶段一个阶段来，不一口气全做完？第一，AI 的上下文窗口有限，塞太多东西质量会下降。第二，每个阶段做完你可以检查一下，发现问题及时纠正，不用等全做完了才发现第一步就错了。
示例
你发送的信息：
/feature-implementation 完成评论功能的任务 第1阶段
AI 回复的信息：
正在读取相关文档…
- 需求文档：specs/features/评论功能.md
- 技术方案：specs/features/评论功能_技术方案.md
- 任务规划：specs/features/评论功能_任务规划.md
第 1 阶段：数据层，包含 3 个任务。前置检查通过，无依赖阻塞。
即将开始执行 Task-01：创建 comments 表及索引
涉及文件：migrations/003_create_comments.sql
参考：技术方案 3.1 节 - 数据库设计是否继续？
（你回复"继续"后，AI 会执行代码、写测试、跑测试，一路推进到阶段结束，最后输出完成报告并更新任务状态。）
Skill 12：feature-evolution（功能迭代变更）
功能做完了，上线了，用了一段时间——然后你又有新想法了。“评论能不能加个点赞？”“能不能支持图片评论？”
这时候如果你直接对 AI 说"给评论加个点赞"，它大概率会把已有代码搅得一团乱——因为它不知道之前的需求文档、技术方案里写了什么，只看到了现在的代码，然后"野蛮施工"。
这个 Skill 扮演的是产品架构师，专门处理对已完成功能的增量修改。它会先读取之前的所有文档，搞清楚现状，然后分析变更属于哪种类型：
- 微调（Tweak）：小改动，比如调整排序方式，不涉及新需求
- 扩展（Extension）：加新东西，比如加点赞功能，需要新增验收标准
- 重构（Refactor）：动了核心结构，比如改了评论的存储模型
然后增量更新文档（不是推倒重写），只生成变更相关的新任务。它有一条硬规则：只做分析和规划，绝对不写代码——代码的事交给 feature-implementation。
示例
你发送的信息：
/feature-evolution 我想给评论功能加一个点赞功能
AI 回复的信息：
已读取评论功能的全套文档，分析变更影响。
变更分类：扩展（Extension）
原因：需要新增"点赞"相关的验收标准、新增 API 接口和数据库字段，但不破坏现有评论结构。影响分析：
- 需求文档：新增 2 条验收标准（AC-06、AC-07）
- 技术方案：新增 1 个 API，comments 表新增 like_count 字段
- 已有代码：需修改 2 个文件，新增 3 个文件
- 回归风险：低，不影响已有的评论发布和展示逻辑
需要新增 3 个开发任务（Task-09 到 Task-11），预计工时 90 分钟。
是否确认生成变更文档？
Skill 13：bugfix-workflow（BUG 修复）
遇到 BUG 了怎么办？大多数人的做法是把报错信息丢给 AI，说"帮我修了"。AI 看了看报错，猜了个原因，改了几行代码，告诉你"应该好了"。
好了吗？有时候好了，有时候没好，有时候旧 BUG 没了但新 BUG 来了。问题在哪？没有复现就开始改。 AI 根本不知道这个 BUG 在什么条件下触发，它只是根据报错信息猜了个可能的原因。
这个 Skill 强制执行一套严格的修复流程：复现 → 定位 → 修复 → 单元测试 → 验证 → 报告。
最关键的硬规则：没复现出来，不准改代码。 信息不够复现？它会追问——在哪个页面？做了什么操作？期望结果是什么？实际结果是什么？一直问到能复现为止。
修完之后也不是说句"好了"就完事，它必须给你一份逐步的手动验证步骤——具体到"打开哪个页面、点哪个按钮、输入什么内容、看到什么结果"。还会自动写一个针对这个 BUG 的单元测试，防止同样的问题再冒出来。最后生成修复报告存到 docs/BUG修复文档/，方便追溯。
示例
你发送的信息：
/bugfix-workflow 评论发布之后页面没有刷新，还是显示旧的评论列表
AI 回复的信息：
收到，我需要先确认几个信息来复现这个问题：
- 发生在哪个页面？（文章详情页？个人中心？）
- 你做了哪些操作？（尽量细化到每一步）
- 发布评论后，页面完全没变化，还是过一会儿才刷新？
- 打开浏览器控制台，有没有报错信息？
请先回答这几个问题，我复现之后才开始定位和修复。
实战技巧：我踩过的坑和总结的经验
介绍完所有 Skill 之后，分享一些我在实际开发中积累的技巧。这些都是文档里不会告诉你、但用起来会反复遇到的问题。
技巧 1：功能级开发，规划和编码分开窗口
功能级工作流有 4 步：需求澄清 → 技术方案 → 任务规划 → 编码实现。
前三步（需求澄清、技术方案、任务规划）关联性很强，建议在同一个窗口里连着做完。因为需求讨论的细节会直接影响技术方案的设计，技术方案又直接决定任务怎么拆——在同一个窗口里 AI 对这些上下文记得最清楚。
但到了编码实现阶段，做法就不一样了：按任务规划里的任务来，一个任务开一个新窗口。 不要在一个窗口里连续做好几个任务，上下文堆积太多，AI 的回复质量会明显下降。
当然，具体还要看任务的复杂度——如果是几个特别简单的小任务，合在一个窗口里做也没问题。但遇到复杂任务，一定要给它一个干净的窗口。
你可能会担心：开新窗口不会丢失上下文吗？不会。因为每个 Skill 生成的文档都保存在了 specs/ 目录下，新窗口打开后，Skill 会强制 AI 先读取这些文档，重新建立完整的项目认知。
文档在，上下文就在。 所以不要舍不得开新窗口，该开就开。
技巧 2：项目级规划，尽量在一个窗口内完成
跟功能级相反，项目级的 7 个 Skill（需求澄清到路线图规划）我建议在一个窗口里连着做完——前提是你用的模型上下文窗口足够大。
为什么？因为项目级的 Skill 之间关联性很强，前一步的讨论细节会直接影响下一步的判断。比如需求澄清时你提到"要支持离线使用"，这个信息在技术栈选型时非常关键。如果在同一个窗口里，AI 对这些细节记得很清楚；换了新窗口，虽然文档里会有记录，但聊天中那些微妙的上下文（你的偏好、你纠结过的点）就丢了。
当然，如果你的模型上下文不够大，或者中途聊了太多导致 AI 明显变迟钝了，那还是果断开新窗口，不要硬撑。
技巧 3：提示词先润色，然后存下来复用
你发给 AI 的每一句话，本质上就是一条提示词。同样的意图，表达方式不同，AI 给你的结果质量天差地别。
我的做法是：在发送给 AI 之前，先把你想说的话丢到网页版 AI（比如 ChatGPT、Claude）里润色一遍。 让它帮你把模糊的描述变成清晰、结构化的表述。你会发现润色后的提示词，AI 理解得更准，产出质量明显提升。
更重要的是：创建一个文档，专门存放你用过的提示词。 为什么？因为你开发到后面会发现，很多任务其实是类似的——同样是做一个列表页，同样是写一个接口。但你这次写的提示词可能没有上次写的好，如果有记录，直接把上次效果更好的提示词拿来改改就能用。
这个习惯一旦养成，你的提示词库会越来越强，效率也会越来越高。
技巧 4：feature-evolution 和重新走一遍怎么选？
功能做完之后要改需求，到底是用 feature-evolution 做增量变更，还是从 feature-requirements-clarification 重新走一遍？
判断标准很简单：改动范围。
- 改动不超过原功能的 30% → 用 feature-evolution（增量更新文档 + 追加新任务）
- 改动超过 70% → 基本等于重做了，用 feature-requirements-clarification 重新走流程
- 30%-70% 之间 → 看复杂度，拿不准就先用 feature-evolution，它会自动判断变更类型并给你建议
技巧 5：一个阶段做完发现不对，怎么回退？
比如你完成了编码实现的第 1 阶段，结果发现技术方案里有个设计不合理。
不要慌，也不要直接改代码。正确的做法是：
- 回到技术方案 — 用 feature-evolution 提出变更，让它分析影响范围
- 更新文档 — 它会增量更新技术方案和任务规划
- 再执行变更任务 — 用 feature-implementation 执行新生成的增量任务
这样做的好处是所有改动都有据可查，文档和代码始终保持一致。直接改代码虽然快，但后面 AI 读到的文档和实际代码对不上，会越来越乱。
技巧 6：不懂就问，让 AI 等你的时候别闲着
说一段我的真实经历。我刚开始用 AI 开发的时候，什么都不懂——不知道后端是什么，不知道数据库是干嘛的，不知道 Next.js 和 Vue 有什么区别，甚至不知道 API 是什么意思。完全是一个小白。
但你想想，你现在已经在用 AI 了，AI 帮你干活的时候你在干嘛？刷手机？等着？
不如趁这个时间，把你不懂的东西问清楚。 比如 AI 在帮你写代码，你发现技术方案里提到了"中间件"，你不知道那是啥——直接开个新窗口问 AI："中间件是什么？用大白话给我解释一下。"然后让它把这些知识整理成一份文档存下来，以后遇到同样的概念直接翻文档就行，不用再问一遍。
你懂得越多，跟 AI 沟通就越高效，给出的需求就越精准，最后做出来的东西就越好。这是一个正向循环——AI 帮你干活的同时，你也在成长。 别浪费这个免费的老师。
技巧 7：文档不同步了，手动让 AI 去同步
这个问题你一定会遇到，我自己也经常遇到。
什么情况呢？AI 在按任务规划写代码的过程中，你临时加了个需求——比如"这个按钮改成红色的"、“列表加一个搜索框”。AI 照做了，代码改了，但是 specs/ 下面的需求文档、技术方案还是旧的。文档和实际代码不同步了。
这个问题如果不管，后面再开新窗口的时候，AI 读到的文档是旧的，它以为项目还是之前的样子，就会跟实际代码产生冲突。
我的解决办法很简单粗暴：直接手动告诉 AI，让它去同步文档。 比如跟它说"我刚才额外加了 XX 功能，请把需求文档和技术方案同步更新一下"。AI 会去对比当前代码和文档的差异，然后把文档补齐。
你可能会问：为什么不做一个专门的同步 Skill？因为这种情况太灵活了——你加的可能是一个小改动，也可能是一个大调整，涉及哪些文档、改多少内容，每次都不一样。我试过之后发现，直接用自然语言告诉 AI 反而是最高效的方式，比固定流程更灵活。
核心原则就一条：改了代码，就要同步文档。发现不同步，立刻补。拖得越久越难补。
技巧 8：AI 生成的文档，花两分钟过一遍
AI 生成的文档不要直接跳过，哪怕你看不懂技术细节也没关系，只需要花两分钟扫一遍。
你不需要看懂每一行，但你能看懂的部分往往是最重要的——功能描述对不对？流程是不是你想要的？有没有漏掉你说过的某个需求？这些都是用大白话写的，新手也能判断。
为什么这一步很重要？因为文档是后面所有 Skill 的输入。需求文档写错了，技术方案就跟着错；技术方案错了，任务规划就跟着错；最后写出来的代码自然也是错的。越早发现问题，改起来越便宜。 在文档阶段改一句话，比写完代码再推倒重来轻松一百倍。
所以每次 AI 生成文档后，别急着进入下一步，先扫一眼。
技巧 9：跟 AI 沟通的黄金法则
用这套工作流的时候，跟 AI 说话有几个技巧能大幅提升效果：
- 自己主动调用 Skill：比如手动输入
/feature-requirements-clarification 评论功能，不要丢一句"我想做个评论功能"然后等 AI 自己去找对应的 Skill。AI 不一定能准确识别你的意图，自己调用最稳 - 一次只做一件事：不要在一条消息里说"帮我做评论功能，顺便把登录页面也改一下"。每个功能走自己的流程，互不干扰
技巧 10：AI 搞不定的任务，按这个顺序试
用 AI 开发一定会遇到它搞不定的任务，我自己就遇到过好多次。别死磕，按下面这个顺序一步步试：
第一步：换个模型。 不同模型擅长的东西不一样，Claude 搞不定的，GPT 可能一下就搞定了，反过来也一样。换个模型试试成本最低。
第二步：优化提示词。 有时候不是 AI 不行，是你没说清楚。把你的需求重新组织一下，描述得更具体、更结构化，可能就通了。
第三步：把任务拆小。 一个大任务 AI 做不出来，可能是太复杂了。试着把它拆成两三个小任务分别完成，然后自己组合起来。
第四步：去 GitHub 找参考。 让 AI 去 GitHub 上搜一下类似的功能，看看别人的开源项目是怎么实现的。有了参考代码，AI 照着改比从零开始容易多了。
第五步：搞清楚到底卡在哪。 前面几步都试过了还是不行，那就停下来想想：AI 给出的结果跟你的预期差在哪？是逻辑错了？还是方向就不对？问 AI 分析一下失败的原因，搞清楚了再决定——换个思路绕过去，还是干脆先放一放，等更强的模型出来了再回来做。
不要在一个死胡同里耗太久。 AI 技术在飞速进步，今天搞不定的任务，可能过几个月新模型出来就是一句话的事。先把能做的做了，搞不定的记下来，回头再来。
关于效率和未来计划
有一件事我想坦诚地说：目前这套工作流的开发效率确实不算快。
因为任务是一个一个串行完成的——做完 Task-01 再做 Task-02，做完 Task-02 再做 Task-03。我自己用的时候也明显感觉到了，尤其是任务多的时候，等待时间很长。
我不是没想过解决这个问题。之前尝试过让 AI 创建多个 Agent 同时开发多个任务——比如 Task-01 和 Task-02 如果没有依赖关系，完全可以并行跑。但试过之后发现了一个致命问题：没有审核机制，我根本不敢放手。
为什么？因为多个 Agent 同时写代码，A 那边偏了一点，B 那边也偏了一点，等你发现的时候已经两边都出了问题。你去修 A，发现 B 也要改；改完 B，A 又冒出新问题。没有一个自动审核的环节帮你把关，并行开发反而比串行更折腾。
所以审核 Skill 是必须做的，而且要做得足够可靠——它需要能自动检查代码质量、验证是否符合技术方案、发现问题后让 Agent 自己修正，形成一个闭环，但它非常消耗 token。
这套工作流最初是为我自己设计的。 没有任何资金支持，也没有厂商赞助，AI订阅全靠自己充。所以我选择了最省钱的方式——自己辛苦一点，一个任务一个任务地开发，虽然慢，但每一步都可控。
但从我把它分享出来的那一刻起，这就不再只是我一个人的事了。用这套 Skill 的人，可能有更充裕的预算，也可能对效率有更高的要求。串行开发对我来说可以忍，但不应该成为所有人的限制。
所以后续我会认真做这几件事：
- 审核 Skill：让 AI 能自动审查代码质量，形成"开发 → 审核 → 修正"的闭环
- 并行开发支持：在审核机制可靠之后，支持多任务同时开发
- 配套教程：每个新能力都会附带详细的使用教程
这些不是画饼，是我自己在开发过程中切实感受到的痛点。做出来之后会第一时间分享给大家。
写在最后
回头看这整套工作流，核心理念就三个词：
文档驱动——所有决策都落到文档上，AI 换了窗口也不会"失忆"，你隔一个月回来也能看懂当时为什么这么做。
阶段分离——每个 Skill 只干一件事，产品经理不碰代码，架构师不写实现，开发工程师不改需求。不会出现"问着问着需求突然开始写代码"的混乱场面。
引导式交互——不需要你是专家，你只需要回答问题、做选择。AI 会把选项摆出来，告诉你推荐哪个、为什么，你点头就行。
说白了，这套工作流就是把软件工程那套"需求 → 设计 → 开发 → 测试"的流程，用 Skill 的方式固化下来，让 AI 在每个阶段扮演对应的专业角色。你不需要懂技术，你只需要知道自己想要什么——剩下的，交给流程。
基础技巧 skills trae技巧便利店
果断收藏
