冻结准确编程主张与用户结果
- 判断问题
- 主张涉及补全、生成、解释、审查、调试、仓库问题解决、迁移还是自主软件变更;针对何种语言、代码库与后果?
- 最低证据
- 逐字主张与日期;准确模型、Agent 与工具链版本;任务定义;语言、框架、仓库与用户;验收、安全和可维护性阈值。
- 停止条件
- “会编程”把本质不同的任务压成一个标签,或只从精美演示推断出来时停止。
写出代码不等于完成软件变更
代码能够解析、通过示例或获得短函数基准高分,只能回答特定协议中的局部问题。真实软件变更还可能要求理解跨文件依赖、澄清需求、修改测试、处理环境、保护数据、接受审查并在失败时安全回滚。
适用边界本页是公共研究方法,不代表 FUURAA 或 FUUVO 产品能力,也不评价任何模型、供应商、代码助手、Agent、仓库或基准;不构成能力保证、认证、审计、安全结论、采购、投资、法律或合规意见。
六道可拒绝的证据门
最低编程主张失效矩阵
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
记录受影响的任务、仓库、环境、测试、用户与决定;保留仍成立的最窄结论,并明确需要补测试、拆分结果、限制权限、人工修复、重测还是撤回主张。
最低编程能力评估记录
统一证据状态
准确系统在可复现且有代表性的任务分布上达到声明的功能、审查、安全、资源与运行阈值。
证据只支持指定任务、仓库、语言、工具、权限、预算与审查控制;迁移仍有边界。
结果在任务类型、仓库、语言、测试、复核者、安全发现或资源等级上显著分化,须拆分报告。
演示、可见测试通过、短函数基准、精选补丁或无记录的 Agent 运行无法建立编程能力。
FUURAA 分析AI 编程能力主张的最小判断单位是“准确系统、Agent 与版本 × 任务、语言、仓库提交及环境 × 上下文、工具、权限与预算 × 独立测试、审查、安全及副作用 × 完整失败分母、人工工作与成本 × 运行控制和截止日期”。生成代码是候选变更的起点;只有独立验证、完整结果与受控工作流,才能支持更窄的‘可用于某类软件变更’结论。
一手来源与不可外推边界
来源于 2026 年 8 月 26 日重新核对。每项保留发布日期、在本方法中的作用与不可外推边界。
区分固定基准准确率与广义准确率,说明重复试验、题目难度、假设与不确定性为何重要。
边界统计建模改善结果解释;不会自动使编程任务代表某个仓库、工作流或真实部署。
打开一手来源 ↗2021 年 7 月 7 日首次提交OpenAI — Evaluating Large Language Models Trained on Code / HumanEval提出 HumanEval 与 pass@k,用于衡量根据文档字符串合成 Python 程序的功能正确性,并讨论重复采样与部署影响。
边界带隐藏单元测试的短小独立函数,不能证明仓库理解、可维护性、安全性或端到端软件工程能力。
打开一手来源 ↗2021 年 2 月 9 日首次提交Microsoft Research and collaborators — CodeXGLUE汇集十四个数据集中的十项代码理解与生成任务,使任务类型和指标选择可见,而不是把编程视为单一能力。
边界跨精选数据集的广度,不等于当前生产性能、安全变更或在活跃仓库中成功协作的证据。
打开一手来源 ↗2023 年 6 月 5 日首次提交UC San Diego — RepoBench区分仓库级检索、代码补全与组合流水线,揭示 Python 与 Java 场景中相关跨文件上下文的重要性。
边界在给定仓库上下文下预测下一行代码,不衡量问题诊断、多步修改、测试修复、审查或运行安全。
打开一手来源 ↗2023 年 10 月 10 日首次提交Princeton University — SWE-bench把真实 GitHub issue 构造成仓库级软件工程任务,需要理解代码库、协调修改并执行验证。
边界解决一个基准实例仍取决于仓库快照、环境、测试、issue 选择、脚手架及基准对成功的定义。
打开一手来源 ↗2024 年 3 月 12 日首次提交LiveCodeBench collaboration — Holistic and Contamination-Free Evaluation使用新发布的竞赛题,并覆盖生成、自我修复、执行与测试输出预测,以降低污染并拓宽代码评估。
边界新鲜竞赛题减少一种污染路径,但不复现私有代码库、模糊产品需求、团队审查、依赖关系或生产运行。
打开一手来源 ↗继续核对