AI Coding 工程化实践：从想法到落地的完整方法论

用好 AI 的关键，在于你的工程化和规范化做到什么程度。本文基于我个人付费多家 Coding Plan 的真实使用经验，按照项目的三个阶段展开：想法还不清晰时怎么把想法变成项目，需求明确之后前后端怎么开发与测试，以及怎么把重复劳动沉淀成 Skill 工作流。每一条建议背后基本都是我真实踩过的坑，希望能帮你少浪费一些 Token，毕竟浪费 Token 就是浪费钱。

一、工程化与规范化是用好 AI 的关键

在过去很长一段时间里，我付费了多家的 Coding Plan 和 Token Plan，包括 MiniMax、火山、MIMO、ChatGPT 等等。体验下来一个很直接的结论，现在的 AI 并没有网上宣传的那么强大。

对于稍微复杂一点的项目来说，根源在上下文：项目过大、文件过多，AI 无法全部阅读。表现出来就是不复用公共工具类或者模块内的工具类，代码编写不规范，不考虑并发等等。想一句话生成一个项目，是不太可能的。具体到开发过程中，很容易遇到三类问题：

幻觉：编造不存在的 API、凭空捏造字段和配置；
偏移中心：写着写着忘了目标，生成的代码越来越偏离核心需求；
理解错误：你说的和它理解的对不上，代码看起来能跑，但逻辑根本不是你想要的。

拿我自己项目里的实际表现举例。偏移最明显的就是不用工具类：我项目里搞了 Redis 的工具类、数字转换工具类等等，但到后面开发的时候能很明显感觉到 AI 乱搞，明明有公共工具类它不用，非要自己写一个，某些类里已经抽出来的公共方法它也不复用。还有 SQL 的 N+1 问题，循环里一条条查，数据量一上来接口就慢得没法看。更难受的是前后风格不一致：我前面用 MyBatis-Plus 的 Lambda 写查询语句，它改用 MyBatis 写 XML 文件，同一个项目里两套写法并存，后面维护起来非常痛苦。

但反过来说，如果是比较简单的项目，比如只做一个宣传网站，里面不涉及并发、不涉及大量数据存储，那完全没必要上后面这套复杂流程，这种活 AI 是可以直接完成的。流程的重量要和项目的复杂度匹配，这是我踩了很多坑之后的第一条经验。

所以这篇文章讲的所有内容，都是针对"稍微复杂点的项目"：怎么通过工程化和规范化的编写与推进，让 AI 稳定地朝你想要的方向走。这背后有一个贯穿全文的角色认知：你必须扮演领导，AI 是强大的执行者。混乱的记忆会使它偏移，模糊的描述会使它弄错方向，你要做的就是统领它，让它发挥强大的作用。

下面按项目的三个阶段展开。

二、从想法到项目：把想法沉淀成文档

这个阶段针对的是：项目还没开发起来，只是有个想法，或者需求还不明确、还不完善。这个阶段的核心任务只有一个，完善项目认知，并把它们沉淀成文档，提供给后面开发时的 AI 查阅。

2.1 为什么文档先行：一次昂贵的踩坑

我之前踩过一个大坑：项目做到中途，整体我还记得，但具体需求和功能要求的细节已经忘了，只凭当时的记忆让 AI 继续写。拿出入库单举例，当时设计的是出入库成功之后要回填对应的采购单，同时一张采购单可以对应多张入库单，因为货可能分批到。这几个要求我全忘了，AI 更不可能知道。结果到测试阶段才发现数据错乱，排查了很久才定位到问题：代码量实在太大，而且锁很多，业务缠得很深，后面补得非常痛苦。返工烧掉大量 Token，这部分钱花得很冤。

这类坑的根源在于 AI 没有跨会话的记忆，人的记忆又会衰减、走样。你脑子里的"大概记得"，传到 AI 那里就是模糊描述，模糊描述必然导致理解错误和偏移。解法只有一个，把需求沉淀成文档，文档就是 AI 的外部记忆，每次开发都让 AI 先读文档，别再依赖你我的记忆。

2.2 用"反问"把想法聊清楚

如果你现在只是有点想法，项目具体怎么做还没有详细计划，先别急着让 AI 写任何东西。第一步是明确你的需求，而且这一步有个特别实用的技巧，就是让 AI 反问你。

大多数人的用法是"我问 AI"，但在这个阶段更好的用法是让 AI 给你思路、追问你。你可以先给它一个基本描述，比如：

我现在准备做一个有 xxx 功能、给 xxx 人员使用的 xxx 系统，解决 xxx 人员的 xxx 需求。

就这一句话里，有无数可以让 AI 反问你的点：人员有哪些？ 它可以帮你补充。而需求是跟着人员走的，人员确定了，需求根据人员的确定就会更加具体和明确，自然而然后面的功能和系统也就更加明确了。

也就是说，通过不断与 AI 交流，被它一遍遍追问，你可以一点点把项目聊清晰：需求是什么，功能有哪些，为谁服务，要解决什么问题。当你觉得已经足够明确的时候，再进入下一步，让 AI 生成对应的 PRD（需求文档）。

2.3 生成 PRD：多轮对话的记忆陷阱

让 AI 生成 PRD 这一步，有一个非常坑的地方：多轮对话之后的上下文遗忘。

前面你已经和 AI 聊了很多轮，上下文可能已经比较大了，此时让 AI 总结输出 PRD，它发生部分需求遗忘或功能遗忘的概率非常大，它会把前面聊过的某些功能直接漏掉，或者记住的是走样的版本。

我非常建议你在让它生成 PRD 之后，先让它自我审阅一遍，明确要求它"找可以完善的点、遗漏的需求"，往往能抓回一部分丢失的内容。但自我审阅不是万能的，因为它和初稿共享同一份上下文，它忘掉的东西，自我审阅时大概率也想不起来。

2.4 跨工具交叉审阅：让没有上下文的 AI 当"新人评审"

想把方案再完善一层、多找出一些漏洞，最好的办法是换一个完全没有上下文的 AI 来审阅。

我的做法是：用 Codex 生成 PRD 初稿并审阅修改一遍之后，再交给 Claude Code 审阅。这里有个关键细节，Claude Code 是完全没有上下文的，所以你需要大概讲解一点你的想法给它，然后让它以对应业务人员的视角来审阅这份 PRD，并且让它参考网上其他现有的、完善的大项目，为你这个项目做补充。

为什么要强调业务人员视角？因为同一份文档，开发视角看的是"能不能实现"，业务视角看的是"全不全、对不对"。需求完整性恰恰是业务视角才能审出来的。

为什么强调参考成熟大项目？AI 并不是不知道同类系统一般该有什么，只是没有参照的时候，它的补充会不够明确；参考现有的完善方案之后，内容相对来说就基本完善了，输出也会更加集中。

这相当于团队里来了个新同事做交叉评审，他不知道之前开会的来龙去脉，反而不会被带着跑，能一眼看出文档本身的漏洞。

2.5 审阅的正确节奏：先交流，再方案，后动笔

跨工具审阅这里还有一个踩坑点，节奏非常重要：不要第一轮就直接让它修改 PRD。

先交流：把背景讲给它，聊清楚你的想法，让它理解这个项目是干什么的；
让它自我审阅：以业务人员视角 + 参考成熟项目，输出它发现的问题和可以补充的点；
你来审阅它的回答：看看它说的有没有道理、有没有真正遗漏的点，把你的判断和补充一起反馈给它；
让它出修改方案：基于双方确认的内容，先出一份修改方案（改什么、怎么改、为什么改），而不是直接改文档；
敲定修改方案：你确认这份方案没问题之后，明确要求它务必遵循这份修改方案去修改 PRD。

先出方案再动笔，能大大减少它自由发挥带来的偏移。这个"先方案、审方案、再执行"的节奏，不只是用在 PRD 上，后面开发阶段的每一步都是这个套路，是全文反复出现的核心方法。

2.6 PRD 是活文档

要说明的是，到这里完成的只是初版 PRD。随着开发的进行，这个 PRD 后续还会被修改：发现新的需求、砍掉不合理的功能、补充遗漏的流程，都要回头更新它。我们能做到的，是在每个阶段尽可能完善它，让它在任何时候都是"这个项目唯一权威的需求来源"。

2.7 技术选型：让 AI 给方案，自己拍板

需求明确之后，下一步是架构选型。这部分如果你自身不是很懂，可以让 AI 分析 PRD，根据 PRD 给你几种方案选择，同时讲明每个方案的优劣，并给出这几个方案里的推荐方案和对应的理由。

当然，如果你自己懂一些是最好的。选型里面其实有很多细节，前端框架选哪个，后端语言和框架怎么定，数据库用什么，消息队列要不要上、上哪种，还有其他很多中间件，甚至如果是分布式架构，会涉及更多大量的中间件。如果没有系统学习过开发，这部分会比较难以处理，我也没有什么好办法，只能靠积累。

但有一条建议我可以给得很坚决：选你熟悉的。这样会为后续开发减少很多困难。拿我自己举例：后端语言里我 Java 使用最多且熟练，而且 Java 生态很好，中间件我基本都熟悉，所以我选 Java。你对 Go 熟悉或者对 Python 熟悉，也可以选对应的，这跟你的项目情况有关。前端同理，一般就是在 Vue 和 React 里选一个，如果是客户端开发则选择其他对应技术栈。

选型完毕之后，强烈建议沉淀为文档，并且标明对应的选型理由。这有两个用处：一是方便你后续回看"当时为什么这么选"；二是后续开发新模块的时候，可以让 AI 看看这个模块需要引入哪些中间件，有选型文档在，它给出的建议才是贴合项目现状的。

2.8 页面原型：图片先行，模块分清

接下来是页面大概的样子和形式。这一步的核心产出是图片和模块划分。

如果你会使用 Figma 这类设计工具，会好很多：Codex 里面能连接 Figma，Trae、Qoder 这些工具也都支持，并且可以根据 Figma 的设计稿生成前端页面，整个链路非常顺。

如果你不会 Figma 也没关系，方法和前面一样，你对页面有点想法，就和 AI 沟通交流，把想法聊清楚。这里我建议，如果你的用量够的话，去 Codex 让它生成对应的前端页面图片给你看，它是支持你选择对应的元素进行修改的，这一步体验非常友好。而且根据 Codex 生成的网页图片，你让它根据图片生成或者修改对应的前端页面，相似度在 85% 左右，作为原型迭代来说完全够用了。

这个阶段不用追求定稿，做到下面几点就够了：

确定整个页面的大概样子，各个部分有什么；
把对应的图片保存好，放到项目对应的某个文件夹里面；
最好让 AI 帮你把模块分清楚，明确这个系统对应有哪几个模块，这个信息对后面开发非常有用。

最后，把页面原型图 + 模块划分 + 技术选型放在一起，形成一个项目大概介绍的文档。

2.9 模块划分与开发顺序：先独立，后耦合，MVP 先行

在正式动工之前，还有一步规划工作：确定模块的开发顺序。这一步可以让 AI 来分析，根据 PRD 和模块划分给出开发顺序建议，一般来说这部分它出错很少。

通常合理的顺序是：从与其他模块联系不深的独立模块开始开发，然后慢慢过渡到复杂的、多个模块交互的核心模块，把 MVP 的核心闭环先跑通。拿 ERP 举例，先做产品模块这种相对独立的，再进采购、销售、退货、库存这些必然绑定、深度交互的核心模块。

核心模块之间是高频交互的，代码编写上非常容易漏掉一些跨模块的逻辑：你改了某个产品的产品名，很可能要同时改多个模块的内容；某个产品因为代言人出问题、或者工厂生产出了问题要禁用，销售和采购模块就必须立刻停掉对它的销售与采购。

类似的跨模块联动逻辑会有很多，开发时是不可能一次全想到的。所以我的推荐做法是：让 AI 先帮你分析这类跨模块逻辑，尽可能帮你写成 TODO，后面相关模块完成之后回来补全。这样既不会打断当前的模块开发节奏，也不会把这些关键逻辑漏掉。

三、需求明确后的开发：以模块为单位推进

这个阶段的前提是：项目具体需求和页面样式已经明确了。核心原则先摆出来，后面所有内容都围绕它们展开：

先方案，后代码：任何一步都不让 AI 直接动笔；
每步沉淀文档：PRD、选型、表设计、接口文档，全部落成文件；
上下文隔离：不同的事开不同的窗口，互不污染；
多重审阅：AI 自审 + 跨 AI 交叉审阅 + 人工审阅。

3.1 开工前的两件事

在逐模块开发之前，有两件事要先做：

第一件：搭建项目骨架。 先让 AI 根据前面设计的模块文档，搭建出前后端对应的文件骨架（目录结构、模块划分、基础配置），然后连接 GitHub 并上传骨架。之后的所有开发都在这个骨架上、一个模块一个模块地推进。骨架先行的好处是：后续每个模块的开发都有明确的"落脚点"，AI 不会每次都自己发明一套目录结构。

第二件：把本地环境信息写进 AGENTS.md / CLAUDE.md。 AI 是可以访问你本地的数据库这些资源的，但它不会记住这些信息。所以你最好在 agent.md（Codex 用）或者 CLAUDE.md（Claude Code 用）文件里面写好：

本地数据库是哪个端口、什么账号；
Redis 是哪个端口；
MQ 是哪个端口；
对应的编译工具在本机的哪个位置。

不写这些的下场是：AI 每次需要连接数据库都要重新调用工具查找位置，来回浪费大量时间和 Token。环境信息前置，一次写好，全程受益。

3.2 上下文隔离：一类文档一个窗口，一个模块一个窗口

这是一个非常重要、但很容易被忽略的习惯，生成 PRD、做技术选型、设计数据库，这几件事我都是建议各开一个独立的窗口来做。

原因有两点：

避免上下文污染。前面窗口里聊过的内容，会一直留在上下文里，其中过时的、错误的讨论会干扰 AI 当前的判断。开新窗口，AI 反而可以更加明确地看出错误；
精华都沉淀在对应的文档里面了，实在不是很需要之前的记忆。文档就是记忆，何必让 AI 靠着上下文里一堆聊天残渣干活呢？

这个原则延伸到开发阶段就是：一个模块，一个窗口。模块 A 的窗口只聊模块 A，模块 B 另开窗口，互不掺和。

3.3 单模块开发闭环：完整流程拆解

下面是这篇文章最核心的内容，一个模块从设计到完成的完整流程。前面已经明确了前端页面大概的样子，现在需要一个个模块完善。

Step 1：页面完善——变动最多、耗时最长的部分

每个页面要呈现什么内容，这部分是整个项目变动最多且最高频的部分，需要花费大量时间。

做法和之前一样：让 AI 以对应的目标需求人员的视角审阅和说明该页面应该呈现什么、有哪些操作比较好、动画怎么样等等，仍旧以图片修改为主，让它生成页面图给你看，你挑毛病、选元素改，迭代到满意为止。如果用 Figma 就更简单了，直接改设计稿就行。

注意节奏：以一个模块为单位完成。不要东一榔头西一棒子，把一个模块的所有页面都确定下来，再进入下一步。

Step 2：数据库表设计——AI 初版大概率不合理

模块页面确定之后，开始设计这个模块的数据库表结构和对应字段。这部分比较重要，因为 AI 第一遍生成的数据库表很可能是不合理的。

这个环节需要你有判断能力，拿着表结构回头看看和页面对不对得上：页面要展示的字段表里有没有？页面要做的操作表结构撑不撑得起？这需要一定的项目经验。

如果你没有这个经验，我的建议就是前面说过的：两个 AI 交互审阅。Codex 出的初稿丢给 Claude Code（附上页面说明和业务背景），Claude Code 的问题再拿回 Codex 确认。这是减少错误最好的方法，而且十分有效。

表设计确认后，沉淀成文档，和 PRD、选型文档放在一起。

Step 3：接口文档——Postman / Apifox 里过一遍

表设计完成之后，我非常建议接着生成对应的接口文档（API 文档），并且把它导入到你自己的 Postman 或者 Apifox 之类的工具里面看看有没有问题。

这一步是让你以调用方的身份检查契约：字段名对不对、返回结构合不合理、缺不缺接口。你自己如果察觉不到什么问题，就可以进入开发了。

Step 4：编码前的最后一道审阅

在正式编写代码前，我建议在提示词里加上一句话：

请审阅接口文档是否出现问题，如果无问题，再开始动笔。

就这么简单一句话，成本几乎为零，却能挡掉不少"拿着错误契约写了一整套代码"的返工。

Step 5：方案先行——不让 AI 直接写代码

这一步是我整个开发流程里的重中之重，我不建议让 AI 直接开始编写代码。

原因很实际：直接动笔，大概率生成的代码会有很多漏洞，而且问题很大，SQL 效率低下、锁该加的没加、该复用的工具类重新造了一个，这些坑事后返工的成本远比先出方案高。

正确的做法是先让它把编程方案给你：

AI 输出编程方案；
你先审阅方案，看看有没有问题；
同时让 AI 自我审阅，自己提出这套方案的问题和解决思路；
大概两轮之后，这套方案就比较完善了，再开始动笔写代码。

这里注意，你自己也必须审阅方案，不能当甩手掌柜。另外，最好对 AI 的输出格式做点限制，这个看你个人喜好，我说说我喜欢的格式，供参考：

具体的流程图：一个请求从前端到后端经历了哪些流程，对应的各个流程大概干什么，注意是流程，而不是具体代码；
说明新增的文件在哪里、改动涉及哪些文件；
分析有没有并发或者锁的问题，如果有，给出对应的解决方案。

这种"流程图 + 文件清单 + 风险点"的方案格式，你审阅起来快，AI 落地时也稳定。具体喜欢哪种输出，需要你自己慢慢摸索，找到最适合自己的那一种，这也会成为后面沉淀 Skill 的素材（第四部分会讲）。

Step 6：编码与 AI 测试

方案敲定后进入编码。AI 写完代码不是终点，它还要自己把测试做掉。这里的测试方案需要在编程方案里就重点说明，我要求的测试体系是：

前端测试：

断言测试：关键交互逻辑的自动化断言；
视觉测试：页面渲染是否正常、样式有没有跑偏；
浏览器自动操作测试：模拟真实用户点击、输入、跳转，把交互流程走一遍。

后端测试：

单元测试：核心业务逻辑的正确性；
并发测试：并发场景下的行为是否符合预期；
锁测试：分布式锁、事务锁有没有真的锁住。

联调测试：

前后端接口打通后的端到端验证。

窗口的使用上，我建议：前端一个窗口编写，后端一个窗口编写，联调的时候选择前端的那个聊天窗口进行联调测试（前端窗口天然带着页面上下文，联调问题定位更直接）。这些测试 AI 都是可以做到的，关键是你要在方案里明确要求，否则它写完代码就停了。

Step 7：人工把关——AI 的测试不一定准确

AI 测试完了之后，你不能直接就不管了。三个必须做的动作：

审阅代码。它的测试不一定准确，有可能测试本身写得就是错的，跑通过不代表逻辑对；
在 Postman 或者 Apifox 里面手动测一下接口，确保返回格式没问题、字段和接口文档一致；
自己到页面上点击看看。前端跑一遍真实操作，交互对不对、显示正不正常，自己点过才算数。

到这里，一个模块的开发闭环才算真正完成：页面设计 → 表设计 → 接口文档 → 方案审阅 → 编码 → AI 测试 → 人工把关，然后带着这份沉淀，开下一个模块的窗口。

3.4 全流程一图流

把第三部分的内容串起来，整个开发阶段的流程是这样的：

┌─────────────────────────────────────────────────┐
│ 开工准备                                         │
│   搭建前后端骨架 → 上传 GitHub                   │
│   AGENTS.md / CLAUDE.md 写好本地环境信息          │
└───────────────────┬─────────────────────────────┘
                    ▼
┌─────────────────────────────────────────────────┐
│ 单模块闭环（一个模块一个窗口）                    │
│   1. 页面完善（需求人员视角审阅 + 图片迭代）       │
│   2. 数据库表设计（双 AI 交叉审阅）→ 沉淀文档      │
│   3. 接口文档生成 → 导入 Postman/Apifox 检查      │
│   4. "请审阅接口文档是否出现问题"                 │
│   5. 编程方案先行（流程图+文件清单+并发锁分析）    │
│      → 人工审阅 + AI 自审，约两轮 → 动笔          │
│   6. AI 编码 + AI 测试                           │
│      前端：断言/视觉/浏览器操作测试               │
│      后端：单元/并发/锁测试                      │
│      联调：在前端窗口进行                        │
│   7. 人工审阅代码 + Postman/Apifox 实测接口       │
└───────────────────┬─────────────────────────────┘
                    ▼
   每完成一个模块：重构审计（抽取工具类/公共方法）
                    ▼
   Bug 修复：定位根因 → 复现 → 修复方案
            → 修复后再次复现 → 最小影响面
                    ▼
        下一个模块（新窗口） / 回补跨模块 TODO

3.5 代码量到了一定规模，务必及时重构

还有一点很重要，要单独拿出来说：当项目代码量到达一定量的时候，务必及时重构。

AI 写的代码有个很典型的毛病，它尤其喜欢抽取大量短的私有方法，一个逻辑被拆得七零八落，每个方法就几行。单看每个方法都没问题，连起来读就很困难，代码越堆越复杂。等你看不懂自己项目里的代码了，AI 后续的修改只会更偏，它面对的也是同一堆难读的代码。

所以我的做法是，每完成一个模块就停下来，让 AI 审一遍代码结构，看看有没有可以抽取的工具类、公共方法，有没有可以优化的地方，其实挺多地方可以优化的。把过度拆分的方法合并回去，该复用的工具类统一，该删的删掉。

这里必须审阅它怎么抽，最好还是先出方案再动手，不然它会发癫：一行代码而且只被一个方法调用的，它都能给你抽成一个私有方法。这种"为抽而抽"的方案直接打回去，别让它落地。重构这件事拖得越晚，成本越高，后面 AI 的产出质量也会跟着往下掉。

3.6 Bug 修复：先定位根因，再做最小影响面的修复

开发过程中 bug 是躲不掉的，这里也有一套我总结的流程，核心思路是先定位、再修复、必复现、控影响面。

第一步，定位 bug 根因。 别一上来就让 AI 改，先让它把根因找出来。可以直接把日志、请求响应、复现步骤丢给它分析。根因没找准就动手，改出来的往往是"治标不治本"，甚至引入新问题。

第二步，复现 bug。 修复之前必须先能稳定复现。复现不了就没法验证修复效果，修复完了你也不知道它是真的好了，还是恰好这次没触发。

第三步，设计对应的修复方案。 还是老规矩，先出方案再动笔，方案里说清楚改哪里、为什么这么改。

第四步，修复之后再次复现。 用同样的步骤验证 bug 是否还会出现，不出现才算修完。

其中有一条要特别强调：最小影响的修复，尽量不影响其他模块。能让 AI 把改动控制在最小范围内的，就别让它顺手重构。如果改动比较大、影响多个模块，建议把受影响的模块一起测试一下，且顺便看看还有没有其他 bug，一起修复最好，省得来回返工。

这套流程是要自己不断去总结的，每次踩坑都是完善它的机会，我自己的 bug 修复流程就是抽成了 Skill 一直迭代的（第四部分会讲）。

四、从重复到复用：用 Skill 搭建专属工作流

前面两个部分，我说了很多"文档沉淀到项目内"的做法。但你实际跑起来会发现一个麻烦：后续每次开发，你都得跟 AI 说一遍"xxx 文档在 xxx 位置"。这种高度重复的东西，就是我第四部分要讲的内容：把重复抽取成 Skill。

4.1 痛点：重复的"文件在哪"和重复的提示词

重复主要有两类：

第一类：文档位置的重复告知。 每次开新窗口开发，都要交代一遍 PRD 在哪、选型文档在哪、表设计文档又在哪。

第二类：提示词的重复编写。 回想一下前面流程里反复出现的操作，比如"以 xxx 人员的视角审阅"，比如"生成 PRD"，再比如"数据库表设计并审阅"，这些基本都是大量重复的提示词和操作。

4.2 什么值得抽成 Skill

针对第一类重复，你可以抽一个"项目理解"之类的 Skill（名字看你命名），它提供给 Agent 的信息就是：这个项目有哪些文档、各在什么位置。当然，这有一个前提：你的文档存储必须是规范化的。文档位置天天变，Skill 就废了；文档有固定的相对路径（比如统一放在项目文件夹的 ~/docs 下面），Skill 才能稳定工作。

针对第二类重复，把你觉得效果好的提示词抽出来沉淀成 Skill，比如：

PRD 生成与审阅的完整流程（反问澄清 → 生成 → 自审 → 交叉审阅 → 方案化修改）；
数据库表设计初版（阅读 PRD → 以业务人员视角设计 → 参考网上完善方案）；
接口文档设计初版（和表设计高度同构：读 PRD → 定契约 → 对照成熟方案检查）；
Bug 修复闭环（定位根因 → 复现 → 修复方案 → 再次复现 → 最小影响面控制）；
输出格式也可以抽成 Skill，比如前面说的方案设计格式（流程图 + 文件清单 + 并发锁分析），如果你用下来觉得某种方案描述方式对你的开发很有帮助，就把它沉淀下来，以后每次出方案都自动是这个格式。

除了省事，抽 Skill 还有一层更重要的意义：提高质量。编码质量、审阅质量、输出质量，都能靠 Skill 抬上去。拿后端编码来说，方案先行的 Skill 里可以固化这些检查项：SQL 效率高不高、缓存方案选哪种、锁方案选哪种、有没有并发问题、工具类有没有用上、公共模块有没有可以复用的。前端同理。质量上去了，你需要修改修复的地方就少了，效率自然也就快了。

这些抽取出来的 Skill，因为都指向固定的相对路径、遵循固定的流程，互相之间就实现了联动：PRD Skill 的产出是表设计 Skill 的输入，表设计 Skill 的产出是接口文档 Skill 的输入，一条链就串起来了。

4.3 这是生成质量跃升的点

我的体会是，不断提取 Skill 并实现联动，是生成质量跃升的点，非常重要。原因很简单，效果好的提示词被固化下来了，不再依赖你每次的临场发挥和状态；每次都是验证过的最佳流程，生成质量的下限被抬高了；效率上的节省更不用说，一句话触发一整套流程。

按自己的开发习惯，不断把好用的东西抽出来，慢慢就能搭建一套非常不错的、完全定制于你的开发工作流。当然，这需要一定时间的积累，不是一次就能抽完的，每踩一个坑、每发现一个好用的表述，都是一次沉淀机会。Skill 也不是抽完就完了，它会随你的经验一直优化，改到贴合你的习惯为止。

4.4 我的部分 Skill 与开源仓库

我把抽取出来的一部分工作流开源在了 GitHub 上，有兴趣的可以看看：LI-S-H/my-skills，包含三个部分：

分组	用途
前端开发包	覆盖前端项目从需求澄清、PRD、开发规范、契约同步、代码审核、浏览器 QA、产品验收到修复沉淀的完整闭环
博客写作包	技术博客写作 + Hexo front matter 生成
通用工作流工具	需求澄清、复杂任务审查、Bug 修复闭环

其中前端开发包最能体现"Skill 联动"的思路，它的调用顺序是一条完整的流水线：

需求门禁 → PRD 生成 → 开发规范 → 契约同步
                                ↓
                        代码审核（显示/代码/业务逻辑三类问题）
                                ↓
              浏览器 QA（截图取证 + 自动化断言） → 产品验收 → 修复闭环

另外从我本地 Codex 和 Claude Code 的 Skill 目录里，挑几个有代表性的给大家参考，都是上面方法论的落地：

before-implementing-dev-task：接到任何开发任务，自动按"核对契约 → 出方案 → 等审阅 → 实施 → 同步 → 提交"的标准流程走，这就是第三部分"方案先行"的 Skill 化；
erp-backend-module-crud：后端模块 CRUD 接口的标准化流程，先给文字版方案（流程图 + 文件清单 + 关键点），等用户确认后开工，这就是"输出格式约束"的落地；
code-audit-and-refactor：存量代码审计重构，多维度扫出问题清单 → 用户挑 → 出三段式方案再实施；
requirement-clarifier / task-review-executor：需求澄清和复杂任务审查，对应第二部分的"反问澄清"和"多重审阅"；
figma / figma-implement-design / playwright：设计稿转页面、浏览器自动化测试，对应页面原型和前端测试环节。

我没有全部上传，仓库里只是部分，思路比 Skill 本身更重要：照着你自己的开发习惯去抽，你的工作流才是你的。

五、写在最后

把三个阶段的心法收在一张表里：

阶段	核心动作	给 AI 什么
想法 → 项目	反问澄清、交叉审阅、沉淀文档	明确的需求和边界
需求明确 → 开发	方案先行、多重审阅、模块推进、及时重构、最小影响面修 bug	完整的契约和规范
重复 → 复用	抽取提示词、Skill 联动	固化的最佳流程