Answer

answer — AI Native'S Workflow(er)

answer = AI Native'S Workflow(er)

拆解这个名字：

A I Native' S Workflow( ER )
└─┘ └───┘└─┘ └────┘└───┘
A N S W ER

• answer（答案）—— 给你结构化找到答案的路径
• AI Native'S Workflow(er)（AI 原生的 工作流者）—— 赋予 AI 结构化思考的能力

以 design-flow 编排范式为核心，将 grill-me / design-brief / information-architecture / design-tokens / brief-to-tasks / design-review 的方法论内化，适配到新业务构建、新技能创建、新方案规划等通用领域。

触发条件

通用领域触发矩阵

7阶段工作流覆盖9大业务领域，45个子场景。

AI / 技术产品

数字产品 / SaaS

业务流程 / 运营

市场营销 / 品牌

商业策略 / 创业

技能/工具创建

调研分析

复盘/汇报

内容/创作

自动触发场景（按置信度分层）

Tier 1 — 显式调用（100% 触发）：

• "answer this" / "用 answer" / "workflow this"
• "AI 原生工作流" / "帮我厘清" / "结构化规划"

Tier 2 — 高置信度场景（触发，并告知用户已加载 answer）：

Tier 3 — 上下文触发（结合复杂度判断）：

• "帮我分析一下" — 如果话题涉及多步骤决策 → 触发 answer
• "帮我梳理" — 如果内容涉及多个模块/阶段 → 触发 answer
• "拆解" — 如果问题有多个子问题 → 触发 answer
• "评估" — 如果有多个方案需要对比 → 触发 answer
• "不知道怎么开始" — 任何不够清晰的任务 → 触发 answer
• "盘一下" / "捋一下" / "理一理" / "过一遍" — 口语化梳理请求 → 触发 answer
• "plan this" / "design this" / "think this through" — 英文等价请求 → 触发 answer

不触发 answer 的场景（直接处理，不走工作流）：

• 单一事实查询（"今天天气怎么样"）
• 已有明确答案的问题（"这段代码哪里错了"）
• 简单操作（"帮我发个消息"、"打开XX文件"）
• 已有成熟方案的重复性任务（"按上次的流程再做一次"）

领域自动识别（扩展版）

根据用户描述自动判断最佳匹配领域。判断优先级如下：

匹配规则：

1. 多个关键词命中时，取优先级最高的领域（技能 > 业务 > 方案 > 流程 > 分析 > 决策）
2. 无法明确判断时，默认使用「新方案」模板，并询问用户确认领域
3. 用户可随时覆盖自动判断（"不，这不是技能，是方案"）

🔴 CHECKPOINT：领域识别完成后，向用户确认——"识别为 {领域标签}，走对应的 7 阶段追问流程。正确吗？" 确认后再进入 Phase 1。

领域覆盖后：自动加载 references/domain-mapping.md 中对应领域的追问清单和模板变体。

⛔ 设计先行门禁（Design-First Gate）

吸收自: obra/superpowers brainstorming v6.1.1

Anti-Pattern: "这个太简单不需要设计"

每个项目都走这个流程。Todo List、单功能工具、配置更改——全都要。"简单"项目是未经检验的假设造成最多浪费的地方。设计可以很短（真正简单的项目几句话），但必须呈现并获批准。

设计门禁检查清单

在进入任何 Phase 6 Build 之前，必须全部完成：

1. ✅ 问题已被理解和重构
2. ✅ 至少 2-3 种方案已被探讨，有取舍
3. ✅ 推荐方案已呈现并获用户批准
4. ✅ 设计范围已明确（包含什么、不包含什么）
5. ✅ 成功标准已定义且可验证

Red Flags — 你正在跳过设计

所有这些都是 STOP 信号——先设计，再构建。

设计门禁与 7 阶段的映射

answer 的 Phase 1 Clarify 和 Phase 2 Brief 本身就是设计门禁的实现。但以下是增强点：

• Phase 1 Clarify 必须完成决策树的完整遍历——不在未验证的假设上前进
• Phase 2 Brief 必须包含 ≥2 个被探索和拒绝的替代方案（不只是推荐方案）
• Phase 3 Architect 之前必须有用户对 Brief 的显式批准
• Phase 5 Decompose → Phase 6 Build 的门禁是最关键的：除非设计方案已批准，绝不进入 Build

digraph design_gate {
    "用户需求" [shape=ellipse];
    "Phase 1: Clarify\n(决策树遍历)" [shape=box];
    "Phase 2: Brief\n(含替代方案对比)" [shape=box];
    "设计方案已批准？" [shape=diamond];
    "Phase 3-5\n(架构→标准→拆解)" [shape=box];
    "Build Gate\n(设计已完整批准？)" [shape=diamond];
    "Phase 6: Build\n(实现)" [shape=box];
    "回到设计阶段" [shape=box style=filled fillcolor=#ffcccc];

    "用户需求" -> "Phase 1: Clarify\n(决策树遍历)";
    "Phase 1: Clarify\n(决策树遍历)" -> "Phase 2: Brief\n(含替代方案对比)";
    "Phase 2: Brief\n(含替代方案对比)" -> "设计方案已批准？";
    "设计方案已批准？" -> "Phase 3-5\n(架构→标准→拆解)" [label="yes"];
    "设计方案已批准？" -> "回到设计阶段" [label="no"];
    "Phase 3-5\n(架构→标准→拆解)" -> "Build Gate\n(设计已完整批准？)";
    "Build Gate\n(设计已完整批准？)" -> "Phase 6: Build\n(实现)" [label="yes"];
    "Build Gate\n(设计已完整批准？)" -> "回到设计阶段" [label="no"];
}

7 阶段编排序列

1. Clarify    → 决策树遍历，追问到底（grill-me 方法论）     🔴 CHECKPOINT → 🛑 STOP
2. Brief      → 结构化简报，记录意图/目标/约束（design-brief 方法论）  🔴 CHECKPOINT → 🛑 STOP
3. Architect  → 定义结构/层次/关系/流程（information-architecture 方法论） 🔴 CHECKPOINT → 🛑 STOP
4. Standards  → 建立可复用标准/模式/规范（design-tokens 方法论）   🔴 CHECKPOINT → 🛑 STOP
5. Decompose  → 拆解为独立可验证的增量任务（brief-to-tasks 方法论）  🔴 CHECKPOINT → 🛑 STOP
6. Build      → 按任务逐步构建交付物                     🔴 CHECKPOINT（任务完成即验证）
7. Review     → 对照简报逐项检查（design-review + blue-team 方法论）

编排规则

1. 开始前：告知完整 7 阶段序列，询问是否跳过某些阶段（常见跳过的：已有清晰思路可跳过 Clarify；单一产出可跳过 Architect）
2. 每阶段前：宣布进入哪个阶段、产出什么、确认是否继续
3. 每阶段后：总结产出（文件名、关键决策、开放问题），询问「进入下一阶段？」
4. 阶段间检查：前一阶段的输出是否影响下一阶段？（如 Brief 中的领域设定会影响 Standards 的规范模板）
5. 可随时暂停：用户说"够了"即停止，总结当前进度和下一步
6. 活文档纪律：{answername}_工作流全记录 是活文档（Living Document）——Phase 3 的关键架构决策、Phase 6 的意外发现和决策记录、Phase 7 的成果回顾，都必须持续更新到文档中。进度、决策、发现全在一处，确保跨会话中断后可从文档恢复。

产出目录

所有产出创建为飞书在线文档，归档到 Wiki 节点 J4EewYIT2ieFuwkRWbxcgWbFnhe（AI Native 工作流）下。

默认模式：合并文档（用户偏好）。Phase 1-5 合并为单一飞书文档 {answername}_工作流全记录，各阶段作为一级章节。Phase 6 Build 产出最终交付物（方案文档/报告等），Phase 7 Review 追加到工作流记录文档末尾。

J4EewYIT2ieFuwkRWbxcgWbFnhe (AI Native 工作流)
└── {answername}_工作流全记录        ← Phase 1-5 合并 + Phase 7 Review 追加
    ├── # Phase 1: Clarify
    ├── # Phase 2: Brief
    ├── # Phase 3: Architect
    ├── # Phase 4: Standards
    ├── # Phase 5: Decompose
    └── # Phase 7: Review
└── {最终交付物}                     ← Phase 6 Build 产出（方案文档/报告等）

分文档模式（仅在用户明确要求时使用）——每阶段独立文档：

J4EewYIT2ieFuwkRWbxcgWbFnhe (AI Native 工作流)
└── {answername}/
    ├── CLARIFY_{answername}
    ├── BRIEF_{answername}
    ├── ARCHITECTURE_{answername}
    ├── STANDARDS_{answername}
    ├── TASKS_{answername}
    ├── BUILD_LOG_{answername}
    └── REVIEW_{answername}

注意：Phase 1-5 产出完成后，如果用户要求合并已有文档，使用 lark-cli wiki +node-delete --node-token TOKEN --obj-type wiki --yes 删除分散文档（注意 --obj-type wiki 而非 docx），创建合并文档后重新写入。

创建文档方法：必须使用 v2 API 一步法。禁止两步法（Wiki API 建节点 + docs update 写内容）——该模式在 lark-cli v1.0.40–v1.0.44 上返回 ok:true 但文档永远为空。

# ✅ 一步法（唯一可靠方式）
# ⚠️ lark-cli v1.0.53+ 已废弃 --title：标题必须以 <title>Title</title> 写入 content
# ⚠️ @file 只接受 cwd 下的相对路径（绝对路径如 @/tmp/x.md 报 unsafe file path）
cat > ./_content.md << 'ENDOFFILE'
<title>{文档标题}</title>

{markdown 内容}
ENDOFFILE

lark-cli docs +create --api-version v2 --doc-format markdown \
  --content @_content.md \
  --parent-token {parent_node_token} --as bot

写入后校验：

lark-cli docs +fetch --api-version v2 --doc {document_id} --as bot
# 确认 revision_id > 1 且 blocks 数 > 0

阶段详情

Phase 1: Clarify（决策树遍历）

来源：grill-me — 无死角追问，逼出所有设计决策

目标：在动手之前，遍历决策树的每一个分支，确保所有前提假设都被显式化。

方法：

1. 从用户初始描述中提取关键决策点，展开为决策树
2. 逐分支追问，每个追问提供推荐答案
3. 用代码库/数据源探索替代提问（能查到的不要问）
4. 追问维度（按领域适配）：

完整的 6 领域追问清单（含 🔄流程/SOP、🔍分析/调研、🎯决策支持）见 references/domain-mapping.md，Clarify 阶段会自动加载对应领域的追问模板。

产出：CLARIFY_{answername}.md — 决策树记录、关键决策、开放问题

模板：

# Clarify: {answername}

## 决策树
### Q1: {核心问题}
- 推荐答案：{recommendation}
- 用户选择：{answer}
- 影响的分支：{downstream decisions}

### Q2: ...
...

## 关键决策摘要
1. {decision 1}
2. {decision 2}

## 仍开放的追问
- {open question 1}（将在 Phase 2 Brief 中作为假设记录，或在后续阶段回答）

**处理开放问题**：无法在此阶段回答的开放问题，记录到 Brief 的「待验证假设」字段中，供后续阶段引用。

🔴 **CHECKPOINT**：确认决策树已遍历完毕、关键决策已记录，再进入 Phase 2。

过渡语：🛑 "我们已遍历核心决策树。下面把结论沉淀为结构化简报。继续？"

Phase 2: Brief（结构化简报）

来源：design-brief — 交互式访谈 + 代码库探索

目标：将所有澄清结果结构化，产出可被后续阶段引用的单一真源。

方法：

1. 基于 Phase 1 的决策树结果，填充简报模板
2. 探索已有资源（对于技能创建：已有技能文件；对于业务：已有飞书文档/数据）
3. 为每个决策项提供推荐答案

产出：BRIEF_{answername}.md — 结构化简报

模板（领域适配）：

# {领域标签} Brief: {answername}

## 问题定义
{从用户/受众角度描述核心问题，不是技术描述，不是商业指标}

## 目标方案
{这个方案做什么，描述为体验/流程，而非功能列表}

## 核心原则（最多 3 条）
1. **{原则名}** — {实践中的含义，应解决一个张力}
2. ...
3. ...

## 价值主张（JTBD 6-part — 数字产品/服务类项目必填）

> 🆕 借鉴 pm-skills `value-proposition`——用 JTBD 框架定义价值主张，替代空泛的「我们提供XX」。

对每个目标用户群：

| 维度 | 说明 | 示例 |
|------|------|------|
| **Who（谁）** | 目标用户的具体画像 | 「中型企业 IT 经理，每天处理 50+ 审批」 |
| **Why（为什么）** | 他们的痛点/未满足需求 | 「现有工具审批慢、追溯难、跨部门协调靠微信」 |
| **What before（现状）** | 他们现在怎么做的 | 「Excel + 微信 + 邮件三件套，平均每单 3 天」 |
| **How（我们怎么做）** | 我们的解决方式 | 「一站式审批：自动路由 + 移动端秒批 + 全程留痕」 |
| **What after（改善后）** | 使用后的改善结果 | 「审批时间从 3 天 → 2 小时，合规审计秒级响应」 |
| **Alternatives（替代方案）** | 他们现在用什么替代 | 「钉钉审批（但缺乏定制化）、自研系统（维护成本高）」 |

## 产品战略画布（数字产品/SaaS/AI方案类可选）

> 🆕 如果产出是数字产品/SaaS/AI 产品的战略方案，可用 9-section Product Strategy Canvas 替代或补充上面的通用 Brief 模板。
> 
> 9-section: Vision → Market Segments → Relative Costs → Value Propositions → Trade-offs → Key Metrics → Growth → Capabilities → Can't/Won't (Defensibility)
> 
> 详见 `references/product-strategy-canvas.md`。

## 领域约束
- 平台/环境：{已有技能、工具、平台限制}
- 时间/资源：{截止日期、预算、团队}
- 合规/品牌：{必须遵守的规范}

## 成功标准

每条标准必须是可观测的、人类可验证的。格式：「条件 → 操作 → 预期结果」

- **SC-1**：{描述}。验证方法：{具体操作}，预期结果：{可观测输出}
- **SC-2**：{描述}。验证方法：{具体操作}，预期结果：{可观测输出}

> **示例（方案类）**：
> - **SC-1**：方案逻辑无断层。验证方法：蓝军审查 Phase 2 死亡假设全部有应对，预期结果：蓝军报告无 Must Fix
> - **SC-2**：交付物可在 10 分钟内被目标受众理解。验证方法：找 1 名未参与项目的人阅读后复述核心观点，预期结果：复述准确率 ≥ 80%
>
> **示例（技能类）**：
> - **SC-1**：技能可从空状态触发。验证方法：在干净 Hermes 环境中说「触发词」，预期结果：Hermes 加载该技能并开始执行 Phase 1

> 此格式借鉴 execplan 的 Observable Outcomes 方法论——验收标准必须是人类可感知的行为，而非内部属性。

## 已有资产
{可以复用的技能、文档、代码、数据}

## 产出物清单
| 产出物 | 类型 | 接收方 |
|--------|------|--------|
| {output 1} | {doc/deck/skill/html} | {audience} |

## 不做什么
{明确排除的内容，防止范围蔓延}

过渡语：🛑 "简报已结构化。下面我们定义架构——结构、层次、流程。继续？"

Phase 3: Architect（结构设计）

来源：information-architecture — 导航/内容层级/用户流

目标：定义产出物的骨架：模块划分、层级关系、信息流、关键路径。

方法：

1. 基于 Brief 中的产出物清单，逐项设计结构
2. 对于复杂产出（多页面、多子技能、多阶段方案），先画结构树
3. 定义模块间依赖关系
4. 定义关键路径（用户/受众如何使用这个产出）

产出：ARCHITECTURE_{answername}.md — 结构设计文档

模板：

# Architecture: {answername}

## 结构总览

{层级树，缩进表示嵌套}

- 模块 A
  - 子模块 A1
  - 子模块 A2
- 模块 B
  - 子模块 B1

## 模块关系与依赖

| 模块 | 依赖 | 被依赖 | 备注 |
|------|------|--------|------|
| A | — | B | 基础模块 |
| B | A | — | 依赖 A 的数据 |

## 关键路径（用户流）

### 路径 1: {路径名}
1. 受众/用户进入 {入口}
2. 看到 {内容/提示}
3. 采取行动：{action}
   - 若 {条件A} → {结果}
   - 若 {条件B} → {结果}
4. 到达 {终点}

## 信息层级

### {模块名}
1. **最高优先级**：{内容} — 理由：{why}
2. **次优先级**：{内容} — 理由：{why}
3. **第三优先级**：{内容} — 理由：{why}

## 增长适配
{哪些部分会随时间扩展？如何处理？（分类/分页/归档）}

## 接口规格（技术类项目时使用）

> 借鉴 execplan 的 Interface Specs 方法论——对技术类项目显式定义模块接口。

| 模块 | 输入 | 输出 | 依赖 |
|------|------|------|------|
| {模块A} | {类型 / 格式 / 示例} | {类型 / 格式 / 示例} | {外部服务的 API 版本 / 认证方式} |
| {模块B} | {类型} | {类型} | — |

### {模块名} 错误处理
- 失败时回退行为：{描述}。

注意：如果产出是单一文件/简单结构（如单篇方案文档），此阶段可快速通过——仅需确认内容大纲和层级（创建一个简化的 ARCHITECTURE 文档，只包含「结构总览」和「信息层级」两节，跳过模块关系和增长适配）。

Architect 视觉增强（精装修模式）

当用户对 Phase 3 结构表达"看上去不够丰富"时，在不增加内容的条件下添加视觉层：

1. ASCII 架构全景图 — 用框图展示 Days × Modules 嵌套关系，标注子模块核心动作
2. 三层能力映射表 — 认知层/操作层/创造层，每层标注覆盖模块和学员获得
3. 时间配比 — Day 1/Day 2 实操/讲解/茶歇百分比分布

原则：内容一个不改，穿上视觉外衣。不改变 Brief/Standards 中定义的任何设计决策。

过渡语："架构已定义。下面建立标准和规范——复用模式、命名约定、质量基线。加载 domain-mapping 获取领域特定的规范模板。继续？"

Phase 4: Standards（标准规范）

来源：design-tokens — 建立可复用模式

目标：定义可复用的标准、模式、命名约定、质量基线，确保产出的一致性。

方法：

1. 识别可复用的模式（技能创建时的命名约定、方案文档的段落模板）
2. 加载 references/domain-mapping.md，根据当前领域加载对应的 Standards 模板变体
3. 定义标准（格式、命名、结构）
4. 定义质量基线（什么算"完成"）

产出：STANDARDS_{answername}.md — 标准规范文档

模板：

# Standards: {answername}

## 命名约定

| 概念 | 命名 | 规则 |
|------|------|------|
| {concept 1} | {name} | {rule} |

## 格式规范
- 文件格式：{markdown/html/json/...}
- 编码：UTF-8
- 换行：LF

## 复用模式

### 模式 1: {模式名}
- **何时使用**：{trigger}
- **模板**：\`\`\`{示例}\`\`\`
- **已有参考**：{链接到已有实例}

## 质量基线（DoD）

每个产出物必须满足：

| # | 检查项 | 通过标准 |
|---|--------|---------|
| 1 | {item} | {standard} |
| 2 | {item} | {standard} |

## 反模式（禁止）

| # | 反模式 | 原因 |
|---|--------|------|
| 1 | {anti-pattern} | {why bad} |

领域特定 Standards 变体

🔴 内部制度/财务文档（非技术受众）→ 加载 references/standards-for-policy-docs.md。 该变体强制：中文全称变量、自然语言公式、"在算什么→公式→为什么"三步解释、手机计算器可验算。 当用户说"非财务人员也要看懂""用叙述性语言"时自动切换到此变体。

过渡语：🛑 "标准已建立。下面将简报拆解为可独立构建的增量任务。继续？"

Phase 5: Decompose（任务拆解）

来源：brief-to-tasks — 垂直切片式拆解

目标：将 Brief 中的所有产出物拆解为独立、可验证、可增量交付的任务列表。

方法：

1. 每个任务是一个垂直切片——包含结构+内容+验证
2. 任务可独立构建、独立验证
3. 按依赖排序：基础 → 核心 → 润色
4. 每个任务标注：是新创建/复用/修改

产出：TASKS_{answername}.md — 任务清单

模板：

# Build Tasks: {answername}

Generated from: BRIEF_{answername}.md
Date: {date}

## Spike（可行性验证）

> 借鉴 execplan 的 Prototyping Milestones 方法论——先验证关键假设，再投入完整构建。

- [ ] **{尖刺任务名}**: {要验证的假设}。_{通过标准：{可观测结果}}。_{若通过 → 进入 Core Task N；若不通过 → 记录到决策日志}。_

## Foundation（基础）
- [ ] **{任务名}**: {一句话描述什么是"完成"}。_{状态：新建 / 复用 / 修改}。_

## Core（核心构建）
- [ ] **{任务名}**: {描述}。_{依赖：{前置任务}}。_
- [ ] **{任务名}**: {描述}。

## Polish（润色与验证）
- [ ] **{任务名}**: {描述}。覆盖：{状态/边界情况}。
- [ ] **Review：运行 answer Phase 7 审查**。

## 执行顺序

Task 1 → Task 2 → Task 3 (可与 4 并行) ↘ Task 4 ↗ Task 5

任务设计规则：

• 不允许"创建项目结构"/"初始化仓库"类纯搭建任务
• 每个任务包含内容+验证
• 高风险/不确定的任务排在前面
• 视觉/用户感知优先级高的排在前面

过渡语：🛑 "任务已拆解。下面按顺序逐步构建。是否现在开始构建？"

🔴 CHECKPOINT：

1. 任务清单完整（Spike + Foundation + Core + Polish 四组齐全） ✓
2. 每个任务是垂直切片（含内容+验证） ✓
3. 自包含检查：随机抽取 1 个任务，假设自己是"从没见过这个项目的人"——只看该任务的描述和上下文，能否独立完成？如果不能，缺少什么信息？ ✗
4. 确认后进入 Build。Build 阶段不可逆——开始后按任务顺序执行，不跳回重排。

Phase 6: Build（逐步构建）

目标：按 TASKS.md 的顺序，逐个完成任务并在每个任务后验证。

方法：

1. 从 Foundation 第一个任务开始
2. 完成后立即验证（对照 Standards 中的 DoD）
3. 🔴 文档写入后强制校验：每次用 lark-cli docs +update --command overwrite 写入飞书文档后，立刻 lark-cli docs +fetch 确认 revision_id > 1 且文本内容存在。创建时 revision_id=1 且无文本 = 写入失败。不跳过此步。
4. 打勾 ✅ 标记完成，输出该任务的交付物
5. 确认后进入下一个任务
6. 所有任务完成后，记录构建日志

产出：BUILD_LOG_{answername}.md + 各任务的交付物

构建日志模板：

# Build Log: {answername}

## Task 1: {任务名}
- 状态：✅ 完成
- 时间：{开始时间} ~ {结束时间} (UTC+8)，耗时约 {分钟} min
- 产出：{链接/文件路径}
- 调用的技能/工具：{skill_manage / feishu-doc / feishu-html / ...}
- 参数：{关键参数摘要}
- 验证结果：{通过/失败 + 详情}

### 💡 意外发现（如有）
- {实施中发现的非预期行为 / 工具坑 / 边界情况}。_{证据：{复现步骤或输出摘要}}。_

### 🔄 决策记录（如有）
- 决策：{中途改了什么}
- 理由：{为什么}
- 替代方案：{曾考虑但放弃的选项 + 放弃原因}

## Task 2: {任务名}
...

重要：Build 阶段可能调用其他技能来完成具体交付：

• 需要做 HTML 页面 → 调用 feishu-html
• 需要写飞书文档 → 调用 feishu-doc
• 需要画架构图 → 调用 architecture-diagram
• 需要做行程页 → 调用 trip-landing
• 需要创建技能 → 调用 skill_manage

幂等性要求

借鉴 execplan 的 Idempotence 方法论——步骤可安全重复执行，不产生副作用。

• 创建类操作：先检查是否已存在，已存在则跳过（不覆盖）
• 写入类操作：使用 overwrite 模式（重复执行结果一致）
• 部署类操作：重复部署不产生重复资源（OSS 同名文件覆盖）
• 如果某步骤不可幂等（如发送通知），在 BUILD_LOG 中显式标注 ⚠️ 非幂等

全局决策日志

借鉴 execplan 的 Decision Log 方法论——贯穿 Phase 3 和 Phase 6，记录所有关键决策。

在工作流记录文档末尾维护「## 决策日志」章节：

## 决策日志

### D-001: {决策标题}
- 阶段：Phase {3 Architect / 6 Build}
- 决策：{选择了什么方案}
- 理由：{为什么选这个}
- 替代方案：{曾考虑的选项 + 放弃原因}
- 日期/作者：{YYYY-MM-DD} / {作者}

过渡语：🛑 "构建完成。现在运行审查——对照简报逐项检查质量。继续？"

Phase 7: Review（质量审查）

来源：design-review（对照性审查）+ blue-team（压力测试）+ strategy-red-team（红队攻击）+ pre-mortem（风险分级）

目标：对照 Brief 和 Standards，检查所有产出物的质量，暴露逻辑断层和实现偏差。

方法：

7.1 对照性审查（design-review 方法论）

逐项检查产出物 vs. Brief：

7.2 压力测试（blue-team 方法论）

调用 blue-team 技能对方案本身进行逻辑审查：

• 本质还原：核心价值主张是什么？
• 死亡假设：如果失败，最可能的死因？
• 苏格拉底追问：未被验证的前提假设？

7.2a 红队攻击（strategy-red-team 方法论 — 战略级方案必用）

🆕 借鉴 pm-skills strategy-red-team —— 攻击 Load-bearing Assumptions，不是泛泛的风险列表。

适用于：战略方案、PRD、商业计划书、架构决策等关键决策文档。对日常方案（活动策划、简单流程 SOP）可选。

红队审查规则（与 blue-team 的差异化定位）：

红队流程：

1. 提取每个 claim：列出方案断言为真的每件事——关于用户、市场、约束、机制、时间线。区分 Load-bearing claims（如果假，方案崩溃）和装饰性 claims。只攻击 Load-bearing 的。

2. Steelman, then Attack：对每个 Load-bearing claim，先陈述它为真的最强版本，然后攻击那个版本——不是稻草人。攻击弱版本毫无价值。

3. 每个失效模式写成「Fails if ___」：具体、可证伪。「Fails if 激活率不是真正的瓶颈」优于「执行风险」。

4. 按 (Impact if wrong) × (Likelihood wrong) × (Cheapness to test) 排序：列表顶部是本周就该测的——高影响、可能出错、测试便宜。

5. 自我反驳，不编造：默认「这个风险是真的」，除非方案已引用证据反驳。但如果一个 claim 确实有理有据，直接说——红队编造疑虑和橡皮图章一样没用。

6. 每个存活下来的 kill-assumption 给三个动作：

   • Fails if：精确地，什么条件会让方案崩溃
   • Evidence to get this week：本周能拿到的具体数据/查询/对话
   • Kill criterion：到什么阈值你该停下来或改变方向
   • Cheapest test：最小的验证实验

红队输出模板：

## 红队审查: {方案名}

### Top Kill-Assumptions（按测试便宜度排序，最多5条）
对每条：
- **Claim**: {承受性断言}
- **Fails if**: {具体、可证伪的崩溃条件}
- **Evidence to get this week**: {具体数据来源}
- **Kill criterion**: {停止/转向阈值}
- **Cheapest test**: {最小验证实验}

### 什么站得住脚
{明确说哪些部分理由充分——不编造疑虑}

### 无法评估的部分
{方案未给出足够信息的盲区}

红队纪律：

• 不稻草人——攻击钢人或别攻击。
• 不泛化风险列表——每一条都针对这个方案。
• 不编造——如果站得住，就说站得住。
• 无情排序——最便宜的、影响最大的测试才是整个红队的意义。

7.2b 死亡假设风险分级（pre-mortem Tiger 分级）

🆕 对 blue-team 的死亡假设增加 Tigers / Paper Tigers / Elephants 三级分类。

使用方式：在 blue-team 审查完成后，将每个死亡假设标注 Tiger/Paper Tiger/Elephant 级别。Tiger 项写入 Must Fix，Elephant 写入 Should Fix 并附 if-then 预案。Paper Tiger 记录在「什么站得住脚」中。

7.2b 深度审视（Advanced Elicitation — 可选增强层）

🆕 调用 advanced-elicitation 技能对产出做多视角审视。

对 Review 中发现的 Must Fix / Should Fix 项，建议运行 2-3 种方法做深度审视：

加载 advanced-elicitation，对 Review 中的关键发现运行：
- 方案/决策类 → Pre-mortem + First Principles + Inversion
- 代码/技术类 → Boundary Sweep + 5 Whys + Red Team
- 文案/内容类 → Critique & Refine + Socratic + Steelmanning

AE 不会自动运行——Phase 7 结束后提示用户"是否需要对关键发现运行深度审视？"

7.2c 文案质量门禁（Editorial Review — 可选增强层）

🆕 调用 editorial-review-prose 技能对产出文案做临床级审查。

如果最终交付物包含面向客户的文案：

加载 editorial-review-prose（如需贵州之客铁律，同时加载 zhike-content-output 作为 style_guide）
→ 三列表格审查（原文/修订/变更理由）
→ 用户逐条确认是否采用

7.3 可视化验证（如产出是 HTML 页面）

对部署后的页面运行 feishu-html 阶段五的 Playwright 验证协议（6 项必检）。

产出：REVIEW_{answername}.md — 审查报告

模板：

# Review: {answername}

Review against: BRIEF_{answername}.md
Date: {date}

## 对照审查

| # | 检查项 | 结果 | 证据/备注 |
|---|--------|------|----------|
| 1 | 完整性 | ✅/❌ | {detail} |
| 2 | 一致性 | ✅/❌ | {detail} |
| 3 | 标准合规 | ✅/❌ | {detail} |
| 4 | 依赖闭合 | ✅/❌ | {detail} |
| 5 | 受众适配 | ✅/❌ | {detail} |

## Must Fix（必须修复）
1. **[问题]**：{具体描述}。_修复方案：{建议}。_

## Should Fix（应该修复）
1. **[问题]**：{描述}。_修复方案：{建议}。_

## Could Improve（可以优化）
1. **[问题]**：{描述}。_建议：{idea}。_

## 蓝军审查摘要
{调用 blue-team 的结果摘要或完整嵌入}

## 红队审查摘要（战略级方案）
{如有运行 7.2a 红队攻击，嵌入 Top Kill-Assumptions + Cheapest Test}

## 总体评分
{score}/100 — {一句话总结}

## 成果与回顾 (Outcomes & Retrospective)

> 借鉴 execplan 的 Outcomes & Retrospective 方法论——对照 Brief 的成功标准，总结实际达成。

### 对照 Brief 成功标准

| Brief 中的成功标准 | 实际达成 | 差距 |
|-------------------|---------|------|
| {SC-1} | {实际结果} | {✅ 达标 / ⚠️ 部分 / ❌ 未达成} |
| {SC-2} | {实际结果} | ... |

### 未达成的目标（如有）

- **{目标}**：未达成原因 → {原因}，建议：{后续行动}

### 经验教训

1. **{关键学习}**：{描述} — {对未来项目的启示}
2. **{改进建议}**：{描述}

### 可复用资产

- 决策日志中的关键决策（D-001, D-002...）
- 意外发现中可跨项目复用的发现（S-001...）

领域适配参考

详见 references/domain-mapping.md — 不同领域到 7 阶段的参数化模板。

快速适配表

约束与陷阱

约束

1. Phase 2 核心原则 ≤ 3 条 — 超过即失去聚焦
2. Phase 5 每个任务必须是垂直切片 — 不含纯搭建任务
3. Phase 7 审查必须具体 — 每条发现指向具体产出物的具体位置
4. 产出全进飞书 Wiki — 不在本地留散落文件
5. 每阶段必须等用户确认 — 不自动跳下一阶段

常见陷阱

财务/分润类框架的表达模式

🆕 从企业管理培训分润体系项目中沉淀——财务公式的表达方式显著影响可读性。

公式优先用"恒等式"而非"序列流"：

• ❌ 序列流：合同→扣A→扣B→得C→分D→算E→扣F→到手
• ✅ 恒等式：合同总价 − 业务渠道 − 开票税费 − 机构利润 = 讲师课酬 + 资金占用
• 恒等式让读者一眼看清"谁从总价里分走了什么"，剩余就是讲师的。不需要追踪九步才能理解结构。

结算公式用"实得比例"而非"扣除比例"：

• ❌ 扣除式：资金占用费 = 应结 × 50% × (1 − 已等/周期) —— 读者要先算占用费再减
• ✅ 实得式：实际结算 = 应得 × (50% + 50% × 已等/周期) —— 直接告诉你拿到百分之多少
• 验证：立即(0天)→50%，正常(满周期)→100%，中间线性增长。手机计算器一步出结果。

术语用"应得/实际"比"应结/实收"更直观：

• "应得课酬"比你分到的名义金额，"实际结算"是结算时点决定的到手金额（扣占用前），"实收"是扣完税后打入卡里的金额。三步层层递进。

简化时以"表"为单元砍：

• 用户说"只保留分润结构+比例+公式"时，用五张表覆盖全文档：分润结构表/层级比例表/计算公式表/结算规则表/一个示例表。每张表独立可读，删除所有叙述段落。

⛔ 禁止操作（Anti-Patterns Blacklist）

以下操作在任何情况下都禁止——不是"不建议"，是"不允许"。

每一条都是经过真实项目验证的失败模式。违规操作的后果不是"可能出错"，而是已验证会出错。

约束与陷阱

错误处理

每个可预见的失败场景必须有明确的 if-then 响应路径。禁止静默失败——任何异常都必须向用户通报并提供下一步选项。

工作流级故障表（Phase 1-7 全程）

技术级故障表（API/工具层）

中断恢复

当用户说"暂停"/"够了"/"之后继续"，或对话中断后用户返回：

1. 检查 Wiki 节点：列出 J4EewYIT2ieFuwkRWbxcgWbFnhe 下的已有文档
2. 判断进度：根据已存在的文档判断当前在哪个阶段：
   • {answername}_工作流全记录 存在 → 读取内容，判断最后完成的阶段
   • 各阶段独立文档存在（旧模式）→ 按文档名判断
3. 从中断阶段继续：告知用户「上次进行到 Phase {N}，从 Phase {N+1} 继续？」
4. 如果 Wiki 中无记录：检查 ~/.hermes-feishu/answer/ 本地降级目录

与现有技能互动规则

快速通道：富材料场景（Rich-Materials Fast-Track）

🆕 从思奔酒业连续两次深度合作中沉淀——当用户提供丰富源材料时，加速 7 阶段流程。

触发条件（全部满足时自动激活快速通道）：

1. 用户提供了 ≥2 份高质量源材料（会议纪要、录音转写、PDF 方案、Word 文档等）
2. 材料中已包含明确的需求、讨论、决策方向
3. 用户要求"帮我梳理并产出"而非"帮我从零设计"

快速通道规则：

适用领域：📋 新方案（方法论文档/提案/规划案/橙皮书/白皮书）

不适用场景：🛠️ 新技能（需要精确接口定义）、🏢 新业务（需要市场验证假设）、🔍 分析调研（需要数据源确认）

多方案并行生成模式

当用户要求"做两套方案"（如方案 A + 方案 B、高价版 + 低价版）时：

1. Phase 1-5 共享一次：两套方案共享相同的 Clarify 结论和 Brief——因为源材料和核心受众相同
2. Phase 6 Build 分别生成：两套方案各写一份完整的独立文档
3. 关键差异必须在 Brief 中显式标注：两套方案的核心分歧点是什么（如"全案 vs 分步"、"高价 vs 低价"），避免 Build 阶段偏离
4. 费用和交付物必须分别计算：不能共用数字

示例：思奔酒业 AI 落地规划案中，方案 A（全案）和方案 B（分步）共享 Phase 1-4 的现状诊断和业务理解，但 Phase 6 独立生成两份完整提案，费用结构完全不同。

决策汇报案：Build 后的精简变体

当 Build 产出的完整方案文档过于厚重（如两份各 17-19KB 的详细提案），而用户需要一份可直接用于客户汇报和内部决策的简明版时，在 Build 完成后追加生成一份决策汇报案：

触发信号：用户说"我需要一个清晰简明扼要的方案用于汇报/决策"、"太长了，帮我精简一下"、"给我一个能拿去讲的版本"

决策汇报案的规则：

决策汇报案的结构模板：

# {项目名} — 决策汇报案
## 一、问题定义（一页说清"为什么做"）
## 二、两案速览（ASCII 对比图，一句话概括）
## 三、方案A详解（只留核心：做什么/多少钱/时间线）
## 四、方案B详解（同上）
## 五、对比表（8-10 维度并排对比）
## 六、建议（明确推荐 + 理由）
## 七、下一步（决策→行动映射）

注意事项：

• 决策汇报案不替代完整方案——完整方案作为"附件"供深度阅读
• 不要简单截取完整方案中的章节——必须重新组织语言，以"决策者视角"重写
• 费用数字必须与完整方案一致，不能因精简而丢失精度
• 决策汇报案同样输出 MD + PDF 双格式

快速启动（省略模式）

当用户只需要快速规划而不要完整 7 阶段时，支持精简模式：

• answer quick {topic}：Clarify(精简) → Brief(模板) → Decompose(5 条任务)，跳 Architect/Standards/Build/Review
• answer brief {topic}：只跑 Clarify + Brief，产出结构化简报
• answer review {project}：只跑 Phase 7 审查已完成的产出

端到端示例：创建一个"行程总结"技能

以真实案例展示 7 阶段如何运作：

用户: "answer this: 创建一个 trip-summary 技能，输入方案文档自动生成客户总结页"

🔴 CHECKPOINT → 识别为 🛠️ 新技能领域。确认。

Phase 1 CLARIFY → 追问 5 轮：
  Q1: 谁在什么场景触发？→ 运营人员，客户要出行前生成
  Q2: 输入输出？→ 输入 doc_token，输出 HTML 页面
  Q3: 依赖？→ trip-landing(页面结构) + feishu-html(部署)
  Q4: 不覆盖什么？→ 不修改方案、不与已有 trip-landing 功能重叠
  Q5: 最不确定？→ 文档内容提取的准确性
→ 产出: CLARIFY_trip-summary.md ✓

Phase 2 BRIEF → 结构化：
  核心原则: 一键交付 > 灵活配置; 客户体验优先; 品牌一致性
  产出物: SKILL.md + extract.py + build_page.py
→ 产出: BRIEF_trip-summary.md ✓

Phase 3 ARCHITECT → 结构树：
  触发 → 提取行程(extract.py) → 生成页面(build_page.py) → 部署OSS
→ 产出: ARCHITECTURE_trip-summary.md ✓

Phase 4 STANDARDS → 规范：
  命名: trip-summary (kebab-case)
  DoD: 从方案链接输入→3步内生成可访问URL
→ 产出: STANDARDS_trip-summary.md ✓

Phase 5 DECOMPOSE → 任务清单：
  Foundation: [ ] 创建 SKILL.md 骨架
  Core: [ ] 实现 extract.py [ ] 实现 build_page.py
  Polish: [ ] 端到端测试 [ ] Review
→ 产出: TASKS_trip-summary.md ✓

🔴 CHECKPOINT → 任务清单完整，确认进入 Build。

Phase 6 BUILD → 逐步构建：
  Task 1 ✅ SKILL.md → 调 skill_manage 创建
  Task 2 ✅ extract.py → 写入 scripts/
  Task 3 ✅ build_page.py → 写入 scripts/
  Task 4 ✅ 端到端测试 → 测试用例通过
→ 产出: BUILD_LOG_trip-summary.md ✓

Phase 7 REVIEW → 对照审查 + blue-team 压力测试：
  完整性 ✅ | 一致性 ✅ | 标准合规 ✅ | 依赖闭合 ✅ | 受众适配 ✅
  评分: 88/100
→ 产出: REVIEW_trip-summary.md ✓

总计: 7 个 Wiki 文档, 1 个技能上线, 耗时 ≈ 15 分钟

验证清单

• 工作流记录文档已创建并写入飞书 Wiki（Phase 1-5 合并为单文档，Phase 7 追加）
• Phase 2 Brief 包含 ≤ 3 条核心原则
• Phase 5 任务全是垂直切片，无纯搭建任务
• Phase 6 Build 交付物已独立写入飞书 Wiki
• Phase 7 Review 包含对照审查 + 蓝军审查
• Review 中有具体评分

开源仓库

GitHub: jorinyang/answer — SKILL.md + domain-mapping + README + CHANGELOG，含 v1.0.0 / v1.1.0 / v1.1.1 三个 Release。

非飞书环境？ 使用 answer-standalone 技能（v2.0.0），纯本地 markdown 输出，零外部依赖。与原版 answer 共享相同的 7 阶段方法论和 6 领域模板。

非飞书环境自动降级：当无飞书 API 时，Phase 1-5 合并为本地 {项目}_工作流全记录.md，Phase 6 产出独立 .md 文件，Phase 7 追加到全记录。交付物可导出 DOCX（python-docx）或 PDF（Playwright/Chromium，见 references/pdf-generation-pipeline.md）。

独立封装文档: Answer 方法论完全指南 — 脱离 Hermes 技能系统的 18 章独立参考文档，归档于 AI Native 工作流节点下。

📚 引用文件索引