课程介绍

本课程面向希望系统提升岗位 AI 应用能力的研发、测试、运维及相关技术管理人员。课程不从零散工具功能出发，也不将 AI 理解为代码补全或单点问答助手，而是围绕研发全流程中最核心的三类工程能力展开：一类是面向真实代码仓库的执行能力，一类是面向需求与变更的规格组织能力，一类是面向复杂任务的技能化工作流能力。

课程以研发活动的真实推进过程为主线，系统讲解 AI 如何进入需求澄清、方案设计、任务拆解、代码实现、测试验证、评审交付、发布变更、问题定位与经验沉淀等关键环节，帮助学员建立对 AI 工程化应用的整体认识。课程强调的不是“如何把一句提示词写得更漂亮”，而是“如何把任务讲清楚、把上下文给到位、把变更组织好、把验证做扎实、把方法沉淀下来”。

课程整体分为三个部分。第一部分聚焦仓库级执行，让学员建立对执行型 AI 工具的第一手认知，理解 AI 如何真正进入工程现场推进任务；第二部分聚焦规格驱动，帮助学员掌握从模糊需求到结构化变更的组织方法，降低执行过程中的歧义、返工和漂移；第三部分聚焦技能化工作流，讲清楚如何把研发中的高频动作固化为可复用的方法与模板，使 AI 使用从个人尝试走向团队规范与长期沉淀。

课程目标

1. 建立 AI4SE 全流程统一认知，理解 AI 在研发、测试、运维链路中的定位、边界与协同方式。

2. 掌握面向真实仓库的 AI 协作方式，理解代码理解、跨文件修改、命令执行、测试运行与变更整理的闭环。

3. 掌握规格驱动的基本方法，理解需求、设计、任务、测试与交付工件之间的关系。

4. 掌握技能化工作流的基本思想，理解设计先行、计划先行、测试先行、审查回路与任务分派的工程价值。

5. 理解 Prompt、Context、Tool、Skill、Memory、Policy、Eval、Guardrail 等关键要素在研发闭环中的真实落点。

6. 理解 AI 使用方式从“问答式”转向“任务式、变更式、工件式、工作流式”的能力升级。

7. 通过真机实操与场景化演练，形成岗位可复用的模板、规格样例、任务清单、测试样例与落地动作。

课程大纲     

第一部分：Claude Code——仓库级执行与研发任务闭环

建议安排：第 1 天上午

目标

本部分围绕执行型 AI 工具在研发现场中的实际用法展开，帮助学员建立对“AI 不只是回答问题，而是能够理解仓库、推进任务、完成改动、运行验证、整理交付”的第一手认知。重点解决研发人员最常见的认知偏差：为什么 AI 在演示场景中看起来很好用，一旦进入真实项目却容易出现改错位置、理解跑偏、改动不完整、验证不充分等问题。

模块一：从代码补全到仓库级执行

1. AI 编程工具的能力演进：从补全、问答、局部改写走向任务承接与闭环推进。      

2. 真实研发任务中的最小闭环：理解需求、识别改动点、修改代码、运行命令、验证结果、整理输出。      

3. 为什么“推进一个工程动作”比“生成一段代码”更接近真实研发价值。

4. 哪些任务适合优先交给执行型 AI，哪些任务仍然需要人工主导。

5. 如何建立对 AI 执行能力的合理预期，而不是把它等同于自动化替代。

6. 从工具视角转向任务视角，理解 AI 在研发中的真正落点。

模块二：代码仓库上下文与执行稳定性

1. 决定 AI 表现的，不只是提示词，而是仓库结构、依赖关系、配置方式、构建入口与测试入口。

2. 工程任务中的真实输入层：用户目标、仓库代码、项目约定、运行环境、命令反馈与任务历史。      

3. 为什么同样的模型在不同项目中的稳定性会明显不同。      

4. 如何组织上下文，让 AI 获得足够信息而不过载。

5. 项目规则、团队约定、历史代码风格对 AI 输出一致性的影响。

6. 从“会问问题”转向“会组织任务信息”。

模块三：执行型 AI 的常见失效模式

1. 常见问题：改错文件、漏改依赖、误解边界、命令执行不完整、结果看似正确但无法交付。      

2. 为什么很多问题不是“代码生成错了”，而是“上下文给错了、范围没讲清、验证没做全”。

3. 如何通过任务边界、执行顺序与人工确认点降低风险。      

4. 代码修改、命令执行、外部调用与危险动作的控制方式。      

5. 从只关注最终结果转向关注执行过程与验证过程。      

6. 让 AI 成为受控的执行者，而不是不可见的黑盒。

模块四：研发闭环中的最小交付要求

1. 一个可接纳的 AI 研发输出，至少应包含代码改动、验证记录、风险说明与变更摘要。      

2. 为什么“代码写完了”不等于“研发任务完成了”。

3. 从结果展示走向证据交付。

4. 让 AI 输出进入团队协作，而不是停留在个人使用。

5. 研发闭环中最小工件集的组织方式。

6. 为后续规格驱动与技能化工作流打基础。      

工作坊：仓库级任务最小闭环实战

围绕一个真实的小型研发任务，组织学员完成从需求理解、仓库扫描、改动定位、代码修改、测试运行到结果整理的最小闭环。重点不是单纯体验“AI 很快”，而是观察其在仓库理解、执行路径、影响面判断与验证链路中的真实表现，并输出一份最小研发闭环样例。

第二部分：OpenSpec——规格驱动的需求澄清与变更实施

建议安排：第 1 天下午

目标

本部分聚焦研发过程中最容易被忽视、但又最决定后续执行质量的一环：需求与变更的结构化组织。重点帮助学员理解，AI 进入研发链路之后，最怕的不是不会写代码，而是需求模糊、边界不清、约束缺失、任务拆解不到位。课程将通过规格驱动的方法，把模糊需求转化为可执行、可验证、可追踪的变更输入。

模块五：为什么要先做规格

1. 模糊需求直接进入执行，往往会导致意图漂移、边界模糊与返工扩散。      

2. AI 会放大需求表达中的不确定性，而不是自动消除不确定性。      

3. 规格的作用不是增加文档，而是把执行前提讲清楚。      

4. 需求讨论的重点要从“想做什么”转向“做什么、不做什么、怎么验收、哪里有风险”。

5. 为什么需求没有讲清时，后面的设计、实现、测试都会不稳定。      

6. 让 AI 从“猜需求”转向“按变更输入推进任务”。

模块六：从原始需求到结构化变更

1. 一个可执行的变更，至少要讲清背景、目标、范围、约束、边界与完成标准。      

2. 如何把口语化需求转化为结构化说明。      

3. 如何区分 Scope 与 Non-Goal，减少 AI 的过度扩写。

4. 如何通过边界条件、反例与约束减少实现阶段的误判。      

5. 如何把需求、设计、任务与测试串成一条连续的工程链路。      

6. 从一句话需求走向一套最小变更包。

模块七：设计与任务拆解

1. 设计不是事后总结，而是实现前的路径约束。      

2. 如何把一个需求拆成可实施、可追踪、可验证的任务清单。      

3. 任务拆解中应体现依赖、优先级、验证顺序与完成条件。      

4. 为什么“先形成计划，再推进执行”会显著降低 AI 漂移。

5. 在实施中发现新问题时，如何反向修正规格与设计。      

6. 让设计、任务与执行形成闭环，而不是彼此脱节。      

模块八：规格驱动的开发、测试与评审

1. 规格、代码、测试、评审应建立强绑定关系。      

2. 影响面分析、多文件修改、测试补齐与交付整理如何在规格约束下推进。      

3. 需求验收不再靠感觉，而要靠断言、样例、边界条件与验证记录。      

4. 代码评审不只看代码写得好不好，还要看是否满足原始需求与变更目标。      

5. PR 工件如何与需求、设计、测试对应起来。      

6. 从“完成代码修改”走向“完成一次变更闭环”。

工作坊：从原始需求到结构化变更包

围绕一个真实功能需求，组织学员从原始口语化输入出发，完成需求澄清、范围划分、设计整理、任务拆解与测试准备，并形成一套最小变更包。重点在于让学员体会：决定 AI 输出质量的，不是提示词修辞，而是变更是否已经被组织成清晰、完整、可执行的工程输入。

第三部分：Superpowers——技能化工作流与团队级工程方法沉淀

建议安排：第 2 天上午 + 第 2 天下午

目标

本部分聚焦 AI 使用方式从“个人临场提问”走向“团队稳定工作流”的升级过程。重点讲清楚如何把研发中的高频动作沉淀为可复用的方法与模板，如何把设计、计划、实现、测试、调试、审查、交付等动作组织成稳定的工程流程，使 AI 使用从偶发提效走向持续、可审查、可复制的团队级能力。

模块九：从 Prompt 到 Skill

1. Prompt 更适合一次性调用，Skill 更适合稳定复用。

2. 一个可复用的 Skill，通常应包含适用场景、输入条件、执行步骤、检查清单与输出模板。

3. 哪些研发动作适合优先技能化：需求分析、设计拆解、代码实现、测试补齐、缺陷修复、PR 整理、发布说明。

4. 为什么技能化能够降低个人经验差异，提高团队内部输出一致性。      

5. 从“会用工具”转向“会用一套稳定方法”。

6. 让 AI 使用方式从临场发挥转向工程复用。

模块十：设计先行、计划先行、测试先行

1. 复杂研发任务不能直接一句话交给 AI 完成。

2. 设计先行可以明确方案与边界，避免实现阶段的大幅返工。      

3. 计划先行可以形成清晰路径，降低任务推进中的漂移。      

4. 测试先行可以把实现约束到可验证范围内。      

5. 小步推进、逐步验证、持续确认，是复杂任务中比“一次性生成”更可靠的方法。

6. 让 AI 的工作方式更接近真实工程，而不是一次性产出。

模块十一：子任务分派、审查回路与复杂任务协作

1. 复杂任务宜拆分，不宜一条链跑到底。      

2. 子任务分派的依据可以来自模块边界、文件边界、能力边界与验证边界。      

3. 多任务并行推进时，仍然需要共享目标、共享规格、共享计划与共享验证标准。      

4. 审查回路的意义在于让结果经过检查、对比、确认，而不是直接接纳。      

5. AI 在代码评审、差异分析、风险识别与交付确认中的典型作用。      

6. 从单点调用转向可拆分、可汇总、可复核的复杂任务方法。      

模块十二：系统化调试、验证与完成确认

1. 问题定位应围绕现象、假设、验证、修复、确认展开。      

2. 修复完成不以“看起来差不多”为标准，而以验证结果为标准。

3. 测试、日志、回归、边界条件与交付记录共同构成修复证据链。      

4. 为什么“先验证，再宣布完成”是 AI      进入工程闭环的关键要求。

5. 如何把调试与验证也纳入可复用工作流。      

6. 让完成定义从主观判断转向客观证据。      

模块十三：团队级共享规范与长期沉淀

1. 团队真正需要的，不只是大家都会用 AI，而是大家按照相近的方法用 AI。

2. shared rules、shared checklists、shared specs、shared skills、shared templates 的组织方式。      

3. 如何形成统一的规格门禁、测试门禁、评审门禁与发布门禁。      

4. 如何沉淀统一的任务输入、执行记录、验证结果、风险说明与复盘条目。      

5. 从个人提效到团队规范，再到组织级工程资产沉淀。      

6. 让 AI4SE 从工具应用升级为工程能力建设。

结业工作坊：三部分贯通的 AI4SE 全流程综合演练

采用分组方式完成一次端到端练习，要求学员基于真实需求完成一次从仓库级执行、规格驱动组织到技能化流程推进的完整演练，输出内容包括任务说明、结构化规格、设计与任务清单、代码变更摘要、测试记录、评审意见、发布说明与流程模板草图。工作坊重点不是看学员是否会操作几个工具，而是检验其是否已经能够把执行能力、规格能力与技能化方法组织成一个最小但完整的研发闭环。