AI 编程工具开始改代码前，要交代哪些任务与权限

先说明怎样才算完成

“帮我优化一下”很难验收。更清楚的任务是：在哪个页面或命令遇到什么现象，输入是什么，预期输出是什么，以及怎样复现。最好保留一个最小样例，让工具先解释问题，再开始修改。

Codex、Claude Code、Cursor和GitHub Copilot的入口与执行模式不同，但明确任务边界对这些工作方式都适用。下面是委托方法，不表示所有产品共享同一套权限按钮或默认设置。

可读与可改范围。 指出相关目录、必要文件和禁止改动的部分。如果只修一个显示问题，就说明是否允许修改依赖、数据结构和其他页面。已有未提交修改应先辨认归属，避免一起被覆盖。

可以运行的命令。 提供项目已有的启动、构建和测试命令。安装依赖、执行迁移和访问远端服务与读取文件不同，按实际任务分别说明。涉及账户令牌时使用项目既有的安全配置方式，不把秘密直接粘贴进任务正文。

外部动作的边界。 本地编辑、提交代码、推送分支和生产发布是不同动作。任务需要做到哪一步，应当明确。工具已生成代码或本地测试通过，不等于已经更新线上环境。

结果检查的方法。 指定需要看到的行为、错误场景与保留功能。界面改动检查实际页面；数据处理检查真实输出；外部调用检查相应目标，而不是只看工具的完成描述。

当前问题：在【入口】输入【样例】后出现【实际结果】，预期是【目标结果】。请先查看【相关目录】，说明原因，再完成必要修改。保留【已有行为】，不要改动【范围外内容】。使用【现有检查命令】验证，并报告实际修改、检查结果和仍未确认的部分。需要超出上述范围时先说明原因。

方括号不是越长越好，填入具体信息即可。先完成一个小任务，再根据结果扩大范围。需要规划较多文件时，可以先让工具提出步骤或使用产品提供的规划方式，再审阅实施方案。

先查看差异，关注删除、配置、依赖和外部请求的变化。确认修改与问题相关，再运行项目已有检查。若新增测试，应能在旧行为下失败、在修复后通过，并覆盖真正的边界；仅重复代码实现的测试可能没有检验价值。

如果工具无法运行某项检查，要求它明确说明原因和未验证的范围。若检查失败，保留错误信息并先定位原因，不要通过删除测试或放宽条件来获得绿色结果。

不等于。发布可能影响其他用户和真实数据，应按项目已有的发布规则和明确任务范围执行。

不要仅凭名称作保证。查看所用产品当前模式和权限说明，确认实际允许的工具和动作；任务文本与产品设置应相互配合。

需要核对测试命令、实际结果和覆盖范围。单元检查通过不一定覆盖浏览器显示、外部服务或生产配置。