# 人机协同编程与工作流基础 授课计划

来源提交：657dd77927bb84309ef4aa6b3c87c6e33ba69f0e
状态：课程组审阅稿。这是与网页相同范围的阅读下载，人员明细/内部批注按发布约定移除。文中图片链接指向获准的站点资源，单独下载此Markdown不包含离线图片。

# 人机协同编程与工作流基础
## 学期授课计划

版本：2026.09.20-r1｜修订日期：2026年9月20日｜状态：课程组审阅稿

## 一、课程与授课信息

| 项目 | 内容 |
| --- | --- |
| 学年学期 | 2026—2027学年第一学期 |
| 适用班级 | 2026级人工智能技术应用专业；实际班号按课表填写 |
| 课程性质 | 专业基础必修课；非群平台课 |
| 总学时 | 56 |
| 学分学时 | 3学分，56学时（理论28学时，实践28学时） |
| 实践分配 | 常规实践26学时，期末综合实操2学时 |
| 任课教师 | 周兵，实际安排以教学单位为准 |
| 标准依据 | 本课程标准2026.09.20-r1 |
| 核心教材 | 《人月神话》；按实际采购版选读，不虚填中文页码 |
| 平台与环境 | 校内GitLab；VS Code、Cline、校内私有化大模型服务、Git |
| 教学周 | 按课程教学周1—14编排，具体日历日期按校历填写 |
| 状态 | 课程组审阅稿，教学采用与审批按校内流程确认 |

基本口径依据高职人培方案[P1]与线上工作稿[P0]。每周4学时（每学时45分钟，共180分钟，课间休息不计入）。全学期共56学时，其中理论讲授28学时，常规实践26学时，期末现场综合实操考核2学时。课外自主学习时长单列，不计入课程56学时。

## 二、学期教学组织与工程双主线

本课程以“宏观工程哲学 $\leftrightarrow$ 微观代码碰撞”为双主线驱动教学：
1. **哲学与管理主线**：以《人月神话》中的14个永恒困境统领各周主题，引导学生超越“代码编写工具人”视角，建立概念完整性、契约设计、上下文工程、组织协作秩序与不可伪造的质量证据意识。
2. **微实验与作品主线**：每周安排一个直击痛点的终端代码微实验（如依赖崩溃、覆盖丢失、并发拒推、Schema契约断裂、多智能体上下文污染、回归失效等）；学生从四类入门脚手架（学习记录工具、知识卡片工具、数据清洗工具、交互自测工具）中选择方向，通过5阶段人机协同证据链（Intent $\to$ AI Plan $\to$ Human Review $\to$ Git Diff $\to$ Final Verdict）在个人作品上完成迭代与工程闭环。

常规周讲练采用180分钟交替循环：引出困境15分钟、问题与预测20分钟、基线实践15分钟、原理讲授20分钟、自选迁移35分钟、过程讲评20分钟、深化验证40分钟、反思复盘15分钟。

## 三、周次、主题与学时安排

| 周 | 单元 | 本周工程命题与中心问题 | 理论 | 常规实践 | 实践考核 | 合计 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | U1 | 做出一个东西，怎样才算完成？（焦油坑与交付标准） | 2 | 2 | 0 | 4 |
| 2 | U1 | 昨天还好好的，今天怎样找回？（没有银弹与受控恢复） | 2 | 2 | 0 | 4 |
| 3 | U2 | 为什么已经有版本工具，还要创造Git？（分布式与边界定义） | 2 | 2 | 0 | 4 |
| 4 | U2 | 一个想法，能不能保留两种做法？（外科手术团队与特性分支） | 2 | 2 | 0 | 4 |
| 5 | U3 | 每个部分都不错，为什么整体用不了？（概念完整性与Schema契约） | 2 | 2 | 0 | 4 |
| 6 | U3 | 多开几个AI，会更快吗？（布鲁克斯法则与多智能体上下文治理） | 2 | 2 | 0 | 4 |
| 7 | U3 | 怎样让另一个人或AI接着做？（巴别塔与现代上下文工程） | 2 | 2 | 0 | 4 |
| 8 | U4 | 有能力做更多，就应该做更多吗？（画蛇添足与三不原则） | 2 | 2 | 0 | 4 |
| 9 | U4 | 大家都说做完了，为什么还不能交付？（削足适履与系统集成评审） | 2 | 2 | 0 | 4 |
| 10 | U4 | AI说修好了，怎样确认？（缺陷连锁反应与回归测试套件） | 2 | 2 | 0 | 4 |
| 11 | U5 | 每天都很忙，进度在哪里？（祸起萧墙与真实进度度量） | 2 | 2 | 0 | 4 |
| 12 | U5 | 别人为什么愿意使用和改进你的作品？（文档即系统与开源资产化） | 2 | 2 | 0 | 4 |
| 13 | U6 | AI究竟帮助了哪一部分？（抛弃型原型与工程效能复盘） | 2 | 2 | 0 | 4 |
| 14 | U6 | 留下一份别人能够继续的成果（期末现场综合实操考核） | 2 | 0 | 2 | 4 |
| 合计 | | | 28 | 26 | 2 | 56 |

## 四、各周教学内容与课外学习

### 第1周 做出一个东西，怎样才算完成？

**单元与学时：** U1；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第1章《焦油坑》（The Tar Pit）。Brooks揭示了单个临时程序到编程系统产品（Programming Systems Product）之间高达9倍的开发成本鸿沟。 阅读入口：初版序言与第1章。[B1][B2]

**中心问题：** 本地电脑能跑通，与“可以交接给同伴运行”之间存在哪些本质鸿沟？AI生成代码后，人类必须确定哪些可观察的验收契约？

**讲授内容：** 输入—处理—输出（IPO模型）；单机运行与工程交付；环境依赖与打包边界；5阶段证据链总览；人机责任边界与最小权限安全。

**终端微实验（Micro Code Experiment）：** 运行崩溃实验。在缺少全局依赖的干净虚拟机或新终端窗口中直接执行同伴拷贝的未封装脚本，观察模块缺失或路径报错现象，体悟“在我的机器上能跑”不等于工程交付，体验依赖声明与自包含脚手架的重要性。

**自选作品实践：** 运行A类脚手架（简易学习记录工具），手工阅读关键执行路径，完成一处核心阈值参数修改（如最小有效时长）并验证；提出自选作品方向意向。

**Git落点：** 认识项目文件组织，理解可复现的工程起点；不把复杂的Git命令设为首周障碍。

**AI参与控制面：** AI可辅助解释代码逻辑与变量含义，但学生必须手工完成一处核心修改并用自然语言解释执行流。

**当堂成果与评价：** 完成作业 A1（运行证据、验收契约、个人手工修改与同伴反馈，共8分）。

**课外学习：** 完善A1记录；从四类脚手架中选择一个自选作品方向，写出三句核心意图（建议30分钟）。

---

### 第2周 昨天还好好的，今天怎样找回？

**单元与学时：** U1；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第16章《没有银弹》（No Silver Bullet）。探讨软件工程的本质复杂性（状态多、变化快、不可见）与偶然复杂性；从对“历史不可追溯”的恐惧进入Git快照哲学。 阅读入口：版本控制概述与Git快照模型。[B1][G1][G3]

**中心问题：** 怎样既能保留大胆探索的自由，又能精准知道改动了什么、为什么改，并在误操作时安全回退？

**讲授内容：** 保存 vs 暂存 vs 提交；Git底层对象快照模型；工作区、暂存区（Index）与版本库（HEAD）；原子提交（Atomic Commit）原则；非破坏性安全恢复。

**终端微实验（Micro Code Experiment）：** 覆盖灾难与安全恢复。模拟手动保存多份“最终版_v1.js”、“最终版_v2_真的最终版.js”引发的误删与覆盖事故；在Git测试仓库中通过 `git diff` 观察未暂存变化，执行原子提交，并使用 `git restore --worktree` 精确恢复被恶意误删的核心函数，验证恢复前后一致性。

**自选作品实践：** 为自选作品建立第一个独立本地Git仓库，完成初始基线提交，建立 `.gitignore` 过滤系统缓存。

**Git落点：** `git init`、`git status`、`git diff`、`git add`、`git commit -m`、`git log --oneline`、`git restore`。

**AI参与控制面：** AI可协助审查差异并生成提交信息草稿，但学生必须逐行审查 `git diff` 并确认提交意图，禁止未经阅读直接无脑 `git commit -a`。

**当堂成果与评价：** 完成作业 A2（快照状态解释、原子提交、差异阅读与安全恢复验证，共8分）。

**课外学习：** 整理自选作品初始化基线，提交一次规范的原子提交日志（建议30分钟）。

---

### 第3周 为什么已经有版本工具，还要创造Git？

**单元与学时：** U2；理论2学时，常规实践2学时。

**经典工程命题与阅读：** Git诞生史（2005年Linus Torvalds为Linux内核开发设计的分布式版本控制）；集中式与分布式的哲学差异。 阅读入口：Pro Git第1章技术简史。[G1][G2]

**中心问题：** 当团队成员各自拥有完整的本地历史时，怎样既保持独立探索的自主性，又维护团队协同的统一秩序？

**讲授内容：** 集中式（CVCS）与分布式（DVCS）拓扑；本地分支、远程追踪分支与远程仓库；团队身份配置与权限；自选作品的“三不原则”（Out-of-Scope Rule）。

**终端微实验（Micro Code Experiment）：** 并发推送冲突碰撞。两人结对克隆同一校内GitLab远程仓库，分别在本地修改同一文件的元数据并先后推送到远程 `main` 分支，后推送者遭遇 `[rejected - non-fast-forward]` 拒推报错；学习查看远程状态并排查原因。

**自选作品实践：** 正式为自选作品在校内GitLab创建远程仓库并建立关联；在项目根目录编写初版 `PRD.md`，严格声明“本项目当前绝不做的三件事”（三不原则）。

**Git落点：** `git clone`、`git remote -v`、`git fetch`、`git push -u origin main`。

**AI参与控制面：** AI辅助分析拒推原因，但学生必须亲自在终端核查远程配置与分支指针。

**当堂成果与评价：** 个人自选作品远程仓库连通、首个远程提交与“三不原则”声明；为A3积累证据。

**课外学习：** 细化自选作品第4周待实现的最小可行流程（MVP）设计（建议20分钟）。

---

### 第4周 一个想法，能不能保留两种做法？

**单元与学时：** U2；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第3章《外科手术式团队》（The Surgical Team）与第11章原型探索合读。主程序员把握主线，多方案并行探索与增量构建。 阅读入口：第3、11章。[B2]

**中心问题：** 面对具有不确定性的技术方案，如何不污染稳定主干，同时进行两套方案的并行试验与客观取舍？

**讲授内容：** 主干保护（Protected Main）；特性分支（Feature Branch）工作流；分支切换与工作区隔离；方案选型矩阵（性能、可读性、复杂度）；基于证据的合并决策。

**终端微实验（Micro Code Experiment）：** 双分支方案决斗。针对作品中的核心处理逻辑（例如数据排序或格式解析），分别创建 `feat/plan-a-regex` 与 `feat/plan-b-split` 两个特性分支独立实现；设计统一基准测试输入，对比两分支的执行结果与代码清晰度，决定将优胜分支合入主干并安全删除废弃分支。

**自选作品实践：** 在自选作品中通过特性分支完成第一条完整的端到端业务闭环（用户输入 $\to$ 核心处理 $\to$ 界面展示）。

**Git落点：** `git branch`、`git switch -c`、`git branch -d`、`git merge`。

**AI参与控制面：** 允许AI在两个分支分别生成不同思路的方案，但评价标准与测试对比必须由人类学生预先制定。

**当堂成果与评价：** 完成作业 A3（共同基线、双分支方案对比、合并取舍决策与MVP闭环，共8分）。

**课外学习：** 撰写A3方案取舍说明，记录废弃方案的保留理由或删除依据（建议30分钟）。

---

### 第5周 每个部分都不错，为什么整体用不了？

**单元与学时：** U3；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第4章《概念完整性》（Conceptual Integrity）。系统设计中，一致性是衡量质量的最核心维度；体系结构（Architecture）必须先于独立实现。 阅读入口：第4章概念完整性主题。[B1][B2]

**中心问题：** 为什么各模块单测完全通过，联调时却全面崩溃？在AI可以秒级生成代码的时代，系统接口契约的决定性作用是什么？

**讲授内容：** 概念完整性与模块边界；接口契约设计；JSON Schema规范；字段命名统一（驼峰 vs 下划线）、单位定义与异常状态码契约；契约测试。

**终端微实验（Micro Code Experiment）：** Schema契约断裂惨剧。运行预置的微型系统，数据采集模块输出带有嵌套字段的JSON对象，而数据处理模块按平面字典键名直接取值，触发 `TypeError: Cannot read property of undefined` 导致程序致命崩溃；学生通过制定并执行严格的 JSON Schema 接口契约修复集成故障。

**自选作品实践：** 审视自选作品的模块结构，将数据流接口抽离为独立的契约定义文件（如 `schema.json` 或接口常量声明），消除硬编码字段隐患。

**Git落点：** 将契约变更与模块实现关联为原子提交；利用 `git log -S` 追溯破坏契约的关键代码变更。

**AI参与控制面：** 向AI提出修改请求时，必须附带 Schema 契约约束，严禁由AI自行捏造数据字段名。

**当堂成果与评价：** 完成接口不一致的复现、Schema契约修复与回归记录；纳入A4。

**课外学习：** 补充完善个人作品的接口契约说明文档（建议20分钟）。

---

### 第6周 多开几个AI，会更快吗？

**单元与学时：** U3；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第2章《人月神话》（Brooks's Law：向进度落后的项目增加人手只会使其更落后）。将团队沟通成本随人数激增的定律迁移至AI智能体协作场景。 阅读入口：第2章协作规模命题。[B2]

**中心问题：** 当盲目开启多个AI智能体并发生成代码时，为什么整体进度没有加速，反而引发了上下文漂移、命名混乱与严重的调试返工？

**讲授内容：** 沟通复杂度与任务解耦；串行依赖 vs 可并行任务；AI时代的上下文污染与幻觉放大；单工作区串行交互纪律；任务拆解与等待开销。

**终端微实验（Micro Code Experiment）：** 多智能体并发污染灾难。学生在两个并行AI会话中同时要求修改同一份业务代码（一个做性能优化，一个增加错误捕获），将两份结果依次合入同一文件，产生大面积重名覆盖、全局变量冲突与语法错乱；对比转为“串行任务拆解＋单点审查”后的交付质量，记录两者的时间与返工开销。

**自选作品实践：** 在自选作品中建立规范的“单次修改清单”，一次只让AI聚焦解决一个明确的小任务，杜绝大范围模糊指令。

**Git落点：** 独立实验在临时分支完成；掌握使用 `git checkout -- <file>` 丢弃被并发污染的脏修改。

**AI参与控制面：** 严格限定单次提示词的变更范围（Scope Limit），单次只允许修改不超过2个相关函数。

**当堂成果与评价：** 记录并发修改与串行修改的耗时、冲突数与返工代价对比；纳入A4。

**课外学习：** 总结属于自己的AI交互防污染军规（建议20分钟）。

---

### 第7周 怎样让另一个人或AI接着做？

**单元与学时：** U3；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第7章《巴别塔》（The Tower of Babel）与第10章项目文档。团队失败往往源于信息断层；上下文工程是组织协同的生命线。 阅读入口：第7、10章。[B2]

**中心问题：** 当团队新成员或新开启的AI会话接手项目时，最少需要知道哪些核心信息才能做到无损继续开发？

**讲授内容：** 现代上下文工程（Context Engineering）；`AGENTS.md` 规范的设计与落地；系统现状、禁止事项、代码风格与测试运行命令；无损交接标准。

**终端微实验（Micro Code Experiment）：** 盲人摸象交接实验。结对同学交换电脑，原作者全程禁止口头交流；接收者仅凭项目内的 `AGENTS.md` 与项目说明，在5分钟内开启全新的AI对话完成一项小型缺陷修复；测试交接文档的完整性与自包含性。

**自选作品实践：** 为自选作品编写规范的 `AGENTS.md` 文件，包含项目意图、三不原则、接口规范、关键文件说明与运行测试指令。

**Git落点：** 将 `AGENTS.md` 作为核心资产纳入版本管理；用清晰的提交历史辅助交接者理解决策背景。

**AI参与控制面：** 在开启新对话时，首先将 `AGENTS.md` 作为系统上下文（System Prompt / Instructions）载入，验证AI理解规范后的代码采纳率。

**当堂成果与评价：** 完成作业 A4（系统契约规范、AGENTS.md落地、无损交接验证与个人贡献，共8分）。

**课外学习：** 依据同伴反馈修订个人作品的 `AGENTS.md`（建议30分钟）。

---

### 第8周 有能力做更多，就应该做更多吗？

**单元与学时：** U4；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第5章《画蛇添足》（The Second-System Effect）。在初次尝试成功后，工程师极易落入功能膨胀、盲目增加高级特性的陷阱。 阅读入口：第5章。[B2]

**中心问题：** 面对AI强大的代码生成诱惑，工程师怎样抑制过度设计的本能，把有限精力聚焦在核心用户价值与稳定性上？

**讲授内容：** 功能蔓延（Scope Creep）的危害；MVP最小可行产品原则；功能优先级评估矩阵；需求剔除与版本冻结机制；Issue驱动开发。

**终端微实验（Micro Code Experiment）：** 需求狂欢节裁剪。教师为每个作品强行派发3个“看似炫酷但极度复杂”的新增需求（如引入复杂的3D动画图表、过早引入云端分布式同步）；学生依据“三不原则”进行严格评估，编写技术拒绝函，通过 GitLab Issue 记录推迟或剔除的理由。

**自选作品实践：** 在自选作品的 GitLab 仓库建立 Milestone 与 Issue 看板，冻结下一稳定版的功能清单，严格封锁范围蔓延。

**Git落点：** Issue 与分支绑定；使用语义化分支名（如 `feat/issue-12-filter`）；在提交信息中关联 Issue 号。

**AI参与控制面：** 引导AI进行需求影响面与技术代价分析，但最终决定保留还是拒绝必须由人类做出。

**当堂成果与评价：** 需求裁剪决策记录、三不原则执行证据与版本发布计划；纳入A5。

**课外学习：** 梳理自选作品的待开发 Issue，确保每个 Issue 都有清晰的验收准则（建议20分钟）。

---

### 第9周 大家都说做完了，为什么还不能交付？

**单元与学时：** U4；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第13章《削足适履》（Ten Pounds in a Five-Pound Sack）与系统集成。组件各美其美，整体协同丑陋；文本合并成功绝不等于系统集成成功。 阅读入口：第13章。[B2]

**中心问题：** 当Git提示自动合并无冲突（Auto-merge passed）时，为什么依然可能潜藏着严重的业务逻辑崩溃？代码评审（Code Review）不可替代的价值何在？

**讲授内容：** 文本合并 vs 逻辑正确性；合并冲突的底层原理（三方合并与共同祖先）；GitLab 合并请求（MR）工作流；同伴代码评审的核心关注点（逻辑陷阱、未捕获异常、契约破坏）。

**终端微实验（Micro Code Experiment）：** 静默冲突与集成陷阱。两个分支分别修改了同一函数调用的实参类型与默认参数，Git自动三方合并成功并未报错，但运行自动化测试时触发静默逻辑错误（数据被错误格式化）；通过发起 GitLab MR 并在代码评审阶段借助审查清单拦截故障。

**自选作品实践：** 同伴之间建立交叉评审关系，在 GitLab 上为彼此的作品发起至少一次规范的 MR，完成至少2处有实质内容的评审意见回复与代码合入。

**Git落点：** `git merge`、冲突标记解读（`<<<<<<<`、`=======`、`>>>>>>>`）、解决冲突后的提交流程；GitLab Web 评审界面操作。[G7]

**AI参与控制面：** AI可协助审查潜在的未定义边界，但严禁以“一键接受AI合并”代替人工逻辑推演。

**当堂成果与评价：** 完成一条规范的 MR、同伴评审互动记录与合并测试验证；纳入A5。

**课外学习：** 整理代码评审中采纳的一项改进建议及其带来的代码质量提升（建议20分钟）。

---

### 第10周 AI说修好了，怎样确认？

**单元与学时：** U4；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第13章系统测试与缺陷连锁反应。修复一个错误通常有20%—50%的概率引入一个全新的偶生缺陷；测试预期必须先于实现独立确立。 阅读入口：第13章缺陷治理。[B2]

**中心问题：** 当AI助手轻巧地声称“已为您修复Bug”时，怎样用确定性的工程手段戳破假象，守住软件的质量底线？

**讲授内容：** 缺陷复现（Reproduction）；预期测试驱动（Test-First Verification）；正常用例、边界用例与极端异常用例；回归测试套件（Regression Test Suite）设计；修复提交与回滚提交的区别。

**终端微实验（Micro Code Experiment）：** 虚假修复与回归狙击。微实验提供一个既有功能完备但存在边界Bug的程序，学生让AI修复该Bug，AI给出的修复代码看似通过了新用例，但由于修改了公共数据结构，直接破坏了原有核心逻辑；运行事先编写好的回归测试套件，红色报警立刻戳破虚假修复，引导学生编写针对性修复并通过全量测试。

**自选作品实践：** 为自选作品建立包含至少5个核心测试用例的回归测试脚本，覆盖正常输入、空值、非法边界等场景。

**Git落点：** `git commit --fixup`、区分单文件 `git restore` 与使用 `git revert` 产生撤销提交的历史语义差异。[G4][G5]

**AI参与控制面：** 严禁为了“迎合AI实现”而随意降低或篡改测试用例的断言预期。

**当堂成果与评价：** 完成作业 A5（范围控制、MR评审、回归测试套件与真实Bug修复，共8分）。

**课外学习：** 完善自选作品的自动化测试脚本，确保终端一条命令即可执行全量回归（建议30分钟）。

---

### 第11周 每天都很忙，进度在哪里？

**单元与学时：** U5；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第14章《祸起萧墙》（One Day at a Time）。“项目是怎样延迟一年的？一次延迟一天。”不可控的进度源于缺乏可验证的客观交付物。 阅读入口：第14章进度与里程碑主题。[B2]

**中心问题：** 怎样摆脱“差不多快做完了”的主观幻觉，用不可伪造的工程证据度量真实研发进展？

**讲授内容：** 可验收里程碑（Verifiable Milestones）；完成的定义（Definition of Done, DoD）；进行中（WIP）与已交付（Done）的区别；提交历史作为进展的唯一真理源。

**终端微实验（Micro Code Experiment）：** 虚实进度对比。对比两组学生展示的进度：一组仅有口头说明和草稿代码，另一组具有通过自动化测试的规范原子提交树；剖析后者为何具备不可伪造的确定性，将一项被拖延的模糊任务拆解为两小时内可验证的微型里程碑。

**自选作品实践：** 全面对照自选作品的功能矩阵，依据 DoD（代码干净、测试通过、文档同步）清点真实完成情况，在看板上完成最终冲刺拆解。

**Git落点：** `git log --graph --oneline` 审查全项目提交脉络；核对每个提交是否符合原子性与独立可运行要求。

**AI参与控制面：** AI协助拆解任务清单，但任务规模与个人完成能力的匹配度必须由学生亲自把关。

**当堂成果与评价：** 真实的进度审计记录与期末冲刺任务拆解；纳入A6。

**课外学习：** 完成自选作品核心功能收尾，确保主分支始终保持绿色的可运行状态（建议20分钟）。

---

### 第12周 别人为什么愿意使用和改进你的作品？

**单元与学时：** U5；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第15章《另外一面》（The Other Face）与开源协作规则。优秀程序面向机器，卓越工程面向人；开源协议与公共软件资产化。 阅读入口：第15章；开放源码定义。[B2][G7][G8]

**中心问题：** 一个代码仓库如何从私有玩具蜕变为具备公共协作价值的可靠开源资产？

**讲授内容：** 面向使用者的文档架构（README标准结构：背景、快速起步、使用示例、配置契约、贡献指南）；主流开源许可证（MIT、Apache-2.0、GPL-3.0）的权利与义务；第三方依赖合规与安全漏洞防范。

**终端微实验（Micro Code Experiment）：** 跨环境盲测复现。两位同学互换代码仓库链接，在全新的纯净终端环境中，不经过口头询问，严格按照对方 README 的安装与起步说明从零构建运行作品，记录遇到的卡点与阻碍，并向对方仓库提交一份改进文档的 Merge Request。

**自选作品实践：** 为自选作品配置规范的开源许可证文件（LICENSE），完善图文并茂、步骤自包含的 `README.md`。

**Git落点：** 标签管理 `git tag -a v1.0.0-rc1`；处理同伴提交的文档改进合并请求。

**AI参与控制面：** AI可协助润色文档文字，但文档中记载的每一条终端命令、参数说明与运行截图必须经由人类在真实环境实测验证无误。

**当堂成果与评价：** 完成作业 A6（阶段可验证交付、同伴盲测复现、README完善与开源许可证配置，共8分）。

**课外学习：** 处理同伴盲测提出的 Issue，发布作品的候选版本标签（建议30分钟）。

---

### 第13周 AI究竟帮助了哪一部分？

**单元与学时：** U6；理论2学时，常规实践2学时。

**经典工程命题与阅读：** 《人月神话》第11章《抛弃型原型》（Plan to Throw One Away）与20周年纪念篇回顾。认识技术债务，勇于重构早期的脆弱逻辑；对人机协同展开基于证据的全景复盘。 阅读入口：第11、16章及纪念版回顾。[B1][B2]

**中心问题：** 在整个学期的开发中，AI究竟在哪些环节带来了实质提效，在哪些环节引发了误导与返工？人类的核心价值体现在哪里？

**讲授内容：** 架构重构策略（提炼函数、解耦依赖、消除重复）；技术债务（Technical Debt）识别与偿还；AI协同效能归因模型；客观证据复盘方法（用提交日志、diff规模、测试修复率说话，拒绝主观编造）。

**微实验与工程实操：** 重构早期代码。学生调出第1周编写的初级逻辑，运用面向对象或模块化思想，将其重构为结构清晰、高内聚低耦合的高质量代码，并确保原有回归测试套件全量变绿；对照 Git 历史统计个人编写、AI辅助生成与代码审查的比例分布。

**自选作品实践：** 完成个人自选作品的终期封包与版本打标（`git tag -a v1.0.0 -m "Release v1.0.0"`），生成最终工程归档包。

**Git落点：** `git tag`、`git archive`、完整工程提交树复盘。

**AI参与控制面：** 使用AI辅助提取重构建议，但重构后的回归测试必须100%在本地执行通过。

**当堂成果与评价：** 完成作业 A7（AI协同工程复盘报告，6分）与 A8（自选作品终期工程封包，6分）。

**课外学习：** 准备第14周现场实操考核，回顾全套工程方法与终端操作（建议40分钟）。

---

### 第14周 留下一份别人能够继续的成果

**单元与学时：** U6；理论2学时，实践考核2学时。

**经典工程命题与情境：** 完整工程交付与终生迁移；让接手者不仅能跑通程序，更能读懂每一个关键决策的来龙去脉。 阅读入口：课程方法论总结与高职专业发展指引。[P1]

**中心问题：** 面对一个全新的工程场景与限时任务，能否独立、规范地调动人机协同完成有质量保证的工程交付？

**讲授内容：** 前半段90分钟进行学期工程方法大复盘、匿名优秀工程案例展评、后续专业课程（Linux/Python/AIoT/开源工程）的协作接口衔接，以及期末综合实操考核纪律与环境说明。

**期末综合实操考核（现场闭卷90分钟，满分40分）：**
考核在统一发放的全新可运行微型工程基线上展开，限时完成一个具体功能的改进与交付：
1. **阶段一：需求契约与三不原则（前20分钟，独立完成，严禁开启AI）**——分析需求边界，编写输入输出 Schema 契约与预期测试用例（8分）；
2. **阶段二：人机协同与差异审查（中间55分钟，允许统一AI协同）**——受控运用AI生成实现代码，逐行审查 `git diff`，手工修正逻辑瑕疵，保持原子提交规范（20分）；
3. **阶段三：回归验证与封包交付（最后15分钟）**——运行回归测试确保全部通过，完善 README 变更说明，打上 release 标签并完成推送（12分）。

**Git落点：** 任务分支、原子提交、测试验证、版本打标与提交日志完整性检查。

**AI参与控制面：** 严格按照考试环境统一授权模型使用，故障时启用离线等效试题，保证公平可比。

**当堂成果与评价：** 期末现场综合实操考核（折合40分计入总评）。

**课外学习：** 无课后计分任务，自愿完成课程教学反馈与学习心得交流。

## 五、阶段作业与考核衔接

| 编号 | 截止周 | 任务名称与核心考查点 | 分值 | 对应学习目标 |
| --- | --- | --- | --- | --- |
| A1 | 第1周 | 运行、完成标准与首次交接（环境隔离、验收标准、手工修改解释、同伴反馈） | 8分 | O1, O4 |
| A2 | 第2周 | 版本差异审查、提交与受控恢复（Git快照理解、原子提交、diff阅读、git restore） | 8分 | O3, O4 |
| A3 | 第4周 | 两套方案探索与分支取舍（远程协作、特性分支、双方案选型对比、取舍证据） | 8分 | O2, O3 |
| A4 | 第7周 | 系统契约、AI上下文与无损交接（Schema规范、AGENTS.md落地、交接实测、个人贡献） | 8分 | O1, O2, O5 |
| A5 | 第10周 | 范围控制、集成与回归测试（三不原则、MR代码评审、回归测试套件、防虚假修复） | 8分 | O1, O3, O4 |
| A6 | 第12周 | 阶段交付与开放协作（微里程碑治理、README盲测复现、处理贡献、开源许可合规） | 8分 | O1, O2, O5 |
| A7 | 第13周 | AI协同工程复盘报告（基于真实Git数据的客观归因、人机分工证据、得失反思） | 6分 | O5 |
| A8 | 第13周 | 自选作品终期工程封包（完整仓库规范、回归测试全绿、关键工程决策说明） | 6分 | O1—O5 |
| 过程小计 | | 8项过程性工程作业 | 60分 | |
| 期末实操 | 第14周 | 新任务90分钟现场综合实操考核（契约设计、受控实现、差异审查、回归封包） | 40分 | O1—O5 |
| 课程总计 | | | 100分 | |

所有作业证据均由平时Git开发过程自然产生，禁止期末突击补写虚假报告。

## 六、教学资源与保障措施

### 1. 软件环境与工具链

实训室机房统一配置：
- 编辑器与插件：VS Code 最新稳定版，Cline 智能体协同插件；
- 本地与私有AI：校内私有化部署的大语言模型服务（统一API端点与鉴权）；
- 版本控制：Git 2.40+ 客户端，校内自建 GitLab 服务；
- 运行环境：内置 Node.js 22 LTS 与轻量现代浏览器环境。

### 2. 脚手架与参考资料

- 前两周提供开箱即用的共同实验脚手架（含测试套件与可运行演示）；
- 配套《人月神话》选读指导卡、Git速查手册、`AGENTS.md` 模板与回归测试范式；
- 严密监控第三方依赖，不引入需要复杂云端配置的庞大框架，保护学生起步信心。

## 七、执行记录与审批

| 记录项目 | 填写要求 |
| --- | --- |
| 实际日期、班级、授课教师 | 按教务课表与实际授课填报 |
| 实施情况与进度差异 | 记录各周微实验与自选作品进度，说明进度偏离原因 |
| 教学反思与调整 | 记录学生在各周出现的典型工程误解与实验改进点 |
| 审定与批准 | 经课程负责人与教学单位按规范办理确认 |

依据编号与可核查来源详见配套《依据与故事来源说明》。

## 参考资料

来源核对日期：2026年9月20日。

[P0] [现行线上课程工作稿（本轮核对基线）](https://ai.openkub.com/courses/human-ai-programming/)

[P1] 《信通学院人工智能技术应用专业2026年高职人才培养方案》，第5—6、10、31页。

[B1] [Brooks《人月神话》英文纪念版：出版方样章与序言](https://www.informit.com/content/images/9780201835953/samplepages/0201835959.pdf)

[B2] [出版方《人月神话》纪念版目录](https://www.informit.com/store/mythical-man-month-essays-on-software-engineering-anniversary-9780201835953)

[G1] [Pro Git：版本控制](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)

[G2] [Pro Git：Git简史](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git)

[G3] [Pro Git：Git模型](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F)

[G4] [Git官方文档：diff](https://git-scm.com/docs/git-diff)

[G5] [Git官方文档：restore](https://git-scm.com/docs/git-restore)

[G6] [VS Code：源代码管理](https://code.visualstudio.com/docs/sourcecontrol/overview)

[G7] [GitLab：合并请求](https://docs.gitlab.com/user/project/merge_requests/)

[G8] [Open Source Initiative：开源定义](https://opensource.org/osd)

具体中文译名、书目信息和页码以所购教材为准，本文不复制教材正文。