把项目讲成有证据的工程经历

当前业务代码尚未实现。本页是复盘模板，不是可直接写进简历的项目成绩。

三分钟介绍结构

背景（约 30 秒）：零售集团业务人员无法直接理解复杂表结构，指标口径、Join 和权限比“写出 SQL”更难。目标是把自然语言映射到业务语义和可治理查询。

架构（约 60 秒）：控制库治理元数据与指标，OpenSearch 与 Milvus 混合召回，Linking 把概念落到字段和值，Join Graph 补路径，语义层固定口径，IR 表达计划，再经过 AST、权限、成本与只读执行，结果校验后解释。

演进（约 45 秒）：V1 建基线，V2 解决选表列和值，V3 解决指标，V4 建企业级防线，V5 处理多步分析，V6 管持续回归。选择一条真实失败说明为什么需要其中一层。

证据与取舍（约 45 秒）：给出你亲自复现的测试、实测提升和成本，说明仍不能保证什么。没有测得的指标不能使用总纲示意数字替代。

每个故事收集一张证据卡

字段	该写什么
具体问题	哪个用户问题失败，什么结果错了
最小数据	哪几条记录足以复现，数据版本是什么
根因	召回、链接、指标、权限还是执行
方案	改了哪个模块，契约怎样变化
备选	为什么没用另一种更简单/更复杂方案
验证	哪条测试和 Gold 证明修复，是否引入回退
实测	同版本基准、题数、质量、延迟与成本
限制	尚未覆盖的场景与可能失败方式

V4 最值得讲清的四件事

1. Join 扇出：表和键都对，为什么金额还能翻倍；为什么先聚合或存在性过滤比 DISTINCT 修补更可靠。
2. 指标版本：相同 SQL 字段无法代表相同业务口径；发布、回归、索引和缓存如何协同。
3. 全链路权限：为何在检索前过滤，还要在 SQL 和数据库再次约束；修复为何不能处理权限错误。
4. 可测量演进：如何通过 V1 失败分类与 V2 消融，把架构收益变成证据。

如何诚实说明 AI 的参与

可以说：“我让 AI 按明确故事和验收实现初稿，再通过手算夹具、失败实验和代码走读理解并验证设计。”关键是能解释你评审和验证了什么，能现场改一个条件并预测行为。不要把“AI 生成了很多代码”当作工程贡献本身。

完成后的简历句式

围绕【真实业务问题】，设计/实现【你完成的模块】；
在【数据版本、题数、环境】上，用【测试/比较规则】验证【实测变化】；
通过【治理机制】约束【实际风险】，代价为【实测成本或限制】。

替换不了括号就先不要写成绩。规模、准确率和生产部署都需要 验收证据。