课程介绍

本课程面向希望系统推进 AI 全栈开发能力建设、优化研发交付方式、提升组织级研发效能的技术团队与管理团队。课程不将 AI 理解为单点提效插件，而是将其放回真实的软件工程体系中，围绕需求理解、规格定义、任务拆解、跨前后端实现、测试验证、代码评审、流程治理、效能度量与能力复制等关键环节，系统讲解 AI 全栈开发进入研发组织后的方法路径、能力要求与管理配套。

课程按照“先建立 AI4SE 背景认知，再构建 Spec Coding 方法底座，再进入 Repo 级前后端完整交付，再重构岗位协同与研发管理机制，最后走向组织级能力建设与业务落地”的路径递进展开。课程重点不是讲若干工具如何操作，而是帮助团队建立一套适配 AI 全栈开发的完整工程方法，使 AI 能力从个体使用走向团队协作，从局部提效走向体系化落地。

课程目标

1、建立 AI4SE 的统一认知，理解 AI 编码从局部辅助走向任务级、仓库级执行后，对软件工程对象、岗位职责与交付机制带来的变化。

2、掌握 Spec Coding 的核心方法，能够将自然语言需求转化为结构化规格，提升 AI 开发的确定性、可验证性与跨岗一致性。

3、掌握 AI 参与前后端完整功能交付的基本方法，理解 Repo 级上下文装配、契约驱动联调、测试前置与交付证据整理的关键机制。

4、理解前端、后端、测试、架构、效能与管理岗位在 AI 全栈开发条件下的职责变化、能力要求与协同接口。

5、掌握适配 AI 全栈开发的最小流程、质量门禁、评审标准与效能度量方法，推动效率提升转化为稳定交付能力。

6、形成团队级模板、规则、案例与推广机制，建立可复用、可扩展的 AI 全栈开发能力建设路径。

7、结合核心业务场景形成 AI 全栈开发的落地方法，使技术能力更有效地服务业务需求交付、系统迭代与研发组织升级。  

课程大纲

第一部分：建立 AI4SE 的背景认知与工程问题意识

建议安排：第 1 天上午

目标：

本部分不先进入具体工具操作，而是先从软件工程范式演进的角度，建立对 AI4SE 的统一认知。重点回答三个问题：为什么 AI Coding 已经不再只是代码补全工具，而正在进入任务执行与交付链路；为什么 Spec、上下文、测试与评审会成为新的工程基础设施；以及为什么研发组织必须同步调整岗位分工、协同机制与治理方式，才能真正承接 AI4SE 带来的效率变化。

模块一：AI4SE 的行业背景与软件工程范式迁移

1.  从代码生成到工程动作执行的能力跃迁：系统分析 AI 编码能力从补全级、修改级走向任务级、仓库级执行的演进路径，理解“生成代码”与“推进一个工程动作”之间的差异。

2.  从局部实现到完整交付单元的对象切换：讨论研发活动如何从以函数、类、文件为中心，逐步转向以需求片段、规格、任务、验证与交付工件为中心的组织方式。

3.  从同步协作到异步 Agent 执行的研发节奏变化：分析 AI 介入后任务颗粒度、反馈频率、并行方式与责任边界为何会一起改变。

4.  从工具采纳走向工程体系承接的组织命题：说明企业推进 AI4SE 时，真正的挑战不在“有没有工具”，而在“是否具备承接工具的规格、流程、验证与治理体系”。

5.  从单点效率议题走向研发方式升级议题：建立课程整体问题意识，使学员理解后续 Spec、交付、协同、管理与推广几部分内容之间的内在关系。

模块二：AI4SE 时代的新型工程基础设施

1.  Spec 作为确定性输入层：讨论规格为何从传统说明材料，转变为 AI 执行的边界定义、跨岗协同的共同基线与变更追踪的主索引。

2.  Context 作为执行资源层：分析仓库上下文、业务上下文、规则上下文、工具上下文与运行状态如何共同决定 AI 输出质量。

3.  Rules 作为团队约束层：讲解代码规范、接口约定、字段字典、异常码体系、评审标准等规则如何从“经验性约定”变为“必须显式建模的执行约束”。

4.  Tests 作为验证控制层：分析 AI 条件下测试为何必须从后置验收转向过程内验证，理解“生成链增强，验证链必须同步增强”的基本逻辑。

5.  Evidence 作为治理留痕层：讨论变更摘要、验证记录、影响面说明、风险点和回滚策略为何会成为 AI 参与研发之后的重要治理工件。

模块三：AI4SE 对研发组织的典型影响

1.  岗位边界的松动与职责重心的上移：分析前端、后端、测试等岗位在 AI 条件下的变化，理解“技术栈分工”与“交付责任分工”的差异。

2.  协同模式从串行接力转向规格驱动并行：讨论需求、开发、测试、评审之间的协作关系如何改变，以及为什么 AI 会倒逼组织重写协同接口。

3.  局部收益难以自然转化为系统收益的原因：分析个体层面的编码提速为何可能被联调、测试、评审、发布与审批环节抵消。

4.  研发管理面临的核心适配问题：讨论流程过长、基线不清、质量门禁后置、指标失真、知识沉淀不足等典型矛盾在 AI 条件下为何会更突出。

5.  AI4SE 课程主线的工程地图：将后续 Spec Coding、Repo 级交付、岗位协同、质量治理、业务结合与推广机制串成一套完整的问题框架。

工作坊：AI4SE 影响点识别与团队现状盘点

本工作坊围绕团队当前研发方式展开，组织学员从需求输入、规格表达、仓库上下文、测试机制、评审方式、岗位分工、发布门禁和过程留痕几个维度，对现有工程基础进行系统盘点，识别已经受到 AI 影响的环节、尚未适配的关键环节以及未来最可能形成瓶颈的环节，最终形成一份“团队当前状态—AI4SE 影响点—后续建设重点”的共识图谱。

第二部分：构建 Spec Coding 驱动的结构化研发输入

建议安排：第 1 天下午

目标：

本部分聚焦 AI 全栈开发的方法底座，系统回答“为什么 AI 经常在真实需求中失效”以及“怎样为 AI 提供可执行、可验证、可追踪的输入”。课程将围绕 Spec Coding 展开，帮助学员掌握将自然语言需求转化为结构化规格的方法，并建立规格与任务拆解、测试设计、评审检查和变更追踪之间的绑定关系。

模块四：Spec Coding 的方法论基础

1.  Spec 的核心价值在于约束而非说明：阐明 Spec 在 AI 开发中的作用不只是记录需求，而是建立范围边界、明确执行约束、压缩理解歧义。

2.  从口语需求到工程规格的转写逻辑：讲解如何将会议结论、业务描述、原型说明等模糊输入转化为面向实现和验证的结构化规格。

3.  Spec 作为跨岗共同真相源：分析前端、后端、测试、评审为何必须围绕同一份规格协同，而不能继续依赖各自的局部理解。

4.  Spec Coding 与传统需求文档的边界差异：讨论为何 AI 条件下的规格更强调范围、约束、行为、边界和验收，而不是长篇说明性文本。

5.  Spec 在组织级研发中的枢纽作用：说明 Spec 如何连接需求澄清、实现拆解、测试派生、评审检查与后续变更追踪。

模块五：结构化 Spec 的核心组成

1.  范围定义与非目标约束：讲解为何 Scope 与 Non-Goal 必须并列存在，以及它们对控制 AI 扩展实现边界的重要作用。

2.  主流程、异常流程与边界反例：讨论为什么 AI 最容易在异常路径和边界条件上出错，以及如何通过结构化规格将这些内容前置写清。

3.  页面行为、接口契约与状态迁移的一体化建模：讲解如何将前端交互、后端接口、业务状态和规则约束放在同一规格框架中表达。

4.  验收断言的工程化写法：说明为什么“体验友好”“逻辑合理”不能作为 AI 执行依据，以及如何将验收标准写成可测试、可评审、可判定的断言。

5.  非功能要求进入规格的方法：讨论性能、权限、审计、兼容性、回滚要求等非功能性约束如何进入 Spec，避免 AI 只关注功能主线。

模块六：以 PRD 规格化作为研发入口控制面

1.  PRD 质量波动为何会在下游被放大：分析上游输入不稳定时，需求澄清、设计决策、测试设计与交付节奏为何都会受到连锁影响。

2.  从写作物到规格资产的改造方向：讲解如何让 PRD 从叙述性文档转向具有目标、非目标、规则、边界、异常、验收和风险结构的规格骨架。

3.  研究式生成与证据化表达：讨论如何把历史缺陷、业务规则、监管约束、系统限制等依据前置到需求形成过程，使规格不再停留在主观表述。

4.  需求—设计—测试映射的前置建立：说明规格条款为何必须能够自然映射到研发任务、测试用例与交付证据，避免形成“伪完成”。

5.  以入口确定性换下游交付确定性：强调研发入口稳定之后，后续编码、测试和发布自动化才具备规模化价值。

案例研讨：某国有大型银行的规格驱动研发实践

围绕“PRD 波动、证据缺失、需求—测试链路断裂、变更影响难判断”这一类典型问题，分析如何通过研究驱动的 PRD 规格化改造，把需求入口从一次性写作物升级为可验证、可追踪、可复用的规格资产。

工作坊：结构化 Spec 编写与任务拆解实战

本工作坊围绕一个真实业务功能展开，组织学员完成从原始需求梳理、结构化 Spec 编写，到任务拆解、验收断言抽取和测试点派生的全过程，最终形成一份可直接进入 AI 开发链路的最小规格工件。

第三部分：建立 AI 参与的 Repo 级前后端完整交付闭环

建议安排：第 2 天

目标：

本部分在完成结构化研发输入之后，进一步进入真实交付链路，回答“AI 如何从局部编码辅助走向完整功能交付”。课程围绕 Repo 级上下文组织、前后端契约协同、多文件修改、联调验证、测试前置与交付工件整理展开，帮助学员掌握 AI 全栈开发的工程闭环方法。

模块七：Repo 级 AI 开发的上下文组织

1.  仓库结构理解作为执行前提：讲解目录结构、模块边界、依赖关系、配置入口、测试入口对 AI 实现路径的决定作用。

2.  从单文件生成到多文件联动的思维切换：分析页面、接口、DTO、配置、测试和脚本往往共同变化的原因，理解 Repo 级开发与局部辅助的本质差异。

3.  计划先行的执行组织方式：说明为何 AI 在复杂需求下必须先生成实现计划、识别变更点、梳理影响面，再进入代码修改与验证。

4.  常见失效模式与预防机制：讨论上下文不足、模块定位错误、依赖遗漏、配置缺失、测试入口错误等典型问题的成因与预防方式。

5.  Repo 级开发的交付视角：强调 AI 修改代码不是终点，真正目标是产出可联调、可验证、可评审、可回滚的完整交付结果。

模块八：前端侧的 AI 全栈开发方法

1.  页面骨架、状态模型与交互结构的组织方式：系统讲解页面层次、组件关系、状态管理、表单模型与交互流程如何进入 AI 的执行上下文。

2.  高频页面模式的规格化表达：围绕表单页、列表页、详情页、配置页等典型模式，讨论查询、分页、排序、字典映射、校验和反馈的建模方法。

3.  前端实现中的高风险漏项识别：分析权限控制、异常提示、禁用条件、空态展示、边界状态、字段映射等 AI 容易遗漏的关键点。

4.  前端代码生成与组件治理的平衡：讨论在 AI 提升局部实现效率的同时，如何避免组件边界混乱、样式失控与前端工程一致性下降。

5.  前端验证的最小闭环：说明前端实现完成后应如何进行功能验证、交互验证、状态验证与视觉回归检查。

模块九：后端侧的 AI 全栈开发方法

1.  接口、领域对象与状态流转的上下文表达：讲解请求模型、响应模型、领域对象、状态迁移、权限校验与异常语义如何组织成 AI 可执行输入。

2.  后端实现中的关键工程约束：围绕参数校验、权限控制、事务边界、幂等处理、日志审计、异常码设计等主题，分析 AI 容易忽略的控制点。

3.  数据层变化的联动机制：讨论表结构、字典项、配置项、迁移脚本与缓存策略如何与接口逻辑共同构成后端改动范围。

4.  业务逻辑正确性与实现完整性的区别：说明 AI 生成“看起来可运行”的代码，不等于覆盖了完整业务规则、审计要求与异常路径。

5.  后端验证的最小闭环：讲解接口测试、规则测试、异常测试、鉴权测试与数据一致性检查在 AI 条件下的前置意义。

模块十：前后端契约驱动联调与测试前置

1.  接口契约先行的联调原则：讲解前后端为何必须围绕字段语义、枚举取值、异常码、状态机和返回结构形成统一契约。

2.  联调中的高频不一致问题：系统分析字段命名差异、时间金额格式差异、空值语义差异、错误提示差异、按钮权限差异等典型返工来源。

3.  Mock、样例数据与假环境的作用：说明在 AI 加速开发条件下，为什么需要更稳定的联调样例和假数据环境来降低等待成本。

4.  测试从后置验收到过程内验证的转变：讲解如何从 Spec 直接派生单元测试、接口测试、契约测试与关键场景测试。

5.  最小交付证据的形成方式：讨论测试结果、截图、接口样例、异常用例、影响面说明与风险提示如何共同构成可审查的交付证据。

模块十一：从规格到实现、测试与证据包的闭环收束

1.  规格条款与实现项的映射关系：讲解如何让页面、接口、规则、状态和异常处理都能回指到对应规格条款。

2.  规格条款与测试项的映射关系：说明为什么测试用例不能临时补写，而应由规格断言与风险边界自然派生。

3.  交付证据包的组成方法：讨论变更摘要、验证结果、关键截图、异常样例、风险说明、回滚条件如何形成标准化工件。

4.  变更影响与回滚条件的前置表达：讲解为何回滚策略和影响面说明必须在交付前完成，而不能放到发布后补写。

5.  从“代码完成”到“交付完成”的判断标准：强调 AI 全栈开发不能停留在代码层，而必须以完整交付与可验证性收束。

工作坊：Repo 级完整功能交付实战

本工作坊围绕一个带页面、接口、规则校验与联调验证的真实功能展开，组织学员完成上下文装配、任务计划、多文件修改、前后端联调、测试验证与交付说明整理，形成从 Spec 到 Repo 级交付的最小闭环。

第四部分：重构岗位协同、评审方式与研发管理适配

建议安排：第 3 天

目标：

本部分聚焦 AI 全栈开发进入组织之后最关键的落地问题：岗位怎么变、协同怎么改、评审看什么、流程如何适配。课程将从岗位职责重构、协同接口设计、评审重点迁移、流程重组、质量门禁、端到端评估与效能度量几个层面展开，帮助团队建立适配 AI 全栈开发的新型研发管理机制。

模块十二：岗位职责的重心重构

1.  前端岗位从实现执行走向交互抽象与体验治理：讨论前端岗位在 AI 条件下如何更多承担页面抽象、组件规范、体验一致性与前端工程边界控制。

2.  后端岗位从接口实现走向领域规则与契约治理：分析后端岗位为何会更加强调领域约束、数据一致性、异常语义与可审计性。

3.  测试岗位从后置验证走向规格校验与门禁设计：讲解测试岗位如何从单纯验收转向参与规格澄清、验收断言设计、自动化回归与质量门禁建设。

4.  架构与效能岗位从选型支持走向规则与平台建设：讨论其在模板、规范、脚本、流水线、工具接入与共享能力层建设中的新职责。

5.  管理岗位从任务分派走向交付组织与能力编排：说明管理者为何需要重新关注任务颗粒度、协同节奏、评审效率、指标观察与风险兜底。

模块十三：AI 全栈开发下的协同接口设计

1.  围绕共同对象重构协同，而不是围绕角色口头约定协同：讲解为何 Spec、接口契约、字段字典、异常码、状态机、验收断言必须成为统一协作对象。

2.  并行协同条件下的职责边界设计：讨论在开发、联调、测试同步前移时，如何重新界定谁负责定义、谁负责实现、谁负责确认通过。

3.  需求澄清会、联调会、评审会的关注点重写：分析不同会议类型应该围绕哪些对象展开，避免低信息密度和重复性沟通。

4.  阻塞条件与升级机制的显式化：讲解在高频反馈节奏下，如何定义阻塞条件、升级路径与跨岗问题处理机制。

5.  从“人找人对齐”走向“围绕规格与证据对齐”：强调协同机制设计的目标不是减少沟通，而是提高沟通对象的工程密度。

模块十四：研发流程、质量门禁与 CMMI 适配

1.  流程不是取消，而是前移、收敛与重组：分析 AI 条件下哪些控制点必须保留，哪些流转可以压缩，哪些检查必须前移到过程内。

2.  需求基线与规格评审的重构方法：讲解如何以结构化 Spec 作为需求基线，提升需求评审、范围控制与变更管理的清晰度。

3.  配置管理与交付留痕的适配机制：讨论在 AI 参与实现之后，代码、脚本、配置、测试和验证记录如何共同纳入可追踪、可审计的交付管理。

4.  质量门禁的分层设计：讲解规格门禁、开发门禁、测试门禁与发布门禁在不同阶段分别检查哪些对象、由谁判断、以什么工件给出结论。

5.  CMMI 语境下的 AI 研发适配思路：说明如何在不削弱过程可控性、可追溯性和质量治理的前提下，将 AI 全栈开发纳入现有成熟流程体系。

模块十五：端到端评估、放量门禁与失败回放

1.  评估对象从“回答质量”扩展到“系统行为质量”：讲解为何在智能体和 AI 驱动交付场景中，必须同时评估结果、证据、动作、边界与代价。

2.  Success / Reliability / Risk / Cost 的四维评估框架：讨论如何用统一语言描述任务完成度、系统稳定性、边界风险与单位成本，而不是只看局部技术指标。

3.  离线与线上之间的 Sim2Real 迁移问题：分析为何离线高分并不等于线上稳定，以及如何通过仿真用户、边界样本和扰动约束提升可迁移性。

4.  灰度扩容、自动降级与 Go/No-Go 机制：讲解如何把评估结论真正变成放量策略与回滚策略，而不是停留在展示型分数。

5.  失败样本归因与历史事故回放：说明如何将线上失败样本结构化归因到路由、证据、权限、工具、上下文等关键环节，并形成可回放、可回归的评测集。

模块十六：AI 条件下的效能度量与管理看板

1.  从编码产出指标转向交付过程指标：讨论为什么“写了多少代码、节省了多少时间”不足以反映 AI 全栈开发的真实价值。

2.  围绕交付周期建立核心度量体系：讲解需求到联调、联调到验收、验收到发布等关键链路的周期如何成为研效判断重点。

3.  围绕稳定性交付建立质量度量体系：分析返工次数、缺陷逃逸率、一次评审通过率、回归通过率等指标对判断真提效的重要性。

4.  围绕过程成熟度建立能力度量体系：讨论 Spec 完整度、任务拆解质量、验证覆盖率、人工接管率等过程指标如何帮助识别组织短板。

5.  从看板展示到管理动作联动：说明度量的真正意义在于识别瓶颈、校准流程、调整协同与判断推广节奏，而不是形成新的报表负担。

案例研讨：某头部股份制银行的 E2E 评估与 Sim2Real 治理实践

围绕“只评回答、不评证据与动作”“离线高分、线上翻车”“放量不可控、责任不可界定”这一类问题，分析如何建立系统级评估语言、灰度门禁和失败回放机制，使版本比较、扩容决策和风险处置具备证据基础。

工作坊：岗位协同与最小流程草案设计

本工作坊围绕本团队真实岗位结构与现有研发流程，组织学员输出岗位职责重心草案、协同接口草案、评审清单、质量门禁图、评估框架与最小流程图，形成适配 AI 全栈开发的初版管理框架。

第五部分：走向业务结合、语义治理与组织级能力建设

建议安排：第 4 天

目标：

本部分在完成方法、交付与管理机制讨论之后，进一步回答“如何把 AI 全栈开发从少数骨干的经验，转化为团队可复制、可推广、可持续演进的组织能力”。课程将围绕业务场景分层、语义治理、标准资产沉淀、分层培养体系与组织级建设框架展开，形成面向长期建设的整体方案。

模块十七：工具能力与业务场景的结合路径

1.  业务场景选择必须建立分层方法：讲解为什么不是所有需求都适合同样方式推进 AI 全栈开发，而必须从复杂度、风险与收益三个维度进行判断。

2.  适合优先推进的高频标准化场景：分析后台运营、审批配置、规则配置、表单流、查询分析、管理端页面等场景为何更容易形成稳定样板。

3.  需要谨慎推进的高风险复杂场景：讨论核心交易、复杂计费、强一致性链路、高审计要求场景在 AI 条件下面临的特殊约束。

4.  从工具能力到业务价值的映射方法：说明如何将 Spec、Repo 级交付、测试前置和评审机制真正落到业务需求交付周期、系统迭代效率与支撑能力提升上。

5.  场景分层对推广节奏的决定作用：强调组织建设应遵循先样板、再扩展、再体系化的基本路径。

模块十八：从配置堆叠到语义治理与受控执行

1.  规则工程化债务的形成机制：分析在复杂业务系统中，为什么规则、配置、脚本和流程条件会逐步演化为不可维护的复杂度放大器。

2.  统一语义层作为控制面的治理价值：讲解如何围绕对象、属性、关系、策略边界和处置动作建立统一语义框架，减少跨系统口径漂移与冲突。

3.  决策结果从命中值升级为证据化输出：讨论为何在高约束场景中，结论必须与依据、条件和版本强绑定，才能支撑争议处理与审计复盘。

4.  关键动作进入受控执行通道：说明自动化动作为什么必须具备边界校验、权限隔离、异常降级、人工接管和审计留痕，而不能只追求自动化率。

5.  专家经验向组织资产的抽象路径：强调复杂系统最终拼的不是“是否能跑”，而是“是否能统一解释、统一约束、统一治理”。

模块十九：标准资产沉淀与团队规则建设

1.  哪些经验必须沉淀为组织资产：讲解 Spec 模板、任务模板、提示模板、代码规则、字段约定、异常码规范、测试模板与评审清单的建设价值。

2.  从骨干经验到团队规范的转化机制：分析为什么只依赖高手示范难以形成团队能力，以及如何把经验转成可学习、可复用、可审核的显性资产。

3.  共享规则与共享工件的作用边界：讨论哪些内容适合固化为团队共识，哪些内容应保留局部弹性，避免规则过载或模板失效。

4.  案例资产与失败案例库的长期价值：说明优秀案例、返工案例、缺陷案例和评审案例如何共同构成组织学习机制。

5.  规则建设与平台能力的联动关系：强调标准资产最终要进入工具配置、脚本能力、流水线检查与团队协作环境。

模块二十：分层培养体系与组织级建设框架

1.  能力建设必须分层而不是一刀切推进：讲解基础层、进阶层、骨干层在能力要求、实践任务和培养方式上的差异。

2.  从个人会用工具到团队具备交付能力的升级路径：分析结构化 Spec、Repo 级任务闭环、评审能力、模板建设与规则输出如何构成进阶路径。

3.  带教、认证、复盘与扩散机制的设计：讨论如何通过结对实践、样板项目、复盘机制与阶段性认证推动能力扩散。

4.  组织级建设框架的五层结构：系统梳理方法层、工程层、流程层、治理层与人才层的建设对象及相互关系。

5.  从局部样板到体系化推广的收敛方法：说明组织推进时如何控制节奏、选择切入口、判断成熟度并持续校准方法。

结业工作坊：AI 全栈开发组织能力建设方案共创

本工作坊采用分组方式，围绕真实业务与研发场景，组织学员输出一版综合建设方案，内容包括场景分层、核心能力项、模板资产、协同机制、最小流程、质量门禁、评估框架、语义治理要点与推广路径。工作坊的重点不是停留在培训总结，而是形成一份后续可持续推进的组织能力建设草案。