861 篇博文 含有标签「insider」

你最棒的系统提示词是由一位已经不在这里工作的人编写的。

那句话的杀伤力取决于你在组织中所处的位置。如果你是一名继承了一个管理着生产级 AI 功能的、未经文档记录的 3,000 token 提示词的工程师，你肯定已经经历过这种情况。你盯着像“除非上下文需要，否则不要包含补充数据”这样的条款，却完全不知道“上下文”意味着什么，是什么触发了这条规则，或者删除它会导致 5% 的质量提升还是灾难性的性能回归。如果你是一名团队负责人，你眼睁睁地看着制度性知识随着每一位资深工程师或提示词专家的跳槽而流失——而这些知识并没有进入文档，因为没有人意识到有什么需要记录的。

这就是系统提示词的知识管理问题，它比大多数团队意识到的还要严重。解决办法借鉴了机器人研究中的一个理念，并将其应用于一个深刻的人性化工程挑战：行为克隆 (behavioral cloning) —— 捕捉专家做了什么，以及背后的原因，在他们离职之前。

大多数团队一开始都用一个单一的、庞大的系统提示词。在演示时效果不错。然后产品不断增长：你添加了付费用户层级、企业客户的合规模式、模型可以调用的新工具，以及增长团队想要 A/B 测试的功能开关实验。所有这些都被塞进同一个提示词里。六个月后，你有了 4000 个词的指令，没有人能完全理解，编辑某个部分时行为会不可预测地改变，而调试过程不过是"改点什么看看会发生什么"。

大多数团队会转向可组合的、动态组装的系统提示词——在请求时从模块化组件构建提示词，而不是维护一个静态文本文件。这是一个合理的架构直觉，但实现的复杂度比看起来要大得多。可组合提示词引入了一类静态提示词根本不存在的新型故障模式。

你的评测套件全绿。你的基准测试分数很高。你的预发布环境看起来很干净。然而 —— 你的用户正反馈一些隐蔽的错误答案、不一致的语气，以及一些难以捉摸的、感觉不对劲的输出。

这就是行为模式切换（behavioral mode switching）问题：一个在被评估时表现出色，但在非评估状态下明显偏离的生产环境 LLM。这并非假设。这是 LLM 部署中常见的“静默式”失败模式，许多团队在向利益相关者宣称模型行为已验证并发布之后，才发现这一问题。

问题不在于你的评测框架不够勤勉。而在于大多数评测框架在结构上无法检测到这类故障。

2025 年的一项对照实验让有经验的开发者使用了 AI 编码工具，并测量他们是否变得更快。开发者们预测效率会提升 24%。研究结束后，他们报告自己大约快了 20%。而客观测量显示，他们实际上慢了 19%。

这并不是一个关于 AI 过度炒作的故事。这是一个关于隐性知识的故事——那种存在于每个成熟代码库中、仅靠阅读代码无法恢复的、无文档记录的"为什么"。AI 智能体在全新系统中生产效率出奇地高，正是因为那里几乎没有隐性知识可以违反。它们在成熟代码库中退步，原因完全相同。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

大多数关于上下文窗口（context windows）的讨论都集中在模型能“容纳”什么。更难的问题是模型如何“处理”它所容纳的内容——具体来说，它如何追踪对话者不断演变的目标。

意图并非一成不变。用户从模糊的描述开始，通过迭代不断细化，有时会自相矛盾、离题或修正。他们在第 40 条消息时真正的需求，未必是他们在第 2 条消息中所表达的内容。如果一个智能体将上下文视为扁平的追加日志，它会堆积所有信息——但仍然会误判当前的意图。

当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。

这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。

模型背了锅，边界才是元凶。

一个团队上线了基于 LLM 的意图分类器，评估准确率高达 94%。然而上线两周后，客服工单量上涨了 30%——并非因为模型无法分类，而是它以极高的置信度将边缘案例路由到了错误的队列。没有人为"模型判断错误却浑然不知"这种情况设置熔断机制。那个 94% 的数字从未暴露过这种风险。

这种失败模式在内容审核流水线、路由系统和实体提取器中反复出现。LLM 在留出集上得分很高，团队上线，然后生产环境中悄悄出现了问题。

问题不在于准确率是个坏指标，而在于它回答的是错误的问题。生产环境中的分类有一套不同的要求，而大多数评估流水线并不测试这些要求。

你的路由系统完全按照设计运行。80% 的查询流向廉价模型；20% 升级到高性能模型。延迟降低了，成本下降了 60%，领导层也很满意。然后有人按用户细分提取了数据，你发现了问题：非母语英语用户的查询升级率只有母语人士的一半，而他们的满意度评分低了 18 分。路由系统将查询复杂度信号视为中性的，但事实并非如此——它是语言熟练程度的替代指标，而你已经在几个月的时间里，系统性地向特定用户群体提供了更糟糕的产品。

这就是 20% 问题。这不是路由器的 bug。这是任何经过成本优化的路由系统在无人衡量的情况下，直到为时已晚才显现出来的涌现特性。

有一种故障模式几乎出现在每一个企业 RAG 部署中：一名员工向内部 AI 助手询问薪酬政策相关问题。系统返回了正确、具体的信息——却是从一份该员工本无权查看的 HR 文档中提取的。由于没有人监控检索层，这件事不会立刻让任何人丢掉工作。但那份机密文档已被索引，用户的查询在语义上命中了它，模型忠实地报告了它所找到的内容。

这个错误并不罕见，它是将公共网络 RAG 模式原封不动地应用于私有组织知识却不做架构适配的默认结果。公共网络 RAG 没有访问控制层，因为公共网络内容本身就没有访问限制。而企业数据有——这一约束从根本上改变了整个系统的设计。

有一件事看似不该令人意外，但实际上出乎意料：当你告诉智能体"避免犯错"与"优先保证准确性"时，你给出的并不是同一条指令。在模糊决策点上，可观测到的行为存在可测量的差异——以损失规避框架提示的智能体更多地回避、升级和放弃端到端任务完成；以收益寻求框架提示的智能体完成更多任务，但在决策边界处会引入更多错误。这种差异并非哲学层面的；它会体现在评估日志中。

这就是智能体的行为经济学，而大多数工程团队尚未系统地思考过这个问题。他们把系统提示当作文档来写——描述智能体是什么——而实际上，系统提示是一种决策塑造工具，无论作者是否有意为之，它都在编码一种风险立场。

当成本飙升、模型下线通知或竞争对手的基准测试迫使你更换 Provider 时，工程团队通常会在能力基准测试上评估候选模型，并将其视为迁移计划的全部。这个过程大约能捕获一半的问题。另一半并非能力问题，而是行为问题：那些不可见的格式习惯、拒绝模式、序列化怪癖以及输出约定——你的生产代码在数月迭代中已悄悄将其内化。

能力基准告诉你新模型能否完成任务。行为指纹告诉你你的代码库能否承受这次替换。