專業 BA 方法論案例：研究內容工廠客戶試點需求分析
专业BA方法论--案例
這份研究內容工廠客戶試點 BRD 案例，展示如何把內容方對生產速度、數字錯誤及 AI 合規的訴求，拆解為業務目標、流程規則和系統需求。試點期設定 2–3 周，採託管代跑，只接公共數據源；驗收目標包括成稿週期不超過 48 小時、數字溯源覆蓋率至少 90%、合規詞表零命中，以及編輯終審可發布率至少 75%。
业务需求文档（BRD）：研究内容工厂 · 客户试点项目
0. 文档目的与范围
回答四个问题：为什么做、做什么、不做什么、怎样算做成。
本需求不是来自客户的一句话「我们想用 AI 自动分析市场」，而是经过业务访谈与现状调研后，对客户真实业务流程的翻译。依据方法论的原则：先弄清真实业务，再决定哪些问题用流程优化、制度调整或软件开发解决——本文档区分了这三类。
范围：首单试点（2-3 周，托管代跑形态）。多租户、客户私有数据接入、自动发布为明确出界项（见 §8）。
1. 业务目标（Step 01）
1.1 客户原始诉求（访谈原话）
客户（一家面向个人投资者的教育/内容服务机构，下称「内容方」）在首次沟通中只说了三句话：
- 「我们的研究内容生产太慢了，跟不上市场节奏。」
- 「小编写的东西经常被读者挑数字错误，很伤品牌。」
- 「我们想用 AI，但又怕 AI 编数字、乱荐股出合规事故。」
BA 判读：这三句话各自指向不同的业务问题，不能合并成「买一个 AI 写作工具」：
| 原话 | 背后业务问题 | 解决手段归属 |
|---|---|---|
| 「太慢」 | 生产节奏问题：选题→成稿周期 2-5 天，错过事件热度窗口 | 流程再造 + 软件（自动研究组织） |
| 「被挑数字错误」 | 质量与信任问题：数字无来源、核验靠人工 | 软件（机器质量门）+ 制度（编辑终审规则） |
| 「怕 AI 荐股」 | 合规风险问题：无前置合规扫描，出事靠事后删稿 | 制度（红线入合同）+ 软件（合规词表阻断） |
1.2 业务目标（可验证表述）
| # | 目标 | 衡量指标 | 基线（AS-IS） | 目标（试点验收） |
|---|---|---|---|---|
| G1 | 缩短选题→可发布成稿周期 | 小时 | 2-5 天 | ≤ 48 小时（含编辑终审） |
| G2 | 数字论断可回溯 | 数字溯源覆盖率 | ~0%（人工核验抽查） | ≥ 90%，机器逐篇校验 |
| G3 | 合规风险前置拦截 | 荐股价词表命中数 | 事后人工审，无清单 | 交付时零命中（硬门） |
| G4 | 跑通人机协作流程 | 编辑改稿次数 | — | 平均每篇 ≤ 1 次（软性标准） |
成功定义：试点期产出 4-8 篇成稿全部通过机器硬门，编辑终审可发布率 ≥ 75%，且内容方能在案例复盘中复述出「可信度留痕」差异点。
2. 现有流程调研 · AS-IS（Step 02）
调研方式：与内容方主编、2 名编辑、1 名合规人员的访谈 + 对其现有工作表格与发布制度的走查。以下为实际运作（AS-IS），非制度文本上的「应该怎么做」——这是方法论强调的关键区别。
2.1 现有流程（事件驱动型研究内容生产）
编辑盯盘/刷资讯 发现热点（如「某板块资金连续净流入」）
→ 口头/群里报题，主编拍板选题（无书面标准）
→ 小编手工查行情网站、截图、抄数字（来源不落档）
→ 小编写稿（800-1500 字），数字凭抄录
→ 主编审稿（重点看行文，数字抽查）
→ 合规审（有合规事故后才逐字看，平时抽审）
→ 发布；读者挑错 → 删稿/更正声明
2.2 现状数据点
- 月产研究类内容 12-18 篇，从报题到发布中位数 3 天；
- 上半年读者指出数字错误的更正 7 次（每篇错误稿平均引发 2-3 条负面评论）；
- 编辑核验一篇稿的数字耗时约 40 分钟，且核验结果不留痕——下一篇同样题材还要重查；
- 无合规词表，禁语靠编辑记忆和一篇内部注意事项文档。
3. 业务流程模型（Step 03）
3.1 参与角色
| 角色 | 所属 | 在流程中的动作 |
|---|---|---|
| 主编 | 内容方 | 选题池确认、终审、发布决定 |
| 编辑 | 内容方 | 题材方向输入、每篇改稿判断、读者侧表述把关 |
| 合规负责人 | 内容方 | 红线最终责任（读者侧） |
| 研究组织（AI 多人格系统） | 服务方 | 观察→假设→研究→批评→评审全流程，产 artifacts |
| 成稿引擎（Composer） | 服务方 | artifacts → 成稿 md/HTML + 机器质量门 |
| 平台运维 | 服务方 | 每日研究调度运行、交付打包 |
3.2 TO-BE 主流程（含判断条件与异常分支）
[选题池] 主编确认 1 类题材方向（试点期固定，如「资金流异动」）
↓
[自动研究] 平台每日运行，观察员在题材内发现异常 → 立项（研究线）
├─ 异常分支 A：cn 队涉及新因子立项权争议题材 → 跳过，只续已有研究线
↓
[研究执行] 假设可证伪化 → 工具调用留痕 → 批评/评审轮
├─ 异常分支 B：评审 reject / 判据不可测 → 成稿如实写「被否决/不可判」※这是特性不是缺陷
↓
[机器质量门] 成稿引擎生成稿件，自动跑两道门：
├─ 门1 数字溯源覆盖率 <90% → 自动重试一次 → 仍不过 → 回落确定性模板
└─ 门2 合规词表命中 → 阻断重写（重试一次，再命中回落模板）
↓
[打包交付] 按约定周期打包：成稿 + 事实来源清单 + 过程时间线 + 双门校验结果
↓
[编辑终审] 客户编辑判断相关度/风格/结构
├─ 软性问题 → 每篇可要求 1 次改稿
└─ 机器门问题（数字/合规）→ 服务方无限次修正（责任在服务方）
↓
[发布] 内容方自行发布（平台不接触发布渠道）
3.3 数据与信息流
| 数据 | 来源 | 处理 | 流向 |
|---|---|---|---|
| 行情/资金流/情绪数据 | 服务方已接入的公共数据源 | 研究组织工具调用，逐次留痕 | 成稿证据索引（脚注可点开验证） |
| 研究 artifacts | 平台 qrteam 库 | Composer 聚合成稿 | 交付包 + 过程时间线 |
| 质量门校验结果 | Composer 自动校验 | 溯源覆盖率 + 词表扫描 | 随交付包附机器可复核报告 |
| 选题方向/终审意见 | 内容方 | 人工输入 | 服务方排产/改稿依据 |
| 客户私有数据 | —— | 不接入（试点出界） | —— |
4. 问题与根因分析（Step 04）
| # | 现状问题 | 根因（5-Why 收敛） | TO-BE 对策 | 手段类型 |
|---|---|---|---|---|
| P1 | 成稿周期 2-5 天 | 研究与写作串行依赖单个小 编手工查数 | 自动研究组织 7×24 运行，事件发生时研究已在跑 | 软件+流程 |
| P2 | 数字错误 7 次/半年 | 数字来源不落档，核验不可复用 | 机器质量门 G2：数字逐个回溯证据，覆盖 <90% 阻断 | 软件 |
| P3 | 合规靠事后删稿 | 无前置词表、无责任划分 | 词表阻断 + 红线写入 SOW §5（荐股价内容侧责任划分） | 制度+软件 |
| P4 | 编辑核验耗时 40 分钟/篇 | 核验对象是「句子」而非「证据」 | 终审对象改为「证据已机器校验的稿」，编辑只判内容判断 | 流程 |
| P5 | 不利结论被修饰成正面 | 无独立评审环节，写作者倾向自证 | 评审人格一票否决 + reject 也如实成稿（演示故事 B 已验证该纪律） | 软件+制度 |
5. 目标流程 · TO-BE 关键业务规则（Step 05）
业务规则清单（判断条件 / 限制 / 例外），编号供 FRD 与测试用例引用：
| 规则ID | 规则内容 | 违反后果 |
|---|---|---|
| BR-01 | 成稿中所有数字性论断必须回溯到研究档案证据条目，覆盖率 ≥90% 方可交付 | 自动重试→回落模板→仍不过不交付 |
| BR-02 | 合规词表（买入/卖出/建仓/目标价/止损/仓位建议等 16 词）命中即阻断 | 同上；交付包附扫描结果 |
| BR-03 | 假设被证伪或判据不可测时，成稿必须如实呈现，禁止修饰为正面结论 | 属红线，写入合同 |
| BR-04 | 内容定位为研究过程与方法论报道，不给买卖点/目标价/仓位/收益承诺 | 红线，写入合同 |
| BR-05 | 软性质量问题（风格/相关度）每篇限 1 次改稿；机器门问题不限次且责任在服务方 | SOW §4 |
| BR-06 | 试点期题材固定为 1 类；新增题材属范围变更，需双方书面确认 | 变更管理 |
| BR-07 | 现场演示/交付中的研究线避开 cn 队「新因子立项权争议」题材，只选已有研究线 | 选材规则 |
RACI 职责矩阵
| 活动 | 服务方平台 | 服务方BA/运维 | 客户主编 | 客户编辑 | 客户合规 |
|---|---|---|---|---|---|
| 选题池确认 | I | C | A/R | C | I |
| 研究执行与留痕 | A/R | R | I | I | – |
| 机器质量门 | A/R | R | I | I | I |
| 打包交付 | R | A/R | I | I | – |
| 每篇终审 | I | C | A | R | C |
| 发布与读者侧合规 | – | – | A | R | R |
| 红线（BR-03/04）终责 | R | R | I | I | A |
6. 需求清单（Step 06：业务需求 → 系统能力）
按方法论转化链：业务目标 → 业务规则 → 功能需求。试点复用已建成的平台能力（见 demo-spec §2/§4），新增需求集中在交付协作层。
6.1 功能需求（FRD 摘要）
| ID | 需求 | 溯源 | 现状 |
|---|---|---|---|
| FR-01 | 按客户题材选题并排产（题材内自动发现 + 避开争议题材） | G1, BR-07 | ✅ 平台已有 |
| FR-02 | 成稿生成（800-1500 字，结构：现象→假设→检验→评审→局限，证据脚注 E1..En） | G2 | ✅ compose.py |
| FR-03 | 数字溯源机器校验（覆盖率报告随交付） | G2, BR-01 | ✅ |
| FR-04 | 合规词表前置扫描（16 词，报告随交付） | G3, BR-02 | ✅ |
| FR-05 | 周期打包交付：成稿 md/HTML + 事实来源清单 + 过程时间线 + 双门报告 | G1 | ⬜ 需按客户节奏打包（现为演示货架） |
| FR-06 | 改稿工作流：记录编辑意见→改稿→重跑双门→再交付（软性 1 次限制的执行） | G4, BR-05 | ⬜ 试点期人工流程，工具化留 v2 |
| FR-07 | 交付追踪表：每篇状态（研究生成/双门通过/待终审/已改稿/可发布） | G4 | ⬜ 轻量新增 |
6.2 用户故事与验收标准（示例，验收以 SOW §4 为准）
US-01（编辑）：作为编辑，我想在成稿里点开任何一个数字看到它的来源工具调用，以便 40 分钟的核验降为抽查，并且能向读者证明数字可信。
验收：① 每篇证据索引零死链（DOM 断言）；② 数字溯源覆盖率报告 ≥90%；③ 覆盖率不达标时该篇不进入交付包。
US-02（主编）：作为主编，我想看到假设被否决的研究也成稿，以便用「系统敢否决自己」建立读者信任。
验收：① reject/不可判 结局如实出现在成稿与时间线；② 交付包含至少 1 篇非 promoted 结局的成稿（选材保证三结局覆盖）。
US-03（合规负责人）：作为合规，我想在稿子到我之前就知道荐股价词表已零命中，以便把审稿精力放在表述而非禁语。
验收：① 每篇附词表扫描结果；② 命中阻断有留痕（重试/回落记录）。
US-04（主编）：作为主编，我想知道每篇改稿用了几次机会，以便管理试点期的协作纪律。
验收：① 交付追踪表区分「软性改稿（计 1 次）」与「机器门修正（不计次）」；② 软性超 1 次的请求按范围变更处理（BR-06）。
7. 非功能需求与约束
-
形态约束：v1 托管代跑——客户收到成稿包，不含平台访问；平台在服务方环境运行（成本已计量：单篇全链 <¥20，定价锚人力，见
cost-pricing.md）。 - 数据边界：仅公共数据源；客户私有数据不接入。
- 节奏约束：QR 研究单 run 31-53 分钟；承诺 48 小时周期时须含此余量。
- 语言：v1 中文。
- 不做：用户系统/多租户、debate 辩论线、自动发布到任何渠道。
8. 验收与效果验证（怎样证明改变有效）
方法论要求 TO-BE 设计回答「如何验证改进效果」，验收对照 §1.2 指标：
- 硬门（机器可复核，逐篇）：数字溯源 ≥90% + 合规词表零命中——两报告随交付包，客户可独立复核。
- 软门（编辑判断）：终审可发布率 ≥75%；软性改稿平均 ≤1 次/篇。
- 业务指标（试点复盘）：选题→可发布周期 ≤48h vs 基线 2-5 天；读者数字类更正 = 0。
- 差异点确认：试点复盘会上，客户方能复述「可信度留痕」差异点（对应 demo-spec 验收第 3 条的 B2B 版）。
9. 开放问题（待客户确认）
| # | 问题 | 影响 | 建议 |
|---|---|---|---|
| Q1 | 交付节奏：每周打包 vs 一次性 | FR-05 排产 | 建议每周，保留中途校正机会 |
| Q2 | 试点题材首选（资金流异动/情绪极值/行业轮动） | 选材与基线 | 建议资金流异动（演示线证据最厚） |
| Q3 | 试点后订阅计价（按篇/按月） | 商务 | 另行报价，不阻塞试点启动 |
本文档按「按项目规模和风险选择合适方法」原则裁剪：试点规模小、硬门可机器复核，故 BRD 与 FRD 合体、流程用文字模型而非完整 BPMN；签约时以 SOW-pilot-template.md 为合同附件，本文档作为其需求基线。
來源：DEV Community · dev.to