AI 输出品控的边界感——哪些地方该装规则，哪些地方该让 AI 自己发挥
装了半年 sharp-skills，我走过一段弯路：恨不得所有 AI 输出的场景都套上规则，结果发现规则装得越多，AI 反而越呆。
技术文档要规则，API 设计要规则，图表配色要规则——这些都没问题。但当我想给"代码评审"装规则时，发现写出来 50 条规则里能执行的不到 10 条；当我想给"架构方案"装规则时，发现品控变成了僵化的设计模板，AI 输出的方案比不用规则还差。
sharp-skills 不是万能胶水，不是所有地方都该装规则。品控有边界，过了边界就是束缚。
一个反例：规则装过头是什么样
去年我做过一件蠢事。我想让 AI 帮我们团队做技术方案评审——输入是"上线一个订单导出功能"，输出是一份"方案是否合理"的评审意见。
我开始写规则：
- MUST: 方案必须包含技术选型理由
- MUST: 方案必须列出风险点
- MUST: 方案必须考虑幂等性
- SHOULD: 方案应该考虑数据一致性
- SHOULD: 方案应该考虑监控告警
- SHOULD: 方案应该考虑回滚方案
- MAY: 方案可以考虑性能压测
写到第 30 条规则的时候，我开始发现问题了。
第一条问题：规则之间开始打架。"方案必须考虑幂等性"和"方案应该考虑可观测性"听起来都对，但当 AI 强制都执行时，输出的方案里每条功能都要塞幂等设计、每条接口都要配监控，方案变得臃肿且过度工程化。
第二条问题：规则无法覆盖真正的关键决策。"为什么选择 RocketMQ 而不是 Kafka"——这种选型决策 AI 写出来都是泛泛的"考虑吞吐量和延迟"，规则约束不了，因为约束条件本身是个开放问题。
第三条问题：AI 输出一旦被规则绑死，就失去了"灵感"能力。技术方案评审里最有价值的反而是"这里有个反直觉的设计"或"这里我看到类似系统的另一种做法"——这些不是规则能逼出来的。
这个场景我后来砍掉了大部分规则，只留 3 条最关键的，剩下的让 AI 自由发挥。品控边界不是"全装"，是"挑关键装"。
三个判断标准：该不该装规则
不是所有场景都适合用 sharp-skills 装规则。判断标准我总结了三个。
第一个：可重复性。
这个任务会不会以相近的形态反复出现？如果一个任务一年就做一次，写规则的成本比收益高。如果一个任务每天做 10 次，规则写一次能用 3650 次，ROI 极高。
API 文档生成、接口设计、面试题设计——这些是高重复场景，每个都该装规则。架构方案评审、一次性技术调研——这些是低重复场景，规则性价比不高。
第二个：可验证性。
这个任务的结果有没有明确的"对错"标准？如果有，规则好用；如果是开放问题，规则就变成教条。
API 设计有标准——RESTful 约束、错误码体系、幂等性设计——这些都有明确的"对"和"错"。营销文案没有标准——同一个卖点可以用"赋能"也可以用"成就"，没有对错，只有效果差异。
sharp-skills 的 6 个模块（tech-writing、dataviz、copywriting、api-design、interview、presentation）选的都是可验证的场景，不是巧合。
第三个：可量化性。
这个任务的质量能不能拆成可量化的维度？
API 文档的质量可以拆成：参数完整性、错误码覆盖、示例可运行性、版本标注——每个维度都能打勾。
架构方案的质量很难拆——"方案是否优雅"这种维度没法量化。AI 能写出来"包含 7 个维度"的内容，但写不出"优雅"。
三个该装规则的场景
回到 sharp-skills 的应用，我总结出三个最该装规则的场景。
第一种：高频次的标准化输出。
比如你团队每天要写 5 个 API 文档、每天要评审 3 个 PR、每天要生成 10 个测试用例。这种高频次场景下，规则一次编写长期受益。sharp-tech-writing、sharp-api-design、sharp-interview 这三个模块对的就是这种场景。
第二种：质量风险高、错误代价大的输出。
比如写用户协议的文案、生成数据迁移的 SQL、设计支付接口的错误处理——这种场景输出错了代价很大，必须有规则约束，不能依赖 AI 自觉。
sharp-copywriting 里关于"避免误导性表述"的规则、sharp-api-design 里关于"幂等性设计"的规则、sharp-tech-writing 里关于"废弃 API 标注"的规则——这些对的都是高风险场景。
第三种：跨成员复用、跨项目复用的输出。
如果一个团队 5 个人都要写 API 文档，规则可以保证 5 个人写出来风格一致。如果一个项目要做 3 个微服务，规则可以保证 3 个微服务的 API 风格统一。这种"团队一致性"和"项目一致性"的需求，是规则最该出场的地方。
三个不该装规则的场景
相对应地，也有三个场景不该装规则。
第一种：一次性、探索性任务。
技术调研、POC 验证、新技术选型评估——这些是一次性任务，质量标准本身就在变化，今天觉得好的方案明天可能就过时。规则会锁死 AI 的探索能力，不如让它自由发挥，自己再做判断。
第二种：高度依赖上下文的创意性输出。
写一句产品 slogan、设计一个用户引导流程、起一个有调性的活动名字——这种输出的质量高度依赖品牌调性、用户认知、市场时机，没有通用规则可言。AI 在这些场景下的"灵感"反而比"标准答案"更有价值。
第三种：规则覆盖成本高于收益的复杂任务。
架构设计、系统容量规划、故障复盘——这些任务本身复杂度极高，试图用规则穷举所有质量维度会陷入两种困境：要么规则太严格导致 AI 失去思考能力，要么规则太宽松形同虚设。遇到这种任务，我现在的做法是只装 3-5 条"硬规则"（比如"故障复盘必须包含根因"），剩下的留给人来判断。
规则的边际收益曲线
把规则覆盖率（横轴）和输出质量（纵轴）画成曲线，你会发现一个规律：
- 覆盖率 0% → 30%：质量从 50 分到 80 分，提升最明显
- 覆盖率 30% → 70%：质量从 80 分到 90 分，提升变缓
- 覆盖率 70% → 100%：质量从 90 分到 92 分，提升极小
- 覆盖率 > 100%（规则过度严苛）：质量开始下降，AI 输出变得僵化
这就是品控的"边际收益递减"。sharp-skills 的 6 个模块不是要做到 100% 覆盖率，是要把每个领域从 50 分拉到 90 分。剩下的 8 分靠人来做，不是规则能做好的。
我现在的做法是：每个领域先装 10-15 条 MUST 级硬规则，覆盖最关键的质量维度。装完跑一周看输出，如果发现新问题再补规则。如果补到 30 条规则还没有明显质量提升，说明这个领域不适合用规则主导。
边界感是品控的一部分
品控不是为了把 AI 训练成听话的工具人，是为了在"AI 自由发挥"和"标准化输出"之间找到平衡点。
sharp-skills 提供了 6 个最常见领域的规则模板，但用不用、怎么用、用多少，是你的判断。如果你的项目只需要 3 个模块，不需要硬装 6 个。如果某个领域你发现规则装上反而更差，就该拆掉。
装规则之前先问自己三个问题：
- 这个场景的输出频率有多高？
- 这个场景的错误代价有多大？
- 这个场景的输出质量能不能拆解成可量化维度？
三个问题答得越清楚，规则该不该装就越明确。品控不是装得越多越好，是装得准才好。
最近在做那个小程序「爪爪代码冒险记」也遇到类似问题——23 个设计模式哪些该用漫画重讲、哪些该用代码演示、哪些该让用户自己探索，本质也是品控边界问题。规则适合教套路，自由发挥适合练手感。
