qws-zoom-out

qws 升维

作用

分三步：先消解用户的问题，判断它问得对不对，问法错了就指出断点、给出正确的问题；再做减法，检查用户的做法或现有流程里哪些可以省掉；最后直接回答。用户已经在局部反复修改时，同样先检查问题，再处理打转。整篇文案、整套方案、代码和发布等完整业务产物，仍交回原任务。

已发生的执行失败归因（例如格式没保存对、命令执行出错）不在本 Skill 范围，留在当前任务处理。

需要读取的文件

• 执行升维流程前，完整读取 references/system-scope-model.md。缺失时说明缺少该文件，仍按本文件的流程完成，不编造层级或步骤。
• 再按任务类型读取落地文件：修改文字（句子、段落、指代、措辞）读 references/landing-text.md；内容与账号相关（视频、选题、框架、标题封面、加粗重点、账号定位、阶段、议程）读 references/landing-content.md；AI、Skill、Agent、提示词和自动化工作流相关读 references/landing-ai.md；其他任务不读。落地文件只提供落地方法，不改变本文件的流程。

原则

1. 先消解用户的问题，再选答案。 问法对不对，只按 1.3 的判断标准，依据用户目标、现有事实和断点；不因为暂时写不出更好的答案而改变判定。
2. 分清想要的结果和问法。 用户想要的结果和价值取舍由用户决定，不替换。用户的问法、任务的定义和其中的前提可以被否定。
3. 中间结果要具体、可证伪。 推演写出的状态、条件和判断必须用这个领域的具体对象，不用「本质」「深层需求」这类空词；只写一句「推到底看」不算完成推演。改变框架时，说明改变了哪项解释、目标、原因、方案、风险、责任层或验收标准，以及依据。
4. 分析范围 ≠ 执行范围。 发现问题在上层时，退回最早受影响的环节，不把整个系统的责任压给眼前对象。
5. 比较只用于同一有效问法。 原问题成立且确有用户认可、已发布、正在使用或打转前仍有效的答案 A 时，才比较 A 与新方案 B；B 没有实质改善就保留 A。没有真实 A 时直接求解，不临时制造默认答案作门槛。问法错了时，A 只提供仍成立的事实与做法，不作为整份答案的回退项；新问题的答案按其自身的依据和效果验收。

流程

触发

• 升维：用户调用本 Skill（/qws-zoom-out、$qws-zoom-out、Skill 链接或其他调用方式），或说「升维」「升维 Skill」「从全局看」「这是不是局部问题」「检查是否只在局部解决」时，执行下面的升维流程，直接给出最终结果。调用本身就是要求，用户不需要再说「升维」。
• 提示升维：用户没有明确要求，但对话显示他在同一件事上反复修改仍不满意时，只在当前回复末尾加一句提示，不自动展开升维分析，原任务照常完成。按意思判断，不只匹配固定句子。常见的意思包括：
  • 对同一处修改连续表示不满意：「还是不对」「不是这个意思」「感觉哪里不对，但说不上来」「都不太行」「再换一个」；
  • 越改越差或想退回：「越改越差」「还不如原来的」「算了，还是用第一版吧」；
  • 觉得 AI 的判断在摇摆：「你怎么一直在变」「刚才不是这么说的」「又改回去了」；
  • 不同来源给出的方向冲突，用户拿不定主意：「几个 AI 说的都不一样」「我也不知道该听谁的」；
  • 同一个问题修好又出现，或规则、补丁越加越多却不见效。 提示句为：「这个问题可能卡在局部了。需要的话说『升维』，我从更高的维度帮你看一下。」以下情况不提示：用户第一次提修改意见；用户给出明确、具体的修改指令（例如“把这个词换成某某”）；问题是执行错误，例如文件没保存对、命令执行失败。同一件事只提示一次；用户没有回应时不再重复，除非之后又出现新一轮反复修改。
• 措辞里出现「战略」「架构」等词，但实际只是局部小改时，不构成扩大范围的理由；仍按流程检查，结论通常是局部足够。

升维流程

只有这一个流程，没有深浅之分；篇幅由检查结果决定。第 1 步的中间结果只在内部写出，用来约束回答，不整段展示给用户。顺序是：先消解用户的问题，再做减法，最后直接回答；各步的检查方法见 references/system-scope-model.md。

0. 先看是否再次调用。 已有 Active Scope State 时，按「连续性」判断沿用旧答案，还是从第 1 步重新检查。

1. 消解用户的问题。 查清用户想得到什么、原问题的前提是否成立：成立就保留原问题，确有断点才重新定义。本 Skill 中「消解」只指这一步。分三项做： 1.1 设定问题。 写出：用户原话；他提出的做法；他想要的结果；约束；有反复修改历史时，之前被否定的各版及否定理由。记录真实存在的答案 A（用户明确认可过、已经发布或正在使用，或打转开始前仍有效的版本），用法见原则第 5 条；不临时写默认答案。 1.2 找断点。 按顺序检查，每项都写出具体产出；查完用 reference 的「层级阶梯」判断问题主要出在哪一层：

   • 历史共同前提（有反复修改历史时先做）：已试各版共同默认了什么。它是首要嫌疑。对照 reference 中的「常见打转成因」认出打转类型；表里没有对应类型时，也要自己判断并说出是哪一种。
   • 前提：问题默认成立的事实、因果（做 X 会导致 Y）、可控性（Y 在用户能影响的范围内）、目标（Y 真是他要的）前提，逐条标成立、存疑或不成立。结果说多强，以用户实际会接受的成功标准为准：日常说的「防止」「让他喜欢我」，通常指把风险降到可以接受、或明显提高可能，不按字面理解成百分之百；只有用户听过较弱的答案后仍反复追问原来的结果，才按强的理解，这时较弱的答案不能冒充回答了原问题。
   • 根本目标：对想要的结果反复问「为什么要这个」，问到再往上只剩空话为止；选定一层作为根本目标，写出可观察的成功标准，以及按用户实际想要的程度达到它要满足的关键条件（不推到最强，不限条数），并列出涉及的其他参与者和他们各自想要什么。根本目标必须是用户说过或明显隐含的，不得改变用户已确定的取舍。
   • 条件推演：找出原问题默认不变、且一变就可能改变结论的条件（范围、时间、资源与约束、外部条件、其他参与者的反应），只推其中一两个到最大或最小，写出照原问法做时，用户想要的结果还能不能按成功标准达到。用户的做法本身在这里不推，能不能去掉留到第 2 步减法。回检：只在极端情况下才达不到的，降为提醒，不推翻原问题；但现实情况或用户的计划本身就在朝那个方向走时，不算「只在极端成立」。方法见 reference。
   • 适定性：照这个问法，有没有判断对错的标准；几个答案是否互相冲突，而现有信息无法裁决；答案是否对某个未知事实高度敏感，这个事实一变答案就翻转。

   快速通道：问题简单、没有反复修改历史、事实和因果前提都成立时，判定局部足够，跳过其余检查和第 2 步减法，按「回答结构」写一行痕迹加答案。 1.3 判断问题是否成立，确定要求解的问题。

   • 断点候选：不成立的前提；条件推演显示照原问法达不到用户想要的结果；适定性不通过的一项；历史共同前提满足下面「做法维持了问题」的判据。回检已降为提醒的不算。逐项检查断点是否在用户实际想要的程度上仍成立，以及是否会改变解释、决策或行动；不依据后续答案的成熟度判断。做法可以被去掉或替换，本身不等于问题问错；只有原问法把做法当成不可变的前提，因而导向错误行动时，才据此重定义问题。
   • 判断标准：按用户原话的常规意思认真回答：能得到对的做法，就是问题成立，即使原话用了「防止」「确保」这类绝对的词；只有照这个问法回答一定会走错方向（沿用错误因果、处理错责任层，或做法注定达不到用户要的结果）时，才算问法错了。原话没写出决定结果的因素，不等于问错了：正常回答会把它说出来。
   • 问法错了：至少一个有依据的断点通过上面的判断标准。写出「原问题假设了什么；事实或推演显示什么；照原问法会错在哪里」，再按 reference 对应类型重建问题。新问题保留用户想要的结果，明确现在要决定什么、谁能决定结果，以及哪项因果或责任关系改变；不能只把原做法换成另一种做法。「做法维持了问题」须有已试而持续／加重，或互相维持的循环；只凭极端情况下变差不能判定。
   • 问题成立：找不到上述会改变答案的断点；保留原问题，不为了显得升维而另造问题。
   • 证据尚不能定界：某个关键事实会翻转问法判定或解法时，保留相应条件及最可能的当前判断，不把存疑前提直接判为错误，也不因暂时没有更好的答案而判原问题成立。

2. 减法。 行动任务先做减法，再考虑增加做法；解释、理解类任务跳过这一步。整个流程只在这里做一次减法。检查对象是用户已经决定或打算采取的行动，包括问题背景里提到的，不只是问题直接问的那个手段；以及当前方案沿用或 Agent 自己设置的规则和流程步骤。身份和事实不是检查对象，它们是判断的依据。先查其中最主要的行动，再查次要的。每个做法先写出它的作用（它替用户完成什么），再问：不要这个做法，这个作用还能由谁、由什么完成，用户要的结果还能不能按成功标准达到？能，这个做法可以省掉，并写出替代它的人或办法；不能，就保留，改进或增加做法留到第 3 步。「去掉」指完全不做这个行动本身，不是只去掉它的前置条件、时机或附加步骤：比如检查「开会」，要问的是不开会行不行，不是先别急着开会。有事实显示某个做法已经做多、继续下去会起反作用时，作为提醒写进回答开头（见「回答结构」）。减法检验的是手段，不改变用户要的结果。问法错了时，原做法按 1.3 重建的问题检查。这一步只给结论：哪些做法可以省掉、由谁或什么替代、哪些必须保留；第 3 步从这些替代办法出发形成具体路径。

3. 直接回答。 从 1.3 确定的问题、1.2 的成功标准和关键条件、第 2 步减法的结论出发形成解法，形成时就检查依据和适用条件，不另设一道筛选关卡；方法细节见 reference 第三节。

   • 形成路径：针对尚未满足、足以影响结果的条件和 1.3 的断点，写出用户能采取的行动、由谁执行、怎样影响目标；涉及他人选择时，写清用户能提供的安排和对方仍需作出的选择，不把对方同意当作事实。把需要配合的动作组成可执行的路径；作用机制确实不同才算不同路径，不靠换措辞或加数量凑方案。路径都没处理 1.3 的断点时，继续找做法或成熟方法，不用原因清单冒充方案。
   • 写进答案：事实已否定、明显不适用、与用户目标冲突或只是换说法的路径不写。关键事实未知时，给出不同条件下的具体做法，再附最低成本的区分动作，区分动作不能代替做法；事实足以支持一种做法、或用户要求比较时，说明推荐哪条及依据；现有事实支持不了更强的办法时说明边界。
   • 完成回答：问题成立就按原框架回答；问法错了就回答 1.3 重建的问题，原做法怎么处理用第 2 步的结论。只有原因或核实条件、没有对应做法，不算完成行动任务。整篇稿子、口播稿这类完整业务产物，只给约束和落地规格，交回原任务。

要求：

• 一次调用给出最终结果。 往上查到「再上一层就会改变用户想要的结果，或用户已确定的定位、价值取舍」为止；改变问法不算越界；更上一层只写成约束或待用户决定的事项。
• 交付前自检。 假设用户马上再调用一次：往上一层或换个框架会不会得出不同答案？会且不改变用户想要的结果，就本次继续检查；否则停下交付。同时确认答案回答了最初的疑问，而不只是在新框架里看起来正确。
• 完成后在当前任务里保留精简的 Active Scope State（见下），不展示给用户，除非用户要求。

Active Scope State

必填 5 项，其余只在用到时填写；不涉及的写「不涉及」，不虚构层级。只留在当前任务和 Agent 日志中，不写入用户文稿或长期档案。

## Active Scope State
- 用户真正要推进的结果：
- 边界与选择依据（保留／扩展／重定义）：
- 应该介入的层级：
- 原任务必须继承的约束：
- 停止边界及原因：
- （按需）原因判断、关键关系、验收标准、未知与失效条件：

连续性

• 再次调用时先继承已有状态，并重读上一轮的回答原文。没有新事实、新目标或针对旧答案的具体失败反馈时，沿用原边界和答案，用一两句说明为什么不再往上走；不因用户说「再升一次」制造新答案。
• 复核时认为旧答案有错或有漏，必须引用上一轮回答的原句，说明它具体错在哪里、依据是什么；引用不出原句的，不算错漏。只补被证明有问题的地方，其余保留；原来的问题判断没有被证明错时，不重写「正确的问题」。
• 新事实或具体失败反馈改变了问题定义、目标、原因、方案、风险、责任层或验收时，从第 1 步重新检查。
• 后续执行继承该状态，不把系统性问题静默降回局部问题。

交付

两种情况都适用

• 涉及用户已有的稿子或方案时，不论问题成立还是问法错了，对稿子的改动都只动定位到的那一处，保留用户原来的判断，给候选；删段、合并、重写整篇只能列为「可选」，由用户决定。问法错了时，改变的是评价标准和改哪里，不是改动的幅度。
• 判断和答案在同一条回复里给出，不等用户再问「怎么办」。换目标、换定位、换框架这类大改动，也直接给出具体做法；用户明确只要诊断时，才只给判断。
• 缺少事实时，先从用户的文件和对话里找；找不到就按最可能的情况回答并写明假设（条件性做法的写法见第 3 步）。只有方向取决于用户的价值取舍、或存在会改变答案而只有用户能决定的事项时，才在末尾问一个问题，尽量给可选项；不能只给判断和问题就结束。
• 对话里用户已经没有回答过的问题，不再追问同一项；改为按最可能的情况给结果，或按两三种情况分别给出简短答案。
• 顺带发现的其他问题，用一句话列为「可选」，不写进改法；用户已定稿或明确要保留的内容不动。改法只解决定位到的问题，不替换用户的结论、立场或评价标准，也不改变原句的语气强度。
• 需要局部动作时附落地规格：改哪里、要完成什么、不能破坏什么、怎么验收，压缩成一两句。
• 价值取舍由用户决定；不路由到其他具名 Skill。

回答结构

检查后没有改变任何解释、目标、原因、方案、风险、责任层或验收时，结论为局部足够：只写一行痕迹加改法，例如「边界检查：原框架成立」；因用户要求而检查的，写「已按你的要求检查：原框架成立」。其余情况按下面的顺序说，每项只放自己的内容，怎么做只写在「答案」里。「停在哪」只记在 Active Scope State，用户问要不要再往上看时再说；需要用户决定的取舍，按「两种情况都适用」在末尾问一个问题。

问题成立时：

1. 问题对不对：一句话说明问题成立。提醒都写在这里：降为提醒的推演结论，以及某个做法继续下去会起反作用的事实。会改变用户做法的，用一句话说；不会改变的，不写。有反复修改历史时，写出打转类型的名称和最关键的一条依据，并写出这类问题的成熟做法名称；没把握时，至少两个可以搜索的关键词。
2. 做法：用户打算做的每个主要行动（包括问题背景里提到的），各用一句写出结论：可以省掉、由谁或什么替代，或者必须保留；必须保留时，用一句话说明想过的替代办法为什么不行，只陈述事实，不劝用户接受。只写结论，不写后果和具体怎么做。没有可以省掉或需要改变的做法时，整项不写。
3. 答案：小改动（一句话、一处指代、一个标题、一处加粗、一个参数）给 1–2 个候选；其他情况按第 3 步给出具体做法和适用条件。有真实且仍有效的 A 时，说明保留 A 还是换成 B，换成 B 时说出 B 在哪条具体事实或诉求上更好。

问法错了时：

1. 断点：用 2–4 句展示推演链，让用户能自己复核，不只给结论。提醒也写在这里，规则同「问题成立时」第 1 项。有反复修改历史时，同时写出打转类型；并写出成熟做法名称或至少两个搜索关键词。
2. 正确的问题：一句话。
3. 做法：原来的做法停止、减少、改变性质，还是保留其中仍成立的部分，并说明原因；不把用户原来的问题晾在一边。
4. 答案：具体可执行，质量要求和问题成立时一样。
5. 假设和退路（有才写）：改写依赖一个没有确认的、对用户目标的判断时，写明这个判断，并用一两句给出判断不对时原问题的答案；改写不依赖这类判断就不写这一项。

写法要求

• 打转过程用一句话概括，不逐条复述试过的版本；每个判断只给最关键的一条依据。
• 同一内容只说一次：整条回复里，同一个动作、防护措施或前提只出现一次；几条做法共用的，在答案开头或结尾集中说；别处需要时用一句话指过去，不重写。
• 每条做法写清两样：什么情况下用、一到三个关键动作。原因只在用户想不到、而且会影响他做不做时，写一句。关键动作要具体到用户能照做，不能压成「先评估」「先协商」这类方向性的话。
• 逐句检验：删掉这一句，用户的做法会不会变？不会变就删，包括重复的背景、同义提醒、总结句、过渡句，以及结尾把前文换个说法再讲一遍的段落。路径和具体动作不在删减范围内。
• 篇幅以讲清答案为准，不设固定字数。
• 不展示 Active Scope State、理论来源或内部检查表，用户要求时再展开。

正反例

• 该升维：「从全局看：转化率掉了，帮我改落地页文案。」同期流量来源、定价、客服话术都改过，「转化」口径还混了试用和付费。→ 改写问题，先校准指标和原因，再交回文案任务。
• 看起来问错、其实成立：条件推演得出的结论只在极端情况下成立，或者只是用户的某个做法可以省掉。→ 判为问题成立；极端情况降为提醒，可省的做法写在「做法」一项，说明由谁或什么替代。例：「每周例会太长，怎么让大家发言更简短？」问题成立；「每人轮流口头汇报」可以省掉，改成会前交书面进度，会上只讨论要决定的事。
• 局部足够：「把这段说明里的错别字改掉」，或改一个函数名。→ 一行痕迹，直接返回；不产出父级链、状态表这类没有改变判断的分析。
• 没喊只提示：用户第三次说「还是不对」，但没有要求升维。→ 照常完成这次修改，在回复末尾加一句「这个问题可能卡在局部了。需要的话说『升维』，我从更高的维度帮你看一下」，不展开分析。