Day 057 · Prompt 写的越完整，有时候效果更差

「事无巨细的老板会限制员工的创造力，Micro-manage 的结果往往更不尽人意」

上一篇讨论的是，模型升级后，同一个 Prompt 可能不再按原来的方式工作。

这一篇想说的是另一件事：

模型没有变，Prompt 也可能被我们越改越差。

我之前把自己反复使用的小红书审稿方法整理成了一个 Skill。

初衷很简单：既然每次都会检查主线、事实依据、重复内容、AI tone 和作者语气，不如把它们固定下来，以后直接调用。

但实际使用时，我经常觉得，调用 Skill 得到的结果反而不如直接和 ChatGPT 讨论。

不是它没有执行要求。

文章通常会变得更完整、更工整，每一项标准也似乎都照顾到了。但重点被磨平了，语气也淡了。最后得到一篇没有明显错误，却也没有多少个人判断的文章。

这让我意识到，Prompt 或 Skill 的效果，并不只取决于它写得是否详细。

可以粗略写成：

结果 = f（模型、Skill、当前输入、上下文、工具、运行参数）

模型提供基础能力。

Skill 提供一套可重复使用的方法、规则和资源。

当前输入决定这一次具体要解决什么；上下文影响模型如何理解任务；工具和运行参数又会改变它能做什么、愿意投入多少。

所以 Skill 不是独立生效的，也不是“写得越完整，效果就越稳定”。

Skill 可以沉淀经验，也可能把错误的优先级一起沉淀下来。

它只是整个系统中的一个变量。

每一条标准都合理，不代表应该同等重要

例如，一篇文章可能同时要求：

信息密度高；
逻辑完整；
语气自然；
保留真实例子；
篇幅不要太长；
每个判断都有依据；
删除所有重复；
让没有背景的读者也能看懂。

这些要求单独看都成立。

问题在于，它们之间本来就需要取舍。

多保留例子，篇幅就可能变长；解释得足够完整，节奏就可能变慢；追求严谨，有时会削弱个人表达。

当十几项标准都被写成同等级的“必须”，模型最容易采用的办法，就是平均照顾每一项。

于是每一处都过得去，真正重要的那一处反而没有被突出。

问题不只是规则太多，而是规则之间没有清楚的优先级。

每次踩坑都加一条规则，也会留下后遗症

这在 Claude Code 里也很常见。

模型曾经漏过测试，于是增加“必须运行测试”。

曾经顺手重构了一大片，于是增加“绝对不能修改指定文件以外的内容”。

曾经创建了很多临时文件，于是再增加“禁止创建任何新文件”。

每条规则都有来历。

但一次异常，不一定适合被改写成永久规则。

例如，“禁止创建新文件”可以防止过程垃圾，却也可能让模型在真正需要补充测试文件时绕开正确做法。

“只能修改指定文件”可以限制范围，却也可能让它无法修复位于共享模块里的根因。

这里的问题是：

一次具体事故，被概括成了一条适用于所有任务的规则。

Skill 会把这条规则稳定地带进之后的每一次调用。

这正是它的价值，也是它的风险。

什么适合写进 Skill？

我更倾向于把 Skill 分成两层。

固定层：长期不变的部分

例如：

不虚构事实；
区分事实、推论和未知信息；
必须完成某项验证；
必须使用指定工具或资料；
输出需要满足某种明确格式；
几条真正稳定的判断顺序。

这些要求换一篇文章、换一个项目，通常仍然成立。

运行层：这一次才知道的部分

例如：

这次最想解决什么；
目标读者是谁；
当前最大的疑问是什么；
哪些内容必须保留；
这次更看重严谨、节奏，还是个人表达；
哪几项标准应该优先。

这些信息不应该由 Skill 提前替你决定，而应该在每次调用时补充。

可以把它理解成：

Skill 固定方法，当前输入决定重点。

好的 Skill，不是标准最多的 Skill

一个 Skill 真正需要提供的，不是一张越写越长的检查清单，而是三样东西。

1. 明确目标

这套 Skill 到底在帮助模型完成什么？

不要让一个 Skill 同时承担审稿、重写、事实核查、标题生成和风格模仿等所有工作。

2. 给出优先级

当标准冲突时，什么最重要？

没有优先级，模型只能自己平均分配注意力。

3. 保留可变空间

不要把某一次任务中的取舍，永久写成适用于所有任务的规定。

如果一套 Skill 效果不好，第一反应不一定是继续补规则。

可以先检查：

它是不是同时承担了太多目标；
每一项要求是否都被写成同等重要；
某条规则是不是来自一次偶发失败；
哪些判断应该在调用时再提供；
当前模型、上下文、工具和运行参数是否已经变化。

上一篇说的是，模型变了，旧 Prompt 要重新试。

这一篇说的是，Prompt 自己也会在不断修补中改变。

放在一起看，结论其实很简单：

模型变了，重新测试 Prompt；规则越积越多，重新整理 Prompt。