内容写作 编辑复核
客户案例事实大纲
用可核验的背景、过程和结果组织案例，不虚构客户身份、收益、评价或因果关系。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名案例内容编辑。请把项目资料整理为事实可追溯的案例大纲，只写获得授权且有记录的结果，相关性不要写成因果证明。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 背景、原问题、约束和选择标准
2. 按时间线记录实施步骤和关键取舍
3. 区分观察到的结果、归因假设和未验证影响
4. 列出引用授权、匿名化和发布前核对项
输入变量：
- 客户背景（{{customer_context}}）：提供已获授权的行业、规模和问题描述。
- 项目记录（{{project_notes}}）：提供时间线、决策和交付记录。
- 观察结果（{{observed_results}}）：提供原始指标、时间窗口和对照口径。
- 授权边界（{{permissions}}）：说明可公开的名称、数字和引用。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先拿到客户书面授权和原始指标，再写公开版本。
- 结果页面标明样本、时间和测量方式，不用单个案例承诺普遍收益。
WHEN IT FITS
适用判断
适合这些情况
- 客户愿意配合，能提供真实数据和引述。
- 已经拿到授权，可以公开客户名称或行业信息。
- 需要一份能给销售用的结构化案例。
换个做法更好
- 你手上只有访谈录音需要转成故事：用《客户访谈转案例故事》。
- 客户不愿意透露任何信息：匿名案例说服力有限。
- 还没有实际成效数据：案例会变成功能介绍。
FAILURE MODES
常见翻车与修正
- 案例里的数据是模型按「合理范围」编的。
编造客户数据是严重问题。要求所有数字来自客户提供的材料，缺失的标注「待客户确认」而不是填补。
- 把成效全部归功于产品，忽略客户自身的努力。
这会让案例失真也让客户不适。要求区分产品带来的部分和客户团队做的工作，并说明其他影响因素。
- 案例只写成功，没有实施过程中的困难。
要求包含实施中遇到的问题和解决方式，这部分对潜在客户的参考价值最高。
ACCEPTANCE
怎么判断输出合格
- 所有数据来自客户提供的材料，没有编造。
- 成效归因区分了产品作用和其他因素。
- 包含实施过程中的困难和应对。
- 标明了发布前需要客户确认的内容。
SAFETY BOUNDARY
使用边界
- 客户名称、业务数据和成效数字必须经过客户书面授权才能公开，未授权的一律匿名处理。
- 模型会把「提升明显」写成具体百分比，所有数字要有可核对的原始记录支撑。