AI Coding 面试实战题

这些案例也可作为限时笔试素材，但训练时应限制 AI 的执行权限，并按 AI Coding笔试模拟训练 记录结果、对话和 Token。

练习时完整走一遍“澄清需求—拆任务—实现—Review—测试—复盘”，不要只背答案。

四、Vibe Coding 真题实操

下面几道题是我从公开面经和牛客内容里整理出来的。练习时别背整段答案，至少要亲手跑一遍“澄清需求—拆任务—让 AI 实现—看代码—做测试”的过程，不然面试官追问两句就容易露馅。

4.1 美团 AI Coding：商品自动审核系统

题目

商家提交商品后，系统需要自动判断商品是否允许上架。请全程使用 AI 辅助完成方案设计与核心功能实现，并回答下面的问题：

1. 任务拆解：把“商品自动审核”拆成至少 5 个可以独立执行的原子任务，并标注每个任务的输入和输出。
2. 决策边界：哪些任务不能完全交给 AI 自主决策？说明原因。
3. 置信度路由：设计高置信、中置信、低置信三档处理策略，并说明如何进入自动通过、人工复核或自动拦截流程。
4. 代码审查：AI 生成了违禁词检测模块，合并前至少检查 5 项内容，并说明每项对应的生产风险。
5. 测试设计：至少设计 3 个边界场景，并说明为什么选择这些边界。

解题思路：_这题最容易答成一份审核流程介绍。真正要讲清的是每一步吃什么输入、吐什么结果、谁能拍板，以及结果不确定时怎么转人工。_置信度只是一个信号，不能替代业务风险判断。

参考回答

一、原子任务拆解

1. 商品基础校验：输入商品标题、描述、类目、价格、图片和商家信息；输出标准化商品对象或字段错误清单。
2. 文本规范化：输入标题与描述；输出完成大小写、全半角、特殊空格、繁简体和拆字处理后的文本，以及原文位置映射。
3. 违禁词与规则检测：输入规范化文本、类目和规则版本；输出命中规则、风险标签、证据位置和规则编号。
4. 图片与 OCR 检测：输入商品图片；输出 OCR 文本、图片风险标签、置信度和证据区域。
5. 类目与资质校验：输入商品类目、品牌和商家资质；输出资质是否齐全、缺失材料和类目冲突。
6. 模型风险判断：输入文本、图片和结构化特征；输出风险类型、置信度和可解释理由。
7. 路由与结果聚合：输入规则命中、模型结果和业务风险等级；输出自动通过、自动拦截或人工复核。
8. 审计与反馈：输入审核过程、人工结论和申诉结果；输出可追溯日志、误杀漏放样本和规则或模型优化数据。

二、AI 不能自主决定的部分

平台政策、违规阈值和处罚等级不能由 AI 自己制定；涉及高价值商家、资质争议、处罚与申诉的决定必须由人工负责；新型违规、证据冲突或低置信样本也不能直接自动判定。原因是这些决策涉及平台规则、法律合规、商家权益和不可逆损失，AI 可以提供证据与建议，但不能承担最终责任。

三、基于置信度与风险方向的路由

• 高置信安全：没有命中硬规则、模型高置信判断安全时自动通过，并保留抽检。
• 高置信违规：只有命中明确硬规则且证据完整时才自动拦截；涉及封禁、扣款等处罚仍转人工确认。
• 中置信：调用第二套规则或模型复核，结果一致且属于低风险场景可自动处理，否则进入人工审核。
• 低置信或证据冲突：直接转人工，不能把“模型不确定”误解成“商品违规”。

四、违禁词模块 Code Review

1. 是否处理大小写、全半角、特殊空格、同形字、拼音和拆字绕过，否则会漏放。
2. 是否支持白名单、上下文和类目差异，否则“苹果”“枪色”等正常词可能被误杀。
3. 正则是否存在灾难性回溯，超长文本是否有限制，否则可能造成 CPU 飙高或服务阻塞。
4. 规则是否有版本号、热更新和回滚能力，否则规则变更后结果不可追溯。
5. 并发读取与更新是否线程安全，缓存是否会出现新旧规则混用，否则同一商品可能得到不一致结果。
6. 日志是否记录命中证据但不泄露商家敏感信息，否则会带来审计与隐私风险。
7. 规则服务超时或异常时是否有明确降级策略，否则可能默认放行或全量拦截。
8. 代码是否修改无关模块、引入不必要依赖，并具备监控指标和快速回滚能力。

五、上线前测试

• 空字段与缺失图片：验证输入校验和异常提示，避免空指针或默认放行。
• 全半角、特殊空格、Emoji、同形字和拆字：验证规避检测的典型方式。
• 超长标题与描述：验证性能、正则安全和截断策略。
• 文字安全但图片违规：验证多模态结果冲突时不会只看文本。
• OCR 模糊或模型恰好落在阈值附近：验证边界值和人工路由是否稳定。
• 模型超时、规则更新中断和并发审核：验证降级、版本一致性及重复请求幂等。

4.2 蚂蚁 AI Coding：终端早餐店系统

题目

题目要求候选人在 AI 辅助下实现一个多终端 TUI 早餐店系统，模拟从顾客下单到制作、取餐、支付的完整流程。

系统包含三个终端：

• 叫号牌端，端口 8024：展示所有订单及当前状态；
• 顾客端，端口 8025：浏览菜单、创建订单；
• 店主端，端口 8026：查看订单、修改订单状态。

订单状态要求按照规定路径流转：

待确认 → 已确认 → 制作中 → 待取餐 → 已支付

↓ ↓

已取消已取消

不能跳过中间状态，例如不能从“已确认”直接变成“待取餐”。

加分项包括：

• 使用持久化存储，系统重启后订单不丢失；
• 增加基础权限控制，只有店主能够修改状态；
• 设计清晰、易读的终端交互界面。

交付物包括：

• 完整、可运行的项目代码；
• 测试脚本和测试结果；
• 安装、启动与使用说明。

解题思路：时间有限，先保住下单到支付的完整链路。中央服务、数据模型和状态机先定下来，三个终端能互相看到一致结果后，再补持久化、权限和界面。别一上来就追求漂亮。

参考回答

一、架构选择

我会使用一个中央 HTTP 服务保存菜单和订单，三个 TUI 终端分别调用接口。技术上可以选择 FastAPI、SQLite 和 Rich：FastAPI 负责订单 API 与状态机，SQLite 保证重启后数据不丢失，Rich 用来快速完成终端界面。限时场景下先用短轮询同步数据，不急着上 WebSocket，因为轮询更容易实现、调试和验收。

二、核心模型与状态机

核心对象包括 MenuItem、Order、OrderItem、StatusHistory、User 或访问令牌，以及用于并发控制的 version 字段。所有状态转换统一在服务端执行，客户端只能提交“想转换到哪个状态”，不能直接改数据库。服务端维护合法流转表，并记录操作者、时间和前后状态。

三、开发顺序

1. 先写数据模型、状态流转表、接口契约和验收清单。
2. 实现最小后端闭环：查菜单、创建订单、查订单、合法修改状态。
3. 先完成一个最简单的终端模板，验证网络、刷新和错误提示。
4. 复用模板完成顾客端、店主端和叫号牌端。
5. 补 SQLite 持久化、简单令牌权限、并发控制和启动脚本。
6. 最后完善测试、README 和界面细节。

四、如何使用 AI

我不会让 AI 一次把三个终端全写完。先让它交架构、目录和风险点，我确认以后只做后端核心接口；接口跑通，再做一个终端模板，其余两个照着扩。每一轮都写清可修改文件和验收条件，比如非法状态必须返回明确错误。这样出问题时，至少知道是哪一步坏了。

五、重点测试

• 完整下单、确认、制作、取餐和支付链路。
• 从已确认直接跳到待取餐、已取消后继续流转等非法路径。
• 同一请求重复提交，验证创建订单和状态更新的幂等性。
• 两个店主终端同时修改同一订单，验证 version 或乐观锁冲突处理。
• 服务重启后订单与状态历史仍然存在。
• 顾客尝试修改订单状态、令牌缺失或错误时必须被拒绝。
• 中央服务不可用时，三个终端能够提示错误并继续重试，而不是直接崩溃。

**取舍说明：**考试里我会优先提交“粗糙但完整”的闭环。WebSocket、复杂认证和精细动画可以写进后续规划，但不能以牺牲状态机、测试和可运行性为代价。

4.3 快手面试：如何用 AI 从零开发电商项目

假设让你使用 AI 编程工具，从零完成一个简化版电商项目，请说明：

1. 你会如何拆解需求和安排开发顺序？
2. 哪些信息需要提前提供给 AI？
3. 如何限制 AI 的修改范围，避免过度设计？
4. 如何确认 AI 实现的功能符合原始需求？
5. 你会设计哪些测试和异常场景？
6. Spec Coding 和 Vibe Coding 有什么区别？
7. 如果 AI 连续生成错误方案，你会如何接管？

解题思路：开场先主动砍需求。电商项目什么都能做，但考试时间不够，第一版只保留最小交易链路。后面的回答围绕这个 MVP 展开，重点让面试官看到你怎么限制 AI、怎么验收订单和库存。

参考回答

一、先定义 MVP

第一版我只做商品浏览、购物车、创建订单、库存扣减和模拟支付。推荐、优惠券、退款、复杂运营后台先不碰。原因很简单：先把“选商品—下单—扣库存—支付”跑通，别让 AI 看到“电商项目”四个字就给你搭一套大系统。

二、开发顺序

1. 确认用户、商品、库存、订单和支付五个核心对象。
2. 确定接口契约、订单状态和库存扣减规则。
3. 先实现后端核心链路和数据库约束。
4. 再实现商品页、购物车和订单页，并完成前后端联调。
5. 最后补单元测试、接口测试、端到端测试、启动说明和验收记录。

三、提供给 AI 的上下文

我会明确技术栈、目录结构、数据模型、相关文件、接口输入输出、错误码、代码风格和验收条件。每轮只交付一个任务，并写清允许修改的文件、禁止新增的依赖、不能改变的公共接口和需要输出的测试结果。

四、如何避免过度设计

先让 AI 输出实现计划和预计修改文件，不直接写代码；明确“不引入新框架、不重构无关模块、不增加规格之外的功能”。如果它提出缓存、消息队列或微服务，我会要求说明当前业务量下的必要性，没有明确收益就不采用。

五、如何验收

我会建立需求到测试的对应表：每条需求至少有一个正常用例和一个异常或边界用例。除了运行 AI 生成的测试，还要独立审查金额精度、库存并发、订单幂等、支付回调重复、权限和异常回滚，并跑一次完整端到端链路。

六、重点异常场景

• 两个用户同时购买最后一件商品，库存不能扣成负数。
• 创建订单请求或支付回调重复到达，不能生成重复订单或重复支付。
• 商品下架、价格变化或库存不足时，购物车与结算结果要一致。
• 支付成功但本地更新失败时，要有补偿或对账机制。
• 金额使用精确小数处理，不能直接用浮点数造成误差。

七、Vibe Coding、Spec Coding 与人工接管

原型期可以用 Vibe Coding 快速探索页面和交互；进入订单、库存和支付实现后，应先固化接口、状态机和验收标准，用更接近 Spec Coding 的方式交付。如果 AI 连续几轮没有缩小问题，我会停止生成、回退无效差异、构造最小复现并人工定位根因，再把明确的修复方案交给 AI 做限定范围的修改。

4.4 阿里千问 Vibe Coding：高性能增量数据同步 CLI

题目

使用 AI 编程工具实现一个高性能增量数据同步 CLI 工具。

公开面经记录的面试官追问包括：

1. 项目里的核心功能有哪些？
2. 高性能是如何实现的？
3. 如何避免 AI 的回答偏离问题？

**延伸练习：**任务中断后如何恢复？怎样验证断点续传、数据一致性和并发性能？

解题思路：先追问“增量”和“高性能”到底怎么量，数据从哪来、写到哪、允许重复还是允许丢。指标不清楚就谈架构，基本都会跑偏。方案里至少要交代恢复点、幂等和对账，不然吞吐再高也没用。

参考回答

一、先澄清需求

我会确认数据源和目标端类型、数据规模、延迟与吞吐目标、是否需要同步删除、失败后允许重复还是允许丢失，以及目标端是否支持幂等写入。通用工具很难凭一句话承诺严格 Exactly Once，我会优先设计为 At Least Once 加目标端幂等，并通过 Checkpoint 和对账保证可恢复与可验证。

二、核心模块

• CLI 与配置解析：连接信息、批大小、并发度、起止位置和过滤规则。
• Source Adapter：从 CDC、时间戳加主键游标或哈希扫描中读取增量。
• Transformer：字段映射、过滤、校验和数据清洗。
• Sink Adapter：批量写入、Upsert 和删除同步。
• Checkpoint：记录已确认的位置，支持中断恢复。
• Retry 与错误隔离：指数退避、错误文件或死信记录。
• Metrics 与审计：吞吐、延迟、失败数、积压量和一致性对账。

三、高性能怎么实现

性能先从批处理做起，把读取、转换和写入拆开，用有界队列控制背压。网络和磁盘操作再考虑异步 I/O、连接池，批大小和并发度都留成配置项。具体开多少不能拍脑袋，得压测。看结果时也别只盯吞吐，错误率、P 95 延迟、内存和目标端压力要一起看。

四、正确性与恢复

只有一批数据在目标端确认成功后才推进 Checkpoint；目标端使用唯一键或 Upsert 保证重试安全；部分失败时保留失败记录，不让整批静默丢失；重启后从最近确认位置继续。完成同步后用条数、主键范围、抽样哈希和差异清单进行对账。

五、如何避免 AI 跑偏

我会先写一页需求和验收说明，让 AI 每次只做一个模块，动手前交差异计划，完成后跑对应测试。它如果建议加缓存、消息队列或别的组件，必须说清楚现在遇到了什么瓶颈、加完怎么验证。不能因为题目写了“高性能”，就默认把架构搞复杂。

六、测试与压测

• 写入成功但 Checkpoint 保存前进程退出，重启后不能丢数据。
• 重复、乱序和删除事件能够得到确定结果。
• 批次部分失败时，成功数据不重复破坏，失败数据可重试和追踪。
• 目标端变慢时能够触发背压，内存不会持续上涨。
• 大数据量下记录吞吐、P 95 延迟、CPU、内存和错误率。
• 同步完成后执行源端与目标端一致性对账。

作者：码客明

链接：https://www.nowcoder.com/discuss/906361801430921216 来源：牛客网

相关笔记

• AI Coding笔试高分指南 — 复杂工程题的笔试拿分方法
• AI Coding笔试模拟训练 — 限权、限时和 Token 复盘方法
• AI辅助编程工程方法 — 实战题的通用解题流程
• AI Coding七步工程流程 — 每个实战题的具体推进顺序
• AI Coding面试问答 — 面试表达框架
• 智能体运行时可靠性
• AI辅助编程 MOC