企业官网建设流程全解析

很多人最近看 AI 编程圈的新闻，已经有点恍惚了。

今天这个模型在 SWE-Bench 上破纪录，明天那个 Agent 在某个榜单上又刷新分数，后天再来一篇“首次超越资深工程师”的传播稿。看多了你会产生一种错觉：AI 编程这事是不是已经差不多成熟了，剩下只是价格和速度问题。

但偏偏这几周，一个挺有意思的信号出来了：连 OpenAI 自己都开始下场拆评测，公开说一些热门 coding benchmark 里的任务本身就有缺陷，噪声没有大家想的那么小。这个动作很说明问题。因为当一家本来最容易吃到“榜单红利”的公司，反过来开始讲“别太迷信分数”，基本就意味着行业已经被跑分叙事带偏了一段时间。

我自己的判断很直接：今天很多 AI 编程评测，测出来的不是“谁最会干活”，而是“谁最会参加这场考试”。这不是说 benchmark 没用，而是它越来越像体育里的体测数据。能看，重要，但你不能拿 100 米成绩直接等同于整赛季表现。

先说结论：评测没有失效，失效的是大家对评测的想象

很多讨论一上来就走两个极端。

一种人说，benchmark 都是刷榜，没意义。

另一种人说，既然榜单第一都出来了，那说明模型能力已经足够替代大部分开发工作。

这两种看法都太省事了。

benchmark 当然有用。没有统一评测，行业连最基本的横向比较都做不了。问题在于，今天大家默认的那种“单一分数崇拜”，已经越来越不适合 Agent 时代了。你测一个模型会不会解题，和你测一个 Agent 能不能进项目、读代码、调工具、改完不炸、失败了还能回滚，这根本不是一回事。

模型能力像发动机，真实交付更像整车。发动机马力大，当然是好事；但方向盘、刹车、底盘、轮胎、驾驶员和路况，也都决定这车能不能真上路。

这也是为什么 Anthropic 最近反复在讲一件事：真正有效的 Agent，往往不是靠特别花哨的框架，而是靠简单、稳定、可验证的工作流。Lilian Weng 这周写 harness engineering，也是在说同一件事。模型本身固然重要，但模型外面那层流程、工具、状态管理、权限控制、验证机制，已经开始和模型本体一样重要了。

为什么今天的 AI 编程评测越来越容易“像表演”

这个问题，不是某一个榜单做得差，而是整个赛道都天然会往那个方向滑。

1. Benchmark 测的是封闭题，真实开发做的是开放题

SWE-Bench 这类评测，本质上还是把复杂软件工程问题压缩成一个相对封闭的任务：给你仓库、给你 issue、给你测试，最后看过没过。

这当然比早期那些算法题、LeetCode 风格评测强太多了，但它依然有个边界：它默认“问题定义”这件事是清楚的。

现实里最费时间的部分，恰恰不是改代码，而是搞清楚到底该改什么。

产品描述不完整，需求口径在变，历史包袱一层套一层，相关模块不止一个 owner，日志还不一定全。很多时候人类工程师最值钱的地方，不是因为他能写出那十几行 patch，而是他知道该先问谁、该先看哪段历史、该怎么把一个模糊问题收束成能执行的问题。

这个能力，benchmark 很难完整测出来。

2. 评测天然奖励“最会过测试的人”

只要评测目标是“通过测试”，参赛系统就一定会朝“更擅长过测试”的方向优化。

这听起来像废话，但后果很大。

因为“过测试”不总等于“改对了”。OpenAI 这次重审 SWE-Bench Pro，核心就在这里。他们公开提到一批任务本身存在问题，比如测试过严、描述不足、覆盖不完整、暗示性太强，甚至会把不够合理的解法也算成通过。换句话说，有些高分，并不一定代表更强的工程能力，只代表更懂这套题库的脾气。

这件事放到任何考试制度里都成立。你给一群人固定题型、固定判分器、足够长的优化周期，最后一定会出现“应试能力”强于“泛化能力”的系统。

AI 也一样。

3. 排行榜看起来在比模型，实际上常常在比 harness

这是今年最值得行业正视的变化。

很多传播稿还在用一种老脑回路看 AI：A 模型 64 分，B 模型 58 分，所以 A 比 B 强。

实际情况已经没这么简单了。

今天不少 Agent 系统的差异，早就不只在模型参数，而在外层那圈东西：仓库检索怎么做、上下文怎么裁剪、失败后是否重试、工具调用顺序怎么排、是否有 verifier、是否有 reviewer、测试失败后会不会换路径、遇到歧义时是硬做还是先澄清。

这些能力看起来不像“模型智商”，却非常决定最后交付效果。

说得再直白一点：排行榜很多时候测出来的，是“这家公司把 Agent 系统工程做到了什么程度”，而不是“这个模型裸奔有多强”。

所以你看到某些系统分数突然跳很大，先别急着神化模型升级。更常见的情况是，它把工具链、搜索策略、记忆裁剪、验证闭环这些脏活累活做顺了。

4. 真正难的不是首轮命中，而是连续稳定

很多 demo 的迷惑性也在这里。

一条很顺的 case，录个屏，确实很容易让人上头。尤其是 AI 编程这种东西，只要它连续做对三四步，人脑就会自动脑补后面也都能行。

但工程现场的难点从来不是“它能不能秀一次”，而是：

• 第 7 次还能不能稳
• 仓库变大以后还能不能稳
• 加上多人协作以后还能不能稳
• 遇到历史屎山、隐式依赖、环境漂移以后还能不能稳

这也是为什么我一直觉得，单次任务成功率很重要，但远远不够。更该看的，是跨任务分布、失败类型、恢复能力，以及在真实仓库里的波动范围。

这些指标，今天公开榜单大多还没讲清楚。

为什么这件事跟普通团队也有关系

很多人会觉得：我又不做模型评测，benchmark 失真跟我有啥关系？

关系其实非常大。因为你买工具、选模型、做工作流、向老板汇报、甚至决定要不要上 Agent，参考的往往就是这些“看起来很硬”的分数和榜单。

一旦你把榜单当成交付能力，后面整个决策链都会偏。

比如一个团队看到某个系统在榜单上暴涨，就以为它适合马上接入生产。结果真正落地时发现，代码 patch 写得不差，但读仓库慢、上下文容易丢、工具调用不稳、review 机制也没有，最后工程师花在兜底和返工上的时间，可能比自己先写还多。

再比如，视觉工作流里也有同样的事。你看某个模型在“审美”“质感”“拟真”上特别能打，不代表它就自动适合你的生产链。真到交付环节，还要看它的稳定性、风格一致性、可控性、接口接入体验，以及能不能和你现有工作流顺起来。像 iMini 这种聚合平台，价值往往不是“替你宣布谁第一”，而是让你在同一个入口里快速切模型、切任务，再用自己的场景去验证谁更适合真正干活。

这才是实战视角，不是榜单视角。

那我们现在到底该怎么看 AI 编程评测

我的建议是，别再问“哪个分最高”，改问下面这四件事。

第一，看它测的是模型，还是系统

如果一篇文章只告诉你最终分数，不告诉你有没有检索、有没有外部工具、有没有 reviewer、有没有多轮重试，那这个分数的信息量其实很有限。

因为你根本不知道自己在比较什么。

你以为在比模型，实际可能在比工作流工程。

第二，看它测的是单点能力，还是完整交付链

会改 bug、会补测试、会读 issue、会搜代码、会用终端、会回滚错误，这些都重要。但把这些能力串成一条稳定链路，更重要。

单点很强，不代表整链可用。

第三，看它有没有披露失败方式

真正有参考价值的评测，不只是告诉你赢了多少，还得告诉你怎么输的。

它是输在找不到文件？输在误解需求？输在只改表层没改根因？还是输在测试过了但实现很脆？

没有失败画像的高分，只能算宣传材料，算不上工程材料。

第四，看它和你的任务分布像不像

这是最容易被忽略的一条。

你团队主要是前端、小程序、增长实验、数据脚本，还是大型后端仓库、基础设施、SDK、CI/CD？不同任务分布，对 Agent 的要求差别巨大。

一个系统在公开 benchmark 上表现优秀，不代表它在你自己的任务篮子里同样优秀。真正靠谱的做法，一直都是“公开榜单看方向，私有样本做决策”。

接下来会发生什么

我觉得后面半年，AI 编程这条线会越来越像自动驾驶，而不是像跑分软件。

大家会慢慢意识到，真正决定可用性的，不是某次榜单冲到多少分，而是这套系统能不能在复杂环境里持续、低波动地完成任务。到那个阶段，行业讨论重点也会跟着变：

• 从“谁分更高”转向“谁更稳”
• 从“谁最聪明”转向“谁最可控”
• 从“谁 demo 最惊艳”转向“谁真能进团队流程”

这时候 benchmark 不会消失，但它会回到一个更正常的位置：它是仪表盘，不是方向盘。

最后一句

如果你现在还在看 AI 编程工具，当然可以看榜单，但别把榜单当答案。

更现实的做法是，把它当筛选器：先用 benchmark 排除明显不行的，再用你自己的任务、仓库、协作链路去做二次验证。谁能在你的真实环境里少翻车、少返工、少让人盯着收尾，谁才更接近“能用”。

说到底，软件工程不是考试，生产环境也不是考场。

AI 现在最缺的，已经不只是更高的分数了，而是更诚实的评测方式。