高校学生学 AI Coding，真正要学的不是“让 AI 写代码”
训练营第一天，我没有急着让七十多位同学打开工具写代码，而是先问了一个问题：如果 AI 已经能快速生成页面，学生还需要学什么？
现场最容易出现的答案是“学会写提示词”“学会用某个 AI 编程工具”。这些当然有用，但都不是课程最核心的目标。工具会更新，模型会变化，今天记住的按钮位置可能几个月后就不一样。真正能带走、也更接近企业需要的能力，是把一个模糊想法变成可验证、可上线、可维护结果的完整交付能力。
会生成页面，不等于会交付项目
AI Coding 最容易制造一种错觉：输入一句话，页面出来了，项目就完成了。
但企业里的“完成”至少还要回答这些问题：
- 为什么值得做，投入和收益是什么？
- 用户到底要完成什么目标？
- 哪些功能属于第一版，哪些明确不做？
- 前端、后端和数据库如何协作？
- 正常场景和异常场景怎样验收？
- 出现问题如何定位，改坏后如何回退？
- 代码交给下一位开发者后，还能不能继续维护？
AI 可以快速生成局部答案，却不会天然替项目负责。如果学生只练习“让 AI 写一个 To Do List”，他练到的是工具操作；如果他能从立项、需求、原型一路走到测试和答辩，他练到的才是交付。
校园项目和企业项目，差别不只在代码量
学校里的项目常常从兴趣、作业或比赛题目出发，评价重点是“有没有做出来”。企业项目则必须先说明价值，再控制范围，最后用验收结果证明交付成立。
训练营里的水果商城案例就是为了制造这种差别。案例中的水果摊已经有稳定客户，却长期依赖微信群接龙、人工记账和手动核销。学生不能一上来就设计首页，而要先判断：最痛的问题究竟是获客、库存、订单还是对账？第一版系统解决哪一段，才最可能产生价值？
当学生开始讨论这些问题时，AI Coding 才从“代码生成演示”变成了真实项目训练。
一条完整的学习主线
我把这次训练营收成了五个动词：
- 想清楚：先判断项目价值、用户目标和需求边界。
- 写清楚：用业务流程、PRD、原型和技术方案形成共同语言。
- 做出来：先跑通脚手架，再按功能小步实现和提交。
- 测得住：把一句话需求变成实例化验收标准，用自动化测试守住行为。
- 改得动：通过职责分离和持续重构，让代码能够继续演进。
这五步里，写代码只占其中一段。AI 越能加速编码，前面的判断和后面的验证反而越重要。因为生成速度提升后，错误方向也会被更快放大。
学生和 AI 应该怎样分工
我在课堂上反复强调：不要把全部思考外包给 AI。
学生必须负责项目目标、范围、优先级和验收判断；AI 适合负责资料整理、方案草拟、代码实现、测试生成和重复操作。换句话说，人负责决定“为什么做、做什么、什么算对”，AI 负责加速“怎么把它做出来”。
一旦人放弃前面三项，项目就会被模型的第一版答案牵着走。页面可能很快出现，但团队会逐渐说不清为什么有这个功能、异常场景该怎么处理、改动是否真的符合需求。
判断自己是否真的学会了
完成一个 AI Coding 项目后，可以用下面这份清单自检：
- 我能用一句话说明项目为谁解决什么问题。
- 我能解释第一版为什么只做这些功能。
- 我有业务流程、页面流程和功能流程，而不是只有页面截图。
- 我能说清前后端接口和数据库变化。
- 我为关键功能写了正常与异常验收标准。
- 我实际运行并验证过页面、接口和数据，而不是只看 AI 的完成说明。
- 我按小步提交保存了可回退的版本。
- 我能读懂核心代码，并判断 AI 的修改是否合理。
如果这些问题答不上来，项目大概率还停留在“AI 帮我生成了一个东西”。如果能够完整回答，即使项目规模不大，也已经具备了企业交付的基本形状。
讲师判断：先把评价标准从页面移到交付
我不会否定学生从一个漂亮页面获得的成就感，那是继续学习的重要动力。但在课程评价里，页面只能算阶段证据，不能替代完整结果。真正值得加分的是：学生主动追问用户目标，能解释为何砍掉某项功能，遇到错误时知道收集日志，交付时能让别人复现运行环境。
这也意味着教师不必和 AI 比拼谁写代码更快。教师的价值是设置边界、制造真实约束、追问判断依据，并把“看起来完成”转成一组可验证事实。学生一旦形成这套习惯，未来更换任何编程工具，能力仍然能够迁移。
课后练习
找一个你曾经做过的课程设计，不改代码，先补写一页项目交付说明：用户是谁、问题是什么、第一版范围是什么、如何验收、出现问题如何回退。然后再问自己：过去缺失的到底是编码能力，还是完整交付意识？