批量更新知识库，而不会失去对更改的控制

在生成文本之前清点受影响的内容

从产品变更开始，在现有内容中搜索旧术语、规则或程序。记录文章标识符、支持宏、入门消息和可能提及的内部说明。不要假设相似的标题意味着相同的内容，或者模型知道旧措辞出现的每个位置。

创建一份已批准的变更表，其中包含旧行为、新行为、生效日期、例外情况和准确术语。为未解决的事实指定所有者。将事实更新与可选样式清理分开，因此更漂亮的句子不会隐藏策略更改。对于程序性文本，谷歌的指导倾向于明确的行动步骤和明确的上下文；整个批次应用相同的标准。

用变更台账跟踪每一项内容直至发布

设想一个虚构服务更改了导出按钮的位置。批准的新路径是“报告 → 导出”，权限和输出格式保持不变。受影响清单包括一篇操作指南、一份新用户引导清单和一条客服回复。这些说明性输入不是 Colay 的界面。

这些项目需要不同的编辑：完整的说明可能需要新的屏幕截图，清单需要更改一个标签，而支持脚本可能只需要更正的路径。对每个项目生成八次完整重写会产生审核工作，但不一定改进更新。

在小型代表性样本上进行校准

八种重写方式在校准过程中非常有用：简明程序、初学者解释、故障排除、常见问题解答、支持回复、内部检查表、以可访问性为中心的简单语言和简短摘要。选择清单实际需要的格式。有用的输出是一致的编辑规则，而不是每个页面的八个相互竞争的版本。

1. 选择一篇简单的文章、一篇有例外的文章和一篇支持脚本。在处理清单的其余部分之前起草这些内容。
2. 向可用的Colay智能体提供相同的变更表，并要求替代的编辑方法。比较它们是否保留所有未更改的规则。
3. 批准编辑模式和术语列表。在批次简介旁边保留已接受和拒绝的更改的示例。
4. 手动处理可管理的内容组，保留每个项目标识符及其源版本。当出现新的矛盾时停止批处理。

可追溯批次项目的提示

仅提供获准用于此目的的材料，并省略不必要的客户细节。正式台账应保存在现有文档或内容系统中。Colay 生成答案，本身并不会更新内容项的发布状态。

使用此批准的变更表更新内容项[ID 和源版本]：[旧行为、新行为、生效日期、例外]。现有文本：[文本]。批准的术语和编辑模式：[规则]。返回修改后的文本、已更改段落的列表及其原因、保留的未更改规则以及阻止发布的问题。仅修改受影响的内容。保留链接和标识符，除非简报明确更改它们。请勿发明新的 UI 标签、权限、日期或产品行为。如果此项与变更表冲突，请标记冲突，而不是通过猜测来解决。

按已审查批次发布，并保留回退方式

发布前，根据批准的来源和实际产品检查每条更改的说明、例外情况和链接。查看有关编辑的完整文档：更正的段落仍然可能与未更改的介绍发生冲突。记录审批者并保留之前的内容版本。

通过现有工具发布，然后验证实时文章以及链接到该文章的所有已保存回复。仅在检查后将项目标记为完成。如果您想评估流程，请跟踪已用的编辑时间和出版后发现的更正。批量工作流程可以减少重复简报，但结果取决于内容和审核工作；它不承诺自动节省一周时间。

问题及解答