专题
Unity 游戏客户端、AI 协同与游戏研发 Agent 面试准备手册
面向中级 Unity 客户端求职的单一总手册：先复习商业项目与 Unity/C#，再按 AgentLearn Z0–Z8 亲手完成 UI 工具、CLI/Pipeline/uauto 和 Evidence，最后进入 M2–M5 Agent/Eval。
郭昊｜Unity 游戏客户端、AI 协同与游戏研发 Agent 面试准备手册
最终完整版 · 内容核对日期：2026-08-06
目标岗位：中级 Unity / U3D 游戏客户端开发，兼顾 Unity 编辑器工具与游戏研发 Agent 方向
薪资口径：20–25K，理想约 22K；需要同步修改当前简历和招聘平台中的 17–20K
使用原则：商业项目是面试主场，AI 与 Agent 是差异化能力；没有可复现证据的内容不写成已完成成果。
1. 一页速览
1.1 最终定位
推荐统一表述：
我有约 4 年游戏客户端开发经验，经历过 Unity 项目从 0 到二测、正式上线，以及大型运营项目持续迭代。我的核心能力是客户端业务系统、UI 与数据刷新、服务端联调、异常流程和内容生产工具。近期重点补强 Unity/C#、Prefab 与 Editor 工具实操，以及受控 AI 协同、Harness 和游戏研发 Agent 方法；只有本人亲手完成并验证的练习才作为面试证据。
必须主动守住的边界：
- 是 4 年游戏客户端经验，不是 4 年连续纯 Unity。
- 2024.09–2026.05 的网易外包项目使用 Python 自研引擎，不是 Unity。
- 三个商业项目主要是传统开发，是当前最可靠的面试证据。
- 旧个人项目中 AI 参与较多，不作为当前求职的核心项目证明，也不要求背诵项目细节。
- AI、Harness、Prefab、Editor 工具和 Agent 只讲本人已经理解、亲手运行并能现场修改的部分。
- 不包装成主程、核心战斗框架负责人、TA、复杂 Shader/C++ 或 xLua 底层专家。
1.2 当前证明顺序
| 顺序 | 证明内容 | 当前面试作用 |
|---|---|---|
| 1 | 三个商业项目 | 证明中级客户端经历、真实交付和联调能力 |
| 2 | Unity/C#、UGUI、资源、网络和性能基础 | 证明能够回到中级 Unity 客户端日常开发 |
| 3 | 在 AgentLearn 中亲手完成的 UI Editor 工具、CLI/uauto 和 Harness/Evidence 练习 | 只有 Ledger 有运行证据后才作为当前手感证明 |
| 4 | AI Change 工作流 → Unity 工程闭环 → GameDev Agent/Eval；ET10 按岗位选读 | 普通 Unity 岗只作 3–5 分钟加分项；工具岗再按真实完成度展开 |
1.3 掌握深度 D1–D4
| 深度 | 含义 | 面试表现 |
|---|---|---|
| D1 能定义 | 知道是什么、解决什么问题 | 30 秒说清概念和用途 |
| D2 能解释 | 理解数据流、边界和取舍 | 能画图、讲输入输出和失败路径 |
| D3 能修改调试 | 能找到入口、运行、制造失败并修复小问题 | 能现场加参数、改规则、跑测试和定位错误 |
| D4 能独立实现 | 不依赖 AI 也能从零完成最小版本并排错 | 能承担需求到交付的完整责任 |
目标深度：
- 简历中的商业项目主张：D4。
- Unity/C# 高频基础：D2–D3。
- AgentLearn UI Editor 工具和 Harness 实操：完成本人从零实现、故意失败和 Unity 复测后达到 D3；未实操前只算 D1–D2。Prefab 练习作为独立补强，不打断 Z0–Z8。
- AI Change 工作流：达到 D2–D3，能独立写 Proposal/Specs/Design/Tasks，并解释 Check、Verify 和人工 Gate。
- Unity CLI/Pipeline/uauto、MCP、Harness 和 Evidence：先达到 D2；本人完成 AgentLearn 只读链、故意失败和 Ledger 后升级到 D3。
- GameDev Agent/Eval：先达到 D1–D2；完成写入闭环、多工具编排和固定 Eval 后才能升级到 D3。
- ET10：普通 Unity 岗只需 D1–D2 选读；岗位明确追问 Roslyn/ET/AI Native 时，再深挖专属规则和生命周期例子。
1.4 准备优先级
| 优先级 | 内容 | 完成标准 |
|---|---|---|
| P0 | 定位、简历、自我介绍、三个商业项目、Unity/C# 高频题 | 本周就能参加中级 Unity 面试 |
| P1 | AI Change 工作流、AgentLearn Z0–Z8、Editor 只读工具、CLI/Pipeline/uauto、Harness 与 Evidence | 本人从零实现并完成自动化、人工、故意失败和重开复验后，能经受专项追问 |
| P2 | M2 安全写入、M3 Agent 接入、M4 扩展、M5 固定 Eval 与作品化；ET10 按岗位选读 | 完成真实证据后再投编辑器工具或游戏研发 Agent 相关岗位 |
1.5 三种顺序不要混淆
这份手册同时服务面试和学习，所以必须分开三种优先级：
| 顺序 | 用来决定什么 | 唯一规则 |
|---|---|---|
| 面试证明顺序 | 面试先讲什么 | 商业项目 → Unity/C# 基础 → 本人当前实操 → AI/Agent 加分 |
| AI 实践执行顺序 | 今天到底做哪一步 | Z0 → Z1 → Z2 → Z3 → Z4 → Z5 → Z6 → Z7 → Z8 → M2 → M3A → M3B → M3C（可选）→ M4 → M5 |
| 证据升级顺序 | 什么时候可以说“做完了” | planned → implemented → compiled → automated green → manual runtime accepted → resume-ready → 可作为面试证据 |
两条阅读路线：
- 近期面试路线：第 1–6 章 → 第 7.1/7.11 节 → 第 8.1/8.2/8.9 节 → 第 10 章。商业项目和基础不被 AI 学习挤掉。
- 本人从零实操路线：先读第 7 章的协作规则，再严格执行第 8.2 节；Z8 通过后才进入第 9 章的 M2–M5。第 10.6 节只安排日历，不定义第二套技术顺序。
1.6 当前 AI 实践起点
截至 2026-08-06，本手册把 AgentLearn 当作尚未开始业务实现的学习项目：
| 项目 | 当前允许陈述 |
|---|---|
| Unity 项目 | 2D + URP 模板和 Test Framework 保留；版本以本人打开项目后记录为准 |
Assets/AgentLearn、UI 夹具、业务代码和测试 | 尚未由本人建立 |
项目内 Pipeline、共享自动化包和 .uauto | 尚未由本人导入或初始化 |
三个 agentlearn.* Action | 目标设计，尚未实现、编译或运行验证 |
| 当前学习进度 | 从 Session 01 / Z0 开始；今天只做 Z0，不提前安装 Z5/Z6 能力 |
机器上能够运行 unity 或 uauto，只证明机器级工具存在，不代表 AgentLearn 已接入。后文所有尚未由 Ledger 证明的代码、命令输出、错误码、Action 调用链和 Eval 数字，都只能视为目标形态或教学示例。
1.7 四类真实性标签
- 已核验：当前本地文件、代码、版本或官方来源可以确认。
- 简历陈述：来自最新简历，应准备真实口述、调用链和本人边界。
- 待复跑：以前有记录，但当前没有重新执行验证；不能主动报数字。
- 规划中：尚未实现，不作为现有成果。
1.8 面试回答纪律
- 先用 10–20 秒给结论，再根据追问展开。
- 明确区分“我负责、我参与、团队已有、AI 生成、只研究过”。
- 讲调用链、状态、错误、日志和验证，不用“熟练、精通”替代证据。
- 不知道时收缩边界，说明当前理解和验证方法，不猜 API、错误码或数字。
- AI 追问不防御：承认生成比例，同时说明本人对结果承担工程责任。
- 外包身份、开源框架、团队基础设施和规划中的项目都不算个人独立成果。
1.9 人工重点：AI 开发工作流复习卡
这是本人复习时优先看的版本。先区分两个“任务”：
- 业务任务 / 需求工作项：原则上一项对应一个 Change；如果范围太大，就拆成多个能独立验证、独立交付的 Change。
- Change 内的 Tasks：是
tasks.md中更小的执行步骤；一个 Change 通常包含多个 Task，每次只由本人实现一个，AI 也只围绕当前 Task 解释或 Review。
最短记忆链：
Change 管一次变更；Proposal 管为什么改和允许改什么；Specs 管最后应该看到什么；Design 管准备怎样实现；Tasks 管执行顺序；Apply 小步修改；Check 检查工程正确性；Verify 验证真实行为；Archive 沉淀规范和证据。
执行时只记五个字：
| 五步 | 本人必须亲手 | AI 只允许协助 |
|---|---|---|
| 定 | 决定目标、非目标、规则值、允许范围、风险和验收标准 | 调查代码、追问缺口、起草 Proposal/Specs/Design/Tasks |
| 做 | 写首个 Contract、成功路径和测试；在 Unity/CLI 中执行每个最小步骤 | 解释 API、Review 小步 Diff、指出遗漏；不代写整个目录 |
| 查 | 查看 Diff、第一条错误、依赖、编译和测试原始结果 | 做结构化 Review，解释错误机制，不伪造绿灯 |
| 验 | 亲自跑正常、空、边界、故意失败、无副作用和重开路径，并作最终判断 | 在本人先写原因假设后协助定位、对比结构化结果 |
| 归 | 确认证据真实、写 Ledger、脱稿口述并现场小改 | 整理证据索引和表达，不能替本人签字验收 |
完整停止条件见第 7 章；唯一动手顺序见第 8.2 节；当前阶段口述见第 8.9 节。
2. 岗位、简历与投递策略
2.1 最新简历事实基线
以下信息来自 2026-07-14 的最新两页简历，属于“简历陈述”：
| 时间 | 公司 / 项目 | 技术与阶段 | 核心证明 |
|---|---|---|---|
| 2024.09–2026.05 | 网易外包，《七日世界》 | Python 自研引擎；PC/移动/主机三端互通；已上线 | 大型项目持续迭代、制造/职业/养殖、数据兼容、联调 |
| 2023.08–2024.08 | 上海绯宵，《七星传》 | Unity/C#/Lua；Android；已上线 | Unity 正式上线、UI 数据链、红点、重连、真机日志 |
| 2022.06–2023.07 | 莫彼吾斯，《野火流明》 | Unity/C#/Lua/Utage/Odin；从 0 到二测 | 业务模块 0→1、引导、红点、AVG 编辑器和工具链 |
| 2021.07–2021.12 | 上海煜航实习 | Unity；WebGL/VR | UI 动效、交互、动画和项目测试维护 |
教育与证书只需简洁说明：华东理工大学本科，日语专业并辅修计算机；CET-4、JLPT N2、计算机辅修证书。
2.2 当前简历必须处理的冲突
| 冲突 | 风险 | 最终口径 |
|---|---|---|
| 简历写 17–20K，当前目标为 20–25K | HR 会直接按低区间锚定 | 修改简历和平台；口头说“20–25K，理想约 22K，结合岗位级别与年包” |
| “4 年工作经验”容易被理解为 4 年纯 Unity | 最近近两年是 Python 自研引擎 | 统一为“4 年游戏客户端，前两段 Unity，最近大型项目是 Python 自研引擎” |
| “熟练使用 Codex/Copilot/ChatGPT/Claude Code”过宽 | 会追问流程、责任、验证和失败 | 改成结构化规格、限定修改、Diff、编译、Harness、Unity 运行和人工 Gate |
| Unity、C#、Lua、Python 都写得很强 | 面试官会按同等生产深度追问 | 分成核心能力、项目使用、了解/个人实践三档 |
| EditorWindow、Odin、Utage 等工具并列 | 容易被问成工具框架作者 | 绑定到真实 AVG 编辑器、导表或项目接入案例 |
2.3 推荐的一页简历结构
| 模块 | 建议占比 | 重点 |
|---|---|---|
| 姓名/定位/联系方式 | 8% | 游戏客户端开发｜4 年｜Unity/C#；城市和薪资一致 |
| 个人优势与技能 | 20% | 3–4 条可证明优势，AI 只占 1 条 |
| 《七日世界》 | 30% | 制造、职业、养殖、兼容、联调；标明外包和 Python 自研引擎 |
| 《七星传》 | 18% | Unity 上线、UI 链路、红点、重连、真机 |
| 《野火流明》 | 16% | 0→1、引导、红点、AVG 工具 |
| 个人 Unity/AI 实践 | 8% | 只放一个已经复跑、能解释、能修改的闭环 |
2.4 简历动词真实性等级
| 真实情况 | 安全动词 | 必须能证明 |
|---|---|---|
| 独立完成且能重建排错 | 负责、设计并实现 | D4：需求、入口、数据、实现、测试、结果 |
| 与同事协作 | 参与、协同完成 | 清楚自己的接口和边界 |
| 接手已有模块扩展 | 维护、扩展、迭代、优化 | 原有结构、本人改动、验证结果 |
| 使用现有工具/框架 | 使用、接入、基于……扩展 | 工具入口、调用方式和项目化修改 |
| AI 生成主要实现 | 借助 Codex 完成搭建、集成和验收 | 能解释、修改、调试和承担结果责任 |
| 只研究或规划 | 研究、验证机制、规划中 | 不放在“已完成成果”区域 |
2.5 推荐的 AI 简历表述
在个人 Unity 项目中实践 OpenSpec 驱动的 AI 协同流程：先明确需求、非目标与验收条件，再限定 Codex 修改范围；本人负责 Diff 审查、项目集成、编译、Harness 测试、Unity 运行验证和最终验收，并保留失败证据与回滚边界。
暂时不要写：
- “独立设计完整 AI Agent 平台”。
- “AI 自动完成游戏功能并保证正确”。
- “完整移植 ET10 Analyzer 体系”。
- “Unity MCP 可稳定自动修改所有 Scene/Prefab”。
- 未亲自复跑的
14/14、spec:validate 43、覆盖率或效率百分比。
2.6 岗位分层
| 层级 | 适合的 JD | 投递占比 | 处理方式 |
|---|---|---|---|
| 主投 | 3–5 年游戏客户端；Unity/C#；UI、任务、引导、养成、背包、工具、联调 | 60% | 匹配 60%–70% 即投，按 JD 调整前半页关键词 |
| 冲刺 | 3 年以上 Unity；工具/性能/框架要求较高但非主程；高质量新项目 | 25% | 准备专项案例，允许 1–2 个可补缺口 |
| 谨慎 | 5–10 年纯 Unity；主程；C++/Shader/TA/xLua 底层硬门槛 | ≤15% | 没有强项目吸引力就跳过，不用虚假关键词换面试 |
2.7 JD 100 分评分卡
| 维度 | 权重 | 高分信号 | 低分信号 |
|---|---|---|---|
| 技术匹配 | 25 | Unity/C#、业务系统、UI、工具、联调 | 硬性 C++/Shader/TA/xLua 底层 |
| 项目阶段 | 20 | 新项目、预研转正式、核心迭代 | 纯维护、边缘活动、项目状态模糊 |
| 职责成长 | 20 | 独立模块、设计+实现+联调+验收 | 只切 UI、只修零散问题 |
| 薪资年包 | 15 | 20–25K 覆盖，薪数和奖金清楚 | 上限低于目标，拒绝说明构成 |
| 团队流程 | 10 | 分工清晰、Review、测试和版本流程 | 一人承担所有端且没有支持 |
| 稳定与合同 | 10 | 直招、合同清楚、项目阶段可解释 | 驻场、外包归属和劳动关系含糊 |
低于 60 分不投入大量准备；70 分以上优先沟通。
2.8 城市与沟通策略
- 杭州：当前简历目标城市；优先 Unity 新项目、业务系统、工具链和大型 3D 项目。
- 上海：已有两段本地 Unity 经历，叙事连续；优先新项目、完整模块和工具岗位。
- 北京：岗位类型多但系统、性能和框架深度要求通常更高；先远程沟通，避免硬投主程。
- 广州/成都：关注大型项目、团队阶段、Lua 深度、年包和迁移成本。
- 城市排序不是实时薪资统计；投递当天用真实 JD 校准。
BOSS/HR 首次联系可以先问：
您好，我对岗位有兴趣。想先确认一下：项目是自研还是外包，目前处于预研、开发还是上线维护阶段？客户端技术栈、团队规模和这个岗位的主要模块是什么？薪资和年包范围怎样？匹配的话我再发最新简历，方便双方提高沟通效率。
2.9 本章检查清单
- 简历、招聘平台和口头薪资已统一为 20–25K，理想约 22K。
- 任何地方都没有把网易项目写成 Unity。
- 每条“负责/独立”都能连续追问 10 分钟。
- AI 表述已经从工具清单改成可验证工程闭环。
- 已用评分卡筛选至少 10 个真实 JD，并记录高频缺口。
3. 自我介绍与通用压力题
3.1 30 秒版本
面试官您好，我叫郭昊，有约 4 年游戏客户端开发经验。前两段主要使用 Unity/C#/Lua，经历过项目从 0 到二测和正式上线；最近近两年在网易外包的大型 3D 项目中使用 Python 自研引擎，负责制造、职业、养殖等复杂业务系统和跨端联调。我的优势是业务模块、UI 数据链、异常流程和工具开发。最近也在个人 Unity 项目中实践受控 AI 协同与游戏研发 Agent 工具，希望寻找中级 Unity 客户端岗位继续积累。
3.2 60 秒版本
面试官您好，我叫郭昊，有约 4 年游戏客户端开发经验。第一段正式项目是在莫彼吾斯参与《野火流明》从 0 到二测，独立负责过编队、好友、任务、抽卡、新手引导、红点和 AVG 剧情等系统，也使用 Odin 和 Utage 做过面向策划的剧情工具。第二段在上海绯宵参与 Unity 项目《七星传》开发到正式上线，负责关卡剧情、看板娘、好友任务、红点，并参与 UI 框架、断线重连和 Android 真机问题处理。最近近两年在网易外包的《七日世界》项目中使用 Python 自研引擎，负责设施制造、职业框架、养殖模块和复杂数据兼容。虽然最近项目不是 Unity，但工作一直是客户端业务、UI、状态和联调。近期我通过个人 Unity 项目恢复并深化 C#、Editor 工具和测试能力，同时实践 OpenSpec、Harness、Unity MCP 与 Agent 工具。我希望寻找中级 Unity 客户端岗位，把已有商业项目经验和新的工程化能力结合起来。
3.3 2 分钟展开结构
- 10 秒：姓名、4 年游戏客户端、中级 Unity 方向。
- 30 秒：《野火流明》证明 0→1、业务系统、引导/红点/AVG 工具。
- 25 秒：《七星传》证明 Unity 正式上线、UI 链路、重连和真机。
- 35 秒：《七日世界》证明大型代码库、复杂系统、兼容和联调。
- 15 秒：个人 Unity 项目和 AI 工程化，不抢商业项目篇幅。
- 5 秒：说明目标岗位和希望承担的职责。
3.4 高频压力题
你有 4 年 Unity 经验吗？
更准确地说，我有约 4 年游戏客户端经验。前两段正式项目使用 Unity/C#/Lua，最近近两年使用 Python 自研引擎，所以我不会说自己有 4 年连续纯 Unity。我的优势是完整项目经历、客户端系统和联调能力；Unity/C# 手感通过个人项目持续恢复和验证。
最近两年不是 Unity，为什么还投 Unity？
最近项目引擎和语言不同，但职责仍是游戏客户端：模块拆分、状态管理、UI 刷新、网络联调、异常流程和问题定位。这些核心能力可以迁移。前两段我有真实 Unity 项目和上线经验，个人项目也持续使用 Unity/C#，所以这是回到主技术方向，不是从零转行。
网易项目是正式员工还是外包？
我是网易外包岗位，参与《七日世界》客户端开发。我会明确合同归属，不把自己说成网易正式员工；能证明的是我在该大型项目中实际负责的制造、职业和养殖模块及联调工作。
为什么离开上一份工作？
项目阶段结束后，我希望回到长期的 Unity 客户端方向，寻找职责更匹配、能够持续积累完整模块与工程深度的新项目。
仅当这符合真实离职原因时使用；如果实际原因不同，必须改成真实版本。
期望薪资怎么说？
我这次目标是 20–25K，比较理想的是 22K 左右。依据是约 4 年游戏客户端经验、Unity 上线和 0→1 项目、大型 3D 复杂业务系统以及联调经历。最终会结合岗位职责、定级、薪数、奖金和项目情况综合沟通。
代码是不是 AI 写的？
三个公司项目主要是传统开发，我能独立读调用链、实现业务、联调和定位问题。个人项目中部分甚至较多实现由 Codex 生成，我不会说成全部手写。我负责需求与数据契约、限定范围、审查架构和调用链、处理集成问题，并通过编译、测试和真实运行验收。解释不清或不能修改的模块，我不会写成独立设计实现。
不用 AI 还能开发吗？
可以。商业项目的核心业务是在传统方式下完成的。我会把 AI 当成检索、样板实现、审查和重复验证的加速器，而不是替代需求判断、架构边界、调试和结果责任。面试前我也会亲自完成一次不依赖 AI 的小功能修改和回归。
为什么公司要招你，而不是直接使用 AI？
AI 能提高生成和检索速度，但不能替团队承担需求澄清、历史上下文、跨端联调、上线责任和业务取舍。我的价值是既有传统客户端项目经验，也懂得把 AI 放进可约束、可审查、可验证的流程，让效率提升不以放弃工程责任为代价。
3.5 高风险口头词
| 避免 | 改成 |
|---|---|
| 我精通 Unity/C#/Lua/Python | 我的核心是 Unity/C#；Lua/Python 是项目使用经验 |
| 我做了整个系统框架 | 我负责其中的客户端框架/模块，接口边界是…… |
| AI 自动把功能做完了 | AI 辅助实现；我负责范围、审查、验证和验收 |
| 测试全部通过所以没问题 | 已覆盖测试通过；仍有运行、体验和未覆盖路径 |
| ET10 保证 AI 不犯错 | ET10 强制已编码且启用的规则，不替代业务验收 |
| MCP 能控制 Unity，所以功能完成 | MCP 是结构化通道，成功不等于业务正确 |
3.6 本章检查清单
- 30 秒、60 秒、2 分钟版本都已录音练习。
- 外包身份、最近两年非 Unity、薪资和 AI 代码四题已脱稿回答。
- 自我介绍没有提前塞入过多 ET10 错误码或 Agent 架构细节。
- 每个“独立负责”都能准确说明团队已有部分和个人部分。
4. 三个商业项目
4.1 《七日世界》：大型项目持续迭代
状态：简历陈述。 网易外包，2024.09–2026.05；大型 3D SOC 生存游戏；Python 自研引擎；PC、移动端、主机端三端互通；已上线。
30 秒介绍
我在网易外包项目《七日世界》中负责客户端业务开发，项目使用 Python 自研引擎。我的主线模块是设施制造和职业系统，也接手迭代过异常物、动物捕捉和养殖。制造系统涉及配方、材料、队列、设施数据、Timer、服务端推送、断线重连和多个交互入口；职业系统通过配置、接口、继承和事件扩展园丁、驯兽师、主厨等玩法。这段经历主要证明我能在大型代码库里处理复杂状态、兼容历史数据并完成跨端联调。
第一深挖案例：设施制造系统
八段式回答：
- 目标：玩家在设施中选择配方、投入材料、进入队列，并持续看到可靠的制造状态和产出。
- 入口：设施交互或远程入口打开制造页面，加载设施和玩家相关数据。
- 配置与状态：配方、材料、队列、设施效能、产出、客户端展示状态。
- 请求链：客户端预校验 → 发起制造请求 → 服务端权威校验与写入 → 状态推送/回包 → 客户端刷新。
- 刷新链：系统层处理数据 → 事件或页面 Controller → 列表、计时、设施外进度。
- 异常：断线重连、材料变化、队列结束、背包满、客户端时间偏差、旧数据结构。
- 一致性：客户端只做展示与预校验；制造结果、材料扣除和产出以服务端为准。
- 验证：正常制造、跨时间完成、重连恢复、材料变化、队列满/结束、背包满、不同入口复用。
建议现场流程图：
设施交互/远程入口
→ 配方与设施数据
→ 客户端材料和条件预校验
→ 制造请求
→ 服务端权威校验与记录
→ 回包/状态推送
→ 系统层更新
→ 页面与设施外进度刷新
→ Timer 只负责展示剩余时间，不决定最终结果数据迁移与兼容 STAR 骨架
- S：制造记录从玩家实体迁移到领地设施，历史数据仍要可读取。
- T：在不破坏旧数据的前提下，让新旧数据能被同一业务逻辑访问。
- A：梳理旧
dict与服务端组装对象的差异；封装统一访问方式；重写相关get/getattr接口；逐入口核对依赖；与服务端确认权威数据。 - R：新旧数据结构可以继续支持制造页面和多个入口；避免各模块分别写兼容分支。
- 追问准备：迁移触发条件、缺字段处理、旧对象识别、回滚策略、为什么不一次性删旧逻辑。
职业系统
可讲事实来自简历：
- 独立负责客户端职业框架，通过配置、接口、继承、事件和服务端属性开关支持扩展。
- 完成园丁、驯兽师、主厨三类职业相关客户端功能。
- 覆盖作物嫁接、特殊材料种植、动物召唤、随身灶台、玩家下单、自动制作、邮件交付和 DIY 食品 Buff 计算。
- 多入口包括据点租赁小摊、野外随身灶台和大地图远程交互，目标是复用业务逻辑而不是复制页面状态。
追问重点：配置如何驱动、接口与继承怎样分工、事件订阅何时释放、服务端属性如何控制、不同入口怎样统一数据源。
养殖与性能问题
安全口径：
我接手的是已有异常物、动物捕捉和养殖模块，主要工作是在理解原有结构后修复历史问题并继续迭代，同时对 UI 层级、页面刷新、数据刷新、动态列表和按钮 Update 做局部优化。我不会把它说成从零设计整个养殖框架，也不会使用没有 Profiler 或数据支持的百分比。
本项目待准备证据
- 一张制造系统数据流、协议流和刷新链图。
- 一个数据兼容真实 Bug：第一条有效证据、根因、修复和回归。
- 一个断线重连或旧回包问题。
- 制造与职业中各一个 10 分钟深挖案例。
- 一个性能问题的定位过程，而不只是一串优化技巧。
4.2 《七星传》：Unity 正式上线
状态：简历陈述。 上海绯宵，2023.08–2024.08；Unity/C#/Lua；Android 回合制手游；已上线。
30 秒介绍
我在《七星传》中独立负责关卡剧情、看板娘互动、好友任务和红点提示等客户端系统，并协作维护背包、关卡和设置。项目使用 Unity/C#/Lua。我持续维护过自研 UI 框架，梳理服务端通知到 View/Model 的刷新链，也参与过断线重连治理、Android 真机日志定位，并围绕 Excel to Lua 流程写过 EmmyLua 辅助导表工具。
UI 数据刷新链
服务端通知/协议回包
→ 系统层更新数据
→ UI 事件
→ Controller
→ View / Model
→ 页面、列表和红点刷新需要解释：
- 数据所有者是谁，UI 是否直接修改业务状态。
- 页面关闭后事件如何解除，如何防止重复订阅和重复刷新。
- Controller 的职责，View/Model 之间如何避免循环依赖。
- 服务端推送与本地操作同时到达时怎样处理旧数据。
红点系统
推荐回答：
红点由叶子业务条件计算，父节点只做聚合，UI 订阅节点变化而不重复实现业务判断。数据变化时只刷新受影响路径；页面打开时做一次状态同步，关闭时解除订阅。需要防止同一条件被多个页面各写一套、父节点重复计数和事件泄漏。
断线重连 STAR 骨架
- S：重连后页面数据或状态不完整，Android 真机上还可能出现无响应。
- T：恢复可靠会话和页面状态，不能只让 Socket 重新连上。
- A：重新执行完整登录协议请求；区分连接态、认证态、业务数据态；重构页面刷新；结合游戏内日志和落盘日志定位。
- R：重连后业务数据重新建立，页面不依赖断线前的临时状态。
- 追问准备：请求顺序、超时、旧回包、重复请求、当前页面恢复、后台切回。
EmmyLua 辅助导表工具
安全口径：围绕现有 Excel to Lua 流程生成代码提示，改善 Lua 配置读取体验。准备说明输入表、输出提示文件、命名与类型映射、错误字段处理和工具触发入口；不要扩大成独立设计完整配置框架。
本项目待准备证据
- 一个本人负责的 Unity 功能达到 D4。
- 一个上线前、真机或网络问题整理成真实 STAR。
- 能解释项目从开发、集中修复到上线中本人实际经历的环节。
- 能画红点树和 UI 刷新链。
4.3 《野火流明》：Unity 0→1 到二测
状态：简历陈述。 莫彼吾斯，2022.06–2023.07；Unity/C#/Lua/Utage/Odin；Android 二次元战棋手游；从 0 到二测。
30 秒介绍
我在《野火流明》项目早期独立负责过编队、好友、任务、抽卡、新手引导、红点和 AVG 剧情，并协作维护背包、设置和本地化。这段经历最适合证明我能在 0→1 阶段搭建业务模块、与策划协作，以及开发内容生产工具。代表案例是大节点与小步骤结合的新手引导、树状红点，以及使用 Odin 和 Utage 完成 AVG 编辑、导出和运行时接入。
新手引导
大节点（阶段/功能）
→ 小步骤（点击/等待/延时/超时）
→ 条件满足后推进
→ 节点持久化
→ 重登或异常后恢复追问准备：
- 如何避免把 UI 路径硬编码到每个步骤。
- 点击目标不存在、页面切换、超时、跳过和版本变化怎样处理。
- 业务功能与引导覆盖层如何解耦。
- 为什么需要大节点持久化，小步骤是否需要保存。
红点系统
重点讲事件驱动、叶子条件、父级聚合、路径更新、订阅释放和调试可见性；不要只说“用了树结构”。
AVG 编辑器与 Utage
策划 Excel / 可视化编辑
→ Odin Editor 工具
→ 校验与导出 JSON
→ Utage 项目化接入
→ C# / Lua 事件交互
→ Spine、角色切换、镜头特效、自定义命令需要准备：
- EditorWindow 或 Odin 入口。
- 数据结构和 JSON Schema。
- 错误行、未知命令、资源缺失怎样暴露。
- 新增一条自定义剧情命令要改哪些层。
- 为什么选择 Utage，项目化接入改了什么。
“0→1”安全边界
“项目从 0 到二测”描述的是项目阶段，不代表我主导了整个项目架构。我可以说清自己独立负责的业务系统、工具和接口，但不会把团队框架、战斗或所有模块算成个人成果。
本项目待准备证据
- 能画引导状态流和红点聚合图。
- 能从 AVG 工具入口讲到运行时消费和新增命令扩展点。
- 准备一个 0→1 阶段需求变化或工具错误的真实 STAR。
- 明确哪些模块独立负责，哪些是协作维护。
4.4 五个 STAR 案例最低配置
面试前至少完成以下五个：
- 《七日世界》制造系统与数据迁移。
- 《七日世界》职业扩展或养殖历史问题。
- 《七星传》断线重连/真机日志问题。
- 《野火流明》引导/红点或 AVG 编辑器。
- 三个商业项目中一次线上、真机或联调故障的定位、修复与回归。
每个案例统一写：背景、目标、本人边界、关键设计、第一条证据、失败路径、验证、结果、限制、如果重做怎样改。
5. 个人项目处理原则（不作为准备主线）
旧个人项目中 AI 参与较多，当前不把它们作为简历主项目、模拟面试主案例或需要背诵的学习内容。面试证明顺序始终是：商业项目 → Unity/C# 基础与业务系统 → 本人亲手完成的当前实操 → AI/Agent 加分能力。
如果面试官追问近期个人练习，只需用一句话守住边界：
我用个人练习恢复 Unity/C# 和验证 AI 工程流程，但其中 AI 参与较多，所以不把项目整体包装成独立成果；我只展开本人已经从零做过、运行过、故意破坏并修复过的具体工具或验证链。
不再在本章记录项目版本、模块清单、代码规模、历史测试数字和待复跑状态。有面试价值的技术内容统一放到后面：
| 要准备的能力 | 本手册内主位置 |
|---|---|
| Unity/C#、UGUI、资源、网络和业务系统基础 | 第 6 章 |
| AI 规格、范围、Apply、Check/Verify 定义和归档 | 第 7 章 |
| AgentLearn 从 Z0 到 Z8 的全部亲手顺序和阶段门 | 第 8.2 节，这是唯一执行入口 |
| RuleSet/Validator、CLI/Pipeline/uauto、MCP、Harness 和 Evidence 的解释 | 第 8.3–8.8 节；只在对应 Z 阶段查阅 |
| M2 安全写入、M3 Agent、M4 扩展、M5 Eval 和作品路线 | 第 9 章 |
| ET 的规则工程通用思想 | 第 8.3 节；ET 专属规则、Entity 示例和许可证仅看第 9.12 节 |
只有 Ledger 中存在本人真实命令、Unity 运行、失败修复和结果证据的练习，才能在面试中升级为“我做过”；其他内容只作为学习资料，不要求记忆项目故事。
6. Unity / C# 与业务系统基础
6.1 基础题统一回答法
每题按四层回答：
- 结论：10–20 秒说清是什么、何时用。
- 机制：解释运行方式、数据和生命周期。
- 项目：绑定一个商业或个人项目例子。
- 边界：说明性能、线程、平台、版本或本人经验限制。
不要从“设计模式名字”开始，也不要背完定义后没有项目落点。
6.2 C# 高频
值类型、引用类型、class 与 struct
- 值类型变量通常直接包含值；引用类型变量保存对象引用。
- 赋值 struct 通常复制值，赋值 class 复制引用；但实际存储位置不能简单等同为“值类型一定在栈、引用类型一定在堆”。
- struct 适合小、稳定、以值语义表达的数据；过大或频繁装箱反而产生复制和 GC 成本。
- Unity 中修改集合里的 struct、属性返回的 struct、
Transform.position等要注意“拿到的是副本还是可写入口”。
装箱、拆箱和 GC Alloc
- 值类型转换到
object或某些接口会发生装箱；再取回具体值是拆箱。 - 高频 Update、UI 刷新、日志格式化、LINQ、闭包和集合枚举中要关注分配。
- 优化顺序是先用 Profiler 找真实热点，再减少频率、缓存、复用或改数据结构，不靠猜测删除所有抽象。
delegate、event、Action、Func
- delegate 是类型安全的方法引用；
Action/Func是常用泛型委托。 - event 限制外部只能订阅/退订，通常只能由声明者触发。
- 项目重点不是语法，而是订阅生命周期：重复订阅、对象销毁后未退订、匿名 Lambda 无法正确移除。
- UI 页面通常在打开/启用时订阅，在关闭/禁用或销毁时解除，并保证多次打开不重复绑定。
闭包和 Lambda
- Lambda 捕获外部变量可能生成闭包对象并延长生命周期。
- 循环变量、异步回调、事件长期持有和 Entity/Unity 对象失效是常见风险。
- 对高频或长生命周期回调，保存稳定 ID/句柄，明确解除时机，不让回调隐式拥有业务对象。
List、Dictionary、HashSet
List<T>：有序、按索引、连续遍历快；查找通常 O(n)。Dictionary<TKey,TValue>：按 Key 平均 O(1) 查询；关注 Key 稳定性、哈希和遍历无业务顺序保证。HashSet<T>：唯一集合、成员判断和集合运算；不保存重复项。- 选择基于访问模式、数据规模和生命周期，不因“字典更快”把小列表全改掉。
接口、抽象类和组合
- 接口表达能力契约，便于替换和多实现；抽象类可以共享状态和基础实现。
- Unity 业务中优先通过小接口和组合控制依赖，不为每个类建立复杂继承树。
- 需要序列化、Inspector、多态或性能时要结合 Unity 实际限制。
async/await 与 Coroutine
- Coroutine 由 Unity 主线程按帧推进，适合等待帧、动画和 Unity 生命周期；不是后台线程。
- async/await 适合表达异步结果、I/O、取消和异常传播，但恢复线程/上下文取决于实现。
- Unity API 通常要求主线程；对象可能在 await 期间销毁，需 CancellationToken、版本号、Owner 或有效性检查。
- 禁止用
async void承载普通业务，除非明确是事件入口且异常可见。
对象池
对象池适合创建/销毁频繁、初始化成本高、生命周期可控的对象。必须定义：创建、获取、重置、归还、容量、超限策略、场景切换清理和重复归还检测。池化错误状态比重新创建更难查，因此不能把所有对象都池化。
6.3 Unity 生命周期与主循环
Awake、OnEnable、Start、OnDisable、OnDestroy
Awake：对象加载/实例化时初始化自身不依赖外部顺序的状态。OnEnable：每次启用执行，适合订阅和可重复激活逻辑。Start：首次启用后的首帧前调用，常用于依赖其他对象已完成 Awake 的初始化。OnDisable：每次禁用执行，适合解除可重复订阅和停止临时行为。OnDestroy：对象最终销毁清理；不能只依赖它处理每次禁用。
回答时说明：脚本执行顺序不应靠 Inspector 偶然排列；需要显式依赖、初始化入口或生命周期管理。
Update、FixedUpdate、LateUpdate
Update：每帧逻辑、输入和非物理表现；使用deltaTime。FixedUpdate：固定时间步，适合物理相关操作；一帧可能执行 0 次或多次。LateUpdate：通常在 Update 后做相机跟随或依赖最终位姿的表现。- 性能问题先减少每帧工作和无效对象数量，再讨论微优化。
Coroutine 常见点
yield return null等待下一帧。WaitForSeconds受timeScale影响；实时等待用对应 realtime 机制。- 协程依附于宿主与激活状态，需明确停止、场景切换和对象销毁行为。
- 协程异常、取消和返回值表达弱，复杂任务可封装为状态机或明确异步抽象。
ScriptableObject
适合共享配置、可编辑数据、资源引用和项目级定义；不应把运行时每个玩家的可变状态直接写回资产。区分“配置资产”和“运行时实例”，特别注意 Editor 下修改资产会持久化。
6.4 UGUI 与 UI 性能
Canvas Rebuild
触发布局、顶点或材质变化可能导致 Canvas 重建。常见问题：大 Canvas 中高频变化、LayoutGroup/ContentSizeFitter 连锁重算、文本频繁更新、隐藏对象仍参与布局。
排查顺序：
- Profiler/UI Details 定位高耗时 Canvas 和 Rebuild。
- 找谁在每帧修改尺寸、文本、激活或层级。
- 将静态与高频动态 UI 拆到不同 Canvas，但避免过度拆分。
- 减少布局嵌套、批量刷新、虚拟化长列表。
- 再检查图集、材质、Mask 和合批。
Draw Call、合批和 Overdraw
- 合批受 Canvas、材质、纹理、层级和裁剪影响。
- 图集减少纹理切换，但要考虑包体、加载粒度和更新。
- Overdraw 是同一像素多次绘制，半透明大图、Mask 和全屏叠层常见。
- 优化必须结合 Frame Debugger、Profiler 和目标设备，不只背“用图集”。
ScrollView 大量 Item
- 使用对象复用和可见区虚拟化。
- 数据与 View 分离，滚动时只绑定进入可见区的项。
- 避免每项 Update、复杂 Layout 和重复字符串/图片加载。
- 处理异步加载旧回调覆盖新 Item 的问题，可用版本号或绑定 Key。
UI 事件泄漏与重复刷新
页面多次打开时最常见：重复订阅、匿名 Lambda 无法退订、静态事件持有页面、Controller 与 View 都刷新同一数据。解决方案是明确订阅所有者、幂等绑定、关闭时解除，并用日志或计数验证一次事件只触发一次刷新。
6.5 资源与热更新
Resources、AssetBundle、Addressables
- Resources 简单但难以细粒度管理和更新，目录内容会进入构建。
- AssetBundle 提供资源打包、依赖和远端更新能力，但需要管理 Manifest、引用计数、版本和卸载。
- Addressables 在 AssetBundle 之上提供地址、依赖、异步句柄和内容更新工作流；不是“自动解决所有内存问题”。
AssetBundle.Unload
Unload(false)卸载 Bundle 容器，已加载对象仍存在；后续重复加载可能产生资源实例和管理问题。Unload(true)同时卸载从中加载的对象，仍被场景或 UI 使用时可能丢失。- 实际项目需要引用计数、依赖图、统一句柄和场景切换策略。
热更新基本流程
版本检查
→ 获取远端清单
→ 比较本地版本/Hash
→ 下载临时文件
→ 校验完整性
→ 原子替换
→ 更新版本记录
→ 加载脚本/资源
→ 失败重试或回滚本人边界：有 Lua 业务与 C#/Lua 事件交互、Excel to Lua、EmmyLua 工具和 Utage 接入经验；不包装成 xLua/ToLua VM、绑定生成、解释器或热更底层专家。
6.6 网络、一致性与重连
TCP、UDP、粘包拆包
- TCP 是可靠字节流，没有消息边界；应用层需长度字段、固定头或分隔协议处理粘包/拆包。
- UDP 保留数据报边界但不保证可靠、顺序或不重复；可靠机制需自行设计。
- 游戏协议选择取决于实时性、可靠性、带宽、复杂度和服务端架构。
客户端预校验与服务端权威
- 客户端预校验提升反馈，但不能决定背包、制造、奖励等最终结果。
- 服务端负责权威校验、状态变更和防作弊。
- 客户端收到结果后根据服务端数据刷新；预测或乐观更新必须有回滚/校正。
重复请求、旧回包与幂等
- 请求带唯一 ID、序列号或版本号。
- 服务端高价值操作设计幂等。
- UI 异步回包绑定页面/对象当前版本，旧回包不覆盖新状态。
- 超时不等于失败，重试前要确认服务端是否已经执行。
断线重连完整状态机
检测断线
→ 停止或隔离新业务请求
→ 退避重连
→ 连接恢复
→ 重新认证/登录
→ 拉取关键权威数据
→ 重建订阅和页面状态
→ 处理断线期间结果
→ 恢复交互不能只回答“重新连 Socket”。绑定《七星传》真实重连经历和《七日世界》制造状态恢复。
6.7 性能定位
统一流程：
- 明确平台、场景、基线、帧率和复现步骤。
- 判断 CPU、GPU、内存、I/O、网络还是加载瓶颈。
- 用 Profiler/Frame Debugger/Memory Profiler 找真实热点。
- 做最小改动并对照复测。
- 检查副作用、目标设备和长时间稳定性。
常见 CPU：脚本 Update、布局重建、序列化、反射、物理、动画、GC。
常见 GPU：Overdraw、Draw Call、Shader、分辨率、后处理、阴影。
常见内存：资源重复加载、引用未释放、事件持有、静态缓存、纹理/网格过大。
禁止在没有测量时说“优化了 50%”。安全表述是问题、证据、改动、前后环境和仍有限制。
6.8 数据结构、算法和 3D 数学
P0：数组/链表、栈/队列、哈希、树、排序/二分、时间/空间复杂度、LRU 基本思路。
3D 数学：
- Dot：夹角、朝向、视野前后判断。
- Cross：法向、左右方向、垂直向量。
- Quaternion：避免直接欧拉角累积和万向节问题；使用插值和组合旋转。
- 坐标空间：世界/局部转换，方向与点的转换不同。
- 距离比较：只比较远近时可用平方距离避免开方，但不要在无热点处过度优化。
6.9 系统题八段式
任何业务系统按以下顺序：
- 用户目标和核心流程。
- 配置与数据模型。
- 状态所有权和生命周期。
- 请求/事件/调用链。
- UI 和表现刷新。
- 边界、异常和一致性。
- 测试、日志和人工验收。
- 扩展、性能、回滚和取舍。
制造系统
绑定《七日世界》：配方、材料、设施、队列、Timer、服务端权威、重连、背包满、多个入口和数据迁移。
红点系统
叶子业务判断 → 父级聚合 → 增量刷新 → UI 订阅。重点回答去重、依赖、缓存失效、页面生命周期和调试工具。
新手引导
大节点持久化 + 小步骤条件驱动。重点回答点击/等待/超时、UI 路径变化、跳过、恢复和业务解耦。
AVG 编辑器
策划输入 → 编辑工具 → Schema/校验 → 导出 → Runtime 命令解释 → 表现扩展。重点回答错误暴露、版本兼容和新增命令。
背包与掉落
物品定义、实例/堆叠、容量、操作请求、世界容器、存档/快照、重复操作和服务端权威。适合作为 Spec/Harness 主案例。
UI 框架
页面路由、Controller/View/Model、数据所有权、事件订阅、异步加载、层级、缓存和关闭清理。绑定《七星传》的真实刷新链。
6.10 基础检查清单
- C# P0 题能按“结论—机制—项目—边界”回答。
- 能画 Unity 生命周期和异步对象失效问题。
- 能走一次 UI 卡顿完整排查，不只列技巧。
- 能画制造请求、服务端权威、旧回包和重连恢复。
- Lua 业务经验与 xLua 底层边界回答稳定。
- Dot/Cross/Quaternion 能写简单项目例子。
7. AI 协同 Change 工作流
本章只回答“一个任务怎样被规格化、限制范围、实现、检查、验证和归档”。本人如何按 Z0–Z8 操作、命令怎样进入 Unity、Harness 怎样执行、Evidence 怎样保存，统一放在第 8 章。
7.1 人工总结：30 秒箭头复习卡
只看这张图即可；细节需要时再查第 7.2–7.11 节。
业务任务
→ Change：一项任务一个 Change；太大就拆成多个可独立验证的 Change
→ Proposal：背景问题 / 目标 / 修改范围 / 风险与人工审批 / 模块边界
→ Specs：条件 → 行为 → 状态 → 表现 → 无副作用
→ Design：数据所有权 → 调用链 → 接口 → 状态/生命周期 → 错误/兼容
→ Tasks：拆成小而可执行、可单独验证的任务
→ Apply：本人一次一个 Task → 只改白名单 → AI Review Diff / 测试 / 未知点
└─ 需求、接口或生命周期变化：立即停止，回 Proposal / Design
→ Check：Diff 范围 → 接口/依赖/生命周期/错误 → 编译/Analyzer
→ Verify：本人按 Specs 跑正常/边界/失败/无副作用 → AI 辅助对照 → 本人最终验收
→ Archive：同步规格 / 证据 / 限制 / 遗留项只记三句话：
- Check 查工程是否达标；Verify 验行为是否符合 Specs。
- AI 负责调查、解释、Review 和辅助诊断；本人负责首版实现、真实执行、风险和最终接受。
- 没有可复现证据，就不算完成。
需要面试口述时直接看第 7.11 节，本节不再重复展开。
7.2 五步总览
| 阶段 | 输入 | AI 主要动作 | 输出 | 人工 Gate | 失败返回 |
|---|---|---|---|---|---|
| 1. Propose（定） | 需求、代码、规则 | 调查并起草范围、规格、设计、任务 | Proposal/Specs/Design/Tasks | 目标、范围、重大设计 | Propose 内修订 |
| 2. Apply（做） | 已批准变更包 | 解释 API、Review 当前小步和测试遗漏 | 本人写出的可审查 Diff、进度 | 本人实现首个成功路径；范围和架构变化停下 | Apply；设计错回 Propose |
| 3. Check（查） | 当前 Diff | Review Diff、依赖和错误机制 | 本人执行编译/Analyzer/测试的原始结果 | 第一条失败、重大架构和是否继续 | Apply |
| 4. Verify（验） | Specs 和可运行实现 | 提供用例映射、辅助比较结果和诊断 | 本人执行 Harness/Unity/错误路径形成的证据包 | 真实体验、副作用和最终业务验收 | Apply；规格错回 Propose |
| 5. Archive（归） | 实现和证据 | 同步主规格、记录限制、归档 | 新规范源与审计历史 | 最终接受 | 留在 Verify 或返回前面 |
“定、做、查、验、归”是本人的工程口径，不是 OpenSpec 官方固定五条命令。OpenSpec Core 常见路径为
Explore（可选）→ Propose → Apply → Sync（可选）→ Archive；Expanded 可包含New → FF/Continue → Apply → Verify → Archive。其中 Check 是项目额外增加的确定性工程 Gate。
口诀：
Proposal 管范围，Specs 管结果，Design 管实现，Tasks 管执行，Evidence 管完成。
7.3 Propose：写代码前回答四个问题
- 为什么改、改到哪里？
- 正确的可观察结果是什么？
- 技术上怎样实现、为什么这样选？
- 接下来按什么顺序执行和验证？
Explore（可选）
适合需求模糊、入口不清或存在多方案时。只调查代码、依赖、现有模式、风险和候选方案，不生成实现，不以“先写再看”替代调查。
Proposal
至少包含：
- 背景和问题。
- 本次目标。
- 允许修改范围。
- 明确非目标。
- 风险和人工批准点。
- 影响模块和迁移/兼容边界。
Specs
Spec 写可观察行为，不写内部实现：
GIVEN 玩家拥有不可丢弃的任务物品
WHEN 玩家请求丢弃该物品
THEN 请求失败并返回明确错误
AND 背包数量、世界掉落和存档均不变化每个核心需求至少覆盖正常、边界和失败路径。
Design
说明数据所有权、调用链、接口、状态、生命周期、错误、兼容、回滚和关键取舍。它不是逐行代码清单。
Tasks
每项任务必须小、可执行、可验证，有明确依赖和完成条件；不能写“完成整个背包系统”这种宽泛 Todo。
7.4 Apply：本人小步实现，AI 做解释与 Review
执行顺序：
- 本人和 AI 都先读取已批准 Artifact 和项目规则。
- 本人每次只实现一个可验证 Task；AI 不一次生成整个学习模块。
- 只修改白名单目录和文件。
- 本人提交当前最小 Diff、测试和第一条失败，AI 再做 Review。
- 本人执行编译和测试；AI 不能用推测结果代替原始输出。
- 发现需求、接口或架构变化时停止，先更新 Propose 产物。
禁止：
- 为了编译通过扩展到无关重构。
- 关闭 Analyzer、删除断言或降低预期。
- 静默吞异常、返回默认成功或创建假数据。
- 未经批准修改 Scene、Prefab、Packages、公共协议、存档格式或构建设置。
7.5 Check：确定性工程门禁
检查：
git diff是否只在范围内。- 公共接口、依赖方向、生命周期和错误处理是否合理。
- C# / Unity 编译是否通过。
- Analyzer、asmdef、配置或静态规则是否通过。
- 是否出现新警告、重复系统、硬编码、静默兜底或意外资源变更。
Check 通过只表示工程结构和编译层面达标，不表示玩法正确。
7.6 Verify：五层行为验证
| 层 | 验证什么 | 不能证明什么 |
|---|---|---|
| Spec 映射 | 每个需求是否有实现和证据 | Spec 本身是否理解正确 |
| 纯逻辑/EditMode | 数据、算法、配置、错误和不变量 | 场景、帧、物理和 UI 真实表现 |
| PlayMode/UnityHarness | 生命周期、协程、场景、UI 集成 | 真机、长时间性能和全部网络时序 |
| Unity Editor/CLI；M3C 后可加 MCP | 当前状态、Console、测试、结构化结果和受控操作 | 业务语义与用户体验 |
| 人工验收 | 真实流程、画面、手感、限制 | 未执行和未观察的路径 |
故意破坏
至少故意破坏一条关键逻辑，确认测试会失败。例如把“任务物品禁止丢弃”判断反转或删除。如果测试仍绿，优先修测试和 Spec 映射，而不是庆祝通过。
7.7 Archive：规范和证据沉淀
只有在以下条件满足后归档：
- 任务与实现一致。
- Check 和 Verify 结果完整。
- 主规格已经同步。
- 已知限制、未覆盖项和回滚方法已记录。
- 没有用“先归档以后再补证据”掩盖未完成。
7.8 AI 与人的职责边界
| AI 可以负责 | 本人必须负责 |
|---|---|
| 调查代码入口和调用链 | 决定真正业务目标 |
| 起草 Proposal/Specs/Design/Tasks | 确认范围、非目标和业务语义 |
| 解释 API、Review 本人小步代码和测试遗漏 | 写首个 Contract、成功路径、关键测试和安全判断 |
| 建议编译、Analyzer、Harness 命令并分析原始输出 | 亲自执行 Unity、CLI、编译、测试和故意失败 |
| 整理本人提供的日志、报告和证据索引 | 作第一原因判断，确认结果真实并写 Ledger |
| 暴露未知、失败和限制 | 真实体验、最终验收和产品/工程责任 |
最重要的一句：
AI 可以调查、解释、Review、建议和整理，但不能替本人完成学习实践、定义业务正确性或批准自己的结果。
7.9 风险分级
| 等级 | 示例 | AI 权限 | 必须 Gate |
|---|---|---|---|
| R0 只读 | 查代码、解释调用链、整理日志 | 只读 | 人工核对关键结论 |
| R1 低风险 | 注释、测试数据、小菜单、明确样板 | 限定文件 | Diff + 编译 |
| R2 中风险 | 单一业务模块、UI 逻辑、普通测试、SO 字段 | 独立分支/限定范围 | Diff + 编译 + 测试 + 运行 |
| R3 高风险 | 公共接口、存档、网络、异步、Scene/Prefab 批改 | 先方案后授权 | 架构审查、完整回归、人工批准 |
| R4 极高风险 | 数据迁移、发布、密钥、线上、删除资产、大重构 | 默认只输出方案 | 人工实施或逐步授权 |
7.10 失败应该退回哪里
| 失败 | 返回 | 禁止动作 |
|---|---|---|
| 需求含义或范围变化 | Proposal/Specs | 在代码里暗改需求 |
| 技术方案不成立 | Design | 继续叠补丁 |
| 任务拆分错误 | Tasks | 同时扩展多个模块 |
| 编译/Analyzer 失败 | Apply 修复后再 Check | 关闭规则制造绿色 |
| 运行行为不符合 Specs | Apply 后再 Verify | 直接改断言 |
| Verify 发现 Specs 错 | 回 Propose | 让测试迎合错误实现 |
| 证据不完整 | 留在 Verify | 提前 Archive |
| MCP 超时 | 查询 Unity 真实状态 | 重复发送高风险命令 |
7.11 AI 流程面试回答
一句话：
需求先规格化，我在白名单内小步实现，AI 负责调查、解释和 Review；修改必须由我亲自经过 Diff、编译、Harness、Unity 运行和最终验收，没有可复现证据就不算完成。
30 秒：
我的流程不是让 AI 自由写代码，而是先用 Change 锁定范围、行为、设计和任务。我亲手完成首个最小实现并执行 Unity、CLI、编译、测试、故意失败和人工路径；AI 负责调查、解释、Review 和在我提出原因假设后辅助诊断。结果通过 Check、Harness、Evidence 和人工 Gate 后才归档；MCP 只在 M3C 作为可选入口。没有本人可复现证据就不算完成。
8. AgentLearn 从零学习手册与 Unity AI 工程闭环
8.1 一条贯穿主线：从 Change 到可复现 Evidence
先只记住这一句：
第 7 章决定改什么和怎样验收；Check 把规则变成确定性门禁；Unity CLI/Pipeline 把命令送进 Unity；uauto 负责调用、编排和保存证据；MCP 只是可选入口；Harness 依据 Specs 执行行为验证；Evidence 把结果变成可复查事实。
Change：Proposal → Specs → Design → Tasks
↓
Apply：本人每次只实现一个 Task；AI 只解释和 Review；只改白名单
↓
Check：Diff → 依赖/生命周期/错误 → 编译 → Analyzer/确定性测试
↓
Execute：Unity CLI → Pipeline → 白名单 Action
↓
Orchestrate：uauto；MCP 可选
↓
Verify：本人执行 Test / Harness / Unity → 正常、边界、失败、无副作用；AI 辅助对照
↓
Evidence：requestId / runId / 输入 / 输出 / 日志 / Diff / 人工结论
↓
Archive；Z8 通过后再进入第 9 章的 M2–M5这些层不是相互替代：CLI 调用成功不等于业务正确，编译通过不等于 Spec 通过，Harness 自动通过也不等于人工体验验收完成。
8.2 AgentLearn 唯一执行入口：本人从 Z0 做到 Z8
这一节已经把 00-start-from-zero.md 的核心流程、本人/AI 分工、阶段门、关键命令和证据要求完整并入总手册。只看这一节也能决定今天做什么；项目内分册只用于查更长的代码骨架、参数解释和排错案例，不再承担第二套执行顺序。
8.2.1 使用规则与当前起点
- 严格按 Z0→Z8 推进，不跨阶段安装或调用后续能力。
- 每次只完成一个可验证行为；本人写第一版、执行命令、看第一条错误并作第一判断。
- Unity 编译、自动测试、人工操作、CLI/uauto、关闭重开分别留证，不能合并成一个“通过”。
- AI 只解释、Review 和基于真实错误协助诊断；不得一次生成完整
Assets/AgentLearn、.uauto或 Action 模块。 - 当前从
Session 01 / Z0开始。后文代码和输出在本人实跑前都只是教学目标。
机器级 unity/uauto 存在，不等于项目已经导入 Pipeline、共享包或 Action。项目事实以当前 ProjectSettings、Packages、源码、Console、测试和 Ledger 为准。
8.2.2 唯一阶段顺序与里程碑映射
Z0 Unity 模板基线
→ Z1 UI 规则与真实夹具
→ Z2 Core Contract / Guard / Snapshot / RuleSet / Validator
→ Z3 Editor 查询 / Importer Adapter / Report / Window
→ Z4 EditMode + 人工只读 + 故意失败 + 无写入门
→ Z5 Unity CLI + Pipeline 项目导入
→ Z6 uauto 初始化 + 共享包编译
→ Z7 三个只读白名单 Action
→ Z8 直接 CLI / Runner / 错误路径 / 重开复验
→ M2 安全写入
→ M3A 固定 JSON Adapter
→ M3B 模型 Tool Calling
→ M3C 可选只读 MCP
→ M4 第二工具 / RAG / Tracing
→ M5 固定 Eval 与作品化为避免旧资料里的 M1 含义冲突，本手册执行时只使用 Z 编号：
| 范围 | 里程碑含义 | 不能提前做什么 |
|---|---|---|
| Z0–Z1 | M0 准备：项目事实、规则和 Fixture | 不写 Validator，不接自动化 |
| Z2–Z4 | M1A：普通 Unity 本地只读工具 | 不导入 Pipeline/uauto，不写 Action |
| Z5–Z8 | M1B：自动化只读工具闭环 | 不做 Importer 写入，不接模型 Agent |
| M2 | Plan/Confirm/Apply/Verify 安全写入 | Z8 未通过不得开始 |
| M3–M5 | Agent 接入、扩展、Eval 与作品 | Tool Core 和写入状态机不稳定不得开始 |
8.2.3 每次练习的固定闭环
每个 Session 都走同一条链，不因 AI 参与而省略步骤：
本人定义目标、非目标、允许范围和完成门
→ 本人画输入 / 数据 / 调用 / 副作用链
→ 本人写一个最小实现或执行一个最小操作
→ 等 Unity 编译，先看第一条 Error
→ 跑与本次增量匹配的最小确定性测试
→ 本人在 Unity/CLI 中走真实路径
→ 故意破坏一个关键条件
→ 本人先写原因假设和准备验证的证据
→ AI 基于源码与真实错误做 Review/诊断
→ 本人执行最小修复并回归
→ 写 Ledger、证据路径和未覆盖风险
→ 脱稿口述，并做一个不依赖 AI 的小改阶段门高于日历。7/14/30 天只是节奏建议，不能用“今天是第几天”替代通过证据。
8.2.4 全阶段本人/AI 边界
| 内容 | 本人必须负责 | AI 可以协助 | AI 不得替代 |
|---|---|---|---|
| 规则与范围 | 决定业务规则值、白名单、风险和非目标 | 解释 Unity 字段、检查遗漏和冲突 | 猜规则值、扩大目录或默认自动修复 |
| 代码 | 写首个 Contract、成功路径、测试和关键安全判断 | Review 分层、Schema、错误和测试覆盖 | 一次生成整套 Core/Editor/Action 后让本人只点运行 |
| 操作 | 打开 Unity、执行 CLI、观察 Console/Test Runner/Inspector | 给出命令含义和排错顺序 | 伪造命令输出、编译、测试或人工验收 |
| 诊断 | 先记录第一条失败、自己的原因假设和验证办法 | 基于真实证据定位机制和最小修复 | 吞错误、补假数据或静默改走别的路径 |
| 验收 | 判断业务表现、副作用、风险和是否进入下一阶段 | 对比结构化结果、整理缺口 | 代替人工确认写入或把自动测试说成人工通过 |
| 证据与面试 | 确认证据真实、写 Ledger、脱稿解释和现场小改 | 整理索引、改进表达 | 把规划、教学代码或历史记录包装成当前成果 |
8.2.5 Z0：确认 Unity 项目基线
目的： 先分清模板、业务代码、项目包、机器级工具和本地生成文件，不在错误起点上学习。
本人亲手：
- 用 Unity 打开
D:\Project\AgentLearn，等待导入、编译和 Domain Reload 完成。 - 记录 Editor 路径与版本、Console Error/Warning、当前场景和 Git 状态。
- 打开 Test Runner，确认模板已有 Test Framework 能使用。
- 确认
Library、Temp、Logs、解决方案文件和 URP 模板设置不是业务成果。
AI 只协助： 解释目录、日志和 Unity 概念；不远程替你勾“已确认”。
故意失败： 本阶段不制造项目改动；如果 Console 有真实错误，只记录第一条并查明来源，不先清空或忽略。
完成门与证据： Session 01 / Z0 中记录版本、首次导入、Console、Test Runner、场景、Git 和本人结论。Z0 未完成时不进入 Z1，也不运行安装命令。
8.2.6 Z1：本人定义 UI 规则并制作真实 Fixture
目的： 先决定“什么叫正确”，再写检查器。首个允许根固定为：
Assets/AgentLearn/Samples/UITextures/
Compliant/
InvalidSingle/
InvalidMultiple/本人亲手：
- 建立 V1 规则表：路径、命名、Texture Type、Sprite Mode、Mipmap、Max Size、sRGB 和 Alpha。
- 每条规则写稳定 Rule ID、期望值、严重级别、理由、是否允许后续自动修复和
rulesVersion。 - 第一版不自动处理 Compression 和平台 Override；这些属于 M2 以后扩展，不能混进当前最小闭环。
- 导入至少 2 张合规、4 张单项违规、2 张多项违规 PNG。
- 在 Inspector 中逐张设置并点击 Apply，记录“文件 → 预期诊断 → Inspector 实际值”。
AI 只协助： 解释字段、Review 规则矩阵和样本是否能单独击中规则；规则值与例外仍由本人决定。
故意失败： 把一张合规样本临时改成单项违规，确认你能只凭规则表判断应命中哪个 Rule ID；再恢复并 Apply。
完成门与证据： 规则表、Fixture manifest、预期诊断和 Inspector 实际值一致。本阶段不得出现 Importer 写入代码。
8.2.7 Z2：从空文件建立确定性 Core
目的： 让规则在没有 EditorWindow、CLI、uauto 和模型时也能稳定测试。
本人按顺序逐个建立：
AgentLearn.Core.asmdef，Core 不引用UnityEditor。- 最小 Tool Contract、显式
ToolError/Result和统一错误结构。 - 只允许 canonical 目录的路径 Guard。
- 普通 C# 数据：Snapshot、RuleSet、Diagnostic、Report。
- 纯
UiTextureValidator；输入相同应得到稳定、可排序的结果。 - 合规、单项、多项、边界、非法路径和稳定顺序的 EditMode Test。
每新增一个类型，都执行“保存 → Unity 编译 → 第一条错误 → 本人判断 → 最小修复 → 最小测试 → Ledger”，不要一次生成整个目录。
AI 只协助： Review 类型职责、Contract、Guard、错误模型和漏测；不替本人决定规则或宣称编译通过。
故意失败： 临时改错一个断言，保存真实红灯；恢复后重新跑绿。另用临时错误依赖证明 Core 不能引用 UnityEditor，恢复后确认无残留。
完成门与证据： Core 无 UnityEditor；当前 Unity 编译和规则测试有真实结果；本人能脱稿增加一条简单规则并回归。
8.2.8 Z3：实现普通 Editor 只读工具
目的： 先把真实 Unity 读取工具做成立，再考虑外部调用。
本人按链实现：
Search Assets
→ TextureImporter Adapter 读取 Snapshot
→ Validator
→ Report
→ 最小 EditorWindow- 建立
Editor与Editor.Testsasmdef，依赖方向固定为Tests → Editor → Core。 - 实现只读资源搜索、Importer→Snapshot、编排和最小窗口。
- 窗口明确展示正常结果、空结果、非法路径和环境错误。
- 不调用
SaveAndReimport，不修改 Fixture，不用默认演示数据掩盖空结果。
AI 只协助： Review Unity API 隔离、副作用、错误分类和测试遗漏。
故意失败： 传越权路径和不存在路径，确认它们与合法零匹配是三种不同结果。
完成门与证据： 结构化报告、窗口观察、错误路径、扫描前后 Fixture 和 Git 对比均有记录；三个只读能力可脱离 CLI/uauto 独立工作。
8.2.9 Z4：通过 UI 只读工具阶段门
Z4 不是继续堆功能，而是把 Z1–Z3 变成可复现事实。
本人亲手验收：
- Core、Editor、Editor.Tests 在当前 Unity 编译。
- 指定 EditMode Test 有真实结果，不是只存在测试源码。
- EditorWindow 走正常、空结果、非法路径和关闭重开。
- 至少一个故意失败由本人先定位、修复并回归。
- 做一次不依赖 AI 的规则小改并补测试。
- 对 Fixture 内容和
.meta做 before/after，证明扫描没有业务写入。
AI 只协助： 在本人写出失败假设后辅助诊断、Review 回归范围。
完成门与证据： compiled、automated green 和 manual runtime accepted 分别有证据；任何一项缺失都不得进入 Z5。
8.2.10 Z5：本人导入 Unity CLI/Pipeline 项目能力
目的： 区分机器级 Unity CLI 与项目内 Pipeline，并亲手观察安装改动。
先做只读确认：
Set-Location -LiteralPath 'D:\Project\AgentLearn'
unity --version
unity --help
unity pipeline list-versions --format json本学习批次计划固定 com.unity.pipeline 0.4.0-exp.1；它不是永久“最新版”声明。只有本人本次 list-versions 仍看到该版本时，才执行：
$PipelineVersion = '0.4.0-exp.1'
unity pipeline install `
--project-path 'D:\Project\AgentLearn' `
--package-version $PipelineVersion本人亲手： 核对 manifest.json、packages-lock.json、UPM、编译、Domain Reload、Console、unity status 和 unity list。不使用 --force，不顺手升级。
AI 只协助： 解释 help、命令和 Diff；不能替你选版本、吞掉安装失败或修改 PackageCache 伪装修复。
故意失败： 优先保留真实安装/连接第一条错误；若没有真实失败，只做不存在命令的 help 对照，不破坏包状态。
完成门与证据： 原始 CLI 输出、包文件 Diff、Unity 编译与 Console 当前证据齐全，并能解释安装实际修改了什么。
8.2.11 Z6：本人初始化 uauto 和共享自动化包
目的： 让项目产生可读的自动化配置，但此时仍不假装已有业务 Action。
先用 uauto help 复查当前命令；本学习批次的批准包源为：
uauto init `
--project-path 'D:\Project\AgentLearn' `
--project-id 'agentlearn' `
--package-source 'https://github.com/kaku1210/unity-automation-kit.git?path=/Packages/com.kaku.unity.automation#v0.1.1'本人亲手：
- 检查 manifest 新增项、lock 解析版本与 commit。
- 逐字段理解
.uauto/project.json的项目、版本、超时、证据目录和受控策略。 - 回 Unity 等共享包编译和 Domain Reload，记录 Console。
- 在项目 Module 尚未注册时，确认
uauto actions是空白名单或明确报告“无项目 Action”，而不是伪造三个条目。
AI 只协助： 解释配置和真实错误；不得手写一份 .uauto 冒充 init 结果，也不得增加静默 fallback。
完成门与证据： init 原始输出、manifest/lock、commit、project.json、共享包编译和空 Action 状态均有记录。
8.2.12 Z7：把已验证 Tool Core 注册成三个只读 Action
目的： 外部只能调用项目明确允许、已经测试的能力，而不是任意 Unity API。
本人亲手实现：
AgentLearnAutomationModule。- 显式 Bootstrap/Register，不扫描任意方法自动开放。
- 三个 Action：
agentlearn.search_assetsagentlearn.get_import_settingsagentlearn.validate_ui_textures
- 外部 canonical JSON Contract、内部强类型 DTO 映射、Schema、路径白名单、错误码、风险、幂等和注册测试。
- Handler 复用 Z2–Z4 的 Tool Core，不复制第二套规则；仍禁止 Importer 写入。
AI 只协助： Review Schema、白名单、安全边界、错误一致性和漏测；本人写首个 Action/Handler 绑定并解释调用链。
故意失败： 未知 Action、缺字段、越权路径、非法 limit 和重复 requestId 至少各有明确拒绝或错误语义。
完成门与证据： Unity 编译、Module/Action 测试、uauto actions 只出现预期三项；代码存在不等于这三项已完成。
8.2.13 Z8：完成 A–G 双入口、错误路径和恢复验收
目的： 证明同一个只读能力能从两个入口稳定到达同一 Registry/Handler，并且失败明确、资源不被修改、重开后仍可复现。
按 A–G 顺序执行：
| 顺序 | 本人操作 | 必须观察 |
|---|---|---|
| A 环境 | 核对项目、Unity、CLI、包、.uauto、Console 和证据目录 | 不要求尚未创建的 scenario 预先存在 |
| B Doctor | uauto doctor --project-path 'D:\Project\AgentLearn' | manifest → CLI → Pipeline → bridge → Registry |
| C Actions | uauto actions --project-path 'D:\Project\AgentLearn' | 只列三个正式白名单 Action |
| D Health | 直接 unity command ... uauto_health | requestId/runId、项目和包信息、错误结构 |
| E 双入口 | 直接 CLI 与 uauto invoke 调同一个 search payload | 业务 data/diagnostics 语义一致；外层 ID/耗时可不同 |
| F 三 Action | 每个 Action 走正常、合法零结果、非法/越权；再测未知 Action | 空结果、目标不存在、越权、Schema 错误不能混成成功 |
| G Evidence | 保存 Console、原始 JSON、stderr、错误码、before/after 和本人结论 | 关 Unity 后重开，再复跑关键路径 |
代表性命令模板：
$ProjectPath = 'D:\Project\AgentLearn'
$RunId = 'manual-z8-YYYYMMDD'
$Payload = '{"rootPath":"Assets/AgentLearn/Samples/UITextures","limit":50}'
unity command --project-path $ProjectPath uauto_health `
--requestId 'manual-health-001' `
--runId $RunId
unity --json command --project-path $ProjectPath uauto_invoke `
--requestId 'manual-direct-search-001' `
--runId $RunId `
--actionId 'agentlearn.search_assets' `
--payloadJson $Payload
uauto invoke `
--project-path $ProjectPath `
--action 'agentlearn.search_assets' `
--payload $Payload参数名和 envelope 以本人在 Z7 实现的 canonical Contract、当前 help 和真实输出为准；模板不是运行证据。
AI 只协助： 对比两条结构化结果，基于第一条真实错误辅助定位；不能替本人操作、判断副作用或宣布重开通过。
无写入边界： .uauto/evidence 写入属于预期证据副作用；“无资源写入”只针对纳入 before/after 的 Assets/AgentLearn/Samples/UITextures 及其 .meta，不能扩大成“整个项目没有任何文件变化”。
完成门与证据： raw output、requestId/runId、错误码、Fixture before/after、scenario 和关闭重开复验齐全；这时才判断是否 resume-ready。A–G 属于 Z8；写入、Agent 和 Eval 不再混入“H”冒充当前验收。
8.2.14 Ledger、证据梯子与允许宣称
每次 Ledger 至少记录：
- Session、阶段、目标、非目标和允许路径；
- 开始前本地事实；
- 本人亲手输入、文件、命令与操作；
- AI 协助范围；
- 第一条失败、本人原因假设、验证、修复与回归；
- 编译、自动测试、人工 Unity、CLI/uauto 和重开结果；
- 原始证据路径、未覆盖风险和三分钟口述。
状态只能单向逐级升级：
| 状态 | 需要的证据 |
|---|---|
planned | 只有设计、教程或待办 |
implemented | 本人实现的源码和配置存在 |
compiled | 当前源码在目标 Unity 中编译成功 |
automated green | 指定测试/scenario 的当前原始结果通过 |
manual runtime accepted | 本人完成正常、空、错误和副作用路径 |
resume-ready | 新会话或关闭重开后可依据配置和证据重复成功 |
| 可作为面试证据 | 本人能脱稿解释、现场小改、复现失败并守住边界 |
命令卡住时必须设置明确超时并保留第一现场，不做无界等待和盲目重试。
8.2.15 Z8 后的唯一顺序与可选深挖资料
Z8 全部门通过后，才进入第 9 章：M2 安全写入 → M3A 固定 JSON → M3B 模型 Tool Calling → M3C 可选 MCP → M4 扩展 → M5 Eval/作品。安全写入和模型 Agent 不得倒置。
需要更长代码或命令解释时，可在本机查以下补充材料；它们不能改变本节顺序：
| 需要深挖 | 本地补充材料 |
|---|---|
| Z1–Z4 的完整 C# 教学骨架与 Fixture 细节 | Docs\01-ui-texture-tool-from-zero.md |
| Z5 的 CLI/Pipeline 参数、三种执行模式与排错 | Docs\07-unity-cli-and-pipeline-latest-learning-guide.md |
| Z6–Z8 的全部参数、JSON 转义、A–G 细节 | Docs\06-unity-cli-pipeline-uauto-from-zero.md |
| M2–M5 的 Contract、状态机与 28 个 Eval 详单 | Docs\03-agent-mcp-eval-from-zero.md |
| 每次真实进度 | Docs\practice-ledger.md |
8.3 Check 与规则工程化：把“请遵守规范”变成会失败的门禁
第一次阅读只看 8.3.1 → 8.3.2 → 8.3.8，先弄懂概念和操作顺序；真正动手时只在第 8.2 节进入对应 Z 阶段后，再回来对照中间的代码。
8.3.1 先分清楚：这里不是四个连续步骤，而是四种问题的处理办法
规则工程化，就是把“大家记得这样做”变成机器能读取的规则、稳定的判断代码、明确的错误结果和可以故意跑失败的测试。
原表中的四种实现方式不是要求你全部依次执行，也不是同一种技术的四个版本。你要先问：我现在想检查的到底是资源值、程序集依赖、源码写法，还是运行后的真实行为？
要检查某张贴图当前是不是 Sprite？
→ Snapshot + RuleSet + Validator
要禁止 Core 代码依赖 UnityEditor？
→ asmdef 分层 + C# 编译
代码本来能编译，但想强制 namespace、命名或特定写法？
→ Roslyn Analyzer
要证明命令运行后真的拒绝越权，而且没有改资源？
→ Test / Harness + Unity 实际调用先看中文名词表：这些东西分别是什么
| 英文名词 | 中文简单说法 | 最直白的目的 | 它属于什么 |
|---|---|---|---|
Snapshot | 当前状态快照 | 把 Unity 当前真实设置抄成一份普通数据，方便比较和测试 | AgentLearn 自定义 C# 数据类 |
RuleSet | 规则标准表 / 合格标准 | 集中写明“正确状态应该是什么” | AgentLearn 自定义 C# 数据类 |
Validator | 规则检查器 | 比较“当前值”和“标准值”，找出不一致 | AgentLearn 自定义纯 C# 逻辑 |
Diagnostic | 问题明细 / 诊断项 | 把每一处问题写成带编号、实际值和期望值的结果 | AgentLearn 自定义 C# 数据类 |
Importer | Unity 资源导入设置对象 | 让 Editor 读取贴图的 Texture Type、Mipmap 等真实设置 | Unity 官方 Editor API |
Adapter | Unity 数据读取桥 / 适配层 | 把 TextureImporter 转成 Core 能理解的 Snapshot | 项目中的工程分层角色 |
asmdef | 代码模块边界文件 | 规定一组代码能引用谁、在哪个平台编译 | Unity 官方 Assembly Definition 资源 |
Roslyn Analyzer | C# 源码规范检查器 | 检查“虽然能编译，但违反团队源码规则”的代码 | .NET/Roslyn 编译器扩展 |
Test | 单项自动测试 | 给一个确定输入，自动断言输出是否正确 | NUnit / Unity Test Framework 测试 |
Fixture | 固定测试样本 | 准备结果已知的合规和违规输入，保证问题能重复出现 | 通用测试概念 |
Harness | 整套验证台 | 准备环境、执行调用、处理超时、比较前后状态并收集结果 | 项目自建的测试编排概念 |
Gate | 放行门禁 | 根据检查结果决定通过、警告还是阻断 | 工程策略，不是 Unity 按钮 |
Evidence | 可复查证据包 | 保存输入、输出、日志、Diff、测试结果和人工结论 | 工程记录 |
Action | 白名单动作 / 可调用功能 | 让外部工具只能调用项目明确注册的能力 | AgentLearn 自动化契约 |
先记住它们在同一个案例中的位置：
TextureImporter（Unity 里的真实贴图设置）
↓ Adapter 读取并转换
Snapshot（当前实际值） + RuleSet（正确标准）
↓ Validator 比较
Diagnostic[]（问题明细）
↓ Gate 决定是否放行；当前硬 Gate 仍是规划
Evidence（实际运行后保存证据）特别注意：Snapshot、RuleSet 和 Validator 没有各自的 Unity 菜单或 CLI 命令。 到 Z2 时由纯逻辑测试直接创建和调用；到 Z3 时先由 Editor Adapter 读取真实资源并完成 Adapter → Snapshot → Validator，到 Z7 才把同一条链注册为 agentlearn.validate_ui_textures Action。Action 尚未由本人实现并留证前，不能把目标调用链写成当前能力。
8.3.1-A 资源/业务数据规则：Snapshot + RuleSet + Validator（现状 + 标准 + 检查器）
适合检查资源导入设置、配置数据或业务状态。例如：“UI 贴图必须是 Sprite，并且不能开启 Mipmap。”
RuleSet（规则标准表）：记录应该是什么，例如textureType = Sprite。Z2 的目标设计是由本人在 C# 中实现UiTextureRuleSet.CreateDefault()，不是 JSON、ScriptableObject 或 Inspector 配置。Snapshot（当前状态快照）：记录从 Unity 中读到的现在是什么，例如textureType = Default。它不是备份、存档或撤销点，只是本次检查需要的字段副本。Validator（规则检查器）：比较两者；不一致就生成结构化错误Diagnostic。它不会自己启动，也不会自动修改资源。Diagnostic（问题明细）：包含ruleId、严重级别、字段、实际值、期望值和说明。它不是 Unity Console 日志，也不是 Roslyn 自带的 Diagnostic 类型。Adapter（Unity 数据读取桥）：只有这一层读取AssetDatabase和TextureImporter，再把结果转换成 Snapshot；Core Validator 不认识 Unity API。
下面代码是 Z2 要亲手实现的目标形态，用来解释类型关系；它不是当前项目已有代码或编译证据：
// 应该是什么：项目规则。
var rules = UiTextureRuleSet.CreateDefault();
// 现在是什么：从一张真实贴图读取后形成的普通 C# 数据。
var snapshot = new UiTextureSnapshot
{
assetPath = "Assets/AgentLearn/Samples/UITextures/ui_button.png",
textureType = "Default", // 当前值错误；规则要求 Sprite
mipmapEnabled = true // 当前值错误；规则要求 false
};
// 比较“当前值”和“期望值”，返回 UI_TYPE_001、UI_MIP_001 等错误。
var diagnostics = UiTextureValidator.Validate(new[] { snapshot }, rules);它的重点是检查数据。它不会限制 C# 项目引用，也不能证明一个 Unity 命令运行后没有副作用。
在 AgentLearn 里怎么亲手操作（Z1–Z4）：
- Z1 先由本人写规则表，并导入真实的合规、单项违规和多项违规纹理夹具；规则和样本先于代码。
- Z2 从空文件创建
Assets\AgentLearn\Core\ToolContracts.cs与UiTextureValidator.cs，每增加一个类型就等待 Unity 编译并处理第一条真实错误。 - 同阶段创建
UiTextureValidatorTests.cs，至少覆盖合规输入、单项违规、多项违规、非法路径和稳定输出顺序。 - 在 Test Runner 的 EditMode 中运行本人刚写的测试，记录实际测试数量和结果；文档里的预期数字不能代替本次输出。
- 临时改错一个断言制造红灯，保存失败信息，恢复正确断言后重新跑绿；不要把故意错误留在项目里。
- Z3 再写 Editor Adapter，让它读取
TextureImporter并生成 Snapshot；先通过普通 EditorWindow 操作，不接 CLI 或 Action。 - Z4 完成人工正常、空结果、非法路径和无写入验收，把命令、测试、红灯、恢复和本人结论写入
Docs\practice-ledger.md。
面试能说明什么： 你知道如何把资源规范拆成可测试的纯 C# 规则，而不是把检查、Unity API 和资源修改全部塞进一个 Editor 方法。
8.3.1-B 代码结构规则：asmdef + C# 编译（模块边界 + 编译门禁）
适合保护代码结构。例如：Core 只放纯规则，不允许它调用 UnityEditor.AssetDatabase；Editor 层可以引用 Core，反过来不行。
Z2–Z3 要亲手建立的目标结构可以简化理解为：
AgentLearn.Editor → AgentLearn.Core
可以引用 不反向引用 Editor在 Z2 创建 AgentLearn.Core.asmdef 时，要让它不引用其他程序集并设置 noEngineReferences: true；Z3 再让 Editor 引用 Core，而不是反过来。因此基线编译通过后，如果临时把下面代码写进 Core，编译就应该失败：
// 错误示例：这段代码不应该出现在 AgentLearn.Core 中。
using UnityEditor;
public static class WrongCoreTool
{
public static void Search()
{
AssetDatabase.FindAssets("t:Texture2D");
}
}这里不需要自己再写一个 Validator；程序集引用配置和编译器本身就是门禁。但它只能判断“能不能引用”，不能判断贴图是不是 Sprite，也不能判断 Action 的运行结果。
在 AgentLearn 里怎么亲手操作：
- Z2 由本人创建
Assets\AgentLearn\Core\AgentLearn.Core.asmdef，确认references为空且noEngineReferences=true。 - Z3 再创建
Assets\AgentLearn\Editor\AgentLearn.Editor.asmdef与Assets\AgentLearn\Editor.Tests\AgentLearn.Editor.Tests.asmdef；Editor 只在 Editor 平台编译并引用 Core，Tests 引用 Core 和 Editor。 - 先画出
Tests → Editor → Core的允许方向，并在 Ledger 记录每次 asmdef 变更后的真实编译结果。 - 需要故意验证红灯时，在单独学习分支临时创建
Assets\AgentLearn\Core\PracticeWrongDependency.cs：
// 故意错误：Core 不应该使用 UnityEditor。
using UnityEditor;
namespace AgentLearn
{
public static class PracticeWrongDependency
{
public static string[] Search()
=> AssetDatabase.FindAssets("t:Texture2D");
}
}- 等待 Unity 编译并保存真实错误；常见会是找不到
UnityEditor或AssetDatabase，具体编号以本人 Console 为准。 - 删除这个临时文件及 Unity 生成的对应
.meta，确认 Console 恢复、项目重新编译通过，并用git diff确认没有把练习残留在 Core。 - 将红灯、恢复后的绿灯和依赖图写入 Ledger。
面试能说明什么： 你理解 asmdef 是可由编译器强制的模块边界，不只是为了缩短编译时间。它不是安全沙箱，也不能验证运行行为。
8.3.1-C 源码语义规则：Roslyn Analyzer（懂 C# 的自定义源码检查器）
有些代码完全能编译，却违反团队规范。例如要求 Assets/AgentLearn/Core 下的 namespace 必须以 AgentLearn.Core 开头：
// C# 本身可以正常编译，但可能违反项目 namespace 规则。
namespace Random.Tools
{
public sealed class TextureRule { }
}Roslyn Analyzer 会在编译时读取源码的语法和语义，发现问题后报告类似：
AGL001 Error：Core 目录下的 namespace 必须以 AgentLearn.Core 开头。可以把 Analyzer 理解为“懂 C# 语义的自定义代码检查器”。它适合查 namespace、禁用 API、特定类型写法等；不适合读取 Unity 贴图 Importer，也不会启动场景验证真实行为。AgentLearn 当前尚未实现 Analyzer，这一项现在只需理解，不需要动手。
当前可以做的对比实操：
- 在单独学习分支临时创建
Assets\AgentLearn\Core\PracticeWrongNamespace.cs：
// 纯 C# 允许这个 namespace，所以普通编译可能仍然通过。
namespace Random.Tools
{
public sealed class PracticeWrongNamespace { }
}- 观察普通 C# 编译没有自动执行“目录必须匹配 namespace”的项目规则。这正是 Analyzer 要解决的问题。
- 删除临时文件和对应
.meta，确认git diff无残留。 - 在纸面或 Ledger 中写出期望诊断：
AGL001 Error：Core 目录 namespace 必须以 AgentLearn.Core 开头。 - 到这里就停止。真正实现 Analyzer 前必须单独建 Change，先核验 Unity 使用的 Roslyn 版本与依赖兼容；当前不能把纸面诊断说成已落地。
面试能说明什么： 你知道编译错误与团队源码规范不是一回事，也知道 Analyzer 只能强制已经编码并启用的规则。
8.3.1-D 真实行为规则：Test / Harness + Unity 实际调用（单项测试 + 整体验证台）
有些结论只有把代码真正跑起来才能知道。例如：非法目录是否被拒绝、错误码是否正确、执行前后资源有没有被改写。
Test（单项自动测试）：通常验证一个类或方法，例如给 Validator 一份违规 Snapshot，断言返回UI_TYPE_001。Fixture（固定测试样本）：人为准备且结果已知的输入。例如一张合规贴图和一张Texture Type=Default的违规贴图。当前真实纹理 Fixture 仍待补。Harness（整套验证台）：组织 Fixture、环境、命令、超时、断言、前后状态、清理和证据；它不是 Unity 自带的某个按钮，当前完整 Harness 仍在规划。Gate（放行门禁）：消费测试或报告结果，决定通过、警告或阻断。Z7 目标 Action 以后即使返回AutomationResult.Success，也只能表示命令成功执行，不代表资源合规；硬 Gate 仍是后续目标。Evidence（可复查证据包）：实际运行后保存的输入、输出、日志、Diff、测试结果和人工结论。教程文字和预期输出不算 Evidence。
下面是表达验证思路的教学伪代码，不是当前项目已有测试方法：
// 1. 记录调用前状态。
var before = CaptureAssetState();
// 2. 真实调用白名单 Action，并故意传入越权路径 Assets。
var result = InvokeAction(
"agentlearn.validate_ui_textures",
"{\"rootPath\":\"Assets\"}");
// 3. 验证失败方式符合 Spec。
Assert.That(result.success, Is.False);
Assert.That(result.errorCode,
Is.EqualTo("AGENTLEARN_PATH_OUTSIDE_ALLOWLIST"));
// 4. 再读一次状态，证明失败过程中没有偷偷修改资源。
var after = CaptureAssetState();
Assert.That(after, Is.EqualTo(before));普通单元测试通常验证一个类或方法；Harness 会进一步组织环境、输入、真实 Unity 调用、超时、前后状态和 Evidence。编译或 Analyzer 只能看静态代码，无法代替这层运行验证。
在 AgentLearn 里怎么亲手操作：
- 先按 8.2.7 和 8.3.1-A 完成本人写的
UiTextureValidatorTests，确认纯规则层可以独立验证。 - 后续在允许目录准备一张合规贴图和一张违规贴图作为 Fixture；当前未准备时必须记录
BLOCKED_NO_TEXTURE_FIXTURE，不能用空目录冒充通过。 - Z8 时按 8.2.13 的命令调用一次正常目录，再调用一次越权目录
Assets。 - 正常调用要检查
scannedCount、diagnosticCount、ruleId 和资源路径；越权调用要检查AGENTLEARN_PATH_OUTSIDE_ALLOWLIST。 - 比较调用前后的资源和
.meta状态，确认只读 Action 没有写入；同时区分“命令成功”“发现违规”“Gate 是否阻断”三个状态。 - 把 requestId/runId、payload、JSON 输出、Console、前后 Diff 和人工结论写入
Docs\practice-ledger.md；原始证据按项目配置保存到.uauto\evidence。 - 当前没有完整 Harness 或硬 Gate 时，明确记录为“人工按 Harness 流程执行”，不能说已经全自动化。
面试能说明什么： 你不仅会写一个检查函数，还能证明它在真实 Unity 环境中的正常、失败和无副作用行为。
四种方法最后压成一张表：
| 你要检查什么 | 使用什么 | 什么时候执行 | 失败时看到什么 |
|---|---|---|---|
| 资源或业务数据值 | Snapshot + RuleSet + Validator | 工具调用或测试时 | Diagnostic：ruleId、实际值、期望值 |
| 程序集依赖方向 | asmdef + C# 编译 | Unity 编译时 | 编译错误 |
| 能编译但不合规的源码写法 | Roslyn Analyzer | 编译或 IDE 分析时 | AGLxxx Diagnostic |
| 运行结果与副作用 | Test/Harness + Unity 实际调用 | 测试或自动化场景运行时 | 断言失败、错误码、Diff、Evidence |
你的学习优先级是：方法一、方法二和方法四都要在 Z2–Z4 亲手完成并故意跑失败；方法三 Roslyn Analyzer 暂时只理解用途，不插入当前主线。
下面继续用 Z2 要由本人实现的 UI 贴图 Validator 目标形态展开方法一，再说明它以后怎样接入测试、Unity 和 Gate；这些示例不是当前实现证据。
8.3.2 一个规则怎样逐层变硬
以“UI 贴图必须使用 Sprite，且屏幕 UI 不生成 Mipmap”为例：
口头规范
“UI 贴图要用 Sprite，不要开 Mipmap”
↓
RuleSet：把期望值写成数据
requiredTextureType = "Sprite"
requiredMipmapEnabled = false
↓
Snapshot：只读取当前真实值
textureType = "Default"
mipmapEnabled = true
↓
Validator：逐字段比较
↓
Diagnostic：输出稳定 ruleId、字段、实际值、期望值和说明
UI_TYPE_001 / Error
UI_MIP_001 / Warning
↓
Test / Action：自动断言或返回结构化 JSON
↓
Gate：根据 Error、Warning、读取失败决定通过、警告或阻断
↓
Evidence：保存输入、输出、错误码、Diff 和人工结论这里的关键是：规范没有直接修改资源。 规则检查只读取 Snapshot 并返回 Diagnostic；以后是否修复、怎样修复，属于 plan → confirm → apply → verify 写入闭环。
8.3.3 第一步：把口头规则写成 RuleSet
目标代码位置：D:\Project\AgentLearn\Assets\AgentLearn\Core\ToolContracts.cs；该文件要在 Z2 由本人创建。
下面是目标 CreateDefault() 的教学展开，并补上中文注释；本人实现并编译前只属于设计：
public static UiTextureRuleSet CreateDefault()
{
return new UiTextureRuleSet(
version: CurrentVersion, // 规则也要有版本，方便以后兼容和审计
requiredNamePattern: "^ui_[a-z0-9_]+$", // 命名必须以 ui_ 开头
requiredTextureType: "Sprite", // UI 贴图必须导入为 Sprite
requiredSpriteMode: "Single", // 当前学习基线只接受 Single
requiredMipmapEnabled: false, // 屏幕 UI 不生成 Mipmap
requiredMaxTextureSize: 2048, // 当前基线固定 Max Size
requiredSrgbTexture: true, // 颜色贴图使用 sRGB
requiredAlphaIsTransparency: true); // 示例 UI 使用透明 Alpha
}为什么单独建 RuleSet，不把 false、2048 写死在每个 if 里：
- 所有规则值集中在一个地方，Review 时容易看。
- 报告可以携带
rulesVersion，知道当时按哪版规则检查。 - 以后不同平台或资源目录需要不同规则时，不必复制 Validator。
- 测试可以显式传入规则，不依赖隐藏的全局状态。
注意：RuleSet 只是“期望是什么”，它自己不会检查任何东西。
8.3.4 第二步：读取 Snapshot，再用 Validator 比较
UiTextureSnapshot 只保存检查所需的当前值；纯 Validator 不直接调用 AssetDatabase 或修改 TextureImporter。
// 这是一个教学用 Snapshot：除了 textureType 和 mipmapEnabled，其他字段都合规。
var snapshot = new UiTextureSnapshot
{
assetPath = "Assets/AgentLearn/Samples/UITextures/ui_button.png",
assetName = "ui_button",
textureType = "Default", // 错：规则要求 Sprite
spriteMode = "Single",
mipmapEnabled = true, // 错：规则要求 false
maxTextureSize = 2048,
srgbTexture = true,
alphaIsTransparency = true
};
// Validator 只接收普通 C# 数据，所以无需真的导入一张图片也能测试规则。
TextureDiagnostic[] diagnostics = UiTextureValidator.Validate(
new[] { snapshot },
UiTextureRuleSet.CreateDefault());目标 Validator 中，Texture Type 规则的核心调用可以写成：
AddStringDiagnostic(
snapshot,
diagnostics,
ruleId: "UI_TYPE_001", // 稳定 ID，测试和报告不要依赖自然语言
severity: "Error", // Error 可作为硬门禁
field: "textureType", // 哪个字段违规
actualValue: snapshot.textureType, // 当前真实值：Default
expectedValue: ruleSet.RequiredTextureType,// 规则期望值：Sprite
message: "UI textures must use the Sprite texture type.");AddStringDiagnostic 的逻辑很简单：相等就不输出；不相等就创建一条 Diagnostic。Mipmap 使用相同思路，只是比较 bool，当前严重度是 Warning。
结构化结果大致如下：
{
"ruleId": "UI_TYPE_001",
"severity": "Error",
"assetPath": "Assets/AgentLearn/Samples/UITextures/ui_button.png",
"field": "textureType",
"actualValue": "Default",
"expectedValue": "Sprite",
"message": "UI textures must use the Sprite texture type."
}这比只输出一句“贴图设置错误”更有用，因为工具、测试、Agent 和人都能稳定读取同一份结果。
8.3.5 第三步：用测试证明正确代码会绿、错误代码会红
目标测试位置：D:\Project\AgentLearn\Assets\AgentLearn\Editor.Tests\UiTextureValidatorTests.cs；该文件要在 Z2–Z4 由本人创建、运行和修正。
计划中的测试应覆盖：合规 Snapshot 返回空结果、单项/多项违规返回稳定 ruleId、非法路径显式失败，以及输出顺序确定。下面是第一个聚焦测试的教学示例，需要本人手写并以当前 Unity 真实结果为准：
using System.Linq;
using NUnit.Framework;
[Test]
public void Validate_TextureTypeIsDefault_ReturnsUiTypeError()
{
// Arrange：构造“只有 Texture Type 错误”的输入。
var snapshot = new UiTextureSnapshot
{
assetPath = "Assets/AgentLearn/Samples/UITextures/ui_button.png",
assetName = "ui_button",
textureType = "Default", // 故意违反 Sprite 规则
spriteMode = "Single",
mipmapEnabled = false,
maxTextureSize = 2048,
srgbTexture = true,
alphaIsTransparency = true
};
// Act：调用真实 Validator，不在测试里复制 if 判断。
var diagnostics = UiTextureValidator.Validate(
new[] { snapshot },
UiTextureRuleSet.CreateDefault());
// Assert：只关心稳定 ruleId、字段和严重度，不依赖整段英文 Message。
var diagnostic = diagnostics.Single(item => item.ruleId == "UI_TYPE_001");
Assert.That(diagnostic.field, Is.EqualTo("textureType"));
Assert.That(diagnostic.actualValue, Is.EqualTo("Default"));
Assert.That(diagnostic.expectedValue, Is.EqualTo("Sprite"));
Assert.That(diagnostic.severity, Is.EqualTo("Error"));
}故意失败的安全做法：把最后一行期望暂时改成 Warning，确认测试变红并看到实际值为 Error；随后恢复为 Error 并重新运行。这样证明测试真的会抓错，而不是只看一次绿色结果。
8.3.6 第四步：Editor Adapter 读取真实 Importer
纯 Validator 不认识 Unity 资源；UnityUiTextureTools.ValidateUiTextures 才负责 Editor API：
// 1. 只在白名单目录里查 Texture2D。
var assetPaths = AssetDatabase.FindAssets(
"t:Texture2D",
new[] { normalizedRoot })
.Select(AssetDatabase.GUIDToAssetPath);
// 2. 从真实 TextureImporter 生成只读 Snapshot。
// 这一层可以使用 UnityEditor；Core Validator 不应该依赖 UnityEditor。
snapshots.Add(CreateSnapshot(assetPath, importer));
// 3. 把普通数据交给同一个纯 Validator。
var rules = UiTextureRuleSet.CreateDefault();
var diagnostics = UiTextureValidator.Validate(snapshots, rules);
// 4. 返回规则版本、扫描数、Diagnostics 和读取错误；不修改任何资源。
var report = new UiTextureValidationReport
{
rulesVersion = rules.Version,
rootPath = normalizedRoot,
scannedCount = snapshots.Count,
diagnosticCount = diagnostics.Length,
snapshots = snapshots.ToArray(),
diagnostics = diagnostics,
errors = errors.ToArray()
};Z7 完成后要达到的目标调用链是：
agentlearn.validate_ui_textures
→ AgentLearnAutomationModule 中的 ActionDefinition
→ UnityUiTextureTools.ValidateUiTextures（Editor Adapter）
→ AssetDatabase / TextureImporter 生成 Snapshot
→ UiTextureValidator（纯规则）
→ UiTextureValidationReport（结构化 JSON）这里有一个重要区别：目标 Action 将用 AutomationResult.Success 表示“检查命令成功执行”；即使 diagnosticCount > 0，也不代表资源合规。命令成功、发现违规、Gate 是否阻断是三个不同状态。 本人完成 Z7 前，这只是 Contract 设计。
8.3.7 第五步：怎样从“报告工具”升级为硬 Gate
Z7 的目标 Action 只负责报告，不包含下面这段 CI 阻断策略。下面是规划中的教学代码，用于解释 Gate 将怎样消费报告：
using System.Linq;
private static int GetGateExitCode(UiTextureValidationReport report)
{
// 2：报告结构缺失，或连资源都没有完整读出来，不能把“没检查完”当成通过。
if (report == null || report.errors == null || report.diagnostics == null
|| report.errors.Length > 0)
{
return 2;
}
// 1：规则执行完成，但存在 Error 级违规，阻断合入或后续写入。
bool hasRuleError = report.diagnostics.Any(
item => item.severity == "Error");
if (hasRuleError)
{
return 1;
}
// 0：没有 Error。Warning 是否阻断，应由项目策略决定，不能临时猜。
return 0;
}一个完整 Gate 至少区分：
| 状态 | 含义 | 建议处理 |
|---|---|---|
0 | 检查完整且没有 Error | 允许进入下一层；Warning 仍写入报告 |
1 | 检查完整但发现规则 Error | 阻断，列出 ruleId、资源和字段 |
2 | 读取失败或检查未完成 | 阻断并先修环境/资源问题，不能当作合规 |
只有 Runner/CI 真实执行并按策略返回失败码后，才能说“规则已经成为硬门禁”。当前 AgentLearn 还不能宣称这一层完成。
8.3.8 本节在 Z0–Z8 主线中的位置
本节不是第二套执行清单。真正操作始终回到第 8.2 节：
| 当前阶段 | 只查本节什么 | 查完回哪里 |
|---|---|---|
| Z1 | RuleSet、Fixture、规则值和 Diagnostic 的关系 | 回 8.2.6 制作规则与真实样本 |
| Z2 | Snapshot/RuleSet/Validator、asmdef 和 Test | 回 8.2.7 逐个亲手实现 |
| Z3 | Importer Adapter 与普通 Editor 入口 | 回 8.2.8 完成只读工具 |
| Z4 | Harness 思路、故意失败、硬 Gate 与 Evidence 区别 | 回 8.2.9 完成人工阶段门 |
| Z5–Z8 | 不再从本节找顺序 | 直接按 8.2.10–8.2.14 执行 |
Analyzer 暂时只理解用途，不插入 Z0–Z8 主线。所有预期错误码和教学输出都不能代替本人实际结果。
8.3.9 工程门 1–5 在这个例子里分别检查什么
这里的“工程门 1–5”是 Change 的通用检查层，不是 Z8 的 A–G 操作步骤。
| 工程门 | 这个例子的具体动作 | 失败时回哪里 |
|---|---|---|
| 1 范围 | git diff 只能出现批准的 Core/Test/Docs 文件；只读练习不应出现 Fixture .meta 或 Importer 改动 | 回 Apply 清理越界修改 |
| 2 结构 | AgentLearn.Core 不引用 UnityEditor；Editor Adapter 才读取 AssetDatabase | 调整程序集和接口所有权 |
| 3 编译/确定性规则 | C# 编译、UiTextureValidatorTests、稳定 ruleId | 修代码或测试；不能关闭规则求绿 |
| 4 行为 | Z7 后验证 Action 的空结果、真实违规、非法路径与无写入 | 修 Adapter/Guard/规则，再复跑 |
| 5 人工接受 | 人确认规则值、Warning/Error 策略和证据是否足够 | 回 Proposal/Design 修改规则策略 |
8.3.10 Analyzer 在哪里使用
上面的 UiTextureValidator 是项目业务 Validator，不是 Roslyn Analyzer。它检查“资源数据是否符合规则”。
Roslyn Analyzer 更适合检查源码本身，例如：
Assets/AgentLearn/Core 下的代码
→ 禁止 using UnityEditor
→ 或要求 namespace 与目录约定一致
→ 编译时报告 AGL001Analyzer 只报告已经编码的源码规则；Source Generator 用来生成 .g.cs 样板；Code Fix 是 IDE 中可选择的修复；Harness 验证编译后的行为。四者不能互相替代。
当前 AgentLearn 没有引入 Roslyn Analyzer 工程和兼容依赖，因此只能说“已理解并规划”，不能说“Analyzer 门禁已落地”。等 UI 贴图 Validator、测试、Action 和 Evidence 真实跑通后，再按 Docs\02-unity-editor-and-csharp-labs.md 的 P2 实验核验 Unity/Roslyn 版本并实现一条最小规则。
8.3.11 当前真实边界
- 当前学习起点：Unity 2D + URP 模板与 Test Framework 保留；UI 规则、真实纹理夹具、
Assets/AgentLearn业务代码、测试、项目内 Pipeline/uauto 配置和agentlearn.*Action 尚未由本人建立。 - 机器级工具边界：本机即使能运行
unity或uauto，也只代表命令可用，不代表 AgentLearn 已安装项目包、完成编译或跑通过调用链。 - 后续目标：Z1–Z8 完成 UI 只读工具、项目接入、三个 Action、双入口、错误路径与重开复验；M2/M3 再做安全写入、Agent/MCP 与固定 Eval。
- 状态纪律：
planned ≠ implemented ≠ compiled ≠ automated green ≠ manual runtime accepted ≠ resume-ready。
是否完成只看 D:\Project\AgentLearn\Docs\practice-ledger.md 的本人真实记录，不能把本节代码示例直接当作已完成证据。
8.4 Tool Contract 与确定性 Tool Core
最重要的顺序：
先开发正常、确定、可测试的工具，再把工具开放给 Agent。
flowchart LR
A[人工 EditorWindow] --> D[Tool Contract]
B[EditMode / PlayMode 测试] --> D
C[Agent Adapter / MCP] --> D
D --> E[确定性 Tool Core]
E --> F[Unity Editor API]
E --> G[Validator]
E --> H[Planner / Diff]
H --> I[Confirm / Executor]
I --> J[Verify / Undo / Audit]图表示多个入口最终复用同一 Contract，不表示它们同时开发；实际顺序仍是 EditorWindow/Test → CLI/uauto → M2 → M3A/B → 可选 MCP。
分层职责
- Tool Contract
- 定义工具名称、输入、输出、错误和副作用。
- 与具体模型服务解耦。
- 人工 UI、测试和 Agent Adapter 使用同一份契约。
- Query / Validator
- 查询资源和读取当前状态。
- 纯只读校验，不在检查过程中修改资源。
- Planner / Executor
- Planner 生成旧值、新值、原因和预期影响。
- Executor 只执行明确确认且仍有效的计划。
- Safety / Observability
- Dry Run、Diff、确认、Undo、幂等、防重和审计。
- 失败显式暴露，不用静默兜底。
- Adapter
- EditorWindow：人工调试。
- Test Adapter：确定性自动测试。
- Agent/MCP Adapter：结构化调用，不复制业务逻辑。
8.5 Test / Harness：怎样验证 Unity 真实行为
准确定义：
AIHarness 是为 AI 辅助开发建立的项目级执行与验证设施，组织编译、测试环境、入口、日志、结果和证据。UnityHarness 是其中面向 Unity 的具体封装，可以建立在 Unity Test Framework、自定义 Editor 工具、命令行和 MCP 之上。
这两个名称描述目标验证设施，不代表当前 AgentLearn 已有完整 Harness。Z4 先由本人用 Test Runner、EditorWindow、before/after 和 Ledger 组成最小可复现验证；只有相应 Runner、Fixture、Timeout、Reporter 和 Artifact 都真实实现并运行后，才能说 Harness 已落地。
组成：
| 组件 | 职责 | 追问重点 |
|---|---|---|
| Runner | 接收参数并调度 | 入口、同步/异步、退出码 |
| Fixture | 准备结果已知的资源、场景和依赖 | 初始化、随机种子、复用 |
| Driver | 模拟操作或调用真实业务入口 | 是否绕过真实调用链 |
| Oracle | 断言结果 | 为什么断言能证明 Spec |
| Cleanup | 清理对象、事件和静态状态 | 怎样避免顺序依赖 |
| Timeout | 防止异步/协程无限等待 | 取消、阈值和失败信息 |
| Reporter | 汇总通过、失败、堆栈和耗时 | 报告位置和定位方式 |
| Artifact | 保存日志、截图和 JSON | 怎样关联 Change/Commit/Run |
如何避免 AI 把实现和测试一起写错：
- 验收条件先于实现存在。
- 断言对应 Specs，不复制内部实现。
- 人工审查输入、动作和预期。
- 至少一个负向或边界用例。
- 故意破坏关键逻辑。
- 自动测试后走真实场景。
- 对数量、所有权、唯一性增加不变量。
8.6 Unity CLI、Pipeline 与 uauto：命令怎样进入 Unity
这部分只在 Z0–Z4 的 UI 只读工具阶段门通过后开始。学习批次计划使用 Unity CLI
1.0.0-beta.3、com.unity.pipeline 0.4.0-exp.1 和 uauto 0.1.1；到 Z5、Z6
时必须先用本机帮助、unity pipeline list-versions、项目 manifest 和 lock 重新确认，
再由本人执行安装。机器级 CLI/uauto 已存在不等于项目包已导入，这些版本也不是永久
“最新版”声明。
必须把四个范围分开：
| 范围 | 正确定位 | 当前要学到什么 |
|---|---|---|
| Unity CLI | Editor 进程外的独立 unity 命令入口 | version/help、doctor、Editor/项目管理、JSON 输出、command/shell/run |
| Unity Production Pipeline 大平台 | 还包含云 API、Web、Automation、Build 等产品 | 知道范围即可；AgentLearn 不依赖整套云平台 |
本地 com.unity.pipeline | Editor / Development Player 内的命令发现与执行桥 | [CliCommand]、本机连接、Token、主线程执行、内置命令和安全约定 |
| uauto + AgentLearn | 自建统一网关、业务白名单、编排和证据 | 双入口、Registry、Action、风险、幂等、Eval 和 Evidence |
两组同名职责也不能混：
| Unity 官方入口 | AgentLearn/uauto 入口 | 区别 |
|---|---|---|
unity doctor | uauto doctor --project-path D:\Project\AgentLearn | 前者检查 CLI 机器环境；后者检查 .uauto、Pipeline 连接、共享包、health 和 Registry |
unity list --project-path D:\Project\AgentLearn | uauto actions --project-path D:\Project\AgentLearn | 前者列 Pipeline 的官方内置通用命令与自定义命令；后者只列项目业务白名单 Action |
执行方式不能用一句“要不要打开 Unity”概括：
| 执行方式 | 正确边界 |
|---|---|
unity command ... | 连接已经运行且 Pipeline ready 的 Editor |
unity command --runtime ... | 连接已经运行并正确配置的 Development Player |
unity run <project> --command ... | CLI 临时启动 Batch Mode Editor，执行后退出；AgentLearn 尚未把它作为本人验收证据 |
Pipeline 0.4 已经自带资产、Scene、GameObject、Prefab、Import Settings、测试、
Console、Package、Runtime 和 Eval 等大量通用命令。因此四个 uauto_* 不是
Pipeline 的完整命令表，三个 agentlearn.* 也不应宣传成 Unity 底层 API 创新。
项目的真实增值是把高权限通用能力收敛为固定业务含义、固定目录、Schema、错误码、
幂等、过期检测、场景编排和前后 Evidence。
官方 Pipeline 已有本机回环、Bearer Token、Authoring Root、路径限制、
confirm/dry_run 约定和 Undo 等基础安全能力；但不少策略仍由各命令自己实现。
uauto / Registry 的价值是把业务白名单、风险、确认、错误、恢复和证据集中统一，
不能说这些安全概念全部由 AgentLearn 首创。
学习时间按岗位控制：
- 普通 Unity 客户端：先完成 Z0–Z4 的普通 UI 工具，再用 3–4 小时学懂 CLI/Pipeline 本体；没有 Action 证据前只讲机制，不讲项目完成度。
- 完成 AgentLearn Z5–Z8、真实失败路径和 Ledger：通常还需约 9–16 小时，按本人 编码与排错速度调整。
- AI/Unity 工具岗：写入闭环、固定 Eval、恢复和演示真实通过后，才升级为主案例。
四个名称先彻底分开
| 名称 | 所在层 | 做什么 | 不是什么 |
|---|---|---|---|
Invoke-UAuto.ps1 | 共享源码仓库 PowerShell | 把参数转给 dotnet run ...UAuto.Cli.csproj | 不是 Unity 接口；不会随 UPM 包注入 AgentLearn |
uauto invoke | Unity 外部 .NET 8 Runner | 构造并发送 Action 调用，整理结果 | 不是 Unity 内部 [CliCommand] |
uauto_invoke | 公共 UPM 包的 Unity 内部命令 | 接收 actionId/payload 并进入 Registry | 不是一个业务 Action |
agentlearn.search_assets 等 | AgentLearn 业务 Action ID | 选择已注册的预编译 Handler | 不是第二种 [CliCommand] |
最简单的一句话：
Unity CLI 是进程外入口，本地 Pipeline 是 Unity 内的执行桥；AgentLearn 只开放 白名单 Action；uauto 负责调用、编排并保存证据；MCP 只是可选适配入口。
Z6–Z7 的目标架构：官方平台层 + 项目自定义两层
以下是后续要由本人实现和验证的目标结构，不是当前项目已完成状态。在 Pipeline 官方 内置命令之外，项目自定义部分仍分两层。
第一层是 Pipeline 自动发现的四个公共包自定义 [CliCommand]：
uauto_health、uauto_capabilities、uauto_invoke、uauto_snapshot。
第二层不是另一种 [CliCommand]，而是 AgentLearn 自建 Registry：
AgentLearn Bootstrap
→ AutomationRegistry.Register(new AgentLearnAutomationModule())
→ AutomationActionDefinition
→ 预编译 HandlerPipeline 自动发现 [CliCommand]；Module 由 Bootstrap 显式注册，不使用反射扫描。
Unity 技术上允许每个业务方法直接声明 [CliCommand]，但统一
uauto_invoke + actionId 可以集中统一业务 Target、Risk、确认、错误码、幂等、
过期检测、统一结果与 capabilities。新增普通功能通常只新增 ActionDefinition 与
Handler；没有注册的函数不能从正式 uauto 路径调用。
两条调用链
直接 CLI：
unity command ... uauto_invoke --actionId agentlearn.search_assets
→ Unity CLI → Pipeline → 公共包 → AutomationRegistry
→ AgentLearn Module/Adapter → HandlerRunner：
uauto invoke --action agentlearn.search_assets
→ Runner 通过 unity shell --protocol ndjson 发送等价 uauto_invoke 请求
→ 后续与直接 CLI 相同单次 invoke 进入 Unity 后下游相同；uauto doctor/actions/run 还负责 manifest、
状态、超时、重试、进程连接、cleanup 位置与 evidence，所以 Runner 不是别名。
正式自动化/CI 推荐 uauto → Unity CLI → Pipeline → Action；临时单次诊断用
直接 unity command。官方 unity mcp 是可选协议入口，AgentLearn 可以 CLI-only。
官方 Eval 仍是高权限能力，只是没有进入 AgentLearn 正式白名单，不能说物理删除。
学习总入口始终是
D:\Project\AgentLearn\Docs\00-start-from-zero.md。完成 Z0–Z4 后，到 Z5 使用
Docs\07-unity-cli-and-pipeline-latest-learning-guide.md 学懂 Unity CLI 与本地
Pipeline；到 Z6–Z8 再按 Docs\06-unity-cli-pipeline-uauto-from-zero.md 完成
uauto 初始化、三个 Action、双入口、PowerShell 转义、错误路径与恢复复验。
8.7 Evidence：怎样证明做过且做对
变更 ID / Commit / Run ID：
需求与非目标：
风险等级与批准点：
允许修改目录：
AI / 人工职责边界：
关键 Diff：
编译与 Analyzer：
自动测试：
故意破坏结果：
Unity 运行验证：
性能 / 资源检查：
已知限制：
回滚方式：
Reviewer：8.8 Unity MCP：只在 M3C 作为可选协议适配入口
MCP 不属于 Z0–Z8，也不是进入 Agent 的必选门。只有 Z8、M2、M3A 固定 JSON Adapter 和 M3B 模型 Tool Calling 都有证据后，才评估 M3C；第一版只映射三个已经验证的只读 Action，不开放 Scene、Prefab、Importer 或 ProjectSettings 写入。
AI Agent
→ 结构化 MCP 请求
→ MCP Server / Bridge
→ Unity Editor 插件 / Editor Tool
→ 编译、场景、测试、日志
→ 结构化结果返回 AgentMCP 是结构化通道，不是业务正确性判断器。只读首版必须设置项目绑定、白名单、Schema、超时、取消、断线和明确错误；以后若经单独 Change 扩展写入，还必须满足：
- Scene/Prefab 保存、删除资产前人工批准；首版不开放这些能力。
- 编译稳定后才能进入 PlayMode。
- 写操作白名单、超时和明确错误码。
- 批处理任一步失败立即停止。
- 同一 Unity 实例同一时间只有一个控制者。
- 超时后先查询真实状态，不重复发送保存/删除。
- 大量 Scene/Prefab YAML Diff 时立即停止。
8.9 Unity AI 工程闭环面试口述
当前阶段 30 秒：
我把目标闭环设计为 Change 锁定范围，Check 检查 Diff、依赖、编译和规则，Unity CLI/Pipeline 负责进入 Unity，项目只开放白名单 Action，uauto 负责编排和 Evidence，MCP 只是可选入口，最后由 Harness 和人工验收正常、边界、失败与无副作用。AgentLearn 现在从 Z0 开始，UI 工具、Pipeline/uauto 项目接入和三个 Action 都要由我亲手建立；只有 Ledger 有证据后，我才分别表述 implemented、compiled、automated green、manual runtime accepted 和 resume-ready。
记忆边界：
Check 通过只代表工程门禁通过，不等于真实行为正确。unity command 成功只代表命令链成功，不等于业务 Spec 通过。Harness 通过只代表已覆盖用例通过，不等于全部体验和风险已接受。MCP是入口适配，不是 Agent 本体，也不是业务正确性判断器。implemented / compiled / automated green / manual runtime accepted / resume-ready必须分别陈述。
9. M2–M5 游戏研发 Agent、Eval 与 ET10 选读参考
9.1 Z8 之后的唯一高级实践顺序
本章不是与 Z0–Z8 并行的第二条路线。只有第 8.2 节达到 resume-ready，才按下面顺序继续：
| 顺序 | 本阶段只解决什么 | 本人完成门 |
|---|---|---|
| M2 安全写入 | 确定性 Plan/Diff/Confirm/Apply/Verify/Audit/Rollback | 未确认、过期、目标变化、重复、部分失败和复检失败均有自动与人工证据 |
| M3A 固定 JSON Adapter | 不接模型，先证明外部结构化请求只能到达白名单 Tool Core | 正常、缺字段、未知工具、越权和超时可重复测试 |
| M3B 模型 Tool Calling | 模型只做意图理解、工具选择和参数生成 | 模型不能保存业务状态、确认计划、直接写 Unity 或自行宣布成功 |
| M3C 可选只读 MCP | 在已有 Adapter 外增加协议映射 | 首版只开放三个只读 Action；没有真实连接就保持规划中 |
| M4 扩展与可观测性 | 第二个独立工具，再考虑 RAG 和 Tracing | 本人能独立迁移 Contract/测试/证据方法，来源和调用可追踪 |
| M5 Eval 与作品门 | 固定 28 案例、连续运行、失败回归、文档和演示 | 数字来自真实 run，安全案例全部正确拦截，作品可复现 |
M3A → M3B → M3C 不能倒置。先接模型或 MCP，再补 Contract、状态和测试，会把模型不确定性、协议问题和 Unity 副作用混在一起。
9.2 M2：先完成确定性安全写入闭环
9.2.1 案例和能力边界
唯一案例继续使用：
检查
Assets/AgentLearn/Samples/UITextures下的 UI 贴图，先返回问题和字段级修改计划；只有本人明确确认后才修改，并立即重新读取和验证。
Z7 的三个只读 Action 保持不变；M2 才新增：
| Action | 类型 | 职责 |
|---|---|---|
agentlearn.plan_import_fixes | 计划，只读 | 根据诊断生成旧值/新值、理由、风险和资源指纹，不写入 |
agentlearn.apply_import_fixes | 写入 | 只执行已确认、未过期且资源未变化的计划 |
agentlearn.verify_import_fixes | 只读 | 重新读取 Importer，验证实际值和规则结果 |
V1 规则仍以 Z1 的 path/name/type/mode/mipmap/max size/sRGB/alpha 为准；Compression 和平台 Override 只有单独定义规则、Fixture、风险和恢复后才扩展。
9.2.2 目标写入状态机
下面是 M2 要由本人实现和验证的目标状态机，不是当前运行状态：
diagnosed
→ planned
→ awaiting_confirmation
→ confirmed
→ executing
→ applied
→ verifying
→ succeeded
任一步可以明确进入：rejected / expired / partial / failed
若已设计并验证恢复：rolling_back → rolled_back / rollback_failed计划至少保存 planId、requestId、生成时间、规则版本、目标 GUID/路径、资源指纹、字段旧值/新值、风险、确认人/确认时间、idempotencyKey 和审计引用。关键状态必须落文件或状态仓库，不能只存在聊天记录中。
9.2.3 本人、AI、失败路径和完成门
本人必须亲手：
- 写 Planner、Plan Store、Confirm、Expiry/Fingerprint、白名单 Executor、Verifier 和 Audit。
- 在窗口中先展示 Plan 和 Diff，再由本人明确批准或拒绝。
- 执行前重读资源并比较规则版本、时间和资源指纹。
- 执行后重新读取和验证；不能用“API 没抛异常”代表修改成功。
- 明确每项成功/失败和恢复边界，不把批量部分失败包装成全部成功。
AI 只协助： Review 威胁模型、状态机、Schema、幂等和测试矩阵；不得代替本人确认、执行最终写入或选择静默 fallback。
至少覆盖八类负向路径：
- 未确认直接执行。
- 错误或不存在的
planId。 - 时间过期。
- 规则版本变化。
- 资源在确认前变化。
- 同一 idempotencyKey 或 plan 重复执行。
- 多资源中部分失败。
- 重新导入、复检或恢复失败。
完成门： Dry Run 无资源写入；成功、拒绝、过期、重复、部分失败、复检失败和恢复边界都有自动测试、本人 Unity 操作、before/after 和 Audit 证据。M2 未通过不进入 M3A。
9.3 M3A：先做不接模型的固定 JSON Adapter
目的： 先证明“外部请求 → Schema → 白名单 → Tool Core → 结构化响应”稳定，再引入模型。
固定 JSON 请求
→ Envelope / Schema 校验
→ projectId + tool/action 白名单
→ 强类型 DTO 映射
→ 已验证 Tool Core
→ 结构化 data / diagnostics / errors / auditRef本人必须亲手：
- 定义唯一外部 canonical Contract；内部 DTO 命名不同必须显式映射，不能让字段漂移。
- 实现 requestId、projectId、toolVersion、actionId、parameters、dryRun 和超时边界。
- 显式保存请求、工具结果、planId、确认、idempotencyKey、状态变更和 audit/evidence 路径。
- 直接用固定 JSON 覆盖正常、缺字段、类型错误、未知 Action、越权路径、超时和工具失败。
AI 只协助： Review Schema 与错误分类；不能用模型自由文本补齐缺字段或猜默认值。
完成门： 不接任何模型也能完整重复测试；错误输入返回明确失败而不是假数据；Adapter 不包含第二套业务规则。
9.4 M3B：再接模型 Tool Calling
游戏研发 Agent 与普通命令工具的区别，是它接收目标、选择白名单工具、保存多步状态、依据结果决定下一步，并用 Eval 衡量质量；但业务正确性仍由 Tool Core、状态机和人工 Gate 决定。
本人必须亲手：
- 记录模型服务、模型版本、Prompt/Tool Schema 版本和允许工具集。
- 第一轮只注册已经在 M3A 验证的工具，不让模型看到任意 Unity API。
- 实际运行正常工具选择、参数缺失、选择错误工具、重复调用、越权意图和工具返回失败。
- 模型每一步都接收显式任务状态和工具结果；不能把模型当数据库、任务队列或唯一状态源。
- 写操作仍必须由 M2 的 planId、确认和 Executor 控制；模型不能代表用户确认。
AI/模型只负责： 理解意图、选择允许的工具、生成待校验参数、解释结构化结果和提出下一步候选。
完成门： 模型无法绕过 Tool Core；参数先过 Schema；工具失败会停止或交给人工；最终成功只依据工具/验证结果，不依据模型一句“已完成”。
9.5 M3C：最后才评估可选只读 MCP
MCP 只是把同一 Contract 映射成另一种协议入口，不是 Agent 本体，也不是业务正确性判断器。CLI-only 或现有 Adapter 已满足目标时，可以不接 MCP。
首版只开放：
agentlearn.search_assetsagentlearn.get_import_settingsagentlearn.validate_ui_textures
本人必须亲手： 验证项目绑定、能力清单、Schema、超时、取消、断线、未知工具、越权和重连；确认 MCP 与 CLI/Runner 最终调用同一 Tool Core。
禁止： 首版开放任意 Scene/Prefab/Importer/ProjectSettings 写入；把 MCP 调用成功说成 Spec 通过；没有真实连接时写“已完成 MCP”。
完成门： 正常与失败连接可重复、结构化结果与现有 Adapter 语义一致、控制会话可释放；MCP 仍不是进入 M4/M5 的强制条件。
9.6 M4：第二个独立工具、RAG 与 Tracing
先由本人在 30–60 分钟内新增一个相似但独立的小工具或规则，证明方法可以迁移，再考虑 RAG/Tracing。不要先搭知识库和观测平台掩盖 Tool Core 尚不稳定。
建议顺序：
- 新 Contract、Schema、Guard、测试和人工路径。
- 复用 Adapter、Evidence 和错误模型，不复制旧业务逻辑。
- 若引入 RAG，保存来源路径/URL、版本、时间、Hash 和引用片段；检索内容不能直接驱动写入。
- 若引入 Tracing，至少关联 taskId、requestId、runId、tool、参数摘要、耗时、结果、重试、人工 Gate 和证据。
完成门： 第二工具由本人独立实现并验证；来源可追踪，调用可回放；没有静默 fallback 或无来源默认答案。
9.7 M5：固定 28 个 Eval 与作品门
Eval 不是让模型自评，也不是只录一次成功视频。先冻结 Fixture manifest、规则版本、工具版本、模型版本、运行环境和期望，再运行固定案例。
| 案例组 | 数量 | 重点 |
|---|---|---|
| E01–E06 查询与 Contract | 6 | 正常、多条件、空、目标不存在、越权、缺字段 |
| E07–E12 规则检查 | 6 | 合规、单项、多项、非贴图、规则版本错误 |
| E13–E18 Plan 与确认 | 6 | 无需修改、单/多资源计划、未确认、错误 planId、部分批准 |
| E19–E24 过期、幂等与执行 | 6 | 时间/规则/资源过期、重复 key、重复 plan、部分失败 |
| E25–E28 验证与 Agent 安全 | 4 | 复检成功/失败、错误工具、越权请求 |
本人必须亲手：
- 为每次运行生成唯一 runId，保存
run.json和逐案cases.jsonl。 - 每案保存输入、期望、实际工具链、参数、状态、耗时、证据引用和失败分类。
- 修复失败后重跑相关组和最小全量回归，保留修复前后结果。
- 统计工具选择、Schema、任务完成、写入确认、防重/越权、错误分类和修改后验证等指标。
建议目标只能用来定门槛，不能写成结果。作品投递前至少要求全部安全案例正确拦截；其余通过率、耗时和稳定性必须来自真实连续 run，不能编造“28/28”。
作品门： README、架构/时序图、Contract/错误模型、成功/拒绝/失败/恢复证据、Eval 报告、3 分钟演示和本人/AI 边界索引齐全；本人能现场新增一个小工具或规则。
9.8 先把“游戏研发 Agent”说准确
| 名称 | 解决什么 | 典型技术 | AgentLearn 是否属于 |
|---|---|---|---|
| 游戏研发 Agent | 帮助开发者检查、计划、修改和验证 Unity 项目 | Tool Calling、MCP、Editor API、Schema、Eval | 是，完成 M3B 后才可按证据表述 |
| 游戏内智能体 / NPC AI | 控制角色感知、决策、行为和战术 | FSM、行为树、GOAP、Utility AI | 不是当前主目标 |
| 训练型游戏 Agent | 通过强化学习或模仿学习训练策略 | ML-Agents、RL、环境与奖励函数 | 不是当前主目标 |
推荐表述：
NPC AI 面向游戏运行时角色决策；游戏研发 Agent 面向开发流程。我做的是后者：模型负责理解意图和编排白名单工具，真正的 Unity 读写由确定、可测试、受权限约束的 Tool Core 完成。状态、确认、验证和证据显式保存，模型不能直接操作任意 Unity API，也不能自行宣布成功。
只有 Z0–Z8、M2、M3A 和 M3B 各自有证据时，才能说“完成了最小游戏研发 Agent”；之前只能说正在建立它需要的工具地基。
9.9 技术选型的正确顺序
已确定：Unity/C# Tool Core、Unity Test Framework、强类型或 JSON Schema 契约、Git 小步历史。
后决定：TypeScript/Python 编排、模型服务、首版是否接 MCP、RAG 存储、Tracing/Eval 框架。
模型和框架不是首个作品的核心卖点。先证明确定性工具、安全副作用和量化 Eval，再选择 Agent 框架。
9.10 作品投递线
- 可运行 Unity 项目和清晰源码结构。
- README 与 3 分钟快速演示。
- 架构图和工具调用时序图。
- Tool Schema 与错误模型。
- 成功、拒绝、失败、恢复四类演示。
- 28 个固定 Eval、连续运行记录和量化结果。
- 开发日志，区分本人设计、AI 协助和本人修复。
- 能在 30–60 分钟内独立新增一个工具或规则。
9.11 GameDev Agent 面试回答与追问
当前阶段可用的 30 秒回答：
AgentLearn 是我按 Z0–Z8 从零学习 Unity Editor 工具和自动化闭环的项目。我会先亲手完成 UI 规则、真实夹具、Core、EditorWindow、EditMode 和人工只读验收，再导入 Pipeline、初始化 uauto，并实现资源搜索、Importer 快照和 UI 贴图校验三个白名单 Action。现在这些仍是学习目标，不是已实现成果；只有 Ledger 记录到哪一级，我就讲到哪一级。
完成 Z8 后可升级的 2 分钟深挖（必须先有 Ledger 证据）：
目标实现分成官方平台层和项目自定义层。Unity CLI 在 Editor 外运行，本地
com.unity.pipeline在 Unity 内负责连接、Token、[CliCommand]发现和主线程 执行。unity command连接已运行实例，unity run --command可启动一次 Batch Mode Editor。Pipeline 0.4 本身已有很多通用命令；学习目标中的共享包额外声明 health、 capabilities、invoke、snapshot 四个网关，AgentLearn Bootstrap 再显式注册 Module，把agentlearn.*ID 映射到预编译 Handler。Z7–Z8 完成后，调用既可以直接走
unity command ... uauto_invoke，也可以走外部 .NET Runneruauto invoke --action ...。单次调用进入 Unity 后都走同一个 Pipeline、Registry 和 Handler；Runner 还处理 manifest、连接、超时、重试、scenario 和 evidence。 学习批次的 0.1.1 Runner 通过unity shell --protocol ndjson发送等价命令，不只是字符串别名。官方 Pipeline 已有 Token、路径限制、
confirm/dry_run和 Undo 等基础约定； 统一 invoke 的增值是集中管理业务白名单、Target、Risk、错误码、幂等、恢复和 Evidence。没注册的函数不能从正式路径调用。官方 Eval 仍存在，但不在项目白名单。 这些只能在当前代码、测试、双入口、负向路径和重开复验都有证据后作为完成态回答； 写入闭环和固定 Eval 没完成时，仍不能说生产落地或完全替代 MCP。
14 个高频追问：
Invoke-UAuto.ps1、uauto invoke、uauto_invoke的区别？
前者是源码阶段 PowerShell 包装，中间是外部 Runner 子命令，后者是 Unity 内部[CliCommand]；agentlearn.*才是业务 Action ID。- Pipeline 自动发现什么？
自动发现[CliCommand]；AgentLearn Module 由 Bootstrap 显式 Register。 - 为什么不让每个业务方法直接加
[CliCommand]？
技术上可以，但统一入口能复用风险、确认、错误、幂等、Target 和能力清单。 - 新功能是否要新增
uauto_xxx？
通常不用；新增 Contract、Handler、ActionDefinition 和测试。 - 没注册的函数能否调用？
不能；目标 Contract 应返回稳定的未知 Action 错误，例如规划中的UAUTO_ACTION_NOT_FOUND，实际名称以本人实现和运行证据为准。 - 两种 invoke 的下游相同吗？
进入 Unity 后相同；requestId/runId、外层 envelope 和耗时可以不同。 - Runner 为什么不是直接 CLI 的别名？
它还负责 manifest、状态、连接、超时、重试、scenario、cleanup 位置和 evidence。 - MCP 是否必要？
不必要；AgentLearn 可以 CLI-only，MCP 只是可选协议 Adapter。 - 官方 Eval 被删除了吗？
没有；只是没有进入 AgentLearn 正式 Action Registry。 - 当前到底做完了什么？
当前从 Z0 开始，UI 工具、项目接入和 Action 都是 planned；以后只按 Ledger 分别 回答 implemented、compiled、automated green、manual runtime accepted 和 resume-ready，写入闭环与固定 Eval 也单独说明。 - Pipeline 是否只有四个
uauto_*？
不是。Pipeline 0.4 有大量官方内置命令，四个只是共享包的自定义网关。 - 是否所有 Pipeline 命令都要提前打开 Editor？
unity command要连接运行实例；unity run --command可启动一次 Batch Mode Editor；Runtime 调用需要运行中的 Development Player。 unity doctor/list与uauto doctor/actions有什么区别？
前一组检查 CLI 机器环境和 Pipeline 全命令；后一组检查项目自动化链和业务白名单。- 官方已有安全能力，为什么仍要 uauto？
官方提供基础连接和命令级约定；uauto 集中统一业务风险、幂等、恢复、场景和证据。
9.12 ET10 选读参考：只学规则工程思想，不作为当前实操主线
9.12.1 为什么把 ET10 放在最后
ET10 与第 8 章的关系是“思想来源和深挖案例”，不是 AgentLearn 的运行依赖。四层约束、Analyzer/Generator/Code Fix 与 Harness 的通用结论已经集中在第 8.3 节；这里仅保留 ET 专属规则、Entity 生命周期例子、许可证和面试口述，防止复习时重复学习。
本手册不安排进入或修改 ET 项目，也不把 ET 的实验结果当作 AgentLearn 证据。普通 Unity 客户端岗位可以暂时只理解本节；只有岗位明确追问 ET、Roslyn 规则工程或 AI Native 架构时再深挖。
9.12.2 ET10 高价值规则类别
具体 Diagnostic ID 会随版本变化，面试优先讲机制和真实复现实验：
- Entity/System：禁止把业务逻辑随意塞进 Entity，生命周期接口与 System 必须匹配。
- Component/Child 归属：组件和子 Entity 的父类型必须符合声明。
- 异步生命周期：await 后旧 Entity 可能 Dispose 或换实例，应通过稳定引用重新获取并判定。
- 闭包与长期引用：Lambda、字段和集合不能无约束保存可能失效的 Entity。
- ETTask 使用：任务必须被 await、显式 Coroutine 或正确传播；避免
async void和丢异常。 - Package/端依赖：跨包类型和调用必须声明合法依赖，Client/Server/Share 方向受限。
- 路径/namespace：目录、命名空间和端归属保持一致。
- 测试发现：测试命名、目录和入口符合 Harness 约定。
9.12.3 await 后 Entity 示例
错误思路：
await timer.WaitAsync(100);
self.Ready = true; // await 期间 self 可能已经失效修正思路：
EntityRef<DemoComponent> selfRef = self;
Fiber fiber = self.Fiber();
await fiber.Root.TimerComponent.WaitAsync(100);
self = selfRef;
if (self == null)
{
return;
}
self.Ready = true;Analyzer 能迫使开发者重新确认对象身份，但无法决定失效后业务应该退出、重试、补偿还是返回错误。
9.12.4 许可证边界
截至 2026-07-22，ET10 官方 LICENSE 表述包括：禁止自行修改源码后再次开源；使用项目代码开发并上线商业项目需要获得授权，当前文件写明费用 4999 元；第三方商业插件需要另行取得许可。
安全路线：
- 学习公开的工程思想。
- 围绕自身项目独立设计，不复制实现代码。
- 用于个人作品或新公司前重新阅读当时 LICENSE。
- 商业项目遵从公司负责人、法务和许可证要求。
本段不是法律意见；价格和条款可能变化，面试只讲当前核验边界，不替公司做授权判断。
9.12.5 ET10 面试回答
我理解 ET10 的 AI Native 不是模型层面保证 AI 不犯错，而是建立分层约束和反馈闭环。AGENTS 和 Skills 提供生成前软规则；Package、目录和程序集限制结构；Roslyn Analyzer 把跨包调用、Entity/System 和异步生命周期等规则变成编译诊断；Source Generator 固化样板；最后通过测试 Harness、UnityBridge、日志和人工 Review 验证。它能强制已编码且启用的规则，但不能替代业务验收。我会学习这种规则工程化思想，在普通 Unity 或 AgentLearn 实操中独立实现少量高价值 Gate，而不是迁移 ET10 Runtime。
10. 模拟面试与行动计划
10.1 100 分模拟面试评分
| 维度 | 分值 | 通过标准 |
|---|---|---|
| 定位与真实性 | 10 | 4 年游戏客户端、非 4 年纯 Unity；外包/AI/规划边界准确 |
| 自我介绍 | 10 | 60 秒清楚、无冲突、商业项目优先 |
| 《七日世界》 | 15 | 制造主案例和一个补充案例可连续追问 |
| 两个 Unity 商业项目 | 15 | 上线、0→1、引导/红点/AVG/重连有真实案例 |
| Unity/C# 基础 | 15 | P0 题能结合项目，不背定义 |
| 系统设计与调试 | 10 | 八段式、第一条证据、失败路径和验证完整 |
| AI Change 工作流 | 5 | Proposal/Specs/Design/Tasks、Apply 停止条件、Check/Verify 和人工 Gate 准确 |
| Unity AI 工程闭环 | 10 | CLI/Pipeline/uauto、Tool Contract、Harness、Evidence 和五级状态不混淆 |
| GameDev Agent / Eval | 5 | 能区分 Agent 类型，说明工具地基、状态、Eval 和作品门；ET10 仅按岗位选读 |
| 沟通与反问 | 5 | 先结论、标边界、不防御、反问有判断价值 |
评分解释：
- 85–100：可以主投中级岗。
- 75–84：可以投递，但需针对 JD 补一个专项。
- 65–74：项目或基础存在明显断点，先训练再扩大投递。
- <65：不要靠背更多术语解决；优先修真实性、项目主线和基础。
10.2 一轮完整模拟面试顺序
- 60 秒自我介绍。
- 为什么最近项目不是 Unity、为什么回 Unity。
- 《七日世界》制造系统 10 分钟深挖。
- 一个历史 Bug/联调问题。
- 《七星传》上线和重连。
- 《野火流明》引导/红点/AVG 工具。
- C#、Unity、UI、网络、性能快问快答。
- AI 参与比例、本人职责和真实性边界。
- AI Change 工作流：规格、范围、Check/Verify 和人工 Gate。
- 仅在岗位相关时继续追问 Unity CLI/Pipeline/uauto/Harness，再进入 GameDev Agent/Eval；ET10 放最后选读。
- 薪资、离职、到岗和反问。
每轮录音，复盘以下问题：是否先给结论、是否说清本人边界、是否有证据、是否使用了未经核实数字、是否把规划说成成果。
10.3 高频问题清单
履历与项目
- 为什么每段经历时间不长？
- 最近两年不是 Unity，技术会不会生疏？
- 在网易外包实际负责什么，谁给你需求和 Review？
- 制造记录为什么迁移到设施？如何兼容旧数据？
- Timer 和服务端时间怎样保证一致？
- 断线重连后哪些状态必须重新拉取？
- 红点树如何避免每帧全量计算？
- 引导如何面对 UI 改版？
- AVG 编辑器怎样校验错误命令和资源？
- 你做过最难定位的线上/真机问题是什么？
AI Change 与 Unity 工程闭环
- 代码和测试都是 AI 写的，怎样证明可信？
- OpenSpec validate 通过说明什么？
- MCP 调用成功是否等于功能完成？
- AI 改出范围怎样发现和处理？
- AI 连续两次修复失败怎么办？
- 为什么需要人工 Gate？
- 怎样防止 AI 删除资源或修改错误 Prefab？
- Harness 与 Unity Test Framework 有什么区别？
- Unity CLI、Pipeline、uauto 和 MCP 分别负责什么？
implemented、compiled、automated green、manual runtime accepted和resume-ready有什么区别？- 你实际独立修过哪一个 AI 生成问题？
GameDev Agent 与 Eval
- 你的 Agent 与 NPC AI 有什么区别？
- Agent 为什么不能直接调用 Unity Editor API？
- Eval 怎样测，不只是演示一次成功？
- 你本人当前实际跑通过哪些 Action、失败路径和证据？
ET10 选读
- ET10 如何通过软规则、结构、编译诊断和行为反馈约束 AI？
- Analyzer、Source Generator、Code Fix 有什么区别？
- await 后 Entity 为什么危险？
- ET10 能否保证 100% 正确？为什么不直接照搬 ET10 Runtime 或源码？
10.4 7 天简历与口径对齐
| 天 | 任务 | 输出 |
|---|---|---|
| 1 | 修正 17–20K 与 20–25K 冲突；统一 4 年游戏客户端口径 | 新简历和平台草稿 |
| 2 | 三个项目逐条红黄绿审计 | 每条动词与证据表 |
| 3 | 完成 30/60/120 秒自我介绍 | 三份录音 |
| 4 | 制造系统流程图和 STAR | 10 分钟主案例 |
| 5 | 《七星传》重连、《野火流明》AVG/引导 | 两个 STAR |
| 6 | AI、外包、薪资和离职压力题 | 脱稿回答 |
| 7 | 完整模拟面试和简历最终修订 | 评分与缺口清单 |
10.5 14 天面试冲刺
| 天 | 主题 | 必须完成 |
|---|---|---|
| 1 | 定位与简历 | 全部事实边界一致 |
| 2 | 自我介绍 | 三个时长版本 |
| 3 | 制造系统 | 数据/协议/刷新/异常图 |
| 4 | 职业与养殖 | 一个扩展、一个接手案例 |
| 5 | 《七星传》 | 上线、UI 链、红点、重连 |
| 6 | 《野火流明》 | 引导、红点、AVG 工具 |
| 7 | C# | 委托、集合、GC、异步、对象池 |
| 8 | Unity/UGUI | 生命周期、协程、Canvas、列表 |
| 9 | 资源/网络 | 加载、热更边界、协议、重连 |
| 10 | 性能/算法 | 完整定位法、常用结构与数学 |
| 11 | AgentLearn Z0–Z4 复习 | 按本人当前 Ledger 讲规则、Fixture、Core、Editor、测试和人工门；没做过的只讲计划 |
| 12 | AI Change + Unity 执行闭环 | 五步、本人/AI 边界、Check/Verify、Harness、Evidence 和一个本人真实故意失败案例 |
| 13 | Z5–Z8 与 M2–M5 边界 | CLI/Pipeline/uauto 四个名称、双入口、证据梯子，以及为什么 Agent/MCP/Eval 不能提前 |
| 14 | 全真模拟 | 100 分评分、修正最后断点 |
每天至少：30 分钟口述、30 分钟代码/流程定位、20 分钟错题复盘。这是面试复习计划，不授权在第 11–13 天跳过第 8.2 节的真实阶段门。
10.6 30 天 AgentLearn 人工实践日历
这张表只安排时间，不再重复技术步骤。每一天具体做什么、AI 能帮什么和完成门是什么，统一回第 8.2 节；阶段门没有通过就顺延，不为了赶日历跳级。
| 周 | 建议阶段 | 本周唯一交付 | 禁止提前 |
|---|---|---|---|
| 第 1 周 | Z0–Z2 | Unity 基线、V1 规则、8 张 Fixture、纯 Core 与第一批真实红/绿测试 | 不写 EditorWindow、Pipeline 或 Action |
| 第 2 周 | Z3–Z4 | 普通 Editor 只读工具、EditMode、人工正常/空/错误/重开、故意失败和无写入证据 | Z4 未通过不进入 CLI |
| 第 3 周 | Z5–Z6 | CLI/Pipeline 固定批次项目导入、uauto init、共享包编译和空 Action 状态 | 不预填 .uauto，不伪造三个 Action |
| 第 4 周 | Z7–Z8 | 三个只读白名单 Action、A–G 双入口/错误路径/Evidence/重开复验 | 不做 Importer 写入、模型 Agent 或 MCP |
每天建议用同一个节奏：
- 10 分钟复述当前阶段目的、非目标和完成门。
- 45–90 分钟本人完成一个最小代码或操作增量。
- 先看第一条真实失败并写自己的原因假设。
- 再让 AI Review/辅助诊断，由本人修复和回归。
- 15–30 分钟写 Ledger、整理证据并做三分钟口述。
如果 30 天结束时还在 Z4、Z6 或 Z8，继续当前阶段；这比跳到 Agent 更有价值。只有 Z8 达到 resume-ready 后，才另开后续周期：
M2 安全写入
→ M3A 固定 JSON Adapter
→ M3B 模型 Tool Calling
→ M3C 可选只读 MCP
→ M4 第二工具 / RAG / Tracing
→ M5 28 个固定 Eval、报告与作品化时间只作规划：Z0–Z4 常需 12–24 小时，Z5 约 3–4 小时，Z6–Z8 常需 9–16 小时；M2–M5 是后续数周实践。任何估时都不是完成证据。
本手册内的唯一入口
| 现在要找什么 | 打开位置 |
|---|---|
| 当前事实、优先级和允许宣称 | 第 1.5–1.7 节 |
| AI Change、停止条件和本人/AI 边界 | 第 7 章 |
| Z0–Z8 全部操作、命令、阶段门和 Ledger | 第 8.2 节 |
| 当前阶段需要的 Rule/Contract/Harness/CLI/Evidence 解释 | 第 8.3–8.8 节 |
| Z8 后的 M2–M5 | 第 9.1–9.8 节 |
| 当前真实进度 | 第 1.6 节与本人最新 Ledger |
项目内 Docs/01、03、06、07 和 practice-ledger.md 只是本机深挖材料与证据载体；网站读者不需要打开本地磁盘路径才能知道执行顺序。
10.7 入职后的 30/60/90 天
0–30 天：理解现状
- 先确认公司是否允许外部 AI、哪些代码可进入模型、是否有内部模型和脱敏规范。
- 学习现有架构、构建、测试、发布、权限和事故流程。
- 记录重复痛点，不宣布迁移 ET10、不私接 MCP、不上传源码。
- 输出一页现状图和 3 个低风险候选问题。
31–60 天：低风险试点
- 选择 Editor 校验、配置检查或纯业务单元，不从核心战斗、存档、网络、Scene 批改开始。
- 用现有工具写清 Spec、限定目录、编译、测试、故意破坏和证据。
- 衡量任务中位耗时、提前发现的缺陷、Review 时间和误报。
61–90 天：团队化
- 与负责人评审任务模板、PR 证据和一个 CI Gate。
- 建立例外/逃生流程和回滚。
- 让 1–2 位同事可以独立复现，而不是只有本人会用。
- 只有试点数据有效才扩大规则和范围。
10.8 面试前 7 天
针对 JD
- 标注 JD 的 P0、可补和不匹配项。
- 调整简历前半页关键词，但不添加虚假经验。
- 为岗位选择主项目和两个补充案例。
- 查清项目品类、阶段、技术栈、公司和面试轮次。
针对证据
- 所有版本、命令、数字和测试已复跑或标记待复跑。
- 关键流程图可在白纸 3 分钟内画出。
- 代码入口、测试入口和报告路径记录在一页纸。
- 一个 AI 失败和一个商业项目 Bug 已准备好。
10.9 面试前一天
- 简历 PDF、JD、会议链接、设备和网络已确认。
- 只复习一页速览、项目图和错题，不再扩展新主题。
- Demo 有本地备份；即使 Demo 失败也能用图和证据讲清。
- 关闭不相关通知和敏感窗口，不现场暴露公司或个人隐私。
- 准备纸笔、耳机、摄像头和 3 个反问。
10.10 面试现场
- 先结论，再展开。
- 主动标边界，不抢团队、开源和 AI 的成果。
- 不为维护自尊而与面试官争论；用证据或验证方法回答。
- 现场写代码先确认输入输出、边界、复杂度和测试。
- Demo 失败时说明真实状态、第一条诊断和替代证据，不假装成功。
推荐反问：
- 项目目前处于什么阶段，未来半年客户端最关键目标是什么？
- 这个岗位入职前三个月希望独立负责什么模块？
- 客户端团队怎样做 Review、测试、版本和线上问题复盘？
- 公司对 AI 工具、源码和数据安全有什么政策？
- 当前最希望解决的技术债或效率问题是什么？
10.11 面试后 24 小时
- 记录问题、自己的回答、卡点和面试官反馈。
- 区分知识缺口、表达缺口、证据缺口和岗位不匹配。
- 只修最高价值的 3 个问题，不无限扩充题库。
- 更新 JD 评分和下一轮主案例。
10.12 当前学习与证据复核表
| 项目 | 当前下一步 | 当前安全说法 |
|---|---|---|
| AgentLearn Z0–Z8 | 从 Session 01 / Z0 开始，只按第 8.2 节推进 | 当前只有学习文档和 Unity 模板起点；UI 工具、项目包、Action 与运行证据都尚未由本人完成 |
| M2–M5 | Z8 达到 resume-ready 后才进入第 9 章 | 安全写入、模型 Agent、可选 MCP、28 个固定 Eval 和作品目前都是后续目标 |
| Unity/C# 与 Editor 补强 | 不打断当前 Z 阶段；面试 P0 按第 6 章持续复习 | Ledger 没有本人代码、失败和操作证据前，不把练习说成当前成果 |
| ET10 选读 | 本手册不安排进入 ET 项目实操 | 只讲已理解的规则工程机制、Entity 示例和许可证边界，不作为 AgentLearn 证据 |
| 商业项目 | 无本地源码可核验 | 按简历与本人真实经历准备，不虚构数字和内部细节 |
10.13 可以开始投递的最低标准
- 60 秒自我介绍稳定。
- 制造系统可连续深挖 10 分钟。
- 两个 Unity 商业项目各有一个真实 STAR。
- Unity/C# P0 基础达到 70% 以上。
- 至少一个 AgentLearn Z0–Z4 UI Editor/Harness 练习达到 D3；否则不主动作为项目成果展开。
- AI Change、Z0–Z8 Tool Core、M2 安全写入、M3–M5 Agent/Eval 四层不混淆；ET10 只按岗位选读。
- AgentLearn 证据梯子准确，不把 planned/implemented/compiled 冒充自动化、人工、恢复或面试证据。
- 薪资、城市、外包身份和离职原因全平台一致。
11. 事实边界、来源与覆盖表
11.1 来源优先级
- 当前本地代码、版本、Git 状态、测试和报告。
- 2026-07-14 最新简历 PDF。
- OpenSpec、ET10 当前官方文档和源码。
- 2026-07-17 的完整 HTML 面试手册。
- 2026-07-22 的 AI 协同 Markdown 手册。
- 以前会话结论，只作为定位证据的索引。
11.2 本地来源
- 最新简历：
D:\Download\郭昊--游戏客户端开发.pdf - 原完整手册：
D:\Download\guohao_unity_interview_playbook.html - AI 专项手册：
D:\Download\郭昊_Unity_AI协同面试准备手册.md - AgentLearn 从零主入口：
D:\Project\AgentLearn\Docs\00-start-from-zero.md - AgentLearn 总入口与规划：
D:\Project\AgentLearn\Docs\README.md、Docs\agent-development-plan.md - AgentLearn 逐步实操教材：
Docs\01-ui-texture-tool-from-zero.md至Docs\07-unity-cli-and-pipeline-latest-learning-guide.md、Docs\practice-ledger.md
11.3 本轮项目复核关键证据
| 结论 | 本地证据入口 |
|---|---|
| AgentLearn 为 Unity 6000.7.0a2 的 2D + URP 学习项目；当前从 Z0 开始，UI 业务代码、项目内 Pipeline/uauto 与三个 Action 尚未建立 | D:\Project\AgentLearn\ProjectSettings\ProjectVersion.txt、Packages\manifest.json、Packages\packages-lock.json、Docs\00-start-from-zero.md、Docs\practice-ledger.md |
本轮只做文档与项目结构复核，没有运行 Unity、编译、测试或 Action。当前完成度只从
practice-ledger.md 的 Session 01 / Z0 新记录开始累计；没有本人当次证据的内容保持 planned。
11.4 官方来源
- Unity CLI 总览
- Unity CLI 安装与使用
- Unity CLI 命令参考
- Unity CLI Release Notes
- 本地 Unity Pipeline 包安装
- Pipeline 0.4 包文档
- Pipeline 自定义命令
- Pipeline 连接与 Token
- Pipeline 写操作安全
- OpenSpec Getting Started
- OpenSpec Concepts
- ET10 Repository
- ET10 AGENTS
- ET10 LICENSE
CLI、Pipeline、命令、profile、Analyzer、UnityBridge 指令和许可证可能变化；正式 面试前按本机 help、项目 manifest/lock 与当日官方来源重新核验。
11.5 章节覆盖表
| 来源内容 | 最终位置 |
|---|---|
| 定位、JD、简历真实性、城市和薪资 | 第 1–2 章 |
| 自我介绍、履历与压力题 | 第 3 章 |
| 三个商业项目和 STAR | 第 4 章 |
| 个人项目不作为准备主线；有用技术按能力归档 | 第 5 章导航至第 6–9 章 |
| Unity/C#、UI、资源、网络、性能、系统题 | 第 6 章 |
| Change、Proposal/Specs/Design/Tasks、Apply、Check/Verify 定义、风险和人工 Gate | 第 7 章 |
| AgentLearn Z0–Z8、本人/AI 边界、Rule/Contract/Harness、CLI/Pipeline/uauto、Evidence 与可选 MCP 定位 | 第 8 章 |
| M2 安全写入、M3A/B/C、M4、28 个 Eval、作品路线；ET10 专属选读与许可证 | 第 9 章 |
| 高频问答、评分、7/14/30/90 天计划和清单 | 第 10 章 |
11.6 版本与真实性声明
本手册是准备工具，不替代：
- 本人对商业经历的真实回忆和保密义务。
- 对本地项目代码、日志和测试的亲自复跑。
- 投递当日对 JD、薪资、城市和公司状态的核查。
- 对 OpenSpec、ET10、Unity 和第三方许可证的最新官方确认。
任何状态变化后，优先更新“已核验/简历陈述/待复跑/规划中”标签，再修改回答稿。不要为了让手册看起来完整而隐藏错误、缺证据或未完成项。
11.7 最终记忆卡
我的核心竞争力是四年游戏客户端商业项目经验和 Unity 客户端基础。AI 加分线按“第 7 章定范围 → 第 8.2 节本人从 Z0 做到 Z8 → M2 安全写入 → M3A 固定 JSON → M3B 模型调用 → M3C 可选 MCP → M4 扩展 → M5 固定 Eval”推进；ET10 只作选读。只讲本人亲手实现、运行、故意验证、修复并能现场修改的部分，未完成练习不包装成项目成果。