未来18个月的研究重点：自主编程的下一步发展方向

研究重点：未来18个月的自主编程

人工智能驱动的编程助手已在改变软件开发。到2025年末，像GitHub Copilot和AI聊天机器人这样的工具将被大多数开发者日常使用，甚至非程序员也能通过简单的提示来原型化代码。谷歌CEO指出，这一趋势——常被称为“情感编程”（vibe coding）——正使编程对非技术人员而言更易上手 (www.itpro.com)。然而，实际部署暴露了一些重要缺陷。AI生成的代码常包含不易察觉的错误，在复杂项目中表现不佳，并引发了责任和政策问题。要从实验室演示走向可靠的生产系统，我们需要在四个方面进行重点研究：可靠性、长期规划、可验证性和社会技术治理。下文我们将概述关键的未解决问题，并提出研究议程、基准和合作方案来解决这些问题。

1. 可靠性与代码质量

一个主要问题是基本的可靠性：AI助手编写的代码仍然比人类编写的代码包含明显更多的错误。例如，对470个GitHub拉取请求（PR）的分析发现，AI编写的PR比人类编写的PR多出约1.7倍的问题 (www.itpro.com)。平均而言，AI PRs引发约10.8个问题（逻辑错误、命名或格式问题、安全漏洞等），而人类PRs约为6.5个 (www.itpro.com)。值得注意的是，AI编写的代码存在更多严重的“尾部”错误（逻辑错误和安全漏洞的出现频率几乎是人类代码的两倍） (www.itpro.com)。在实践中，使用AI工具的团队报告了意料之外的问题：代码在独立查看时看似正确，但在集成时失败或带有隐藏缺陷。实际上，一项针对代码生成工具的全面调查指出，现有基准未能捕捉到生产环境中出现的故障模式——例如幻觉般的API调用、不一致的命名或通过单元测试但仍然存在的微妙逻辑错误 (doi.org)。简而言之，AI可以生成可运行的代码片段，但这些片段通常不适合生产环境 (doi.org)。

开发者的经验也反映了这种不信任。一项大型SonarSource调查（由行业媒体报道）发现，尽管72%的工程师每天使用AI工具编写高达42%的代码，但高达96%的人承认他们不完全信任AI的输出 (www.itpro.com)。然而，不到一半的团队在提交前始终审查AI生成的代码 (www.itpro.com)。这种高使用率但低信任度的差距导致了专家所称的“验证债务”。如果没有更好的可靠性，组织在使用AI编程捷径时，就有引入难以发现的错误和技术债务的风险 (www.itpro.com)。

研究议程： 我们需要系统地研究AI代码中的错误模式，并开发新的方法来缓解这些问题。思路包括自动化AI验证：集成静态分析器或辅助模型，扫描AI输出以查找常见错误（类似于第二位评审员）。更好的LLM训练目标可以侧重于稳定性——例如，通过在有缺陷的代码和干净的代码示例上进行训练，教导模型倾向于更安全的解决方案。研究人员应分析哪些类型的代码（算法、I/O、安全关键型）会使AI的内部启发式方法出错，并开发专门的防御措施。例如，早期研究已指出AI工具过度使用危险的捷径（硬编码密码、低效循环等） (www.businesswire.com) (www.infoworld.com)。我们必须将这些故障模式规范化。

教育解决方案也有帮助：正如社区准则所强调的，AI工具只能辅助——人类必须验证 (firefox-source-docs.mozilla.org) (chromium.googlesource.com)。为鼓励这一点，未来的工具可以自动生成警告，甚至在没有人类批准的情况下拒绝处理任务。基准测试应转变：从“代码能否编译”转向“还剩下多少微妙的问题”。例如，代码评审AI模型正在出现，专门衡量错误检测性能 (docs.factory.ai)。一项社区努力，旨在生成一个包含真实AI与人类代码更改（带有缺陷标注）的公共数据集——类似于CodeRabbit的PR研究——将使研究人员能够追踪可靠性方面的进展。

2. 长期规划与维护

AI代码生成器擅长小型、独立的任务，但大型项目则暴露出其局限性。真实的软件会随着时间演变，需要管理不断变化的需求、多个文件和架构决策。调查指出，“生成正确的独立函数与在大规模代码库中维护一致的架构决策存在质的差异” (doi.org)。在实践中，即使是最先进的模型也难以处理多步骤、多文件的任务。两项近期基准测试突显了这一差距：

• RoadmapBench (2026年5月) 评估真实开源项目中的“长期”升级。每个任务都给代理提供一个项目的基线版本和一系列要实现的功能，涉及50多个文件，约3700行代码的修改。即使是Claude-Opus-4.7，作为最强大的模型之一，也只解决了约39%的任务，其他模型甚至低至5% (papers.cool)。相比之下，简单的一次性错误修复任务中，AI的表现几乎完美。RoadmapBench的作者总结道，“长期软件开发仍然是一个悬而未决的问题。” (papers.cool)

• SlopCodeBench (2026) 考察迭代开发。代理被赋予一个任务并生成代码，然后在20轮中任务规范发生变化，迫使代码进行演进。结果：尽管所有中间版本都通过了现有测试，但AI生成的代码库变得冗长2.2倍，并且比人类维护的代码更难维护 (www.techradar.com)。事实上，没有一个顶级模型解决了完整的序列：到最终检查点时，成功率骤降至约0.5%。这表明，在AI辅助下，小的设计错误会累积，阻碍未来的修改 (www.techradar.com)。

这些发现表明研究应侧重于规划和分解。AI系统不应仅仅根据提示“编写代码”，而应规划多步骤的策略。一个新兴的理念是计划与执行：让模型首先勾勒出设计或步骤序列，然后为每个步骤生成代码 (crabtalk.ai)。事实上，对编程代理（Claude Code、GitHub Copilot等）的分析发现，将规划与执行分离（并将计划展示给用户）可以显著提高复杂任务的性能 (crabtalk.ai)。研究应开发新的架构：例如，嵌套代理，其中一个“管理器”LLM将大问题分解为由工作LLM处理的子任务。还需要长期记忆机制：未来的模型应该记住会话早期生成的代码，即使超出上下文窗口。

基准： 社区应定义反映真实开发工作的基准。除了RoadmapBench，我们还需要涵盖多种语言和集成挑战（前端/后端、数据库等）的任务。模拟的团队项目将测试AI和人类在发布过程中的协作情况。借鉴软件工程的理念，基准不仅可以衡量正确性，还可以衡量可维护性（添加新功能有多容易？）、性能（AI代码在演进过程中是否退化？）和集成度（是否符合现有风格约定？）。例如，基准可以从一个现有代码库开始，要求代理实现一系列功能请求或重构，并进行定期测试。在接下来的18个月中，创建此类开放挑战（可能通过学术-工业竞赛）将指导多阶段编程的研究。

3. 可验证性与形式化接口

随着AI助手尝试执行更关键的任务，确保正确性变得至关重要。可验证性意味着将代码与精确的规范或测试套件关联起来，以便我们确信它能按预期运行。在传统工程中，人们在编码之前会编写形式化规范或详尽的测试。我们如何将这种思维带入AI驱动的编程中？

一个机会是“闭环”生成。最近的研究提出，AI生成的代码、其文档字符串以及任何形式化注解都应进行一致性检查。例如，Clover方法在生成代码的同时自动生成形式化规范（使用Dafny等语言），然后使用证明工具拒绝不一致的解决方案 (theory.stanford.edu)。在早期测试中，这在教材级别的数据集上检测到所有不正确的程序。类似地，AutoACSL使用静态分析提示LLM编写精确的函数契约（前置/后置条件），然后用Frama-C进行验证 (papers.cool)。通过反馈未满足的条件，它显著提高了可证明正确代码的百分比。这些例子表明，在代码生成步骤中集成形式化方法可以将不受控制的AI猜测转化为经过验证的程序。

除了形式化数学，我们还需要非形式化规范、测试和代码之间更好的接口。如今，常见做法是用英语描述一个函数，然后希望AI能做对。但我们也应该让AI生成或要求测试用例、类型注解和设计注释。例如，提示可以首先要求模型用自然语言或伪代码描述算法或不变量，然后才进行编码。或者我们可以采用契约优先开发：编写AI必须满足的单元测试（或属性测试）。这些想法的初步探索已显示出前景：即使只生成几个基于示例的测试，也能引导模型避免平凡的解决方案。

基准： 新的基准应包含形式化检查问题。例如，我们可以增加任务，其中“正确性”由定理证明器或符号检查器验证，而不仅仅是单元测试。包含LTL/TLA+或Alloy规范以及相应代码的用户故事数据集将非常有价值。在教育领域，像TLA+模型检查挑战赛这样的竞赛表明，编写规范是困难的——一项研究发现，当前LLM在直接的TLA+规范上的语义正确性仅达到约8% (papers.cool)。开源项目可能会更广泛地发布规范语言（一种编程宣誓书）。AI可以利用API规范或数据模式的标准化格式（YAML、JSON）来使代码与预期行为保持一致。

4. 社会技术治理与信任

最后，自主编程引发了人员和政策问题。谁来对AI代码负责？我们如何确保安全性、版权合规性和问责制？一些组织已开始解决这个问题，但仍存在未解决的问题。

开发者实践： 如前所述，行业调查显示存在信任差距。开发者知道应该审查AI输出，但如果更简单，他们常常会跳过这一步，导致风险无法管理 (www.itpro.com)。作为回应，主要项目已制定了明确的规则。例如，OpenInfra基金会允许AI辅助，但前提是提交必须带有“Assisted-By:”或“Generated-By:”标签 (openinfra.org)。谷歌的Chromium项目也类似地要求作者完全理解任何AI建议的代码，否则将失去提交权限 (chromium.googlesource.com)。Mozilla的Firefox政策直言不讳地指出：“AI可以辅助，但责任始终由变更背后的人承担” (firefox-source-docs.mozilla.org)。即使是NumPy项目也警告说，你必须能够解释所提交的任何代码，无论它是否由AI编写 (numpy.org)。这些政策强调，仅有技术工具是不够的——我们还需要清晰的工作流程和文化。

法规和标准： 在更广阔的范围内，政府和标准制定机构正在迎头赶上。欧盟正在最终确定通用AI实践准则，这将要求AI模型提供商采取透明和安全措施 (digital-strategy.ec.europa.eu)。虽然这并非专门针对编程，但它预示着对训练数据许可和模型可解释性将进行更严格的审查——如果你的代码助手使用了受版权保护的代码，这两点都高度相关。同样，ISO和IEEE已开始制定AI治理和伦理标准，尽管只有少数直接涉及代码生成。欧盟的《AI法案》和即将出台的美国指导方针可能会影响公司内部审查AI代码的方式。

需要合作： 弥合这些社会技术差距将需要共同努力。学术界可以研究AI工具如何影响团队生产力、漏洞发现和许可；行业可以分享匿名的真实AI相关事件数据；标准机构（如W3C、IEEE）可以将编程场景纳入道德AI准则。例如，研讨会可以召集SAT-EL（软件保障）专家和机器学习人员，共同定义AI代码安全性的评估标准。指南可以演变为标准（例如“IEEE 8201: AI辅助软件过程”），为组织提供一个通用框架。在接下来的18个月中，通过白皮书、行业联盟或开源政策模板，就最佳实践达成共识，将有助于团队负责任地采用这些工具。

5. 研究与基准议程

总而言之，我们建议研究界采取以下具体步骤：

• 增强型基准： 开发一套模拟真实软件项目的基准。例如，多模块框架（Web应用、API、嵌入式系统），其中AI必须实现新功能并随后维护它们。包括演进的规范（模拟不断变化的需求）。不仅衡量测试通过率，还要衡量代码复杂性、可读性、安全指标和评审工作量。与行业合作，获取真实的错误修复历史和功能请求作为基准任务。

• 错误分类学研究： 系统地分类AI引入的错误类型。CodeRabbit的报告给出了初步分类（逻辑错误、命名问题等） (www.infoworld.com)。一项更大规模的学术研究可以收集PR数据，并对AI与人类的错误进行分类。这将指导新的模型损失函数（例如，对安全性施加额外权重）和自动化检测器（标记典型AI错误模式的工具）。

• 规划与多代理研究： 探索规划器/执行器代理等架构。研究如何为AI系统提供跨会话的某种形式的记忆或强制执行分层规划。与代理AI和机器人领域的现有工作合作（将多步推理方法重新用于代码）。

• 形式化方法集成： 投资于像Clover和AutoACSL这样结合程序合成和证明的研究。鼓励形式化方法研究人员与NLP/ML团队合作。例如，学术竞赛可以将LLM代码助手与证明器配对，共同完成任务。创建AI生成证明或契约推理的竞赛。

• 治理框架： 对团队实践和责任进行社会科学研究。例如，进行开发者研究：为团队提供AI工具，观察他们如何审查和调试。知识产权方面的法律研究：正如一篇博客所指出的，“Copilot版权问题”（未经许可的代码）是一个悬而未决的问题 (www.systemshardening.com)。标准机构应起草关于AI代码数据许可和归属的清晰指南。

• 工具和接口： 最后，构建展示最佳实践的工具原型。一个例子：一个AI编程IDE插件，它自动对任何AI生成的代码运行静态分析或测试并警告用户。或者一个CLI工具，标记代码库中所有AI辅助的部分。鼓励开源项目采用“AI使用”徽章或提交消息约定。这些非正式标准日后可以形式化。

通过定义社区基准并举办多机构挑战赛（例如AI编程马拉松以实现某些安全或可维护性目标），我们可以追踪进展。可以将其比作ImageNet如何推动了计算机视觉领域的发展：我们需要一个反映真实开发的共享“代码版ImageNet”。早期的努力（RoadmapBench、SlopCodeBench、Sigmabench (sigmabench.com))指明了方向，但接下来我们应扩大其规模并使其广泛可用。

6. 形式化接口：规范、测试与代码

一个核心的机会是将规范和测试更紧密地集成到编码循环中。在传统开发中，规范描述代码应该做什么，测试则检查它。AI工具可以帮助连接这些。例如，一种有前景的实践是规范驱动生成：首先编写一个（可能是非形式化的）规范，然后提示AI进行编码。更好的是，可以与AI共同开发规范。例如，可以询问助手：“为这个需求生成单元测试”，然后“使用这些测试来验证代码”。这创建了一个形式化接口：自然语言规范、它所隐含的测试以及代码形成一个紧密的三角关系。

在研究方面，可以定义一个规范的标准格式（例如描述功能的YAML或JSON模式），并要求AI系统能够使用它。TLA+、Alloy或BDD风格工具（Cucumber）等工作可能会被集成：想象一下告诉AI，“请生成满足此TLA+模型的代码。”尽管目前的LLM不擅长从头开始编写TLA+ (papers.cool)，但将人工编写的抽象规范与AI增强的代码生成相结合值得探索。目标是让团队能够轻松生成AI可以遵循的可运行规范（即使是非正式的）。然后可以自动生成形式化测试：最近的研究表明，GPT模型可以在给定函数行为描述的情况下生成基于属性的测试。

更具雄心的是，我们可以创建形式化规范模板。对于云部署或安全关键代码，可以定义一个模板（例如，带有字段的“用户认证流程”）。AI填写模板并生成代码；验证器检查契约。通过提供这些接口，我们将编程从一个黑盒转变为一个更受控的流程。像“TLA+的AI工具”或“LLM到规范翻译”（一些研究组正在进行中）这样的倡议是早期的例子。在实践中，即使是部分采用（要求AI输出注释或类型签名）也能提高正确性。

作为开发者的第一步：现在就整合简单的规范-测试循环。例如，如果使用ChatGPT，可以从写“我们想要一个做X的函数，先写测试。”开始你的会话。然后要求它生成实现。即使没有花哨的形式化工具，这也能强制执行一个原则，即AI始终生成附带检查的代码。随着时间的推移，这种习惯可以形式化为AI编程的标准。

7. 合作：学术界、工业界与标准机构

实现这些目标需要广泛的合作：

• 学术界可以通过创建和分享数据与基准，以及发布严谨的评估报告来做出贡献。大学应与公司合作，获取真实代码库进行测试。研究实验室可以就长期代码质量或已验证代码生成等任务举办开放挑战赛（并设奖金）。

• 工业界必须提供反馈循环。部署AI编程工具的公司应匿名分享错误统计数据、贡献者经验和功能请求。科技公司还可以资助会议（如ICSE、FSE）上的“AI编程”研讨会或专题。他们可以开源部分政策（就像谷歌对Chromium的AI政策所做的那样 (chromium.googlesource.com))，以便他人学习。

• 标准机构（IEEE、ISO、W3C等）应将编程纳入现有的AI伦理和安全标准。例如，ISO正在进行的AI治理（ISO/IEC 38507）和AI生命周期（ISO/IEC 5338）工作可以明确指出代码生成。W3C有一份Web ML的伦理原则草案 (www.w3.org)——这可以扩展一个关于编程使用的章节。应为依赖AI的开发团队制定一套轻量级的“实践准则”，就像安全开发标准（如OWASP）存在于安全领域一样。

简而言之，前进的道路是社会技术性的。就像开源社区形成了编码标准和评审文化一样，新兴的AI编程领域也需要共享的规范。联合路线图（例如，AI代码安全行业联盟）和透明度（发布基准和故障案例）将使所有人达成共识。

8. 受益者与入门指南

至关重要的是，AI辅助编程不只适用于专家开发者。这些工具可以普及编程。初学者和领域专家可以使用AI快速启动他们以前没有时间手动编码的项目。例如，市场分析师可以要求AI编写一个数据报告脚本，而不是从头学习Python。艺术家可以通过草拟提示来原型化应用UI。在每种情况下，AI都降低了创作的门槛。

要开始使用这些工具，请遵循专业团队使用的相同敏捷、迭代工作流程：

1. 定义明确的目标或规范。 首先具体说明你想要什么。这可以是对功能的自然语言描述，也可以是简单的步骤草图。对于程序员来说，即使是项目符号列表或用户故事也可以。
2. 使用AI助手起草代码。 运行AI编程工具（有许多可用：在线聊天机器人或IDE扩展），并要求它实现规范。例如，你可以输入“创建一个Python函数，读取CSV并绘制数据点。”AI将生成第一个版本。
3. 验证和完善。 至关重要的是，获取AI的输出并对其进行测试。如果是代码，请在你的环境中运行它。编写或自动生成一些简单测试：它在基本情况下是否给出正确结果？如果出现问题（初次尝试常会失败），向AI提供反馈：例如，突出显示失败案例并要求它修复代码。许多工具允许迭代提示或“多轮”编辑。
4. 寻求解释和文档。 事后使用AI生成文档字符串或注释。这有助于你，这位（新）程序员，理解所完成的工作。你还可以要求AI指出潜在问题或提出改进建议。
5. 逐步增加复杂性。 一旦简单的脚本运行正常，你可以尝试一个小项目（例如待办事项应用、数据分析管道）。将项目分解为多个部分：一次请求AI完成一个组件（数据库模式、前端、业务逻辑）。将其视为结对编程，AI是你的初级伙伴。

下一个第一步： 选择一个对初学者友好的AI编程工具，并尝试一个小实验。例如，使用像GPT-4（具有代码能力）这样的接口或你的代码编辑器中的免费扩展。给它一个简单的任务（“排序列表”、“制作图表”、“hello world网页”），看看它会生成什么。然后阅读代码——即使没有编程经验，也要查看其结构。运行它并注意任何错误。然后重复：完善你的提示（可能添加更多细节或约束）并重新生成。随着时间的推移，你将学会如何与工具有效沟通，以及如何引导它走向正确的解决方案。

新程序员应记住：AI是一个强大的助手，而非神谕。始终检查其工作，并将其视为学习机会。为AI的代码编写自己的测试，运行它们，并提出后续问题，直到你确信无误。这种“先检查后信任”的习惯是每个人——无论是新手还是专家——都应安全地使用AI的方式。

结论

自主编程工具的兴起是一个分水岭时刻，但要充分利用其优势，我们必须正视早期部署所揭示的未解决问题。在可靠性方面，我们看到代码助手比人类犯的错误更多，因此研究必须侧重于错误检测和鲁棒生成。在规划方面，我们看到代理在长期、多步骤项目中表现不佳，因此我们需要针对复杂工作流的新架构和基准。在可验证性方面，我们认识到需要将形式化规范和测试支持内置到AI编程过程本身。在治理方面，公司和监管机构正竞相制定规则，以确保AI代码的透明、安全和可问责。

在接下来的18个月中，在这些领域取得进展至关重要。通过建立严格的基准（从项目规划挑战到AI引发错误的检查），将形式化方法集成到AI编程流程中，以及促进跨学科合作，我们可以弥合华丽演示与实际可靠性之间的差距。愿景是明确的：一个AI编程生态系统，即使是初学者也能安全地创建软件，并且AI生成的代码像人类编写的代码一样值得信赖。实现这一愿景将需要同时塑造技术及其相关实践。通过重点研究和广泛的社区努力，下一代AI工具可以真正为每个人解锁编程——从今天开始。

**`