面试表达：如何讲清楚“我会用 AI”
“会用 Claude Code、Codex”没有区分度。区分度来自：能否把模糊问题拆清楚，控制 AI 的边界，并用证据证明结果。
这份表达只使用当前可证明的事实：生态店铺 GMV 清洗迁移是企业项目；异构数据同步平台是持续开发中的个人项目。没有运行记录的吞吐、成功率、效率提升不写成成果。
30 秒版本
我有 5 年以上 Java 企业应用经验，做过供应链、经营数据和业财系统。
现在我把 Claude Code、Codex 等工具放进真实交付流程：先还原业务规则和调用链，
再由我确定领域边界、接口契约、失败语义和验收标准，AI 辅助分析、实现和测试，
最后通过代码审查、异常场景和数据核对验收。
在生态店铺 GMV 迁移里，我把分散在旧文档、历史任务和数据库调用关系中的规则，
梳理成九个平台执行模块和统一总控。我的优势不是“生成代码快”，
而是能判断哪些结论可信、哪些决策不能交给模型，以及怎样证明迁移没有改错口径。
2 分钟版本
我使用 AI 的方式可以分成五步。
第一步是证据梳理。面对遗留系统，我不会直接让 AI 重写，而是让它辅助检索旧文档、
任务、SQL 和调用关系，先形成“平台—源表—日期—销售/退款—目标表”的口径矩阵。
每条结论标记为代码已证实、文档说明或待业务确认。
第二步是我做关键决策。比如 GMV 迁移采用总控 + 九个平台执行器，
总控只处理平台选择、日期校验、失败策略、结果聚合和汇总门禁，
平台差异留在各自模块；预览不写库，目标表受白名单控制，
任一平台失败都不能把部分结果包装成完整汇总。
第三步是任务拆分。我把证据梳理、契约设计、单平台迁移、总控实现、
独立验证和新旧核对拆开，给 AI 的每张工作单都有允许范围、禁止事项和验收标准。
第四步是交叉审查。实现会话不能直接宣布自己正确，审查只看规格、diff 和测试，
重点检查平台口径是否泄漏到总控、预览是否有副作用、失败是否越过汇总门禁。
第五步是结果验收。功能测试通过只证明实现符合规格；
还要用同平台、同日期范围核对新旧行数、销售额、退款额和关键维度。
没有完成的数据核对和生产指标，我会明确写成待补证，不写成量化成果。
企业项目深挖：生态店铺 GMV 清洗迁移
背景与难点
这个项目不是从零写一个报表，而是迁移旧的数据清洗链路。
难点是规则分散在旧文档、历史任务、SQL 和数据库调用关系里，
九个平台的日期、销售、退款、字段和归属规则又不完全相同。
如果只按现有 SQL 翻译，代码能运行，但口径可能已经丢了。
我主导的判断
我先把旧链路整理为可追踪的口径矩阵，再决定 Java 迁移边界。
结构上采用“平台差异隔离、公共流程统一”：
九个平台分别保留取数与清洗规则；总控统一平台选择、日期校验、
失败继续/停止、结果聚合、通知和完整汇总刷新。
我还明确了两条容易被忽略的控制：
save=false 只预览，不能删除、写入或刷新汇总；
save=true 的目标表必须来自配置白名单。
AI 怎样参与
Claude Code、Codex 等工具用于分析代码库、追踪调用关系、生成候选规则文档、
按工作单实现平台模块、补测试和检查 diff。
我负责确认事实、选择方案、冻结跨模块契约、审查关键路径和最终验收。
模型可以告诉我“代码可能怎样组织”，但不能替我确认某个平台退款是否计入、
某个日期字段是不是业务口径，也不能自行决定部分失败是否允许刷新汇总。
当前证据边界
目前代码与文档可以证明：九个平台执行器、统一入口、预览/写入、
失败策略、目标表白名单、平台级运行结果和汇总门禁已经形成。
新旧链路同范围金额核对、性能变化、长期生产成功率仍需运行记录补齐，
所以我不会在简历或面试中编造百分比。
完整证据见生态店铺 GMV 清洗迁移。
个人项目深挖：异构数据同步平台
这是我持续开发的个人项目，目标不是再做一套数据同步 CRUD，
而是把数据源管理、同步任务、任务编排、日志中心、数据血缘、用户管理和业务预警
组织成一条“接入—运行—追踪—影响分析—预警—处置”的闭环。
我先冻结 DataSource、SyncTask、Workflow、RunInstance、LineageEdge 和 AlertRule
这些核心对象，再让页面和后端围绕同一状态模型展开；
同步任务负责一条链路，任务编排负责多节点依赖，二者不混在一起。
Claude Code、Codex 辅助代码分析、页面实现、测试和文档整理；
我负责交付语义、领域模型、模块契约、故障场景和验收边界。
当前能证明的是系统设计、功能代码和可运行页面，
真实吞吐、延迟和长期稳定性要等接入测试环境并形成运行记录后再说。
完整复盘见异构数据同步平台。
被质疑“是不是 AI 写的”
AI 参与了分析、实现和测试，这一点我会直接说明。
但我不会把“敲代码的比例”当价值证明。
你可以继续追问我：旧口径怎样确认、为什么这样划分模块、
平台失败为什么不能刷新完整汇总、预览副作用怎么验证、
目标表为什么要白名单、新旧差异怎样定位。
这些判断、取舍、审查和验收是我负责的，也是我能讲清楚的部分。
高频追问
“你怎么保证 AI 代码质量？”
我不靠相信模型，而是让检查标准在生成之前存在。
先冻结输入输出、错误语义、模块边界和验收用例；
实现与审查分开，审查只看规格和 diff；
测试必须覆盖预览、未知平台、无效日期、两种失败策略、白名单和完整成功；
最后做新旧数据核对。发现问题后还要追问“哪个上游环节本该拦住”，
再把它补回规则、工作单或测试。
“所有任务都用多 Agent 吗？”
不会。低风险单文件改动直接实现和回归；
涉及数据写入或契约的任务增加独立审查；
只有像 GMV 迁移这样跨平台、涉及经营口径和存量链路的任务，
才值得拆成证据、实现、验证和核对多个上下文。
流程的重量必须和缺陷代价匹配。
“AI 写错了怎么办？”
先分类：是事实取错、边界越过、失败语义缺失，还是测试没有守住。
修代码只是第一步；第二步是把同类问题加入体检问题、禁止事项或验证用例。
比如总控出现平台特例、preview 发生写入、部分失败仍刷新汇总，
这些都可以变成下次交付前就检查的缺陷模式。
“这套方法是你发明的吗？”
不是凭空发明。规格驱动、上下文工程、独立审查和 Agent 编排都有行业实践。
我做的是把这些方法放进自己的 Java 企业项目，围绕遗留逻辑迁移、
跨系统集成和数据口径验证形成可执行流程，并持续用真实证据校正。
我不会把引用来的概念说成原创，也不会把尚未落地的设计说成成果。
简历表达参考
主导生态店铺 GMV 旧链路迁移：借助 Claude Code、Codex 等工具梳理历史文档、
任务、SQL 与数据库调用关系，形成九平台口径矩阵；设计总控 + 平台执行器边界，
落地预览/写入、失败策略、目标表白名单、平台级结果与完整汇总门禁，
并通过测试和新旧同范围数据核对持续验证迁移正确性。
独立设计并持续实现异构数据同步平台：围绕数据源、同步任务、编排流程、
运行实例、血缘与业务预警建立统一领域模型；使用 AI 工具辅助代码分析、
实现与测试，本人负责交付语义、跨模块契约、代码审查和验收边界。