# 用豆包给一条快讯补背景：三问模板 快讯通常只有两三行：谁、做了什么、什么时候。直接转发价值不大，想写点自己的东西又缺上下文。我习惯用豆包跑一个固定的三问模板，把“这条消息放在什么位置”补齐，而不是让它替我扩写成一篇长文。 ## 三问模板 > 以下是一条快讯原文：<粘贴原文> > 请依次回答三个问题，每个不超过三句，不要做评价： > 1. 它改变了什么？即与之前的状态相比，具体哪一项不同了。 > 2. 之前是什么？指出被替换或被补充的旧做法，若原文未提供，写“原文未说明”。 > 3. 谁受影响？列出最直接的一类使用者，以及他们需要做的动作（如果有）。 > 最后单独列出：为了回答这三问，还缺哪些事实需要我去核实。 三个问题分别对应**变化点、基线、影响面**。缺了基线，任何“新功能”都无从判断；缺了影响面，写出来的东西就容易变成空泛的行业评论。最后一问是整套模板里最有用的部分：它把“我不知道什么”明确摆出来。 ## 一条实际例子 看到一条关于静态站点生成方式更新的消息，三问跑完得到的结论很短：变化是构建产物里默认带上了站点地图；基线是此前需要自行配置；影响面是维护文档站的人，可能需要检查原有配置是否重复。最后列出两项待核实：默认行为是否可关闭、从哪个版本开始。 顺着这两项去 [HTML 入门教程站关于 sitemap 与结构化数据的说明](https://html.eapis.site/) 查一遍，比让豆包“帮我分析一下这条新闻”有效得多。有明确待核实项，查资料才有方向。 ## 两条必须守住的边界 **补背景不等于编背景。** 豆包很擅长把不确定的地方补得顺顺当当，所以模板里明确写了“原文未提供就写原文未说明”。凡是涉及版本号、日期、默认值、适用范围的硬信息，一律回原文核对。技术类的定义可以到 [前端 Wiki](https://www.37466.top/) 或 [BackendWiki](https://backend.37466.top/) 确认，不要让模型凭印象给。 **别让它下结论。** 三问里有意没有“这条消息重要吗”。重要性取决于你在做什么，模型不知道你的场景。把判断留给自己，模板只负责把事实摆整齐。 ## 小结 这套模板跑一次不到两分钟，产出通常只有五六行，但正好是写一条有质量的资讯短评所缺的那部分。真正提升效率的不是 AI 写得快，而是**把“我还缺什么”问清楚了**——剩下的核实工作反而变少了。