北京
上周，斯坦福丢出了一份文档，每一位在用AI写代码的开发者都该看看。这份东西叫CLAUDE.md，归属于CS336（从零开始的语言模型）课程，里面是一套毫不客气的规则——直指AI智能体应该如何、以及不应该如何帮学生写代码。
这份文档在Hacker News冲上第一不是没道理的。它管的远不止学生。如果你用过Claude Code、Cursor、Copilot，或者任何同类工具，这些规则会捅破一层窗户纸：工具能做到的，和工具应该做的之间，有条让人不舒服的裂缝。GitHub刚对Copilot推出按token计费，开发者那边已经炸了。张力指向同一个问题：AI辅助从什么时候开始，从帮忙变成了添乱？
斯坦福的态度没有留任何余地：“AI智能体应当充当教学辅助，通过解释、引导和反馈来帮助学生学习——而不是替他们完成作业。”这不是学术上的空谈。这是一条设计约束，直接映射到职业开发场景。一个三十秒能帮你提PR的智能体，和那个凌晨两点代码崩了你却不知道该怎么查的智能体，是同一个东西。
文档划出了一条硬线。AI可以做的事包括：通过引导推动理解来解释概念、审阅你的代码并指出可改进的地方、提出引导性问题而不是直接给出修复方案、引用文档讲义和调试工具、建议你做合理性检查、加断言、用性能分析器排查问题。
AI不该做的事项写得更直接：不得编写任何Python代码或伪代码、不得补全作业里的TODO段落、不得提供问题的解答、不得直接编辑学生仓库里的代码、不得把需求直接转成可运行的代码、不得指向第三方实现。
对职业开发者来说，这个“不得做”的清单可能显得极端。但换个场景看：如果你正在啃一个新代码库、一门新语言、或者一个陌生的业务领域，清单上每一条都是通往依赖的路径。
斯坦福的指引里还包含一套结构化的教学方案，可以干净地映射到代码评审和结对编程中。这套六步法先问澄清性问题——你试过什么？你期待看到什么？实际发生了什么？接着引用概念，指向文档、讲义或前人经验，而不是直接给答案。
然后建议下一步，不动手实现，只指方向。通过对话来审阅代码，以讨论的形式点出可改进之处，而不是甩出一个补丁。解释“为什么”，理解原因远比拿到修复更重要。
最后，优先测试而非修复——在重写代码之前，先建议你做形状断言检查、构造玩具输入、用性能分析器探查。这套框架不是专为AI智能体设计的，它同样适用于任何一个团队日常的协作方式。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
