把客户真实生产部署写成工程师信服的技术案例研究（含证据台账…

当需要将客户的真实生产部署、迁移或上线转化为可发布的技术案例研究时，用证据纪律和坦诚的局限说明写出工程师愿意相信的故事。

适用场景

解决思路

1. 先做范围检查：确认对象是外部采用者；若是自家系统、自家项目进展、教程/快速上手、更新日志/迁移指南或作者个人作品集，则改用对应技能。
2. 在动笔前对案例负责人做访谈，一次一个问题，尽量用多选题，直到能判断故事是否可发布；问题包括：采用者是谁、是否已上生产、访谈对象及其角色、已有证据、变化数字及可背书者、命名/引用/logo 授权人及耗时、安全或法律审查、发布渠道及是否需要销售单页、读者应记住的一句话、上线截止日期、一次性还是故事库、投入上限。
3. 若有持久记忆，存储第 5、6、7 项答案（授权、审查、发布渠道），因为它们是每个客户和项目长期不变的约定。
4. 按五道资格门筛选故事：生产而非试点、有可测量的变更前基线、有愿意发声的具名人物、有读者可复用的决策、有可行的审批路径；多个候选时按“先追哪个故事”排序，不合格者直接删除或降级，不要靠编辑挽救。
5. 先从自有证据重建故事：在通话前阅读工单、issue、PR 和遥测数据，带着具体细节去确认，而不是带着空白问题去填。
6. 并行开启审批轨道：先读合同中的宣传条款，再询问谁批准引用、指标和安全审查，答案决定可写哪个版本。
7. 按 source-interview-guide 进行来源访谈，征得同意后录音并保留转录稿。
8. 构建证据台账：每条声明一行，记录声明、证据类别、测量工具、可复现者；必须在起草前完成。
9. 与负责人确认故事主线和标题数字；此时修改成本低，1200 字后成本高。
10. 按 case-study-outline 的主线起草，引用逐字取自转录稿。
11. 根据访谈中关于成本和未解决问题的回答撰写局限部分，绝不跳过。
12. 运行 humanizer 处理，再跑发布门；迭代直到每项检查通过。
13. 按 approval-and-anonymization 发送审批，附标记好的决策清单和有日期的截止时间；应用其修改后打包衍生版本。
14. 默认交付六部分，按顺序：结论行、证据台账、草稿、审批包、门禁报告、衍生版本；先出结论和台账再起草。
15. 数字纪律：每个数字必须带四个属性——变更前值、变更后值、产生它的工具、测量窗口；证据类别分 measured、partially measured、reported、directional，并按规定写法处理。
16. 两个来源可靠的数字胜过六个松散数字；客户不批准绝对值时用比率（如“基础设施成本降低三分之一”），周期时间和可靠性数字比原始量更易传播。
17. 不要计算客户未确认的数字、不要把一个月结果年化、不要在客户同时改了三件事时把业务成果归因于你的产品。
18. 主线采用 Challenge / Solution / Results，并补上模板遗漏的三节：被否决的替代方案、指标来源、局限；按 1200-1800 词目标分配八节字数：标题成果约 60 词、采用者与系统约 120、变更前状态及成本约 250、为何选此技术及被否决替代方案约 200、构建内容（架构、命名组件、顺序）约 400、结果及方法约 200、成本与未解决问题约 200、下一步约 70。
19. 局限部分写读者会继承的成本而非计划：迁移投入的工程师周数、双跑期、上线时坏掉的东西、团队重新培训的内容、刻意未迁移的工作负载、仍不工作的部分，并说明谁不应照搬此架构。
20. 审批轨道：先读合同宣传条款；标准自助 SaaS 条款通常已授权客户名称、logo 和“他们是客户”的声明，但不含引用、指标、架构描述和运行叙事，需单独索取。
21. 四项权限常分属四人：工程师同意被引用、其经理同意消耗团队信誉、传播部门批准公司名和 logo、安全或法律审查技术细节；首次接触就问清各由谁持有。
22. 预先删减安全审查可预见会砍掉的内容：绝对基础设施规模和成本、内部服务名、工单 ID、仪表盘 URL、被否决替代方案中的竞品名、暗示变更前存在安全弱点的内容。
23. 发送完整草稿，标记决策、附有日期的截止时间和默认选项。
24. 命名被拒时逐级下降匿名化阶梯，而非放弃故事：具名公司和工程师→具名公司不具名工程师→不具名公司加识别性描述→仅类别描述→无客户模式文章；取审批允许的最高一级，把下降视为损失而非权衡。
25. 发布前运行 humanizer，但逐字保留所有引用、数字、版本字符串、组件名和架构描述；被 humanize 的引用就是伪造引用。
26. 发布门七项检查全部通过才发布：每条声明已分类、每个数字有工具和窗口、至少一条具体局限、有替代方案节、每条引用逐字且署名确认、公司名/logo/引用/安全审查的审批证据在案、零无支撑的夸张词；报告失败项和所做修改后重查。
27. 发布前两次人工阅读：被访谈工程师确认技术准确性，账户外人员检查无内部术语也能理解。
28. 衍生版本在审批前就问清需要哪些，以便许可覆盖；按复用回报排序：文档交叉链接、销售单页、社区帖子、会议或网络研讨会材料。
29. 把研究的原子（每个指标、每条引用、架构图）连同叙事存入证据库，带公开/私有标记；后续资产从原子取用。
30. 付费或广告场景的再发布通常需单独许可；复用超过约 18 个月的研究前重新核实，对快速迭代或流失的采用者缩短期限。
31. 按失败模式表排查：读起来像证言、客户砍掉一半数字、审批拖数周、工程师公开质疑、引用像营销、访谈后故事夭折、数字夸大、客户质疑“已批准”研究、局限部分空洞、流失客户的研究仍在线。
32. 用是否推动评估前进而非流量来衡量：销售/方案工程师在哪个阶段实际发送、阅读率和链接点击、入站参考请求、采用者是否自行传播、故事库对主要用例和采用者规模的覆盖；不要把收入归因于单个案例研究。
33. 需要时参考配套技能：tech-talk-outline、technical-video-script、tech-podcast-interview-prep、devrel-content-calendar、tech-press-relations，以及 source-interview-guide、case-study-outline、approval-and-anonymization、evidence-and-sources 等参考文件。

适用边界 · 注意事项

• 对象是自家系统且无外部采用者时，应改用 engineering blog post 技能。
• 故事是自家项目的持续进展时，应改用 build-in-public 技能。
• 读者需要学习或安装某物时，应改用教程或快速上手指南；材料是“v2.4 发布了什么”或“如何从 v1 迁到 v2”时，应改用更新日志或迁移指南技能。