Ai Native

---
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 才能真正发挥规模优势
```

**两个铁律**：
1. Phase 0/1 不能纯意图驱动——AI 没素材可推
2. Phase 2 不能跳过——没有质量契约，Phase 3 Agent Team 并行会崩

## 2. 领域特化接口

创建派生工作流时，需在以下维度做领域特化。参照 [`ai-native-code`](https://github.com/tianji-qingtian/AI-Native-Code) 的 SKILL.md 作为完整示例。

| 骨架概念 | 软件开发（ai-native-code） | 写作 | 设计 | 研究 |
|---------|--------------------------|------|------|------|
| 产出物 | 代码 + 测试 | 章节 + 大纲 | 设计稿 + 组件库 | 论文 + 数据 |
| 质量契约 | mypy/pytest/linter | 风格/情节/字数检查 | 设计系统/无障碍检查 | 引用/数据溯源 |
| Agent 类型 | 编码/测试/架构 | 创作/编辑/审校 | 布局/组件/审校 | 检索/分析/审校 |
| Batch 粒度 | 功能模块 | 章节/卷 | 页面/组件组 | 章节/实验 |
| 证据通道 | 埋点/日志/指标 | 读者数据/完读率 | 用户测试/评审 | 引用/同行评议 |

## 3. 如何派生领域特定工作流

本 skill 提供了创建新 AI-native 工作流 skill 的完整流程。以下各节（§4-§9）是**通用骨架的参考实现**——创建领域特定 skill 时，以此为模板，将领域特定的内容替换进去。

### 3.1 创建流程

1. **确定领域**：明确要服务的领域（如写作、设计、研究、数据分析等）
2. **定义领域特化接口**（§2）：填写上表中的对应列——产出物、质量契约、Agent 类型、Batch 粒度
3. **取模板**：从本 skill 的 `assets/starter-templates/` 拷贝项目模板文件，替换 `<...>` 占位符
4. **写 SKILL.md**：参照 §4-§9 的结构，用领域特定的工具、术语、示例替换软件开发相关内容。完整示例见 [`ai-native-code`](https://github.com/tianji-qingtian/AI-Native-Code) 的 SKILL.md
5. **写 starter 模板**：`assets/starter-templates/` 下的 CLAUDE.md、EXECUTION.md、docs/ 等文件需做领域适配（如写作领域将 `03-data-model.md` 替换为 `03-quality-contract.md`）
6. **测试**：用 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。**

**工作流**：
1. 用户用自然语言描述愿景（5-15 句话）
2. Claude 走强制反问 ≥ 1 轮：
   - "你为什么需要这个？市面上没有同类东西吗？"
   - "什么场景下会用？什么场景下不会用？"
   - "如果不做，用户/受众怎么解决同一问题？"
   - "如果只能做 1 件事，是哪件？"
3. 反问后起草 ≤ 5 条顶层意图，填入 `docs/01-vision.md`
4. 用户审 / 改 / 砍 / 合并，定稿

**顶层意图格式**（不是任务清单，是可证伪的成功假设）：

| ❌ 任务式 | ✅ 意图式 |
|----------|----------|
| "写一本玄幻小说" | "读者能从第一章追读到结局，中途弃书率 < 30%" |
| "做一个品牌 VI 系统" | "新设计师只看 VI 手册就能独立产出风格一致的物料" |
| "拍一支产品宣传片" | "目标受众看完后品牌记忆度提升 ≥ 20%" |

**完成判定**：≤ 5 条顶层意图 + 每条都能用客观指标验证。

**输出文件**：`docs/01-vision.md`（从 assets/starter-templates/docs/01-vision.md 模板创建）

### Phase 1 · 契约骨架

**Claude 角色**：起草者。**必须传统范式——人类主笔、AI 起草框架、人类填理由。**

**输出文件清单**（全部从 assets/starter-templates/ 拷贝模板后填入）：

1. **`CLAUDE.md`**：项目纪律权威源。含硬约束（每条指向决策记录）、协作模式、工具链、规划范式
2. **`EXECUTION.md`**：续跑剧本。新会话第一件事读这个
3. **`docs/02-architecture.md`**：项目架构（≤ 1 屏，≤ 5 个核心模块）
4. **`docs/03-quality-contract.md`**：质量契约初版——领域特定的验证标准与工具
5. **`docs/execution/DECISIONS.md`**：≥ 5 条初始决策记录。每个不可逆决策必有一条
6. **`docs/execution/AGENT-PROMPTS.md`**：子代理 prompt 模板

**工作流**：
1. 逐一询问工具链/方法论选型（根据领域不同），每项列 2-3 个选项让用户拍板
2. 每个不可逆决策写入 DECISIONS.md
3. 起草项目架构图（ASCII 或 Mermaid）
4. 填 CLAUDE.md 硬约束段——每条指向决策记录编号
5. 用户逐文件审定

**完成判定**：
- CLAUDE.md 已含项目硬约束
- DECISIONS.md ≥ 5 条决策记录
- 任何新会话读 CLAUDE.md + EXECUTION.md 能 5 分钟入门

### Phase 2 · 核心产出 + 质量契约网络

**前提**：Phase 1 全部定稿。

**工作流**：
1. 拆 ≤ 10 个 Batch，写入 `docs/execution/PROGRESS.md`
2. 每个 Batch 创建 `docs/execution/BATCH-XX-<name>.md`（从 BATCH-template.md 模板）
3. 按依赖顺序执行 Batch，每个 Batch：
   - 用户审任务书 → 派 Agent Team 执行 → 跑质量检查 → 人类验收 → 更新 PROGRESS.md
4. 质量契约配置与产出物同步建（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 角色**：考古者。**只列事实，不写"为什么"。**

**工作流**：
1. **扫描项目**：派 agent 扫描项目结构，输出：模块划分 / 核心产出物清单 / 依赖关系 / 主要工作流 / 质量现状。只列事实。
2. **创建 PROJECT-MAP.md**：将扫描结果整理为 `docs/execution/PROJECT-MAP.md`，每个核心模块一段，留出"人类批注"空位
3. **人类逐段标注**：逐段问：
   - "这个模块是核心还是辅助？"
   - "有没有历史原因不能动？"
   - "哪些是已知债？哪些是死资产？"
4. **隐性约束入决策记录**：人类标注中每条"不能动的原因"写入 DECISIONS.md

**输出**：`docs/execution/PROJECT-MAP.md` + ≥ 5 条隐性约束决策记录

**关键风险**：AI 容易把"冗余/过度设计"当"待简化目标"。**人类标注不可省。**

### Phase 1 · 反推意图

**目标**：从现有资产反推意图，发现"资产有但没意图"的僵尸和"意图有但资产弱"的弱点。

**工作流**：
1. 基于 PROJECT-MAP，AI 起草反推意图清单（≤ 10 条），每条标类型：🟢 对齐 / 🟡 资产有但没意图（疑似僵尸）/ 🔴 意图有但资产弱（弱点）
2. 用户逐条审
3. 定稿入 `docs/execution/INTENT-GRAPH.md`，**状态全部 pending**——证据通道等 Phase 2 质量网建好

### Phase 2 · 建质量契约网络

**这是最不能省的阶段。跳过会出大事故。**

**核心原则**：只补核心路径，不全量覆盖。

**工作流**（按顺序，不要并行跳步）：
1. **先配工具**：加领域特定的质量检查工具，先设宽松规则
2. **补核心路径基线检查**（并行度 2-3）：从核心链路开始补
3. **起草追溯决策记录**：基于历史变更，AI 起草决策草稿，**人类审定后**入 DECISIONS.md
4. **收紧质量门**：逐步提高严格度

**完成判定**：
- 核心路径有基线质量检查
- 质量契约全部通过
- 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/`。创建项目文件时：

1. 读取对应模板文件
2. 替换所有 `<...>` 占位符为项目实际内容
3. 删掉模板中的"例："参考段落
4. 不要原样拷贝——根据项目实际情况裁剪

### 模板索引

| 模板文件 | 用途 | 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 时：

1. 读 CLAUDE.md（项目纪律）
2. 读 EXECUTION.md（续跑剧本）
3. 读 docs/execution/PROGRESS.md（找下一个 pending Batch）
4. 读 docs/execution/DECISIONS.md（已定决策）
5. 读对应 BATCH-XX-*.md（任务详情）
6. 执行 → 质量检查 → 验收 → 更新 PROGRESS.md

**不要擅自跳批、不要重新规划路线图、不要改 docs/0X-*.md（默认只读）。**

---

## 11. 参考实现

- **[AI-Native-Code](https://github.com/tianji-qingtian/AI-Native-Code)**：软件开发特化版。以 mypy/pytest/importlinter 为质量契约，以编码/测试/架构为 Agent 类型。推荐作为派生新领域工作流时的完整参考。