人机协同的 AI 编程

王树义

今天这节课，你们要带走什么

  • 先用 Trae 做出一个能玩、能展示的小游戏

  • 再把“会提需求、会改结果、会验收”迁移到一个最小 Skill 助手

  • 下课时，你们每个人都要知道自己课后怎么继续练

这节课怎么走

从前，做系统实施常常很痛苦

  • 不是因为大家一点都不会

  • 而是每次一碰到完整项目

  • 需求、流程、界面、数据、交互就会一起压过来

  • 人一慌，手就停了

上过 Python 啊，为什么还是做不出来

  • 你们并不陌生语法

  • 真正难的是把零散知识拼成一个能交付的系统

  • “学过”不等于“能做完整项目”

这不是个别现象

  • 课前问卷回收 42 份，92.9% 的同学最熟悉 Python

  • 但只有 21.4% 觉得自己能独立完成简单项目

  • 全班 47 人里，只有 3 人已经在用 AI Agent

  • 这说明问题不是“完全不会”，而是“学过，却很难做成完整系统”

所以今天不先补语法

  • 因为今天最重要的，不是多记几个语法点

  • 而是先把东西做出来

  • 先有一次成功体验，后面的抽象总结才站得住

AI 编程能力演进

  • 代码补全：你写一句，它补一句

  • 自然语言编程：你写一句话，它先给你一个能跑的版本

  • 氛围编程：你边说边改，先把东西做出来

  • Agent / Skill 协作：你把方法、边界和验收标准也交给 AI

第一阶段：补全代码

  • 它最像输入法联想

  • 适合帮你补全已经想清楚的部分

  • 不适合替你决定“这个系统到底该怎么做”

第二阶段：自然语言编程

  • 你可以直接用中文说要做什么

  • AI 会先把你的想法翻成一个能跑的程序

  • 这一步最大的价值是：降低起步门槛

课堂播放：春节版贪吃蛇（20 秒）

  • 看完先想一件事

  • 如果换成你自己的题材，你第一句会怎么描述

课堂播放：字符雨小程序（20 秒）

  • 看完再想一件事

  • 如果结果不满意，你下一句会怎么改

第三阶段：氛围编程

  • 先把想法说出来

  • 让 AI 给你第一个版本

  • 再边看边改，逐步逼近你脑子里的样子

  • 它特别适合破冰

第四阶段：Agent / Skill 协作

  • 更进一步的时候，你不只是在“让 AI 写代码”

  • 你开始让它按流程、按方法、按标准来协作

  • 这时人的位置开始转向：架构师、审查者、决策者

人在环中：哪些地方必须你来盯

  • 不是所有事情都该自己做

  • 也不是所有事情都能放心交给 AI

  • 真正的关键是：你知不知道什么时候该自己拍板

Trae：今天这节课的主力工具

  • 国内版起步门槛低

  • 支持多模型，也能接国产模型

  • 过程可见，适合边看边改

  • 今天你们先把它当成最顺手的练习场

Trae：你们会看到的界面

  • 先别急着记所有按钮

  • 今天只看三件事：它能不能先给初版、能不能继续改、能不能让你看清过程

Trae：Builder 怎么帮你起步

  • 你说需求

  • 它先搭一个可以动的版本

  • 然后你继续追着它改

Trae：过程可见，才方便验收

  • 如果过程不可见，你就很难知道它为什么改成这样

  • 过程可见，才方便你追问、修正、否决

下面，咱们来试试

  • 先别追求复杂

  • 先把课堂气氛拉起来

  • 先体验一下“我一句话，AI 真能把东西做出来”

玩儿玩儿试试

  • 先把一个最小想法做出来

  • 再决定要不要继续打磨

  • 别一上来就想把课程项目一次做完

练习 1：任务卡

  • 时间：12 分钟

  • 目标：做一个能玩、能展示、能让同学会笑的作品

  • 关键词：能运行、有创意、改得动

  • 你们要做的不是“让 AI 自己发挥”

  • 而是边做边改，直到它像你脑子里那个样子

练习 1：做完后先检查什么

  • 能不能跑

  • 有没有一个清楚的玩法

  • 你能不能说清楚自己改过哪几轮

  • 如果只能说“AI 帮我做的”，这次练习就还没做完

练习 1：评价标准

维度 权重 说明
功能完整性 30% 程序能运行、核心流程完整
创意表达 30% 题材或玩法有表达性
迭代清晰度 20% 能说清提示词如何改、问题如何修
用户体验 20% 操作反馈清晰、容易上手

学生作品（已匿名）

  • 先看到同学也能做出来，心理门槛会马上下降

学生作品（已匿名）

  • 作品不用一开始就完美

  • 但一定要有一个能展示、能继续改的雏形

一句话能写游戏，够不够做系统

  • 写游戏时，一句话往往就够用

  • 做真实系统时，用户会不断改口

  • 这里要加流程，那里要补权限，格式还要统一

  • 这时如果你只靠临场对话，结果很容易越改越飘

复杂系统为什么更难

  • 因为复杂任务里，最容易失控的不是代码量

  • 而是需求边界

  • 是输入输出

  • 是你到底拿什么标准说“这个版本可以交了”

为什么严肃任务更需要 Skill

  • 一次性 prompt 适合破冰，但不擅长稳定复用

  • 真到系统实施，AI 更需要你给它稳定的方法、边界和验收口径

  • Skill 的价值，不在“更炫”

  • 而在“少返工、少跑偏、少甩锅”

Skill 是怎么长出来的

  • 不是先造一个“万能助手”

  • 而是把你已经会做的一件小事，变成别人也能反复调用的方法

  • 例如：系统分析图助手、验收清单助手、学习辅导助手

上一届同学做过什么 Skill

  • 真实个案：信息系统学习助手

  • 它能解释课程名词

  • 能给出样例

  • 还能提醒相应图形应该怎么画

  • 这类助手离“万能”很远

  • 但离“真能帮到同学”很近

练习 2：任务卡

  • 时间：12 分钟

  • 课堂产出：一张 Skill 设计卡 + 在 Trae 中完成一次最小试跑

设计卡必须写清 4 件事：

  • 帮谁

  • 解决什么问题

  • 输入是什么

  • 输出怎么算合格

练习 2：做完后先检查什么

  • 这个助手到底帮的是谁

  • 它解决的是不是一个具体问题

  • 同学拿来以后能不能马上看懂怎么用

  • 最后拍板的地方有没有保留给人

练习 2：评价标准

维度 权重 说明
问题对准度 30% 是否真正解决了一个具体问题
输入输出清晰度 30% 输入边界、输出形式、合格标准是否明确
上手友好度 20% 同学拿来能否立即理解并试用
人机分工意识 20% 是否保留了必须由人判断和验收的环节

你们的 Skill 助手：展示与点评

  • 时间：5 分钟

每组用 30 秒讲清三件事：

  • 帮谁

  • 解决什么问题

  • 哪一步必须保留给人判断

  • 展示不是比谁说得玄

  • 而是比谁设计得真能上手

想一想：AI 帮你写的代码，责任归谁

  • 归你

  • 归 AI

  • 归 AI 的开发公司

  • 还是谁也说不清

  • 这个问题没有你想得那么轻松

真实世界里，为什么还要你来负责

  • AI 可以写代码

  • 但不能替你承担版权、安全、上线责任

  • 真正可怕的不是“它不会写”

  • 而是“它写得太快，你来不及验”

一个真实提醒

  • 2025 年，Amazon Q Developer for VS Code 扩展曾因构建流程中的凭据边界问题被植入恶意代码

  • 这件事提醒我们：AI 编程插件一旦进了开发环境，就可能接触仓库、凭据和发布链

  • 所以不是所有“更快”的工具都该直接装、直接信、直接放进正式环境

高校已经在行动

  • AI 编程正在进入课程、训练营和实践项目

  • 这不是“以后再说”的话题

  • 它不是玩具，而是你们这一代学生必须学会的工作方式

课后继续练，可以从哪里开始

  • Trae：继续完成你今天没做完的小游戏或 Skill

  • CodeGeeX / CodeBuddy：装进常用 IDE，练“补全 + 改错”

  • GitHub Copilot / Cursor：如果你有学生优惠或教育邮箱，可以继续试更强的协作方式

  • 课后任务不是“把工具都装一遍”

  • 而是选一个顺手的，拿自己的课程项目继续做

课后不只是继续写

  • 你们的作品后面还会进入 AI 评价与个性化反馈环节

  • AI 会继续看功能、创意、协同过程和体验

  • 但最后决定你是否真正做成了，还是你自己对结果的判断

小结

  • 今天先用氛围编程把门推开

  • 再用 Skill 把经验、标准和审查留下来

  • 你们不一定要会手写每一行代码

  • 但你们必须是那个提需求、改结果、做决定的人