来自 Microsoft Build 2026 的一场“真实对话”——Scott Hanselman 与 Mark Russinovich 的 BRK247 完整解读

引言：当两位技术老兵选择不谈 hype

在微软 Build 2026 大会上，有一场 session 既没有华丽的 demo，也没有一键生成完整 App 的魔法。它的标题很朴素：BRK247 – How Agents Reshape Software Engineering。

但它的两位主讲人，却足以让任何开发者停下来认真听：

  • Scott Hanselman：微软开发者社区副总裁，超过 30 年编程经验，既是布道者也是终身程序员。

  • Mark Russinovich：微软 Azure CTO、Sysinternals 之父，真正的操作系统内核大师。

他们共同主持一档名为《Scott & Mark Learn To...》的播客，而这场演讲就是播客精神在 Build 舞台上的延伸——“Real talk, no hype”（实话实说，不炒作）。

他们没有承诺 AI Agent 会取代你，也没有贩卖焦虑。他们用真实的失败案例、公开的论文数据，以及几十年的工程直觉，给出了三个清晰而深刻的结论。这三点，我认为每一个还在写代码的人，都应该认真思考。

三个核心结论（原文提炼）

  1. AI 不会取代人类的监督——工程判断力、系统边界理解、风险直觉，短期内无法被 AI 接管。

  2. 开发者的重心正在转移——从“写代码”转向“指导 AI、验证 AI、深度思考复杂逻辑”。

  3. 初级开发者必须被保护——如果行业只追求短期效率而放弃培养新人，将引发人才链断裂的伦理危机。

下面，我尝试从 伦理判断、决策逻辑 和 学习机制 三个维度，对每一个结论做更深入的拆解。

结论一：AI 不会取代人类的监督 —— 伦理与判断力的不可替代性

伦理维度的思考

很多人讨论 AI 取代工作时，习惯问“它能做到吗？”——这是一个纯粹的技术问题。但 Russinovich 和 Hanselman 提出了一个更根本的伦理问题：即使 AI 做到了，我们应不应该让它做？

在 ZoomIt 全景拼接和 ClearType 字体渲染的案例中，AI 给出的方案“看起来对”，但底层逻辑完全错误。如果无人监督，这些错误会进入生产环境，轻则造成界面错位，重则破坏用户体验的可访问性（例如 ClearType 的错误实现可能导致视觉疲劳甚至阅读障碍）。

这引出了一个经典的 责任归属 伦理问题：当 AI 造成损害时，谁负责？目前的法律和行业共识依然指向人类。因此，监督不是一种可选的“谨慎”，而是必须内嵌在工程流程中的伦理义务。

决策逻辑：人机协作的分层决策模型

基于这个伦理前提，演讲实际上暗示了一种分层决策模型：

决策层级

适合 AI 执行

必须由人类裁决

代码生成（样板/CRUD）

✅

❌

测试用例生成

✅

❌（但需抽样验证）

边界条件识别

❌

✅

架构权衡（性能 vs 可维护性）

❌

✅

非功能性约束（安全、隐私、可访问性）

❌

✅

这意味着，未来的软件工程决策不是“AI vs 人”，而是 AI 负责扩展人类判断的带宽，人类负责守住决策的最后一道门。

学习机制：如何培养“监督能力”

如果监督是必须的，那么开发者如何学会监督？传统的“写更多代码”路径在此失效，因为 AI 生成的大量正确代码掩盖了需要监督的点。演讲中提到了一个有效的学习机制：Preceptor 模型（向导式教学）。

  • 在安全环境（沙盒、代码分支）中允许 AI 犯错；

  • 开发者作为“导师”看到错误、分析错误、复盘错误；

  • 错误本身成为学习材料。

这种机制不仅适用于人教人，也适用于人训练 AI——但关键是，必须有具备判断力的人类导师在场。这就是为什么初级开发者不能被排除在团队之外：他们也需要在真实的监督实践中成长为未来的导师。

结论二：开发者的重心正在转移 —— 从编码到指导、验证与深度思考

伦理维度的思考

重心的转移不是技术问题，而是一个 职业身份伦理 问题。过去，一个“好程序员”的标志是能写出优雅、高效、可维护的代码。未来，“好程序员”的标志将变成：能问出正确的问题，能识别 AI 给出的错误答案，能在模糊的需求中提炼出可验证的约束。

这本质上是将工程师从 执行者 转变为 判断者。而判断力的培养，远比语法的学习更慢、更依赖经验，也更依赖失败的积累。如果行业为了效率而让 AI 接管所有失败场景，人类将永远无法获得判断力。

决策逻辑：从“如何做”到“为什么这样做”

演讲中举了一个极具象征意义的例子：AI 在处理并发竞争条件时，插入一个 sleep() 来“修复”问题。从“如何做”（How）的角度看，AI 完成了任务——测试通过了。但从“为什么这样做”（Why）的角度看，这个方案是灾难性的。

因此，未来开发者的核心决策不再是“选择哪个库”或“用哪种排序算法”，而是：

  • 这个问题是否适合交给 AI？（任务分解决策）

  • AI 给出的多个方案中，哪个在长期维护性上更优？（价值判断决策）

  • 如果 AI 的答案与我的直觉冲突，我应该信任谁？（元认知决策）

这些决策无法被自动化，因为它们涉及对未知风险、团队能力、业务优先级等多维度的权衡。

学习机制：逆向思维训练

Hanselman 在自己的博客和播客中多次提到一种训练方法：强制在没有 AI 的情况下完成一个复杂任务，然后对比 AI 的方案。这种“逆向对比”能够暴露出 AI 的隐性假设和遗漏的边界条件。

例如，手动实现一次 ZoomIt 的全景拼接，即使效率很低，也能让你理解拼接错位的根本原因。之后再使用 AI 辅助，你就具备了“它哪里可能出错”的直觉。这种 先手动、后对比 的学习闭环，可能是未来工程师训练判断力的基本单元。

结论三：初级开发者必须被保护 —— 一场关乎行业未来的伦理抉择

伦理维度的思考

这是整个演讲中最令人不安，也最需要深入讨论的部分。

自 2022 年以来，入门级开发者职位的招聘数量下降了 67%。
在 AI 暴露率高的职业中，22-25 岁年轻人的就业率在 GPT-4 发布后下降了约 13%。
MIT 研究：将写作外包给 ChatGPT 的成年人，信息回忆能力明显下降，形成“认知负债”。

这些数据指向一个残酷的现状：企业正在用 AI 替代初级开发者的工作，而不是用 AI 来辅助他们成长。

从 功利主义伦理 角度看，这似乎是高效的——资深开发者 + AI 就能完成原先需要一整个团队的工作。但从 义务论伦理 角度看，行业存在 培养下一代工程师的道德义务。如果所有人都只“收割”而不“播种”，那么十年后，当资深开发者退休或转行，谁来接替？

Russinovich 和 Hanselman 在 ACM 论文中明确写道：

“我们必须继续雇佣初级开发者，接受他们一开始会降低团队生产效率的事实，并系统性地设计让他们的成长成为组织的明确目标。”

这不是一句口号，而是一个需要制度设计的伦理承诺。

决策逻辑：短期效率 vs 长期生存的博弈

企业面临的决策困境是：短期财务指标（本季度交付速度）vs 长期人才储备（5-10 年后还能否招到合格的资深工程师）。

演讲实际上给出了一个可行的决策框架：

  • 允许效率折损：明确将“培养初级开发者”列入团队的 OKR 或绩效指标，而非用纯代码产出衡量。

  • 结构化指导：将 AI 作为初级开发者的“陪练”，而非“替代者”。例如，让初级开发者先手动思考解决方案，再用 AI 生成对比，最后由导师复盘差异。

  • 错误预算：为初级开发者设定“允许犯错”的预算，包括代码缺陷、设计缺陷，只要能从中学到东西。

这种决策本质上是在为行业的 反脆弱性 投资——今天的效率牺牲，是为了避免未来的系统性崩溃。

学习机制：如何设计“安全失败”的成长路径

Preceptor 模型在这里再次适用，但这次不是训练 AI，而是训练人。

具体到工程教育（无论是大学还是企业内部培训），可以设计：

  • 受控的复杂度阶梯：初级开发者先处理明确定义、有完备测试的问题，再逐步过渡到模糊需求。

  • 强制的手动阶段：在引入 AI 辅助之前，必须有一次“无 AI 的初版尝试”。

  • 复盘仪式：每次 AI 辅助完成任务后，必须列出“AI 做得好的地方”和“AI 遗漏的地方”，并由导师点评。

这种学习机制的本质是：用失败来训练判断力，用判断力来监督 AI，用 AI 来放大判断力——形成一个正向循环。而初级开发者就是这个循环的起点。

结语：AI 不会写诗，但会写代码；而我们需要的是会写诗的工程师

Scott 和 Mark 在演讲最后没有给出一个煽情的结尾。他们只是说：“我们仍然需要学习、批判与指导。”

这句话今天听起来像是一句常识，但在 AI 能生成整个 Pull Request 的 2026 年，它已经变成了一种需要主动捍卫的立场。

捍卫的方法不是抵制 AI，而是：

  • 理解哪些判断只能由人类做出（伦理边界），

  • 设计让人类判断力持续成长的流程（学习机制），

  • 做出“为未来投资”的短期牺牲（决策勇气）。

这就是我从 BRK247 中带走的三样东西。希望对你也有用。

相关链接

（本文基于 Microsoft Build 2026 BRK247 公开内容及作者个人思考撰写，观点不代表微软官方立场。）