FDE / AI 工程岗：真实面试题与口述答案

这组题按用户提供的 FDE 面经截图整理，编号 F01 至 F11 对应截图编号，不代表某公司的官方题库。FDE 通常指 Forward Deployed Engineer，即贴近客户现场把产品与业务流程落地的工程角色。涉及 “你用过” 和 “你做过” 的题，下面给出不虚构履历的回答口径；若你有更多可验证经历，再替换成真实项目。通用原理可复习 Agent 框架选型、RAG 和 Agent 评测。

工具选择与 AI 辅助研发

F01. 用过哪些 AI 编码工具？Claude Code、Codex、WorkBuddy 怎样区分场景？参考答案

我实际用过 Claude Code 和 Codex，主要用来读项目、实现功能、定位问题、补测试和审查改动。我的用法不是让 AI 一次生成一堆代码，而是先明确约束和验收，再让它完成一个能验证的任务。例如先让它解释现有调用链和修改范围，再实现并运行相关测试，最后检查 diff 和失败路径。

Claude Code 和 Codex 都属于编码 Agent，能力有重叠。我也会用 Slash Command、Skill 或 JS Workflow 固定重复流程，让不同任务分别负责分析、实现和审查；但工具提出的结论仍要用代码和运行结果验证。选哪个不只看聊天回答，而看同一批真实任务的正确率、返工量、完成时间和费用，也看权限控制及团队集成是否合适。

WorkBuddy 更偏面向办公任务的通用工作助手，适合调研、文档和表格等交付物，也能覆盖部分开发工作。它不是我这段编码实践的主要依据，我不会把产品了解说成深度使用经验。主要改仓库代码时，我优先编码 Agent；主要整理资料或交付办公成果时，再评估通用助手。产品介绍：Codex、Claude Code、WorkBuddy。

F02. 多任务开发时，怎样借助 AI 提高效率？参考答案

我会并行安排真正独立的工作，不会把同一个模糊需求同时扔给几个 AI。先拆依赖和接口，再为每个任务说明可以改哪些文件、输入输出是什么、怎么验收。例如后端按接口契约实现，前端用约定数据开发，测试任务准备异常用例，这几块可以同时推进。

共享的数据结构、数据库迁移和发布顺序需要统一决策，否则几个 Agent 各自做得很快，最后却拼不起来。代码修改尽量隔离在不同文件或工作分支；依赖没确定的任务先做分析，不抢着实现。让 AI 审查另一个 AI 的产物也不能代替测试，仍要核对实际 diff、权限、兼容性和边界行为。

最后统一集成，跑相关回归，遇到冲突按接口和验收标准解决，而不是看谁最后提交。衡量收益时我看从接需求到可合并代码的总时间，也算人工审查、返工和 Token 成本。并行的目标是缩短关键路径，不是增加同时工作的 Agent 数量。

知识图谱与行业数据工程

F03. 有自研知识图谱框架的实践吗？参考答案

我没有自研通用知识图谱框架的项目经历。Aladdin 里主要是语义检索和任务工作流，任务依赖图不等于知识图谱：前者说明先做什么后做什么，后者记录业务实体以及它们之间的关系。

如果要落地，我会先从要回答的问题倒推实体和关系。比如要查哪些产线使用某批材料，可以建材料批次、设备、产线等实体，以及使用、归属等关系，再沿关系查询。文档抽取只是第一步，还要解决同名不同物、不同名称指同一实体、关系有效时间和来源证据；否则图画得很复杂，查出的关联却不可靠。

向量检索擅长找语义相关材料，图查询擅长沿明确关系做多跳查找，两者可以配合。我的方案会先用现有图数据库和一组可验收问题跑通，建立实体与关系的人工标注和抽检，再考虑封装共用能力。没有业务验证前，不会先造一个通用框架，也不会把模型抽到的关系直接当事实。

F04. 用 AI 辅助开发业务 APP，怎样配置人员和分工最有效？参考答案

我会先分清需要谁承担责任，再决定需要几个人，而不是先按 AI 能省多少人来排团队。至少要有人负责业务规则和验收，有人负责架构、数据和权限，有人实现前后端及 AI 链路，也要有人负责测试与发布。这些角色在小团队可以兼任，但责任不能缺。

例如做一个业务审批 APP，业务负责人先确认审批条件和例外，技术负责人把状态和接口定下来，前后端再并行实现。AI 适合生成页面初稿、重复代码、测试用例和迁移建议；涉及行业规则、隐私、资金以及上线审批，必须由负责人确认。测试应早参与，提前准备越权、重复提交、审批撤回等异常用例，而不是最后只点一遍页面。

我会先交付一条端到端的核心业务链路，确认技术和业务都能跑通，再扩展功能。人数随业务复杂度、交付期限和维护责任调整；AI 生成速度提升后，瓶颈可能转移到需求澄清、审查和集成，所以还要控制并行任务量，避免产生大量没人验收的代码。

F05. 过去项目中用 AI 解决了哪些真实业务问题，有哪些不同用法？参考答案

在 Aladdin 里，AI 分别解决找谁做、怎么拆、怎么产出三个问题，这三种用途不是同一个模型调用。匹配环节用 Embedding 把任务描述和 Agent 能力描述转成向量，找出语义接近的候选，弥补仅按标签或关键词匹配的不足；但是否满足业务条件仍由代码过滤。

规划环节让大模型提出任务节点和依赖，例如设计先完成、Coding 再消费设计结果；代码检查依赖有无环、输入输出是否匹配。执行环节再由具体 Agent 生成代码、设计稿或文档，交付物经过校验和验收，不能因为模型说完成就结算。

系统还训练了用于候选评分的排序模型，目前在 shadow，也就是影子路径里记录预测分数，用来和实际策略对比，不参与线上排序决策。我不会把它表述成已经提高线上转化率。这个项目的原则是模型处理语义理解和内容生成，代码与合约负责权限、状态和资金边界；AI 的不确定性不能直接变成业务的不确定性。

F06. 1TB 多模态原始文件怎样提取、清洗并建知识库和知识图谱？CPU/GPU 膨胀怎么办？参考答案

我会把 1TB 文件处理成一条可增量执行、失败后只重做局部的离线流水线，而不是一次性加载或统一送进模型。先建立文件清单，记录类型、大小、哈希、权限和版本，原件进入对象存储；不同类型分别做文本解析、版面识别、图像理解或音视频转写。

每一步输出可追溯的中间结果。清洗去重后，一路生成带出处的文本块和向量索引，服务语义检索；另一路只抽业务需要的实体和关系，经过归一、校验和抽检后进入知识图谱。用文件版本、处理阶段和配置版本识别一次处理，失败可以从中间结果续跑，升级解析器时也知道哪些数据需要重算。

资源上涨要先找原因：是反复解析重复文件、某批扫描件特别大，还是 GPU 推理跟不上。常规解析和压缩用 CPU，模型推理根据实际负载选择 CPU 或 GPU，不是所有 OCR（光学字符识别）任务都必须占 GPU。阶段之间用有界队列，上游在下游忙不过来时减速，这就是背压；同时限制单文件内存和运行时长，异常文件单独处理。最后按每类文件的吞吐、失败率和单位成本扩容，不能仅凭 1TB 就估算需要多少 GPU。

F07. 多个异构数据库怎样做 ETL？CPU/GPU 资源上涨怎样解决？参考答案

ETL 是抽取、转换、加载。异构数据同步的难点不只在搬运，还在于不同来源能不能对齐，以及重复、乱序和删除会不会把结果弄错。我会先确定源系统的主键、字段语义、时区、编码和删除方式，原始数据进入可追溯的暂存层，再转换成统一模型。

首次全量同步后通常接增量。支持 CDC，也就是变更数据捕获的源，我会利用数据库日志位置衔接一致性快照与后续变更，避免全量和增量之间漏数据；只能轮询的源，则使用可靠游标、重叠读取和去重，并明确如何发现删除。写目标库时按业务键幂等更新，同时校验来源版本，防止较旧事件晚到后覆盖新值。

资源方面先看慢在源库读取、网络、转换还是目标写入，再做批量、分区并行和限速，避免同步任务压垮业务库。普通 ETL 主要消耗 I/O 和 CPU，不默认需要 GPU；只有额外的语义抽取、Embedding 等模型步骤才单独安排推理资源。发生失败先恢复游标和未完成批次，而不是全表重跑，用对账和抽样验证同步后的完整性。

F08. 钢铁行业非结构化文档怎样抽取实体、工艺参数？参考答案

我会先确定业务要用哪些参数、参数在什么条件下成立，再让模型抽取。这类行业数据不能只拿到一个数字。例如温度必须同时知道属于哪道工序、对应什么材料、单位是什么，以及它是建议范围、上限还是实际测量值。

具体会先和工艺专家定义字段、实体字典和标注样本，解析时保留标题、表格、脚注及页码，再让模型输出结构化结果。比如示例文档写某材料在某工序的温度为 850～900℃，结果应包含材料、工序、最小值、最大值、单位、适用条件和来源，不能只抽成温度 900。这里的数字只是说明抽取方式，不代表具体工艺标准。

代码随后检查单位换算、范围关系、必填项和实体对应，原文没有的信息返回缺失而不是猜测。冲突版本、识别模糊和高风险参数由专家复核，评分看字段准确率、漏抽和来源可追溯性。未经验证的抽取结果不能直接变成设备控制参数，知识整理与自动控制之间还需要独立的安全审批。

Agent 运行框架与产品边界

F09. LangChain / LangGraph 与开源 Codex CLI 有何区别、优缺点，怎样选？参考答案

它们的主要区别是我在搭建业务 Agent，还是直接使用一个已经集成好的编码 Agent。LangChain 提供模型、工具和 Agent 组件，LangGraph 提供状态图、分支和持久执行等编排能力；用它们构建应用时，我仍要设计用户入口、业务数据、权限、部署和评测。Codex CLI 则已经把读仓库、改文件和运行命令等编码能力组织成可使用的产品。

例如面向客户做一个需要查业务数据、审批后才能执行操作的助手，我会评估业务框架，因为需要自己控制状态和权限；为研发团队做代码修改、测试或自动审查，则可以优先集成编码 Agent，减少从零搭建工具链的工作。Codex 也可以接入自动化流程，并不只能手工聊天；反过来，用框架也能造编码 Agent，只是要承担更多建设成本。

框架的优势是业务定制空间大，代价是实现和运维责任更多；现成编码 Agent 的优势是开箱可用，代价是要适应它的接口、执行环境和安全边界。所以选型要用真实任务比较可控性、集成成本和结果质量，不能直接比较谁更聪明。可核对 Codex CLI 官方说明，通用边界见 Agent 框架选型。

F10. DeepSeek Harness 的主要作用是什么？参考答案

DeepSeek 模型负责推理，DeepSeek Harness 负责把模型组织成能持续执行任务的 Agent。它不是另一个大模型。比如用户要求修复代码，运行框架需要把上下文交给模型，执行模型提出的文件或命令操作，把结果传回，再继续判断下一步，直到完成、失败或达到限制，这就是 Agent 执行循环。

DeepSeek Harness 的特点是把模型适配、工具、会话、审批和执行循环等能力做成插件。需要换会话存储、增加专用工具，或修改模型和工具之间的执行方式时，可以在这些边界上定制，而不只是改变提示词。JS Workflow 进一步用代码安排子任务、并行和多阶段处理，但这些编排最终仍依赖底层的 Agent 执行能力。

它适合需要定制运行机制的团队，自由度的代价是要自己承担插件兼容、工具权限、状态恢复和升级测试。一切皆插件不等于接上插件就自动安全可靠；它仍处于开发者预览阶段，采用前要评估版本兼容性，并验证实际任务效果和维护成本。架构依据见 官方仓库 与 架构说明。

F11. DeepSeek Harness 与 Claude Code 有什么区别，原因是什么？参考答案

我认为两者最核心的区别，是能不能深入修改 Agent 的运行机制，而不只是能不能加工具。

Claude Code 已经把读代码、改文件、执行命令和多 Agent 协作整合好了。我们可以通过 Skill 固定开发规范，通过 MCP 接入业务系统，通过 Hook 加检查，也可以写 JS Workflow 编排任务。但这些主要是在它提供的接口上扩展，不是自己重写底层执行机制。

DeepSeek Harness 则把模型适配、工具注册、会话存储，甚至 Agent 循环本身都做成可替换的插件。Agent 循环就是模型判断下一步、调用工具、读取结果，再继续执行的过程。需要深入调整这些行为时，它提供的修改空间更大。

比如只是在提交前加代码审查，Claude Code 的 Hook 就能解决，没必要换框架；但如果团队要替换会话存储后端，或者修改模型与工具之间的执行循环，DeepSeek Harness 更适合。这种自由度的代价，是团队要承担更多集成、兼容性测试和维护工作。

所以我会根据需求选择：主要提升研发效率，用 Claude Code；需要深度定制 Agent 运行机制，再考虑 DeepSeek Harness。不是简单比较哪个模型更聪明，也不是说 Claude Code 不能扩展。

JS Workflow 的编排思路相同，但接入方式和支持的运行能力不完全一样。

两者都支持 JS Workflow：用 JavaScript 安排任务，通过 agent() 派子 Agent，用 parallel() 并行执行，用 pipeline() 让每项任务依次经过多个阶段。

区别主要在接入方式和运行能力。Claude Code 可以通过 /effort ultracode 自动规划工作流，也可以运行提前保存的脚本；DeepSeek Harness 则通过工作流插件和 workflow 工具执行脚本。

它们的接口也不是完全兼容。例如 Claude Code 脚本里的 meta，在 DeepSeek Harness 中要放到工具参数里；DeepSeek Harness 的工作流 agent() 也不支持同样的 effort、agentType、isolation 配置。因此，流程设计可以复用，脚本迁移仍需要适配，不能原样复制就认为行为相同。

在 Claude Code 中写 JS Workflow，是使用它提供的编排能力；DeepSeek Harness 的开源插件架构，则允许进一步修改提供这些能力的运行机制。

具体函数与使用方式可复习 Dynamic Workflow 函数与参数。参考资料：DeepSeek Harness 架构、DeepSeek Harness 工作流工具、Claude Code 扩展机制、Claude Code Dynamic Workflow。