AI 编程代理的五问预检框架：风险识别与验证

我在使用 AI 编码 Agent 时，反复遇到一个规律：真正危险的通常不是 Agent，而是缺失的前置检查。

在让 Agent 接触真实代码库之前，我会先尝试回答五个问题：

最小且可逆的改动是什么？

哪些文件禁止修改？

用什么命令可以证明这次改动没有破坏产品？

Agent 在声称“完成”之前，应该收集哪些证据？

如果结果看起来合理、实际上却是错的，回滚方案是什么？

例如，与其要求 Agent“添加计费功能”，我会把任务拆分为：

• 检查现有支付流程，并总结其中的假设；

• 先添加一个范围明确的测试或 fixture；

• 在功能开关后实现一条路径；

• 运行与改动最相关、范围最小的测试或构建；

• 报告具体修改了哪些文件、运行了哪些命令，以及还存在哪些不确定性。

一个很实用的习惯是：把 Agent 的工作当成一位效率极高的初级队友提交的 pull request。明确边界，要求提供证据，并审查 diff，而不是相信它表现出来的自信。

我常用的一个简单模板：

Goal:
Non-goals:
Allowed files:
Risky areas:
Validation command:
Rollback:
What to report if blocked:

这会让前期多花几分钟，但能避免以后耗费大量时间去调试那些看似自信、实则只对了一半的改动。

很好奇大家是如何处理的：在 Agent 辅助编码之前，你会使用一份正式的前置检查清单，还是会根据具体任务采用更轻量的方式？

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。

这里是一个让程序员分享知识、了解最新动态并推动职业成长的社区。