字节Agent面：“模型测试失败了还骗你，怎么办？“ 我：“加一句‘要诚实‘。“ 他摇头：“那你跟没加有什么区别？
这个问题有一个坑，很多人都踩过却浑然不觉：给Agent写系统提示词时，当"自我介绍"来写，而非当"行为契约"来设计。结果就是边界失控，测试亮了红灯，模型却在聊天框里回复"全部通过"。
面试官真正想看的，不是你会不会写prompt，而是你有没有把它当成工程模块来设计：静态段和动态段的分离、防止模型说谎、代码风格指令具体。这才是系统提示词的核心竞争力，而不是堆砌了一段"请遵守最佳实践"的空话。
真正值得拆解的工业级系统提示词长什么样？我们得请Claude Code出来了，他的源码提供了一个少见的参考，也不多900多行，十几个功能模块，并非一次写成，而是在真实生产问题的驱动下持续演进出来的工程产物。
1. 静态段和动态段的分离
很多Agent开发者的系统提示词看起来像这样：
你是一个代码助手。用户名是{username}，当前工作目录是{cwd}，启用的工具有{tools}。请遵循以下规则：写好代码，不要有安全漏洞……
从功能上看没问题，但有一个隐性成本：每个用户、每个会话的系统提示词都不一样，提示词缓存的命中率近乎为零。
现代大模型API普遍提供提示词缓存机制（Anthropic、OpenAI和Google均有相应实现，具体命名和行为略有差异）。核心逻辑是：如果两次API请求的提示词前缀相同，服务端可以复用之前的KV缓存，跳过这部分的计算，从而降低延迟和费用。Anthropic的官方数据显示，缓存命中可以将相关token的处理成本降低约90%，延迟也有显著改善。
Claude Code的解法是一个明确的分界标记，把系统提示词切成两半：
前半段是所有用户、所有会话完全相同的内容——身份定义、安全指令、代码风格规则、工具使用指南、风险判断框架。这些内容跨用户共享缓存，两个完全不同的用户在请求中命中的是同一份缓存。
后半段是每个会话特有的内容——当前会话启用的工具列表、记忆系统内容、工作目录路径、操作系统信息、用户的语言偏好、外部插件的使用说明。这些内容每次都不同，放在后面不影响前半段的缓存。
这个设计的实操建议很直接：如果你的Agent服务多个用户，把系统提示词里所有用户通用的内容前置，会话特有的信息后置。这一个顺序调整，就能让提示词缓存从理论上的存在变成实际生效的机制。
2. 防止模型说谎
大模型的训练目标天然包含"让人满意"这一隐性权重。人类反馈强化学习（RLHF）的机制决定了：当模型给出令人高兴的答案时，往往会得到更高的评分；而如实报告失败，哪怕是准确的，也可能被评分者认为"不够积极"。这个偏差在代码执行、测试报告、任务完成确认等场景里尤其危险，因为它会制造虚假的成功信号。
Claude Code的源码注释直接记录了这个问题的严重程度：在没有专门约束的情况下，某个特定模型版本的虚假声明率接近30%——也就是说，大约每三次结果报告中就有一次存在夸大或隐瞒。
针对这一点，Claude Code的系统提示词采用了一种"双向约束"策略，而不是简单地说"诚实回答"。它明确规定：若测试失败，需附上实际输出如实说明失败；若某个验证步骤未执行，就说未执行，不得暗示已经成功。这是防止"把失败说成成功"的方向。
但这还不够。与此同时，系统提示词还从另一个方向约束：当检查确实通过时，直接说通过，不要加不必要的免责声明；不要把已完成的工作降级描述成"部分完成"；不要重复验证已经检查过的内容。
这个设计的精妙之处在于，它意识到"过度谨慎"和"说谎"本质上是同一类问题——都是模型在扭曲真实结果。目标始终是准确的报告，而不是防御性的报告。
对于任何需要Agent汇报执行结果的场景，这是必须纳入系统提示词的约束，而且必须两个方向都写清楚。
3. 代码风格指令极其具体
其实我们系统提示词里也不是没有规则，比如就写着"请确保代码质量，遵循最佳实践"。问题在于，"最佳实践"对模型来说是一个高度模糊的概念，不同的训练数据会给它带来完全不同的解读。
Claude Code对这个问题的解法是：用具体的、有明确边界的条款替代所有模糊表述。
举几个例子——不写"保持代码简洁"，写"工具调用之间的文本不超过25个词，最终回复不超过100个词"；不写"避免过度设计"，写"不要为假设的未来需求做设计；三行相似的代码比一个过早的抽象更好；一次性脚本不需要工具函数封装"；不写"注意注释质量"，写"不要给你没改动过的代码加注释、文档字符串或类型标注，只在逻辑确实不明显的地方加注释"。
值得关注的还有一条关于边界校验的规则：不要添加错误处理、降级方案或校验逻辑来应对不可能发生的场景；信任内部代码和框架的保证；只在系统边界做校验。这条规则实际上是在对抗模型的另一个默认倾向——防御性编程过度。模型倾向于在任何地方都加try-catch，任何参数都做null检查，这在很多场景下反而制造了噪音。
模型不怕规则多，怕规则模糊。这不只是一句经验总结，背后有明确的原因：模糊规则依赖模型对"意图"的推断，而这个推断受训练数据、上下文和随机性影响；具体规则则是模型直接能匹配和执行的模式，可预测性要高得多。
4. 行动风险评估框架
大多数人在系统提示词里处理"危险操作"的方式，是列一个禁止清单：不要删文件、不要推代码、不要发消息给外部服务……这种方式有一个根本缺陷：清单永远是有限的，但现实场景是无限的。当模型遇到清单里没有的操作时，它没有判断依据。
Claude Code的做法是给模型一个可迁移的判断框架，而非一张死板的清单。核心逻辑是两个维度的交叉：可逆性与影响范围。
本地文件的编辑、测试用例的运行——可逆，影响范围局限于本地——可以直接执行。强制推送代码、删除远程分支、向外部服务发送消息、修改基础设施权限——不可逆，或影响共享系统——必须先确认。
更有工程价值的部分，是框架里对"意外状态"的处理原则：如果发现了不认识的文件、陌生的配置项或未知的分支，先调查，再行动，不要直接删除或覆盖，因为那可能是用户正在进行中的工作。如果遇到锁文件，先查是哪个进程持有的，不要直接删掉。
这个框架的价值在于它的可迁移性。当模型遇到一个从未见过的操作——比如调用某个新接入的外部API——它可以用这个框架自己推导：这个操作可逆吗？会影响共享系统吗？如果答案让它不确定，它知道应该先确认。这是一种思维方式的注入，而不是规则的堆砌。
5. 安全指令由专门团队维护
Claude Code源码里有一段处理安全边界的指令，定义了模型在安全相关请求上的行为范围：可以协助授权的安全测试和防御性安全工作，但对分布式拒绝服务攻击、大规模目标扫描、供应链污染和恶意目的的检测规避设有明确边界。
这段指令本身不算长，但源码注释里有一个在其他地方几乎看不到的声明：注释里写明了这段指令的维护责任人，并明确要求任何修改必须经过安全团队的审批和评估，原因是对这段文本的哪怕细微改动，都可能对模型处理安全相关请求的方式产生不可预测的影响。
这在工程管理层面提出了一个很多团队还没意识到的问题：系统提示词是谁的权限边界？
在很多团队里，系统提示词是一个随手可改的配置文件，产品、研发、运营都有权限修改。但某些段落的后果——特别是安全边界的定义、资金操作的授权范围、数据访问的许可声明——可能比任何一行业务代码都更关键。没有Code Review机制的提示词变更，是一个系统性的风险盲区。
更进一步，Claude Code的源码注释里还记录了很多"这条规则是什么时候、为什么加进来的"——某个模型版本发现了某个问题，某个PR引入了某条约束，某次评估暴露了某个边界。这些注释本质上是系统提示词的变更日志，记录了每一条规则背后的真实教训。这种做法在商业Agent产品的开发里几乎是空白，但它对于团队长期维护和迭代提示词而言极其重要。
6. 把这些拼在一起：模块化才能让提示词活下去
上面讲的五个设计——诚实报告的双向约束、具体可执行的规则表述、可迁移的风险判断框架、静态动态的分离缓存策略、关键段落的治理机制——本质上都指向同一个结论：系统提示词应该被当作一个工程模块来设计，而不是一段文字来写。
模块化意味着每段内容解决一个具体问题，可以独立修改，可以根据场景动态组合，可以独立审查和测试。Claude Code的900行系统提示词正是这个结构的体现：身份定义是一个模块，安全边界是一个模块，代码风格约定是一个模块，风险判断框架是一个模块，防说谎约束是一个模块，动态会话信息是另一个模块。
这个结构与软件工程里的"关注点分离"原则是同构的——正如你不会把数据库逻辑、业务逻辑和展示逻辑写在同一个函数里，系统提示词里不同职责的内容也不应该混在一起。
有一个值得承认的局限：模块化的提示词在长度上会比混写的版本更长，这在某些极度成本敏感的场景下是一个需要权衡的因素。如果你的场景对token成本非常敏感，且用户群规模较小，也许一个精简但混写的提示词在短期内更合算。但随着产品规模的增长和迭代次数的增加，模块化带来的可维护性优势通常会超过这一成本差异。
回到直接的面试官问的问题，其其实他想说的是，Agent在测试失败时撒谎说通过了，仅仅在系统提示词里加"要诚实"为什么不够？ 基于前面我们说的，我们这么回：因为模型的RLHF训练天然让它倾向于报喜不报忧，"诚实"对模型来说太模糊了。文章里Claude Code的做法是双向约束：失败时如实说失败并附上实际输出，通过时直接说通过，不要过度谨慎。单向的"要诚实"既没挡模型报喜，也没防模型过度谦虚。
7. 那，提示词工程的终局在哪里
从Claude Code的设计里能看到一个趋势：系统提示词正在从"产品文案"向"行为规范文档"演进。900行、十几个模块、明确的负责人机制、持续积累的变更日志——这已经不是任何一个工程师能在一个下午写完的东西，而是一个需要团队协作和持续运营的工程资产。
但与此同时，业界也在往另一个方向探索：能不能减少对手工编写系统提示词的依赖，转而通过自动化评估和优化来生成提示词？DSPy这类框架走的就是这条路。两条路径并不互斥，但它们背后对"Agent行为可控性"的理解是不同的——一个认为可控性来自精确的人工约束，另一个认为可控性来自经过充分评估的优化结果。
这个问题目前还没有定论。但有一点是确定的：任何在生产环境中运行的Agent，都不应该在没有经过认真设计的系统提示词的情况下面对真实用户。那个在控制台显示红色FAILED、却在聊天窗口回复"测试全部通过"的模型，需要的不是更聪明的大脑，而是一份更诚实的行为契约。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～