使用场景
面试官设计
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
994 道问题
本页为第 1–50 题，共 994 题。
A · 专业解题与实现50
- AI 助手可以代表用户创建工单、退款或修改账户。它发起退款时发生超时，系统不知道退款是否已经完成；自动重试可能造成重复退款。你会怎样确认操作结果、控制重试，并确保操作仍在用户授权范围内？
- 两个评审者对同一批 AI 输出的好坏经常意见相反，你会怎样判断这是标注分歧、评价标准含糊，还是模型本身不稳定？
- 文档助手在多数场景下可以自动提交，但不同错误的后果差异很大。增加人工复核后，错误减少了，待审核任务却持续积压。你会怎样决定哪些任务自动处理、哪些交给人工，并让审核量不超过团队处理能力？
- 一个生成式功能的回答质量不错，但高峰时延和单次成本都超过产品约定。你会如何判断问题出在模型、上下文、检索还是调用链？
- 更换基础模型后，核心任务平均分数提高了，但少数重要客户的结果明显变差。你会如何决定是否发布、分批发布或回退？
- 公司要做一个内部知识问答助手，而文档权限会随人员变动。你会怎样让它既答得有依据，又不泄露不该看到的内容？
- 知识问答助手的用户满意度下降，但离线检索指标没有变化。你会从哪些环节拆查这次退化？
- 让 AI 帮你审核一段配置，或生成一段代码，你怎样决定它能不能上线？
- 一份内部文档被撤回或改为限权后，检索索引、缓存和已生成的引用可能仍保留旧内容。你会怎样设计更新与验证机制？
- 线上回答出现了错误引用，但当时的提示词、模型版本和检索结果都没有完整记录。你会补哪些观测信息，才能既排查问题又控制敏感数据暴露？
- 新模型把总体准确率从 91% 提高到 94%，但错误仍集中在少数会影响客户权益的场景。团队希望按总体分数发布。你会如何定义发布判断？
- 知识问答助手引用了内部文档，但文档所属团队已更新流程，新版本还没有进入检索范围。你会怎样确定内容更新时限、更新流程，以及更新完成前该怎样回答？
- 一个多步骤 Agent 在开始时读取了项目权限，执行到第三步时用户被移出项目，但任务仍持有已签发的工具令牌。你会如何设计权限检查和取消语义？
- 用户更新账户设置后立即刷新，服务从只读副本读取到旧值。切主读会增加数据库负载，等待同步又可能超时。你会怎样设计一致性体验？
- 写代码和做代码评审时，你有哪些已经形成习惯的检查点，用来防止循环里查数据库、大对象长期不释放这类性能问题？你怎样知道它们真的有效？
- 请实现一个重试封装：调用外部服务失败时按规则重试，同时不让重试压垮对方。先说明接口，再写代码，并说明怎样让它在测试里可确定地运行。
- 需要校验一个很大的 CSV 文件，但不能把整份文件读入内存；遇到格式错误时还要报告行号并继续检查。你会怎样设计解析接口？
- 宏和代码生成经过多层展开后，编译错误只指向生成文件，使用者无法定位原始代码。你会怎样设计诊断信息？
- 增量编译很快，但改动共享头文件后偶尔没有重新编译所有依赖目标。你会怎样定位依赖追踪缺口？
- 编译器升级改变了结构体布局或调用约定，但部分插件仍按旧 ABI 构建。你会怎样管理兼容与迁移？
- 缓存能让读取变快，也可能让用户看到过期内容。你会怎样判断一份数据适不适合缓存，出错时又怎样发现？
- 一个长时间运行的进程内存持续增长，但没人能指出明显的泄漏。你怎样区分真正的泄漏、正常的缓存增长和内存碎片？
- 新字段需要补算数亿行历史数据，首轮脚本运行后线上锁等待和复制延迟都上升。你会怎样决定暂停、分批、限速或改用在线迁移？
- 新增索引后查询变快了，但写入延迟和存储增长明显恶化。你会怎样判断索引是否值得保留？
- 服务把读请求切到副本后，写入成功的用户偶尔读不到刚才的修改。你会怎样界定并处理这种陈旧读取？
- 缓存失效后，大量请求同时回源，服务恢复时又出现第二次流量尖峰。你会怎样定位并抑制缓存击穿与预热风暴？
- 缓存键已失效，应用日志显示重新读取数据库，但部分用户仍看到旧资料；切换到主库后问题减少却没有消失。你会怎样沿缓存、副本和客户端定位？
- 生产者日志显示事件已发布，Broker 也返回确认；消费者没有报错，但业务对象未变化。你会如何区分确认语义、处理失败的消息、过滤、反序列化和重复处理问题？
- 用户请求依次调用四个下游，每个服务都使用完整的 2 秒超时，导致整体尾延迟很高，客户端还会在响应失效后继续计算。你会如何传递截止时间和预算？
- 分片后总体容量充足，但少数租户的热点键仍持续超载。你会怎样重新评估分区策略？
- 值班人员每天收到大量告警，但用户投诉和服务目标违约仍会漏报。你会如何重新整理告警？
- 老系统持续叠加新业务，代码越来越难维护。你会如何在新旧系统之间建立适配边界，避免旧规则和数据模型渗入新业务？请说明迁移步骤，以及必须接受的妥协和风险。
- 说一次架构升级。为什么当时必须升级，而不是继续修补？迁移中遇到了哪些挑战，怎样保证业务不中断，最后收益是否兑现？
- 一项能力，你怎样决定是自研、采用开源，还是购买？自研和开源在成本、可控性、维护和风险上分别有什么差异，什么时候该从一种换成另一种？
- 仓库允许外部贡献者提交代码，自动检查与构建流程会读取测试凭证并构建发布包。你会怎样检查流水线中的信任边界和凭证暴露风险？
- 云成本连续上升，财务要求削减开支；与此同时，团队正处于可靠性改善阶段。你会怎样找出可削减成本且不转嫁风险的方案？
- 一个长期凭证被多个服务共享，安全要求尽快轮换，但无法一次性停掉所有依赖方。你会怎样推进？
- 技术债怎样识别、记录，并在不停下业务交付的前提下还掉？哪些债值得还，哪些可以一直留着，你怎么判断？
- 一次故障还没有找到根因，但业务方要求你给出恢复时间。你会如何更新进展、表达不确定性并避免承诺误导？
- 生产环境中的部分资源与代码声明不一致，其中一些差异来自未记录的紧急手工修复。你会怎样区分有意变更与无法解释的配置差异，评估覆盖风险，恢复可信状态并减少复发？
- 一次发布需要覆盖数千个运行节点，但节点版本和网络状态并不一致。你会怎样设计分批发布、健康验证和暂停条件？
- 公司的多个前端项目分散在不同仓库，有人提议合并成 monorepo。你会怎样判断该不该做，又怎样分步验证？
- 应用发布可以回滚，但数据库迁移已经删除旧字段，旧版本因此无法启动。你会怎样重新设计发布顺序和回退策略？
- 框架允许界面在后台并发更新，但慢请求的旧结果偶尔覆盖新选择。你会怎样设计并发状态更新？
- 复杂表单同时有字段校验、跨字段规则和服务端错误，用户编辑时状态彼此覆盖。你会怎样划分框架状态与业务状态？
- 多个页面共用服务端数据，框架缓存减少请求，却在用户切换账号后暴露旧结果。你会怎样设计缓存键和失效边界？
- 升级前端框架后没有编译错误，但渲染时机、默认缓存或副作用顺序改变。你会怎样验证升级不会改变产品行为？
- 用户在一个子应用完成登录后，切换到另一个应用却丢失权限或会话状态。你会如何设计认证上下文的共享边界？
- 一个子应用发布“订单已完成”事件，其他模块各自解释不同，导致重复请求和页面状态分叉。你会怎样定义跨应用事件接口约定？
- 用户报告跨子应用跳转后页面空白，但各团队监控都没有异常。你会怎样补齐日志、指标和调用链，让团队可以跟踪用户从跳转到页面加载的完整过程？
当前目标在这里暂无匹配题。 ·