去年还管用的编程作业，今年一次提示就能做完。斯坦福《现代软件开发者》课程 CS146S 的授课人 Mihail Eric 在下一轮开课前作出了这个判断——他同时负责 Monaco 的 AI 工作，一边看学生怎么学 AI 编程，一边看工程团队怎么用编程智能体。
CS146S 首次开课设了九次作业和一个综合项目，其中一项练习是让学生在代码仓库上运行 AI 代码审查工具，并评估工具给出的反馈。到了下一轮，Eric 认为许多练习已经可以由智能体通过一次提示完成。他曾询问一群斯坦福大二、大三学生如何编程，受询学生都已在使用智能体。
问题随之变得具体：如果生成代码不再足以体现学习成果，作业还应该考查什么？
作业搬进真实开源项目
新一轮课程把部分作业调整为向开源项目贡献代码，由项目维护者审查学生提交的补丁。与封闭的课堂练习相比，这类任务多了几项不能只靠生成代码解决的要求：
- 确认维护者是否真的需要这项功能；
- 理解现有代码为什么这样运行；
- 判断补丁可能影响哪些其他行为；
- 根据维护者的反馈解释、修改和完善方案。
智能体可以在一个下午实现功能，但功能是否适合进入项目，仍需要沟通与判断。学生也因此获得了向资深开发者学习的机会。变化不只是把作业放进公开仓库，而是让学习成果接受真实项目需求与维护标准的检验。
能提交补丁，不等于能解释补丁
讨论中还介绍了 Geoffrey Litt 的 explain-diff 技能：它会把代码变更转化为可视化讲解，再围绕变更向使用者提问。一个可以直接尝试的练习是，把智能体刚写好的补丁交给它，看看哪些问题会让自己不得不重新打开代码。
能够提交补丁，与能够解释补丁，并不是同一件事。这类练习把注意力从“代码是否生成了”，转向“开发者是否理解了变更”。
买工具与自建环境的分界
在 Monaco，团队评估过代码审查产品，并继续使用 Devin；但对于智能体的工作环境，团队选择了自建。原因是后台运行的智能体不仅需要读取代码，还需要一个能完成实际工程操作的环境，包括运行产品、复现故障、验证修复补丁。这些能力与 Monaco 自身的云端部署方式有关，团队因此搭建了适合自身系统的工作空间。
Eric 把这类取舍概括为：购买是为了学习，自建是为了长期保留。代码审查产品与智能体运行环境承担不同职责，团队也作出了不同选择。
同一个智能体，面对不同角色还要交付不同结果。Monaco 的内部系统 Hal 既能帮工程师调查故障并创建拉取请求（PR），也能回答销售人员关于产品如何运作的问题。如果系统向两类用户都输出大量调试日志，就无法同样有效地满足他们的需求。智能体是否有用，不只取决于能否完成技术操作，也取决于能否交付适合当前角色的结果。
代码之外，还有历史决策
智能体能读取当前代码，但它去哪里了解团队为什么在六个月前否决过类似改动？这涉及当前实现、历史决策和设计意图如何被组织，以及智能体应当去哪里查找这些信息。讨论中的 Basis Authority Map，正是围绕这类信息的查找与权威性展开。
Eric 预测，开源仓库未来可能发展为由智能体运行的软件工厂。这仍是预测，而非已经确立的结果。即使代码生产过程进一步自动化，哪些改动应该进入项目，仍需要有人作出判断。这也呼应了 CS146S 的作业调整：让学生面对真实维护者，不只是训练他们使用工具，也是训练他们理解项目、解释改动，并参与工程决策。
当智能体已经能完成过去的许多练习，考核的重点值得重新讨论：实现一个功能、解释一次代码变更、排查一个真实故障、完成一次被维护者接受的开源贡献——这些任务该怎么安排比重？又用什么方式，区分“智能体完成了任务”和“学生掌握了工程能力”？
热门跟贴