docs: 更新TRA编程培训课程材料、课件与AI技能交付包

- 新增全套考试卷、评估卷、参考答案与考试培训包模板
- 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象
- 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求
- 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块
- 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语
- 新增考试输出模板与TRAE使用记录文档

slidev/pages/day6/m1-team-flow.md

@@ -0,0 +1,124 @@
+# 模块 1：AI 改动的工程闭环
+
+<div class="mt-6 text-sm">
+
+AI 辅助完成的代码，仍然要经过研发协作中的基本检验：范围清晰、变更可审查、结果可验证、结论可追溯。
+
+这些工程要素共同约束 AI 改动的速度、质量与责任边界。
+
+</div>
+
+<div class="mt-8 text-sm">
+
+```text
+影响分析
+  -> 变更实现
+  -> PR 说明
+  -> Git 审查与合并
+  -> CI 构建与测试
+  -> 发布或回退判断
+  -> 可追溯技术结论
+```
+
+</div>
+
+<!--
+逐字稿：第六天不再讨论如何让 AI 生成更多代码，而是讨论一段 AI 改动怎样进入研发交付。前面的影响分析、测试安全网和回退判断，会在这里连接成一条可审查、可验证、可追溯的工程链路。每个环节都要留下能够支撑下一步判断的技术信息。
+
+第六天不再介绍新的工具按钮，而是把前面形成的影响分析、问题定位、测试安全网和回滚判断放回工程交付的完整语境。
+
+这条链路强调每一步输出什么技术信息：影响分析限制范围，变更实现落实规则，PR 提供审查上下文，Git 保存历史，CI 补充自动化验证，最后留下准确的技术结论。它描述的是工程质量要求，不预设任何组织安排。
+-->
+
+---
+
+# CI/CD 在交付链路中的位置
+
+<div class="grid grid-cols-3 gap-3 mt-6 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
+<div class="font-bold">CI：持续集成</div>
+<div class="mt-2 text-xs op-70">代码提交后自动编译、检查和测试，尽早发现无法合入的问题。</div>
+</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
+<div class="font-bold">持续交付</div>
+<div class="mt-2 text-xs op-70">CI 通过后形成可部署版本，进入测试或预生产环境；生产发布仍需人工确认。</div>
+</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
+<div class="font-bold">持续部署</div>
+<div class="mt-2 text-xs op-70">CI 通过后自动发布生产环境，需要成熟的监控、自动化门禁和回退能力。</div>
+</div>
+</div>
+
+<div class="mt-8 text-sm text-center">
+提交 PR <span class="op-50">-&gt;</span> CI 构建与测试 <span class="op-50">-&gt;</span> 可部署版本 <span class="op-50">-&gt;</span> 测试环境验证 <span class="op-50">-&gt;</span> 人工确认 <span class="op-50">-&gt;</span> 生产发布或回退
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-slate-500/10 border border-slate-500/30 text-xs">
+CI 负责尽早暴露问题；是否发布仍需要结合业务风险和验证证据作出判断。
+</div>
+
+<!--
+逐字稿：CI 的全称是持续集成，代码进入协作链路后，它自动执行编译、检查和测试，尽早暴露不能合入的问题。CD 需要区分持续交付和持续部署：前者形成可部署版本并保留人工发布判断，后者才是自动发布生产环境。无论采用哪种方式，CI 通过都只是发布判断的一份证据。
+
+CI 是持续集成，关注代码进入协作链路后能否正常构建、检查和测试。第六天的 CI 日志分析会围绕这个环节展开。
+
+CD 在不同语境中可能指持续交付或持续部署。持续交付侧重形成可部署版本，生产发布保留人工确认；持续部署则会自动发布生产环境。两者的差异是生产发布是否自动发生。
+-->
+
+---
+
+# AI 改动进入协作后的四类信息
+
+<div class="grid grid-cols-2 gap-4 mt-8 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
+改动目标
+<div class="mt-2 text-xs op-70">解决什么问题，明确不解决什么问题</div>
+</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
+影响范围
+<div class="mt-2 text-xs op-70">涉及哪些入口、数据、状态、权限或外部依赖</div>
+</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
+验证证据
+<div class="mt-2 text-xs op-70">哪些行为已经由测试、日志或人工检查证实</div>
+</div>
+<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30">
+已知边界
+<div class="mt-2 text-xs op-70">哪些场景尚未覆盖，哪些结论仍需要确认</div>
+</div>
+</div>
+
+<!--
+逐字稿：AI 参与过的上下文不能只停留在对话窗口。进入协作后，至少要把改动目标、影响范围、验证证据和已知边界写清楚。这样评审、排障和后续维护的人才能基于同一组事实继续判断，而不是重新猜测改动意图。
+
+AI 生成代码时，关键上下文很容易只留在对话窗口中。进入协作链路后，至少需要把改动目标、影响范围、验证证据和已知边界说清楚。
+
+这四类信息不是额外文书，而是代码评审、CI 排障和后续维护能够进行准确判断的前提。
+-->
+
+---
+
+# 工程质量的最终责任仍在人
+
+<div class="mt-5 text-xs">
+
+| AI 可以加速 | 人必须确认 |
+|---|---|
+| 搜索代码、归纳调用链、生成候选实现 | 业务规则是否正确 |
+| 生成测试草稿、解释日志、提出修复假设 | 权限、数据和状态边界是否完整 |
+| 补充 PR 说明和变更摘要 | 变更范围是否可接受，验证结论是否准确 |
+| 提供多种实现方案 | 采用哪一种方案及其长期维护成本 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+把 AI 当作加速器，而不是把工程判断外包给 AI。
+</div>
+
+<!--
+逐字稿：AI 可以快速搜索代码、生成候选实现、起草测试和解释日志，但这些都是辅助判断的材料。业务规则是否正确、权限和数据边界是否完整、变更是否可以合入，仍然需要由人根据证据确认。把 AI 当作加速器，不能把工程责任交给 AI。
+
+这一页给出边界：AI 擅长生成候选、归纳信息和补齐重复劳动；但业务规则、权限和数据安全、范围取舍与交付结论必须由人确认。
+
+后续模块将从 PR、Git、CI、资产和可维护性几个角度具体说明如何保留这种判断能力。
+-->

slidev/pages/day6/m10-ai-trends.md

@@ -0,0 +1,236 @@
+# 模块 10：AI Agent 新趋势
+
+<div class="mt-6 text-sm">
+
+AI Agent 已能读取外部资料、触发真实动作、组合工具能力并委托其他 Agent。输入边界、执行门禁、工具服务、能力分发、IDE 接入与跨 Agent 协作，开始形成不同层次的开放协议。
+
+</div>
+
+<div class="grid grid-cols-6 gap-3 mt-9 text-sm text-center">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30"><strong>输入权威</strong><br><span class="text-xs op-70">外部内容不能下指令</span></div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30"><strong>运行时策略</strong><br><span class="text-xs op-70">动作发生时再判断</span></div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><strong>MCP 新扩展</strong><br><span class="text-xs op-70">工具调用走向任务与交互</span></div>
+<div class="p-4 rounded-xl bg-cyan-500/10 border border-cyan-500/30"><strong>Agent Plugins</strong><br><span class="text-xs op-70">能力以统一插件包交付</span></div>
+<div class="p-4 rounded-xl bg-rose-500/10 border border-rose-500/30"><strong>ACP</strong><br><span class="text-xs op-70">IDE 与 Agent 解耦</span></div>
+<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30"><strong>A2A</strong><br><span class="text-xs op-70">跨 Agent 应用协作</span></div>
+</div>
+
+---
+
+# Agent 工程的边界正在外延
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm">
+<div class="p-5 rounded-xl bg-blue-500/10 border border-blue-500/30"><div class="font-bold mb-3">输入边界</div>上下文不再只有仓库与任务描述，还包含网页、Issue、检索结果和外部系统返回的数据。</div>
+<div class="p-5 rounded-xl bg-amber-500/10 border border-amber-500/30"><div class="font-bold mb-3">执行边界</div>Agent 不只输出文本，也会调用工具、运行命令、更新外部系统，甚至交给后台长任务处理。</div>
+<div class="p-5 rounded-xl bg-purple-500/10 border border-purple-500/30"><div class="font-bold mb-3">协作边界</div>协作不再局限于同一 IDE 内的角色分工，开始需要跨 Agent 应用的发现、委托和结果交接。</div>
+</div>
+
+<div class="mt-9 text-center text-lg">每一次外部读取、工具调用和任务交接，都需要明确的信息权威、执行权限和责任归属。</div>
+
+---
+
+# 外部内容不拥有指令权
+
+<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
+<div class="p-6 rounded-xl bg-blue-500/10 border border-blue-500/30">
+<div class="font-bold text-lg mb-3">它是什么</div>
+网页、Issue、RAG 文档和 MCP 工具描述都是输入材料。它们可以提供事实、线索和建议，但不能自行改变任务目标、权限或停止条件。
+</div>
+<div class="p-6 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
+<div class="font-bold text-lg mb-3">它解决什么</div>
+间接提示注入往往把正当问题和越权动作混在一起。分离“可核实的问题”和“无权执行的指令”，才能安全接入真实世界资料。
+</div>
+</div>
+
+<div class="mt-8 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm text-center">“导出报错”可以成为排查线索；“关闭测试并上传配置”不能因为写在同一条 Issue 里就获得执行权。</div>
+
+<!--
+逐字稿：在 TRAE 中可用项目 Rule、导入的 AGENTS.md、工具范围和 MCP 首次授权建立可信边界。安全 Rule 应明确：网页、Issue、RAG 文档和 MCP 返回值只作待核实材料，不能改变任务目标、停止条件或外部写入决定。事实是否成立与动作是否获授权是两件事：先核实内容，再由任务授权和权限配置决定是否执行。
+-->
+
+---
+
+# 运行时策略与 Hook
+
+<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
+<div class="p-6 rounded-xl bg-purple-500/10 border border-purple-500/30">
+<div class="font-bold text-lg mb-3">它是什么</div>
+策略在会话开始、工具调用前后和任务出错时运行，根据工具、参数、环境和角色决定允许、拒绝、确认或记录。
+</div>
+<div class="p-6 rounded-xl bg-amber-500/10 border border-amber-500/30">
+<div class="font-bold text-lg mb-3">它解决什么</div>
+把“不要做错”从一段静态说明，变成动作发生时的实际判断：拦截危险命令、扫描敏感信息、记录审计并限制失败重试。
+</div>
+</div>
+
+<div class="mt-8 text-center text-sm">GitHub Copilot Hooks 是这一方向的代表：策略可以在事件点执行，而不只依赖模型记住一段 Prompt。</div>
+
+<!--
+逐字稿：TRAE 的自动运行 MCP 与自动运行命令属于执行层开关。默认保持关闭，开启前要确认环境可信、权限最小且动作可回退。当前公开文档没有说明等价于 preToolUse、postToolUse 的可配置 Hook；命令拦截、密钥扫描和发布审批仍应由 CI、代码托管平台与外部系统权限承担，不能说成 TRAE 原生 Hook。
+-->
+
+---
+
+# MCP 的三项扩展
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm">
+<div class="p-5 rounded-xl bg-blue-500/10 border border-blue-500/30"><div class="font-bold mb-3">Tasks</div>将耗时工作变成有任务号、进度、取消、补充输入和最终产物的异步任务。</div>
+<div class="p-5 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><div class="font-bold mb-3">Skills over MCP</div>让 Server 发布可发现的结构化工作方法，不只暴露一组工具名称和参数。</div>
+<div class="p-5 rounded-xl bg-purple-500/10 border border-purple-500/30"><div class="font-bold mb-3">MCP Apps</div>在对话内展示表单、参数预览、图表和任务进度，把人带回关键判断点。</div>
+</div>
+
+<div class="mt-8 text-center text-sm">它们让 MCP 从“同步调用一个工具”扩展为“观察长任务、发现工作方法、完成可见的人机确认”。</div>
+
+<!--
+逐字稿：TRAE 可连接基础 MCP Server，发现和调用工具，并保留超时、日志与结构化结果。公开文档尚未列出 Tasks、Skills over MCP、MCP Apps 的原生配置和运行方式；本地 Skill 也不能被说成远程 Skills over MCP。实际采用前，要逐项确认客户端、Server、权限模型和失败语义，而不是只看协议是否发布。
+-->
+
+---
+
+# MCP 正在摆脱会话绑定
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm">
+<div class="p-5 rounded-xl bg-blue-500/10 border border-blue-500/30"><div class="font-bold mb-3">请求自带上下文</div>协议版本、客户端能力与调用信息跟随每次请求，不再依赖先建立一条长期会话。</div>
+<div class="p-5 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><div class="font-bold mb-3">服务可水平扩展</div>任意请求可以路由到任意实例，网关可按方法与工具名进行路由、限流和授权。</div>
+<div class="p-5 rounded-xl bg-purple-500/10 border border-purple-500/30"><div class="font-bold mb-3">状态必须显式交接</div>业务仍可有状态，但状态要以任务号或句柄传递，不能隐含在一条连接里。</div>
+</div>
+
+<div class="mt-9 text-center text-lg">连接可以断开和重连；任务与业务状态必须可见、可恢复、可审计。</div>
+
+<!--
+逐字稿：MCP 2026-07-28 的核心变化是从“双向、有会话的协议”转为“无状态的请求/响应核心”。initialize/initialized 交换和 Mcp-Session-Id 被移除。每个请求都携带协议版本、客户端身份和客户端能力；如果客户端需要预先了解服务能力，可以调用可选的 server/discover。这样一个请求可以落到负载均衡后的任意实例，MCP Server 能像普通 HTTP 服务一样扩展。
+
+无状态不等于业务不能保存状态。规范给出的正确方式是：工具创建一个显式句柄或任务号，再让模型在后续调用中把它带回。例如“导出报表”返回 jobId；查询进度、取消任务和下载产物都以 jobId 为参数。它比把进度藏在某条 SSE 或 WebSocket 连接里更可靠，也让日志、重试、人工接管与审计有明确对象。
+
+这次更新还使 Mcp-Method 和 Mcp-Name 以 HTTP Header 传递，网关、WAF、限流和授权系统不必解析 JSON Body 即可识别调用；工具、提示词和资源列表可以带缓存提示；原来依赖持续双向流的交互改为 Multi Round-Trip Requests。Tasks 成为正式扩展，旧的 HTTP+SSE、Roots、Sampling 和 Logging 进入弃用期。这里不要求记住协议名，关键结论是：远程 MCP 已从“本地脚本的连接方式”走向可路由、可缓存、可扩展的服务基础设施。
+
+TRAE 使用边界：TRAE 使用的是 MCP 客户端。公开资料没有说明其已完整支持 2026-07-28、server/discover、MRTR 或 Tasks 扩展，不能写成已支持。连接一个普通 MCP Server 的基本操作不因服务端升级而自动失效，但生产环境升级时必须以 TRAE 当时实际支持的协议版本、Server 的迁移说明和一次真实工具调用验证为准。若团队自行维护远程 MCP，应在 Server、网关和 SDK 层完成无状态迁移；不要把“TRAE 可以连 MCP”误解为“TRAE 已处理所有服务端扩展”。
+
+资料：MCP Blog《The 2026-07-28 Specification》https://blog.modelcontextprotocol.io/posts/2026-07-28/；MCP Specification https://modelcontextprotocol.io/specification/latest。
+-->
+
+---
+
+# Agent Plugins：把一组能力装进同一个包
+
+<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
+<div class="p-6 rounded-xl bg-cyan-500/10 border border-cyan-500/30">
+<div class="font-bold text-lg mb-3">它是什么</div>
+<div class="font-mono leading-7 text-xs">
+reports-plugin/<br>
+├─ plugin.json<br>
+├─ skills/ &nbsp;&nbsp;&nbsp;&nbsp;工作方法与参考资料<br>
+├─ mcp.json &nbsp;&nbsp;&nbsp;工具与服务连接声明<br>
+└─ com.vendor.client/ &nbsp;&nbsp;客户端扩展
+</div>
+</div>
+<div class="p-6 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
+<div class="font-bold text-lg mb-3">它解决什么</div>
+将相互配合的 Skill 与 MCP Server 按固定目录和清单一起交付。不同客户端不必各自发明目录、清单和连接配置，能力包也不必维护多份分叉版本。
+</div>
+</div>
+
+<div class="mt-8 p-4 rounded-xl bg-slate-500/10 border border-slate-500/30 text-sm text-center">Plugin 只规定“怎么打包”；安装、权限、信任校验、沙箱和界面仍由每个客户端负责。</div>
+
+<!--
+逐字稿：Agent Plugins 1.0.0 是面向 AI Agent 能力包的开放、中立打包规范。2026 年 8 月发布时，核心维护方包括 Amazon、Cursor、Microsoft、OpenAI 和 Vercel，Google 随后作为核心维护方加入。需要如实说明：规范页面当前标注为 Working Draft，不能讲成已经稳定且所有 IDE 都原生支持的事实。
+
+先把四个概念放在不同层次上。Skill 是“怎样完成一类工作”的方法包，内容可以是 SKILL.md、脚本、参考资料和检查单；MCP 是 Agent 与工具、数据或服务在运行时通信的协议；A2A 是独立 Agent 应用之间发现能力、委托任务和交接状态的协议；Agent Plugin 则是把相关的 Skill 与 MCP Server 放进一个可搬运目录的包格式。它不定义任务委托，也不重写 MCP 的工具调用语义，更不定义 Skill 的写法。
+
+对照本课程：第 3 天和第 5 天讲的 Skill 解决“把稳定的方法沉淀下来”；本页补充的是“这些方法怎样和配套工具一起跨客户端交付”。第 3 天、第五天和本模块的 MCP 内容解决“怎样连上并调用工具”；Plugin 中的 mcp.json 只统一描述 Server 的位置、传输类型和配置，MCP 的通信协议和生命周期仍由 MCP 自己定义。A2A 解决“一个 Agent 怎么把任务交给另一个 Agent”，Plugin 不传递任务状态、结果或失败原因；一个 A2A Agent 可以安装 Plugin 来获得自己的 Skill 与 MCP 能力。第 5 天的资产库解决团队内如何治理、验证和演进资产；Plugin 只改善跨客户端的目录与清单可移植性，不能替代版本审查、来源审查和测试夹具。
+
+1.0 的可移植核心刻意很小：根目录必须有 plugin.json；Skill 固定在 skills/ 下；MCP Server 固定在 mcp.json 中；客户端专有能力放在反向域名的扩展目录或 extensions 字段中，其他客户端应忽略它。规范只标准化两类组件：Agent Skills 和 MCP Server。固定位置的好处是客户端不用猜测目录，也能让“某个 MCP Server 启动失败”与“Skill 仍可被加载”相互隔离。
+
+这份规范最容易被误讲。它不是插件市场，也不定义下载、安装或升级流程；不是权限协议，也不定义 OAuth、凭证保存或授权确认；不是安全沙箱，也不证明包可信；不是发现协议，资源发现由 Agentic Resource Discovery（ARD）和 AI Catalog 等上层机制处理。mcp.json 的 header 是可见的包内容，规范明确不能把密钥放进去；远程 Server 的认证、凭证保存和用户确认仍由客户端管理。因此拿到一个 Plugin，不能因为它有统一清单就直接执行其中的命令或连接。
+
+TRAE 使用边界：截至本页资料核对时，Agent Plugins 官方兼容客户端列表列出 Kiro、ChatGPT & Codex、Cursor、VS Code 和 GitHub Copilot，未将 TRAE 列为已支持客户端；TRAE 公开资料也没有可核实的 Plugin 导入或安装说明。因此不能宣称“TRAE 已原生支持 Agent Plugins”。在未获得原生支持前，只能把它当成待审查的能力包：先检查 plugin.json、Skill 内容及每条 mcp.json 配置；对本地命令、参数、环境变量、远程 URL 和权限逐项确认；再按 TRAE 当时实际支持的 Skill 与 MCP 配置方式手工复用其中的独立组件。Plugin 的统一目录不会自动授予任何执行权限。
+
+资料：Google Developers Blog《Agent Plugins package your skills, tools, and more》https://developers.googleblog.com/agent-plugins-package-your-skills-tools-and-more/；Agent Plugins Specification v1.0.0 https://agent-plugins.org/specification；Compatible Clients https://agent-plugins.org/compatible-clients。
+-->
+
+---
+
+# IDE 与 Coding Agent 正在解耦
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm text-center">
+<div class="p-5 rounded-xl bg-blue-500/10 border border-blue-500/30"><div class="font-bold mb-3">IDE / 编辑器</div>负责工作区、文件编辑、Diff 展示、终端入口和人工确认。</div>
+<div class="p-5 rounded-xl bg-rose-500/10 border border-rose-500/30"><div class="font-bold mb-3">ACP</div>统一会话、消息与编码任务交互，让编辑器和 Agent 不必逐对定制集成。</div>
+<div class="p-5 rounded-xl bg-purple-500/10 border border-purple-500/30"><div class="font-bold mb-3">Coding Agent</div>负责理解任务、制定计划、修改代码、调用工具并返回可审查的变更。</div>
+</div>
+
+<div class="mt-8 p-4 rounded-xl bg-slate-500/10 border border-slate-500/30 text-sm text-center">选择 Agent 不必同时接受唯一界面；选择 IDE 也不必被单一 Agent 绑定。</div>
+
+<!--
+逐字稿：ACP 是 Agent Client Protocol，不是 A2A。它标准化的是代码编辑器或 IDE 与 Coding Agent 之间的通信，解决“每个编辑器都要为每个 Agent 单独做集成”的问题。它的定位类似 LSP 对语言服务的作用：编辑器接入兼容 Agent，Agent 接入兼容编辑器，双方可以分别演进。ACP 文档明确其目标是本地和远程场景；本地 Agent 以编辑器子进程运行，通过 JSON-RPC over stdio 通信；远程 Agent 可使用 HTTP 或 WebSocket，但远程场景仍在持续完善。
+
+与本模块其他协议要严格区分。MCP 是 Agent 到工具、数据和服务：例如 Coding Agent 通过 MCP 查询工单或调用测试平台。A2A 是 Agent 到 Agent 应用：例如一个规划 Agent 向独立的审查 Agent 委托任务。Agent Plugins 是能力包：把 Skill 与 MCP Server 按统一目录交付。ACP 则是 IDE 到 Coding Agent：关注会话、变更、Diff 等编码交互。ACP 会尽量复用 MCP 的 JSON 表示，但它不是 MCP 的替代品，也不负责为 Agent 打包工具。
+
+对研发者的意义不是“以后必然换 IDE”，而是评估工具时可以拆开看：IDE 是否提供好的代码浏览、Diff、终端和审批体验；Agent 是否擅长规划、改动、测试与交付。开放客户端协议降低了两者必须绑定采购的可能性，但前提是双方真实实现相同版本与能力集，不能只看宣传名称。
+
+TRAE 使用边界：截至本页资料核对时，ACP 官方文档没有将 TRAE 列为已支持客户端，TRAE 公开资料也没有可核实的 ACP 配置或 Agent 接入说明。因此不能把 TRAE 的现有 Agent 或 Subagent 称作 ACP Agent，也不能提供不存在的配置步骤。未来若 TRAE 宣布 ACP 支持，应先确认它扮演 Client 还是 Agent、支持本地还是远程传输、能够展示哪些变更与确认事件，再用一个只读或低风险任务进行兼容性验证。
+
+资料：Agent Client Protocol《Get Started》https://agentclientprotocol.com/get-started；ACP Protocol https://agentclientprotocol.com/protocol。
+-->
+
+---
+
+# Agent 的输出开始变成交互界面
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm text-center">
+<div class="p-5 rounded-xl bg-blue-500/10 border border-blue-500/30"><div class="font-bold mb-3">Agent</div>输出当前任务需要展示的字段、选项、进度与下一步，而不是直接执行一段界面代码。</div>
+<div class="p-5 rounded-xl bg-cyan-500/10 border border-cyan-500/30"><div class="font-bold mb-3">A2UI</div>用声明式组件蓝图描述界面，可随 Agent 的流式输出逐步更新。</div>
+<div class="p-5 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><div class="font-bold mb-3">宿主应用</div>按自身设计系统渲染原生组件，并决定哪些控件、数据和交互可以出现。</div>
+</div>
+
+<div class="mt-8 p-4 rounded-xl bg-slate-500/10 border border-slate-500/30 text-sm text-center">Agent 决定“现在需要什么交互”；宿主应用决定“允许如何呈现和执行”。</div>
+
+<!--
+逐字稿：A2UI 是 Agent-to-User Interface Protocol。它让 Agent 输出声明式的组件蓝图，而不是输出 HTML、JavaScript 或一张静态图片。宿主应用把蓝图映射为自己允许的原生组件，因此 Web、移动端、桌面端可以各自使用同一份 Agent 输出，同时保持自己的设计系统、主题和交互边界。它特别适合把“请确认参数”“选择一个方案”“展示任务进度”“补充缺失信息”从纯文字对话变为可操作的界面。
+
+它与 MCP Apps 不是同一件事。MCP Apps 中，MCP Server 通过 ui:// 资源提供预构建 HTML，宿主通常放在沙箱 iframe 中运行，远程 Server 对外观与内容有更强控制权；A2UI 中，Agent 只发送组件说明，宿主控制可用组件、样式与渲染，不执行 Agent 下发的界面代码。选择 MCP Apps 的典型情况是“某个工具拥有完整、固定的专属界面”；选择 A2UI 的典型情况是“Agent 针对当前任务动态组织一组跨平台交互”。因此，本模块的 MCP Apps 页面不需要删除，本页讲的是另一条 Agent 到用户界面的协议路径。
+
+也不要把 A2UI 与 AG-UI、A2A 混淆。AG-UI 是 Agent 后端到前端的高频状态同步通道，A2UI 是“应该渲染什么”的内容格式，两者可以配合使用。A2A 管 Agent 应用之间的任务协作，A2UI 消息可以随 A2A 在多 Agent 场景中传递。A2UI 当前资料还提到计划中的 MCP bridge，这不代表每个 MCP Server 或客户端已经支持 A2UI。
+
+TRAE 使用边界：A2UI 需要客户端或业务应用实现对应 Renderer 和组件白名单。TRAE 公开资料没有可核实的 A2UI Renderer、配置入口或 Agent 交互界面扩展说明，因此不能写成 TRAE 已支持 A2UI。TRAE 当前能展示的对话、Diff、终端和 MCP 交互不等同于 A2UI。若未来出现官方支持，应先验证它允许哪些组件、是否执行远程代码、如何限制数据访问和动作确认；在没有这些能力时，A2UI 应作为构建自有业务 Agent 前端时的协议趋势来理解。
+
+资料：A2UI《How Does A2UI Compare?》https://a2ui.org/introduction/agent-ui-ecosystem/；Google Developers Blog《Introducing A2UI》https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/。
+-->
+
+---
+
+# A2A：多 Agent 协作的协议层
+
+<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
+<div class="p-6 rounded-xl bg-blue-500/10 border border-blue-500/30">
+<div class="font-bold text-lg mb-3">它是什么</div>
+多 Agent 协作是多个角色分工和交接任务的广义工作方式。A2A 是其中的协议层，让独立 Agent 应用按标准方式发现彼此、委托工作和返回结果。
+</div>
+<div class="p-6 rounded-xl bg-purple-500/10 border border-purple-500/30">
+<div class="font-bold text-lg mb-3">它解决什么</div>
+跨产品、跨框架协作不再依赖共享所有 Prompt、记忆和工具实现，而是交接身份、能力、任务状态、结果和失败原因。
+</div>
+</div>
+
+<div class="mt-8 p-4 rounded-xl bg-slate-500/10 border border-slate-500/30 text-sm text-center">A2A 管 Agent 到 Agent 的任务协作；MCP 管 Agent 到工具、数据和资源。一个 A2A Agent 可以在内部使用 MCP。</div>
+
+<!--
+逐字稿：TRAE Subagent 是同一产品内的多 Agent 分工，可让角色独立处理任务并交接结构化结果。TRAE 当前没有公开 A2A 配置、Agent Card、远程 Agent 发现或跨厂商委托文档，因此不能把 Subagent 说成 A2A 互操作。无论使用本地 Subagent 还是未来接入 A2A，交接都应先写清目标与非目标、输入与工具范围、结果与验证、停止与交接条件。
+-->
+
+---
+
+# 工程落地的三项前提
+
+<div class="grid grid-cols-3 gap-5 mt-9 text-sm">
+<div class="p-5 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><div class="font-bold mb-3">来源有边界</div>外部内容只能补充事实与线索，不能自行改变任务、权限或停止条件。</div>
+<div class="p-5 rounded-xl bg-amber-500/10 border border-amber-500/30"><div class="font-bold mb-3">执行有门禁</div>每次写入、发布或高风险工具调用，都要有最小权限、确认与可回退条件。</div>
+<div class="p-5 rounded-xl bg-purple-500/10 border border-purple-500/30"><div class="font-bold mb-3">协作可交接</div>跨角色或跨系统协作必须明确任务状态、验证结果、失败原因与责任归属。</div>
+</div>
+
+<div class="mt-9 text-center text-lg">外部内容不能授予权限；工具动作必须有执行门禁；跨 Agent 协作必须交接任务、状态、结果与责任。</div>
+
+<!--
+逐字稿：落地时再回到产品能力核对。TRAE 的 Rule、AGENTS.md、MCP 授权和自动运行开关可支撑来源与执行边界；新版 MCP、事件级 Hook、Agent Plugins、ACP、A2UI 和 A2A 互操作则必须以当时的官方文档和实际环境为准。不要把协议趋势直接当作 IDE 已具备的功能。
+
+资料：MCP 最新规范 https://modelcontextprotocol.io/specification/latest；MCP 2026-07-28 https://blog.modelcontextprotocol.io/posts/2026-07-28/；Agent Plugins Specification https://agent-plugins.org/specification；ACP https://agentclientprotocol.com/get-started；A2UI https://a2ui.org/introduction/agent-ui-ecosystem/；A2A Protocol https://a2a-protocol.org/latest/；GitHub Copilot Hooks https://docs.github.com/en/copilot/concepts/agents/hooks。
+-->

slidev/pages/day6/m11-six-day-retrospective.md

@@ -0,0 +1,221 @@
+# 复盘：六天能力图谱
+
+<div class="mt-6 text-sm">
+
+六天内容只有一条主线：让 AI 参与研发时，团队如何持续获得事实、控制范围、验证行为，并把可靠经验沉淀下来。
+
+</div>
+
+<div class="mt-8 text-sm text-center">
+<div class="inline-block px-4 py-2 rounded-lg bg-blue-500/10 border border-blue-500/30">看懂项目</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-emerald-500/10 border border-emerald-500/30">组织上下文</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-amber-500/10 border border-amber-500/30">处理复杂业务</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-purple-500/10 border border-purple-500/30">沉淀团队资产</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-red-500/10 border border-red-500/30">进入工程闭环</div>
+</div>
+
+<!--
+复盘的目标是让学员看到六天内容之间的依赖关系。后面的 Skill、Agent、CI 和资产治理，都建立在前面的事实、规则和验证能力上。
+-->
+
+---
+
+# 第 1 天：先把陌生项目变成可追溯的事实
+
+<div class="mt-5 text-xs">
+
+| 学到的动作 | 不能跳过的原因 | 交付物 |
+|---|---|---|
+| 找模块、入口与关键对象 | 不知道系统在哪里，就无法讨论改动影响 | 模块认知图、项目结构图 |
+| 追认证、路由、权限和日志链路 | 后台系统的风险常在跨层调用关系中 | 调用链路图 |
+| 区分代码事实、业务事实与推断 | AI 的流畅表达不等于项目真实行为 | 输出校验清单 |
+| 写代码理解报告 | 让团队的理解可被交接和审查 | 代码理解报告 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
+项目理解必须回到文件、函数、调用关系和不确定点，不能停在泛泛总结。
+</div>
+
+<!--
+第一天决定后续所有工作的事实质量。没有项目地图和调用链，后续的 Rule、Plan 和 Review 都会建立在泛泛理解上。
+-->
+
+---
+
+# 第 2 天：把一次会话变成可复用的上下文与规则
+
+<div class="mt-5 text-xs">
+
+| 学到的动作 | 解决的问题 | 交付物 |
+|---|---|---|
+| 用目标、范围、约束、输出、验收组织任务 | 避免 AI 泛泛回答和无边界修改 | 上下文组织清单 |
+| 组合 @workspace、#File、#Code、#Web | 让检索从宽到窄、从事实到细节 | 上下文引用模板 |
+| 先收集证据，再判断和给方案 | 切断幻觉和错误归因 | 证据收集 Prompt |
+| 编写安全、编码、测试与前端 Rule | 让团队隐性习惯变成可执行约束 | rules.md v0.1 与检查单 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+好规则不是“写得严格”，而是能说明何时触发、必须检查什么、不能做什么、如何验收。
+</div>
+
+<!--
+第二天将个人 Prompt 技巧升级成团队上下文和规则资产。它直接为后面的复杂业务设计、Agent 边界和 Review 提供统一语言。
+-->
+
+---
+
+# 第 3 天：从工具功能转向任务编排能力
+
+<div class="mt-5 text-xs">
+
+| 学到的动作 | 关键判断 | 交付物 |
+|---|---|---|
+| 理解 Rule、Cue、模型和 Token 的位置 | 资源要匹配任务风险与信息复杂度 | 成本与任务匹配表 |
+| 区分 Command、Skill、MCP 与 CLI | 高频输入、多步决策和外部工具不是同一问题 | 能力封装决策表 |
+| 设计 Agent 分工 | 输入、输出、验收和停止条件都要明确 | Agent 分工表 |
+| 使用 Browser、文档与 Plan | 先计划、再执行、再记录验证 | 前端验证清单与 Plan 检查项 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+任务越复杂，越需要先把边界显式化，不能因为有 Agent 就跳过计划。
+</div>
+
+<!--
+第三天的重点不在于背产品名称，而在于根据任务类型选择合适的封装和参与深度。复杂任务需要结构化交接，不能靠一个巨大 Prompt 解决。
+-->
+
+---
+
+# 第 4 天：复杂业务先建立控制面，再讨论实现
+
+<div class="mt-5 text-xs">
+
+| 业务难点 | 先产出的控制面 | 为什么不能直接生成代码 |
+|---|---|---|
+| 权限 | RBAC 矩阵、页面/按钮/接口/数据范围方案 | 角色与数据范围是业务事实 |
+| 状态 | 状态流转表、非法流转清单 | 允许和拒绝路径都必须明确 |
+| 审计 | 字段表、前后值、SOP | “记录日志”不足以保证可追溯 |
+| 异常态 | 前后端行为与最小测试集 | 正常流程跑通不代表业务安全 |
+| 看板 | 指标字典、接口契约和验收 | 数字必须有口径、来源和权限范围 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+复杂业务最危险的顺序是“先让 AI 写代码，再回头补权限、状态和审计”。
+</div>
+
+<!--
+第四天强调控制面优先。AI 可以帮助生成初稿、发现遗漏和组织 Review，但权限、状态、审计和指标口径必须由人和证据共同确认。
+-->
+
+---
+
+# 第 5 天：把可靠判断沉淀为可维护资产
+
+<div class="mt-5 text-xs">
+
+| 资产 | 适合保存什么 | 不应保存什么 |
+|---|---|---|
+| Rule | 长期稳定、违反代价高的约束 | 一次任务的临时路径和猜测 |
+| 任务上下文契约 | 输入、输出、证据缺口和停止条件 | 没有来源的项目事实 |
+| Checklist / Template | 固定遗漏点和稳定输出结构 | 所有判断逻辑的重复副本 |
+| Skill | 多步骤、需要证据和验收的工作流 | 只有一句指令的简单需求 |
+| Agent / MCP | 稳定角色、权限边界和外部能力 | 未声明读写性质的工具连接 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-purple-500/10 border border-purple-500/30 text-sm">
+资产化不是把聊天记录保存下来，而是把可复用的判断、边界和验证方式保存下来。
+</div>
+
+<!--
+第五天的核心是区分稳定资产与运行时事实。资产必须有来源、适用范围、输出契约和验证方式，否则会把旧项目结论错误套用到新任务。
+-->
+
+---
+
+# 第 6 天：让 AI 改动进入真实工程闭环
+
+<div class="mt-5 text-xs">
+
+| 工程环节 | AI 可以辅助的工作 | 人必须负责的判断 |
+|---|---|---|
+| PR 与 Git | 归纳 Diff、生成说明、检查范围 | 改动是否该合入、如何回退 |
+| Review | 发现风险、汇总证据缺口、生成问题草稿 | 问题是否成立、优先级与修复决策 |
+| CI | 分类日志、关联配置与 Diff、建议验证命令 | 区分代码缺陷与环境处置 |
+| 证据链 | 整理需求、实现、测试和边界 | 结论能否被当前证据支持 |
+| 资产变更 | 检查引用、夹具和行为变化 | 权限和兼容性是否可接受 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-cyan-500/10 border border-cyan-500/30 text-sm">
+AI 产出必须进入已有的工程审查、验证和责任体系。
+</div>
+
+<!--
+工程闭环是六天课程的最终落点。AI 可以加快信息处理与候选方案生成，但合入、发布和责任不能被一句“AI 已验证”替代。
+-->
+
+---
+
+# 六项能力必须形成闭环
+
+<div class="mt-8 grid grid-cols-3 gap-4 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30"><strong>事实</strong><br><span class="text-xs op-70">代码、配置、日志和业务确认。</span></div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30"><strong>上下文</strong><br><span class="text-xs op-70">目标、范围、约束、输出和验收。</span></div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30"><strong>计划</strong><br><span class="text-xs op-70">影响范围、最小方案、风险和验证。</span></div>
+<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30"><strong>控制面</strong><br><span class="text-xs op-70">权限、状态、审计、异常和指标。</span></div>
+<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30"><strong>验证</strong><br><span class="text-xs op-70">测试、CI、浏览器和人工观察。</span></div>
+<div class="p-4 rounded-xl bg-cyan-500/10 border border-cyan-500/30"><strong>沉淀</strong><br><span class="text-xs op-70">PR、证据链、Rule、Skill 和资产库。</span></div>
+</div>
+
+<!--
+这六项是课程的能力模型。后面的能力不能替代前面的能力：没有事实，计划会虚构；没有控制面，代码会遗漏业务边界；没有验证，资产会积累错误经验。
+-->
+
+---
+
+# 六天里最应该避免的六种误用
+
+<div class="mt-5 text-xs">
+
+| 误用 | 正确替代动作 |
+|---|---|
+| 让 AI 泛泛总结整个项目 | 指定入口、问题、范围和证据格式 |
+| 把模型回答当作业务规则 | 区分代码事实、业务确认、推断与待确认 |
+| 直接接受大范围代码生成 | 先审阅 Plan，选择最小可验证 Diff |
+| 只隐藏前端按钮就认为有权限控制 | 验证页面、按钮、接口和数据范围四层边界 |
+| CI 变红就修改业务代码 | 先定位最早错误，区分代码、依赖、配置和环境 |
+| 把一次有效 Prompt 直接升级为团队标准 | 先验证适用范围、停止条件和代表性夹具 |
+
+</div>
+
+<!--
+这六种误用贯穿整个课程。让学员记住它们，比记住某个具体产品按钮或命令更有长期价值。
+-->
+
+---
+
+# 最终交付不应只有代码
+
+<div class="grid grid-cols-2 gap-4 mt-7 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">项目结构、调用链与事实记录</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">上下文包、Rule、Prompt 和检查单</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">权限、状态、审计、异常与指标控制面</div>
+<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30">Plan、Diff、测试、浏览器与 CI 证据</div>
+<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">PR 说明、Review、修复记录和未覆盖边界</div>
+<div class="p-4 rounded-xl bg-cyan-500/10 border border-cyan-500/30">可验证、可维护、可演进的工程资产</div>
+</div>
+
+<div class="mt-8 text-center text-lg">代码是结果之一；可复用、可验证、可维护的工程资产，才能支撑长期协作。</div>
+
+<!--
+这页把六天各自的交付物收束为一套工程资产。它们能够随代码、PR 或项目知识库留存，帮助下一位维护者理解为什么、改了什么、验证到哪里。
+-->

slidev/pages/day6/m2-pr-template-ai-record.md

@@ -0,0 +1,162 @@
+# 模块 2：标准 PR 说明与 AI 使用记录
+
+<div class="mt-6 text-sm">
+
+PR 是团队协作里最稳定的交付节点。
+
+如果 TRAE 参与了需求拆解、代码修改、测试和 Review，PR 说明里就要能看见这些证据。
+
+</div>
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">需求背景</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">实现说明</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">测试结果</div>
+<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">风险与 AI 记录</div>
+</div>
+
+<!--
+逐字稿：PR 是代码进入协作和评审的稳定节点。这里要保留的是与本次变更有关的事实、证据和风险，而不是完整的 AI 对话。评审者应当能快速看清为什么改、改了什么、验证到哪里，以及还有哪些边界没有确认。
+
+PR 中需要留下的是与变更有关的事实、证据和风险，而不是完整聊天记录。reviewer 应能快速回答：为什么改、改了什么、测了什么、还有什么没有确认。
+-->
+
+---
+
+# PR 模板
+
+<div class="mt-5 text-xs">
+
+```md
+## 需求背景
+<为什么做，本次解决什么>
+
+## 实现说明
+<改了哪些模块、接口、页面、规则>
+
+## 测试结果
+- [ ] 单元测试：
+- [ ] 接口验证：
+- [ ] 浏览器验证：
+- [ ] 手工验收：
+
+## 风险点
+<权限、状态、审计、异常、兼容性、数据范围>
+
+## AI 使用记录
+<TRAE 协助了哪些步骤，哪些建议被采纳，哪些被人工否决>
+
+## 关联资产
+<使用了哪些 rules、任务上下文契约、skills、checklists>
+```
+
+</div>
+
+<!--
+逐字稿：这份模板按评审者的阅读顺序组织。测试没有执行就明确标记为未执行，不能用含糊表述填补验证空白。AI 使用记录也只保留影响实现或判断的建议，以及人工采纳或否决的理由。
+
+模板按 reviewer 的阅读顺序组织。未执行的测试必须如实填“未执行”，不能用模糊描述掩盖测试缺口。AI 使用记录只保留影响决策的建议和人工取舍。
+-->
+
+---
+
+# PR 说明示例
+
+<div class="mt-5 text-xs">
+
+```md
+## 需求背景
+取消已派车任务时，后端必须拒绝空白取消原因。
+
+## 实现说明
+- `OfficialVehicleDispatchServiceImpl.cancel` 在状态写入前加入 `Assert.hasText`。
+- 新增全空白取消原因的 Service 单元测试。
+- 未改前端必填、权限、审计、SQL、派车和行程逻辑。
+
+## 测试结果
+- [x] 单元测试：覆盖空白取消原因的拒绝行为。
+- [ ] 接口、数据库、浏览器和审计验证：按实际执行情况记录。
+
+## 风险点
+统一异常映射、非空正常取消路径和外部调用方需要单独确认。
+```
+
+</div>
+
+<!--
+逐字稿：示例的价值在于它只陈述已经有依据支持的内容。它明确改动放在 Service 的写入前校验，也明确哪些相邻范围没有修改。接口、浏览器和审计验证尚未执行，就必须如实保留为待验证项。
+
+这段示例只记录已有证据支持的变更与测试结果。未执行的接口或浏览器验证必须如实标记，不能为了让 PR 看起来完整而写成通过。
+-->
+
+---
+
+# TRAE 生成 PR 说明的任务上下文契约
+
+<div class="mt-5 text-xs">
+
+```md
+请基于以下材料生成标准 PR 说明：任务背景、
+main 与当前分支的 git diff、实际测试结果、Review 结论、
+使用过的 rules、任务上下文契约、skills。
+
+输出必须包含：需求背景、实现说明、测试结果、风险点、
+AI 使用记录、关联资产。
+
+要求：不要编造测试结果；没有证据的测试项标记“未执行”；
+风险必须具体到模块或文件；不要将训练约束写成客户既有需求。
+```
+
+</div>
+
+<!--
+逐字稿：让 TRAE 起草 PR 说明时，最关键的输入不是一句需求，而是实际 diff、实际测试结果和已有 Review 结论。输出结构要固定，尤其要求未执行项如实标记、风险具体到模块或文件。生成后的每一条事实仍由提交者核对和负责。
+
+这里最关键的是输入必须包含实际 diff 和实际命令结果。TRAE 生成后，提交者仍要对每个事实负责，尤其要检查它有没有擅自补全测试结果或客户业务结论。
+-->
+
+---
+
+# AI 使用记录表
+
+<div class="mt-5 text-xs">
+
+| 环节 | TRAE 做了什么 | 人工判断 | 沉淀内容 |
+|---|---|---|---|
+| 代码理解 | 定位前端必填、取消 API、权限、审计和 Service | 用源码逐条核对 | 影响分析任务上下文契约 |
+| 方案选择 | 建议 Service 作为最终保护边界 | 因状态变更和车辆释放都在此处而采纳 | 状态变更 Rule |
+| 测试设计 | 提出空白输入与正常取消回归点 | 仅将实际执行的空白单测标为通过 | 测试安全网 |
+| 交付说明 | 整理最小 diff、风险和待确认项 | 删除任何无证据的“已验证”表述 | PR 模板 |
+
+</div>
+
+<!--
+逐字稿：AI 使用记录的目的不是统计工具使用次数，而是复盘人机分工。代码理解、方案选择、测试设计和交付说明中，哪些建议被源码或测试支持，哪些被人工否决，都应该留下可复核的理由。反复出现的人工修正，才是以后沉淀 Rule、任务上下文契约或检查清单的依据。
+
+记录 AI 使用不是为了统计对话，而是为了看清它在哪些环节有用、哪些结论仍需人工取证。反复出现的人工修正，才值得升级为 Rule、任务上下文契约或检查清单。
+-->
+
+---
+
+# AI 使用记录不是聊天记录
+
+<div class="mt-5 text-xs">
+
+| 应保留 | 不必保留 |
+|---|---|
+| 影响实现或验证结论的 AI 建议 | 完整对话逐字稿 |
+| 人工采纳或否决建议的理由 | 与本次改动无关的探索 |
+| 关联的 Rule、任务上下文契约、Skill 或检查单 | 无法复查的笼统评价 |
+| 未解决风险和待确认边界 | 把推断包装成已验证结论 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
+好的 PR 说明，让评审者看到工程结论，而不是看到一段 AI 对话。
+</div>
+
+<!--
+逐字稿：AI 使用记录不等于聊天记录。应当保留影响设计、实现或验证结论的建议，保留人工取舍的原因，保留关联资产和未解决风险。与本次改动无关的探索以及无法复核的评价，不会帮助后续评审，也不应成为工程记录的一部分。
+
+本案例中的变更范围、Maven 记录和影响分析都可以回到对应的源码与执行材料核对。关键是不能为了让 PR 看起来完整而填写未发生的验证。
+-->

slidev/pages/day6/m3-ai-code-review.md

@@ -0,0 +1,111 @@
+# 模块 3：AI 变更的 Git 协作与合并控制
+
+<div class="mt-6 text-sm">
+
+TRAE 可以加快修改，但不能绕开 Git 的可追溯、可审查和可回退要求。
+
+AI 参与的改动越多，越要让分支、提交和合并边界保持清楚。
+
+</div>
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">分支范围</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">提交粒度</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">冲突处理</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">合并控制</div>
+</div>
+
+<!--
+逐字稿：AI 可以帮助生成修改，但不能绕过 Git 带来的工程边界。分支、提交和合并控制让每次业务变更都能被理解、审查和回退。AI 参与得越多，越需要这些边界来隔离无关改动和错误假设。
+
+Git 记录的不是操作痕迹，而是可被理解和恢复的业务变更。AI 参与越多，越需要用分支和提交来维持清晰边界。
+-->
+
+---
+
+# 分支和提交要服务于审查
+
+<div class="mt-5 text-xs">
+
+| 做法 | 为什么重要 | 公务用车案例 |
+|---|---|---|
+| 一个分支只解决一个问题 | diff 容易审查和回退 | 取消原因保护不混入无关重构 |
+| 一个提交对应一个可验证动作 | 可定位问题和选择性回退 | 参数保护与对应测试保持一致 |
+| 提交前排除无关文件 | 噪声不会掩盖业务风险 | 构建生成物不应混入业务变更 |
+| 描述真实变更与验证情况 | 后续定位有证据 | 提交信息和 PR 只写有依据的验证 |
+
+</div>
+
+<!--
+逐字稿：分支和提交不是为了制造更多操作步骤，而是为了服务审查和恢复。一个分支解决一个问题，一个提交对应一个可验证动作，无关文件不混入业务变更。这样出现问题时，团队能定位影响，也能有针对性地回退。
+
+公务用车案例的改动范围只包含 Service 参数保护及对应测试。构建生成物和无关格式调整没有纳入提交，这比把所有变动都塞进一个“fix”提交更适合 review 和回退。
+-->
+
+---
+
+# 合并前的四道检查
+
+<div class="mt-5 text-xs">
+
+| 检查点 | 要确认什么 | 当前案例的检查问题 |
+|---|---|---|
+| 范围 | diff 是否只包含已说明的改动 | 是否只有 Service 校验和相应测试？ |
+| 证据 | PR 是否如实标记测试、风险和未确认项 | 是否把 API 或浏览器验证误写为已通过？ |
+| 冲突 | 是否理解双方业务意图 | 是否保留“写入前校验”的顺序？ |
+| 回退 | 是否知道回退哪个提交、是否涉及数据补偿 | 代码改动可以选择性回退；集成数据仍需另行核对 |
+
+</div>
+
+<!--
+逐字稿：合并前先检查四件事：范围是否收敛、测试和风险是否如实、冲突是否理解双方业务意图、回退点是否明确。任何一项说不清，都不应急于合并。TRAE 可以帮助解释 diff 和冲突，但保留哪段逻辑仍由规则与代码证据决定。
+
+这四项中任何一项不清楚，都不应该急于合并。对冲突不确定时，TRAE 可以解释两段逻辑的差异，但保留哪段必须由业务约束和代码证据决定。
+-->
+
+---
+
+# 用 TRAE 审查变更范围
+
+<div class="mt-5 text-xs">
+
+```md
+请检查以下 git diff 是否符合本次变更范围。
+
+目标：取消派车必须由后端拒绝空白取消原因。
+允许修改：Dispatch Service 的参数保护和对应的聚焦测试。
+禁止修改：SQL、权限、菜单、前端页面、派车/行程状态协议、无关格式。
+证据：实际 Maven 定向测试结果；API 和浏览器验证尚未执行。
+
+请输出：直接相关改动、可能无关或风险较高改动、
+合并前必须补充的验证、回退点。
+```
+
+</div>
+
+<!--
+逐字稿：这是一份用于审查变更范围的任务上下文契约，不是让 AI 重新定义业务需求。输入中要写清目标、允许范围、禁止范围和实际验证证据。AI 的输出应识别直接相关改动、可疑改动、合并前缺口和回退点，不能凭空补齐未完成的集成验证。
+
+这份任务上下文契约审查的是范围，不是重新判断业务需求。输入要把允许和禁止范围写清，尤其要提供实际证据，防止模型凭空认定集成验证已完成。
+-->
+
+---
+
+# Git 历史也是工程接口
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">看得懂<br><span class="text-xs op-70">目标与范围一致</span></div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">审得动<br><span class="text-xs op-70">每次改动足够聚焦</span></div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">退得回<br><span class="text-xs op-70">影响与恢复路径清楚</span></div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">查得到<br><span class="text-xs op-70">结论能对应 diff 与证据</span></div>
+</div>
+
+<div class="mt-7 text-sm text-center op-75">
+AI 可以生成改动，Git 负责把改动保留为可理解、可审查的工程历史。
+</div>
+
+<!--
+逐字稿：Git 历史本身也是工程接口。后续维护者应当从提交和 diff 中看懂目标和范围，评审者应能审查每次聚焦改动，出现异常时也能知道退回哪里。AI 生成的是候选变更，Git 保留下来的是可理解、可验证的工程历史。
+
+本案例的真实分支只包含 Service 参数保护及对应的聚焦测试。它说明规则保护已经落在后端最终边界，但单测通过仍不足以得出“接口、数据库、浏览器链路可发布”的结论。
+-->

slidev/pages/day6/m4-ci-failure-loop.md

@@ -0,0 +1,284 @@
+# 模块 4：CI 失败日志分析
+
+<div class="mt-6 text-sm">
+
+CI 失败时，首先要判断失败来自代码、配置、依赖还是运行环境。
+
+TRAE 可提取日志中的直接错误、关联改动和缺失证据；修复前仍要先确认失败来源。
+
+</div>
+
+<div class="grid grid-cols-5 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">代码</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">测试</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">配置</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">依赖</div>
+<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">环境</div>
+</div>
+
+<!--
+逐字稿：CI 失败时，最危险的反应是只看最后一行然后立即改代码。首先要判断失败属于代码、测试、配置、依赖还是运行环境，因为不同来源对应不同证据和处置边界。分类的目的不是贴标签，而是确定下一步该读取什么材料。
+
+日志很长时，不要只看最后一行。先按失败来源分类，才能避免把环境或依赖问题误改成业务代码问题。
+-->
+
+---
+
+# 先按失败来源分类
+
+<div class="mt-5 text-xs">
+
+| 失败来源 | 常见信号 | 首先核对的材料 | 处理边界 |
+|---|---|---|---|
+| 代码与类型 | 编译、lint、类型报错指向具体文件 | diff、调用方、类型定义 | 只修改能解释错误的实现 |
+| 测试断言 | 预期与实际结果不同 | 测试用例、业务规则、测试数据 | 不能只为通过而改断言 |
+| 构建配置 | 脚本、工作流、环境变量缺失 | package/pom、workflow、项目规则 | 先确认配置是否属于本次改动 |
+| 依赖解析 | 版本冲突、锁文件不一致、制品缺失 | lockfile、依赖树、仓库配置 | 区分项目依赖与制品服务异常 |
+| Runner 与环境 | 权限、磁盘、网络、系统工具失败 | Runner 日志、环境配置、重试结果 | 不把环境故障归因到源码 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+分类不是为了快速贴标签，而是为了确定下一份该看的证据。
+</div>
+
+<!--
+逐字稿：一份日志可能出现很多错误，但先找最早阻断流水线的直接错误。然后根据错误信号核对 diff、测试、构建配置、依赖信息或 Runner 日志，判断它来自哪一层。环境和依赖故障没有代码关联证据时，不应推动业务代码修改。
+
+同一份日志可能同时出现多个错误，但应先定位最早阻断流水线的直接错误，再判断其来源。环境或依赖异常通常不应触发业务代码修改。
+-->
+
+---
+
+# 日志必须和 diff 一起读
+
+<div class="mt-5 text-xs">
+
+| 日志现象 | 与 diff 的关系 | 正确结论 |
+|---|---|---|
+| 新增类型错误指向本次修改文件 | 直接命中新增或改动行 | 优先检查该改动与接口契约 |
+| 测试失败在相邻模块，diff 未触及该模块 | 关联尚未建立 | 标记待确认，不把失败直接归因于本次改动 |
+| 依赖下载失败，代码尚未进入编译 | 没有代码执行证据 | 按环境或依赖问题排查 |
+| 同一失败在未改动分支也可复现 | 与本次 diff 无关 | 记录为基线问题或外部问题 |
+
+</div>
+
+<div class="mt-6 grid grid-cols-3 gap-3 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">日志给出直接错误</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">diff 说明影响范围</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">两者共同支持根因</div>
+</div>
+
+<!--
+逐字稿：日志告诉我们直接报错，diff 告诉我们本次改动触及了什么，两者结合才能支持根因判断。错误在相邻模块但 diff 没有触及，或者在未改动分支也能复现，都只能说明需要继续确认。AI 可以建立关联，但关联本身不能直接当成因果。
+
+模型擅长关联日志与变更，但关联不等于因果。只有错误位置、改动范围和执行阶段能互相印证时，才可以形成较强根因判断。
+-->
+
+---
+
+# 代码修复与环境处置要分开
+
+<div class="mt-5 text-xs">
+
+| 场景 | 代码侧动作 | 环境侧动作 | 不应做的事 |
+|---|---|---|---|
+| 类型或编译失败 | 修正实现、类型或调用契约 | 保持环境不变 | 顺手升级无关依赖 |
+| 测试预期冲突 | 复核业务规则和测试数据 | 保留失败记录 | 只改断言让流水线通过 |
+| 依赖解析失败 | 核对锁文件与版本声明 | 核对制品源、缓存和网络 | 修改业务逻辑 |
+| Runner 权限或资源不足 | 不改项目源码 | 调整 Runner 或重试并留存结果 | 误报为代码缺陷 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+修复范围必须和失败来源一致；CI 通过也不应掩盖未验证的业务风险。
+</div>
+
+<!--
+逐字稿：看到流水线失败并不等于业务代码一定有问题。类型和编译失败应回到实现与调用契约，依赖和 Runner 问题则需要回到制品源、缓存、网络或运行环境。代码修复和环境处置要分别记录、分别验证，不能用改业务逻辑来掩盖环境故障。
+
+这张表的目的，是防止“看到 CI 红了就改代码”。代码修复和环境处置的证据、责任边界、验证方式都不同，应分别记录。
+-->
+
+---
+
+# 公务用车模块：已执行的定向测试门禁
+
+<div class="mt-5 text-xs">
+
+```bash
+mvn -pl jeecg-boot-module/jeecg-module-officialvehicle -am \
+  -DskipTests=false \
+  -Dtest=OfficialVehicleDispatchServiceImplTest \
+  -Dsurefire.failIfNoSpecifiedTests=false test
+```
+
+| 项目事实 | 该命令支持的结论 | 不能外推的结论 |
+|---|---|---|
+| 公务用车模块启用了 Maven Surefire 测试 | 模块依赖与指定 Service 用例能够被执行 | 接口、数据库、浏览器与审计链路已验证 |
+| 用例传入全空白取消原因 | `cancel` 会在状态写入前拒绝空白原因 | 非空正常取消路径已经回归 |
+| 2026-08-06 记录为 `BUILD SUCCESS`，1 项用例零失败 | 本次定向 Service 验证通过 | 全模块或生产可发布 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+可执行命令、实际结果和结论边界一起保存，才构成一项可复核的质量门禁证据。
+</div>
+
+<!--
+逐字稿：这里不是假设一条流水线，而是使用本项目已经执行过的 Maven 命令。它定向运行公务用车模块中的 Service 测试，验证全空白取消原因会在状态写入前被拒绝。记录中的 BUILD SUCCESS 只支持这一项定向验证；接口、数据库、浏览器和审计链路没有执行，就不能写成已通过。
+
+这类命令可以成为 CI 的测试门禁，但是否由某条流水线调用，仍应以项目实际工作流配置为准。证据强度取决于实际执行的命令和结果，而不是门禁名称。
+-->
+
+---
+
+# 真实失败案例：Maven 本地仓库无写入权限
+
+<div class="mt-5 grid grid-cols-2 gap-4 text-xs">
+
+<div>
+
+```text
+[WARNING] Failed to write tracking file
+$HOME/.m2/repository/.../resolver-status.properties
+
+[ERROR] java.io.FileNotFoundException
+(Operation not permitted)
+[ERROR] BUILD FAILURE
+```
+
+</div>
+
+<div>
+
+| 判断项 | 本次结论 |
+|---|---|
+| 首个直接错误 | Maven 更新本地仓库跟踪文件时被系统拒绝 |
+| 失败来源 | 本地环境 / 文件权限 |
+| 与业务 diff 的关联 | 未建立源码关联证据 |
+| 正确处置 | 恢复 Maven 仓库写入条件，保留日志后重跑 |
+| 不应做的事 | 修改派车 Service、测试断言或业务状态逻辑 |
+
+</div>
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+构建失败发生在依赖元数据写入阶段时，不能据此推断公务用车业务代码存在缺陷。
+</div>
+
+<!--
+逐字稿：这段 Maven 失败记录来自实际保留的训练材料。最早的直接错误是本地 .m2 仓库的 resolver-status.properties 无法写入，错误信号是 Operation not permitted。它发生在 Maven 处理依赖元数据时，没有指向派车 Service 或测试源码，因此结论应当是环境和文件权限问题，而不是修改业务代码。
+
+正确做法是保留原始日志，恢复 Maven 仓库的写入条件后重跑同一命令。CI 排障的价值就在于把“红色结果”分解为可被证据支持的处置边界。
+-->
+
+---
+
+# CI 分析任务上下文契约
+
+<div class="mt-5 text-xs">
+
+```md
+请分析以下 CI 失败日志。
+
+输入材料：CI 日志、相关 diff、package/pom/workflow 配置、锁文件、项目 rules。
+
+请输出：
+1. 首个失败阶段与原始错误；2. 失败来源分类；
+3. 与 diff 的关联证据；4. 有依据的根因判断；
+5. 需要查看的文件或环境信息；6. 候选处置方案；7. 验证命令；
+8. 是否适合沉淀为规则或检查清单。
+
+要求：先解释失败原因，再给方案；不能只根据最后一行日志下结论；
+区分代码修复与环境处置；证据不足时标记待确认。
+```
+
+</div>
+
+<!--
+逐字稿：让 TRAE 分析 CI 时，输入至少包含失败日志、相关 diff、构建配置和项目规则。输出先给出最早失败阶段和原始错误，再说明失败来源、关联证据、候选处置与验证命令。证据不足时必须标记待确认，不能依据最后一行日志直接给出修复结论。
+
+输入尽量同时包含日志、相关 diff、构建配置和项目规则。没有这些上下文，模型很难区分源码、依赖和环境问题。候选方案必须落到具体文件或可复现的处置步骤。
+-->
+
+---
+
+# CI 修复记录
+
+<div class="mt-5 text-xs">
+
+| 字段 | 内容 |
+|---|---|
+| 失败阶段 | lint / typecheck / test / build / dependency / environment |
+| 原始错误 | 日志中的直接报错，不改写 |
+| 失败来源 | 代码、测试、配置、依赖、Runner 或外部服务 |
+| diff 关联 | 命中改动 / 无关联证据 / 待确认 |
+| 根因 | 支持判断的日志、配置或代码证据 |
+| 处置范围 | 代码修复或环境处置，涉及哪些位置 |
+| 验证命令 | 本地或 CI 重新执行命令 |
+| 结果 | 通过 / 未通过 / 待确认 |
+| 资产沉淀 | rule / checklist / 任务上下文契约 / example / 不沉淀 |
+
+</div>
+
+<!--
+逐字稿：CI 修复记录要把原始错误、失败来源和根因分开写。原始错误来自日志，失败来源是分类判断，根因需要由日志、配置或代码共同支撑。这样沉淀的是下一次诊断的方法，而不会把一次偶然有效的修复动作误当成通用结论。
+
+记录要区分原始错误、失败来源和根因。这样下次面对相似日志时，才能复用诊断方法，而不是错误复用某一次的修复动作。
+-->
+
+---
+
+# CI 质量门禁分别覆盖什么？
+
+<div class="mt-5 text-xs">
+
+| 门禁 | 作用 | 不能替代什么 |
+|---|---|---|
+| lint | 保证基础格式和规范 | 业务规则审查 |
+| typecheck | 提前发现接口和类型不匹配 | 运行时行为验证 |
+| unit test | 保护核心逻辑 | 完整集成链路 |
+| coverage | 发现测试覆盖缺口 | 测试质量判断 |
+| manual checklist | 覆盖权限、审计、状态和页面验收 | 可重复的自动化验证 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+质量门禁不是越多越好，而是每道门禁都要清楚自己覆盖和不覆盖什么。
+</div>
+
+<!--
+逐字稿：每一道 CI 门禁只覆盖一类问题。lint 不能替代业务规则审查，类型检查不能替代运行时验证，单元测试也不能替代完整集成链路和人工验收。质量门禁的价值不在数量，而在于每一项通过时，我们知道它能支持什么结论、又不能支持什么结论。
+
+不同门禁支撑不同强度的结论。重点是避免以某一种通过结果替代全部质量判断。
+-->
+
+---
+
+# 一条 CI 结论应当写清什么？
+
+<div class="mt-5 text-xs">
+
+| 信息 | 说明 |
+|---|---|
+| 失败阶段 | lint、类型检查、测试、构建、依赖或环境 |
+| 原始错误 | 保留日志中的直接报错，不提前改写 |
+| diff 关联 | 说明是否命中本次改动及依据 |
+| 根因判断 | 说明对应的配置、代码或环境依据 |
+| 处置范围 | 只指出确实需要调整的位置 |
+| 验证方式 | 使用可重复的命令或 CI 结果确认 |
+| 结论边界 | 证据不足时明确标记待确认 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+先区分直接错误、失败来源和根因，再决定是否修改代码。
+</div>
+
+<!--
+逐字稿：一条可审查的 CI 结论需要让读者回到原始材料复核。它应说明失败阶段、原始错误、与 diff 的关系、根因依据、处置范围和重跑验证方式。证据还不足时，最准确的结论就是待确认，而不是猜一个看似完整的原因。
+
+一条可审查的 CI 结论，需要让读者回到日志、diff、配置或重跑结果中核对。结论没有证据时，应保留为待确认项。
+-->

slidev/pages/day6/m5-asset-governance.md

@@ -0,0 +1,149 @@
+# 模块 5：共享资产的版本与兼容性
+
+<div class="mt-6 text-sm">
+
+Rule、任务上下文契约、Skill、自定义 Agent 和 MCP 契约一旦被共享使用，就会影响后续任务的判断与行为。
+
+共享资产治理要明确资产变更后的可用范围、引用迁移与旧版本退出方式。
+
+</div>
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">版本</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">兼容</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">迁移</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">回退</div>
+</div>
+
+<!--
+逐字稿：第五天处理的是资产如何设计以及如何验证自身边界。第六天关心的是资产已经被共享使用后，发生变化时如何识别影响、处理引用、完成迁移和保留回退能力。它们的差别不在资产类型，而在验证对象和协作场景。
+
+第五天已经解决“资产怎么写、怎么验证边界”。本模块只讨论资产进入共享使用后，内容变化如何作为工程改动被控制。
+-->
+
+---
+
+# 哪些资产变更属于行为变更？
+
+<div class="mt-5 text-xs">
+
+| 资产 | 变更示例 | 可能改变的行为 |
+|---|---|---|
+| Rule | 增加必须检查的前置条件 | Agent 的允许范围和停止条件 |
+| 任务上下文契约 | 删除一个必填输入字段 | 输出是否仍有足够事实基础 |
+| Skill | 调整步骤或输出 Schema | 下游任务能否继续消费结果 |
+| 自定义 Agent | 增加工具或修改默认指令 | 可访问的能力和风险边界 |
+| MCP 契约 | 更改读写标识或错误语义 | 调用权限与失败后的处置 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+只要会改变 Agent 的输入、判断、输出或权限，就不应把它当成普通文案修改。
+</div>
+
+<!--
+逐字稿：判断资产改动是否需要认真控制，不看它是 Markdown 还是配置文件，而看它会不会改变任务行为。只要改动影响输入、判断顺序、输出结构、权限或停止条件，就属于行为变更。即使只删除一条输入要求，也可能让模型在事实不足时继续输出结论。
+
+判断是否需要版本控制，不看文件格式，而看它是否改变运行时行为。即使只改一行任务上下文契约，也可能删除了关键证据约束。
+-->
+
+---
+
+# 版本号应表达使用边界
+
+<div class="mt-5 text-xs">
+
+| 变更类型 | 使用建议 | 对既有调用方的要求 |
+|---|---|---|
+| 仅修正文案，不改变输入输出或约束 | 小版本 | 保持原有验证夹具通过 |
+| 增加可选字段或补充反例 | 小版本，并说明新增行为 | 检查是否需要提供新材料 |
+| 修改必填输入、输出结构、权限或停止条件 | 新版本边界 | 明确迁移方式和不兼容点 |
+| 移除能力或结束支持 | 弃用版本 | 保留替代资产和退出期限 |
+
+</div>
+
+<!--
+逐字稿：版本号的作用不是追求某种命名形式，而是帮助使用者判断能否直接替换。只改表达且不改变约束，可以在小版本内验证；一旦修改必填输入、输出结构、权限或停止条件，就必须明确新的使用边界和迁移方式。使用者最需要知道的是这次升级会不会破坏已有任务。
+
+版本号的意义是帮助使用者判断能否直接替换。重点不是采用某一套固定命名规则，而是让不兼容变化有明确边界。
+-->
+
+---
+
+# 兼容性说明的最小字段
+
+<div class="mt-5 text-xs">
+
+| 字段 | 要回答的问题 |
+|---|---|
+| 资产与版本 | 当前使用的是哪一份可识别资产？ |
+| 适用范围 | 面向哪些项目、任务或技术栈？ |
+| 行为变化 | 输入、输出、约束、工具权限中变了什么？ |
+| 不兼容点 | 哪些旧引用、模板或 Agent 不能直接继续使用？ |
+| 迁移方式 | 使用者需要替换什么、补充什么或调整什么？ |
+| 回退条件 | 遇到何种结果时应回到哪个稳定版本？ |
+| 验证证据 | 哪些夹具、测试或实际记录支持本次变化？ |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+兼容性说明服务于正确替换，不是为了增加文档数量。
+</div>
+
+<!--
+逐字稿：每份共享资产都应附带最小兼容性说明。它要回答当前版本和适用范围是什么，行为变了什么，哪些旧引用不能继续使用，怎样迁移，以及异常时回退到哪里。没有这些信息，使用者无法判断升级风险，只能靠试错。
+
+如果资产没有说明不兼容点和迁移方法，使用者无法安全升级。说明应与资产本身一起被审查和版本化。
+-->
+
+---
+
+# 弃用不是删除旧文件
+
+<div class="mt-5 text-xs">
+
+| 需要保留的信息 | 目的 |
+|---|---|
+| 被替代的版本与适用范围 | 识别历史引用，不误用旧能力 |
+| 替代资产及目标版本 | 提供明确迁移方向 |
+| 不再适用的原因 | 防止未来又恢复同一错误做法 |
+| 已知引用位置 | 便于逐项替换与复核 |
+| 回退条件与稳定版本 | 变更异常时能够恢复已验证行为 |
+
+</div>
+
+<div class="mt-6 grid grid-cols-2 gap-3 text-sm">
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">直接删除：历史引用失去解释</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">明确弃用：新旧边界仍可追溯</div>
+</div>
+
+<!--
+逐字稿：弃用不是简单删除旧文件，而是停止把旧版本作为默认选择。旧版本的适用范围、替代资产、已知引用位置和稳定回退点仍要保留，才能解释历史任务并指导迁移。对于有引用关系的 Skill、Agent 和 MCP 契约，这些信息尤为关键。
+
+弃用的重点是停止默认使用，而不是抹去历史。对于存在引用关系的 Skill、Agent 和 MCP 契约，替换目标和回退点尤其重要。
+-->
+
+---
+
+# 版本发布前需要确认什么？
+
+<div class="mt-5 text-xs">
+
+| 确认项 | 要回答的问题 | 形成的版本结论 |
+|---|---|---|
+| 当前稳定版本 | 哪个版本仍可作为已知可用的回退点？ | 明确 source version |
+| 目标版本边界 | 新版本改变了哪些使用前提与适用范围？ | 明确 target version |
+| 使用者与引用 | 哪些 Rule、Skill、Agent、MCP 或模板仍依赖旧版本？ | 明确迁移清单 |
+| 退出与回退 | 旧版本何时停止默认使用，异常时回到哪里？ | 明确弃用与恢复路径 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+模块 5 解决“发布哪个版本、谁需要迁移、出现异常退回哪里”；单次资产 diff 的验证证据由模块 8 处理。
+</div>
+
+<!--
+逐字稿：共享资产的版本治理，重点是版本选择和使用者迁移。发布前先识别当前稳定版本、目标版本的新边界、仍在引用旧版本的使用者，以及弃用和回退方式。这样可以决定谁能直接替换、谁必须迁移、异常时回到哪个稳定点。
+
+这里不展开一条资产改动要怎样跑夹具或审查 diff。那是模块 8 的工作：它验证本次变化本身是否有充分的工程证据。两者的边界应当分清。
+-->

slidev/pages/day6/m6-onboarding-rollout.md

@@ -0,0 +1,207 @@
+# 模块 6：变更证据链与可追溯说明
+
+<div class="mt-6 text-sm">
+
+AI 可以帮助定位和实现，但不能替代研发交付中的说明责任。
+
+一次改动是否值得合入，取决于阅读者能否快速判断：改了什么、为什么改、验证到哪里、还存在哪些边界。
+
+</div>
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">目标</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">范围</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">证据</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">边界</div>
+</div>
+
+<!--
+逐字稿：这一模块讨论技术交付为什么必须可追溯。一次改动能否被准确理解，取决于读者能否回答四个问题：目标是什么，范围到哪里，哪些结果已有证据，哪些边界仍未确认。AI 可以协助整理这些信息，但不能替代对每项结论的说明责任。
+
+这一模块强调的是技术交付的可追溯性。四项信息分别回答：解决什么问题、修改到哪里、哪些行为已被证实、哪些路径仍不能下结论。
+-->
+
+---
+
+# PR 模板不等于证据链
+
+<div class="mt-5 text-xs">
+
+| PR 模板解决什么 | 证据链解决什么 |
+|---|---|
+| 让评审者快速阅读改动说明 | 让每条结论回到可核对的事实 |
+| 组织目标、实现、测试和风险 | 关联需求、diff、测试、CI、日志与人工观察 |
+| 呈现本次交付 | 支撑结论强度与后续排查 |
+| 可以由 AI 协助起草 | 必须由真实记录持续校验 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+PR 是阅读入口；证据链是结论能够被复核的依据。
+</div>
+
+<!--
+逐字稿：PR 模板解决的是如何让评审者快速阅读，证据链解决的是每句话凭什么成立。模板组织目标、实现、测试和风险，证据链把它们关联回需求、规则、diff、测试、CI、日志和实际观察。两者互相配合，但不能用写好了 PR 模板来代替真实证据。
+
+模块 2 已讲 PR 的写法。本模块继续追问其中每个结论凭什么成立，因此不重复讲模板字段。
+-->
+
+---
+
+# 一条变更证据链包含什么？
+
+<div class="mt-5 text-xs">
+
+| 证据节点 | 能支持的判断 | 不能替代的判断 |
+|---|---|---|
+| 需求与规则 | 改动目标、约束和非目标 | 实现已正确运行 |
+| diff 与代码阅读 | 修改范围、调用关系与关键分支 | 线上或全链路行为 |
+| 自动化测试 | 对应方法、接口或场景的行为 | 未覆盖路径的行为 |
+| CI 结果与日志 | 构建、检查和已运行用例的结果 | 所有环境和业务风险 |
+| API、浏览器或人工观察 | 特定环境下的真实交互结果 | 未观察到的条件组合 |
+| 已知边界 | 仍需确认的依赖与缺口 | 已完成验证的替代结论 |
+
+</div>
+
+<!--
+逐字稿：证据链不是要求每次都做完所有验证，而是要说明现有证据能支持到哪里。需求和规则确定目标，diff 支持范围判断，自动化测试和 CI 支持已运行场景，实际观察补充具体环境结果。每一类证据都有边界，不能替代尚未覆盖的结论。
+
+证据链不是要求所有节点都必须存在，而是明确已有何种证据、它能支持到哪里、还缺少什么。不同场景可采用不同组合。
+-->
+
+---
+
+# 用证据地图连接结论
+
+<div class="mt-7 text-sm text-center">
+
+<div class="inline-block px-4 py-2 rounded-lg bg-blue-500/10 border border-blue-500/30">需求与规则</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-emerald-500/10 border border-emerald-500/30">diff 与关键代码</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-amber-500/10 border border-amber-500/30">测试与 CI</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-purple-500/10 border border-purple-500/30">技术结论</div>
+
+</div>
+
+<div class="mt-9 grid grid-cols-3 gap-3 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">每个结论都能回指来源</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">每项证据都有适用边界</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">缺口不能被推断补全</div>
+</div>
+
+<!--
+逐字稿：可以把证据地图理解为每个重要结论的来源图。向左能回到需求、规则和关键代码，向右能回到测试、CI 或实际观察。只要某个结论无法连接到这些材料，它就应当被降级为假设或待确认项。
+
+证据地图不是额外流程图，而是一种审查视角：任何重要结论都应能向左回到需求、规则和实现，向右回到验证结果。
+-->
+
+---
+
+# 技术结论要和证据强度匹配
+
+<div class="mt-5 text-xs">
+
+| 信息类别 | 可以形成的结论 | 常见误区 |
+|---|---|---|
+| 代码阅读 | 已定位到调用入口、状态写入点或权限判断 | 把源码推断当作线上运行结论 |
+| 实际变更 | 本次修改了哪些文件、条件和分支 | 用“优化”“完善”等词掩盖改动范围 |
+| 自动化验证 | 已覆盖某个方法、接口或用例 | 用局部测试替代全链路验证 |
+| 待确认事项 | 业务规则、外部调用、环境差异仍需核对 | 用“应该没有影响”替代事实 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+证据能支持多大的结论，就只写多大的结论。
+</div>
+
+<!--
+逐字稿：技术结论的强度必须匹配证据强度。代码阅读只能说明调用入口或状态写入位置，定向测试只能说明被覆盖的方法或场景，不能外推为线上或全链路结论。没有事实支持时，写清待确认项比写一句“应该没有影响”更专业。
+
+源码阅读可以支持调用关系判断，不能替代线上行为；一个定向单测能支持对应方法的行为，不能代替浏览器、数据库、审计等整条链路的结论。
+-->
+
+---
+
+# 证据丢失时，结论也会失效
+
+<div class="mt-5 text-xs">
+
+| 缺失的证据 | 常见后果 | 正确处理 |
+|---|---|---|
+| 原始 CI 日志 | 无法判断失败来自代码还是环境 | 保留失败阶段、原始错误与关联链接 |
+| 已执行命令与结果 | “已测试”无法复核 | 记录命令、环境和结果摘要 |
+| 需求或规则依据 | 不清楚为什么改、是否越界 | 关联明确的约束与非目标 |
+| diff 与关键位置 | 无法核对实际影响范围 | 说明模块、入口和关键条件 |
+| 未覆盖边界 | 被误解为全量验证 | 明确写出待确认项和原因 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+没有证据的“已完成”，在工程上等同于不可审查的结论。
+</div>
+
+<!--
+逐字稿：证据一旦丢失，结论就失去复核基础。没有原始 CI 日志，无法区分代码和环境问题；没有执行命令和结果，“已测试”就无法追溯；没有未覆盖边界，局部验证很容易被误解为全量验证。我们不需要保存所有过程，但需要保存支撑关键判断的最小事实集。
+
+这页强调记录的最低粒度：不需要保存完整聊天过程，但应保存足以复核关键结论的事实。
+-->
+
+---
+
+# 一份可审查的改动说明
+
+<div class="mt-5 text-xs">
+
+```md
+## 改动目标
+解决什么业务问题或风险，并关联需求或规则依据。
+
+## 实现范围
+涉及的模块、入口和关键判断；明确未修改的相邻范围。
+
+## 验证证据
+已执行的测试、检查项、CI 或实际观察，以及对应结果。
+
+## 已知边界
+尚未覆盖的场景、依赖的前提和需要业务确认的事项。
+```
+
+</div>
+
+<div class="mt-6 grid grid-cols-2 gap-3 text-sm">
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">避免：功能已完成、已充分测试</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">写清：已覆盖范围与未覆盖范围</div>
+</div>
+
+<!--
+逐字稿：一份可审查的改动说明至少包含目标、实现范围、验证证据和已知边界。它不靠“已完成”或“已充分测试”这种笼统表述制造确定感，而是明确写出已覆盖和未覆盖的场景。这个结构既可以用于 PR，也可以用于缺陷修复和后续排查。
+
+这四段内容可以写进 PR、变更记录或缺陷修复说明。重点不是固定格式，而是每一段都能被代码、测试记录或明确的待确认项支撑。
+-->
+
+---
+
+# 让 AI 产出成为工程知识
+
+<div class="mt-5 text-xs">
+
+| 只保留对话 | 留下可追溯说明 |
+|---|---|
+| 结论散落在窗口和临时文件里 | 关键结论随代码或 PR 一起保存 |
+| 难以判断 AI 建议是否被采纳 | 清楚说明人工选择了什么、舍弃了什么 |
+| 后续排查需要重新理解上下文 | 可直接定位目标、范围、证据和边界 |
+| 相同问题容易重复分析 | 可复用判断方式，但重新核对项目事实 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+AI 的价值不止是更快产出代码，也包括留下经得起复核的技术结论。
+</div>
+
+<!--
+逐字稿：只有对话记录并不会自动形成工程知识，因为结论会散落在窗口和临时文件中。真正可复用的是能够和代码、PR、测试与变更记录对应的技术结论，以及人工采纳或舍弃建议的理由。这样下一次遇到相似问题时，复用的是可靠判断结构，而不是上一段对话的记忆。
+
+对话记录是过程材料，不能天然成为工程知识；能够与代码、PR、测试和变更记录对应的结论，才可以被后续维护者可靠使用。
+-->

slidev/pages/day6/m7-maintainability-review.md

@@ -0,0 +1,179 @@
+# 模块 7：AI 改动的可演进性审查
+
+<div class="mt-6 text-sm">
+
+业务行为通过验证，只说明本次任务得到了正确结果。
+
+可演进性关心的是下一次规则变化时，能否找到唯一入口、控制影响范围、替换依赖并准确定位回归。
+
+</div>
+
+<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">修改入口</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">单一权威</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">依赖隔离</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">回归定位</div>
+</div>
+
+<!--
+逐字稿：业务行为通过验证，只能说明本次任务得到了正确结果。可演进性继续追问下一次规则变化时，我们能否快速找到入口、控制影响范围、替换依赖并定位回归。它不重复业务正确性审查，而是降低下一次修改的成本和风险。
+
+本模块不重新审查权限、状态、审计等业务正确性，而是检查代码在后续变化中的定位成本和修改风险。
+-->
+
+---
+
+# 四类会放大后续修改成本的风险
+
+<div class="mt-5 text-xs">
+
+| 风险 | 典型表现 | 更好的处理 |
+|---|---|---|
+| 修改入口分散 | 一个业务变化要在多个页面、接口或服务中同步修改 | 明确唯一的规则入口和调用边界 |
+| 平行规则 | 同一校验在多个位置各自维护一份 | 让关键规则只有一个权威实现 |
+| 隐藏依赖 | 逻辑依赖环境、全局状态或外部服务却不可见 | 把依赖显式注入、记录或隔离 |
+| 回归难定位 | 失败只能靠全项目搜索和猜测 | 保留可观察结果、场景夹具与最小影响范围 |
+
+</div>
+
+<!--
+逐字稿：可演进性并不等于过度抽象。真正需要避免的是规则入口分散、同一约束维护多份副本、依赖隐藏在环境或全局状态中，以及失败后只能靠全局搜索猜测原因。更好的实现让关键规则有权威位置，让依赖和回归场景能够被看见和定位。
+
+这里的关注点不是要求抽象越多越好，而是让下一次变化能从清晰入口开始，而不是在多个副本和隐含依赖中猜测。
+-->
+
+---
+
+# 从“本次通过”到“下次可改”
+
+<div class="mt-5 text-xs">
+
+| 本次交付已确认 | 可演进性还要确认 |
+|---|---|
+| 当前行为符合预期 | 下一次规则变化从哪里修改最清楚 |
+| 本次 diff 已通过构建与测试 | 影响范围能否被调用关系和夹具限制 |
+| 新逻辑放进了可运行的位置 | 关键规则是否有唯一权威位置 |
+| 用例覆盖当前结果 | 失败时能否回到具体场景和依赖定位 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+可演进的改动，不是为未来过度设计，而是不给下一次变化留下多份解释。
+</div>
+
+<!--
+逐字稿：功能验证与可演进性是互补关系。前者证明当前行为符合预期，后者保证未来发生规则变化时，不需要在多个位置修改同一含义，也不会难以缩小回归范围。可演进的改动不是提前设计所有未来，而是不给下一次变化留下多份解释。
+
+功能验证和可演进性互补。前者证明当前结果，后者降低未来修改与回归的定位成本。
+-->
+
+---
+
+# 可演进性审查的四个问题
+
+<div class="grid grid-cols-2 gap-4 mt-8 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">规则变化时，第一处应修改哪里？</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">关键约束是否只有一个权威实现？</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">外部依赖能否替换、观察或明确失败？</div>
+<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">回归能否缩小到具体场景、diff 与依赖？</div>
+</div>
+
+<div class="mt-7 text-sm text-center op-75">
+审查的目标，是让 AI 生成的改动成为下一次可靠修改的起点。
+</div>
+
+<!--
+逐字稿：这四个问题可以作为审查 AI 改动的最小检查框架。规则变化时第一处改哪里，关键约束是否有唯一权威位置，外部依赖能否替换或观察，回归能否缩小到具体场景。能够回答这些问题，AI 生成的改动才不只是一次性交付，而会成为下一次可靠修改的起点。
+
+这四个问题将可维护性从泛泛的代码质量讨论，收敛到规则入口、权威位置、依赖边界和回归定位四项工程能力。
+-->
+
+---
+
+# 公务用车案例：规则入口与状态写入相邻
+
+<div class="mt-5 text-xs">
+
+| 已读取的实现事实 | 对后续修改的意义 |
+|---|---|
+| `OfficialVehicleDispatchServiceImpl.cancel` 首行使用 `Assert.hasText` 校验取消原因 | 取消原因规则有明确的后端最终保护入口 |
+| 同一方法随后读取派车单、校验 `DISPATCHED` 状态、写入取消状态与原因，并释放车辆 | 规则与其保护的状态写入相邻，影响范围容易阅读 |
+| `OfficialVehicleDispatchServiceImplTest` 直接传入全空白原因并断言异常 | 规则变化可以从同一测试文件开始定位回归 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+下一次调整“取消原因”规则时，应先从 Service 与这项聚焦测试开始；不应在页面、Controller 和 Service 中维护多份独立规则。
+</div>
+
+<!--
+逐字稿：可维护性必须回到实际代码。当前公务用车案例中，取消原因的后端保护在 OfficialVehicleDispatchServiceImpl 的 cancel 方法首行，紧邻后续的状态校验、取消状态写入和车辆释放。对应的单元测试直接传入全空白原因并断言异常。
+
+因此下一次调整取消原因规则，第一处应查看 Service 和同一测试文件。页面提示和 Controller 参数接收可以改善体验或协议，但不应成为与 Service 平行、各自演化的业务规则副本。
+-->
+
+---
+
+# 案例结论：已获得的可维护性证据
+
+<div class="grid grid-cols-2 gap-4 mt-6 text-xs">
+
+<div>
+
+<div class="font-bold text-emerald-500 mb-3">已经由源码与测试支持</div>
+
+| 证据 | 可形成的结论 |
+|---|---|
+| 本次训练分支仅改动 Service 参数保护和对应测试 | 改动范围聚焦，未混入页面、SQL 或状态协议调整 |
+| 空白原因在读取派车单与写状态前被拒绝 | 无效输入不会进入后续状态变更路径 |
+| 定向 Maven 测试记录为成功 | 该 Service 场景具备可重复的回归起点 |
+
+</div>
+
+<div>
+
+<div class="font-bold text-amber-500 mb-3">尚不能由现有材料证明</div>
+
+| 缺少的证据 | 不能写成的结论 |
+|---|---|
+| 取消接口的 HTTP / 统一异常验证 | 前端会收到何种错误码和提示 |
+| 非空正常取消的集成验证 | 派车、车辆状态与审计已完整回归 |
+| 浏览器与数据库观察记录 | 页面交互和持久化链路已通过 |
+
+</div>
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
+可维护性审查也要按证据说话：明确规则入口与回归起点，不把局部验证扩大成全链路结论。
+</div>
+
+<!--
+逐字稿：这一页把可维护性判断和证据边界放在一起。本次分支的实际改动集中在 Service 参数保护和对应测试，空白原因会在读取派车单与状态写入前被拒绝，定向 Maven 测试也已成功。这些是已经成立的结论。
+
+但现有材料没有执行取消接口的 HTTP 异常映射、非空正常取消的集成路径、浏览器或数据库观察，因此不能把这一条 Service 测试扩大成全链路已通过。工程上的克制，正是维护成本可控的基础。
+-->
+
+---
+
+# 何时需要重构，何时保持聚焦？
+
+<div class="mt-5 text-xs">
+
+| 观察到的证据 | 适合的处理 | 不应做的事 |
+|---|---|---|
+| 当前只新增一条取消原因非空规则，且规则入口就在状态变更方法中 | 保持 Service 中的最小改动，并维护同一聚焦测试 | 为单一校验新建没有复用对象的抽象层 |
+| 后续出现多个取消入口且重复表达同一规则 | 先核对全部调用方、状态效果与测试，再评估抽取唯一规则入口 | 未确认重复语义就机械合并代码 |
+| 发现外部调用方、异常协议或审计要求会影响规则 | 补齐接口与集成证据，再调整边界 | 用猜测替代兼容性和回归验证 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+可演进性不是预先堆叠抽象，而是让每次重构都有明确的重复、耦合或回归证据。
+</div>
+
+<!--
+逐字稿：当前案例的证据只支持一个小而清晰的 Service 改动和对应测试，不支持为了形式上的可维护性额外建立抽象。只有当后续确实出现多个取消入口、重复规则，或者外部调用和异常协议带来新的边界时，才需要用调用关系和回归证据评估重构。
+
+这也是审查 AI 改动的重要原则：AI 很容易提出结构优化候选，但是否重构应由重复语义、耦合关系和可验证的回归风险决定，而不是由代码看起来是否“更抽象”决定。
+-->

slidev/pages/day6/m8-asset-change-validation.md

@@ -0,0 +1,195 @@
+# 模块 8：资产变更也要走工程验证
+
+<div class="mt-6 text-sm">
+
+代码变更会进入 Review、测试和 CI；会影响 Agent 行为的资产变更也应接受同样严肃的验证。
+
+Rule、任务上下文契约、Skill、自定义 Agent 和 MCP 契约不是静态文档，而是研发过程中的可执行配置。
+
+</div>
+
+<div class="grid grid-cols-5 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">Rule</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">上下文契约</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">Skill</div>
+<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">Agent</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">MCP</div>
+</div>
+
+<!--
+逐字稿：第五天验证的是一份资产自身是否有清晰边界：材料齐全时怎样交付，材料缺失时能否正确停止。模块 5 管理共享版本、使用者迁移与稳定回退点。这里聚焦一条资产 diff：实际行为改了什么，引用是否仍可用，代表性边界是否重新验证，证据是否能进入审查记录。
+
+第五天建立资产的内容与边界；模块 5 管理版本生命周期；模块 8 审查本次资产变更的行为与证据。
+-->
+
+---
+
+# 为什么资产变更会改变行为？
+
+<div class="mt-5 text-xs">
+
+| 改动位置 | 直接影响 | 需要防范的风险 |
+|---|---|---|
+| Rule 的必须与禁止项 | 任务允许做什么、何时停止 | 放宽关键约束或误伤正常任务 |
+| 任务上下文契约的输入与输出 Schema | 模型可依据什么、结果如何被消费 | 事实缺失、下游解析失效 |
+| Skill 的步骤与引用 | 判断顺序、加载的资产和交接结果 | 漏掉验证步骤或引用旧资产 |
+| Agent 的指令与工具 | 角色职责、可调用能力和权限 | 越权、职责重叠或不可控输出 |
+| MCP 的能力契约 | 外部读写范围与失败语义 | 把高风险调用当成只读查询 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+审查资产 diff 的重点，是行为变化，而不是措辞是否顺畅。
+</div>
+
+<!--
+逐字稿：资产文件看起来像文档或配置，但它们会直接改变 Agent 的输入、判断、输出和工具权限。因此审查资产 diff 的重点不是语句是否顺畅，而是行为发生了什么变化。删除一个输入字段、放宽一条 Rule、增加一个工具，都可能扩大不可靠结论或越权调用的风险。
+
+资产可以是 Markdown 或配置文件，但应按其对任务行为的影响来审查。不同资产对应的风险层次不同。
+-->
+
+---
+
+# 资产变更审查的四个问题
+
+<div class="grid grid-cols-2 gap-4 mt-8 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">输入、输出、停止条件或权限改变了吗？</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">名称、路径、引用和元数据仍能正确解析吗？</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">实际行为变化与本次变更目的一致吗？</div>
+<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">完整、缺失、冲突和越界输入都重新验证了吗？</div>
+</div>
+
+<div class="mt-7 text-sm text-center op-75">
+四个问题覆盖语义、引用、变更意图与边界验证。
+</div>
+
+<!--
+逐字稿：审查一次资产变更时，可以从四个方向提问。输入、输出、停止条件和权限变了吗；名称、路径和引用还能解析吗；实际变化是否真的解决了本次问题；完整、缺失、冲突与越界输入是否重新验证。版本兼容、迁移和回退已经在模块 5 中定义，这里不重复讨论。
+
+这四个问题能避免只看正文不看引用关系，也能避免只跑正常示例而忽略停止条件和权限边界。
+-->
+
+---
+
+# 用测试夹具做资产回归
+
+<div class="mt-5 text-xs">
+
+| 夹具类型 | 输入特征 | 预期行为 |
+|---|---|---|
+| 完整输入 | 事实、规则和验证材料齐全 | 输出结构完整，结论能关联证据 |
+| 缺失输入 | 缺少关键代码、日志或规则 | 明确列出缺口并停止结论 |
+| 冲突输入 | 需求、规则和实现信息不一致 | 标识冲突，不擅自选择一方 |
+| 越界输入 | 请求超出定义的项目或权限范围 | 拒绝越界操作，解释允许范围 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+资产回归验证边界是否正确，不要求模型每次生成完全相同的文字。
+</div>
+
+<!--
+逐字稿：资产回归使用夹具，而不是要求模型每次输出相同句子。完整输入验证能否形成有证据的交付，缺失输入验证能否停止，冲突输入验证能否标识分歧，越界输入验证能否拒绝。我们断言的是结构、边界和结论等级；历史版本的迁移与降级属于模块 5 的版本治理。
+
+夹具是可重复的输入与预期行为组合。对于生成式资产，更稳定的断言是结构、边界和结论等级，而不是逐字比对输出。
+-->
+
+---
+
+# 修改前后都要检查引用完整性
+
+<div class="mt-5 text-xs">
+
+| 检查对象 | 典型问题 | 验证方式 |
+|---|---|---|
+| Skill 元数据 | 名称、触发描述、入口路径失效 | 读取目录与发现配置 |
+| Rule 与任务上下文契约引用 | 指向旧路径、旧字段或旧版本 | 搜索引用并运行代表性任务 |
+| Agent 调用 Skill | 角色名或交接 Schema 改变 | 检查调用参数与结构化输出 |
+| MCP 工具契约 | 工具名、读写标记、错误语义不一致 | 契约校对与权限夹具 |
+| 下游交付模板 | 新输出字段未被消费或旧字段仍被依赖 | 对照输入输出 Schema |
+
+</div>
+
+<!--
+逐字稿：资产变更最常见的问题往往不是正文写错，而是引用链断了。Skill 的发现元数据、Rule 和任务上下文契约的路径、Agent 的交接字段、MCP 的工具语义、下游模板的 Schema，都相当于接口。修改前后都要检查这些名称、路径、字段和调用关系是否仍能正确工作。
+
+资产改动常见故障不是正文写错，而是引用链断裂。应把路径、名称、字段和调用关系视为需要验证的接口。
+-->
+
+---
+
+# 三类不能直接合入的资产变更
+
+<div class="mt-5 text-xs">
+
+| 信号 | 风险 | 需要补齐的内容 |
+|---|---|---|
+| 新增工具权限，却没有用途和停止边界 | Agent 可能越权调用外部能力 | 权限说明、允许场景和失败降级 |
+| 修改必填输入或输出结构，却没有代表性夹具 | 行为变化无法被回归判断 | 覆盖正常、缺失与冲突材料的验证记录 |
+| 更新规则或任务上下文契约，却没有代表性夹具 | 无法判断是修复还是引入新误用 | 完整、缺失、冲突和越界输入验证 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
+没有行为说明、引用检查和验证证据的资产 diff，不具备合入条件。
+</div>
+
+<!--
+逐字稿：三类资产改动不能直接合入：新增工具权限却没有用途和停止边界，修改输入或输出却没有迁移说明，更新规则或任务上下文契约却没有代表性夹具。它们缺的不是表面流程，而是行为说明、兼容边界和验证证据。补齐这些证据之后，才知道改动是在修复问题还是引入新的误用。
+
+这三类信号对 Rule、任务上下文契约、Skill、Agent 和 MCP 都适用。重点是补齐证据，不是形式化地增加审批步骤。
+-->
+
+---
+
+# 资产变更的最小交付说明
+
+<div class="mt-5 text-xs">
+
+```md
+## 变更目的
+解决的重复问题、误用风险或项目事实变化。
+
+## 行为变化
+输入、输出、约束、工具权限、停止条件中发生了什么变化。
+
+## 变更范围与引用结果
+受影响的文件、调用方、模板或配置，以及名称、路径和 Schema 的检查结果。
+
+## 验证证据
+已运行的夹具、引用检查和可复核结果；未覆盖项如实列出。
+```
+
+</div>
+
+<!--
+逐字稿：资产变更也需要一份最小交付说明。先说明为什么改，再说明输入、输出、权限或停止条件改变了什么，随后列出受影响的引用及检查结果，最后附上已运行的夹具和可复核证据。它可以随资产 diff 或 PR 保存，让后续维护者无需从修改记录中反推行为变化。
+
+这份说明记录本次资产 diff 的工程证据。模块 5 的版本兼容性说明则记录目标版本的适用范围、迁移与回退，两者分别服务于变更审查和版本使用。
+-->
+
+---
+
+# 资产也纳入工程质量闭环
+
+<div class="mt-7 text-sm text-center">
+
+<div class="inline-block px-4 py-2 rounded-lg bg-blue-500/10 border border-blue-500/30">识别行为变化</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-emerald-500/10 border border-emerald-500/30">检查引用与解析结果</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-amber-500/10 border border-amber-500/30">验证夹具与权限边界</div>
+<span class="mx-2 op-50">-&gt;</span>
+<div class="inline-block px-4 py-2 rounded-lg bg-purple-500/10 border border-purple-500/30">留下可追溯结论</div>
+
+</div>
+
+<div class="mt-9 text-sm text-center op-75">
+代码和 AI 工程资产都需要以事实、边界和验证作为进入共享使用的依据。
+</div>
+
+<!--
+逐字稿：资产进入共享使用前，也要走完整的工程质量闭环。先识别行为变化，再检查引用和解析结果，然后验证夹具与权限边界，最后留下可追溯结论。代码验证的是实现结果，AI 工程资产验证的是判断、权限和引用是否仍然可靠。
+
+资产变更与代码变更采用相同的质量原则，但验证对象不同：代码验证行为实现，资产验证判断、权限和引用是否仍然可靠。
+-->

slidev/pages/day6/m8-final-demo.md

@@ -0,0 +1,83 @@
+# 模块 9：AI 编程的工程底线
+
+<div class="mt-6 text-sm">
+
+AI 让研发更快，但不改变软件工程的基本要求。
+
+范围、规则、验证、协作和可维护性，决定一段 AI 生成代码能否真正进入项目。
+
+</div>
+
+<div class="grid grid-cols-5 gap-3 mt-8 text-sm">
+<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">理解范围</div>
+<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">保护规则</div>
+<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">验证行为</div>
+<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">说明结论</div>
+<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">保持可维护</div>
+</div>
+
+<!--
+逐字稿：第六天的收束不是新增一套流程，而是归纳 AI 编程进入工程协作后必须保留的五项判断能力：理解范围、保护规则、验证行为、说明结论和保持可维护性。PR、Git、CI、证据链和资产验证，都是让这五项能力真正落到交付中的手段。
+
+第六天的收束不是增加新的流程要求，而是归纳 AI 编程进入工程协作时必须保留的五项判断能力。
+
+前面模块中的 PR、Git、CI、证据链、资产变更验证与可维护性审查，都服务于这五个目的：理解范围、保护规则、验证行为、说明结论和保持可维护性。
+-->
+
+---
+
+# AI 参与研发时，什么没有改变？
+
+<div class="mt-5 text-xs">
+
+| AI 可以改变 | 工程原则不变 |
+|---|---|
+| 更快搜索代码和生成候选方案 | 先理解现有系统，再决定改动范围 |
+| 更快补齐实现和测试草稿 | 业务规则仍要在正确边界保护 |
+| 更快解释日志和定位假设 | 验证证据必须与结论强度匹配 |
+| 更快生成说明和文档初稿 | 人工仍对合入与发布结论负责 |
+
+</div>
+
+<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+工具能力会持续演进，工程判断的价值反而更高。
+</div>
+
+<!--
+逐字稿：AI 会持续改变搜索、生成和归纳信息的速度，但不会改变工程原则。仍然要先理解现有系统，再决定改动范围；仍然要把业务规则放在正确边界；仍然要让验证证据和结论强度匹配。模型越强，人的工作越集中在定义问题、判断约束和承担技术结论。
+
+这张表帮助学员建立正确预期：AI 改变的是信息处理和代码生成速度，不改变软件工程中范围、规则、验证和责任这些基础要求。
+
+当模型能力继续提升，人的工作会更多集中在定义问题、判断约束、验证结果和承担技术结论上。
+-->
+
+---
+
+# 高质量 AI 编程的共同语言
+
+<div class="grid grid-cols-2 gap-4 mt-8 text-sm">
+<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
+<div class="font-bold">事实优先</div>
+<div class="mt-2 text-xs op-70">区分已读到、已验证和仍待确认的信息。</div>
+</div>
+<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
+<div class="font-bold">最小改动</div>
+<div class="mt-2 text-xs op-70">以明确目标约束改动范围，避免无关重写。</div>
+</div>
+<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
+<div class="font-bold">验证闭环</div>
+<div class="mt-2 text-xs op-70">让测试、日志和人工检查分别支持相应结论。</div>
+</div>
+<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30">
+<div class="font-bold">可追溯说明</div>
+<div class="mt-2 text-xs op-70">让后续维护者理解目标、范围、证据和边界。</div>
+</div>
+</div>
+
+<!--
+逐字稿：高质量 AI 编程需要一套稳定的共同语言。事实优先，区分已确认和待确认；最小改动，让实现不超出明确目标；验证闭环，让测试、日志和人工检查各自支撑结论；可追溯说明，让后续维护者看得懂目标、范围、证据和边界。这四点不依赖某个工具，也能用于讨论任何一段 AI 参与的改动。
+
+这四点可以作为 AI 编程质量沟通的共同语言。它们不依赖某个具体工具，也不依赖特定项目的流程。
+
+面对一段 AI 生成代码时，可以用这四点讨论：事实是否充分、范围是否收敛、验证是否匹配、结论是否可追溯。
+-->