请允许康泰俊先把话说清楚。这篇文章既不是在谈如何利用泄露的资料，也不是在谈如何"越狱"某套系统——对这两件事，他都不感兴趣；任何一位真正在经营公司的人也不应该感兴趣。他真正感兴趣的是：一份被深度打磨过的生产级系统提示词，在其结构本身里到底告诉了我们什么——关于"如何写出在真实世界里真正奏效的 AI 智能体指令"这件事，一份能在压力下、在规模下、在真实用户试图破坏它时仍能稳定运作的指令。
Anthropic 本身其实已经公开了大量相关材料——请参阅他们官方的系统提示词发布说明——而 Simon Willison 则是目前公开环境里对这些提示词结构及其揭示的内容做得最出色的一位记录者。那些被曝光的提示词之所以有价值，不是因为它们暴露了什么秘密，而是因为它们展示了：一支真正懂自己在做什么的团队，在严肃的生产级规模上，是如何给一个强大模型写指令的。而他们写指令的方式，与大多数创始人和经营者在给 AI 智能体写提示词时的做法，几乎毫无相似之处。
第一课：结构本身，就是指令
读任何一份严肃的生产级提示词，最先击中你的就是它所呈现出的"结构性脚手架"的密度——分节、分章节标题、带编号的规则、明确的角色定义、用 XML 标签区分不同类别指令。这不是风格问题，这本身就是指令。
当你把一整段墙面式的文字一股脑扔给模型时，模型必须自己去推理"你这段话里的不同部分分别是什么意思、它们之间是什么关系"。而当你明确告诉它——"这一节是关于安全，这一节是关于工具使用，这一节是关于什么时候拒绝执行"——光是把标题写好，你就已经完成了提示词工程一半的工作。
康先生认识的大多数创始人写出来的提示词长得像一封邮件：一句问候、一段陈述、一个请求、一个署名。这套对一个已经很了解你公司的实习生管用，但对一个在对抗性环境里、在规模上运作的模型，并不管用。
第二课：规则优于示例，示例优于抽象
严肃的生产级提示词有一个非常明确的分层：硬规则在最上面（"永远不要做 X"）、具体示例在中间、抽象原则作为最后的兜底放在底部。那份流传出来的 Claude Code 提示词几乎完美地遵循了这个结构。
而大多数经营者自己写的提示词恰恰相反：开头就是一堆模糊的抽象——"请保持有用和准确"——既不给硬规则，也不给具体示例。模型尽力而为，却没有任何锚点可依赖。于是它的行为以一种你无法预测、无法复现、也无法调试的方式漂移。
认真读过之后，康先生得出的结论是：他给一个智能体的每一条指令，都至少要附带一个"正确输出应该长什么样"的具体示例。如果他写不出这个示例，那就意味着他自己都还没把"想要什么"想清楚到足以下指令的地步——那么智能体当然更不可能替他想清楚。
如果你无法给智能体展示一个"你想要的正确输出长什么样"的示例，那么智能体就无法替你造出一个来。示例本身，就是规格书。
第三课："拒绝行为"是一个设计问题，不是一个安全问题
系统提示词中相当大的篇幅，是在规定模型"什么时候、以什么方式拒绝做一件事"——而且远不只是"违法内容"那一块。它包含了一整套分类法：什么时候拒绝、什么时候反推回去、什么时候主动提出澄清性问题、什么时候直接上手。这一整套分类法是被工程设计出来的，而不是被默认假设出来的。
如果你正在为自己的公司打造一个智能体产品，"拒绝行为"绝不是一个事后补丁。它是你整个提示词里杠杆最高的一部分。因为每一次智能体应该说"我需要更多信息"的时候却说了"我尽力试试"；每一次智能体本该尝试的时候却说了"我帮不了这个"——你都在消耗用户对它的信任，并把他们训练成"绕开你这个智能体去做事"的人。"言出必行，行之所言"——这句话同样适用于智能体。如果智能体自己都无法在"什么事我会做、什么事我不会做"之间划出一条清晰的线，那么它会对本不该说是的事情说"是"，同时对本该说是的事情说"否"。
先设计你的"拒绝分类法"，再设计你的"顺利路径"。这是成年人的做法。
第四课：工具使用指令所需要的字数，要比任务指令更多
在那份提示词里，关于"如何以及何时使用工具"的指令，明显比关于"要执行什么任务"的指令长得多。这不是偶然。工具使用，正是智能体在真实世界里翻车的地方——调错工具、调对工具但传错参数、按错误顺序调用工具、本该先问一个澄清性问题却直接上手调了一个工具。
如果你公司的智能体有权调用任何工具——数据库、API、文件系统、搜索索引——那你至少应当把 60% 的提示词工程时间花在"工具使用指令"上。不是人格，不是语气，而是这些机械细节：什么时候伸手去拿哪个工具，以及如何验证它是否真的做了它说自己做了的事情。
第五课：提示词是一份"政策"，不是一段对话
读过一份真正的生产级提示词之后，康先生最重要的一次思维转变就是这一条——系统提示词不是一条消息，它是一份政策。它是智能体赖以运作的成文宪法。它应当像一份法律文件那样被写出来：精确、无歧义，在相互冲突的规则之间写明优先级，对边缘情况有专门条款。
而大多数由创始人自己写的提示词，读起来都像对话——像一条发给新入职同事的 Slack 消息。由此而来的智能体，也就长得像一位"只被做了五分钟入职培训的新人"：热情、大多数时候有帮助、偶尔灾难级翻车、每天表现都不一致。
把你给智能体写的系统提示词，像"等会儿要被一位律师从头读一遍"那样重写一次。不是因为你希望智能体听起来像律师，而是因为——把它写到那样的精度所需要的那种专注度，恰恰是你的智能体在"同一时间有一千个用户在敲它"时所需要的那种一致性。
读完之后他自己做了什么
在自己日常使用的工具链中，他对"写提示词"这件事做了三项实际调整：
- 任何新智能体的提示词，现在他都从一张结构大纲开始写——角色、硬规则、工具使用指令、示例、拒绝分类法、边缘情况——在写出任何一句正文之前先把骨架搭好。
- 对每一条主要指令，他强制自己至少写出三个具体示例。如果他写不出来，就说明这条指令还没被定义清楚——这是他给自己的一个信号，而不是一场挫败。
- 他把提示词当作"有版本管理的政策"来对待。每一次改动都要有一个提交说明，每一次改动都要用同一组场景再跑一遍回归测试。凌晨一点的牛仔式即兴修改，严禁发生。
你不需要真的去读任何一份"被泄露"的提示词，也完全可以开始采用这三项习惯。但如果有一天你确实接触到了一份严肃的生产级提示词——请带着开放的心认真读一遍。它会比任何一篇关于提示词工程的博客（包括这一篇）教给你更多的东西。
这是他给你的拷问：现在就把你那个"最重要的智能体"正在用的系统提示词调出来。像一位正在审查合同的律师那样逐句读一遍。对每一句话都问：这条规则够具体吗？有示例吗？当两条规则冲突时，它的优先级还能站得住吗？只要三个答案中有一个是"否"，请在这一周内就把它重写掉。"一个真正奏效的智能体"与"一个在周二下午让你当场尴尬的智能体"之间的差距，几乎总是在提示词里，而不是在模型里。
关于康先生如何把这一切接入到自己日常运营的工作台里，请参阅《AI 进入经营者的驾驶舱》。