有位读者私信我说他去面阿里大模型应用架构方向的岗位被P9问了一道题卡住了。题目是这样的你研究过 Claude Code 的源码那你说下它的系统提示词是怎么写的“他回答说就是静态内容和动态内容拼在一起静态的放前面动态的放后面。P9听完笑了笑说你说对了一部分但实际上没这么简单建议回去仔细看看”。他面完之后很困惑问我这个回答到底哪里有问题。我帮他复盘了一下发现问题不在于他答错了而在于他只答出了一个维度。Claude Code 的系统提示词确实有静态和动态的分离但这只是其中一个设计背后还有代码风格指令的写法、行动风险框架的构建、安全指令的维护机制、防说谎约束——这些他当时都没提到。这个问题其实挺典型的。大多数人对系统提示词的认知停留在拼接这个层面但真正做工程的人关注的是怎么拼、为什么这么拼、每个模块解决什么问题。今天就把这五个设计都讲清楚。1. 系统提示词从文本到工程系统说到 Agent 开发嘛有一件事几乎每个人都干过但真正认真做的人其实不多。那就是写系统提示词。大多数人对这个东西的理解呢还停留在开头先介绍一下角色然后下面列几条规则这个层面。但你要是去翻 Claude Code 的源码就会发现这个认知跟现实之间差距还挺大的。它的系统提示词有 900 多行由十几个功能独立的模块拼接而成每个模块解决的是不同的问题。有的模块对所有用户完全一样有的模块是随着每次会话动态生成的模块之间还设了明确的分界标记来控制服务端的缓存行为。所以这不是一段文字这是一套工程系统。今天是 Claude Code 源码系列的第八期我挑了五个最有启发性的设计来讲。这也是那位读者面试时被追问的真正考察点——面试官想听的不是静态加动态而是每个设计背后的工程决策。2. 设计一静态段跟动态段的分离Claude Code 的系统提示词呢被一个边界标记切成了两半。前半段是静态内容包括身份介绍、安全指令、代码风格规则、工具使用指南、行动风险评估框架这些。不管哪个用户、哪个会话看到的都是同一份。后半段是动态内容比如当前会话启用了哪些工具、记忆系统里装了什么东西、工作目录和操作系统的信息、用户的语言偏好、外部插件的说明之类的。这些是跟着每个会话走的每个人都不一样。那为什么要费心做这个区分呢答案就是缓存。大模型 API 有一种提示词缓存机制。简单来说就是如果两次请求的提示词前缀完全一样服务端就可以跳过重复计算直接复用之前算好的结果。按照 Anthropic 官方文档的说法缓存命中的 token 费用大概只有正常输入价格的 10% 左右。也就是说同样的内容第二次之后只收一成的钱。有实际测试数据显示一次比较重的 Opus 编程会话有缓存跟没缓存的成本差距可以达到五倍以上。那问题来了。如果静态内容和动态内容混在一起写的话每个用户的提示词前缀都不一样缓存就等于废了。Claude Code 的做法是把通用规则放在最前面会话特有的信息放在最后面。这样你跟另一个素不相识的用户共用同一套 Claude Code你们的系统提示词前半段在服务端共享同一份缓存Anthropic 只需要算一次就行了。对于正在开发多用户 Agent 的人来说这个设计的启发其实很直接。把对所有用户说的话跟对当前用户说的话分开前者往前放后者往后放。光是这一个调整就能让 API 账单好看不少。3. 设计二代码风格指令写得特别具体写提示词的时候最常见的偷懒方式大概就是这样的“请写高质量的代码”、“遵循最佳实践”。这类表达说了等于没说因为高质量和最佳实践在不同语境下意味着完全不同的东西模型没法从中提取出可执行的信息。Claude Code 的代码风格指令走的是另一条路。它的每一条都是具体的、有明确边界的。比如说没改过的代码不要加注释、文档字符串或者类型标注只在逻辑不自明的地方加注释。不要为假想的未来需求做设计。不要给一次性操作封装工具函数三行相似的代码比一个过早的抽象要强。没被要求加的功能就不要加修一个 Bug 不需要顺便清理周围的东西一个简单功能不需要附带可配置选项。不要写面向不可能场景的防御性代码只在系统边界做校验信任内部代码和框架的保证。可以看到每一条都是在告诉模型不要做什么而不只是要做到什么程度。这背后有一个反直觉的认知值得记住。那就是模型不怕规则多怕的是规则模糊。请简洁不是规则工具调用之间的文字不超过二十五个词才是规则。写好代码不是规则不要给你没改的代码加注释才是规则。有意思的是这种负面约束的写法跟 Google 内部的 Eng Practices 指南思路挺像的。与其说好代码应该怎样不如直接说代码审查时我们不接受什么。具体的禁止项往往比模糊的正向期望更容易执行。4. 设计三行动风险评估框架Claude Code 的系统提示词里有一段完整的该不该先确认的判断框架。注意这不是一张危险操作清单而是一套判断逻辑。框架的核心是两个维度可逆性和影响范围。本地的、可逆的操作比如编辑文件、跑测试直接执行就行。不可逆的、波及共享系统的操作比如强制推送代码、删除分支、向外部服务发送消息、修改基础设施权限这些就必须先确认。具体例子包括删除文件和分支、删除数据库表、强制推送、修改已发布的提交、上传内容到第三方工具。除此之外呢它还教模型怎么处理意外发现。碰到不认识的文件、分支或者配置先调查再行动不要直接覆盖因为那可能是用户正在进行中的工作。碰到锁文件先查是哪个进程在持有不要直接删。这个框架跟传统的白名单/黑名单方案有一个关键差别。当模型遇到一个从未见过的新操作时白名单方案是没法处理的但这套框架可以让模型自己去推断。这个操作可逆吗影响的是本地还是共享系统从而得出是否需要确认的结论。换句话说这不是在训练模型背规则而是在给模型装判断能力。5. 设计四安全指令由专门团队来维护源码里有一段叫 “Cyber Risk Instruction” 的安全指令划定了模型在安全相关请求上的行为边界。授权的渗透测试和防御性安全可以协助但拒绝服务攻击、大规模目标攻击、供应链攻击、以及出于恶意目的的检测规避一律拒绝。这段指令本身不长但源码注释里有一处特别值得注意。里面写了这段指令的具体负责人名字并且明确要求任何修改必须经过安全团队审批评估。原因是对这段文本的改动会对模型处理安全请求的方式产生重大影响。这个设计最有意思的地方其实不在技术层面而在工程管理层面。系统提示词不是一个随手可以编辑的配置文件。某些段落的修改会直接改变 Agent 的行为边界后果可能远超一般的 Bug。在团队协作中哪些提示词段落需要审批流程这件事跟哪些代码文件需要 Code Review是同等重要的。但实际上呢几乎没有团队认真对待前者。更广泛来说这是一个关于 AI 系统治理层级的问题。不同的提示词模块应该对应不同的修改权限和审批机制而不是让任何人在任何时候都能随意改动全部内容。6. 设计五防止模型说谎这是我在整个源码里觉得最务实的一段设计。它直接告诉模型如实报告结果。原文的逻辑大概是这样的测试失败了就说失败附上输出。没执行验证步骤就说没执行不要暗示它通过了。不能在输出显示失败的情况下生成所有测试通过。不能压缩失败信息来制造绿色结果。不能把未完成的工作说成已完成。但它的聪明之处在于紧接着还补了另一面。当检查确实通过了、任务确实完成了就直接说。不要加不必要的免责声明不要把已完成的工作降级成部分完成不要重新验证已经检查过的东西。这段注释里有一句话我觉得值得反复琢磨没有这段提示词的时候模型大约每三次就有一次会在报告执行结果时说谎或者夸大。这跟研究数据的方向是吻合的。2025 年一项多模型研究发现在对抗性场景下简单的提示词干预可以将 GPT-4o 的虚假输出率从 53% 压到 23%。也就是说提示词对说谎倾向的影响是真实的、可测量的。这背后的机制其实不神秘。模型的训练目标天然倾向于生成用户期望听到的答案坏消息的吸引力远不如好消息。所以在没有明确约束的情况下它会默默偏向乐观报告。你需要用双向约束来矫正这个倾向。既不能把失败说成成功也不能把成功说得像失败。目标是准确不是防御性。7. 总结系统提示词是 Agent 的操作系统五个设计讲完了。回头看一下整个 Claude Code 系统提示词的架构。900 多行十几个模块静态段跟动态段分离每个段落解决一个具体问题。身份介绍告诉模型它是谁安全指令划出不可逾越的底线代码风格规则用可执行的条目替代模糊期望行动风险框架赋予模型推断能力防说谎指令对抗模型的讨好倾向。这些内容不是一次写成的。源码注释里到处可以看到针对某个模型版本新增的、“某次评估发现的问题”、某个 PR 引入的修复这样的说明。每一条规则背后都有一个真实的生产故障或者一个真实的行为偏差。系统提示词是一个持续演进的工程产物不是初始配置。如果你正在给自己的 Agent 写系统提示词可以从三个原则开始。模块化。不要写一大段混合文本把不同职责的内容拆成独立段落。身份是一段规则是一段工具指南是一段环境信息是一段。这样每个模块可以独立维护也可以根据场景动态组合。具体化。每一条规则都要具体到模型能直接执行。写好代码不是规则不要给你没改的代码加注释才是。缓存分离。通用内容放前面会话特有信息放后面。光是这一个调整就能让你的 API 成本降下来。一句话总结系统提示词不是一段介绍文字而是你的 Agent 的操作系统。它定义了 Agent 的身份、能力、边界、行为规范和风险判断框架。写得越精确Agent 的行为就越可控。我个人的判断是这样的大多数 Agent 开发者在系统提示词上欠的债迟早会以行为不可控的形式还回来。Claude Code 的这套架构不是最终答案但至少给出了一个思考框架值得认真借鉴。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
阿里P9问:“你研究过claude源码,那你说下它的系统提示词怎么写的“,我说“静态和动态拼一起“,他说:“只对一部分,但实际更复杂......“
发布时间:2026/6/7 1:55:45
有位读者私信我说他去面阿里大模型应用架构方向的岗位被P9问了一道题卡住了。题目是这样的你研究过 Claude Code 的源码那你说下它的系统提示词是怎么写的“他回答说就是静态内容和动态内容拼在一起静态的放前面动态的放后面。P9听完笑了笑说你说对了一部分但实际上没这么简单建议回去仔细看看”。他面完之后很困惑问我这个回答到底哪里有问题。我帮他复盘了一下发现问题不在于他答错了而在于他只答出了一个维度。Claude Code 的系统提示词确实有静态和动态的分离但这只是其中一个设计背后还有代码风格指令的写法、行动风险框架的构建、安全指令的维护机制、防说谎约束——这些他当时都没提到。这个问题其实挺典型的。大多数人对系统提示词的认知停留在拼接这个层面但真正做工程的人关注的是怎么拼、为什么这么拼、每个模块解决什么问题。今天就把这五个设计都讲清楚。1. 系统提示词从文本到工程系统说到 Agent 开发嘛有一件事几乎每个人都干过但真正认真做的人其实不多。那就是写系统提示词。大多数人对这个东西的理解呢还停留在开头先介绍一下角色然后下面列几条规则这个层面。但你要是去翻 Claude Code 的源码就会发现这个认知跟现实之间差距还挺大的。它的系统提示词有 900 多行由十几个功能独立的模块拼接而成每个模块解决的是不同的问题。有的模块对所有用户完全一样有的模块是随着每次会话动态生成的模块之间还设了明确的分界标记来控制服务端的缓存行为。所以这不是一段文字这是一套工程系统。今天是 Claude Code 源码系列的第八期我挑了五个最有启发性的设计来讲。这也是那位读者面试时被追问的真正考察点——面试官想听的不是静态加动态而是每个设计背后的工程决策。2. 设计一静态段跟动态段的分离Claude Code 的系统提示词呢被一个边界标记切成了两半。前半段是静态内容包括身份介绍、安全指令、代码风格规则、工具使用指南、行动风险评估框架这些。不管哪个用户、哪个会话看到的都是同一份。后半段是动态内容比如当前会话启用了哪些工具、记忆系统里装了什么东西、工作目录和操作系统的信息、用户的语言偏好、外部插件的说明之类的。这些是跟着每个会话走的每个人都不一样。那为什么要费心做这个区分呢答案就是缓存。大模型 API 有一种提示词缓存机制。简单来说就是如果两次请求的提示词前缀完全一样服务端就可以跳过重复计算直接复用之前算好的结果。按照 Anthropic 官方文档的说法缓存命中的 token 费用大概只有正常输入价格的 10% 左右。也就是说同样的内容第二次之后只收一成的钱。有实际测试数据显示一次比较重的 Opus 编程会话有缓存跟没缓存的成本差距可以达到五倍以上。那问题来了。如果静态内容和动态内容混在一起写的话每个用户的提示词前缀都不一样缓存就等于废了。Claude Code 的做法是把通用规则放在最前面会话特有的信息放在最后面。这样你跟另一个素不相识的用户共用同一套 Claude Code你们的系统提示词前半段在服务端共享同一份缓存Anthropic 只需要算一次就行了。对于正在开发多用户 Agent 的人来说这个设计的启发其实很直接。把对所有用户说的话跟对当前用户说的话分开前者往前放后者往后放。光是这一个调整就能让 API 账单好看不少。3. 设计二代码风格指令写得特别具体写提示词的时候最常见的偷懒方式大概就是这样的“请写高质量的代码”、“遵循最佳实践”。这类表达说了等于没说因为高质量和最佳实践在不同语境下意味着完全不同的东西模型没法从中提取出可执行的信息。Claude Code 的代码风格指令走的是另一条路。它的每一条都是具体的、有明确边界的。比如说没改过的代码不要加注释、文档字符串或者类型标注只在逻辑不自明的地方加注释。不要为假想的未来需求做设计。不要给一次性操作封装工具函数三行相似的代码比一个过早的抽象要强。没被要求加的功能就不要加修一个 Bug 不需要顺便清理周围的东西一个简单功能不需要附带可配置选项。不要写面向不可能场景的防御性代码只在系统边界做校验信任内部代码和框架的保证。可以看到每一条都是在告诉模型不要做什么而不只是要做到什么程度。这背后有一个反直觉的认知值得记住。那就是模型不怕规则多怕的是规则模糊。请简洁不是规则工具调用之间的文字不超过二十五个词才是规则。写好代码不是规则不要给你没改的代码加注释才是规则。有意思的是这种负面约束的写法跟 Google 内部的 Eng Practices 指南思路挺像的。与其说好代码应该怎样不如直接说代码审查时我们不接受什么。具体的禁止项往往比模糊的正向期望更容易执行。4. 设计三行动风险评估框架Claude Code 的系统提示词里有一段完整的该不该先确认的判断框架。注意这不是一张危险操作清单而是一套判断逻辑。框架的核心是两个维度可逆性和影响范围。本地的、可逆的操作比如编辑文件、跑测试直接执行就行。不可逆的、波及共享系统的操作比如强制推送代码、删除分支、向外部服务发送消息、修改基础设施权限这些就必须先确认。具体例子包括删除文件和分支、删除数据库表、强制推送、修改已发布的提交、上传内容到第三方工具。除此之外呢它还教模型怎么处理意外发现。碰到不认识的文件、分支或者配置先调查再行动不要直接覆盖因为那可能是用户正在进行中的工作。碰到锁文件先查是哪个进程在持有不要直接删。这个框架跟传统的白名单/黑名单方案有一个关键差别。当模型遇到一个从未见过的新操作时白名单方案是没法处理的但这套框架可以让模型自己去推断。这个操作可逆吗影响的是本地还是共享系统从而得出是否需要确认的结论。换句话说这不是在训练模型背规则而是在给模型装判断能力。5. 设计四安全指令由专门团队来维护源码里有一段叫 “Cyber Risk Instruction” 的安全指令划定了模型在安全相关请求上的行为边界。授权的渗透测试和防御性安全可以协助但拒绝服务攻击、大规模目标攻击、供应链攻击、以及出于恶意目的的检测规避一律拒绝。这段指令本身不长但源码注释里有一处特别值得注意。里面写了这段指令的具体负责人名字并且明确要求任何修改必须经过安全团队审批评估。原因是对这段文本的改动会对模型处理安全请求的方式产生重大影响。这个设计最有意思的地方其实不在技术层面而在工程管理层面。系统提示词不是一个随手可以编辑的配置文件。某些段落的修改会直接改变 Agent 的行为边界后果可能远超一般的 Bug。在团队协作中哪些提示词段落需要审批流程这件事跟哪些代码文件需要 Code Review是同等重要的。但实际上呢几乎没有团队认真对待前者。更广泛来说这是一个关于 AI 系统治理层级的问题。不同的提示词模块应该对应不同的修改权限和审批机制而不是让任何人在任何时候都能随意改动全部内容。6. 设计五防止模型说谎这是我在整个源码里觉得最务实的一段设计。它直接告诉模型如实报告结果。原文的逻辑大概是这样的测试失败了就说失败附上输出。没执行验证步骤就说没执行不要暗示它通过了。不能在输出显示失败的情况下生成所有测试通过。不能压缩失败信息来制造绿色结果。不能把未完成的工作说成已完成。但它的聪明之处在于紧接着还补了另一面。当检查确实通过了、任务确实完成了就直接说。不要加不必要的免责声明不要把已完成的工作降级成部分完成不要重新验证已经检查过的东西。这段注释里有一句话我觉得值得反复琢磨没有这段提示词的时候模型大约每三次就有一次会在报告执行结果时说谎或者夸大。这跟研究数据的方向是吻合的。2025 年一项多模型研究发现在对抗性场景下简单的提示词干预可以将 GPT-4o 的虚假输出率从 53% 压到 23%。也就是说提示词对说谎倾向的影响是真实的、可测量的。这背后的机制其实不神秘。模型的训练目标天然倾向于生成用户期望听到的答案坏消息的吸引力远不如好消息。所以在没有明确约束的情况下它会默默偏向乐观报告。你需要用双向约束来矫正这个倾向。既不能把失败说成成功也不能把成功说得像失败。目标是准确不是防御性。7. 总结系统提示词是 Agent 的操作系统五个设计讲完了。回头看一下整个 Claude Code 系统提示词的架构。900 多行十几个模块静态段跟动态段分离每个段落解决一个具体问题。身份介绍告诉模型它是谁安全指令划出不可逾越的底线代码风格规则用可执行的条目替代模糊期望行动风险框架赋予模型推断能力防说谎指令对抗模型的讨好倾向。这些内容不是一次写成的。源码注释里到处可以看到针对某个模型版本新增的、“某次评估发现的问题”、某个 PR 引入的修复这样的说明。每一条规则背后都有一个真实的生产故障或者一个真实的行为偏差。系统提示词是一个持续演进的工程产物不是初始配置。如果你正在给自己的 Agent 写系统提示词可以从三个原则开始。模块化。不要写一大段混合文本把不同职责的内容拆成独立段落。身份是一段规则是一段工具指南是一段环境信息是一段。这样每个模块可以独立维护也可以根据场景动态组合。具体化。每一条规则都要具体到模型能直接执行。写好代码不是规则不要给你没改的代码加注释才是。缓存分离。通用内容放前面会话特有信息放后面。光是这一个调整就能让你的 API 成本降下来。一句话总结系统提示词不是一段介绍文字而是你的 Agent 的操作系统。它定义了 Agent 的身份、能力、边界、行为规范和风险判断框架。写得越精确Agent 的行为就越可控。我个人的判断是这样的大多数 Agent 开发者在系统提示词上欠的债迟早会以行为不可控的形式还回来。Claude Code 的这套架构不是最终答案但至少给出了一个思考框架值得认真借鉴。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】