一套基于 Kimi Code CLI Skill 系统的结构化研发全流程工具，将软件开发生命周期拆分为 6 个可复用、可独立触发的阶段 Skill，由 1 个工作流编排 Skill 统一串联。
- 阶段化：每个研发阶段独立为一个 Skill，可单独调用，也可按流程串联
- 质量门禁：每个阶段产出明确的结构化输出，经确认后再进入下一阶段
- 上下文传递：前一阶段的输出自动作为后一阶段的输入，避免信息丢失
- 知识沉淀：最终阶段强制归档设计决策和运维知识，解决“只有代码没有上下文”的问题
- 产物持久化：每个阶段的输出保存为标准化文件，支持跨会话继续工作和追溯历史
┌─────────────────────────────────────────────────────────────┐
│ PRD / 功能需求 │
└──────────────────────────┬──────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 1：需求分析（analyze-requirements） │
│ 输出：结构化需求、用户故事、边界/异常场景、待澄清问题清单 │
└──────────────────────────┬──────────────────────────────────┘
│ 质量门禁：用户确认需求
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 2：技术方案设计（design-tech-solution） │
│ 输出：整体流程、数据模型、模块设计、改动清单、非功能性设计 │
└──────────────────────────┬──────────────────────────────────┘
│ 质量门禁：用户审查设计决策
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 3：任务拆解（decompose-tasks） │
│ 输出：按层次拆解的编码任务列表（含依赖关系、复杂度评估） │
└──────────────────────────┬──────────────────────────────────┘
│ 质量门禁：用户确认任务列表
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 4：编码（coding） │
│ 输出：可运行的代码及对应测试 │
└──────────────────────────┬──────────────────────────────────┘
│ 质量门禁：自审通过（编译、测试、Lint）
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 5：代码审查（review-code） │
│ 输出：规范问题、潜在 BUG、性能隐患、安全风险、可读性建议 │
└──────────────────────────┬──────────────────────────────────┘
│ 质量门禁：严重问题清零
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 6：知识归档（archive-knowledge） │
│ 输出：需求背景、设计决策记录、核心实现说明、运维及维护指南 │
└─────────────────────────────────────────────────────────────┘
| 编号 | Skill 名称 | 触发场景 | 核心能力 |
|---|---|---|---|
| - | ai-coding-workflow |
启动完整流程或跨阶段流转 | 编排 6 个阶段，自动管理输入输出和门禁确认 |
| 1 | analyze-requirements |
用户提供 PRD、需求文档或功能描述 | 需求结构化、用户故事提取、边界场景暴露、缺失信息澄清 |
| 2 | design-tech-solution |
需求确认后进入技术设计 | 现有代码库分析、数据模型设计、模块划分、非功能性设计（性能/安全） |
| 3 | decompose-tasks |
技术方案批准后进入开发 | 最小可分配单元拆解、依赖关系梳理、并行机会识别、复杂度评估 |
| 4 | coding |
拿到具体编码任务后 | 按项目规范编码、同步写测试、小步增量交付、自审门禁 |
| 5 | review-code |
代码完成后合并前 | 多维度审查（逻辑/安全/性能/可维护性/测试）、分级问题输出、可操作建议 |
| 6 | archive-knowledge |
功能交付后或项目收尾 | 设计决策记录、运维指南、技术债务标注、维护注意事项 |
在对话中粘贴 PRD 或功能描述，然后说：
"针对这个 PRD 启动完整开发流程"
Kimi 将自动按 6 个阶段推进，每个阶段结束后展示输出并暂停等待你的确认。
| 你想做什么 | 对 Kimi 说 |
|---|---|
| 分析需求 | "分析这些需求" / "结构化这个 PRD" |
| 技术设计 | "设计这个功能的技术方案" |
| 拆解任务 | "把这个设计拆成任务" / "任务分解" |
| 编码实现 | "实现任务 T-03" / "编写 OrderService" |
| 代码审查 | "审查这段代码" / "对订单功能做代码审查" |
| 归档知识 | "给这个功能写文档" / "归档设计决策" |
- 已安装 Kimi Code CLI
- 将本目录下的 Skill 文件夹复制到你的 Kimi Skill 目录：
# 推荐路径
mkdir -p ~/.config/agents/skills/
cp -r ai-coding-workflow analyze-requirements design-tech-solution \
decompose-tasks coding review-code archive-knowledge \
~/.config/agents/skills/- 验证加载成功：
ls ~/.config/agents/skills/
# 应看到：ai-coding-workflow analyze-requirements archive-knowledge coding decompose-tasks design-tech-solution review-code- 重启 Kimi Code CLI 或开始新会话，Skill 将自动生效。
所有 Skill 已预打包为 .skill 文件，可直接复制到其他环境：
cp ~/.config/agents/skills/*.skill /path/to/backup/
# 在其他机器解压
unzip ai-coding-workflow.skill -d ~/.config/agents/skills/~/.config/agents/skills/
├── README.md # 本文件
│
├── ai-coding-workflow/ # 工作流编排器
│ ├── SKILL.md
│ └── references/
│ └── usage-guide.md # 使用技巧与示例对话
│
├── analyze-requirements/ # 阶段 1：需求分析
│ ├── SKILL.md
│ └── references/
│ └── output-template.md # 需求分析输出模板示例
│
├── design-tech-solution/ # 阶段 2：技术方案设计
│ ├── SKILL.md
│ └── references/
│ └── output-template.md # 技术方案输出模板示例
│
├── decompose-tasks/ # 阶段 3：任务拆解
│ ├── SKILL.md
│ └── references/
│ └── output-template.md # 任务拆解输出模板示例
│
├── coding/ # 阶段 4：编码
│ ├── SKILL.md
│ └── references/
│ └── workflow.md # 增量实现模式与常见陷阱
│
├── review-code/ # 阶段 5：代码审查
│ ├── SKILL.md
│ └── references/
│ └── checklist.md # 按关注点分类的审查检查清单
│
└── archive-knowledge/ # 阶段 6：知识归档
├── SKILL.md
└── references/
└── output-template.md # 知识归档输出模板示例
每个阶段的输出都会保存为标准化文件，存储在项目的 docs/ 目录下：
project-root/
├── docs/
│ ├── requirements/ # 阶段 1：需求分析产物
│ │ └── YYYY-MM-DD-功能名称.requirements.md
│ ├── design/ # 阶段 2：技术方案产物
│ │ └── YYYY-MM-DD-功能名称.tech-design.md
│ ├── tasks/ # 阶段 3：任务拆解产物
│ │ └── YYYY-MM-DD-功能名称.tasks.md
│ ├── implementation/ # 阶段 4：编码实现摘要
│ │ └── YYYY-MM-DD-功能名称-task-T-XX.md
│ ├── review/ # 阶段 5：代码审查产物
│ │ └── YYYY-MM-DD-功能名称.review.md
│ └── knowledge-base/ # 阶段 6：知识归档产物
│ └── YYYY-MM-DD-功能名称.md
- 格式：
YYYY-MM-DD-功能名称.阶段标识.md - 示例：
2024-03-15-用户头像上传.requirements.md2024-03-15-用户头像上传.tech-design.md2024-03-15-用户头像上传.tasks.md2024-03-15-用户头像上传-task-T-04.md2024-03-15-用户头像上传.review.md2024-03-15-用户头像上传.md（知识归档）
如果你需要在不同会话中继续工作，可以按照以下方式恢复上下文：
告诉 Kimi 当前进度和产物位置：
"我已经完成了需求分析和技术方案，文件在
docs/requirements/2024-03-15-用户头像上传.requirements.md和docs/design/2024-03-15-用户头像上传.tech-design.md。请从任务拆解阶段继续。"
Kimi 会：
- 读取指定的产物文件
- 理解当前进度
- 从下一阶段继续执行
浏览 docs/ 目录下的文件，了解之前的决策和上下文：
# 查看某个功能的所有产物
ls docs/*/*用户头像上传*
# 查看最近的需求分析
ls -t docs/requirements/ | head -5如果需要修改之前的决策，可以回退到对应阶段：
"我发现技术方案中的数据模型有问题，请回到阶段 2。参考文件：
docs/design/2024-03-15-用户头像上传.tech-design.md"
Kimi 会：
- 读取现有技术方案
- 根据你的反馈修改
- 更新产物文件
- 重新进入后续阶段（如需要）
在每个阶段结束时，Kimi 会：
- 展示输出：在对话中展示结构化的阶段产物
- 请求确认：等待你审查和确认
- 保存文件：确认后，将产物保存为标准化的 Markdown 文件
- 传递上下文：将文件路径和内容传递给下一阶段
注意：如果你使用 Kimi Code CLI 的 Skill 系统，Kimi 会自动管理文件的读写。如果你手动使用 Skill，需要确保产物文件保存在正确的位置。
任何阶段都可以向前或向后跳转：
"回到阶段 2，我需要修改数据模型设计"
"跳过设计阶段，直接编码这个简单修复"
"并行实现 T-02 和 T-03，它们没有依赖"
对于估计 <1 小时的简单需求，编排器会自动跳过阶段 2 和 3，直接进入编码。
代码审查可以指定关注领域：
"只审查安全性"
"重点关注性能问题"
"检查是否遵循了设计文档"
每个阶段的 references/output-template.md 包含示例输出格式。你可以：
- 修改模板以匹配团队现有的文档规范
- 添加公司特定的字段（如合规要求、内部系统名称）
编辑各阶段 SKILL.md 底部的质量检查清单，添加团队特有的规范要求。
在 design-tech-solution 和 coding 的参考文档中，可以补充：
- 内部框架的使用模式
- 私有 npm/Gradle/Maven 仓库配置
- 内部 CI/CD 流水线要求
Q: Skill 没有触发怎么办？
A: 确保 Skill 文件放在正确的目录（~/.config/agents/skills/ 或 ~/.kimi/skills/）。检查 SKILL.md 顶部的 description 是否包含你使用的关键词。
Q: 可以只使用其中几个 Skill 吗？
A: 可以。每个 Skill 都是独立自包含的，按需使用即可。
Q: 如何备份这些 Skill？
A: 直接备份 ~/.config/agents/skills/ 目录，或复制预打包的 .skill 文件。
建议在实际项目中使用本工作流，根据团队反馈迭代优化：
- 使用 Skill 处理真实需求
- 记录 Kimi 在哪些环节表现不足
- 调整对应 Skill 的
SKILL.md或参考文档 - 重新打包并测试
本工作流基于 Kimi Code CLI 的 Skill 系统设计，遵循渐进式披露原则，确保上下文窗口高效利用。