“你这个需求分析到开发设计的 Skills 能不能分享一下？”
“有没有一套能从需求一直走到开发交付的流程？”
问的人多了以后，我认真想了一下：
如果只是把我项目里的原始 Skills 直接丢出来，那肯定不合适。
里面有真实业务习惯、历史项目经验、团队流程、字段映射、行业规则，甚至还有一些只有我们自己才懂的“祖传坑位”。
所以我做了一件事：
把我自己在真实项目里用过的 Skills 做了一次蒸馏处理。
去掉具体业务数据，保留方法论；
去掉公司内部上下文，保留可复用流程；
去掉个人项目细节，保留大家都可能踩的坑。
最后整理成了这个开源项目：
Analysis to Delivery
它不是一个“让 AI 更会聊天”的 Prompt 包。
它是一套从需求澄清 → BRD → 合规 → 测试用例 → PRD → 开发设计 → QA 审计 → 交接的标准化 Skills 工作流。
说人话就是：
让 AI 不要一听需求就开写代码，而是先像一个靠谱产品经理、开发经理、架构师、测试负责人那样，把事情问清楚、设计清楚、验证清楚。
一、为什么我要做这个 Skills
我之前做项目管理时，最头疼的不是开发不会写代码。
真正麻烦的是这些：
需求只说了一半，开发理解的是另一半； 用户嘴里的字段名，和数据库真实字段名不是一个东西； Oracle、PostgreSQL、MySQL 方言混着写； 前端页面、后端接口、数据库字段三方对不上； 设计文档写得很好看，但开发一看还是不知道怎么做； 测试用例后置，结果上线前才发现核心路径漏了； AI 接手时特别自信，但它的自信往往来自“我猜的”。
尤其是有了 AI 之后，一个新问题变得更明显：
以前人瞎猜，速度还有限；现在 AI 瞎猜，效率非常高。
这就有点可怕了。
你说“ASN 单号”，它可能随手写成 ASN_ID。
你说“批号”，它可能写成 LOT_ID。
你说“订单状态”，它可能给你造一套自认为很合理的枚举。
它写得很快，格式很漂亮，语气很笃定。
然后上线时系统告诉你：
字段不存在。
这四个字，朴素、冷静、杀伤力极强。
所以我做这套 Skills 的核心目标非常明确：
不是让 AI 写得更快，而是让 AI 不要瞎写。
二、它是什么
仓库当前包含：
- 26 个独立可组合 Skills
- 3 个完整行业示例
- 5 个 GitHub Actions CI workflow
- 流程图工具链：ASCII → Mermaid / Drawio → SVG / PNG
- VSCode 扩展
- 项目级知识库配置机制
它的设计原则是：
小而精、可组合、不拥有流程。
我不希望它变成一个“一键接管你项目”的大怪物。
我更希望它像一套工具箱：
你想完整走流程，可以用 /analysis-delivery-workflow；你只想澄清需求，可以用 /grill-task；你只想出 PRD，可以用 /to-prd；你只想做 QA 审计，可以用 /qa-audit；你想进入编码实施，再接 /using-superpowers。
也就是说：
流程可以完整，但控制权还在你手里。
三、怎么安装
一键安装：
curl -fsSL https://raw.githubusercontent.com/sunj243909596-collab/analysis-to-delivery/main/install.sh | bash
手动安装：
git clone --depth 1 https://github.com/sunj243909596-collab/analysis-to-delivery.git \ ~/.claude/skills/analysis-to-delivery
安装后建议先跑一次 smoke test：
bash ~/.claude/skills/analysis-to-delivery/scripts/smoke-test.sh
如果你使用 Claude Code，可以直接：
/analysis-to-delivery
如果你不知道该用哪个 Skill，可以先：
/ask-delivery
它会根据你的目标帮你路由到合适的 Skill。
四、26 个 Skills 怎么分层
这套 Skills 我拆成了四层。
1. Router：入口层
主要是两个入口：
/ask-delivery/using-superpowers
/ask-delivery 负责帮你判断现在该用哪个 Skill。
比如你说：
“我现在有一个需求，还没整理清楚。”
它会建议你走 /grill-task。
你说：
“我已经有 PRD 了，要做开发设计。”
它会建议你走 /dev-design。
你说：
“我想从需求到交付完整跑一遍。”
它会建议你走 /analysis-delivery-workflow。
这就像一个前台分诊台，不直接治病，但能防止你挂错科。
2. User-invoked Actions：动作层
这是你最常用的一层，一共 9 个：
/setup-analysis-delivery：生成项目级配置 /grill-task：需求澄清 + 字段对齐 /to-brd：生成业务需求文档 /compliance-review：合规评审 /test-case-design：测试用例设计 /to-prd：生成产品需求文档 /dev-design：生成开发设计 7 件套 /qa-audit：QA 审计 /handoff：生成交接文档
这 9 个动作对应的就是从需求到交付的主链路。
3. Orchestration：编排层
如果你不想一个个选，可以直接用：
/analysis-delivery-workflow
它会按 9 阶段推进：
项目配置 需求澄清 BRD 合规评审 测试用例 PRD 开发设计 QA 审计 交接
这是我个人最看重的一层。
因为真正让 AI 变靠谱的，往往不是“多一个命令”，而是“少犯几个致命错误”。
它包含 7 条纪律：
no-field-guessing：严禁猜字段 no-self-invent：严禁自造知识 ascii-flowchart：流程图必须结构化表达 stage-gate：阶段门控，不能跳步 sql-dialect-discipline：SQL 方言必须一致 doc-numbering：文档编号必须稳定 context-pointer：必须按项目知识库加载上下文
这些纪律平时不需要你手动调用。
它们更像后台安全带，自动约束 AI 的行为。
五、我最想强调的几个设计
1. 不猜字段
这是我踩过最多坑的地方。
用户说“ASN 单号”，AI 不应该自己创造 ASN_ID。
它应该先读项目级 knowledge-path.md 指向的真实知识库。
如果找不到，就标成待确认。
找不到可以问，不能编。
这句话听起来朴素，但对企业项目特别重要。
2. 项目级知识库优先
真实项目里，不能只靠 Skill 自带的通用规则。
所以这套工作流支持项目级配置：
knowledge-path.mdtech-stack-path.mdcompliance-path.mddoc-naming.mdconfig-used.md
也就是说，每个项目都可以告诉 AI：
“我的知识库在这里。”
“我的技术栈是这个。”
“我的合规要求是这个。”
“我的文档编号规则是这个。”
AI 不再靠猜，而是按项目实际上下文工作。
3. 阶段门控
我不希望 AI 从需求澄清直接跳到开发设计。
所以这里设计了阶段门控：
需求确认没签字，不能进入 BRD； 字段对齐有缺失，不能进入下一步； 设计回测不通过，不能进入 QA； QA 审计 P0 > 0，不能交接。
这不是形式主义。
这是防止 AI 一路自信狂奔，最后把你带沟里的刹车系统。
4. 开发设计不是伪代码
它会要求产出：
AGENTS.md02-功能规格说明书 FSD.md03-数据模型设计.md06-开发设计说明书.md08-设计回测报告.md可选的任务复盘汇总
并且要求包含：
后端分层 前端组件 接口契约 数据模型 事务与异常 联调说明 Mock 数据 错误码映射
一句话：
开发拿到以后要能干活，而不是读完以后继续问“所以我要改哪儿？”
5. QA 审计前置到交接前
很多项目是上线前才发现文档、字段、SQL 方言、测试用例对不上。
这套流程在交接前加入 /qa-audit：
文档格式检查 文档编号检查 核心文档完整性检查 SQL 方言一致性检查 字段映射一致性检查 删除/修改精度检查
并按 P0 / P1 / P2 分级。
其中 P0 必须修复。
这相当于在交给开发之前，先做一次“文档和设计的上线前体检”。
六、三个示例：不是空架子
我在仓库里放了 3 个完整示例，方便大家照着看：
1. 医药物流 WMS 收货管理
技术栈：
Oracle Spring Boot Vue 3
重点演示：
GSP 合规 Oracle 字段对齐 巴枪扫码场景 状态机设计
这个示例非常接近我自己过去项目里最常见的场景：字段复杂、状态复杂、合规要求多，AI 最容易瞎猜。
2. SaaS 后台客户订单管理
技术栈：
PostgreSQL Express 5 React 19
重点演示：
多租户 PostgreSQL 方言 订单状态流转 支付集成场景
3. 移动 App 会员积分管理
技术栈：
Flutter Firestore Cloud Functions
重点演示：
FIFO 积分消耗 FCM 推送 离线优先 PIPL 轻合规
我放这 3 个例子，不是为了显得仓库丰富。
而是想说明一件事：
这套 Skills 不绑定某个行业，也不绑定某个技术栈。
它真正绑定的是一套工作方法：
需求先澄清，字段先对齐，设计先验证，交接前先审计。
七、适合谁用
我觉得它尤其适合这几类人：
1. 产品经理
如果你经常需要把一句业务需求变成开发能理解的 PRD、FSD、接口设计、测试用例，这套 Skills 会非常顺手。
它不会替你做产品判断，但会逼你把需求讲清楚。
2. 技术负责人 / 开发经理
如果你经常被这些问题折磨：
文档说不清； 字段对不上； SQL 方言混乱； 开发设计不可落地； 交接质量不稳定；
这套 Skills 可以作为团队的“交付前置门禁”。
3. 想用 AI 做企业项目的人
企业项目和 Demo 项目不一样。
Demo 可以“能跑就行”。
企业项目要考虑字段、状态、权限、合规、历史数据、交接、审计。
这套 Skills 就是为这种场景准备的。
八、一个推荐用法
如果你第一次使用，不建议一上来就跑完整 9 阶段。
可以先这样试：
/ask-delivery
然后从一个小需求开始：
我有一个订单查询需求，请用 analysis-to-delivery 帮我先做需求澄清和字段对齐。
如果你已经知道要走哪一步，也可以直接：
/grill-task
后续再依次推进：
/to-brd/test-case-design/to-prd/dev-design/qa-audit/handoff
如果是复杂需求，再使用：
/analysis-delivery-workflow
完整跑一遍。
九、我为什么选择开源
很简单。
因为我发现，很多人不是不会用 AI。
而是缺少一套能把 AI 拉回工程现场的流程。
大家都知道要“用 AI 提效”，但真实项目里最容易出问题的地方，往往不是代码写慢了，而是：
需求没有确认； 字段没有对齐； 业务规则没有复盘； 测试用例没有提前设计； SQL 方言没有检查； 交付物没人审计。
这些东西不性感，但非常要命。
所以我把自己用过的一套方法蒸馏出来，放到 GitHub 上。
你可以直接用，也可以 Fork 后改成你们团队自己的版本。
如果你所在行业有自己的合规规则、技术栈模板、真实示例，也欢迎提 PR。
我更希望它变成一个大家一起维护的“AI 交付工作流工具箱”，而不是我一个人的收藏夹。
结尾
Vibe Coding 很爽。
但真正进入企业项目以后，你会发现：
只靠 Vibe 不够。
你还需要字段对齐、阶段门控、合规评审、测试用例、开发设计、QA 审计和交接文档。
听起来很传统。
但也正是这些“传统工程动作”，决定了 AI 写出来的东西能不能真的交付。
所以这套 Skills 的目标不是让 AI 看起来更聪明。
而是让 AI 做事更像一个靠谱交付团队。
AI 可以帮我们写得更快，但交付这件事，还是要有规矩。
