阅读视图

发现新文章,点击刷新页面。
🔲 ☆

AI 时代,敏捷宣言已死?听听 Martin Fowler 和 Kent Beck 怎么说

本文永久链接 – https://tonybai.com/2026/04/12/agile-manifesto-dead-in-ai-era-martin-fowler-kent-beck

大家好,我是Tony Bai。

25 年前,在美国犹他州的一间滑雪小屋里,17 位当时最顶尖的软件开发者聚集一堂,共同签署了一份将彻底改变未来二十年软件工程形态的纲领——《敏捷软件开发宣言》。

在这 17 位“上古大神”中,有两个名字,如同北极星一般,指引了一代又一代程序员的成长:一位是《重构》的作者 Martin Fowler,另一位则是“极限编程(XP)”之父、敏捷宣言的发起人 Kent Beck。

25 年后的今天,当生成式 AI 的海啸席卷全球,当“敏捷迭代”被 AI 的“瞬间生成”无情碾压时,我们不禁要问:敏捷已死吗?我们曾经信奉的那些工程哲学,还剩下什么?

就在前几天,在一个汇聚了硅谷最火热 AI 创业者的闭门活动上,这两位白发苍苍的“活化石”出人意料地并肩坐到了一起,进行了一场关于 AI 时代的世纪对话

他们没有去鼓吹 AI 带来了多高的效率,反而用一种极其深刻、甚至有些悲观的视角,对当下这场“AI 狂欢”提出了终极拷问。这场对话,值得我们每一个身处其中的技术人,暂停手中飞速生成的代码,静下心来,一字一句地读完。

历史的轮回:AI,不过是又一个“微处理器”

面对台下年轻开发者对 AI 的狂热与恐慌,Kent Beck 的开场异常平静。他把时间拉回到了自己还是个孩子的时候。

“在微处理器(Microprocessor)诞生之前,电脑是一个你根本搬不动的庞然大物。当英特尔 4004 芯片问世时,我们突然意识到,‘等等,这也是一台电脑!’ 突然之间,你能做的事情的想象空间被无限放大了。”

Kent Beck 认为,今天的 AI,在本质上与当年的微处理器、后来的面向对象、再后来的互联网浪潮并无不同。它们都是“想象力的放大器”。

他坦言自己现在正在用 AI 去做一些“极其离谱的、野心勃勃的项目”,比如用 Rust 写库级别的高质量代码。“很多都会失败,但这没关系,这就是探索的一部分。”

而 Martin Fowler 则补充了他对技术浪潮的“二阶思考”:

“你必须在‘怀疑主义’和‘好奇心’之间找到完美的平衡。我对区块链就极其怀疑。但我的怀疑主义必须是绝对的——这意味着,我必须连我自己的怀疑本身,都保持怀疑。”

他坦言,自己一开始对 Copilot 这种东西也极度不屑,觉得它生成的都是垃圾。直到他读了 Simon Willison 的博客,才意识到:要用好一个工具,你必须先学会如何用好它。这和当年很多人嘲笑“面向对象”没用,但其实只是他们自己没有用对,是同一个道理。

戳破幻觉:“敏捷”的敌人,从来不是瀑布开发

当被问及“AI 承诺的‘更快、更好、更便宜’,与 25 年前敏捷宣言的初衷是否一致”时,Kent Beck 抛出了一个极其扎心的观点:

“事实证明,企业根本不想要更快、更好、更便宜。在一个公司内部,各种激励机制的错位,导致他们会惩罚那些真正追求效率的人。”

Martin Fowler 对此深有同感。他认为,AI 与敏捷最大的不同在于,当年他们需要费尽口舌去说服企业“敏捷有多重要”,而今天,没有任何一家公司敢对 AI 的重要性视而不见。

但这恰恰是最大的陷阱。

当年的“敏捷转型”,在无数企业中最终都演变成了一场“形式主义的灾难”,催生了庞大的“敏捷工业复合体”。

而今天,同样的剧本正在 AI 身上重演。无数根本不懂技术的咨询公司,正在兜售着各种“AI 转型”的灵丹妙药。

AI 正在成为新的“蛇油(Snake Oil)”。

注:“蛇油”是19 世纪的美国民间骗局,有人贩卖一种据说能治百病的“蛇油”之类的神药。其核心特征是用夸张的疗效宣传、用故事/神秘疗法包装、同时缺乏科学依据,最后你花钱买到的往往是没用甚至有害的东西。

架构师的终极拷问:AI 正在摧毁程序员的“社交”

如果说对“蛇油”的警惕还只是宏观层面的担忧,那么 Kent Beck 接下来提出的观点,则直接刺向了每一个正在享受 AI 编码便利的开发者。

他认为,AI 正在让软件开发“重新孤岛化(Re-soloing of programming)”

“极限编程(XP)很大一部分工作,是为那些天生不善社交的程序员,创造一个安全的社交环境。在一个 XP 团队里,人们每天花几个小时进行结对编程、激烈讨论,并乐在其中。”

“但我现在看到的是什么?‘我是一个程序员,我手下有 6 个 Agent,所以我是一个小团队的管理者。’ 不,你不是。你只是在同时使用 6 个工具。

在过去,我们把程序员从一个个封闭的办公室里解放出来,让他们围坐在一起,通过“混乱、复杂、充满人味儿”的社交过程,去创造伟大的软件。

而现在,我们似乎又在主动退回那个“把程序员关进小黑屋,从门缝底下塞披萨”的时代。只不过,这次陪伴你的,是几个冰冷的 AI 机器人。

Martin Fowler 也表达了同样的担忧:

“未来的团队,到底是‘一个披萨的团队’(因为 Agent 不吃披萨),还是一个‘两个披萨的团队,但效率翻倍’?我赌后者。

他认为,“两个人类 + N 个 AI” 的结对编程模式,可能是未来的答案。因为两个人类可以更好地控制 AI 的方向,同时保留了宝贵的人类交互。

有趣的是,Kent Beck 甚至觉得现在的 AI 有点“太快了”。

“当 AI 需要 3 分钟才能返回结果时,我们正好可以利用这段时间,去讨论一下变量命名的哲学,或者下一步的架构方向。但如果它 15 秒就返回了,我们就失去了交流的时间。”

手艺人的黄昏:当 AI 剥夺了“重构的快感”

在对话的最后,当被问及“AI 时代,程序员该如何自处”时,Kent Beck 的一段独白,充满了“手艺人”的失落与悲情,足以让每一个热爱编码的资深开发者瞬间破防。

“我过去在编程中获得的一种‘强迫症’般的享受,正在消失。那种把一个文件从一坨屎山,通过无数个微小、安全的步骤,最终重构成一件艺术品的快感,再也没有了。”

“我依然可以从宏观上理解我正在做什么。但我需要把我的关注点,从享受‘雕琢程序本身’,转移到享受‘理解业务领域’上。因为在‘雕琢程序’这件事上,我们已经失去了杠杆。”

Martin Fowler 则给出了更具操作性的建议:

“一个有趣的现象是:开发者体验(Developer Experience)和智能体体验(Agent Experience)的维恩图,是一个完美的圆。对 Agent 友好的代码,对人类也友好。”

他认为,拥有良好模块化、清晰接口和完备测试的代码,AI 处理起来会更得心应手。我们过去几十年积累的那些“手艺”,并没有过时,它们只是从“指导人类”变成了“指导 AI”。

小结:在不确定的浪潮中,抓住不变的礁石

这场持续了一个多小时的对话,没有给出任何关于“如何写 Prompt”、“用哪个模型”的答案。

但这两位穿越了数个技术周期的智者,用他们的人生经验,为我们指明了在 AI 这场史无前例的巨浪中,唯一能抓住的几块礁石:

  1. 保持绝对的怀疑,包括对怀疑本身的怀疑。
  2. 学会设计最小化的实验,亲自去验证那些天花乱坠的说法。
  3. 不要放弃与人交流,那才是创造力的真正源泉。
  4. 把你的代码写得更清晰、更模块化、测试更完备。这不仅是为了你自己,更是为了你未来的 AI 同事。

最后,Kent Beck 给出了一个极其悲壮的建议:或许,我们是时候放弃享受“雕琢代码”的乐趣,而去享受“理解世界”的乐趣了。

这或许是对 AI 时代,我们这些“数字手艺人”最深刻、也最无奈的宿命注解。

资料链接:https://www.youtube.com/watch?v=CZs8J1ZD0CE


今日互动探讨:

在使用 AI 编程后,你是否也像 Kent Beck 一样,感觉失去了那种“重构屎山”的快感?在 AI 时代,你认为“结对编程”是会消亡,还是会变得更加重要?

欢迎在评论区分享你的看法!


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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

当AI 榨干了编程所有的乐趣:我不再是程序员,而是“Claude Code”的项目经理

本文永久链接 – https://tonybai.com/2026/04/04/the-death-of-coding-joy-in-the-age-of-ai-agents

大家好,我是Tony Bai。

过去的两年,我们见证了 AI 编程工具从“玩具”到“神器”的进化。从 Copilot 的代码补全,到 Claude Code 的“一句话建站”,再到各种Coding Agent 的“自主开发”,我们写代码的效率被史无前例地拉满了。

但在这场效率的狂欢之下,一股难以言喻的“失落感”和“空虚感”,正在资深程序员群体中悄然蔓延。

就在几天前,Reddit 的 r/webdev 社区(一个拥有 66 万开发者的顶级论坛)上,一位拥有 20 年经验的资深后端工程师发了一篇帖子,标题极其刺眼:AI has sucked all the fun out of programming》(AI 榨干了编程所有的乐趣)。

他写道:

“我曾对自己解决难题、深挖源码的能力无比自豪。但自从 Claude Code 变得越来越强,我感觉自己不再是一个程序员,更像是一个项目经理,每天管理着一个叫 Claude Code 的中高级外包。我交付功能的速度比以往任何时候都快,但内心却无比空虚。这些没有灵魂的特性,我无法再把它们看作是我的创造。”

“AI 让我变得极度懒惰,它彻底摧毁了我作为一个优秀工程师、甚至一个人类的价值。我希望它从未被发明过。”

这篇充满“怨气”的帖子,像一块巨石砸入了平静的湖面,瞬间引爆了整个社区。短短一天,帖子收获了 1500+ 的高赞和近 400 条评论。无数开发者涌入评论区,分享着自己在 AI 时代相似的困惑、挣扎与幻灭。

今天,我们就来扒开这场顶级社区的“赛博哀悼会”,看看当 AI 剥夺了编程最后的“手艺活”时,我们这些“数字工匠”,到底失去了什么?

身份的剥夺:从“创造者”到“代码审查员”

在评论区,点赞最高的一条回复,只用了一句话,就说出了所有人的心声:

“是的,是的,是的。而且,审查那些由 AI 生成的、过度工程化的垃圾 PR,简直让人精疲力竭。”

这精准地概括了资深程序员们失落感的第一个根源:身份的降维

在没有 AI 的时代,我们是“创造者”。我们享受的是从零开始,将复杂的业务逻辑,通过一行行精巧的代码,构建成一个优雅系统的过程。那种“庖丁解牛”般的掌控感和心流体验,是支撑我们熬过无数个加班夜的精神支柱。

而现在呢?

AI 成了那个大刀阔斧的“创造者”,它可以在几分钟内生成 10 个文件、成千上万行代码。而我们,这些曾经的“建筑师”,被迫降级成了一个卑微的“代码审查员(Code Reviewer)”

我们的日常工作,不再是“如何巧妙地设计一个接口”,而是“如何在这堆由 AI 生成的、看似完美却隐藏着无数暗雷的代码里,找出那个该死的 Bug”。

一位开发者形容这种感觉就像“吃屎”:

“重构一小段代码,就像在菜里加点盐,很有趣。但如果让你 9 点到 5 点都在重构 AI 生成的屎山,那就完全是另一回事了。”

学习的终结:当“挣扎”的权利被剥夺

除了身份的降维,更让开发者们感到恐惧的,是“学习感的丧失”

一位只有 2 年经验的前端开发者的评论获得了 123 个高赞:

“AI 确实让我变快了。但有时我感觉,我跳过了那些本该挣扎和学习的部分。而正是那些挣扎,才让知识真正刻进我的脑子里。”

这说出了一个残酷的真相:人类的学习,本质上是一个伴随着痛苦和摩擦的过程。

当你为了一个 Bug 熬了三个小时,翻遍了 Stack Overflow,最后在某个不起眼的角落找到解决方案时,你对这个 Bug 的理解是刻骨铭心的。

但现在,你只需要把报错信息扔给 Claude Code,它会在 3 秒钟内给你正确答案。

效率是提升了,但你的大脑也失去了构建深度知识模型(Mental Models)的机会。你成了知识的“搬运工”,而不是“内化者”。

更可怕的是,这种趋势正在从个人蔓延到团队,甚至威胁到新人的成长路径。

评论区的一位开发者也分享了他的遭遇:

“我们是做嵌入式开发的,AI 很多时候根本不懂底层。但我们的经理对 AI 产生了宗教般的狂热,他强迫我们必须用 AI。如果我们不用,他就会 visibly upset(肉眼可见地不爽);如果我们用了,然后报告 AI 出了问题,他会立刻假定是我们用错了,而不是 AI 的问题。”

这种来自管理层的“AI 迷信”,正在让那些真正懂技术的专家感到心寒。当你的老板拿着 ChatGPT 的一段胡言乱语来质疑你的专业判断时,技术尊严的丧失,远比失去乐趣更令人痛苦。

正在分裂的社区:效率派 vs 手艺派

当然,也并非所有人都对 AI 感到悲观。评论区同样出现了鲜明的“效率派”阵营。

一位拥有 27 年经验的资深开发者表达了截然不同的看法:

“我反而觉得 AI 增强了我的能力。我依然负责掌控项目的整体架构,AI 只是帮我处理那些烦人的、重复的体力活。这就像我有了一个能完美听懂我话的初级开发人员,而且他永远不会抱怨。”

另一位开发者则将这种转变描述为角色的升维:

“乐趣转移了,但没有消失。我们团队的人类现在负责所有的架构决策,AI 负责具体的实现。创造性的工作依然存在——它从‘如何写好这个函数’,变成了‘如何设计好这个系统’。我们从‘砖瓦工’,变成了‘建筑师’。”

这两种截然不同的声音,揭示了 AI 时代开发者社区正在经历的一场剧烈的身份分化:

  • 手艺派:他们热爱编码本身,享受那种与代码“人剑合一”的创造快感。对他们而言,AI 剥夺了这个过程。
  • 效率派(或架构派):他们更享受从宏观层面掌控系统的乐趣,将编码视为一种实现目标的手段,而非目的。对他们而言,AI 是解放他们生产力的“外骨骼”。

这两种观点没有对错,它仅仅反映了不同性格的开发者,在面对一场史无前例的生产关系变革时,所产生的自然分化。

出路何在?:夺回“原子化”的掌控力

在这场关于“乐趣与灵魂”的大讨论中,我们依然能找到一些极具建设性的生存法则。

第一,坚决捍卫“人类最终解释权”。

AI 可以生成,但你必须成为那个拥有“一票否决权”的最终审计者。正如一位开发者所言:

“我正在无视所有关于‘再不拥抱 AI 就会被淘汰’的末日预言。我只把它当成一个强化版的搜索引擎。如果未来真的只需要一批不懂底层原理的‘提示词操作员’,那我的工作反正也变得毫无意义了。但如果未来依然需要懂底层的人,那我的处境绝对比那些‘氛围编码’了好几年的人强得多。”

第二,主动创造“无 AI 日(Zero AI Day)”。

另外一位开发者的建议获得了很多人的认同:

“为了对抗这种侵蚀,我每周会选定一天作为我的‘无 AI 日’。在那一天,我禁止自己使用任何 AI 工具。这种感觉非常自由。”

这就像健身中的“欺骗餐”,它能让你重新找回对代码最原始的“手感”。

第三,把 AI 当作“副驾驶”,而不是“自动驾驶”。

真正的老司机,绝不会在高速上双手离开方向盘。他们会利用 AI 去处理那些最耗时、最没有创造性的部分:写单元测试、生成 OpenAPI 文档、转换数据格式。

而在核心的业务逻辑和架构设计上,亲手去写,去感受系统的“摩擦力(Friction)”,去构建你脑海中那张独一无二的架构蓝图。

小结:从“多巴胺”到“内啡肽”

AI 的出现,极大地满足了我们对“即时反馈”的多巴胺式快感:敲一句话,代码就出来了。

但真正的编程乐趣,那种来自于深度思考、解决难题后获得的、持久而宁静的成就感,属于“内啡肽”。

AI 正在用廉价的多巴胺,稀释我们获取内啡肽的能力。

我们不必为此感到绝望。正如工业革命没有消灭所有手工艺人,反而催生了更昂贵的“高级定制”一样。

当 AI 能够批量生产千篇一律的“预制菜”代码时,那些依然能够亲手雕琢出艺术品级架构的“米其林大厨”,其价值将不降反升。

问题的关键在于,在这场大浪淘沙中,你,是选择成为流水线上一颗随时可被替换的螺丝钉,还是那个手握最终菜谱的顶级大厨?


今日互动探讨:

在使用 AI 编程后,你的“编程乐趣”是增加了还是减少了?你觉得 AI 帮你完成的最有价值和最没有价值的工作分别是什么?

欢迎在评论区分享你的真实感受!


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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

别再用 AI 疯狂撸代码了!我们正在把自己逼入“死胡同”

本文永久链接 – https://tonybai.com/2026/03/29/stop-mindless-ai-coding-we-are-heading-to-a-dead-end

大家好,我是Tony Bai。

过去的一年,大概是所有程序员肾上腺素飙升最快的一年。

从早期的 Copilot、Cursor到如今的Claude Code、Codex,再到各种号称能“全自动开发”的 Agent Swarm(智能体集群)。只要在周末花上几个小时,敲几句 Prompt,你就能把以前想做却没时间做的 Side Project 全部干出来。

甚至,连微软 CEO Satya Nadella 都在四处宣扬“微软现在有多少代码是 AI 写的”。仿佛在一夜之间,“一个人就是一家公司”、“一天撸完一个 SaaS 平台”成了技术圈的标配。

但在这场速度的狂欢中,你有没有感觉到一丝不对劲?

最近,国外资深开发者 Mario Zechner 写了一篇极其辛辣的文章《Thoughts on slowing the f**k down》。他毫不客气地戳破了这层“繁荣”的窗户纸:

当我们把 AI 智能体(Agent)全面引入生产代码库后,我们并没有迎来软件工程的乌托邦,反而正在以惊人的速度,制造着前所未有的“屎山”和灾难。

今天,我想结合他的反思,以及我最近在使用 AI 原生开发时的一些切身痛点,给大家浇一盆冷水。在被大模型彻底“惯坏”之前,我们必须看清,过度依赖 Agent 正在如何毁掉我们的系统,甚至我们的职业生涯。

100% AI 生成,等于 100% 的不可控

很多公司和独立开发者喜欢标榜:“我的产品 100% 是由 AI 写的。”

他们以为这是高科技的证明,但在行家眼里,这简直是灾难的代名词。

那些号称“完全脱手、让 Agent 自己去写”的代码库,往往充斥着你能想象到的最糟糕的垃圾:

高达几个 G 的内存泄漏、莫名其妙的 UI 闪烁、完全没有一致性的设计模式,以及一碰就碎的核心逻辑。

为什么会这样?难道现在的 AI 不够聪明吗?

原因在于:Agent 是“没有痛感”的,而人类有。

在传统的手工编码时代,人类程序员是一个天然的“物理瓶颈”。你一天最多只能写 500 行高质量代码。如果你在这个过程中犯了错(比如引入了某个不良的抽象,或者写了一个极其恶心的嵌套),你会立刻感到“痛苦”

为了避免这种痛苦,你会花时间去重构,去梳理架构,或者因为被 Reviewer 骂了一顿而痛改前非。

痛苦,逼着人类去学习和进化,逼着系统保持在一个“可维护”的边界内。

但 Agent 呢?它是一台没有感情的打字机。

它可以在几分钟内拉出两万行代码。如果其中包含了一个微小的设计缺陷,它不会感到痛苦。相反,它会在你看不见的地方,将这个缺陷以成百上千倍的速度“复利式地放大(Compound)”

等你回过神来,想要在这个 100% 由 AI 生成的系统上加一个新功能时,你会绝望地发现:你连它长什么样都不知道,而且它已经烂到连 AI 自己都改不动了。

为什么 AI 连自己写的屎山都修不好?

有人可能会说:“既然 AI 能写屎山,那我再派一个高级 Agent 去重构这堆屎山不就行了?”

这就是当下最可怕的“平替思维”陷阱。

现实是:当代码的复杂度和体积膨胀到一定程度后,AI 的“召回率(Recall)”会呈现断崖式下跌。

这不仅仅是上下文窗口大小(Context Window)的问题。在拥有百万行代码的迷宫中,Agent 根本不知道该去哪里找相关的依赖,不知道哪些旧代码可以复用。它只能基于极其局部的视野(Local View)去做决策。

这就导致了极度荒谬的现象:Agent 在重构时,不仅找不到病根,反而会发明出更多为了抽象而抽象的垃圾代码,让屎山开出更加绚丽的“奇葩”。

人类制造企业级的屎山,需要几十个程序员耗费好几年的时间来堆砌;

而你,只需要带上 2 个 AI Agent,几个星期就能搞出一个连上帝都看不懂的废墟。

当你发现连号称 100% 覆盖率的 AI 测试用例都在撒谎时,除了手动去点产品、祈祷它别崩溃,你已经失去了对系统的任何掌控力。

我们该如何与 Agent 共生?

难道我们要砸烂电脑,退回到手敲汇编的时代吗?当然不是。

Agent 就像古希腊神话中的海妖塞壬(Sirens),用极速的快感诱惑着你。我们必须在它摧毁我们的工程纪律之前,重新夺回主动权。

真正的顶级开发者,绝不会对 AI 说:“嘿,帮我把这个系统全干了。”

他们与 Agent 的协作,遵循着极其严苛的边界:

1. 坚决把控“系统的整体结构”

什么是系统的整体结构?那是你的核心架构设计、API 的边界、数据库的实体关系,以及整个系统跑起来时的“手感”。

这些东西,必须由你亲手来写,或者通过 Pair Programming(结对编程)一行一行地推敲。

只有亲手写过,感受到那份“摩擦力”,你才能在脑海中建立起对系统的上帝视角。这是目前任何 SOTA(最先进)大模型都无法替代的品味与经验。

2. 让 AI 去干“不用动脑子”的脏活

Agent 最适合的场景,是那些不需要全局视野的局部任务:写一段正则、爬个数据、写几条枯燥的单元测试,或者是写一个就算坏了也不影响公司赚钱的内部临时脚本。

把时间花在“决定做什么”和“决定不做什么”上。学会对需求说“不”,本身就是最高级的特性。

3. 强制减速

这是最反直觉,也是最重要的一条建议。

不要为了追求那虚荣的“代码生成量”而沾沾自喜。给自己设定一个限制:每天 AI 生成的代码量,绝对不能超过你“能够深入 Review 和理解”的极限。

你必须确保,如果明天所有的 AI 公司突然破产,你依然能从容地接管这个系统,因为它的每一根骨架,都在你的掌控之中。

小结:只有人类,才能兜住底线

在过去的一年里,我们把太多的权力让渡给了机器,以至于我们忘记了软件工程的本质。

在这个鼓吹“快、更快、再快一点”的癫狂时代,慢下来,反而成了最稀缺的竞争力。

你的代码可能不再是纯手工敲出来的了,但你的架构品味、你的工程纪律、你在出 Bug 时能一针见血找到根源的敏锐直觉,才是你在这个时代安身立命的根本。

一切自动化,最终都需要人类的纪律(Discipline)与主体性(Agency)来兜底。

机器可以写代码,但只有人类,才能为系统注入灵魂。

资料链接:https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down


今日互动探讨:

在日常开发中,你有没有遇到过被 AI 生成的“看似完美、实则藏雷”的代码坑得很惨的经历?你是怎么发现并解决的?

在 AI 编程的浪潮中,你觉得人类程序员最不可被替代的核心能力是什么?

欢迎在评论区分享你的血泪史与思考!


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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

手工作坊的终结:为什么你必须把 Agent Skills 开发,变成严谨的软件工程?

本文永久链接 – https://tonybai.com/2026/03/18/building-industrial-grade-agent-skills

大家好,我是Tony Bai。

我是你的老朋友,一个正在被 AI 疯狂“内卷”的程序员。

如果你最近几个月一直在使用 Cursor、Claude Code 或者其他各种 AI 编程助手,你大概率会经历一个情绪的“过山车”:

第一天:“卧槽,太牛了!这代码它自己就写完了!”

第一周:“等等,这段逻辑有点怪,我得去修一下它的 Bug。”

第一个月:“崩溃了……我给它写了 500 行的 Prompt,它还是会在同一个地方犯错。而且,它昨天明明写对了,今天稍微换个问法,它又按老套路瞎编了一遍!”

这就是我们当前面临的真实困境。

我们正处在一个尴尬的过渡期:AI 写代码的速度远远超过了我们人类 Review 和兜底的速度。当我们试图用更长、更复杂的 Prompt 去控制 AI 时,我们发现自己变成了一个“疲于奔命的手工作坊老板”

你精心雕琢的 Prompt,就像是一本厚厚的员工手册。你把它塞给一个记忆力只有 7 秒、充满迷之自信、速度极快的“初级天才开发”。结果就是,他偶尔能超常发挥,但大多数时候,他会把事情搞砸,而且你根本不知道他为什么搞砸。

靠“玄学 Prompt”来驱动 AI 的时代,已经一去不复返了。

为什么你觉得无力?因为你在用“黑盒”对抗“黑盒”

为了解决这个问题,业界开始推出各种“技能(Skill)”或者“智能体(Agent)”框架。你可以把一套工作流、最佳实践、甚至是工具库打包成一个 Skill,让 AI 在需要的时候调用。

这听起来很完美,对吧?

于是,你开始尝试用一些自动化工具(比如 Anthropic 的 skill-creator 或者各种自研的 Agent 平台)来帮你写 Skill。你输入一句“帮我写一个分析日志的技能”,工具咔咔咔一顿输出,生成了一堆配置文件和 Markdown。

你测试了一下,好像能用。

但当你把它投入真实的生产环境时,灾难开始了:

  • 触发率成迷: 用户明明说了“帮我看看日志”,AI 却死活不加载这个 Skill。
  • 指令“漂移”,输出不稳定: 面对结构稍微不同的日志,它就开始胡编乱造。
  • 薛定谔的复现率: 同一个任务,昨天它完美执行,今天你稍微换了个问法,它就彻底无视了整个 Skill 的存在,开始自由发挥。
  • 难以迭代: 你想加个新功能,结果旧功能莫名其妙就退化了。

面对这些自动生成的代码和配置,你感到一种深深的无力感。因为对你来说,这个 Skill 是一个“黑盒”,而生成它的那个工具,是另一个“黑盒”

当系统出问题时,你甚至不知道该修改哪一行字。

打破黑盒:把 AI 技能开发,变成严谨的软件工程

如果我们要真正驾驭 AI,让它成为我们可靠的队友,而不是一颗随时会爆的定时炸弹,我们就必须抛弃“调包侠”和“按键猴子”的心态。

我们需要将 AI 技能(Agent Skill)的开发,视为一项严肃的软件工程

这也是我策划这门微专栏的初衷。我将它命名为:《打破黑盒:用工程思维构建工业级 Agent Skill》

在这门专栏中,我不会教你那些几个月后就会失效的“Prompt 奇技淫巧”。相反,我将带你深入底层,拆解一个高质量工业级 Skill 诞生的全生命周期。

我的核心观点只有两个:

  1. 不要逆势而为,必须“用 AI 制造 AI”。 面对复杂的上下文和多步推理,人类的手写能力已经触及天花板。我们必须学会熟练使用类似 skill-creator 这样的自动化工具,利用多智能体协作(Multi-Agent Collaboration)来帮我们生成、测试和优化 Skill。
  2. 绝不接受“黑盒”。 我们必须站在“上帝视角”,深刻理解这些自动化工具内部的运行机制。我们需要知道:
    • AI 是如何“阅读”和“加载”一个技能规范(Spec)的?
    • 在自动化测试中,那个负责打分的“裁判智能体(Grader)”是按照什么标准来评判好坏的?
    • 当需要评估两个版本哪个更好时,那个“盲测智能体(Blind Comparator)”是如何排除偏见,给出量化数据的?
    • 最后,那个负责迭代的“分析师智能体(Analyzer)”是如何通过分析执行轨迹(Transcript),找出失败的根本原因,并给出改进建议的?

只有看懂了裁判的打分规则,你才能写出满分的卷子。只有理解了系统底层的齿轮是如何咬合的,你才能在遇到触发率低、输出不稳定等问题时,精准地进行降维打击,而不是像无头苍蝇一样乱改 Prompt。

你将在这个微专栏中获得什么?

这门专栏共 7 讲,每一讲都是一次认知升级和实战演练:

  • 第 1 讲 | 开篇:手工作坊的终结,为什么你必须学会“用 AI 制造 AI”? (就是你现在看到的这篇)
  • 第 2 讲 | 拆解 Skill Spec:揭秘 AI “理解”与“按需加载”技能的底层逻辑
  • 第 3 讲 | 启动引擎:从“模糊意图”到“高潜草稿”的自动化生成之路
  • 第 4 讲 | 拒绝玄学:构建可量化的 Eval 断言与全自动测试流水线
  • 第 5 讲 | 盲测与进化:让 AI 裁判自己证明“新版本比老版本强”
  • 第 6 讲 | 榨干最后 1% 精度:用数据驱动的 Benchmark 彻底解决触发难题
  • 第 7 讲 | 交付与升华:从打包部署到构建“人机混合”的新一代研发体系

我希望,通过这门专栏的学习,你能完成从“被 AI 牵着鼻子走的打字员”到“能够指挥一支硅基研发车队的超级架构师”的蜕变。

在这个全新的时代,代码的生成速度不再是壁垒,如何定义规范、如何编写断言(Assertions)、如何设计基准测试(Benchmark)、如何建立评估体系(Eval),才是工程师真正的护城河。

准备好打破黑盒,迎接挑战了吗?

立即点击此处订阅专栏,或者扫描下方二维码,让我们一起,用工程思维,重新定义 AI 时代的开发范式!


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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

AI 时代的新王座:为什么说 Go 可能是开发 AI Agent 的最佳语言?

本文永久链接 – https://tonybai.com/2026/03/07/why-go-is-the-best-language-for-ai-agents

大家好,我是Tony Bai。

当我们在谈论 AI 编程时,Python 似乎是那个无需讨论的“默认选项”。

然而,随着 AI 应用从模型训练(Training)走向自主智能体(Agents)和复杂的工程落地,基础设施层的语言选型正在悄然发生变化。近日,开源数据编排工具 Bruin 的作者发表了一篇题为《Go 是开发 AI Agents 的最佳语言》的文章,在 Hacker News 上引发了数百条跨语言阵营的激烈辩论

为什么一位有着 10 年 Python 和 JS 经验的开发者,最终选择用 Go 来构建现代 AI 基础设施?在 AI 生成代码(AI-Generated Code)日益普及的今天,编程语言的“静态类型”、“编译速度”和“语法极简主义”又被赋予了怎样的新维度价值?

本文将深度拆解这场争论,带你探讨在“Vibe Coding(氛围编程)”时代,Go 语言如何凭借其独特的设计哲学,意外地命中 AI Agent 开发的甜点。

为什么是 Go?来自生产一线的工程反思

Bruin 是一个开源的 ETL(提取、转换、加载)工具。在数据工程领域,Python 拥有统治级的地位(Pandas, Airflow 等),按理说,Bruin 完全应该用 Python 编写。

但作者最终选择了 Go。原因在于,AI Agent 和数据编排工具在本质上属于基础设施(Infrastructure),它们面临的工程约束与模型训练截然不同:

  1. 极致的并发需求:Agent 绝大部分时间都在等待外部 API 的响应(OpenAI, Anthropic)。Go 极其轻量的 Goroutine 机制(2KB 栈空间,极低的上下文切换成本)允许在单机上轻松维持数万个并发请求,而 Python 的 GIL(全局解释器锁)即使配合 asyncio,在 500-1000 RPS 后也会遇到明显的线程竞争瓶颈。(注:最新版Python已经去除了GIL的限制。)
  2. 极简的部署体验:Go 编译出的单一静态二进制文件,无需像 Python 那样处理复杂的虚拟环境(venv)、依赖冲突和运行版本问题。对于需要在用户机器上运行的 CLI 工具来说,Go 是“分发即运行”的典范。
  3. 跨平台验证的便利:Go 一等公民的跨平台编译能力,意味着不仅开发者可以轻松构建多平台产物,未来的“后台 AI Agent”也能在一个隔离的沙箱中快速验证代码的跨平台兼容性。

除了上述硬核的工程指标外,作者还坦诚地分享了一个极其主观,但对初创团队至关重要的考量:开发体验(Developer Experience)与情绪价值。

作者将在很长一段时间内作为项目的核心贡献者,他深刻地意识到:

“对于一个小型团队来说,在构建大型项目时,快乐和活力(Joy and Energy)是最稀缺的资源之一。因此,至关重要的是,我不能对自己每天要面对的技术栈感到畏惧或厌烦。”

Go 语言或许在某些特性上不如 Python 灵活,也不如 Rust 表达力强,但它带来的那种“一切尽在掌握”的确定性和快速获得反馈的成就感,能让开发者在漫长的马拉松式开发中保持心流状态。这种心理层面的正向反馈,在 AI Agent 这种充满不确定性的前沿领域探索中,往往是支撑团队走过低谷、坚持到黎明的关键力量。

如果说以上只是 Go 作为“云原生王者”的常规操作,那么在引入大语言模型(LLM)作为“代码生成器”后,Go 的语言特性产生了奇妙的化学反应。

静态编译:给 AI 戴上“紧箍咒”

当 Coding Agent 开始每分钟吐出成千上万行代码时,最大的挑战不再是“如何生成”,而是“如何证明它有效”。

在解释型语言(如 Python 或 JavaScript)中,代码的正确性往往只有在运行到特定分支时才能被验证。作者指出,这是 Go 在对抗 AI 幻觉时最大的优势之一:Go 是一门强类型的编译型语言。

编译器的“守门员”效应

当你用 LLM 生成 Go 代码时,go build 成了一道天然且严苛的防火墙。类型不匹配、未使用的变量、错误的函数签名——这些占据了 AI 幻觉相当大比例的低级错误,会被 Go 编译器瞬间无情地驳回。

正如一位 HN 网友 所言:

“在这个人人都在‘氛围编程(vibing left and right)’的时代,你迫切需要一个编译器在背后支持你。Go 让你可以写稍微随意一点的代码,但又不会像 Python 或 JS 那样毫无底线。编译器扮演了看门人的角色,将混乱控制在一定范围内。”

为什么不是 Rust?

讲到编译期安全,Rust 绝对是无可争议的王者。但为什么作者认为 Go 比 Rust 更适合 AI Agent?

  • 迭代速度决定一切:AI Agent 的工作流是一个“生成 -> 编译 -> 报错 -> 修复”的紧密反馈循环(Feedback Loop)。Go 的编译速度几乎是瞬时的,这使得 LLM 的试错循环可以极快地运转。而 Rust 漫长的编译时间,在这里成为了致命的瓶颈。
  • 借用检查器的“认知负荷”:Rust 的内存模型(生命周期、借用)极其复杂。现阶段的 LLM 在处理复杂的借用关系时,常常会陷入“为了让编译器闭嘴而无脑 clone()”的陷阱,导致生成的代码偏离 Rust 的最佳实践。
  • 更平缓的试错成本:Go 的垃圾回收(GC)机制让 AI(以及审查代码的人类)可以专注于业务逻辑,而不必在内存管理上耗费计算 token 和审查精力。

简单来说:Rust 的上限极高,但门槛太陡;Go 用 20% 的努力(快速编译+GC),换取了 80% 媲美 Rust 的安全性,这恰好是 AI 迭代的最优解。

极简主义与“无聊”的胜利

Go 语言自诞生起,就因为其语法的“无聊”和“死板”(比如缺乏灵活的宏、长期没有泛型、繁琐的错误处理)而饱受争议。然而,在 AI 时代,这种“无聊”却意外地成为了巨大的优势。

“只有一种做法”的红利

Python 和 JavaScript 以“灵活”著称。在一个 JS 项目中,有人用 CommonJS,有人用 ES6 Modules;有人用 npm,有人用 pnpm。对于人类来说,这叫“生态繁荣”;但对于 LLM 来说,这叫“状态空间爆炸”(High Entropy)。

Go 是极其“固执”的语言(Opinionated)。

  • 格式化代码?只有 gofmt。
  • 怎么处理错误?永远是 if err != nil。
  • 怎么写测试?标准库 testing 包。

正如作者指出的:“要求 Agent 格式化 JS 代码,它会去引入一个新工具并尝试配置它;而在 Go 中,它只需要运行 gofmt。”

这种高度统一的代码风格,意味着在 LLM 的训练语料库中,Go 代码的“信噪比”极高。模型不需要在多种编程范式中猜测你的偏好,它输出的 Go 代码通常具有高度的同质性和可预测性。

人类可读性:代码审查的最后防线

当 AI 成为主要的“代码编写者”时,人类的角色将不可避免地向“代码审查者(Code Reviewer)”倾斜。

如果 AI 生成了一段高度抽象的 Haskell 代码,或者使用了大量宏的 Rust 代码,人类审查者需要耗费极大的脑力去反编译这些逻辑。

而 Go 代码是出了名的“所见即所得”。没有隐藏的控制流,没有复杂的运算符重载。当 AI 生成了几百行 Go 代码时,即使是一位初级开发者,也能相对轻松地顺着逻辑线读懂它在干什么。

在 AI 编程的下半场,“代码易读”将比“代码易写”重要一万倍。

跨越阵营的交锋:Hacker News 的不同声音

当然,这篇文章在 Hacker News 上并非一边倒的赞同。不同语言阵营的开发者提出了极其犀利的反思。

反思一:Python 真的过时了吗?

Python 拥护者指出,文章混淆了“运行时性能”和“开发生态”。

虽然 Go 在高并发和 I/O 上碾压 Python,但如果 AI Agent 的核心逻辑涉及大量的数据科学计算、复杂的概率模型,或者需要直接调用底层的 C++ 机器学习库,Python 依然是不可替代的粘合剂。对于许多初创团队来说,“让代码先跑起来”远比“让代码跑得快”更重要。

反思二:类型系统能否取代测试?

支持函数式语言(如 OCaml, F#)的开发者指出,Go 的类型系统依然过于薄弱。

Go 缺乏代数数据类型(ADT)和模式匹配,导致其虽然能抓住低级语法错误,但难以像 Rust 或 OCaml 那样“在编译期保证业务逻辑状态的正确性”。

对于他们而言,如果 AI 真的足够聪明,应该让 AI 生成具有极强类型约束的代码,把正确性完全交给编译器,而不是像 Go 那样依然需要编写大量的单元测试。

反思三:长远来看,语言还重要吗?

这是一个终极的哲学问题:如果未来 AI 不再犯错,能够零成本生成正确的机器码,高级编程语言还有存在的意义吗?

有评论认为,当模型能力足够强时,我们甚至不需要编译型语言的保护,直接用自然语言(英语)+ LLM 生成运行时的 WebAssembly 可能才是终局。在这个维度上,争论 Go 还是 Python,就像在争论用什么牌子的算盘(意指已经被时代所抛弃的东西)一样没有意义。

小结:实用主义者的狂欢

在 AI 技术日新月异的当下,我们往往容易陷入一种对“前沿”的盲目崇拜,认为只有最复杂的语言、最先进的模型才能构建出优秀的系统。

但 Bruin 作者的实践和 Go 社区的繁荣告诉我们另一个故事:工程的本质是权衡(Trade-off)。

Go 并不是世界上最完美的语言,它的类型系统不如 Rust 严谨,它的生态不如 Python 庞大。但它用极致的编译速度、简单的并发模型、出色的内存管理和统一的编码规范,构建了一个容错率极高的工程基座。并且在这个基座上,无论是人类还是 AI Agent,都能以最低的“认知摩擦力”输出可靠的工业级代码。

资料链接:

  • https://getbruin.com/blog/go-is-the-best-language-for-agents/
  • https://news.ycombinator.com/item?id=47222270

你更相信谁?

在 AI 编程的下半场,语言的地位正在重构。你是坚守 Python 的生态优势,还是更看好 Go 在“基础设施级 Agent”中的爆发?你认同“编译器是 AI 的最佳守门员”这个观点吗?

欢迎在评论区留下你的“阵营宣言”!


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

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

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


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

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

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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

停止“氛围编程”(Vibe Coding),拥抱新一代软件工程

本文永久链接 – 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原生开发之旅。


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

© 2026, bigwhite. 版权所有.

🔲 ☆

AI入门系列 Mac:AI时代不容忽视的设备

Bensz
AI入门系列 Mac:AI时代不容忽视的设备

本博客由AI模型商OhMyGPT强力驱动!如何更快地访问本站?有需要可加电报群获得更多帮助。本博客用什么VPS?创作不易,请支持苯苯!推荐购买本博客的VIP喔,10元/年即可畅享所有VIP专属内容! 概览 Vibe Coding 时代来临,Mac 作为开发者首选设备的地位愈发巩固 macOS 全球桌面操作系统市场份额达 14.59%,开发者使用率约三分之一 Mac 的 Unix 原生环境为 AI 编程工具提供近乎完美的兼容性 Apple Silicon 的统一内存架构和神经引擎为 AI 工作负载提供硬件级加速 续航与便携、触控板体验、屏幕素质、界面美学等日常体验优势显著提升开发效率 生态系统连续互通与隐私安全机制为本地 AI 计算提供理想环境 Mac mini M4 以 4,499 元起售价成为性价比之王,16GB 内存起步适配 AI 需求 2026 年春将推出搭载 A18 Pro 芯片的 […]

Bensz

🔲 ☆

Rust 输了?在 AI Agent 的战场上,TypeScript 才是唯一的“神”

本文永久链接 – https://tonybai.com/2026/01/31/rust-vs-typescript-ai-agent-battleground-winner

大家好,我是Tony Bai。

如果把 2025 年定义为 Coding Agent(编程智能体) 的元年,那么刚刚开启的 2026 年,毫无疑问是 Personal AI Agent(个人助理智能体) 的元年。

openclaw(曾用名Clawdbot/Moltbot)为代表的开源项目,一夜之间席卷了 GitHub,让无数开发者为之疯狂。但在这一片繁荣的景象背后,作为一名敏锐的技术观察者,我发现了一个极其有趣的现象。

请环顾四周,看看那些最顶尖、最流行、体验最好的 AI Agent 项目:

  • Claude Code (Anthropic 官方):TypeScript。
  • Gemini CLI (Google 官方):TypeScript。
  • openclaw(100k+ Star):TypeScript。
  • opencode以及配套的oh-my-opencode:TypeScript。

再看看Go语言,虽然没有占据头把交椅,但也稳稳地守住了一席之地。Gastowncrush 这些专注于并发和后端服务的 Agent 或Agent编排框架,依然拥有自己的一批拥趸。

但是,那个在过去几年呼声最高、号称“内存安全、性能无敌、将重写一切”的 Rust 去哪了?

在 AI Agent 的应用层战场上,尤其是像上述这些火出圈的AI Agent项目中,Rust 几乎“失声”了。除了 OpenAI 的 Codex 这个孤勇者之外,我们很难在主流的开源 Agent 列表中看到 Rust 的身影。

难道在 AI 时代的Agentic AI(智能体AI应用)阶段,Rust 输了吗?为什么被视作“玩具语言”的 TypeScript,反而成了 AI Agent的“母语”?

今天,我们不谈信仰,只谈架构。让我们深入剖析这场语言战争背后的第一性原理。

数据说话:统治 Agent 界的“TS 军团”

在下结论之前,我们先来看一组数据。

我统计了目前 GitHub Trending 上排名前 20 的 AI Agent 相关项目(排除单纯的模型推理框架,仅统计应用层 Agent),结果令人震惊:

  • TypeScript / JavaScript:占比约 75%。
    这是绝对的统治地位。无论是官方的 SDK,还是社区的野生项目,TS 都是默认选项。openclaw的作者 Peter Steinberger 本人就是 iOS 和 C++ 出身,但他依然选择了 TS 来构建他的个人AI助理。
  • Python:占比约 15%。
    依靠着 LangChain 和 AutoGen 的早期积累,Python 依然有存量优势,但在构建交互式 CLI全栈应用 时,Python 的体验明显不如 TS 丝滑。
  • Go:占比约 8%。
    Go 凭借其单文件分发(Single Binary)和强大的并发模型,在Agent编排框架、Coding Agent,尤其是 DevOps 类的 Agent(如 K8s 运维助手)中表现亮眼。
  • Rust:占比 < 2%。
    除了 OpenAI 这种拥有无限工程资源的巨头敢用 Rust 重写 Codex,绝大多数独立开发者和创业公司似乎都对其敬而远之。

这个数据说明了什么?

说明在 Agent 这个特定的垂直领域,开发效率(Velocity) 已经彻底压倒了 运行效率(Performance)

对于一个每秒钟只能输出 50 个 Token 的 LLM 来说,你的程序是 1ms 响应还是 10ms 响应,用户根本感觉不到区别。但你能否在 1 天内上线一个新功能,用户感知极强。

第一性原理:为什么是 TypeScript?

TypeScript 之所以能赢,绝不是因为运气,而是因为它在基因层面契合了 AI Agent 的特性。

AI 的“母语”是 JSON,而 TS 是 JSON 的亲兄弟

这是最核心的原因之一。

大模型(LLM)与外部世界交互的通用协议是什么?是 JSON

无论是 Tool Calling(函数调用),还是 Structured Output(结构化输出),LLM 吐出来的都是 JSON。

  • TypeScript: 处理 JSON 是原生的。JSON.parse() 之后,直接当作对象操作。配合 TypeScript 的 Interface 定义,你可以获得极佳的类型提示,但又保留了运行时的灵活性。

    // TS: 轻松处理
    interface ToolCall { name: string; args: any }
    const call = JSON.parse(llmOutput) as ToolCall;
    
  • Rust/Go: 你需要定义严格的 Struct。如果 LLM 发疯,多返回了一个字段,或者把 int 写成了 string,你的 serde_json 或 json.Unmarshal 就会直接报错 panic。在 AI 开发中,你需要的是“宽容”,而 Rust/Go 给你的却是“严厉”。

“Vibe Coding” 需要松弛感

openclaw 作者提到的 Vibe Coding,本质上是一种“心流状态”。我想到了一个功能,告诉 AI,AI 生成代码,我运行,成功。整个过程行云流水。

  • TS 的体验: AI 生成了一段 TS 代码,可能类型有点小问题,用了 any,但能跑。我先跑起来看看效果,以后再修类型。It works > It is correct.
  • Rust 的体验: AI 生成了一段 Rust 代码。10分钟后编译器报错:“生命周期不匹配”、“借用检查失败”、“unwrap 可能会 panic”。你被迫停下来,花 30 分钟和编译器搏斗。你的 Vibe(氛围)瞬间没了。

在探索性开发(Exploratory Development)阶段,Rust 的严格性变成了阻碍。

生态位的降维打击:全栈与浏览器

Agent 不仅仅是在终端跑。它需要操作浏览器(比如使用Playwright),需要写 Chrome 插件,需要构建 Web UI。

在这些领域,TS 是唯一的王

如果你的 Agent 需要抓取网页数据,TS 有最成熟的库;如果你的 Agent 需要提供一个可视化的 Dashboard,TS 前后端通吃。

Rust 的尴尬与反击:退守“基础设施”

那么,Rust 真的输了吗?

从应用层来看,是的。但从基础设施层来看,Rust 依然是基石。

我们必须看清一个分层结构:

  • L0 (Infrastructure): 向量数据库 (LanceDB, Qdrant)、推理引擎 (像Candle)、高性能网关。这是 Rust 的领地。
  • L1 (Application): Agent 业务逻辑、流程编排、工具调用。这是 TypeScript 的领地。

Rust 并没有输,它只是退到了幕后。 Rust 成了 AI 的“地基”之一,而 TS 成了 AI 的“胶水”。

Agent 本质上就是把 LLM、数据库(记忆)、API 粘合在一起的胶水层。在这个层面上,灵活的胶水(TS)永远比坚硬的水泥(Rust)好用。

Go 的中间路线:CLI 界的“钉子户”

在这场战争中,Go 语言处于一个非常有趣的位置。它不像 TS 那么动态,也不像 Rust 那么死板。

Go 在 Agent 领域依然有一席之地,主要得益于两点:

  1. Single Binary (单文件分发):
    如果你写一个 CLI Agent 分发给用户,Go 编译出来就是一个二进制文件,扔过去就能跑。TS 还需要用户装 Node.js,装依赖(npm install 地狱)。对于 openclaw 这种本地工具,其实 Go 也是一个极佳的选择(虽然作者选了 TS)。
  2. 并发模型 (Goroutine):
    当我们需要构建 Agent Swarm (蜂群),比如同时启动 100 个 Agent 去爬取数据、分析情报时,Go 的 Goroutine 模型比 TS 的 Promise.all 更轻量、更可控,性能也更佳。

像 Beads 和 Gastown 这样的项目选择 Go,正是看中了它在工程化和并发上的平衡。

小结:语言没有优劣,只有“生态位”

Openclaw 的爆火和 Claude Code 的选择,向我们揭示了 AI 时代的一个新真理:

在 Agent 应用层,灵活性(Flexibility)和容错性(Forgiveness)是第一生产力。

  • 如果你想快速构建一个能够“听懂人话、调用工具”的 Agent,请毫不犹豫地选择 TypeScript
  • 如果你想构建一个高性能的 llm 路由网关、MCP Server 或 并发Agent编排工具,又或是Cli Agent,Go 是你不错的好帮手。
  • 如果你想造一个新的 向量数据库推理引擎,请拥抱 Rust

不要带着旧时代的“语言鄙视链”进入新时代。

在 AI 眼里,代码只是它实现目标的工具。它写 TS 最顺手,那 TS 就是最好的语言。

Rust 没有输,它只是太“硬”了,不适合在这个充满幻觉和不确定性的 Agent 世界里跳舞。


你的“Agent 母语”

TypeScript 的统治力看似不可动摇,但技术圈永远不缺变数。在你心目中,开发 AI Agent 的最佳语言是哪一门?你愿意为了开发效率而忍受 TypeScript 的类型体操,还是为了极致性能去啃 Rust 的硬骨头?

欢迎在评论区捍卫你的“本命语言”!让我们看看谁才是真正的 Agent 之王。

如果这篇文章颠覆了你的技术选型观,别忘了点个【赞】和【在看】,并转发给还在纠结学什么的兄弟!


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

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

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


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

🔲 ☆

Gas Town 启示录:多智能体编排开启 AI 编程工业革命

本文永久链接 – https://tonybai.com/2026/01/25/gas-town-multi-agent-orchestration-ai-programming-revolution

大家好,我是Tony Bai。

“启示录”(Apocalypse)在希腊语原意中并非仅指毁灭,更意味着“揭开面纱”。

2026 年的钟声敲响时,软件开发领域正经历着这样一场启示录。旧世界——那个由 IDE、手动键入代码、人类结对编程构成的世界——正在崩塌。我们拥有了前所未有的强大模型(Claude Sonnet/Opus 4.5、GPT-5、Gemini 3.0 Pro等),但当开发者试图用它们构建庞大的企业级系统时,却陷入了另一种混乱:我们被淹没在无数的 Prompt 中,我们在复制粘贴中迷失,我们变成了 AI 的保姆。

前 Amazon/Google 资深工程师、传奇技术博主 Steve Yegge 在其 57 岁生日之际,用一款名为 Gas Town 的工具,揭开了新世界的面纱。

他指出,行业的方向错了。我们一直在试图制造一只能够解决所有问题的“超级蚂蚁”(Super-Ant)。但纵观生物学与人类工业史,解决复杂规模化问题的从来不是一个个体,而是分工明确、协同工作的群体

Gas Town 的发布,标志着 AI 编程正式从 “单点辅助” (Level 6) 迈向 “集群编排” (Level 8) 。在这个新世界里,IDE 变成了过时的手工作坊,而 Gas Town 则是一座由 Go 语言 构建的、轰鸣作响的 AI 软件工厂

本文将带大家走进这片废土,见证多智能体编排如何开启这场工业革命。

软件开发的范式转移

开发者进化的终局

Steve Yegge 在其著名的《Revenge of the Junior Developer》中曾预言,AI 将赋予初级开发者对抗资深专家的能力。但他现在的观点更进一步:人类开发者必须进化为“编排者”(Orchestrator)。

为了厘清从“手工作坊”到“工业化生产”的演变路径,他在《Welcome to Gas Town》一文中,提出了一套精准的开发者 AI 进化等级论。首先,你需要在表格中找到自己的位置:

  • Stage 1: 零 AI 或近乎零 AI (Zero or Near-Zero AI)
    处于这一阶段的开发者,也许只使用基础的代码补全功能,偶尔向 Chat 问几个问题,工作流基本维持传统原貌。
  • Stage 2: IDE 中的编码智能体(权限开启)
    你开始使用 IDE 侧边栏里那个窄窄的编码 Agent。但你很谨慎,开启了所有权限拦截,Agent 每次运行工具或修改文件,都需要征求你的许可。
  • Stage 3: IDE 中的智能体(YOLO 模式)
    信任度建立。你关闭了烦人的权限询问,进入 YOLO (You Only Look Once) 模式。Agent 的权限变大,操作变得丝滑流畅。
  • Stage 4: IDE 中的宽屏智能体 (Wide Agent)
    Agent 逐渐反客为主,占据了屏幕的核心位置。源代码退居幕后,你不再逐行编写,而是在审阅 Agent 生成的 Diffs(差异)。
  • Stage 5: CLI 单体智能体 (CLI, single agent)
    你离开了 IDE,进入终端(CLI)。Diff 信息在屏幕上飞速滚动,你可能扫一眼,也可能根本不看,直接让它提交。
  • Stage 6: CLI 多智能体 (CLI, multi-agent)
    这是目前大多数高阶玩家的水平。 你经常在终端里并行运行 3 到 5 个 Claude Code 实例。你的编码速度非常快,远超常人。
  • Stage 7: 10+ 智能体(人工管理)
    你试图同时操作 10 个以上的 Agent,但你开始触碰到“人肉管理”的极限。窗口切换、上下文同步让你手忙脚乱,效率反而开始下降。
  • Stage 8: 构建你自己的编排器 (Building your own orchestrator)
    这就是 Gas Town 所在的领域,也是进化的终局。你站在了技术的最前沿,开始自动化整个工作流。你不再操作 Agent,你编排它们。

Gas Town 就是 Stage 8 的产物。当你有 30 个 Agent 同时工作时,你不再写代码,你是在管理产能


开发者AI进化的8个阶段

为什么是“工厂”?

Gas Town 的核心隐喻是“工厂”

在传统 IDE 模式下,AI 是你的结对编程伙伴(Partner)。这听起来很温馨,但不可扩展。你不能和 50 个人同时结对编程。

在 Gas Town 模式下,AI 是工人(Worker)。

  • 可替换性: 工人是“耗材”。一个 Agent 跑偏了、卡住了、上下文满了,直接销毁,启动一个新的接手。
  • 专业分工: 有的负责写代码,有的负责 Review,有的负责合并,有的负责打扫卫生。
  • 流水线: 任务在不同的 Agent 之间流转,而不是堆积在一个人身上。

解构 Gas Town —— 欢迎来到废土

Gas Town 的命名致敬了《疯狂的麦克斯》(Mad Max),暗示了 AI 编程早期的混乱与狂野。但在这层废土朋克的外衣下,是一套严密的分布式系统架构

基础设施:Town 与 Rig

Gas Town 采用了一种类似 Kubernetes 的层级架构:

  • Town (工作区): 对应 Kubernetes 的 Cluster。这是你的根目录(如 ~/gt),也是 gt 命令行工具管理的边界。
  • Rig (钻井/项目): 对应 Kubernetes 的 Node/Namespace。Town 下的每一个 Git 仓库就是一个 Rig。Gas Town 天生支持 Monorepo多仓库并行开发。你可以命令 AI:“在前端 Rig 加个按钮,同时在后端 Rig 写好 API。”

角色体系 (The Roles):智能体社会学

Gas Town 不使用通用的 AI,而是将 LLM 封装为特定的角色 (Persona)。每个角色都有独立的 System Prompt、上下文记忆和权限边界。

1. The Mayor (市长/经理)

  • 职责: 指挥官与交互入口。
  • 工作流: 用户通过 tmux 窗口向 Mayor 下达模糊指令(例如:“把登录页面的 CSS 丑陋问题修一下”)。Mayor 不会自己去修,它会分析需求,创建任务单(Beads),然后呼叫工人。

2. The Crew (船员/核心团队)

  • 职责: 你的贴身设计团队与长期雇佣兵。
  • 特性: Long-lived (长寿的)Named (有名字的)
  • 差异: 与一次性的 Polecats 不同,Crew 是你项目中的固定成员(你可以给它们起名,如 ‘Jack’, ‘Gus’, ‘Max’)。它们拥有持久的身份,直接向你汇报,不归 Witness 管辖。
  • 用途: 它们是 Gas Town 里的“高级脑力工作者”。你通常用它们来进行复杂的架构设计、深入的代码审查,或者生成给 Polecat 做的“燃料”(Guzzoline,即详细的任务清单)。你可以在 tmux 中快速循环切换不同的 Crew 成员,像检阅精英部队一样给它们派活,甚至可以指定其中一个为“PR Sheriff”(PR 警长)来专门管理代码合并。

3. Polecats (臭鼬/一次性工人)

  • 职责: 真正的执行者,耗材。
  • 特性: Ephemeral (短命的)。Polecats 是 Gas Town 的消耗品。它们是无状态的、用完即弃的。
  • 蜂群战术 (Swarming): 这是 Gas Town 最恐怖的能力。你可以瞬间启动 20 只 Polecats,并行处理积压的 20 个 Bug。它们各自拉分支、写代码、跑测试、提 PR,然后自我销毁。

4. The Refinery (炼油厂/合并专员)

  • 职责: 解决 Merge Hell (合并地狱)
  • 痛点: 当 20 只 Polecats 同时提交代码时,Git 冲突是必然的。
  • 机制: Refinery 维护一个合并队列 (Merge Queue)。它像一个冷静的守门员,依次将 PR Rebase 到主干,运行集成测试,解决冲突,合并代码。如果没有 Refinery,大规模的 AI 编程将不可持续。

5. The Witness (见证人/修复者)

  • 职责: 监控与运维。
  • 痛点: AI 经常会“发呆”(卡在等待输入界面)或陷入死循环。
  • 机制: Witness 像一个巡逻的监工,它不写代码,只盯着 Polecats 的状态。如果发现某个 Worker 长时间没反应,Witness 会执行 gt nudge(推一下)或重启该 Worker。

6. The Deacon (执事) & Dogs (猎犬)

  • 职责: 系统守护进程。
  • 机制: Deacon 运行在一个死循环中,维护系统的“心跳”。为了防止 Deacon 自己被繁重的杂务阻塞,它配备了一组名为 Dogs 的子 Agent,专门处理日志清理、状态同步等脏活。

核心机制:GUPP 与 NDI

Gas Town 的运行依赖两大理论基石:

GUPP (Gas Town Universal Propulsion Principle)

定义: “如果钩子(Hook)上有工作,Agent 必须运行它。”

LLM 通常被训练得非常礼貌,倾向于等待用户指令。Gas Town 必须打破这种“礼貌”。系统通过底层的事件循环,不断向 Agent 发送信号,强制驱动它们读取任务队列。

NDI (Nondeterministic Idempotence)

定义: 非确定性幂等性

在 Temporal 等传统编排系统中,工作流要求是确定性的。但在 AI 领域,同样的 Prompt 每次生成的代码都不同。

Gas Town 接受这种混沌。它不要求过程一致,只要求结果收敛。

  • Agent 崩溃了?没关系,新的 Agent 启动,读取 Git 中的状态(Checkpoint),继续干。
  • 代码写错了?没关系,测试挂了会触发新的 Loop,直到测试通过。

这就是 AI 时代的“最终一致性”。

技术核爆 —— MEOW 栈与 Beads 数据面

Gas Town 能够运转,不仅仅是因为 Prompt 写得好,更因为它底层有一套极具颠覆性的数据存储技术。这也是为什么它必须用 Go 重写的原因。

Beads:Git-Backed Graph Database

Steve Yegge 曾尝试用 SQLite 甚至文本文件来存储 Agent 记忆,但最终发明了 Beads

Beads 是什么?

它是一个分布式任务追踪系统,但它将 Issue(任务) 视为 Code(代码)

  • 存储: 每一个 Bead(任务单)是一个 JSONL 文件,直接存储在项目的 .beads/ 目录下。
  • 版本控制: 任务与代码同构。当你切换 Git 分支时,你的任务列表也会自动切换到该分支的状态。这对于 AI 理解“当前分支要干什么”至关重要。
  • 无冲突哈希: 为了支持分布式协作,Beads 不使用自增 ID(如 Issue #1),而是使用类似 Git 的哈希 ID(如 bd-a1b2),彻底解决了多 Agent 并发创建任务时的冲突问题。

MEOW 栈:分子级工作流

基于 Beads,Gas Town 构建了 MEOW (Molecular Expression of Work) 技术栈。

  • Atom (原子): 单个任务 Bead。
  • Molecule (分子): 可编程的工作流。它是一个由 Beads 链接而成的有向无环图(DAG)。
    • 例如:设计分子 -> 实现分子 -> Review 分子 -> CI 分子。
  • Wisp (游丝): 运行时的临时分子。它们在内存中流转,执行完即焚毁,不污染 Git 历史。

这套机制让 Gas Town 能够定义复杂的“软件生产配方”。你可以编写一个 Formula(配方),定义“如何修复一个 Bug”,然后让 100 个 Agent 同时执行这个配方。

为什么是 Go?(The “Boring” Advantage)

Steve Yegge 之前尝试过 TypeScript 和 Python,但最终 Gas Town (v4) 选择了 Go。这并非巧合,而是 AI 基础设施演进的必然。

  1. AI 生成代码的“质量悖论”:

    • TypeScript: 类型系统过于复杂。LLM 经常为了满足类型检查而生成大量无用的样板代码,浪费 Token 且容易产生幻觉。
    • Python: 动态类型导致运行时错误频发,且作为分发给用户的 CLI 工具,环境依赖管理是个噩梦。
    • Go: Go 的“无聊”是 AI 的福音。 Go 的语法简单、正交、缺乏花哨的语法糖。AI 生成的 Go 代码逻辑扁平(if err != nil),易于静态分析,且编译速度极快。在 Vibe Coding 的循环中,秒级编译意味着 Agent 可以更快地试错。
  2. 并发原语:
    Gas Town 本质上是一个高并发的编排系统。它需要同时管理数十个 tmux 会话、监控数十个 Agent 进程、处理并行的 Beads 数据读写。Go 的 GoroutinesChannels 让这种复杂的并发模型变得可控且高效。

  3. 云原生基因:
    Gas Town 的目标是成为 AI 时代的 Kubernetes。使用与 K8s、Docker、Terraform 相同的语言,意味着它可以无缝融入现有的云原生生态。

实战指南 —— Vibe Coding 与贝佐斯模式

Vibe Coding:氛围编程

在 Gas Town 中,编程不再是打字,而是一种“氛围编程” (Vibe Coding)

  • 你不再关注变量命名,你关注意图
  • 你不再关注函数实现,你关注验收标准
  • 实战场景示例:
    你告诉 Mayor:“给 Beads 项目加个功能,支持导出 CSV。”
    Mayor 创建 Beads,Witness 唤醒 Polecat。
    Polecat 1 写代码,Polecat 2 写测试。
    你不需要看中间过程。5 分钟后,Refinery 通知你:“PR 已准备好,测试通过,请验收。”
    你扫一眼 Diff,回复:“LGTM。”
    代码合并,任务结束。

贝佐斯模式 (Bezos Mode)

这种高效带来的副作用是 “决策疲劳”

Steve 称之为 Bezos Mode。就像杰夫·贝佐斯一样,你不再做执行层的工作,你整天都在做高维度的决策:架构评审、产品方向判断、风险评估。
这种高密度的决策会迅速耗尽大脑的“缓冲区”。Steve 及其团队发现,使用 Gas Town 后,他们每天下午必须强制午睡(Nap Strike),否则大脑会罢工。

这预示着未来开发者的核心竞争力,将从“编码速度”转变为“决策质量”。

终局 —— 工业化未来

编排器的战国时代

目前,Claude Code 只是“工人”,Loom 和 Ralph Wiggum 试图成为“包工头”,而 Gas Town 是唯一的“工厂”

Gas Town 不关注单个 Agent 有多强,它关注的是账本 (Ledger)审计 (Audit Trail)流水线 (Pipeline)。这才是企业级软件开发的刚需。

大公司的黄昏

Steve Yegge 做出了一个激进的预测:“一人一库” (One Engineer per Repo)

随着 Gas Town 类工具的普及,一个装备了 AI 军团的 3 人精英小组,其产出将吊打 100 人的传统开发部门。大公司内部繁琐的沟通成本,在 AI 的光速执行面前,将成为无法忍受的累赘。

未来的独角兽,可能只有 3 名员工,但拥有 3000 个并发运行的 Agent。

对于开发者而言,现在是时候放下 IDE,学习 Beads,去尝试驾驭那个疯狂、混乱但充满无限可能的 Gas Town 了。

小结:新世界的入场券

截至本文编写时,Gas Town 目前仍处于 v0.5.0 的早期阶段,它昂贵(消耗大量 Token)、危险(可能搞乱代码)、粗糙(基于 tmux)。但它代表了不可逆转的未来。

Gas Town 的出现,就是软件工程领域的“蒸汽机时刻”。它无情地宣告了手工作坊(IDE)时代的终结,并开启了工业化大生产(编排器)的序幕。

Go 语言凭借其稳健、高效和并发优势,再次赢得了这场 AI 基础设施战争的入场券。

“启示录”已经降临。旧世界的围墙正在倒塌,而 Gas Town 的大门已经打开。

因为正如 Steve 所说:“你是想继续做一只忙碌的蚂蚁,还是想成为那只在竹林里指挥若定的熊猫?”

Welcome to Gas Town.

The factory is open.

参考资料

  • https://github.com/steveyegge/gastown
  • https://github.com/steveyegge/beads
  • Welcome to Gas Town – https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04
  • Gas Town Decoded – https://www.alilleybrinker.com/mini/gas-town-decoded/
  • Beads best practices – https://steve-yegge.medium.com/beads-best-practices-2db636b9760c
  • The Future of Coding Agents – https://steve-yegge.medium.com/the-future-of-coding-agents-e9451a84207c
  • Gas Town Emergency User Manual – https://steve-yegge.medium.com/gas-town-emergency-user-manual-cf0e4556d74b
  • Stevey’s Birthday Blog – https://steve-yegge.medium.com/steveys-birthday-blog-34f437139cb5

你的“进化”阶段

Gas Town 描绘的未来令人心潮澎湃,也让人心生敬畏。对照文中的“8个进化阶段”,你目前处于哪一级?你准备好迎接“一人一库”的时代,还是更享受传统的结对编程?

欢迎在评论区晒出你的“等级”,或者分享你对多智能体协作的看法!让我们一起在废土中寻找新世界的坐标。

如果这篇文章点燃了你对 AI 编程的全新想象,别忘了点个【赞】和【在看】,并转发给你的极客朋友,邀请他们一起加入 Gas Town!


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

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

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


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

🔲 ☆

Cursor与Vibe Coding

Vibe Coding以及八卦

简单总结Vibe Coding:人利用AI生成代码完成大部分的软件开发任务。

我个人理解Vibe Coding的本质就是开发工作中的一种新的协作关系 —— 人专注于差异性工作,把能交给大模型做的工作尽量交给它去完成,充分发挥AI的可塑性、高效性等。

随着大模型底层基础能力的飞速迭代(例如Qwen3-Coder),AI的能力范畴正在变得越来越大,Vibe Coding的发展趋势就是自底向上蚕食程序员的工作范畴。

Vibe Coding的分层架构(理想)

以Cursor和Claude Code为代表Vibe Coding工具正在快速迭代,Vibe Coding的架构是时刻在演进和变化,我根据自己的理解比较理想化给出Vibe Coding的分层架构,与上面发展趋势图相对应,Vibe Coding发展到最后就是这张图只剩下蓝色框框没有其他颜色🥳。

Vibe Coding的八卦

关于Vibe coding的八卦,一图胜千文,其实目的还是想让好奇AI Assistant Coding的人知道它的优缺点,以及需要注意的事项。

Vibe Coding技术研究

AI Code Agent工作流

我总结了主流的几个AI Code Agent的架构:

1. Cursor Agent工作流
2. RooCode Agent工作流
3. Cline Agent工作流

综合来看,当下AI Code Agent的技术架构基本上都是类似的,主要的差异就是工具、策略等方面选择的差异。

AI Code Agent技术架构

以Cline架构为例对AI Code Agent架构进行管中窥豹

除了基础模型造成的差异之外,Cline建立的AI Coding的差异化竞争力主要在:

  1. Human in the loop: 这是Cline最根本的架构原则。通过要求用户对所有关键操作进行审批,它在强大的自主能力和专业开发所需的安全可控性之间取得了务实的平衡,使其成为可以信赖的工具;
  2. MCP实现的开放扩展性: Cline没有选择构建一个封闭的、专有的工具生态,而是全面拥抱了开放标准MCP。这不仅为其带来了无限的扩展能力,更使其成为一个能够自我完善、与社区共同成长的平台;
  3. 混合式上下文管理: 结合自动化分析和用户精确引导的上下文管理策略,是Cline能够有效处理大型复杂代码库的关键。它承认AI的局限性,并巧妙地将人类的领域知识融入到人机交互的循环中;
  4. 工具生态:代码理解、codebase index、AST、diff_apply等代码相关的工具生态支持Cline能够高效和准确的完成任务,同时支持可扩展性;
  5. 模型无关的灵活性: 通过稳健的 LLM 抽象层,Cline避免了对任何单一模型提供商的深度绑定。这使用户可以根据任务需求、成本预算和性能表现,自由选择最合适的AI“引擎”;

我们更进一步来拆解这些优势:

竞争力项目 Cline Cursor RooCode
Human in the loop
MCP生态支持
工具生态 AST RAG AST + RAG
混合上下文管理 Context Management Automated Context Management + Context Priority Management Intelligent Context Condensing
Agentic AI Model
Model apply edit 小模型

AI Code在卷哪些技术一目了然。

Vibe Coding应用

Vibe Coding 大致上有两种使用方法:

  1. 我需要个xxx(我需要xxx功能),帮我实现一下,然后一直retry;
  2. 我按照方案和架构设计原子化Vibe Coding任务,然后提供任务必要的信息,然后交给AI实现;

实践中,我发现方法1可以极大释放人力,有的时候AI给出的结果超出预期,唯一存在的问题就是人对于代码的信任度。方法2效率提升不如方法1,但是基本的代码实现以及项目进展情况人能够掌控,能够有效的避免AI Coding的几个问题:

  • 偷懒(例如,几次测试通不过直接在测试代码pass来绕过失败的case);
  • 用力过猛(例如,有现成的算法实现还自己重复实现一套);
  • 幻觉(例如,判断条件弄反了等);

基于上述经验,我对Vibe coding的采取的是不信任的态度,原子化任务保证我能够review检查代码(神仙也很难在2万行代码的PR里面准确挑出2-3个bug)。同时,如果是比较明确的任务并且已经有参考(例如已经有sqlite实现了,让AI完成mysql的实现)我就会采用方法1来提升效率。

另外,还有一种方式(我使用相对较少)—— 结对编程的方式,即向AI描述问题或者需求,然后AI规划方案,人来修改或者补充形成 todo list(plan),然后由AI实现。

最后,总结一下Vibe Coding的个人思考:想写一个demo直接扔给AI自动完成,当下的AI已经能够保证试错成本和效率了。想写一个生产使用的软件,自己把控方案设计和技术架构让Vibe coding作为帮助生成代码的工具,同时对Vibe coding始终抱着不信任的态度,时时review、处处检查。

几个重要原则

由于每个人使用AI Code工具以及编程习惯都不一样,所以有一些关键原则是需要注意的,其他可以自由发挥。

  • 最重要的原则,Curosr能写出符合要求的好代码的前提是它有足够的上下文,包括:项目、需求、架构、技术栈、编程约定等等;
  • 清晰的文档和注释,让Cursor获取更多的上下文;
  • AI更擅长修改和优化,新创造有一定的随机性,随着模型增强会改善;
  • 当下的Code Agent已经足够好了,特别是在Cursor,Cline等成熟产品中prompt可以更加自然语言些,类似「你是个xxx专家」这类激活专家系统的方式可以放弃了,省钱还省时间;
  • prompt engineering技巧的掌握和运用还是要持续升级,例如最近跟着Manus学会的response prefill技巧,使用<|im_start|>assistant<tool_call>{"name": "xxx"来控制工具调用的模式(自动、必需、指定等);
  • 有规划的拆分原子任务,一次只做一件事,有助于代码的准确性和可靠性;

几个重要概念

Agent/Chat/Tab

能够跨多个文件读取和修改代码的 AI。用自然语言描述更改,Agent 会执行这些更改。

Rules

定义 AI 行为的自定义指令。设置编码标准、框架偏好和项目特定约定。

Memory

持久存储项目上下文和过往对话中的决策。在未来的交互中自动引用。

codebase index/graph

对代码库进行语义分析。支持代码搜索、引用查找和上下文感知建议。

context

在代码生成过程中提供给 AI 模型的信息。包括文件、符号和对话历史。

基于Cursor的Vibe Coding

1. Cursor Rule设置

Rule的设置是为了让Cursor了解项目结构以及开发约定,包括:

  • 编码关于代码库的领域特定知识
  • 自动化项目特定的工作流程或模板
  • 标准化样式或架构决策

Rule编写时应该注意:

  • 保持规则在500行以内
  • 将大型规则拆分为多个可组合的规则
  • 提供具体的示例或引用文件
  • 避免模糊的指导。编写规则时要像清晰的内部文档一样
  • 在聊天中重复提示时重用规则

rules 结构示例如下图所示

另外一种Rule设置方法(来自Cline),Task Manager + Todo List的方式管理active context:

Task Manager的方式使用AI Code工具是比较进阶的使用方式,项目开发周期的缘故我还没生产实际中使用过,后续再研究和分享。目前这块有一些比较不错的实践经验可以参考:

2. 文档更新

我会在项目的docs目录中放置所有的项目相关的问题,包括技术选型、架构设计、模块说明、部署架构、使用手册等等,这样可以让人和AI都能够及时了解项目详细情况,一般修复问题或者新增feature的时候,我会将对应的文档添加到上下文中(@docs/xxx.md),帮着Agent能够更好的完成任务。

随着项目迭代和演进文档需要及时更新,不然会对AI形成误导导致无法正确地完成任务,所以我会形成固定的文档更新工作流。

flowchart TD Start([Start]) End([End]) Agent[Task Auto Trigger]:::redClass Developer[Triggered by Hand]:::blueClass Task[Document Update Process] subgraph AI-Process direction LR P1[Review Files] P2[Current State] P3[Clarify Steps] P4[Documents Change] P1 --> P2 --> P3 --> P4 end subgraph Review-Change Review[Developer Docs Change Review] Review -->| review ok? |Review Review --> Apply[Merge Changes] end Start --> Agent Start --> Developer Agent --> Task Developer --> Task Task --> AI-Process AI-Process --> Review-Change Review-Change --> End classDef redClass fill:#ffcd70,stroke:#333,stroke-width:2px; classDef blueClass fill:#97fcf9,stroke:#333,stroke-width:2px;

3. Cursor四大使用场景

  1. 功能实现,先给样例再给出功能实现的要求以及项目上下文
  2. 测试代码,给出测试规划并要求测试要求
  3. 修复问题,给出问题描述以及关键上下文
  4. 比较方案,对于无法很好解决的问题让Cursor给出方案以及比较

References

  1. Taskmaster AI - The PM for your AI agent
  2. Shrimp Task Manager - 為AI編程助手提供結構化任務管理的智能系統
  3. Waterfall, Agile, And AI: The Evolution Of Development · ProgrammerHumor.io
  4. OAuth provider library for Cloudflare Workers|一个由Claude实现的代码库
  5. cline-doesnt-index-your-codebase-no-rag-activity | LinkedIn

❌