科大讯飞飞凡计划研发面经：数据治理 Agent、Skill 治理与换模型的耦合成本

《面试题目》

项目与数据治理

1. 请做自我介绍。
2. 项目追问：指标 A 是怎么打标的？是单点归因吗？
3. 项目追问：这类指标是否一定需要完整的数据治理链路？能不能轻量化实现？
4. 梳理一下链路：原始数据 → 分层表设计 → 数据清洗 → 指标映射，是这样吗？
5. 度量 AI 编码效果的项目中，日常是否使用 AI 辅助工具？
6. AI 工具能否独立完成整套数据治理流程？人类工程师相比 Coding Agent 的核心优势是什么？
7. 设想构建一个数据治理 Agent，设置规则护栏让 AI 独立完成全链路治理，现阶段可行吗？
8. 面试官认可人工打样的价值，追问：Agent 运行时的 Memory 可否作为多 Agent 交互的载体，替代部分人工文档？

Agent 与 Skill 治理

1. 介绍一下 Open Cloud 智能管理平台自动化测试相关的开发经历。
2. 更换底层大模型，是否需要重新调优 Skill？
3. 不同模型的指令跟随差异很大，模糊指令容易造成 Skill 匹配出错，频繁换模型是否要全量重评 Skill？这里的耦合成本很高。
4. 追问：这个方案仍然有漏洞——底层选择的模型一换，选择结果依然会变，怎么应对？
5. 追问：Skill 规模大时人工维护提示词不可行，模型切换也不能靠人工全量重测，系统需要自进化的能力，怎么办？
6. 面试官提出「先搭建框架与评价体系，再交给 Agent 执行，人工只复核关键决策，用结果围栏管控不确定性」，你怎么看？

实习、学习与反问

1. 这段实习最大的收获是什么？
2. AI 数据开发对比传统数据开发，需要额外掌握哪些能力？
3. 平时通过哪些渠道学习 AI、Agent 前沿技术？
4. 了解 DeepSeek R1 吗？
5. 未来想做的工作方向是什么？
6. 反问：咱们研发岗的工作职责和内部 AI 落地情况是怎样的？

《参考解析》

指标打标与归因，要能区分「口径」和「算法」两层。 指标 A 这类打标问题，面试官想听的是标签怎么定义、由谁定义、用什么数据算出来。回答可以拆成三步：口径层说清标签的业务定义与边界（哪些样本算正、哪些算负、时间窗口多长），实现层说清数据来源与计算方式（埋点字段、离线表还是实时流、规则打标还是模型打标），校验层说清怎么验证标签质量（抽样人工核对、与业务方对齐口径、看标签分布是否漂移）。追问「是不是单点归因」时，要主动说明单点归因的适用条件和局限：只有一个触点时它足够，多触点并存时会高估最后一步的作用，这时要么做归因窗口划分，要么按规则/模型做多触点分权重，同时承认归因结果只是业务决策的参考而不是事实。

「要不要完整的数据治理链路」是一道成本题，答案取决于谁在用这份数据。 完整链路（原始层 → 明细层 → 汇总层 → 应用层，加元数据、血缘、质量监控）的价值是口径统一、可追溯、可复用；代价是建设周期长、维护人力大。判断标准可以落在三件事上：这份数据的使用者有多少、指标变化的频率有多高、出错的代价有多大。只有一两个人临时看、口径不常改，用宽表加脚本轻量化实现就够了，但要把口径写进文档；一旦指标进入考核或对外披露，血缘、口径存档和质量告警就不能省。这样回答比单纯说「需要」或「不需要」更像做过项目。

为什么 Agent 暂时替代不了人工全链路治理，关键是「输入输出没被定义清楚」。 数据治理里大量工作是判断而不是执行：某个字段的业务含义、两个口径冲突时以谁为准、脏数据是清洗还是保留。这些判断依赖和业务方对齐，而 Agent 只能执行已经被明确表达过的规则。所以现阶段的可行形态是人工先跑通全链路、把每个环节的输入输出和判定标准沉淀成文档与知识库，再让 Agent 在护栏内执行、人工复核关键决策，用结果围栏（对产出做自动校验和回滚）控制不确定性。人类工程师的不可替代之处在于定义问题、对齐需求、对异常做兜底判断，而不是写得更快——把这条讲清楚，比强调「AI 还不行」有说服力。

Memory 替代不了文档，因为两者承担的责任不同。 运行时 Memory 是 Agent 的上下文状态，可读写、可能被覆盖、难以评审，适合承载「这一轮任务里已经确认过什么」。人工文档和知识库是不可变的事实源和契约：谁定义的、什么版本、改了要通知谁，都要能追溯。更稳的设计是让 Memory 只做缓存和会话上下文，真正的定义、规则和接口说明落在版本化的知识库里，Agent 每次按需检索，产出再回写知识库时要走人工评审——这样多 Agent 之间共享的是同一份契约，而不是各自记得不一样。

换模型要不要重评 Skill，本质是 Skill 的写法决定了耦合有多深。 如果 Skill 是一大段自由文本的提示词，模型一换，指令跟随风格、工具调用格式、甚至对示例的敏感度都会变，只能全量重测；把 Skill 结构化——技能清单加参数 schema、明确的触发条件与不适用场景、少量高质量示例、输出格式约束——迁移成本就会降到「改清单和校验器」的量级。工程上的配套是三件事：在 Agent 与技能之间加一层知识库/路由层，主 Agent 只负责选择、多个 Sub-Agent 各自判断，降低单点决策的复杂度；建一套与模型无关的回归评测集，换模型只跑评测集而不是手工重测；再叠一层结果围栏，输出不合格直接拦下重试。要诚实地承认这套方案的边界：换模型后选择结果仍可能漂移，评测集覆盖不到的角落一定会有，所以还需要人工抽检和线上指标回流，系统才谈得上「自进化」——自进化的前提是先有人工标注的评测基线和反馈闭环，不是让模型自己改自己。

末段的软性问题同样在做能力判断。 实习收获题要落到可迁移的东西：工业级的湖仓架构实践、借助 AI 快速进入陌生技术栈的方法、以及角色从「自己产出」转向「管控 Agent 与迭代知识库」的转变。AI 数据开发与传统数据开发的差别，可以答在链路完整度与技术栈上：埋点与数据传输、消息中间件与流处理、湖仓表格式（如 Iceberg）与存储治理，加上把 AI 真正用进研发流程的能力，以及懂业务、能把链路讲通。学习渠道题不要只报平台名，讲清「看什么 → 在项目里怎么验证 → 得到什么结论」的闭环更可信。

面试官最后交的底，比前面的问答更值得复盘。 他明确说这个岗位不做数据治理、聚焦人机交互，业务线是语音全链路智能体（赋能传统行业与硬件厂商）和机器人超脑平台交互研发，工作内容包括垂域模型微调蒸馏、推理优化、以及搭建 Harness 框架做智能体；团队「All in 大模型」，97%—98% 的代码由 AI 生成，人力转向架构与业务，原来 20 人的项目现在 4—5 人即可完成。这些信息的含义有两层：一是业务不 match 时，回答技术问题答得再好也可能被判定为不合适，所以反问环节一定要问清岗位职责和团队在做什么，越早问越好；二是「代码大部分由 AI 生成」的团队，面试筛的是架构判断、业务理解和把 AI 用出结果的能力，候选人在反问里追问团队的评测方式与人工兜底机制，会显得是认真考虑过要来做这件事的人。原帖没有写最终结果。