当AI开始自己写代码、自己做实验，2026年的技术圈在讨论什么

先说一个2025年夏天被反复引用的实验。

研究机构 METR 找了一批资深开源开发者，做随机对照试验：一半任务允许用 AI 编程工具，一半不许。结果有点反直觉——用 AI 的那组，完成任务的平均耗时反而多了 19%。更有意思的是，这些开发者在事后回顾时普遍认为"AI 帮我快了不少"，他们预估的提速是 24%。

会做的人和会估算的人，判断差了四十多个百分点。

这个实验后来被引用得有点滥，但它确实点出了 2026 年技术圈讨论的重心变化：问题已经不是"AI 能不能写代码"，而是"我们怎么知道自己判断得对不对"。

从"补全一行"到"接一个任务"

如果拉一条时间线，变化其实很清晰。

阶段	典型形态	人的角色
2021–2023	行内补全、对话式问答	写代码的人，AI 递砖
2024–2025	仓库级理解、多文件改动、Agent 跑终端	提需求的人，AI 干活，人验收
2025–2026	长任务、自主迭代、跑测试直到通过	定目标、审结果、担责任

2024 年 Devin 出来的时候，大家还在争论"这算不算演示效果"。到 2025 年下半年，Claude Code、Cursor 的 Agent 模式、以及国内的通义灵码、Trae、CodeBuddy、文心快码这些工具，基本都把"改多个文件→跑测试→看报错→再改"做成了常规操作。差别更多在于工程细节：上下文怎么管、权限怎么给、失败怎么回滚。

真正的门槛从"生成质量"挪到了"验收成本"。

有个做后端的朋友跟我讲，他现在最大的时间开销不是写代码，是看 diff。AI 十分钟改八个文件，他要花四十分钟确认这些改动没有顺手把某个边界条件改掉。"以前是我写他看，现在是他写我看，工作量没少，但累的方式不一样了。"

"自己做实验"已经不是比喻

如果说写代码还算是工程圈的内部事务，那"AI 做科研"这条线的影响面就大得多。

2024 年 8 月，Sakana AI 放出 The AI Scientist，端到端跑完"提想法→写代码→做实验→写论文→自我评审"。2025 年 4 月，他们的 v2 版本有一篇由 AI 生成的论文通过了某个学术 workshop 的同行评审——注意，是通过了评审，不是被接收为 Oral，也没人会说这等于做出了真正的研究贡献。但流程走通了。

同期还有几条线：

• Google 在 2025 年 2 月发布 AI co-scientist，定位是给科学家做假设生成和文献推演的搭档；
• DeepMind 的 AlphaEvolve 用进化式搜索改进算法，在矩阵乘法、数据中心调度这类问题上拿到了可验证的改进；
• FutureHouse、Coscientist 这类工作，把"机器人做湿实验"和"模型提假设"接在一起。

这些系统的共同点是：它们不产出观点，产出可以被验证的东西。 一段能跑通的代码、一个更快的矩阵乘法算法、一个在实验里复现出来的结果。

这也是为什么 2026 年技术圈对"AI 做研究"的态度，比两年前冷静得多。大家不太聊"AI 会不会取代科学家"了，转而讨论更具体的问题：实验结果可复现吗？评审能不能看出这是 AI 写的？如果看不出，评审制度还成立吗？

2026 年真正在吵的四件事

一、代码评审成了新瓶颈

生成变便宜之后，瓶颈自动转移到下游。Google 2024 年就披露过，他们新增代码里相当比例已经由 AI 辅助产生。当这个比例继续往上走，评审的人力就成了硬约束。

现在能看到几种应对方式，都在试：

• 分级评审：把 AI 生成的改动按风险分层，低风险的（依赖升级、样板代码、测试补全）走轻量流程；
• 让 AI 先审 AI：用另一个模型做首轮 review，人只看它标出来的疑点；
• 规格前置：先写清楚要什么、边界在哪，再让 Agent 动手，把验收标准提前固化。

第三种是 2025 年下半年开始被反复提的"规格驱动"思路。听起来像老派的详细设计文档回潮，其实动机很实际——你没法验收一个你没描述清楚的东西。

二、怎么证明它是对的

AI 生成代码最大的隐患不是写错，是"看起来对"。它很擅长写出语法正确、命名漂亮、注释齐全，但在某个并发场景下会出问题的代码。

所以 2025 年之后，测试相关的工具链明显热了起来。不只是跑单测，还有模糊测试、形式化验证、以及针对 AI 输出的静态扫描。有安全团队做过统计，AI 辅助生成的代码里，引入注入类、权限校验缺失类问题的比例并不低，尤其在开发者不熟悉的那部分技术栈上。

一句被讲了很多次的话：AI 让写代码变快了，但没让验证变快。 而软件质量是由后半段决定的。

三、速度悖论

回到开头那个 METR 实验。为什么用 AI 反而更慢？

参与者的反馈大致归成几类：一是要花时间判断 AI 的输出靠不靠谱；二是熟悉的大型代码库里，AI 常常理解错上下文，纠错比手写还费劲；三是被打断的节奏本身有成本。

这个结论不能被滥用——它测的是特定人群（资深、熟悉自己仓库的开发者）在特定任务上的表现。换成刚入行的开发者、或者写一个全新项目、或者做不熟悉的技术栈，结论很可能反过来。

但它提醒了一件事："效率提升"是个需要分场景讨论的词。 拿一个平均数字去推所有团队，很容易得出错误的决策。

四、人的成长路径

这是我认为 2026 年最该被认真讨论、但实际讨论得不够的一条。

过去一个工程师的成长，很大程度上靠"从写烂代码开始"。写第一版，被 review 打回来，改，再被打回来，反复几次才有手感。现在新人直接拿到的是 AI 写好的、看上去还挺像样的代码。他可能跑得通、能上线，但他没有经历那个"我为什么会写错"的过程。

几家公司的技术负责人在公开分享里提过类似的做法：刻意让新人在某些任务上不用 AI，或者要求他们必须先自己写一版再看 AI 的版本，对比差异。听起来有点反效率，但这是在给未来的判断力投资。

国内的情况，稍微不一样

国内的讨论重心和海外有些偏移。

海外更关注"Agent 自主性"和"评审制度"，国内的讨论更多集中在落地成本、私有化部署、以及和现有研发流程的结合上。通义灵码、Trae、CodeBuddy、文心快码这些产品，在过去一年里功能迭代都很快，但在企业侧的选型逻辑里，模型能力只是其中一项，还要看 IDE 兼容、代码库索引、权限管理、以及能不能嵌进既有的发布流程。

另一个明显差异是价格。2025 年国内模型厂商把 API 价格压得很低，直接结果是"用 AI 写代码"在很多团队里不再需要单独立项申请预算，变成了和个人装个插件差不多的决策。这反而加快了渗透速度。

冷静一点看

有些问题目前还没有好答案：

责任归属。 如果 AI 生成的代码出了生产事故，签字的人是谁？几乎所有的合规框架里，"最终负责"这一条还是落在人身上。这就要求 AI 生成的改动必须是可解释、可追溯的，而不是"它改了，跑通了，就这样吧"。

基准的失真。 SWE-bench 这类基准在 2025 年就接近饱和了，各家分数都奔着 70%、80% 去。于是又有了更难的变体、更新的评测集。但任何静态基准都有个天然缺陷：它会被针对性优化。真实世界里的任务，往往模糊、缺上下文、需求还会变。

长任务的不稳定性。 让 Agent 跑二十分钟，成功率还不错；跑两个小时，成功率下降得很快。误差会累积，越往后越容易跑偏。这也是为什么现在主流做法还是"切成小块，每块有人验收"。

结尾

2025 年有一句流传挺广的话："AI 不会取代程序员，但会用 AI 的程序员会取代不会用的。"

到 2026 年，这句话本身也该更新了。更贴切的版本可能是：能把任务描述清楚、能把结果验证住的人，和做不到这两件事的人，差距在拉大。

工具的能力还在涨，这一点没什么争议。但工具涨多少，不等于团队产出涨多少。中间隔着评审流程、测试覆盖、文档习惯，还有一群需要时间成长的人。

这些东西没法靠升级模型解决，只能靠一家一家公司慢慢磨。2026 年技术圈讨论的，说到底就是这些磨法。