这不是习惯问题，是任务类型问题
有人习惯把要求一次性写长，有人习惯先给一句再逐步补充，两种都常见，也都被认为只是风格差异。实际上它们适配的任务类型不同：一次性说清适合边界明确、输入输出都确定的任务；多轮推进适合需求模糊、需要边看边改的任务。把多轮当成偷懒省事的人，往往是不清楚一次性描述能带来什么；而把长提示词当成万能的人，则会发现自己反复重发同样的请求。
差别一：上下文积累方式不同
第一种差别在上下文。一次性提问时，所有要求都在同一段话里，模型需要在一次处理中兼顾全部约束，约束越多越容易顾此失彼。多轮对话则把约束分批加入，每一步只需处理增量，前面已确认的内容留在上下文里继续生效。这解释了为什么复杂任务拆成几轮往往更稳——不是模型变聪明了，是每一步的负担变小了。
差别二：纠错成本不同
第二种差别在出错之后。一次性提问出错时，你无法定位是哪一条要求被忽略或理解偏了，只能整体重写或反复微调，成本很高。多轮对话出错时，问题通常局限在最近这一轮，你只需重说这一步，前面已经满意的部分不受影响。对于需要反复打磨的内容，这一点决定了效率的量级差异。
差别三：可控性与漂移
第三种差别是方向控制。一次性提问的方向在开始时就锁死了，中途无法干预，结果好坏基本取决于你开头写得准不准。多轮对话允许你每一步校准：看完第一部分说「这部分可以，但再具体一点」，方向就在你的掌控中。代价是轮数多了之后可能出现漂移，前面定下的风格到后面被稀释，需要偶尔回述一次约束。
什么时候该一次问完
三种情况适合一次性说清：任务简单、要求明确、且不打算反复修改，比如把一段话改成另一种语气；需要批量处理同类内容，同一份描述要复用很多次；以及需要结果可复现、把要求固化成模板的场景。这三类任务的共性是：你想清楚要什么了，只是需要执行。
什么时候该分多轮
反过来，三种情况适合多轮：你自己还没想清楚最终要什么，需要看初稿才能判断方向；任务体量大，一次性描述会非常长且容易丢失重点；以及内容需要逐段把控质量，比如长文写作、方案设计、代码重构。这三类任务的共性是：过程是探索性的，结果要在过程中成型。
一个对照案例
某人要一份活动方案，第一次把所有要求写成一大段，拿到一份面面俱到但没有重点的文档，改了三次仍不满意，因为每次他都要重述全部要求。第二次他改成：先要框架，确认后再逐块展开，每块写完提一句修改意见。第二次总字数更多，但有效修改只有五次，成品也更贴近他的真实想法。差别在于把一次性赌注变成了逐步校准。
两种方式的常见坑
一次性提问的坑是：把要求堆得很长却互相矛盾，或者关键条件埋在中间被忽略；写完之后不看结果对错就直接用。多轮对话的坑是：轮数过多导致上下文漂移，前后风格不一致；以及陷入无止境的小改，忘了最初要达成什么。两者的共性问题都是缺少验收——不论哪种方式，都要在开始前想清楚什么叫做对了。
两者怎么配合
实用的做法是混合：先用一个简短的起始轮把目标、限制、输出形态交代清楚，之后进入多轮校准。这样既有明确起点，又保留调整空间。如果中间出现漂移，就把已经确定的约束重新复述一遍当作锚点。不要迷信某一种方式，把一次性与多轮看成同一条流程上的两个环节，用起来才顺。
局限声明
不同工具对上下文长度与记忆方式的处理差异明显，过长对话的衰减表现也不一致，本文基于通用使用经验。具体表现请以你所用工具的实测为准，重要内容建议分段落核对，本文不替代产品说明。