无解的博客

Appearance

wxvirus2026-10-08
2388
8.1m

如何建立适合新手的 AI 结对编程流程：提问、执行、验证、复盘 ​

AI 结对编程流程封面

引言：AI 不是自动售货机，而是一位需要被带领的搭档 ​

刚开始使用 AI 编程时，很多人会把需求一次性丢给 AI，然后期待它直接交付一套完整代码。结果往往是：代码看起来很多，却不知道放在哪里；程序能运行，却不知道是否真的解决了问题；出现报错后，只能把一大段日志再次粘贴给 AI，越改越乱。

更稳妥的方式，是把 AI 当成一位速度很快、但不了解你项目背景的结对编程伙伴。你负责说明目标、提供上下文和做最终判断，AI 负责搜索、解释、编写和提出检查办法。整个过程可以固定成四个环节：提问、执行、验证、复盘。四个环节不是一次性的直线，而是一个小循环：验证没有通过，就带着新证据回到提问；复盘后形成的经验，又会让下一次提问更准确。

一、提问：先把“想做什么”说清楚 ​

1. 先描述结果，再描述手段 ​

新手最容易犯的错误，是一上来就指定技术方案，例如“帮我写一个 Redis 缓存类”。但你真正想解决的可能是“首页接口响应太慢”。更好的提问顺序是：先说用户能看到的结果，再补充你已经知道的约束。

例如：

text
我正在学习 Go，项目是一个简单的待办事项 API。
目标：让 GET /tasks 返回当前用户的待办事项，并且没有登录时返回 401。
现状：项目使用 net/http，数据暂时保存在内存中。
请先阅读相关目录，告诉我需要修改哪些文件，不要马上写代码。

这样提问，AI 会先理解项目，而不是凭空创建一套与你的项目不匹配的结构。

2. 一次只解决一个小目标 ​

把“注册、登录、支付、消息通知和部署”放进同一个问题，会让 AI 难以保持上下文，也让你无法判断是哪一步出了问题。新手可以把任务拆成 30 分钟左右能验证的小块，例如：先实现登录接口，再补登录失败测试，最后接入前端页面。

每次提问最好包含四项信息：目标、现状、限制、验收标准。验收标准要尽量可观察，例如“运行 go test ./... 通过”“输入空标题时返回 400”，不要只写“代码要健壮”。

3. 让 AI 先复述理解 ​

对于不熟悉的项目，先要求 AI 输出“我对需求的理解、相关文件、准备采取的步骤和风险”，等你确认后再执行。这一步看起来慢，实际上能避免 AI 在错误方向上写出几十行代码。若它提到的文件与你看到的项目不一致，立即纠正，不要等到代码完成后再返工。

常见问题与建议 ​

  • 问题太短：只说“帮我修一下登录”。建议补充报错信息、复现步骤、预期行为和实际行为。
  • 上下文太多：一次贴整个项目。建议先说明目录结构，再让 AI 按需读取文件。
  • 没有边界：AI 可能顺手升级依赖或重构无关代码。明确写出“只修改这些文件，不改公共接口，不新增依赖”。

二、执行：让 AI 小步修改，并保持你能跟上 ​

1. 先看计划，再让它动手 ​

确认理解无误后，可以让 AI 按清单执行：先修改一个文件，展示关键差异，再继续下一个文件。新手不需要一开始就理解每一行代码，但要知道每个文件为什么会被改动。若 AI 提议新增依赖，先问一句：“标准库或项目已有依赖能否完成？”这能减少安装和维护成本。

2. 使用“解释—执行—停顿”的节奏 ​

适合新手的节奏不是让 AI 连续运行十分钟，而是每完成一个小步骤就停下来说明：改了什么、为什么这样改、下一步准备做什么。例如实现一个表单校验时，可以先让 AI 写校验函数，再运行一个最小示例，确认输入为空、长度过长和正常输入三种情况后，再接到页面。

3. 把命令和输出留在现场 ​

尽量让 AI 在当前项目目录执行命令，并把完整命令和关键输出告诉你。不要只接受“已经完成”的口头结论。你可以要求它在每一步结束时列出：执行的命令、修改的文件、命令结果、仍未解决的问题。

4. 不懂就追问，不要复制粘贴到失控 ​

看到陌生代码时，用小问题拆开理解，例如“这一行为什么要用指针？”“这个错误分支会在什么输入下触发？”如果 AI 一次改了太多地方，直接要求它暂停并展示 git diff。必要时先保存当前进度，再回退到最后一个可运行状态。

常见问题与建议 ​

  • AI 改了无关文件：立即查看差异，要求撤销无关改动；不要用“顺便优化”扩大范围。
  • 命令卡住：先确认是否在等待输入、网络下载或服务启动，不要重复运行同一命令。
  • 错误越改越多：停止继续堆补丁，回到最后一个通过检查的版本，重新描述根因和证据。

三、验证：用证据判断，而不是凭感觉 ​

验证不是最后才做的一次“大考试”，而是每个小步骤后的快速检查。至少分三层：

  1. 静态检查：格式化、类型检查、构建或 lint，确认代码结构没有明显问题。
  2. 自动测试：覆盖正常输入、边界输入和错误输入。比如待办接口至少测试未登录、空标题和正常创建三种情况。
  3. 真实操作：启动应用，用浏览器或命令行走一遍用户流程。页面能打开不等于保存成功，还要确认刷新后数据仍符合预期。

可以直接这样要求 AI：

text
请先不要修改代码。根据当前实现，给出最小验证清单：
1. 要运行哪些命令；
2. 每条命令预期看到什么；
3. 哪些失败说明是代码问题，哪些可能是环境问题。

验证失败时，提交“事实包”而不是一句“还是不行”：包括执行命令、完整错误、复现步骤、最近一次改动和预期结果。事实越完整，AI 越容易定位根因。

常见问题与建议 ​

  • 只看构建成功：构建只说明语法和依赖基本可用，不能证明业务正确。
  • 只测成功路径：错误输入通常更能暴露问题，至少补一个边界案例。
  • 把环境问题当代码问题：先确认端口、数据库、环境变量和依赖版本，再判断是否需要改代码。
  • 测试结果不完整：等待命令真正结束并记录退出码，不能把“正在运行”当成通过。

四、复盘：把一次对话变成下一次的能力 ​

复盘不需要写长报告，五分钟就够。完成后回答四个问题：

  1. 这次目标是否完成？用什么证据证明？
  2. 哪个提问最有效？缺了什么上下文？
  3. 哪个错误重复出现？根因是需求、代码还是环境？
  4. 下次可以提前准备什么检查或模板？

建议在项目里维护一个简短的 AI_NOTES.md，记录可复用的命令、目录说明、常见错误和已确认的约束。例如：“本项目测试前必须启动 PostgreSQL”“接口错误统一返回 JSON，不要返回 HTML”。这些事实比泛泛的提示词更有价值，也能减少每次重新解释项目的时间。

复盘时还要检查范围：有没有为了修一个小问题引入新依赖？有没有修改不相关文件？有没有把 AI 的猜测当成事实？如果答案是“有”，下次就在提问阶段加入明确限制。

总结：把 AI 速度放进一个可控的小循环 ​

适合新手的 AI 结对编程，不是让 AI 替你做完全部工作，而是让每一步都能被理解、执行和验证。提问负责把目标和边界说清楚，执行负责小步修改，验证负责用命令和真实操作收集证据，复盘负责沉淀经验。你可以先从一个很小的任务开始：让 AI 修改一个函数、补一个测试、运行一次检查，再记录结果。

当你不确定下一步做什么时，回到四个问题：目标是什么？现在有什么证据？最小改动是什么？如何证明改对了？ 按这个顺序循环，AI 就不再只是“帮你生成代码的工具”，而会成为一个能一起定位问题、解释选择并持续改进的编程伙伴。

最近更新