从 Claude Code 源码里扒出 14 条提示词秘籍，读完发现：这些规则是写给人的
清明节有时间，从Claude Code 泄露的源码里，扒出了 Anthropic 写给自家 AI 的系统提示词。
其中有14 条规则，条条扎心。
但扎心的不是它有多复杂，而是它用的全是禁令：never、do not、critical。不是在教 AI 怎么变聪明，而是在一条一条堵它犯蠢的路。
我的第一反应是：这提示词工程确实有水平。
第二反应是：这不就是十几年踩过的坑吗？
一、核心发现：「不准做什么」比「应该做什么」有效 10 倍
Anthropic 的工程师显然想通了一件事——
与其教 AI 怎么做得更好，不如先列出它最容易犯的错，逐条写禁令。
这个思路反直觉。我们写提示词的本能是描述期望：「请用专业的语气回答」「请给出详细的步骤」。但 Claude Code 的系统提示词里，正面指令少得可怜，满屏都是「绝对不能做什么」。
为什么？因为 AI 和人一样——犯错的路径是有限的、可枚举的，而「做得更好」是无穷的、模糊的。
一句「请写出高质量的代码」，AI 理解不了。但一句「不准在没有读过文件的情况下编辑文件」，它立刻知道边界在哪。
二、14 条秘籍，我分成四组来拆
14 条规则我按底层逻辑重新分组，因为逐条罗列容易见木不见林。
第一组：堵住犯错路径（规则 1、3、14）
规则 1：用禁令代替指令。 少写「你要怎么做」，多写「绝对不能做什么」。 规则 3：不要画蛇添足。 不加没被要求的功能，不为不可能的情况做预防，三行重复代码好过一个过早抽象。 规则 14：限制工具使用方式。 专用工具不准用通用命令行代替——因为专用工具有操作记录、可追溯，通用命令行是黑箱。
这三条的底层逻辑是一样的：减少自由度。
自由度越大，犯错的排列组合越多。好的规则不是给更多选择，而是把不该走的路堵死。
第二组：强制认知诚实（规则 4、5、6、7）
规则 4：如实汇报，不吹牛也不谦虚。 没做好就说没做好，做好了也别加一堆免责声明。 规则 5：活可以分出去，但思考不行。 可以派子任务，但不能外包理解。别写「根据你的调查结果处理」——你自己先消化、先判断。 规则 6：不知道就说不知道。 没有信息的时候不编造，不预测进展，杜绝幻觉。 规则 7：先看再改，不准凭空编造。 必须先读过文件内容才能编辑，否则系统直接报错。这四条的共同主题：反对「看起来在做事」。
AI 最危险的模式不是不会做，而是不会做的时候装会做——胡编一个看上去合理的答案，你还信以为真。这组规则的核心是：宁可暴露无知，不准伪装能力。
第三组：权限与边界管理（规则 8、9、10）
规则 8：一次授权≠永久授权。 你批准一次操作，不代表以后同类操作都自动通过。 规则 9：每条禁令写清楚「为什么」。 不只写「不准」，还要写原因和后果。AI 懂了边界的理由，才不会自己绕路。 规则 10：信息按需加载。 先给工具名，用到时再加载详细说明。避免信息过载。这三条的底层逻辑：最小权限原则。
给够用的权限，不给多余的。给够用的信息，不给多余的。而且每条限制都要解释原因——不是为了「说服」AI，而是让它在模糊地带有判断依据。
第四组：系统化防御（规则 2、11、12、13）
规则 2：专门设一个唱反调的验证角色。 它的任务不是确认「能用」，而是尽量找出问题。 规则 11：沟通规范细到标点符号。 不准用 emoji，不准废话，先说结论再说理由。 规则 12：不同场景加载不同规则。 外部环境宽松，内部更严；公开场合隐藏敏感信息。 规则 13：提示词模块化。 拆成角色、规则、任务、风格等独立模块，按场景动态组合。这四条构成了一个防御性系统架构：内置质疑者、统一沟通标准、场景化规则切换、模块化维护。
三、等等——这不是在说 AI，这是在说人
上面 14 条规则，你把「AI」替换成「新入职的工程师」，每一条都成立。
你再把「AI」替换成「你自己」，每一条都更成立。
我们花大量精力教 AI 的那些规则，恰恰是我们自己最不遵守的。来，逐条对照：
「用禁令代替指令」→ 你给团队的 coding guideline 是不是全在说「应该怎么做」，却从没列过「绝对不能做什么」？我见过太多团队的开发规范：洋洋洒洒写了 50 页「最佳实践」，新人看完一页就关了。但如果你只写 10 条「红线」——不准直接改生产数据库、不准在 PR 里偷加无关改动、不准不跑测试就合代码——效果比 50 页文档好 10 倍。
「活可以分出去，但思考不行」→ 你是不是也在把判断外包给下属，然后说「你看着办」？「你调研一下吧，调研完告诉我结论。」这句话我说过不下一百次。直到有一天我发现：下属调研完给我的「结论」，其实是他基于他的认知边界做的判断，而我不加消化就采纳了。这跟写提示词说「based on your findings, implement it」一模一样——你外包了理解。
「不知道就说不知道」→ 你上次在会上说「我不知道」是什么时候？AI 的幻觉和人的面子本质上是一回事：没有信息的时候，与其承认无知，不如编造一个看起来合理的答案。我们教 AI 不准瞎编，自己却在每天的工作中不停地「合理推测」。
「一次授权≠永久授权」→ 你是不是也在放任团队越来越大胆？批准了一次加急上线，下次就变成了「上次也这么干的」。批准了一次跳过 code review，下次就变成了「紧急情况都可以跳」。权限的蔓延，在人身上比在 AI 身上严重一百倍。
「每条禁令写清楚为什么」→ 你定的规则，下面的人知道原因吗？「代码提交前必须跑 CI」——为什么？因为上个季度有人不跑 CI 直接合了代码，挂了生产环境三小时。把这个故事讲出来，规则才不会被绕过。没有原因的禁令，人和 AI 都会想方设法绕开。
四、底层逻辑：好的系统设计是堵漏洞，不是教做人
这 14 条规则揭示了一个管理学的老命题：
好的制度设计不依赖个体的自觉，而是让犯错变得困难。
Anthropic 的工程师不相信 AI 会「自觉变好」，所以他们设计了一套约束系统：读过才能改、用过才算授权、信息按需加载、内置质疑角色。
好的管理者也不应该相信团队会「自觉变好」。不是因为团队不好，而是因为自觉是最不可靠的资源。人会疲倦，会侥幸，会路径依赖。
真正有效的管理，是把护栏焊死，而不是每天早上喊口号。
这跟软件工程是一个道理：你不会用一句注释「请不要传 null」来防止空指针异常——你用类型系统、用编译器、用断言。
对 AI 的约束写成代码。对人的约束，写成制度和流程。五、你现在可以做的三件事
如果你只是用 AI 工具，这些规则能帮你写出更好的提示词。
但如果你带团队、做产品、管项目，这些规则的价值远不止于此。
第一，重写你的团队规范。 把「最佳实践」砍到最少，把「红线清单」写到最多。每条红线附上原因和真实事故。新人入职第一天只看这份清单。 第二，建立「唱反调」机制。 每个重要决策，指定一个人的职责就是找问题。不是为了否定，而是为了让盲点暴露在损失发生之前。 第三，审视你自己的工作方式。 你有没有在不了解情况的时候假装了解？有没有把判断外包给别人然后直接采纳？有没有因为忙就跳过了验证？Anthropic 花了巨大的精力教 AI 不犯蠢。你花了多少精力教自己？
不是 AI 需要禁令，是所有容易犯错的智能体都需要禁令。你也是一个智能体。