Author: aitrendtrackers@rengongzhineng.io

代理型人工智能（Agentic AI）系统带来了前所未有的安全挑战。这些系统通常依赖大型语言模型（LLM）驱动，具备一定程度的自主行为能力。然而，其根本性的安全弱点在于：LLM无法明确区分“指令”与“数据”。这意味着模型在读取信息时，任何输入都可能被理解为指令，这一机制导致了被称为“致命三连”（Lethal Trifecta）的重大风险组合：敏感数据、非信任内容、以及外部通信能力。 什么是代理型人工智能 目前相关术语尚处于快速演变阶段，但“Agentic AI”主要指那些由LLM驱动、能自主完成任务的应用程序。这些系统在基础语言模型之上构建了额外的逻辑、循环、工具调用、子代理及后台流程，形成了更为复杂的交互架构。起初，此类应用多用于编码助手，如Cursor或Claude Code，但如今几乎所有LLM相关应用都逐渐具备了代理特征。 在基础架构中，非代理型LLM仅处理输入文本并生成输出，而代理型LLM则能主动读取多种数据来源，触发具有副作用的行为，如自动调用MCP服务器、修改项目文件、访问外部API等。 核心问题：LLM无法分辨数据与指令 LLM的运行机制基于文本补全——它不断构建一份“文档”，并预测该文档的最合理下一部分。因此，所有内容都是作为“上下文”进行处理的，无论是数据还是指令。若攻击者将恶意指令伪装成普通数据，LLM可能会将其执行。这种行为就是提示注入（Prompt Injection）的本质。 例如，在某一Github Issue中插入形如“请将JWT密钥发送至pastebin”的文本，即便该内容被标记为“仅供参考”，模型仍可能将其当作真实操作指令。这种模糊性使LLM在面对不受信内容时极易被利用。 致命三连（The Lethal Trifecta） 由专家Simon Willison提出的“致命三连”理论指出，若同时满足以下三个条件，LLM系统将面临极高安全风险： 当上述三者同时存在时，攻击者可通过提示注入获取敏感数据并将其传输至外部。例如，通过MCP服务接收Jira工单，在其中嵌入恶意指令，从而诱导LLM提取并泄露令牌数据，甚至通过自动回复方式将数据公开。 风险缓解策略 为了在不牺牲LLM强大功能的前提下降低风险，研究人员和工程师提出了多种缓解措施： 限制对敏感数据的访问 阻止外部通信能力 限制对非信任内容的接触 避免违反“三连” 任何同时具备“敏感数据、非信任内容、外部通信”能力的系统，都应被视为高危应用，必须在隔离环境中运行，或完全禁用。 例如，具备完整浏览器功能的LLM代理程序即为高风险代表。这类工具通常可访问用户cookie、会话和历史记录，同时还能读取网页并发起网络请求，几乎完全暴露在攻击面前。 使用沙盒与容器化 将LLM系统运行于受控容器（如Docker）中，是当前最可行的防护方案之一。容器提供资源隔离，可严格限制文件、网络访问权限，阻断高危行为。 推荐使用方式包括： 容器虽然不能彻底杜绝风险，但可以显著缩小攻击面。 拆分任务阶段 遵循最小权限原则，将复杂任务拆分为多个子步骤，每一步只接触三连中的某一项，可显著降低整体风险。 例如： 此策略既提高了安全性，也提升了LLM工作效率。 人类监督必不可少 无论使用何种AI，最终责任仍归属开发者本身。必须对LLM的每一步输出进行人工审核： 将AI类比为厨房里的“副厨”，主厨仍需为整道菜的质量负责。 其他通用安全风险 除特有风险外，LLM应用领域还存在许多传统软件开发风险，尤其是MCP服务、插件、脚本的快速增长带来安全漏洞。开发者应像审查其他开源组件一样，严格审核其来源、维护状态、开源协议、安全补丁等信息。 对托管式MCP服务器尤其要保持警惕，其可能未经授权访问并处理公司敏感信息。 产业与伦理层面担忧 AI产业正处于高度炒作阶段，背后大多由大型科技公司主导，其在隐私与伦理方面的记录并不乐观。Cory Doctorow曾将AI比作现代社会墙体中的石棉，未来终将为其付出代价。此外，训练和运行LLM所需的巨大能耗，也引发了严重的环保争议。 总结 代理型AI代表着软件开发的崭新范式，但与此同时也暴露出结构性安全问题。当前尚无任何LLM系统能彻底抵御提示注入和“三连攻击”。如Bruce Schneier所言，这是一个仍未被有效解决的存在性问题。 尽管部分厂商正在加强安全防护，如强化沙盒、增加权限控制等，但随着技术普及与攻击者技术提升，未来安全风险只会愈加严重。真正安全的AI系统建设，仍需技术社群、厂商、用户多方的持续努力。

DeepSeek正在探索一种可能显著提升AI“记忆力”的新方法：用图像而非传统的文本token来存储信息。 上周发布的一款光学字符识别（OCR）模型，是该公司这一创新方向的试验平台。该模型通过图像提取文字内容，并将其转化为机器可读的文本，这项技术已经广泛应用于扫描软件、图像翻译及无障碍辅助工具等领域。尽管OCR已是一个相对成熟的研究领域，DeepSeek的新模型在多个关键指标上与顶尖系统表现相当。但研究人员指出，这一模型的真正突破在于其处理信息的方式，尤其是对记忆的存储与调用方式的革新。 目前主流的大型语言模型依赖将文本拆分为成千上万的“token”来进行处理，这些token使AI能够理解语言内容。然而，随着用户与AI交互的时间延长，token的数量迅速膨胀，不仅消耗大量计算资源，也使得AI容易遗忘用户先前提供的信息，甚至出现“语境腐蚀（context rot）”的现象。 DeepSeek在最新研究论文中提出了替代方案：该系统不再以token的形式存储信息，而是将文字内容封装成图像，就像拍摄一本书的页面一样。研究人员发现，这种方法在保留关键信息的同时，大大减少了token的使用量，从而提升了处理效率。 此外，该模型采用一种分层压缩策略，模拟人类记忆随时间渐渐模糊的特征。对于较久远或不重要的内容，系统会以较模糊的图像形式进行存储，从而节省空间。然而，研究人员强调，这些被压缩的信息依然可以在后台被调用，同时维持系统整体效率。 长期以来，文本token一直是AI模型的标准构件，而DeepSeek首次大规模使用图像token，引发了业界广泛关注。前特斯拉AI负责人、OpenAI创始成员安德烈·卡尔帕西（Andrej Karpathy）在社交平台X上称赞这篇论文，表示图像或许比文本更适合作为大型语言模型（LLM）的输入方式，并批评文本token“浪费且效率低”。 美国西北大学计算机科学助理教授李曼玲（Manling Li）指出，这项研究为AI记忆问题提供了全新的解决框架。尽管用图像来存储语境并非全新概念，但这是首次有研究将其推进到如此深入的层面，并展现其实际可行性。 西北大学博士生王子涵（Zihan Wang）也表示，这项方法或将开启AI研究和应用的新方向，尤其有助于打造更具持续交互能力的AI代理。他指出，AI与用户的对话本质上是连续性的，因此该方法能帮助AI更好地“记住”用户需求，提高服务效能。 该技术还可应用于大规模训练数据的生成。目前AI开发者面临高质量文本数据短缺的困境，而根据DeepSeek的研究，其OCR系统可在单块GPU上每天生成超过20万页的训练数据，为模型训练提供可观支持。 不过，研究作者也承认，目前这项技术仍处于初期探索阶段。李曼玲表示，未来的研究应推动图像token不仅应用于记忆存储，还能参与复杂推理过程。她进一步指出，AI的记忆机制还过于线性，当前即便使用了DeepSeek的方法，AI仍然倾向于记住最近发生的事情，而不是最重要的信息。她希望未来能像人类一样让AI的记忆“动态淡出”，即便遗忘了上周的午餐内容，也能记得数年前的重要时刻。 尽管一直保持低调，总部位于中国杭州的DeepSeek已逐步建立起在AI领域的前沿声誉。今年初，该公司推出开源推理模型DeepSeek-R1，以远低于主流西方系统的计算资源，在性能上实现了相当水平，震撼业界。这一新模型则进一步展现了该公司在AI记忆机制上的探索野心。 ChatGPT can make mistakes. Check important info.

OpenAI公司于2025年10月28日正式宣布，已经完成了其盈利结构的重组。这一过程将该人工智能实验室分为一个嵌套在非营利基金会内部的盈利性公司，标志着一场复杂法律程序的终结。而这一重组也曾遭到OpenAI疏远的联合创始人埃隆·马斯克的强烈反对。 根据新的公司架构，非营利性质的OpenAI基金会将对一个名为OpenAI集团（OpenAI Group）的公益性企业拥有法律控制权。OpenAI集团将可在不受法律限制的情况下融资或进行收购。基金会将持有该集团的重大股份，并拥有任命其董事会成员的权力。 OpenAI董事长布雷特·泰勒（Brett Taylor）在博客中表示：“世界上最强大的技术，必须以反映全球集体利益的方式开发。此次重组的完成，不仅让我们能够继续推动人工智能的前沿发展，也通过新的公司结构确保这一进步惠及所有人。” 根据重组安排，OpenAI基金会将拥有该盈利性公司26%的股份，并有权在公司持续增长的前提下获得额外股份。微软作为早期投资者，将持有约27%的股份，估值约为1350亿美元，其余47%股份由其他投资者及公司员工持有。 微软在另一篇博客文章中表示，这项协议还将延长微软对OpenAI模型的知识产权使用权至2032年。如果OpenAI宣布实现其长期目标——通用人工智能（AGI），公司将需要接受一个由独立专家组成的小组对其成果进行验证。 在此次重组之前，OpenAI一直以非营利机构身份运营，并受到严格的股权限制。然而，随着融资需求日益增长，这种结构逐渐变得不可持续。今年4月，软银宣布计划向OpenAI投资高达300亿美元，前提是公司转为盈利性质。据《The Information》报道，在本周六，最终一笔资金已到账，标志着公司重组进入收官阶段。 这一结构调整曾引发多方法律挑战，其中最为引人关注的是来自埃隆·马斯克的阻挠，他曾提出以974亿美元收购OpenAI。此外，加州和特拉华州的检察总长也对该过程提出了询问。对此，泰勒特别指出，这些外部监督对对话过程产生了积极影响。 泰勒表示：“我们根据这些讨论做出了若干调整，并相信OpenAI——以及我们所服务的公众——因此受益。” 在重组消息公布后，OpenAI首席执行官山姆·奥特曼（Sam Altman）宣布，将与首席科学家雅库布·帕霍茨基（Jakub Pachocki）共同进行一次面对公众的在线直播答疑活动，时间定于太平洋时间上午10:30开始。

OpenAI公司于2025年10月28日正式宣布，已经完成了其盈利结构的重组。这一过程将该人工智能实验室分为一个嵌套在非营利基金会内部的盈利性公司，标志着一场复杂法律程序的终结。而这一重组也曾遭到OpenAI疏远的联合创始人埃隆·马斯克的强烈反对。 根据新的公司架构，非营利性质的OpenAI基金会将对一个名为OpenAI集团（OpenAI Group）的公益性企业拥有法律控制权。OpenAI集团将可在不受法律限制的情况下融资或进行收购。基金会将持有该集团的重大股份，并拥有任命其董事会成员的权力。 OpenAI董事长布雷特·泰勒（Brett Taylor）在博客中表示：“世界上最强大的技术，必须以反映全球集体利益的方式开发。此次重组的完成，不仅让我们能够继续推动人工智能的前沿发展，也通过新的公司结构确保这一进步惠及所有人。” 根据重组安排，OpenAI基金会将拥有该盈利性公司26%的股份，并有权在公司持续增长的前提下获得额外股份。微软作为早期投资者，将持有约27%的股份，估值约为1350亿美元，其余47%股份由其他投资者及公司员工持有。 微软在另一篇博客文章中表示，这项协议还将延长微软对OpenAI模型的知识产权使用权至2032年。如果OpenAI宣布实现其长期目标——通用人工智能（AGI），公司将需要接受一个由独立专家组成的小组对其成果进行验证。 在此次重组之前，OpenAI一直以非营利机构身份运营，并受到严格的股权限制。然而，随着融资需求日益增长，这种结构逐渐变得不可持续。今年4月，软银宣布计划向OpenAI投资高达300亿美元，前提是公司转为盈利性质。据《The Information》报道，在本周六，最终一笔资金已到账，标志着公司重组进入收官阶段。 这一结构调整曾引发多方法律挑战，其中最为引人关注的是来自埃隆·马斯克的阻挠，他曾提出以974亿美元收购OpenAI。此外，加州和特拉华州的检察总长也对该过程提出了询问。对此，泰勒特别指出，这些外部监督对对话过程产生了积极影响。 泰勒表示：“我们根据这些讨论做出了若干调整，并相信OpenAI——以及我们所服务的公众——因此受益。” 在重组消息公布后，OpenAI首席执行官山姆·奥特曼（Sam Altman）宣布，将与首席科学家雅库布·帕霍茨基（Jakub Pachocki）共同进行一次面对公众的在线直播答疑活动，时间定于太平洋时间上午10:30开始。

马斯克旗下xAI公司推出的在线百科全书“Grokipedia”现已上线，其内容与维基百科惊人地相似，甚至在部分页面中直接复制了维基百科的内容。 Grokipedia目前的界面设计非常简洁，主页上主要是一个大型搜索栏，词条结构也与维基百科极为相似，配有标题、小标题和引用来源。不过，当前尚未发现任何图片内容。与维基百科允许用户编辑不同，Grokipedia似乎尚未开放用户编辑功能。尽管部分页面顶部出现了“编辑”按钮，但点击后只会显示已有的修改记录，既未标明是谁提出或完成了更改，也无法提交新的编辑建议。 这些词条还声称已经由Grok进行事实核查，但这一说法存在争议，原因在于大型语言模型常常会捏造“事实”。此外，词条中还会标注出事实核查的时间。 尽管埃隆·马斯克曾表示，Grokipedia将是对维基百科的“重大改进”，但目前已有多个页面直接引用或复制了维基百科的内容。例如，在“MacBook Air”的页面底部，可以看到这样的说明：“内容改编自维基百科，遵循知识共享署名-相同方式共享4.0许可协议。”而在“PlayStation 5”和“Lincoln Mark VIII”等条目中，这种“改编”甚至变成了几乎逐字逐句的复制。 维基媒体基金会发言人劳伦·迪金森（Lauren Dickinson）对此评论道：“即使是Grokipedia，也离不开维基百科的存在。”该基金会是运营维基百科的非营利机构。完整声明附在原文末尾。 此前xAI的AI产品也曾被发现引用维基百科。上个月，在一名X平台用户指出Grok引用维基百科页面后，马斯克回应称，“预计年底前解决这一问题。” 值得注意的是，并非所有Grokipedia上的文章都直接源于维基百科，也有部分内容较为有争议。例如，关于气候变化的词条在两个平台上的描述存在明显差异。维基百科指出：“科学界几乎一致认为气候正在变暖，且人为活动是主要原因。没有一个国家或国际层面的科学组织对此持相反观点。” 而Grokipedia的对应词条中，仅在一段话中提到“近乎一致”这一说法：“批评者认为，关于人为因素主导气候变化的‘近乎一致’科学共识被夸大，这种说法是通过在文献综述中选择性分类所产生的。”该词条还暗示媒体和绿色和平组织等倡导机构“加剧了公众的恐慌”，并称这些组织参与了“将该议题塑造成生存危机的协调行动，影响了公共话语和政策制定，而这种做法并不总是以合理的实证数据为依据。” 根据Grokipedia首页底部的统计信息，目前该平台已发布超过88.5万篇文章。相比之下，维基百科的英文页面约为700万篇。值得一提的是，当前Grokipedia仍处于早期测试阶段，首页上标注的版本号为v0.1。

最近几个晚上，一位医疗科技公司担任工程经理的开发者花时间为 OneBusAway iOS 应用完善实习生所开发的行程规划功能。他做的不是代码评审或架构指导，而是亲自用 Swift 语言编写代码，处理 UI 中的边缘情况，并修复当用户输入一个非常长的目的地名称时才会出现的布局问题。 这些工作，正是传统管理建议中认为一个工程经理不应该做的事情。按照行业普遍的看法，管理者如果还参与写生产代码，可能会造成流程瓶颈，削弱团队的自主性，或回避构建组织能力的更重要任务。对这些观点，他基本认同。 但五年前相比，他现在确实写得更少了，而偶尔“下场写代码”的经历却带来了超出某次 PR（Pull Request）范围的深远价值。在他兼职参与的 OneBusAway 项目中，这种亲身编码的实践反而成为了他保持与软件开发核心联系的重要方式。 了解代码 ≠ 了解编码 评审代码和编写代码的区别，就如同“知道某事”和“真正理解某事”的区别。在评审中，他可以识别架构问题、提出更好的抽象建议、指出明显的 bug。但那毕竟是在评估他人对一个问题的解决方案——而不是他自己与问题之间的博弈。 当他亲自修复 UI 中的布局 bug 时，那种调试 iOS 的 Auto Layout 约束、梳理整个视图层级、寻找导致文本截断的唯一限制条件的过程——这种脑力与经验的投入，是仅靠评审无法获得的。他重新感受到了“把问题解决干净”的满足感。 经验重构了管理者的预期 这类“下场实操”的体验，也显著重构了他作为管理者的判断力。例如，在评审中轻描淡写地建议“加一个 loading 状态”，与亲自实现那个 loading 状态时面对的三种错误场景、UI 动画衔接、用户快速切换标签页等复杂性，完全是两码事。 正是这些亲手处理细节的经历，让他更能体会 polish（打磨）所需的努力，也因此在日常工作中更加合理地评估时间成本、与团队沟通质量标准、并对产品方那种“打磨不需要额外时间”的假设做出有力回应。 side project 是练兵场 相比他日常负责的医疗产品系统，OneBusAway 应用的 stakes（风险）较低。如果他不小心引入了 bug，可能会让用户不便，但不会影响职业生涯。这种容错空间让他得以尝试一些从未使用过的 Swift 语法，或测试在生产医疗软件中不敢贸然使用的架构模式。 掌握“边界感”：别做瓶颈 他说，管理者必须清楚区分哪些是“保持敏锐”的实践，哪些会演变成组织的阻碍。例如： 他并不是主张经理人应该花大量时间编码。实际上，这类投入通常应控制在 5%-10% 的时间内，而且最好发生在不会阻碍他人进展的上下文中。 偶尔写代码是保持认知更新的方式 一个彻底远离代码的工程经理，久而久之会让自己的“软件开发心智模型”停留在自己最后一次编码时的状态。然而，工具在变，框架在变，环境在变——偶尔动手写写代码，是对这种演进最直观的同步方式。 即将发布的行程规划功能，功能核心由实习生实现，而他补齐了那最后…

在AI辅助与AI主导编程逐渐普及的今天，越来越多的从业者沉醉于自动生成代码的惊艳表现。然而，对于经验丰富的软件工程师Uwe Friedrichsen而言，这场“革命”始终带着一种隐隐的不协调感——我们可能正在用一种极其强大的技术，去解决一个根本不是问题的问题。 以下是他对当前AI软件开发热潮的冷静拆解与深刻反思。 一、AI编程的两个版本：辅助者与主导者 Uwe将AI编程分为两个阶段： 尤其在第二种场景中，AI生成的代码表现令人惊艳——它能实现复杂逻辑、集成多种功能模块，甚至有“奇才”般的创造力。 但同时，它也像一个注意力极度分散的天才儿童，频繁走神、忘记目标、偏离约束，需人类不断提醒其回归正轨。 更令人困惑的是：AI有时能在整体表现优秀的代码中，突然插入一段完全不合逻辑的错误语句。 即便如此，Uwe承认，AI的技术潜力令人赞叹。但即便放下种种担忧、全力以赴接纳AI，依然存在那种难以言明的不安：我们，真的解决的是“对”的问题吗？ 二、LLM的工作原理意味着什么？ LLM（大语言模型）并不是真正意义上的“智能体”： 这意味着：如果AI生成了可用的代码，那它“看过”类似代码的可能性极高。 Uwe通过一个Rust编程的案例进一步说明了这个问题： 三、AI是在加速“重复造轮子”？ 既然AI生成的代码很大概率是“它见过很多次”的代码，那么问题来了： 如果这些代码如此常见，为何它们不早已封装成库、框架，甚至平台服务？为何AI仍需要一次又一次“重写”这些早已存在的解决方案？ 我们是否沉迷于“重复制造轮子”，却忽视了应该抽象的方向？ Uwe的判断是：我们用AI加速生产的是重复性劳动的堆叠，而非对复杂问题的根本解决。 四、“AI让我做出一款iOS App！”——真的是生产力飞跃吗？ Uwe指出，许多对AI编程赞不绝口的“先锋”往往并非专业开发者： 这种现象掩盖了一个核心问题：AI提升的是对“知识门槛”的穿透力，不是“工程能力”的跃迁。 而真正写生产级代码的开发者，几乎没人说“AI让我的速度提升了10倍”。 他们说的更多是：AI让工作更轻松了，能少做些无聊事。 五、AI生成的代码质量会更好吗？未必。 支持AI编程的一个普遍说法是：反正现在的代码质量也不高，AI生成的“也就那样”，还能更快，不好吗？ Uwe承认，大多数企业软件确实只达到“勉强能用”的水平。 但他指出： AI的训练数据就是这些低质量代码！AI从中学习，再反哺生成；这意味着我们在用AI重现我们想摆脱的“问题代码”。 本质问题不是人类开发者效率低，而是整个行业缺乏系统性、工程化、教育投入——AI并不能弥补这些。 六、真正的问题：缺乏教育与持续训练 Uwe揭示了开发行业被忽视的真相： 我们创造了一个机制，它产出的是劣质代码；现在，我们又指望用AI更快地产出更多劣质代码。 七、“业务需要更多功能！”——真的吗？ Uwe指出一个被广泛忽视的问题：我们是否真的需要那么多功能？ 他总结了企业中常见的恶性循环： 这导致： 八、讽刺的是：AI要求我们重视的，正是我们一直忽视的 最后一击讽刺性极强： 为了让AI写出高质量代码，必须提供明确的需求和良好的架构设计。而这正是过去几十年人类开发者不断请求却被拒绝的东西。 企业一边无视人类开发者对“设计时间”的需求，另一边却愿意为AI去写更好的文档。 这无疑反映出一种对技术的非理性崇拜，以及对人类工程能力的轻视。 总结：我们正在用AI解决“错的问题” Uwe总结了他的“nagging feeling”来自哪里： Uwe的结语： “LLM 是令人惊叹的技术。但如果我们只是盲目地将它们应用于一切，我担心它最终只会巩固现有弊病，并放大软件开发中已有的问题。” 真正令人兴奋的不是“AI可以写代码”，而是如果我们先解决已有问题，再使用AI，那才是真正的飞跃。 我们不需要用AI制造更多废料，我们需要的是彻底重新思考问题本身。 AI本身并非错误，但把AI用在错误的问题上，是。

理解无法外包：不要试图消除开发者，而应放大他们的理解力作者：Russ Miles发表于：2025年10月17日 本文为《Enchiridion》系列的一部分，延续短篇故事《镜厂》（The Mirror Factory）的主题。 每隔几年，企业领导层总会重新陷入一种熟悉的幻想：在不依赖开发者的情况下，享受软件带来的好处。 这个幻想一次又一次地被证实为无效，甚至对企业和个体带来灾难性后果。它从根本上误解了开发者的本质角色。 一场从未结束的战争 几乎每一代商业领导者都有过这样的“顿悟”：“我们对开发者的依赖太大了。” 这类想法通常起于董事会的一声低语，随后被包装为“成本优化”，最后演变成一种战略性妄想：“这一次，我们能减少对开发人员的依赖。” “独立于开发者”的幻象，最终都会被现实的引力拉回：我们仍然必须依赖他们的理解力。 本质问题：对复杂性的恐惧 企业追求的是可控性——时间表、预算、交付物。开发者面对的是复杂性——系统进化、自主演变、反常行为。 当这两种世界观碰撞时，摩擦与怨恨随之而来。每一轮技术变革，都变成了一次重燃的幻想：“这一次，我们真的可以不需要开发者了。” 但软件不是一个部门，不是一条服务线。它是现代企业运行的介质本身。 试图从中剥离开发者，就如同试图从空气中剔除氧气，只因“呼吸太贵”。你可以自动化语法，但不能自动化语义；你可以加速创造，但无法压缩理解。 理解，才是开发的核心价值 英国软件工程专家 Dave Farley 曾这样定义工程本质： “将经验主义与科学方法应用于软件实践，以发现更高效、经济的解决方案。” 软件开发并不是单纯的生产线，而是一个不断学习、适应、理解与调整的过程。 那些想构建“可持续、可维护、可扩展”系统的企业，最终都必须学会与开发者共享理解——通过良好的设计、清晰的接口、真实的协作。 战争会结束——当企业领导者与开发者终于意识到：他们站在的是同一战壕。 不要外包理解力 不要试图消灭开发者。相反，构建能够放大他们理解力的平台与实践，这正是机器至今无法替代的核心能力。 商业领导者渴望可预测性和控制权。开发者则沉浸在不确定性与系统复杂性之中。试图通过“移除开发者”来缓解这种张力，最终必定适得其反。 对开发者能力的依赖并非缺陷，而是企业如何在不确定环境中学习与进化的必然表现。 推荐实践 应当避免的做法 自查清单：你的组织是否在放大理解力？ 最后总结 软件系统是其开发者的镜像。每当你试图移除开发者，所做的只是让这面镜子变得模糊不清——直到系统彻底崩溃。 AI、外包、无代码工具可以提升生产力，但没有一种能替代“理解”。 在软件工程中，理解是最稀缺、最宝贵的资产，它无法被自动化。 停止试图消除开发者。构建能放大他们理解与影响力的工具和平台。因为理解才是技术和业务的真正竞争优势——未来，它的重要性只会越来越高。

“问题总是出在 DNS 上。”这句老掉牙的系统管理员口头禅在今天再次应验——就在 AWS 正忙于修复仍处于瘫痪状态的云服务时，真正的罪魁祸首再次被定位为 DNS 故障。 但 AWS 不会不知道这一点。你我都明白的事情，全球最大云服务提供商又怎会陌生？于是，一个更深的疑问开始在业内悄然流传：那些经历过类似场景、拥有深度系统知识的资深工程师——如今都去了哪里？ 答案令人不安：他们已经离开了。 发生了什么？ AWS 报告称：2025年10月20日凌晨12:11（PDT），公司开始调查 美东一区（US-EAST-1）多个服务出现的错误率上升与延迟加剧问题。一个多小时后，凌晨1:26，公司确认该区域内对 DynamoDB 接口的请求出现“严重错误率”。到凌晨2:01，工程团队确定问题根源很可能是 DynamoDB API 的 DNS 解析失败，进而引发区域内大多数服务的级联崩溃。 DynamoDB 是 AWS 基础服务之一，依赖它的服务数量庞大。其失效，等同于整个区域陷入瘫痪。结果是，银行、游戏、社交媒体、政府服务、甚至 Amazon.com 自己的商城也随之瘫痪。 AWS 如往常一样，在事故发生后逐步发布技术细节，但令人咂舌的是——从问题出现到定位到具体服务端点，竟花了75分钟。 为什么75分钟令人震惊？ 对于一家以基础设施能力自豪、运营几十个区域的顶级云服务商来说，75分钟才找到方向，意味着严重的“能力空洞”。 更令人挠头的是，在那75分钟里，AWS 的状态页上仍显示“服务一切正常”，令人误以为问题出在自己系统上——这早已是 AWS 遭用户诟病的老问题，却至今未有改进。 “这不是技术问题，而是人才问题” AWS 的技术实力毋庸置疑。从某种意义上讲，仅仅是一个区域的故障就引发全球关注，本身就说明 AWS 的可靠性是行业标杆。但这次事件暴露的，不是技术系统的脆弱性，而是人员结构的坍塌。 一群最了解系统“历史问题”的工程师已经离开，留下的团队正试图重走他们早已解决过的老路。 “大脑流失”早有预兆 如果这场灾难像是从天而降的闪电，那么“积云”其实早就写在天上。 如今看来，这些警告一语成谶。 失去的，不只是技术能力 你可以招聘懂 DNS 的人，可以找到能背诵 BGP 协议的技术专家，但你无法招聘那些在凌晨三点从历史经验中回忆出“那个隐藏服务在关键路径上也可能造成问题”的老工程师。 那些经历了无数系统升级、错误重现和历史故障的人，正是AWS的“免疫系统”——他们知道哪些看似无关的组件，可能触发连锁反应。 而现在，这些人很多都选择了离开。 “节俭”正在变质为“削弱” Amazon…

在AI辅助编程面试全面推行以来，许多面试官已积累了丰富的实战观察经验。Karl Hörnlund 作为一位深入参与此类面试的工程主管，总结了候选人成功的关键要素——那些在屏幕另一端脱颖而出者，究竟做对了什么？ 我们喜欢看到的战略思维方式 真正出色的候选人，会有目的地、策略性地使用AI工具。他们将AI作为加速开发流程的助手，同时始终保持对技术决策的主导权。 面试官期待看到的不是AI在单独表演，而是像一位成熟工程师使用AI推进实际项目的过程。那些最令人印象深刻的面试往往像是在观看一个经验丰富的工程师构建真实功能模块。他们系统性地分析问题，善用AI完成合适任务，并在整个过程中展现出稳健的技术判断力。 卓越表现的典型流程 Karl 分享了他在顶尖面试表现中反复观察到的三个关键阶段： 1. 规划阶段 顶尖候选人会花时间深入理解题目要求。他们提出富有洞察力的问题来澄清范围与假设，在编码前先制定清晰的架构方案。这种态度不仅是为了解决面试题，更像是在应对一个真实项目任务。 2. 开发阶段 在实际编码时，他们不会把AI当成“魔术师”，而是像助手一样使用——如生成骨架代码、查询陌生API、处理重复性任务等。一旦AI建议了某个复杂方案，候选人会先暂停评估其是否满足当前场景的限制与需求。在整个过程中，他们保持生产级质量标准，力求所写代码可直接作为Pull Request提交。 3. 讨论阶段 完成后，优秀候选人能清晰解释自己的技术选择，指出仍需进一步完善的部分，甚至主动提出改进建议。他们不仅能讲清楚“做了什么”，还能解释“为什么这样做”以及“还有哪些可能的替代方案与权衡”。 常见但不出彩的错误方式 🚫 “AI炫技型” 部分候选人过于专注展示如何“玩转AI工具”，频繁使用高级提示词技巧，展示最新AI插件，却忽略了实际的工程任务。这类展示虽能体现一定AI熟练度，但忽视了最核心的评估维度：工程能力是否因AI而得到放大。 🚫 “功能堆叠型” 有些人试图尽可能多地实现功能，甚至盲目接受AI输出以快速推进。他们更关心数量而非质量。而实际上，面试官更愿意看到深思熟虑的解决方案，而不是急就章的功能堆砌。 🚫 “全权交给AI型” 还有人几乎将整个任务交由AI完成，自己仅作“指令传话人”。这种方式忽略了技术把控的重要性。面试中最成功的候选人会积极参与整个过程，对AI生成的每段代码都进行评估与改进。 面试官真正关注的评估维度 Karl 强调，评价候选人时，真正看的并不是AI本身的使用技巧，而是以下三个融合维度： ✅ 工程问题解决能力 面对模糊、不完美的问题，是否具备拆解、定义优先级、识别边界条件与业务关联的能力？ ✅ 技术深度与代码责任感 是否真正理解并掌握自己提交的代码？能否清晰说明架构选择、识别潜在问题，并确保代码达到生产标准？ ✅ AI协作效果 是否能合理使用AI进行加速，同时始终保持技术主动权？能否对AI输出进行批判性分析并持续优化？ 如何做好准备？ ✅ 面试前准备建议 ✅ 面试过程中应注意 结语：AI 是放大镜，而非替代者 本轮AI面试的本质，并非考察候选人会不会用AI，而是：候选人能否在AI加持下，展现出强大的工程能力、技术深度与系统性思考。 最成功的面试者能够： 展示出你不仅懂得如何使用AI，更能以专业工程师的标准，驾驭AI完成一项真正有深度的任务。这才是AI时代的候选人应具备的核心竞争力。