Brief Analysis

Brief Analysis — 需求归一与对齐

把任何格式的客户输入转成可执行的项目需求卡，识别目标矛盾、信息缺口、工作假设和下一步任务。

开工前确认

开始正式解析前，先检查任务口径。至少覆盖：

• 用户真正要做什么，聚焦哪个品牌、产品、品类、平台和业务优先级。
• 本地资料有哪些，每份资料用于什么；哪些部分禁止用网络公开数据替代。
• 逐板块资料来源矩阵：行业、竞品、消费者、人群、关键词、价格段、直播、商品卡、千川、KOL、Campaign、TVC、预算/KPI 分别是“仅本地上传 / 仅网络公开 / 本地为主+网络补充 / 网络为主+本地校验”。
• 是否允许联网，以及只允许在哪些未被本地资料覆盖的部分联网。
• 给谁看、用于什么决策、默认交付为 Markdown .md、需要什么深度。
• 参考旧方案时，哪些只借鉴框架，哪些会议纪要/修改意见优先级更高。

只有缺失信息会改变战略方向、交付边界或高风险判断时才暂停追问。若用户需求明确、要求直接开始或缺口可逆，先输出确认摘要和关键假设，然后继续解析。不要因为历史案例聚焦直播，就默认所有方案直播第一；业务主次必须来自用户本次输入。

输入处理

1. 先完整读取全部材料，不要只抓关键词。
2. 将原文信息分为：

• 已明确：客户明确说过或文件中写明。
• 可推断：根据上下文和行业常识可暂定。
• 冲突：不同材料或同一材料内部矛盾。
• 缺失：会影响策略、预算、排期或验收的信息。

1. 对聊天记录和会议纪要，优先提炼“最终口径”，保留重要分歧。
2. 对一句话需求，先形成最小可用 Brief，再列追问。

信息提取维度

| 维度 | 内容 | 必须程度 | |---|---|---| | 品牌与业务 | 品牌名、行业、产品类别、商业模式、客单价 | 必须 | | 项目类型 | 新品上市、节点 Campaign、社媒运营、直播、年度规划、分析报告等 | 必须 | | 目标 | 业务目标、传播目标、转化目标、优先级 | 必须 | | 目标受众 | 核心人群、机会人群、地域、消费能力、痛点 | 必须 | | 产品/卖点 | USP、RTB、价格、货盘、合规表达、禁区 | 必须 | | 竞品 | 直接竞品、替代竞品、客户提到的参考对象 | 尽量 | | 渠道 | 抖音、小红书、微信、微博、B站、电商、线下等 | 必须 | | 时间 | 提案日、上线日、节点、审核周期、素材交付期 | 必须 | | 预算 | 制作、达人、媒介、样品、机动 | 尽量 | | 资产 | 品牌规范、历史案例、素材、店铺/账号、数据后台 | 尽量 | | 限制 | 合规红线、禁用词、法务审核、行业监管、品牌偏好 | 必须确认 | | 成功标准 | KPI、验收方式、客户内部决策标准 | 必须确认 |

Brief 质量评级

• A 级：目标、受众、产品、渠道、时间、限制、验收方式明确，可直接进入策略和执行。
• B 级：缺 1-3 个关键项，但能以工作假设推进，需要同步确认。
• C 级：目标冲突或缺失过多，必须先做对齐工作坊或追问清单。

常见矛盾与处理

| 矛盾 | 表现 | 处理 | |---|---|---| | 品牌 vs 转化 | 又要声量又要短期 GMV | 分阶段目标，拆 KPI 权重 | | 人群过宽 | “18-45 岁女性” | 拆核心人群和机会人群 | | 卖点过多 | 客户给 8-10 个卖点 | 提炼主卖点、支撑卖点、禁用卖点 | | 预算不匹配 | 低预算参考高制作案例 | 说明差距，给替代执行路径 | | 时间不合理 | 过短周期要求大制作/多平台 | 给风险、压缩方案和必须取舍 | | 口径冲突 | 销售、市场、老板说法不同 | 标注冲突，建议确认最终决策人 |

输出格式

# 项目需求卡

## 1. 一句话项目判断
[用一句话说明这是一个什么项目，真正要解决什么问题。]

## 2. 已知信息
| 维度 | 内容 | 来源片段/依据 | 可信度 |
|---|---|---|---|

## 3. 关键矛盾
| 矛盾 | 影响 | 建议处理 |
|---|---|---|

## 4. 工作假设
| 假设 | 为什么可先这样假设 | 影响范围 | 需确认方式 |
|---|---|---|---|

## 5. 信息缺口
| 优先级 | 缺失信息 | 为什么重要 | 建议追问 | 能否先推进 |
|---|---|---|---|---|

## 6. 资料来源矩阵
| 分析板块 | 建议资料来源 | 是否需要用户授权联网 | 备注 |
|---|---|---|---|

## 7. Brief 质量评级
评级：[A/B/C]
理由：[3 条以内]

## 8. 下一步建议
- 立即启动：[可开始的研究/策略/执行任务]
- 等待确认：[必须确认的信息]

规则

• 引用客户原话时保持短句，避免长段粘贴。
• 不因信息缺失而停住；只有会改变方向的缺口才要求先追问。
• 将“客户想要的交付物”和“客户真正要达成的业务结果”分开写。
• 输出必须能直接喂给 $opc-proposal 或 $task-decomposition 继续工作。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mabzhang
• Source: mabzhang/opc-toolkit
• License: MIT

Install and usage instructions live in the source repository linked above.