先定框架，再让学生走完整个 AI 产品开发闭环

课程设计里，最重要的不是工具清单

这次筹备高校学生 AI 辅助产品开发训练营时，最先对齐的不是某个工具怎么教，而是课程主线怎么搭。

我最后更认可的结构是三段式：

• 产品探索：用户需求分析、原型设计、PRD 输出
• 产品交付：技术方案、开发、测试上线
• 产品运营迭代：暂不深入展开，避免增加学生理解负担

这个取舍背后有一个很明确的判断：面对初学者，先让他们建立完整流程感，比一开始就塞进过多概念更重要。

产品思维的核心，是先分清需求和方案

这次讨论里，我最看重的一点，还是用户需求分析的训练。

用户经常会直接说出一个“想要的功能”，比如导出、筛选、某个按钮怎么放。但这些往往是解决方案，不是问题本身。真正需要追问的是：这个功能背后到底要解决什么问题？

我越来越确认，这种区分能力才是产品思维最核心的部分。不是先把需求单写出来，而是先识别什么是用户痛点，什么只是用户随口给出的实现建议。这个顺序不能反。

文字会失真，所以原型不是装饰品

PRD 当然重要，它是解决方案的书面表达。但文字天然会带来理解偏差，这也是为什么原型在课程里不能被当成“锦上添花”的环节。

原型的价值，不只是让页面更直观，而是帮助需求双方做到一种接近所见即所得的对齐。

这次我很认可一个互动设计：让一个人只用文字描述图形，其他人根据描述去画。这个小游戏很简单，但它能让学员直接感受到一件事：文字沟通并不天然可靠。当他们亲自经历这种偏差之后，再去理解原型为什么重要，会比直接讲概念有效得多。

AI 时代，分工方式和教学内容都该更新了

这次在分组规则上，原本考虑过按前端、后端、测试拆角色，但最后放弃了。原因很现实：在 AI 辅助开发的前提下，功能点不多时，传统分工很容易让一部分人提前结束，另一部分人还在等待协作。

所以最终的方向是：每个学员都独立完成前端、后端、测试的全流程，小组内部共同讨论，再选代表汇报。

我觉得这不是单纯为了教学方便，而是因为它更贴近这次训练营的任务规模和 AI 辅助开发前提。与其让学生一开始就按传统角色切分，不如直接让他们走完整个前后端与测试流程，更能建立完整的实践感。

同样的变化，也体现在课程内容选择上。比如提示词技巧，这次更适合放在基础带过的位置，而不必作为训练营的核心内容。随着模型能力增强，真正重要的不是技巧堆砌，而是能不能把自己的需求表达清楚。

所以课程里 AI 的应用更应该落在这些地方：

• 用 AI 生成 PRD
• 用 AI 生成技术方案
• 用 AI 辅助代码开发
• 让学员为 AI 生成的代码补测试用例，理解测试与缺陷之间的关系

比起完美备课，我更相信边跑边调

这次筹备给我最大的确认，不是某个具体环节，而是一种工作方法：先定框架，边跑边调。

不追求一开始就把所有 PPT、所有细节、所有节奏都预排完，而是先把核心主线确定下来，再根据每天的实际推进不断调整。这种方式看起来没那么“完整”，但更接近真实协作，也更适合内容和环境都还在快速变化的 AI 主题训练。

归根到底，我还是那个判断：在 AI 时代，培养习惯和完整流程感知，比灌输单点知识更重要。学生真正需要的，不是记住多少技巧，而是完整走过一遍从需求到原型、到 PRD、到技术方案、到开发、到测试的全过程。