Menu
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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名}-{优先级}】{具体可执行的行动}