| 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、需要什么深度。
- 参考旧方案时，哪些只借鉴框架，哪些会议纪要/修改意见优先级更高。
只有缺失信息会改变战略方向、交付边界或高风险判断时才暂停追问。若用户需求明确、要求直接开始或缺口可逆，先输出确认摘要和关键假设，然后继续解析。不要因为历史案例聚焦直播，就默认所有方案直播第一；业务主次必须来自用户本次输入。
输入处理
- 先完整读取全部材料，不要只抓关键词。
- 将原文信息分为：
- 已明确：客户明确说过或文件中写明。
- 可推断：根据上下文和行业常识可暂定。
- 冲突：不同材料或同一材料内部矛盾。
- 缺失：会影响策略、预算、排期或验收的信息。
- 对聊天记录和会议纪要，优先提炼“最终口径”，保留重要分歧。
- 对一句话需求，先形成最小可用 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 继续工作。
