最近，Anthropic Claude Code 团队的 Daisy Hollman 在 NDC Conferences 做了一场分享。整场没怎么谈新功能，她讲清楚了一件正在发生的事：

软件工程正在从"人写代码，机器执行"，转向"人定义意图，Agent 组织实现"。

她提出了一个值得认真推演的假设：当 Agent 写出的代码比你更好时，软件工程会变成什么样？

她没有要求听众立刻相信这个假设一定会发生，只说即使持保留态度，也值得提前想一想：Agent 如何真正进入大型软件项目，而不是停在做几个漂亮原型的阶段。

一、 大模型是 AI 时代的意图编译器

Daisy 没有直接说"大模型就是编译器"，但她的描述，处处在给这个比喻铺路。

1.1 编译器没有淘汰程序员，只是搬走了价值

传统编译器把高级语言转换成机器码。程序员不再手写汇编、分配寄存器，开始用更高层的语言描述程序，编译器负责处理大量实现细节。

编译器出现后，程序员的价值没有消失，只是换了地方：手写汇编不再是核心能力，抽象、算法、系统设计和工程判断变得更重要。

1.2 这一次被编译的是意图，不是语言

大模型正在把这种迁移推进到更高一层。

它不只是把一种语言翻译成另一种语言，而是把人的意图、代码、文档、约束和工具反馈，转换成一系列可执行的工程动作：读取信息、调用 shell、编辑文件、运行测试、查看 CI 结果，再根据反馈决定下一步。

Agent 的本质，就是"理解、行动、获得反馈、继续行动"这个循环。所以，大模型更准确地说是一种意图编译器。它把人对系统的描述，编译成代码修改、命令执行和工程决策。

1.3 输出不确定，所以它需要一整套编译环境

传统编译器建立在明确的语法和语义规则之上，同样的输入通常得到确定的输出。大模型的输出则依赖上下文、工具、反馈和概率。

它可以生成一段能运行的代码，却不会自动知道这段代码是否符合团队架构，不知道某个异常该被修复还是被隐藏，也不会关心三个月后谁来修改它。

所以，大模型不是一个孤立的代码生成器。系统提示词、机构知识、代码库、CI、生产监控、Hooks、权限边界和 Agent teams，共同构成了新的编译系统，模型本身只是其中最显眼的部分。

如果 Agent 只能看到一个代码仓库和一个 shell，它就像一个只能看到半张设计图的编译器：不知道团队为什么拒绝过某个方案，不知道生产环境最近发生了什么，也不知道某个内部术语在这家公司具体意味着什么。

Daisy 说得很直接：如果 Agent 做不到你能够做的事情，它就不可能真正和你一起完成工作。

1.4 工程师要设计的，是这套编译系统

这也是上下文工程变得重要的原因。上下文不是把所有资料一股脑塞给模型，而是让正确的信息在正确的时间出现。

模型能力越强，工程师越不能只盯着代码本身：

• 上下文决定 Agent 能理解什么
• 工具决定 Agent 能做什么
• 反馈闭环决定 Agent 能否及时纠错
• 架构约束决定 Agent 不能做什么 
  过去，工程师主要把设计编译成代码。未来，工程师越来越多要设计的，是一套能把意图稳定编译成可靠系统的环境。

二、 Agentic Programming 不等于软件工程

2.1 智能体编程解决的是"连续行动"

Daisy 在演讲开头明确区分了智能体编程和智能体软件工程。

Agentic programming 主要解决模型如何连续行动：调用工具、读取结果、再调用下一个工具。编码 Agent 使用的工具，通常就是程序员熟悉的 shell、文件编辑、代码运行、编译和 CI。

2.2 软件工程有一大半不在源代码里

团队聊天里的决定、CI 中暴露的失败、生产监控里的异常、设计文档中的取舍、内部 API 的约定，以及两季度前尝试过但没有落地的方案，都是软件工程的一部分。

一个只能修改文件的 Agent，最多是一个速度更快的程序员。只有当它能访问并理解这些工程信息，在权限和流程边界内行动，接受即时反馈并保留决策痕迹，它才真正接近软件工程师。

这也是为什么 Daisy 说，她关心的不是让人用 Agent 做更多"可爱的原型"，而是让非技术人员和半技术人员也能参与构建真正的生产软件。

软件工程师未来的工作，也许不是简单地被 Agent 取代，而是帮更多人和更多 Agent 做好软件工程。

三、 上下文窗口是一个有限的盒子

3.1 原则只有一条：不为没有用到的东西付费

过去一年，模型能力快速提升，从代码补全逐渐走向长时间自主工作。但上下文窗口并没有以同样的速度增长。

这意味着，不能把整个代码库、所有文档和所有工具说明一起塞进模型。放进去的每一段文字，都会和真正用于完成任务的空间竞争。

3.2 MCP、Skills、Sub-agents 是三种不同的省法

Daisy 介绍的几种抽象，都是围绕这个问题形成的：

• MCP 适合连接外部系统，但工具数量一多，描述就会迅速占满上下文
• Skills 可以按需展开完整说明
• Sub-agents 可以把复杂任务放进独立上下文，再将摘要返回主会话

它们都比无条件注入大量文字更有效，但仍然存在规模边界。

3.3 Hooks 是 Agent 的红色波浪线

Daisy 最喜欢 Hooks，因为 Hooks 不触发时几乎不占上下文。它们在工具调用、用户提交提示词或上下文压缩等事件发生时运行脚本，先判断信息是否相关。相关内容才进入上下文，不相关就快速退出。

类型检查、lint、格式校验和部分架构规则，不必等到任务结束才反馈，而是在错误刚发生时就提醒模型。

这就引出一个判断：想让 Agent 在某个代码库里表现更好，最快的路不一定是换一个更聪明的模型，也可能是把反馈闭环建得更紧。

四、 从一个会话到一支 Agent 团队

4.1 Anthropic 内部的并行做法

当代码生成速度提高后，单个会话会成为新的瓶颈。Daisy 分享了内部并行运行多个 Claude Code 会话的方式：

• 用 git worktree 隔离工作目录
• 为长期任务分配固定身份
• 让 Agent 之间互相发送消息
• 用 fleet view 统一查看所有会话

4.2 但并行不等于规模化

多个 Agent 可以同时修改代码，却不能自动保证这些修改彼此兼容。它们可能分别完成了任务，却共同改变了系统边界、接口语义或故障处理方式。

所以，多 Agent 工作必须建立在清晰的任务边界上。每个任务应该能独立验证、独立回滚、独立合并。Agent teams 需要统一的接口、权限和验收标准，也需要有人负责判断多个局部修改是否改变了系统的整体语义。

4.3 人的注意力，是系统里最小的盒子

Daisy 还提到，未来的瓶颈可能不再是模型输入质量，而是人的注意力。她把人的注意力称为系统里最小的盒子。

fleet view 的价值，正是把多个会话的状态压缩成很短的信息，让人快速知道每个 Agent 在做什么、刚完成了什么，还需要什么。

未来的软件工程，管理的不只是代码和任务，还有人的认知空间。

五、 Daisy Hollman 的方案能解决维护问题吗

5.1 便宜的第一阶段，和昂贵的第二阶段

Vibe coding 让做出一个产品变得非常便宜。用户描述想法，Agent 生成页面、接口和数据库，再通过几轮对话修正细节。对快速验证想法、搭原型来说，这是好事。

问题通常在产品进入第二阶段后出现。功能开始互相依赖，需求在变，故障跨模块蔓延，最初为演示准备的代码却被当成了系统本身。

代码能运行，不等于代码能解释；测试能通过，也不等于代码能安全地修改。

5.2 技术债没有消失，只是失去了债主

AI 生成代码的风险，不只是代码粗糙，而是代码很容易失去明确的维护责任。

过去，工程师亲手写下临时方案，通常知道哪里埋着债，也知道为什么暂时接受这个取舍。现在，代码由 Agent 生成，测试又是绿色的，团队很容易把它当成已经完成的工作。

5.3 当目标是让测试变绿，最短路径未必是正确路径

许多编码 Agent 的评价仍然偏向短周期、可自动验证的结果。测试能否通过是一个重要指标，但没法完整评价架构是否清晰、模块是否解耦、命名是否准确，也没法直接回答半年后另一个工程师能否安全地修改这段代码。

举个真实的小故事：某次项目里出现了空指针异常。真正该查的是上游对象为什么为空、调用关系是不是设计错了。但对模型来说，最快让测试变绿的办法，是在外面包一层 try-catch。异常暂时不再抛出，任务完成，奖励到手。

Bug 表面消失了，原因却藏得更深。下一次有人动这段代码时，维护成本才真正兑现。

这就是"能运行"和"值得维护"之间的差距。

5.4 Daisy 给出的是必要条件，不是充分条件

她的演讲没有直接讨论 vibe coding 的技术债，也没有给出一套已经闭合的长期维护方案。但她在大型软件工程上的分析，正好给这个问题提供了一个判断框架。

答案要分成两部分。

对于大型软件项目如何让 Agent 工作，Daisy 给出了相当具体的方向：让 Agent 访问工程师能够访问的信息，把机构知识和工具放进有限的上下文盒子，在错误发生时立即反馈，选择能随规模增长继续有效的抽象，再通过多会话管理减少人的注意力切换成本。

这些机制可以让 Agent 在大型代码库中更可靠、更高效地工作，也为长期维护提供了必要条件。但必要条件不等于充分条件。

可维护性是一种跨时间的系统属性。它涉及未来的需求、未来的维护者、未来的依赖变化，也涉及今天的设计决策会怎样影响明天的修改。只要评价闭环仍然主要奖励"测试通过"，Agent 就不会天然地为半年后的维护成本负责。

5.5 两个 Agent 都只看测试，等于同一套盲区查了两遍

让另一个 Agent 做代码审查当然有价值。它可以发现格式问题、明显缺陷、重复代码和部分安全风险，也能提高代码质量的下限。

但如果审查 Agent 用的仍然是同一套短期评价标准，它并不能自动补齐长期架构判断。第一个 Agent 只看测试，第二个 Agent 也只看测试，结果是同一套盲区被检查了两次。

要解决 vibe coding 的长期维护问题，关键不在让 Agent 少写代码，而在让每一次修改都进入有边界、有证据、有反馈、有人负责的工程流程。

六、 软件工程的下一步，是把可维护性编译进去

如果把大模型看成意图编译器，那么 vibe coding 的长期维护问题，就是这个编译器目前更擅长编译"能运行"，还不擅长稳定地编译"值得长期维护"。

它能根据自然语言快速生成页面、接口和数据库，却还不能仅凭一次提示，就理解一个组织多年积累的边界、取舍和失败经验。

Daisy Hollman 给出的方向，不是把所有信息写进一份巨大的提示词，而是建立一套能随规模扩展的工程环境：扩大 Agent 能看到的信息，缩短它拿到反馈的时间，再把它正在做什么及时传回给人。

这解决了 Agent 如何进入大型软件工程的问题。接下来还需要更完整的工程制度，去解决代码如何在多年变化中保持可维护的问题。

未来的软件工程师，可能不再是代码的主要生产者，而是"意图到系统"这条转换链路的设计者。模型负责扩大实现能力，工具负责建立反馈闭环，工程师负责定义边界、保留证据和安排未来的维护。

真正高级的 Agent，不光能写出更多代码，还知道什么时候不该写、哪些信息必须先拿到，也知道一段看似成功的代码可能给未来留下什么代价。

代码只是表达，真正的核心是工程。

参考来源

• Daisy Hollman, Anthropic Claude Code 团队，NDC Conferences 演讲 (https://www.youtube.com/watch?v=shZgedW15vg)