让AI解释同一技术概念，先写清读者要学会什么
把技术说明交给AI，再要求“分别解释给业务同事和工程师”，经常只得到一版少术语、一版多术语的文章。我更愿意先补上一个问题：读完以后，每位读者需要做成什么事？答案不同，解释的入口、必要细节和结束位置才会真正不同。
AI生成概念配图
用学习目标定义读者
Google的技术写作课程建议先明确读者已有知识与需要学会的内容，并提醒角色不足以完整定义读者，还要考虑他们对领域的熟悉程度。我据此给AI一张简短的“读者卡”：当前任务、已掌握概念、尚不熟悉内容、读完要做出的判断。这里的卡片是本文建议的工作方法。
例如“运营同事”太宽泛，“会在后台发布内容、知道页面与服务器的区别，需要理解为何更新可能没有立刻显示”就具体得多。工程师也未必熟悉某个协议；不要让职位名称替代对先备知识的说明。
虚构案例：展馆网站为什么仍显示旧介绍
以下网上展馆和读者设定均为虚构。团队需要解释HTTP缓存。共同的事实底稿可以写成：缓存保存与请求相关的响应，并在适用条件下复用它；这样可以减少重复获取的成本。这个基本描述可参照MDN的HTTP缓存文档。无论生成几个版本，核心事实都不应改变。
给内容编辑：已会发布文章，目标是区分“内容未保存”与“可能仍在展示已有响应”，因此先讲更新路径和信息停留的位置，不先罗列响应头。
给刚接触HTTP的开发者：已懂请求与响应，目标是读懂新鲜度和重新验证的作用，因此先补齐这两个概念，再带到具体机制。
给项目负责人：已懂页面更新流程，目标是讨论更新时效与加载成本的取舍，因此解释约束和选项，不让实现细节淹没决策问题。
三个版本不必长度相同。内容编辑版本也不能许诺“刷新一定解决”；负责人版本不能为了简短而省掉时效条件。差异应来自任务需要，而不是把同一段文字机械压缩。
类比必须带着使用范围
我可能用“手边留一份展览介绍的复印件”帮助读者理解复用，但会立刻注明：这个类比只解释为何能减少重复获取，并不表示复印件会自动与原稿同步，也不描述实际的HTTP验证规则。随后回到正式概念，说明哪些条件决定已有响应能否继续使用。
给AI的要求是，每个类比最多服务一个关键关系，并写出最容易让人误会的地方。如果解释离开比喻就无法成立，说明正文还缺少必要的概念桥梁。对熟悉领域的读者，直接描述机制可能更省力。
可复用的解释任务模板
“概念是【主题】，事实底稿是【资料】。读者当前要完成【任务】，已知道【先备知识】，还不知道【缺口】。读完应能【具体判断或行动】。请先列出必要知识的顺序，再写解释。保留共同事实与适用条件；首次使用新概念时交代含义；如用类比，说明对应关系和失效边界。最后列出本版主动省略的内容及原因。”
如何发现解释偏离了目标
我会检查每段能否回答读者的一个真实疑问，以及是否突然依赖尚未解释的术语。读者背景不清楚时，先提出待确认的先备知识，别擅自把人当成零基础。如果一项技术行为依赖具体产品配置，通用解释也应停在原理层面。把学习路径写清楚，比把所有知识塞进一篇说明更有用。
