重写一篇知识库文章而不丢失其说明

为文章明确一种读者和一个任务

有关更改通知设置的文章目前可能会混合帐户设置、权限和故障排除。在重写之前，说明读者的出发点和他们应该达到的结果。将其他所有内容放在先决条件、相关链接或单独的文章中。这种编辑选择通常比改变基调更重要。

创建任务卡：文章标识符、受众、支持的产品版本、所需角色、确切的界面标签、预期结果、已知异常和所有者。仅使用经批准的材料。如果某个步骤不确定，请将其标记为验证，而不是要求模型从记忆中填补空白。 Google 的程序指南支持以操作为中心的步骤和足够的上下文来定位操作。

使用固定产品事实进行虚构重写

以一个虚构的工作区工具为例：成员可以在“设置 → 通知”中关闭个人邮件通知；只有工作区所有者能修改整个组织的默认设置。保存后会影响未来的邮件，但不会移除已排队的消息。这些是为说明方法而虚构的输入，并非 Colay 的功能。

使用相同的事实要求不同的结构。程序可以帮助某人立即完成任务；故障排除版本可以帮助找不到控件的人。常见问题解答可以解释排队电子邮件异常。八种请求的方法是可能的，但它们应该解决八种阅读情况，而不是重复相同的句子。

区分措辞与产品真相的提示

在 Colay 中使用 Ask separately，观察所选智能体如何理解任务。先比较提纲，再完善整篇文章。如果一个答案删除了权限要求而其他答案保留了它，应回到已批准的来源核查。模型意见一致不能代替实际测试文档所述的操作流程。

重写此已批准的知识库文章：[文本]。任务卡：[受众、产品版本、角色、确切的 UI 标签、预期结果、例外情况]。制作编号的操作方法、故障排除版本和简短的常见问题解答版本。保留每一个条件、许可和例外。不要发明控制或行为。对于每个版本，列出支持每个指令的源语句。将不清楚或有冲突的来源材料放在单独的问题列表中。为[读者情况]推荐一种结构并解释选择。不要默默地结合不同产品版本的事实。

将最佳草稿转变为可发布的修订版

最终交付物可以很精简：已批准的标题、前提条件、操作步骤、预期结果、例外情况，以及一个相关后续链接。把来源与指令的对应关系保存在编辑说明中。Colay 帮助起草和比较；这个流程不意味着它可以连接知识库或自动发布更改。

1. 选择与任务卡匹配的结构。仅在检查其含义后才保留其他草稿中有用的句子。
2. 使用指定角色逐步完成受支持产品版本中的每个步骤。验证标签、顺序、结果和记录的异常。
3. 以新用户身份阅读本文：先决条件应在需要之前出现，失败的步骤应有可用的下一步操作。
4. 记录审稿人、文章版本和更改的部分。通过现有的知识库工作流程进行发布，保留以前的版本进行比较。

根据读者的能力来判断重写

请一位不熟悉该草案的同事找到起点，确定他们的权限要求并解释最后一步之后会发生什么。将误解记录为编辑问题。如果您对该文章有反馈或搜索数据，请在发布后比较相同的信号，而不要将每个更改都归因于人工智能。当剩余的工作是缺少产品事实而不是措辞选择时，停止生成。

问题及解答