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

我自己正在使用一套自研的工作流SpecForge我使用过市面上大多数 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 执行时都会自动加载它们机制一边界守卫GUARDRAILSAI 有个本能你问它什么它都想帮你做。听起来是好事但在工作流里这反而是最大的隐患。比如你在用需求澄清 Skill 的时候随口说了句这个功能大概怎么实现“AI 的本能反应是直接给你写代码。但这时候需求还没想清楚呢代码写了也是白写甚至会把你带偏——你会觉得既然代码都写了需求就这样吧”结果后面全是坑。边界守卫就是来管这个事的。它给每个 Skill 划了一条硬线你在这个阶段只能做这个阶段的事。需求阶段只能聊需求设计阶段只能出方案编码阶段才能写代码。AI 想越界直接拦住然后告诉你现在不是做这个的时候我们先把当前阶段想清楚。这不是 AI 不帮你恰恰相反——在错误的阶段做错误的事才是帮倒忙。边界守卫强制 AI 在正确的时间做正确的事。机制二项目上下文协议PROJECT-CONTEXTAI 最大的问题是什么没有记忆。你在一个窗口里跟它聊了两小时切到新窗口它对你的项目一无所知。没有这个协议会怎样AI 在一个用 Next.js TypeScript 的项目里给你写 Vue JavaScript 代码项目里明明有现成的工具函数它又重新写了一个开发规范里说用 Tailwind它给你写了一堆内联样式。项目上下文协议的规则很简单每个 Skill 执行前AI 必须先读取specs/目录下的所有文档建立对项目的完整认知。不读完不许开始干活。这就是为什么前面说开新窗口不怕丢上下文——因为不管开多少个新窗口AI 每次都会被强制重新读取项目文档。你的技术栈、开发规范、已有的功能设计它全都知道。文档在记忆就在。下面开始逐个介绍每个 Skill。Skill 1project-requirements-clarification需求澄清这个 Skill 就是来解决没有系统规划流程这个问题的。当你有一个模糊的想法时它会通过苏格拉底式的引导提问从多个维度帮你把想法挖透——核心价值是什么、目标用户是谁、关键特征有哪些最终生成一份标准化的项目描述。为什么是引导式而不是让你自己填表因为对于不知道细节的人来说你让他自己说他说不出来。他需要有人引导一步一步往下问答案自然就出来了。这个 Skill 最厉害的地方在于它像一个好奇的合伙人在跟你聊天而不是一个冷冰冰的填表机器。就像你跟合伙人说我想做个博客合伙人肯定会追问你很多问题——AI 在这里扮演的就是这个角色。而且你可以反复调用这个 Skill。比如第一次生成结果后你觉得还不够完善直接告诉 AI我还想加更多功能它会用同样的引导方式继续帮你深挖。我在开发新项目时百分之百会用这个 Skill对新手来说强烈建议从这里开始。示例你发送的信息/project-requirements-clarification 我想开发一个个人博客AI 回复的信息这个想法很有趣我来帮你把它想清楚。先聊几个关键问题为什么想做博客A记录自己的技术学习过程给自己看B写文章吸引读者打造个人品牌C纯粹练手学习全栈开发或者其他原因先告诉我这个后面我再问你目标用户和核心功能。一步一步来不着急。Skill 2project-product-overview产品概述需求澄清完成后你手上有了一份项目描述。但这份描述更像是聊天记录的总结——信息有了但还不够结构化拿去做技术选型或架构设计还差点意思。没有这个 Skill 会怎样你可能直接拿着模糊的需求就开始让 AI 写代码了。写到一半发现这个功能到底归哪个模块验收标准是什么目标用户到底是谁然后你开始回头补补着补着发现前面的代码跟新的规划对不上又得改。这个 Skill 做的事情就是把需求澄清的结果升级为一份正式的产品文档。它会帮你明确项目愿景是什么、核心价值在哪、目标用户是谁、系统分成哪几个核心板块、验收标准怎么定。AI 在这里扮演的是首席产品官的角色。信息不够的地方它会用引导式提问帮你补上——问法很具体给你举例子让你选不会问那种让人懵的开放式大问题。最终输出一份specs/产品概述.md这份文档就是后面所有 Skill 的地基。示例你发送的信息/project-product-overview 请基于需求澄清的结果生成产品概述AI 回复的信息我已经读取了你的项目描述大部分信息很清晰但有几个关键点需要补充1. 核心价值还不够明确你的博客和市面上其他博客的最大区别是什么A主打 Markdown 写作体验像 Typora 一样流畅B主打 SEO 和流量获取帮你把文章推出去C主打极简部署一键上线零运维或者你有其他想法2. 验收标准需要量化第一版上线的标准是什么我建议至少定两条功能层面比如能发布文章、能按标签分类、有基础的阅读统计性能层面比如首页加载 2 秒请告诉我你的选择我来生成完整的产品概述文档。Skill 3project-tech-stack技术栈选型产品概述定了下一个问题就是用什么技术来做这一步很多人要么自己去搜最火的前端框架要么直接跟 AI 说你帮我选。两种做法都有问题——追热门容易踩坑新框架生态不全、文档不够、AI 训练数据少全交给 AI 的话它也不知道你的具体约束容易推荐一个技术上完美但你根本用不起来的方案。这个 Skill 的 AI 角色是CTO它做选型的逻辑是**“最合适而不是最热门”**。它会先读你的产品概述分析项目规模、用户量级、实时性要求这些关键约束然后主动给你推荐完整的技术组合——不是让你一个一个选而是直接给你打包好的方案。对于不懂技术的人来说这里最贴心的设计是当需要你做选择时一定会给选项、给解释、给推荐。不会冷冰冰地问你用什么数据库而是告诉你每个选项适合什么场景然后说我建议选这个因为…。最终输出specs/技术栈.md。示例你发送的信息/project-tech-stack 请进行技术选型AI 回复的信息我已经读取了你的《产品概述》这是一个个人博客项目核心需求是 Markdown 写作 SEO 友好 低运维成本。基于分析我推荐以下方案推荐方案Next.js Supabase Vercel前端/后端Next.js 14App Router—— SSR 天然对 SEO 友好前后端一把梭不需要单独维护后端数据库SupabasePostgreSQL—— 免费额度足够个人博客用自带用户认证部署Vercel —— Next.js 的亲儿子推上去就能跑零运维样式Tailwind CSS —— 开发快AI 写起来也最顺手有一个细节需要确认你需要评论功能吗A不需要保持极简B需要用第三方服务如 Giscus基于 GitHub Discussions零成本C需要自建评论系统工作量会增加不少我的建议如果要做的话选 B成本为零且不影响核心开发节奏。Skill 4project-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 5project-dev-standards开发规范目录结构有了但代码怎么写变量怎么命名Git 怎么提交这些如果不提前定好后果就是——你让 AI 写了十个文件每个文件的风格都不一样。有的用驼峰命名有的用下划线有的组件用箭头函数有的用 function 声明Git 提交信息更是五花八门。改起来的痛苦远比提前规定好要大得多。这个 Skill 的 AI 角色是技术委员会它会基于你的技术栈生成一份完整的开发规范覆盖代码风格、命名约定、Git 工作流、错误处理甚至包括AI 协作协议——告诉 AI你在这个项目里写代码必须遵守哪些规矩。这里有一个重要的设计每条规则都具体到可以直接执行。不会出现遵循最佳实践这种废话而是明确告诉你组件文件用 PascalCase工具函数用 camelCase并且附带正确写法和错误写法的对比。最终输出specs/开发规范.md。示例你发送的信息/project-dev-standards 请制定开发规范AI 回复的信息已读取技术栈和项目结构文档以下是定制的开发规范节选命名约定元素风格示例组件文件PascalCasePostCard.tsx工具函数文件camelCaseformatDate.ts目录名kebab-caseuser-profile/TypeScript 严格规则// 错误 - 禁止使用 anyconstdata:anyawaitfetchPost()// 正确 - 明确类型定义constdata:PostDetailawaitfetchPost()Git 提交规范feat(posts): 添加文章标签筛选功能 fix(auth): 修复登录状态丢失问题完整规范共 15 个章节已全部生成。请确认后我保存到specs/开发规范.md。Skill 6project-roadmap-planning路线图规划到这一步你已经有了产品概述、技术栈、目录结构、开发规范——怎么做已经很清楚了。但还有一个问题先做什么这个问题比你想象的重要。很多人的做法是想到啥做啥或者从第一个页面开始做。结果呢做到用户管理的时候发现登录系统还没搭做到文章详情页的时候发现数据模型还没定义。到处被依赖卡住。这个 Skill 的 AI 角色是技术产品经理它会做三件事分析模块依赖——哪些是地基比如用户认证、公共组件哪些是核心业务哪些是锦上添花划分里程碑——MVP 做什么、完整版做什么、增强版做什么生成开发顺序——每个模块带具体的开发指令做完一个勾一个拿到路线图以后你就不用纠结接下来做什么了按顺序推进就行。最终输出specs/开发路线图.md。示例你发送的信息/project-roadmap-planning 请规划开发路线图AI 回复的信息基于产品概述和项目结构我分析了模块间的依赖关系规划如下里程碑一MVP核心闭环Phase 1.1基础设施 ——authshared地基所有业务模块都依赖它Phase 1.2核心业务 ——posts文章的创建、编辑、发布、Markdown 渲染Phase 1.3前台展示 —— 文章列表页、详情页、标签筛选做完这步 MVP 就能用了里程碑二完整版Phase 2.1阅读统计analyticsPhase 2.2后台管理admin里程碑三增强版Phase 3.1SEO 优化sitemap、Open GraphPhase 3.2性能优化图片懒加载、ISR建议从 Phase 1.1 开始每完成一个 Phase 回来勾选进度。Skill 7project-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 开始开发。功能级工作流开发具体功能V3 重做项目初始化完成后你手里有了一整套文档和项目骨架。接下来就进入真正的开发阶段了一个功能一个功能地做。功能级工作流的流程跟项目级很像——先澄清需求、再设计方案、再拆任务、最后写代码。但区别在于它是针对单个功能的闭环而且你会反复使用它。路线图里列了 10 个功能那你就跑 10 遍这个流程。V3 对功能级的五个 Skill 做了近乎完全的重做。核心变化有三个一是 Skill 从操作手册变成了角色设定不再一步步教 AI 做什么而是告诉它你是谁、关注什么、底线在哪二是编码阶段引入了 TDD测试驱动开发先写测试再写代码三是验收标准AC贯穿了整条链路从需求到编码每个阶段都必须能追溯到 AC。Skill 8feature-requirements-clarification功能需求澄清你可能会想前面不是已经做过需求澄清了吗为什么还要再来一遍因为项目级的需求澄清是全局视角——你想做什么产品、有哪些大板块。但具体到某个功能细节差得远。比如你说我想给文章列表加个搜索听起来很简单对吧但你想过这些问题吗搜标题还是搜正文筛选条件能不能组合搜不到东西显示什么要不要记住搜索历史怎么算做完了这些你不想清楚AI 就只能猜猜出来的东西跟你脑子里想的完全不一样。V3 里这个 Skill 的角色是你的产品搭档它不会给你列 ABCD 让你选而是像一个真正的搭档跟你聊天。你说搜标题就行它可能会追问正文要不要搜、标签呢你提到支持筛选它会接着聊筛选条件之间是什么关系。全程不聊技术只聊用户能做什么。这个阶段最重要的产出是验收标准AC每条用 Given-When-Then 格式描述一个具体场景。AC 的质量决定了后面一切——技术方案怎么设计、任务怎么拆、测试怎么写。最后输出一份功能需求文档到specs/features/目录下。示例你发送的信息/feature-requirements-clarification 我想给文章列表加个搜索AI 回复的信息搜索功能好的。先聊几个基本的——你说的搜索是只搜标题还是正文也要搜标签呢另外你的文章列表现在有没有分类或者筛选如果有的话搜索和筛选之间是什么关系比如我先选了某个标签再搜索是在这个标签下搜还是搜全部你先说说大概想要什么效果咱们一步步聊。Skill 9feature-tech-design技术方案设计需求文档写好了接下来该想怎么实现了。没有这个 Skill 的时候很多人直接让 AI 开始写代码。结果 AI 随便选了个实现方式写到一半发现不合适又推倒重来。或者更糟——功能写完了发现跟已有的代码架构冲突改起来比重写还痛苦。V3 里这个 Skill 的角色是你的技术搭档它会先看你项目里已有什么可以复用然后从 AC 反推需要什么数据模型、什么接口、什么核心逻辑。沿用项目已有做法的决策它直接定不问你但需要引入新依赖或者有多种可行方案的它会暂停让你确认。方案末尾有一张 AC 覆盖汇总表一眼就能看到每条需求是否都有对应的技术设计。如果某条 AC 在技术上没法实现它必须明说不能假装覆盖了。示例你发送的信息/feature-tech-design 搜索功能AI 回复的信息读完需求文档了。搜索这块有个决策需要你来定——现在你的文章数据量不大用数据库的 LIKE 查询就够了简单直接。但如果后面文章量上来了可能需要换 Elasticsearch 之类的方案。我建议先用 LIKE后面真到了性能瓶颈再迁移成本最低。你觉得呢另外搜索框要不要做防抖就是用户打字的时候不要每敲一个字就请求一次等停下来再搜。这个我建议加上体验会好很多实现也不复杂。Skill 10feature-task-planning任务规划技术方案有了但你总不能直接丢给 AI 说按技术方案写代码吧。一个功能可能涉及十几个文件、五六个模块让 AI 一口气全写了它大概率会搞混、漏掉东西因为上下文太长导致质量下降。V3 里这个 Skill 的角色是技术主管把技术方案拆成一个个原子任务——每个 30 分钟到 2 小时单一职责可独立验证。同时理清依赖关系用 Mermaid 图展示。V3 有两个重要变化。第一测试不再是独立的任务。V2 里会有单独的编写单元测试任务V3 取消了因为每个任务都通过 TDD 执行测试内嵌在执行过程中。第二验证标准的质量成了核心产出。验证标准直接就是 TDD 红灯阶段的输入——写得好开发时就知道第一个测试该怎么写。比如搜索接口返回正确数据就是差的验证标准GET /api/articles?qNext.js 返回 200每篇文章的 title 都包含 Next.js才是好的。每个任务还有一行通俗解释用零技术术语描述用户可见的变化比如完成后用户在列表顶部能看到一个搜索框。示例你发送的信息/feature-task-planning 搜索功能AI 回复的信息读完技术方案了拆成了 5 个任务分 2 个阶段。第 1 阶段后端Task-01搜索接口实现 [45min]通俗解释完成后后台具备了按关键词查找文章的能力验证标准GET /api/articles?qNext.js返回的每篇文章 title 都包含 Next.jsTask-02筛选与分页 [40min] ← 依赖 Task-01通俗解释完成后搜索结果支持按标签筛选一页显示 10 条验证标准GET /api/articles?qNext.jstag前端page2返回结果同时满足关键词和标签条件第 2 阶段前端Task-03搜索框组件 [40min]Task-04搜索结果列表与空状态 [35min] ← 依赖 Task-03Task-05防抖与加载状态 [30min] ← 依赖 Task-04注意这里没有单独的测试任务每个任务在执行时都会通过 TDD 先写测试再写代码。Skill 11feature-implementation编码实现终于到写代码的环节了。前面铺垫了这么多——需求、技术方案、任务规划——到这一步其实是最轻松的。因为 AI 要做什么已经写得清清楚楚了它不需要猜、不需要自由发挥照着文档一个任务一个任务执行就行。V3 最大的变化在这里引入了 TDD 作为唯一的编码方式。每个任务都走 Red-Green-Refactor 循环——先根据验证标准写一个会失败的测试再写刚好能通过的代码最后在测试保护下重构。铁律只有一条没有失败的测试就不写实现代码。V2 里每个任务开始前都会弹一句是否继续“七个任务弹七次你只能一直回继续”。V3 去掉了这种机械确认AI 像一个真正的开发者一样流畅地推进。TDD 循环完成后根据任务性质选择验收方式UI 任务用 Playwright 在浏览器中操作验证纯后端任务靠单元测试覆盖数据库变更通过查询验证。每个阶段完成后生成报告里面有个技术债务区域记录开发中务实的妥协。重要的是记录下来不是假装它们不存在。为什么一个阶段一个阶段来不一口气全做完AI 的上下文窗口有限塞太多东西质量会下降。每个阶段做完可以检查一下发现问题及时纠正。示例你发送的信息/feature-implementation 完成搜索功能的任务 第1阶段AI 回复的信息读完三份文档了第 1 阶段有 2 个任务没有依赖阻塞直接开始。Task-01搜索接口实现先写测试。根据验证标准第一个测试是请求 GET /api/articles?qNext.js断言返回 200 且每篇文章的 title 都包含 Next.js。第二个测试是空结果的情况q一个不存在的词断言返回 200 且数组为空。跑一下——两个测试都失败了原因是接口还不存在符合预期。现在开始写实现代码…AI 会按 TDD 循环推进每个任务完成后更新任务规划文档并生成阶段报告。Skill 12feature-evolution功能迭代变更功能做完了上线了用了一段时间——然后你又有新想法了。“搜索能不能记住历史”“能不能按时间范围筛选”这时候如果你直接对 AI 说给搜索加个历史记录它大概率会把已有代码搅得一团乱——因为它不知道之前的需求文档、技术方案里写了什么只看到了现在的代码然后野蛮施工。这个 Skill 的角色是产品架构师专门处理对已完成功能的增量修改。它会先读取之前的所有文档搞清楚现状然后从四个层面分析影响需求层面 AC 要增删改哪些、技术层面接口和数据要怎么动、代码层面哪些文件受影响、任务层面有没有进行中的任务被波及。核心原则是改不是重做。没受影响的内容原封不动只在受影响的地方就地修改末尾追加变更日志。变更分三类微调Tweak小改动比如调整排序方式不涉及新 AC扩展Extension加新东西比如加搜索历史需要新增 AC重构Refactor动了核心结构比如搜索引擎从 LIKE 换成 ElasticsearchV3 新增了一个关键判断如果变更影响超过原始功能的 70%AI 会建议你回到需求澄清重走流程而不是硬做增量。这个劝退本身就是有价值的输出。示例你发送的信息/feature-evolution 搜索功能加一个搜索历史AI 回复的信息读完搜索功能的全套文档了。加搜索历史属于扩展类变更需要新增 AC但不影响现有的搜索逻辑。影响分析需求层面新增 2 条 AC搜索后自动记录、点击历史词直接搜索技术层面需要新增一个 search_history 表和对应的 API前端需要在搜索框下方加一个历史记录的下拉面板。已有的搜索接口和结果展示不需要改动回归风险很低。需要新增 3 个开发任务预计工时 80 分钟。我先把变更文档生成出来然后你用 feature-implementation 执行就行。Skill 13bugfix-workflowBUG 修复遇到 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 理解得更准产出质量明显提升。更重要的是创建一个文档专门存放你用过的提示词。为什么因为你开发到后面会发现很多任务其实是类似的——同样是做一个列表页同样是写一个接口。但你这次写的提示词可能没有上次写的好如果有记录直接把上次效果更好的提示词拿来改改就能用。这个习惯一旦养成你的提示词库会越来越强效率也会越来越高。技巧 4feature-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 反而是最高效的方式比固定流程更灵活。核心原则就一条改了代码就要同步文档。发现不同步立刻补。拖得越久越难补。技巧 8AI 生成的文档花两分钟过一遍AI 生成的文档不要直接跳过哪怕你看不懂技术细节也没关系只需要花两分钟扫一遍。你不需要看懂每一行但你能看懂的部分往往是最重要的——功能描述对不对流程是不是你想要的有没有漏掉你说过的某个需求这些都是用大白话写的新手也能判断。为什么这一步很重要因为文档是后面所有 Skill 的输入。需求文档写错了技术方案就跟着错技术方案错了任务规划就跟着错最后写出来的代码自然也是错的。越早发现问题改起来越便宜。在文档阶段改一句话比写完代码再推倒重来轻松一百倍。所以每次 AI 生成文档后别急着进入下一步先扫一眼。技巧 9跟 AI 沟通的黄金法则用这套工作流的时候跟 AI 说话有几个技巧能大幅提升效果自己主动调用 Skill比如手动输入/feature-requirements-clarification 评论功能不要丢一句我想做个评论功能然后等 AI 自己去找对应的 Skill。AI 不一定能准确识别你的意图自己调用最稳一次只做一件事不要在一条消息里说帮我做评论功能顺便把登录页面也改一下。每个功能走自己的流程互不干扰技巧 10AI 搞不定的任务按这个顺序试用 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 也要改改完 BA 又冒出新问题。没有一个自动审核的环节帮你把关并行开发反而比串行更折腾。所以审核 Skill 是必须做的而且要做得足够可靠——它需要能自动检查代码质量、验证是否符合技术方案、发现问题后让 Agent 自己修正形成一个闭环但它非常消耗 token。这套工作流最初是为我自己设计的。没有任何资金支持也没有厂商赞助AI订阅全靠自己充。所以我选择了最省钱的方式——自己辛苦一点一个任务一个任务地开发虽然慢但每一步都可控。但从我把它分享出来的那一刻起这就不再只是我一个人的事了。用这套 Skill 的人可能有更充裕的预算也可能对效率有更高的要求。串行开发对我来说可以忍但不应该成为所有人的限制。所以后续我会认真做这几件事审核 Skill让 AI 能自动审查代码质量形成开发 → 审核 → 修正的闭环并行开发支持在审核机制可靠之后支持多任务同时开发配套教程每个新能力都会附带详细的使用教程这些不是画饼是我自己在开发过程中切实感受到的痛点。做出来之后会第一时间分享给大家。写在最后回头看这整套工作流核心理念就三个词文档驱动——所有决策都落到文档上AI 换了窗口也不会失忆你隔一个月回来也能看懂当时为什么这么做。阶段分离——每个 Skill 只干一件事产品经理不碰代码架构师不写实现开发工程师不改需求。不会出现问着问着需求突然开始写代码的混乱场面。引导式交互——不需要你是专家你只需要回答问题、做选择。AI 会把选项摆出来告诉你推荐哪个、为什么你点头就行。说白了这套工作流就是把软件工程那套需求 → 设计 → 开发 → 测试的流程用 Skill 的方式固化下来让 AI 在每个阶段扮演对应的专业角色。V3 更进一步把测试前置到了开发过程中TDD让 AC 成为贯穿始终的检查线。你不需要懂技术你只需要知道自己想要什么——剩下的交给流程。SpecForge 的 Skill 文件已开源GitHub 地址https://github.com/MingYuePop/SpecForge仓库里有 V1、V2、V3 三个版本直接用最新的 V3 版本就行。V1 是早期实验版V2 是第一次重构V3 是功能级 Skill 的彻底重做——从操作手册变成了角色设定引入了 TDDAC 贯穿了全链路。感谢大家看到这里希望这套工作流能帮到你。