907 篇博文 含有标签「insider」

令人惊讶的是，许多 AI 团队一旦获得 o3 级别或 Claude 扩展思考模型的访问权限，就会默认对所有查询启用扩展思考。这背后的逻辑看似显而易见：更智能的推理等于更好的输出，何不始终开启？问题在于，这种逻辑没有考虑到测试时计算扩展在实践中如何运作的基本事实。扩展思考能显著提升特定类型任务的性能，在另一些任务上则会降低质量，并可能将全局推理成本推高 5-30 倍。那些从这些模型中获取最大价值的团队，将推理预算作为一个明确的决策来对待——其重要性不亚于模型选择或提示词工程。

本文阐述了任务分类体系、成本结构，以及将战略性使用思考预算的团队与仅仅为质量幻觉溢价买单的团队区分开来的路由决策框架。

一个智能体成功创建了 GitHub Issue、开启了 Jira 工单，并更新了共享表格。然后在发送 Slack 通知之前超时了。框架将此次运行记录为"已交付"。用户从未收到通知。副作用存在于三个系统中，而对人类真正重要的结果却没有送达。

这是生产智能体系统中最常见的超时失败模式，但几乎从来不是团队预先准备好的那种。大多数智能体实现把超时当作普通异常处理：捕获、记录、返回错误。即使智能体完成了 90% 的工作，用户也什么都得不到。问题不在于是否设置超时——每个生产系统都需要超时。问题在于当时钟走完时，智能体该如何应对。

一个团队发布了一款面向用户的 AI 助手。他们将其定价为每席位每月 49 美元，根据一份假设“每次查询平均 500 个 token”的电子表格，目标毛利率为 70%。三个月后，财务部门指出，他们的重度用户在每个会话中消耗了 15,000 个 token。定价模型之所以崩溃，并不是因为功能失败，而是因为产品团队为他们尚不了解的东西定了价。

这并非预测失败。这是一个结构性问题：大模型驱动产品的成本基准与传统 SaaS 定价所设计的处理方式根本不同。每一次 API 调用都有不可预测且实质性的 token 成本。输入因用户、任务和时间段而异。输出以各种方式复合增长，而这些影响直到几周后才会出现在你的云账单上。一旦你引入了智能体模式 (Agentic patterns) —— 工具调用、多轮推理、子智能体编排 —— 单次用户交互的成本可能是 0.02 美元，也可能是 20 美元，这完全取决于模型的决定。

大多数构建 AI 智能体的团队，都会在第五个迭代周期发现同一个问题：智能体再也无法可靠地选对工具了。十个工具时，基本还能用。二十个时，准确率开始下滑。五十个时，你会亲眼看着智能体在应该调用 update_record 的时候调用了 search_documents，而日志毫无解释。常见的反应是调整工具描述——加更多上下文、写得更明确、重写示例。这偶尔有效，但它绕开了根本原因：平面嵌入检索在大型工具库中架构上就是错的，更好的描述无法修复一个架构问题。

工具选择本质上是检索，而检索有已知的扩展上限。理解这些上限——以及绕过它们的结构化元数据模式——是让智能体系统在生产中稳定运行与需要持续人工维护之间的分水岭。

大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的HNSW索引进行分片时，实际情况如何。答案是：供应商在营销材料中刻意回避的事实是，HNSW图在分区方式上存在特殊阻力，会导致无声的召回率下降，而恢复这一质量所需的运营模式会带来真实的复杂性。

本文将深入探讨HNSW分片失效的技术原因、实际中召回率损失的表现，以及团队在超出单节点容量后用于维持检索精度的运营模式。

询问任何工程副总裁 AI 编码工具是否能提高生产力，他们都会给出肯定的回答。但如果你询问一名在一套拥有十年历史的代码库中工作的资深工程师（Staff Engineer），这套代码库里有六个没有文档记录的数据模型，部署流程全靠 Shell 脚本维系，你得到的答案将会截然不同。

AI 编码工具带来的生产力提升呈现出一种大多数组织尚未完全消化的分化态势。初级工程师在每周完成的任务量上看到了 27%–39% 的提升。而在一项针对真实世界问题的受控研究中，资深开发者在使用 AI 辅助时，完成任务所需的时间反而比不使用时增加了 19%。这两个结果都与这些工具的工作原理相一致 —— 并且它们正导向一个目前正在工程团队中悄然上演的管理陷阱。

大多数工程团队都能准确地告诉你哪个环境变量在控制他们的数据库连接池。但几乎没有人能告诉你现在是哪个版本的 system prompt 在处理 90% 的流量 —— 或者自上一次收到模型行为投诉以来发生了哪些变化。

这就是 AI 配置足迹（AI configuration footprint）问题。构建基于 LLM 功能的团队会积累一个隐形的配置层 —— 模型选择、采样参数（sampling parameters）、system prompts、工具 schemas、重试预算 —— 这些配置决定了他们的产品在生产环境中的行为。这一层的大部分内容都没有记录在案（system of record）。它们通过直接修改代码、交付电子表格或 Slack 消息进行更新。当出现问题时，没有人能说清楚发生了什么变化。

这不是流程问题，而是架构问题。解决方案需要以成熟团队对待环境配置、功能旗标（feature flags）和基础设施即代码（infrastructure-as-code）同样的严谨态度来处理 AI 配置。

你的文档六个月前看起来没问题，今天单独看依然没问题。但这周一位用户提交了一个 bug：开发者文档的两个页面对同一个配置项给出了相反的建议。一个页面说生产环境应将 max_retries 设为 3；另一个页面说保持默认值 0 即可。两者都是 AI 生成的，两者听起来都很权威。一个反映的是你们系统在一月份的实际行为，另一个反映的是 AI 工具在六月用略有不同的提示词所做的解读。没有人发现，因为没有人在整体上审视这个语料库。

这就是 AI 内容漂移。它不是幻觉问题——AI 在生成时是准确的。漂移发生在两次生成之间的间隙里。

一位小团队工程师花了三个月将测试生成委托给 AI。代码覆盖率从 47% 跃升至 72%，再到 98%。每次 PR 都返回绿色。然后生产环境崩了。用户注册中的竞态条件因数据库复制延迟导致重复邮箱。优惠码接口在代码无效时返回 null 而非零，导致支付计算对 4700 名客户静默出错。最终损失：4.7 万美元退款和 66 小时工程时间。测试并没有遗漏几个边界情况——它们覆盖了所写的代码，而非所部署的系统。

这就是覆盖率幻觉。随着 AI 辅助开发成为默认选项，落入这个陷阱正变得越来越容易。

一个三人团队花了整整一个季度，为一个日活跃用户仅 200 人的应用实现了事件溯源架构。这套架构技术上无懈可击，运维上却是一场噩梦。设计方案来自 AI 的推荐，团队之所以接受，是因为推理听起来流畅、权衡分析看似严谨，而最终构建出来的系统也完全符合高级工程师架构图上的样子。

这个故事如今已成为一种警示性范式，而非孤例。AI 在特定的、可识别的场景下能够提供真正有价值的架构输入——而在从外部看起来几乎相同的情况下，它也会给出自信满满却大错特错的建议。这两者之间的差距，如果你把 AI 当成答案机器，就几乎无从察觉；但如果你把它当成思维伙伴，则完全可以驾驭。

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

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

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

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

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