你的 AI prompt 写了 500 字，输出还是差点意思——不是你不会写 prompt，是该把品控逻辑交给规则文件

你有没有过这种体验：

给 AI 写了一长串 prompt，"输出要结构清晰、不要用黑话、数据要有来源标注、结论要具体不要空泛……"，500 字的指令写完，第一次输出还行，第二次就开始偷懒，第三次直接把你的要求忘了一半。

这不是你的 prompt 写得不好。这是 prompt 本身就不适合承载品控逻辑。

prompt 的衰减是结构性的

prompt 是一段自然语言文本，它的运作方式是"一次性注入上下文"。问题在于：

没有优先级。你写了 20 条要求，AI 把它们当成同一权重的东西来处理。"不要用黑话"和"结论要具体"在 prompt 里地位平等，但 AI 执行的时候会选择性遗忘后面的条目——这不是 bug，是 attention 机制的天然衰减。
没有可执行结构。"输出要有层次感"这种表述，对 AI 来说跟"尽量好看"差不多。它不是一条可判定、可检查的规则，它是一条模糊的期望。
没有检查机制。prompt 只管"生成"，不管"校验"。你没法在 prompt 里写"如果输出包含以下词汇就拒绝"，因为 prompt 的作用止步于输入端，输出端没有任何拦截。

所以你看到的"第一次还行后面越来越糊"不是偶然现象，是 prompt 承载品控的固有缺陷。

规则文件为什么不一样

sharp-skills 的做法是把品控逻辑从 prompt 里抽出来，编码成独立的规则文件。一个规则文件的结构大致是这样：

# MUST 规则（违反就拒绝输出）
- 禁止出现：赋能、闭环、抓手、沉淀、矩阵、打法
- 结论段必须包含至少 1 个可验证的数据或事实
- 每个技术主张必须附带 1 个代码片段或配置示例

# SHOULD 规则（违反就标记为待修正）
- 段落长度控制在 150-300 字
- 代码示例必须包含 import 语句和完整方法签名
- 对比论证至少涉及 2 个方案

# MAY 规则（建议但不强制）
- 优先使用主动语态
- 避免连续 3 段以上纯文字描述

MUST/SHOULD/MAY 三级优先级解决的是 prompt 的"无优先级"问题。MUST 是硬门槛，违反就直接打回；SHOULD 是质量线，违反会标记但不会拒绝；MAY 是风格建议，违反无所谓。AI 不需要"记住 20 条同等权重的期望"，它只需要按三级优先级依次检查。

可判定的表述解决的是"模糊期望"问题。"结论段必须包含至少 1 个可验证的数据或事实"是一条可以逐条检查的规则，AI 可以在生成完之后自检：扫一遍结论段，看有没有数据/事实，没有就补上。这比"结论要具体"有效率得多。

实测对比：同一个任务，两种品控方式

我用同一个任务测试过：写一篇关于 Redis 缓存策略的技术文章。

纯 prompt 方案：写了一段 400 字的 prompt，包含"结构清晰、有代码示例、不要空话、结论要落地"等要求。

第 1 次输出：结构还行，代码有但 import 缺了，结论段写的是"合理使用缓存可以显著提升系统性能"——典型的空话。

第 3 次输出：结构开始松散，代码示例缩水到只有 2 行配置，结论段变成了一个总结性的泛泛陈述。

规则文件方案：把同样的品控要求编码成 sharp-tech-writing 的规则文件，MUST 3 条、SHOULD 5 条、MAY 2 条。

第 1 次输出：结构稳定，代码示例包含完整方法签名和 import，结论段写了"在笔者实测中，热点 key 本地缓存 + Redis 二级缓存的方案，将 QPS 从 1200 提升到 4500，P99 延迟从 85ms 降到 12ms"——有数据、可验证。

第 5 次输出：质量没有衰减。因为规则文件是每次生成前都会注入的，不存在"遗忘后半段要求"的问题。

这不是玄学，是结构差异带来的必然结果。

三种常见的"伪规则文件"

有些人看到规则文件的效果，也想自己搞一套，但写了之后发现没用。大概率是踩了这三种坑：

第一种：全是 MAY。 写了 15 条规则，全是"建议""优先""尽量"，没有一条 MUST。这等于没有规则文件——AI 看到的跟看一段 prompt 没区别，因为没有任何硬约束。

第二种：规则太抽象。 "代码示例要完整"——什么叫完整？是包含 import 就算完整，还是必须包含完整的类定义、方法签名、异常处理？抽象规则对 AI 来说跟模糊 prompt 一样不可执行。"代码示例必须包含 import 语句和完整方法签名"才是可判定的规则。

第三种：跟业务脱节。 从别人的规则文件里抄了一堆通用规则，但没改过任何一条来适配自己的场景。sharp-tech-writing 的规则适合技术文档，但你写的是 API 设计文档，应该用 sharp-api-design 的规则。品控规则必须跟领域匹配，通用规则等于没有规则。

taste-skill 不是品控规则的替代品

有人会问：taste-skill 不是也在做品控吗？跟规则文件什么关系？

taste-skill 做的是"审美判断"——它判断的是输出的风格、语气、可读性这些主观维度。它能告诉你"这段话读起来像 AI 写的"或者"这个图表配色不协调"，但它没法告诉你"结论段缺了数据"或者"代码示例缺了 import"。

sharp-skills 做的是"工程品控"——它判断的是可量化、可判定的客观维度。MUST 规则是一条检查清单，不是审美偏好。

两者是互补的：taste-skill 管风格，sharp-skills 管质量底线。如果你只有 taste-skill，AI 的输出可能读起来舒服但内容空洞；如果你只有 sharp-skills，AI 的输出可能内容扎实但读起来干硬。两个一起用，输出才既有质量又有味道。

落地四步

从你的实际痛点出发。 回看你最近 5 次 AI 输出，挑出最让你不满意的那次，把不满意的地方拆成可判定的规则。比如"结论太空泛"拆成"结论段必须包含至少 1 个可验证的数据"。
分级。 哪些是硬底线（违反就不能用），哪些是质量线（违反要修正），哪些是风格偏好（违反无所谓）。对应成 MUST/SHOULD/MAY。
写得可判定。 每条规则都能用"是/否"来判断是否违反。如果判断不了，要么细化规则，要么降级为 MAY。
持续迭代。 规则文件不是写完就完的。每次发现 AI 输出有新问题，就加一条规则；每次发现某条规则太严导致输出僵化，就降级或删除。

我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，23 个设计模式用漫画加答题的方式讲，目前正在开发中。如果你觉得这类内容有意思，搜一下「爪爪代码冒险记」，或者等我后面的文章。

说到底

AI 不是不会做，是太糊弄。你用 prompt 告诉它"要认真做"，它会认真做一次；你用规则文件告诉它"不认真做就打回"，它每次都会认真做。

prompt 是期望，规则是底线。期望会衰减，底线不会。