brief-analysis

name	brief-analysis
description	Parse and normalize marketing inputs into execution-ready requirement cards. Use for client Briefs, Brand Briefs, Campaign Briefs, WeChat chat records, meeting notes, voice-note summaries, scattered requirements, or one-line marketing tasks. Trigger for: $brief-analysis, Brief, 需求解析, 客户需求, 项目需求, 微信聊天记录, 会议纪要, 信息缺口, requirement analysis.

Brief Analysis — 需求归一与对齐

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

开工前确认

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

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

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

输入处理

1. 先完整读取全部材料，不要只抓关键词。
2. 将原文信息分为：
   • 已明确：客户明确说过或文件中写明。
   • 可推断：根据上下文和行业常识可暂定。
   • 冲突：不同材料或同一材料内部矛盾。
   • 缺失：会影响策略、预算、排期或验收的信息。
3. 对聊天记录和会议纪要，优先提炼“最终口径”，保留重要分歧。
4. 对一句话需求，先形成最小可用 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 继续工作。