大家好。很荣幸作为开发者代表来讲讲《AI 革命》这个话题。
开始之前，我想先回看下过去。现在最火的可能是龙虾或者 code agent，那么以前呢？
如果要讲「AI 革命」之最初想象，大家会想到什么？
答案是机器翻译。
在 70 年前“人工智能”刚诞生的年代，人们对 AI 的想象并不是“写代码”，而是“让机器像人一样处理语言”。
机器翻译是最早一批能被公众直观想象的 AI 杀手级应用。
1954 年 Georgetown–IBM 用 IBM 701 做了一次公开演示，把 60 多句俄语句子自动翻成英文，大家想一下这个时间点，这效果在当时绝对非常震撼。
当然这实际只是 demo：大约 250 个词汇、6 条语法规则，句子也经过挑选。
但媒体高潮了：再过三到五年，机器翻译就会变成“基本解决”的技术。
现实呢？
我在 2015 年做过一个“翻译对照”小实验，把技术文章中的一小段话的三段机翻和一段人翻放在一起让大家猜。
当时机翻和人翻几乎还是能一眼分出来，哪怕是质量不咋高的技术翻译水平。
现在呢？如大家所料，大模型译文质量极高，而且能精准评价翻译质量。
Deepseek 它评价豆包是初级或中级人类译者，评价自己是资深译者或顶级 AI，评价前辈则像早期的机翻或英语水平欠佳的人类生硬直译。
我的小实验恰好在 2016 Google 发布 GNMT 之前，这项技术标志机器翻译在发展了60年后终于“达到人类水平”，真正开始冲击翻译行业，然后再过10年，2026，LLM 基本上是给翻译行业的棺材板钉上了最后一颗钉子。
回到今天的主题，我们从开发者视角看看 AI。其实编程和翻译似乎是相当类似的。
翻译，是一种自然语言的符号体系转换到另一种。编程，是把需求这种自然语言，转换到形式化符号，也就是编程语言。
那么软件开发这个行业，也会像翻译那样完全 AI 化，进而凋亡吗？
如果像翻译那样 60、70 年后消亡，倒也可以不用在意。但按照现在模型和 code agent 的疯狂节奏，不是 70 年，也不是 70 个月，可能 70 天之后就翻天覆地。
过去20年，开发者群体大体上是每 5 年翻一番，尽管现在开发者群体还在增长，但未来呢？
大家会担心，即使行业还在，但人都被 AI 取代。大家对开发者群体继续增长缺乏信心，而且怀疑将萎缩。
所以我对当前开发者状态的概括是：既被 AI 打了鸡血，又对 AI 非常焦虑。
继续之前简单介绍一下我自己。
我是谁？贺师俊，知乎上就是这个实名，欢迎关注。GitHub 上 @hax 。
我是已经干了 25+ 年的老程序员。长期搞 Web 前端。
2003 年就参加了 W3C 在北京举办的第一次大会，2019 年我成为 TC39 代表，也就是 JavaScript 标准委员会成员，2020 年到 2023年我有幸担任了 OpenAtom 中国首个开源基金会的技术监督委员会成员。
我的技术领域原本和机器学习啊，AI啥的没啥关系。不过在这轮 LLM 热潮起来之后，我在 2023 到 2024 年，也在一家创业公司搞了一段时间 AI Agent。当时我们算是最早一批让 LLM 在沙箱里直接操作 shell 的 agent。可以说是先驱吧，不过最后变成了先烈。
到 2025 年，我又回到了“传统”的前端技术基建。
回归的一个原因是，2024 年底时我觉得 code agent 的能力主要来自于大模型。模型能力不到时，怎么优化，如果以做工程的最终目标来评估，提升其实很有限，因此感觉做的事情意义不大。
果然，模型厂商亲自下场后，code agent 突飞猛进。短短一年后，code agent 已经完全改变了开发方式。
最简单一点就是，从 2025 年第四季度开始到现在这半年时间，几乎大部分程序员已经放弃古法编程了，可能还有少数遗留，但这可能只是时间问题。
所以我今天讲这件事，一半是观察，一半也是亲历。
如果看过去三年，开发工具和方式的变化非常快，是从 AI 补全一路走到 Code Agent。
开发者和 AI 的协作方式，其实已经经历了四个很不一样的阶段。
而且可能是跨越式的，像我这种比较保守的程序员，即使在搞 AI agent 时，才刚用上 AI 补全，说实话都还没完全适应，转眼刷一下就快进到了 Code Agent。
先说第一阶段，就是传统补全增强。
2021 年 6 月 29 日，GitHub Copilot preview 发布，这是这一阶段的起点。AI 开始以 autocomplete 的形式大规模进入 IDE。
BTW，记住这个日子。以后要定古法编程纪念日的话，就选 6 月 28 日。
第一阶段的核心特征是，AI 主要做补全和片段生成，开发者的局部体验提升了，其实有时候也未必，但开发者的整体开发方式并没有变。
这一阶段，AI 名副其实就是副驾。
你敲一点，它续一点；你写个注释，它补一段。
第二阶段，是超级补全加多文件编辑。
代表性产品，是 Cursor，硬是在 IDE 这个红海杀出了一条路。
2024 年 7 月，Cursor 推出 Composer 和 multi-file edits：AI 不再只补一段，而是开始跨多个文件一起改。
这一阶段，输出单位已经从 snippet 变成 patch set。
使用“超级补全”后，开发者开始无脑 tab，工作慢慢开始更多地 review diff，而不是复制粘贴代码块。
这时瓶颈也变了。不再只是模型聪不聪明，而是上下文是不是够、改动范围是不是可控、diff 能不能 review、结果能不能回退。
第三阶段，我把它叫做指挥式编程。
这阶段，大家从动手逐渐变成了动嘴——或者说虽然你可能还是用键盘输入，但输入的东西发生了变化。
先是 vibe coding。
2025 年 2 月 2 日，Karpathy 把 vibe coding 这个词讲火了。
不过马上大部分程序员就会问：这不是造屎山吗？能维护吗？
于是 spec-driven 也来了，也就是先指挥 AI 写 spec，再让 AI 根据 spec 写代码。
这一波里我找个代表性的吧，2025 年 9 月，Spec Kit 把 spec、technical plan、task breakdown 这套流程直接产品化。
spec-driven 不是某个人在某一天突然发明的，更像是 2025 年中后期，强调软件工程严谨性的人群对 vibe coding 的反弹。
不过呢，vibe 还是 spec，这个争论其实还没分出胜负就过气了。
因为到了2025年年底时，很清楚的，第四阶段已经来了，就是 Code Agent，再明确点就是最近的 harness engineering。
第四阶段，AI 不再只是写代码或者写文档，而是开始自己拿工具、跑链路、操作你的电脑，产出交付物。
其实这个讨论可以追溯到 2024 年 3 月 Devin，包括我当时所在创业公司也做了类似的：它先证明了“直接操作电脑（通常是通过 shell） 的 agent”这条路能成立。
但真正让这个阶段成型的，是模型厂商自己下场。
读代码、改文件、跑命令，这三个动作连起来，意义就完全不一样了。
2025 年 2 月，Claude Code 进入研究预览后，一个很大的变化是：模型厂商不再只卖 API，而是亲自把 agent 做进终端工作流，给开发者兜售 code plan。
2025 年 5 月，GitHub Copilot Coding Agent 又把这件事进一步带进 GitHub 自己的 SDLC：assign issue，异步工作，推 draft PR，附 session logs，人类批准后再继续。
也就是说，issue 可以直接变 PR。
我自己就是在 10 月份尝试了 GitHub Copilot agent 之后，感到时间点到了。
到这里，AI 已经不只是副驾，也不只是结对程序员，而是开始像团队成员一样进入真实交付链条。
之后 OpenAI Codex 也不再只是历史名词，而是重新以 CLI 和 agent 形态进入开发现场。
国内的模型厂商也是如此。
总之模型厂商全面取代创业公司自己做 agent，模型提供方亲自定义产品、交互和责任边界。这样马后炮看来我当时从创业公司撤退确实是正确的。
目前我们还处于这个阶段中，下一个阶段会是怎样呢？目前还不清楚，但有一点是明确的，开发者的开发模式已经永久得被改变了。
接下来我想讲一下 AI 改变开发方式后，对实际项目的影响，抛开龙虾之类本身就是 AI 高度相关的项目，我们看产品本身并不直接和 AI 相关的一个爆款例子，就是 Pretext。
我们可以看它怎么被做出来，又怎么被传播。
Pretext 做的是什么呢？简单说就是绕开浏览器直接用 JavaScript 做排版。
项目站点自己的标题：Text measurement that never touches the DOM.
零 DOM 读取，按帧 reflow。
https://x.com/_chenglou/status/2037715519277760531
龙穿行文本、文字绕开障碍、动态 exclusion zones，这些 demo 好看，但背后首先是一个很硬的排版与性能问题。
它让我们想到了 CSS shapes 还有 CSS exclusions。
肯定不是 CSS 不能做，但今天我们不聊 CSS 工作组当年在这些领域的挣扎，反正结果是 pretext 在某些领域上先跑到前面。
而且它是被 AI 帮着做出来的。
这里最有意思的不是“AI 帮忙做 demo”，而是作者公开说过，开发过程在等一个 AI verifier loop。
作者的说法是：拿真实浏览器当 ground truth，在不同宽度、不同语言下对照；阿拉伯语还专门卡了一阵。
这很关键，因为它说明 AI 在这里不是外挂在项目外面，而是已经进入实现与验证链路。
也就是说，AI 先进入开发，进入验证。
这是一种今天越来越常见的模式：项目先把 AI 接进开发和验证链路，然后才有机会快速迭代到足够惊艳的状态。
然后它才开始传播。
起手，先丢链接。
作者 Cheng Lou 发帖时，不只是贴仓库，还直接说：把 AI 扔进去，做点酷 demo。
这一句很关键，因为它把传播门槛从“读懂实现”降成了“先做一个能转发的东西”。
然后，龙。
https://x.com/Riyvir/status/2038093450139279426
不是巴哥那个🐲。
龙在文字里穿行，文字绕开障碍物。这种画面不需要解释，一眼就能懂。
所以最先爆掉的，不是 README，也不是 benchmark，而是可录屏、可转发、可二创的视觉奇观。
“文字像水一样分开又合上”这种体验，把话题从优化库变成了新交互媒介。
接下来 repo 就会变成 meme。
https://www.pretext.cool/
当社区开始做龙、做实验、做 playground、做 gallery，项目就不只是仓库，而像一场集体创作活动。
传播也就从看，变成做。
AI 在这里扮演的角色也很直接：它大幅降低了二创门槛，让围观者更容易变成参与者。
当然，争议也一起放大。
有人觉得这是魔法，有人觉得只是噱头；但这类分歧本身就是下一轮传播的燃料。
Pretext 提醒我们，今天 AI 已经能同时放大实现、验证和传播。
第二个案例，我想把问题从“能不能做出来”，拉到“社区敢不敢接”。
Node.js，PR #61478。
这不是 demo，这是 core。
这是一份给 Node.js 引入 node:vfs 的巨型 PR，要同时碰好几个核心模块。
问题不是没人想做。
作者也是 Node.js 团队的核心成员，专门解释过，VFS 对应的需求一直都在，只是规模太大，长期没人把它完整推进到 core。
而它的规模到底有多大？PR 自己给过一个很直白的数字：164+ interception points。
也就是说，要拦截的接口点就有 164 个以上。
作者主动披露了 AI 参与。
PR 描述里明确写了：这份改动用了大量 Claude Code，但所有改动都由作者自己 review。
里面有一句话很重要：AI made it possible。
这句话重要，不是因为它像口号，而是因为它说明了 AI 在这里扮演的是“把超大工程推进出来”的放大器。
而且它的工程价值是明确的。
但审查成本没有消失。
代码能更快产出，不等于 review、回归、兼容性验证也会同步变便宜。
争论很快就变成了组织问题。
讨论后来不只是“这个 PR 值不值得合”，而是升级成“OpenJS，也就是 node.js 项目后的基金会和治理组织要不要允许 AI-assisted development”。
甚至还出现了请愿：No AI in core，主张 Node.js core 不应接受 LLM 生成的核心重写。
OpenJS 的讨论里，问题已经不只是代码，而是治理、DCO、维护责任，等一系列问题。
最后卡住的，不是作者。
AI 放大了提交能力，但 reviewer、maintainer 和能为大规模变更兜底的人，并没有同比例增加。
再来，我们看看标准组织。
TC39。
这条线可以从 2024 年 2 月的 issue #62 讲起。这个讨论的标题就是，要不要明确禁止 generated content。
到 2026 年 3 月 20 日，讨论的结果是给 tc39/how-we-work 仓库里加入了 AI_POLICY.md。
这份 policy 要求参与者在 tc39 仓库里发的 issues 和 comments 不能用 AI 生成。
注意它讲的不是代码，代码还是按原来的 review process 处理。
它讲的是 issue / comment 这种内容必须是你自己写的，不能把 LLM 扩写后的文字直接贴进讨论区。机器翻译和 proofreading 可以用，但不能引入新内容。
再看 ISO。
ISO 这边对应的是 2025 年 3 月的 Guidance on use of artificial intelligence for ISO committees。
这份 guidance 允许把 AI 用在研究、翻译、会议记录这些场景。
但同一份文档也写得很直接：不要把生成式 AI 生成的图片或文字放进 ISO 内容；也不要把 ISO 受版权保护的材料喂给免费的、公共的、或者没有授权的 AI 工具。
也就是一句话：GenAI 图文，别进 ISO 内容。
原文是：Do not use images or text created by generative AI in any ISO content。
再看 Linux Foundation。
Linux Foundation 这边对应的是法律团队发布的 Guidance Regarding Use of Generative AI Tools for Open Source Software Development。
这份 guidance 里有一句很核心的话：development and review should be treated no differently。
也就是说，它没有要求把 AI 生成代码单独放进另一套审查流程。
但它补充的要求是另外两条：先确认工具条款不会和项目的开源许可或 IP 政策冲突；如果输出里包含第三方版权材料，要补上相应的许可、notice 和 attribution。
所以 Linux Foundation 的重点，其实是条款、归因和权利链条。
最后看 W3C。W3C 有一个新的 Community Group。
2026 年 2 月 3 日，AI Content Disclosure Community Group 发布了 call for participation。
它想讨论的是，内容使用生成式 AI 的程度，能不能用结构化、机器可读的方式表达出来。
比如四档：人写、AI 辅助、AI 写人审、全自动。
如果把这些组织放在一起看，虽然关心的内容和政策范畴不同，但有一点启示：
AI 带来的变化，最后一定会进入制度层，而不只是停留在工具层。
现在回到最初的问题：编程会 AI 化或者无人化吗？
我想可能就像翻译一样，只是时间问题。而且肯定用不了60年。
但开发者的工作，会向“定义、验证、审查、责任”迁移。
这里最难 AI 化的东西，我觉得还是责任。
更具体一点说，就是谁来定义问题，谁来确认验收标准，谁来判断这份改动该不该进入生产环境、进入开源 core、进入标准文本，以及最后谁来承担后果。
最后我想再说一个像机器翻译一样曾被预期为“最先发生的 AI 革命”的例子。
无人驾驶。
尤其在 2010 年代中后期，很多人真心相信它会是最先落地的 AI 革命。
我自己当年也认真这么想过，所以一直没去学驾驶，因为用了这个借口，就一直享受老婆开车我坐车的悠闲。
软件开发领域，我们已经看到了越来越多“看起来像无人驾驶”的时刻：AI 自己读代码、自己改文件、自己跑测试、自己开 PR。
很可能软件开发的无人驾驶会比真无人驾驶更早到来。不过即使如此，只要最后那个责任闭环还在人这里，那么开发者就不会消失，只会从驾驶者，变成监护者、调度者、签字者。
我的分享就到这里。
谢谢大家，Q&A。