DSH这套模式划分，我最初是当成产品经理为了凑功能列表硬拆出来的四档预设——标准、PTC、极简、创造，听起来跟相机里那几个滤镜差不多。真正拿它跑了两个多月的实际活之后，我改主意了：这四种模式不是风格选项，而是一套关于自由度、可控性、单次成本的三角权衡工具。同样一个需求，你用错模式，不是结果差一点，而是差一个量级——要么废话连篇抓不住重点，要么过度精简漏掉关键约束，要么发散得太远根本收不回来。

这篇东西我想把 DSH 的四种工作模式拆开讲清楚：每种模式内部到底在做什么动作、能力边界卡在哪里、什么样的任务该进哪个模式、以及混着用的时候怎么切。需要先说明一点，DSH 的具体实现各家不一样，下面关于模式内部动作的描述，一部分来自公开资料里的通用说法，一部分是我根据常见协作框架的实践逻辑做的合理补全，凡是补全的地方我会标出来，你按自己手头的实际系统对照着看，别当成官方手册背。

适合谁看：刚开始接触这类协作框架、面对四个模式按钮不知道点哪个的新手；也适合已经在用、但总觉得自己"用得不顺手"的中级使用者——大概率不是你提示词写得差，是模式选错了。

1. 四种模式不是四档滤镜，而是一套成本与可控性的坐标系

1.1 我理解的 DSH：把模糊意图翻译成可执行动作的协作层

先把 DSH 这个词摆正。在我接触到的语境里，DSH 指的是一类对话式协作框架，核心职责是把人嘴里那句模糊的"帮我弄一下这个"，翻译成一串可执行、可检查、可交付的动作。它自己不生产内容，它组织生产内容的过程。这个定位很关键，因为它决定了四种模式的差异点不在"回答得好不好"，而在"过程组织得紧不紧"。

你可以把 DSH 想成一个包工头。标准模式是那种什么活都接、按常规流程走的工头；PTC 模式是先出施工图、再分段施工、最后验收的工头；极简模式是你说什么他干什么、一句废话没有的工头；创造模式是先给你画五版草图让你挑的工头。四种工头都能把房子盖起来，但盖出来的东西、花的时间、返工的概率完全不同。

我见过最常见的误判，是把四种模式理解成"质量从低到高"的排序，以为创造模式最强、极简模式最弱。这是错的。极简模式在很多高频场景下的实际产出效率，比创造模式高好几倍；创造模式用在格式固定的批处理任务上，纯属给自己找麻烦。模式没有高低，只有匹配。

1.2 三个取舍维度：自由度、可控性、单次成本

要理解模式边界，得先抓住三个互相牵制的维度。

自由度指的是模型在"怎么完成任务"这件事上有多少自主决策空间。自由度高的模式，会自己决定先做什么后做什么、要不要举例、要不要给备选方案；自由度低的模式，路径基本被框死。

可控性指的是你对输出形态的预测能力。你今天给它一个任务，明天给同类任务，输出结构是不是基本一致。可控性高的模式，输出像流水线产品；可控性低的模式，每次都是开盲盒。

单次成本不只是钱，还包括时延、上下文占用、你阅读和筛选的时间。一个输出三千字但你只看懂三百字的回答，成本远高于一个两百字直接给结论的回答。

这三个维度是跷跷板。自由度拉高，可控性通常下降，单次成本上升；成本压到最低，可控性和自由度都得让路。四种模式本质上是这个三角上的四个站位，不是四个质量档位。

1.3 四种模式的能力边界对照表

下面这张表是我自己整理的，数字是经验值，不同实现差异很大，仅作相对比较用：

看这张表有个诀窍：别盯"哪个好"，盯"我最怕哪种失败"。如果我最怕的是方向跑偏、返工重来，那我该选可控性高的 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 一张选型决策表

实际用的时候，我基本是按下面这张表快速判断的：

这张表用的时候有个前提：你得先能说清任务特征。说不清的时候，我的默认动作是先上标准模式跑一轮，从输出里判断这任务到底复杂在哪，再决定要不要换。用标准模式做一次"侦察"，成本不高，信息量不小。

6.2 同一个任务里的模式切换示例

举个完整的例子，说明四种模式怎么在一条线上接力。

假设我要做一份行业观察的初稿。

第一轮，创造模式：让它给 6 个可能的切入角度，每个一句话。我挑出 2 个有意思的。

第二轮，标准模式：针对挑出的 2 个角度，各展开 300 字，看哪个更有话说。这一步是在做低成本试错。

第三轮，PTC 模式：选定角度后，让它出写作计划——分几个部分、每部分的核心论点、需要什么类型的例证。我在这里拦一次，调整结构。

第四轮，PTC 分段执行：按计划一部分一部分写，每部分写完我看一眼再走下一步。

第五轮，极简模式：全文写完，让它用极简模式做一次压缩，输出 200 字的摘要。这一步同时起到校验作用——如果压缩出来的摘要跟我原本的意图对不上，说明中间某段跑偏了。

这条线上四种模式全用上了，每种都在它最擅长的位置。如果全程只用标准模式，我大概会得到一份"哪哪都还行、哪哪都不出彩"的稿子；如果全程只用创造模式，我会得到一堆没法落地的想法。

6.3 常见问题速查与排查思路

这张表里，我个人踩得最多的是第一行和第七行。第一行是"杀鸡用牛刀"，总觉得多给点信息没坏处，实际上读长输出的时间成本经常被低估。第七行是"发散完了忘了收"，创造模式给了一堆想法，兴奋之下直接拿去用，结果发现没一个能落地。现在我强制自己在创造模式之后必须接一个收束动作，哪怕只是写一句"我选第 3 个，理由是……"。

6.4 我自己的几条硬规则

用到现在，沉淀下来几条不太会变的规则，分享一下。

规则一：先定失败代价，再选模式。我最怕的是哪种失败，就避开对应的模式弱点。怕跑偏就用可控性高的，怕啰嗦就用极简，怕想窄了才用创造。这个顺序不能反。

规则二：模式切换要显式声明。别指望系统自己判断该用什么模式。每换一个模式，我会在输入开头写一句"接下来用极简模式"，明确告知。这个动作看着笨，但能省掉大量"它以为我要 A 其实我要 B"的误会。

规则三：复杂任务宁可从 PTC 降级，不要从标准升级。意思是，任务拿不准复杂度时，先按 PTC 走一小段，发现太简单了再降回标准；而不是先用标准跑，跑乱了再往上加流程。前者损失小，后者经常要推倒重来。

规则四：任何模式的产出，都要有一个"我自己能验"的点。极简模式靠抽样复核，标准模式靠常识判断，PTC 靠中间产物对照，创造模式靠反例测试。没有验证手段的模式选择，等于赌博。

规则五：批量任务先跑五条试水。不管是极简还是标准，处理大批量之前先拿五条跑一遍，看输出形态稳不稳、假设有没有跑偏。这五条的成本几乎可以忽略，但能避免两百条全废。

最后说一个我自己的体会：这四种模式真正难的不是记住它们的定义，是在动手之前花十秒钟问自己一句"这活的失败代价是什么"。这十秒钟的停顿，比我后来所有的技巧加起来都管用。模式选对了，提示词随便写写都过得去；模式选错了，提示词打磨到极致也是事倍功半。