AI Coding 七步工程流程：从题目到可验收交付

视频来源：手撕大厂题-vibe coding降龙七步（青阳-AI，8 分 57 秒） 整理说明：七步流程、上下文漂移、路径依赖和卡 Bug 处理来自视频；标有“补充”的内容是为了方便实践而加入的工程化展开。

本文是通用流程。针对 AI 无执行权限、最终评测与对话 Token 共同考核的限时笔试，优先阅读 AI Coding笔试高分指南 和 AI Coding笔试Prompt速查。

一、先记住结论

AI Coding 不是“把题目复制给 AI，然后等待完整答案”，而是：

人负责目标、取舍、边界与验收，AI 负责在反馈闭环中探索和执行。

可以把可靠交付理解为：

可靠交付 = 清晰目标 × 小步闭环 × 可执行反馈 × 人类检查点

其中任何一项缺失，都可能出现“代码很多，但无法证明题目已经完成”的结果。

flowchart LR
    A["1. 问题定义"] --> B["2. 确定方案"]
    B --> C["3. 搭建核心骨架"]
    C --> D["4. 完成最小闭环"]
    D --> E["5. 异常、边界检验"]
    E --> F["6. 按定义与骨架验收"]
    F --> G["7. 编写交付材料"]
    D -. "发现方向错误" .-> B
    E -. "发现结构问题" .-> C
    F -. "发现需求遗漏" .-> A

这不是一条只能向前走的流水线。发现错误时应回到相应决策点，而不是继续在错误路径上堆补丁。

二、七步总览

视频强调：关键要求和决策要沉淀到 Markdown 文档中，不要只留在聊天记录里。长对话被清理、压缩或重新开启后，AI 仍能从仓库中的文档恢复目标。

小任务不必机械地创建七份文档，可以把这些内容合并到一个 PLAN.md 或题目要求的 README.md 中；重点是信息可恢复、可版本化、可检查。

三、逐步执行

第一步：问题定义

先让 AI 复述和结构化题目，不要立即写代码。

至少回答以下问题：

• 用户是谁，要解决什么问题？
• 输入是什么，格式、规模和异常情况是什么？
• 输出是什么，格式和示例是什么？
• 必须实现哪些功能，明确不做什么？
• 技术、时间、依赖、权限和性能约束是什么？
• 必须交付哪些文件或运行结果？
• 什么可观察证据能够证明完成？
• 哪些信息尚不明确，需要提问或声明假设？

可复用提示词：

先不要写代码。请把下面的题目整理成可执行的问题定义：

1. 用户与目标
2. 输入、输出及其格式
3. 必须交付的内容
4. 功能约束和非功能约束
5. 完成定义与可执行的验收标准
6. 风险、歧义和需要确认的问题

缺失的信息请标记为“待确认”，不要自行脑补。
确认后把结论写入项目内的 Markdown 文档。

检查点：如果你还不能根据问题定义写出验收用例，就说明题目还没有被定义清楚。

第二步：确定方案

让 AI 给出 2～3 个可执行方案，再由人做取舍。不要只接受第一个“看起来能用”的答案。

比较维度可以包括：

• 能否在规定时间内交付；
• 是否满足原题的硬约束；
• 实现与调试复杂度；
• 可测试性和可观测性；
• 性能、安全与数据一致性风险；
• 后续扩展和接手成本。

可复用提示词：

基于已确认的问题定义，提出 2～3 个可交付方案。
请按实现复杂度、风险、可测试性、交付时间和后续扩展性比较，
推荐一个方案并说明理由，同时记录未选择其他方案的原因。
先等我确认，不要开始实现。

应保留的不只是最终方案，还包括被放弃方案及其原因。否则后续 Agent 可能再次提出已经否决的路线。

第三步：搭建核心骨架

方案确定后，先设计系统的骨架，再拆实现任务。视频中强调的内容包括：

• 核心模块及每个模块的职责；
• 模块之间如何通信；
• 目录结构和关键文件；
• API、数据结构与数据库设计；
• 模块之间的隔离与边界。

可复用提示词：

根据已确认的方案，只设计核心骨架，不要一次性实现全部功能。
请输出：

1. 模块及单一职责
2. 模块之间的依赖和通信方式
3. 核心接口、输入输出和错误语义
4. 关键数据结构与状态变化
5. 建议目录结构
6. 不允许跨越的边界或不变量

最后说明这个骨架如何支持后续的小步实现和独立测试。

补充：骨架的目的不是提前设计所有细节，而是固定高成本边界。模块内部实现可以演进，但公共接口、状态机、数据所有权和依赖方向不应被 AI 随意改变。

第四步：完成最小闭环

不要按“先写完所有后端，再写所有前端”的方式横向铺开。优先选择一条最小但完整的主链路，从输入一直走到输出。

每轮只推进一个小任务，并明确：

• 本轮目标；
• 允许修改的文件或模块；
• 禁止改变的接口与行为；
• 本轮完成后执行什么命令或观察什么结果；
• 失败时保留哪些日志和证据。

执行节奏：

1. 选择一条最小端到端链路；
2. 让 AI 实现一个可独立验收的小步；
3. 查看差异，确认没有无关修改；
4. 运行最小测试或实际操作；
5. 记录结果，再进入下一步；
6. 持续扩展闭环，直到主流程完整。

可复用提示词：

现在只完成任务 T1，不要实现后续任务，也不要重构无关代码。

目标：...
允许修改：...
禁止修改：...
完成标准：...
验证命令或可观察结果：...

完成后请列出实际修改文件、验证结果和仍未解决的问题。

当上下文变得很长时，应先确认关键决策已经写入仓库，再压缩或清理上下文，必要时开启新会话并重新读取问题定义、方案和骨架。新会话不等于丢失项目状态，只要状态已沉淀到文件和 Git 中。

第五步：做异常、边界检验和测试

主流程跑通不等于任务完成。让 AI 切换到测试工程师视角，主动寻找“正常演示不会出现，但真实使用一定会遇到”的情况。

补充测试矩阵：

可复用提示词：

请切换到测试工程师视角。基于问题定义和当前实现，
列出尚未覆盖的边界、异常路径、失败依赖、状态冲突和安全风险。

先给出“场景—预期行为—验证方式”的测试矩阵，
等我确认后再逐项补测试和修复。不要用跳过测试或吞掉异常来制造通过。

第六步：基于问题定义和骨架验收

测试关心“代码在某些输入下是否工作”，验收还要回答“做出来的是不是原题要的东西”。

建议建立最小追踪表：

验收时检查：

• 每条硬性要求是否有实现和证据；
• 输入、输出与交付格式是否完全匹配；
• 主链路和关键失败链路是否实际运行；
• 实现是否仍遵守选定方案和模块边界；
• 是否出现题目没有要求的过度设计；
• 测试是否真的执行，而不是只生成了测试文件；
• 是否存在只能靠人工主观判断的质量项。

视觉效果、交互感受、代码组织是否清晰、文档是否易懂等内容，即使自动测试通过，也需要人类检查。

第七步：写最后的交付材料

交付的目标是让下一位接手者不依赖聊天记录，也能运行、验证并继续开发。

交付材料至少说明：

• 项目解决了什么问题，完成了哪些功能；
• 安装、启动和最短演示路径；
• 输入、输出格式及示例；
• 核心设计、目录和模块边界；
• 测试命令、测试范围和实际结果；
• 已知限制、风险、假设与未完成项；
• 后续可以优化什么，但不要把规划写成已经实现。

可复用提示词：

请根据问题定义、设计文档、实际代码和真实测试结果整理交付材料。
不要仅根据聊天记录推测。

必须包含：功能范围、启动方式、最短验证路径、输入输出示例、
设计说明、测试命令与结果、已知限制、风险和后续优化点。
未验证的内容必须明确标记，不能写成已完成。

四、为什么这套流程有效

1. 上下文有限，目标会漂移

长会话会混入旧方案、失败尝试、大段日志和无关文件。关键目标如果只在聊天开头出现，后续可能被淡化。把问题定义、方案和骨架写进仓库，相当于为 AI 设置可重新读取的检查点。

2. AI 容易形成路径依赖

AI 可能抓住一条看似可行的路径不断补丁，即使新证据已经说明方向错误。人需要在关键节点暂停执行，要求它重新比较假设和方案。

3. AI 需要可执行反馈

“感觉不对”“再优化一下”不是可靠反馈。失败测试、错误日志、期望输出、截图差异和性能指标才是 AI 可以据此收敛的信号。

4. 自动检查不能代替全部判断

测试可以证明已覆盖的行为，却不能自动证明需求没有遗漏，也不能完全判断产品体验、风险接受度和代码是否易于接手。人类检查点仍然必要。

五、卡 Bug 时：停止补丁循环

视频给出的核心方法是：先复现，找根因，验证；路径错误时回退，再尝试其他路径。

实用停止信号（补充）：连续两轮修改没有产生新证据，失败范围也没有缩小，就不要继续说“再试一次”。先清理现场并重新诊断。

依次检查：

1. 目标和约束是否已经漂移？
2. 当前失败能否稳定复现？
3. 哪些观察是事实，哪些只是猜测？
4. 已尝试过什么，各自排除了什么假设？
5. 上下文是否被无关信息或旧方案污染？
6. 任务是否太大，需要缩成一个最小复现？
7. 多个 Agent 或多人是否同时修改了同一边界？
8. 什么证据才算修复完成？

可复用提示词：

先停止修改代码，不要继续叠加补丁。

请只做诊断并输出：
1. 预期行为和稳定复现步骤
2. 已观察到的事实、日志和失败测试
3. 已尝试路径及其结果
4. 最可能的 2～3 个根因假设
5. 每个假设的最小验证实验
6. 建议先验证哪一个，以及为什么
7. 哪些无效修改应当回退

得到验证证据后，再提出最小修复方案。

六、人类必须把住的检查点

AI 可以提出建议或执行，但下面这些决定不能被默认外包：

• 需求歧义如何解释，哪些假设可以接受；
• 技术方案的成本、风险与交付取舍；
• 数据所有权、权限、安全和架构边界；
• 是否接受公共接口、数据库结构或依赖变化；
• 失败是否真正被修复，而不是被隐藏；
• 测试证据是否足以支持“完成”；
• 交付说明是否忠实于真实实现。

一个简单习惯：每轮 AI 修改后都问自己三个问题——改了什么？为什么这样改？用什么证据证明它是对的？

七、跟着视频做一次练习

视频中的示例题是一个简历筛选和排序助手：

• 输入：约 6 份 Markdown 简历和岗位要求；
• 输出：result.json，包含候选人的排序结果；
• 功能：特征提取、同义词归一化、评分；
• 交付：源码、说明文档、输出结果、测试代码和后续优化点。

练习规则

不要一次性让 AI 写完。严格走完七步，并保留每一步的产物：

README.md              # 运行、使用与交付说明
docs/problem.md         # 问题定义和验收标准
docs/decision.md        # 方案比较与选择
docs/architecture.md    # 模块、接口和数据结构
docs/acceptance.md      # 需求—测试—结果对应表
src/                    # 实现
tests/                  # 正常、异常和边界测试
result.json             # 题目要求的示例输出

小项目也可以把 docs/ 中的内容合并到一个 PLAN.md，但不要只保留在聊天里。

建议的最小闭环

1. 先用一份简历和一条岗位要求跑通“读取—提取—评分—输出”；
2. 为这条链路写一个确定性的测试；
3. 再扩展到多份简历、同义词归一化和稳定排序；
4. 补空文件、字段缺失、重复候选人、同分和非法 Markdown；
5. 最后按原题逐条验收，并从零执行 README 中的命令。

最低验收标准

• result.json 结构固定，可被程序解析；
• 同一输入重复运行得到稳定排序；
• 缺失字段不会导致程序无说明地崩溃；
• 同义词归一化有明确规则和测试；
• 每个评分结果能够追溯到输入特征和规则；
• README 中的启动与测试命令在干净环境中可执行；
• 已知限制被写清楚，没有伪装成已经解决。

练习结束后复盘：哪一步由你做了关键决策？AI 在哪里开始跑偏？哪个测试最早暴露了问题？如果重新做一次，你会把哪条经验固化成文档、测试或自动检查？

八、一页速查

1. 定义：输入、输出、约束、交付物、完成标准
2. 选型：比较 2～3 个方案，记录取舍
3. 骨架：模块、接口、数据、状态、目录、边界
4. 闭环：一次一个小步，每步都有验证证据
5. 找错：异常、边界、失败依赖、并发、安全
6. 验收：让每条需求对应实现和真实测试结果
7. 交付：README、设计、测试、限制、风险、后续项

卡住时：停止补丁 → 稳定复现 → 提出根因假设
       → 做最小实验 → 修复 → 回归验证 → 错路回退

参考资料

• B 站：手撕大厂题-vibe coding降龙七步
• OpenAI Codex：Best practices
• OpenAI：Harness engineering
• Anthropic：Claude Code Best Practices
• GitHub：Spec-driven development with AI

相关笔记

• AI Coding笔试高分指南 — 针对结果分、过程分和 Token 效率的应试策略
• AI Coding笔试Prompt速查 — 限时笔试的精简对话模板
• AI Coding笔试模拟训练 — 后端和游戏规则题训练
• AI辅助编程工程方法 — AI Coding 面试考察点与通用工程方法
• AI Coding面试实战题 — 用完整题目练习拆解、实现、测试与复盘
• AI Coding面试问答 — 高频概念与回答框架
• Harness Engineering 实践启示 — 将约束、反馈和验证做成工程环境
• 从 Claude Code 学习 Agent 工程实现
• AI辅助编程 MOC