Anthropic 旗舰模型的 3.4 万 token 系统提示词被公开到 GitHub——64 章、30 个工具 schema、完整合规手册。这不是八卦，而是一份 AIcoding 产品化的硬核说明书。
2026 年 7 月 26 日，开发者 Eversmile1 把 Anthropic 旗舰模型的完整系统提示词扔到了 GitHub——135027 个字符、19370 个英文词、折合约 3.4 万 token，被拆成 64 章。仓库很快被 DMCA 下架，但镜像已经满天飞。对 AIcoding 行业来说，这份文件的价值不在于满足好奇心，而在于它把「闭源模型如何做产品化」的完整蓝图摊在了桌面上。
读完这 3.4 万 token，你会发现 Anthropic 不是在写 prompt——他们在写一套完整的 AI 产品操作系统。三层结构分工明确：
系统提示词的第一大块是工具定义：bash 执行、文件读写、代码搜索、多会话记忆管理、网页浏览……共 30 个工具，每个都附带了完整的 JSON schema 参数约束。这相当于把模型「能力边界」白纸黑字写给了它自己看。例如文件编辑工具不仅定义了 replace 的输入格式，还明确约定了冲突处理策略——当两次编辑冲突时，必须重新读取文件而非盲目覆盖。
跨会话记忆系统的设计尤其值得注意。Opus 5 的记忆不是简单的「记住用户说了什么」，而是一套分层存储机制：短期对话缓存、中期项目上下文、长期用户偏好。模型需要自主判断什么信息该存到哪一层，以及何时该「忘记」。
第二大块是 Anthropic 内部称为「模型宪法」的合规体系，覆盖版权保护、儿童安全、危机干预、政治中立四大领域。一个关键设计原则是：合规规则的优先级高于用户请求。当用户要求生成受版权保护的内容时，模型的拒绝不是「道德判断」而是系统提示词中的硬约束——就像操作系统的权限管理，用户态程序无权绕过内核的安全策略。
版权部分尤其具体：模型被明确禁止输出完整歌曲歌词、受版权保护的书籍章节、或模仿在世作家的风格进行长篇创作。这直接影响 AIcoding 场景——如果你的团队用 AI 辅助编程，模型内部已经在检查生成的代码片段是否与已知开源项目存在实质性相似。
第三块出乎很多人意料：一份详细的 recommend_claude_apps 工具说明，规定了模型在什么场景下可以推荐自家桌面应用、移动端 app 或 API 服务，以及推荐时必须使用的措辞。这不是 bug，而是厂商故意放进系统提示词的「软销售」逻辑——每一次产品推荐都要经过三层过滤：相关性判断 → 措辞模板选择 → 披露声明附加。
如果你做过 AIcoding 工具的落地实施，这个问题的答案不言自明。
企业 AIcoding 场景下，AI 需要同时理解四层上下文：代码仓库的架构约定（这个项目是微服务还是单体）、团队编码规范（用 Prettier 还是 ESLint、缩进几个空格）、业务领域知识（这个函数处理的是医疗数据还是金融交易）、安全与合规边界（哪些第三方库有许可证风险、哪些 API 调用需要审计日志）。每一层都是独立的「子系统」，而系统提示词就是协调这些子系统的运行时调度器。
我们在之前的实践中验证过这一点——通过提示词瘦身 80%，编程助手的 AIcoding 效率反而提升，但前提是你在瘦身之前已经明确了哪些约束是「硬规则」、哪些是「软建议」。Anthropic 的 3.4 万 token 提示词说明他们选择了「先做全、再做精」的路径——把所有边界条件都写进去，再通过内部测试逐步修剪。
| 层级 | 系统提示词占比 | 企业 AIcoding 对应层 |
|---|---|---|
| 工具定义与能力边界 | 约 45% | IDE 插件配置 + CI/CD 集成 |
| 合规与安全约束 | 约 35% | 代码审查规则 + 许可证合规检查 |
| 产品推销逻辑 | 约 10% | 内部工具推广话术（非必要） |
| 会话管理与记忆 | 约 10% | 项目上下文缓存 + 团队知识库 |
这份泄露文档给企业团队的三条可直接落地的启示：
不要把所有规则塞进一个巨大的系统提示词。拆成三层：全局规则层（永远不输出个人隐私数据、永远不执行 rm -rf 等破坏性命令——这些是硬约束，写在系统级 prompt 里）、项目规则层（代码风格、框架约定、目录结构——写在项目根目录的 .aicoding 配置文件中，随 Git 版本管理）、会话上下文层（当前任务的目标、上一步的输出、用户反馈——写在每次 API 调用的 messages 里）。
这与 Anthropic 的系统提示词结构高度一致：全局合规 = 硬约束层，工具定义 = 项目规则层，记忆系统 = 会话上下文层。Opus 5 上线后我们的实测表明，这种分层设计可以让 token 消耗降低 30-40%，同时保持输出质量。
如果你的团队用 AI 生成生产级代码，必须在系统提示词中写入明确的许可证约束。具体做法：
Anthropic 已经在模型层做了第一步，但第二步和第三步是企业自己的责任——模型厂商的合规只能到「输出阶段」，代码入库后的风险需要工程团队自己兜底。
Opus 5 的 30 个工具 schema 给出了一个关键设计原则：每个工具的权限范围必须在 JSON schema 中显式定义，不允许模型自行推导。例如 bash 工具明确限制了可执行的命令白名单、文件读写工具限制了可访问的路径范围。这对企业 AIcoding 的启示是：如果你在搭建自己的 AI 编程 Agent，不要给模型一个「万能 shell」——给它一组精确限定范围的工具，每个工具的权限用 schema 锁死。
这是这次泄露事件把 AIcoding 商业化推到的一个分岔路口。
闭源路线的代表是 Anthropic 和 OpenAI——系统提示词是黑盒的、由厂商维护、用户只能通过 API 参数做有限的微调。优点是开箱即用、合规责任在厂商；缺点是你不知道自己团队的代码被什么样的「宪法」约束着，也不知道模型的推销逻辑是否在悄悄影响输出。
开源路线——用 DeepSeek、Qwen、Llama 等开源模型，自己写系统提示词——则完全相反。你可以精确控制每一行规则，能够针对行业场景（医疗 HIPAA 合规、金融 PCI-DSS 审计追踪）做深度定制。但代价是需要一个真正懂提示工程的团队来维护这些规则，而且每次模型升级都可能需要重新测试系统提示词的有效性。
我们过去半年在企业 AIcoding 落地中摸到的结论是：年代码量超过 10 万行的团队，自建系统提示词的 ROI 远高于依赖闭源模型默认行为——因为你团队的技术债、编码约定和业务约束，没有任何一个通用模型能内置。
直接影响有限——你不会因为读了这份提示词就让 AI 写出更好的代码。但间接影响很大：它揭示了 AIcoding 工具的产品设计逻辑，帮你在做工具选型时有了一个「对照基准」。你知道一个成熟 AIcoding 产品应该在系统层解决哪些问题，也就能判断你正在评估的工具在哪些维度上偷了懒。
普通 prompt engineering 是「给模型写一段指令」，系统提示词是「给模型写一部运行宪法」。前者影响一次对话的质量，后者定义模型的全部行为边界——包括什么能做、什么不能做、在什么情况下该拒绝、拒绝时用什么措辞。Anthropic 的实践说明，一个真正产品化的 AI 系统，系统提示词的工作量至少是用户可见 prompt 的 10 倍。
取决于团队规模和技术栈复杂度。5 人以下、技术栈标准化的团队，默认配置够用。10 人以上、有明确编码规范和企业合规要求的团队，建议在默认配置之上叠加项目级规则层——不需要从零写 3.4 万 token，但至少要把你的 .eslintrc 精神写进系统提示词。
大概率会。可能的两个方向：一是把系统提示词拆成「公开层」和「私有层」，公开层继续暴露在 API 响应中，私有层（合规细节、推荐话术）移到服务端做推理前注入；二是加速系统提示词的迭代频率，让泄露的版本快速过时。无论哪种，对企业用户来说，这都意味着「黑盒」程度加深——你需要更强的内部提示工程能力来抵消厂商的不透明性。
如果你正在评估 AIcoding 工具的企业级落地路径，或者想了解如何为自己的团队定制系统提示词体系，联系我们 或查看 已交付案例——我们从 2025 年开始帮企业搭建 AIcoding 工作流，踩过的坑比大多数团队见过的都多。
