---
name: kiakun-collab/clean-deliverable
source: https://app.decimal.ai/s/kiakun-collab-clean-deliverable@1/SKILL.md
source_sha256: 8a959bbea467
---

# 纯净交付守卫 (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 里的原句/近似句出现在成品里即回声输入。
2. **对每一处**给出:原文 → 问题类型 → 建议改法(替换成受众真正想看的真实内容,而非删成空白)。
3. 若上下文足够,**直接产出清洗后的干净版本**;若信息不足以补全真实内容,明确指出"这里需要你补充真实内容",不要自己瞎编事实。
4. 用"受众视角"复核一遍:站在最终读者角度,还有哪句让人觉得"这是说给作者听的"?

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

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

---

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

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

1. 通读成品,对每一句问:"这是说给受众看的,还是说给作者(我/用户)听的?"
2. 对照用户本次给的要点/约束,确认没有原句或近似句混进成品——包括改写成标题、bullet、注释的变体。
3. 占位符一律替换成真实内容;信息不足以补全时,明确向用户标注"此处需你提供:××",
   放在成品**外面**(消息正文里),不放在成品里面。
4. 给用户的说明(改动点、使用方法、注意事项)写在消息正文,不写进成品文件。
5. 自检不必输出过程,直接交干净的成品;只有发现"信息缺口"时才说明。

---

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

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