牛客 AI Coding 笔试评分机制拆解（以米哈游为例）

《核心观点》

评分权的真实结构：结果 40%，过程 60%。题面配置里 testcaseWeight: 0.4、processWeight: 0.6，也就是说把所有用例刷到全过，收益上限只有四成；剩下六成看过程。这直接推翻「猛猛追求用例全过」的备考策略——Plan 的质量、测试的实质性、对失败的归因，权重比拿满分更高。

过程分的五个维度及其权重：工程交付 30%、AI 指令设计 20%、AI 产出校验 30%、AI 异常归因 10%、AI 多轮迭代质量 10%。权重最高的是「AI 产出校验」，也就是你怎么验证 AI 写出来的东西是对的。这个分布意味着时间不该全花在让 AI 生成第一版代码上，而应该留出固定比例给验证与修正。

低信息量的 review 是最大的丢分点。「你自查一下」「你确定没问题吗」这类指令拿不到任何东西——AI 回一句「已经全面检查，没有问题」，你既没有验证动作，也没有可展示的思考过程。有效的替代做法是：让它列出当前实现依赖的关键假设，再针对这些假设逐个设计测试。

测试必须解释自己在验证什么。正常输入跑通只是起点，后面还要问：空输入、极值、重复数据、状态切换分别会怎样？具体测什么跟题目走，但每一条测试都要能说清它验证的是哪条假设，结果也必须真的去看，不能只看 AI 的口头结论。

异常归因与多轮迭代是一条链。发现错误后，把失败输入、预期结果、实际结果整理清楚再让它定位原因，而不是丢一句「报错了你改改」；改完以后，原来失败的用例要复测通过，之前通过的相关用例也要重新检查有没有回归。这样就自然把「异常归因 10%」和「多轮迭代质量 10%」一起拿下——你知道哪里出了问题、为什么这样改、这次修改到底有没有效果。

上下文管理围绕同一套流程调整：每完成一个阶段，整理一份简短的状态交接（已经实现什么、验证了什么、哪些问题没解决），需要换会话时用这份状态接手，不要把前面几千字的争论一起搬过去，更不要把模型口头说的「没问题」当成已经验证正确的代码。

一句话总结：做到「处处有例证」，过程分就能拿满，用例不必 8888 全过也够通过笔试。

---

《参考解析》

为什么过程分占大头：AI Coding 笔试的设计目标和传统算法笔试不一样。传统 OJ 只看结果，因为题目的解法空间有限；而 AI Coding 的题面通常是一个小工程（带模糊需求、要改代码、要交付可运行产物），考察的是你能不能把一个模糊需求拆成可执行步骤、能不能判断生成物是否正确、出问题时能不能定位。这些能力在最终产物里看不出来，只能通过过程记录（Plan、对话、测试、修改轨迹）观测，所以评分自然向过程倾斜。理解了这一点，答题时的动作就有方向：每个阶段都要留下可被观测的证据。

Plan 怎么写才算「优雅」：Plan 不是把题目复述一遍，而是一份可执行的方案说明，包含四件事——输入输出与边界条件的明确化（把题面里含糊的地方写成假设，比如数据规模、是否允许重复、异常输入怎么办）、模块划分（哪几个函数/类，各自职责与接口签名）、关键算法或数据结构的选择及理由（为什么用哈希表而不是排序）、验证策略（打算怎么证明它是对的）。Plan 里写出的每一条假设，都是后面测试用例的种子。这样一份 Plan 天然同时得分在「工程交付」和「AI 指令设计」两项上，因为它让 AI 的输出变得可预期。

AI 产出校验的实操套路：把校验拆成三层。第一层是静态检查，让 AI 解释关键代码的意图，你判断逻辑是否与 Plan 一致，重点看边界处理（空、单元素、超大值）、错误路径（异常怎么抛、失败怎么返回）、以及有没有隐含假设（比如默认输入已排序、默认不为空）。第二层是构造性验证，针对 Plan 里列出的每条假设设计用例，覆盖正常、边界、异常、重复、状态切换；对每条用例写清「验证什么」，并实际运行、实际比对输出。第三层是对抗性验证，主动构造反例、让 AI 站在「找 bug」的角度审视自己的实现，或者用小规模暴力解法对拍随机用例——对拍在笔试里性价比极高，几十行就能给出强证据。三层都做完，「AI 产出校验 30%」这项基本就是满分。

异常归因怎么做才体现能力：发现失败后，先做最小化——把失败输入缩减到能复现问题的最短形式；然后固化事实——失败输入、预期输出、实际输出、报错堆栈，四项写全；接着提出假设——列出 1~3 个可能原因并说明判断依据；最后让 AI 针对具体假设去定位，而不是让它自由发挥。修完要有闭环：失败的用例复测、相关用例回归、必要时补一条新的测试用例防止同类问题再出现。这个流程看起来慢，但在评分维度里它同时喂满了「异常归因」和「多轮迭代质量」，而且比盲目重试省时间得多。

多轮迭代的节奏与常见误区：迭代质量不等于迭代次数。有效的迭代是「一次改动解决一类问题」，每次改动前说清要解决什么、怎么验证、影响哪些已通过的行为。常见误区有三个：一是每轮都把全部代码推倒重来，导致前面的验证成果作废；二是只改被报错的那一行，没有检查同类代码里是否有相同问题；三是改完后不做回归，把原来对的用例改坏。另外要注意把「模型的自我声明」和「实际验证结果」严格分开记，前者只是假设，后者才是证据。

时间分配模板：以一场两小时的笔试为例，可以这样切——读题与澄清假设 10 分钟（写进 Plan）、方案与模块划分 15 分钟、让 AI 实现第一版 20 分钟、三层校验与测试 40 分钟（这是权重最高的一段，必须留足）、按失败用例归因修正 20 分钟、整理最终交付与说明 15 分钟。核心原则是「生成只占一小段，验证和修正占一大段」，因为分数的分母在过程上。