绝对不能交给 AI Agent做的6件事

Selenium.

324人浏览 · 2026-06-12 22:20:07

Selenium. · 2026-06-12 22:20:07 发布

绝对不能交给 AI Agent做的6件事

前言

你也在让 AI Agent 帮你写代码吗？
很好！

但我有过这样的经历：Agent “按指示正确执行” 反而让我白白浪费了 1 小时。

真实案例：我让 Agent “把仓库清理一下，把没在用的文件删掉”。结果 Agent 把"没在用"理解得很宽，连部署脚本还在引用的配置目录都一起删了——而那个配置目录恰好在 .gitignore 里，不受 Git 管理。

结果：恢复被删的文件花了我 1 小时。

教训：要会判断哪些任务该交给 AI。这是和 AI Agent 协作时最重要的能力。

下面把我自己实践中的经验详细分享出来。

权限矩阵：什么时候交给 Agent，什么时候人审

任务类型	Agent 的自主度	是否需要人审	理由 / 风险
小函数的重构	高	不需要或很轻	容易回滚。风险低。
加单元测试	高	通常不需要	CI 立即就能发现。
前端 Bug 修复（UI）	中～高	需要目视确认	逻辑 bug 看得到，但 UI 的细微不协调需要人眼。
改 API 行为	中	需要	会影响客户端。必须审"契约"。
引入新依赖	中	需要	可能带来安全漏洞或许可证问题。
数据库迁移	低	必须	错的迁移会导致数据丢失或 schema 损坏。
鉴权 / 安全逻辑	低	必须	漏洞单元测试抓不到，几个月后以事故报告的形式被发现。
基础设施 / 云（IAM、k8s、terraform）	极低	必须	权限配错会悄无声息地毁掉系统，溯源极难。
部署到生产	零（必须手动）	必须 + 人工确认	Agent 不知道有没有进行中的事故、也不清楚维护窗口。

简单规则：凡是"无法回滚"的操作，必须设置人工检查点。

按风险级别分类的实例

风险级别	任务示例	Agent 弄错后的影响	能否回滚？
高自主	改个变量名	编译不过，CI 立即报错，5 分钟修好	✅ 简单
中	改 API 响应格式	调用方会报错，但还没上生产就没大事	⚠️ revert commit 即可
低	删一个数据库字段	数据丢失。从备份恢复要几小时到几天	❌ 极难
零自主	凌晨 3 点部署到生产	没人发现，影响用户，on-call 找不到人	❌ 极难

绝对不能交给 AI Agent 的 6 件事

1. 破坏性文件操作

rm -rf、git clean -fd、git reset --hard
Agent 一看到 “clean up” 这种字眼，可能在重构过程中直接执行 git clean -fd，所有未提交的修改一瞬间全没了。

2. 数据库的写 / 删操作

没有 WHERE 子句的 DELETE、DROP TABLE、TRUNCATE，以及任何触碰生产数据的 migration
WHERE 子句打错一个字就能把整张表干掉，Agent 不会替你二次确认。

3. 基础设施（云）

terraform apply、kubectl delete、aws iam *
权限相关的操作尤其危险，出问题前一切看起来都正常。

4. 部署到生产

代码可以由 Agent 写，但**"什么时候部署"的决定必须由你做**。
Agent 不知道"现在有没有进行中的事故"“今晚有没有维护窗口”。

5. 鉴权 / 安全逻辑

登录流程、授权规则、token 处理、会话管理
这类 bug 单元测试抓不到，通常以事故报告的形式暴露出来，甚至可能延迟数月。

6. Secrets、`.env` 文件、API 密钥

绝不允许 Agent 读取或写入这些文件。

AGENTS.md：与 AI 的"合同"

在仓库根目录放一个 AGENTS.md 文件。它向 Agent 说明三件事：项目目标、怎么执行、以及绝对不能碰的东西。

我用的模板

# AGENTS.md

## Project
[项目的简要说明和技术栈]

## Setup

npm install # 或 pip install -r requirements.txt
npm run dev
npm test
npm run lint


## Coding rules
- 改动保持最小，不要顺手重构无关代码。
- 改了行为就要新增或更新测试。
- 不要触碰任务范围之外的文件。
- 一个 commit 只做一件事。

## Safety rules
执行 blocked_commands.md 中列出的命令前必须先征得确认。
不确定安不安全 → 停下来问人。

## Definition of done
- 测试通过
- diff 改动能用一句话说清楚
- 有 final report（见下）

## Final report format
每个任务结束后，Agent 必须提供：
1. 改动概要
2. 改动了哪些文件
3. 跑了哪些测试、结果如何
4. 风险或前提条件
5. 没完成的事项

### `blocked_commands.md`（执行前必须审批）

```markdown
# blocked_commands.md

## 破坏性文件操作
- rm -rf
- git clean -fd
- git reset --hard

## Git 操作
- git push --force
- git push --force-with-lease

## 数据库操作
- DROP TABLE
- TRUNCATE TABLE
- 没有 WHERE 子句的 DELETE
- 会改生产 schema 的 migration

## Cloud / Infrastructure
- terraform apply
- kubectl delete
- aws iam *
- gcloud iam *

## Secrets
- 任何读 / 写 .env 文件的命令
- 任何触碰 API key、凭证的命令

## Two-Agent Loop：一个写、另一个审

对于中等及以上复杂度的任务，用 **2 个** Agent，而不是 1 个。

### Agent 1 — Implementer（写代码）
**Prompt：**

你是资深工程师。任务：[任务说明]
Context: [AGENTS.md 的链接]
规则：
- 改动保持最小。
- 不要重构无关代码。
- 改了行为要补测试。
- 最后给出 final report（概要、改动文件、测试结果、风险、未完成项）。
### Agent 2 — Reviewer（审代码）

**Prompt：**
你是代码 reviewer，对实现没有"情感"。
请审这份 diff：[贴 diff]
检查项：
- bug 与边界条件
- 缺失的测试
- 安全问题
- 是否有意外的行为变更
- 是否越过了约定的范围

输出：
- Critical issues（必须改）
- Minor issues（可选）
- 需要 flag 给人类的事项

不要改代码，只 flag 问题。