本文永久链接 – 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 侧边栏必死，以及未来的软件工厂究竟长什么样。

Deep Mode：当 AI 学会了“深思熟虑”

要理解为什么要砍掉侧边栏，首先要理解模型能力的质变。

在 2025 年之前，主流模型（如 Claude 3.5 Sonnet）的特点是“聪明但急躁”。它们非常适合 Smart Mode：你问一个问题，它秒回一段代码；你报错，它秒回修正。这是一种高频的、实时的“结对编程”体验。

但随着 GPT-5.2 Codex 的发布，情况变了。

AMP 推出了一个新的模式：Deep Mode（深度模式）。

• 特性：这个模型不爱说话，它爱干活。它不是“懒惰”，而是“深沉”。
• 特工作流：你给它一个模糊但宏大的目标（例如“重构整个鉴权模块并适配新的安全协议”），然后你就可以走开了。
• 特时延：它可能会运行 45 分钟甚至 60 分钟。它会自主查阅文档、搜索代码、尝试方案、遇到错误、自我修正、运行测试，直到最终交付结果。

“侧边栏”完全无法承载这种体验。

想象一下，如果你在 IDE 侧边栏里发了一个指令，然后 AI 转了 45 分钟圈圈，期间你不敢关窗口，不敢切分支，这是一种多么糟糕的体验？

结论 1：

当 AI 的能力从“秒级补全”进化到“小时级任务”时，它必须脱离 IDE，进入后台，成为一个独立的Worker，而不是依附于编辑器的 Assistant。

惊人的抉择：Agent DX > Human DX

访谈中透露了一个令人细思极恐的细节，揭示了 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 生产力的十倍跃迁。

软件的消融：从 SaaS 到 Text

访谈中提到了一个名为 “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（上下文文件）。

• 你不需要 Google Cloud 的网页控制台，你只需要给 Agent 一个 gcloud 的 Skill。
• 你不需要 Jira 的复杂界面，你只需要一个能读写 Markdown 的 Agent。

结论 3：

软件正在退化为 API 和数据，中间的“交互层”正在被 Agent 接管。

技能（Skills）：新的抽象层

既然侧边栏死了，我们靠什么来通过 AI 开发？

答案是：CLI + Skills。

AMP 团队展示了他们如何在内部大量使用 Skills。

• Tmux Skill：教 Agent 如何在终端里正确使用 Tmux，如何杀掉进程（甚至包括“记得按两次 Ctrl-C”这种经验知识）。
• Google Cloud Skill：赋予 Agent 使用 Google Cloud CLI 的能力。
• BigQuery Skill：这被描述为“最神奇的体验”。你问：“多少用户用了这个功能？”，Agent 自动写 SQL，查 BigQuery，返回结果。

Skills 是“经验的固化”。

当你教会 Agent 解决一个问题后，让它把过程总结成一个 Skill。下次，它（以及团队里的其他 Agent）就不会再犯错。

这比在 Chat 窗口里一遍遍写 Prompt 要高效得多。

组织哲学：像艺术装置一样自我毁灭

为什么 AMP 敢于砍掉 VS Code 插件？这源于他们独特的公司哲学。

“我们就像一个艺术装置（Art Installation），随时准备自我毁灭和重建。”

在这个技术每 3 个月就迭代一代的疯狂时代，“护城河”是最大的陷阱。

• GitHub Copilot 曾经是王者，Cursor 出来后它显得老了。
• Cursor 曾经是王者，Claude Code 和 AMP 出来后，编辑器模式显得老了。
• 也许 3 个月后，OpenClaw 这样的纯本地 Agent 会让现在的模式也显得老了。

AMP 的 CEO 说：“如果我们因为‘用户习惯’而保留旧功能，我们就会变成哪怕是最好的‘落伍者’。我们必须每 3 个月重新赢得我们的客户。”

“Run towards the fire.”（向着炮火前进。）

如果你看到某个技术趋势正在颠覆你，不要躲避，不要观望，加入它，甚至成为颠覆自己的人。

小结：给 1% 的开发者

这篇文章可能让大家感到不安。

你习惯了 VS Code，习惯了 Copilot 的自动补全，习惯了掌控一切。

但在 2026 年的视野里，“人机结对”只是一个过渡形态。

真正的未来属于 Agentic System（智能体系统），属于 Factory（软件工厂）。

在那个未来里：

• 你不再是写代码的人，你是定义 Spec 的人。
• 你不再在编辑器里工作，你在终端（CLI）里指挥。
• 你不再管理代码，你管理智能体集群。

对于那 1% 愿意走出舒适区、拥抱“Factory Mode”的开发者来说，你们的生产力将不再是线性的增长，而是指数级的爆发。

侧边栏已死，工厂万岁。

资料链接：https://www.youtube.com/watch?v=4rx36wc9ugw

你愿意为效率牺牲体验吗？

AMP 为了 Agent 效率主动劣化人类开发体验（Agent DX > Human DX），这一决定让你感到兴奋还是不安？如果一个工具能让你效率提升 10 倍，但代价是你再也看不清语法高亮，你会接受吗？

欢迎在评论区分享你对“AI 软件工厂”的看法！

提前布局你的“软件工厂”

虽然我们还不能完全抛弃编辑器，但 AMP 倡导的 Agent-Native 开发流，现在就可以开始实践。

在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深度对齐这种前沿理念：

• CLI First：如何脱离 IDE，使用 Claude Code 在终端完成全流程开发？
• Skill Engineering：如何编写高质量的 Skill，让 Agent 掌握你独有的业务知识？
• Agent DX 优化：如何改造你的项目结构，让它对 AI 更友好？

不要等了。扫描下方二维码，现在就构建你的未来开发流。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/02/09/go-immutable-types-8-year-dormant-proposal-awakened

大家好，我是Tony Bai。

2026 年 2 月 4 日，在 Go 语言规范团队的最新一次“语言变更评审会议”纪要中，一个尘封已久的 Issue 赫然在列：proposal: spec: immutable type qualifier #27975。

这个提案最初提交于 2018 年，那是“Towards Go 2”口号喊得最响亮的年代。当时的 Go 社区正沉浸在对泛型、错误处理和不可变性的热烈讨论中。然而，随着泛型的落地，关于不可变性的声音似乎逐渐微弱。

如今，这个提案被重新摆上台面，是否意味着 Go 语言在完成泛型这一宏大叙事后，终于要向“数据竞争”和“防御性编程”这两个顽疾开刀了？

今天，我们就来看看复盘这份长达 8 年的提案，剖析一下“不可变性”对 Go 意味着什么，以及它面临的巨大挑战。

痛点：防御性拷贝的代价

在 Go 1.x 的世界里，我们为了保证数据的安全性，往往需要付出高昂的代价。

假设你有一个包含敏感配置的结构体，你想把它暴露给其他包，但又不希望它被修改：

type Config struct {
    Servers []string
    // ...
}

// 现在的做法：为了安全，必须返回拷贝
func (c *Config) GetServers() []string {
    out := make([]string, len(c.Servers))
    copy(out, c.Servers)
    return out
}

这种“防御性拷贝”带来了两个严重问题：

1. 性能损耗：每次访问都要分配内存和复制数据，对于热点路径是不可接受的。
2. 语义模糊：如果我不拷贝，直接返回 c.Servers，调用者能不能改？文档说不能改，但这只是君子协定，编译器不会阻止手滑的程序员。

正如提案作者 romshark 所言：“我们现在的做法，要么是不安全的（直接返回指针），要么是低效的（防御性拷贝）。”

而不可变类型（Immutable Types）的引入，旨在提供第三种选择：既安全，又高效。

提案核心：immut 限定符

NO.27975 提案的核心思想非常直接：引入一个新的类型限定符（最初建议重载 const，后倾向于引入immut ），让编译器来强制执行“只读”契约。

想象一下这样的 Go 代码：

// 定义一个只读的切片类型
func ProcessData(data immut []byte) {
    // 读取是 OK 的
    fmt.Println(data[0]) 

    // 修改是编译错误的！
    // data[0] = 'X' // Compile Error: cannot assign to immutable type
}

在这个愿景中，不可变性是类型系统的一部分。

• 赋值限制：你不能把一个 immut 类型的变量赋值给一个 mut（可变）类型的变量，这防止了“权限逃逸”。
• 传递性：如果一个结构体是不可变的，那么它字段指向的所有数据（如切片、映射、指针）也自动变为不可变。

这看起来很像 Rust 的 & (immutable reference) 和 &mut (mutable reference)，或者 C++ 的 const。但 Go 社区的讨论，揭示了这背后远比想象中复杂的工程难题。

社区激辩：理想与现实的碰撞

这份提案下的讨论区，堪称 Go 语言设计哲学的“修罗场”。Ian Lance Taylor, Rob Pike 等核心大佬纷纷下场，与社区开发者展开了长达数年的拉锯战。

const 污染

这是 Ian Lance Taylor 最担心的问题。如果你把一个底层函数的参数标记为 immut，那么所有调用它的上层函数，为了传递这个参数，往往也需要把自己的变量标记为 immut。

这种“传染性”会导致代码库中充斥着 immut 关键字。更糟糕的是，如果你以后需要修改底层函数，让它对数据进行一点点修改，你需要修改整个调用链上的类型签名。这在 C++ 中被称为“const correctness”的噩梦。

io.Writer 的尴尬

bcmills 提出了一个极其尖锐的兼容性问题：现有的 io.Writer 接口定义是 Write(p []byte)。

• 如果我们把 p 改成 immut []byte，那么现有的所有 Write 方法实现都会破坏兼容性。
• 如果我们不改，那么即使我手里有一个只读的切片，我也没法把它传给 io.Writer，因为类型不匹配。

这似乎陷入了一个死循环：要么破坏所有现有代码，要么新特性无法与标准库兼容。

所谓“不可变”，到底是谁不可变？

jimmyfrasche 指出了一个微妙的语义陷阱。

在 C++ 中，const T& 只是意味着“我不可以通过这个引用去修改它”（Read-only View），并不意味着“这个数据本身不会变”。因为可能还有另一个非 const 的指针指向同一块内存，并且正在修改它。

如果是前者（只读视图），它无法解决并发安全问题（数据竞争依然存在）。如果是后者（真正的内容不可变），那么 Go 必须引入一套类似 Rust 的所有权（Ownership）系统来保证“没有其他人在写”。这对于 Go 来说，改动太大了。

为何现在重提？

既然困难重重，为何在 2026 年的今天，这个提案又被翻出来了？

我认为有几个关键因素：

首先，泛型的“降维打击”。以权限泛型（Permission Genericity）化解兼容性死结。

前面提到了，在 Go 1.18 泛型落地之前，不可变性提案面临着一个被称为“io.Writer 陷阱”的致命矛盾：如果将 io.Writer.Write(p []byte) 改为接受 immut []byte，将导致全世界现有的实现代码因签名不匹配而崩溃；如果不改，只读数据又无法直接传入。

泛型的引入为这一难题提供了全新的解题思路。通过类型约束中的联合类型（Union Types），我们可以实现所谓的“权限泛型性”。这意味着 mutability（可变性）不再是一个硬编码的死结，而可以作为一个类型参数（Type Parameter）来处理。

想象一下，我们可以利用泛型约束定义一个覆盖“可变”与“不可变”两种状态的超集：~[]byte | ~immut []byte。下面是在这种模式下的一个泛型化的Writer接口：

// 这是一个设想中的“权限泛型”接口
type Writer[T ~[]byte | ~immut []byte] interface {
    Write(p T) (n int, err error)
}

泛型化的 Write[T ~[]byte | ~immut []byte](p T) 方法，在逻辑上可以产生如下影响：

1. 权限无关的调用：由于约束涵盖了两种类型，调用者现在可以合法且安全地将 immut []byte 传给标准库函数，解决了“只读数据无法写入”的窘境。
2. 非破坏性的兼容：对于现有的实现者（如 bytes.Buffer），其原本定义的 Write([]byte) 签名可以被视为该泛型约束的一个特化实例。编译器可以在不改动任何旧代码、不引入任何运行时开销的前提下，在静态分析阶段完成权限的自动适配与校验。

其次，性能压力的倒逼。

随着 Go 在高性能领域的应用越来越深（如数据库、AI 推理），对于“零拷贝”的需求越来越强烈。能够安全地共享内存，是提升性能的关键。

最后是安全性需求。

在并发编程中，数据竞争依然是 Go 程序的头号杀手。go vet 和 race detector 虽然好用，但它们是运行时的、滞后的。社区渴望一种编译期的保证。

未来的可能性：温和的演进

虽然完全的“不可变类型”可能依然很难落地，但我们可以期待一些更温和的替代方案：

• 只读视图 (Read-only Views)：不是引入新的关键字，而是引入一种新的泛型类型 ReadOnly[T]，或者编译器内置的 view 类型。
• 纯函数检查：引入一种机制，标记某些函数是“无副作用”的，从而允许编译器进行更激进的优化。
• 静态分析增强：不改变语言规范，而是通过更强大的 vet 工具，利用注释或特定命名约定，来静态检查不可变性约束。

小结

NO.27975 提案的“复活”，是一个信号。它表明 Go 团队并没有满足于现状，依然在探索如何在保持“简单”这一核心价值观的同时，赋予语言更强的表达力和安全性。

无论最终结果如何，这都是 Go 语言演进史上值得铭记的一笔。它提醒我们：在软件工程中，没有免费的午餐，每一个简单的特性背后，都是无数次复杂的权衡。

你支持引入 immut 吗？

面对“性能”与“简单”的博弈，你是否愿意为了消除数据竞争而接受 immut 带来的“类型传染”？在你的项目中，是否也曾深受“防御性”的性能困扰？

欢迎在评论区分享你的看法，或者聊聊你最期待的 Go 演进方向！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。