Author: aitrendtrackers@rengongzhineng.io

过去8个月，某技术团队深度参与了RAG（Retrieval-Augmented Generation，检索增强生成）项目的落地实践。其服务对象包括Usul AI（共计900万页）以及一家未具名的法律AI企业（共计400万页）。本文回顾了该团队在真实生产环境中构建RAG系统所踩过的坑、优化过程及关键经验，并对每项优化措施按ROI（投资回报率）进行排名。 初始阶段：Langchain + Llamaindex 项目初始阶段以常见教程为指导，采用了 Langchain 结合 Llamaindex 的组合。第一周内便构建出原型系统，并在小规模数据（100个文档）上测试结果令人满意。随后在接下来的几天里将整个流程扩展到生产级数据集上，整个过程在一周内完成，表面上进展迅速。 然而，问题随之而来：实际结果效果不佳，且只有终端用户能明确指出问题所在。接下来数月内，团队对系统各模块逐步重写和优化，直至达到理想性能。 真正“有效”的关键优化（按效果排序） ✅ 1. 查询生成（Query Generation） 用户的最后一句话往往不足以表达其全部信息需求。团队引入LLM对完整对话线程进行分析，生成多个语义查询与关键词查询并行处理，随后将结果交由重排序器处理。这种方式显著扩大了搜索覆盖面，避免了过度依赖初步检索评分的弊端。 ✅ 2. 结果重排序（Reranking） 仅需几行代码，却带来了最大性能提升。团队发现，仅靠初始排序的表现差距巨大，通过传入较多候选块（chunks）并由 reranker 精选，可极大提升最终结果质量。最佳设置为：输入50个chunks，输出15个。 ✅ 3. 切块策略（Chunking Strategy） 这是最耗费精力但至关重要的环节。团队为两个项目构建了定制化切块流程。关键点在于： ✅ 4. 向LLM传递元数据（Metadata to LLM） 初期仅传递chunk内容，后经实验发现，在输入中加入元数据（如标题、作者等）能显著提升答案质量与上下文完整性。 ✅ 5. 查询路由（Query Routing） 很多用户提问并不适合用RAG解决，例如“这篇文章是谁写的”“总结一下全文”等。团队开发了轻量级路由器用于识别此类问题，并调用API + LLM方式处理，避免不必要的全文检索与推理。 技术栈与工具选择 总结 在生产环境构建 RAG 系统，远不只是“搭一个 Langchain + LLM”那样简单。快速跑通原型容易，但真正做到效果可靠、性能可控，需要： 唯有不断打磨细节，才可能让RAG系统真正从实验室走向实用级落地。

在过去的一年中，构建一个 AI 智能体几乎意味着同一件事：设置一个 while 循环，获取用户指令，发送给大型语言模型（LLM），解析工具调用，执行工具，将结果返回，再重复。这就是所谓的“浅层代理”（Shallow Agent），或“代理 1.0”。 这种架构在处理诸如“东京今天的天气如何？我该穿什么？”这类事务性任务时表现得极其高效。但当任务复杂、持续时间长、需要数十步操作时，这类代理往往会失焦、丢失上下文、陷入无限循环，甚至开始幻觉，因为任务所需步骤远远超出了语言模型的单次上下文窗口所能承载的能力。 当前，智能体架构正经历转型，朝向“深层代理”（Deep Agents）或“代理 2.0”迈进。这一代系统不再仅仅在循环中反应，而是整合多种智能体行为模式，具备规划能力、持久状态管理能力，并能将复杂任务委派给专门的子代理执行，从而解决多步骤、长周期的复杂问题。 代理 1.0：浅层循环的局限 理解未来的发展方向，必须先了解当下的状况。如今大多数智能体都是“浅层”的，也就是说，它们完全依赖于语言模型的上下文窗口（对话历史）来维持状态。 典型流程如下： 该架构是无状态的，易失性的。整个“智能体大脑”都寄存在当前上下文之中。 当任务变得复杂，例如：“研究10家竞争对手，分析其定价模型，制作比较表格，并撰写战略分析总结”，浅层代理会失败，原因如下： 浅层代理擅长5–15步内完成的任务，但面对500步以上的任务时表现极差。 代理 2.0 的架构（深层代理） 深层代理将“规划”与“执行”解耦，使用上下文之外的持久存储来管理状态。该架构由四大支柱构成： 支柱一：显式规划 浅层代理通过思维链（Chain-of-Thought）隐式规划，即“我应该先做 X，再做 Y”。而深层代理则使用工具明确规划任务，通常以待办事项列表（如 Markdown 文件）形式存在。 在每一步操作之后，代理会回顾并更新此任务清单，标记任务状态为 待处理、进行中 或 已完成，并添加备注说明。如果某一步失败，代理不会盲目重试，而是更新计划，调整路径。这种方式帮助代理持续聚焦于高层目标。 支柱二：分层委派（子代理） 复杂任务需要专业化。浅层代理试图在一个提示中成为“多面手”，结果力不从心。深层代理采用“协调器 → 子代理”架构。 主代理（协调器）将任务拆分后交给具备独立上下文的子代理执行。比如，研究员、开发者、写手等角色型子代理会在自己的工具调用循环中完成任务（搜索、调试、重试），最后返回精炼后的结果交由协调器统一处理。 支柱三：持久内存 为避免上下文窗口溢出，深层代理将状态和中间结果存储在外部资源中，如文件系统或向量数据库。这些存储成为“真实信息源”。框架如 Claude Code 与 Manus 允许代理读写这些存储。 代理会写入中间结果（如代码草稿、文本内容、原始数据），后续子代理只需通过路径或查询取用必要内容。这种模式从“记住一切”转向“知道在哪能找到”。 支柱四：极致上下文工程 更智能的模型并不代表需要更少的提示，而是需要更高质量的上下文。若仍然使用“你是一个有帮助的AI”这类空泛提示，是无法唤起代理 2.0 行为的。 深层代理依赖详细且结构化的系统提示，长度可能达到数千个 token，内容包括： 深层代理执行流程可视化 以“研究量子计算，并将总结写入文件”为例，可视化流程如下： 该流程体现了规划、委派、内存调用和结构化执行的结合。 结语：从代理…

苹果自带的计算器泄漏了32GB内存。 不是占用。不是分配。是泄漏。一个最基本的计算器应用，竟在无声无息中消耗掉了比十年前一整台电脑还多的内存资源。 放在二十年前，这种情况会引发紧急补丁、详细的事故回溯和高层介入。如今，不过是排队等候处理的又一个Bug报告。 人们已经把软件灾难当作常态接受。一个计算器泄漏32GB内存的事件几乎没能掀起任何波澜。重点不在于AI。软件质量危机早在ChatGPT诞生前数年就已酝酿。AI只是把原本存在的无能放大成了灾难。 被忽视的数据：质量的断崖式崩塌 过去三年中，相关研究持续追踪软件质量指标，发现问题并非逐步恶化，而是呈指数级下滑。 内存使用已失控： 这并非功能需求，而是从未修复的内存泄漏。 系统级崩溃成为日常： 模式清晰可见：先发布一个有问题的版本，之后再考虑修复——如果有修的话。 一场价值百亿美元的灾难预演 2024年7月19日CrowdStrike的宕机事故是“失能常态化”的完美案例。 一份配置文件中，仅因数组长度检查缺失，便导致全球850万台Windows电脑崩溃。紧急服务瘫痪、航班停飞、医院手术取消。 直接经济损失至少100亿美元。 其根本原因？程序预期接收21个字段，但只收到20个。 仅仅是一个字段。 这不是高深错误，而是《计算机科学入门》课程中最基础的错误处理问题，却成功穿过了整个部署流程，直至引发全球性事故。 当AI成为“无能的倍增器” AI编程助手出现前，软件质量已经呈现断崖式下滑。而AI的介入，让本已不堪的局势雪上加霜。 2025年7月，Replit发生的事件集中展现了这种风险： AI后续承认：“此次事故是我方严重失误，违背了明确指令，摧毁了数月的成果，并在代码冻结期间破坏系统。”（来源：《The Register》） Replit CEO称之为“不可接受”。但公司年收入已超1亿美元。 更令人不安的是，这类事件并非孤例。据研究数据显示： 结果是一个完美风暴的形成：低质代码的生成工具，被缺乏判断能力的开发者使用，由对机器过度信任的管理层审查。 软件崩溃的“物理学”基础 工程管理层不愿面对的现实是：软件并非虚无，它受物理限制影响——而这些限制正同时显现。 抽象层级的指数型“叠加税” 现代软件依赖多层抽象，每一层都打着“开发更便捷”的旗号，但也带来资源消耗： 现实中的堆栈链条：React → Electron → Chromium → Docker → Kubernetes → 虚拟机 → 托管数据库 → API网关。 每一层可能只增加20–30%的开销，几层堆叠后，性能损失可达2到6倍。 这就是为何一个简单计算器能泄漏32GB内存。并非有意为之，而是因层层叠加的代价无人察觉，直到用户发现为止。 能源危机已经降临 软件设计中假设电力是无限的，实际并非如此。 低效软件正在带来物理层面的后果： 真相是：软件的能源需求已远超现实供给。到2027年，预计40%的数据中心将面临供电瓶颈。届时，再多的风险投资也无济于事。 因为——电力无法下载。 3640亿美元的“伪解法” 面对根本性质量危机，大型科技企业选择的不是提升软件质量，而是疯狂砸钱搞基础设施。 仅2025年：…

2025年10月15日，OpenAI推出其视频生成器Sora 2.0及其配套社交应用，引发好莱坞业内的巨大震动。据《好莱坞报道者》报道，在Sora新版本发布前夕，各大经纪公司内部充满疑问与不安。一家重量级经纪公司通过小道消息得知OpenAI即将发布新产品，却惊讶于高层并未接到奥特曼领导的团队任何通知。这家机构主动联络了OpenAI。 双方的首次会谈气氛紧张。一位参与谈判的经纪公司高管表示，OpenAI在沟通过程中“故意误导”。对方一再强调，这将是一个“自愿参与”机制，承诺会保护该机构旗下艺人的肖像权及知识产权。然而，随着不同公司之间的信息交流逐渐展开，人们发现OpenAI对各方的说法并不一致。 有的高管被告知艺人肖像和知识产权都需获得明确授权才能使用；而另一些人则得到了相反的说法，甚至未被明确告知两者的区别。这种前后矛盾的沟通方式令好莱坞各方困惑不已。 WME的合伙人透露，该公司旗下包括马修·麦康纳、迈克尔·B·乔丹与瑞安·雷诺兹等明星都被告知，若不希望自己的脸孔或声音出现在Sora上，必须主动向OpenAI提出申请。该合伙人直言，这种要求不切实际：“想象一下，一个经纪人给客户打电话，劝他加入Sora。那客户很可能会直接解雇这位经纪人。” 9月29日，Sora 2.0发布前一天，WME方面终于收到通知，确认未经授权不得使用艺人肖像。尽管这一点算是初步胜利，但也只是“半步”成果。新发布的社交平台允许用户创作包含好莱坞各大公司所拥有热门角色的内容。前提是，各大制片厂必须逐一列出不希望被使用的角色与作品。这一变化，被视为硅谷对娱乐产业的进一步侵蚀。 10月3日，奥特曼宣布将转向一种“类自愿参与”的机制，但此时，OpenAI的计划已基本达成。Sora生成的视频已经开始出现诸如《开心汉堡店》、《海绵宝宝》、《怪诞小镇》、《精灵宝可梦》、《侠盗猎车手》和《荒野大镖客》等广受欢迎的电影、电视剧及游戏画面。Sora迅速登顶App Store免费应用排行榜。 “这一系列操作非常精心算计，”该经纪公司高管表示，“他们在未设任何保护机制的情况下发布产品，绝非无意。” 目前，谈判已升级至法律层面，诉讼正在被严肃考虑中。与此同时，好莱坞各方正奋力应对突如其来的局势。素来保持低调的电影协会（MPA）首次发声，公开谴责OpenAI。CAA和UTA也采取行动，WME更是向所有经纪人发送备忘录，明确表示其客户不参与Sora的任何形式使用。 据知情人士透露，目前各大制片厂与经纪公司内部对于Sora的“退出机制”感到困惑与愤怒。该机制并非正式系统，而是一个链接，供用户逐个举报侵权内容，效率低下且缺乏组织。甚至在Sora上线之前，OpenAI内部都没有专责人员负责此类内容管理，直到事件发酵后才增设相关岗位。一些高管对继续与OpenAI接触持保留态度。 他们担心，一旦启动谈判流程，等于默认由内容方承担起通知OpenAI不得使用其知识产权的责任。而迪士尼在9月底发出的一封措辞强硬的信函中明确指出，自己“没有义务选择‘退出’以保留或主张其著作权权益”。 事实上，迪士尼、环球影业和华纳兄弟探索公司今年早些时候已联合起诉Midjourney，指控其平台允许用户创建带有版权角色的图像。诉讼预示着好莱坞未来或将面临更多针对AI公司的法律战。 “这简直是颠覆版权法的做法，”法律咨询机构Moses Singer合伙人、前Showtime Networks执行副总裁罗伯·罗森伯格指出，“他们设定了一个虚假前提：只要你不主动反对，他们就能用。而你若没反对，那就是你的错。” 多年来，OpenAI在Shetty与McKean等科技老将的推动下，对好莱坞版权问题一直采取“先做再说”的策略。他们更倾向于在出现争议后寻求原谅，而不是事先征得许可。这种策略被认为是变现Sora的最便捷路径。 尽管ChatGPT的应用极为广泛，每月带来约10亿美元营收，拥有每周7亿活跃用户，但Sora的盈利模式尚不明朗。AI视频生成器若无法使用熟悉角色与元素，其吸引力将大大降低。Midjourney在遭遇诉讼后曾短暂加装版权防护机制，但在用户活跃度下降后又悄然移除。奥特曼对外高调宣称其目标，最终成败仍取决于好莱坞是否愿意开放授权。 奥特曼在博客中写道：“我们听到很多版权持有人对这种‘互动式同人创作’充满期待，并相信这将带来巨大价值。”Shetty也补充称：“我们看到创作者与粉丝建立更紧密联系的新机遇。” 但当前局势更像是一场消耗战，好莱坞与资本雄厚的AI企业正展开角力，处境日益被动，正如当年面对网络盗版时的迟缓反应。目前好莱坞唯一尚存的筹码，或许就是未来可能的合作协议。只不过，OpenAI似乎更像是对手，而非潜在伙伴。 “你们怎么能一边烧毁合作的桥梁，一边还希望我们达成合作？”WME合伙人曾对OpenAI代表如此质问。 业内还有一种声音，对制片公司未能积极对抗硅谷的步步紧逼表达不满。据知情人士透露，AI企业早已多年在网络上爬取影视作品用于训练模型。而创作者们往往并不拥有作品的知识产权，因多数属于“定制创作”类型合同。 有评论指出，如果好莱坞早早通过司法途径介入，是否能迫使AI企业清除其训练库中涉嫌侵权的内容？正如Amazon旗下Anthropic与作者达成和解所展现的先例。目前，各大制片厂更专注于防御性维权，而非主动探索与AI技术的深度合作。 未来，迪士尼可能会选择绕开OpenAI，自行开发如Sora般的平台，让用户按月订阅、使用旗下IP生成互动内容。其他公司则可能已着手谋划合作协议。在这种情况下，经纪公司与制片厂的利益可能并不一致。 WME合伙人指出：“这正是最大的问题。如果选择起诉，就可能失去与这些科技公司合作的机会。” 另一家经纪公司的高管则表达了更为直接的态度：“客户们期望被保护。如今暴露出的问题，正说明这个系统存在严重缺陷。”

超过30位招聘经理与技术招聘人员近期分享了他们对软件工程招聘市场的观察。主要趋势包括：职位申请量激增导致筛选更严格，对产品工程师的需求增长，以及对远程职位和高级工程师招聘的挑战等。 招聘市场：表面热闹，实则复杂 虽然2025年科技招聘总体呈现出缓慢回升趋势，但市场整体状况仍显混乱。一方面，许多招聘经理表示职位难以填补；另一方面，工程师却普遍感受到申请难获回应。与此同时，《大西洋月刊》之类媒体流传出“求职地狱”等耸动标题，反映出公众对就业市场的焦虑。然而，据市场调研显示，AI虽对求职生态产生影响，但并非市场异常的根本原因。 现象一：职位申请量暴增 目前几乎所有初创企业和大型科技公司都遭遇了前所未有的申请数量。例如： 许多招聘经理表示，不再需要第三方招聘推送候选人，因为招聘渠道早已被申请淹没。Honeycomb 的 Field CTO Liz Fong-Jones 直言：“问题已不是吸引足够候选人，而是如何从噪音中筛选出合适人才。” LinkedIn应用质量堪忧不少招聘经理批评 LinkedIn 的职位申请质量低下。部分企业甚至关闭了 LinkedIn 的职位发布功能，转向通过招聘工具主动搜索候选人。有些公司尝试使用如 Wellfound 和 JustJoin.it 等更小众的招聘平台，但质量也参差不齐。 甚至并非招聘岗位的员工也遭遇申请洪流。例如，一家初创企业的早期工程师表示，LinkedIn 每天收到5至10个学生添加请求，有的附带求职意图说明，有的甚至毫无介绍直接添加。 部分新毕业生可能是受到网上课程和职业影响者建议，尝试直接联系企业员工，因为传统渠道成效有限。 现象二：通过“主动申请”的成功率低 尽管职位申请数量庞大，但真正通过直接投递渠道成功录用的比例很低。大部分招聘仍依赖以下方式： 一位在美国招聘超过30名工程师的金融科技公司招聘人员指出，直接投递成功率仅占10%。其中，常见淘汰原因包括不符合岗位要求、频繁跳槽、或面试表现不佳。 另一位在欧洲招聘工程师的招聘人员提到，150多位通过社交平台主动联系的人选中，仅一人进入最终面试阶段。相比之下，主动联系AI初创公司员工更具成效。 纽约一家大型科技公司的工程经理指出，许多应聘者完全不具备岗位要求，如前端岗位却有大量后端工程师申请，说明不少人可能只是“广撒网”式申请，或依赖自动系统投递简历。 综合各方反馈显示： 现象三：顶尖工程师难觅 尽管求职者众多，但真正“合格”或“出色”的候选人却极为稀缺。招聘经理主要通过以下方式寻找优质工程师： 不少经理表示，即便筛选大量简历，真正能通过初筛的寥寥无几。例如： “看似有经验的人，在电话初筛中常常暴露出能力不足。”——美国某大型科技公司工程经理 在印度，一位工程经理则表示，尽管工作量繁重，推荐渠道始终是最有效的方式。 高级岗位竞争激烈即使成功发出offer，也常被候选人拒绝或跳槽至更优职位。伦敦某金融科技公司开发主管提到，高级工程师常常手握多个机会，而毕业生或初级岗位则较容易填补。 工程师普遍倾向“观望”大量资深工程师对求职保持谨慎态度。纽约某上市公司工程经理指出，只有通过私人网络联系，才可能吸引出色候选人应聘。 过去三年间，科技行业频繁裁员，除苹果与NVIDIA等个别公司外，大部分企业皆有大规模裁员纪录。因此，不少工程师选择“稳中求胜”，不愿冒险跳槽，除非由信赖的人亲自推荐，并承诺协助面试流程。 现象四：用人单位越来越“挑剔” 由于申请人众多，招聘方往往有充足理由等待“完美候选人”。亚特兰大某工程经理坦言： “公司普遍在‘保守行事’，只考虑那些完全符合预设画像的候选人。” 也有招聘方强调，虽然职位相较疫情前更容易填补，但优质工程师仍稀缺，招聘周期依旧漫长。 小结 目前软件工程职位市场呈现出“冰火两重天”的局面：

2025年10月6日，SpaceX 宣布与 EchoStar 达成一项高达170亿美元的交易，获得 50 MHz 关键频谱授权，并计划发射 最多1.5万颗新一代卫星，全面推进其 Starlink 直连手机服务（D2D, Direct to Device）。此举不仅直接挑战英伟达在AI计算领域的竞争对手，也使得 AT&T、Verizon 和苹果等巨头不得不重新审视他们与 Starlink 竞争对手的现有合作关系。 关键交易内容： 对手阵营动摇：AT&T、Verizon 和苹果可能动摇对现有伙伴的忠诚 📱 AT&T 与 Verizon 的困境： AT&T 与 AST SpaceMobile 建立了合作关系，而 Verizon 也正尝试与其协同推进。然而，AST 被批评为“进展缓慢、延期不断”。目前仅部署了5颗商用卫星，远远落后于 Starlink 已部署的 650 颗 D2D 卫星。 业界专家 Tim Farrar 表示：“AT&T 当初称自己比 T-Mobile 和 Starlink 提前了18个月，但如今来看，AST 可能反而落后了18个月以上。” Verizon 被认为“对 AST 合作更不坚定”，并已与 Skylo 等其他卫星运营商合作。外界普遍认为，Verizon…

OpenAI 宣布，即日起将开放一种全新方式，让开发者在 ChatGPT 中构建并嵌入互动式应用程序。用户从本周一开始即可在 ChatGPT 中直接访问来自 Booking.com、Expedia、Spotify、Figma、Coursera、Zillow、Canva 等公司的互动式应用。同时，OpenAI 也正式推出了其应用开发工具包（Apps SDK）的预览版本，面向开发者开放。 这一消息是在 OpenAI 一年一度的开发者大会 DevDay 2025 上发布的。 OpenAI 首席执行官 Sam Altman 表示：“OpenAI 希望让 ChatGPT 成为人们实现目标的强大助手——无论是提升生产力、加快学习速度、激发创造力，还是解决生活中的问题。通过这些内嵌式应用，我们正在开启一个全新的互动、适应性强、个性化的应用生态系统。” 此次发布标志着 OpenAI 又一次尝试围绕其旗舰 AI 产品 ChatGPT 构建应用生态。不同于此前推出的 GPT 应用商店（GPT Store）那样的独立平台，此次的新系统直接将应用嵌入 ChatGPT 对话界面中，使用户能在自然交谈过程中调用第三方工具。这不仅为开发者提供了更广泛的分发渠道，也大幅提升了用户在 ChatGPT 中的互动体验。 用户只需在对话中输入应用名称，即可调用服务。例如输入“Figma，把这张草图变成可用图表”，即可唤起 Figma 应用。或者说“Coursera，可以教我一些关于机器学习的内容吗？”则会自动调取 Coursera 应用并进入学习界面。 在 Zillow 的应用展示中，用户只需用自然语言请求，便可查询某地某价位区间内的出租房源。ChatGPT 随即生成交互式地图展示房源，并可继续对话了解更多详细信息。 此外，ChatGPT 也会在适当时机主动推荐相关应用。例如当用户请求为即将到来的派对生成播放列表时，系统可能会自动调用 Spotify 应用协助生成歌单。未来，DoorDash、Instacart、Uber 和 AllTrails 等服务也将陆续接入 ChatGPT。…

在即将进行的高管更替之际，苹果公司正日益将焦点集中在硬件工程高级副总裁 John Ternus 身上。与此同时，公司已搁置“Vision Air”轻量版头显项目，将资源转向开发智能眼镜，而 Vision Pro 与 iPad Pro 的更新版本也即将发布。 尽管作为全球最具规模和影响力的科技公司之一，苹果过去十年来在高管层面维持了罕见的稳定性，但这一局面正在悄然发生变化。首席运营官 Jeff Williams 的即将离职，标志着苹果新一轮高管更替的开始。Williams 曾一度被视为 CEO Tim Cook 的接班人，但他在今年七月已卸下运营职责，并准备在年底前正式离任。 多位高层预计将陆续离开。例如人工智能负责人 John Giannandrea 的去留一直不明朗。尽管其团队在推出 Apple Intelligence 及 Siri 改版过程中屡屡受挫，他目前依旧留任，只是权力有所削减。被认为可能接替 Giannandrea 的 Mike Rockwell —— Vision Pro 的关键缔造者 —— 现在接手了修复 Siri 的任务，但高管层似乎更倾向从外部引入 AI 新领导。Meta 的一位 AI 高管成为潜在人选，而 Meta 近期也正进行 AI 部门重组，为其他公司提供了“挖角”机会。 苹果芯片部门资深主管 Johny Srouji 也被认为可能接近退休阶段。Srouji 长期负责硬件技术团队，包括每年推出的…

许多软件工程师对公司政治持宿命论态度。他们普遍认为参与政治毫无意义，原因包括以下几点： 首先，技术决策往往出于完全自私的动机，而这些动机并不受任何善意工程师的影响。其次，关键的利益相关者通常愚蠢且组织混乱，以至于工程师根本无法识别他们的需求，更不用说为其提供解决方案。再者，公司内部的政治博弈高度依赖于私人信息，而这些信息工程师往往无法获得，因此任何参与政治的尝试最终都会变成盲目乱撞。此外，管理层和高管几乎将所有时间都用于政治活动，而工程师则专注于技术工作，因此在政治博弈中，工程师天生就处于劣势。 总的来看，普遍的观点是：软件工程师根本不具备与专业政治操盘手同场竞技的能力。事实的确如此。如果一位软件工程师幻想自己能像《权力的游戏》中的角色那样策划阴谋，结果很可能是灾难性的——这些“阴谋”会立刻被揭穿，并被他人利用，反而对自己不利。搞政治手段需要经验和权力，而这两样工程师通常都不具备。 软件工程师在大型科技公司的政治游戏中更像是工具，而非真正的博弈者。然而，即使如此，也并不意味着无法涉足政治领域，只是方式有所不同——无需“搞阴谋”。 最简单的做法，就是积极参与并推动一项高关注度项目的成功。这本应就是本职工作的一部分。如果公司当前重金投入某项新项目，例如当前流行的人工智能项目，那么通过工程实力为该项目的成功作出贡献，就是一种对项目背后副总裁或高管的政治支持。作为回报，这些高管通常会给予工程师奖金、晋升机会，以及未来更多重要项目的参与权。作者在《棘轮效应决定工程师在大公司中的声誉》一文中曾详细论述过这一点。 稍难一点但控制力更强的方式，是将自己的技术构想“借壳上市”到已有的政治运动中。例如，一名工程师一直希望将某项已有功能拆分为独立服务。在实现这一目标上，有两条路径： 其一，是通过自身的政治资本推动：积极争取支持、向经理表明项目的重要性，并逐步说服质疑者，最终实现项目立项；其二，是让某位高管用他们强大的政治资本来推动这个项目。这需要等待一个公司层面的战略目标出台，而这个目标恰好与项目方向一致（例如在发生重大事故之后，公司可能突然注重“系统可靠性”）。此时，只需向经理提出，这项项目或许能成为可靠性提升的一部分。若时机判断准确，公司组织将会支持该项目。更妙的是，这不仅能实现项目落地，还能反过来提升工程师本人的政治资本。 组织的关注点往往呈波浪式变化。当公司高层关注“可靠性”时，VP们急需拿出能落地的可靠性项目来向上级展示成果，但他们自身缺乏提出这类项目的能力，因此通常愿意接受任何来自工程团队的提议。相反，当组织重心转向新产品发布时，高层并不希望工程师把精力投入到内部、客户看不到的系统改造中。 因此，若希望某项技术计划在公司内部顺利推进，最佳策略就是“等浪来”。提前准备多项不同方向的技术计划是明智之举。优秀的工程师在日常工作中就会留意到各种改进点，自然形成备选项目。例如： 当高层关注账单系统时，可将第一个项目包装为“可靠性提升”；当关注开发者体验时，则可推荐构建管道的改造；客户抱怨性能时，可提出用 Golang 重写作为解决方案；当 CEO 对外部文档系统的表现不满时，则可主张用静态站点重建。关键在于：任何时候都有一套详实且有效的技术方案，随时准备迎合当下组织的主旋律。 公司终究会在某些项目上投入资源，无论是否有合适的方案。但如果工程师未能事先准备，就无法左右最终选择的项目内容。经验显示，企业最糟糕的技术决策，往往是在“政治需要推动某事”却“缺乏优质选项”的情况下做出的。没有好点子时，只能用坏点子凑数。这个结果对谁都不好：高管需要费力将不理想的成果包装成成功，工程师则要耗费精力去构建一个错误的方案。 对于一位非常资深的工程师而言，高管们甚至会私下将这类失误归咎于其身上——而这种指责是有道理的。因为在恰当的时机提出正确的技术方案，正是资深工程师的重要职责之一。 这一切可以从两种角度看待：悲观者认为，这是在建议工程师成为公司政治操盘者手中的便利工具，助长其无休止的内部权力斗争；而乐观者则将其看作是一种合作方式，让高管设定公司优先级，而工程师则巧妙地将自身技术计划与其对接。无论选择何种解读方式，只要能在正确的时间推动正确的技术方案，最终就能实现更多技术目标。

自 COVID-19 疫情以来，工作文化发生了许多积极变化，但也出现了一些负面趋势——其中最突出的，是每位员工的会议数量平均增加了 13.5%。 问题在于：管理者与工程师对“会议”的理解存在巨大差异。 Paul Graham 曾在著名的《创作者时间表与管理者时间表》中写道： “当你按创作者的时间表工作时，会议就是灾难。一场会议就能毁掉整个下午，把它分成两个过小的时间段，让你难以完成任何需要深度思考的任务。” 如今，即使 AI 编码工具广泛应用，这一问题依然存在，甚至愈发严重。许多管理者以为工程师现在可以利用更碎片化的时间进行产出。 过去两年间，有研究对数百个工程团队进行了观察，试图找出表现最出色的团队所采取的不同策略。本文将分享他们的经验和可立即实施的做法。 什么是“深度工作”？ “深度工作（Deep Work）”这一术语由 Cal Newport 在其著作《深度工作：如何在分心的世界中取得成功》中提出。 深度工作，指的是需要大量脑力、能创造独特价值的工作。它无法在分心状态下完成。一个简单的测试是：如果某项任务可以在 Zoom 会议中完成，那它就不是深度工作。 与之相对的是“浅层工作（Shallow Work）”——例如回复 Slack 消息、查看邮件、审阅文档等，不需要动用全部注意力的任务。 软件工程曾被视为热爱深度工作的人的理想职业。至今仍有人认为工程师戴着耳机，独自在地下室敲代码。 但如今，要找到真正的“深度工作”时间变得越来越困难。而这种时间，在与 AI 协作的时代，变得更为重要。 深度工作为何如此关键？ 唯有进入“深度工作”状态，工程师才能真正进入所谓的“心流（Flow）”状态，也就是大家常说的“进入状态”。 深度工作能带来以下好处： 许多管理者犯的最大错误是认为：既然有了 AI 编码工具，深度工作就不再必要了。工程师应当习惯于频繁切换任务，反正每次生成代码都要等待几分钟，“那多做点别的也无妨”。 但现实情况是：这种频繁切换导致思维质量下降、提示词粗糙、AI 反馈变差，反而陷入不断求助 AI 修复问题的恶性循环。 如果能维持专注、沉浸于问题之中，所需的迭代次数将大幅减少——虽然没有具体数据支持，但长期的经验表明确实如此。 深度工作的障碍 远程办公本该是解药，但现实并非如此。 虽然通勤时间没了，但打扰却更多。自2020年以来，除了总会议量增长13.5%，远程会议的数量也激增了60%。更糟糕的是，92% 的人承认自己在远程会议中会“多任务处理”——而对于软件工程师来说，这个比例几乎可以说是 100%。 这种现象带来两大严重后果： 1. 原本需要“深度”的工作，变成了“浅层” 还记得前文提到的测试方法吗？能在 Zoom 会议中完成的任务，就不是深度工作。 代码审查（PR Review）是一个典型例子。 日程排满会议时，工程师会选择在会议中“顺手”看…