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 个设计模式哪些该用漫画重讲、哪些该用代码演示、哪些该让用户自己探索本质也是品控边界问题。规则适合教套路自由发挥适合练手感。