2026-02-11 12:55:42
本文永久链接 – https://tonybai.com/2026/02/11/2026-software-development-anthropic-agentic-coding-trends-report
大家好，我是Tony Bai。
时间来到 2026 年初。回顾过去的一年，软件工程领域发生的变化比过去十年加起来还要多。
如果说 2024-2025 年是 AI Coding（AI 编程） 的“试水期”，开发者们还在为 Cursor 的 Tab 补全感到兴奋，或者为 Claude 3.5 能够写出一个贪吃蛇游戏而惊叹；那么 2026 年，正如 Anthropic 最新发布的重磅报告《2026 Agentic Coding Trends Report》所言，我们正式进入了 Agentic Coding（智能体编程） 的深水区。
这份报告更像是一份“新时代软件工程的生存指南”。它揭示了一个核心事实：AI 已经从一个被动的“Copilot（副驾驶）”，进化为一个主动的“Collaborator（协作者）”，甚至是一个独立的“Team（团队）”。
在这个新时代，软件开发的瓶颈不再是“写代码”的速度，而是“定义问题”的精度和“编排智能体”的能力。作为开发者，我们必须清醒地认识到：SDLC（软件开发生命周期）正在被重写，而我们的角色也正在被重新定义。
今天，我们将深度解读这份报告中的 8 大趋势，剖析 3 大核心变革，并探讨在 2026 年，作为一名技术人，该如何拿到通往未来的船票。
Anthropic 报告的开篇就用“Tectonic Shift（地壳运动）”来形容正在发生的变化。这绝非夸张。
在计算机历史上，每一次抽象层级的提升，都带来了生产力的爆发：从机器码到汇编，从汇编到 C，从 C 到高级语言。
而在 2026 年，我们迎来了最新的抽象层：自然语言驱动的智能体编排。
报告指出，“写代码、调试、维护” 这些战术性的工作，正在全面转移给 AI。工程师的精力开始聚焦于架构设计、系统设计和战略决策。
这意味着，未来的“源码”，可能不再是 GitHub 仓库里那一堆 .ts 或 .go 文件，而是“Prompt + Spec（规规说明书） + Agent Configuration（智能体配置）”。
这是报告中一个极具冲击力的预测：“新员工入职一个复杂代码库的时间，将从数周缩短为数小时。”
还记得以前入职一家新公司，光是配置环境、阅读文档、理解那堆“屎山代码”的逻辑，就要花掉两周时间吗？
在 Agentic Coding 时代，像 Augment Code 这样的工具（报告案例），利用 Claude 对代码库的深度理解，可以让工程师在几分钟内获得对系统上下文的掌控。 此外，一位 CTO 预估需要 4-8 个月完成的项目，在 Claude Code的加持下，两周内就完成了。这是人力资源配置的革命。企业可以实现“动态激增（Surge）”式的人员调配，工程师可以随时在不同项目间无缝切换，而无需支付高昂的认知切换成本。
报告揭示了一个有趣的现象：AI 并没有取代工程师，而是让工程师变得更“全栈”了。
前端工程师开始敢于修改后端数据库，后端工程师也能轻松搞定复杂的 CSS 动画。为什么？因为 AI 填补了那部分“知识鸿沟”。
只要你具备系统思维和验收能力，具体的实现细节（Implementation Details）不再是障碍。这标志着“领域专家（Domain Expert）”与“通用工程师（Generalist）”的边界开始模糊。
如果说第一部分是“软性”的流程变化，那么第二部分则是“硬核”的技术能力升级。Anthropic 报告明确指出，2026 年的 AI 编码将呈现出集群化和长时程的特征。
2025 年，我们还在试图用一个超级 Agent 解决所有问题。2026 年，这种做法已经被淘汰。
报告预测：“多智能体系统（Multi-agent Systems）将取代单智能体工作流。”
早期的 Agent 只能处理“帮我写个函数”这种几分钟的短任务。
但报告指出，Long-running Agents（长时运行智能体） 正在成为主流。
Rakuten 的案例令人印象深刻：工程师让 Claude Code 在一个拥有 1250 万行代码的开源库（vLLM）中实现一个复杂的数学算法。Claude 独自工作了 7 个小时，最终交付了准确率为 99.9% 的代码。
这就是“无人值守开发（Unattended Development）”的雏形。
这部分是报告中最发人深省的洞察。
Anthropic 的社会影响研究团队发现了一个“协作悖论”：
尽管工程师在 60% 的工作中使用了 AI，但他们报告称，能够“完全委托（Fully Delegate）”给 AI 的任务只有 0-20%。
这意味着 Human-in-the-loop（人类在环）依然是核心。
AI 不是那种“交给他就不管了”的外包，而是一个需要你持续关注、持续反馈的“实习生”或“副驾驶”。
技术变革必然引发经济变革。报告的第三部分探讨了 Agentic Coding 对商业世界的深远影响。
传统的软件开发成本高昂，导致很多“小需求”或“长尾需求”无法被满足（ROI 算不过来）。
但 AI Agent 的出现，极大地降低了软件生产的边际成本。
这是我认为最激动人心的趋势：Agentic Coding Expands to New Surfaces and Users.
“人人都是程序员” 的口号喊了很多年，但在 2026 年，依靠 Agent，这终于变成了现实。
当然，硬币总有两面。报告特别提到了 Dual-use Risk（双重用途风险）。
这要求我们在设计 Agentic System 时，必须将安全性（Security-first Architecture） 植入到基因中。
面对这些汹涌而来的趋势，作为技术决策者或一线开发者，我们在 2026 年应该做什么？ Anthropic 给出了 4 个明确的优先事项：
掌握多智能体协作 (Master Multi-agent Coordination)：不要再沉迷于优化单个 Prompt。去学习如何使用 Gas Town 或 Claude Code 的 Agent Team 模式。学会如何让多个 Agent 像一支军队一样协同作战。这是解决复杂问题的唯一路径。
扩展人类的监督能力 (Scale Human Oversight)：构建自动化审查系统。当 AI 一天生成 1 万行代码时，靠人眼看是看不过来的。你需要构建基于 AI 的 Reviewer，以及基于严格测试（Test-Driven）的验收流水线。
赋能领域专家 (Empower Domain Experts)：不要把 AI 编程工具锁在技术部门。把它们分发给产品经理、法务、运营。让他们自己去构建解决问题的工具。
内嵌安全架构 (Embed Security Architecture)：从第一天起，就要考虑 Agent 的权限边界。不要给 Agent 无限制的 sudo 权限。构建沙箱（Sandbox）和鉴权机制。
读完这份报告，我最大的感受是：软件工程正在从一门“精确的科学”，变成一门“管理的艺术”。
在 Software 1.0 时代，我们追求的是确定性，每一行代码的执行逻辑都是可预测的。
在 Agentic Coding 时代，我们管理的是概率，是模糊性，是一群有一定自主权但偶尔会犯错的数字员工。
这并没有让软件工程变简单，反而变得更难、更深刻了。
我们不再是代码的作者（Author），我们是代码的编辑（Editor）、导演（Director）和架构师（Architect）。
2026 年，对于那些愿意拥抱变化、主动升级认知模型的开发者来说，将是最好的时代。限制你产出的，不再是手速，而是你的想象力和领导力。
资料链接：https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf
你感到的是“解放”还是“威胁”？
Anthropic 预测 2026 年新员工入职代码库的时间将坍塌为几小时。在你目前的团队中，是否已经感受到了 AI 带来的这种“入职加速”？如果有一天你主要的工作变成了“编排 Agent 集群”，你觉得最大的挑战是什么？
欢迎在评论区分享你的 2026 职业预判！
如何落地 Anthropic 的预测？
趋势看懂了，但怎么落地？
Anthropic 的报告指明了方向，而我的专栏负责提供地图和车辆。
在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深度对齐这份报告中的前沿技术：
不要做旧时代的守墓人，做新时代的领航者。扫描下方二维码，开启你的 Agentic Coding 之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-02-11 08:29:28
本文永久链接 – https://tonybai.com/2026/02/11/go-1-26-json-v2-delay-7-technical-roadblocks
大家好，我是Tony Bai。
Go 1.26 预计将于本月（2026 年 2 月）正式发布。然而，在即将到来的 release notes 的欢呼声中，有一个备受瞩目的名字依然带着“实验性”的标签躲在 GOEXPERIMENT 背后——那就是 encoding/json/v2。
作为 Go 生态中最核心的基础设施之一，JSON 库的每一次呼吸都牵动着数百万开发者的神经。从 v1 到 v2，不仅仅是性能的提升，更是一场关于API 设计哲学、向后兼容性与极致性能的艰难博弈。
很多人以为 v2 的延迟是因为“官方动作慢”或“设计理念之争”。但当我们深入 json/v2 工作组的看板，剥开表层的讨论，会发现横亘在稳定版之前的，是七个具体而微、却又关乎全局的技术“钉子”。这些问题并非宏大的路线图分歧，而是关乎浮点数精度、错误处理语义、API 封装性等实打实的工程细节。
本文将基于最新的 GitHub Issues 讨论（截至 2026 年 2 月），带你通过显微镜审视这七大阻塞问题，一窥 Go 标准库演进背后的严谨与妥协。
在当前的 encoding/json/jsontext 包中，竟然存在一个导出的 Internal 类型。这在 Go 标准库的审美中，简直是“房间里的大象”。
jsontext 是 v2 引入的底层包，专注于 JSON 的语法解析（Tokenizing），而上层的 json 包负责语义绑定（Binding）。为了让上层包能够访问底层的缓冲区或状态机，当前的实现不得不导出一个 Internal 符号。
这违背了 Go 标准库的黄金法则之一：公共 API 必须是为用户设计的，而不是为实现者自己设计的。
Joe Tsai (dsnet) 提出了一种解决方案：将 jsontext 的核心逻辑移入 encoding/json/internal/jsontext，然后通过类型别名（Type Alias）在公共包中暴露 API。然而，这带来了一个新的难题：godoc 对类型别名的支持并不友好，生成的文档可能会让用户感到困惑，因为方法都挂载在内部类型上。
这个问题已经上升为工具链生态问题。如果这个问题不解决，v2 发布后将面临两个风险：要么用户依赖了这个“临时” API 导致未来无法修改，要么标准库留下了一个永久的“伤疤”。
这是一个真实且诡异的 Bug。一位开发者在迁移旧代码时发现，以下模式在 v1 中正常工作，但在开启 GOEXPERIMENT=jsonv2 后会导致栈溢出（Stack Overflow）：
type MyType string
// 自定义 Unmarshal 方法
func (m *MyType) UnmarshalJSON(b []byte) error {
// 试图通过定义一个新类型来“剥离”当前类型的方法，以回退到默认行为
type MyTypeNoMethods *MyType
var derived MyTypeNoMethods = MyTypeNoMethods(m)
// v2 在这里会错误地再次识别出 derived 拥有 UnmarshalJSON 方法
// 从而导致无限递归调用自己
return json.Unmarshal(b, derived)
}
在 v1 中，开发者习惯通过类型转换来“剥离”自定义方法。但在 v2 中，为了修复 v1 中某些指针方法无法被调用的 Bug（如 #22967），引入了更激进的方法集查找逻辑。
v2 的逻辑是：只要这个值的地址（Addressable）能找到 UnmarshalJSON 方法，就调用它。在上面的例子中，derived 虽然是新类型，但它底层的指针指向的还是 MyType，v2 过于“聪明”地认为应该调用 (MyType).UnmarshalJSON，结果造成了死循环。
这是一个典型的“修复了一个 Bug，却引入了另一个 Bug”的案例。Go 团队目前倾向于保留 v2 的正确逻辑（即更一致的方法调用），但也必须为这种遗留代码提供一种检测机制。目前的计划是引入运行时检测或 go vet 检查，明确告知用户：请使用 type MyTypeNoMethods MyType（非指针别名）来剥离方法，而不是使用指针别名。
下面是展示该问题的一段示例代码：
var f float32 = 3.1415927 // math.Pi 的 float32 近似值
json.Marshal(f)
输出应该是 3.1415927（保持 float32 精度），还是 3.1415927410125732（提升到 float64 精度以确保无损）？
Go v1 的 json 包为了兼容性，倾向于将所有浮点数视为 float64 处理。这导致 float32 在序列化时经常会出现“精度噪音”——那些用户并不想要的、只有在 float64 精度下才有意义的尾数。
然而，v2 的 jsontext 包默认使用 64 位精度。这导致了 json.Marshal（上层）和 jsontext.Encoder（底层）在行为上的不一致。
Go 团队正在考虑引入 Float32 构造器和访问器到 jsontext 包中，并修改底层的 AppendFloat 逻辑，以支持显式的 32 位浮点数格式化。这不仅是为了“好看”，更是为了数值正确性——避免“双重舍入”（Double Rounding）带来的微小误差。
你调用 json.Marshal(v, json.WithIndent(” “)) 很爽，但如果你想控制底层的 jsontext 行为（比如“允许非法 UTF-8”或“允许重复键名”），你发现：顶层函数把路堵死了。目前的 MarshalEncode 只接受 json.Option，不接受 jsontext.Option。
v2 将 json（语义层）和 jsontext（语法层）拆分是架构的一大进步。但这也带来了配置穿透的问题。
如果为了保持 API 纯洁，强迫用户必须先创建一个 jsontext.Encoder 并在那里配置选项，再传给 json.MarshalEncode，那么 99% 的简单用例都会变得无比繁琐。
Go团队给出的提案是打破层级隔离，允许 json.Marshal 等顶层函数直接接受 jsontext.Option。这是一个实用主义战胜洁癖的胜利。
v2 曾引入了一个 unknown 结构体标签，用于指示某个字段专门用来捕获所有未知的 JSON 字段。同时，还有一个 DiscardUnknownMembers 选项用于丢弃未知字段。
dsnet（Joe Tsai）发起提案，建议删除两个功能。理由如下：
json.SkipFunc 是 v2 引入的一个 Sentinel Error，用于告诉编码器“跳过当前字段/值”。目前它只能在 MarshalToFunc（用户自定义函数）中使用。但如果我在类型的方法 MarshalJSONTo 中想跳过自己怎么办？目前是不支持的。
这是一个典型的“二等公民”问题。用户自定义的函数拥有比类型方法更高的权限。这导致在迁移旧代码时，如果要实现“条件性跳过”，必须写出非常丑陋的 hack 代码（比如定义一个空结构体来占位）。
允许 MarshalJSONTo 返回 SkipFunc 看似简单，但它要求调用者必须处理这个错误。这意味着不能直接调用 v.MarshalJSONTo，而必须通过 json.Marshal 来调用，否则你会收到一个未处理的错误。这需要文档和工具链的配合。
v2 引入了 MarshalerTo 和 UnmarshalerFrom 两个高性能接口，它们直接操作 jsontext.Encoder/Decoder，避免了内存分配。但是，到底该什么时候用它们？
目前缺乏明确的文档指导。如果用户在任何时候都直接调用 v.MarshalJSONTo(enc)，可能会绕过 json.Marshal 中处理的许多全局选项（如大小写敏感、省略零值等）。
Go 团队计划在文档中明确：这属于“高级 API”，普通用户应始终使用 json.Marshal，除非你在编写极其底层的库。
根据最新的工作组纪要和 Issue 状态，我们可以画出一条清晰的时间线：
Go 团队的“慢”，是对生态的“敬”。这七个拦路虎，每一个都是为了让未来的十年里，我们能写出更少 Bug、更快速度的 Go 代码。好事多磨，让我们静候佳音。
你更在意什么？
Go 团队为了 API 的洁癖和严谨，宁愿让 json/v2 多飞一会儿。在你的开发实践中，你更倾向于“尽快用上新特性”，还是“哪怕慢一点也要保证接口设计的绝对完美”？你对 float32 的精度噪音有切肤之痛吗？
欢迎在评论区分享你的看法，我们一起坐等 Go 1.26 官宣！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-02-10 12:11:49
本文永久链接 – https://tonybai.com/2026/02/10/ai-agent-realizes-ultimate-dream-software-factory
大家好，我是Tony Bai。
在计算机科学与软件工程的历史长河中，始终存在着一个令人魂牵梦绕、却又屡屡受挫的终极梦想——“软件工厂（Software Factory）”。
早在 20 世纪 60 年代，日本的大型科技企业（如日立、东芝）就开始尝试引入制造业的流水线理念来生产软件。80 年代，CASE（计算机辅助软件工程）工具试图实现全流程自动化；21 世纪初，MDA（模型驱动架构）试图通过 UML 图直接生成代码。
然而，这些尝试无一例外都未能成为主流。
为什么？因为软件开发与硬件制造有着本质的不同。硬件是标准化的，而软件需求充满了不确定性（Ambiguity）、非标准化（Non-standard）和创造性（Creativity）。传统的刚性流水线无法处理这种“软”的复杂性。
但这一次，不一样。
随着以 GPT-5.2、Claude 4.5、Gemini Pro 3.0 等为代表的大语言模型（LLM）能力的爆发，以Claude Code、Gemini Cli等编码智能体的快速演进，以及Agentic Workflow（智能体工作流）的成熟，我们第一次拥有了能够理解“非标需求”并将其转化为“标准代码”的通用推理引擎。
特斯拉前 AI 总监 Andrej Karpathy 将这一刻定义为 Software 3.0 的黎明。在这个新时代，那个尘封已久的“软件工厂”蓝图，正在从幻想变成触手可及的现实。
今天，我们就来深度剖析这座正在崛起的 AI 软件工厂，看看它将如何重塑我们的行业、生态与职业。
要理解软件工厂的本质，我们需要先理解 Karpathy 提出的软件演进三阶段论。这是一次技术的迭代，更是编程范式的根本性迁移。
这是我们最熟悉的时代。程序员使用 Go、Python、C++、Java、TypeScript 等语言，编写显式的逻辑规则。
深度学习的兴起带来了 2.0 时代。程序员不再编写规则，而是编写目标（损失函数）和准备数据，由优化器（Optimizer）在神经网络的权重空间中搜索出最优解。这是一个黑盒。虽然它能解决图像识别等 1.0 很难解决的问题，但它缺乏逻辑的可解释性。
现在，我们进入了 3.0 时代。LLM 成为了一个新的、通用的可编程实体。
正是 Software 3.0 的出现，让“输入模糊需求，输出精确系统”成为了可能。
想象一下，未来的软件交付不再是一个团队几周的冲刺，而是一个工厂几分钟的运转。这座工厂不再由传送带和机械臂组成，而是由运行在云端的 Agent Swarm（智能体集群）构成。
这是一座柔性制造的超级工厂，其运作流程如下：
你不需要编写代码，甚至不需要编写格式严格的 PRD 文档。
工厂的原材料可以是极其粗糙的：
需求进入工厂后，会被一个Orchestrator（编排器）接管，并分发给不同的“职能车间”。这些车间由专精不同领域的 Agent 组成：
设计车间 (Architect Agent)：
它首先分析需求，进行系统拆解。它会输出：
制造车间 (Coder Agent)：
这是工厂的主力军。它会裂变出多个子 Agent 并行工作：
质检车间 (QA Agent)：
这是保证“良品率”的关键。QA Agent 不会等到代码写完才介入，而是采用 TDD（测试驱动开发）模式。
装配车间 (DevOps Agent)：
代码通过测试后，DevOps Agent 上场。它编写 Terraform 或 Dockerfile，调用 AWS/Aliyun/Cloudflare的 API，自动配置云端环境，进行部署。
工厂的传送带末端，输出的不是一堆冷冰冰的代码文件，而是一个可访问的 URL，一个已经配置好的 Admin 后台，以及一套完善的系统监控仪表盘。
这就是 Software 3.0 的终极形态：Prompt in, System out.
为什么我们要强调这是“柔性”工厂？因为它解决的是传统 CI/CD 流水线最大的痛点——刚性。
传统的流水线是线性的（Build -> Test -> Deploy）。一旦 Test 挂了，流水线就停了，红灯亮起，必须等待人类工程师介入修 Bug。
但 AI 软件工厂是有生命、会呼吸的。
它是基于 Agentic Workflow 的动态有向无环图（DAG），甚至是包含循环的图。
这是一条会思考的流水线。它不仅生产代码，还生产基础设施（IaC）。它与云厂商深度集成，实现了真正的 Serverless——作为用户，你连 Server 都不用感知，你只感知 Service。
当这种“输入需求，输出系统”的工厂模式普及后，软件行业的格局将发生天翻地覆的变化。
传统的软件工程理论（Agile, Scrum, 看板）很大程度上是为了解决“人与人协作”中的摩擦——信息不对称、理解偏差、情绪波动。
但在 AI 工厂里，协作变成了 A2A (Agent-to-Agent) 的协议交互。
未来的软件工程，将从管理“人”，转向管理“协议”和“标准”。协作的重心将聚焦于“人与工厂”的交互——即如何更精准、更高效地向工厂下达指令（Prompt Engineering / Spec Writing）。
在 Software 1.0 时代，开源项目（如 React, Spring, Django）是给人用的库（Library）。我们需要学习它的文档，理解它的 API。
在 Software 3.0 时代，开源项目将变成工厂的“模具”。
我们可能不再直接引用库，而是告诉工厂：“用 React 的模具生产前端”。源代码（Source Code）本身可能会变成像汇编语言一样的中间产物/表示——只有 AI 读写它们，而人类只会面向Spec。
Software is ephemeral. Spec is eternal.（软件是瞬态的，规格是永恒的。）
这是最残酷但也最充满机遇的转变。软件公司的人才结构将呈现极端的两极分化：
我们正处于软件行业“手工作坊”向“机器大工业”过渡的前夜，就像 1760 年代瓦特改良蒸汽机的前夜。
AI 软件工厂 不是科幻小说，它正在此时此刻发生。
Claude Code的Agent Team、针对编码智能体编排的Gas Town等，很可能都是这座工厂雏形的组件。
Karpathy 说的 “The hottest new programming language is English” 并不是一句玩笑。它意味着编程的门槛被无限降低，但构建系统的门槛被无限拔高。
无论你是想做“订货人”还是“厂长”，现在开始学习驾驭 AI Agent，学习如何构建和管理这些“数字员工”，是你拿到新时代船票的唯一方式。
你的“厂长”初体验
“软件工厂”的时代正在加速到来，我们每个人都将面临从“码农”到“订货人”或“厂长”的转型。想象一下，如果你现在拥有一座 24 小时不停工的“AI 软件工厂”，你最想让它为你生产一个什么样的系统？你认为在“机机协作”的未来，人类程序员最后的护城河在哪里？
欢迎在评论区分享你的脑洞与思考！让我们一起在这场软件工业革命的前夜寻找坐标。
如果这篇文章为你揭示了软件工程的未来，别忘了点个【赞】和【在看】，并转发给你的架构师朋友，大家一起未雨绸缪！
亲手搭建你的“微型工厂”
虽然完全自动化的“软件工厂”还在建设中，但其中的核心技术——Agent 编排、Spec 驱动开发——已经触手可及。
在我的极客时间专栏《AI 原生开发工作流实战》中，我将带你从零开始，利用 Claude Code，构建一个微型的 AI 软件流水线。
扫描下方二维码，开启你的 AI 架构师之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-02-10 08:43:33
本文永久链接 – https://tonybai.com/2026/02/10/goodbye-flaky-tests-go-testing-nettest-proposal
大家好，我是Tony Bai。
在 Go 语言的测试哲学中，我们一直追求快速、稳定和可重复。然而，一旦测试涉及到 net 包——无论是 HTTP 服务、RPC 框架还是自定义协议——这种追求往往就会撞上现实的墙壁。
我们通常面临两种选择：要么在 localhost 上监听真实端口，但这会导致测试并发时的端口冲突、防火墙干扰以及操作系统层面的不确定性；要么使用 net.Pipe，但它那“同步、无缓冲”的特性与真实的 TCP 连接大相径庭，常常导致生产环境运行良好的代码在测试中死锁。
为了彻底解决这一“最后一公里”的测试难题，Go 团队的 Damien Neil 提议引入 testing/nettest。这是一个完全在内存中运行，但行为上高度仿真真实网络栈（支持缓冲、异步、错误注入）的实现。
本文将和你一起剖析该提案的背景、设计细节以及它将如何改变我们编写网络测试的方式。
要理解 nettest 的价值，我们首先需要审视现状。目前的 Go 标准库在网络测试辅助方面，存在显著的“中间地带真空”。
net.Pipe() 是目前标准库提供的唯一内存网络模拟工具。但它本质上是一个同步内存管道。
使用回环地址（Loopback）是另一种常见做法，但它带来了“外部依赖”：
Go 1.24 引入了实验性的 testing/synctest 包，旨在通过虚拟时钟解决并发测试中的时间依赖问题。然而，synctest 难以接管真实的系统网络调用。为了让 synctest 发挥最大威力，Go 需要一个完全由用户态代码控制、不依赖操作系统内核的网络实现。nettest 正是这块关键的拼图。
testing/nettest 的目标非常明确：提供 net.Listener、net.Conn 和 net.PacketConn 的内存实现，使其行为尽可能接近真实的 TCP/UDP，同时暴露极强的控制力。
这是 nettest 与 net.Pipe 最大的区别。nettest.Conn 内置了缓冲区。
// 创建一对连接
client, server := nettest.NewConnPair()
// 模拟一个拥塞的连接，缓冲区仅为 1 字节
server.SetReadBufferSize(1)
// 此时写入大量数据，client.Write 将会阻塞，直到 server 端读取
go func() {
client.Write([]byte("hello world"))
}()
在真实网络中，我们可以通过 IP 地址来区分连接来源。nettest 通过 netip.AddrPort 模拟了这一点。
更妙的是 Listener.NewConnConfig 方法，它允许我们在 Server Accept 之前，对“即将到来”的连接进行修改。
实战场景：测试 IP 白名单中间件
以往测试 IP 白名单，你可能需要复杂的 Mock 或者真的去配置网卡。现在：
l := nettest.NewListener()
defer l.Close()
// 模拟一个来自特定 IP 的恶意连接
go func() {
conn := l.NewConnConfig(func(c *nettest.Conn) {
// 伪造源 IP
c.SetLocalAddr(netip.MustParseAddrPort("192.168.1.100:12345"))
})
conn.Close()
}()
conn, _ := l.Accept()
// 在这里断言你的中间件是否正确拒绝了该 IP
网络编程中最难测试的不是“连通”，而是“断连”、“超时”和“读写错误”。nettest 将错误注入标准化了。
它提供了一系列 Set*Error 方法：
你可以通过 SetReadError 模拟连接在中途突然 Reset，验证你的客户端是否会按预期进行重试。这些注入的错误会被自动包装在 *net.OpError 中，以保持与真实网络行为的一致性。
我们在测试中经常需要断言“连接是否已关闭”或者“是否有数据可读”。在标准 net 包中，这通常需要发起一个阻塞的 Read 调用，如果超时则认为无数据。这种基于时间的断言是 Flaky Test 的温床。
nettest 提供了非阻塞的状态查询方法：
配合 synctest，这将允许我们编写出逻辑极其严密、不依赖 time.Sleep 的确定性测试。
除了面向流（Stream）的 TCP 模拟，提案还照顾到了面向报文（Packet）的 UDP。
由于 UDP 没有“连接”的概念，不能像 TCP 那样简单返回一对 Conn。nettest 引入了 PacketNet 的概念，它就像一个微型的内存交换机。
// 创建一个虚拟的 UDP 网络环境
pn := nettest.NewPacketNet()
// 在这个网络中创建两个端点
c1, _ := pn.NewConn(addr1)
c2, _ := pn.NewConn(addr2)
// c1 发送给 c2
c1.WriteTo([]byte("ping"), addr2)
// c2 收到数据
buf := make([]byte, 1024)
n, src, _ := c2.ReadFrom(buf)
这使得测试基于 UDP 的自定义协议（如 QUIC 的某些握手流程、或是自定义的游戏协议）变得轻而易举，且完全隔离于宿主机网络。
在提案的讨论中，Damien Neil 非常清晰地界定了 nettest 的边界。理解它“不做”什么，和理解它“做”什么同样重要。
该提案一经发布，立即引起了 Go 社区资深开发者的强烈共鸣。
下一步是什么？
考虑到 API 表面积较大，Go 团队计划遵循“实验先行”的原则。nettest 将首先在 golang.org/x/exp/testing/nettest 中落地。这意味着我们很快就能在项目中引入并尝鲜了。待经过充分的社区验证和 API 打磨后，它最终将进入标准库，成为 testing 包下的一员猛将。
testing/nettest 的提案，看似只是增加了一个测试工具，实则反映了 Go 团队在工程效能上的深层思考。它试图消除测试中的“不确定性”，让网络测试回归逻辑的本质，而不是与操作系统和网络协议栈的噪声做斗争。
对于我们每一位 Gopher 而言，这意味着未来的测试代码将更少依赖 time.Sleep，更少处理端口冲突，运行速度更快，且更加稳定。让我们拭目以待，并准备好在 x/exp 发布的第一时间去拥抱它。
资料链接：https://github.com/golang/go/issues/77362
聊聊你的测试难题
网络测试中的“随机失败”曾让你抓狂吗？你是否也曾为了避开 net.Pipe 的坑而被迫在测试里撒满 time.Sleep？对于即将到来的 nettest，你最期待它的哪个功能？
欢迎在评论区分享你的测试心得或吐槽！让我们一起期待测试变得更简单、更稳健。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-02-09 08:25:53
本文永久链接 – https://tonybai.com/2026/02/09/amp-kills-vscode-plugin-human-ai-pair-programming-is-dead
大家好，我是Tony Bai。
如果一家 AI 编程工具公司，宣布砍掉它最受欢迎、用户量最大的产品入口，你会怎么想？
这听起来像是商业自杀，但这正是 AMP（从 Sourcegraph 孵化出来的 AI 编程 Agent）刚刚做出的决定。
在 2026 年 2 月的一期播客中，AMP 的创始人 Thorsten 和 Quinn 宣布：将在 60 天后，彻底关停 AMP 的 VS Code 插件和 Cursor 扩展。
要知道，在过去的两年里（2024-2025），IDE 侧边栏（Sidebar）几乎定义了 AI 编程的标准形态。无论是 GitHub Copilot、Cursor 还是早期的 AMP，我们都习惯了在编辑器里写代码，在侧边栏里和 AI “乒乓球”式地对话。
但 AMP 团队认为：这个时代结束了。
“你看着代码，AI 在侧边栏看着你，你们一来一回地对话……这种模式不是未来。对于那 1% 想要活在未来的开发者来说，侧边栏不仅不是助力，反而是枷锁。”
为什么他们敢于“烧掉桥梁”？因为一种全新的开发范式——“AI软件工厂模式（The Factory）”，正在随着 GPT-5.2 和 Claude Opus 4.5的成熟以及新版本编程大模型的发布而全面爆发。
今天，我们深度解读这份极具前瞻性的访谈，看看为什么 IDE 侧边栏必死，以及未来的软件工厂究竟长什么样。
要理解为什么要砍掉侧边栏，首先要理解模型能力的质变。
在 2025 年之前，主流模型（如 Claude 3.5 Sonnet）的特点是“聪明但急躁”。它们非常适合 Smart Mode：你问一个问题，它秒回一段代码；你报错，它秒回修正。这是一种高频的、实时的“结对编程”体验。
但随着 GPT-5.2 Codex 的发布，情况变了。
AMP 推出了一个新的模式：Deep Mode（深度模式）。
“侧边栏”完全无法承载这种体验。
想象一下，如果你在 IDE 侧边栏里发了一个指令，然后 AI 转了 45 分钟圈圈，期间你不敢关窗口，不敢切分支，这是一种多么糟糕的体验？
结论 1：
当 AI 的能力从“秒级补全”进化到“小时级任务”时，它必须脱离 IDE，进入后台，成为一个独立的Worker，而不是依附于编辑器的 Assistant。
访谈中透露了一个令人细思极恐的细节，揭示了 AI 原生开发时代的价值观重构。
AMP 团队为了优化内部的开发效率，重写了他们的构建工具。
他们用 Zig 语言重写了 svelte-check，将其命名为 zvelt-check。这样做的目的是为了让 Agent 跑得更快，且输出的日志更结构化（便于 Agent 解析）。不过，这个新工具也破坏了 VS Code 对 Svelte 的原生支持（Human DX 下降）。人类开发者在编辑器里看到的错误提示变差了，甚至失去了一些高亮功能。
在“人类体验（Human DX）”和“智能体体验（Agent DX）”发生冲突时，AMP 选择了后者。
甚至有一半使用 NeoVim 的员工表示：“我不在乎 VS Code 体验变差，只要 Agent 跑得快就行。”
这是一个标志性的时刻。
长久以来，所有的开发者工具（CLI、Linter、Log）都是为了“让人类读懂”而设计的。我们需要漂亮的颜色、进度条、友好的报错提示。
但在 AI 时代，90% 的工具调用者将是 Agent。Agent 不需要颜色，不需要进度条，它们需要的是极致的速度、结构化的 JSON 输出、幂等的执行逻辑。
结论 2：
未来的工具链，将优先为 AI 优化。如果一个工具对人类不友好但对 AI 友好，它依然会被采用。我们正在主动劣化人类的开发体验，以换取 AI 生产力的十倍跃迁。
访谈中提到了一个名为 “The Melting of Software（软件的消融）” 的概念。这不仅影响开发工具，更影响我们构建产品的方式。
案例 A：Ryan Florence 的健身教练
Ryan 没有使用任何健身 App。他只是打开了 ChatGPT 的语音模式，说：“我在家里的健身房，指导我锻炼。”
AI 说：“做一组深蹲，好了叫我。”
Ryan 做完说：“好了。”
AI 说：“休息 60 秒。”
没有 UI，没有按钮，没有 App。软件消失了，只剩下服务。
案例 B：购物清单的回归
Torston 本想用 Agent 自动化管理 Todoist（一个著名的待办事项 App）。
但他突然意识到：“我为什么要用 Todoist？我的购物清单只有 15 项。Agent 可以直接在一个纯文本文件里管理它。”
如果 Agent 能读懂文本，能实时更新状态，能通过 CLI 提醒我，那我为什么还需要一个复杂的 SaaS 软件？
这指向了一个终极问题：当 Agent 能够理解非结构化数据，并能通过原子化工具（如Skills）操作一切时，传统的“应用软件”是否会大量消亡？
未来的软件，可能不再是精心设计的 GUI，而是一组 Skills（能力） + Context（上下文文件）。
结论 3：
软件正在退化为 API 和数据，中间的“交互层”正在被 Agent 接管。
既然侧边栏死了，我们靠什么来通过 AI 开发？
答案是：CLI + Skills。
AMP 团队展示了他们如何在内部大量使用 Skills。
Skills 是“经验的固化”。
当你教会 Agent 解决一个问题后，让它把过程总结成一个 Skill。下次，它（以及团队里的其他 Agent）就不会再犯错。
这比在 Chat 窗口里一遍遍写 Prompt 要高效得多。
为什么 AMP 敢于砍掉 VS Code 插件？这源于他们独特的公司哲学。
“我们就像一个艺术装置（Art Installation），随时准备自我毁灭和重建。”
在这个技术每 3 个月就迭代一代的疯狂时代，“护城河”是最大的陷阱。
AMP 的 CEO 说：“如果我们因为‘用户习惯’而保留旧功能，我们就会变成哪怕是最好的‘落伍者’。我们必须每 3 个月重新赢得我们的客户。”
“Run towards the fire.”（向着炮火前进。）
如果你看到某个技术趋势正在颠覆你，不要躲避，不要观望，加入它，甚至成为颠覆自己的人。
这篇文章可能让大家感到不安。
你习惯了 VS Code，习惯了 Copilot 的自动补全，习惯了掌控一切。
但在 2026 年的视野里，“人机结对”只是一个过渡形态。
真正的未来属于 Agentic System（智能体系统），属于 Factory（软件工厂）。
在那个未来里：
对于那 1% 愿意走出舒适区、拥抱“Factory Mode”的开发者来说，你们的生产力将不再是线性的增长，而是指数级的爆发。
侧边栏已死，工厂万岁。
资料链接：https://www.youtube.com/watch?v=4rx36wc9ugw
你愿意为效率牺牲体验吗？
AMP 为了 Agent 效率主动劣化人类开发体验（Agent DX > Human DX），这一决定让你感到兴奋还是不安？如果一个工具能让你效率提升 10 倍，但代价是你再也看不清语法高亮，你会接受吗？
欢迎在评论区分享你对“AI 软件工厂”的看法！
提前布局你的“软件工厂”
虽然我们还不能完全抛弃编辑器，但 AMP 倡导的 Agent-Native 开发流，现在就可以开始实践。
在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深度对齐这种前沿理念：
不要等了。扫描下方二维码，现在就构建你的未来开发流。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
