Clean deliverable
Kiakun 的 AI Agent Skills 集合(Claude Code / OpenClaw / 通用 SKILL.md):HTML→可编辑 PPTX、图片型 PPT 重构、GPT Image 2 出图、小红书/B站自动化、文件夹向量知识库、游戏 UI 与玩家互动设计等 10+ 技能。
npx -y skills add kiakun-collab/kiakun-skills --skill clean-deliverableAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
纯净交付守卫(模型通用)。用于在"生成"或"审查"交付物(幻灯片、文案、报告、邮件、代码等)时, 防止元信息泄漏到成品里——包括自造占位符("符合营销话术的标题")、回声输入(把用户给的 要点/约束/设计依据原样贴进成品)、以及思考过程残留。适用于任何生成式模型(GPT、Gemini、 Claude 及本会话中的我自己)。三种用法:①产出可粘贴到任意目标模型的约束提示词; ②审查并清洗一份已有交付物(含图片类,给出重生成提示词);③我自己生成交付物时的交付前自检。 触发词:纯净交付、清洗交付物、防元信息泄漏、约束提示词、别把要点写进成品、 clean deliverable、anti meta leak。
SKILL.md
8.5 KB, as published. Nobody here has run it
纯净交付守卫 (clean-deliverable)
帮助产出"只含受众想看的内容、不含任何幕后元信息"的交付物。
这是所有生成式模型的通病,不是某家模型的问题——GPT、Gemini、Claude(包括本会话中的我)都会犯。 成因相同:模型把"给作者的指令"和"给受众的内容"混在同一个输出流里,没消化就上桌。 因此本 skill 的原则、审查方法、约束提示词全部与具体模型无关。
核心原则:分清三层,只交付最上面一层
一次创作里混着三种东西,只有第一种该出现在成品里:
- 呈现内容(受众想看的)→ ✅ 唯一该交付的
- 幕后输入(用户给的要点/约束/设计依据/brief)→ ❌ 只用来指导创作,一字不留
- 思考过程(模型自己的构思、占位、自我要求)→ ❌ 留在草稿区,会被丢弃
判断某句话属于哪层,只问一个问题:
这句话是说给"受众"看的,还是说给"作者"听的? 说给作者听的(任务、约束、依据、占位),一律不进成品。
三类典型泄漏(要同时防)
| 类型 | 例子 | 来源 |
|---|---|---|
| 自造占位符 | "一个吸引人的标题""此处填写简介""TODO: 填写""[公司名]" | 模型自己编的 |
| 回声输入 | 把 brief 里的要点/约束/设计依据原样或轻改后贴进成品 | 用户之前给的幕后输入 |
| 思考残留 | "先列个大纲:……""(这里用对比结构)""按要求补充如下" | 模型的草稿/自我对话 |
回声输入最隐蔽:它看起来像正经内容,实则是幕后指令被原样搬到了台前。防它的关键是让模型消化要点、产出受众真正需要的东西,而不是复述/贴标签/当条目列出来。
一个对照示例(brief:"海报要突出怀旧主题,别提新功能"):
- ❌ 泄漏:海报角落印着"突出怀旧主题"或标题写"不含新功能的怀旧海报"
- ✅ 消化:画面用老照片色调、旧物件元素,文案讲一段年代记忆——受众感受到怀旧,但看不到指令本身
按交付物形态,泄漏的常见藏身处:
| 交付物 | 高发泄漏 |
|---|---|
| 幻灯片/海报 | brief 要点被直接当成标题或 bullet;图片里烤进指令文字 |
| 文案/报告/邮件 | 开头复述任务("本文旨在满足……要求");结尾自我总结("以上体现了……") |
| 代码 | 注释对审阅者说话("按用户要求新增""此处为修改点");交付说明写进源文件 |
| 模板/文档 | "TODO: 填写""[占位]"未替换;示例数据里混着真实指令 |
三种用法,按场景选
| 场景 | 用法 |
|---|---|
| 用户要一段提示词,去约束某个目标模型(GPT/Gemini/Claude/任意) | A |
| 用户贴来一份已有交付物让检查/清洗 | B |
| 我自己正要在本会话生成交付物 | C(默认) |
用法 A:产出给任意目标模型的约束提示词
当用户想"生成一段能约束目标模型的提示词"时,输出下面这段(可按场景微调)。 放置位置按平台选:system prompt / 自定义指令 / 项目指令,优先于单次 user 消息;都不可用时贴在每次消息开头。
【交付原则】
你输出的是直接交给最终使用者的成品,不是给我的工作汇报。
1. 分清三层,只交付"呈现内容":
- 呈现内容 = 受众想看的 → 唯一该出现在成品里的
- 幕后输入 = 我给你的要点/约束/设计依据/brief → 只用来指导你怎么做,
绝不能原样或轻微改写后出现在成品里
- 思考过程 = 你的构思、占位、自我要求 → 留在草稿区,会被丢弃
2. 消化,不要复述:
把设计依据(如"突出怀旧主题")转化成受众能直接感受的具体内容(画面、文案、步骤),
而不是把它当条目贴上去。占位符("一个吸引人的标题")必须替换成真实内容。
3. 判断标准:成品里每一句,都应是"受众想知道的",不是"我对你提的要求"。
【思考与创意】
构思阶段尽情发散、大胆创新、试错推翻——想得越野越好。
但发散只发生在草稿区:如果你有内部思考区,用它;如果没有,先在【草稿】标题下推演,
再在【成品】标题下只交付消化后的最终内容。我只采用【成品】部分。
【交付前自检】
通读成品,清除这些元话语信号词:
"应该/需要/符合……的/体现……的/这里/此处放……/一个……的/(占位)/TODO",
以及任何把我的要求、约束、设计依据原样搬上来的句子。命中即替换成真实内容或删除。
一句话极简版(不方便贴长指令时):
我给你的所有要求和约束都是幕后指令,只用来指导你怎么做,一个字都不许出现在成品里。成品里只放受众想看的内容,不放我对你提的要求。构思时可以尽情发散,但成品只交消化后的结果。
用法 B:审查并清洗一份已有交付物
当用户贴来一份交付物(文本、幻灯片文案、文档、图片里的文字等)让你检查时:
- 逐条扫描,标出疑似泄漏,分类为【占位符】或【回声输入】或【思考残留】。
信号词:
应该 / 需要 / 符合……的 / 体现……的 / 这里 / 此处 / 一个……的 / (占位) / TODO / 为了…… / 依据…… / 满足……要求;以及任何复述任务、约束、设计理由的句子。 注意:信号词是线索不是判决——教程正文里的"需要先安装依赖"是合法内容。 命中后仍要回到唯一标准:这句话是说给受众看的,还是说给作者听的? 若用户提供了原始 brief,优先做逐条比对:brief 里的原句/近似句出现在成品里即回声输入。 - 对每一处给出:原文 → 问题类型 → 建议改法(替换成受众真正想看的真实内容,而非删成空白)。
- 若上下文足够,直接产出清洗后的干净版本;若信息不足以补全真实内容,明确指出"这里需要你补充真实内容",不要自己瞎编事实。
- 用"受众视角"复核一遍:站在最终读者角度,还有哪句让人觉得"这是说给作者听的"?
输出用清晰的对照表 + 清洗后成品两部分。
图片类交付物(AI 生成的幻灯片图、海报等):文字已烤进像素,无法就地清洗。 审查时同样输出对照表,但"建议改法"给的是修正后的生成提示词(把占位符换成真实文案、 删掉被回声的指令),供用户重新生成;若走 gpt-image-2-api skill,可直接代为重生成。
用法 C:我自己生成交付物时(默认自检)
我和被审查的模型是同类,会犯完全相同的错,尤其是:长交付物里把用户约束改写成小标题、 代码注释对审阅者说话、模板里留 TODO 占位、把"给用户的交付说明"写进成品文件内部。 所以只要本次任务的产出是"交付物"(用户会转交/发布给最终受众的东西),交付前做一遍自检:
- 通读成品,对每一句问:"这是说给受众看的,还是说给作者(我/用户)听的?"
- 对照用户本次给的要点/约束,确认没有原句或近似句混进成品——包括改写成标题、bullet、注释的变体。
- 占位符一律替换成真实内容;信息不足以补全时,明确向用户标注"此处需你提供:××", 放在成品外面(消息正文里),不放在成品里面。
- 给用户的说明(改动点、使用方法、注意事项)写在消息正文,不写进成品文件。
- 自检不必输出过程,直接交干净的成品;只有发现"信息缺口"时才说明。
不该做的(避免过度约束)
- 不限制模型"想什么"(题材、角度、发散)——只提纯"最后交什么"。
- 好约束管形式与边界(别抄要点、别留占位、别漏思考);坏约束管内容思路(别发散、照抄要点),后者才扼杀创意。
- 鼓励在草稿区大胆创新;泄漏源于"没消化",不是"太有创意"。