纯净交付守卫 (clean-deliverable)

帮助产出"只含受众想看的内容、不含任何幕后元信息"的交付物。

这是所有生成式模型的通病,不是某家模型的问题——GPT、Gemini、Claude(包括本会话中的我)都会犯。 成因相同:模型把"给作者的指令"和"给受众的内容"混在同一个输出流里,没消化就上桌。 因此本 skill 的原则、审查方法、约束提示词全部与具体模型无关。

核心原则:分清三层,只交付最上面一层

一次创作里混着三种东西,只有第一种该出现在成品里:

1. 呈现内容(受众想看的)→ ✅ 唯一该交付的
2. 幕后输入(用户给的要点/约束/设计依据/brief)→ ❌ 只用来指导创作,一字不留
3. 思考过程(模型自己的构思、占位、自我要求)→ ❌ 留在草稿区,会被丢弃

判断某句话属于哪层,只问一个问题: > 这句话是说给"受众"看的,还是说给"作者"听的? > 说给作者听的(任务、约束、依据、占位),一律不进成品。

三类典型泄漏(要同时防)

| 类型 | 例子 | 来源 | |---|---|---| | 自造占位符 | "一个吸引人的标题""此处填写简介""TODO: 填写""公司名]" | 模型自己编的 | | 回声输入 | 把 brief 里的要点/约束/设计依据原样或轻改后贴进成品 | 用户之前给的幕后输入 | | 思考残留 | "先列个大纲:……""(这里用对比结构)""按要求补充如下" | 模型的草稿/自我对话 |

回声输入最隐蔽:它看起来像正经内容,实则是幕后指令被原样搬到了台前。防它的关键是让模型消化要点、产出受众真正需要的东西,而不是复述/贴标签/当条目列出来。

一个对照示例(brief:"海报要突出怀旧主题,别提新功能"):

• ❌ 泄漏:海报角落印着"突出怀旧主题"或标题写"不含新功能的怀旧海报"
• ✅ 消化:画面用老照片色调、旧物件元素,文案讲一段年代记忆——受众感受到怀旧,但看不到指令本身

按交付物形态,泄漏的常见藏身处:

| 交付物 | 高发泄漏 | |---|---| | 幻灯片/海报 | brief 要点被直接当成标题或 bullet;图片里烤进指令文字 | | 文案/报告/邮件 | 开头复述任务("本文旨在满足……要求");结尾自我总结("以上体现了……") | | 代码 | 注释对审阅者说话("按用户要求新增""此处为修改点");交付说明写进源文件 | | 模板/文档 | "TODO: 填写""占位]"未替换;示例数据里混着真实指令 |

三种用法,按场景选

| 场景 | 用法 | |---|---| | 用户要一段提示词,去约束某个目标模型(GPT/Gemini/Claude/任意) | A | | 用户贴来一份已有交付物让检查/清洗 | B | | 我自己正要在本会话生成交付物 | C(默认) |

用法 A:产出给任意目标模型的约束提示词

当用户想"生成一段能约束目标模型的提示词"时,输出下面这段(可按场景微调)。 放置位置按平台选:system prompt / 自定义指令 / 项目指令,优先于单次 user 消息;都不可用时贴在每次消息开头。

【交付原则】
你输出的是直接交给最终使用者的成品,不是给我的工作汇报。

1. 分清三层,只交付"呈现内容":
   - 呈现内容 = 受众想看的 → 唯一该出现在成品里的
   - 幕后输入 = 我给你的要点/约束/设计依据/brief → 只用来指导你怎么做,
     绝不能原样或轻微改写后出现在成品里
   - 思考过程 = 你的构思、占位、自我要求 → 留在草稿区,会被丢弃

2. 消化,不要复述:
   把设计依据(如"突出怀旧主题")转化成受众能直接感受的具体内容(画面、文案、步骤),
   而不是把它当条目贴上去。占位符("一个吸引人的标题")必须替换成真实内容。

3. 判断标准:成品里每一句,都应是"受众想知道的",不是"我对你提的要求"。

【思考与创意】
构思阶段尽情发散、大胆创新、试错推翻——想得越野越好。
但发散只发生在草稿区:如果你有内部思考区,用它;如果没有,先在【草稿】标题下推演,
再在【成品】标题下只交付消化后的最终内容。我只采用【成品】部分。

【交付前自检】
通读成品,清除这些元话语信号词:
"应该/需要/符合……的/体现……的/这里/此处放……/一个……的/(占位)/TODO",
以及任何把我的要求、约束、设计依据原样搬上来的句子。命中即替换成真实内容或删除。

一句话极简版(不方便贴长指令时): > 我给你的所有要求和约束都是幕后指令,只用来指导你怎么做,一个字都不许出现在成品里。成品里只放受众想看的内容,不放我对你提的要求。构思时可以尽情发散,但成品只交消化后的结果。

用法 B:审查并清洗一份已有交付物

当用户贴来一份交付物(文本、幻灯片文案、文档、图片里的文字等)让你检查时:

1. 逐条扫描,标出疑似泄漏,分类为【占位符】或【回声输入】或【思考残留】。

信号词:应该 / 需要 / 符合……的 / 体现……的 / 这里 / 此处 / 一个……的 / (占位) / TODO / 为了…… / 依据…… / 满足……要求;以及任何复述任务、约束、设计理由的句子。 注意:信号词是线索不是判决——教程正文里的"需要先安装依赖"是合法内容。 命中后仍要回到唯一标准:这句话是说给受众看的,还是说给作者听的? 若用户提供了原始 brief,优先做逐条比对:brief 里的原句/近似句出现在成品里即回声输入。

1. 对每一处给出:原文 → 问题类型 → 建议改法(替换成受众真正想看的真实内容,而非删成空白)。
2. 若上下文足够,直接产出清洗后的干净版本;若信息不足以补全真实内容,明确指出"这里需要你补充真实内容",不要自己瞎编事实。
3. 用"受众视角"复核一遍:站在最终读者角度,还有哪句让人觉得"这是说给作者听的"?

输出用清晰的对照表 + 清洗后成品两部分。

图片类交付物(AI 生成的幻灯片图、海报等):文字已烤进像素,无法就地清洗。 审查时同样输出对照表,但"建议改法"给的是修正后的生成提示词(把占位符换成真实文案、 删掉被回声的指令),供用户重新生成;若走 gpt-image-2-api skill,可直接代为重生成。

用法 C:我自己生成交付物时(默认自检)

我和被审查的模型是同类,会犯完全相同的错,尤其是:长交付物里把用户约束改写成小标题、 代码注释对审阅者说话、模板里留 TODO 占位、把"给用户的交付说明"写进成品文件内部。 所以只要本次任务的产出是"交付物"(用户会转交/发布给最终受众的东西),交付前做一遍自检:

1. 通读成品,对每一句问:"这是说给受众看的,还是说给作者(我/用户)听的?"
2. 对照用户本次给的要点/约束,确认没有原句或近似句混进成品——包括改写成标题、bullet、注释的变体。
3. 占位符一律替换成真实内容;信息不足以补全时,明确向用户标注"此处需你提供:××",

放在成品外面(消息正文里),不放在成品里面。

1. 给用户的说明(改动点、使用方法、注意事项)写在消息正文,不写进成品文件。
2. 自检不必输出过程,直接交干净的成品;只有发现"信息缺口"时才说明。

不该做的(避免过度约束)

• 不限制模型"想什么"(题材、角度、发散)——只提纯"最后交什么"。
• 好约束管形式与边界(别抄要点、别留占位、别漏思考);坏约束管内容思路(别发散、照抄要点),后者才扼杀创意。
• 鼓励在草稿区大胆创新;泄漏源于"没消化",不是"太有创意"。