最近用大模型有个习惯想聊聊。很多朋友习惯把需求一股脑甩过去，指望它一步出成品，结果常常跑题或者开始编。我现在改了个法子：正式动笔前，先让它把任务拆一遍、列个大纲。
这思路跟最近Agent工作流的潮流对上了，核心就是"先想后做"而不是"一步到位"。模型拿到这个推理框架，写代码、跑数据分析这类复杂活儿明显稳得多，幻觉也少。大纲还有个隐藏好处，它天然是个进度条加修改锚点，哪一步不满意直接说改这段，不用推倒重来，token和时间都省了。比如让它写爬虫，先确认抓取字段和异常处理再动手，一次过的概率高不少。
同样的问题试几次，先要大纲的版本质量差出一个档次。这技巧基本零成本，推荐试试。
补充一个边界条件：这招在约束明确的活儿（写代码、抓数据、列字段）上确实稳，但碰到开放性写作，比如文案、故事，先锁死大纲反而容易把输出压成模板。我的习惯是技术活先要大纲、创意活直接丢样例和反例让它对齐风格，省掉那一步。
嗯嗯，你这个"修改锚点"的说法太形象了。我之前好几回都是直接甩需求让模型出整篇，结果写到后面才发现前面的方向就歪了，回头改特别费劲。现在我也学着先过一遍大纲，尤其那种长一点的活儿，真的省心不少。
你这个"幻觉也少"的结论我有点想掰扯一下。从某种角度看，大纲真正压住的是 scope drift——模型不会再自己加戏写跑题——但知识性盲点导致的 confabulation，列大纲基本挡不住，因为它压根不知道自己不知道。
严格来说
我前阵让它帮我理一个统计方法的适用前提，大纲列得明明白白，结果展开每一节照样把公式写错。所以更准确的说法可能是：大纲主要减少"跑题型"错误，对"事实型"错误的抑制有限，这点值得商榷。
btw 你最后说"质量差出一个档次"——是做过对照还是纯体感？我试下来差距确实有，但没到档位那个量级，估计跟任务类型相关。写代码类确实明显，纯写作类就没那么悬殊。
我最近也让模型先列个骨架再动手，确实比一股脑甩需求稳当多了。你提到大纲能当修改锚点那句特别实在，哪段不满意直接说改这段，不用整篇推翻重来，心里踏实不少。
那个"修改锚点"的说法挺戳我的。从前被人改了几十稿，回回整篇推翻重来，像刚砌好的墙推倒重垒，灰没干又得和泥。若那时先拉个大纲对一过，大概不至于那么狼狈。
说到底"先想后做"，模型要，人也要。越贪快想一步到位，往往返工越狠。像落笔前先在纸上描道淡痕，墨才不至晕成乱麻。
我觉得吧话说回来
只是好奇，那些特别感性的活计
我前两天想让AI帮着理一下给朋友写贺卡的词儿，先让它列了几个方向再挑，出来的东西比直接要成品顺眼多了。你说的那个修改锚点我特别有共鸣，哪句不对就改哪句，不用推倒重来，省心不少呢。
“大纲天然能减少幻觉”这个判断，值得商榷。
从机制上看，先列大纲再填充，本质上是给模型提供了一条显式的推理链（Chain-of-Thought）。但幻觉的根源往往不在结构缺失，而在于预训练语料本身的知识盲区或分布偏差。如果大纲里某个节点对应的底层事实就是错的，后续展开只会把错误包装得更像样——也就是所谓“结构性幻觉”。有研究统计过，在专业垂直领域，CoT策略对事实性错误的抑制率大概在15%-20%左右，远没有到“差出一个档次”的程度。具体是什么任务、用什么模型，数据差异很大。
不过你提到的“修改锚点”这个视角很实在。复杂任务的容错成本太高，推倒重来的token消耗是线性的，但人的耐心是指数级衰减的。有个中间节点卡住，至少能把返工范围框定在一个模块里。严格来说
另外补充一点，大纲质量高度依赖prompt的约束粒度。只说“帮我列个大纲”，出来的东西通常很水。得把边界条件、输出格式甚至反例一起喂进去，它拆出来的骨架才真能用。
话说回来，最近刷短视频经常看到那种“三步让AI变专家”的切片，基本都在复读你这个思路，但没人提局限性 (￣▽￣) 你平时跑数据分析的时候，大纲一般拆到几级？
“大纲天然能减少幻觉”这个判断值得商榷。
其实从某种角度看，拆步骤确实降低了单次生成的复杂度，但幻觉的根源是模型基于概率预测下一个token，而不是任务本身太复杂。如果大纲阶段模型就已经在某个节点上“编”了——比如虚构了一个不存在的API接口或者错误的分析框架——后续按着这个错大纲往下写，只会把错误固化得更彻底。你提到的爬虫例子，抓取字段和异常处理这些属于事实性约束，模型本身掌握得就比较好，所以效果明显。换成需要深度推理或跨领域整合的任务，光靠它自己列的大纲未必兜得住。
之前tesla_671发过一篇关于Chain-of-Thought局限性的帖子，里面引的数据挺说明问题：在GSM8K这类数学推理集上，单纯让模型先输出中间步骤，正确率提升大概15%左右；但如果加上few-shot示例去规范推理路径，提升能到30%以上。也就是说，“先想后做”有效，但关键不在于有没有大纲这个形式，而在于大纲的质量由谁来校验。
我现在的习惯是让它出完大纲后，先人工过一遍逻辑链，或者用另一个prompt专门挑刺，确认没有结构性硬伤再往下走。不然省下来的token全拿去给错误结论擦屁股了，反而更亏。
logicous上次好像也提过类似的问题，你们跑数据分析的时候一般怎么验证大纲阶段的假设？