AI 编程从哪里开始：工具选择、仓库改动与交付验收
从修复一个能复现的小问题开始，选择适合的编程工具，给出可检查的任务范围，再核对代码实际运行结果。本导读串联概念解释与具体排错文章。
先交付一个可以验证的小改动
第一次使用 AI 编程，适合选择已有项目中的一个小改动，例如修复无效按钮或增加一个字段校验。先写下原来的错误表现，再约定改好后的可见结果。工具能生成补丁，只说明它完成了一次修改；运行相关检查并核对实际页面，才有依据判断任务是否完成。
按任务决定使用哪一种编程工具
只需补全当前函数，可以先使用编辑器中的代码补全。需要读取多个文件并运行检查，再考虑编程 Agent。IDE 与命令行描述的是操作入口，不能单凭界面判断代码在哪里执行；接入云端环境时，要另外确认依赖安装位置和仓库版本。
不要因为换了一个产品名字就从头建立判断标准。保留同一个小任务，在自己的项目里比较修改范围和实际结果。本文不提供工具性能排名，也没有把官方描述作为本站对各产品的横向实测。
把任务写成可检查的改动范围
给 Agent 的任务应包含出错入口，并附上能够重现问题的输入。例如“空邮箱提交后仍创建账户，应显示提示且不发送创建请求”，比“把注册页优化一下”更容易验收。涉及旧代码时，先让它读取现有实现，避免把项目已经使用的框架替换成另一套。
明确允许修改的功能，并说明本次交付是否包含上线。项目已有未提交修改时，先保存状态或使用隔离目录，让后续差异能够区分本次补丁与原有工作。资料中的指令也需要单独判断，仓库注释和网页文字不能自动扩大用户授权。
- 记录当前仓库状态，确认本次问题涉及哪个页面或命令，并保留一个可重复执行的失败样例。
- 写明改好后的实际表现，把不能改变的业务规则放在同一份任务说明里。
- 约定必要检查和交付范围；如果测试环境无法复现，要先补足环境信息。
从失败现象选择验证办法
验收应回到原来的失败路径。页面问题需要在浏览器里重做同一操作，接口问题需要核对响应与最终状态。编译成功能发现部分代码错误，但不能证明一个按钮触发了正确动作；测试通过也要看测试是否覆盖原来的问题。
对无法自动验证的结果，保留清楚的手动检查记录。若 Agent 只报告“已完成”却没有命令结果或可观察证据，应继续检查具体交付，而不是根据它调用了多少次工具来判断质量。记录失败样本还能帮助下一次改动发现同类回归。
| 问题位置 | 优先检查 | 不能据此判定成功 |
|---|---|---|
| 页面交互 | 按原步骤操作并检查页面结果 | 只有构建成功截图 |
| 库函数或接口 | 按当前依赖版本执行最小调用 | 文档里找到相似名称 |
| 上线后行为 | 访问真实地址并检查关键功能 | 本地预览可以打开 |
反复修不好时先缩小失败路径
修改几轮仍报同样错误时，先停止继续扩大补丁。保存原始报错，并找出第一次出现错误的最小输入。若模型给出的函数在当前版本里不存在，应回到所安装依赖的官方文档核对；一边换库一边修业务逻辑，会让问题更难定位。
长会话开始遗忘要求时，重新提供当前任务状态，并指出已经通过的检查。上下文工程的目标是让这一步得到相关资料，不是把全部历史重复粘贴。Agent 一直检查却不交付时，应明确剩余验证和停止条件，而不是继续增加同义要求。
保留可复查的交付记录
交付记录应说明实际改动，并附上验证结果。如果有未测试的系统或输入类型，需要明确列出；测试环境能够通过，不能推定所有设备都正常。准备上线时，按项目已有流程保留可恢复版本，再到真实地址检查，而不是停在预览页面。
审阅补丁时，将 Git 差异与任务范围对照。无法解释的配置变化应先弄清用途，再决定是否保留。对 AI 生成代码的审查同样需要具体失败条件；“代码可能不好”不是足够的缺陷描述，而一个可复现的输入能直接帮助修复。
方法参考
以下资料说明相关方法与技术条件。本文是任务导读；本站实测的样本和结果由链接中的实测指南单独说明。