产品文案撰写：客户案例不能公开时怎样写清方法而不伪造案例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5b986d948e91.html
📄
产品文案撰写：客户案例不能公开时怎样写清方法而不伪造案例
可以写，但前提是把“案例”降级为“方法说明”：不声称某个客户发生过什么，只描述一类问题在什么条件下、按什么顺序处理、每一步留下什么可验证的结果。若你无法说明方法在哪种输入下会失败，或无法给出任何可被第三方复核的中间产物，那么这篇文案就只能算经验随笔，不能承担证明产品有效性的功能。
先分清“不能公开”卡住的是哪一层
客户案例通常包含四层信息：客户身份、业务背景、使用过程、量化结果。保密协议、行业惯例或客户内部审批，往往只卡住其中一两层，而不是全部。写之前先确认卡点：
- 身份不能出现，但行业、规模区间、原有关键指标量级可以脱敏描述。
- 结果数字不能引用，但处理步骤、判断依据、交付物形态通常可以写。
- 过程细节涉及客户内部系统，可以抽象为“输入条件—判断规则—输出物”三段，不还原具体界面和字段名。
- 连业务场景都不能提，那就放弃案例叙事，改为写方法本身适用的条件与边界。
判断标准很简单：删掉客户名称后，这段内容是否仍能让读者判断“我的情况是否适用”。如果不能，说明你写的只是身份背书，不是方法。
用“条件—动作—可验证产物”替代案例叙事
不伪造案例的写法，是把叙述重心从“谁做成了什么”移到“在什么条件下做什么、留下什么”。一个可用的结构是：
- 适用条件：说明这套方法在什么输入下成立，例如原始素材完整度、决策权限、时间窗口。条件写得越具体，越不需要靠案例撑可信度。
- 动作顺序：写读者下一步该做什么，而不是你当时按什么时间顺序做了什么。动作要能被执行，例如“先列出所有对外口径不一致的句子，再逐条标注来源”。
- 可验证产物：每一步产生什么可以被检查的东西，例如一份口径对照表、一版标注过的草稿、一组待确认问题清单。
假设一个场景：某团队为内部工具写产品文案，客户不允许公开名称和用量数据。可写的版本是——“当原始需求文档中存在三处以上互相矛盾的功能描述时，先不写卖点，而是产出一张矛盾点清单，标注每处矛盾的出处页码，交由产品负责人确认后再进入文案结构设计。”这里没有客户、没有数字，但读者能判断自己是否遇到同样条件，也能立刻执行第一步。
什么情况下这套写法会失效
反例是：你的产品价值恰恰依赖“别人已经在用”这一事实，而读者所在品类采购风险高、决策链长，此时纯方法说明无法替代同行验证。比如面向受监管行业的软件，采购方往往要求看到同行业已上线案例才进入下一轮。这种情况下，继续用脱敏方法文硬撑，读者会认为你在回避，转化反而更差。
遇到这种失效条件，正确的动作不是编造一个“某大型企业”，而是换目标：把文案任务从“说服采购”改为“筛选出愿意先做小范围验证的读者”，并在文中明确写出你无法提供公开案例这一事实及其原因。这一步会损失一部分读者，但留下的读者预期更准确，后续沟通成本更低。
一个可执行的最小动作
如果现在就要动笔，先做这一件事：从你手上任何一个不能公开的项目里，抽出“输入条件”和“判断规则”两栏，写成两句话，删掉所有专有名词。然后检查这两句话是否能让一个陌生人判断自己是否适用。若不能，补充条件；若能，再往后写动作和产物。
这个动作的结果会直接决定下一步：条件写得出来，说明你可以写方法文；条件写不出来，说明你对方法的理解还停留在个案层面，此时应先去补一次内部复盘，而不是先写文案。方法文的质量上限，取决于你对适用条件的诚实程度，而不取决于你能否找到一个可以署名的客户。
