大厂真题 / 蚂蚁

蚂蚁 8.27 AI Coding：贷款全链路已披露需求与作答策略

说明

现有材料披露了业务主链、部分校验规则、三个关键工程口径和建议作答流程，但没有给出完整题面。本文因此定位为“已披露需求与作答策略”，不补写材料中未出现的固定枚举、期限选项、利率数值、命令、错误码、接口、数据结构或完整实现代码。

实际作答时，预设代码位置、启动方式、自测方式、提交规则以及所有精确验收标准，均应以考场做题说明和需求文档为准。

题型概览

• 考试日期：2026 年 8 月 27 日
• 题型：AI Coding 工程题
• 系统形态：终端交互的个人贷款系统
• 存储方式：数据保存在内存中，进程退出后不保留
• 业务主链：授信 → 支用 → 还款

题目分阶段扩展能力：先完成授信审批，再接入支用和还款，随后处理逾期罚息、利率折扣券、提前还款试算和多次支用管理。材料并未披露这四个方向的完整验收细节，不能仅根据业务常识自行补全。

一、已披露需求

1. 授信审批

授信阶段接收以下信息：

• 姓名；
• 年龄；
• 月收入；
• 期望额度。

系统需要完成两类校验：

• 年龄是否合规；
• 收入与期望额度是否合理，其中已披露的明确规则是：额度不超过月收入的 24 倍。

审批通过后生成可用额度。额度需要体现：

• 总额；
• 已用额度；
• 可用额度；
• 有效期自审批通过之日起一年。

年龄的具体合规范围、日期边界如何计算、审批失败时如何展示等内容未被披露，应从完整题面读取，不能自行设定。

2. 支用

支用从当前可用额度中发生，已披露能力包括：

• 支持部分支用；
• 同一额度下支持多笔支用；
• 支用时选择等额本息或等额本金；
• 支用时选择期限；
• 支用成功后生成还款计划；
• 金额精确到分。

材料没有披露可选期限、利率来源、计息起止日、每期日期规则及尾期调平公式。因此，策略设计应先确保“多笔支用彼此可识别、每笔有独立计划、额度口径统一”，具体计算严格交由完整题面约束。

3. 还款

还款阶段需要：

• 展示还款计划明细；
• 模拟某一期还款；
• 按“先利息、后本金”的顺序核销；
• 已还期次不能重复核销。

这里的核心不是单次金额更新，而是保证计划、剩余本金和额度之间始终一致。一次还款只有在全部校验通过后才能推进状态；失败时不应留下“利息已核销、本金未核销”之类的中间结果。

4. 后续扩展方向

第三阶段披露了四个区分度方向：

1. 逾期罚息；
2. 利率折扣券；
3. 提前还款试算；
4. 多次支用管理。

现有材料只进一步明确了罚息重复计算的工程口径，没有披露折扣券适用条件、提前还款处理规则或多笔支用的展示与操作规格。实现这些功能时，应先要求编码助手从题面逐条抽取规则，不应凭常见金融产品经验补齐。

二、把主链整理成状态与不变量

这类题的需求很长，但真正需要人工把关的是跨阶段不变量。

授信审批通过
  -> 生成额度并开始计算有效期
  -> 在可用额度内发起一笔或多笔支用
  -> 每笔支用生成自己的还款计划
  -> 展示计划并选择某期模拟还款
  -> 先核销利息，再核销本金
  -> 已还期次禁止再次核销
  -> 未还本金变化后，额度视图同步变化

授信阶段检查

• 所需输入是否齐全且符合题面类型；
• 年龄是否落在题面规定的范围内；
• 期望额度是否超过月收入的 24 倍；
• 审批通过后，总额、已用、可用与有效期是否能被查询；
• 校验失败时是否没有生成半成品额度。

支用阶段检查

• 额度是否仍在有效期内；
• 支用金额是否在当前可用额度范围内；
• 还款方式和期限是否来自题面允许值；
• 一笔支用是否只生成一套对应计划；
• 多笔支用是否相互独立，同时共同占用同一授信额度；
• 计划各期的本金合计是否与该笔支用本金一致。

其中“过期额度能否进行哪些查询或操作”“重复请求如何处理”等规则未被披露，应以完整题面为准。

还款阶段检查

• 被还期次是否存在且尚未核销；
• 核销顺序是否始终为先利息、后本金；
• 成功核销后，该期是否被明确标记为已还；
• 重复核销同一期时，账务状态是否保持不变；
• 本金变化是否正确反映到已用和可用额度；
• 多笔支用时，只影响目标支用及其计划，不误改其他支用。

三、三项必须先定死的工程口径

材料明确指出，这三处存在多种看似合理的实现，若不在第一轮就统一，后续很容易出现账务不一致。

1. 金额统一使用整数分

全程用整数分表示金额，不使用浮点数。所有需要取整的地方只经过同一个取整函数。

这样做的目的不是代码风格统一，而是让授信额度、支用本金、计划本金、利息、还款核销和罚息共享同一精度口径。否则不同位置分别使用浮点、round 或截断，会造成各期本金之和无法回到原始支用金额，而且这种错误可能不会抛出异常。

需要重点验证：

• 同一输入在所有流程中采用相同单位；
• 中间计算不会提前转成浮点；
• 需要取整时不会散落多套逻辑；
• 分期后若存在尾差，必须按完整题面的规则处理，不能自定方案。

2. 已用额度由未还本金之和派生

不要把“已用额度”作为一个在支用时手工增加、还款时手工减少的独立事实源。它应由所有支用的未还本金之和派生。

已用额度 = 所有支用的未还本金之和
可用额度 = 授信总额 - 已用额度

这一口径把额度守恒变成结构性保证。新增支用、某期还款、多笔支用或后续提前还款只要正确更新本金，额度视图即可统一得到结果，避免某个分支漏记额度。

需要重点验证：

• 刚审批但未支用时，已用额度为零；
• 新增一笔支用后，已用额度随未还本金增加；
• 偿还本金后，已用额度随未还本金下降；
• 仅核销利息时，不应错误释放本金对应额度；
• 多笔支用下，聚合值等于各笔未还本金之和。

3. 同一期罚息按最新日期整体重算

同一期已经计算过罚息后，再次计算时不要在旧结果上累加，而是根据最新日期对该期罚息进行整体重算。

这是一项幂等性口径：重复执行不是“再产生一笔罚息”，而是“更新截至新日期应有的罚息结果”。应避免把前次结果继续作为本金或罚息基数，导致重复累计。

材料没有披露罚息利率、宽限期、计息基数和日期边界。可以确定的是“重复计算采用重算而非累加”，其余公式必须以完整题面为准。

四、推荐作答流程

第一步：人工先读做题说明

优先确认：

• 预设代码在哪里；
• 工作区如何准备；
• 项目如何启动；
• 如何执行自测；
• 如何提交和查看结果。

这些信息决定操作顺序。长需求文档可以交给编码助手完整读取，但做题说明不能跳过。

第二步：先跑一次原始自测

在修改代码前运行题面规定的自测，目的有两个：

1. 确认环境和预设项目可以正常运行；
2. 留下后续比较所需的基线结果。

如果跳过这一步，后续失败时难以区分是环境问题还是实现问题。每轮修改后都应与基线和上一轮结果对比。

第三步：让编码助手完整读文档和入口

文档完备时，不建议人工把需求二次转述成若干片段。二次转述容易漏掉看似不起眼、实际属于验收点的约束。

第一条实现指令至少应包含：

• 完整阅读需求文档和入口文件；
• 严格按功能与验收标准实现；
• 金额统一使用整数分；
• 所有取整复用同一个函数；
• 已用额度由未还本金之和派生；
• 同一期罚息按最新日期整体重算，不做累加；
• 文档不明确的地方先列出问题，不得自行假定。

编码助手提出的澄清问题需要人工判断，因为金额、余额和重复操作口径正是本题最容易出现“实现自洽但不符合验收”的地方。

第四步：尽早得到可运行基线

第一版完成后，立即执行自测并提交一次，记录结果。此时不要急于追求架构重构或界面完善，先确认授信、单笔支用和单期还款的最小闭环是否能运行。

第五步：让编码助手生成并运行测试

要求它按题面验收标准覆盖：

• 正常流程；
• 边界值；
• 非法输入；
• 当前状态不允许推进的操作。

先让它运行并输出失败清单，暂时不要修改实现。人工先审查失败是否来自测试理解错误，再决定修代码还是修用例，避免错误测试把正确逻辑改坏。

第六步：基于原始失败结果做最小修复

把完整失败信息交给编码助手，不要只转述成“大概是某处有问题”。要求它：

1. 先定位失败对应的题面规则；
2. 列出计划修改的位置和原因；
3. 不全量重写文件；
4. 不改动与失败无关的行为；
5. 修改后重新运行相关测试和全量自测。

每轮只接受可解释的最小改动。如果结果下降，应回退到上一份已知更好的版本，而不是继续在坏版本上叠加修改。

第七步：连续失败时清理上下文

同一错误多轮仍未解决时，可以开启新会话，让编码助手重新阅读当前代码、需求文档和原始失败信息。新会话应先审查现状，再做局部修复，避免在不了解当前实现的情况下大范围重写。

如果预设项目同时提供多种语言目录，且当前语言长期无法推进，换用另一种语言重新实现可以作为备选；是否值得切换，应结合剩余时间和既有通过情况判断。

第八步：有余量再补方案审查

在核心功能和测试结果已经稳定后，再让编码助手输出实现方案、任务拆解和逐项审查清单。不要一开始就花大量时间生成无法人工 review 的中间文档。

五、测试矩阵

1. 授信测试

• 合法信息可以完成审批并生成额度；
• 年龄边界分别测试边界前、边界值和边界后，具体数值取自题面；
• 期望额度恰好等于月收入 24 倍；
• 期望额度超过月收入 24 倍；
• 非法输入不会生成额度；
• 审批通过日与一年有效期边界按题面规则处理。

2. 支用测试

• 第一次部分支用；
• 同一额度连续多笔支用；
• 支用金额恰好等于可用额度；
• 支用金额超过可用额度；
• 两种已披露还款方式分别生成计划；
• 各期本金合计与支用本金一致；
• 金额计算全程精确到分；
• 失败支用不改变额度和既有计划。

3. 还款测试

• 展示尚未还款的计划明细；
• 正常核销某一期，顺序为先利息、后本金；
• 同一期重复核销被拒绝或按题面方式处理，且不产生第二次账务变化；
• 核销成功后未还本金、已用额度和可用额度保持一致；
• 多笔支用时，对一笔还款不改变另一笔计划；
• 非法期次或不允许推进的状态不产生副作用。

4. 罚息重算测试

• 首次按目标日期计算某期罚息；
• 使用同一日期重复计算，结果不重复累加；
• 使用更晚日期再次计算，结果按最新日期整体重算；
• 重算只更新目标范围，不误改已还本金或其他支用；
• 罚息公式和日期边界全部来自题面。

5. 全链路守恒测试

至少从空系统完整走一遍：

授信审批
  -> 第一笔部分支用
  -> 第二笔支用
  -> 查看两笔还款计划
  -> 核销第一笔的某一期
  -> 再次查询额度与两笔计划
  -> 尝试重复核销
  -> 对逾期期次重复计算罚息

每一步都检查：

• 金额仍是整数分；
• 已用额度等于所有未还本金之和；
• 可用额度与总额、已用额度之间保持一致；
• 已还期次不会再次产生核销；
• 罚息重算不会累加旧结果；
• 失败操作前后的业务状态一致。

六、可直接用于编码助手的 Prompt

Prompt 1：读取需求并建立约束清单

请完整阅读当前项目的做题说明、需求文档、入口文件和预设代码。先不要修改文件。

请输出：
1. 题面明确要求的启动、自测、提交与验收方式；
2. 授信、支用、还款的完整流程和前置条件；
3. 所有精确字段、枚举、期限、边界、错误行为和输出格式；
4. 额度、支用、计划、还款和罚息之间必须保持的不变量；
5. 文档未明确、需要我决定的问题。

每项结论标注来自哪个项目文件。不得根据常见贷款系统自行补充规则。

Prompt 2：实现最小业务闭环

请严格按项目文档完成可运行的最小闭环：授信审批 -> 单笔支用 -> 生成还款计划 -> 展示计划 -> 模拟某期还款。

三项硬约束：
1. 所有金额统一使用整数分，不出现浮点数；所有取整只调用同一个函数；
2. 已用额度由全部支用的未还本金之和派生，不手工加减维护；
3. 同一期罚息重复计算时，按最新日期整体重算，不在旧结果上累加。

还款必须先核销利息、再核销本金，已还期次不能重复核销。
只使用文档给出的字段、枚举和规则。文档不明确时先提问，不要自行假定。
完成后按题面方式运行自测，并列出通过项、失败项和对应原因。

Prompt 3：先生成失败清单，不改代码

请根据需求文档和验收标准，为当前实现补充并运行测试，但现在不要修改业务代码。

测试覆盖：
- 授信、支用、还款的正常全链路；
- 题面规定的边界值；
- 非法输入；
- 当前状态不允许推进的操作；
- 同一额度多笔支用；
- 金额精度和分期本金守恒；
- 已还期次重复核销；
- 已用额度等于所有未还本金之和；
- 同一期罚息按相同日期和更晚日期重复计算。

运行后输出：测试名称、预期、实际、失败对应的题面规则。先不要修复。

Prompt 4：最小范围修复

下面是完整失败结果。请先定位每个失败违反了哪条题面规则，不要立即改代码。

先输出：
1. 根因；
2. 计划修改的文件和位置；
3. 为什么该修改不会影响已通过流程；
4. 需要新增或更新的回归测试。

禁止全量重写文件，禁止重构无关模块。确认修改范围后再做最小改动，并重新运行相关测试和全部自测。

Prompt 5：最终一致性审查

请对当前项目做最终审查，不要扩大功能范围。逐项检查：
1. 所有金额是否始终使用整数分；
2. 所有取整是否复用同一个函数；
3. 已用额度是否只由所有未还本金之和派生；
4. 多笔支用是否共享授信额度但计划彼此独立；
5. 还款是否先利息后本金；
6. 已还期次是否无法重复核销；
7. 同一期罚息是否按最新日期整体重算而非累加；
8. 任一失败操作是否不会留下部分状态修改；
9. 字段、枚举、期限、边界和输出是否逐字符合题面；
10. 是否存在题面未要求的假设、调试内容或无关改动。

先列问题和最小修复方案，再逐项修复并运行全部题面自测。

七、常见失分点

1. 金额混用浮点与整数分：流程能运行，但分期合计和额度会出现静默误差。
2. 多处各自取整：相同金额在计划、核销和罚息中得到不同结果。
3. 手工维护已用额度：某个还款或扩展分支漏减后，额度与本金失去一致性。
4. 把利息还款误当成释放本金额度：已用额度应跟随未还本金，而不是跟随总还款额。
5. 重复核销已还期次：同一期产生第二次本金或利息变化。
6. 罚息重复累加：再次试算时叠加旧结果，而不是按最新日期整体重算。
7. 多笔支用共用一套计划状态：还一笔时误改另一笔。
8. 失败后留下部分修改：先改额度再发现计划生成失败，导致状态不可恢复。
9. 只跑正常流程：没有覆盖边界、非法输入和状态不允许推进的情况。
10. 让编码助手全量重写：修复一个失败时破坏此前已经通过的行为。
11. 人工转述失败信息：丢失原始报错中的关键上下文。
12. 补造完整题面：自行发明期限、利率、枚举、接口或错误码，导致实现偏离验收。

小结

这道题应先抓住一条业务主线和三项工程口径：

授信 -> 支用 -> 生成计划 -> 还款

金额统一为整数分
已用额度由未还本金派生
罚息重复计算按最新日期整体重算

限时作答中，编码助手适合承担完整阅读需求、生成实现、编写测试和定位报错；人工则负责确认题面硬约束、决定存在歧义的账务口径、审查失败清单并拦截无关重写。稳定的得分路径不是一次生成全部功能，而是尽快获得可运行基线，再用“测试—定位—最小修复—回归”的循环逐步扩大覆盖面。