代码库自动驾驶：AI 时代的工程新范式
Towards Self-Driving Codebases
当前 AI 代理在软件工程中正处于 Gartner 技术成熟度曲线的“幻灭低谷期”，盲目堆砌 token 并未带来预期的生产力爆发。文章指出，未来的核心不在于让工程师沦为提示词工程师，而在于将低价值的代码维护、Bug 修复、前端一致性检查及增长优化等工作完全移交给 AI，让人类专注于高杠杆的创意与架构设计。实现这一愿景的关键在于构建 Agent-legible 的开发环境、建立跨工具链的 Global memory 以及防止代码腐化。只有当开发环境足够完善，AI 代理才能真正接管大部分工作，推动软件工程进入真正的“自动驾驶”时代。
GitHub Copilot 为我们提供了代码行的自动补全，而 AI 代理将为我们提供整个产品的自动补全。
HN 评论区
83- CharlieDigital
其实，如果智能体犯了很多蠢错，这完全没问题。真正不能接受的是它们反复犯同样的错误。
我在生命科学领域工作过一段时间。临床试验中有一个流程叫“纠正与预防措施”（CAPA）。在容错率低的领域（例如航空业）也能看到类似的流程。
原理很简单：一旦发生错误，就启动你的 CAPA 流程（在 Google 搜索 CAPA 表格看看示例，就能推断出该流程的大致模样），找出根本原因，并修正导致该错误发生的流程本身。
（至少作为生命科学领域的 SaaS 供应商，当我们遇到 CAPA 事件时（例如发生 SEV0 级故障后），它会纳入我们的标准作业程序（SOP），然后我们必须重新接受 SOP 培训。审计员会要求查看我们的 CAPA 证据、SOP 版本以及培训记录。这对大多数公司来说可能过于极端，但我补充这些是为了提供背景信息。）
大多数工程团队缺乏执行这一流程所需的纪律，因为它需要一定的严谨性。
这是否应该完全由智能体自主完成？是否应该有人类介入来审批 CAPA？这些都是有待解答的开放性问题。
- calldacopsidc
很抱歉纠结于可能只是点缀性的文字，但第一句话……“智能体可以一键完成真正有趣的游戏”，呃，比如哪些？
我很想被证明是错的，但感觉我在大约 3 个模型的发布中看到的都是同一个基础的一级赛车游戏。甚至不确定它们是否真的是一键生成的，我肯定无法把它们描述为“有趣”。
- 2001zhaozhao
归根结底，我们已经有适用于人类的流程，也知道哪些测试、验证和评审能让代码库健康增长。我们只需要尽可能好地将这些设计适配给 AI。
AI 相比人类有很多优势，比如速度快、可控性强、默认设置友好（例如 Claude 会在无人提示的情况下写出有帮助的注释，这比大多数工程师都要好），以及以比人类团队低得多的成本实施最佳实践（如全面的测试）。在我的个人项目中，使用 AI 让我能以比手动编写低得多的错误率来开发软件，因为现在我可以建立自动化测试套件，而以前我根本没有时间去做。然而，AI 也有缺点，比如僵化、上下文窗口有限、默认缺乏创造力等，这些需要通过约束（例如让不同的智能体拥有独立且压缩良好的上下文）或通过人工评审层来规避。
我怀疑代码自动化的最佳核心模式是创建一个“工程经理”智能体层，能够灵活地将一套工程实践应用于手头的具体问题。它将处理所有到达人类之前的代码智能体请求，并通过提示使其在做出决策时可靠地考虑大局。只有在问题真正阻塞时，它才会极其罕见地将问题或计划评审直接升级给人类；更可能的情况是，它会整理从底层代码智能体获取的信息并呈现……
- aerodexis
这对我来说很有道理——我看到它会沿着两条独立的路线并行发展：
一是将人类从网络防御的 OODA 循环中移除。Servlet 库（例如）将变得像流体一样，具备自修改能力，其运行契约与今天截然不同。围绕这些事物的工程实践也需要改变。
二是用户体验（UX）将具备自修改能力。就像 pi 可以自我修改一样，我认为这将成为面向用户应用程序的通用实践。也许会出现一个文本框，用户可以在其中描述微调需求，并请求应用程序功能如何变化。工程应用的重点将转向建模应用程序运作的不可协商部分，并提供正确的原语，供用户驱动的 LLM 实时修改软件，同时跟踪和回滚更改。此外，关于如何确保即使用户试图移除广告，广告仍能正常投放，也会有一些有趣的变数。
- drob
我是作者，大家好！如果有任何不清楚的地方，我很乐意进一步阐述我们的思路。
我们撰写这篇文章是为了配合产品发布，大家可以在此查看：https://x.com/danlovesproofs/status/2095182189499711759