AI 提示词与技能库

保留原意和信息密度，只做语言层面的修整

你是中文母语编辑。把下面这段改得通顺，要求：1）保持原意和信息密度；2）去掉套话、重复和空转的形容词；3）不要增加我没写的内容；4）改完用一句话说明你主要动了哪里。

[粘贴草稿]

删掉「不是…而是…」「首先其次最后」这类模板腔

下面这段文字读起来像 AI 写的。请重写：1）删掉「不是……而是……」「不仅……而且……」这类对仗句式；2）删掉「首先/其次/最后」「总的来说」「值得注意的是」；3）把抽象名词换成具体动作；4）句子长短交错，允许不完整句。改完只输出正文。

[粘贴文本]

删掉一半还不丢信息，靠的是挑出真正的重点

把下面这段压缩到 [目标字数] 字以内。规则：1）保留所有事实、数字、结论；2）删掉铺垫、重复解释和修饰；3）可以合并句子，但不要改变因果关系。

[粘贴文本]

输入一堆碎片笔记，输出可以直接用的提纲

下面是我的零散想法。请整理成一份提纲：1）先给一句话主旨；2）按逻辑层级分 3–5 个部分，每部分一句话说明它解决什么问题；3）把每个碎片归到对应部分下；4）指出哪两个想法其实重复了，或者互相矛盾。

[粘贴笔记]

拒绝、催进度、纠正错误——不卑不亢

帮我写一封邮件。背景：[背景]。收件人：[关系与身份]。我要达到的目的：[目的]。我的底线：[不能让步的地方]。要求：简短；先给结论再给理由；不道歉超过一次；结尾给出明确的下一步和时间点。

给老板看和给工程师看，必须是两套话

把下面这段内容改写成两个版本：1）给[管理者]看——控制在 150 字内，只讲影响、风险和需要的决策；2）给[执行同事]看——保留所有技术细节和操作步骤。两个版本都不许丢关键事实。

[粘贴原文]

同一篇文章写出从克制到夸张的标题，并标出哪条越界

你是做内容分发的老编辑。读下面这篇文章，给 5 个标题，强度从克制到夸张依次递增。每个标题后面标注：1）它承诺了什么；2）正文是否真的兑现；3）读者点进来后最可能的反应（失望/被冒犯/觉得值）。最后单独指出：哪一个标题已经构成标题党，为什么。不要为了点击率牺牲准确性。

[粘贴文章]

强硬、缓和、自嘲：同一件事的三种说法及各自代价

把下面这段改写成三个版本，内容不变，只换语气：1）坚定版——不留商量余地，但要给出理由；2）缓和版——保留立场，把对抗性降到最低；3）自嘲版——用承认自己的窘迫来降低对方防备。每个版本后面用一句话说明它的代价（会被怎样解读、失去什么）。不要添加原文没有的事实。

[粘贴段落]

只标出可验证的问题，不重写文章

你是事实核查编辑。逐段读下面这篇文章，只做核查，不要改写。输出三栏：1）文中的数字、日期、人名、引语，逐条列出并注明「需核实」或「与上下文矛盾」；2）前后说法不一致的地方，引用两句原文；3）没有来源的强断言（「所有」「从来」「必然」）。每条给出最省事的核实方式。没问题的段落不要提。

[粘贴文章]

保留说话人的语气，删掉口语的重复和跑题

下面是一段访谈录音的文字稿。请整理成一篇 1500 字左右的文章：1）按主题重组，不按时间顺序；2）保留 5–8 句最有信息量的原话作引语，一字不改；3）删掉口头禅、重复和跑题，但不要改变说话人的语气和立场；4）标出 3 个我没追问下去、但应该追问的问题。

[粘贴文字稿]

用户能看懂，且知道这次更新对自己意味着什么

根据下面的改动记录写一篇更新日志。读者是已在使用产品的普通用户。结构：1）一句话说这次更新最值得注意的变化；2）按「新增 / 改进 / 修复」分组，每条写「改了什么 + 对你有什么影响」，不用内部术语；3）单独列出需要用户动手的事（重新登录、改配置等）；4）已知问题。不要写「优化了用户体验」这种空话。

[粘贴改动记录]

找出文章在哪一句被放弃，而不是夸它写得清楚

你要扮演一个很不耐烦的目标读者：[读者身份]，本来只想扫两眼。请按顺序读下面这篇稿子，然后回答：1）读到第几段你会关掉，具体是哪句话让你失去耐心；2）哪三处是在自说自话、没有回答读者心里的疑问；3）哪个论点你觉得作者自己也没想清楚；4）如果要你只保留一半，删哪几段。不要评价文笔，不要给鼓励。

[粘贴稿子]

把长文压成三张能各自独立成立的卡片，而不是一段更短的摘要

你是做知识管理的编辑。把下面这篇长文改成三张摘要卡，每张卡只回答一个独立问题：1）卡一：这篇文章最核心的结论，用一句话说清；2）卡二：支撑结论的关键证据或机制，只留必要细节；3）卡三：读者读完能做什么，或者什么情况下不适用。每张卡 80 字以内，标题不超过 12 字；原文没有的内容不要补。最后标出哪张卡最可能被单独转发，并说明理由。

[粘贴长文]

找出话题真正转换的位置，再用小标题把结构显出来

你是非虚构编辑。给下面这篇文章加小标题：1）先通读，标出话题真正转换的位置，不要按段落平均切；2）每个标题 8–14 字，让读者只看标题就知道这一节在回答什么问题；3）标题用陈述句，不用「关于……」或「……的思考」；4）如果某段找不到可命名的主题，说明它应该合并或删掉。最后列出你新增和改动的标题。

[粘贴文章]

先把最强的反对意见说到位，再逐条回应，而不是打稻草人

你是负责挑错的论证教练。针对下面这个观点做四步：1）用一句话复述观点，并指出它成立所依赖的隐含前提；2）给出三个反方，每个都必须是该领域聪明人会认真提出的版本，不许用容易被驳倒的稻草人；3）逐个回应：承认哪部分成立、哪部分不成立、还需要什么证据；4）指出如果其中一个反方成立，原观点应该怎么改。不要替原观点辩护到底。

[粘贴观点]

去掉口头重复和跳跃，留下可执行、可引用的书面结论

你是会议记录编辑。把下面这段会议发言整理成书面文档：1）开头三行写清决定了什么、谁负责、什么时候；2）正文按「背景—讨论—决定—待办」组织，不按发言顺序；3）删掉口头禅、重复和没说完的句子，但不改变发言人的立场；4）把「大概」「回头再说」这类模糊说法标出来，换成需要确认的问题。不要补造会上没说过的话。

[粘贴发言记录]

逐句对照断言的强度和证据的强度，只标问题不改稿

你是审稿编辑，只检查「断言」和「证据」是否匹配，不改写文章。逐段找出所有带判断的句子：1）把断言按强度分级——事实、趋势、因果、预测；2）标出它引用的证据属于哪一类：数据、案例、引语、常识，还是没有；3）指出强度不匹配的地方，例如用一个案例支撑「所有」，或用相关性证明因果；4）给每条不匹配的断言一个最小修改建议：降级措辞，或补上它需要的证据。不要评价文笔。

[粘贴文章]

保留限制和失败情况，把实现细节换成读者能对应的后果

你是技术传播编辑。把下面这段技术文档改写成非技术读者能懂的版本，读者是[角色，例如产品经理、客户、管理层]。要求：1）开头一句话说清这对读者意味着什么；2）每个技术概念第一次出现时，用一句日常经验解释，不引入新术语；3）保留限制条件、失败情况和数字，不要为了好懂而删掉风险；4）原文有歧义或缺失的信息单独列出，标「需确认」。不要用比喻替代机制。

[粘贴技术文档]

禁掉形容词，只写能被验证的细节和使用场景

你是产品文案编辑。为[产品]写一段 200 字以内的介绍，读者是[目标用户]。硬性约束：1）禁用「强大」「高效」「极致」「智能」「一站式」这类形容词，也不要用同义词替换；2）每个卖点必须落在一个具体动作或场景上，写清谁在什么情况下做什么；3）至少包含一个能被验证的细节（数字、限制、适用条件）；4）给出三版：功能视角、场景视角、对比视角。宁可写得朴素，也不要写无法核实的评价。

[粘贴产品信息]

把评论、工单和访谈里的碎片归并成少数可行动的主题

你是用户研究分析师。把下面这些零散反馈归成主题：1）先通读，按「用户想完成什么」聚类，不要按关键词或情绪聚类；2）每个主题给出：一句概括、支持条数、两条一字不改的典型原话、一条反例；3）按「影响人数 × 严重程度」排序，并说明排序依据；4）单列无法归类的反馈和可能的误读。不要美化措辞，也不要替用户补全逻辑。

[粘贴评论、工单或访谈记录]

只挑会导致 bug、安全和性能问题的地方

你是资深工程师。审查下面这段代码，只指出会导致 bug、安全问题或性能问题的地方，按严重程度排序。每处给出：1）问题是什么；2）会在什么条件下触发；3）具体改法。不要评价代码风格，不要给「建议加注释」这类意见。

```
[粘贴代码]
```

列出可能性排序 + 每种怎么验证

我在 [技术栈与版本] 上遇到这个报错。[已尝试过的方法]。请：1）按可能性从高到低列出原因；2）每条给出验证方法（一条命令或一段最小复现代码）；3）不要重复我已经试过的；4）如果信息不足以判断，直接告诉我需要补充什么。

```
[粘贴报错与堆栈]
```

针对这条查询，不要通用建议

你是数据库专家。这条 SQL 在 [表名，约 X 万行] 上执行需要 [耗时]。请：1）指出最可能的瓶颈（看执行计划）；2）给出优化后的 SQL；3）说明需要加什么索引，以及加了之后可能的副作用（写入变慢/空间占用）。不要给我「避免 SELECT *」这类通用建议。

```sql
[粘贴 SQL]
```

按数据流讲，而不是逐行翻译

解释下面这段代码。要求：1）先用一句话说它整体在干什么；2）按数据流讲：输入从哪来、经过哪些变换、输出到哪去；3）标出 2–3 个最容易看错的地方；4）指出任何看起来多余或可疑的代码。不要逐行翻译语法。

```
[粘贴代码]
```

在写代码之前，先找出设计漏洞

这是我的接口设计：[粘贴设计]。请以审查者的身份挑刺：1）列出 5 个最可能在实现时出问题的点；2）指出哪些字段是冗余的、哪些缺失会导致客户端二次请求；3）给出向后兼容的修改建议；4）如果这个设计有明显的更简单替代方案，直接说出来。

连边界情况和反例一起给

帮我写一个正则：匹配 [描述需求]。要求：1）给出正则表达式；2）逐个片段解释含义；3）列出 3 个能匹配的例子和 3 个不该匹配的例子；4）指出这个正则在什么极端输入下会回溯爆炸，以及如何避免。

先假设方案必须被否掉，再决定它值不值得做

你是被拉来评审这次迁移的资深工程师，任务是找出足够充分的理由否决它。请：1）列出会让这次迁移失败的具体条件（数据量、停机窗口、回滚、依赖方配合）；2）指出方案里被当成「到时候再说」的问题；3）给出一个更小的替代路径（先迁一部分、先双写、先只迁读）；4）最后才说明：如果你否不掉它，哪两条必须补上。

[粘贴迁移方案]

从 changelog 里挖出真正会踩到的 breaking change

我要把 [依赖名] 从 [当前版本] 升到 [目标版本]，项目里大约有 [N] 处调用。请：1）列出这两个版本之间所有可能影响我的破坏性变更，只保留真正会被调用到的；2）按「必须改 / 建议改 / 可以不改」分类，每条给出改法；3）给出升级顺序（先升哪个、要不要分两次）；4）指出升级后最可能在运行时才暴露的问题，以及怎么在本地提前验证。

[粘贴 changelog 与依赖配置]

找出没被覆盖的分支，按线上事故概率排序

下面是我的实现和现有测试。请找出测试没覆盖到的地方：1）列出所有分支和边界，标出哪些没有用例；2）按「一旦出错线上影响最大」排序，给出前 5 个应该补的用例（写清输入、预期、为什么容易漏）；3）指出哪些用例其实是重复的、删掉不影响信心；4）有没有哪个测试在断言实现细节而不是行为。

```
[粘贴代码与测试]
```

实体、关系、状态机，以及将来一定会改的字段

把这个需求转成数据模型，先不写代码。输出：1）实体清单，每个实体一句话说明它代表现实中的什么；2）实体间关系与基数，指出哪些是多对多、需要中间表；3）核心对象的状态机（状态、触发条件、不可逆的转换）；4）哪些字段现在看着够用、但半年内大概率要改（价格、权限、多语言、软删除）；5）三处需求里没写清楚、必须先问产品的地方。

[粘贴需求]

找出被吞掉的异常和无法诊断的报错

审查下面这段代码的错误处理。只关注失败路径：1）哪些异常被吞掉或降级成了默认值，出问题时会不会静默出错；2）错误信息是否足以定位（有没有带上关键 id、入参、上游状态）；3）哪些重试是不安全的（非幂等、会重复扣款或重复写入）；4）哪些地方该失败却继续跑，哪些该继续却整个中断；5）给出修改后的关键片段。

```
[粘贴代码]
```

假设两个请求同时到达，逐条走共享状态

审查下面这段代码的并发安全。方法：假设有两个请求在同一毫秒到达，逐个走一遍共享状态。请：1）列出所有共享可变状态（内存变量、缓存、数据库行、文件）；2）指出哪几处存在检查与使用之间的间隙（先查后写）；3）说明在什么并发量下才会暴露，以及暴露时的现象；4）给出最小改法（锁、唯一约束、原子操作、改为幂等），并说明各自的代价。

```
[粘贴代码]
```

一次交付迁移、回滚和校验，先在少量数据上走通

你是负责线上数据迁移的后端工程师。根据下面的表结构和变更目标，输出三部分：1）迁移脚本：分批执行、可重入、每批有上限，避免长事务锁表；2）回滚脚本：说明哪些操作不可逆、回滚后如何核对；3）校验 SQL：在回填后、切换前、回滚前各跑一次，给出预期结果和阈值。先指出方案里最可能丢数据的一步，再给脚本。不要假设可以停机。

[表结构/变更目标/数据量级]

把散落的日志收成一条时间线，分清证据和猜测

你是排查线上故障的工程师。下面是一段时间的日志，可能混有多个服务。请：1）按时间排出事件链，标出第一个异常点；2）把「日志直接证明的」和「你推测的」分两栏列出；3）指出还缺哪条日志才能定论；4）给出下一步最小验证动作。不要从第一条 ERROR 开始讲，先找它之前发生了什么。

[日志片段/时间范围/相关服务]

用最小输入稳定复现，不顺手搭一套测试框架

你是擅长定位边界条件的工程师。为下面这个 bug 写一个最小验证用例：1）只保留触发所必需的输入和状态，能删的都删掉；2）断言具体到「期望值 vs 实际值」，不要只写「不应报错」；3）说明它在修复前必须失败、修复后必须通过；4）如果无法稳定复现，列出还缺的环境条件，不要编造。用现有测试框架的一个文件写完。

[bug 描述/相关代码/运行环境]

假设配置一定会出事，逐项找出默认值、密钥和环境差异的坑

你是负责上线的 SRE，任务是挑刺而不是确认。审查下面的配置和环境变量清单：1）找出所有依赖默认值才能工作的项，并把默认值写出来；2）标出密钥、连接串、超时、重试、并发上限中任一环境不一致就会出事的项；3）列出「本地能跑、线上会挂」的具体路径；4）给一份上线前逐项打勾的检查清单，按风险排序。不要评价格式，不要假设平台会兜底。

[配置文件/环境变量清单/部署环境]

用时间线、根因和可验证的改进项，替代「加强监控」式总结

你是事故复盘的主持人。根据下面的时间线和处置记录，写一份复盘：1）时间线只保留改变系统状态或决策的节点，统一标注时区；2）根因写到「哪个机制缺失、哪条假设不成立」，不要停在「人为误操作」；3）改进项分「已做/待做」，每条有负责人角色、截止时间和验证方式；4）单列「这次运气好的地方」。不要写「加强监控」「提高意识」这类无法验收的项。

[事故时间线/影响范围/处置记录]

按真实查询逐条核对索引，指出冗余、失效和写放大

你是数据库性能评审者。根据下面的表结构、数据量和慢查询，逐条评审索引：1）每个索引对应哪条查询，写出走索引的 WHERE/ORDER BY 片段；2）标出冗余索引（最左前缀已被覆盖）、永远用不上的索引，以及会失效的写法（函数、隐式转换、前导通配符）；3）估算新增索引对写入和存储的影响；4）给出「保留/删除/新增」三栏结论。不要只按字段名猜查询。

[表结构/索引/慢查询/数据量级]

按接口契约切分，让几个人同时动手而不互相等待

你是技术负责人。把下面这个需求拆成可以并行开发的任务：1）先定出不可并行的顺序约束（数据模型、接口契约、迁移）；2）其余任务按「一个人一周内能独立交付」切分，写清输入、输出和验收方式；3）标出依赖方向和最早可开始时间；4）指出哪些共享文件或模块最容易冲突，并给出规避方式。不要按前端/后端这种粗粒度分，按可独立验证的交付物分。

[需求说明/现有系统/团队规模]

列出谁会被影响、哪条链路最脆，以及出事后怎么退

你是这次改动的反对者，任务是找出它可能伤到谁。根据下面的改动说明和系统依赖，输出：1）受影响的调用方、数据、定时任务和下游，逐个说明影响方式；2）按「影响人数 × 恢复难度」排出风险最高的三处；3）指出这次改动依赖但未验证的假设；4）给一份上线顺序和回退方案，包含判断回退的指标阈值。不要用「影响可控」收尾，要给具体证据。

[改动 diff/依赖关系/流量规模]

只保留决策、责任人和时间点

把下面的会议记录整理成纪要。格式：1）用一句话总结这次会议要解决什么；2）已决定的（每条写：决定 + 谁负责 + 什么时候）；3）未决定但有分歧的（写清双方理由）；4）下次会议前要完成的事。删掉所有寒暄和重复。

[粘贴记录]

写给上级看，重点是结果和风险

根据下面这些零散记录写一份周报。结构：1）本周产出的结果（用可验证的事实，不用「推进了」这种词）；2）遇到的问题和我的处理；3）下周计划（最多 3 项，标出优先级）；4）需要你决定或协调的事。全文控制在 300 字内。

[粘贴记录]

结论先行，然后是依据和风险

我要向 [对象] 汇报 [事项]。请按金字塔结构帮我写：1）第一句给结论；2）支撑结论的 3 条依据（每条一句话 + 一个数据/事实）；3）风险与我的应对；4）需要对方做的决定。不要铺垫背景，除非我明确要求。

[背景材料]

把对方可能的反应提前演练一遍

我要和 [对象] 谈 [事情]。我的目标是 [目标]，我最怕的是 [担忧]。请：1）列出对方最可能的 3 种反应，以及每种背后的真实关切；2）针对每种给一句开场白；3）指出我自己的说法里哪句最容易激化；4）给我一个「如果谈崩了」的退路。

把长文档变成可以打勾的步骤

读完下面的文档，生成一份执行清单。要求：1）每一步都可以直接执行，动词开头；2）标注依赖关系（哪步必须在哪步之后）；3）标出 3 个最容易漏掉的步骤；4）如果有需要人决策的分支，单独列出。

[粘贴文档]

先反问再复述，避免做完才发现方向错了

你是一位经验丰富的项目负责人，现在做我的需求澄清搭档。我收到一句很模糊的任务：「[老板/客户的原话]」。先不要给方案。请：1）列出为了动手必须知道、但这句话里没说的信息，最多 6 条，按重要性排序；2）每条给出你猜测的默认答案，并说明猜错的后果；3）用 100 字复述你理解的任务，标出哪些是我的原话、哪些是你补的。

让对方愿意配合，而不是把球踢回来

你是一位擅长跨部门推动的项目负责人。帮我写一封邮件，请 [部门] 在 [时间] 前完成 [具体事项]。背景：[为什么需要，之前和谁沟通过]。要求：1）开头一句说清要对方做什么、什么时候；2）讲这件事对他们的影响，不只讲我的进度；3）列出我已经做完的前置工作，降低对方的成本感；4）给出具体到时间的跟进方式；5）200 字内，不要用「辛苦」「麻烦」开头。

把「什么都会一点」拆成可以筛人的条件

你是招聘负责人，帮我写 [岗位名称] 的 JD。输入：团队现状 [一句话]、这个人来了要解决 [1–2 件事]、预算 [区间]。要求：1）第一段写这个岗位为什么存在，不写公司介绍；2）职责按「他会做的具体动作」写 4–6 条；3）必需项不超过 5 条，每条都能在面试里验证，加分项另列；4）明确写出不接受的画像；5）不出现「抗压能力强」「有责任心」这类无法验证的词。

用证据说话，而不是「感觉还行」

根据我的面试记录写一份候选人评价。岗位关键要求：[粘贴 JD 要求]。面试记录：[粘贴问答]。要求：1）逐项要求给「超过/符合/不符合」，每条必须引用候选人的原话或具体行为作证据；2）单列一段写我拿不准的地方，以及需要补测的问题；3）给出明确结论：推进、再面一轮或拒绝；4）不用「沟通能力强」「有潜力」这类没有证据的形容词。

一次问全，免得来回三轮还没问到价格口径

你是采购负责人，帮我写一封询价邮件给 [供应商类型]。我们要采购 [物品/服务]，数量 [数量]，期望交付 [时间]。要求：1）需求写成清单：规格、数量、交付地点、验收标准；2）要求对方按同一格式报价：单价、税费、运费、付款方式、报价有效期、最小起订量；3）问清三个后期容易加价的点：改单怎么收费、延期怎么赔、质保范围；4）结尾说明我们在对比几家、几号前回复。

先当反对者，再把风险变成可跟踪的表

你是被请来挑刺的项目审计，默认这个项目会延期。项目信息：[目标、deadline、人力、依赖方]。输出一张风险表，列为：风险 / 触发信号 / 影响（时间、成本、质量）/ 概率 / 我方能做的缓解动作 / 责任人。要求：1）至少 8 条，覆盖人力、外部依赖、需求变更、技术不确定性；2）按概率×影响排序；3）只写现在还能干预的，已发生的另列；4）缓解动作必须可执行，不要写「加强沟通」。

从几百条消息里捞出谁在什么时候做什么

把下面的群聊记录整理成行动项。要求：1）只保留有明确动作或结论的消息，闲聊、表情、重复确认全删；2）输出表格：事项 / 负责人 / 截止时间 / 当前状态 / 原话摘要；3）没人认领的事项单独列一节，标「待分配」；4）互相矛盾的说法单独列一节，写清谁说了什么；5）最后列出 3 个必须今天回复的问题。

[粘贴聊天记录]

说清代价，给出选项，不硬顶

把下面这个加急请求改写成一段回复。先确认对方真正要的结果和最晚时间；说明插进来会挤掉哪项已承诺的交付（写到项目和时间）；给出 A/B 两个方案，写清各自代价：延后哪项承诺、缩多少范围、要不要加人；最后请对方在今天内选一个，不回复就按 B 执行。不要用“尽量”“抽空”这类词，道歉不超过一句。

[请求原文]
[当前排期]

用事实和替代方案，不撕破脸

把下面这件事写成给上级的反对意见。结构：1）先复述我理解的目标，确认我们争的是同一件事；2）只放一条可验证的事实或数据，说明我担心什么；3）承认你的方案在什么条件下成立；4）给出替代方案和代价；5）请你在什么时间前决定。对事不对人，全文不超过300字，不用“我觉得”“可能有问题”开头。

[背景]
[上级方案]
[我的依据]

每项能力配一道能追问到底的题

根据下面的JD和岗位级别，设计一场45分钟面试的问题。先列4–5项这个岗位真正要验证的能力，每项不超过8个字；每项给1道主问题和2个追问，主问题必须问过去具体做过什么；为每道题写清“及格/不及格”的回答特征；最后留5分钟给候选人提问。不要问脑筋急转弯、星座或婚育。

[粘贴JD]
[岗位级别]

先讲影响与恢复，再讲原因和补偿

把下面这次事故写成给客户的通报。结构：1）什么时间、哪些功能、影响了谁；2）现在是否恢复、我们做了什么；3）只写已确认的原因，未确认的标“仍在排查”；4）未来72小时的改进动作和负责人；5）补偿方案和下次同步时间。不要甩锅，不要用“个别用户”“系统波动”这类模糊词，全文不超过400字。

[事故时间线]
[影响范围]
[已确认原因]

一页讲清为什么做、怎么算成

把下面的背景整理成一页纸立项。顺序：1）问题（谁、什么场景、损失多大，用数字）；2）不做的后果；3）目标与非目标（各3条以内）；4）方案概要（不超过5步）和最大风险；5）成功指标（基线→目标→观测时间）；6）所需资源和决策点。全文一页，删掉愿景和形容词，不写“提升体验”这种无法验收的目标。

[背景]
[资源约束]

把反复提起却没人接的事落到人

读下面的会议记录，找出被反复提起、却始终没人明确负责的事。用表格输出：1）事项（一句话说清要交付什么）；2）被提起的次数和原话；3）没人接的原因（缺权限/缺资源/职责不清/只是担心）；4）建议归属到具体角色，不写“相关同事”；5）继续无人负责时，最晚什么时候出问题。最后单列一件需要会上当场拍板的事。

[粘贴记录]

按“别人能接手”来列，不按心情列

根据我的岗位和手头工作，生成一份离职交接清单。分四块：1）进行中的事（当前状态、下一步、截止时间、对接人）；2）只有我知道的事（账号、口径、历史决策、外部联系人）；3）文档和权限（Notion 页面、存放位置、移交方式、审批人）；4）交接后的支持边界（最后工作日、可答疑到什么时候）。每项写接收人和验收方式，不要写“已交接”这种无法验证的状态。

[岗位]
[手头工作]
[最后工作日]

把模糊反馈拆成可验收的改动

把下面这句模糊反馈翻译成可执行任务。先列出它可能指的3种具体问题，各配一个可观察的信号；再追问我3个必须回答的问题（目标、现状、验收标准）；然后给出一个默认方案：改什么、不改什么、怎么验证、工作量级。不要直接开始改，也不要把“优化”当成“重做”。

[模糊反馈]
[当前版本/数据]

比喻 → 定义 → 常见误解 → 自测题

用费曼学习法给我讲清楚 [概念]。顺序：1）给一个 10 岁能懂的比喻；2）给出准确定义，并指出这个比喻在哪里不成立；3）说出一个最常见的误解和它为什么错；4）给两道自测题（一道基础、一道容易答错）。

一次只问一个问题，问到你想不到为止

你是苏格拉底式的导师。针对 [主题]，一次只问我一个问题，等我回答后再追问下一层。规则：1）不要给答案；2）当我的回答含糊时，要求我给具体例子；3）当我答错时，用反例让我自己发现矛盾；4）最多问 8 轮，最后总结我卡在哪。

说清边界在哪，而不是罗列定义

对比 [概念 A] 和 [概念 B]。要求：1）各用一句话说清是什么；2）给出 3 个关键差异（维度自行选择并说明为什么重要）；3）举一个「看起来像 A 其实是 B」的例子；4）什么情况下这个区分根本不重要。

先问它到底证明了什么，再看细节

帮我读下面这段论文内容。输出：1）它要解决什么问题；2）方法的核心思想（用大白话）；3）实验证明了什么、没证明什么；4）作者自己承认的局限；5）如果我要复现，最难的一步是什么。不要复述摘要。

[粘贴论文片段]

专门考最容易混淆的地方

根据下面的材料出 8 道题：4 道单选、2 道多选、2 道简答。要求：1）题目只考容易混淆或容易漏掉的细节，不考记忆性的数字；2）每题给答案和一句话解释；3）标出每题考察的能力（记忆/理解/应用）。

[粘贴材料]

先给骨架，再决定哪几章值得细读

我要读《[书名]》，目的是 [解决什么问题]。请：1）用 5 句话讲清全书的主论点，以及论点之间的依赖关系；2）给章节地图，每章一句话说明它在这条链上承担什么；3）标出 2–3 章核心章节和可以跳过的部分，说明理由；4）指出作者只是断言、没有证明的地方；5）给我 3 个读完后应该能回答的问题。

先看清有几块、谁依赖谁，再决定学什么

我要学 [领域/技能]，目标是 [具体用途]。先给一张知识地图，不要展开讲解：1）拆成 4–7 个模块，各用一句话说明它解决什么问题；2）用表格列出模块间的依赖（学 B 之前必须会 A）；3）标出哪 20% 决定 80% 效果，哪些可以后补；4）按我的目标给一条最短路径，并说明这条路径放弃了什么。

让它当反方，只挑错不夸你

下面是我对 [概念] 的理解：[我的表述]。请你当反方，只做一件事：找出我理解错的地方。要求：1）逐句判断「准确 / 不准确 / 含糊」，不准确的指出错在哪；2）指出我混淆了哪两个概念，一句话说清区别；3）给一个按我的理解会推出错误结论的具体例子；4）不要补充我没问的知识，也不要先肯定我。

反过来讲一遍，才知道哪里是真空洞

我要给你讲 [概念]，你当严格的听众。规则：1）我讲完后，你只指出三件事：哪里说错了、哪里跳过了关键步骤、哪里只是背定义没解释；2）每处追问我一个「为什么」，我答不上来就记下来；3）不要替我补答案，等我要求再给；4）最后列出我讲得最含糊的两处，作为下次复习重点。

我开始讲：[我的讲解]

术语、缩写、行话，一次翻干净

下面这段 [领域] 材料里有很多行话。做一张对照表：术语 / 字面意思 / 在这个语境里实际指什么 / 不懂它会漏掉什么。要求：1）只收我可能不懂的，常识词不列；2）容易混淆的近义词单独加一行辨析；3）某个词在行业里有多种用法时，说明是哪一种；4）最后用 100 字把整段话改写成不需要背景知识也能读懂的话。

[粘贴材料]

从边界和输入输出入手，而不是从细节开始

帮我拆解 [系统名称]，例如 [具体例子]。按顺序做：1）先划边界，什么在里面、什么在外面；2）列出输入、输出和它要维持的目标；3）拆成 3–6 个子系统，说明各自职责和彼此接口；4）指出瓶颈或单点故障在哪；5）用一个具体场景走一遍流程，标出我容易忽略的环节。信息不足的地方直接说不确定，不要编。

按周给目标，每周都有可检验的产出

我要在 30 天内学会 [技能]，每天能投入 [X] 小时，目前基础是 [水平]。给一份计划：1）按 4 周分，每周一个明确的能力目标；2）每周列出练习任务和一份可检验的产出（能拿给别人看的东西）；3）标出第几天最容易放弃，以及那时该做什么；4）留 20% 缓冲；5）给一个判断「是否真的学会」的标准，不要用「熟练掌握」这种词。

从现象退到机制，而不是停在「不够细心」

用 5 个「为什么」追这件事的根因：[描述问题现象]。规则：1）每一层只给一个最可能的原因，写成「因为…所以…」一句；2）每层追问后标注证据强度（有数据 / 只是推测）；3）证据不足时不要硬往下推，先给一个一周内能做的核查动作；4）到第 5 层停下，输出完整因果链，并标出哪一层是真正可以动手改的。

前提 → 推论 → 结论，并补上作者没写的那一步

读下面这段文字，把它的论证结构画出来：[粘贴文章或章节]。输出：1）中心结论，一句话；2）前提逐条编号，区分事实陈述和价值判断；3）前提如何推出结论，补上作者省略的隐含前提；4）标出哪一步是跳跃，即结论比前提多说了什么；5）如果我要反驳，最省力的是攻哪一条前提。

定义谁都背得出，边界只有反例说得清

我在学 [概念]，已经知道定义和两个典型例子。请给三个反例，分别对应：1）看起来符合定义，其实不是；2）只在某个条件成立时才算，条件一变就不算；3）常被当作正面例子，实际是边界案例。每个反例说明：差在哪一条定义要素上，以及误判会导致什么后果。

答错不只给答案，还指出你错在哪一步

用下面这份材料出一套诊断式测验：[粘贴材料]。要求：1）先给出理解这个主题的 4–6 个步骤（比如「识别变量 → 选对公式 → 代入单位 → 解释结果」）；2）每步出 1–2 题，题少但要对准该步；3）我答完后，先判断我错在哪一步，再解释这一步为什么容易错；4）同一步连错两题就停下重讲这一步，再继续。

每个转折点，解决的都是上一阶段的瓶颈

把 [领域] 的发展脉络整理成时间线。要求：1）分成 4–6 个阶段，每段标注大致年代和一句话主题；2）每个转折点写清：上一阶段卡在哪、用什么办法解开、代价是什么；3）标出哪些早期方案今天还在用，以及为什么没被淘汰；4）指出当前阶段最可能被推翻的假设。

先给一个好用的类比，再亲手把它拆掉

用类比解释 [概念]，并且必须交代它在哪里失效。要求：1）给一个主类比，说明它对应概念的哪几个要素；2）明确指出失效处，至少两条，并说清失效时会产生什么错误推论；3）再给一个备选类比，说明它在哪个角度更准；4）用一个例子演示：照着主类比推，会在哪一步推错。

从能立刻用上的倒推，砍掉可以先不学的

我要在 [时间] 内用 [技能或工具] 完成 [具体任务]。请给一条最小可行学习路径：1）先写清这个任务的最低完成标准；2）只保留达成标准必需的知识点，按依赖顺序排列；3）每个知识点配一个 15 分钟内能做完的练习；4）明确列出「现在可以不学」的部分和理由；5）给出判断「已经够用」的检验方法。

把「研究表明」拆成几件可以核查的事

检验这个说法：[粘贴说法或结论]。请：1）把它拆成可以用数据证伪的具体命题；2）指出支撑它需要什么数据（样本、时间范围、对照组），以及现有说法缺了哪一项；3）区分相关与因果，给出至少一个替代解释；4）评估来源强度（一手研究／二手报道／厂商材料／无出处）；5）给出核查清单：我去哪里能查到这些数据。

中文描述 → 结构化英文提示词

把下面这句中文描述扩写成一段英文绘图提示词。结构：主体与动作 → 材质与环境 → 风格 → 光线 → 构图与镜头 → 画幅参数（--ar）。要求：具体到可以画出来，不要用「好看」「高级」这类词。

[中文描述]

从可用性角度挑问题，不谈「好不好看」

这是我的界面设计描述：[描述]。请以可用性评审的角度列出问题：1）信息层级是否清晰，用户第一眼会看到什么；2）主要操作是否容易被找到；3）哪些地方需要用户回忆或猜测；4）空状态、错误状态、加载状态分别怎么设计。不要评价配色是否好看。

让接手的开发者不用问你就知道怎么做

把下面这个需求写成设计说明（不含代码）。包含：1）用户要完成的动作，按步骤；2）每一步的界面元素与状态；3）异常与边界情况；4）不做什么（明确的排除项）；5）验收标准。

[粘贴需求]

把「我要高级感」翻译成可执行要求

我要做 [东西]，给设计师提需求，但我不懂设计术语。请帮我写一份视觉需求书：1）这个设计的用途和受众；2）我希望传达的感受（用 3 个形容词 + 具体参照物）；3）必须出现的元素；4）绝对不能出现的元素；5）交付物清单与尺寸。

把一张喜欢的图拆成能复现的提示词，而不是只存个链接

这是我找到的参考图：[图像描述或直接附图]。请反推出能复现这种风格的提示词：1）拆解画面构成——主体与材质、光源方向与色温、镜头与景深、构图重心落在哪；2）提取风格线索——笔触或质感、接近的流派与媒介、后期处理痕迹；3）按「主体→环境→风格→光线→镜头→参数」写成一段英文提示词；4）列出 3 个最容易画歪的特征，以及对应的负向提示词；5）给一份验收清单：生成结果里必须出现哪些特征才算复现成功。不要只堆形容词。

不给色号，给一套能推导、能调整的配色规则

我要给 [产品/页面] 定配色，但不想只拿到几个色号。请给一套可推导的方案：1）先排定这套颜色要服务的目标（可读性、情绪、品牌识别），并说明排序理由；2）解释主色为什么是这个色相，依据是什么；3）给出中性色的层级逻辑——背景、卡片、分割线、次要文字各差多少明度；4）规定强调色的使用配额，一屏最多出现几次、只准用在什么元素上；5）给出切换深色模式时的调整规则。不要用「高级灰」这类没法执行的词。

没有数据、加载失败的时候，界面到底该说什么

帮我写 [页面/功能] 的空状态与错误状态文案，分五个场景：1）首次使用、还没有数据；2）筛选后无结果；3）失败但可重试；4）没有权限；5）网络中断。每个场景给三样：主文案（12 字内，说清发生了什么）、辅助说明（说清为什么、下一步做什么）、按钮文案（动词开头）。规则：不要把责任推给用户，不说「出错了」这种没信息量的话，不卖萌，不用感叹号。最后标出哪些场景可以直接复用同一套文案。

数清用户在一张表单上要记住和决定多少事

这是我的表单设计：[字段清单与分组]。请从认知负担角度审查：1）数出用户需要同时记住的信息有几项，超过 3 项的位置在哪；2）哪些字段可以推迟、合并，或由系统侧带出；3）哪些选项必须去别处查资料才能填；4）报错在什么时机出现，会不会让已填内容丢失；5）把字段按「必填 / 可后补 / 可删除」重新分类。最后给出一版精简后的字段顺序，并说明删掉的每个字段由什么替代。

把「年轻、专业、有温度」变成能做取舍的句子

我们的品牌调性是：[三个形容词 + 一段描述]。请转成 4 条设计原则，每条必须：1）写成一句能用来做取舍的话，例如「宁可少一个入口，也不让主操作需要找」；2）配一个正例和一个反例，具体到界面元素；3）指出它会和哪条其他原则冲突，冲突时谁优先；4）说明这条原则最容易被误用成什么样。不要输出形容词清单，也不要写「以用户为中心」这种谁都能说的话。

找出这套图标里线宽、圆角、体量不一致的那几个

这是我界面里用到的图标：[图标列表或截图]。请检查一致性：1）线宽是否统一，换算到同一尺寸下差了几个像素；2）圆角与端点的处理是否一致；3）视觉重量是否均衡，哪个在同尺寸下显得过重或过轻；4）隐喻是否统一，同一个概念有没有用了两种画法；5）指出必须重画的 2–3 个，并给出重画时的规格（画布、线宽、圆角、留白）。不要评价图标好不好看。

把间距、字号、层级写成开发不用猜的规格

把这份设计标注成开发能直接用的规格：[设计描述或截图]。要求：1）定义一套间距刻度（如 4/8/12/16/24/32），并说明本页只用了其中哪几档；2）按区块列出外边距、区块间距、元素内边距、文字与图标之间各是多少；3）标出字号、行高、字重的层级关系，以及哪些文案允许换行、换行后怎么对齐；4）指明哪几处必须精确、哪几处可以弹性；5）给出窄屏时的取值变化。不要只说「间距保持统一」。

从一堆抱怨里提炼该改什么，以及哪些不该照做

下面是用户反馈原文：[粘贴反馈]。请转成设计改动清单：1）先合并成不超过 6 类问题，每类注明出现次数；2）区分用户说的和用户实际遇到的，标出哪些是表述问题、哪些是流程问题；3）每条给一个改动动作，并注明改的是界面、流程还是文案；4）按「影响人数 × 修改成本」排序；5）列出哪几条建议不该照做，理由是什么。不要直接把反馈当需求，也不要因为有人喊得响就排前面。

把「这张图好看」拆成网格、层级和密度上能照做的规则

这是我喜欢的参考图：[附图或描述]。我要的不是复刻这张图，而是把它拆成能用在别的页面上的规则。请分六层提取：1）网格与版心；2）间距节奏，用 4 或 8 的倍数标注；3）字号层级与行高；4）色彩角色，背景、表面、文字、强调各占多少面积；5）圆角、描边、阴影的取值；6）信息密度，每屏几个视觉块。每条规则写成可执行的数值或条件句。另外标出哪些只是这张图的偶然，比如照片内容、文案长度，不能当规则。最后用这些规则描述一个内容完全不同的页面。

按用户来这一页的唯一任务，重排首屏的信息优先级

这是我的页面：[截图或内容清单]。请评审首屏的信息优先级：1）列出首屏实际可见的元素，按面积和对比度排出它们当前的视觉权重；2）判断用户来这一页的唯一任务是什么，指出第一眼该落在哪个元素上，只能有一个；3）指出哪些元素在抢注意力但不需要，比如装饰、重复入口、运营位；4）用尺寸、对比、位置、留白四个杠杆给出一版重排，标注每项改动；5）做一次遮挡测试：只允许保留 3 个元素，留哪三个，为什么。不要用「更清晰」这类词。

把网格、线宽、圆角定成数字，让后面 20 个图标不用再讨论

我要为 [产品] 定一套图标规范，接下来会画 20 个以上，可能外包。请写一份能直接执行的规范：1）画布与活动区，例如 24×24 画布、20 活动区、四周各 2 出血；2）线宽取值，以及缩放时是否跟着改；3）圆角与端点处理；4）视觉重量补偿，圆、方、三角在同尺寸下怎么调；5）命名与导出，含尺寸、格式、深色模式变体；6）验收清单 5 条，每条可勾选。最后给出「正确 / 错误」各一例的文字描述，说明最容易画错的地方。不要写「简洁统一」这类形容词。

用户点下「新建」之后那 400 毫秒，界面该发生什么

场景：列表页首次为空，用户点了「新建」并提交。请设计从空状态到有内容的过渡：1）状态序列有哪些，空、提交中、骨架、局部出现、完整；2）每段的时长与缓动，总时长控制在 400ms 内；3）怎么避免布局跳动，包括预留高度、骨架尺寸与真实内容一致；4）焦点和滚动位置怎么处理；5）无障碍，prefers-reduced-motion 下改成什么、要不要 aria-live；6）这条过渡要让用户确认哪三件事。最后给一张时序表，标出每一步用户看到什么。

别修用户说的那个东西，修他真正撞上的那个

用户原话：「[粘贴投诉]」。不要直接照做。请这样拆：1）分三栏写下「他说的 / 他实际做的 / 他实际遇到的」；2）列出 3 个可能的界面原因，按可能性排序，每个注明依据；3）对最可能的那个给最小改动，并说明改的是文案、控件还是流程；4）指出如果照字面改会引入什么新问题；5）给一个验证方式，看哪个指标、观察多久算有效；6）写一句回给用户的话，不承诺做不到的事。

逐项量出深色界面的对比度、发光和层级问题

这是我的深色模式配色：[色值或截图]。请评估可读性风险，逐项给数值：1）正文、次要文字、占位符、禁用态与各自背景的对比度，标出低于 4.5:1 的；2）背景用纯黑还是 #121212 这类抬升面，给取舍理由；3）哪些高饱和色在深底上会震动，需要降饱和或提亮；4）阴影在深色里几乎不可见，层级改用什么表达；5）图片、白底插图、1px 分隔线的处理；6）连续阅读 10 分钟以上的疲劳点。最后给一版修改后的色板。

逐字段做删除审判，而不是把表单压缩得更挤

这是我的表单字段：[字段清单与用途]。逐个字段做删除审判，每个回答四问：1）去掉它，用户还能不能完成任务；2）这个信息能不能从别处拿到，比如账号、上次填写、设备、第三方；3）晚点再问行不行，放进设置、第二次登录或结果页；4）它换来什么，合规、风控、个性化还是运营，值不值多一次放弃。然后给出四栏结论：必删、可合并、可后置、必须保留。最后写删减后的字段数和顺序，并估计完成率会怎么变。不要为了少而少。

拆成对比度、点击区、竞争元素和位置四项，逐项验收

我的主按钮在 [页面] 上被反馈「不够明显」。请把它拆成可测量的项：1）按钮文字与底色的对比度、按钮与页面背景的对比度，各给当前值和目标值；2）点击区尺寸，是否达到 44×44；3）同屏有几个元素比它更亮、更大或更饱和，列出来；4）它在用户扫描路径上的位置，是第几个视觉落点；5）这一屏是否只有一个主操作。给 3 个改动方案，每个标明只改了哪个变量、预期效果、怎么验证，比如首次点击时间、任务完成率。不要只说加大加粗。

只找最可能错的地方，不补充优点

下面是我的判断：[我的结论]。请只做一件事：找出这个判断里最可能错的地方。要求：1）给出至少一个反例或反数据；2）指出我可能遗漏的变量；3）说明如果这个判断错了，最早会在什么时候暴露。不要安慰我，也不要补充优点。

给维度、最坏情况和适用条件

帮我在 [方案 A] 和 [方案 B] 之间做选择。要求：1）列出 4 个对比维度并说明为什么这四个重要；2）各自的最坏情况是什么、能不能承受；3）什么条件下选 A、什么条件下选 B；4）结合我的情况 [我的约束] 给出一个明确建议，不要说「各有优劣」。

假设已经失败了，倒推原因

假设 [项目/计划] 半年后彻底失败了。请写一份事后复盘：1）最可能的 5 个失败原因，按概率排序；2）每个原因现在的早期信号是什么；3）哪些原因是可以现在就预防的；4）如果只能做一件事降低失败概率，是哪件。

找出结论里没说出口的前提

下面是我的推理：[推理过程]。请：1）列出这段推理里所有隐含假设（没说出口但必须成立的前提）；2）标出哪个假设最脆弱；3）如果那个假设不成立，结论会怎样变化；4）我还需要什么信息才能更确定。

同一个数字，换个口径就是另一个故事

我看到的说法是：[结论 + 数据]。请只做一件事：拆它的统计口径。1）指标的分子和分母分别是什么，有没有把不该算的算进去；2）时间窗口怎么选的，换个窗口结论还成立吗；3）样本是谁，谁被排除在外；4）用的是均值、中位数还是百分比，换一种会怎样；5）有没有幸存者偏差，或者分母缩水造成的假增长。最后补一句：这个数字最容易被怎样误读。不要评价结论对错。

两件事一起变，不代表一件推动了另一件

我认为 [A] 导致了 [B]，依据是：[观察到的相关性或数据]。请证伪这个因果判断：1）列出至少 3 个能同时解释 A 与 B 的第三变量；2）指出反向因果的可能，也就是 B 导致 A 的路径；3）说明这个相关性在什么条件下会消失；4）给出一个能区分因果与相关的检验方法，以及需要哪些数据；5）如果只能拿到现有数据，我的结论最多能说到什么程度。不要先肯定我的判断。

开始之前，先定好什么情况下该停

我准备做 [方案]，计划投入 [时间/钱/人力]。请在开始前帮我定退出条件：1）列出 3–5 个可观测的信号，出现就说明方向不对；2）给每个信号设定检查时点、阈值和判定人；3）区分「暂时不顺」和「方向错了」，各给一个具体例子；4）说明退出时怎么保住已经投入的部分；5）给一个「不停但缩小规模」的中间选项。不要给鼓励，也不要假设我会执行到位。

没有数据也能给出量级，并说清哪一步最虚

帮我估算 [问题，例如：这个城市一天卖出多少杯咖啡]。要求：1）拆成 3–5 个可以单独估的因子，写成乘法或加法关系；2）每个因子给出取值、依据和上下限；3）算出结果，并给出量级范围而不是一个精确数；4）标出哪个因子对结果影响最大、最不可靠；5）说明要把误差缩小一半，应该先去查哪个数。不要给精确到个位的假答案，也不要省略推导。

分清哪些决定能撤回，哪些撤不回

这是我的计划：[计划内容]。请找出里面最贵的不可逆部分：1）逐项标注每个决定属于可逆、有成本可逆，还是不可逆；2）对不可逆的那几项，说明撤回的代价具体是什么——钱、时间、关系还是机会；3）指出哪些决定其实能拆成两步，先做小规模的可逆版本；4）给出执行顺序建议：先做哪些，把哪些尽量往后拖；5）哪一项判断错了会让整个计划没法继续。

列出你甚至没想到要问的问题

我要做 [事情]，目前的理解和信息是：[现状描述]。请只列出我不知道自己不知道的东西：1）这个领域里外行通常会漏掉的 5 个关键变量；2）哪些问题我甚至没想到要问，但一问就会改方案；3）我描述里的哪些词是含糊的、各方理解可能不同；4）如果让做过这件事的人看我的计划，他最可能先追问哪三个问题；5）按「会不会推翻方案」排序。不要总结我已经说过的内容。

不是稻草人，是对方最好的那个版本

我的立场是：[立场]。请为反方写出最强版本，强到我会觉得难反驳：1）先用对方的话语体系重述我的立场，确认没有曲解；2）给出 3 条最有杀伤力的反对理由，每条带证据或机制，而不是态度；3）指出我的立场在什么条件下确实成立，再说明那些条件为什么可能不成立；4）标出反方版本里最薄弱的一环，方便我回应；5）判断这场分歧属于事实之争、价值之争还是利益之争。

把混在一起的一段话拆成三种成分

下面这段话里事实、推断和偏好混在一起：[粘贴文本]。请逐句拆开并标注：1）事实——可被第三方独立验证的；2）推断——由事实推出但可能出错的，写出推理链；3）偏好——价值判断或立场，本身无对错。然后回答：4）哪一句被当成事实使用，其实是推断或偏好；5）哪些推断只要补一个数据就能验证；6）给一个只保留事实、去掉修饰的版本。

用最省力的检验，先把结论打掉

我的结论是：[结论]。请只做一件事：找出证明它不成立的最短路径。要求：1）给 1–3 个最省力的检验，每个都要能在 [时间/预算] 内做完；2）每个检验写明「出现什么结果就说明结论不成立」；3）按「成本最低、最能一票否决」排序；4）指出哪个检验做完后，其余可以不做；5）如果我只能做一个，做哪个。不要论证它为什么成立。

拆到每个子问题都能用是/否或一个数字回答

我的大问题是：[问题]。请把它拆成一组能独立验证的小问题。要求：1）拆成 4–6 个，每个都必须能用「是/否」或一个数字回答；2）每个写明需要什么数据、从哪拿、大概多久；3）标出哪几个一旦答「否」，大问题就不用再问；4）按「信息量 ÷ 成本」排序，给出先查的三个；5）指出我混在一起的两种问题：事实问题和选择问题，分别归到哪边。不要先回答大问题。

同一个词，在两句话里不是同一个意思

下面这段论证是：[论证原文]。请找出其中的偷换概念：1）列出反复出现的关键词，逐个标出它在每句话里的实际含义；2）指出哪一步从含义 A 滑到了含义 B，把两句原文并排引出来；3）说明这个滑动让哪句结论显得成立；4）把概念钉死成一种含义，重写这段论证；5）重写后还成立吗，如果不成立，缺的是哪一步。不要评价文风。

只查估算偏低的部分，不评估值不值得做

我对这个方案的估算是：[总成本/工期]。请只查一件事：这个估算是不是系统性偏低。1）列出通常被漏掉的成本项：沟通、迁移、返工、培训、合规、维护、机会成本；2）逐项给量级和依据，不要只写「可能有」；3）指出同类项目里最常超支的是哪一项、通常超多少；4）区分一次性成本和持续成本，后者按年折算；5）给出一个保守值和一个最坏值，并说明差在哪一步。不要评价这个方案值不值得做。

先看波动区间，再谈趋势

我看到 [指标] 最近 [变化]，判断这是 [趋势]。请只回答一个问题：这是噪声还是信号。1）这个指标的历史正常波动区间是多少，当前变化相当于几个标准差；2）手上有几期数据，够不够判断趋势；3）有没有一次性事件、口径变更、季节性在起作用；4）如果只是噪声，通常多久会自己回落；5）要确认是信号，最少还需要什么证据、等到什么时候。最后给一句「现在最多能说到什么程度」。

按「推错了能不能退」排序，再决定先后

我要做的决定是：[决定]。请先把里面不可逆的部分挑出来并排序。要求：1）逐项标出哪些动作一旦做了就退不回，退回的代价具体是什么；2）每个不可逆动作会锁死哪些后续选项；3）在推开它之前，能拿到的最便宜的信息是什么，比如试点、试单、报价、小范围灰度；4）给出顺序：哪些必须现在推，哪些可以拖到信息更多时再推，各自的最晚时点；5）哪一个推错了会让整个决定不成立。不要评估这个决定该不该做。

先写错法，再写发现后 24 小时做什么

我的判断是：[判断]，已经据此投入 [已花的钱/时间/承诺]。请写一份「如果我错了」的预案：1）列出 3 种最可能的错法，按「概率 × 损失」排序；2）每种错法最早能观测到什么信号，在多长时间内出现；3）发现后 24 小时、一周、一个月分别做什么；4）哪些东西现在就该提前准备：退路、预算、对外话术；5）哪一步拖过某个时点就救不回来，那个时点是哪天。不要安慰我，也不要说「大概率不会错」。

拆自己的理由，看去掉偏好后还剩下什么

我倾向于选 [选项]，理由是：[我的理由]。请把我这份理由拆成两栏：事实和偏好。1）逐条标注，事实要能被第三方独立验证，偏好是价值排序或立场；2）指出哪些「事实」其实是偏好的包装，比如把「我更熟悉」说成「更稳妥」；3）去掉所有偏好项后，事实还支持这个选择吗；4）我的偏好之间有没有互相矛盾，比如既要快又要稳；5）列出偏好一旦改变、结论就会翻转的那一条。不要替我选。