与 Anthropic 共话软件工程的未来
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：当AI审查比人更靠谱，程序员正变成“智能体牧羊人”。软件开发的复利时代已至，SaaS的壁垒正在瓦解。文章来自编译。
最近，我和 Sivesh 与 Anthropic 的 Ash Prabaker 共同主持了一场关于软件工程未来的圆桌会议。出席会议的还有来自 Stripe、英伟达（NVIDIA）、微软（Microsoft）、Google DeepMind、xAI、苹果（Apple）、Scale AI 的工程负责人，以及 OpenClaw/OpenAI 的传奇人物 Peter Steinberger。
Claude Code 的起源
会议以重述 Claude Code 的起源故事拉开序幕，其中大部分内容在公开采访中已有所提及。这个项目始于 2024 年底一个简单的终端界面（Terminal UI），最初非常粗糙。其开发的核心原则是：针对模型在 6 到 12 个月后的预期能力进行设计，而非受限于当时的水平。它的普及是自发形成的——这是一个由基层工程师（IC）驱动的项目，通过展现出的实际价值而非行政命令实现了规模化应用。
递归改进论
贯穿整个讨论的一条主线是“闭环”开发。一位与会者描述了他们公司的流程：Bug 报告由智能体（Agent）自动分拣，按严重程度分类，对照评估集（Eval set）进行检查，然后直接开启修复 PR（拉取请求）——整个过程几乎无需人工干预。全场达成共识：这种闭环正是复利收益的真正来源——更出色的编程工具能改进模型，而更好的模型又反过来优化编程工具。几位负责人指出，正因为这种良性动态，他们的公司正将编程任务列为优先处理事项。
工作流的变革
与会者交流了各自工程实践中正在发生的转变：
测试先行已成为默认准则。多人表示，他们现在会先定义测试用例，然后让智能体围绕这些用例进行构建——他们认为，面对海量的 PR，这是唯一理性的处理方式。
两级评估体系。一位参与者概述了他们团队的方法：一是回归评估（Regression evals），必须在每个 PR 中保持 100% 的通过率；二是针对新能力的前沿评估（Frontier evals）。在场其他人纷纷表示认同这种模式。
不要强制推广。这一点引发了强烈共鸣。一位与会者提到，他们通过竞赛、黑客松和非正式奖励来引导使用，而非自上而下的硬性要求。他认为强迫使用会滋生抵触情绪，而让员工亲眼看到早期试用者的成果，反而能自然地推动工具的普及。
代码审查正处于变动中。一位与会者承认，他们公司的开发人员往往在几分钟内就点击批准，因为 AI 审查层已经做得足够出色。在被追问最终走向何方时，他们坦言“必须由人工审查”的模式最终会变得效率低下，并暗示在某些代码库（Repos）中，他们可能已经跨过了那个临界点。这番话让在场人员既感到共鸣，又隐约有些不安。
注释回归。几位与会者发现了一个有趣的文化反转：起初，工程师们讨厌智能体生成的冗长注释，但现在的共识转向保留这些注释，因为下一个智能体在处理任务时会发现它们非常有用。有人将其总结为：“我们现在编写代码，既是为了让人读懂，也是为了让 AI 读懂。”
终端里的生活。一位参与者描述了他的个人工作流：制定计划、验证计划、通过智能体执行、然后继续下一个任务——全程无需逐行阅读生成的代码。这引发了关于何时这种做法是安全、何时又是危险的辩论。
仍需严密审查的领域
并非所有代码都应一视同仁。与会者普遍认为，任何涉及破坏性操作（如数据丢失、权限提升）或核心基础设施的代码都值得更高强度的人工审查，而内部原型则不需要达到面向公众代码的同等标准。至于界限究竟划在哪里，各家公司标准不一。
瓶颈所在：长跨度任务
大家一致认为，长跨度任务（Long-horizon tasks）是真正的挑战前沿。一位参与者指出，虽然产品工程已经开始呈指数级增长，但在更复杂的科研工作流中实现闭环尚未成功。大家共同面临的开放式问题是：你到底该给一个运行四五小时的智能体分配什么任务？如何观察它？如何在无需时刻盯着的情况下保持“有人参与”？目前还没有人能给出一个完美的答案。
基础设施与沙箱机制
讨论涉及了行业对沙箱（Sandboxing）态度的转变——最初为了安全趋向沙箱，后来为了便利弃用，现在又带着更多细节回归（如远程编程智能体、单次会话独立沙箱）。大家提出的实际痛点包括：长时间会话的算力消耗、权限管理以及企业级部署。
可观测性与值班制度
一位参与者描述了早期的内部原型：拥有日志、源代码控制和聊天系统访问权限的智能体，可以处理突发事件的分拣和调试——尽管系统尚未达到生产级，但已经减轻了值班（On-call）负担。几位与会者发现了一个有趣的副作用：没有基础设施背景的工程师现在也能参与基建工作，因为智能体填补了他们的知识空白。
上下文管理
有人问道，当成千上万的人每分钟都在修改代码时，如何大规模管理上下文。在座者的坦诚回答是：没人搞清楚了这一点。一位参与者承认，他们的方法基本上是碎片化的——通过 MCP（模型上下文协议）让智能体读取临时聊天记录，并依靠强大的写作文化，但并没有正式的文档化流程。
会议提到了一项研究，表明预加载的 Markdown 上下文文件有时效果不如让智能体从基础原理出发遍历代码库。反方意见认为，这可能反映了上下文内容的陈旧或由 AI 生成的问题。大家达成的共识是：人类编写的上下文文件是有益的，而 AI 生成的或陈旧的文件则可能适得其反。人类必须提供核心见解。
人才招聘
谈到招聘时，最引人注目的观点是：一位参与者现在最看重的特质并非原始的工程技能，而是对最前沿技术不断尝试的意愿。他们表现最好的员工是那些对模型局限性有深刻理解，知道何时该信任输出、何时该人工干预的人。另一位参会者指出，由于 AI 辅助的跨领域协作，他们的核心基础设施团队一直保持精简，让产品工程师也能在传统领域之外做出贡献。
SaaS 面临压力
这部分的讨论非常热烈。与会者分享了他们在内部已经取代的工具类别：
事件管理——有人说他们的团队撤掉了供应商的工具，因为它对于实际的工作方式来说太复杂了。
鉴权层——一位参与者声称在六个月内多次迁移了鉴权系统，每次迁移只需数小时而非数周。
项目跟踪——有人正在编程智能体之上开发定制化 UI 来管理工程任务，并暗示这一整个类别可能就是下一个被取代的对象。
内部微型工具——短链接生成器及类似工具是几个人提到的“信手拈来”的战果。
大家注意到一个模式：到目前为止，被取代的都是开发人员工具，因为工程师在这些领域拥有决策权和执行速度。面向业务的软件（如 CRM 等）粘性更高。有一种观点认为，现有的业务工具之所以能生存，不是因为它们好用，而是因为还没有人推出引人入胜的 AI 原生替代品——目前只有一些增量插件。
场内的一个反驳观点是：机会成本论（“我们应该专注于自己最擅长的事情”）可能永远成立，这意味着模型实验室可能永远不会把开发 SaaS 替代品放在改进模型之前。
“万物皆可选”带来的问题
现场的一位初创公司创始人提出了反面观点：由于 AI 让一切都变得可行，确定优先级变得更难了。六个月前，在内部重新构建一个工具显然不值得；现在，只需一个晚上。由于可以做的事情太多，团队反而不堪重负。除了定义清晰的“泳道”并将个人视为组织内的“微型公司”所有者之外，没有人能给出更好的答案。
代码质量
当有人问及代码质量标准时，得到的回答是其定义正在发生变化。“好代码”过去意味着以人为本——简单、易于维护、易于参与贡献。现在，它还必须考虑 AI 的可读性。现场的务实观点是：强大的回归评估和测试先行原则，比“整洁代码”的审美更为重要。
设计品味与糟粕
“紫色渐变风”引来一阵笑声——大家都认出了这种典型的 AI 生成的 UI 审美。有人指出了一处进退两难的境地：如果你更新了模型的品味偏好，所有人都会去用它，而这种新审美很快就会变成下一代“AI 废料”。还有人注意到，某些模型会主动引导用户使用特定的框架，这实际上形成了一种锁定效应。
趋同风险
一位与会者担心，如果每个人都使用相同的模型进行编程并接受相同的建议，整个行业会陷入工具和模式的同质化。反驳意见认为，这在早期模型中风险更大，因为当时模型在热门 Web 技术栈上比在旧系统或冷门语言上强得多——而现在这种差距正在缩小。旧系统的代码现代化被认为是一个进步极快的领域。
后台智能体
大家普遍同意，发展方向是异步后台智能体——它们运行在远程沙箱中，可以通过手机监控，并能持续运行数小时甚至数天。有人提到，长达数小时的自主运行直到最近才成为他们的常规操作，而在此之前一直处于实验阶段。
模型 vs. 框架（Harness）
当被问及最近的提升有多少归功于模型权重，有多少归功于外部框架（Harness）时，一位参与者的观点是两者都重要，但节奏不同——巨大的跨越来自模型的进步，而框架的设计哲学应当是“别挡着模型的道”。他们描述了一个极简原型——基本上就是当前一代模型配上系统提示词和 Bash 访问权限——其表现出奇地好，这在几代前的模型上是不可能实现的。
受监管行业
一位拥有金融科技背景的人询问了受监管环境下的部署。现场的解读是：在受监管行业（以法律科技为例）最成功的 AI 初创公司，本质上仍然是“有人参与”的文档对话产品。在受监管的工作流中，还没有人实现向自主智能体的跨越。这里的门槛是不对称的——类似于自动驾驶，AI 必须比人类表现得好得多才能被接受。更好的可解释性和结构化审计追踪被认为是开启这一领域的钥匙。
多智能体编排
答案出奇地“低科技”：Git 工作树和十个终端标签页。虽然第三方正在构建更复杂的编排工具，但在座没有人声称已经解决了这个问题。
数字化转型的讽刺
有人观察到，让工程师采用 AI 工具——寻找带头人、克服阻力、管理变革——这恰恰是其他行业多年来面临的数字化转型难题。将这一套应用在那些亲手构建了转型工具的工程师身上，其中的讽刺意味让全场心领神会。
编程语言的发展轨迹
最后的问题是：智能体是否会开始编写更接近底层（Metal）的代码，绕过那些为了人类方便而存在的抽象层？观点是肯定的，终将如此，但前提是模型认为这样做有利于性能——而不是因为底层代码对模型更简单。目前的模型仍然受益于结构良好、注释清晰且人类可读的代码。有人指出，初创公司中出现了向 Rust 迁移的趋势，部分原因在于 AI 抹平了学习曲线。
关键要点
递归循环是真实存在的。更好的编程工具产出更好的模型，进而产出更好的编程工具。多位参与者表示，这就是为什么他们的公司将编程放在首位。
瓶颈已从编写代码转向管理长跨度任务，以及在受监管环境中部署智能体。
开发者工具正首先被取代。具有网络效应的业务侧软件目前依然稳固。
人类的角色正从编写和审查转向规划、评估和引导——而表现最出色的人是那些始终站在技术最前沿的人。
企业级应用的普及受限于权限管理、沙箱机制和监管审慎，而非模型能力。
当数百万人使用相同的模型做出相同的选择时，内容的平庸化和趋同性是切实的担忧。
上下文管理仍未解决。人类编写的上下文有帮助，而陈旧或 AI 生成的上下文可能会产生负面影响。
译者：boxi。