前言

你有没有过这种经历？

早上刚跟 AI 说好，“这个函数只改返回值类型，别的别动”。下午回来一看，好家伙，它把整个文件都重写了，还顺手删了你半个组件。

你问它为什么，它还特别真诚：“我觉得这样更优雅哦。”

优雅是挺优雅的，就是项目跑不起来了。

这不是你运气差，也不是你遇到了叛逆期的 AI。这玩意儿天生就是这样干活的。今天这篇东西，不讲玄学，只讲实战——为什么它总给你搞事情，怎么把任务说清楚，怎么用配置和流程让它变得稳定靠谱。

第一部分：先搞懂你对面坐的是个什么东西

1. 为什么这玩意儿就不能好好干活？

用 AI agent 干活，你会发现它有三个经典毛病，比你家猫拆家还稳定。

1.1 一本正经地胡说八道

行话叫"幻觉"，说白了就是瞎编。

它能给你编一个根本不存在的 API，语气还特别坚定，就好像这个 API 是它昨天刚写的一样。你照着它的代码抄，跑不起来，回头质问它，它还会跟你道歉：“哎呀不好意思，我记错了，应该是另一个。”

另一个也不存在。

这就好比你问一个路痴朋友"XX 大楼在哪"，他特别自信地给你指了个方向，你打车过去，发现是个公共厕所。他还觉得自己没错，只是"可能记错了"。

1.2 你让它往东，它把整个小区都拆了

行话叫"遵从性差"。

你说"只改这一个函数"，它顺手把旁边三个文件也"优化"了。你说"不要加注释"，它每行都给你注释上，还注释得特别认真，生怕你看不懂。

你说"预算 5000"，它给你搞了个 50000 的方案，还跟你说"我给您升级了，物超所值"。

这就像你去理发店说"修一下就好"，托尼老师给你剪了个全新的发型，还问你"满意吗"。你能说什么呢？头发已经短了。

1.3 聊着聊着就变笨了

行话叫"长对话退化"。

早上刚聊的时候，它聪明伶俐，反应飞快，你说上句它就知道下句。聊到下午，它连早上定好的规矩都忘了，你跟它说"我们不是说好不用这个库吗"，它回你：“哦，是吗？那我改回来吧。”

改回来就改回来吧，它还把别的东西也改错了。

这就跟你跟同事开长会一个道理。前半小时大家都精神抖擞，两小时后所有人都开始放空，领导问"刚才说的那个方案谁来做"，全场沉默。AI 也一样，聊久了它也"累"。

1.4 它到底是怎么干活的？

说穿了，大模型就是个超级接话机器。

它读了几乎整个互联网的文本，然后学会了一件事：你前面说了一堆话，它猜下一个词最可能是什么。

注意，是"猜"，不是"想"。它并不真正理解你在说什么，它只是根据上下文，计算出下一个最有可能出现的词，然后写出来。写完一个，再把这个词加进去，继续猜下一个。循环往复，直到生成完一整段话。

所以你以为它在"思考"，其实它在"接龙"。

这就解释了为什么它有时候特别聪明，有时候又特别蠢——因为接龙接得好的时候，看起来就像真懂了；接错的时候，你就觉得这怕不是个傻子。

还有个关键概念叫"上下文窗口"。你可以把它想象成模型的书桌。桌面上能摊开的资料就那么多，塞满了就放不下新的。

而且桌上东西越乱，它越找不到重点。这一点跟我们人类一模一样——你书桌上堆了二十本书的时候，你也找不到你要的那本。

2. 它能干什么，不能干什么

用久了你就会发现，这玩意儿是偏科生。有些事情它干得特别好，有些事情它干得特别烂，比高中时候的你还偏科。

2.1 它擅长的：语感型任务

写代码、改代码、解释代码——互联网上这类样本最多，它"语感"最好。就像一个人读了一百万本小说，你让他写一篇同风格的文章，他写得有模有样。

模式化的工作：写单元测试、补类型、调格式、写文档。这些活它干得又快又好，因为套路都是一样的，它见多了。

知识密集的问答："这个报错一般是什么原因？"这种问题它答得往往不错，因为网上的报错文章它都读过。

2.2 它不擅长的：精确型任务

精确计算。你让它算个大数乘法，它靠"语感"给你猜一个答案，错得还挺自信。这就像让一个语文课代表去做数学题，他能给你写出一篇作文，但答案是错的。

数字符数、排序去重这类"笨功夫"。它经常数错。你让它数一段文本有多少个字，它给你报的数字永远跟真实数字差那么几个。你以为它偷懒，其实它真的数不准——因为它不是在数，是在猜"这种长度的文本大概有多少字"。

实时信息。它的知识停在训练截止那天，你问它今天的新闻，它不知道。就像你问一个闭关修炼了三年刚出来的人"最近发生了什么"，他一脸懵。

超长逻辑链。一步错，步步错。前面有一步理解偏了，后面全跟着偏，而且偏得越来越离谱。这就跟传话游戏一样，第一个人说"今天买了一斤苹果"，传到第十个人变成了"明天去火星旅游"。

第二部分：怎么把任务说清楚

3. 下任务这事儿，真不是你想的那么简单

很多人抱怨 AI 听不懂人话，但你仔细想想，你自己说清楚了吗？

就像你遇到一个不靠谱的领导，下任务的时候只说了个大概，“小王啊，你把那个页面搞一下”。等你搞完了，他又说"我要的不是这个效果"。你心里是不是特别想骂街？

AI 也一样。你没说清楚目标、要求、边界，它怎么知道你到底要什么？它又不能读心。

3.1 目标、约束、验收标准，一个都不能少

给 AI 下任务，跟给装修队下单是一个道理。你说"帮我把客厅弄一下"，装修队八成装不出你想要的样子。

一张靠谱的需求单要有三样东西：

目标：干什么。比如"把客厅刷成暖白色"。

约束：什么不能碰。比如"预算 5000，不要动吊顶，家具不用搬"。

验收标准：做到什么程度算完。比如"墙面无色差，踢脚线恢复原位"。

给 AI 下任务也是这个套路。你看看下面的对比：

差："优化一下这个页面" 好："这个页面首屏加载要压到 2 秒内（目标）。 不要改接口协议，不要引入新的大型依赖（约束）。 用 Lighthouse 跑分，Performance 不低于 90， 且现有测试全部通过（验收标准）。"

你说"优化一下"，它给你优化成什么样全凭它心情。你把标准说死了，它就只能在你画的圈子里转。

这就像你去吃饭，你说"随便来点好吃的"，厨师给你上什么你都得接着。你说"我要一份微辣的牛肉面，不要香菜，多加牛肉"，厨师就知道该怎么做了。

3.2 别一上来就甩个大任务给它

新人最容易犯的错：一上来就把巨型需求甩给 AI——“帮我把这个项目从 Vue 2 迁移到 Vue 3”。

这就像你让装修队"三个月后交房时再看"。等他装完了，你一看，好家伙，墙砌错了，水电全改了，你后悔都来不及。

大任务里任何一步理解偏了，后面的步骤都会跟着偏，最后整体跑偏。就跟你走错了第一步一样，后面越走越远，最后你发现自己走到隔壁小区去了。

正确做法是小步走：

第 1 步：先迁移构建配置，跑通 第 2 步：迁移一个最简单的页面，验证模式 第 3 步：总结成迁移规范，写进 AGENTS.md 第 4 步：按规范批量迁移，每批跑一次测试

每一步都有验证，有验证就有退路。宁可慢，不可失控。

这话听着像鸡汤，但真的是血泪经验。你以为你在提速，其实你在给自己挖坑。坑挖深了，你自己都爬不上来。

3.3 大任务怎么拆？三个切法

按模块拆。登录、订单、支付分开做，互不干扰。一个模块搞砸了，不会连累别的模块。

按层次拆。先数据层、再服务层、再 UI 层。从下往上搭，一层一层来，别跳步。

按风险拆。最没把握的部分先做小实验探路，确认可行了再铺开。就像你过河，先伸一只脚试试水深，别直接跳进去。

拆分标准就一条：每一小步做完，你都能在几分钟内判断对不对。判断不了，说明步子还是太大了。

你想想，是不是经常遇到这种情况——AI 说"我做完了"，你一看代码，完全不知道它做的对不对，因为它一口气干了太多事。这就是步子迈太大了，容易扯着蛋。

3.4 三个好用的招

Plan 模式——先计划再动手。

就是让它先只读代码，不出手改，先给你列一份计划：改哪些文件、分几步、每步怎么验证。你批准了它才开始动手。

这招拦住的是什么？是"边想边做"式的跑偏。方向错了，在计划阶段就能拦下——改计划比改代码便宜两个数量级。

就像你出差，先看一眼地图确认方向，再出发。而不是闭着眼走，走了两小时发现方向反了。

审批计划的时候重点看两样：打算动哪些文件、每步怎么验证。这两样对了，执行阶段基本稳。

grill-me——让它反过来盘问你。

任务描述最常见的漏洞，不是你写错了，而是你脑子里的信息没全写出来。你以为的常识，它不知道。

补这个缺口最快的办法，是让它开工前主动盘问你：

"开工前，把你需要确认的问题一次问完。 每个问题附 2-3 个候选答案和你的倾向，我来挑。"

注意，让它出选择题，不要出问答题。开放问题你得从零想，选择题你只负责挑，快一个量级。

这招还有个意外收获：你自己也没完全想清楚的任务，它问着问着，你把需求理清了。相当于免费做了一次需求咨询。

就像你去理发店，托尼老师问你"要怎么剪"，你本来没想好，他一问"剪短一点还是保持长度"，你突然就知道自己要什么了。

多方案对比——别让它给你一个方案就完事。

你让它出方案，它端上来的第一个方案，是它语感最顺的惯性路径。你一点头，就被它锚定了，后面再改都是在它那个方案底下修修补补。

差："给我一个迁移方案" 好："给我 2-3 个可行方案，各列优缺点、工作量和风险， 最后附你的推荐和理由。"

强制对比会逼它把搜索范围放宽。更重要的是，选方向的决定权回到了你手里。三个方案里，经常藏着比默认答案好得多的选项。

这就像你买手机，销售直接给你推荐一款，你可能就买了。但你说"给我对比三款"，你才发现原来有更好的选择。

三招各管一个失效环节：Plan 模式拦跑偏，grill-me 堵信息缺口，多方案防锚定。它们不冲突，复杂任务的完整流程，往往是先进 Plan 模式，在里面用 grill-me 把问题问清、用多方案对比选定方向，最后审批计划开工。

第三部分：用配置换稳定性

4. 一个文件解决"每次开会都要重新自我介绍"

4.1 AGENTS.md 是什么

还记得那个最烦人的痛点吗？每次新会话，AI 都失忆了。

技术栈是什么、用什么命令跑测试、代码规范是什么——每开一个新窗口，你都要重新交代一遍。光"热身"就要几分钟，比你早上到公司开电脑还慢。

AGENTS.md 就是解药。一个放在项目根目录的 Markdown 文件，AI 每次启动都会自动读它。

它最早是 OpenAI 的 Codex CLI 搞出来的，因为太实用了，各家编程 AI 纷纷跟上，现在基本成了事实标准。就像当年的 USB 接口，大家都觉得好用，就都支持了。

4.2 为什么这玩意儿能提高稳定性

机制很简单：AI 每次启动，AGENTS.md 的内容会被自动注入上下文，而且通常是优先级最高的位置。就像把最重要的东西永远摆在书桌最显眼的地方。

这正好解决两个根子问题：

第一，对抗失忆。跨会话的约定有了持久载体，不用每次重复交代。就像你给新员工写了份入职手册，不用每天早上跟他说一遍"我们公司用 pnpm 不是 npm"。

第二，对抗跑偏。规范以书面形式存在，遵从度比口头约束高得多。"项目用 pnpm"写在手册里，比你在对话里说十遍都管用。

这话真的不夸张。你在对话里说"我们不用这个库"，聊了几轮之后它可能就忘了。但写在 AGENTS.md 里，它每次启动都会看到，就不敢随便乱来了。

4.3 怎么写出一个好的 AGENTS.md

核心原则：当成写给新实习生的入职手册来写。

要短。没人会认真看 100 页的手册。控制在 100 行以内，重要的事放前面。模型对开头和结尾的内容更敏感，中间的容易被忽略——这一点跟人一模一样，你看书也是开头认真看，中间就开始跳了。

只写"它自己发现不了"的信息。"代码要写好"这种废话不要写。"测试用 vitest 不用 jest，因为历史原因"这种才值得写。

多用"不要"。约束比期望好用。“不要动 legacy/ 目录”、“不要自行升级依赖”，防跑偏效果立竿见影。

包含命令。怎么构建、怎么跑测试、怎么 lint——给它命令，它就能自己验证。

一个实用的骨架长这样：

# AGENTS.md ## 1. 项目概述 一段话说清楚：项目是什么、技术栈、仓库结构。 前 10 行必须让 AI 建立项目心智模型。 ## 2. 快速命令 构建、启动、格式化、质量检查的命令速查表。 环境变量配置说明（env 文件位置、启动脚本自动 source）。 ## 3. 后端架构 包结构树（ASCII）+ 每个包的用途注释。 核心子系统的简要说明 + 详细文档链接。 前后端术语映射（如有差异）。 ## 4. 前端架构 技术栈、路由方案、API 层约定、组件库规范。 详细文档链接。 ## 5. 关键约定 5-10 条硬性编码规则（违反会直接导致问题的）。 每条规则附详细文档链接。 ## 6. 本地开发及验证流程 「改 → 构建 → 启动 → 验证」的完整闭环。 curl 验证模板、Token 获取、日志路径。 ## 7. 质量检查 lint、format、build、test 命令矩阵。 ## 8. 参考项目约定 参考项目列表 + 优先级规则。 ## 9. 文档导航 所有详细文档的索引表。

最后一条最容易被忽视：AGENTS.md 是活文档。每次 AI 犯错、你纠正了它，就想想"这个教训要不要写进手册"。

踩一个坑，补一条。手册越写越厚，AI 越用越稳。

这就跟你养孩子一样——每次他犯了错，你就教他一次，下次他就不会再犯了。AI 也一样，它不记仇，但它记手册。

5. Skills 是什么？给 AI 装个"技能包"

5.1 AGENTS.md 管"永远要知道的"，Skills 管"特定任务的标准流程"

Skill 就是给 AI 编程助手"加装"的能力包。本质上，它是一种结构化的提示词工程——把分散在你脑子里的领域知识、操作流程和最佳实践，转化成 AI 能理解、能执行的指令集。

物理上看，它就是一个文件夹，里面放一个 SKILL.md 文件，再加上一些可选的脚本和参考资料。

核心是三样东西：指令（告诉 AI 该怎么干活，按什么步骤来）、上下文（告诉 AI 项目背景、团队规范这些它不可能凭空知道的东西）、工具（一些辅助脚本、配置模板，AI 可以直接拿来用）。

机制上有个精巧的设计叫"渐进式披露"。AI 平时只看到每个 Skill 的"目录页"——名称加简介，用到哪个才翻开哪本。

就像工具挂在墙上，一眼扫过去知道有什么，用的时候才取下来，不会把工作台堆满。还记得书桌比喻吗？桌子就那么大，别什么都往上堆。

Skills 能干什么？

固化复杂流程。比如"发布版本"要跑十几个步骤，写成 Skill，以后一句话触发。不用每次都从头跟 AI 说一遍"先跑这个再跑那个然后检查那个"。

沉淀领域知识。比如"我们公司的 API 错误码规范"，写成 Skill 随取随用。不用每次都把规范重新贴一遍。

跨会话记忆。社区里流行的 memory-bank 类 Skill，把重要信息分类存档、按需加载。相当于给"金鱼记忆"的 AI 装了一块硬盘——会话关了，记忆还在。

5.2 怎么写好一个 Skill

一个 Skill 只干一件事。"发布流程"和"代码规范"分成两个，不要揉在一起。揉在一起的结果就是两个都干不好，就像你同时学吉他和钢琴，最后哪个都半吊子。

触发描述写清楚。Skill 的描述决定了它什么时候被使用，描述含糊，该用的时候它想不起来。就像你给文件命名"新建文档最终版真的最终版"，过两天你自己都忘了里面是啥。

步骤可执行。写成"先跑 X 命令，检查 Y 输出，再做 Z"，而不是"认真仔细地处理好发布"。后者等于没说——"认真仔细"这四个字，在任何说明书里都是废话。

让流程自验证。步骤里嵌入检查点，跑测试、看输出，AI 自己就能发现偏差。不用你盯着，它自己就知道哪里不对。

判断一个 Skill 写得好不好，就问一个问题：新来的同事拿着这份 SOP，能不能不问任何人就把事办了？

能，就是好 Skill。不能，就继续改。

6. 工具和 MCP：给 AI 装上手脚

6.1 没有工具的 AI 只是个文字处理器

没有工具的大模型，本质上就是个高级文本框。你问它什么，它打字回答你，仅此而已。

有了工具，它才真正长出了手脚：能读写文件、执行命令、搜索代码，成了我们说的"Agent"。

工具调用的流程是这样的：AI 分析任务，决定用哪个工具，传参调用，拿到结果，再决定下一步。一轮干不完就多轮循环，看起来就有了"自主干活"的样子。

这套东西你基本不用操心。主流的编程 AI 出厂就内置了读写文件、搜索代码、执行命令、抓取网页——开箱即用。你平时看到的"打开文件看了看"、“跑了一遍测试”，背后就是一次次工具调用，只是你完全无感。

就像你走路的时候，不会想到自己在"调用腿部肌肉"。你只是在走，肌肉自己会动。

真正需要你主动出手装工具的只有一种情况：内置工具够不着的外部世界——数据库、浏览器、公司内部系统。

6.2 MCP：工具界的 USB 接口

工具虽好，但早期各家 AI 接工具的方式互不兼容。同一个功能，你要为每个平台各写一遍。就像当年手机充电器，苹果一个口，安卓一个口，诺基亚一个口，出门带三个充电器。

MCP 就是为解决这个问题的开放协议——像 USB 接口一样，定义了工具和 AI 之间的标准插口。

实际使用不需要深入协议细节，记住三点就行：

现成的 MCP server 开箱即用。文件系统、Git、数据库查询、浏览器操作、文档检索……一大堆，直接用。

配置一次，所有支持 MCP 的 AI 都能用。就像 USB 鼠标，插哪个电脑都能用。

可以为团队内部系统写一个 MCP server，让 AI 直连内部工具。比如你公司的审批系统、知识库，都可以接进去。

第四部分：构建可靠的工作流

7. 凡是能写脚本的，就别让它"用脑子"

7.1 确定性的事，交给确定性的东西

记住这个原则：凡是能写脚本的，就不要让模型"用脑子"做。

模型是"语感型选手"，让它做精确计算，经常出问题。常见踩雷场景：

让模型"数一下有多少条记录"、“算个汇总”——数字经常是错的。你以为它在数，其实它在猜"这种数据集大概有多少条"。

让模型"按这个规则重新排序这两千行"——总有几行排错。两千行它还能勉强记着，两万行它就开始自由发挥了。

让模型"按模板批量改 50 个文件"——改到第 30 个开始自由发挥。前 30 个规规矩矩，后 20 个就开始"我觉得这样更好"了。

正确姿势是让它当"指挥"，脚本当"乐器"：

差：帮我把 data.json 里的记录按时间排序，并统计总数 好：写一个脚本，把 data.json 里的记录按时间排序并统计总数，然后运行它

后者模型写脚本（它擅长），脚本做计算（脚本擅长）。各干各的擅长事，结果就是确定的。

这就像让一个文案去算账，她能给你算出一篇散文；但让她写个 Excel 公式，公式自己算得清清楚楚。

7.2 什么时候该脚本化？

识别标准：同一套规则要重复应用到大量数据上的，都该脚本化。排序、统计、批量重命名、格式转换、批量文件修改……

符合以下几个标准中的一条或者几条，就该考虑脚本化：

数据量大。条目一多，模型的"数感"就撑不住。它不是在数数，是在猜下一个词。

规则清晰。“按创建时间倒序”、“重复的只留一条”，一句话没有歧义。

准确性要求高。错一条就脏数据、要返工的活，别赌它的语感。

重复性高。今天干完，下周还会再干的活。一次性的小事可以偷懒，但要跑第二次的，就值得花三分钟让 AI 写个脚本。

四个信号背后是同一条分工原则：规则明确的交给脚本，需要理解和判断的留给模型。

"把这两千行按时间排序"是前者；"把这段文案改得亲切一点"是后者——后者没有规则可写，硬要脚本化只会得到僵硬的结果。

脚本化的好处也不止"准确性"：

可复现。脚本跑一万遍结果都一样——相当于把模型手里的骰子换成齿轮，确定性不再看运气。

可审计。让脚本自己输出统计——“处理 2000 条，成功 1998，跳过 2”——比让模型口头汇报靠谱。它汇报的数字同样可能是编的。

可沉淀。脚本进了 repo 就是资产，下次一句话重跑。和 AGENTS.md 一个思路：把"怎么做"沉淀成文件，而不是每次重新交代。

省上下文。让模型逐条处理 2000 行，上下文长度大，消耗的 token 也多。使用脚本则只用很少的 token，甚至可以不用 token。

8. 上下文管理：你的书桌就这么大

8.1 token 与上下文窗口

上下文，就是 AI 在回答你这一刻，手边能看到、能拿来参考的信息。

你可以把它想象成一张工作桌。你刚刚问的问题，是桌上的任务单；你上传的文件，是参考资料；前面确认过的要求和结论，也是桌上放着的纸张。

AI 每次回答问题，都会根据这些信息判断你现在想做什么、前面聊到了哪里、接下来该怎么回答。

模型的书桌是有限的。这就是为什么"把整个项目都喂给它"行不通——桌子就这么大，全堆上去，重要的东西反而被挤到角落了。

8.2 上下文污染：不是塞得越多越好

新手常犯的另一个错：把能找到的资料全部贴给模型，心想"信息越全越好"。

恰恰相反。无关信息会污染上下文。

就像你正专心写代码，旁边同事一直聊昨晚的球赛。球赛本身没错，但它占用了你的注意力。模型也一样，桌上的垃圾越多，它越容易"接错话"：把废弃代码当有效约束、把旧方案当新需求。

实践建议：给文件要给相关的，别"以防万一"地多给；贴日志要贴报错那段，别贴全量日志。

你想想，你自己工作的时候，是不是也不喜欢桌面上堆一堆乱七八糟的东西？AI 跟你一样，桌子越干净，干活越利索。

8.3 长对话退化：该开新会话时就开

一个会话聊得越久，桌上的东西越多，早期的重要约定就越容易被挤模糊。

你一定体会过：下午的 AI 明显比上午的"笨"。

怎么办？

一个会话干一件事，干完就换新会话。别恋战。

发现 AI 开始"忘事"、答非所问，果断开新窗口。就像你跟同事聊天聊跑题了，不如重新开个头。

重要的结论——决策、规范、踩过的坑——及时沉淀到 AGENTS.md，别指望它"记住"。它记不住的，你自己也记不住，写下来才是真的。

9. 善用子 agent：把脏活累活外包出去

9.1 上下文无关的任务，扔给子 agent

主会话的上下文是宝贵资源。有些活儿很占桌面，但产出其实很小：

“在整个代码库里调研支付模块的现状”——要读几十个文件，结论就几行。

“审一遍这次改动有没有安全问题”——要翻大量代码，结论是"有/没有"。

这类任务用子 agent：主 AI 派一个分身去干，分身自己开一张新书桌，读它需要读的一切，干完后只把结论交回来，中间过程一概不占主会话的桌面。

就像项目经理把调研外包给顾问：顾问回去翻了三天资料，最后交回一页纸报告。你不用陪他翻资料，你的会议室保持清爽。

9.2 什么适合，什么不适合

适合交给子 agent 的：

调研类。代码库摸底、方案调研、日志排查。

审查类。代码 review、安全扫描。

并行任务。互不依赖的几个模块，派多个子 agent 同时干。

不适合的：

强依赖主对话上下文的任务。子 agent 看不到你们的聊天记录，所有背景要在任务里重新交代。

需要反复来回讨论的任务。每次来回都要重新描述背景，得不偿失。

一句话：子 agent 换来主上下文的清爽，代价是背景信息要重新交代。

信息密度低、过程重的活儿，这笔交易就划算。就像你请搬家公司，你不用自己动手搬，但你得告诉他们搬什么、搬到哪——这点信息成本，换来了你不用累个半死。

10. 验证闭环：别信它说的，看证据

10.1 让 agent 自验证

AI 说"已完成"，只是它的主观感受，不是事实。

就像你家孩子跟你说"我作业写完了"，你信吗？你得检查一下。

规则很简单：能在机器上验证的，就不要用眼睛验证。

让它改完代码跑测试：“改完后运行测试，贴出结果”。

让它修完 Bug 编译一遍：“确认编译通过再交给我”。

有 lint 就让它 lint，有类型检查就让它跑类型检查。

把验收标准直接写进任务里，AI 会自己闭环。你的 review 从"检查对不对"变成"抽查它有没有骗我"，工作量骤降。

10.2 人工检查点：有些门必须你来开

分级设卡，危险操作必须人工确认：

高危：删文件、改数据库、发布上线、git push、花钱的 API 调用——必须人工点头。

中危：批量修改、依赖变更——AI 做完后人工过目。

低危：单文件小改、注释文档——抽查即可。

大多数编程 AI 支持权限配置，把这些门槛设成默认，既安全又不啰嗦。

原则就一条：事故的代价越高，检查点越靠前。

你想想，删错一个文件和改错一个注释，哪个后果严重？肯定是删文件。所以删文件必须你点头，改注释可以让它自由发挥。

这就像开车，刹车要自己踩，导航可以听机器的。但真到了十字路口，方向盘得在你手里。

最后说两句

用 AI agent 干活，本质上不是"让 AI 替你写代码"，而是"你指挥 AI 干活"。

指挥得好，它就是你的得力助手，一个顶仨。指挥得不好，它就是那个帮倒忙的实习生，你还得给他擦屁股。

今天说的这些，没有什么高深理论，都是实战里踩坑踩出来的经验。你不用全记住，先挑一两个用起来，用顺手了再慢慢加。

毕竟，驯这玩意儿跟养猫差不多——你得先搞懂它的脾气，才能让它乖乖听话。

P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，传送门https://blog.csdn.net/qq_74013365