| name | ai-native |
| description | AI-Native 工作流的元框架——用于创建和管理领域特定的 AI-native 工作流 skill（如 AI-Native-Code、AI-Native-Write）。 触发场景：用户说"创建 AI-native 工作流"、"派生领域工作流"、"定制质量契约"、 "做个像 AI-Native-Code 那样的工作流"、"我要给XX领域做一套 AI-native 方法论"、 "AI-native"、"意图凝练"、"契约骨架"、"INTENT-GRAPH"、"意图卡"、"Batch"、 "Agent Team"、"Phase 0/1/2/3"、"顶层意图"、"决策记录"、"反推意图"、 "质量契约"、"多 Agent 并行"、"项目纪律"、"续跑剧本"。 此 skill 是元框架，不是直接引导项目执行的终端 skill。
|
AI-Native 工作流元框架
用 Claude Code 作为主力工具的元框架——用于创建领域特定的 AI-native 工作流 skill。
核心定位与 skill-creator 类似，但专注于一个细分维度：创建带有 4-Phase 框架、质量契约网络、INTENT-GRAPH 和 Agent Team 规范的领域工作流 skill。
这是什么 / 不是什么
| 这是什么 | 这不是什么 |
|---|
| 创建领域工作流 skill 的元框架 | 直接引导项目执行的终端 skill |
| 提供 4-Phase 骨架 + 可替换的领域模块 | 开箱即用的项目启动器 |
| 帮助用户派生自己的 AI-native-xxx 工作流 | 代替用户执行 Phase 0/1/2/3 |
类比：如果 skill-creator 是"创建 skill 的 skill"，那么 ai-native 就是"创建 AI-native 工作流 skill 的 skill"。终端用户不会直接使用 ai-native 启动项目——他们会用 ai-native-code、ai-native-write 等派生 skill。
0. 责任分工铁律
任何阶段下，这张表不可违反。把人类的事委托给 AI 是这套方法论失败的最大原因。
| 工作 | 谁做 | AI 能替代？ |
|---|
| 商业判断 / 用户访谈 | 人类 | ❌ |
| 顶层意图定义 | 人类（AI 可起草，人类定稿） | ❌ |
| 不可逆决策（方向/约束） | 人类（AI 列选项，人类拍板） | ❌ |
| 验收（"AI 报告全绿 ≠ 真的对"） | 人类 | ❌ |
| Batch 任务书起草 | AI 起草 + 人类审 | ✅ |
| 单 Batch 内任务执行 | AI（Agent Team） | ✅ |
| 质量契约守门 | 工具自动化 | ✅ |
| 决策溯源（DECISIONS.md） | AI 起草 + 人类审 | ✅ |
1. 4-Phase 骨架（不可变）
这是所有领域特定工作流共享的骨架结构。派生工作流时，Phase 名称和顺序不变，但每个 Phase 内的工具、产出物、Agent 类型按领域替换。
Phase 0 上下文凝练 人类主笔 + AI 反问
│ 空项目 → 顶层意图（前瞻 ≤ 5 条）
│ 已有项目 → 项目考古（回顾）
▼
Phase 1 契约骨架 传统规格 + 决策记录
│ 空项目 → 领域架构 / 工具链 / 质量契约初版
│ 已有项目 → 反推意图 + 隐性约束显性化
▼
Phase 2 质量契约网络 领域特定的自动化验证体系
│ 这是真相源，所有后续工作的安全网
▼
Phase 3 意图驱动 INTENT-GRAPH + Agent Team
此时 AI 才能真正发挥规模优势
两个铁律：
- Phase 0/1 不能纯意图驱动——AI 没素材可推
- Phase 2 不能跳过——没有质量契约，Phase 3 Agent Team 并行会崩
2. 领域特化接口
创建派生工作流时，需在以下维度做领域特化。参照 ai-native-code 的 SKILL.md 作为完整示例。
| 骨架概念 | 软件开发（ai-native-code） | 写作 | 设计 | 研究 |
|---|
| 产出物 | 代码 + 测试 | 章节 + 大纲 | 设计稿 + 组件库 | 论文 + 数据 |
| 质量契约 | mypy/pytest/linter | 风格/情节/字数检查 | 设计系统/无障碍检查 | 引用/数据溯源 |
| Agent 类型 | 编码/测试/架构 | 创作/编辑/审校 | 布局/组件/审校 | 检索/分析/审校 |
| Batch 粒度 | 功能模块 | 章节/卷 | 页面/组件组 | 章节/实验 |
| 证据通道 | 埋点/日志/指标 | 读者数据/完读率 | 用户测试/评审 | 引用/同行评议 |
3. 如何派生领域特定工作流
本 skill 提供了创建新 AI-native 工作流 skill 的完整流程。以下各节（§4-§9）是通用骨架的参考实现——创建领域特定 skill 时，以此为模板，将领域特定的内容替换进去。
3.1 创建流程
- 确定领域：明确要服务的领域（如写作、设计、研究、数据分析等）
- 定义领域特化接口（§2）：填写上表中的对应列——产出物、质量契约、Agent 类型、Batch 粒度
- 取模板：从本 skill 的
assets/starter-templates/ 拷贝项目模板文件，替换 <...> 占位符
- 写 SKILL.md：参照 §4-§9 的结构，用领域特定的工具、术语、示例替换软件开发相关内容。完整示例见
ai-native-code 的 SKILL.md
- 写 starter 模板：
assets/starter-templates/ 下的 CLAUDE.md、EXECUTION.md、docs/ 等文件需做领域适配（如写作领域将 03-data-model.md 替换为 03-quality-contract.md）
- 测试：用 2-3 个典型场景跑一遍，确认 skill 能正确引导用户走 Phase 0-3
3.2 命名规范
- 仓库名：
AI-Native-<Domain>（如 AI-Native-Code）
- Skill 名：
ai-native-<domain>（如 ai-native-code）
- 方法论文件名：
AI-Native-<领域>方法论.md
4. 场景 A：空项目（参考实现）
以下是在软件开发领域的参考实现。创建其他领域的 skill 时，按同样结构替换领域内容。
Phase 0 · 意图凝练
目标：把自然语言愿景凝练为 ≤ 5 条可证伪的顶层意图。
Claude 角色：反问者 + 起草者。不要直接执行，不要启用 Agent Team。
工作流：
- 用户用自然语言描述愿景（5-15 句话）
- Claude 走强制反问 ≥ 1 轮：
- "你为什么需要这个？市面上没有同类东西吗？"
- "什么场景下会用？什么场景下不会用？"
- "如果不做，用户/受众怎么解决同一问题？"
- "如果只能做 1 件事，是哪件？"
- 反问后起草 ≤ 5 条顶层意图，填入
docs/01-vision.md
- 用户审 / 改 / 砍 / 合并，定稿
顶层意图格式（不是任务清单，是可证伪的成功假设）：
| ❌ 任务式 | ✅ 意图式 |
|---|
| "写一本玄幻小说" | "读者能从第一章追读到结局，中途弃书率 < 30%" |
| "做一个品牌 VI 系统" | "新设计师只看 VI 手册就能独立产出风格一致的物料" |
| "拍一支产品宣传片" | "目标受众看完后品牌记忆度提升 ≥ 20%" |
完成判定：≤ 5 条顶层意图 + 每条都能用客观指标验证。
输出文件：docs/01-vision.md（从 assets/starter-templates/docs/01-vision.md 模板创建）
Phase 1 · 契约骨架
Claude 角色：起草者。必须传统范式——人类主笔、AI 起草框架、人类填理由。
输出文件清单（全部从 assets/starter-templates/ 拷贝模板后填入）：
CLAUDE.md：项目纪律权威源。含硬约束（每条指向决策记录）、协作模式、工具链、规划范式EXECUTION.md：续跑剧本。新会话第一件事读这个docs/02-architecture.md：项目架构（≤ 1 屏，≤ 5 个核心模块）docs/03-quality-contract.md：质量契约初版——领域特定的验证标准与工具docs/execution/DECISIONS.md：≥ 5 条初始决策记录。每个不可逆决策必有一条docs/execution/AGENT-PROMPTS.md：子代理 prompt 模板
工作流：
- 逐一询问工具链/方法论选型（根据领域不同），每项列 2-3 个选项让用户拍板
- 每个不可逆决策写入 DECISIONS.md
- 起草项目架构图（ASCII 或 Mermaid）
- 填 CLAUDE.md 硬约束段——每条指向决策记录编号
- 用户逐文件审定
完成判定：
- CLAUDE.md 已含项目硬约束
- DECISIONS.md ≥ 5 条决策记录
- 任何新会话读 CLAUDE.md + EXECUTION.md 能 5 分钟入门
Phase 2 · 核心产出 + 质量契约网络
前提：Phase 1 全部定稿。
工作流：
- 拆 ≤ 10 个 Batch，写入
docs/execution/PROGRESS.md
- 每个 Batch 创建
docs/execution/BATCH-XX-<name>.md（从 BATCH-template.md 模板）
- 按依赖顺序执行 Batch，每个 Batch：
- 用户审任务书 → 派 Agent Team 执行 → 跑质量检查 → 人类验收 → 更新 PROGRESS.md
- 质量契约配置与产出物同步建（Phase 1 就配好，每 Batch 验证）
Batch 拆分原则：
- ≤ 10 个 Batch
- 每个 Batch 验收的是"哪条顶层意图变得可验证"，不是任务清单
- 严格依赖顺序
INTENT-GRAPH 此时不启用——它是 Phase 3 工具。
完成判定：
- 顶层意图至少 1 条可验证
- 质量契约全部通过
- DECISIONS.md 已记录所有 Batch 内的非平凡决策
Phase 3 · 意图驱动（永续）
触发条件：核心链路真跑通，开始有真实使用者/受众。
此时 INTENT-GRAPH 才发力：
- 用户问"X 要不要做" → 不要直接开 Batch，先看 INTENT-GRAPH 有无对应意图卡
- 有则评估证据，无则先写成意图卡
- 意图卡走状态机：
pending → probing → validated → implemented（或被 falsified）
意图卡字段强制清单：
### Intent #NNN · <一句话标题>
**假设**：<我们相信什么>
**对应规格差异**：<docs/0X 引用，或"无对应——新意图">
**当前替代**：<不实施时用户怎么完成>
**证据触发条件**：<可观测条目>
**证伪条件**：<可观测条目>
**实施空间**：<极简 / 中量 / 重量>
**默认状态**：pending | probing
关键纪律：
- 核心产出落地前不写意图卡（会变空想）
- active 意图 ≤ 12 条（超出强制合并 / falsify）
- 证伪条件必须可观测
- 禁止主观词（"用户体验差"→ 改成可观测指标）
- user override 是紧急通道，不是默认（窗口内比例 > 50% 视为范式失败）
5. 场景 B：已有资产（参考实现）
比空项目复杂：现有产出物里有未文档化的隐性约束，已有规格可能脱节，团队有既定工作流。
Phase 0 · 考古
Claude 角色：考古者。只列事实，不写"为什么"。
工作流：
- 扫描项目：派 agent 扫描项目结构，输出：模块划分 / 核心产出物清单 / 依赖关系 / 主要工作流 / 质量现状。只列事实。
- 创建 PROJECT-MAP.md：将扫描结果整理为
docs/execution/PROJECT-MAP.md，每个核心模块一段，留出"人类批注"空位
- 人类逐段标注：逐段问：
- "这个模块是核心还是辅助？"
- "有没有历史原因不能动？"
- "哪些是已知债？哪些是死资产？"
- 隐性约束入决策记录：人类标注中每条"不能动的原因"写入 DECISIONS.md
输出：docs/execution/PROJECT-MAP.md + ≥ 5 条隐性约束决策记录
关键风险：AI 容易把"冗余/过度设计"当"待简化目标"。人类标注不可省。
Phase 1 · 反推意图
目标：从现有资产反推意图，发现"资产有但没意图"的僵尸和"意图有但资产弱"的弱点。
工作流：
- 基于 PROJECT-MAP，AI 起草反推意图清单（≤ 10 条），每条标类型：🟢 对齐 / 🟡 资产有但没意图（疑似僵尸）/ 🔴 意图有但资产弱（弱点）
- 用户逐条审
- 定稿入
docs/execution/INTENT-GRAPH.md，状态全部 pending——证据通道等 Phase 2 质量网建好
Phase 2 · 建质量契约网络
这是最不能省的阶段。跳过会出大事故。
核心原则：只补核心路径，不全量覆盖。
工作流（按顺序，不要并行跳步）：
- 先配工具：加领域特定的质量检查工具，先设宽松规则
- 补核心路径基线检查（并行度 2-3）：从核心链路开始补
- 起草追溯决策记录：基于历史变更，AI 起草决策草稿，人类审定后入 DECISIONS.md
- 收紧质量门：逐步提高严格度
完成判定：
- 核心路径有基线质量检查
- 质量契约全部通过
- DECISIONS.md ≥ 10 条追溯决策记录
Phase 3 · 增量挂意图（永续）
规则：
- 所有新需求 / 改动强制挂意图卡
- 已有资产维持现状——直到有人触碰时才反向补意图
- Agent Team 并行度低（2-3 + 互相 review）
- 每次改动派独立 agent 做反向核验
- 每个改动必须报告"动了哪些已有约束"
6. Agent Team 使用规范
何时开 Agent Team
应该开：跨模块执行、可并行的独立工作、多步骤任务（研究→规划→执行→校验）、≥ 2 个独立子任务
不应该开：单任务小改、纯查询/探索、Phase 0/Phase 1、Phase 2 质量契约未建好的已有项目
并行度选择
| 项目类型 | 推荐并行度 | 理由 |
|---|
| 空项目 Phase 2 核心链路 | 3-5 | 有质量网兜底 |
| 空项目 Phase 3 实施意图卡 | 3-5 | 同上 |
| 空项目高度独立子任务 | 5-9 | 任务间零依赖 |
| 已有项目 Phase 2 建质量契约 | 2-3 | 没有兜底 |
| 已有项目 Phase 3 改已有资产 | 1-2 + review agent | 隐性约束风险大 |
命名一致性（多 Agent 并行时最关键）
- 启动前先查现有产出物看相关概念是否已有命名/风格
- 复用已有约定；不要起新名/新风格
- 跨 agent 共享术语必须先出现在 DECISIONS.md 中
- 合并前与同 Batch 其他 agent 的产出做 diff
7. 反模式速查（绝对不要）
| 反模式 | 后果 |
|---|
| 让 AI 扫一下自动生成完整规格 | 充满想象的虚假规格 |
| Phase 0 就启用 INTENT-GRAPH | 空想意图 |
| 跳过决策记录 | 隐性决策必死 |
| 没有质量契约就开 Agent Team 大改 | 看似对实际崩 |
| 把项目纪律写进 ~/.claude/projects/.../memory/ | 拷贝丢失 |
| 让单一 Agent 跨多 Batch 上下文连续工作 | 上下文爆炸 |
| 不验收就采纳 AI 产出 | "AI 报告全绿"≠"真的对" |
| 证伪条件用主观词 | 永远证伪不掉 |
| Phase 0/1 纯意图驱动 | AI 没素材可推，写出空想 |
| 已有项目跳过 Phase 2 直接大改 | 隐性约束被破坏，且无回滚锚点 |
8. 模板文件使用
所有模板位于 assets/starter-templates/。创建项目文件时：
- 读取对应模板文件
- 替换所有
<...> 占位符为项目实际内容
- 删掉模板中的"例："参考段落
- 不要原样拷贝——根据项目实际情况裁剪
模板索引
| 模板文件 | 用途 | Phase |
|---|
CLAUDE.md | 项目纪律权威源 | Phase 1 |
EXECUTION.md | 续跑剧本 | Phase 1 |
docs/01-vision.md | 顶层意图 | Phase 0 |
docs/02-architecture.md | 项目架构 | Phase 1 |
docs/03-quality-contract.md | 质量契约（领域特定） | Phase 1 |
docs/execution/PROGRESS.md | 进度看板 | Phase 2 |
docs/execution/DECISIONS.md | 决策日志 | Phase 1 |
docs/execution/INTENT-GRAPH.md | 意图图谱（Phase 3 启用） | Phase 3 |
docs/execution/AGENT-PROMPTS.md | 子代理 prompt 模板 | Phase 1 |
docs/execution/BATCH-template.md | 单 Batch 任务书 | Phase 2 |
9. 现实预期
真实加速幅度（不要吹 10x）：
- 空项目核心产出：30-50% 加速
- 已有项目改造：10-30% 加速（隐性约束风险吃掉部分增益）
- 重复模式（模板化、标准化流程）：50-80% 加速
- 创新性工作（方向判断/创意突破/质量判断）：~0% 加速，AI 是辅助
任何声称"AI 让你 10x 速度"的都没把 Phase 0/1/2 算进去。
10. 派生工作流的执行入口
当用户使用派生工作流 skill（如 ai-native-code）说"继续"或被要求执行具体 Batch 时：
- 读 CLAUDE.md（项目纪律）
- 读 EXECUTION.md（续跑剧本）
- 读 docs/execution/PROGRESS.md（找下一个 pending Batch）
- 读 docs/execution/DECISIONS.md（已定决策）
- 读对应 BATCH-XX-*.md（任务详情）
- 执行 → 质量检查 → 验收 → 更新 PROGRESS.md
不要擅自跳批、不要重新规划路线图、不要改 docs/0X-*.md（默认只读）。
11. 参考实现
- AI-Native-Code：软件开发特化版。以 mypy/pytest/importlinter 为质量契约，以编码/测试/架构为 Agent 类型。推荐作为派生新领域工作流时的完整参考。
