第 4 讲：客座讲座：结合 Rust 课程谈 AI 编程的经验与教训

上课时间：2026 年 11 月 3 日（第 8 周，周二 19:20–20:55）
所属板块：客座讲座
主讲人：陈嘉杰

前 3 讲介绍了 AI 编程的基础用法。这一讲来自 2026 年暑假的 Rust 小学期课《程序设计训练（Rust）》：70 位同学在三周内用 AI 做一个 Agent，最后提交设计文档、完整代码和完整的 AI 对话历史。下面按大作业的六个阶段，分别看好例子和反例。

背景

这门 Rust 小学期课的大作业只有一道题：用 AI 做一个 Agent。70 位同学分三个阶段推进：

最终提交设计文档、完整代码和完整的 AI 对话历史。这次讲座把 70 份“从选题到交付”的记录拿出来分析，看哪些做法有效、哪些地方出了问题。

Rust 小学期课的评分构成是：功能实现 30%、项目报告 20%、阶段检查点 15%、同伴互评 15%、选题与启动 10%、代码质量 10%。报告要求反思 AI 的使用方法与过程，并且要交完整 AI 交互记录。怎么用 AI 本身也是考察内容。

六个阶段

选题

某学生想做掼蛋 AI 教练。第一天他没有让 AI 写代码，而是先评估这个方向值不值得做，确定具体问题、MVP、架构和范围。MVP 和范围定下来之后，才开始写 Rust，最大的技术风险在写代码前就排掉了，后面几乎没有返工。

方向定下来后，他又先做了最小技术验证：在 WSL 环境里对真实合法的掼蛋决策点拿到每个合法动作的 Q 值，不开发 Rust Agent，也不重构仓库。立项前花一两天，把最难的一步单独跑通。

另一名学生做到一半发现项目走向和自己的想法完全不一样，选择回退到 MVP 实现之前，签一个新分支重建。他保留了已经确认的决策和大体的选题方向。因为有 git，回退一次的成本不高；方向错了，代码越多越难改。

反例是某学生：项目从头到尾只有一条一句话的提示词，19 分钟后 AI 交付了 1800 行代码、14 个文件和 12 个单测。评语是“人的参与程度太低”“部分功能未实现”。还有一名学生反复要求 AI 继续生成或整份重写，最后也说不清为什么这么设计、该从哪里改。

选题阶段多花一小时，能省掉后面两周的返工。代码是 AI 写的，但项目得是你自己的。

设计

某学生做 draw.io 绘图 Agent，第一件事不是写代码，而是让 AI 做技术选型：比较 drawio-cli 和 drawio-rs，选轻量渲染的方案。选型定完才开工。他还要求 AI 注意单元测试，AI 自己跑了 366 次 cargo test。技术选型错误的代价很高，改回来要重写；先比较两个方案再选，比直接选错更省时间。

另一名学生把协作规则写进了 AGENTS.md：每次迭代先改设计文档并汇报，人确认后再执行。规则写一次，之后每个新会话自动生效，不用每次重新解释人和 AI 怎么合作。

还有一名学生进入实现阶段的第一件事是先定接口。他冻结了架构和范围，先做 Rust 与 Python Strategy Backend 的最小 JSON-lines 协议设计，只做协议审查，不写实现代码。设计不只是文档，还得把接口确定下来。

还有一名学生想不出设计问题时，让 AI 通查设计文档、尽可能细致地追问。他还要求设计文档面向用户，不写决议号和版本号的注释。想不出问题的时候，让 AI 来问。

实现

某学生给子代理派活时，把“不许做什么”写得和“要做什么”一样清楚：只许改指定的三个地方，不动某条会话链逻辑，禁止新增依赖，完成后 typecheck 必须 0 错误。边界既控制修改范围，也给出停止条件：不是改完代码就停，而是 typecheck 全部通过。模型最常见的两种破坏是顺手重构别的文件、补一个看起来合理的字段。

另一名学生的做法是小步推进：71 个短会话，每个平均 2.5 轮对话，每个会话只做一个可验收的小改动，重构留到专门的会话。一次只改一处，改完立刻验证。

还有一名学生先和 AI 把架构聊清楚，写出实现计划，再把整份计划贴回去作为执行依据。计划里写清做什么、明确不做什么、怎么算完成。这样换会话、换模型都能接着跑，计划本身也容易审计。

反例是另一名学生：10 天、690 轮对话、0 次工具调用，228 段 Rust 代码由 AI 给出后人工复制，再手工 cargo build，35 次把终端输出贴回来。结果是修改成本高、没有版本管理、只有代码没有文档、全程 0 次 cargo test。用 Code Agent 让 AI 在仓库里干活，人不是剪贴板。

调试

某学生很少转述 bug，而是把问题现场原样交给 AI：出问题的网页保存成文件让它自己解析，整段终端日志直接粘，界面上的文字连着按钮一起贴。复述会丢细节，而 bug 常常就在细节里；原始材料也让 AI 没法用“可能是环境问题”搪塞。缺点是可能浪费上下文。

另一名学生在模型看到死循环就想改代码时把它拦住，要求先确认推测和依据。另一名学生让 AI 复盘出问题的那一轮，分析里面不必要查询反映了哪些架构问题。模型有时会基于错误假设循环做无用功，先让它说清假设，能挡掉很多无效改动。

反例是另一名学生：改一个 800 多行的单文件程序，报错后把整份代码和报错一起丢回去，要求 AI 整份重写。结果已经修好的地方再次被改坏，说不清这次改了哪几行，13 次编译、0 次测试。改一处、说清为什么，不要整份重写。

验证

某学生检查 Web 应用时，没有让 AI 读代码，而是让它以真实用户的身份把运行中的界面用一遍：必须通过已连接的浏览器交互，不能只读源码、历史会话或静态截图，也不修改代码和配置。角色是真实用户，边界是只诊断。模型说“我懂了”不算数，模拟用户跑一遍才算。

验收标准要写成确定的条件。另一名学生的 Minecraft 开服 Agent 要求至少能在本机用 127.0.0.1:25565 连接成功进服务器；另一名学生的目标是一次硬刷新都不要、一次红条用户都看不见；还有一名学生先给出标准答案，再让 AI 对着结果找原因。

反例是另一名学生：225 次工具调用、63 次编译、16 次写测试，但很多开发与要求无关，进度混乱，项目一度建在 git 仓库之外，最后五天没有任何记录。跑得多不等于做得对，要符合课程的验收标准。

收尾

某学生在多轮修改之后，让 AI 回头读一遍所有提示词，思考有没有可以优化的表述；也让 AI 读整条轨迹，找多余的查询；再对着检查点清单逐条自查。局部修补容易出现全局范围的不一致，让模型通读一遍常能发现矛盾。

反例是某学生：导出的上下文特别长，但由人写的提示词只有 4 条、416 字，其中两条还是重复的。评语是人的参与程度太低、设计文档没讲清楚。另一名学生交的是项目运行日志，不是开发日志，评语说传的不是 AI 开发过程中的对话历史。

更常见的问题是需求失忆。Rust 小学期课的评语里出现最多的扣分项是“要求没做完”，其次是文档、代码质量和配置项。有人到提交时才发现功能没完成；更常见的是设计文档写了一套、代码实现了另一套。评语里还提到六条硬性要求实现不全、缺少上下文历史管理、不能配置思考模式和上下文长度。

作业要的不是“AI 很努力”的证据，而是你如何指挥 AI 的证据：怎么定义问题、怎么否掉方案、怎么验收。平时要对照评分细则，时不时检查是否满足要求。

同一件事，两种做法

一些数据

对 70 份记录做 Spearman 相关分析，按相关系数排序：

• 正相关：消息数、活跃天数、会话数、人类提示词数、写测试的次数；
• 负相关：指令长度、超长提示词的比例。

投入决定下限，做得完整的同学，工作量普遍是另一批的数倍。但真正拉开差距的是 AI 使用方法：同样的时间，有人做出了能演示、能讲清楚的项目，有人只有一份看起来很长的日志。

优秀作品

优秀作品展示

几条原则

• 先让 AI 评方案，决定权留在自己手里；
• 边界和验收标准要具体，最好写在同一个任务里；
• 让 AI 先确认推测和依据，再动手改；
• 验收时让它以真实用户身份跑一遍，而不是只读代码；
• 收尾时让它复盘整条对话，并对照要求逐条自查。

结语

1. 先想清楚，再让 AI 动手。需求没定下来之前，不要开始生成代码。
2. 让 AI 跑起来，而不是“看起来对”。单元测试、模拟用户去测试，而不只是生成代码。
3. 判断权留在人手里。否定方案、改需求、回退提交，这是你的作品，不是 AI 的作品。

与本课程项目的关系

本讲不布置新检查点。检查点 3（中期检查）于 11 月 8 日截止，可以结合这一讲的方法继续推进项目。具体要求见检查点 3：中期检查。

相关材料

• 第 3 讲：代码生成、理解与调试
• 检查点 3：中期检查
• 课程大作业
• Rust 小学期课作品展示