蚂蚁 AI Coding 笔试经验：3道题与通用 AI Harness Prompt

蚂蚁近年的 AI Coding 笔试，和传统的“在编辑器里完成几道算法题”不太一样。候选人通常会进入一个云端 IDE，项目目录中提供 README.md，再通过与 AI 对话完成需求分析、架构设计、编码、调试、测试和文档整理。

这类考试表面上考的是“能不能把项目做出来”，实际还会考察三件事：

• 能不能从 README 中提取真正的验收标准；
• 能不能把 AI 当作工程协作者，而不是一次性代码生成器；
• 能不能在有限时间内交付一个可运行、可验证、能解释的最小系统。

本文根据公开复盘文章、候选人分享和题面截图整理 3 类代表性题目。这些题目不应被当作蚂蚁官方固定题库或下一场考试的原题；它们更适合作为备考时的高仿训练样本。

一、先理解考试：README 才是第一道题

公开复盘中出现的考试流程大致是：

1. 进入云端 IDE，读取项目目录中的 README.md；
2. README 给出业务背景、功能要求、技术限制、测试标准、交付物和加分项；
3. 候选人与 AI 对话，完成需求分析、架构设计、编码、调试和测试；
4. 系统通过测试用例或 Judger 检查核心功能；
5. 后续面试可能继续追问：哪些设计是你决定的、AI 帮了什么、为什么采用这套架构，以及项目还有哪些已知问题。

因此，第一轮对话不要直接说“帮我把项目做完”。更稳妥的做法是先让 AI 把 README 转成一份可验收清单：

• 必做功能有哪些？
• 每个功能的输入、输出和错误行为是什么？
• 哪些约束不能违反？
• 测试可能从哪些边界进入？
• 最终必须提交哪些文件？
• 哪些内容只是加分项，不能挤占核心功能时间？

二、题目一：网页数据清洗管线

题面概述

题目要求在一批脏、乱、结构不统一的网页数据中，构建可批处理、可观测、可扩展的数据提取与清洗 Pipeline。

公开题面截图中给出的数据规模约为 4,000 个 HTML 文件，目录名为 html_samples/。数据具有以下特点：

• HTML 结构存在多个版本；
• 编码不统一；
• 页面中包含较多脏数据；
• 字段可能缺失，或格式不规范。

必做目标通常包括：批量提取商品名、价格、币种、库存等字段；统计成功和失败数量；保证批处理性能；输出清洗结果文件和运行统计摘要。

推荐解法

不要为每种 HTML 结构写一个巨大而脆弱的 if-else。可以拆成四层：

1. 文件发现层：递归扫描输入目录，过滤扩展名，稳定排序；
2. 解析层：统一读取编码，使用 HTML 解析器定位候选节点；
3. 归一化层：清洗空白、价格符号、货币别名、库存文本；
4. 结果层：输出结构化结果、失败原因和汇总统计。

建议每个文件都形成一条可追踪记录，而不是失败后直接丢弃：

{
  "source_file": "html_samples/001.html",
  "status": "success",
  "product_name": "Example Phone",
  "price": 2999.0,
  "currency": "CNY",
  "stock": 12,
  "errors": []
}

失败记录也要保留原文件名和原因，例如 encoding_error、missing_price、invalid_stock 或 parse_error。这样既方便验收，也方便后续定位样本问题。

边界与性能

• 空 HTML、截断 HTML、非法编码不能让整个程序退出；
• 价格中可能有货币符号、千分位、空格或中文单位；
• 库存可能是数字，也可能是“有货”“缺货”“暂时售罄”；
• 结果输出要避免把异常对象直接序列化；
• 4,000 个文件不一定需要复杂分布式方案，先保证单机批处理稳定，再考虑线程池或进程池；
• 不要为了追求并发而牺牲确定性、错误统计和可复现性。

这道题考什么

这道题不只是考 HTML 选择器。它重点考察：脏数据处理、数据模型设计、错误隔离、批处理可观测性和工程取舍。

三、题目二：LLM 批量推理控制台

题面概述

公开题面截图中的项目名称是“LLM 批量推理控制台”。目标是实现一个基于 TUI 的批量推理工具，让用户在终端中配置推理参数、执行批量任务，并实时查看任务进度。

典型要求包括：

• 读取 CSV 文件作为推理输入；
• 在 TUI 中配置 Prompt 模板；
• 使用 {列名} 引用 CSV 列；
• 配置 API 地址、认证信息和模型名称；
• 对每一行数据完成模板替换并调用 LLM API；
• 支持 OpenAI 兼容的 Chat Completions 接口；
• 在考试环境无法联网时，允许对推理接口进行 Mock。

推荐解法：先把外部推理接口抽象掉

最重要的设计不是先画 TUI，而是把“任务控制”和“模型调用”分离：

CSV 输入
  -> 模板渲染
  -> 推理任务队列
  -> ModelClient 接口
       ├── MockModelClient
       └── OpenAICompatibleClient
  -> 结果持久化
  -> TUI 状态展示

ModelClient 至少应该统一成功、失败、超时和重试后的返回结构。这样测试时可以使用 Mock，不依赖外网，也不会把 API Key 写进代码或日志。

关键实现点

• 模板中的列名不存在时，应给出明确错误，不要静默替换为空字符串；
• CSV 的空值、引号、换行和不同编码需要处理；
• 单条请求失败不能让整个批次崩溃；
• 需要区分任务总数、已完成数、成功数、失败数和重试数；
• 对网络请求设置超时，避免 TUI 看起来“卡死”；
• 结果应持续写入文件或可恢复存储，避免进程退出后全部丢失；
• Mock 模式应能模拟成功、失败、延迟和限流等场景。

TUI 不应先做得过重

两小时考试中，TUI 的重点是“可操作和可观察”，不是做出完整商业产品。优先实现：

1. 输入文件和 Prompt 配置；
2. API/Mock 模式选择；
3. 开始、暂停或取消任务；
4. 进度、成功数、失败数和最近错误展示；
5. 结果文件路径提示。

复杂的主题、动画和大量快捷键属于低优先级功能。核心逻辑应先能通过命令行或单元测试独立验证。

这道题考什么

这道题综合考察：接口抽象、异步或并发任务管理、可靠性设计、可测试性和交互状态建模。如果只让 AI 生成一个“能调用 API 的脚本”，通常会漏掉 Mock、超时、错误隔离和结果恢复。

四、题目三：征信对账系统账单解析引擎

题面概述

公开题面截图中的题目是“征信对账系统——账单解析引擎”。业务背景是：多家合作机构定期以 Excel 文件发送账单，账单格式并不统一。候选人需要从不同机构、不同产品的账单中提取计费信息，并输出结构化 JSON。

题面强调的复杂点包括：

• 数据源来自多家合作机构，格式不统一；
• 一个文件可能包含多个 Sheet；
• Sheet 中可能包含汇总行、小计行和备注；
• 同一机构可能出现简称或全称；
• 部分字段缺失或格式不规范。

推荐解法：规范化，而不是为文件写死脚本

可以设计一个“读取—识别—过滤—映射—校验—输出”的流水线：

Excel 文件
  -> 读取所有 Sheet
  -> 识别表头与明细区域
  -> 过滤汇总/小计/备注行
  -> 机构名与产品名归一化
  -> 金额、日期、数量字段规范化
  -> 必填字段校验
  -> 结构化 JSON + 错误报告

建议先定义统一的内部数据模型，例如：

{
  "institution": "机构标准名",
  "product": "产品标准名",
  "billing_date": "2026-08-01",
  "quantity": 100,
  "unit_price": 2.5,
  "amount": 250.0,
  "source_file": "bill.xlsx",
  "source_sheet": "Sheet1"
}

机构简称、全称和常见别名可以放在配置中，不要散落在代码分支里。字段映射也应尽量配置化，例如把“产品名称”“产品名”“商品”映射为统一字段 product。

重点边界

• 多 Sheet 文件不能只读取第一个 Sheet；
• 表头可能不在第一行；
• 汇总行和明细行不能重复计入金额；
• 金额字段可能包含逗号、货币符号或空字符串；
• 数量可能是整数、小数或带单位文本；
• 缺少关键字段时，应记录错误并继续处理其他行；
• 输出 JSON 时要保证数值类型稳定，不能把所有内容都当字符串。

这道题考什么

这道题考察：半结构化数据解析、规则配置、字段归一化、数据校验和可追溯性。它与网页清洗题的共同点是：输入格式不可靠，但输出必须稳定、可解释、可复核。

五、三道题背后的共同解题框架

虽然三道题分别处理 HTML、CSV/API 和 Excel，但可以使用同一套工程思路：

1. 先建立统一的数据模型

先写清楚每条记录最终长什么样，再决定如何从输入中提取。没有数据模型时，AI 很容易围绕输入格式堆叠临时字段，最后输出不一致。

2. 把输入、核心逻辑和输出分层

推荐至少拆成：

• reader：读取文件或请求；
• parser：解析原始结构；
• normalizer：字段归一化；
• validator：校验必填字段和类型；
• writer：写结果和报告；
• cli/ui：命令行或 TUI 交互。

3. 错误隔离优先于“全部成功”

批处理项目最忌讳一个坏样本让整个程序退出。每条记录都应有明确状态：成功、跳过、失败或重试中，并带有稳定的错误码或错误原因。

4. 先完成必做项，再做加分项

两小时可以按这个节奏安排：

• 前 15–20 分钟：读 README、确认输入输出、设计数据模型；
• 中间 70–80 分钟：完成主链路、异常处理和最小测试；
• 最后至少 15 分钟：对照 README 验收、补运行说明、测试报告和已知问题。

5. 测试自己补充的样例

不要只运行项目自带的样例。至少补充：

• 正常数据；
• 空输入；
• 缺字段；
• 类型错误；
• 多种格式混合；
• 单条失败但其他记录应继续运行；
• 外部 API 不可用或超时。

六、候选人通用 AI Harness Prompt

下面这份 Prompt 不是让 AI 一次性生成全部代码，而是给候选人建立一个稳定的协作流程。使用时，把它放在第一次完整阅读 README 之后，再根据项目情况补充约束。

你是我的 AI Coding 工程协作者。当前任务是在考试提供的项目目录中，根据 README.md 完成一个可运行、可测试、可交付的工程项目。

请严格遵守以下工作方式：

【第一阶段：只分析，不写大段代码】
1. 先完整阅读 README.md 以及项目目录中的相关文件。
2. 用自己的话复述：业务目标、必做功能、输入格式、输出格式、技术限制、验收方式、交付物和加分项。
3. 把需求整理成验收清单，并区分 P0 必做项、P1 重要增强项和 P2 加分项。
4. 明确列出你认为最容易被测试用例检查的边界条件。
5. 如果 README 存在歧义，先列出假设，不要擅自扩大需求。

【第二阶段：设计最小可行架构】
1. 先给出目录结构和模块职责。
2. 定义核心数据模型、接口、错误码和结果格式。
3. 将输入读取、解析、归一化、校验、业务处理、输出和 UI/CLI 分离。
4. 对外部 API、文件系统和时间等依赖提供可替换的 Mock 或适配器。
5. 说明关键设计取舍，以及为什么当前方案适合考试时间和验收方式。
6. 等我确认设计后，再开始分模块实现。

【第三阶段：分模块实现】
1. 每次只实现一个小模块，不要覆盖或删除无关文件。
2. 实现前先说明将修改哪些文件、增加哪些接口、如何验证。
3. 保留清晰的类型、错误处理和日志，不要用静默吞错代替处理。
4. 不要把密钥、Token、密码或真实认证信息写入代码、测试数据和日志。
5. 对批处理任务做到单条失败不影响其他记录，并保留失败原因和来源定位信息。

【第四阶段：边做边测】
每完成一个模块，立即：
1. 运行对应的单元测试或最小样例；
2. 检查正常输入、空输入、缺字段、错误类型和异常依赖；
3. 展示真实的命令、测试结果和失败原因；
4. 如果测试失败，先解释根因，再做最小修复，不要无关重构。

【第五阶段：最终验收】
在声称完成之前，必须：
1. 对照 README 逐项检查必做功能；
2. 运行完整测试、静态检查和一次真实的端到端样例；
3. 检查输出文件、统计摘要、错误报告和运行说明是否存在；
4. 检查是否误提交敏感信息、临时文件或不必要的大文件；
5. 给出：已完成项、未完成项、测试命令及结果、已知问题、运行方式和交付文件清单。

重要约束：
- 不要在没有读完 README 的情况下开始编码；
- 不要一次性生成整个项目；
- 不要声称“已完成”而不实际运行测试；
- 不要为了加分项破坏 P0 核心功能；
- 不要改变验收接口、文件名或输出格式，除非 README 明确允许；
- 如果无法联网，优先使用 Mock 完成可验证的核心流程；
- 所有结论都要以实际代码、测试输出或 README 要求为依据。

七、如何准备自己的 Prompt

考前不建议只背一段万能 Prompt。更有效的是准备三个可组合片段：

需求分析片段

用于第一次对话，把 README 变成验收清单和边界条件。

工程实现片段

用于约束 AI 分模块修改、保留接口、避免覆盖文件，并要求每次修改后运行测试。

验收片段

用于最后 15 分钟，让 AI 对照 README 检查功能、输出、文档、测试和敏感信息。

这比“请帮我完成整个项目”更稳定，因为它把 AI 的工作限定在可检查的步骤中，也让候选人始终知道项目当前完成到了哪里。

八、最后的面试追问准备

AI Coding 笔试结束后，面试官可能追问：

• 为什么把外部 API 抽象成接口？
• 为什么选择逐条错误隔离，而不是遇错即停？
• 如何保证金额、价格或库存字段的类型稳定？
• 如果数据量扩大十倍，瓶颈在哪里？
• 如何补充监控、重试、幂等和断点续跑？
• AI 生成的代码中，你实际审查和修改了哪些地方？

候选人至少应该能解释四件事：数据模型、核心链路、异常处理、测试证据。不需要把项目包装成生产级平台，但必须清楚哪些地方是当前考试范围内的最小实现，哪些地方仍然需要在生产环境继续加强。

结语

蚂蚁 AI Coding 的关键，不是让 AI 写出最多代码，而是让 AI 在明确的工程边界内持续交付可验证结果。

备考时，可以把网页清洗、批量推理、账单解析这三类题目反复练习一遍：它们分别覆盖了半结构化数据处理、外部服务编排和配置化规则解析。真正进入考试后，先读 README，先定数据模型，再实现主链路，最后用测试和交付清单收口。

这样即使遇到没有见过的业务背景，也能把题目还原成一组熟悉的工程问题。