导读
“帮我优化一下这个页面”听起来省事，交给 AI 却很容易做大。它可能顺手改了样式、调整了数据结构，最后连原本没问题的地方也要重新检查。
不妨把一次修改写成一张小任务单：要解决什么，哪些地方可以动，碰到范围外的问题怎么办。这样做不能保证 AI 不犯错，但至少能让改动有边界，也方便验收。
示例说明：全部虚构，仅供演示
先说明要解决的问题
假设有一个虚构的待办列表，完成状态和创建时间都已保存。给某项打上完成标记后，它仍留在原来的位置。目标是让未完成项排在上面、已完成项排在下面；两组内部都按创建时间从早到晚排列。反复勾选、取消勾选，或刷新页面后，显示顺序仍按这条规则计算。本次不改原有的保存机制。
这比“把列表弄好用一点”具体得多。发任务前，把当前现象、期望结果和复现步骤写出来。如果只是收到他人反馈、自己还没复现，就标明“尚未复现”，别替问题下结论。
约定允许改动的范围
下面是一份可以复制的任务单。文件名和场景都是虚构示例，实际使用时要换成自己项目里的路径：
左右滑动查看完整代码
目标：勾选待办项后，未完成项显示在上面，已完成项显示在下面；两组内部都按创建时间从早到晚排列。反复勾选、取消勾选或刷新后，仍按这条规则显示已保存的数据。
已有条件：完成状态和创建时间已经保存。本次只改显示顺序，不改保存机制。
当前现象：勾选“已完成”后，该项仍留在原位置。
复现步骤：打开待办列表 → 勾选任意未完成项 → 观察列表顺序。
本次允许改动：src/todo-list.js；如需补测试，可改 tests/todo-list.test.js。
本次不要改：登录、数据存储结构、其他页面、依赖版本。
开始前：先只读检查相关代码，告诉我预计要改哪些文件和原因，等我确认后再修改。
如果必须改到约定范围之外，先停下，说明原因和可能影响，不要顺手扩大任务。
交付时：列出实际改动文件、做了什么、运行了哪些检查及结果；没测到的情况也要写明。不必每次都猜准文件。若 AI 检查后发现排序实际上由另一个模块控制，这张任务单的“先停下”就派上用场了：先讨论是否扩大范围，再决定怎么改。涉及登录、支付或数据库结构的变化，更不能靠一句“顺手修了”带过。
别把真实密钥、.env、客户资料或完整生产数据贴进任务里。能直接读取仓库的 AI 工具，还要看它实际能访问哪些文件；提示词写“不要看”并不等于权限已收紧。未经许可的代码或私密配置不要交给工具，必要时只在筛选过的项目副本里操作。
交付时看证据
AI 说“已修复”只是一个结论。验收时，至少看看这几件事：
- 实际改动是否只在确认过的文件和功能里？如果有范围外改动，为什么？
- 勾选、取消勾选、连续操作几次以及刷新后，列表顺序是否符合预期，组内创建顺序有没有漂移？原有新增、删除待办的操作是否仍能用？
- 运行了什么测试，结果是什么？没有运行的检查，是否明确写成“未验证”？
会用 Git 的话，再看一遍文件改动列表和 diff；不会用也至少打开最常用的操作路径，自己点一轮。测试通过只能说明测试覆盖到的情况通过，不能代替实际使用时的检查。
如果结果不对，把失败现象和复现步骤补进原任务单，再针对这处继续查；不要立刻追加无关的页面重构。