Latent Space 对谈斯坦福 CS146S 讲师 Mihail Eric：AI 时代工程师该学什么

如果去年的编程作业，今年交给 Agent 一句话就能完成，课程该怎么改？

Latent Space 最近邀请 Mihail Eric @mihail_eric 教授讨论了这个问题。他在斯坦福教授 CS146S「The Modern Software Developer」，同时担任 Monaco 的 AI 负责人。一边教学生，一边在真实团队中部署 Agent，让这场访谈不只停留在教育理念上。

整场讨论最值得关注的转变是：代码生成越来越容易，但理解问题、组织工作、验证结果和承担责任，并没有一起变容易。下一代工程师的训练，必须围绕后面这些能力重新设计。

当“交出能跑的代码”不再足以证明学会了

CS146S 不是从零教编程的课程。学生需要已有算法和系统基础，再学习怎样使用 AI 参与真实的软件开发。

第一期课程更像一次 AI 开发生态的巡览，让学生接触代码审查、规格设计、运维等不同环节。但 Mihail 发现，不少教学练习已经可以被 Agent 一次完成。

在他描述的课堂调查中，受访学生几乎都已使用编码 Agent。继续把“独立写出一段代码”作为主要考点，就越来越难区分：学生究竟理解了问题，还是只是拿到了可运行的结果。

因此，新一轮课程将真实开源贡献和维护者审阅纳入作业。

Agent 可以帮助学生快速写出补丁，但它不能替学生回答所有问题：维护者需要这个改动吗？为什么现有代码采用这种设计？补丁会影响哪些其他功能？面对审查意见，又该怎样修改？

考点从“你能不能生成代码”，转向“你能不能提出一个合理的变更，并对它负责”。

真实维护者的反馈，也让教学不再只有标准答案，而是包含真实工程中的协商、约束与取舍。

先理解 Agent，再学习怎样组织 Agent 的工作

这门课并不是简单教一组工具，而是从 Agent 的内部机制逐步走向团队级工程实践。

起点是亲手搭建一个极简编码 Agent，理解模型如何调用工具、读取结果、继续行动。然后再观察生产级工具怎样处理系统提示、计划和上下文压缩。

这个顺序很重要：只有理解基本循环，才容易判断一次失败究竟来自模型、上下文、工具，还是任务定义，而不是遇到问题就换模型、加提示词。

后续内容围绕几个更持久的问题展开：

怎样提供足够的上下文，又不把无关信息全部塞给模型？

怎样把重复工作沉淀成技能，并设计清楚的工具接口？

怎样利用仓库说明、执行钩子和子 Agent，定制工作流程？

怎样让代码库边界清晰、文档可读、结果可验证，真正适合 Agent 工作？

再往后，才是代码审查、安全、后台任务、持续集成，以及团队共用的基础设施。

这背后的教学逻辑是：先学会判断一个 Agent 为什么有效，再考虑如何扩大它的工作规模。

具体工具会变，模型能力也会变。今天必须靠额外提示补齐的能力，明天可能已经进入模型；曾经有用的复杂规则，也可能变成负担。因此，课程更需要训练实验和更新判断的能力，而不是让学生背一份固定操作清单。

真实团队的经验：先买来学习，再决定哪些值得自建

在 Monaco 的实践中，Mihail 用一句话概括工具策略：先通过采购理解问题，再自建需要长期掌握的能力。

代码审查是采购的例子。团队尝试产品后，认为 Devin 有实际帮助，于是继续使用，而不是为了拥有完整技术栈就全部重做。

Agent 工作区则走向自建。后台 Agent 要运行产品、复现故障、测试补丁，这些能力与公司的云架构和开发环境紧密相关。Monaco 因此基于 Coder 建立了 Monacoder。

配套工程文章提到，早期依靠本机多个会话和 Git worktree 来扩大并行，带来了端口冲突、磁盘占用和通知混乱。问题并不是“再开几个 Agent”就能解决，而是需要隔离、可复现的工作环境。

他们还构建了 Slack 机器人 Hal：工程师可以用它排障、提出代码变更，销售人员则可以用它理解产品。

同一套系统服务不同角色，交付形式却不同。工程师需要可检查的修改，销售需要清楚的产品解释；把一堆调试日志交给销售，并不算完成任务。

这说明，Agent 的产品价值不只来自模型能力，也来自环境、权限、上下文和交付形式是否匹配使用者。

Agent 看得到代码，却未必知道“为什么”

访谈提出了一个很现实的问题：Agent 可以读取当前代码，但六个月前团队为什么否决过类似改动，它去哪里找？

代码记录了当前实现，却不一定记录曾经讨论过的选项、客户承诺、风险判断和组织决策。

缺少这些背景，Agent 很可能再次提出早已被否决的方案，或者在局部优化中破坏重要约束。

这也是为什么团队不能只追求更大的上下文窗口，还需要让重要决策有明确记录，让 Agent 知道哪些信息具有权威性、哪些约束不能自行改变。

对工程师来说，越来越重要的工作，是把隐含背景变成可查阅的依据，把“差不多可以了”变成可验证的验收条件。

新的瓶颈，是审查和理解

当代码生成成本下降，团队不一定按同样比例加速，因为审查、测试、发布和决策仍然需要时间。

节目配套材料引用的 Faros 研究指出，高 AI 采用团队的 PR 合并量增加，同时审查时间也明显增长。它提醒的不是“少用 AI”，而是：生成端提速之后，后续环节可能成为新的瓶颈。

课程因此也讨论怎样解释代码差异，帮助人真正理解修改，而不只是快速点下批准。

一个有用的检验方式是：让 Agent 解释变更，再反过来提问。哪些问题你仍然回答不了、必须重新打开代码才能理解？那些地方，就是尚未掌握的部分。

“看过解释”不等于“理解了变更”，正如“测试通过”不等于“这个功能值得做”。

意图、架构、安全边界、产品取舍和最终发布判断，仍然需要人承担责任。

这与 Addy Osmani 的观点不谋而合

读后感：初级工程师需要更早练习判断，而不是跳过基础

这场访谈并没有证明完全无人值守的软件工厂已经成熟，也没有说明基础编程知识可以省略。

恰恰相反，当 Agent 能替人完成更多实现，判断实现是否正确、是否合理，就需要更扎实的理解。

变化在于，过去工程师可能通过大量手写代码，逐步接触审查、架构与业务取舍；现在，实现过程被压缩了，但这些判断能力不会自动随之获得。教学和团队培养必须有意识地补上这一段。

斯坦福这门课提供的方向，是让学生更早接触真实仓库、真实维护者和真实约束；Monaco 的实践则说明，要让 Agent 持续有效，必须同时建设环境、验证和组织记忆。

下一代工程师的竞争力，不只是“能让 AI 写出什么”，而是能提出值得做的改变，组织可靠的执行，并证明自己理解结果及其后果。