如何设计一场 AI Coding 结业项目与答辩

训练营最后的结业项目，我不希望它变成一场“谁的页面最炫”的展示。AI 很容易生成漂亮首屏，但课程真正训练的是完整交付。因此答辩必须要求学生解释项目为什么成立、如何实现、怎样证明可用。

前置条件

• 学员已经练习过立项、三层需求、PRD、原型、技术方案、脚手架、测试和 Git。
• 每组不超过五人，但每位成员都应理解完整流程。
• 项目规模控制在半天到一天可以形成可运行闭环。
• 提前公布评分标准和必须提交的证据。

第一步：选择小而完整的问题

适合结业项目的题目包括实验室预约、社团报名、校园失物招领、图书借阅提醒等。它们有明确用户和主流程，也能在有限时间内完成。

不适合的题目通常过大，例如“智慧校园平台”“完整电商系统”。题目越大，学生越容易用静态页面假装完成。

选题需要回答：

• 谁遇到了什么具体问题？
• 当前怎样解决，痛点在哪里？
• 第一版只验证哪条价值闭环？
• 哪些功能明确不做？

第二步：规定阶段交付物

每组至少提交：

1. 一页立项说明。
2. 业务、页面和功能三层需求。
3. PRD 与可交互原型。
4. 简洁技术方案和风险清单。
5. 可运行项目与远程仓库。
6. 关键验收用例和测试结果。
7. 一页复盘：AI 做了什么、人做了什么、哪里发生过误判。

测试结果不能只是一张“全部绿色”的截图。至少要标明每条证据属于单元、API 还是 UI，运行命令是什么，保护了哪项业务风险；如果某层没有自动化，也要解释人工验收范围和原因。

这些材料不追求篇幅，而要互相追踪。答辩时随机选择一个功能，学生应能从用户目标一路解释到代码和测试。

第三步：控制团队分工

小组可以分配主责，但不要让产品、开发和测试完全割裂。每个人至少要参与一次需求确认、一次代码评审和一次真实验收。

建议角色包括：

• 项目协调：维护范围、节奏和最终证据。
• 需求与原型主责：确保业务、页面和功能一致。
• 技术主责：维护架构、脚手架和合并质量。
• 测试主责：整理验收、回归和问题记录。

主责不等于只有这个人能解释。答辩可随机提问成员，避免成果由少数人或 AI 单独完成。

第四步：答辩只演示一条主流程

建议每组 8–10 分钟：

1. 1 分钟说明问题与 MVP。
2. 2 分钟展示三层需求和关键决策。
3. 3 分钟现场运行核心流程。
4. 1 分钟展示测试、Git 和错误处理证据。
5. 2 分钟回答问题与复盘。

不要把时间浪费在逐页念 PPT。现场运行能更快暴露项目是否真的成立。

质量演示建议按“单元规则 → API 契约与数据 → UI 主流程 → 重构前后行为不变”的顺序展开。学生不必追求测试数量，但必须说明为什么选这些用例，以及某条测试失败时首先排查哪一层。

评分标准

页面视觉只能作为原型维度的一部分，不能覆盖需求错误和功能不可用。

答辩提问库

• 你们删掉了哪个很诱人的功能，为什么？
• 任选一个页面，它对应哪个业务节点？
• 演示一个异常场景，而不只是成功路径。
• AI 提过什么错误建议，你们如何发现？
• 如果再给一天，先改善质量还是增加功能？
• 当前代码怎样回退到最近可用版本？

常见问题与处理

只展示录屏，不敢现场运行

可以保留录屏作为故障备份，但评分必须包含真实运行或可访问地址。

文档很多，彼此对不上

随机抽一个功能做追踪检查；无法从业务走到测试的材料不计为完整交付。

一个人完成全部工作

通过提交历史、任务记录和随机提问判断参与度，并把协作证据纳入评分。

AI 生成内容未经确认

要求学生指出至少一个 AI 建议被拒绝或修改的案例，说明判断依据。

课后练习

在正式结业前做一次 15 分钟预答辩，只检查主流程、异常演示和证据链。把所有“到时候再解释”的问题转成明确补充任务，再进入最终提交。