Menü
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
持续觉察、系统反思、判断沉淀——建立个人与团队的决策觉察力
| name | p12-contemplation-orchestrator |
| description | 《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程 |
| stage | meta |
| tags | ["orchestrator","观照","产品判断","决策修正"] |
| source_book | 观照 |
| source_chapter | 全书编排 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| user_question | 用户提出的核心问题或困惑 |
| context | 可选：产品阶段、团队规模、行业等背景信息 |
| focus_area | 可选：用户希望聚焦的章节/主题 |
"产品方法解决的是动作问题，产品观照处理的是动作之前的看法问题。"
书稿在第二章明确区分了"方法"与"观照"的关系：方法关心的是"下一步做什么"，观照关心的是"我为什么会觉得下一步该这么做"。这两者不是替代关系，而是前后关系。没有方法，团队会混乱；只有方法没有观照，团队会稳定地偏离正轨。观照不是慢下来发呆，而是一种职业能力——在推进之前，先回看自己是怎么定义问题的、怎么命名用户的、怎么相信某组数据的。
在产品编排场景中，这意味着编排器不应直接跳入方法调用，而应在路由之前先做一次"看法校正"。当用户提出问题时，编排器需要先判断：这个问题的定义是否已被团队的位置和指标语言过滤过？用户说的"留存下降"到底是功能问题、信任问题还是商业模式问题？只有看法先被校正，后续的 Skill 调用链才能真正触及问题，而不是在错误的方向上高效运转。
"正见修问题定义，正思维修判断路径，正语修组织表达，正业修产品机制，正命修商业逻辑，正精进修努力方向，正念修注意力，正定修决策状态。"
书稿将八正道定义为一条完整的修正链路，而非八个独立工具。每个维度处理不同层次的偏差：正见解决"看到了什么"，正思维解决"怎么走到这个结论的"，正语解决"怎么说的"，正业解决"做的机制是否正当"，正命解决"赚钱方式是否扭曲了立场"，正精进解决"努力方向是否需要修正"，正念解决"注意力是否被表层信号吸走"。偏差常常发生在动作之前，而非动作之中。
编排器的核心职责是根据问题类型智能构建这条链路。不是每个问题都需要走完全部八个维度——一个"数据好看但感觉不对劲"的问题可能同时涉及正业、正命和正念；一个"方法以前有效现在不灵"的问题可能只需前提检查加正见。编排器应识别问题的修正层次，按需裁剪调用链，避免过度编排让用户觉得流程太重。
"现象层：用户说了什么、数据发生了什么。场景层：什么约束条件下、用户承担什么成本。关系层：背后变化的是什么关系。"
书稿提出的三层分析法是编排器进行问题分类的核心依据。现象层最容易被看见，也最容易看错——团队往往在现象层就开始争论"这是什么问题"。场景层揭示用户的真实处境和成本结构，决定了"可行解空间"。关系层则揭示结构性原因和改变杠杆点。编排器应引导用户从现象层出发，逐步深入到场景层和关系层，再根据分析结果路由到对应 Skill。
在实际编排中，当用户描述的问题停留在现象层（如"搜索量下降"），编排器应先调用正见 Skill 帮助深入到关系层（如"用户不再愿意自己组织关键词"），再根据关系层洞察路由到具体修正 Skill。这种"先看深再路由"的模式，能避免编排器直接在表层问题上跳转，确保后续 Skill 的分析建立在更准确的问题定义之上。
user_questionp12a-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）团队上线了一个 AI 写作助手功能，初期数据亮眼，但两个月后续费率只有 43%。团队在复盘会上争论不休：有人说"市场还没准备好"，有人说"功能不够强"，有人说"定价有问题"。
user_question: "我们的 AI 写作助手续费率只有 43%，竞品普遍 65-75%。团队对此有分歧，有人说市场不成熟，有人说产品力不够。该从哪里看这个问题？"
context: "B2B SaaS，订阅制，上线 6 个月"
=== 观照报告 ===
【问题重定义】
原问题："续费率低，市场不成熟"
修正后："产品定位从'让用户变强'滑向了'让用户依赖'，续费模式在加速这一偏移"
【关键偏差】
1. "市场不成熟"掩盖了四个不同可能：价值主张不清/价格不匹配/客户选错/产品方向偏移
2. 团队默认"用户说好就会续费"，未验证"好"与"续费"之间的因果
3. 商业模式天然奖励依赖感，团队被 KPI 推着偏离了初心
【行动建议】
1. 【正见-高优】重新做一次用户深度访谈，区分"使用中满意"和"续费时犹豫"的真实原因
2. 【正命-中优】审视提醒机制和功能层级设计，哪些在帮助用户、哪些在制造依赖
3. 【正语-低优】将"市场不成熟"这个结论翻译成可验证的具体命题
一款学习 App 靠连续签到和倒计时提醒将 DAU 拉高了 18%，但用户研究访谈中出现越来越多"被绑架""被推着走"的反馈。团队纠结于"数据很好"与"用户不舒服"之间的矛盾。
user_question: "我们学习 App 的 DAU 涨了 18%，但用户访谈里越来越多'被绑架'的反馈。增长和用户体验怎么平衡？"
context: "C端教育产品，DAU 50万，Q3 刚上线连续签到+倒计时提醒机制"
=== 观照报告 ===
【问题重定义】
原问题："增长和用户体验怎么平衡"
修正后："团队设计了一套更难退出的关系，而非更有价值的产品。数据在变好，用户与产品的关系在变坏。"
【关键偏差】
1. 正业：机制主要激发的是焦虑和损失厌恶，不是价值感和成就感
2. 正精进：团队默认"DAU 上涨=方向正确"，未区分"坚持"和"延长偏差"
3. 正念：注意力全部被 DAU 曲线吸引，忽略了渐进累积的负面情绪
【行动建议】
1. 【正业-高优】弱化"连续天数"威胁，改为用户自定目标；增加"休息模式"
2. 【正业-中优】给提醒和签到机制保留体面退出权
3. 【正念-持续】建立"仪表盘之外"的用户情绪追踪，不只看曲线
| 上游 Skill | 传递给下游的上下文 |
|---|---|
| 前提检查 | 失效前提清单、新情境假设 |
| 视角修正 | 修正后的多视角描述、被挑战的默认假设 |
| 正见 | 三层分析结果、修正后的问题陈述 |
| 正思维 | 判断链拆解结果、薄弱环节标识 |
| 正语 | 清洗后的清晰版本、语言问题标识 |
| 正业 | 四重检查报告、机制正当性判断 |
| 正命 | 收入影响地图、激励偏差识别 |
| 正精进 | 归零分析结果、停止/继续/调整建议 |
| 正念 | 注意力审计报告、判断模式识别 |
=== 观照报告 ===
【问题背景】
{用户原始问题描述}
【调用链】
{按顺序列出的 Skill 调用}
【各维度发现】
{每个被调用 Skill 的核心发现，1-2 句}
【问题重定义】
原问题：{用户原始问题}
修正后：{基于观照分析的问题重定义}
【关键偏差】
1. {偏差1} — 来自 {Skill名}
2. {偏差2} — 来自 {Skill名}
3. {偏差3} — 来自 {Skill名}
【行动建议】
1. 【{Skill名}-{优先级}】{具体可执行的行动}
2. 【{Skill名}-{优先级}】{具体可执行的行动}
3. 【{Skill名}-{优先级}】{具体可执行的行动}