Zero2Leetcode
Star —

大厂真题 / 阿里

阿里 8.19 AI Coding：题型解析与作答策略

说明

本场材料披露的是题型背景、核心业务关系与作答方法，并非完整接口规格。因此本文只整理可确认的系统设计要求和限时实现策略，不补写路由、字段名、枚举值、数值边界、错误码或启动命令。实际作答时，这些内容必须以考场题面为准。

题型概览

考试时间：2026 年 8 月 19 日
题型：AI Coding / 内存态 HTTP JSON 服务
业务背景：数据洁净室治理平台

题目要求实现的重点不是数据库或真实隐私计算，而是治理流程与预算记账。业务中包含的核心概念包括：

  • 参与方；
  • 参与方提供的数据集及版本；
  • 隐私预算与账本；
  • 分析请求从提交、审批到发布或结束的状态流程；
  • 逻辑时间驱动的预算周期、请求过期和相关结算；
  • 写操作安全重放；
  • 相同分析的重复执行与重复扣费控制；
  • 参与方冻结、数据集停用等状态变化对在途请求的影响。

这类题表面上像大量 CRUD，真正的难点却是跨实体不变量：一次业务操作可能同时校验多个参与方、数据版本、请求状态和预算账户，并要求失败时不留下部分修改。

一、先把长需求压缩成可执行模型

不要在第一次读题时直接生成全部代码。先从题面提取四类信息。

1. 实体及关系

建议整理成层级列表或简图，至少明确：

  • 哪些实体有所有权或从属关系；
  • 哪些实体通过 ID 引用其他实体；
  • 删除、冻结、停用是否影响已有引用；
  • 哪些资源需要版本化；
  • 哪些对象参与预算锁定、扣减或释放。

这里不能凭常见后端经验补规则。例如“冻结后已有请求是否继续”“停用版本能否被历史请求引用”都必须从题面核对。

2. 请求状态机

把每个状态写成节点，把允许的操作写成边。每条边记录：

  • 前置状态；
  • 调用方或审批方权限；
  • 依赖资源必须满足的条件；
  • 预算如何变化；
  • 是否写账本；
  • 失败后是否允许重试；
  • 到期时由逻辑时钟触发哪种转换。

状态转换最好集中实现，而不是让多个路由各自修改状态。集中实现更容易保证“不允许越级流转”和“预算变化与状态变化同时成功”。

3. 字段来源

把字段分成三类：

  • 调用方输入：请求体中允许提供的字段；
  • 服务端生成：ID、创建时刻、派生状态、计算结果等；
  • 服务端维护：预算余额、锁定额、账本记录、幂等结果、当前逻辑时钟等。

服务端字段不能直接信任调用方传值。对未知字段是忽略还是拒绝，也应严格服从题面。

4. 硬约定清单

单独抄录题面规定的：

  • 精确枚举字符串与大小写；
  • 数值上下界；
  • 时间区间的开闭边界；
  • JSON 字段名与响应结构；
  • HTTP 状态码和错误格式；
  • 入口文件、启动命令、监听地址与并发要求；
  • 重置接口需要清除的全部状态。

这批规则不需要推理，却最容易因为模型“自动优化命名”而成片失分。应要求编码助手逐字遵守，不得自造别名。

二、先搭三条公共通道

1. 统一校验与原子写入

所有写操作遵循同一顺序：

  1. 解析请求并完成纯校验；
  2. 解析所有被引用的实体；
  3. 验证状态、权限、版本、时间和预算条件；
  4. 计算完整变更集；
  5. 一次性提交变更；
  6. 记录可重放结果。

关键不变量是：校验失败时，所有业务状态保持不变。不要一边校验一边修改共享字典，否则后续校验失败会留下半个对象、部分预算或孤立账本记录。

纯内存实现可以用以下方式保证原子性：

  • 在锁内完成“校验 + 提交”；
  • 先在局部变量中构建新对象与预算变化，再统一写回；
  • 复杂操作使用快照或变更日志，在异常时回滚。

具体并发模型由题面指定；如果服务会并发处理请求，共享内存上的检查与写入必须处于同一临界区，否则两个请求可能同时通过余额校验并造成超扣。

2. 统一幂等处理

写操作可能因网络重试被重复发送。可维护如下映射：

(operation_scope, idempotency_key)
    -> (request_fingerprint, stored_response)

处理流程：

  1. 在执行前查幂等键；
  2. 键不存在则继续执行业务；
  3. 业务成功后保存请求指纹和完整响应；
  4. 相同键、相同请求再次到达时直接返回首次结果，不重复创建对象或扣预算；
  5. 相同键却对应不同请求内容时，按题面规定拒绝或报冲突。

幂等记录何时写入、失败响应是否缓存、键的作用域和有效期都可能影响验收，不能脱离题面自行决定。

3. 统一逻辑时钟推进

题目中的时间由服务维护，而不是读取系统真实时间。建议只允许一个统一入口推进时间：

advance_time(new_time):
    校验时间能否推进
    更新当前逻辑时间
    按题面规定的顺序处理到期事件
    完成预算释放、扣减或周期结算
    推进请求状态

所有“是否到期”的比较都复用同一组函数，避免有的接口写 < deadline，另一个接口写 <= deadline。

若一次推进跨过多个事件时刻，要按题面规定确认是按时间顺序逐个处理，还是直接根据最终时刻结算；材料没有披露这一细节，不能自行补造。

三、重点设计：预算账本与请求生命周期

1. 预算状态不要只存一个余额

若请求在审批期间需要锁住预算，常见的模型至少会区分：

  • 可用预算；
  • 已预留或已锁定预算；
  • 已实际消耗预算；
  • 释放、过期或周期重置产生的变化；
  • 可审计账本记录。

但具体字段和会计口径必须按题面实现。无论采用何种结构，都应保持可验证的不变量，例如每一笔状态变化都能由账本解释，且同一幂等请求不会重复记账。

2. 多参与方预算必须一起成功或一起失败

一个分析请求可能同时依赖多个参与方的预算。提交或批准时不能逐个扣减后再发现最后一方余额不足。正确顺序是：

  1. 收集全部受影响账户；
  2. 在同一临界区检查所有账户；
  3. 计算每个账户的变化；
  4. 全部可行后一次提交；
  5. 同步写入请求状态和账本。

3. 重复分析与幂等不是一回事

两者容易混淆：

  • 幂等重放：同一个写操作因重试再次到达，应返回第一次结果；
  • 业务去重：两个不同请求表达相同分析时，是否复用结果、是否再次花费预算，由题面定义的分析身份或签名规则决定。

不能只靠请求 JSON 的字符串形式判断业务相同。若题面定义规范化字段、数据版本、参与方集合或参数共同构成分析标识，应严格按该规则生成稳定签名。

4. 外部资源状态变化要进入状态机

参与方冻结、数据集停用、版本替换等操作可能影响：

  • 新请求能否提交；
  • 已提交请求能否审批；
  • 已审批请求能否发布；
  • 已锁预算是否释放；
  • 历史结果是否仍可查询。

这些影响应成为显式状态转换规则，并由测试覆盖。没有完整题面时只列检查项，不假定具体结果。

四、按依赖顺序实现业务

文档章节顺序不一定适合编码。更稳妥的实现顺序是：

  1. 基础设施：内存仓库、ID 生成、锁、错误响应、重置能力；
  2. 三条公共通道：统一校验、幂等处理、逻辑时钟；
  3. 基础资源：参与方及其从属空间；
  4. 数据资源：数据集、版本和启停状态；
  5. 预算资源：账户、周期、锁定与账本；
  6. 请求主链：提交、审批、完成或发布；
  7. 异常分支：拒绝、取消、过期、冻结、停用；
  8. 查询与辅助接口：列表、筛选、审计、统计等。

每完成一层，就跑一条端到端流程。不要先实现依赖尚不存在的复杂分支，否则很难判断错误来自该分支还是前置资源。

时间不足时，应优先保证一条主链完整正确，而不是让多个接口都处于“能返回但不守规则”的半成品状态。

五、与编码助手协作的 Prompt 模板

模板 1：需求建模

先不要写代码。请完整阅读题面，只输出：
1. 实体清单，以及它们的从属和引用关系；
2. 请求状态机：每个状态允许转向哪里、触发条件是什么；
3. 调用方字段、服务端生成字段、服务端维护字段的分类；
4. 所有跨接口不变量；
5. 所有精确枚举、范围、时间边界和错误约定。

每一条都标注为“题面明确”或“推断”。不要把推断当成规格。

模板 2：公共基础设施

先只实现公共基础设施，不写具体业务接口：
1. 所有写操作共享的校验与原子提交入口；
2. 幂等键查重、请求指纹冲突检测和首次响应重放；
3. 逻辑时钟推进与集中到期处理；
4. 对共享内存的并发保护；
5. 完整重置所有状态的能力。

严格使用题面给出的字段、枚举、边界、错误格式和启动方式。

模板 3：单条业务链

现在只实现“创建基础资源 -> 配置数据与预算 -> 提交请求 -> 审批 -> 最终状态”这一条主链。
每个写操作必须：先完成全部校验，再原子修改状态，再记录幂等结果。
不要实现题面未规定的字段或状态转换。
完成后列出这条链保持的预算和状态不变量。

模板 4：失败修复

下面是当前代码、失败用例和实际输出。请定位违反了哪条题面规则，做最小修改。
不要重构与该失败无关的模块，不要改变已经通过的接口行为。
修改后重新运行全部已有用例，并说明是否出现回归。

六、测试矩阵

1. 主流程

至少覆盖一条从空系统开始的完整流程：创建前置资源、配置预算、提交请求、逐步审批、结束或发布，并逐步检查对象状态和账本变化。

2. 非法请求无副作用

对每个写接口检查：

snapshot_before = dump_state()
response = send_invalid_request()
snapshot_after = dump_state()
assert snapshot_after == snapshot_before

非法场景包括缺字段、字段类型错误、越界值、引用不存在、归属不匹配、状态不允许、预算不足和资源不可用。

3. 幂等重放

  • 相同键、相同请求发送两次；
  • 检查响应是否与首次一致；
  • 检查对象数量、余额、锁定额和账本条数没有第二次变化；
  • 相同键、不同请求内容应按题面处理。

4. 时间边界

针对每一个截止时刻测试：

  • 截止时刻前一单位；
  • 恰好等于截止时刻；
  • 截止时刻后一单位；
  • 一次推进跨越多个边界；
  • 重复推进到同一时刻；
  • 若题面要求单调时间，尝试向后拨时钟。

5. 并发与原子性

如果验收要求并发处理，至少测试：

  • 两个请求同时竞争最后一份预算；
  • 同一个幂等键并发提交；
  • 时间推进与业务写入并发；
  • 冻结或停用与请求审批并发。

验收重点不是“程序没崩”，而是最终状态满足预算不超扣、对象不重复和账本不缺失。

6. 重置

调用重置后检查：

  • 业务实体、预算、账本、请求全部清空；
  • 幂等缓存清空；
  • 逻辑时钟恢复到题面规定状态；
  • ID 计数器、分析去重索引和派生缓存按要求重置；
  • 下一轮主流程不受上一轮残留影响。

七、限时作答节奏

可按大致比例安排：

  • 前 20%：读题、抽取实体关系和状态机、抄录硬约定；
  • 接下来 20%：搭统一校验、幂等、逻辑时钟和并发保护；
  • 中间 40%：按依赖顺序实现一条完整业务主链，再补高价值分支；
  • 最后 20%：运行测试矩阵、修复失败、检查启动与重置。

交卷前停止大范围重构，执行机械检查：

  1. 从干净目录按规定命令启动；
  2. 确认入口文件、监听方式和依赖安装符合题面；
  3. 调用重置并重新走一遍主流程；
  4. 检查精确枚举、JSON 键名、边界比较和错误格式；
  5. 保留最近一次全部已知测试通过的版本。

核心结论

这类大型 AI Coding 题不以“生成最多代码”为目标，而是考查能否从长需求中提炼不变量，并在有限时间内优先实现高依赖、高复用的主干。最值得优先投入的部分是：

  • 把实体关系和请求状态机画清楚；
  • 把题面硬约定逐字落实；
  • 统一处理校验原子性、幂等和逻辑时间；
  • 让预算、状态与账本同步变化；
  • 用失败无副作用、重放、时间边界和并发竞争用例主动验证。