#0136 给 AI Agent 加一道人类闸门：确认卡片机制

type

Post

status

Published

date

Feb 28, 2026

slug

315a745569bb817b8774c3a245aa338a

summary

你有没有经历过这种场景：让 Agent 帮你重构一下代码结构，泡了杯咖啡回来，发现它改了 5 个文件、新建了 3 个定时任务、还把你的配置文件重写了一遍。你盯着屏幕想：这特么是我要的吗？

给 AI Agent 加一道人类闸门：确认卡片机制

你有没有经历过这种场景：

让 Agent 帮你重构一下代码结构，泡了杯咖啡回来，发现它改了 5 个文件、新建了 3 个定时任务、还把你的配置文件重写了一遍。你盯着屏幕想：这特么是我要的吗？

方向对了还好，万一方向偏了——回滚成本高得离谱。有些改动散落在十几个文件里，你根本不知道它动了什么。

这就是 AI Agent 系统最大的风险：不是"做不到"，而是"做太多"。

Agent 为什么会失控

三个原因：

改错方向。 你说"优化一下"，它理解成"重写"。你说"加个提醒"，它给你搞了一套完整的通知系统。Agent 的执行力太强，一旦理解偏了，它会沿着错误方向狂奔。

无法回滚。 改一个文件好说，git checkout 就完事了。但 Agent 经常是跨文件、跨模块地改，有些还涉及外部状态（比如创建了定时任务、写了数据库、调了 API）。这种改动你想回滚？祝你好运。

信息不对称。 你给了一句话需求，Agent 脑子里已经规划了 15 个步骤。你不知道它要干什么，它也不确定你到底要什么。双方都在猜——这种情况下放手让它干，纯赌博。

解决方案：确认卡片

思路很简单：在执行前，加一张确认卡片。

Agent 接到任务后，不直接动手。它先列出一张操作清单——我打算改哪些文件、新建什么、删除什么、大致思路是什么。

清单呈现给用户，附一个"开始"按钮。用户看完觉得没问题，点"开始"，Agent 才动手。不点？它就老老实实等着。

这张卡片就是一道闸门。Agent 有执行能力，但没有执行权力。权力在你手里。

完整工作流

把确认卡片嵌入到日常工作流里，大概是这样：

讨论 → 你和 Agent 对齐需求。做什么、不做什么、有什么约束。

蓝图 → Agent 输出整体方案。架构怎么分层、模块怎么划分、依赖关系是什么。

确认卡片 → 把方案浓缩成操作清单，展示给你确认。

拆模块 → 确认后，按优先级拆成独立可执行的小任务。

逐模块交付 → 每完成一个模块，你验收一下再继续。不是一口气全干完。

关键在于"逐模块"。就算确认卡片通过了，也不要让 Agent 一股脑把所有事做完。分步交付，每一步都有检查点。这样万一中途发现方向不对，损失可控。

什么时候用，什么时候不用

要用：

涉及多个文件的改动

架构层面的变更

新建模块或重构现有模块

任何不可逆的操作（删除、发布、调用外部 API）

不用：

简单问答："这段代码什么意思？"

单文件小修：改个变量名、修个 typo

日常记录：记个账、打个卡

判断标准就一个：这事干错了，回滚成本高不高？ 高就用确认卡片，低就直接干。

核心原则

说到底就一句话：

Agent 有能力，但没有权力。权力永远在人手里。

AI Agent 的执行力会越来越强。能写代码、能改配置、能调 API、能操作数据库。但执行力强不代表应该放任它干。

确认卡片不是在限制 Agent 的能力，而是在建立人和 Agent 之间的信任机制。你看到它的计划、确认它的方向、然后授权它执行。这个过程让你始终保持对系统的掌控。

很多人追求"全自动化"——设个目标，Agent 自己搞定一切。听起来很酷，但现阶段这是灾难的起点。Agent 还没聪明到可以完全信任的程度，而你也没笨到完全放手的地步。

加一道闸门，不是因为不信任 AI，而是因为你对自己的系统负责。