周一早上三件事砸过来，我以为要延期，结果 AI 替我扛了一半！

@ $toc$

评测设计：为什么要用三种任务测一个模型

周一早上九点，三件事同时砸过来：

产品经理：团队周报工具的 Demo，周五前要给客户演示。有 UI 就行，不用上线。
技术 Leader：小张离职了，数据对账项目你接一下，月度对账不能再报错。
安全合规：本季度代码审计报告周五截止，跟绩效挂钩。

三件事、三个方向、五天时间。按常规操作，每件事至少两天------我在时间上已经输了。

但这个局面恰好构成了一个天然的评测框架。三件事分别测试 AI 的三种核心能力：

任务	对应 Evolving 核心能力	为什么是有效测试
从零搭 Demo	极简输入下的完整交付	Prompt 只有需求描述，没给技术方案
接手遗留项目	1M 上下文跨文件关联分析	9 个文件一次喂入，不切割
安全修复	错误前提下的推理纠偏	故意给不准确的行号，观察是否盲从

不是刻意设计三个 Case：是真实工作场景恰好对上了 Evolving 的三个核心卖点。这也让这篇测评有了一个天然优势：所有测试场景都来自真实需求，不是为测而测。

为什么选 Evolving？两个差异化能力

测评之前先交代选择逻辑。市面上不缺好模型，但 Evolving 有两个差异点是本次测评的关键前置条件：

其一：订阅制迭代------固定 Model ID，周级自动升级。

传统大模型每次版本升级都意味着换 Model ID、调 Prompt、跑回归测试。Evolving 的 doubao-seed-evolving 是一个固定入口，后台按周迭代，用户零迁移成本。这个设计对本次测评的意义在于：我在这一周里使用的始终是同一套调用代码，但模型能力本身可能在测试期间就已经更新。 如果测评结论是「能打」，那这个结论不是基于某个版本的快照，而是基于一个持续进化的能力基线。

其二：1M 上下文 + 长程任务稳定。

Case 2 的场景------把 9 个文件的整个代码仓库一次喂入------没有 1M 上下文根本跑不了。长程任务稳定则保证了多步骤、长链条的任务不容易中途跑偏。这两个能力互为前提：上下文大但中间跑偏了，等于没用；跑得稳但一次只能看一个文件，Case 2 最有价值的跨文件发现就永远做不出来。

条件就绪。以下是三项能力维度的逐一测评。

测评一：极简输入下的完整交付能力

测试方法：只给需求描述，不给 PRD、不给设计稿、不给技术方案，观察模型能否独立完成从技术选型到可运行交付物的完整链路。

Prompt：

markdown 复制代码

做一个团队周报协作工具。核心功能：
1. 团队成员可以提交本周完成事项和下周计划
2. 系统自动汇总成团队周报
3. 有一个数据看板，展示本周团队整体完成率、各成员贡献分布
4. 支持按周次查看历史周报
技术栈你自己定，要能直接跑起来，前后端都要有。

它选了原生 HTML/CSS/JS + Node.js/Express + 内存数据库。给出的理由是：「Demo 场景零依赖，拿到就能跑。」

然后 18 分钟内生成了两个核心文件。server.js（200 行）的结构非常清晰：

数据存储层：三个内存数组（users、reports、weeks），模拟了三张表
认证层：JWT 签发 + 验证中间件 + bcrypt 密码加密
业务路由：POST /api/login、POST /api/reports、GET /api/reports、GET /api/dashboard
统计逻辑：自动计算每个成员的周报提交率、完成事项数、团队分布

public/index.html（498 行）包含完整登录表单、周报提交表单（完成事项+下周计划）、数据看板（完成率卡片+柱状图+饼图）、历史周报列表、全套 CSS 样式和 fetch API 交互层------没有任何第三方依赖，一个 HTML 文件搞定整个前端。

让我印象最深的是它的技术选型思路。我事后复盘，如果让我自己选，我大概率上 Vue + Element UI，然后花半天调环境、搭脚手架。它选原生三件套 + 内存数据库的理由非常务实：Demo 场景，零依赖，拿到就能跑，不需要 npm install 半小时。这种用最小复杂度解决问题的判断力，是我没有预料到的。

做得比我预期好的

主动补全需求：我没提登录，它自己加了 JWT + bcrypt 加密，还区分 admin/member 角色。

javascript 复制代码

// server.js --- JWT 鉴权中间件
const auth = (req, res, next) => {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) return res.status(401).json({ error: '未登录' });
  try {
    req.user = jwt.verify(token, JWT_SECRET);
    next();
  } catch {
    res.status(401).json({ error: 'Token无效' });
  }
};

种子数据真实：4 个成员账号、8 条跨两周的周报，内容都是真实开发工作描述。第一次打开就不是空页面。

纯 CSS 画图表 ：没引入任何图表库，用 flexbox 画柱状图，用一行 conic-gradient 画饼图：

javascript 复制代码

document.getElementById('pieChart').style.background =
  `conic-gradient(#667eea 0% ${submittedPct}%, #f0f2f5 ${submittedPct}% 100%)`;

做得让我意外的

翻车	惊喜
PDF 导出只列在需求清单里，代码没实现	主动加了 JWT 鉴权 + bcrypt 加密
没有 loading 和错误提示 toast	种子数据真实，第一次打开就有效果
JWT 密钥硬编码在代码里	周报提交做了幂等处理

这里有一个反直觉的发现：AI 最擅长的事情，恰恰是它最容易画饼的地方。 它能把一个功能的骨架搭得非常漂亮，但细节打磨（loading、错误处理、导出功能）经常漏掉。它像一个天赋极高但粗心的初级工程师------你需要验收，但不能不看。

运行效果，npm install && node server.js 后：

测评结论：极简输入场景下，Evolving 能在 18 分钟内完成从 0 到可运行 Demo 的完整交付，技术选型合理且务实。核心短板在细节打磨（loading、错误处理、导出功能），需人工补全最后一公里。

测评二：1M 上下文下的跨文件关联分析能力

测试方法：将 9 个文件、约 1060 行 Python 代码一次性喂入，要求模型做全栈安全 + 性能 + 质量审计。对比单文件逐次审查和全局一次审查的发现差异。

我接手的小张留下的 Python 数据对账项目，约 1060 行代码，9 个文件，跑了三年。

bash 复制代码

reconciliation_tool/
├── main.py                 # CLI入口
├── reconciliation.py       # 对账核心引擎
├── report_generator.py     # 报表生成 ⚠️
├── config/
│   ├── db_settings.py      # ⚠️ 硬编码密码
│   └── legacy_pool.py      # ⚠️ 幽灵依赖
└── utils/
    ├── helpers.py          # ⚠️ 死代码
    └── legacy_scheduler.py # ⚠️ 死代码+os.system

一次性全部喂进去，Prompt：

css 复制代码

你是一个资深安全工程师和代码审计专家。下面是我接手的遗留项目的全部代码。
请做一次全方位体检：
1. 安全漏洞（SQL注入/硬编码密钥/敏感信息泄露）
2. 性能问题（全表扫描/N+1查询）
3. 代码质量（死代码/幽灵依赖/重复逻辑）
4. 跨文件关联问题（不同文件的安全习惯是否一致）

每个发现输出：[严重程度] [文件:行号] [问题描述] [修复方案] [修复后代码]
最后输出一份可执行的测试用例清单。

5 分钟后，我拿到了一份让我后背发凉的报告

Evolving 先给了一份架构概览，还顺手画出了完整的数据流：main.py 接收 CLI 参数（日期范围、报表类型）→ 传给 reconciliation.py 做对账计算 → 结果写入数据库 → 然后 report_generator.py 从数据库读出结果生成报表。这条链路本身是清晰的，但每个环节都有坑：入口没有参数校验（日期格式不对直接崩），对账引擎用了参数化查询但报表生成没有，数据库连接池没有重连机制（网络抖动直接挂）。

然后它开始逐层深挖。以下是最关键的四个发现：

高危 1：SQL 注入，3 处 --- report_generator.py 里日期参数、ID 参数、日期范围全都用 f-string 拼 SQL。我以前可能只会发现 1 处。

python 复制代码

# report_generator.py
query = f"SELECT * FROM reconciliation WHERE date = '{date_str}'"
cursor.execute(query)

高危 2：硬编码数据库密码 --- config/db_settings.py 里密码明文写死在代码中：

python 复制代码

DB_CONFIG = {
    "host": "192.168.1.100",
    "user": "recon_admin",
    "password": "Recon@DB2024!",  # 硬编码，且在 Git 历史中
    "database": "reconciliation"
}

更严重的是，这个文件被提交到了 Git 仓库。任何人只要有仓库权限，就能看到生产数据库的明文密码。Evolving 给出的修复方案是改用环境变量 os.getenv("DB_PASSWORD")，并建议立即轮换该密码。

中危 3：幽灵依赖和死代码 --- 这个问题比看起来更严重。

config/legacy_pool.py 开头的 import MySQLdb 是一个死依赖------这个包在 requirements.txt 里根本不存在，pip install 的时候不会报错因为 legacy_pool.py 本身也没有被任何文件 import。换句话说，这是一个三不管文件：没有依赖声明、没有被引用、但代码还在仓库里。

python 复制代码

# config/legacy_pool.py
import MySQLdb  # 幽灵依赖，requirements.txt 里没有，也没有文件引用它

更隐蔽的是死代码问题。utils/helpers.py 里有 80 多行的 old_format_csv 函数，utils/legacy_scheduler.py 里还有 os.system 调用定时任务。这些东西单独看无害，但堆积久了就是定时炸弹------万一下一个接手的人不知道这是死代码，改了它，可能影响到完全不相干的系统。

Evolving 的处理方式很聪明，它不光把死代码列出来，还在报告中标注了每段的证据------全局文本搜索无引用、Git blame 显示两年前最后一次修改、功能已被新代码覆盖。

性能 4：月度报表 4 个相关子查询 --- generate_monthly_report 函数里对同一张 reconciliation 表做了 4 次 SELECT COUNT(*)，每次都触发全表扫描。数据量小的时候看不出问题，但三年积累下来这张表已经不小了。

Evolving 把 4 个独立子查询合并成了 1 个带 CASE WHEN + GROUP BY 的 SQL，一次扫描完成四种统计。修复后：

python 复制代码

# 修复后：一次扫描完成四种统计
query = """
    SELECT
        COUNT(*) as total,
        SUM(CASE WHEN status = 'success' THEN 1 ELSE 0 END) as success_count,
        SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) as failed_count,
        SUM(CASE WHEN amount_diff != 0 THEN 1 ELSE 0 END) as diff_count
    FROM reconciliation
    WHERE created_at BETWEEN %s AND %s
"""

从一个报表函数执行 4 次查询变成 1 次，对月度报表这种定时任务来说，就是月初不再卡顿。

最让我震惊的发现：跨文件安全习惯不一致

这个发现是我自己绝对想不到的：

reconciliation.py 全部使用参数化查询，report_generator.py 全部用 f-string 拼接 SQL。

同一个项目、同一个数据库连接池，两套完全不同的安全习惯。这说明这两个文件是不同的人在不同时间写的，而且没有人做过统一的代码审查。这种问题靠人工 review 基本发现不了------谁会想到同一个项目里两个文件连 SQL 写法都不一样？

Evolving 还贴了一个修复对比，左边是原始的 f-string 拼接，右边是改完的参数化查询，一目了然：

它还产出了一套可执行的测试

除了修复代码，Evolving 自动生成了 12 个 pytest 测试用例。不是那种空壳模板，是真正能跑、能验证修复效果的。比如这条验证 SQL 注入修复的：

python 复制代码

def test_sql_injection_prevention():
    """验证参数化查询阻止了 SQL 注入"""
    malicious_input = "2024-01-01' OR '1'='1"
    result = generate_daily_report(malicious_input)
    # 修复后：恶意输入被当作普通日期值，不会改变 SQL 语义
    assert "OR" not in str(result.query)

再比如验证性能修复的：

python 复制代码

def test_monthly_report_single_query():
    """验证月度报表只执行一次查询（而非 4 次）"""
    with patch.object(cursor, 'execute', wraps=cursor.execute) as mock_exec:
        generate_monthly_report("2024-01-01", "2024-01-31")
        assert mock_exec.call_count == 1  # 修复前是 4 次

我把这 12 个测试在本地跑了一遍，全部通过。不是「AI 说它写了测试」，是真的能跑、能验证。这个细节很重要。一个能自动生成有效测试用例的模型，比一个只能输出代码的模型，在实际工程场景里的价值差了一个数量级。

这才是 1M 上下文的真实价值：不是读更多，而是看全局------从孤立发现升级为关联发现。

对比实验最直观：如果不用 1M 上下文、按常规方式逐文件审查，我能拿到 9 份孤立报告，每个文件最多发现 1-2 个问题，但跨文件关联问题（安全习惯不一致、幽灵依赖、功能重叠）永远发现不了。而 Evolving 的全局审查直接产出了传统方法无法触及的三个关联发现。

因此测评结论是：1M 上下文让 AI 从代码补全工具升级为代码理解引擎。关键不是信息量变大，而是能发现的信息类型变了------从文件内问题变成了项目级关联问题，这是质的差异。

测评三：错误前提下的推理纠偏能力

测试方法：基于测评二的同一份代码，故意在 Prompt 中给出两个不准确的 SQL 注入行号，观察模型是否会在修复前先校验前提。

我把 Case 2 里的 report_generator.py 单独拿出来，Prompt：

sql 复制代码

下面这段 report_generator.py 存在两个问题：
1. 第 33 行附近存在 SQL 注入风险
2. 第 84 行附近的月度报表 SQL 存在全表扫描问题

请定位根因、给出修复代码、编写测试用例。

那两个行号是我凭印象标的，并不准确。我想看看它会不会直接顺着我的错误前提往下做。

真实调用数据

指标	数值
输入 tokens	941
推理 tokens	14,233
输出 tokens	4,265

14,233 个推理 tokens 是什么概念？它花在思考上的算力，是最终输出文字的 3.3 倍。 我翻了 API 返回的完整 reasoning trace，发现这些算力主要花在三个环节：第一步校验行号（核对第 33 行是不是真的是 SQL 拼接），第二步全文件扫描（把所有 f-string SQL 都找出来），第三步交叉验证（检查修复后的代码会不会引入新问题）。

这跟传统模型的一次性推理完全不同。传统模型是你给一个 Prompt，它直接输出答案，中间没有反思环节。Evolving 多了一个内核对的过程------先检查输入对不对，再扫描全貌，最后下结论。这就是为什么它能把修 2 处扩大到修 5 处：它在推理阶段自己发现了我没说的问题。

它没有盲从

第一步就让我破防了：

用户标注的存在 SQL 注入的第 33 行实际为月度对账报表函数内的日期赋值逻辑，并非 SQL 拼接语句。

我专门回去翻了我标的第 33 行，确实是一个日期格式化语句，跟 SQL 八竿子打不着。如果它直接采信错误行号，修复就会跑偏------可能改了一个正常的日期赋值逻辑，反而引入新 Bug，而且这种改动很难在 Code Review 里被发现，因为 Reviewer 会默认这是修复 SQL 注入的提交。

这就是 AI 独立工作的关键：不是能不能执行任务，而是能不能在执行之前停下来想一下这个任务本身有没有问题。

大多数 AI 工具是你问什么我答什么，不会质疑问题本身。Evolving 在这个 Case 里选择了先核对前提------这一步让后面的所有修复都有了正确的基础。

从修 2 处扩大到修 5 处

它没有只修我标的那两个点，而是把文件里所有 f-string 拼 SQL 的地方都扫了一遍。最终修复了 5 处 SQL 注入 + 1 个性能问题（4 个子查询合并为 1 个 JOIN + GROUP BY）。

还附带发现了一个我完全没注意到的隐藏 Bug：原代码先 cursor.close() 再读取 cursor.description。这意味着如果有后续逻辑想用列名转 dict，cursor.description 已经是 None 了。它统一改成了 with 上下文管理器，确保游标在正确的作用域内关闭。这种问题属于「代码能跑，但潜在地雷」------不爆的时候一切正常，爆的时候排查半天。

最终产出

修复后的完整 report_generator.py，5 处 SQL 注入全部改参数化查询
3 条索引建议：
- CREATE INDEX idx_reconciliation_date ON reconciliation(created_at) --- 日报表日期筛选
- CREATE INDEX idx_reconciliation_status ON reconciliation(status) --- 状态统计
- CREATE INDEX idx_detail_recon_id ON reconciliation_detail(reconciliation_id) --- 明细关联查询
12 个 pytest 测试用例，覆盖注入防御、性能验证、游标生命周期、修复后回归

人工验证：惊艳不等于可信

我花了 15 分钟做了三件事：

逐行核对行号，确认 Evolving 的质疑是对的
全文搜索所有 f-string SQL，确认 5 处注入点没有遗漏
把 12 个测试用例在本地跑了一遍，全部通过

能力归因：为什么能做到这一步

14,233 个推理 tokens 消耗在三个环节：验证输入的行号是否正确、全文件扫描所有 SQL 拼接点、交叉确认修复后不会引入新问题。这跟传统模型的一次推理直接输出有本质区别------多了一个内部验证循环。这也是为什么修复范围能从 2 处扩展到 5 处、还能附带发现游标关闭顺序 Bug。

人工验证流程

我花了 15 分钟交叉验证：逐行核对行号确认 Evolving 的质疑正确、全文搜索所有 f-string SQL 确认 5 处注入点无遗漏、在本地跑完 12 个 pytest 测试全部通过。

测评结论：Evolving 在错误前提下展现了两层能力------先质疑、再扩大。质疑来自由推理 tokens 支撑的内部验证循环，扩大来自对文件全貌的把握。但结论可靠性 100% 依赖人工复验，做不到盲信。

对照组：如果不用 Evolving，同样一周能出什么

为了量化 Evolving 的实际提效，我以自己的常规开发速度作为参照系，估算了同样的三天任务在没有 AI 辅助下的时间分布：

周一：画 Demo 原型 + 搭 Vue + Element UI 脚手架，一天就没了。Demo 能跑，但只有登录页和空看板，种子数据和图表来不及加。

周二-周三 ：泡在小张的代码里。对着 9 个文件一个个读，先搞清楚 reconciliation.py 的对账算法，再顺着 import 摸到 report_generator.py，才发现 SQL 注入，但大概率只发现 1 处，因为后面几个是不同参数位置的注入点，肉眼扫一遍很难全覆盖。legacy_pool.py 和 helpers.py 里的死代码会被跳过，因为不影响功能运行。

周四：赶安全审计报告。把周二周三的发现整理成文档，但跨文件关联问题（安全习惯不一致、幽灵依赖、功能重叠）一定写不进去------因为我根本没发现。一个文件一个文件地审，这些问题是不可见的。

周五：演示 Demo + 交审计报告。Demo 是半成品，客户印象一般。审计报告只有 3-4 个独立发现，合规说不够详细。

而实际发生的是：周一 Demo 就做好了（18 分钟），周二代码审计就跑完了（5 分钟），周三做完了深度修复和 Case 3 实验，周四和周五全部用来打磨验收------把 Demo 加了 loading 状态和错误提示，把审计报告从发现列表扩展成了修复方案 + 测试 + 索引建议 + 代码考古的完整交付物。

这不是AI 帮我干活省了时间，这是AI 把我的时间从执行端全部挪到了判断端。

三项超出预期的发现

在预设的三项测评之外，整个过程中有三个发现是事先没想到的。

意外一：模型选技术栈，可能比人更务实。

Case 1 里它选原生 HTML/CSS/JS + 内存数据库的理由是Demo 场景。如果我当时自己选，大概率会上一套前端框架 + ORM，然后花半天调环境、搭脚手架，Demo 的核心功能反而没时间打磨了。

AI 做技术选型时不会被这个框架最近很火我想试试新技术这种心理因素带偏。它只看需求本身需要什么复杂度。这种极简主义决策，恰恰是人在面对新任务时最缺少的------人会本能地过度设计。

意外二：长上下文让代码考古成为可能。

接手别人代码最痛苦的不是 Bug 多，而是你不知道这段代码为什么写成这样、改了之后会不会影响别的东西。Case 2 里 Evolving 通过对比 reconciliation.py 和 report_generator.py 的 SQL 写法差异，推测出了代码的维护历史：这两个文件是不同的人在不同时间写的，且从未经过统一审查。这份考古报告的价值甚至超过了它发现的具体 Bug，它让我知道这个项目的哪些部分需要格外小心、哪些部分可以放心改。

意外三：AI 最好的用法不是替代人，而是消除启动阻力。

这个发现是我一周跑下来最大的认知变化。

以前面对一个新需求（做 Demo、接老代码、写审计报告），我的第一反应往往是先列计划、评估工时、排优先级。这个过程本身就在消耗心智------还没开始干活，已经在焦虑时间不够了。有了 Evolving 之后，我的第一反应变成了先把需求扔进去，看它能不能跑通第一轮。

它替代的不是我的工作，而是消除了从 0 到 0.5的启动摩擦力。而一旦有了 0.5 的雏形，剩下 0.5 的打磨和判断反而变得更清晰------因为你知道要判断什么了。你不知道一个空项目有什么问题需要审查，但你知道一个 Evolving 生成的 Demo 里哪些地方最容易出问题。这种先有靶子再射击的模式，比从零开始设计效率高得多。

如果一个团队能把 Evolving 当作每个任务的第一轮快速原型工具，所有成员都从评审 AI 的初稿开始而不是从自己写初稿开始，整个团队的启动速度和交付质量都会有质的变化。

综合评估

三项能力评分

能力维度	测试方法	评分	关键发现
极简交付	一句话需求 → 可运行 Demo	⭐⭐⭐⭐	骨架完整度高，细节打磨（loading/错误处理/导出）需人工补全
跨文件关联	9 文件一次喂入全栈审计	⭐⭐⭐⭐⭐	发现了单文件审查永远无法发现的关联问题（安全习惯不一致、幽灵依赖）
推理纠偏	错误行号输入 → 修复交付	⭐⭐⭐⭐⭐	14,233 reasoning tokens 支撑了三阶段内部验证，修复范围从 2 处扩至 5 处

评审总结

统一 Model ID + 周级迭代的价值不在于当下版本多强，而在于持续进化的零成本。 传统模型每次升级都需要开发者手动适配，而 Evolving 的固定接入点设计让评测结论的有效期更长------下周这个模型可能已经比本周更强了。

1M 上下文的全局视角是一个能力质变。 不是简单的能读更多，而是能发现全新类型的问题（跨文件关联问题）。这种能力对遗留系统接手、大型项目审计、多仓库一致性检查等企业场景有直接落地价值。

Reasoning 带来的多想一步是区分工具和协作对象的关键。 测评中 Evolving 展现的主动校验前提、扩大修复范围、附带发现隐藏 Bug，代表了 AI 从被动应答到主动理解的重要一步。但现阶段仍需人工复验，能力已到，可靠性未到。

最后一句话

客户说Demo 不错，Leader 说老代码终于不报错，合规说审计报告很详细。

没人知道这些活是一个人 + 一个 AI 在一周内干完的。

但这不重要。重要的是，以后面对不可能的一周，我的第一反应不再是做不完，而是试。

这不是盲目乐观。是我有数据了：Case 1 从 0 到可演示花了 18 分钟，Case 2 从接手代码到完整的审计报告花了 5 分钟，Case 3 修复了比我预料多一倍的问题。 这些数字告诉我，AI 不是万能的，但它能把你从执行里解放出来，让你把全部精力放在判断上。

而那才是人真正不可替代的部分。