工程效能工具：Crash 分单、地图解析、自动化与 AI 辅助研发

这篇回答“除了业务功能，你做过哪些工程建设”。四个案例共同解决一个问题：当内容、版本和缺陷数量增长后，如何把依赖个人经验的排查流程变成可重复、可审计、有人类兜底的工程系统。

面试官：你做过哪些效能工具？

30 秒回答

我有四类直接工作。第一是 Crash 工单自动分配，根据调用栈定位代码文件和行号，再结合仓库 Git blame、白名单和人工规则生成候选负责人；第二是地图数据解析工具，支持解压、解密、反序列化、图层和描述文件解析，并提供 GUI 和批量诊断；第三是 UGC2.0 自动化，把静态契约、构建测试、客户端/DS 集成和 UI 驱动接到流水线；第四是 AI 辅助研发，包括规范知识库、缺陷/需求助手、分支对比和专项技能。

90 秒回答

这些工具的共同设计原则是把“判断”和“执行”分开。Crash 工具可以根据栈和 blame 给出归属候选，但白名单、人工处理状态和低置信度结果必须阻止自动转单；地图解析器可以批量发现坏包和版本问题，但第三方解压库不算我的实现，诊断结论也需要可定位到文件和字段；AI 可以提出改动候选，但不能自行证明改动正确，必须经过权限、确定性检查和人工评审。

我不会在没有统计的情况下说节省了多少人天。可靠的结果是这些工具有持续源码和提交记录，并进入了真实缺陷、地图和研发流程；下一步应补齐自动命中率、误分率、定位时长、采用率和返工率等度量。

面试官：Crash 自动分单怎么做？

一句话结论

先从异常栈得到“哪份代码最可能负责”，再从版本仓得到“这行代码当时由谁维护”，最后通过规则与人工状态决定是否允许自动操作。

flowchart LR
    A["Crash 平台工单"] --> B["栈帧清洗与排序"]
    B --> C["文件 / 行号 / 模块"]
    C --> D["版本与仓库映射"]
    D --> E["Git blame / CODEOWNERS 类规则"]
    E --> F["候选负责人 + 置信度"]
    F --> G{"自动化门禁"}
    G -->|通过| H["更新工单 / 汇总通知"]
    G -->|不通过| I["人工队列"]

为什么不能只匹配标题？

标题通常是现象，不是根因。同一个“空指针”可能来自不同模块，同一个根因也可能产生不同标题。更稳定的特征是首个有效业务栈帧、文件路径、行号、版本和提交归属。

栈清洗要排除引擎公共层、系统库、生成代码和已知包装函数；如果首帧无效，应继续查找最接近业务代码的帧，而不是固定拿第一行。

面试官：Git blame 不准确怎么办？

blame 只能说明最后改动某行的人，不等于真正 owner。重构、批量格式化、Cherry-pick 和公共头文件都会造成误导，所以它只能作为一个信号。

可以按以下优先级组合：

人工指定 owner
  > 当前模块维护规则
  > 文件路径规则
  > 有效栈帧的 Git blame
  > 历史相似问题
  > 人工待处理

工具还要识别“工单已经人工处理”“已有自动处理结果”“文件或人员在白名单”“仓库/版本无法解析”等情况，并保持幂等：重复定时运行不能反复转单或刷通知。

面试官：怎么衡量自动分单是否有效？

不能只看处理了多少工单。至少记录：

指标	含义
可解析率	工单中能提取有效业务栈的比例
自动覆盖率	满足门禁并给出候选的比例
首次命中率	第一次归属是否被最终处理人接受
误分率	被退回或改派的比例
人工兜底率	规则不确定时进入人工队列的比例
路由耗时	从创建到进入正确队列的时间

现有材料没有正式统计，因此面试时讲清指标设计，不虚构百分比。

面试官：地图解析工具解决什么问题？

直接回答

UGC 地图可能来自旧版本、弱网上传、跨平台资源和用户异常数据，只靠启动完整客户端复现成本很高。地图解析器把制品解压、解密、反序列化和规则检查放到独立工具中，使开发、测试可以离线查看地图、图层、组合和描述文件，并批量扫描异常。

flowchart LR
    A["地图包 / 描述文件"] --> B["格式与版本探测"]
    B --> C["解压 / 解密"]
    C --> D["Lua / C++ 反序列化"]
    D --> E["Schema 与引用检查"]
    E --> F["地图 / Layer / 组合视图"]
    E --> G["批量诊断报告"]

我的直接工作包括 PBinParser 的图层解析、GUI、加密描述文件和长期维护。工具随仓包含的压缩库、Lua 源码等第三方组件不能算作个人实现。

面试官：解析器怎样兼容旧地图？

读取流程应遵守“先探测、再选择解析器、最后迁移到内存模型”，不能先按最新结构读一遍，失败后再猜。

bytes
  -> container/version detection
  -> matching decoder
  -> raw versioned model
  -> stepwise migrations
  -> canonical diagnostic model

迁移最好逐级、幂等并保留原始输入。未知字段应按协议选择保留或忽略；缺少必需文件时给出明确诊断，不能只抛“反序列化失败”。对加密内容，密钥获取、明文临时文件和日志脱敏也要有边界。

面试官：诊断工具如何避免自己给错结论？

每条诊断包含规则 ID、严重级别、文件/对象路径、实际值、期望值和工具版本。Error 表示不能继续，Warning 表示风险，Retryable 则是处理策略，三者不能混成一个级别。

规则要用冻结样例回归：正常图、历史版本、部分缺失、损坏包、超大图和已知线上案例都应该进入测试集。自动修复必须生成新文件并保留原件，除非用户明确确认覆盖。

面试官：自动化测试体系怎么分层？

直接回答

静态检查便宜但不能证明引擎里能跑；真机证据最强但成本高。正确方式是分层，并让越靠后的测试只覆盖高价值主路径。

层级	主要验证	典型失败
静态契约	Schema、依赖、API、资源命名	协议漂移、引用错误
单元测试	纯函数、迁移、打包清单、状态机	边界值与算法错误
工具/构建集成	二进制转换、确定性制品、覆盖安装	多工具组合与残留文件
Client/DS 集成	启动、连接、加载、复制、退出	角色和环境不一致
UI 自动化	稳定 ID、交互、页面生命周期	能显示但无法操作
真机/性能	WebView、输入、GPU、内存、网络	平台差异和资源预算

UGC2.0 中，我做过 PixUI DOM 暴露、PlayerGui/原生 UI 稳定 ID，以及基础自动化流水线。重点不是“脚本点到了按钮”，而是节点身份在重排后仍稳定，并且测试运行在真实客户端和 DS 组合中。

面试官：静态契约测试为什么不能替代引擎测试？

静态测试能证明文件和接口形状正确，不能证明模块会被实际加载、World 生命周期正确、原生注册存在、资源能烹饪或网络角色一致。相反，端到端测试能发现这些问题，但定位慢且波动大。

因此一个缺陷应尽量下沉出最小确定性回归，同时保留一条真实运行冒烟：

线上问题
  -> 最小单元/契约回归，快速定位
  -> 集成主路径，证明真实环境已接通

面试官：你做的 AI 辅助研发具体是什么？

30 秒回答

我做过 Lua 开发规范与项目知识索引、需求/缺陷专项助手、分支对比工具、PixUI 研发技能和 Web 审计资产。目标不是让模型自由改代码，而是把任务流程、可用上下文、工具权限和验证门禁固化，让它先收集证据、生成候选，再由确定性工具和工程师裁决。

工作流

flowchart LR
    A["需求 / 缺陷"] --> B["上下文装配"]
    B --> C["模型提出计划与 Patch"]
    C --> D["权限与范围检查"]
    D --> E["编译 / 静态检查 / 测试"]
    E --> F["Diff 审查"]
    F --> G["人工提交 / 更新工单"]

上下文应包含来源、版本、适用模块和可信度，不能只把整个仓库塞进长 Prompt。需求说明、源码事实、历史问题和通用规范的信任等级不同；互相冲突时，工具必须把冲突呈现给人，而不是静默选择。

面试官：AI 工具怎样防止错误扩散？

五道边界

Grounding： 结论附带来源和版本，区分事实与推断。
权限： Tool Schema 只说明能调用什么，不等于允许对任意资源执行；路径、分支和动作要单独授权。
变更集： 多文件修改作为一个 ChangeSet，提交前检查基线 revision，失败时不能用旧快照覆盖用户新修改。
确定性验证： 编译、Lint、测试、Schema 检查和差异规则由工具执行，不由模型口头宣布成功。
人工裁决： 高风险业务逻辑、外部写入和工单状态变化保留人工确认与审计。

取消也不等于回滚。模型停止等待时，外部工具可能已经写文件或发出请求；这类操作需要幂等键、结果查询和补偿，而不是简单发一个 abort 就假设世界恢复原状。

面试官：AI 助手的效果怎么评估？

不能用生成代码量或“任务完成”自报作为指标。应使用冻结任务集，记录：

可接受变更率
一次通过率
编译/测试失败率
工程师审查与修复时间
越权或错误写入次数
线上回退和重复缺陷

还要把模型成本、等待时间和人工复核算入总成本。现有证据能证明工具和知识资产已持续建设，但团队采用率、节省工时和错误率变化仍待补，所以面试时不报没有依据的 ROI。

面试官：工程工具最重要的反思是什么？

第一，自动化的目标不是把人工判断全部删除，而是把确定部分自动完成，把不确定部分清楚地送到人面前。第二，任何会写外部系统的工具都必须有幂等、权限和审计。第三，没有度量的“提效”只是一种感受，工具上线时就应该设计采样点。

追问边界

可以直接说	应限定后再说	当前不能说
开发并长期维护 Crash 分单和地图解析工具	Git blame 是候选信号，不是绝对 owner	没有统计时宣称准确率或节省工时
做过 UI 自动化接入和基础流水线	自动化体系设计包含更多团队能力	独立建设所有项目测试平台
建设规范、知识库、缺陷助手和分支对比	AI 负责候选生成，工程师负责裁决	大量知识文件等同于等量手写代码
参与 Fate 定点数物理引擎，能结合源码讲窄相碰撞、HeightField 和定点边界	XPBD、Fate Math 与锁步框架按团队架构陈述	独立设计整套引擎，或把全部模块算作个人实现
可以准备开源协作方法论	需公开链接或仓库记录支撑	当前声称具体开源组件贡献

一分钟收口

我做效能工具时遵循同一套方法：先把输入和版本固定，再提取可解释证据，把确定性判断交给程序，把低置信度和高风险操作留给人。Crash 分单用栈、仓库和 blame 形成候选；地图解析把坏包和兼容问题变成离线诊断；自动化从契约逐层走到真实 Client/DS；AI 助手负责装配上下文和生成候选，但必须经过权限、测试与审查。这些工具真正体现的是工程闭环能力，而不是脚本数量。

定点物理的设计与实现单独见：定点数物理引擎：确定性数值、XPBD 与碰撞检测源码复盘。