Guided mission
第一个可自研功能
这节不是讲新知识，而是现场选一个真实功能，带学员走完一次完整的安全开发 loop。
为什么现场选功能
固定案例让学员看懂但不会用。现场选一个真实小功能，学员看到的是"从零到 PR"的完整链路在自己项目上如何运转。
Presenter： 和听众互动，让他们提一个最近想做的小功能或改动。选一个足够小、能在课堂上走完分析的需求。如果听众没有想法，可以从 Safe First Tasks 里挑一个。
Step 1：判断车道
What — 三条车道
Green：产品自研
- 同模块 C# 小改
- 复用现有 UI / 提示
- 不碰序列化资产
Yellow：后台/全栈自研
- 接口 / 数据链路
- Command / Service 小逻辑
- 证据和 review 更完整
Red：客户端 owner
- 启动 / 热更 / 构建
- 框架源码
- 大规模 Scene / Prefab
Why — 车道判断决定了这个功能谁来做、需要多少证据、PR 标准是什么。判断错误比代码 bug 更危险：一个 Red 任务被当 Green 做，可能破坏启动或框架。
Presenter： 带学员对选定功能做车道判断。问三个问题：1) 只改同模块 C# 还是要碰 Prefab / Scene？2) 是体验规则还是数据链路？3) 有没有必须碰启动、框架或构建的部分？
Step 2：写验收
What — 验收不是代码完成标准，是用户视角的"什么算做完"。
| 场景 | 操作 | 期望 |
|---|---|---|
| 正常流程 | {现场填} | {现场填} |
| 失败 / 超时 | {现场填} | {现场填} |
| 快速重复操作 | {现场填} | 不重复弹窗、不重复请求。 |
| 关闭页面 / 弹窗 | {现场填} | 不在页面销毁后继续改 UI。 |
| 第二次进入 | {现场填} | 状态符合预期。 |
Why — 没有验收就没有"完成"的定义。产品不写验收就让 agent 动手，等于放弃了对结果的控制。
Presenter： 带学员一起填这张表。先让产品同学说正常流程，再让后台同学补异常和边界。
Step 3：让 agent 只分析
What — 先让 agent 证明它理解了链路，再决定要不要让它改代码。
先不要修改代码。
任务：分析"{现场选定的功能}"在 HappyMahjong 中的最小功能链路。
请只输出：
1. 涉及的 View / Mediator / Command / Service / Model 文件路径。
2. 点击事件或触发入口在哪里。
3. Mediator dispatch 的事件名。
4. Context 中 Event → Command 的绑定位置。
5. 完成这个需求最小可能修改哪些文件。
6. 不应该修改哪些文件。
7. 手动验证清单。
8. 是否涉及 Inspector / Prefab / Scene / meta。
9. Console 需要观察什么。
不确定处标注"推测"。不要改代码。Why — "只分析不修改"是 Unity 项目里最便宜的安全阀。没有路径的方案不可审查。
Presenter： 现场把这段 prompt 填入选定功能，跑一次 agent。让学员一起看输出，判断是否可用。
Step 4：判断 agent 输出
What — 新手不需要懂所有代码，只需要能判断输出有没有越界。
判断路径：先看证据，再看边界
有文件路径吗？
没有路径 = 不可审查
没有路径 = 不可审查
→
链路在目标模块内吗？
跳到启动 / 框架 = 高风险
跳到启动 / 框架 = 高风险
沿用现有 UI / 网络吗？
新造系统 = 拒绝
新造系统 = 拒绝
→
有验证清单吗？
没有验证 = 还不能改
没有验证 = 还不能改
| 输出特征 | 判断 | 为什么 |
|---|---|---|
| 列出目标模块的 View / Mediator / Command / Service | 可能可用 | 链路在模块内，方向合理。 |
建议修改 Assets/Scripts/Base/StrangeIoC/ | 拒绝 | 框架源码不是小需求的解法。 |
| 建议新建 Canvas / 新 UI 框架 / 新 HttpClient | 拒绝 | 应先沿用现有 UIUtil / PopUpManager / TSDK。 |
| 没有任何文件路径，只讲抽象方案 | 不可用 | 无法审查和验证。 |
Why — agent 是放大器不是负责人。输出越界时，唯一的防线是人的判断。
Presenter： 对照刚才的 agent 输出，带学员逐条过判断表。如果输出有越界项，现场演示怎么要求 agent 缩回模块边界。
Step 5：限定范围 → 实现
What — 如果分析可信，给第二个 prompt，明确"只允许改什么"和"不许碰什么"。
基于刚才的分析，给出最小实现方案。先不要改代码。
只允许考虑：
- {现场确认的 1-4 个 .cs 文件}
不得修改：
- .unity / .prefab / .asset / .meta
- ProjectSettings / Packages
- Assets/Scripts/Base/StrangeIoC/
- 任何未列出的文件
请输出：最小修改文件、每个文件改什么、风险、验证步骤、Console 观察点。
如果修改范围仍限于同模块 C# 文件，下一步我会允许你实现。Why — 没有边界的 agent 会"顺手"改启动、框架或 Prefab。明确边界是安全开发的核心。
Presenter： 现场填入 agent 分析出的文件列表。如果时间允许，可以让 agent 执行实现并演示 diff review。
Step 6：验证 + Diff
What — "完成"不是代码写完，而是编译、Console 干净、验收通过、diff 没有越界。
完成 = 过五道门
编译Console 无新增红错
测试能测则测
手动验证正常 + 异常
Diff 审查红黄绿灯
风险说明未验证要写明
Why — Unity 不是纯代码项目。代码编译不代表功能正确；功能正确不代表没有破坏 Prefab / Scene / 启动链路。
Presenter： 如果时间允许，现场跑一次
git diff --stat，带学员判断 diff 是否安全。重点看有没有 .unity / .prefab / .meta / StrangeIoC / ProjectSettings。这节课真正要记住的
不要让 agent "做功能"。先让它用文件路径证明它理解了链路，再限定范围让它改。
判断越界比写代码更重要。能判断 Green / Yellow / Red，能看出 diff 红旗，比能写 C# 更关键。
Retrieval check
agent 为一个小体验需求建议新增 Canvas prefab 和新 HttpClient，最合理的反应是？