如何撰写能带来有效修改的编辑指令
用一套实用的简报结构，把模糊的修改要求变成可比较、可审核、可完善的具体指令。
“让这段文字更好一些”遗漏了太多编辑决策。对谁更好？具体要短在哪里？哪些措辞可以改，哪些细节又需要仔细核对？
一条有用的修改指令要同时完成两件事：
- 指出草稿中需要处理的部分。
- 说明改写后仍需由编辑审核的细节。
这种区分能让请求保持聚焦。你可以要求把过渡写得更紧凑，同时不暗示日期、引文、链接或核心主张可以被随意改动。
使用五部分修改简报
如果你经常处理重复性的编辑工作，每次都按同样的顺序写指令：
- 读者： 谁需要理解这篇草稿？
- 预期修改： 具体要改善什么？
- 语气或重点： 表达应当呈现什么感觉，或应当突出什么？
- 需要核对的细节： 哪些事实、姓名、数字、引用、引文或术语需要检查？
- 格式优先级： 哪些标题、段落、列表或其他元素应当保留？
这不是对完美结果的要求。它是你编辑意图的一份简明记录，让你在比较不同版本时有清楚的标准。
把模糊要求改成可审核的指令
先看一条模糊的指令：
把这个开头改得不像 AI 写的。
它表达了不满，却没有给出编辑方向。更有用的简报可以这样写：
读者：忙碌的运营经理。预期修改：删去宽泛的开场判断，在前两句直接进入实际问题。语气：直接、平静。需要核对的细节：保持既定截止日期和产品名称不变。格式：保留标题和两段式结构。
这样一来，比较就有了明确目的。你可以先检查开头是否更快进入问题，再分别核对截止日期、产品名称、标题和段落结构。
示例：减少空泛表达，但不删掉核心意思
如果一个段落反复强调某个话题很重要，就提出具体修改：
删除关于重要性的抽象表述。保留对该流程为何会影响团队之间交接的解释。优先使用具体动词，并在能提升清晰度时缩短句子。核对原有条件限定是否仍然保留。
关键在于说清楚你想删去什么样的空泛表达，以及必须留下哪一部分解释。单说“写得简洁一点”无法做到这两点。
示例：收紧段落之间的过渡
当每一节都先宣布自己的重要性时，过渡句很容易变得泛泛。你可以这样写：
用能说明与上一节逻辑关系的句子替换套话式过渡。不要增加新的主张或例子。保留现有标题和列表顺序。
审核结果时，连续读完上一节的最后一句和下一节的第一句。如果逻辑连接仍不清楚，过渡就还需要再编辑，即使措辞已经更顺。
示例：保留必须原样呈现的引文
引文应当被当作受保护的元素，而不是普通正文：
修改周围的说明，使其更清晰、节奏更自然。逐字保留引文句子。保留其署名和链接以供审核。不要把引文改写成转述。
发布前，你仍应当将引文、署名和链接与原始材料逐一对照。指令只是标出优先级，不能替代核验。
让指令可以重复使用
为你经常编辑的内容准备一份简短的基础简报，然后只替换每篇草稿特有的细节。例如：
读者：[目标读者]。预期修改：[要解决的问题]。语气或重点：[表达方向]。需要核对的细节：[受保护的细节]。格式优先级：[要保留的元素]。
方括号中的字段会让你在每次修改前先做出判断。它们也能帮助你理解两次改写为何不同：也许一条请求要求更直接的开头，另一条则优先保留一份详细列表。
Web 工作区提供并排审核、保存的历史记录和自定义指令。
把这些控制项纳入你的编辑流程。将简报与它所指导的版本放在一起，用同一套标准比较原文和修改稿；需要重新判断某个选择时，再回到较早的改写版本。自定义指令可以让请求更一致，但最终判断仍由你做出。
对比检查清单
在选择一个修改版本前，按以下顺序检查：
- 含义： 修改后的草稿是否仍在表达同一个核心观点？
- 事实： 姓名、日期、数字、技术术语和限定条件是否正确？
- 引用与引文： 引用、链接、署名和必须保留的引文是否齐全且准确？
- 格式： 必需的标题、段落和列表是否仍然可用？
- 最终措辞： 每一处修改是否都能帮助目标读者？是否有句子加入了你无法支持的主张？
具体指令能让最后一轮检查更快，因为你知道这次修改原本要解决什么。它们不会免除你仔细阅读最终版本的责任。是否可以发布，要由你在这一步决定。