与 AI Agent 协作的五条经验

你以为在用工具，其实在管人

周一早上九点，三个 deadline 压在桌上，两个 bug 还没定位，十一点的会又不能推。

你打开 Codex，甩给 Agent 一句「把这个功能做完」，然后去冲咖啡。回来时 diff 已经生成好了，格式漂亮，注释齐全，测试也加上了。你差点直接 merge——直到同事问了一句：「这个 API 响应结构，谁批准的？」

你才发现 Agent 顺手改了一个公开接口，前端、移动端、外部调用方，全可能跟着炸。

这不是模型不行。是你还在「用工具」，而它已经在「替你决策」了。

一

从「用 AI」到「管 AI」，只差一个认知切换

最近 PMI 发布了 AI 项目管理标准，方向是对的。但大多数官方文档回答的是宏观框架，没回答那个周一早上真正折磨人的问题：

有 deadline、有 bug、有会议的时候，我该怎么跟 Agent 协作？

我几乎每天都在用 Agent 写代码、审代码、查 bug、写文档。踩过的坑很具体：prompt 写得太烂、输出信得太快、错误方向放得太久。从这些失误里，我总结出五条转变——都不复杂，但每一条都改了一点协作方式。

核心认知只有一句：

你下达指令、检查输出、修正方向、决定能不能推进——这本质上就是管理。

二

布置任务之前，先划定边界

我对 Agent 的第一反应，和带新人一样：「任务在这，去做完。」

结果有一次，Agent 做了一个当时看起来很合理的架构决定，等我反应过来，已经很难撤销了。问题不在 Agent，在我——从没告诉它，哪些决定可以自己拍板，哪些必须等我点头。

现在我会在任务清单之前，先写一份决策边界。可以是一份 decision-boundaries.yml，也可以是一段写进项目规则的说明。关键是三类清单：

以前我是在「派活」；现在是在「划定决策空间」。Agent 仍然可以快，但它知道路在哪里结束。真正该告诉 AI 的，不只是该做什么，更是不该往哪里走。

三

学会「冷审」——不看过程，只看结果

审查同事的工作时，你通常知道讨论过程、知道某步为什么这么做。看到产出「看起来没问题」，大多数时候可以信。

Agent 不一样。它给你一份干净的 diff、一份成稿文档，背后的推理过程你根本没看见。输出可以很整洁，解释可以很自信，逻辑却可能是错的。

所以我改用冷审（cold review）：不假设过程正确，只检查最终产出。五个问题：

1. 真的解决了最初的问题吗？
2. 有没有动不该动的东西？
3. 会不会搞坏系统其他部分？
4. 逻辑对不对，还是只是「看起来像对」？
5. 有测试或证据证明能跑吗？

当 Agent 的工作时长超过你的注意力跨度，你不可能盯着每一步。新技能不是「会用 AI」，而是不因输出好看就盲信。

四

规划能力，而不只是规划人头

以前排项目，我问的是：「这事要几个开发者？」

现在我会问：「完成这件事，需要什么能力组合？」

因为活不只能人干。Agent 适合写代码、生成文档、找 bug、探索方案；产品方向、架构选择、安全决策、最终拍板，必须留给人。

排期时我会画四格：

目标不是用 Agent 替代人，而是让人和 Agent 各有清晰角色。这个时代，人最有价值的技能不只是执行，而是判断——知道委派什么、审查什么、保护什么、何时喊停。

五

在起火之前设警报，别等站会才知道

团队站会有个毛病：通常是出事之后才告诉你。

Agent 更快。它可以在错误方向上连改二十个文件，悄悄碰了 .env、动了支付模块、改了你没注意的数据库迁移——等你 review，损失已经发生了。

所以我加了一层触发线（tripwire）。思路很简单：某件事越过安全线，立刻停、立刻通知。

几条我常用的：

• 涉及文件的测试通过率低于 100% → 暂停
• 单个任务改动超过 20 个文件 → 审查范围
• 碰到 .env、auth/、payments/、迁移目录 → 必须批准
• 公开 API 结构变了 → 必须批准
• 产生任何费用 → 必须批准
• Agent 对需求不确定 → 停止，别猜

目标不是阻止 Agent 干活，是在它制造更大麻烦之前拦住它。最好的审查，有时不是任务结束时的 review，而是进行中的警报。

六

拥有系统，而不只是拥有产出

以前「负责」很简单：代码是我的，文档是我的，结果是我的。

Agent 时代，负责的层次变了。你不只拥有交付物，还拥有制造交付物的系统——人、Agent、prompt、审查流程、边界规则、安全检查、最终决策，全算在内。

当 Agent 写了那段代码，你不能说「是 AI 做的」。产出仍是你的责任。但你的工作从「亲手做每一块」，变成「设计一个能反复产出好成果的工作流」。

我会定期问自己五个问题：

1. Agent 拿到足够上下文了吗？
2. 边界清楚吗？
3. 有审查环节吗？
4. 高风险区域被保护了吗？
5. 最终产出真的解决了实际问题吗？

交付一个成果有用；能持续交付好成果的系统，才是规模化的起点。这是 AI 给我们的「晋升」：从亲手做每一项任务，到拥有让工作完成的系统。

七

这不是更大的活，是不同层次的活

五条说起来都不难。难的是从「偶尔用一下」变成「默认就这么协作」。

你可以做个简单自评：每条打 1 到 5 分。1 分是「基本没在做」，5 分是「已经是工作流的一部分」。得分最低的两项，就是这个季度最该改的行为——不必一次全改，先动一个小习惯。

对我来说，第一个大转变是先划边界再派任务；我还在练的，是不因输出干净就放松审查。

真正的学习曲线，不是学会每一个新 AI 工具，而是学会以安全、清晰、真正有用的方式与 AI 协作。

留给你的一个问题

这五条转变里，你已经在做哪些，还在回避哪一条？

如果只能先改一条，你会从哪条开始？

下一篇，我想把「冷审」的五问清单拆成可以直接贴进 PR 的 review checklist。如果你更想先看那份清单，留言告诉我。

想要今天文里提到的两份 YAML 配置？decision-boundaries.yml（决策边界）和 tripwires.yml（触发线警报），后台回复「边界」或「触发线」，我把对应完整模板发你。也可以留言你正在用的 Agent 工具（Cursor、Claude Code、Copilot 等），我按你的场景改一版最小可用配置。

说明：本文核心观点整理自日常 Agent 协作实践，并参考了相关工程管理经验。AI 工具与工作流变化很快，请结合自己的项目、团队场景自行调整。