Claude Code 动态工作流与 GitHub Copilot 桌面应用发布 · AI HOT
ginobefun @hongming731 70
2026-06-03 07:08 ·30天前
AI 摘要 Anthropic 为 Claude Code 推出动态工作流，允许模型为每个任务自主生成 JavaScript 编排脚本，动态选择模型并启动多个子智能体在独立环境中并行执行，以解决单一上下文窗口处理复杂任务的限制。同时，GitHub 在 Microsoft Build 上发布了以智能体为核心的 Copilot 桌面应用，提供统一视图、协作面板和自动化流程，旨在管理并行 Agent 开发。文章披露，GitHub 平台每月提交量已突破 14 亿次。
ginobefun @hongming731 · X 2026-06-03 07:08 · 30天前
在 X 看原推 · x.com AI 摘要 Anthropic 为 Claude Code 推出动态工作流，允许模型为每个任务自主生成 JavaScript 编排脚本，动态选择模型并启动多个子智能体在独立环境中并行执行，以解决单一上下文窗口处理复杂任务的限制。同时，GitHub 在 Microsoft Build 上发布了以智能体为核心的 Copilot 桌面应用，提供统一视图、协作面板和自动化流程，旨在管理并行 Agent 开发。文章披露，GitHub 平台每月提交量已突破 14 亿次。
如果工作流被用户中断（比如关掉了终端），恢复会话后工作流可以从中断点继续，不需要从头再来。
Anthropic 在文章里明确列出了动态工作流针对的几类失败场景：
长任务的上下文污染：单一窗口处理长任务时，早期的规划信息和后期的执行信息混在一起，Claude 开始迷失方向。 大规模并行任务：比如同时处理 80 份简历评级、同时从多个 Slack 频道抓取数据--这类任务天然适合多路并发，但默认 harness 无法原生支持。 高度结构化任务：比如让多个 Agent 分别扮演投资人、用户、竞争对手，从不同角度撕碎一份商业计划书。 对抗性任务：让两个子智能体互相挑战，形成一种反馈机制来提升结果质量。 文章给出的几个示例 prompt 很有启发性：「这个测试大约每 50 次运行就会失败一次，用工作流来复现它，提出竞争性假设，不到找到能存活于证据的那个假设不要停」；「拿我最近 50 个会话挖出我反复在纠正的错误，把那些反复出现的写进 CLAUDE.md 规则」。这两个例子都展示了动态工作流的典型场景：需要反复迭代、需要并行比较、或者需要结构化协作的复杂多步任务。
Anthropic 总结了 Claude 在构建工作流时会组合使用的几种基本模式：
分类执行（Classify-and-act）：先用一个 Agent 对输入进行分类，再把不同类别的任务分配给专门的下游 Agent。 排序（Sorting）：把大批量列表（比如 1000 条支持工单）按定性标准排序--单次 prompt 质量会随列表变大而退化，工作流可以分批处理再汇总。 竞争性验证（Adversarial check）：让一个 Agent 生成，另一个 Agent 专门找漏洞，循环直到结论站得住脚。 动态工作流会消耗更多 token，不适合日常简单任务。最适合的场景是：任务足够复杂（单一上下文处理时质量会退化）、任务足够高价值（额外的 token 成本值得付出）、任务有结构化并行需求（多个角度、多个数据源、多个竞争性假设）。触发方式是在 prompt 里使用关键词 ultracode，或者明确要求「用工作流来完成这件事」。Anthropic 提醒，最佳实践仍在演进，建议首次使用时从相对简单的并行任务开始积累直觉，再逐步应用到更复杂的高价值场景。动态工作流与默认 harness 完全兼容，不需要时可以无缝回退，无需额外配置。
对于正在用 Claude Code 处理复杂多步骤任务的工程师，这篇官方介绍值得仔细阅读：查看原文
精讲二：GitHub Copilot 应用：以智能体为核心的桌面体验 当 Agent 变成开发工作流的常态，管理多个并行 Agent 本身就成了一个新问题。你早上打开电脑，三件工作已经在推进中：一个 Agent 在排查生产 bug，一个 Agent 在实现积压需求，第三个 Agent 在处理代码审查反馈。你需要一个地方能同时看到这三个进度，能介入、能重定向、能测试、能合并。原有的开发工具并不是为这种工作方式设计的。
在 Microsoft Build 2026 上，GitHub 发布了 Copilot 桌面应用，正是要填补这个空缺。
Copilot 桌面应用的核心入口是 My Work 视图。这个视图汇聚了所有关联仓库里当前进行中的工作：活跃的 Agent 会话、Issue、PR、后台自动化任务。开发者不再需要在多个标签页之间切换来追踪不同 Agent 的状态，一个视图看全局。
每一个 Agent 会话都在独立的 git worktree 环境里运行。这与 Claude Code 动态工作流的设计理念高度一致：隔离是并行 Agent 开发的基础--不同 Agent 的工作状态不会互相污染，合并时也有清晰的边界。
Canvas 是一个可视化的双向协作区域。Agent 工作时，你可以在 Canvas 里实时看到它的工作进度，也可以在任何节点插入反馈、调整方向。这种「异步介入」的交互模式与传统的「等待 Agent 完成再审查」不同，更像是一个真实存在的协作伙伴，只是它在你后台异步跑，你随时可以看进度并给意见。
Agent Merge：全程自动化 CI 和代码审查
Agent Merge 功能负责管理从 Agent 提交代码到合并的整个流程，包括触发 CI 检查、处理代码审查反馈、最终完成合并。开发者的精力可以更多集中在方向判断和质量审核，而不是流程管理。
与此同时，GitHub 还扩展了 Copilot 代码审查的能力：开发者现在可以通过自定义 Agent skills、MCP 服务器连接和可配置的 Actions 工作流，让每次代码审查都反映自己团队的标准、内部系统和工程上下文。代码审查还新增了「中等层级审查」（medium tier review）选项，在快速审查和深度审查之间提供了更细粒度的控制。
GitHub 在发布中披露了一组数据：当前平台的每月提交量已经突破 14 亿次，同比近乎翻倍；GitHub Actions 每周运行时间超过 20 亿分钟。这个增速直接说明了为什么 GitHub 要在这个时间点推出 Agent 原生的控制中心--现有工具的设计假设已经跟不上实际工作流的演进节奏。
对于正在将多个 Copilot Agent 整合进开发工作流的团队，这篇发布文章是了解 GitHub Agent 原生方向的第一手资料。Copilot 桌面应用目前已向现有 Copilot Pro、Pro+、Business 和 Enterprise 用户开放技术预览，感兴趣的团队可以直接申请加入：查看原文
精讲三：AI 软件工程范式革命的思考 这篇来自腾讯云开发者的长文，是近期读到的关于 AI 与软件工程关系最系统、最有历史纵深的一篇思考。作者不是在讨论某个工具或某个技巧，而是从工程史的视角，对软件工程过去五十年的本质做出了一次重新定性。
作者从控制论的视角，梳理了经典工程门类的成功路径：机械、化工、电力、自动化，这些领域都靠同一个范式完成了工程化--「消耗能源，把人脑参与的低阶认知回路固化成物理装置」。蒸汽机的离心调速器、化工厂的恒温器、电网的调度装置，本质上都是同一件事：让原本需要人来盯着、调整、判断的事情，由一台烧煤或通电的设备自己完成。不确定性被大规模消除，同样的输入产出稳定可预期的结果。
软件工程卡在了这条路上。软件开发要处理的是抽象、分解、推理、创造--这些是高阶认知，没法像调速器那样固化成物理回路。五十年来，敏捷、Scrum、DevOps 解决的都是同一个问题，用的是同一种方式：优化堆人力的方式，但没有改变「必须靠人力堆」这个事实。
这就是作者对「软件工程是最不彻底的工程」的定义：它在工程的形而上学层面是个残缺品--所有兄弟门类都完成了「能源替代低阶智能」这个动作，唯独软件没有。
大语言模型做到了经典工程从来没做到的事：输入算力，输出能理解需求、生成代码、做逻辑推理的高阶认知产物。
经典工程：能源 → 低阶智能（机械调节、自动控制） 大模型：能源 → 高阶智能（理解、推理、生成、决策） 作者的判断是：大模型和蒸汽机的工程史地位是平行的。蒸汽机让「做功」第一次能源化，大模型让「认知」第一次能源化。软件工程「真正降临」的时刻，不是 Scrum 流行的时候，不是 DevOps 普及的时候，而是大模型让「能源换高阶智能」成为可能的这个时刻。在此之前所有的「软件工程」，严格说都是软件作坊的优化版。
大模型带来了新的不确定性：幻觉（输出看起来合理，悄悄就错了）、漂移（同样的输入，今天和明天给出不一样的结果）、不可解释（没法看进它的决策过程）。
这意味着大模型并没有消除不确定性，只是把「人的不确定性」换成了「模型的不确定性」。真正需要的是一整套新的工程原则--不再是「亲手消除每个微小的偏差」，而是「设计一个能自我纠偏的系统，并处理系统自己纠不回来的剩余偏差」。
作者引入了冯·福斯特 1970 年代提出的二阶控制论：一阶控制论是「观察并控制被控对象」，二阶控制论是「观察并控制『观察并控制』这件事本身」。投射到 AI 软件工程：
作者用一组跨越 150 年的数据指出：自动化越彻底，工业相关人口反而越多。1850 年代蒸汽机普及后，制造业整体爆炸式增长；1950 年代自动化后，工程师、设计师、工艺员数量暴增。每一次系统能力扩张，都会暴露出新的边界，而边界就是新的「偏差地带」，需要新一波人守在那里。
结论：人不是被淘汰，而是迁移。边界在扩大，需要守的人反而更多了。但能在这种边界上工作的人会越来越少，因为形式化吃掉的都是低阶认知，剩下的都是越来越高阶的部分。
这篇文章与精讲一、精讲二形成了很好的理论基础互补。Claude Code 动态工作流和 GitHub Copilot 桌面应用，都是「设计能自我纠偏的 AI 系统」这个新工程原则在工具层的具体体现--worktree 隔离、子智能体协作、Canvas 双向介入，都在解决「如何设计系统来处理 AI 自身的不确定性」这个核心问题。
作者给出了一个相对乐观但也相当严峻的判断：AI 时代，人的统一职能是「处理系统暂时还无法处理的偏差」。这条铁律在所有工程门类里都成立--机械故障靠人拉回、电网负载偏差靠人仲裁，现在是认知偏差靠人纠正。
不同的是，AI 工程里，偏差类型不再可枚举，偏差信号不再可观测，拉回手段也没有 SOP 可循。这意味着守边界的人，需要更强的判断力，而不只是更多的知识。
作者在文章末尾讨论了组织形态和落地路线，以及他认为这场变革「最难的那道坎」在哪里，这部分值得有 AI 落地任务的工程师和技术管理者仔细阅读：查看原文
速览 任务保真度缩放定律：为什么数据质量决定 Agent 性能（AI Engineer） Snorkel 的实验证明：在相同算力和任务数量下，仅改变训练数据质量，高保真任务带来 6% 的性能提升，低质量任务只有 1%，差距高达 5 倍。高质量任务须满足四项标准：容器化（隔离干净的回滚和并行化）、可达性（目标非平凡但可实现）、功能正确性（逻辑可预期）、环境稳定性（执行基础设施稳定）。满足这四项才能产生干净的失败信号，让模型在 RL 训练中有效爬坡。低质量任务的常见缺陷是「退化失败态」：环境本身就不稳定，模型无法从失败中提取有意义的学习信号，额外的计算预算全部浪费在噪声上。对正在做 Agent 微调数据集的工程师，这组数据有直接的策略指导价值。查看原文
打造 AI 原生工程组织 | Claude（Claude Blog） Claude Code 团队分享了他们如何重新设计工程流程以适应 AI 原生工作方式。代码生成、测试编写和重构已经不再是瓶颈，真正的瓶颈变成了验证、代码审查和安全评估。他们重写了规划方式（从长期路线图改为即时制订）、代码审查流程、上下文收集方式，以及团队的构成逻辑。这不是工具使用指南，而是一个已经完全转型的工程组织对「如何重新设计流程」的第一手记录，适合正在思考 AI 原生团队转型的工程 Leader 阅读。查看原文
MiniMax M3：首个融合三大前沿能力的开源权重模型（MiniMax 官方） MiniMax 正式发布 M3，声称是首个同时融合三大前沿能力的开源权重模型：编码与智能体性能（SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%）、由 MiniMax 稀疏注意力（MSA）实现的 100 万 token 上下文窗口、从零构建的原生多模态能力。同期推出 MiniMax Code 产品和新的 token 计划。权重和技术报告将在约 10 天内发布。值得注意的是，M3 是国内团队在开源大模型赛道上迄今为止对标 GPT 4o 级编码能力的最完整尝试之一，对关注开源模型生态的开发者值得持续跟进。查看原文
NVIDIA 推出 Cosmos 3：用于物理 AI 的完全开放全能模型（NVIDIA AI） NVIDIA 发布 Cosmos 3，定位为世界上首个完全开放的、用于物理 AI 的「全能模型」（omnimodel），原生支持视觉推理、世界生成和动作生成三种能力。本次发布了两个版本：Super（32B）和 Nano（8B），面向机器人和自主系统领域。结合精讲三和速览第五条的机器人供应链分析，物理 AI 的基础模型层正在加速成熟。查看原文
拆解机器人「肉身」、量产与供应链：空翻之后，它还要学会接住一片落叶（硅谷 101） 硅谷 101 深度拆解人形机器人的硬件架构：骨架材料（从钢材到铝合金、镁合金、钛合金的演进与轻量化权衡）、关节执行器（从液压到电机转变的背后技术进步）、传感器体系、电气与计算系统，以及整条供应链的成本结构与量产门槛。文章还引用了智元、宇树等头部企业一线负责人的具体判断。宇树科技科创板 IPO 刚刚通过上交所审议，这篇系统性拆解正当其时，适合想深入了解机器人硬件护城河的读者。查看原文
深度解析 Agent 存算分离架构设计（idoubi） 作者以 FastClaw 为例，系统拆解云端 Agent 的存算分离架构：三种运行模式（本地裸机、本地带沙盒、云端多副本）的优缺点对比，存储层的四种方案（热状态用 Redis、对话记录用 Postgres、长期记忆用 pgvector/Milvus、工作产物用 S3/OSS），以及基于存算分离架构的完整运行流程，同时指出了分布式数据一致性的挑战。对比今日精讲一中 Claude Code 动态工作流的 worktree 隔离机制，两篇在「计算与状态分离」这个方向上有一定共鸣，对正在设计云端 Agent 基础设施的工程师有直接参考价值。查看原文
用数据说话：贴吧 AI CR（小码哥）落地 10 周，bug 密度下降 66.87%（百度 Geek 说） 贴吧 Server 团队的 AI Code Review 落地实践：通过规则定制、自动化评测和三层反馈闭环（高/中/低优先级评论处理流程），将 AI CR 评审占比从 33% 提升至 84%，bug 密度从 0.332 降至 0.11，降幅 66.87%。文章完整记录了 10 周的推进节奏、踩坑经验和方法论，代码库多、提交频率高、人工评审质量参差的团队可直接参考迁移。这份实践与精讲三的理论框架形成印证--AI CR 本身就是一个能自我纠偏的代码质量系统。查看原文
今日阅读路径 为每项任务量身打造：Claude Code 中的动态工作流（精讲一）- 如果你在用 Claude Code，这是今天最直接有用的一篇，10 分钟读完，了解动态工作流的工作原理和触发方式，以及哪类任务最值得启用。 AI 软件工程范式革命的思考（精讲三）- 今天内容最有长期价值的一篇。控制论框架下的软件工程史重构，以及「设计能自我纠偏的 AI 系统」这个新工程师身份定位，是理解当前所有 AI 工具演进方向的底层框架。 GitHub Copilot 应用：以智能体为核心的桌面体验（精讲二）- 并行 Agent 开发控制中心的完整介绍，了解 GitHub 在 Agent 原生方向的系统性布局，以及 worktree 隔离、Canvas 协作、Agent Merge 这几个核心机制的实际用法。 还有时间？ 推荐任务保真度缩放定律（做 Agent 微调数据集的工程师必读，5 倍质量差距有直接策略价值）和机器人供应链深度拆解（宇树 IPO 时机下的硬件架构系统梳理，适合关注具身智能落地的读者）。
与此同时，GitHub 在 Microsoft Build 上发布了 Copilot 桌面应用--一个为并行 Agent 开发打造的统一控制中心。My Work 视图让你同时监管多条进行中的 Issue 和 PR，Canvas 面板实时显示 Agent 的工作进度，Agent Merge 全程处理 CI 和代码审查。在所有这些工具铺开的背景下，GitHub 的每月提交量已经突破 14 亿次，同比翻倍。
本期精讲之外还有 7 篇速览，覆盖任务保真度缩放定律、AI 原生工程组织打造、MiniMax M3 开源模型、NVIDIA Cosmos 3、机器人供应链深度拆解、Agent 存算分离架构，以及贴吧 AI CR 落地 10 周后 bug 密度下降 66.87% 的完整实践。
精讲一：Anthropic 详解 Claude Code 动态工作流的工作原理与最佳实践 精讲二：GitHub 在 Microsoft Build 上推出以智能体为核心的 Copilot 桌面应用 精讲三：腾讯云工程师以控制论框架重新审视软件工程五十年与 AI 范式革命
精讲一：为每项任务量身打造：Claude Code 中的动态工作流 | Claude Claude Code 面向的任务场景越来越复杂，但默认 harness 有一个固有限制：规划和执行必须在同一个上下文窗口里完成。随着任务变长、结构变复杂，这个窗口会越来越拥挤，开始出现「智能体懒惰」--Claude 开始抄近路；「目标漂移」--Claude 偏离了最初的任务目标。上周，Anthropic 发布了动态工作流（Dynamic Workflows），为这个问题提供了根本性的解法。
动态工作流的核心是让 Claude 自己写一个 JavaScript 编排脚本，然后执行这个脚本来完成任务。这个脚本可以使用几个特殊函数来生成和协调子智能体（subagents），同时也可以调用标准的 JavaScript 工具：JSON、Math、Array 等。
与静态工作流的关键区别在于两点。首先，动态工作流可以自主决定给每个子智能体使用哪个模型--这意味着 Claude 会把复杂的推理任务分配给更强的模型，把简单的信息采集交给更快的模型，在成本与质量之间动态权衡。其次，子智能体可以在独立的 worktree 里运行，实现真正的环境隔离，避免多个子任务互相污染工作状态。
如果工作流被用户中断（比如关掉了终端），恢复会话后工作流可以从中断点继续，不需要从头再来。
Anthropic 在文章里明确列出了动态工作流针对的几类失败场景：
长任务的上下文污染：单一窗口处理长任务时，早期的规划信息和后期的执行信息混在一起，Claude 开始迷失方向。 大规模并行任务：比如同时处理 80 份简历评级、同时从多个 Slack 频道抓取数据--这类任务天然适合多路并发，但默认 harness 无法原生支持。 高度结构化任务：比如让多个 Agent 分别扮演投资人、用户、竞争对手，从不同角度撕碎一份商业计划书。 对抗性任务：让两个子智能体互相挑战，形成一种反馈机制来提升结果质量。 文章给出的几个示例 prompt 很有启发性：「这个测试大约每 50 次运行就会失败一次，用工作流来复现它，提出竞争性假设，不到找到能存活于证据的那个假设不要停」；「拿我最近 50 个会话挖出我反复在纠正的错误，把那些反复出现的写进 CLAUDE.md 规则」。这两个例子都展示了动态工作流的典型场景：需要反复迭代、需要并行比较、或者需要结构化协作的复杂多步任务。
Anthropic 总结了 Claude 在构建工作流时会组合使用的几种基本模式：
分类执行（Classify-and-act）：先用一个 Agent 对输入进行分类，再把不同类别的任务分配给专门的下游 Agent。 排序（Sorting）：把大批量列表（比如 1000 条支持工单）按定性标准排序--单次 prompt 质量会随列表变大而退化，工作流可以分批处理再汇总。 竞争性验证（Adversarial check）：让一个 Agent 生成，另一个 Agent 专门找漏洞，循环直到结论站得住脚。 动态工作流会消耗更多 token，不适合日常简单任务。最适合的场景是：任务足够复杂（单一上下文处理时质量会退化）、任务足够高价值（额外的 token 成本值得付出）、任务有结构化并行需求（多个角度、多个数据源、多个竞争性假设）。触发方式是在 prompt 里使用关键词 ultracode，或者明确要求「用工作流来完成这件事」。Anthropic 提醒，最佳实践仍在演进，建议首次使用时从相对简单的并行任务开始积累直觉，再逐步应用到更复杂的高价值场景。动态工作流与默认 harness 完全兼容，不需要时可以无缝回退，无需额外配置。
对于正在用 Claude Code 处理复杂多步骤任务的工程师，这篇官方介绍值得仔细阅读：查看原文
精讲二：GitHub Copilot 应用：以智能体为核心的桌面体验 当 Agent 变成开发工作流的常态，管理多个并行 Agent 本身就成了一个新问题。你早上打开电脑，三件工作已经在推进中：一个 Agent 在排查生产 bug，一个 Agent 在实现积压需求，第三个 Agent 在处理代码审查反馈。你需要一个地方能同时看到这三个进度，能介入、能重定向、能测试、能合并。原有的开发工具并不是为这种工作方式设计的。
在 Microsoft Build 2026 上，GitHub 发布了 Copilot 桌面应用，正是要填补这个空缺。
Copilot 桌面应用的核心入口是 My Work 视图。这个视图汇聚了所有关联仓库里当前进行中的工作：活跃的 Agent 会话、Issue、PR、后台自动化任务。开发者不再需要在多个标签页之间切换来追踪不同 Agent 的状态，一个视图看全局。
每一个 Agent 会话都在独立的 git worktree 环境里运行。这与 Claude Code 动态工作流的设计理念高度一致：隔离是并行 Agent 开发的基础--不同 Agent 的工作状态不会互相污染，合并时也有清晰的边界。
Canvas 是一个可视化的双向协作区域。Agent 工作时，你可以在 Canvas 里实时看到它的工作进度，也可以在任何节点插入反馈、调整方向。这种「异步介入」的交互模式与传统的「等待 Agent 完成再审查」不同，更像是一个真实存在的协作伙伴，只是它在你后台异步跑，你随时可以看进度并给意见。
Agent Merge：全程自动化 CI 和代码审查
Agent Merge 功能负责管理从 Agent 提交代码到合并的整个流程，包括触发 CI 检查、处理代码审查反馈、最终完成合并。开发者的精力可以更多集中在方向判断和质量审核，而不是流程管理。
与此同时，GitHub 还扩展了 Copilot 代码审查的能力：开发者现在可以通过自定义 Agent skills、MCP 服务器连接和可配置的 Actions 工作流，让每次代码审查都反映自己团队的标准、内部系统和工程上下文。代码审查还新增了「中等层级审查」（medium tier review）选项，在快速审查和深度审查之间提供了更细粒度的控制。
GitHub 在发布中披露了一组数据：当前平台的每月提交量已经突破 14 亿次，同比近乎翻倍；GitHub Actions 每周运行时间超过 20 亿分钟。这个增速直接说明了为什么 GitHub 要在这个时间点推出 Agent 原生的控制中心--现有工具的设计假设已经跟不上实际工作流的演进节奏。
对于正在将多个 Copilot Agent 整合进开发工作流的团队，这篇发布文章是了解 GitHub Agent 原生方向的第一手资料。Copilot 桌面应用目前已向现有 Copilot Pro、Pro+、Business 和 Enterprise 用户开放技术预览，感兴趣的团队可以直接申请加入：查看原文
精讲三：AI 软件工程范式革命的思考 这篇来自腾讯云开发者的长文，是近期读到的关于 AI 与软件工程关系最系统、最有历史纵深的一篇思考。作者不是在讨论某个工具或某个技巧，而是从工程史的视角，对软件工程过去五十年的本质做出了一次重新定性。
作者从控制论的视角，梳理了经典工程门类的成功路径：机械、化工、电力、自动化，这些领域都靠同一个范式完成了工程化--「消耗能源，把人脑参与的低阶认知回路固化成物理装置」。蒸汽机的离心调速器、化工厂的恒温器、电网的调度装置，本质上都是同一件事：让原本需要人来盯着、调整、判断的事情，由一台烧煤或通电的设备自己完成。不确定性被大规模消除，同样的输入产出稳定可预期的结果。
软件工程卡在了这条路上。软件开发要处理的是抽象、分解、推理、创造--这些是高阶认知，没法像调速器那样固化成物理回路。五十年来，敏捷、Scrum、DevOps 解决的都是同一个问题，用的是同一种方式：优化堆人力的方式，但没有改变「必须靠人力堆」这个事实。
这就是作者对「软件工程是最不彻底的工程」的定义：它在工程的形而上学层面是个残缺品--所有兄弟门类都完成了「能源替代低阶智能」这个动作，唯独软件没有。
大语言模型做到了经典工程从来没做到的事：输入算力，输出能理解需求、生成代码、做逻辑推理的高阶认知产物。
经典工程：能源 → 低阶智能（机械调节、自动控制） 大模型：能源 → 高阶智能（理解、推理、生成、决策） 作者的判断是：大模型和蒸汽机的工程史地位是平行的。蒸汽机让「做功」第一次能源化，大模型让「认知」第一次能源化。软件工程「真正降临」的时刻，不是 Scrum 流行的时候，不是 DevOps 普及的时候，而是大模型让「能源换高阶智能」成为可能的这个时刻。在此之前所有的「软件工程」，严格说都是软件作坊的优化版。
大模型带来了新的不确定性：幻觉（输出看起来合理，悄悄就错了）、漂移（同样的输入，今天和明天给出不一样的结果）、不可解释（没法看进它的决策过程）。
这意味着大模型并没有消除不确定性，只是把「人的不确定性」换成了「模型的不确定性」。真正需要的是一整套新的工程原则--不再是「亲手消除每个微小的偏差」，而是「设计一个能自我纠偏的系统，并处理系统自己纠不回来的剩余偏差」。
作者引入了冯·福斯特 1970 年代提出的二阶控制论：一阶控制论是「观察并控制被控对象」，二阶控制论是「观察并控制『观察并控制』这件事本身」。投射到 AI 软件工程：
作者用一组跨越 150 年的数据指出：自动化越彻底，工业相关人口反而越多。1850 年代蒸汽机普及后，制造业整体爆炸式增长；1950 年代自动化后，工程师、设计师、工艺员数量暴增。每一次系统能力扩张，都会暴露出新的边界，而边界就是新的「偏差地带」，需要新一波人守在那里。
结论：人不是被淘汰，而是迁移。边界在扩大，需要守的人反而更多了。但能在这种边界上工作的人会越来越少，因为形式化吃掉的都是低阶认知，剩下的都是越来越高阶的部分。
这篇文章与精讲一、精讲二形成了很好的理论基础互补。Claude Code 动态工作流和 GitHub Copilot 桌面应用，都是「设计能自我纠偏的 AI 系统」这个新工程原则在工具层的具体体现--worktree 隔离、子智能体协作、Canvas 双向介入，都在解决「如何设计系统来处理 AI 自身的不确定性」这个核心问题。
作者给出了一个相对乐观但也相当严峻的判断：AI 时代，人的统一职能是「处理系统暂时还无法处理的偏差」。这条铁律在所有工程门类里都成立--机械故障靠人拉回、电网负载偏差靠人仲裁，现在是认知偏差靠人纠正。
不同的是，AI 工程里，偏差类型不再可枚举，偏差信号不再可观测，拉回手段也没有 SOP 可循。这意味着守边界的人，需要更强的判断力，而不只是更多的知识。
作者在文章末尾讨论了组织形态和落地路线，以及他认为这场变革「最难的那道坎」在哪里，这部分值得有 AI 落地任务的工程师和技术管理者仔细阅读：查看原文
速览 任务保真度缩放定律：为什么数据质量决定 Agent 性能（AI Engineer） Snorkel 的实验证明：在相同算力和任务数量下，仅改变训练数据质量，高保真任务带来 6% 的性能提升，低质量任务只有 1%，差距高达 5 倍。高质量任务须满足四项标准：容器化（隔离干净的回滚和并行化）、可达性（目标非平凡但可实现）、功能正确性（逻辑可预期）、环境稳定性（执行基础设施稳定）。满足这四项才能产生干净的失败信号，让模型在 RL 训练中有效爬坡。低质量任务的常见缺陷是「退化失败态」：环境本身就不稳定，模型无法从失败中提取有意义的学习信号，额外的计算预算全部浪费在噪声上。对正在做 Agent 微调数据集的工程师，这组数据有直接的策略指导价值。查看原文
打造 AI 原生工程组织 | Claude（Claude Blog） Claude Code 团队分享了他们如何重新设计工程流程以适应 AI 原生工作方式。代码生成、测试编写和重构已经不再是瓶颈，真正的瓶颈变成了验证、代码审查和安全评估。他们重写了规划方式（从长期路线图改为即时制订）、代码审查流程、上下文收集方式，以及团队的构成逻辑。这不是工具使用指南，而是一个已经完全转型的工程组织对「如何重新设计流程」的第一手记录，适合正在思考 AI 原生团队转型的工程 Leader 阅读。查看原文
MiniMax M3：首个融合三大前沿能力的开源权重模型（MiniMax 官方） MiniMax 正式发布 M3，声称是首个同时融合三大前沿能力的开源权重模型：编码与智能体性能（SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%）、由 MiniMax 稀疏注意力（MSA）实现的 100 万 token 上下文窗口、从零构建的原生多模态能力。同期推出 MiniMax Code 产品和新的 token 计划。权重和技术报告将在约 10 天内发布。值得注意的是，M3 是国内团队在开源大模型赛道上迄今为止对标 GPT 4o 级编码能力的最完整尝试之一，对关注开源模型生态的开发者值得持续跟进。查看原文
NVIDIA 推出 Cosmos 3：用于物理 AI 的完全开放全能模型（NVIDIA AI） NVIDIA 发布 Cosmos 3，定位为世界上首个完全开放的、用于物理 AI 的「全能模型」（omnimodel），原生支持视觉推理、世界生成和动作生成三种能力。本次发布了两个版本：Super（32B）和 Nano（8B），面向机器人和自主系统领域。结合精讲三和速览第五条的机器人供应链分析，物理 AI 的基础模型层正在加速成熟。查看原文
拆解机器人「肉身」、量产与供应链：空翻之后，它还要学会接住一片落叶（硅谷 101） 硅谷 101 深度拆解人形机器人的硬件架构：骨架材料（从钢材到铝合金、镁合金、钛合金的演进与轻量化权衡）、关节执行器（从液压到电机转变的背后技术进步）、传感器体系、电气与计算系统，以及整条供应链的成本结构与量产门槛。文章还引用了智元、宇树等头部企业一线负责人的具体判断。宇树科技科创板 IPO 刚刚通过上交所审议，这篇系统性拆解正当其时，适合想深入了解机器人硬件护城河的读者。查看原文
深度解析 Agent 存算分离架构设计（idoubi） 作者以 FastClaw 为例，系统拆解云端 Agent 的存算分离架构：三种运行模式（本地裸机、本地带沙盒、云端多副本）的优缺点对比，存储层的四种方案（热状态用 Redis、对话记录用 Postgres、长期记忆用 pgvector/Milvus、工作产物用 S3/OSS），以及基于存算分离架构的完整运行流程，同时指出了分布式数据一致性的挑战。对比今日精讲一中 Claude Code 动态工作流的 worktree 隔离机制，两篇在「计算与状态分离」这个方向上有一定共鸣，对正在设计云端 Agent 基础设施的工程师有直接参考价值。查看原文
用数据说话：贴吧 AI CR（小码哥）落地 10 周，bug 密度下降 66.87%（百度 Geek 说） 贴吧 Server 团队的 AI Code Review 落地实践：通过规则定制、自动化评测和三层反馈闭环（高/中/低优先级评论处理流程），将 AI CR 评审占比从 33% 提升至 84%，bug 密度从 0.332 降至 0.11，降幅 66.87%。文章完整记录了 10 周的推进节奏、踩坑经验和方法论，代码库多、提交频率高、人工评审质量参差的团队可直接参考迁移。这份实践与精讲三的理论框架形成印证--AI CR 本身就是一个能自我纠偏的代码质量系统。查看原文
今日阅读路径 为每项任务量身打造：Claude Code 中的动态工作流（精讲一）- 如果你在用 Claude Code，这是今天最直接有用的一篇，10 分钟读完，了解动态工作流的工作原理和触发方式，以及哪类任务最值得启用。 AI 软件工程范式革命的思考（精讲三）- 今天内容最有长期价值的一篇。控制论框架下的软件工程史重构，以及「设计能自我纠偏的 AI 系统」这个新工程师身份定位，是理解当前所有 AI 工具演进方向的底层框架。 GitHub Copilot 应用：以智能体为核心的桌面体验（精讲二）- 并行 Agent 开发控制中心的完整介绍，了解 GitHub 在 Agent 原生方向的系统性布局，以及 worktree 隔离、Canvas 协作、Agent Merge 这几个核心机制的实际用法。 还有时间？ 推荐任务保真度缩放定律（做 Agent 微调数据集的工程师必读，5 倍质量差距有直接策略价值）和机器人供应链深度拆解（宇树 IPO 时机下的硬件架构系统梳理，适合关注具身智能落地的读者）。
ginobefun@hongming731 · X