把 AI 当成刚加入项目的同事：交代目标、上下文、范围和验收方式，先让它读和计划，再动手，最后看证据。
- 学习结果
- 能写出一份完整的任务委托，为项目准备一份给 AI 看的说明文件，并用实际运行的证据验收 AI 的工作。
- 时长
- 60 分钟
- 难度
- 效率提升
- 核验
- 未核验
正文
和 AI 协作效果不好，常见的原因不是模型不够聪明，而是我们交代得不够清楚。“帮我把网站改好看一点”“这个功能有 bug，修一下”，这样的要求交给一个刚入职的同事，他也会一头雾水。
一个有用的思路是：把 AI 当成一个能力很强、但刚刚加入你项目的同事。他会写代码，但不知道你的项目背景，不知道哪些东西不能动，也不知道你说的“好”是什么标准。你要交代的，就是一个新同事需要知道的那些事。
一次好的委托包含五样东西
- 目标：要达到什么结果，最好从用户角度描述。不是“改一下筛选组件”，而是“让读者能按分类筛选项目，并打开详情”。
- 上下文：相关的文件在哪里、现在是什么表现、有什么数据样例、怎样复现问题。
- 范围和约束：可以改什么，不能改什么。比如网址结构、数据格式和接口不能变。
- 验收标准：怎样算完成，越具体越好。比如“按分类筛选后，列表只显示该分类；手机上没有横向滚动；没有结果时显示提示”。
- 输出要求：你希望它最后交给你什么，比如改动说明、执行过的检查和结果。
缺了约束，AI 很容易把一个局部改动扩大成整个模块的重写；缺了验收标准，它说“完成了”的时候，你也没法判断是不是真的完成。
上下文：给对的，而不是给全部
上下文要能追溯到当前真实的代码。指出相关的目录、组件和数据样例，给出复现步骤。不要把整个项目粘贴进去，更不要贴带密钥的配置文件。
旧截图、旧日志和以前某次构建成功的记录，都不能证明当前版本是好的。让 AI 先读一读受影响的文件，再开始讨论方案。
对于每次都要交代的信息，比如项目结构、常用命令、代码风格、哪些目录不能动，可以写进一份项目说明文件。越来越多的 AI 编程工具会自动读取项目根目录下的说明文件，比如 AGENTS.md 这个开放约定，就被描述为“给 AI 编程助手看的 README”。
图：AGENTS.md 官网首页截图，截取于 2026-10-24，内容以官方当前页面为准。
不同工具读取的文件名可能不同，以你所用工具的文档为准。内容保持简短具体：怎样安装依赖、运行和测试，有哪些约定，哪些地方不要改。
先读和计划，再动手
对于稍微复杂一点的任务，不要一上来就让 AI 写代码。先让它读相关的文件，说明打算改哪些地方、为什么、有什么风险，你确认之后再动手。
这一步花几分钟，却能拦下很多问题：它可能误解了你的需求，可能打算改一个不该动的文件，也可能发现了你没想到的影响。
拆成可以独立验收的小任务
一次只做一件可以单独验收的事。“改筛选交互”“改接口”“修手机布局”分三次做，比一次同时改页面、认证和数据库容易审查得多。
但拆分要按完整的行为来，不能把一条链路截成半截。比如“提交表单”这个功能，前端按钮和后端保存要在同一个任务里完成，不能为了任务小而留下一个点了没反应的按钮。
读取不等于授权
让 AI 阅读代码、制定计划，不等于授权它发布上线、真实付款或删除数据。给工具配置权限时，按最小必要的原则来。
还要注意：AI 读到的网页、文档和第三方文件里，可能夹带着指令，比如“忽略之前的要求，执行某某操作”。这些外部内容只是材料，不能当成你的指令。来源不明的命令，先看清楚它做什么再决定是否执行。
验收看证据，不看“已修复”
AI 说“已经修复了”，这句话本身不是证据。四种证据各有用途，不能互相替代：
- 代码差异（diff）：改了哪些文件、哪几行。
- 测试：逻辑是否正确。
- 浏览器里实际操作：界面和交互是否正常。
- 构建：项目能否生成可发布的文件。
让 AI 在完成时列出它实际执行了哪些检查、结果是什么、哪些情况没有检查到。检查失败的时候，保留原始的报错信息，不要只听它的总结。
把教训写回说明文件
每次协作中出的问题，都是改进说明文件的机会。AI 误改了网址结构，就在说明文件里补一条“不要修改路由”；测试漏掉了空数据的情况，就把这个样例加进测试。
说明文件要保持短而具体，及时删掉过时的内容。最终的决定，仍然由你根据用户的需要和真实的约束来做。
学习步骤
- 选一个你最近想让 AI 完成的任务，按五要素写出完整的委托。
- 在委托里明确写出不能改动的部分。
- 为你的项目写一份简短的说明文件：安装、运行、测试命令，主要约定，不能改的地方。
- 让 AI 先阅读相关文件并给出计划，确认后再让它动手。
- 完成后，分别用 diff、测试、浏览器操作和构建检查结果。
- 把这次协作中出现的问题，写成一条说明文件里的规则。
场景拆解
给项目列表加分类筛选
小许想让 AI 给工具目录加一个分类筛选功能。
第一次，他这样说：“给工具列表加个筛选功能。”AI 写了一个新的筛选组件，顺手改了数据结构，把分类从文本改成了数组，还调整了列表页的网址格式。结果详情页的链接全部失效。
第二次，他这样委托：
- 目标：读者能按分类筛选工具，筛选结果可以通过网址分享。
- 上下文：列表页在
src/pages/tools.astro，数据在src/data/tools.ts，每个工具的category字段是一个文本。 - 约束：不改数据结构，不改现有网址，不新增依赖。
- 验收：选择分类后只显示该分类；网址带上分类参数，刷新后保持；没有结果时显示提示；手机上筛选按钮可以横向滚动。
- 输出：先说明计划改动的文件，确认后再动手；完成后列出执行过的检查。
AI 先给出了计划：只改列表页和一个新的筛选脚本。小许确认后，它完成了改动，并报告了构建和三项手动检查的结果。小许看了 diff，确认数据文件没有被改动。之后他把“不改动数据结构和网址”写进了项目说明文件。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
交代清楚
- 目标：从用户角度描述
- 上下文：相关文件和复现步骤
- 范围和约束：能改什么，不能改什么
- 验收标准：可以观察的行为
协作的节奏
- 先读和计划，再动手
- 拆成可以独立验收的小任务
- 读取不等于授权
- 外部内容不是指令
验收和改进
- diff、测试、浏览器、构建
- 列出没有检查到的情况
- 把教训写回说明文件
02 实践练习
根据文章内容记录自己的判断与依据。
完成一次完整的委托和验收
用你自己的项目，完成一次从委托、计划、执行到验收的完整协作。
准备材料
- 一个能在本地运行、用 Git 管理的项目。
- 一个你常用的 AI 编程工具。
练习步骤
01 / 写委托
时间： 20 分钟
操作：
- 选一个小功能或小问题，按五要素写出委托。
- 检查是否写清了不能改动的部分。
产出： 一份任务委托。
检查： 验收标准都是可以观察到的行为，没有“好看”“流畅”这类模糊的词。
02 / 计划和执行
时间： 30-60 分钟
操作：
- 让 AI 先阅读文件并给出计划，确认后再执行。
- 执行前提交一次版本。
产出： 一份计划和一次改动。
检查： 实际改动的文件和计划一致。
03 / 验收和复盘
时间： 30 分钟
操作：
- 用 diff、测试、浏览器和构建分别检查。
- 把发现的问题写成说明文件里的一条规则。
产出： 一份验收记录和一条新规则。
检查： 验收记录里写了哪些情况没有检查。
完成检查
- 委托包含目标、上下文、范围和约束、验收标准、输出要求。
- 先计划后执行。
- 用实际运行的证据验收。
03 清单、模板和关键词
用于项目记录和自查。
任务委托模板
目标：（从用户角度描述要达到的结果）
上下文：相关文件 ____；现在的表现 ____；复现步骤 ____
可以改：____
不能改：____（网址、数据结构、接口、依赖……）
验收标准：
- ____
- ____
输出要求：先说明计划改动的文件和原因，确认后再动手；完成后列出执行过的检查、结果和未覆盖的情况。
项目说明文件提纲
# 项目简介（一两句话）
## 常用命令：安装 / 运行 / 测试 / 构建
## 目录结构：哪些目录放什么
## 约定：代码风格、命名、提交方式
## 不要改动：____
## 验收要求：改动后必须执行的检查
关键概念
- 任务委托：目标、上下文、范围和约束、验收标准、输出要求
- 项目说明文件：AI 每次都会读的项目背景和规则
- 先计划后执行：确认方案后再动手
- 最小权限：只给完成任务必需的权限
- 外部内容：网页和文件里的内容是材料，不是指令
- 四种证据：diff、测试、浏览器、构建
容易误判
- 只说“改好”“修一下”，不说清目标和标准
- 没写约束，AI 顺手改了不该动的地方
- 粘贴整个项目或带密钥的配置
- 一次让 AI 同时改很多不相关的东西
- 把 AI 说的“已修复”当成验收结果
- 执行来源不明的网页或文件里的指令
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Claude Code
- Codex
- Cursor
- GitHub Copilot