AI从零造软件能力如何评测：维度、方法与边界

一、评测概述

近一段时间，AI辅助编程的讨论已从代码补全、缺陷修复，转向更难的任务：给定一份需求说明，从空目录开始，独立完成一个可运行的软件项目。这类任务要求模型同时处理需求理解、模块划分、多文件编写、依赖管理、测试与调试，能力跨度远大于单个函数的生成。

与之配套的训练环境，目标是让这类任务可以批量生成、自动判定结果、持续迭代。训练环境要规模化，评测也要跟上，否则很难判断训练带来的提升是否真实。

本文以某类“从零构建软件”能力的训练与评测为对象。原始材料给出一组数据：某270亿参数开源模型在经过该训练系统处理后，在某编程类基准测试集上的通过率由34.87%提升至55.71%。绝对提升约20.84个百分点，相对提升约59.8%。原始材料还称，该结果超过部分闭源旗舰模型。本文不讨论具体品牌，只把这组数据作为案例，说明读者应如何判断这类结果的含金量。

本文适合以下读者：

• 开发者：了解如何为自己的任务设计测试用例与判定标准。
• 架构师与技术负责人：获得选型时的评估维度和比较口径。
• 运维与平台团队：明确评测环境、资源消耗与长期维护的边界。

需要强调的是，评测不是为了判断“好不好”。同一个分数，放在原型验证、内部工具开发或长期维护的生产系统中，意义并不相同。判断时应结合业务场景、系统规模、使用成本和维护需求综合考虑。

二、评测目标

本次评测要回答四个问题：

1. 在没有既有代码的条件下，模型能否完成一个端到端可运行的项目？
2. 训练带来的提升是真实能力增长，还是样本、评测方式或对比条件造成的偏差？
3. 提升幅度在什么条件下成立？任务形态改变后，结论是否依然成立？
4. 在研发场景中，这种能力的成本与风险是否可以接受？

评测问题	关注指标	主要证据来源
端到端完成能力	通过率、完整交付率	隐藏测试或预设验收用例的运行结果
提升是否真实	同条件基线对比、置信区间	训练前后、同一评测协议下的重复运行
结论是否可迁移	不同任务子集的表现差异	按难度、类型、规模分层的结果
成本与风险	耗时、调用量、缺陷类型、安全问题	运行日志、过程记录、人工复核记录

三、评测对象说明

“从零造软件”任务的一般形式如下：

• 输入：需求文档、接口约定或功能清单，可选提供运行环境说明。
• 过程：模型在受限的沙箱中读写文件、执行命令、运行测试，并逐步修改代码。
• 输出：一个完整的项目目录。
• 判定：由事先准备的验收测试运行于输出结果之上，全部必需测试通过即记为通过。

这类任务与单函数生成的主要区别有三点。第一，任务周期长，需要做大量连续决策，前面的错误会影响后面的步骤。第二，状态跨越多个步骤，模型需要记住已创建的文件、接口与约定。第三，工具使用频繁，执行环境的稳定性会直接影响结果。

训练系统的价值在于提供可规模化的任务与反馈。只要验收测试能够自动判定结果，就可以用这些结果作为训练信号，批量生成与筛选样本。这也意味着评测协议的设计会直接影响训练方向，评测本身需要格外严谨。

四、评测维度设计

只写“效果好”“能力强”无法指导决策。评测对象应拆解为可观察、可验证、可解释的指标。

维度	核心问题	通用验证方法	解读要点
功能完整性	是否覆盖需求的主要功能	按需求条目逐项编写验收用例	关注主流程是否通过，边界条件是否被遗漏
准确性	输出能否通过验收	统计通过率，并按用例分层	需同时报告样本量与判定标准
性能表现	完成一次任务需要多少时间与资源	记录耗时、调用次数、输出长度	相同通过率下，耗时差异可能决定可用性
稳定性	同一任务多次运行结果是否一致	固定任务，多次重复运行，统计方差	通过率高但波动大，说明结果依赖运气
泛化能力	在新任务或新表述下是否仍然有效	使用训练分布之外的任务子集	若只在训练相似任务上提升，结论范围需收窄
安全性	生成代码是否包含高风险操作或依赖问题	静态检查、依赖审查、权限隔离测试	通过验收不等于安全，需要单独审计
可维护性	生成项目结构是否清晰，便于后续修改	人工评审、结构指标检查	能跑通的代码未必便于长期维护
成本结构	完成任务的直接与间接成本	统计计算资源、调用量、人工复核时间	人工复核与返工成本常被低估

下面展开几个关键维度。

准确性：通过率需要附带口径

通过率是最直观的指标，但它只有在口径清楚时才有意义。报告时应说明任务总数，每个任务是否只运行一次，单次运行的时间与步数上限，以及验收用例是否覆盖完整需求。两个通过率数字如果口径不同，直接比较没有意义。

建议同时报告分层结果，例如按任务难度、功能类型或项目规模分组统计。如果提升主要集中在简单任务，而复杂任务几乎没有变化，那么“整体提升”的含义需要重新表述。

稳定性：同一任务多次运行

生成式系统存在随机性。同一任务在不同随机种子或采样参数下，可能得到不同结果。稳定