p12-contemplation-orchestrator

name	p12-contemplation-orchestrator
description	《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
stage	meta
tags	["orchestrator","观照","产品判断","决策修正"]
source_book	观照
source_chapter	全书编排
version	1.0.0

观照编排器（Contemplation Orchestrator）

适用场景

• 产品经理面对复杂决策，不确定该从哪个视角切入
• 团队想用《观照》框架做系统性复盘或决策评审
• 需要将模糊的产品困惑拆解为具体检查步骤

输入

字段	说明
user_question	用户提出的核心问题或困惑
context	可选：产品阶段、团队规模、行业等背景信息
focus_area	可选：用户希望聚焦的章节/主题

输出

• 推荐的 Skill 调用链（有序列表）
• 每个 Skill 的调用理由
• 聚合后的检查清单

工作流程

1. 问题分类：分析 user_question，判断其核心属于哪个章节领域
2. 构建调用链：按"前提→视角→问题→判断→表达→行动→收入→止损→反思"顺序排列
3. 执行 Skill 调用：依次调用链中每个 Skill
4. 聚合输出：汇总所有 Skill 的发现，生成结构化"观照报告"
5. 行动建议：给出 1-3 条可直接执行的具体行动项

注意事项

• 并非每个问题都需要走完全部 Skill，应根据问题类型智能裁剪
• 如果只问局部问题，优先调用相关章节，不必强制从 Ch1 开始
• 编排器本身不产出内容，只负责路由和聚合

核心概念

1. 观照（Contemplation）

• 定义：一种在推进之前先回看自己的职业能力——回看自己是怎么定义问题的、怎么命名用户的、怎么相信某组数据的
• 关键点：
  • 方法解决"怎么做"，观照处理"怎么做之前怎么看"
  • 不是慢下来发呆，而是一种前置校准能力
  • 没有方法团队会混乱；只有方法没有观照，团队会稳定地偏离正轨
  • 偏差常常发生在动作之前，而非动作之中

2. 八正道框架（Eightfold Path Framework）

• 定义：书中的核心分析框架，按修正层次递进的八个维度
• 关键点：
  • 正见（问题定义）→ 正思维（判断路径）→ 正语（组织表达）→ 正业（产品机制）→ 正命（商业逻辑）→ 正精进（努力方向）→ 正念（注意力）→ 正定（决策状态）
  • 正见放在最前——方向不正，速度就是风险
  • 八个维度不是独立工具，而是一条完整的修正链路

3. 方法前提检查（Method Prerequisite Check）

• 定义：在调用任何方法之前，先验证该方法依赖的前提是否仍然成立
• 关键点：
  • 旧方法没有失效，失效的是"产品还是原来那种产品"的默认
  • 前提没被重新校准时，方法不再是罗盘，而更像放大器
  • 把数据从"答案"降级为"警报器"

4. 三层问题分析（Three-Layer Problem Analysis）

• 定义：现象层→场景层（情境层）→关系层的逐层深入分析法
• 关键点：
  • 现象层：用户说了什么、数据发生了什么
  • 场景层：什么约束条件下、用户承担什么成本
  • 关系层：背后变化的是什么关系（工具与用户、人与AI、组织与结果）

5. 从方法到观照的转换

• 定义：先修正看法再调用方法的工作模式
• 关键点：
  • 产品方法处理动作问题，产品观照处理动作之前的看法问题
  • 观照不是替代方法，而是在方法之前运行
  • 对所有"太顺的答案"保留一点迟疑

深入核心概念

1. 观照作为前置校准能力

"产品方法解决的是动作问题，产品观照处理的是动作之前的看法问题。"

书稿在第二章明确区分了"方法"与"观照"的关系：方法关心的是"下一步做什么"，观照关心的是"我为什么会觉得下一步该这么做"。这两者不是替代关系，而是前后关系。没有方法，团队会混乱；只有方法没有观照，团队会稳定地偏离正轨。观照不是慢下来发呆，而是一种职业能力——在推进之前，先回看自己是怎么定义问题的、怎么命名用户的、怎么相信某组数据的。

在产品编排场景中，这意味着编排器不应直接跳入方法调用，而应在路由之前先做一次"看法校正"。当用户提出问题时，编排器需要先判断：这个问题的定义是否已被团队的位置和指标语言过滤过？用户说的"留存下降"到底是功能问题、信任问题还是商业模式问题？只有看法先被校正，后续的 Skill 调用链才能真正触及问题，而不是在错误的方向上高效运转。

2. 八正道的递进修正链路

"正见修问题定义，正思维修判断路径，正语修组织表达，正业修产品机制，正命修商业逻辑，正精进修努力方向，正念修注意力，正定修决策状态。"

书稿将八正道定义为一条完整的修正链路，而非八个独立工具。每个维度处理不同层次的偏差：正见解决"看到了什么"，正思维解决"怎么走到这个结论的"，正语解决"怎么说的"，正业解决"做的机制是否正当"，正命解决"赚钱方式是否扭曲了立场"，正精进解决"努力方向是否需要修正"，正念解决"注意力是否被表层信号吸走"。偏差常常发生在动作之前，而非动作之中。

编排器的核心职责是根据问题类型智能构建这条链路。不是每个问题都需要走完全部八个维度——一个"数据好看但感觉不对劲"的问题可能同时涉及正业、正命和正念；一个"方法以前有效现在不灵"的问题可能只需前提检查加正见。编排器应识别问题的修正层次，按需裁剪调用链，避免过度编排让用户觉得流程太重。

3. 三层问题分析的路由依据

"现象层：用户说了什么、数据发生了什么。场景层：什么约束条件下、用户承担什么成本。关系层：背后变化的是什么关系。"

书稿提出的三层分析法是编排器进行问题分类的核心依据。现象层最容易被看见，也最容易看错——团队往往在现象层就开始争论"这是什么问题"。场景层揭示用户的真实处境和成本结构，决定了"可行解空间"。关系层则揭示结构性原因和改变杠杆点。编排器应引导用户从现象层出发，逐步深入到场景层和关系层，再根据分析结果路由到对应 Skill。

在实际编排中，当用户描述的问题停留在现象层（如"搜索量下降"），编排器应先调用正见 Skill 帮助深入到关系层（如"用户不再愿意自己组织关键词"），再根据关系层洞察路由到具体修正 Skill。这种"先看深再路由"的模式，能避免编排器直接在表层问题上跳转，确保后续 Skill 的分析建立在更准确的问题定义之上。

分步执行

第 1 步：问题分类与路由

1. 接收用户的 user_question
2. 分析问题核心属于哪个修正维度：
   • 涉及"问题看不清/定义模糊" → 正见（p12a-contemplation-right-view）
   • 涉及"方法以前有效现在不灵" → 前提检查（p12a-contemplation-prerequisite-check）
   • 涉及"看法需要多角度审视" → 视角修正（p12a-contemplation-view-correction）
   • 涉及"判断依据混乱" → 正思维（p12a-contemplation-right-thinking）
   • 涉及"沟通失真/话术掩盖问题" → 正语（p12a-contemplation-right-speech）
   • 涉及"机制设计/行动正当性" → 正业（p12a-contemplation-right-action）
   • 涉及"商业模式/收入与立场" → 正命（p12a-contemplation-right-livelihood）
   • 涉及"该不该继续/止损" → 正精进（p12a-contemplation-right-effort）
   • 涉及"注意力/看数据但看不见问题" → 正念（p12a-contemplation-right-mindfulness）

第 2 步：构建调用链

1. 如果问题跨多个维度，按八正道顺序排列调用链
2. 默认完整链：前提检查 → 视角修正 → 正见 → 正思维 → 正语 → 正业 → 正命 → 正精进 → 正念
3. 根据问题类型智能裁剪，局部问题优先调用相关章节

第 3 步：执行 Skill 调用

1. 依次调用链中每个 Skill
2. 将上一个 Skill 的输出作为下一个的参考上下文
3. 记录每个 Skill 的发现和建议

第 4 步：聚合输出

1. 汇总所有 Skill 的发现
2. 生成结构化"观照报告"
3. 报告包含：问题重新定义、关键偏差识别、修正建议

第 5 步：行动建议

1. 给出 1-3 条可直接执行的具体行动项
2. 每条行动项标注来自哪个修正维度
3. 标注优先级和预期效果

示例 1：AI 功能上线后留存下降

场景描述

团队上线了一个 AI 写作助手功能，初期数据亮眼，但两个月后续费率只有 43%。团队在复盘会上争论不休：有人说"市场还没准备好"，有人说"功能不够强"，有人说"定价有问题"。

用户输入

user_question: "我们的 AI 写作助手续费率只有 43%，竞品普遍 65-75%。团队对此有分歧，有人说市场不成熟，有人说产品力不够。该从哪里看这个问题？"
context: "B2B SaaS，订阅制，上线 6 个月"

执行流程

1. 问题分类：涉及"问题定义模糊"（续费低到底是什么问题？）+ "判断路径混乱"（不同人有不同归因）+ "商业模式审视"（续费模式本身）
2. 构建调用链：视角修正 → 正见 → 正思维 → 正命
3. 执行调用：
   • 视角修正：拆解"市场不成熟"这个说法——它把产品问题改写成了时间问题
   • 正见：三层分析——现象层（续费率低）→ 场景层（用户在什么场景下决定不续费）→ 关系层（续费模式天然诱导"让用户持续回来"）
   • 正思维：拆解团队判断链——前提（用户说好就会续费）未验证；情绪（对增长的焦虑驱动了过度功能堆砌）
   • 正命：审视商业模式——续费模式奖励"让用户形成依赖"而非"让用户变强"

输出结果

=== 观照报告 ===

【问题重定义】
原问题："续费率低，市场不成熟"
修正后："产品定位从'让用户变强'滑向了'让用户依赖'，续费模式在加速这一偏移"

【关键偏差】
1. "市场不成熟"掩盖了四个不同可能：价值主张不清/价格不匹配/客户选错/产品方向偏移
2. 团队默认"用户说好就会续费"，未验证"好"与"续费"之间的因果
3. 商业模式天然奖励依赖感，团队被 KPI 推着偏离了初心

【行动建议】
1. 【正见-高优】重新做一次用户深度访谈，区分"使用中满意"和"续费时犹豫"的真实原因
2. 【正命-中优】审视提醒机制和功能层级设计，哪些在帮助用户、哪些在制造依赖
3. 【正语-低优】将"市场不成熟"这个结论翻译成可验证的具体命题

示例 2：增长机制引发用户反噬

场景描述

一款学习 App 靠连续签到和倒计时提醒将 DAU 拉高了 18%，但用户研究访谈中出现越来越多"被绑架""被推着走"的反馈。团队纠结于"数据很好"与"用户不舒服"之间的矛盾。

用户输入

user_question: "我们学习 App 的 DAU 涨了 18%，但用户访谈里越来越多'被绑架'的反馈。增长和用户体验怎么平衡？"
context: "C端教育产品，DAU 50万，Q3 刚上线连续签到+倒计时提醒机制"

执行流程

1. 问题分类：核心涉及"机制正当性"（正业）+ "努力方向"（正精进）+ "注意力质量"（正念）
2. 构建调用链：正业 → 正精进 → 正念
3. 执行调用：
   • 正业：四重检查——价值检查（去掉刺激还剩什么？）、代价检查（隐性成本：用户信任）、情绪检查（焦虑/损失厌恶）、退出权检查（用户能体面暂停吗？）
   • 正精进：归零思考——如果今天第一次设计这套机制，还会这样设计吗？
   • 正念：注意力校准——团队是否只盯着 DAU 曲线，忽略了用户情绪的渐进变化？

输出结果

=== 观照报告 ===

【问题重定义】
原问题："增长和用户体验怎么平衡"
修正后："团队设计了一套更难退出的关系，而非更有价值的产品。数据在变好，用户与产品的关系在变坏。"

【关键偏差】
1. 正业：机制主要激发的是焦虑和损失厌恶，不是价值感和成就感
2. 正精进：团队默认"DAU 上涨=方向正确"，未区分"坚持"和"延长偏差"
3. 正念：注意力全部被 DAU 曲线吸引，忽略了渐进累积的负面情绪

【行动建议】
1. 【正业-高优】弱化"连续天数"威胁，改为用户自定目标；增加"休息模式"
2. 【正业-中优】给提醒和签到机制保留体面退出权
3. 【正念-持续】建立"仪表盘之外"的用户情绪追踪，不只看曲线

常见编排陷阱

陷阱 1：强制走完全链

• 不是每个问题都需要走完全部 8 个 Skill
• 编排器应根据问题类型智能裁剪，局部问题只调用相关章节
• 过度编排会让用户觉得流程太重，反而降低使用意愿

陷阱 2：跳过前提检查直接做方案

• 团队最常见的错误是"方法还在就直接用"
• 正见放在最前是有原因的——方向不正，速度就是风险
• 编排器应确保至少做过一次前提检查或视角修正后再进入具体分析

陷阱 3：只关注单一维度

• 一个"数据好看但感觉不对劲"的问题，可能同时涉及正业（机制正当性）、正命（商业模式偏差）、正念（注意力被数据吸引忽略关系）
• 编排器应具备多维度识别能力，不遗漏关键修正维度

陷阱 4：编排器产出内容

• 编排器本身不产出分析内容，只负责路由和聚合
• 内容质量由各子 Skill 保证，编排器负责调用顺序和上下文传递
• 如果编排器自己开始分析，就失去了模块化的优势

Skill 间上下文传递规则

上游 Skill	传递给下游的上下文
前提检查	失效前提清单、新情境假设
视角修正	修正后的多视角描述、被挑战的默认假设
正见	三层分析结果、修正后的问题陈述
正思维	判断链拆解结果、薄弱环节标识
正语	清洗后的清晰版本、语言问题标识
正业	四重检查报告、机制正当性判断
正命	收入影响地图、激励偏差识别
正精进	归零分析结果、停止/继续/调整建议
正念	注意力审计报告、判断模式识别

报告模板

=== 观照报告 ===

【问题背景】
{用户原始问题描述}

【调用链】
{按顺序列出的 Skill 调用}

【各维度发现】
{每个被调用 Skill 的核心发现，1-2 句}

【问题重定义】
原问题：{用户原始问题}
修正后：{基于观照分析的问题重定义}

【关键偏差】
1. {偏差1} — 来自 {Skill名}
2. {偏差2} — 来自 {Skill名}
3. {偏差3} — 来自 {Skill名}

【行动建议】
1. 【{Skill名}-{优先级}】{具体可执行的行动}
2. 【{Skill名}-{优先级}】{具体可执行的行动}
3. 【{Skill名}-{优先级}】{具体可执行的行动}