四轮，胜过一次请求
在一条消息里，要求一份2000字的文档，会产出均匀、泛泛的散文。把这项工作拆分成结构、分段起草、连接润色和最后收紧，能让你在每个阶段都掌握控制权，得到一份保留你自己的素材、而不是模型素材的文字。
一次性长请求的失败之处，不在于长度，而在于千篇一律：每一部分，都得到同样的分量、同样的节奏、同样的深度，不管你实际上对哪些部分真正了解。
第一轮：只做结构
要求给出一份大纲，每一部分用一句话说明它要论证什么。在任何正文出现之前，先修正这份大纲。这才是这份文档真正被决定下来的地方，改动它只需要200个字，而不是2000个字。
第二轮：分别起草各部分
每次请求起草一个部分，附上大纲和你为那部分准备的原始笔记。分开请求，能让你的素材始终摆在模型面前，而不是被埋在40页文字后面，也让你能把更多精力，投入到真正重要的部分。
第三轮：衔接
粘贴已经组装好的各部分，只要求过渡衔接，以及去掉它们之间的重复。分开写的部分，会互相重复，而这一轮，就是专门为了修正这一点，不需要重写内容。
第四轮：用一个具体数字来收紧
要求一个具体的压缩比例，比如「缩短15%，不删掉任何一个论点」。一个具体的目标，能产出真正的删减；只是要求「收紧」，只会产出一份长度相近的重写。这一轮，去掉的是之前几轮引入的那些冗余。
使用者常问的问题
这比一次请求更慢吗？
从消息数量上来说，是的。从得到一份能用的文档所需的时间来说，这更快，因为一次性写出的初稿，通常需要一次你无法引导的重写。
每一部分应该多长？
短到你能仔细读完这个回答的程度：300到500字。超过这个长度，审查质量就会下降，错误也会一路留存到最终的文字里。
我能跳过大纲这一轮吗？
你可以，但大部分价值，恰恰就在这一轮里。修正一个结构，只需要一行字；修正一份已经完成的文档，代价是整份文档。
从大纲开始，每一部分用一句话说明。
打开工具