产品文案撰写：怎样收集内容所需的证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dcdfb97f68ed.html
📄
产品文案撰写：怎样收集内容所需的证据
收集产品文案所需的证据，核心做法是先把文案中每一个需要读者相信的断言列出来，再为每条断言找到可追溯、可复核、可引用的来源，最后按“能公开引用、只能内部参考、暂时无依据”三类归档。在多人协作场景中，这一步的关键不是找到最多材料，而是让写作者、审核者和产品方对“哪句话有依据”达成同一份清单，从而减少反复修改。
准备阶段：把文案断言拆成证据需求清单
不要先收集资料再想怎么写，而要先从文案结构反推证据。把计划中的文案拆成若干断言，例如“适用于某类场景”“操作步骤为三步”“与上一代相比某项指标提升”“支持某种格式导入”。每一条断言后面标注证据类型：产品实测记录、官方规格文档、客服问答记录、用户授权案例、第三方检测报告。
多人协作时，建议用一张共享表格，字段至少包括：断言原文、证据类型、负责人、来源位置、可引用范围、状态。状态分为“已核实”“待核实”“无依据”。这样写作者不必在群里反复问“这句话能不能写”，审核者也能直接看到依据。
实施阶段：按证据强度分级采集
证据强度可以按可复核程度排序：
- 强证据：产品后台可复现的操作记录、官方发布的规格参数、带时间戳的测试日志、经授权的用户原话。
- 中等证据：内部培训材料、客服常见问题汇总、销售反馈记录。这类材料可用于内部对齐，但对外引用前需要确认是否允许公开。
- 弱证据：个人记忆、口头转述、无法定位出处的截图。只能作为线索，不能直接写进对外文案。
采集时给每条证据记录三件事：来源位置（文件第几页、后台哪个页面、记录编号）、获取时间、获取人。缺少这三项，后续审核就无法判断它是否仍然有效。
验证阶段：用交叉核对替代单点确认
一条证据只有一个来源时，先标记为“待交叉核对”。验证方法包括：让另一位协作者按同样路径重新获取一次；把规格文档与实测结果对照；把用户原话与授权范围对照。如果两个来源冲突，不要直接选看起来更有利的那条，而应记录冲突点，交由产品负责人确认。
判断结果可以这样处理：
- 两个独立来源一致，标记“已核实”，可写入对外文案。
- 只有一个来源且无法复现，标记“待核实”，文案中改用限定表述或暂时删除。
- 来源明确但引用范围受限，标记“仅内部参考”，不进入对外版本。
这里最关键的一步是“可复现”：换一个人、按记录的位置重新走一遍，能否得到同样结果。能复现，证据才真正可用于多人协作交付。
维护阶段：让证据清单随文案版本更新
产品功能、规格和授权范围会变化，证据清单也要有维护动作。每次文案改版时，同步检查清单中“已核实”条目是否仍然成立；对涉及具体指标、具体版本的断言，标注适用版本或时间范围。假设某条文案写“支持批量导入”，而该功能仅在特定版本可用，就应在证据清单中注明适用版本，避免旧版本用户产生误解。
协作交付前，做一次最终检查：文案中每个数字、每个“支持”“适用”“提升”是否都能在清单中找到对应条目；找不到的句子，要么补证据，要么改写，要么删除。这样交付的不是一份“看起来没问题”的文案，而是一份依据清楚、返工可控的文案。
下一步，可以从现有文案中随机抽取五条断言，按上面的表格建一次证据清单，先跑通一轮协作流程，再决定是否扩展到全部文案。
