编码智能体如何在您保持控制的情况下修复错误、运行测试并提交代码？

Question

Accepted Answer

编码**智能体**可以端到端地驱动错误修复 — 重现、定位、修复、验证、提交 — 但您可以通过**限定权限、人工批准和小的可逆步骤**来保持控制。智能体负责打字；您决定什么最终会合并到代码库。

## 循环

```text
1. REPRODUCE  → write/run a failing test that demonstrates the bug (red)
2. LOCATE     → search the codebase, read the relevant files, form a hypothesis
3. PROPOSE    → draft a minimal fix (you can review the plan before any edit)
4. VERIFY     → run tests + lint/typecheck → fix is proven by the test going green
5. REVIEW     → show the DIFF for your approval (nothing committed yet)
6. COMMIT     → only after approval, on a branch, with a clear message
```

核心思想是**测试驱动验证**：智能体不是声称"已修复" — 而是通过让失败的测试通过来证明它。第 1 步的失败测试是证明更改有效的客观信号。

## 控制机制

```text
- SCOPED PERMISSIONS → allowlist safe commands (test, lint); prompt for the rest
- APPROVAL GATES     → human confirms destructive/irreversible actions + the final commit
- SMALL STEPS        → one focused change at a time → easy to review and revert
- BRANCH / WORKTREE   → work isolated from main; throw it away if it goes wrong
- DIFF REVIEW        → read the actual diff before commit, not just the agent's summary
```

```bash
# The agent runs the suite itself and reports the result before proposing a commit
npm test -- --runInBand   # red before the fix, green after → objective verification
git diff                  # you review every line that will be committed
```

在**分支或 git worktree** 中运行意味着最坏的情况是 `git checkout main` — 实验永远不会影响您的工作区。小的、可逆的提交使得每一步都易于检查和撤销。

## 为什么这很重要

智能体编码将您从逐行敲代码转变为**审查和引导**。自动化的杠杆作用确实很强，但智能体可能会自信地提交错误或破坏性的更改，这种风险也是真实的。在提交之前保留人工批准门槛、用测试而不是文字来验证、以及在分支中隔离工作，让您既能获得自动化的速度，又能保持对什么最终进入 `main` 的决定权。