摘要：Notion 8 月 28 日为 Agent 增加"建议修改"能力，用户可逐条审阅后批准。本文从工程角度拆解一套可落地的 AI 改稿流水线：不可变原稿、结构化 Patch、风险分级、冲突检测、版本记录和发布前回读。
"帮我润色一下"可能是内容系统里最危险的需求之一。
它没有定义修改范围，也没有定义验收标准。模型可能改掉错别字，也可能重写结构、补充未经核实的事实，顺便把作者原本有辨识度的表达改成一篇标准答案。
Notion 在 8 月 28 日更新中增加了一个很小、但很有工程意味的交互：Agent 可以先 suggest edits，不直接修改原文；用户从上到下查看，再逐条批准。官方给出的例子是语法检查等行级修改。
这并不自动解决事实错误或风格漂移，但它把 AI 改稿从"返回一篇新全文"改成了"提交一组待审变更"。对要进入生产的内容，这个差别很大。
1. 全文重写为什么难审
设原稿为 D0，模型返回 D1。如果系统只保存这两个字符串，审稿人需要自己完成三件事：
- 找出所有变化；
- 判断每处变化的意图；
- 确认是否引入事实、语气或合规风险。
文章越长，人工比对成本越高。更麻烦的是，模型会同时修改标点、语序、结构和观点，真正重要的变化被大量表面润色淹没。
所以第一条原则是：原稿默认不可变，AI 输出修改集。
2. 一条 Patch 应该包含什么
最小数据结构可以这样设计：
ts
type EditRisk = 'low' | 'medium' | 'high';
interface TextPatch {
patchId: string;
baseVersion: string;
anchor: {
blockId: string;
quote: string;
start?: number;
end?: number;
};
before: string;
after: string;
reason: string;
category: 'typo' | 'clarity' | 'structure' | 'fact' | 'brand' | 'compliance';
risk: EditRisk;
evidence?: string[];
status: 'proposed' | 'accepted' | 'rejected' | 'stale';
}before/after 用于展示 Diff，reason 解释修改动机，category 与 risk 决定审批方式，baseVersion 则用于冲突检测。
只返回"修改后的句子"不够。没有理由和风险级别，人只能凭感觉决定接受还是拒绝。
3. 不要只靠字符位置定位
如果 Patch 只记录 start=1024, end=1052，前文新增一个字，所有位置都可能漂移。
更稳的定位方式是组合使用：
- 块 ID：定位段落或编辑器节点；
- 原文片段：确认被改内容仍存在；
- 前后文哈希：判断上下文有没有变化；
- 基础版本号：发现 Patch 是否基于旧稿。
ts
function canApply(patch: TextPatch, doc: DocumentState) {
if (patch.baseVersion !== doc.version) return false;
const block = doc.blocks.get(patch.anchor.blockId);
return block?.text.includes(patch.before) ?? false;
}不能安全定位时，不要"尽力贴上去"，而应把状态改成 stale，重新生成建议。
4. 风险分级决定审批粒度
并非所有修改都要同样处理。
| 风险 | 典型修改 | 默认动作 |
|---|---|---|
| 低 | 错别字、明显标点、重复词 | 可批量接受，但保留撤销 |
| 中 | 句式、段落顺序、标题强度 | 逐组审阅 |
| 高 | 数字、引语、产品承诺、法律与医疗表述 | 逐条人工确认并检查来源 |
一个实用规则是：模型越可能改变"事实或责任"，审批越细；越接近纯格式清理，越适合批量处理。
5. 把作者声音写成约束
很多改稿事故不是事实错了，而是作者被"优化"没了。
风格约束不要只写"口语化、自然、有网感"。这些词过于宽泛。可以把它拆成可检查的不变量：
yaml
voice_invariants:
- 保留第一人称判断，不改成机构口吻
- 不新增感叹号
- 不把具体案例替换成抽象总结
- 允许短句和不完全对称的段落节奏
- 不使用"赋能、重塑、颠覆、时代浪潮"等词
- 观点强度不得高于原文它们不保证绝对风格一致，却能让"不要改成 AI 腔"从一句抱怨变成验收条件。
6. 改稿流水线应分四次跑
一次 Prompt 同时做事实、结构、语气和平台适配，表面省事，出错后却无法定位。
更稳的顺序是：
text
FACT_CHECK
→ STRUCTURE_REVIEW
→ LINE_EDIT
→ PLATFORM_ADAPTATION
→ PUBLISH_REVIEWFACT_CHECK
只找需要核实的数字、日期、引语与动态产品事实，不改文风。每条建议附来源或标记"待确认"。
STRUCTURE_REVIEW
输出段落移动、删减与补证据建议。此阶段不要先把全文写漂亮。
LINE_EDIT
处理错别字、歧义、冗余和节奏，遵守作者声音约束。
PLATFORM_ADAPTATION
基于同一事实清单分别重写，而不是复制后删字。CSDN 补技术解释，掘金强调机制和取舍，头条缩短段落并降低理解门槛。
PUBLISH_REVIEW
回读平台编辑器里的标题、正文、图片、摘要、标签与发布选项。上传成功不等于最终页面正确。
7. 接受 Patch 后仍要生成新版本
每次接受建议，都应产生新版本，而不是覆盖历史：
text
draft-v1
├─ patch-001 typo accepted
├─ patch-002 claim rejected
└─ patch-003 paragraph-move accepted
↓
draft-v2发布记录还应保存最终版本号、平台、时间和页面链接。以后发现问题，才能知道是源稿、平台改写还是发布设置出了错。
8. 从建议修改走到完整交付
单点编辑能力只能解决"怎么改一句"。内容团队真正面对的是选题、调研、写稿、改稿、配图、排版、平台适配、预填和最终发布。
这也是我们做 Tipkay 时采用岗位化方式的一个原因：公众号编辑、知乎博主、博客发布助手带着业务资料、历史内容和平台规则，各自完成一类工作；同一母题在不同平台分别处理，发布等关键动作再由人确认。
这里需要明确边界：Tipkay 官网并没有承诺通用的逐字 Diff 审批，本文的 Patch 协议是一套工程建议；产品的可验证价值，是让业务上下文、岗位流程、工具和发布准备处在同一条交付链里，减少每次从空白聊天框重新解释。
9. 最小落地清单
- 原稿只读保存，生成唯一版本号；
- AI 只输出可定位的 Patch，不默认覆盖全文；
- 每条建议包含理由、类别和风险；
- 数字、引语、承诺和合规表述逐条核验；
- 作者声音写成明确的不变量；
- 接受与拒绝均留记录，可撤销、可回滚；
- 平台改写共享事实清单，不共享整篇成稿；
- 提交前回读最终页面。
AI 编辑真正成熟的标志，不是把一千字瞬间改完，而是知道哪十个字值得提议、哪一句必须问人、哪一段最好原封不动。
参考资料
标签：人工智能、AI Agent、自然语言处理