client-validation-document

/digital-marketing-pro:client-validation-document — 第 5 部分：唯一的正式停点

脚本位置。 如果你的主机未设置 ${CLAUDE_PLUGIN_ROOT}，脚本位于此插件的 scripts/ 文件夹中，与 skills/ 并列。请使用 Python 3.10 或更高版本运行：python；如果找不到 python，则使用 python3（macOS 和许多 Linux 系统）。

此技能用于生成第 5 部分的交付成果：客户验证文档。这是整个合作过程中唯一正式向客户呈现不偏不倚的 v1 研究结果，以供客户决定接受、拒绝或修改的环节。

上下文效率

这是一个重量级技能。打开任何引用文件前，先使用 Grep 搜索，然后仅使用 offset + limit 对匹配范围执行 Read。打开文件前，先列出 ${CLAUDE_PLUGIN_DATA}/<brand>/。在会话中途重新调用时，跳过已在上下文中的文件。

这是 12 部分流程中唯一的正式停点。除非此部分已签字确认，否则不得继续执行第 6 部分及之后的内容。

此文档的内容

客户验证文档会将第 2、3 和 4 部分中最具战略影响的发现（不偏不倚的研究和四份核心文档）汇编成一份结构化的审阅文档。对于每项发现：

• 发现本身
• 证据／来源
• 接受后的拟议影响
• 客户的三种回应选项：接受／拒绝／修改／暂缓
• （对于拒绝或修改）——客户提供修正后的版本及理由

客户的回应随后会输入第 6 部分的决策矩阵，用于确定需要哪些 v2 重跑。

此文档不是什么

• 不是增长计划。 这是研究发现，而非包装成战略建议的内容。增长计划属于第 8 部分。
• 并非面面俱到。 其中只包含具有重大策略影响的发现。详细内容应放在源文档中。
• 不是幻灯片。 这是一份供客户仔细阅读并作出回应的书面文档。幻灯片无法体现所需的严谨性。
• 并非可选项。 每个合作项目都必须执行第 5 部分。不得跳过此步骤直接进入第 6 部分。

前置条件

运行此技能前：

1. 必须完成第 2、3、4 部分（或基本完成，并明确说明部分研究仍在进行）
2. 合作项目状态文件 _engagement.json 必须显示第 3 和第 4 部分的状态为 completed
3. 实时项目指令文件应已更新，包含 v1 策略事实

如果前置条件未满足，请勿生成输出。请告知用户缺少哪些内容。

文档结构

客户验证文档按发现类别组织。每个类别包含 3–8 项发现；整份文档通常涵盖多个类别中的 12–25 项发现。

第 1 节：执行简报

篇幅： 1 页。

内容：

• 本文档的目的
• 如何阅读本文档（接受／拒绝／修改／暂缓框架）
• 客户回应后会发生什么（由决策矩阵决定的第 6 部分 v2 重跑）
• 决策截止日期（通常为 7–14 天）

第 2 节：按类别划分的发现

每个类别都以结构化区块呈现其发现。类别如下：

A. 业务与战略业务单元（SBU）发现（来自 3.1）

关于业务实际情况的发现——SBU 划分、单位经济效益、价值链、增长杠杆、限制因素、风险。通常包含 3–5 项发现。

B. 受众与细分发现（来自 3.2 + 4.3）

关于目标群体、用户画像优先级、决策单元、MQL／SQL 定义的发现。通常包含 3–5 项发现。

C. 定位与传播发现（来自 3.3）

关于所选定位、信息支柱、品牌语调、禁用表达规则、敏感话题处理方式的发现。通常包含 3–5 项发现。

D. 渠道与预算发现（来自 3.4）

关于渠道选择、在市场内与市场外的划分、预算分配、渠道排序的发现。通常包含 2–4 项发现。

E. 竞争发现（来自 4.1 + 4.2）

关于竞争对手名单、竞争定位、三问结果（做得好／做得差／未涉及）的发现。通常包含 2–4 项发现。

F. 市场与客户发现（来自 4.3 和 4.4）

市场规模、客户行为模式、需求信号。通常有 2–4 项发现。

第 3 节：待解问题

中立研究无法解答、需要客户提供意见的问题。客户在此处填写答案。

第 4 节：响应机制

客户如何提交响应（通常是填写结构化响应文件，或通过会议逐项讲解）。

发现条目格式

每项发现都采用以下确切结构：

### Finding {ID}: {Short title}

**Category:** {A/B/C/D/E/F}
**Source:** {Document and step references — e.g., "3.1 Step 4, 4.1 Three-Question Output"}
**Materiality:** {High / Medium / Low}

**Finding:**
{2–4 sentences stating the finding from the unbiased research}

**Evidence:**
- {Cited source 1 with specific data point}
- {Cited source 2}
- {Cited source 3}

**Proposed implication if accepted:**
{1–3 sentences on what this means for the strategy if the client accepts}

**Client response:**

- [ ] ACCEPT — finding is correct as stated
- [ ] REJECT — finding is wrong; correction below
- [ ] EDIT — finding is partially correct; amended version below
- [ ] DEFER — needs further investigation; reason below

**If REJECT or EDIT, client correction:**
{Client fills in: what the correct finding is, with their evidence}

**If DEFER, reason and follow-up plan:**
{Client fills in: what additional research / data is needed, who is accountable, deadline}

重要性分类

每项发现都会标注重要性评级，表示响应可能带来的影响：

• 高 — 接受或拒绝该发现会显著改变渠道组合、预算、定位或受众优先级。根据决策矩阵触发 v2 重跑。
• 中 — 接受或拒绝该发现会改变战术执行，但不影响战略方向。可能触发重跑，也可能不会。
• 低 — 接受或拒绝该发现会改变措辞或示例，但不影响实质内容。不会触发重跑。

客户应重点关注重要性为高的发现；为完整起见，也会呈现中和低重要性的发现。

决策矩阵的响应分类

客户提供响应后，将其归类为决策矩阵触发项：

客户决策模式	决策矩阵触发项
任何竞争对手相关发现被拒绝，或经编辑后新增了竞争对手	competitors_changed
任何市场规模相关发现被拒绝或编辑	target_market_changed
任何细分相关发现被拒绝，或经编辑后更改了用户画像	audiences_changed
任何定位相关发现被拒绝或编辑	positioning_changed
任何预算 / 范围相关发现被拒绝或编辑	budget_or_scope_changed
任何定价或产品方案相关发现被拒绝或编辑	pricing_or_offering_changed
任何单位经济效益相关发现被拒绝或编辑	unit_economics_changed
仅有重要性为低的编辑 / 轻微措辞修正	minor_corrections_only

该技能会汇总触发项列表并运行：

python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" decision-matrix \
  --brand {slug} --id {id} \
  --triggers "{comma-separated-trigger-list}"

随后，输出将用于第 6 部分的 v2 重跑计划。

制作步骤

1. 确认前置条件 — 第 2、3、4 部分均已完成。

2. 阅读 v1 源文档：

   • part-03-four-core-documents/v1/3.1-business-and-sbu-analysis.md
   • part-03-four-core-documents/v1/3.2-segmentation-framework.md
   • part-03-four-core-documents/v1/3.3-brand-positioning-and-communications.md
   • part-03-four-core-documents/v1/3.4-dmflow.md
   • part-04-competitive-customer-market/v1/4.1-competitor-ad-analysis.md
   • part-04-competitive-customer-market/v1/4.2-competitor-positioning.md
   • part-04-competitive-customer-market/v1/4.3-customer-analysis.md
   • part-04-competitive-customer-market/v1/4.4-market-analysis.md

3. 提取重要发现。 对每份源文档，找出 2–5 项在战略层面影响最大的发现。重要性评级：优先选择高和中；仅在客户确认低重要性发现确有益处时才纳入。

4. 将发现综合整理为结构化格式。 使用面向客户的通俗语言，避免内部行话。每项发现都应独立完整，不要求客户阅读源文档。

5. 添加待解问题部分，内容取自各源文档的“待解问题”部分。

6. 添加响应机制部分，说明客户如何提交响应（建议：在文档旁附上配套的 client-validation-responses.json 文件）。

7. 将文档保存至：

   engagements/{id}/part-05-client-validation/client-validation-document.md
   

8. 生成响应模板：

   engagements/{id}/part-05-client-validation/client-validation-responses.template.json
   

   每项发现对应一条记录，决策 / 更正字段留空。

9. 在 _engagement.json 中将第 5 部分标记为 awaiting_input（而非 completed — 只有记录了客户响应后，第 5 部分才算完成）。

10. 向用户简要说明该文档、响应机制，以及通常为 7–14 天的决策期限。

记录客户端回复

当客户端返回回复（填写完成的 JSON 文件或会议中记录的口头反馈）时：

1. 将填好的回复文件保存到：

   engagements/{id}/part-05-client-validation/client-validation-responses.json
   

2. 运行 engagement-state.py decision-matrix --validation-file <path>，确定 v2 重跑计划。

3. 将第 5 部分标记为 completed。

4. 进入第 6 部分（v2 重跑）。

质量规范

1. 使用客户端听得懂的语言。 不要使用“MQL/SQL 管道漏斗架构”之类的术语。应改为“潜在客户从产生兴趣到准备购买的过程”。
2. 每项发现都应独立成篇。 客户不应需要查阅源文档才能理解发现内容。
3. 明确引用证据。 “市场数据表明……”之类的模糊说法不可接受。请引用具体来源和数据点。
4. 如实评估重要性。 不要为了让令人不适的发现更容易被接受，就将其重要性降为“低”。
5. 开放问题必须是真正的问题。 不要为了设置“开放问题”部分而捏造问题。
6. 回复机制应结构化。 客户随意撰写的邮件很难转换为决策矩阵触发条件；JSON 回复模板能让模式一目了然。

示例

示例 1：生成文档

User: We've completed Parts 2, 3, 4 for Acme. Time to prepare the Client Validation Document.

Skill response:
1. Verify pre-conditions ✓
2. Pull findings from the 8 source documents (4 from Part 3 + 4 from Part 4) using grep first to locate each category's section, then targeted Read with offset+limit — avoid bulk-Read on all 8 files up front or you'll blow the per-skill 5K-token budget
3. Extract 18 material findings across categories A–F:
   - 4 in Business & SBU
   - 3 in Audience & Segmentation
   - 4 in Positioning & Communications
   - 3 in Channel & Budget
   - 2 in Competitive
   - 2 in Market & Customer
4. 12 are High materiality, 5 Medium, 1 Low
5. 4 Open Questions identified from source docs
6. Save document at engagements/2026-q2/part-05-client-validation/client-validation-document.md (~22 pages)
7. Save response template at engagements/2026-q2/part-05-client-validation/client-validation-responses.template.json
8. Mark Part 5 as awaiting_input
9. Brief: "Document ready. 18 findings, 4 open questions. Recommend client meeting in 5–7 days for live walk-through, with responses returned within 2 weeks."

示例 2：记录客户端回复

User: Acme client returned responses. They accepted most but rejected the positioning finding (they want to keep their existing positioning) and added 2 new competitors we missed.

Skill response:
1. Read the populated client-validation-responses.json
2. Categorise responses: 16 ACCEPT, 1 REJECT (positioning), 1 EDIT (competitor list)
3. Determine triggers: positioning_changed + competitors_changed
4. Run engagement-state.py decision-matrix --triggers "positioning_changed,competitors_changed"
5. Output: triggered re-runs = 3.1, 3.2, 3.3, 3.4, 4.1, 4.2 (the union of both triggers' re-run sets)
6. Estimate cost: ~85K tokens
7. Mark Part 5 completed
8. Brief: "Part 5 closed. 6 v2 re-runs triggered. Recommend reviewing the re-run plan and approving before invoking four-core-documents and competitor-analysis with view=v2."

相关技能

• engagement-workflow — 编排 12 部分流程
• four-core-documents — 生成了正在验证的 v1 文档；第 5 部分之后将生成 v2 重跑文档
• 现有技能/Agent competitor-analysis、audience-intelligence、market-intelligence 生成了第 4 部分文档

相关参考资料

• engagement-flow-methodology.md — 第 5 部分的背景说明
• decision-matrix-rerun.md — 如何将回复转化为重跑任务
• two-views-model.md — v1 + v2 架构
• stone-vs-opinion.md — 置信度标记背景说明