# Answer Standalone

> AI Native'S Workflow(er) — 7 阶段结构化工作流编排器。适用于任何从零开始的复杂构建任务。独立版本，无外部平台依赖，产出为本地 markdown 文件。

- Skill: `jorinyang/answer-standalone` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jorinyang/answer-standalone`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jorinyang/answer-standalone/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: jorinyang (https://skillmd.com/u/jorinyang)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jorinyang/answer-standalone

---

# answer — AI Native'S Workflow(er)

> **answer = AI Native'S Workflow(er)**
> ```
> A I Native' S Workflow( ER )
> └─┘ └───┘└─┘ └────┘└───┘
> A N S W ER
> ```

以 `design-flow` 编排范式为核心，串联 **Clarify → Brief → Architect → Standards → Decompose → Build → Review** 七个阶段。纯本地运行，产出为 `./answer-output/` 下的 markdown 文件。

**GitHub**: [jorinyang/answer](https://github.com/jorinyang/answer) — MIT 开源

---

## 安装

将此目录复制到 Hermes 技能的 `productivity/` 路径下即可：

```bash
cp -r answer-standalone ~/.hermes-feishu/skills/productivity/
```

零外部依赖——只使用 Hermes 内置工具（terminal、write_file、read_file、web_search）。

---

## 触发条件

### 自动触发（高置信度）

| 场景 | 信号示例 |
|------|---------|
| 从零构建 | "从零开始做一个XX"、"搭一个框架" |
| 方案设计 | "写方案"、"商业计划书"、"BP"、"提案" |
| 项目启动 | "启动一个项目"、"做一个新产品" |
| 流程标准 | "设计流程"、"写 SOP"、"标准化" |
| 策略规划 | "制定策略"、"调研方案"、"竞品分析" |
| 技能创建 | "创建一个技能"、"写一个 skill" |
| 汇报演示 | "做汇报"、"做 PPT"、"演示方案" |
| 复盘总结 | "做复盘"、"总结分析" |
| 运营营销 | "运营方案"、"活动策划" |
| 架构体系 | "设计组织架构"、"指标体系" |
| 迭代优化 | "优化方案"、"迭代计划" |

### 不触发

- 单一事实查询、已有明确答案的问题、简单操作、重复性任务

---

## 领域自动识别

| 领域 | 关键词 | Brief 模板变体 |
|------|--------|---------------|
| 🛠️ 新技能 | skill、技能、工具、CLI、API | 技能接口/I/O/依赖 |
| 🏢 新业务/产品 | 商业模式、产品、市场、营收、启动 | 商业意图/价值主张 |
| 📋 新方案 | 计划、提案、策略、方案、BP、汇报 | 受众分析/方案逻辑链 |
| 🔄 流程/SOP | 流程、SOP、标准化、规范、制度 | 步骤序列/角色/规则 |
| 🔍 分析/调研 | 分析、调研、竞品、评估、可行性 | 分析框架/假设/数据源 |
| 🎯 决策支持 | 决策、对比、选择、权衡、怎么选 | 方案对比/评估标准 |

**匹配规则**：多个关键词命中时取最高优先级（技能 > 业务 > 方案 > 流程 > 分析 > 决策）。无法判断时默认「新方案」。识别后向用户确认。

---

## 7 阶段编排序列

```
1. Clarify    → 决策树遍历，追问到底
2. Brief      → 结构化简报，记录意图/目标/约束
3. Architect  → 定义结构/层次/关系/流程
4. Standards  → 建立可复用标准/模式/规范
5. Decompose  → 拆解为独立可验证的增量任务
6. Build      → 按任务逐步构建交付物
7. Review     → 对照简报逐项检查 + 压力测试
```

### 编排规则

1. **开始前**：告知完整 7 阶段序列，询问是否跳过某些阶段
2. **每阶段前**：宣布进入哪个阶段、产出什么
3. **每阶段后**：总结产出，询问「进入下一阶段？」
4. **可随时暂停**：用户说"够了"即停止
5. **活文档纪律**：工作流记录是活文档（Living Document）——进度、决策、发现持续更新到文档中，确保跨会话中断后可恢复。

### 产出目录

所有产出写入 `./answer-output/{project_name}/`：

```
answer-output/{project_name}/
├── 01_clarify.md
├── 02_brief.md
├── 03_architect.md
├── 04_standards.md
├── 05_tasks.md
├── 06_build_log.md
├── 07_review.md
└── deliverables/           ← Phase 6 最终交付物
```

---

## Phase 1: Clarify（决策树遍历）

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

**方法**：
1. 从用户初始描述中提取关键决策点，展开为决策树
2. 逐分支追问，每个追问提供推荐答案
3. 能查到的不要问（用 web_search / read_file 替代提问）

**6 领域通用追问维度**：

| 维度 | 核心问题 |
|------|---------|
| 核心对象 | 用户/受众是谁？他们的真实需求（JTBD）？ |
| 成功定义 | 什么算成功？（量化指标） |
| 边界约束 | 时间/资源/平台/合规限制？ |
| 核心假设 | 最不确定的是什么？ |
| 反目标 | 明确不做什么？ |
| 已有资产 | 可复用的已有方案/代码/文档？ |

> 6 领域的完整追问清单见 `references/domain-mapping.md`。

**产出**：`01_clarify.md` — 决策树记录、关键决策、开放问题

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

---

## Phase 2: Brief（结构化简报）

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

**模板**：

```markdown
# {领域标签} Brief: {项目名}

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

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

## 核心原则（最多 3 条）
1. **{原则名}** — {实践中的含义}
2. ...
3. ...

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

## 成功标准

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

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

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

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

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

## 产出物清单
| 产出物 | 类型 | 接收方 |
|--------|------|--------|

## 不做什么
{明确排除的内容}
```

**产出**：`02_brief.md`

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

---

## Phase 3: Architect（结构设计）

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

**模板**：

```markdown
# Architecture: {项目名}

## 结构总览
{层级树，缩进表示嵌套}

## 模块关系与依赖
| 模块 | 依赖 | 被依赖 | 备注 |

## 关键路径（用户流）
1. 用户进入 {入口}
2. 看到 {内容}
3. 采取行动 → {结果}
4. 到达 {终点}

## 信息层级
1. **最高优先级**：{内容} — {理由}
2. **次优先级**：{内容} — {理由}

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

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

| 模块 | 输入 | 输出 | 依赖 |
|------|------|------|------|
| {模块A} | {类型 / 格式} | {类型 / 格式} | {外部服务} |
```

**产出**：`03_architect.md`

**过渡语**："架构已定义。下面建立标准和规范。继续？"

---

## Phase 4: Standards（标准规范）

**目标**：定义可复用的标准、模式、命名约定、质量基线。

**模板**：

```markdown
# Standards: {项目名}

## 命名约定
| 概念 | 命名 | 规则 |

## 格式规范
- 文件格式、编码、换行规则

## 复用模式
- 何时使用 / 模板 / 已有参考

## 质量基线（DoD）
| # | 检查项 | 通过标准 |

## 反模式（禁止）
| # | 反模式 | 原因 |
```

**产出**：`04_standards.md`

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

---

## Phase 5: Decompose（任务拆解）

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

**任务设计规则**：
- ❌ 不允许纯搭建任务（"创建目录结构"、"初始化项目"）
- ✅ 每个任务必须是垂直切片——包含内容 + 验证
- 高风险/不确定的任务排在前面

**三组任务**：

```markdown
# Build Tasks: {项目名}

## Spike（可行性验证）

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

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

## Foundation（基础）
- [ ] **{任务名}**: {描述}。_{新建/复用/修改}_

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

## Polish（润色与验证）
- [ ] **{任务名}**: {描述}
- [ ] **Review: 运行 Phase 7 审查**
```

**产出**：`05_tasks.md`

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

---

## Phase 6: Build（逐步构建）

**目标**：按 TASKS 顺序逐个完成任务并验证。

**方法**：
1. 从 Foundation 第一个任务开始
2. 完成后立即验证（对照 Standards DoD）
3. 打勾 ✅ 并输出交付物到 `deliverables/`
4. 记录构建日志到 `06_build_log.md`

**构建日志模板**：

```markdown
# Build Log: {项目名}

## Task 1: {任务名}
- 状态：✅ 完成
- 产出：{文件路径}
- 验证结果：{通过/失败 + 详情}
- 备注：{遇到的问题 + 解决方案}
```

**产出**：`06_build_log.md` + `deliverables/` 下的交付物

---

## Phase 7: Review（质量审查）

**目标**：对照 Brief 和 Standards，逐项检查所有产出物的质量。

### 对照审查（5 维度）

| 维度 | 检查项 |
|------|--------|
| 完整性 | 所有计划产出物是否全部完成？ |
| 一致性 | 产出是否与 Brief 核心原则一致？ |
| 标准合规 | 是否遵守 Standards 的命名/格式/DoD？ |
| 依赖闭合 | Architect 中定义的依赖是否全部满足？ |
| 受众适配 | 产出物对目标受众是否可用/可理解？ |

### 压力测试

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

**输出分级**：Must Fix / Should Fix / Could Improve / 总体评分

**产出**：`07_review.md`

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

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

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

### 经验教训
1. **{关键学习}**：{描述} — {对未来项目的启示}

---

## 6 领域 × 7 阶段快速对照

| 阶段 | 🏢 新业务 | 🛠️ 新技能 | 📋 新方案 | 🔄 流程/SOP | 🔍 分析/调研 | 🎯 决策支持 |
|------|----------|----------|----------|----------|----------|----------|
| Clarify | 市场/用户/模式 | 触发/边界/依赖 | 受众/标准/约束 | 目标/痛点/例外 | 目的/数据源/框架 | 选项/标准/后果 |
| Brief | 商业意图/价值 | 技能接口/I/O | 方案目标/范围 | 流程目标/范围 | 分析目标/数据源 | 决策问题/候选 |
| Architect | 业务流程/角色 | 工作流/子模块 | 模块/逻辑链 | 流程图/异常 | 框架/报告结构 | 决策树/矩阵 |
| Standards | 业务规则/质量 | 命名/风格/文档 | 格式/内容规范 | 编号/格式/SLA | 引用/结论质量 | 评分/权重 |
| Decompose | 里程碑/阶段 | 子技能/测试 | 章节/证据 | 步骤/模板 | 维度/洞察 | 评估/敏感度 |
| Build | MVP/迭代 | 写 SKILL.md | 写方案文档 | 写 SOP 文档 | 写分析报告 | 写决策备忘录 |
| Review | BP检查 | 端到端验证 | 审核+压力测试 | 模拟走查 | 数据/逻辑检查 | 反面意见检查 |

---

## 禁止操作

| # | 禁止 | 正确做法 |
|---|------|---------|
| 1 | 跳过 Clarify 直接写方案 | 至少确认 3 个核心假设后再进 Phase 2 |
| 2 | 创建"搭建项目骨架"类任务 | 第一个任务必须是可产出的垂直切片 |
| 3 | Build 时跳过验证直接标记完成 | 每个任务对照 Standards DoD 逐项验证 |
| 4 | 用"视情况而定"/"灵活把握"替代具体标准 | 给出具体阈值（"≤ 3 条"、"重试 2 次"） |
| 5 | Review 评分用"大概 80 分" | 5 维度逐项打分，计算加权总分 |
| 6 | 领域识别错误时强行继续 | 任何阶段发现不匹配，立即回退 Clarify |
| 7 | 用 answer 子方法论裸拼替代完整 7 阶段 | Phase 1-7 必须按序执行，每阶段有用户确认检查点 |
| 8 | 产出散落各处不归档 | 所有产出统一写入 `answer-output/{project_name}/` |

---

## 错误处理

| 触发条件 | 一线修复 | 仍失败时 |
|---------|---------|---------|
| 写入文件失败（权限/磁盘） | 检查目录权限，重试 2 次 | 降级输出到 `/tmp/answer-output/` |
| web_search 无结果 | 换关键词重试 | 标注"数据缺失"，继续流程 |
| 用户 5 分钟不回复 | 不催促；保留已完成的文件 | 用户返回时从中断处恢复 |
| 领域无法自动识别 | 默认「新方案」；展示候选让用户选 | 用户不选时以「新方案」开始 |
| 用户输入过于模糊 | 输出 1 个具体追问 | 缩小到最核心的 1 个问题 |
| Build 某任务失败 | 标记 ❌，记录错误到 BUILD_LOG | 跳过，Review 时汇总 |
| 产出目录已存在同名项目 | 追加时间戳 `{name}-{HHmm}` | 告知用户，询问覆盖/新建 |

---

## 中断恢复

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

1. 检查 `answer-output/{project_name}/` 下的已有文件
2. 根据已存在的文件判断当前阶段
3. 告知用户「上次进行到 Phase {N}，从 Phase {N+1} 继续？」

---

## 快速启动（省略模式）

- `answer quick {topic}`：Clarify(精简) → Brief → Decompose(5 条任务)
- `answer brief {topic}`：只跑 Clarify + Brief
- `answer review {project}`：只跑 Phase 7 审查已完成产出

---

## 关键约束

1. Phase 2 核心原则 ≤ 3 条
2. Phase 5 每个任务必须是垂直切片
3. Phase 7 审查必须具体——每条发现指向具体产出物
4. 每阶段必须等用户确认——不自动跳下一阶段
5. 产出统一归档 `answer-output/{project_name}/`

---

## 端到端示例

```
用户: "answer this: 做一个暑期营销方案"

🔴 识别为 📋 新方案

Phase 1 CLARIFY → 追问受众/预算/渠道/截止日期
Phase 2 BRIEF   → 结构化简报（核心原则、受众分析、产出清单）
Phase 3 ARCHITECT → 方案目录、逻辑链
Phase 4 STANDARDS → 格式规范、质量基线
Phase 5 DECOMPOSE → 任务清单（调研→策略→执行计划→预算→风险）
🔴 CHECKPOINT
Phase 6 BUILD → 逐步写每个章节 → deliverables/暑期营销方案.md
Phase 7 REVIEW → 5 维审查 → 评分 85/100

产出: answer-output/暑期营销方案/
  ├── 01_clarify.md
  ├── 02_brief.md
  ├── 03_architect.md
  ├── 04_standards.md
  ├── 05_tasks.md
  ├── 06_build_log.md
  ├── 07_review.md
  └── deliverables/
      └── 暑期营销方案.md
```

---

**开源仓库**: [github.com/jorinyang/answer](https://github.com/jorinyang/answer) — MIT License  
**版本**: v2.0.0 (standalone) | **作者**: 杨瑒 (月夜)