自动关联目录：事实底座：索引与验收说明

这组文章只回答三个问题：我做过什么，我能证明到什么程度，哪些话现在还不能说。它不是背诵稿，后续所有自我介绍、项目深挖和问答卡都必须从这里取事实。

一、本批产物

二、证据等级

证据等级证明“这句话有多少依据”，不证明“工作有多重要”。代码量、提交数和职级都不能替代业务影响。

三、职责等级

“仓库里有我的提交”最多先证明参与。只有能说明决策权、协作边界和验收责任，才会上调到 L1 或 L2。

事后源码学习可以把能力提升到“能解释、能设计、能接手”，但不会改变历史职责等级。面试时可以把它作为项目认知和架构判断，不能伪装成当年的个人实现。

四、提交审计规则

个人提交索引按以下规则生成：

1. 仓库来源取三个工作区的清单、根仓和清单外顶层 Git 仓；未 checkout 的清单项也必须留在覆盖表。
2. 每个可用仓先执行 git log --all 并保存未过滤记录，再从中筛选作者别名；不能先凭关键词抽样。
3. 作者别名统一归并，但不把同名、代提交或仅作为 committer 自动视为本人工作。
4. merge、自动同步、工作区/stash 快照、revert、reapply 和纯发布产物只在派生层标噪，不从原始层删除。
5. 同哈希跨仓只算一次；同日同主题的不同哈希生成近似逻辑聚类，以识别拆仓/迁移重复，但不作为生产力指标。
6. Bug 修复只能证明处理过该问题；主题最终还要结合文件路径与源码，不能用标题证明主导权。
7. 自动发布产物不作为设计能力证据；构建规则、协议、工具或故障修复本身可以入选。

五、当前结论

• UGC1.0 的地图数据、编辑器、AI 换色、ASTC、元件管理和四足生物有连续源码与提交证据，适合继续深挖。
• Web/跨端 的 PixUI 多应用工程、共享 SDK、构建发布、SSR 弱网恢复和可视化编程有直接证据。
• UGC2.0 的页面协议与生命周期、编辑器状态路由、原生页面宿主、制品构建和 UI 自动化证据最完整；完整对象模型、三 VM 和运行时能力已纳入源码复盘，但不回写为个人历史交付。
• 特色玩法 已确认是非对称、PVP、PVE 三个连续且重叠的工作流；个人主线集中于新手、时间线、物品/交互、HUD 和跨系统联调，地牢、完整 AI 与战斗框架按团队架构和源码学习陈述。
• 内部效能工具 已找到自动分单、地图解析、AI 知识库与研发技能的源码和连续提交，可以讲机制与工程边界，不能在没有统计前声称效率收益。
• Fate 定点数物理 已通过 D:\Fate 的四个本地仓库补齐源码与提交证据；强化学习、CAE 和 开源贡献 仍需各自的代码、报告或公开链接，不能共享证据等级。

六、验收清单

• 简历中的主要工作均进入主张台账。
• 时间线覆盖实验室、实习、UGC1.0、特色玩法、Web 和 UGC2.0，并说明重叠关系。
• 四个源码域均有仓库与模块边界。
• 提交索引明确排除了自动、回滚和重复迁移噪音。
• 使用脚本导出了所有可用仓的全分支提交历史，并记录所有未 checkout 清单项。
• 提交分析覆盖仓库、月份、文件域、需求单、作者别名和专题线索，原始记录与派生结论分离。
• 需求、实现层、上下游和最终用户形成映射。
• UGC1.0、玩法/PVE、UGC2.0 均形成“直接交付 / 项目参与 / 源码复盘”分层的完整架构底座。
• 所有现有数字都进入指标台账，未验证数字没有被扩写。
• 难题库不少于十个候选案例。
• 公开稿与私有证据采用不同脱敏级别。
• “近四年”与“全职年限”口径已经分开。