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 — MIT 开源

安装

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

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

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

触发条件

自动触发（高置信度）

不触发

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

领域自动识别

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

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 领域通用追问维度：

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

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

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

Phase 2: Brief（结构化简报）

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

模板：

# {领域标签} 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（结构设计）

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

模板：

# Architecture: {项目名}

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

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

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

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

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

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

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

产出：03_architect.md

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

Phase 4: Standards（标准规范）

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

模板：

# Standards: {项目名}

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

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

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

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

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

产出：04_standards.md

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

Phase 5: Decompose（任务拆解）

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

任务设计规则：

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

三组任务：

# 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

构建日志模板：

# Build Log: {项目名}

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

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

Phase 7: Review（质量审查）

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

对照审查（5 维度）

压力测试

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

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

产出：07_review.md

成果与回顾 (Outcomes & Retrospective)

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

对照 Brief 成功标准

经验教训

1. {关键学习}：{描述} — {对未来项目的启示}

6 领域 × 7 阶段快速对照

禁止操作

错误处理

中断恢复

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

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 — MIT License
版本: v2.0.0 (standalone) | 作者: 杨瑒 (月夜)