题目需求

刷题链接 本题要求交付一个内存型 HTTP 服务：把多云账号费用按版本化分摊方案归集为可审计的成本中心账单。费用按 usageAt 选择已发布版本，沿分摊图递归分配：POOL 按基点权重拆分、余数按 nodeId 字典序补 1；CENTER 归集到成本中心；DELEGATE 跨方案委托；CAP 按 origin period 累计额度、超限分流。方案可追溯发布，系统须按 origin period 重放受影响费用，以"冲销+重述"追加式分录修正历史；批量发布与批量更正整体原子，失败全回滚；已关账账期不可改写，迟到费用与追溯改规落入当前开放期；所有写操作按幂等键去重；且任一时刻满足对账不变量——事件分摊合计等于金额，账期分录净额等于账单净额。

做题步骤

一、榨干题面再动手。 让 AI 通读题目后输出契约清单：全部接口字段、枚举、错误码、排序与过滤规则。强制它把括号里的隐含约束显式化——余数补 1 的顺序、CAP 额度按 (capKey, planId) 共享、批量操作"不得等价为顺序执行多次"等。这些括号句就是判分点，也是 LLM 最爱漏的。

二、规划不可替代的阶段。 与 AI 讨论出约十个缺一不可的阶段：骨架与幂等层、基础实体、账期与时钟、版本校验与环检测、选版逻辑、分摊引擎、费用创建与分录落期、更正与批量更正、追溯发布与重述、关账与对账。重点聊清衔接处：重放的排序键、分录落期的判定函数、重述的触发条件。聊不明白就继续聊，这一步值得花二三十分钟——开工走错方向，后续修正代价远大于规划成本。

三、立机械化规矩。 每次只改当前阶段相关代码；题面有歧义必须停下来问，禁止自行假设；每阶段交付可检验的证据——构造测试用例并跑出实际结果，不接受口头"已完成"。

四、逐条推进，人工 React。 每阶段完成后令其自查边界：权重合计是否严格 10000、列表是否处处字典序、金额是否处处整数分。最小用例验证通过再进下一条。发现它开始输出思维链、左右互搏或改 A 坏 B，立即总结现状、新开会话，守住上下文底线。

五、自测后首提。 重点验证对账不变量和难点场景：关账后的迟到费用、追溯发布引发的跨账号重述、CAP 共享额度下的回放顺序、批量更正的失败回滚。

六、黑盒修正。 提交后把错误信息喂回去，要求列举所有可能原因并逐一构造本地复现，用证据排除。同一方向连续失败，就删掉相关代码、带错误信息新开上下文重写，不在错误路径上打补丁。时间充裕则人眼复核余数分配与 CAP 额度等核心算法，古法 debug 与 AI 修正交替使用，磨到满分。