Incoming Request Advisor - 来信请求分析与需求拆解 Claude 技能

技能概述

Incoming Request Advisor（incoming-request-advisor）是一个面向产品经理的来信请求分析 Claude 技能：它把你收到的 Slack 消息、邮件、指令或升级投诉解码为结构化拆解，把字面诉求和背后的真实目标（Job-to-be-Done）分开，帮你在回复之前先找到要达成的结果，而不是急着回答屏幕上的文字。

适用场景

1. 高管加急消息先拆再回：VP 在 Slack 上问"仪表盘改版下个迭代能不能上？"，用技能读出这句话背后"需要向董事会证明响应速度"的真实目标，避免盲目承诺范围。
2. 处理客户成功的升级邮件：收到一封情绪激动的客户成功负责人升级邮件时，先完成语气、紧急度、政治因素的拆解，再决定怎么回应。
3. 解码干系人的模糊需求：干系人发来的指令听起来像开发任务单，用技能穿透字面诉求，找到它背后的成果和为什么是现在。

核心功能

1. 十二段结构化拆解：将消息分类为升级、指令、功能请求、通知等类型，依次输出发件人解读、字面诉求、深层问题空间、必备与可选条件、硬性约束、风险和推荐下一步，篇幅随消息复杂度自动伸缩——一句话的通知不会被硬凑成十二段长文。
2. 字面诉求 vs 真实目标分离：明确区分"对方要什么"和"对方想完成什么"，并单独拆开成功标准（对方如何判断结果好坏）与必备条件（交付物里必须包含什么），这两个最容易被产品经理混为一谈的维度。
3. 推论标注与后续行动：所有猜测都标记为推论并汇总在"待验证假设"清单里，绝不把猜测当事实；分析完成后可直接进入起草回复、生成会议议程、转发现式提问框架或起草保护成果的反提案。

常见问题

这个技能和直接让 AI 起草回复有什么区别？

直接起草回复是在回答消息的字面文字，容易"又快又错地做错事"。这个技能先完成结构化拆解：识别发件人的权力与利益关系、分离字面诉求和真实目标、列出风险和缺口，然后再进入回复起草。它训练的是"先找到结果再响应"的习惯，起草只是拆解之后的可选步骤。

使用时需要提供哪些信息？信息不全也能用吗？

最好提供消息原文（粘贴文本、截图、文件或 PDF 都可以），外加发件人身份和所处情境。如果只有消息本身也能用：技能只会在发件人或情境确实影响判断时提问，最多 3 个、一次一个，随后以明确标注的假设继续分析。调用时附带的上下文会被直接采信，不会重复追问。

分析结果包含哪些内容？可以直接拿来回复吗？

结果是十二段式的 Markdown 拆解：消息分类、发件人解读、字面诉求、深层问题空间、语气与潜台词、必备与可选条件、硬性约束、缺口与风险、推荐下一步，以及一份"待验证假设"清单。所有推论都被明确标注，因此你可以先用它核对假设，再选择直接起草回复、做会议议程、转发现式提问或起草反提案。

技能边界

• 它是分析顾问，不是程序员：不会把功能型请求拆成实现任务清单，而是先找成果和为什么。
• 推理基于消息中的证据，无法验证的部分一律标注为推论，需要使用者自行确认。