AI 全栈应用岗：真实面试题与口述答案

这组题按用户提供的 AI 全栈面经截图整理，编号 A01 至 A10 对应截图顺序，不代表官方题库。题目覆盖后端与 Agent、前端、交付和软技能。涉及个人经验时，只能用自己实际负责且能说明证据的项目回答；下面的口径可作为表达骨架。可结合 Skill 设计、Agent 开发总览 和 项目面试手册复习。

后端与 Agent：选择、执行和权限

A01. 系统有几百上千个 Skill，怎样让模型准确选择和调用？参考答案

我会先缩小候选范围，再加载需要的 Skill，而不是让模型一次读完上千份说明。Skill 是任务方法包，通常包含指令、资料和可选脚本，不等于一个有输入 Schema 的工具函数。先建立包含名称、用途、触发条件和权限要求的目录，用任务类别和环境过滤，再结合关键词或语义检索找少量候选。

选中后加载完整主说明，按当前任务需要再读取相关资料和脚本；如果说明显示不适用，就重新选择。比如用户要求分析表格，目录应能区分只做数据统计和修改工作簿格式，不能几个 Skill 都写成处理文件。对容易混淆的 Skill，补清适用与不适用条件，比无限增加候选更有效。

实际工具调用仍由服务端检查权限和参数，选中 Skill 不代表拿到了额外权限。评测要同时看正确 Skill 有没有进入候选、最终有没有选对，以及任务是否完成，这样才能区分检索问题、目录描述问题和执行问题。具体设计可复习 Skill 的设计与复用。

A02. 从用户输入到最终输出，一条大模型应用链路发生了什么？参考答案

一条链路可以概括为确认身份和目标、提供上下文、让模型决策、执行受控工具、验证真实结果。模型返回的不一定是最终答案，也可能是工具调用请求；真正有权限执行动作的是服务端，不是模型自己。

例如用户要查订单配送进度，服务端先确认身份和预算，再提供任务说明及允许的工具。模型提出查询某个订单，服务端校验订单归属和参数后调用业务接口，将物流结果交回模型，模型再整理成用户能理解的回答。如果需要继续补查，就在步数和时限内继续这个循环；不需要工具的问题则直接生成，没必要强行走复杂链路。

如果是修改订单，还要检查业务状态、用户确认和幂等性，不能只看模型说修改成功。最终保存必要的消息、工具结果和调用轨迹，进行输出安全检查，再返回文本或流式事件。长任务独立保存运行状态，失败能够从明确位置恢复；每一段的耗时和错误也要能追踪，才能知道慢或错发生在哪里。

A03. 用户只输入一句话，怎样判断复杂度并路由简单或复杂模型？参考答案

复杂度不由输入长短决定，而由完成任务需要多少能力、多少步骤以及出错代价决定。一句帮我把支付系统迁移到新版本很短，但需要理解依赖、修改和验证；一大段按指定格式提取字段，反而可能比较确定。

我会先根据任务类型、输入规模、是否依赖多种工具、是否存在跨步骤关系和风险等级做规则分流，模糊情况再用轻量分类器判断。简单且可验证的任务先走低成本路径；未知类型、上下文不足或高风险任务，选择更强模型、补充提问或人工确认。高风险不等于换强模型就可以省掉审批。

路由也不是一次判断后不能变。轻量模型产物如果没通过结构或业务校验，可以在总预算内升级；不能只相信模型自报的置信度。上线前用标注任务比较误分流、最终完成率、总延迟和总费用，尤其看升级重试会不会把省下的钱又花回去。

A04. SQL 熟练度如何，实际使用到什么程度？参考答案

我的 SQL 主要用于业务查询、一致性控制和性能排查。Aladdin 的 PostgreSQL 保存任务、Agent、任务分配和执行尝试等数据，除了按用户、任务和状态查询，更重要的是并发或重试发生时，数据也不能被错误推进。

例如完成任务时，更新语句同时带任务 ID 和预期旧状态，检查影响行数；两个请求同时完成同一任务，只有满足条件的那个可以推进，另一个应读取当前结果，而不是继续执行重复副作用。多个相关写入放事务中，唯一约束用于兜住重复业务键。应用先查有没有、再决定插入，仍可能被并发穿透，所以不能只靠这一层判断。

慢查询先用 EXPLAIN 看计划，检查扫描行数、连接方式和排序，再根据真实过滤条件设计索引，并验证写入成本。需要真实执行数据时，再在安全环境使用 EXPLAIN ANALYZE，因为它会实际运行语句。ORM 方便组织查询，但不会自动解决事务、N+1 查询和索引问题；数据库运维及复杂分库分表则需要另按规模评估。

A05. 行级权限怎样实现？参考答案

行级权限就是即使用户能访问这个接口，也只能读写自己被允许操作的那些行。比如两个用户都能查询订单，但用户 A 不能靠修改订单 ID 看到用户 B 的订单。服务端必须从已认证身份推导用户和租户范围，不能相信前端传来的 ownerId。

落实时把权限条件与资源条件一起放进数据库查询和更新。例如按订单 ID 查询时同时限制所属租户，更新也带同样的范围；如果先只按 ID 查出数据再忘记鉴权，就会形成越权入口。列表、数量统计、导出、批量操作和向量检索都要遵循同一规则，不能只保护详情页。

数据库 RLS，也就是行级安全策略，可以作为第二道防线，但要用真实应用角色验证，不能拿可绕过策略的管理员身份测试后就认为有效。连接池中的租户上下文要限定作用域，缓存键也要区分租户和权限范围。最终专门测试跨租户猜 ID、共享缓存和权限撤销，确保读和写都不会串数据。

前端性能与多语言工程

A06. 万行数据搜索、渲染慢，怎样处理？参考答案

我先测慢在取数据、计算筛选，还是把结果渲染成 DOM，因为这三种问题的解法不同。一万行不是一个固定的性能结论，每行有多少字段、组件多复杂、搜索规则是什么，都影响结果。

常规在线列表把搜索、过滤、排序和分页放服务端，前端只取需要的范围。必须滚动展示大量行时用虚拟列表，只渲染可见区域及少量缓冲；它能减少 DOM，但不会自动降低一万条数据的下载量或筛选计算量。若确实要离线处理全部数据，可以评估索引和 Web Worker，把耗时计算移出主线程，但仍有数据传递成本。

输入搜索做防抖，避免每个按键都发请求；取消旧请求之外，再用请求序号或查询键阻止旧响应覆盖新结果。组件层面保持稳定 key，减少无关行重渲染，最后用性能工具对比输入响应、渲染耗时和内存。不能只是加几个 memo，就认为大列表问题解决了。

A07. Java 项目从部署到上线的流程、回滚怎样做？参考答案

如果由我负责 Java 项目交付，我会把流程分成产出可追溯的版本、验证运行条件、小范围发布、确认可回退。测试和检查通过后构建带版本标识的 JAR 或镜像，同一份产物依次进入预发和生产，配置及密钥独立管理，避免上线时重新打包产生差异。

预发先验证数据库迁移、连接配置和关键业务链路。生产滚动或灰度发布时，进程启动不代表能接流量，还要确认依赖和初始化完成；旧实例停止接新请求后，给在途请求合理时间完成，再退出。监控错误率、P95 延迟（95% 请求耗时不超过的值）、连接池和业务成功指标，异常就停止扩大发布并把流量切回旧版本。

数据库是回滚最容易踩坑的地方。比如字段改名，先加新字段并兼容新旧版本，迁移数据和切换读写确认后，再删除旧字段；直接删旧字段，应用回退也可能启动不了。因此应用回滚、数据库兼容和数据修复要分别设计，不能只准备上一版镜像。

A08. 能看懂 Go 代码吗？AI 生成的 Go 代码怎样分析、排查问题？参考答案

能，我会从业务入口和数据流读 Go 代码，而不是只看语法。结合 Aladdin 的 Go Dispatch Engine，我重点看任务如何领取、何时结束，以及出错后谁负责释放资源和推进状态。先沿接口、数据库访问和外部调用追踪，再理解每个 Goroutine 的生命周期。

例如请求超时后，启动的 Goroutine 如果没有监听 context，也没有自己的超时，可能仍占着连接执行；往 Channel 发送结果时，如果接收者已经退出，还可能一直阻塞。共享 map 或状态被多个 Goroutine 读写时，要看是否有正确同步；加锁也不能只锁写入、不管并发读取。任务重试则要检查事务、幂等键和旧结果写回。

我会先写能复现问题的测试，再运行 go test 和 go vet，并发路径增加 go test -race 和超时、取消、重复执行用例。Race Detector 只能发现实际执行路径上暴露的数据竞争，没报告不等于所有并发逻辑都正确。AI 生成的代码同样要解释修改依据、检查失败路径，编译通过不是上线标准。

落地经验与跨部门协作

A09. 有没有企业级落地经验？参考答案

我有完整项目上线和工程落地经历，可以具体讲 Aladdin。它已完成 AWS 上线，覆盖身份认证、任务发布、Agent 匹配与执行、交付验收和结算；链上资金闭环在 Sepolia 验证。我能展示的不只是页面，还包括部署结构、业务状态变化和异常处理的依据。

例如任务派发后没有及时收到回调，不能简单认为没执行，再无限重发；要区分任务分配与某次执行尝试，限制重试，用幂等键防重复，并拒绝过期结果覆盖当前状态。对恢复能力，项目还有 PostgreSQL checkpointer 的本机中断恢复验证；这与线上高可用已经验证是两件事。我会明确每项能力是在什么环境、用什么用例验证的。

如果企业级指的是企业客户的合同交付、明确 SLA（服务等级协议）或大规模真实流量，我不会把项目上线自动等同于这些经历，也不会把 Sepolia 验证说成主网商业资金运行。我的优势是能把功能推进到可部署、可验证、可排查的业务系统，并且能清楚说明已做到的范围。

A10. 跨部门工作流怎样协作？是否具备项目统筹能力？参考答案

我理解的统筹不是催大家报进度，而是让目标、依赖和验收标准始终一致。开始先明确要解决的业务问题、必须交付的范围和谁负责最终确认，再把工作拆成有负责人和完成条件的交付项。

例如增加退款功能，产品先确定什么状态能退、谁审批、重复申请如何处理；后端明确接口、状态和错误码，前端据此准备页面和约定数据，测试提前设计无权限、重复点击和支付失败等用例。接口没上线时前端也能推进，但修改契约必须通知相关方，不能各自改完后再联调碰运气。

进度跟踪重点看关键依赖是否阻塞、验收证据是否齐全，不只看完成百分比。遇到临时加需求或部门意见冲突，把影响、选项和责任人摆清楚，再决定缩范围、调整时间或增加资源，并记录决定。最后用端到端验收和上线反馈收尾，确保各模块各自完成之外，整条业务链路也真的完成。