Menü
持续觉察、系统反思、判断沉淀——建立个人与团队的决策觉察力
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章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p12a-contemplation-right-mindfulness |
| description | 持续觉察、系统反思、判断沉淀——建立个人与团队的决策觉察力 |
| stage | meta |
| tags | ["正念","持续反思","决策沉淀","系统觉察"] |
| source_book | 观照 |
| source_chapter | 第9章 正念与正定 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| recent_decisions | 近期重要决策列表 |
| decision_outcomes | 决策的实际结果 |
| personal_factors | 影响判断的个人因素（情绪/压力/信息等） |
定义：佛经中以牧牛譬喻修行——牧人不需要比牛力气大，但需要时时知道自己牵的是什么牛、牛往哪里走。正念不是冥想，而是"注意力的走向"：你一直盯着的是什么，你常常忽视的是什么，你在什么节点最容易看错。
书稿引用：「注意力不是态度，不是'重视'，而是真正处在现场。很多人误以为关注就是态度认真。但关注不是'想关注'，而是真的处在那里。你会注意到那些不容易注意到的事情——不是因为你更聪明，而是因为你的眼睛一直放在正确的位置。」（第9章）书中进一步指出：「团队盯着 dashboard 上的指标，却错过客户语气的变化；盯着产品活跃度，却忽略某个页面停留时间的增加；盯着市场数据，却错过对手一个不起眼的策略调整。这些细节，从不单独出现，而是在日复一日的注意力松懈里叠加。」
应用：每天花 10 分钟"扫描周围"——指标之外的指标、客户情绪变化、团队氛围、信息噪音。不追求立刻看到变化，而是建立"知道自己在不在现场"的判断能力。真正可怕的不是大变化，而是那些日复一日、无人注意的小变化。
定义：AI 时代的关注有了另一层含义——在信息过载、模型幻觉的背景下，产品经理的"注意力"和"现场感"变得比数据本身更重要。当你不知道数据背后是什么，再好的 AI 系统也只是一面模糊的镜子。
书稿引用：「Anthropic 的研究团队在分析 AI 系统行为时，并没有先看大量数字指标。他们第一步做的，是'读模型输出'——读大量案例、反复比对、确认方向再开始量化分析。Graph 的创始人在发现用户频繁退出时，也没有先打开报告，而是去现场看一个用户的真实操作过程。」（第9章）书中总结：「量的视角告诉你'似乎正在改变'，质的视角告诉你'正在改变'。很多时候，团队错失的不是数据，而是那个在现场就已经能感受到、却没人在意的细节。」
应用：培养读案例的习惯——读客户反馈的原话而非只看情感倾向数据，读用户操作视频而非只看埋点，听客户访谈而非只看报告。找到需要关注的"一两个客户"、"一两个行为模式"、"一两次案例"，用心花一小时分析。AI 帮你处理了量的层次，但只有你才能在质的层次上做出真正判断。
很多研发管理者的工作台看起来很完整：GitHub 有提交记录、Jira 有任务状态、Linear 有迭代排期、BI 有 dashboard。PR 数量、交付周期、issue 关闭率、团队吞吐、迭代完成度，都能看，也容易看得很频繁。但 Anthropic 写 Graph 客户案例时指出：很多研发管理者其实不缺分析仪表盘，缺的是能把 GitHub、Jira、Linear 这些碎片重新接回上下文的能力。
recent_decisions:
- "基于 PR 数量下降决定增加工程人力"
- "基于迭代完成度低决定缩减需求范围"
- "基于 issue 关闭率下降决定增加 QA 资源"
decision_outcomes: "资源调整后指标略有改善，但根本问题未解决"
personal_factors: "管理者主要通过 dashboard 了解团队状态，较少直接参与技术讨论"
=== 注意力审计报告 ===
【仪表盘之外的信号】
1. 任务粒度越来越细但产出越来越少（渐进变化）
2. 技术债问题持续影响三个迭代但一直被搁置
3. 工程师反馈"上下文切换太多"
4. 评审会议中越来越多重复讨论
【注意力模式识别】
- 团队倾向："看到指标下降→加资源"，而非"先问为什么下降"
- 这让注意力停在表层指标，没有深入理解现场
- 管理者主要通过 dashboard 了解状态，缺少直接上下文
【渐进变化】
- 任务粒度变化：大任务→碎片化小任务（6个月渐进）
- 团队情绪变化：有挑战感→疲于应对（慢变量）
- 这两个变化可能互相关联，但都没有在 dashboard 上触发警报
【建议】
1. 每周留 30 分钟看"dashboard 之外"：原始 PR 评论、1:1 记录、重复出现的问题
2. 追踪渐进变化：任务粒度、上下文切换频率、技术债影响范围
3. 给"我们最近忽略了什么"这个问题留正式位置
4. 不是加更多报表，而是建立更清醒的观察方式
一个产品团队在过去一年里三次犯了类似的判断错误：看到竞品做某功能就跟风，上线后效果不佳，复盘时说"下次要先验证需求"，但下一次又重复。团队需要识别自己的判断模式。
recent_decisions:
- "Q1：跟风做社交分享功能，上线后使用率 3%"
- "Q2：跟风做 AI 聊天功能，上线后用户反馈'多余'"
- "Q3：跟风做短视频内容模块，上线后留存无变化"
decision_outcomes: "三个功能均未达到预期，复盘时都说'下次先验证需求'"
personal_factors: "团队有强烈的 FOMO（怕错过）情绪，竞品动态是主要决策输入"
=== 注意力审计报告 ===
【判断模式识别】
1. 跟风模式：竞品在做 → 跟风 → 效果不佳 → 复盘 → "下次验证" → 重复
2. 情绪模式：FOMO 驱动决策，"怕落后"让行业共识变得太像答案
3. 复盘模式：复盘结论不落地，"先验证需求"停留在口号
【渐进变化】
- 跟风频率上升：半年一次 → 每季度一次
- 决策速度加快：讨论两周 → 讨论三天就拍板
- 对"竞品在做"的敏感度在提高——需要被觉察
【弱信号】
- 用户反馈"这个功能多余"反复出现——团队没有当作模式信号
- 每次复盘的结论相同但行为不变——说明不是认知问题，是注意力结构问题
- "竞品在做"已成为默认决策触发器——需要被质疑
【决策日志模板（建议）】
| 日期 | 决策 | 触发信号 | 判断依据 | 预期结果 | 实际结果 | 偏差原因 |
|------|------|----------|----------|----------|----------|----------|
【建议】
1. 建立决策日志，记录每次重要决策的触发信号、判断依据和预期
2. 每季度对照实际结果，识别反复出现的判断偏差
3. 设计觉察练习："如果竞品不做这个功能，我们还会做吗？"
4. 把"先验证需求"从口号变成流程中的默认步骤——不验证就不讨论方案
5. 至少留一个人专门看"竞品不做但我们的用户需要什么"
第一种用法：收拢弱信号。 把访谈原话、客服记录、用户抱怨和异常路径一起交给 AI，请它归类那些仪表盘里看不见、但反复出现的小问题。AI 很适合帮你把散乱信号先收拢起来。
第二种用法：扫描慢变量。 请 AI 追踪渐进变化，例如同类情绪词是不是越来越多、某类绕路行为是不是在慢慢变成常态。AI 擅长做这种慢变量扫描，但决定哪些值得回应，还是人的注意力工作。