# SpecForge

**Repository Path**: github_speed/SpecForge

## Basic Information

- **Project Name**: SpecForge
- **Description**: forks from  https://github.com/MingYuePop/SpecForge.git
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-03-19
- **Last Updated**: 2026-03-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

我自己正在使用一套自研的工作流 **SpecForge**

我使用过市面上大多数 AI 工作流，但体验往往达不到想要的效果。最初的思路来自 Kiro Spec 模式，但用下来发现它不够完美，于是我自己重新设计了一套，经过多个项目的实战测试和反复优化，发现特别好用，尤其适合我这种几乎没有编程基础的人。

本篇帖子不会逐个讲解 Skill 的内部实现，而是带你了解这套工作流的**方法论和完整流程**——为什么要这样做、每一步在解决什么问题、以及我在实际使用中积累的技巧。文章会比较长，但看完之后，你对 AI 编程的认知会完全不一样。

工作流和技巧会随着开发实践不断迭代，我也会持续分享给大家。如果你觉得有优化的地方，欢迎在 [GitHub](https://github.com/MingYuePop/SpecForge) 上提交 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 严格规则**
>
> ```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 角色是**技术产品经理**，它会做三件事：

1. **分析模块依赖**——哪些是地基（比如用户认证、公共组件），哪些是核心业务，哪些是锦上添花
2. **划分里程碑**——MVP 做什么、完整版做什么、增强版做什么
3. **生成开发顺序**——每个模块带具体的开发指令，做完一个勾一个

拿到路线图以后，你就不用纠结"接下来做什么"了，按顺序推进就行。

最终输出 `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 ........ 已安装
>
> **执行中...**
> 1. `npm init -y` .................. 完成
> 2. 安装核心依赖 ................... 完成（next, react, typescript, tailwindcss...）
> 3. 创建目录结构（共 14 个目录）..... 完成
> 4. 生成配置文件 ................... 完成（.gitignore, .env.example, tsconfig.json...）
> 5. `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 回复的信息：

> 收到，我需要先确认几个信息来复现这个问题：
>
> 1. 发生在哪个页面？（文章详情页？个人中心？）
> 2. 你做了哪些操作？（尽量细化到每一步）
> 3. 发布评论后，页面完全没变化，还是过一会儿才刷新？
> 4. 打开浏览器控制台，有没有报错信息？
>
> 请先回答这几个问题，我复现之后才开始定位和修复。

---

## 实战技巧：我踩过的坑和总结的经验

介绍完所有 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 阶段，结果发现技术方案里有个设计不合理。

不要慌，也不要直接改代码。正确的做法是：

1. **回到技术方案** — 用 feature-evolution 提出变更，让它分析影响范围
2. **更新文档** — 它会增量更新技术方案和任务规划
3. **再执行变更任务** — 用 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 在每个阶段扮演对应的专业角色。你不需要懂技术，你只需要知道自己想要什么——剩下的，交给流程。

SpecForge 的 Skill 文件已开源，GitHub 地址：[https://github.com/MingYuePop/SpecForge](https://github.com/MingYuePop/SpecForge)

仓库里有 V1 和 V2 两个版本，**直接用最新的 V2 版本就行**，V1 是早期实验版，V2 是完整重构后的版本。

感谢大家看到这里，希望这套工作流能帮到你。