最近在投简历遇到了不少 AI Coding 笔试。

这类考试的形式大同小异：给你一个现成仓库和一份 README，要求在限定时间内实现需求，有的还会让你根据测试反馈反复修改。说起来就是”用 AI 写代码”，但真上手我才发现，把题目往对话框里一贴、让它自由发挥，基本等于开盲盒。我第一次做的时候，AI 吭哧吭哧写了一大堆，跑起来一看，需求漏了一半，还顺手把原本能跑的代码给重构了。

后来我慢慢固定下来一套流程：把一次考试拆成 6 个步骤，每一步都要求 AI 先输出具体结果，我确认之后再进入下一步。这套提示词我自己一直在用，贴在这里存档，也方便以后直接复制。

整体流程是这样的：

  1. 需求对齐：读 README、读代码，先和 AI 形成共同理解
  2. 架构设计：让它整理出一份可执行的开发 spec
  3. 拆分 + 开发：把 spec 拆成 tickets，一次只实现一个功能点
  4. Code Review：对照 ticket 和 spec 检查实现质量
  5. 验收测试：对照 README 逐条核对完成度
  6. 定点修复：根据测试反馈找根因，小范围修改

核心就一句话：别让 AI 一路自由发挥。

第 1 步：需求对齐

刚拿到题目的时候，我以前总急着让它写代码，结果写出来的东西经常和题目对不上。现在我会先把这一步走完，全程不写一行代码。

做法是让 AI 先把 README、目录结构、已有测试和核心代码都读一遍，然后反过来追问我。它问的问题按一棵”决策树”来组织，每轮只问当前前置条件已经明确的问题；能自己读代码查到的事实，不许拿来问我。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
请先阅读 README、项目目录、已有测试、入口文件、核心代码。

本阶段不要写代码，只做需求理解。

请持续追问我这个计划、设计或想法，直到我们达成清晰的共同理解。

请把它拆成一棵“决策树”：每个关键决定会引出后续决定。你要按轮次提问。每轮只问当前前置条件已经明确的问题，不要问依赖未决答案的问题。

每个问题请包含：
- 问题编号和简短标题
- 问题正文
- 你的推荐答案
- 为什么你推荐这个答案

你负责查事实。凡是可以通过阅读代码、文件、文档、配置或工具获得的信息，你自己去查，不要问我。

但决定必须由我来做。你不能替我决定，也不能默认我同意。

每轮提问后，等待我的回答。根据我的回答更新决策树，再进入下一轮。

当你认为所有关键分支都已经问完时，请总结我们达成的理解，并问我是否确认。

在我明确确认之前，不要开始写代码、改文件或执行实现。

这一步看起来慢，但我觉得是最值的。很多题目的坑就藏在 README 的一句话和已有代码的约定里，等它写完再发现，返工的成本高得多。

第 2 步：架构设计

需求对齐之后，我会让它输出一份开发 spec，把”这个项目怎么跑、准备怎么改”讲清楚，包括已知信息、功能点拆解、实现思路、测试方式、不做什么和风险点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
请先阅读题目说明、README、项目目录、已有测试、入口文件和核心代码。

本阶段不要写代码，只整理一份可执行的开发 spec。

请重点回答：

1. 题目目标
用简洁语言说明这个题目最终要实现什么。

2. 已知信息
列出 README、代码和测试中已经明确的信息，包括输入输出、业务规则、已有模块、运行方式和测试方式。

3. 需求拆解
把题目要求拆成清晰的功能点。
每个功能点都要说明：要做什么、影响哪里、如何判断完成。

4. 实现思路
说明你建议怎么改。
包括需要关注的模块、核心流程、数据结构、接口关系和边界情况。
不要开始写代码。

5. 测试与验收
说明应该如何验证完成。
优先使用项目已有测试方式。
列出需要运行的测试命令、关键测试场景和验收标准。

6. 不做什么
明确哪些内容不要做，避免超范围实现。

7. 风险点
列出最容易出错的地方，比如边界条件、兼容性、隐藏测试、异常输入或项目约定。

输出后请等待我确认，再进入实现阶段。

我自己最看重”不做什么”和”风险点”这两节。AI 实现需求时很容易顺手加戏，提前把边界写死，后面能少很多麻烦。

第 3 步：拆分 + 开发

有了 spec，我不会让它一口气全做，而是先拆成一组小 ticket，每个 ticket 小到一个会话能完成，有明确的边界、验收标准和测试，再按依赖顺序排好。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
请根据这份 spec 拆成一组可执行的开发 tickets。不要重新讨论需求，不要修改 spec，不要开始写代码。

要求：
- 每个 ticket 要足够小，适合一个 AI Coding 会话完成。
- 每个 ticket 都要有明确边界、验收标准和测试要求。
- 按依赖顺序排列：基础 → 核心 → 边界 → 收尾。
- 测试跟对应实现放在同一个 ticket 里。
- 每个 ticket 都要对应 spec 的具体部分，并遵守“不做什么”。

请先简要说明拆分思路、执行顺序和最大风险点。

然后按下面格式输出：

Ticket <编号>：<标题>

目标
这个 ticket 要完成什么。

背景
它来自 spec 的哪部分，为什么需要做。

修改范围
预计影响哪些模块、页面、接口、状态、数据结构或测试。

任务
列出具体要做的事。

验收标准
完成后应该满足什么，必须可检查。

测试要求
需要增加或修改哪些测试。只测试外部行为，不测试实现细节。

依赖
依赖哪些 ticket。没有就写“无”。

不包含
这个 ticket 明确不做什么。

如果发现 spec 有缺口，不要自行补完。请单独列出“需要确认的问题”，但仍然先拆出当前能确定的 tickets。

然后一个 ticket 一个 ticket 地实现，每次只做当前这一个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
请实现 Ticket <编号>。

只处理这个 ticket 的范围，不要顺手实现其他 ticket。

实现时请遵守：
- 对照 spec 和当前 ticket 的验收标准。
- 优先使用项目已有模式和工具。
- 测试跟实现一起完成。
- 不做无关重构。
- 不扩大需求范围。

完成后请输出：
1. 修改了什么
2. 如何验证
3. 已运行的测试命令和结果
4. 仍然存在的风险或待确认问题

一次只喂一个 ticket，是我踩过坑之后学到的。让它一次做五件事，它大概率会漏掉两件，还把不相关的代码搅在一起，到时候都不知道该从哪查起。

第 4 步：Code Review

每做完一个 ticket，我会立刻让它 review 自己的改动，而不是攒到最后一起看。

1
2
3
4
5
6
7
8
9
10
11
12
请对刚才实现的改动做 code review。

重点检查：
1. 是否符合对应 ticket 和 spec
2. 是否有漏实现或超范围实现
3. 是否有 bug、边界问题或回归风险
4. 测试是否覆盖关键行为
5. 是否符合项目已有代码风格和架构模式

请先列出问题，按严重程度排序，并给出文件位置和修改建议。

没有问题也请明确说明。

这一步经常能抓到它自己几分钟前刚写出来的边界 bug，成本就是多等一轮对话，很划算。

第 5 步：验收测试

Review 通过之后，再做一次整体验收，对照 README、ticket 和 spec 逐条列表：需求、验收标准、实现位置、测试证据、当前状态。这一步只验收，不改代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
请做一次验收测试。

本阶段只验收，不直接改代码。

请对照 README、ticket 和 spec，逐条列出需求验收表。

验收表至少包含：
- 需求
- 验收标准
- 实现位置
- 测试证据
- 当前状态

当前状态请从下面选：
- 已实现且有运行证据
- 静态看起来满足但待验证
- 部分实现
- 未实现
- 失败
- 阻塞

请先给总体结论：当前是否可以交付。

注意：测试通过，不代表需求完成。必须逐条对照题目要求。

如果发现问题，只记录：
- 问题现象
- 证据
- 影响范围
- 建议修复位置
- 优先级

不要直接修复。先把问题讲清楚，等待我确认后再进入下一步。

记住测试通过不等于需求完成，必须逐条对照题目要求。发现问题先记录现象、证据、影响范围和建议修复位置，等我确认之后再动手。

第 6 步：定点修复

最后是修 bug。测试通过率上不去的时候，我不让它直接动手改，而是先输出一张”失败卡片”，列出最多 3 个根因假设，每个假设写清支持证据和验证方式，然后只挑最可能、影响面最小的一个来修。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
现在只修一个具体问题。

先定位根因，再做最小修复。

请先输出失败卡片：
- 问题现象
- 错误类型
- 影响需求
- 已知证据
- 合理推断
- 未知信息

然后列出最多 3 个根因假设，每个假设都要写清楚支持证据和验证方式。

本轮只选择一个最可能、影响面最小的假设来修。

修复前，优先写一个能复现问题的测试、脚本或手工验证步骤。

修复时只改必要代码，不改整体架构，不加无关功能。

改完后给我复测命令。

在我贴回运行结果前，不要说已修复，只能说待验证。

修之前先写一个能复现问题的测试或验证步骤，改完让它给我复测命令；在我贴回运行结果之前，它只能说”待验证”，不能说”已修复”。

这套流程能保住的是下限。只要每一步都认真确认，AI 基本不会写嗨了做偏题，也不会把原本能跑的代码改崩，基本完成度是有的。

但它也就到此为止了。想冲高分、想过那些隐藏测试，模板帮不上忙，还是得自己读得懂代码结构、理得清业务规则、想得到边界情况。提示词管的是流程，最后拼的还是自己的判断力，这点我也还在练。