DSH这套模式划分我最初是当成产品经理为了凑功能列表硬拆出来的四档预设——标准、PTC、极简、创造听起来跟相机里那几个滤镜差不多。真正拿它跑了两个多月的实际活之后我改主意了这四种模式不是风格选项而是一套关于自由度、可控性、单次成本的三角权衡工具。同样一个需求你用错模式不是结果差一点而是差一个量级——要么废话连篇抓不住重点要么过度精简漏掉关键约束要么发散得太远根本收不回来。这篇东西我想把 DSH 的四种工作模式拆开讲清楚每种模式内部到底在做什么动作、能力边界卡在哪里、什么样的任务该进哪个模式、以及混着用的时候怎么切。需要先说明一点DSH 的具体实现各家不一样下面关于模式内部动作的描述一部分来自公开资料里的通用说法一部分是我根据常见协作框架的实践逻辑做的合理补全凡是补全的地方我会标出来你按自己手头的实际系统对照着看别当成官方手册背。适合谁看刚开始接触这类协作框架、面对四个模式按钮不知道点哪个的新手也适合已经在用、但总觉得自己用得不顺手的中级使用者——大概率不是你提示词写得差是模式选错了。1. 四种模式不是四档滤镜而是一套成本与可控性的坐标系1.1 我理解的 DSH把模糊意图翻译成可执行动作的协作层先把 DSH 这个词摆正。在我接触到的语境里DSH 指的是一类对话式协作框架核心职责是把人嘴里那句模糊的帮我弄一下这个翻译成一串可执行、可检查、可交付的动作。它自己不生产内容它组织生产内容的过程。这个定位很关键因为它决定了四种模式的差异点不在回答得好不好而在过程组织得紧不紧。你可以把 DSH 想成一个包工头。标准模式是那种什么活都接、按常规流程走的工头PTC 模式是先出施工图、再分段施工、最后验收的工头极简模式是你说什么他干什么、一句废话没有的工头创造模式是先给你画五版草图让你挑的工头。四种工头都能把房子盖起来但盖出来的东西、花的时间、返工的概率完全不同。我见过最常见的误判是把四种模式理解成质量从低到高的排序以为创造模式最强、极简模式最弱。这是错的。极简模式在很多高频场景下的实际产出效率比创造模式高好几倍创造模式用在格式固定的批处理任务上纯属给自己找麻烦。模式没有高低只有匹配。1.2 三个取舍维度自由度、可控性、单次成本要理解模式边界得先抓住三个互相牵制的维度。自由度指的是模型在怎么完成任务这件事上有多少自主决策空间。自由度高的模式会自己决定先做什么后做什么、要不要举例、要不要给备选方案自由度低的模式路径基本被框死。可控性指的是你对输出形态的预测能力。你今天给它一个任务明天给同类任务输出结构是不是基本一致。可控性高的模式输出像流水线产品可控性低的模式每次都是开盲盒。单次成本不只是钱还包括时延、上下文占用、你阅读和筛选的时间。一个输出三千字但你只看懂三百字的回答成本远高于一个两百字直接给结论的回答。这三个维度是跷跷板。自由度拉高可控性通常下降单次成本上升成本压到最低可控性和自由度都得让路。四种模式本质上是这个三角上的四个站位不是四个质量档位。1.3 四种模式的能力边界对照表下面这张表是我自己整理的数字是经验值不同实现差异很大仅作相对比较用模式自由度可控性单次成本输出长度倾向典型返工触发点标准中中高中中等带解释约束没写清解释带偏PTC中低高高长结构化计划阶段方向就错了极简低极高低极短隐含前提未被识别创造高低中高长多分支收不回来无法落地看这张表有个诀窍别盯哪个好盯我最怕哪种失败。如果我最怕的是方向跑偏、返工重来那我该选可控性高的 PTC如果我最怕的是啰嗦、看不完那选极简如果我最怕的是想法太窄、跳不出框架那才轮到创造模式。选型的第一步不是评估任务是评估风险。还有一点值得说这四个模式之间不存在升级关系。不是先用极简再用标准最后用创造一路打怪升级。它们更像手动挡的挡位上坡下坡平路各用各的随时切。2. 标准模式默认档最稳但稳是有代价的2.1 标准模式的内部动作序列标准模式是绝大多数人打开就用的那一档也是我建议新手先跑熟的一档。它内部的典型动作序列大致是这样先识别任务类型再判断需不需要补充背景然后给出主体回答中间穿插必要的解释最后视情况补一句提醒或延伸。这个序列的特点是解释密度中等。它不会像极简模式那样只丢结论也不会像创造模式那样给三套方案让你选。它会告诉你是什么、为什么、大概怎么做但不会把每一步的参数都摊开。我用标准模式处理最多的是这类活一份不长的材料要读明白、一个中等复杂度的概念要搞懂、一段代码要看出问题在哪。这些任务的共同点是我要的不只是答案还要一点点上下文帮我校准判断。这时候标准模式的中等解释密度刚刚好多一分嫌吵少一分不够。注意标准模式最容易被误用的地方是拿它跑多步骤、有前后依赖的任务。它对步骤之间的依赖关系处理得比较弱经常是每一步单独看都对连起来顺序错了。2.2 标准模式最容易踩的三个坑第一个坑是约束后置。很多人习惯先说需求等输出不满意了再补一句哦对了不要写那么长。在标准模式下这个补充往往只对最后一小段起作用前面的内容已经按默认长度生成了。正确做法是把关键约束塞进第一句比如两百字以内、只讲结论、不要举例一句话定调比后面补五句都管用。第二个坑是把标准模式当搜索引擎用。标准模式有解释倾向你问一个特别简单的事实性问题它可能给你一段带背景的介绍。这不是它笨是模式特性。这类问题应该切极简。第三个坑是默认它记得住上下文。标准模式在多轮对话里对早期信息的保持能力有限尤其是对话拉长到十几轮之后前面定过的格式要求很容易被忘掉。我的做法是每隔几轮把关键约束复述一遍或者在每轮开头用一句话重申格式成本很低效果明显。2.3 实操把标准模式用出准定制效果标准模式虽然居中但通过输入组织可以把它往两个方向拽。往可控方向拽靠的是结构化输入。我常用的四段式任务一句话说清要干什么 输入给到的原始材料 约束长度、格式、禁止项 验收什么样算合格这四段一写标准模式的输出稳定性会明显上升因为约束不再靠它猜。往自由度方向拽靠的是开放式的收尾。比如在结尾加一句如果这个思路有明显漏洞直接指出来它就会在标准回答之外多做一次批判性检查。这个技巧我用得很多成本几乎为零但经常能捞到关键提醒。实测下来标准模式在单轮、中等复杂度、需要一点解释的任务上性价比最高。一旦任务跨到三步以上或者对格式一致性要求极高就该考虑往 PTC 走了。3. PTC模式把一次对话拆成流水线3.1 PTC三段式到底在解决什么问题PTC 这个缩写我看到过两种读法一种读作 Plan-Task-Check说的是流程一种读作 Prompt-Template-Context说的是输入组织方式。这两种读法不冲突前者管怎么走后者管怎么喂实际用起来是配合的。下面我主要按 Plan-Task-Check 这条线讲因为流程上的差异最能解释它的能力边界。PTC 解决的核心问题是多步骤任务里的依赖失控。标准模式处理第一步做完做第二步这种线性任务还行一旦第二步要用第一步的结果、第三步要判断前两步是否一致它就容易乱。PTC 的做法是先强制产出计划让计划本身成为可检查的中间物然后再逐步执行最后统一校验。这个先出计划的动作看着多余其实是整个模式的命门。因为计划是人可以拦截的。你在计划阶段发现方向错了改一行字就行等它把五步全执行完你才发现错了那五步全废。3.2 手把手一个PTC任务的完整走法拿一个具体例子走一遍。假设我要把一堆零散的会议记录整理成一份结构化纪要。第一步出计划。我会这样开口这是一个多步骤任务先只给我执行计划不要开始执行。 任务把 12 条零散记录整理成结构化纪要。 要求计划里要写清每一步的输入、输出、以及步与步之间的依赖。它回来的计划大概是先归类议题、再按议题合并重复项、再补时间线和责任人、最后统一格式。我在这一步会做一件事——检查有没有漏步。经验上第一次给的计划经常漏掉冲突信息如何标注这类边缘情况补进去再走。第二步分段执行。关键技巧是一次只放一步或者最多两步。很多人图省事一次说按计划全做了结果就是它把五步压缩成一段糊在一起中间产物全丢了出问题根本没法定位。第三步统一校验。全部走完之后单独发一轮校验请求重点是查一致性议题分类有没有重叠、责任人有没有前后不一致、时间线有没有倒挂。这一轮不要让它改只要它列问题改由我自己决定。走完这一套总耗时大概是标准模式的 2 到 3 倍但返工率能从经常要重来一遍降到局部微调。任务越复杂这个投入越划算。3.3 PTC的失效边界PTC 不是万能的它有明确的失效区间。任务太简单时失效。三步能做完的事上 PTC光计划阶段就占了一半成本纯浪费。探索性任务失效。如果任务本身的目标都不清楚比如帮我想想这个方向有没有前途你让它出计划它只能编一个看起来很合理但没意义的计划然后你按这个假计划走越走越偏。这类任务该去创造模式。需要频繁人工介入的任务失效。PTC 假设你能在计划阶段拦住它。如果你的领域知识不足以判断计划好坏那你拦不住PTC 就退化成了一个更啰嗦的标准模式。提示PTC 的计划阶段最值得检查的不是步骤够不够多而是每一步的产出物形态有没有定义清楚。产出物形态含糊的计划执行阶段一定会跑偏。3.4 注意事项与实操心得我自己踩过的坑里最值钱的一条是PTC 的计划不要写得太细。细到第一步先写标题、第二步写第一段这种颗粒度反而会锁死执行空间遇到计划外的情况它不会变通。合适的颗粒度是每步一个可验收的产出物具体怎么写交给执行阶段。第二条是保留中间产物。PTC 最大的价值不在最终结果在中间过程可追溯。我习惯让每一步的产出单独成段、带小标题这样出问题时能精确定位到哪一步不用全局重来。第三条是校验轮不要和执行轮混在一起。让它在执行的同时自我校验效果远不如先执行完、再单独发一轮只找问题不要改。这两种做法我对比过很多次后者发现的真问题明显更多。4. 极简模式砍掉解释只留结论4.1 极简模式省掉的到底是什么极简模式常被误解成质量差的模式其实它省掉的是三样东西铺垫、举例、延伸。它不省准确性。我拿同一个问题在标准和极简下对比过。标准模式会先给一句定义再举个例子再说一下常见误解最后给结论极简模式上来就是结论那一句。信息内核是同一个外壳全剥了。这个差异在批量场景下会被放大。假设我要处理两百条格式统一的短文本每条都要提取两个字段。用标准模式每条都带解释我光读解释就要多花一倍时间用极简模式输入输出严格对齐我甚至可以只扫一眼格式对不对就过。这种场景下极简模式的效率优势是数量级的。4.2 极简模式的三个高价值场景场景一格式固定的批量处理。提取字段、转换格式、统一命名、批量改写短句。这类任务的特点是规则明确、单条简单、数量大。极简模式在这个区间几乎没有对手。场景二你已经知道答案只想快速确认。有些时候我不是要它教我我是要一个快速的第二意见。这时候长篇解释纯属干扰一句是/否 一句话理由就够。场景三高频问答里的中间轮次。在一个长流程里中间经常有一些这个参数该填几的小问题。这些小问题用标准模式会把对话撑得很长上下文很快被占满后面真正重要的内容反而挤不进去。极简模式在这里起的是节流作用。4.3 极简模式的反噬与补救极简模式最大的风险是隐含前提没被识别。因为它不解释所以它不会告诉你我假设了 X。而 X 一旦错了输出看起来完全正常你根本发现不了。我遇到过好几次让它按固定规则筛一批数据结果它默认把某类边界情况排除在外了输出干干净净我用到第三步才发现少了一块。标准模式下这个假设可能会在解释里露出来极简模式下它藏得严严实实。补救办法有两个。一个是在输入里显式列出边界规则别指望它自己判断。另一个是抽样复核批量处理完之后随机抽 3 到 5 条人工对一遍成本很低能捞到大部分系统性偏差。还有一个补救技巧是在极简模式里塞一句如果有任何假设单独一行列出来。这句话几乎不增加输出长度但能把藏起来的假设逼出来我用得非常顺手。5. 创造模式把搜索空间放大再手动收窄5.1 创造模式的运行特征创造模式的运行逻辑和前面三个都不一样它不追求给一个正确答案它追求给出足够多的可能性。典型表现是会给多个方案、多个角度、甚至互相矛盾的思路有时候还会主动质疑你给的约束。这个特性决定了它的产出形态长、散、需要人工二次加工。你拿到手的不是一个成品是一堆半成品原料。我用它最多的场景是卡住的时候。写东西写到一半没思路、方案讨论陷入僵局、要给一个东西起名字、要预判某个决定可能引发的反对意见——这些任务的共同点是正确答案不唯一甚至没有正确答案关键是要跳出当前框架。注意创造模式最不适合的场景是有唯一正确答案的任务。你用创造模式去算一个确定的结果它会给你三个都算错的版本还都很自信。5.2 如何给创造模式上缰绳创造模式如果不加约束产出会滑向两个极端要么全是正确的废话要么飞得没边。上缰绳的关键是给它边界但不在边界内规定路径。我常用的约束句式是这样的给我 5 个方向每个方向一句话说清核心思路。 硬约束必须满足 A 和 B不能涉及 C。 不要展开细节等我挑完再展开。这里有几个设计考虑。数量限定在 5 个左右太少发散不够太多我筛不动。硬约束必须给但只给不能违反什么不给应该怎么做。最后一句等我挑完再展开是关键它防止模型在第一轮就把最长的那个方案写满三千字而那个方案可能恰恰是我不想要的。挑完之后第二轮我通常会把选中的方向切回标准模式或 PTC 模式去深化。创造模式负责发散标准/PTC 负责收束这个配合我用得最顺。5.3 创造模式的产出如何验证创造模式的产出有一半以上是不能直接用的这不是缺陷是它的工作方式。所以我给自己定了一条规则创造模式的产出不验证不落地。验证分两层。第一层是可行性筛把明显做不到的直接划掉这一步很快靠常识就行。第二层是反例测试对留下来的每个方向问一句这个方向最可能在哪失败。这一问经常能筛掉一批看起来漂亮但经不起推敲的方案。还有个经验创造模式给的方案里排第一的往往不是最好的。因为排序靠前的通常是最安全、最符合常规的那个真正的亮点经常藏在第三、第四个。所以我会强制自己把每个方案都读完再决定不让第一印象替我做选择。6. 选型参考与混用策略别问哪个好问这一步该用哪个6.1 一张选型决策表实际用的时候我基本是按下面这张表快速判断的任务特征首选模式理由单轮、中等复杂度、需要一点解释标准解释密度刚好成本可控三步以上、有前后依赖、要可追溯PTC计划可拦截中间产物可定位格式固定、批量、单条简单极简效率数量级优势目标不清、需要多方案、要跳出框架创造发散是它的本职高频小问题穿插在长流程中极简节省上下文防止挤占已知大概方向只差执行细节标准转 PTC先定调再拆步这张表用的时候有个前提你得先能说清任务特征。说不清的时候我的默认动作是先上标准模式跑一轮从输出里判断这任务到底复杂在哪再决定要不要换。用标准模式做一次侦察成本不高信息量不小。6.2 同一个任务里的模式切换示例举个完整的例子说明四种模式怎么在一条线上接力。假设我要做一份行业观察的初稿。第一轮创造模式让它给 6 个可能的切入角度每个一句话。我挑出 2 个有意思的。第二轮标准模式针对挑出的 2 个角度各展开 300 字看哪个更有话说。这一步是在做低成本试错。第三轮PTC 模式选定角度后让它出写作计划——分几个部分、每部分的核心论点、需要什么类型的例证。我在这里拦一次调整结构。第四轮PTC 分段执行按计划一部分一部分写每部分写完我看一眼再走下一步。第五轮极简模式全文写完让它用极简模式做一次压缩输出 200 字的摘要。这一步同时起到校验作用——如果压缩出来的摘要跟我原本的意图对不上说明中间某段跑偏了。这条线上四种模式全用上了每种都在它最擅长的位置。如果全程只用标准模式我大概会得到一份哪哪都还行、哪哪都不出彩的稿子如果全程只用创造模式我会得到一堆没法落地的想法。6.3 常见问题速查与排查思路现象最可能的原因处理动作输出很长但抓不住重点用了标准或创造模式跑简单任务切极简约束塞进第一句多步任务顺序错乱用标准模式跑依赖型任务切 PTC强制先出计划格式每次都不一样约束没写死或模式自由度太高用四段式输入切 PTC输出正确但没法用缺业务背景模型在猜补上下文别只加约束想法都很平庸用了标准模式做发散任务切创造限定数量和硬约束极简模式漏了东西隐含假设没被识别加列出所有假设一句创造模式收不回来没设收束轮次第一轮只发散选定后切回标准PTC 耗时过长任务本身不够复杂降级到标准别硬套流程这张表里我个人踩得最多的是第一行和第七行。第一行是杀鸡用牛刀总觉得多给点信息没坏处实际上读长输出的时间成本经常被低估。第七行是发散完了忘了收创造模式给了一堆想法兴奋之下直接拿去用结果发现没一个能落地。现在我强制自己在创造模式之后必须接一个收束动作哪怕只是写一句我选第 3 个理由是……。6.4 我自己的几条硬规则用到现在沉淀下来几条不太会变的规则分享一下。规则一先定失败代价再选模式。我最怕的是哪种失败就避开对应的模式弱点。怕跑偏就用可控性高的怕啰嗦就用极简怕想窄了才用创造。这个顺序不能反。规则二模式切换要显式声明。别指望系统自己判断该用什么模式。每换一个模式我会在输入开头写一句接下来用极简模式明确告知。这个动作看着笨但能省掉大量它以为我要 A 其实我要 B的误会。规则三复杂任务宁可从 PTC 降级不要从标准升级。意思是任务拿不准复杂度时先按 PTC 走一小段发现太简单了再降回标准而不是先用标准跑跑乱了再往上加流程。前者损失小后者经常要推倒重来。规则四任何模式的产出都要有一个我自己能验的点。极简模式靠抽样复核标准模式靠常识判断PTC 靠中间产物对照创造模式靠反例测试。没有验证手段的模式选择等于赌博。规则五批量任务先跑五条试水。不管是极简还是标准处理大批量之前先拿五条跑一遍看输出形态稳不稳、假设有没有跑偏。这五条的成本几乎可以忽略但能避免两百条全废。最后说一个我自己的体会这四种模式真正难的不是记住它们的定义是在动手之前花十秒钟问自己一句这活的失败代价是什么。这十秒钟的停顿比我后来所有的技巧加起来都管用。模式选对了提示词随便写写都过得去模式选错了提示词打磨到极致也是事倍功半。