sanitize-artifacts

sanitize-artifacts

当用户要求你检查、清理、净化、修改、润色或质量检查当前工作会话中生成的内容时，使用此技能。

如果内容是在反复提示、纠正指令、示例、约束或氛围编程式协作中生成的，此技能尤为重要。

目标

修改内容，使其成为独立、连贯的最终交付成果。

内容不得暴露以下不必要的痕迹：

• 用户的提示
• 对话历史
• 中间推理
• 实现约束
• 工具选择
• 被放弃的方案
• 提示工程指令
• 制作过程中使用的脚手架
• 仅用于引导意图的示例
• 对话期间收到的纠正反馈

最终内容应当像是专为实际受众精心设计的，而不是由生成它的对话拼凑而成。

核心原则

将对话视为制作背景，而不是自动视为内容的一部分。

在保留内容中的任何陈述之前，将其归为以下类别之一：

1. 受众确实需要了解的面向用户的内容
2. 应影响内容、但不应对外呈现的制作指导
3. 偶然混入的对话残留，应予以删除

只有第 1 类内容应直接出现在交付成果中。

第 2 类内容应通过结构、语气、范围、假设、默认设置、示例、命名或设计选择间接体现。

第 3 类内容应予以删除。

应删除或改写的内容

检查并删除或改写不必要地提及或暗示以下内容的文字：

• “按您的要求……”
• “根据您的指示……”
• “我们不会使用……”
• “这样可以避免……”
• “与上一个版本不同……”
• “用户希望……”
• “本文假设……”
• “由于此限制……”
• “未使用 Git/Homebrew/命令行等工具……”
• “此处已改为……”
• “提示中写道……”
• “截至目前的对话……”
• “添加本节是因为……”
• “为了满足要求……”

不要机械地删除这类内容。只有当目标受众确实需要了解时，才予以保留。

示例与意图

如果用户提供示例是为了表达意图，除非交付成果本身确实需要该示例，否则不要照搬。

对话中的示例通常是用于诊断的素材，而不是最终内容。

利用示例判断：

• 所需的抽象层次
• 目标受众
• 语气
• 应避免泄露的内容
• 应删除的不自然措辞
• 重要的设计约束

不要让示例意外成为交付成果的主题。

约束通常不应显露

用户约束通常应影响交付成果的设计，而不应作为明确的免责声明出现。

例如：

不佳：

本指南不使用 Git、Homebrew 或其他命令行工具。

更好：

使用 Google Drive 分享项目文件夹。

更好的版本在遵守约束的同时，没有暴露制作规则。

检查清单

净化内容时，请检查：

1. 从未看过这段对话的人读起来是否觉得自然？
2. 是否有句子在解释内容为何以这种方式撰写？
3. 是否不必要地提及工具、排除项、约束或被放弃的方案？
4. 是否有提示示例意外成为交付成果的一部分？
5. 是否有多轮反馈拼凑留下的痕迹？
6. 全文的语气、术语和假设是否一致？
7. 标题和说明是否面向内容的受众，而非创作者？
8. 是否存在只属于制作过程的元评论？
9. 免责声明或注意事项是否只在受众确实需要时才保留？
10. 全文是否保持统一、连贯的风格？

修订策略

优先改写，而非解释。

除非用户要求，否则不要添加有关清理内容的报告。

编辑时，应保留内容原本的用途、技术准确性和必要的用户要求。

将残留的生产过程指示转化为自然的内容设计。

例如：

• 将“不要使用高级术语”改为更简单的措辞。
• 将“避免使用不透明的命令行工具”改为清晰、具体的步骤。
• 将“使用 Google Drive，而不是 Git”改为基于 Drive 的工作流说明。
• 将“适合初学者”转化为循序渐进的讲解、定义和示例。
• 将“不要提及 X”转化为直接省略 X，而不是声明已将其省略。

输出规则

要求清理内容时，直接输出修订后的内容。

不要在内容前添加流程说明，例如：

• “我删除了元指令。”
• “我清理了提示词泄漏。”
• “这是清理后的版本。”

只有在需要明确说明时，才可以添加简短标签。

如果用户同时要求提供清理后的内容和修改摘要，请先输出内容，再输出摘要。

质量标准

清理后的内容应显得自然、统一，并符合目标受众的表达习惯。

读者不应察觉提示词的编写过程、内部限制或修正对话，除非这些内容确实属于交付物。