阅读视图

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

Ruby on Rails 之父最新访谈:AI 正在推高顶尖程序员的身价

本文永久链接 – https://tonybai.com/2026/04/10/rails-father-dhh-on-ai-and-programmer-value

大家好,我是Tony Bai。

在这个由 AI 主导的、充满不确定性的 2026 年,整个软件行业似乎都被一种集体性的焦虑所笼罩。我们每天都在讨论:当 AI 能在一分钟内写完我们一周的代码时,我们这些“人类程序员”的价值还剩下多少?

就在所有人都在悲观地预测“程序员即将贬值”时,一位以“毒舌”和“极简主义”著称的硅谷大神,却逆着人潮,抛出了一个极其震撼的“反共识”暴论:

“我们可能已经见证了‘普通程序员’薪资的顶峰。但对于那些顶尖的、真正懂行的开发者来说,AI 正在让他们变得比以往任何时候都更值钱、更有价值。”

说出这句话的,正是 David Heinemeier Hansson (DHH)——Ruby on Rails 框架之父、37signals (Basecamp & HEY) 的联合创始人兼 CTO。

就在几个月前,DHH 还是 AI 编程最坚定的“喷子”之一。他曾公开嘲讽 Copilot 像个烦人的实习生,打断他的思路,生成的代码全是垃圾。

但在一场最新的深度访谈中,他却上演了一场惊天动地的“自我推翻”。他不仅承认自己已经“彻底投降”,更是将他现在的工作流形容为 “Agent First on Everything”(万物皆以智能体为先)

这场 180 度的惊天逆转背后,到底发生了什么?在这场信息量爆炸的对话中,DHH 不仅详细复盘了让他“觉醒”的那个“aha moment”,更对 AI 时代的程序员价值、团队协作、以及“软件匠艺”的未来,给出了极其深刻、甚至有些残酷的终极洞见。

从“令人作呕”到“欲罢不能”:DHH 的“觉醒”之路

DHH 坦言,在 Copilot 和早期 Cursor 的“代码补全(Autocomplete)”时代,他对此类工具的厌恶达到了顶峰。

“我感到无比愤怒。它总是在我还没想清楚的时候就试图猜我想写什么。‘你是想写这个吗?’‘你是想写那个吗?’ 闭嘴!让我自己把话说完!

他甚至一度悲观地认为,整个行业将走向一个由“Tab 键”驱动的、毫无思想的愚蠢未来,并开玩笑说自己可能要去丹麦种土豆了。

转折点发生在 2025 年的冬天。两个关键变量,彻底改变了游戏规则:

  1. 模型的质变:Anthropic 的 Claude Opus 4.5 模型发布。DHH 发现,这个模型生成的代码质量,第一次持续地、稳定地震惊到了他。它产出的代码,在很多时候,是他自己也愿意合并的。
  2. 交互范式的革命:以 Open Code 和 Claude Code 为代表的 Agent Harnesses出现。AI 不再是那个烦人的“代码补全机”,而是变成了一个可以独立使用工具(Bash、网络)、拥有自己终端的“数字同事”。

DHH 形容,当这两个变量结合在一起时,他迎来了职业生涯的“第二次启蒙”——上一次,是 2000 年初他第一次发现 Ruby 语言的优雅。

“我不再是那个在键盘上打字的人,我感觉自己像是穿上了一套超级机甲。我突然长出了 12 只手,可以同时操作 7 个屏幕。我作为程序员的能力,被极度放大了。

我们可能已经度过了“程序员薪资的顶峰”

当被问及 AI 是否会取代程序员时,DHH 毫不避讳地抛出了一个极其冷酷的观点:

我们很可能已经见证了“程序员(作为一种普通职业)”的黄金时代顶峰。

他认为,在过去,程序员之所以能获得极高的薪资,是因为他们是生产软件的“瓶颈资源”。产品经理想出一个绝妙的点子,必须排队等待昂贵的程序员花几周时间才能实现。

但现在,瓶颈正在快速转移。

“当产品经理自己就能用 AI 生成可用的代码时,事情就要变天了。在任何一个软件开发被视为‘成本中心’(而这恰恰是世界上绝大多数的软件开发场景)的公司,降薪和裁员的压力将是不可避免的。”

但这是否意味着所有程序员都会被淘汰?

恰恰相反。DHH 认为,AI 正在引发一场剧烈的“价值两极分化”

  • 中间层的崩溃:那些只会“把需求翻译成代码”的普通程序员,其价值正在被无限稀释。因为 AI 做这件事更快、更便宜。
  • 顶尖人才的价值飙升:那些具备极高“品味(Taste)”、“审美(Aesthetics)”和“架构判断力”的资深工程师,他们的价值正在被 AI 放大 10 倍甚至 100 倍。

因为他们是那个能够判断“AI 生成的东西是对是错、是美是丑”的最终把关人。他们从“体力劳动者”,进化为了“艺术总监”。

当 AI 能写所有代码,我们还剩下什么?

在这场对话中,DHH 反复强调一个词:Aesthetics is truth(美学就是真理)。

他认为,无论是在数学、物理学还是软件工程中,一个优美的解决方案,往往也正是那个正确的方案。

“乔布斯之所以关心 Mac 电脑机箱内部的走线,是因为他凭直觉知道,只有那些在乎印刷电路板布局的人,才会去死磕用户界面的每一个像素。

在 AI 时代,这种对“美”的追求,不仅没有过时,反而变得空前重要。

因为当你拥有了无限的“算力(AI)”时,唯一稀缺的,就是“品味(Taste)”

DHH 认为,未来顶尖的软件工程师,其核心竞争力将不再是“知道多少种排序算法”,而是:

  1. 产品感:深刻理解“我们应该做什么,不应该做什么”。
  2. 系统设计能力:将模糊的业务需求,抽象为清晰、优美的架构。
  3. 极高的审美标准:能够引导 AI 生成不仅能工作、而且看起来赏心悦目、易于维护的代码。

代码的实现,正在变得廉价;而代码的“品味”,正在变得无价。

大神的日常:我是如何指挥 AI “军团”的?

DHH 详细分享了他现在的“Agent-First”工作流,堪称教科书级:

他使用 tmux 在终端里创建了一个三分屏布局:

  • 左侧是 Neovim 编辑器。
  • 右上是跑着 Google Gemini 的 Open Code。
  • 右下是跑着 Claude Opus 的 Claude Code。

“我几乎所有的工作都从其中一个 Agent 开始。我给它一个模糊的指令,然后看着它生成初稿。然后我把初稿扔给另一个 Agent,让它去批判和重构。我让它们俩来回‘吵架’。最后,我再跳到 Neovim 里,做那个最终的‘裁判’。”

他分享了一个让他自己都感到震惊的案例:

37signals 的 Linux 发行版 Omarchy 积压了 250 个无人处理的 PR。他花了 90 分钟,让 Claude 帮他审完了其中 100 个。

  • 10% 直接合并。
  • 20% Claude 觉得思路对,但实现太烂,直接帮他重写了一版。
  • 剩下的大部分,要么被他判定为“不需要”,要么被 Claude 识别为“实现太差且没有好思路”,直接关闭。

“这在以前至少是一周的工作量。更重要的是,其中一半的 PR 涉及我不懂的领域,Claude 在那些领域,是比我更聪明、更优秀的审查者。”

野心的爆炸:探索一个直觉的成本,已被降低一千倍

DHH 在访谈中提到了一个极具启发性的概念:AI 正在让“雄心(Ambition)”变得廉价。

他举例,他让 Agent 在几天内,为一个搁置已久的需求(为 Omarchy 实现 Windows 双系统启动)制定了一套完整的、可执行的方案。而在过去,他连花 4 个小时去调研的意愿都没有。因为这件事“重要但不紧急”,而且“非常麻烦”。

“探索一个直觉的成本,已经被降低了一千倍。我们现在可以去挑战那些过去连想都不敢想的项目。”

他分享了 37signals 内部的一个真实案例:一位名叫 Jeremy 的工程师,利用 AI 发起了一个名为“P1 优化”的疯狂项目。他要去优化系统中那最快的 1% 的请求,让它们变得更快。

这在传统性能优化的世界里,简直是“吃饱了撑的”。

但 Jeremy 仅用了几天时间,通过让 Agent 疯狂分析和重构,提交了 12 个 PR,硬生生把这 1% 请求的延迟从 4ms 压缩到了 0.5ms 以下,实现了 10 倍的性能提升。

当探索的成本趋近于零时,过去那些被视为“无用功”的边缘优化,将共同汇聚成压倒性的产品优势。

小结:这是一场关于“手艺”的文艺复兴

在访谈的结尾,DHH 表达了他对未来的极度乐观。

他认为,AI 并没有让编程变得无趣,反而让他找回了自 2000 年初发现 Ruby 以来最大的快感。

DHH 的这场“觉醒”,不仅仅是一个技术大佬对新工具的拥抱。它更像一个宣言:

在 AI 时代,软件工程的“手艺(Craft)”并没有消亡,它只是从“雕琢代码”的微观层面,升维到了“塑造品味”与“驾驭系统”的宏观层面。

AI 正在无情地淘汰那些只会“拧螺丝”的码农,但同时,它也为那些真正热爱创造、拥有极高审美和品味的“工匠”,递上了一把前所未有的神兵利器。

你,准备好拿起它了吗?

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


今日互动探讨:

在使用 AI 编程后,你是否也像 DHH 一样,感觉自己的“野心”被放大了,敢于去挑战更复杂的项目?在你的工作中,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. 版权所有.

🔲 ☆

从 P2H 到 P2A2H:软件架构的终极倒置——为智能体设计软件

本文永久链接 – https://tonybai.com/2026/02/12/p2h-to-p2a2h-software-architecture-inversion-designing-for-agents

大家好,我是Tony Bai。

回顾过去 50 年的软件工程史,无论技术栈如何更迭——从汇编到 C,从 Web 到 Mobile,从单体到微服务——其核心的生产关系从未改变。

这种关系被称为 P2H (Programmer to Human):即程序员(Programmer)揣摩人类(Human)的需求,将其固化为代码,构建成功能确定的软件产品,最后交付给用户使用。

在这个模型中,程序员是“权威”。我们决定了按钮在左边还是右边,决定了业务流程是三步还是五步。用户必须削足适履,去学习和适应软件的逻辑。

然而,这种模式正面临前所未有的危机。

人类的需求是无限且流动的(“我想分析一下上个月买咖啡的钱占总支出的比例”),但程序员编写的代码是有限且刚性的(“抱歉,App 只有‘按类别查看支出’的功能”)。

这个供需矛盾,导致了无穷无尽的需求变更、功能堆砌,最终造就了难以维护的“软件屎山”。

但是,AI Agent 的出现,打破了这个死结。

我们在程序员和用户之间,插入了一个拥有无限耐心、通晓所有 API、且具备动态生成能力的“超级中间商”——智能体(Agent)

软件架构正在经历一场“哥白尼时刻”般的倒置:我们不再直接为人类编写软件,我们正在进入 P2A2H (Programmer to Agent to Human) 的新纪元。

定义 P2A2H:供应链的重构

P2A2H 不仅仅是工作流的变化,它是软件产业链的彻底重组。

1. Programmer (P):工具制造者

在 P2A2H 模型中,程序员退守到了基础设施层。我们不再直接编写面向最终用户的业务逻辑(Business Logic),而是编写原子能力(Atomic Capabilities)、工具(Tools)、规则(Rules)和护栏(Guardrails)。我们是“造物主”,负责定义物理定律,而不是搭建具体的房子。

2. Agent (A):运行时环境与超级工人

Agent 成了新的 Runtime。它接收 Human 的模糊意图,实时调用 P 提供的工具,即时生成(Just-in-time) 或 动态编排 出满足特定需求的解决方案。它是“超级工人”,也是“软件本身”。

3. Human (H):指挥官

用户不再是被动的操作者,而是主动的指挥官。他们不再需要学习“如何使用软件”,因为软件会根据他们的意图自动重组。

这意味着,软件工程的重心,正在从“人机交互 (HCI)”转移到“机机交互 (M2M)”与“智能体体验 (AX)”。

P2A (Programmer to Agent):什么是“智能体体验 (AX)”?

过去,我们谈论 UX(用户体验),我们关注的是按钮是否好点、颜色是否悦目、文案是否感人。因为人类是感性的、迟钝的、容易犯错的。

现在,我们需要谈论 AX (Agent Experience)

因为你的代码的第一用户不再是人,而是 AI。AI 是理性的、极速的、但也是极其依赖上下文的。

为了实现高效的 P2A,我们需要对现有的软件架构进行三大重构:

1. API 的重构:从“简洁”到“自描述”

在 P2H 时代,我们追求 API 的简洁。如果出错了,返回一个 404 Not Found 或者一段给人看的 User not authorized 就足够了。

但在 P2A 时代,这种 API 是不合格的。Agent 是一个黑盒,当它收到一个错误时,如果缺乏上下文,它会陷入“幻觉”或死循环。

Agent-Friendly API 的设计原则:

  • Verbose Error (详尽报错):错误信息不仅要说是错的,还要说为什么错以及怎么改。

    // Bad for Agent
    { "error": "Invalid Input" }
    
    // Good for Agent (AX)
    {
      "error": "InvalidDateRange",
      "message": "Start date cannot be later than end date.",
      "schema_ref": "#/definitions/DateRange",
      "suggestion": "Swap the start_date and end_date parameters."
    }
    

    只有这样,Agent 才能利用其推理能力实现Self-Correction(自我修复)。

  • Hypermedia / HATEOAS (Hypermedia as the Engine of Application State) 的回归:API 应该告诉 Agent 下一步能做什么。这种在 Web 2.0 时代被嫌弃的繁琐设计,在 Agent 时代可能迎来复兴,因为这为 Agent 提供了导航图。

2. 文档的重构:从 Readme 到 Spec

以前写文档是为了让同事看懂,充满了“请注意”、“通常情况下”这种模糊词汇,甚至还配了大量截图。

Agent 看不懂截图,也讨厌模糊。

未来的文档将演变为 Spec(规范说明书)和 Schema(模式定义)。

  • OpenClaw (原Moltbot) 的启示:为什么 Moltbot 强调“要连接 xx,就写一个 CLI”?因为 CLI 的 –help 文档就是最标准、最结构化的 Prompt。
  • MCP (Model Context Protocol):为什么 MCP 会火?因为它本质上就是一种 P2A 协议。它强制程序员用 JSON Schema 清晰地定义资源(Resources)、提示词(Prompts)和工具(Tools)。这实际上是在为 Agent 建立世界模型。

3. 工具的重构:Headless First

图形界面(GUI)是给人类的“降维打击”,而命令行(CLI)和 API 才是机器的“母语”。

在 P2A2H 架构中,所有的功能必须优先实现 Headless(无头模式)。

  • 反模式:想要查询数据,必须登录网页后台,点击三次菜单,导出 CSV。Agent 很难操作(需要调用昂贵的视觉模型)。
  • AX 模式:提供一个 query_data 的 CLI 或 API。Agent 可以通过管道(Pipe)直接处理数据流。

程序员的新格言:不要构建只能用鼠标点击的功能。如果它不能被脚本调用,它就不存在。

A2H (Agent to Human):软件的“液态化”

当 P 为 A 准备好了完美的工具箱,A 将如何为 H 服务?

这将导致软件形态的终极质变——从“固态产品”变成“液态服务”。

1. 一次性软件 (Disposable Software)

想象这样一个场景:

用户(H)对 Agent 说:“我想统计一下家里两只猫过去三年的医疗花费,并对比一下猫粮价格的波动,生成一个图表。”

  • P2H 模式:用户需要去 App Store 找一个“宠物记账 App”,如果 App 没有“猫粮价格对比”功能,用户就没辙了。
  • P2A2H 模式:
    1. Agent 理解意图。
    2. Agent 调用 P 提供的“数据库工具”抓取账单,“OCR 工具”识别发票,“搜索工具”抓取历史粮价。
    3. Agent 现场编写 一个 Python 脚本,进行数据清洗和绘图。
    4. Agent 运行脚本,把图表展示给用户。
    5. 任务结束,脚本销毁。

这个“软件”(Python 脚本)只存在了 5 分钟。它不是为了 100 万人设计的,它是为了这 1 个用户在这一刻的特定需求设计的。

软件不再是名词,而变成了动词。

2. 生成式 UI (Generative UI)

既然功能是动态的,界面为什么必须是静态的?

在 P2A2H 架构中,程序员不再纠结按钮放左边还是右边。程序员只提供 Design System(设计系统)和 UI Components(组件库)。

Agent 会根据用户当前的设备(手机/VR眼镜)、视力状况、使用习惯,动态渲染 出最适合当下交互的界面。

  • 对于老人,Agent 生成大字体、语音交互优先的界面。
  • 对于极客,Agent 直接生成一个 Dashboard 或 CLI 界面。

UI 不再是设计师的画布,而是 Agent 与人类沟通的即时语言。

挑战与思考:程序员的门槛是降了还是升了?

有人可能会问:“如果 Agent 能自己写脚本、自己生成 UI,那程序员是不是要失业了?”

答案恰恰相反。在 P2A2H 模式下,程序员的门槛被极大抬高了。

1. 从“实现者”到“抽象者”

以前,你只需要写代码实现业务逻辑(Implementer)。

现在,你需要设计“能让 AI 理解并正确使用的工具”(Toolmaker)。这要求你具备极强的抽象能力。如果你设计的工具边界不清,或者副作用(Side Effects)未被隔离,Agent 可能会拿着你的工具把生产环境搞崩。

2. 安全与护栏 (Safety & Guardrails)

当 Agent 拥有了自主权,P 的核心职责变成了“设置护栏”。

  • 如何防止 Agent 生成恶意 SQL?
  • 如何防止 Agent 在执行“清理文件”任务时误删系统关键数据?
  • 如何确保 Agent 生成的 UI 不包含欺诈信息?

程序员成了 Agent 物理世界的守门人。我们需要编写大量的 Validator(验证器) 和 Sandbox(沙箱)策略,来约束这个强大的数字劳动力。

3. 元编程 (Meta-Programming)

P2A2H 本质上是最高级的元编程——编写“编写程序的程序”的规则。

你需要思考的不是 if (x > 0),而是“如何定义规则,让 Agent 知道在什么情况下应该生成 if (x > 0)”。

小结:从工匠到“神”

在 P2H 时代,程序员是工匠。我们雕琢每一个像素,优化每一行 SQL,为了满足用户的需求疲于奔命。

在 P2A2H 时代,程序员的角色更接近于“神”(造物主)。

我们创造法则(Specs),锻造神器(Tools),赋予智慧(Context),然后放手。

让那些不知疲倦的智能体(Angels),去响应人类的祈祷,去构建那个千变万化的世界。

这是一次伟大的升维。

别再盯着那个该死的按钮颜色了,去设计能让 Agent 自由飞翔的 API 和 Tools 吧。


你准备好成为“工具制造者”了吗?

软件正在从“固态产品”变成“液态服务”。在这种架构倒置的未来,你认为程序员最不可被 AI 替代的能力是什么?你会为了 AX(智能体体验)而主动增加 API 的“繁琐”程度吗?

欢迎在评论区分享你的架构构想!


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

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

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


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

🔲 ☆

承认吧,AI 写的代码,平均质量已经超过了 80% 的人类程序员!

本文永久链接 – https://tonybai.com/2026/02/05/ai-code-quality-surpasses-80-percent-of-human-programmers

大家好,我是Tony Bai。

随着 Claude Code、Gemini Cli、OpenCode 等 AI 智能体编程工具的爆火,技术圈里出现了一种流行的论调:

  • “AI 写的代码质量不高,全是 Bug。”
  • “简单的还行,复杂的还得靠人。”
  • “AI 也就是个实习生水平。”

这些批评有道理吗?当然有。AI 确实会产生幻觉,逻辑偶尔会断裂。

但这种批评忽略了一个最基本的事实:我们拿来对比的基准(Baseline),往往是我们心目中“理想的资深工程师”。

请现在、立刻、马上打开你公司的 Github私有库或GitLab,随便点开一个两年前的遗留项目,看看里面的代码:

  • 那些随意的变量命名 tmp, data1;
  • 那些长达 800 行、没有任何注释的上帝函数;
  • 那些为了赶上线而写死的 Magic Number;
  • 那些复制粘贴了 5 遍却忘了改参数的逻辑……
  • … …

这才是人类编码的常态。

如果我们摘下“幸存者偏差”的滤镜,从全局视角的大数定律来看,一个残酷的真相正在浮出水面:

AI 写的代码,虽然缺乏神韵,但其平均质量,可能已经超越了80%的人类程序员。

人类的“熵增” vs. AI 的“基准线”

人类写代码,本质上是一个对抗熵增的过程。而人类在这个过程中充满了弱点:

  • 情绪与疲劳:下午 5 点写的代码,质量通常低于上午 10 点。为了赶着回家,我们会下意识地省略错误处理(catch (e) { // TODO })。
  • 知识盲区:即使是高级工程师,也记不住所有正则表达式的语法,或者某个冷门 API 的最佳实践。
  • 懒惰:没人喜欢写文档,没人喜欢写单元测试。

相比之下,AI 简直就是代码规范的狂热信徒。

  • 标准化:只要你 Prompt 给对了,它生成的代码默认符合 PEP8、Google Style、Effective Go 或任何你指定的规范。
  • 全面性:它不厌其烦地写 Docstring,写类型注解,写样板代码。这些人类最讨厌干的脏活,是 AI 的舒适区。
  • 无情绪:它不会因为被产品经理气到了,就故意写一段晦涩难懂的代码报复社会。

AI 也许写不出 Linux 内核那样的神作(上限),但它绝对不会写出连缩进都乱七八糟的垃圾。它极大地拉高了代码质量的底线。对于商业软件而言,底线的提升,往往比上限的突破更有价值。

自动驾驶的启示:一场“平庸”的胜利

我们可以用自动驾驶来做一个绝佳的类比。

每当特斯拉撞上路桩,媒体都会大肆报道。人们会说:“你看,机器还是不靠谱。”

但我们忽略了,此时此刻,全世界有成千上万的人类司机正在因为酒驾、看手机、打瞌睡、路怒症而制造车祸。

统计数据最终会证明:只要 AI 的故障率低于人类的平均故障率,它就是巨大的进步。

编程也是一样。

AI 编程的终局,不是写出完美无瑕的代码,而是写出比“人类平均水平”更可靠的代码。

当 AI 写的代码自带测试、自带文档、没有低级语法错误时,它就已经赢了。它消灭了“垃圾代码”。这将是一场“平庸的胜利”——软件工程将不再依赖个别天才的灵光一闪,而是依赖工业化、标准化的稳定产出。

范式转移:从“写代码”到“审代码”

如果承认 AI 已经是中级工程师水平,那么人类的角色必须发生根本性的转变。

以前,我们是 Coder(代码作者)。现在,我们被迫成为了 Reviewer(审查者)和 Architect(架构师)。

这其实对人类提出了更高的要求。

  • 阅读理解能力:AI 一秒钟生成 100 行代码,你是否有能力在 10 秒内看出其中的逻辑漏洞?
  • 系统设计能力:既然“搬砖”的工作 AI 做得比你好,你必须去思考“砖头该怎么垒”——系统架构、数据模型、业务边界。

更关键的是“自动化验证”。

既然人类读代码的速度跟不上 AI 写代码的速度,我们就必须建立一套“机器审查机器”的机制。

  • AI 写代码,AI 写测试。
  • AI 写实现,Compiler/Linter 做检查。

未来的软件质量,将不取决于你手写了多少行代码,而取决于你设计了多严密的护栏(Guardrails)和验收标准(Spec)。

小结:拥抱“无人编程”时代

我们可能正在经历软件工程领域的“无人驾驶时刻”。

初期,我们需要“安全员”(人类程序员)手扶方向盘,随时准备接管。

但随着模型能力的迭代(如 GPT-5.2、Gemini 3.0 Pro、Claude 4.5 Opus等),接管的频率会越来越低。

最终,“人类手写代码”可能会被视为一种不安全的行为——就像现在“酒后驾车”一样。

因为人类是不稳定的、不可控的。而经过严格 Prompt 工程和测试约束的 AI,是稳定、可控、可追溯的。

承认 AI 比我们写得好,并不丢人。

这意味着我们可以从繁琐的语法细节中解放出来,去追求那 1% 的“神来之笔”——创造力、同理心和对未来的想象。


你怎么看这个“80%”?

你认同这个残酷的结论吗?在你看来,AI 生成的代码最让你放心的地方在哪里?最让你担心的地方又在哪里?欢迎在评论区开启你的辩论模式!

如果这篇文章戳中了你的“痛点”,别忘了点个【赞】和【在看】,并转发给你的开发伙伴,看看他们敢不敢“承认”!


如何做 AI 的“安全员”?

AI 的代码质量已经超越了大多数初级工程师。作为一个“AI 时代的 Tech Lead”,你该如何建立一套机制,来驾驭这股庞大的算力?

在我的极客时间专栏《AI 原生开发工作流实战》中,我们不谈如何写代码,而是谈如何审代码,如何构建 Test-Driven 的自动化护栏

  • 如何利用 Claude Code 自动生成高覆盖率的测试用例?
  • 如何构建 AI Code Reviewer 来预审代码?
  • 如何用 Spec 约束 AI,防止幻觉?

让我们一起,从“写代码的人”,进化为“定义代码标准的人”。

扫描下方二维码,开启你的进阶之旅。


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

❌