代码生成之后，工程师学什么：Mihail Eric 的斯坦福课程与 Monaco 实践

一、嘉宾背景

Mihail Eric 是斯坦福大学兼职教授，也是 Monaco 的 AI 负责人，在斯坦福教授 CS146《The Modern Software Developer》。他的工作连接着课堂与企业工程：一方面，将 AI 原生软件开发整理成可教授的知识与训练；另一方面，在实际业务中处理编码代理和复杂代码库。课程设计与工程实践因此成为本期访谈中相互参照的两条线索。

本期 Latent Space 由 Alessio Fanelli 与 Shawn swyx Wang 主持，谈话约两小时，围绕 CS146 的重构展开。Eric 说，课程于 2025 年秋首次开设，录制时正进入第二轮，刚结束第一周。他已经开展的教学、Monaco 已经使用的系统，以及后续课程准备探索的安排，因而处于不同阶段，完整教学计划尚不能视为经过验证的成果。

Eric 的课堂工作，是将实践中的工程问题转化为学生需要完成的训练：既要理解代理内部机制，也要进入复杂仓库，处理结构、验证与协作要求。访谈中的课程安排与企业案例提供了从业者的经验和判断，也保留了这个领域尚未形成固定答案的问题。

二、本期主要内容

CS146 的调整，始于教学练习与工具能力之间的错位。Eric 说，上一版课程主要沿软件开发生命周期介绍编码代理工具，涉及规格、代码审查和 SRE 等用途；新版则更重视上下文工程、设计、架构与生产代码库实践。算法等传统计算机科学知识依然是先修基础。他认为，新人需要具备更强的系统判断能力，并用 Google L3 与接近资深工程师的能力作类比。这是他对教育与就业要求的判断，并非对行业统一招聘标准的描述。

作业也随之改变。Eric 发现，过去一些教学练习很容易由代理一次完成，学生即使交出答案，也未必理解设计。新版课程因此强调向复杂开源仓库贡献代码，并接受维护者的直接审查。任务的难度来自理解既有系统、辨认约束和回应反馈，而非增加必须手写的代码量。

课程先让学生理解代理如何工作。Eric 用约两百行代码展示一个能够交互、调用工具并修改文件的核心循环，同时明确排除 MCP、子代理等扩展。随后，他通过代理工具查看 Claude Code 的真实请求，拆解 system、plan 与 compaction prompt。将最小循环与真实产品放在一起，学生便能看到两者之间还需要哪些工程工作。课程再从代理内部机制、上下文、skills 与定制，延伸到代码库准备、审查、安全、后台代理、团队基础设施和软件工厂。

Monaco 的业务让这些工程问题有了具体落点。Eric 将其描述为 AI 原生销售平台，初期主要服务早期创业团队，销售 harness 支持客户定位、销售管线管理和会前准备等工作。平台结合 Parallel、Exa 与内部 enrichment，补全公司和联系人数据库。访谈将人员换工作作为潜在销售信号来讨论；GTM 人员则帮助客户落实工作流，并将领域经验固化到平台中。Eric 表示这些能力有助于预约会议，但没有提供销售改善的量化数据。

Monaco 对内部工具采取按需采购与自建的方式。团队基于 Coder.com 建设 Monacoder，为长时间运行的代理任务提供隔离环境；Slack 机器人 Hal 用于调试、提交修复 PR，以及回答销售人员的产品问题。代码审查仍采购 Devin。Eric 将这一原则概括为先采购以了解需求，再决定哪些能力值得长期自建，具体取决于产品成熟度和基础设施适配情况。他说，Devin 后来的推广来自工程师主动申请使用。这反映了团队的接受度，尚不能替代对生产率收益的测量。

三、核心观点：推理、例子与边界

代理能力提高后，工程判断的重心也在变化。Eric 观察到，一些 Git 操作与任务设置指导后来从系统提示中消失，他将此理解为模型能力增强的表现，也因此更看重少量通用工具。不过，提示删减本身不足以证明相关知识已经进入模型权重。模型与 harness 之间如何分工，需要随着能力变化重新评估：旧模型依赖的示例，可能成为新模型的多余约束，规则越积越多，也未必让系统更可靠。

在大型陌生仓库中，这意味着要把关键判断放在实现之前。Eric 介绍的 RAPID 方法先研究代码，再提出备选方案，由人选择后形成计划或规格，最后实现并测试。这样做能让架构分歧在大规模修改开始前显现，人仍有机会调整方向。Eric 主张，这套方法可以用于数百万行代码库；访谈没有提供对照结果，尚不能据此判断它在不同项目中的成功率。

上下文工程同样需要取舍。子代理需要足够背景才能理解任务，但如果继承全部历史，也可能把早先随口提出的意见当成硬性规则。主持人倾向于让全局审查者获得完整信息，Eric 则强调压缩、汇总与及时刷新。这两种考虑可以同时成立：执行者需要集中处理当前任务，审查者需要识别跨任务的矛盾。双方没有给出统一的最优策略，信息如何分配，仍取决于角色与任务。

Skills 的讨论进一步涉及人能否理解代理的产出。Eric 提到的 explain diff 会将变更可视化，并通过测验检查使用者是否理解；组织层面的 skill 则可以记录 API 规范与服务边界。swyx 建议实际运行 skills，删去无效内容，并收紧触发条件，避免为某个项目编写的流程在无关任务中启动。技能库是否有用，要看运行反馈与适用边界，Markdown 文件的数量说明不了这一点。同样，代码生成得多，也不能证明使用者理解了系统。

扩大代理规模之前，系统必须能够验证并接收它们的输出。Eric 将可验证性、清晰的仓库结构和代理对代码库的理解视为基础。他指出，合并队列拥堵、应用启动缓慢，可能比代理数量不足更迫切。他用假设中每天三十多个 PR 的情况说明审查压力，并讨论部分变更自动批准的可能性。这个数字用于推演，并非实际产出记录；哪些变更可以自动批准、人工是否仍需逐行检查，讨论中都没有定论。

每个 PR 都写得详细，也不等于系统的长期意图得到了保存。Monaco 用详细的 PR 描述记录实现、文件指引与服务边界，将其作为局部实现规格。主持人关心的则是跨 PR 的约束：今天局部合理的修改，会不会撤销几周前的决定？Eric 提到 Basis 通过版本控制维护规格与 canonical state 的做法，但访谈没有据此提出通用方案。解释当前变更与维护长期意图彼此相关，却需要分别处理。

安全问题也无法单靠增加自动化解决。Eric 强调依赖追踪与版本锁定，主持人则质疑“把依赖改成内部实现就一定更安全”的判断：自研代码同样会有缺陷，开源项目的用户群也可能帮助发现问题。模型还可能引入人类不熟悉的漏洞，因此，代码成本下降并不能直接推导出软件更安全。基础设施整合也面临类似限制：MCP 门户与模型网关可能共同承担治理、安全、审计和成本控制，但组织内的职责归属会阻碍整合，门户业务本身也尚未得到验证。主持人以 OpenRouter 的专注路线为例，质疑是否需要把所有功能打包在一起。技术上能够合并，仍不足以决定组织与产品应如何选择。

软件工厂仍需要人定义意图、审查系统，并理解产品要求、技术约束与衡量指标。访谈中，八成至九成代码由代理编写属于假设情境；三成多贡献完全由代理完成，则是主持人转述的厂商说法，两者都不是统一口径下的测量结果。动态工作流的设想，是按任务生成专用代码或 harness，供子代理执行。Eric 表示 Monaco 在 GTM 中采用了相关模式，但没有披露实现细节或比较评测。这一方向仍有待研究，现有讨论不足以证明它普遍优于复制父代理的方式。

四、学习与应用

对学习者而言，生成代码与解释代码需要分别检验。可以先复现最小工具调用循环，观察模型如何选择动作、修改文件，再研究真实产品如何组织计划和压缩上下文。接着，在真实仓库中完成一项变更，接受维护者反馈，并借鉴 explain diff 的方式说明设计与行为变化。这些训练来自 Eric 的课堂安排；约两百行示例提供了理解代理的入口，生产 harness 所需的扩展与控制机制仍需另行处理。

进入陌生代码库时，RAPID 可以转化为具体的工作约定：先提交仓库研究结论与备选方案，明确需要人作出的选择，再实施和测试。多人或多代理协作，还需要交代各任务所需的背景、有效约束，以及结果如何回传。传递全部历史，需要检查其中是否夹杂过期意见；只传摘要，则需要检查关键限制是否在压缩中丢失。这是在运用访谈提出的取舍，尚不能当作已经证明最优的流程。

团队增加代理之前，应先检查代理能否理解仓库，以及测试、构建、启动和合并环节能否承受更多变更。如果出现积压，应先定位瓶颈，再决定是增加代理、改善基础设施，还是调整审查方式。访谈还讨论了将构建日志、生产分析接入事件触发代理，把问题发现与调查、修复连接起来。Eric 描述的多服务故障沙盒，可用于练习如何提出诊断假设。复杂服务依赖可能提高 AI SRE 的价值，但这一判断不足以推出所有小型系统都需要采购专门平台。

知识维护则需要同时处理当前变更与长期约束。PR 说明解释本次实现，长期规格保存跨变更的约束和决策。Skills 可以承载反复使用的 API 规范与服务边界规则，但需要实际运行、删减内容并测试触发条件。无论采用哪种载体，都要明确谁负责更新；文档生成之后，代码与设计意图仍可能逐渐脱节。

安全要求也应落实到具体任务中。处理数据存储、计费、认证与授权前，需要理解 AuthN、AuthZ 和 IAM，才能准确提出要求并审查代理的实现。依赖追踪、版本锁定、扫描和安全审查需要配合使用，单独一项都不足以构成保证。工具采购同样应按用途评估：Monaco 自建后台代理能力，同时继续采购代码审查工具。评估时，需要区分基础设施适配、团队使用意愿与量化收益，工程师愿意采用某个工具，并不直接证明它提高了生产率。

编排系统与动态 harness 实验也需要明确的交付目标。主持人谈到自己支付工资与 token 成本却未获得产品的经历，提醒工具建设本身可能持续消耗资源。Eric 建议从整体系统出发判断投入，讨论也质疑了仅用 PR 数量衡量表现的做法。对于学生项目，Eric 打算提高要求；主持人建议选择有挑战、能够运行的项目，包括复杂开源贡献、问题明确的 benchmark 或 eval，以及方法和限制可供检验的工程文章。他们预期这些作品具有求职与商业价值，但没有提供效果测量。访谈提及支持一千多个代理实验的资源安排，也仍是设想，并非已经完成的实验或得到验证的能力。验收这些工作，需要回答具体问题：交付了什么，如何验证，在什么条件下有效，以及投入是否值得。

来源

• 原始节目：One Million AI Engineer Special How Stanford Teaches AI-Native Engineering — Mihail Eric, Monaco