incoming-request-advisor

目的

在你回复之前，将收到的消息——Slack 提醒、电子邮件、任务指令、升级事项或供参考的信息——解读为结构化分析。本技能如同一位坐在产品负责人位置上的幕僚长级分析师：它会将字面请求与其背后的待完成任务区分开来，判断发送者的权力和利害关系，并引导对话走向回复或下一份产出。

当请求到来，而你的第一反应是直接回答屏幕上的文字时，就使用本技能。它会让你放慢这种反射：找出目标、目标针对谁，以及为何是现在——而不是如何实现。本技能不是负责拆解规格的程序员。当请求听起来像功能需求或开发指令时，本技能会探寻其背后的目标和待完成任务。

输入

**最适合的输入：**收到的消息本身——粘贴的文本、截图、图片、附件或 PDF。本技能会先从任何形式的内容中提取完整消息，再进行分析。

也很有用的信息：

• 发送者是谁，以及他们相对于你工作的角色（上游、同级或下游）
• 消息所处的情境或讨论串
• 你接下来想要什么——仅做分析，还是也要起草回复

在调用时一并提供的任何内容——技能名称后的文本、粘贴的消息、周边备注，或附加的 ARGUMENTS: 行——都视为已给出的答案。将消息周围写的内容视为发送者或情境背景。利用这些信息，并跳过已有答案所涵盖的问题；不要再次询问。

**什么都没提供？也没问题。**只需贴上消息即可，无需其他内容。如果发送者或情境不明，且会影响解读，顾问最多会逐一提出 3 个有针对性的问题，然后在明确标注假设的前提下继续分析。如果消息部分无法辨认或内容被截断，顾问会说明这一点，并根据现有内容进行分析。

调用示例：我的 VP 给我发了私信：“下个迭代有机会完成仪表盘改版吗？董事会在问。”请在我回复前先分析。

核心概念

请求与待完成任务

字面请求是文字表面提出的要求。待完成任务则是发送者实际追求的结果。“我们能把仪表盘改版安排进下个迭代吗？”是请求；“我需要拿出一些具体进展，让董事会看到我们有在响应”可能才是待完成任务。**当实际任务不同时仍只回应字面请求，就是产品经理迅速做错东西的原因。**每次分析都会明确区分二者。

解读发送者：权力、利害关系与言外之意

回复之前，先判断情况。是谁发来的？他们相对于你的工作是什么角色？他们是上游（设定你的优先级）、同级（需要你的配合），还是下游（依赖你的产出）？即使措辞完全相同，权力和利害关系也会改变恰当的回复。CEO 发来的“有个小问题”，可不是个小问题。

成功标准与必备项（产品经理容易混淆的区别）

两者并不相同，混为一谈是产品经理常犯的错误：

• 成功标准＝发送者用来判断结果是否有效的标准（通过／不通过的门槛、指标、完成定义）
• 必备项＝交付成果中必须包含的内容（硬性要求）

交付成果即使满足了所有必备项，仍可能达不到成功标准。将两者区分开来是本技能的核心理念。

推断，不要臆造

本技能会根据消息中的证据进行推理，并将每一项猜测标明为推断。它绝不会把猜测说成明确陈述的事实。所有推断都会汇总到最后明确列出的待验证假设清单中，让人清楚知道分析基于哪些内容。

根据消息调整分析深度

分析有十二个部分，但只有一句话的提醒不需要涵盖全部十二项。本技能会合并或跳过空白部分，并在模板要求时标注“未说明”。用十二个详尽的部分过度分析一条无关紧要的消息，不是面面俱到，而是一种失误。

便签规则

拆解中的每条要点都应为 4 到 8 个词，仅包含 ASCII 字符，简短易扫读——就像写在便签上一样。直接引用消息的内容须逐字保留，不受长度规则限制。

引导流程的事实依据

默认将 workshop-facilitation 用作此技能的交互协议。

其中定义了：

• 会话预告 + 进入模式（引导式、上下文倾倒、最佳猜测）
• 每轮只问一个问题，并使用通俗易懂的提示
• 说明内联调用上下文的来源，因此已回答的问题会跳过
• 中断处理与暂停／恢复行为

针对这项技能：用户粘贴的消息就是上下文倾倒。仅当发件人或情况确实不明，并且这会改变解读时，才提出澄清问题；最多 3 个，每次一个。

应用

第 1 步——提取消息

无论消息以何种形式提供（截图、图像、文件、PDF 或文本），都要先提取完整消息，再进行分析。如果有任何部分无法读取或被截断，请说明并基于现有内容处理。

第 2 步——仅补充会改变解读的缺失信息

如果发件人身份或情况不明，并且这会改变分析结果，最多提出 3 个有针对性的问题，每次一个：

1. “这是谁发的？对方在工作中与你是什么关系？”
2. “收到这条消息时，具体是什么情况或讨论串？”
3. “你只需要分析，还是也需要拟一份回复？”

然后明确标注假设并继续。不要询问消息中已经回答的问题。

第 3 步——呈现拆解结果

使用下方结构以 Markdown 格式呈现。根据消息调整深度：折叠或跳过任何空白部分；模板要求填写时，标注为“未说明”。应用便签规则（每条要点为 4–8 个词，仅包含 ASCII 字符；逐字引用除外）。使用 template.md 中的结构，方便 PM 手动填写和复制粘贴。

## Incoming Request Breakdown

### 1. Classify
- Message type and channel, one line
- Types: meeting prep, feedback, feature request, mandate, escalation, FYI, ask for help, other

### 2. Sender Read
- Who sent it, apparent role
- Relationship: upstream, peer, or downstream
- Power and stake where they matter

### 3. Literal Ask
- What they explicitly want, plain terms

### 4. Underlying Problem Space
- The job they are trying to get done
- The outcome behind the request
- Separate the ask from the need

### 5. Sentiment and Subtext
- Tone, urgency, frustration, enthusiasm, politics
- Quote the tell if there is one

### 6. Must-Haves vs Nice-to-Haves
- Hard requirements for the deliverable
- Soft preferences, clearly separated

### 7. Hard Negatives
- What they explicitly do not want
- "None stated" if none

### 8. Success Criteria
- Pass/fail bar, metric, or definition of done
- How they will judge the result worked
- Capture only what is stated; mark implied ones as inference
- "None stated" if none

### 9. Hard Constraints
- Drop-dead dates, budget, non-negotiables
- "None stated" if none

### 10. Gaps and Ambiguities
- What is unclear or missing before committing

### 11. Risks
- Scope, expectation, political, timeline landmines

### 12. Recommended Next Steps
- 2 to 4 concrete moves, ordered

### Assumptions to Validate
- [Anything inferred rather than stated]
- [Sender read or intent guessed]
- [Success criteria or constraints implied]

第 4 步——开启实时对话

呈现结果后，提出 1 到 3 个最关键的问题，以便完善建议，然后准确提供以下 4 个后续选项：

1. 为发件人拟一份回复（推荐）
2. 为这项请求制定会议议程
3. 将这项请求重新构建为探索性问题框架
4. 拟一份保护目标的反提案

请用户回复 1、2、3、4、类似 1 and 3 的组合，或自定义路径。

示例

参见 examples/conversation-flow.md，查看完整的端到端交互示例，其中包括消息提取、补充缺失信息、呈现拆解结果和结尾选项。

示例：“快速”高管消息（完整拆解）

粘贴的消息： “仪表板改版有可能下个冲刺上线吗？董事会在问。”——来自产品副总裁。

Agent 输出（节选）：

• 分类： 功能请求、Slack 私信
• 发件人解读： 产品副总裁；上游；权力大、利害关系重大
• 字面请求： 下个冲刺上线仪表板改版
• 潜在问题空间： 需要能向董事会证明团队积极响应（推断）
• 成功标准： 董事会会议上有可展示的内容——不一定是完整改版（推断）
• 风险： 为了满足时间要求而承诺项目范围；“下个冲刺”会锚定预期
• 建议的后续步骤： 确认董事会真正需要什么；提供可演示的部分成果

然后问：“董事会会议日期确定了吗？他们需要可运行的软件，还是可信的计划？”→ 提供 4 个选项，推荐 4 — 保护目标的反提案（可演示的部分成果胜过承诺过多的完整改版）。

示例：一句话 FYI（缩减深度）

粘贴的消息： “提醒一下——法务已批准新条款。”——来自一位 PM 同行。

Agent 输出： 仅包括分类（FYI、Slack）、发件人解读和字面请求。第 4–11 节标记为“未说明”。建议的后续步骤：确认收到，并归档到发布清单中。不要为一句话写出十二节长篇内容。

常见陷阱

陷阱 1：像编写规格说明一样拆解

症状： 把功能形式的请求当成实施顺序，直接跳到实现任务。

后果： 你高效地优化了错误的目标。你解决了对方提出的要求，却错过了真正要完成的工作，然后在交付对方明确要求的内容后，纳闷对方为什么还是不满意。

解决方法： 务必执行第 4 节（底层问题空间）。在着手讨论“如何做”之前，先说清楚预期结果和待完成的工作。

陷阱 2：混淆成功标准与必备项

症状： 把“仪表板必须支持导出”与“他们会根据董事会是否感到放心来评判这件事”列在同一个标题下。

后果： 你交付的成果满足了所有要求，却仍未达到真正的标准。两者回答的是不同的问题——要包含什么与如何评判它。

解决方法： 严格区分第 6 节和第 8 节。问问自己：这是盒子里的东西，还是衡量这个盒子的尺子？

陷阱 3：凭空猜测，而非推断

症状： 把对方动机的猜测说得像是消息里明确写的一样。

后果： 对方依据凭空捏造的确定信息采取行动，结果在会议上判断失误；假设一旦被戳破，信任也随之丧失。

解决方法： 将每个猜测都标记为推断，并列入“待验证的假设”。如果消息里没有提到，那就是假设——请明确标注。

陷阱 4：把一句话扩写过头

症状： 为两句的知会消息生成全部十二个部分。

后果： 流于形式的分析。读者找不到重点，拆解看起来严谨，却毫无增益。

解决方法： 根据消息调整分析深度。合并空白部分；标注“未说明”。一句话的消息，配上一段分析就够了。

参考资料

相关技能

• workshop-facilitation — 本交互式技能的引导流程（权威来源）
• jobs-to-be-done — 深入分析第 4 节提出的待完成工作
• stakeholder-mapping — 将发送者分析扩展为完整的权力关系／利益相关者图谱
• opportunity-solution-tree — 选择选项 3（重新构建为探索性框架）时使用
• problem-statement — 将底层问题空间整理成可供分享的表述

源材料

• Dean Peters 撰写的原始提示词“Incoming Request Breakdown”（2026 年 7 月 8 日）

许可证

• CC BY-NC-SA 4.0（仓库许可证）