/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
牛客网 AI Coding 答题思路
背景
近期校招笔试中出现 AI Coding 题目。本文基于作者对牛客网 AI Coding 的使用和观察，总结一套可复用的答题协作流程，供校招同学参考。
牛客网AI Coding地址：https://www.nowcoder.com/problem/aicoding/
以下评分特征与环境限制来自特定场次的实际观察，平台规则和题目环境可能变化。答题前应以当前题面、环境提示和平台反馈为准。
了解平台规则
平台判分规则
观察到的平台总分由交付分和过程分组成：交付分满分 30 分，过程分满分 70 分。
交付分反映交付代码通过平台测试的情况。过程分反映答题者与 AI 的协作过程是否清晰、可追溯，并符合平台认可的 AI Coding 协作实践。根据过程评分反馈，值得主动体现的行为包括：
过程材料应直接服务于正确交付；不能为了过程分堆砌无关文档或牺牲交付质量。
答题环境的限制
观察到的常见限制如下：
推荐答题策略
AI 交互步骤和提示词模板
答题前根据题目替换模板中的占位符：
- [相关样例或参考文件]：样例、基线代码或接口说明；
- [待修改文件或目录]：如 main.py、js/logic.js；
- [样例测试脚本]：题目提供的测试入口；
- [当前实现文件]、[当前测试文件]：当前任务实际涉及的文件；
- [T编号]、[TC编号列表]：当前任务和测试编号。
步骤 1：准备
选择语言，并将该语言对应的预设代码复制到当前 work/ 根目录。确认题目规定的启动命令、入口文件与样例测试路径；这些信息随后作为提示词中的显式文件引用和手动执行命令。
步骤 2：产出规格、任务与测试设计
@README.md @[相关样例或参考文件] @[待修改文件或目录]
本阶段只做分析和计划：禁止修改实现代码、禁止输出代码片段。
阅读全部已附文件，在工作区写入以下文件：
1. spec.md，最多 120 行，包含：
– 硬约束：编号 C1、C2……；每条写“约束 + 来源”；
– 公开契约：输入、成功结果、题面明确的失败结果；
– 状态变化与失败不变性；
– 必须实现的可验收功能；
– 高风险点：编号 R1、R2……；
– 未决项：标记“?不确定”。不得脑补，且不得把未决项写成硬约束。
2. tasks.md：
– 通常 3–7 个可独立验收的任务，按依赖顺序排列；
– 格式：
– [ ] T1：目标
– 依赖：无 / 已完成任务编号
– 验收：可观察结果
– 测试：TC-01、TC-02
– 不为凑数拆任务，不包含题面未要求的功能。
3. test-cases.md：
– 每项使用 TC-01、TC-02……编号；
– 格式：场景｜前置条件｜操作与输入｜预期结果｜关联任务；
– 覆盖正常路径、题面每条业务规则、非法输入、边界值、
错误或重复操作、失败后的状态不变性、题目定义的初始化/重置行为；
– 只断言题面已承诺的结果；未规定的错误码或响应格式不作硬断言。
若无法一次完整写入三个文件，优先完成 spec.md；下一轮再生成 tasks.md 和 test-cases.md。
完成后只回复：
“已生成 spec.md、tasks.md、test-cases.md，请 review。”
步骤 3：编写可执行测试脚本
@README.md @spec.md @tasks.md @test-cases.md
@[样例测试脚本] @[当前实现文件] @[当前测试文件]
本阶段只编写测试，不实现业务功能。
基于 test-cases.md，将 [TC编号列表] 实现为可执行测试，写入 [当前测试文件]。
要求：
1. 优先在题目提供的样例测试脚本上扩展；若其结构不适合扩展，
新建独立测试文件并保留样例脚本不变；
2. 每个 TC 使用独立测试函数，函数名包含 TC 编号；
3. 每个测试自行准备前置数据；题目提供重置机制时，测试前应调用；
4. 每次校验输出：TC 编号｜场景名｜实际结果｜预期结果｜PASS/FAIL；
5. 测试仅使用题目允许的方式和已声明依赖；
6. 不修改生产实现文件，不为让测试通过而降低断言标准；
7. 告诉我需要手动执行的测试命令。收到执行结果前，不要修改实现代码。
最后只回复：
“已编写 [TC编号列表] 测试；请手动执行：<命令>。”
步骤 4：逐个功能实现
@README.md @spec.md @tasks.md @test-cases.md @[当前实现文件] @[当前测试文件]
现在只处理 tasks.md 中的 [T编号]。
开始前检查依赖：
– 若依赖任务未标记为 [x]，停止并只报告阻塞项；
– 若依赖已完成，继续。
要求：
1. 严格遵守 spec.md 的 C 编号硬约束；
2. 在 [当前实现文件] 中实现 [T编号] 所需功能；
3. 确保 [T编号] 关联的 [TC编号列表] 已在 [当前测试文件] 中存在；
4. 允许修改必要共享代码，但不得无关重构、增加题面未定义功能，
或改变已通过的公开行为；
5. 不要自行把 tasks.md 中的 [ ] 改为 [x]；
6. 告诉我需要手动执行的测试命令，以及本次应关注的 TC 编号；
7. 等我反馈测试输出后，再判断该任务是否完成。
最后只回复：
“[T编号] 已实现；请执行：<命令>；重点验证：[TC编号列表]。”
步骤 5：反馈手动测试结果
答题者手动启动项目并执行 AI 给出的测试命令，或使用平台的“预览运行”功能。将完整或最小必要的失败输出反馈给 AI：
@spec.md @tasks.md @[当前实现文件] @[当前测试文件]
我执行了以下命令：
[测试命令]
结果如下：
[粘贴测试输出]
请只处理 [T编号] 的结果：
1. 判断每个失败 TC 的预期是否符合 spec.md 的 C 编号约束；
2. 若相关测试全部通过，将 tasks.md 中 [T编号] 由 [ ] 改为 [x]；
3. 若测试失败，仅修复导致该失败的最小实现范围；
4. 不修改无关任务，不降低测试断言，不扩展功能；
5. 修改后告诉我下一次需要手动执行的命令。
重复步骤 4 和步骤 5，直至所有任务完成。
步骤 6：全量验证
当 tasks.md 中的任务均标记为 [x] 后，手动启动项目并运行全部样例测试和自编测试。对于失败项，先确认测试预期是否符合 spec.md，再将失败用例的编号、实际结果、预期结果和命令输出反馈给 AI 进行最小范围修复。修改后重新执行全量测试，直到全部用例通过或明确记录剩余风险。
