本文永久链接 – https://tonybai.com/2026/02/28/agentic-software-engineering

大家好，我是Tony Bai。

欢迎来到微专栏 《AI 智能体时代的软件工程》的第一讲，也是开篇词。

想象一下，你刚刚招募了一位极度聪明的初级程序员。

他有着令人“毛骨悚然”的执行力：当你去泡杯咖啡的功夫，他已经噼里啪啦写完了 1000 行代码，不仅编译通过，测试也全绿，看起来极其专业。

但很快，你发现了令人窒息的另一面：

• 他没有任何架构直觉，完全不顾及系统未来的可维护性；
• 他极其盲目自信，会在没有彻底理解业务意图时就大刀阔斧地重构核心逻辑；
• 最要命的是，他有着严重的“失忆症”——今天你刚纠正过他的代码规范，明天一早，他又会带着饱满的热情，把你昨天的纠正忘得一干二净，并再次犯下完全相同的错误。

请问，你会敢让这样一位员工不受限制地直接把代码推上生产环境吗？

绝对不敢。你会为他安排极其严格的代码审查，设定明确的边界，要求他每做一步都提供详尽的证据。

然而，这正是当前整个行业在面对 AI 智能体（AI Agents）时，正在犯下的致命错误。

过去这两年，从 GitHub Copilot 到 Cursor，再到各种强大的命令行编码智能体(比如Claude Code、Codex等)，整个开发生态陷入了一场名为“氛围编程”（Vibe Coding）的狂欢。开发者们发现，只要用自然语言“连哄带骗”地去引导 AI，凭着感觉不断点击“重新生成”，总能碰巧凑出一个看起来能跑的程序。

对于写个一次性脚本或做个原型，这感觉就像魔法一样棒。但如果你是在构建一个长生命周期、需要高可靠性的企业级软件，这种“氛围编程”无异于用 Windows 画图软件去设计一座跨海大桥。

速度是有了，但信任债务（Trust Debt）正在疯狂累积。

为什么 AI 写代码越快，你的团队越痛苦？

很多研发 Leader 和资深开发者最近都有一个共同的痛点：AI 并没有减轻工作量，它只是把“写代码”的痛苦，转移成了“读代码和收拾残局”的痛苦。

在传统软件工程中，由于是人类逐行敲击键盘，代码的“产出速度”天然受限。这个物理限制，给了我们的大脑足够的时间去消化上下文、思考架构边界，并在潜意识里完成质量校验。

但在如今的智能体时代，代码生成的速度不再是瓶颈，人类的注意力和审查带宽成为了绝对的瓶颈。

当 AI 队友可以在几秒钟内吐出几百行横跨多个微服务、改动了数据库 Schema 甚至引入了新依赖的代码时，传统的“拉个 Pull Request，人肉看两眼 Diff”的审查机制瞬间就崩溃了。你面对的是一座由于局部极度优化，但全局逻辑可能支离破碎的“现代化屎山”。

如果你只是把 AI 当成一个“跑得更快的打字机”，而不去升级包裹在 AI 外面的工程管理体系，你最终得到的不会是十倍的提效，而是以光速制造出的系统灾难。

软件工程不仅没有死，反而迎来了“工程化”的黄金时代

有人说，“有了 AI，软件工程就不存在了”。这完全是外行看热闹的错觉。

土木工程从来就不是关于如何徒手搓出一块完美的钢筋，而是关于如何在材料存在公差、工人会犯错的客观现实下，通过冗余设计、安全裕度和检验标准，造出绝对可靠的桥梁。

同样，AI 智能体时代的新一代软件工程，其核心就是：如何在一个由大量“具有随机性（Stochastic）、不可靠”的 AI 队友和人类组成的混合团队中，通过系统性的工程约束，持续、稳定地交付可被绝对信任的软件系统。

再通俗直白一些，就是我们需要把非确定性的魔法，关进确定性的工程笼子里。

坦白说，这套颠覆性的思维范式并非我凭空捏造。在过去的一段时间里，我深受软件工程业界前沿大佬Ahmed E. Hassan的影响，阅读了他的有关Software Engineering 3.0(简称SE 3.0)的论文和著作《Agentic Software Engineering》。尤其是后者，这本书像一座灯塔，极具前瞻性地定义了智能体软件工程的理论框架与核心悖论。

但在反复研读，并尝试将其引入我日常的真实研发流水线后，我深深地感受到：“看懂理论”和“把它变成团队日常执行的肌肉记忆”之间，还隔着一条名为“工程落地”的鸿沟。

这正是我策划这门微专栏的初衷。

在这里，我们不讲那些几个月就会过时的 Prompt 奇技淫巧，也不教你怎么安装某个特定的 AI 插件。我将把《Agentic SE》一书中最具价值的底层心法，结合我在真实复杂架构中的开发实践与踩坑经验，为你翻译并重构为一套“心法 + 战术 + 落地模板”的实战指南，教你如何将非正规军的“氛围编程”，全面升级为正规军的智能体软件工程。

在接下来的内容中，我们将深度探讨：

• 如何利用 AI “不知疲倦”的特质，把枯燥的边界测试和重构做到极致？
• 如何设计任务简报，用“意图契约”取代松散的提示词，给 AI 划定自治的安全边界？
• 如何构建合并就绪包（Merge-Readiness Pack），让基于“代码 Diff”的审查，升级为基于“证据链”的审计？
• 当你的团队从“1个人+1个AI”演进到“10个人+100个并发运行的 AI”时，如何设计自动化的协同流水线，避免它们互相踩踏？
• 为什么在 AI 时代，像 Go、Rust 这种“默认无聊、限制颇多”的强类型语言，反而成为了企业级系统最坚实的底座？

微专栏目录抢先看

本专栏共计 14 讲，分为四大核心模块：

模块一：认知重塑 —— 从“氛围编程”到“智能体工程”

• 第 1 讲 | 停止“氛围编程”（Vibe Coding），拥抱新一代软件工程
• 第 2 讲 | 危险的“初级天才”：AI 队友的四大致命悖论

模块二：人机协作设计模式 —— 压榨 AI 队友的“非人类”优势

• 第 3 讲 | 无尽迭代与超越完成：利用 AI 的“不知疲倦”
• 第 4 讲 | 沟通降本：把“脏乱差”的意图转化为精准的研发契约
• 第 5 讲 | 免费的架构委员会：零社交成本的“魔鬼代言人”
• 第 6 讲 | 并行分解与一次性赌注：零成本验证多种技术方案

模块三：可靠性保障工程 —— 把“随机性”关进笼子

• 第 7 讲 | 任务工程 (Mission Eng)：告别 Prompt，建立“自治契约”
• 第 8 讲 | 上下文工程 (Context Eng)：把知识视为接口，而非垃圾场
• 第 9 讲 | 基于证据的审查：千万别信 AI 的“测试已通过”

模块四：平台与团队规模化 —— 打造多智能体协同流水线

• 第 10 讲 | 协同工程：避免“连环车祸”的自动化流水线设计
• 第 11 讲 | 双态工作台：为何我们需要为 AI 重构 IDE？
• 第 12 讲 | 信任工程：建立 AI 时代的“三维材料清单 (BOM)”
• 第 13 讲 | 语言工程：代码可读性，AI 时代最核心的架构决策
• 第 14 讲 | 结束语：认清现实，去当驾驶法拉利的赛车手

模块五：加餐篇 —— 将 Agentic SE 注入 Claude Code

待定，看微专栏订阅人数是否超出预期^_^

小结：变革的临界点已经到来

那些还在死磕代码生成速度的团队，最终会被堆积如山的“神秘技术债”压垮；而那些率先建立起现代智能体工程体系的团队，将真正驾驭这股洪荒之力，获得十倍甚至百倍的产能飞跃。

你是想成为那个在失控的自动驾驶汽车里尖叫的乘客，还是想成为从容掌控整个 AI 赛车车队的总指挥？

点击链接或扫描下方二维码，立即订阅《AI 智能体时代的软件工程》。 让我们一起拿下通往新时代的头等舱船票，重塑未来的软件工程！

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

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

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

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

本文永久链接 – https://tonybai.com/2026/02/27/go-mod-init-controversy-elitism-vs-democracy

大家好，我是Tony Bai。

仅仅在 Go 1.26 正式发布几周后，一场席卷 Go 社区的风暴迎来了戏剧性的转折。面对广大开发者对 go mod init 默认降级为 1.(N-1) 的强烈不满，Go 核心团队技术负责人 Austin Clements（aclements）亲自下场“灭火”，并明确表示：官方正倾向于撤回这一改动，恢复 1.N 的默认行为。

这看似是一场“社区战胜了官方”的完美结局，但在欢呼之余，我们必须进行更加深刻的冷思考。一个对成千上万新手和业务开发者有着巨大影响的命令行行为变更，为何能在没有引起广泛警觉的情况下被悄然合入主干？

当剥开技术争议的表象，我们会发现一个令人担忧的事实：Go 语言引以为傲的“设计驱动（Design-Driven）”和民主化提案流程正在褪色，取而代之的，是一种脱离群众、缺乏约束的“精英主义”。

从“不接受反驳”到“光速认错”的大反转

如果你错过了前几天的剧情，这里做一个简短的背景回顾：在 Go 1.26 中，官方为了“强制保护下游生态兼容性”，将 go mod init 的默认版本从当前工具链的 1.26 降级成了 1.25。这意味着，当你满怀期待地下载了最新的 Go，敲下初始化命令后，却无法直接使用哪怕是最简单的 new(expr) 新语法。

面对社区在 Issue #77653 中提出的“违背最小惊讶原则”、“惩罚 99% 的普通开发者去迎合 1% 的底层库作者”等尖锐批评，最初参与决策的几位核心成员态度强硬。核心元老 Ian Lance Taylor 甚至抛出了那句著名的、略显傲慢的回复：“除非有新的信息，否则我们不会重新审视已做出的决定。”

就在局势即将陷入僵局，社区情绪日益沸腾之时，Go 团队的技术负责人 Austin Clements 终于出面了。

他的回复展现出了难得的客观与同理心，直接给这场争论定了调：

1. 承认对新手的伤害：“要求那些刚刚安装了 1.N 的用户去使用 1.N（遇到报错时不知所措）显然是令人困惑的。这尤其伤害了新手，因为他们是最不可能知道如何解决这种困惑的群体。这是一个错误的权衡。”
2. 点出视角的错位：“支持 1.(N-1) 的论点是微妙的，是高级用户的考量；而支持 1.N 的论点则是直截了当的。”
3. 最终表态：“我们正倾向于撤回（Revert）这个修改，但我们希望给后续开会的 Go 命令工作组一个发表意见的机会。”

随后，Austin 将恢复 1.N 行为的提议置于了提案审查列表的最高优先级。至此，这场降级风波基本以社区的胜利告终。

傲慢的代价——为什么这个糟糕的决定会被做出？

知错能改，善莫大焉。

Go 团队及时纠错的态度值得点赞。但是，作为一门支撑着全球云计算基础设施的工业级语言，为什么这样一个“伤害新手、逻辑存在明显硬伤”的改动，能够一路绿灯地发布到正式版中？

Austin Clements 在回复中不经意间说出了一句最关键的话：

“The original change probably should have gone through proposal review. I don’t think any of us appreciated the full effect it would have.”
最初的修改可能本应该走提案审查流程。我不认为我们中有人意识到了它会产生的全面影响。

这句话，彻底揭开了 Go 团队目前在工程管理上的遮羞布：他们绕过了自己设定的规矩。

导致 go mod init 行为改变的原始 Issue #74748，从头到尾只是作为一个普通的“Feature Request”存在，它没有被打上 Proposal 的标签，没有经过 Proposal Review 会议的正式审议，更没有撰写任何正式的 Design Document（设计文档）。仅仅是因为几个维护 cmd/go 的核心开发者觉得“这样做对生态好”，就直接敲定并合并了代码。

他们身处维护底层基础设施的“信息茧房”中，满脑子都是复杂的依赖树和版本冲突，却完全忘记了一个刚接触 Go 的大学生在终端敲下 go mod init 时的第一直觉。

这正是典型的精英主义盲区：用自己极其特定的工作场景，去套用世界上数以百万计的普通应用开发者。

如果这个修改走过了正规的 Proposal 流程，在全社区的注视下进行公示，这种盲区早就被一线的业务开发者指出了。

名存实亡的“设计驱动（Design-Driven）”

在早年间，Go 团队以极其克制和严谨的工程规范著称。打开官方Go Proposal仓库的主页(README.md)，开宗明义的第一句话就是：

“The Go project’s development process is design-driven. Significant changes to the language, libraries, or tools (which includes API changes… as well as command-line changes to the go command) must be first discussed, and sometimes formally documented, before they can be implemented.”
（Go 项目的开发过程是设计驱动的。对语言、库或工具的重大更改——包括对 go 命令的命令行更改——在实施之前，必须首先进行讨论，有时还需要进行正式的文档记录。）

规矩写得清清楚楚：go 命令的行为变更，必须走 Proposal 流程。

然而，近两年来，随着 Go 语言演进速度的加快，这种“Design-Driven”的文化似乎正在被一种“Issue-Driven”甚至“PR-Driven”的快餐文化所侵蚀。

数据是反映这种文化流失的最有力证据。

让我们打开 Go 官方存放设计文档的仓库（golang/proposal）。你会震惊地发现，在整个 2025 年，该仓库的 design/ 目录下，一共只有屈指可数的 5 个 Commit！

• 2025 年 2 月：TLS 动态配置设计
• 2025 年 9 月：Goroutine 泄露检测设计
• 2025 年 11/12 月：runtime.free 内存释放设计
• … …

除去这寥寥几个极其硬核的底层变动，大量的 API 新增、标准库重构、以及类似 go mod init 这种影响深远的命令行行为调整，全部在没有正式设计文档的情况下被“悄度陈仓”了。

对比当年引入 Modules、引入泛型（Generics）时动辄上万字、历经数月甚至多年打磨、收集无数社区反馈的设计文档，现在的 Go 团队似乎变得越来越“自信”，也越来越“急躁”。

很多时候，内部成员提一个 Issue，写几百字的简要说明，几位拥有合并权限的大佬在下面留个 +1 或者 LGTM，代码就直接开干了。

警惕精英主义杀死社区的民主

开源项目的治理，本质上是对权力（代码合并权）的约束。Proposal 流程设立的初衷，不是为了增加官僚主义，而是为了强制核心开发者在动手写代码之前，必须进行结构化的思考和广泛的倾听。

当 Proposal 流程被有意无意地绕过时，精英主义的毒药就开始蔓延：

1. “Google Knows Best”心态抬头：当核心决策圈脱离了广泛的社区讨论时，他们不可避免地会认为自己的判断优于普通开发者。最初对社区反馈的冷漠回应，正是这种心态的缩影。
2. 缺乏边界情况的推演：没有要求提交正式的 Design Doc，就意味着没有要求详细列出 “Alternatives Considered”（替代方案）、”Compatibility”（兼容性影响）和 “Drawbacks”（缺点）。缺乏这种强制的“三省吾身”，魔鬼就会藏在未被测试的边界细节中。
3. 社区信任的透支：民主的基石是程序正义。当开发者发现影响自己日常工作的命令被悄悄改掉，且在提出异议时遭遇“没有新信息不予讨论”的傲慢对待时，社区与官方团队之间的信任就会产生深深的裂痕。

小结：让 Go 重回“设计驱动”的轨道

go mod init 降级风波以官方的妥协和准备 Revert 告一段落。对于广大的 Gopher 来说，在未来的 Go 1.26 小版本（或 Go 1.27）中，我们有望找回那个熟悉的、开箱即用的 go mod init。

但这绝不应该仅仅是一个代码上的回滚。它更应该成为悬在 Go 核心团队头上的一记警钟。

Go 语言之所以伟大，很大程度上得益于其早期近乎刻板的严谨与克制。在追求语言特性现代化的今天，我们最不希望看到的就是这种严谨被丢弃，被少数人的“我觉得这样更好”所取代。

我们呼吁 Go 团队重新审视并严格执行 Proposal 流程。 对于任何影响开发者体验、改变默认行为的改动，都应该将其强制拉回到阳光下，撰写详尽的设计文档，接受全社区的拍砖与审视。

“快”从来不是 Go 语言的唯一追求，“稳”与“清晰”才是。希望这场风波能让 Go 开发流程重新找回那份对“设计驱动”的敬畏之心，因为只有倾听真实世界的声音，这只可爱的地鼠才能在云原生以及AI的时代走得更远、更稳。

本文基于 Go GitHub Issue #77653、#74748 及相关开源治理规范深度整理。对于 Go 团队最终的及时纠错，我们表示敬意，同时也期待看到一个更加开放、透明、且尊重程序的决策流程。

你的“投票”

Go 团队的这次“回滚”，是社区声音的一次胜利。作为一名普通开发者，你如何看待 Go 官方近年来的决策风格？你认为现在的 Proposal 流程是太慢了，还是太快太随意了？

欢迎在评论区留下你的真实看法！ 每一个理性的声音，都是对 Go 社区的一份贡献。

如果这篇文章说出了你的心声，别忘了点个【赞】和【在看】，并转发给更多关心 Go 未来的朋友！

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

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

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

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

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

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

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

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

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