同一件事情，写成「帮我看看这段代码」和写成「指出这个函数在空列表时为什么返回错误，不要改其他函数」，得到的结果差很多。AI 工具会补上你没写的部分。没写的部分越多，它就越可能改到不该动的文件，或者交回一段无法判断对错的说明。
下面说的是任务说明怎么写，不涉及某个具体产品的注册和设置。
一条说明里放齐五件事
可执行的说明通常要回答五个问题：
- 目标。 做完以后要得到什么，用一个能观察的结果来写。
- 范围。 允许改哪些文件、哪些不能动。
- 输入。 相关代码、报错、示例数据放在哪里。
- 约束。 必须使用的写法，以及明确不要做的事。
- 完成标准。 怎样算做完，例如测试通过、页面能打开、输出包含某几项。
比较这两条：
帮我优化一下配置读取。目标：让 check_json_config.py 在 app.json 缺少 port 时退出，并提示缺少的字段名。
范围：只改这个文件，不要新增依赖。
输入：配置是 UTF-8 的 JSON，字段有 name、port、debug。
约束：继续使用标准库 json 和 pathlib。
完成：用一份缺少 port 的配置运行，退出信息里要出现 port。第二条没有增加多少字，但每一句都能拿去核对。第一条里的「优化」可以理解成改名、提速、换格式或加功能，工具只能猜。
把不能做的事写成一句
范围如果只写「可以改配置相关代码」，仍可能连带改文档、升级依赖、提交版本库。需要保住的边界要直接写出来，例如：
- 不要升级已经写明版本的依赖。
- 不要新建账号，不要改域名解析。
- 不要把示例里的密钥、口令写进文章或日志。
- 没有运行结果时，不要写「已经测试通过」。
这些句子不是态度，是验收条件。做完以后可以逐条看有没有越过。
输入要能复现，不要只形容
「这里报错了」不足以让工具定位。把报错原文、执行的命令和当前目录一并放上。报错很长时，保留异常类型、最后几行和你执行的命令，不要只留一句「失败了」。
希望它仿照某种格式时，给一个短例子。比如要一段 JSON，就贴出字段名和类型，而不是说「按常规配置来」。常规在不同项目里不是同一件事。
例子也要真实可运行。临时编一个不存在的函数名，工具会顺着这个名字继续写，错误会扩散到后面的步骤。
一次只交一件事
「把文章写完、翻译、配图、再部署到服务器」是四件任务。前一件的结果要作为后一件的输入时，分成几次交。一次交完，中间错了也不容易停下来改。
如果任务本身有顺序，就写成编号步骤，并写明某一步失败时停住，不要自行换一种做法。例如：检查发现端口被占用，就报告占用情况，而不是改去另一个端口继续。
常见错误
- 用「随便」「好看一点」「正常一点」这种无法核对的词当完成标准。
- 把背景写了很长，真正要做的动作放在最后半句。工具可能把背景当成要执行的步骤。
- 同时给出两个互相矛盾的要求，例如「不要改接口」又「给接口加一个必填参数」。
- 没说输出现在哪里。结果写进了聊天记录，没有写进约定的文件，下一轮还得再找一次。
- 发现结果不对，只回复「还是不行」。补充实际输出和预期输出，修改才有依据。
交出去之前自己读一遍：如果把工具换成一位不了解项目的同事，他能不能只靠这段文字动手，并且知道做到哪一步该停。不能的话，缺的就是某一条边界，而不是更华丽的措辞。
小结
清楚的任务说明由目标、范围、输入、约束和完成标准组成。每一样都写成可以观察的事实，并把不许跨越的边界单独列出。一次交一件事，返回结果用原来的完成标准核对，返工会少很多。