OpenAI：推进低资源编程语言编码需以行为保留为前提

OpenAI 于 10 月 19 日发布了两项编码评估，将其证据范围扩展至常见语言之外，同时也让生产可靠性仍是一个悬而未决的问题。推进低资源编程语言编码，如今涉及一项要求更高的比较：生成可运行的软件，还是保留现有系统的行为。

该公告涵盖 MultiLangBench——一项覆盖 20 种语言的软件评估——以及另一项 COBOL 迁移评估。COBOL 是 Common Business-Oriented Language（通用商业导向语言）的简称，仍是 IBM 和 AWS 现代化工具关注的重点。核心矛盾在于：模型生成看似合理的代码之后，接下来会发生什么。

对于开发者和企业采购方而言，有价值的问题是，这些结果是否足以支持不同的现代化决策。更好的模型可以拓展值得尝试的工作范围。要判断一个替代方案是否应当承担现有业务流程的责任，则需要更多证据。

推进低资源编程语言编码面临两种不同测试

根据 OpenAI 的低资源编码研究，MultiLangBench 要求模型构建兼容 SQLite 的数据库引擎。SQLite 是一种嵌入式数据库引擎，应用程序无需运行独立的数据库服务器即可使用。

OpenAI 表示，GPT-6 Astra 的平均测试通过率为 87.4%，而 GPT-5.6 Sol 为 26.8%。其单独的迁移评估要求将 COBOL 翻译为其他语言时实现完整的输出一致性。据称，GPT-6.1 Sol 在低推理强度下达到 86.6% 的准确率，在更高设置下达到 97.9%。

这些评估回答的是不同的工程问题，因此不应将其百分比视为可互换的就绪度指标。

数据库构建任务考察模型能实现多少指定功能。迁移任务则考察现有程序的可观察行为能否在翻译后得以保留。两种情境下的成功都很重要，但各自支持的是不同结论。

想想部分数据库得分意味着什么。某个实现可能支持有用的操作，却无法支持其他操作。其实际意义取决于哪些操作仍不受支持，以及应用程序是否需要这些操作。

迁移得分则需要以不同方式解读。通过验收测试的翻译程序会被归入成功组。这一分类并不会揭示其周边部署会有多么困难。

这种区别改变了采购方解读头条结果的方式。跨多种语言的高平均成绩有助于证明覆盖广度，但并不能证明每种语言、任务或应用程序都能获得同样收益。

同样，迁移评估能够证明其所包含程序取得了进展。要将这一结论延伸到组织自身的软件，还需要了解这些程序与其自身系统的相似程度。

因此，该公告为评估提供了有用的切入点，而非一项通用的替换决策。此前因陌生语言性能而失望的团队，有理由重新评估。他们仍需在已发布任务与预期用途之间建立清晰联系。

对开发者而言，直接含义比“AI 编码有所改进”更具体。相关问题变成了：哪些此前不切实际的任务如今值得进行受控试验？这可能包括理解一个模块、提出修复方案，或准备候选翻译。

每项任务都有不同的验收门槛。说明文本在经审阅者修正后仍可能有用。替代程序则需要更坚实的依据，才能让另一个系统依赖其输出。

通过这些门槛来解读公告，既能保留其意义，也不会让结果承担它们无法承担的责任。改进体现在被评估的能力上；部署决策则关乎特定系统。

维护团队面临新的评估负担

更强的生成能力，会使关注点更多转向团队用于接受或拒绝拟议变更的证据。

推进低资源编程语言编码，要求工程组织更精确地定义成功。过去看似难以置信的演示，如今成为内部测试的候选对象。这为维护者、审阅者和业务负责人带来了工作。

负担始于决定哪些内容必须保持不变。程序源码描述其操作，但验收决策还需要预期结果。没有这些结果，审阅者可以识别出可读代码，却无法证明行为等价。

这造成了一种实际的不对称性。生成另一份候选实现，可能比解决一条存在争议的业务规则更容易。如果生成的代码暴露了歧义，仍需要有人有权决定组织所期望的解释。

设想一个涉及周期性账户调整的假设性维护项目。替代方案针对一条异常记录生成了意外结果。工程团队必须判断原有行为体现的是政策、变通方案，还是错误。

这些解释会导向不同决策。保留政策有助于维持兼容性。保留偶发缺陷可能满足迁移要求，却会妨碍另一项业务目标。

因此，语言变更应具有明确范围。行为保留和业务重构可以共享一个项目，但将两者结合会让分歧更难诊断。当输出存在差异时，审阅者需要知道这一差异是否已获授权。

该公告同样给采购团队带来压力。有吸引力的模型结果只是采购决策的一项输入，而有用的采购比较需要覆盖完整的工作流程。

这一流程包括准备材料、审阅变更、调查故障，以及后续维护结果。能够快速生成可接受候选方案的模型，仍可能需要专家投入大量解释工作。

反过来，模型也不必完成整个迁移才能创造价值。如果它能帮助维护者定位依赖关系或解释陌生例程，这种贡献就值得单独评估。更狭窄的用途可以拥有更清晰的验收标准。

这对人员配置讨论很重要。将更好的生成能力视为机构知识的即时替代品，忽视了这些知识在验证中发挥的作用。能够识别异常例外情况的人，可以决定一份表面干净的翻译是否可接受。

对技术负责人而言，最有力的回应是修订评估计划。识别此前失败的工作，定义可观察的验收标准，并依据这些标准比较新结果。已发布的改进提供了动机；内部证据则支撑决策。

短期压力将落在缺乏可用测试或易获取技术记录的组织身上。更好的候选方案会让这些缺失的基础更加明显，但不会自动解决它们。

保留行为让迁移成为不同的编码问题

IBM 文档在其 COBOL 舍入规则中描述了一个具体示例。当小数结果超过可用存储位数时，除非适用操作指定舍入，否则将发生截断。

截断会舍弃多余数字。舍入则可能改变保留值。因此，采用不同数值惯例的翻译即使语法有效，也可能改变结果。

迁移正确性取决于操作的含义，其中包括可被可读替代代码掩盖的细节。

这正是生成代码与保留行为之间的区别变得重要的地方。审阅者可能更喜欢替代方案的表面形式，却忽略了其处理边界情况方式的变化。

一个假设性的账户计算可以说明这一问题，无需涉及特定客户事件。假设现有程序在中间步骤舍弃小数精度。若将这一调整移至最终输出，结果就可能改变。

替代方案在数学上可能看起来合理，但也可能偏离下游流程所预期的行为。决定哪一种结果更可取，既需要业务判断，也需要语言知识。

同样的推理不止适用于算术。迁移评估应考察预期信息缺失、格式错误或以异常顺序呈现时会发生什么。恰当答案取决于系统的契约。

该契约应区分有效的业务响应与技术故障。返回空结果、记录拒绝以及终止作业，是不同的行为。替代方案不应在未经明确决定的情况下抹平这些区别。

对采购方而言，这使测试设计成为现代化主张的一部分。生成翻译和为该翻译生成测试，并不会自动形成独立证据。两项产物都可能反映同一种错误解释。

只要可能，更强的评估应将候选方案与外部参考进行比较。现有输出、获批的业务示例以及经过独立审阅的需求，都可以提供这种参考。届时，分歧将变得可审查，而非主观。

这也解释了为什么成功的语言翻译并不能解决所有现代化问题。组织可能还希望提升可维护性、采用不同部署选项，或明确所有权。行为一致仅覆盖这一议程的一部分。

这里有一种有益的纪律：先确定结果意味着什么，再讨论它是否令人印象深刻。通过的翻译支持关于已测试行为的陈述；成功部署则支持更广泛的运营陈述。

经济性取决于维持这种区别。如果团队在较晚阶段才发现语义差异，早期的生成收益就会变得不那么有参考价值。如果他们及早识别并解决这些差异，更强的模型就能支持更可信的项目。

因此，对于评估 OpenAI COBOL 迁移的开发者而言，核心能力是严谨的保留。团队确定替代方案必须保留哪些可观察细节之后，生成符合语言习惯的替代代码才具有意义。

IBM 和 AWS 在周边工作流程上竞争

IBM 将 watsonx Code Assistant for Z 定位于应用分析、代码解释、重构和转换。该公司还描述了通过测试来比较翻译后的 Java 服务与原始 COBOL 行为的方法。

AWS 将 AWS Transform 描述为一套主机现代化工作流程，涵盖分析、文档编制、业务逻辑提取、规划和代码转换。其文档包含在需要额外信息或批准时引入人工参与的环节。

竞争比较从模型能力延伸至将候选方案转化为获接受系统所需的工作。

这些方法为 OpenAI 的公告提供了有用背景。通用模型评估会隔离出一种可支撑多种产品的能力。现代化平台则描述这些能力如何融入组织流程。

单靠任何一类都无法回答买方的所有问题。专门化工作流仍需要在买方的软件上交出令人信服的结果。能力强大的通用模型也仍需要恰当的集成、审查和运营责任归属。

这种区别改变了公平比较应涵盖的内容。将模型输出与整个产品平台的承诺相比较，混合了不同的分析单位。比较完整工作流，则能让权衡更加明显。

内部试验可以为竞争方案提供相同的限定任务和验收条件。审查人员随后可检查生成的交付物、未解决的问题，以及达成获批结果所需的工作量。

这种比较应保留原始任务边界。若一种方案依赖额外的人工准备，应记录这项准备。若另一种方案在代码之外还能生成有用文档，则应评估审查人员能否依赖这些文档。

目标是识别每种方案的贡献所在。某个组织可能比起广泛的语言覆盖，更重视与现有环境的集成。另一个组织则可能需要在多个互不相关的代码库中获得灵活协助。

这些是不同的采购情境。基准测试无法消除这些差异。它只是为买方决定哪些候选方案值得深入评估时提供另一项证据。

对 OpenAI 而言，战略机会在于广度。能够处理陌生语言的模型，可以成为维护和现代化流程中的一个组成部分。其商业意义取决于组织能否将这种能力转化为获批的工作成果。

对既有供应商而言，相应的压力在于证明附加价值。发现、审查支持、集成和部署协助都应产生可观察的收益。买方需要一种方式，将这些收益与重叠的生成能力区分开来。

互补使用同样存在空间。工程组织可以在现有现代化流程中评估通用模型。关键结果在于，组合后的工作流是否改善了一项已获批的任务。

这种框架让竞争立足于现实。IBM、AWS 和 OpenAI 为同一个组织问题提供了不同切入点：在保留对软件行为控制的同时修改软件。买方应比较每项产品实际承担的责任。

可信的市场回应会提供更清晰的任务边界和更可复现的证据。关于自动化现代化的宽泛主张，会让这种比较更加困难。

通过评估并不能解答生产环境问题

SQLite 自身的数据库测试实践包括崩溃测试、畸形输入、资源故障和回归测试。回归测试用于检查一项变更是否破坏了此前正常工作的行为。

这份文档从独立工程视角说明了数据库可靠性。常规条件下给出正确答案，只是更大型测试计划的一部分。异常运行条件同样需要关注。

通过既定评估只能支持其明确提出的主张；生产环境验收则需要针对评估未能证明的条件提供证据。

这是推进低资源编程语言编码能力时应持有的核心审慎视角。已发布的结果值得按其自身条件进行审视。其解读应止于现有证据的边界。

数据库可以正确回答查询，但在中断或资源压力下仍可能需要调查。这些条件是否重要，取决于预期应用。一次性原型与持久化运营记录有不同的要求。

同样的原则也适用于经翻译的软件。与预期输出一致，并不能独立证明其性能、部署行为或恢复流程可以接受。如果项目依赖这些属性，就需要明确评估。

这并不意味着输出一致性不重要。它只是将一致性界定为一种边界清晰的证据形式。错误在于把一项有用的测量结果变成对替代方案的完整结论。

评估设计也会影响评分能揭示多少信息。买方应考察任务选择、可用工具、停止条件，以及对失败尝试的处理方式。这些细节会影响已发布的结果是否与自身约束相似。

重复实验还会带来另一个问题：团队最终实际得到了什么？最终通过的交付物很有用。了解在它之前经历了多少被放弃的候选方案和专家干预，同样有价值。

缺少这类背景时，团队可能低估复现结果所需的工作量。有了这些背景，组织就能对审查能力和项目范围作出更现实的判断。

文档记录同样存在问题。如果模型识别出一条业务规则，审查人员应将支撑证据与说明一并保留。否则，后来的维护者只会继承另一份缺乏依据的描述。

可搜索的知识库可以帮助访问技术记录。测试执行和领域专家审查仍决定某项拟议解释是否可接受。

对于假设中的迁移项目，重要记录应将某项行为与其测试和批准关联起来。这种关联有助于未来审查人员理解，为什么某项不寻常的操作在重写后仍被保留。

因此，剩余的不确定性在于迁移适用性。当代码库、业务规则和运行条件发生变化时，经过评估的能力是否仍然有用？这是需要通过客户试验回答的实证问题。

OpenAI 的结果足以让人再次提出这个问题。它们并不能替尚未测试自身软件的组织决定答案。

关注可复现性、客户验收和工作流比较

下一项证据应表明，更强的经评估能力是否能减少接受真实变更所需的工作。

未来几个月，应首先关注可复现性。独立团队需要足够的信息来理解任务，并评估其结果是否支持相同结论。

一项有价值的复现应说明模型设置、环境、验收规则，以及与原始设置的偏差。这样一来，差异才具有可解释性。缺少这些细节，相同百分比可能掩盖性质不同的实验。

如果改进在由独立团队选定的任务中持续存在，复现将增强推进低资源编程语言编码能力的理由。狭窄或不一致的结果，则会限制买方应在多大范围内进行泛化。

第二个信号是客户验收证据。应关注那些说明评估了哪些软件、何为成功、以及如何处理未解决差异的案例。一个精美的生成示例所提供的决策价值更低。

强有力的客户证据应区分实验候选方案与运营上已获接受的变更。它还应说明仍由人承担的责任。这些细节能帮助另一个组织判断该经验是否可迁移。

一项边界明确的维护成果，可能比宏大的转型主张更具信息价值。对已验证修复的说明能够确立具体结果。声称现代化变得更容易，则需要额外解释。

对于 OpenAI COBOL 迁移而言，尤其有用的证据是将生成的替代方案与独立批准的行为关联起来。这将加强评估与实际验收之间的桥梁。

第三个信号是对完整工作流的比较。买方应关注通用模型和专门化现代化工具是否在可比约束下接受等价任务。比较需要包括审查和返工。

IBM 的COBOL 现代化工作流和 AWS 的大型机转型工作流说明了这类评估应考虑的更广泛范围。其已发布描述仍属于供应商主张，而非独立性能排名。

如果更强的模型能够持续降低直至验收的工作量，工作流比较将增强该公告的实际意义。若审查和修正占据主导，短期收益仍将较为有限。

无论哪种结果，都不会使底层能力失去意义。它会澄清该能力应处于什么位置。开发人员需要这种清晰性，胜过另一份缺乏区分度的排行榜。

对于工程负责人而言，下一步有价值的做法是选择一项具有权威预期结果的限定任务。在验收讨论中纳入具有代表性的故障和异常输入。将拟议的行为变更与语言翻译分开。记录模型在哪些环节提供帮助、专家在哪些环节介入，以及哪些证据支持批准。随后，将整个工作量与现有流程进行比较。只有当组织能够将生成能力的提升与经验证的结果联系起来时，推进低资源编程语言编码能力才具有意义。在扩大试验之前，向维护者和业务负责人提出同一个问题：什么证据会让你愿意依赖这一替代方案？