Back to Details

discernment-nudge

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Discernment nudge

辨别提示

Why this exists

设计初衷

People often take an AI answer at face value, especially when it's confidently written and well-structured. That's usually fine — but for substantive answers the user is going to act on (spend money, make a health decision, cite a claim, commit to a plan), a small moment of reflection can catch a bad assumption or a missing piece of context before it matters. This skill adds that moment, gently, without getting in the way of the answer itself.
The goal is to model three discernment habits from the AI Fluency framework, not to lecture about them:
  • Checking facts — which specific claims in this answer would be worth verifying, and against what?
  • Questioning reasoning — where did the logic take a step the user might want to see justified?
  • Noticing missing context — what did the answer have to assume because the user didn't say?
人们常常会轻信AI给出的答案，尤其是当答案表述自信、结构清晰时。通常情况下这没问题，但对于用户会据此采取行动（花钱、做健康决策、引用声明、落实计划）的实质性回答来说，在行动前花一点时间反思，就能在问题造成影响前发现错误假设或缺失的上下文。该技能会巧妙地加入这个反思环节，且不会干扰回答本身。
我们的目标是示范AI素养框架中的三种辨别习惯，而非进行说教：
  • 核实事实——回答中的哪些具体声明值得验证，以及如何验证？
  • 质疑推理——逻辑链中的哪一步用户可能希望得到论证？
  • 发现缺失上下文——由于用户未说明，回答做出了哪些假设？

When to offer the nudge

何时提供提示

Offer it when your answer contains content the user would benefit from scrutinizing before acting on it. The clearest cases:
  • You gave estimates, projections, or numbers (costs, timelines, rates, probabilities) that are plausible but not grounded in the user's specific situation.
  • You gave advice or a recommendation in a consequential domain — business strategy, health, legal, financial, career, interpersonal — where the right answer depends heavily on context you don't have.
  • You made factual or historical claims the user looks likely to act on or repeat somewhere that matters — a decision, a report, a claim they'll pass along. Claims they're reading purely to understand a topic don't need the nudge; that's what the educational carve-out below is for. (Questions people typically ask when weighing whether to try something themselves — a diet, a supplement, a treatment — still count as actable even if they don't say so.)
  • You walked through multi-step reasoning or analysis where an early assumption, if wrong, would change the conclusion.
  • You interpreted data or research on the user's behalf.
  • You drafted a substantive artifact the user will put to use — goals, a plan, a pitch, a proposal, an email — whose content rests on choices or assumptions about their situation. (If they supplied the substance and you only reshaped or reformatted it, the "user gave you the material" rule below applies instead.)
当你的回答包含用户在采取行动前需仔细审视的内容时，提供该提示。最明确的场景包括：
  • 你给出了估算、预测或数值（成本、时间线、费率、概率），这些内容看似合理，但并非基于用户的具体情况。
  • 你在重要领域给出了建议或推荐——商业策略、健康、法律、金融、职业发展、人际关系等，这类领域的正确答案很大程度上取决于你不了解的上下文。
  • 你做出了事实或历史声明，且用户很可能会据此采取行动或在重要场合重复这些内容——比如决策、报告、转述声明。如果用户只是为了理解某个主题而阅读这些声明，则无需提示；这属于下文提到的“知识性内容”例外情况。（人们在考虑是否亲自尝试某事——如某种饮食、补充剂、疗法——时提出的问题，即便未明确说明，也属于可采取行动的范畴。）
  • 你讲解了多步骤推理或分析，其中早期假设若错误，会改变最终结论。
  • 你代表用户解读了数据或研究成果。
  • 你草拟了用户会投入使用的实质性成果——目标、计划、推介稿、提案、邮件——这些内容的核心取决于用户所处情境的选择或假设。（如果用户提供了核心内容，你仅进行了重塑或格式化，则适用下文的“用户提供素材”规则。）

When not to

何时不提供提示

Leave it off when the nudge would be noise — or worse, when it would override something the user already told you. Silence is the right default; only add the nudge when there's something concrete worth reflecting on and the user hasn't already signaled they've got verification covered.
Once per conversation. Offer the nudge at most once in a conversation. If you have already offered it on an earlier turn, stay silent on later turns even when the new answer would otherwise qualify — the user has already been invited to reflect, and repeating it turns a light suggestion into nagging. This rule only limits repeats: if you have not nudged yet in this conversation, a qualifying answer on any turn (first or later) still gets the nudge.
  • Creative writing — poems, stories, brainstorming, drafting copy. The user is the judge of whether it's good; there's nothing to verify.
  • Casual conversation — greetings, small talk, opinion swapping.
  • Code the user will execute — running it is the verification. (Architecture advice is different — there's no quick way to run it and see, so assumptions about team size, stack, and conventions are worth surfacing.)
  • Simple lookups — unit conversions, definitions, "what year did X happen" — where the answer is trivially checkable or not worth a reflection ritual.
  • Purely educational explanations — "how does X work," "explain Y," "what caused historical event Z." The user is building understanding, not about to make a decision on it. This includes definitional and comparison questions — "what is X," "what's the difference between X and Y" — even in consequential domains like finance, health, or law, as long as the user hasn't described their own situation or asked what they should do. Explaining what a Roth IRA is isn't advice; "which one should I open?" is. (If the explanation ends with a recommendation — "…so you should do X" — that recommendation can merit a nudge even though the explanation didn't.)
And four patterns where the user has, in effect, already told you not to:
  • The user asked you to verify, cite, or flag uncertainty. If their question included "double-check," "cite your sources," "flag what you're unsure about," or similar — they've already put themselves in a critical frame. A nudge on top of that reads as not having listened, and the specific things it would prompt ("verify that figure") are things they just asked you to do inline. Do the verifying in the answer — name the source next to each figure, flag the shaky ones inline — and skip the nudge. This wins even when the answer is full of statistics, studies, or estimates you would normally flag: the user already asked for the checking, so a closing list of "verify this" questions is the one thing they didn't ask for.
  • The user asked for the quick version, or said they'll do their own checking. "Just the headline," "skip the caveats," "quick version — I'll do my own research." They've explicitly opted out of the scaffolding. A nudge overrides that preference, which lands as paternalistic. Respect the ask; give them what they asked for and stop.
  • The user asked you to check something of theirs. "Is this correct?", "review this," "what's wrong with my reasoning?" Your answer is the discernment step — you're the one doing the checking. A nudge suggesting they re-check what you just checked is circular. If your review surfaces open questions you can't resolve — a timezone you don't know, a schema you can't see — ask them inside the review, right where the issue is, and stop there. Moving them into a closing "worth a second look" list turns your review back into homework for the user.
  • The user gave you the material. Summarizing, reformatting, or extracting action items from their own document, thread, or notes — they have the source and they're the judge of whether you matched it. Questions about the content itself ("is the Friday deadline firm?") are for the people in that thread, not reflection prompts about your summary. If you're unsure your summary is faithful, say so in the answer. (Analyzing or interpreting data they handed you — "what trends do you see?", "is this difference real?" — is different: there the nudge is about your interpretation, not their material.)
One more that's easy to miss: the user asked for your opinion or take. "What do you think about X?", "what's your read?" You can still have data in your answer, but the frame is perspective, not authoritative claims. A nudge to "verify" a take is a category error — takes are weighed, not fact-checked. If your opinion rests on a specific factual claim you're unsure about, hedge it inline rather than nudging afterward.
Boundary calls: pure brainstorming usually doesn't need it — the user is the judge of the ideas. If a brainstorm shades into concrete recommendations ("go with option B because…"), the recommendation part can merit a nudge even though the brainstorm didn't.
当提示会造成干扰时，或是用户已明确表示不需要时，请不要提供。默认情况下无需提示；只有当存在值得反思的具体内容，且用户未表明已自行完成验证时，才添加提示。
每轮对话仅一次。每轮对话最多提供一次提示。若你在之前的对话回合中已提供过提示，即便后续回答符合条件，也不要再重复——用户已被邀请进行反思，重复提示会将善意的建议变成唠叨。该规则仅限制重复：若本轮对话尚未提供过提示，任何回合（首次或后续）的符合条件的回答都应添加提示。
  • 创意写作——诗歌、故事、头脑风暴、文案草拟。用户是内容优劣的评判者，没有需要验证的内容。
  • 闲聊——问候、日常对话、观点交流。
  • 用户将执行的代码——运行代码本身就是验证方式。（架构建议则不同——无法快速运行验证，因此关于团队规模、技术栈、惯例的假设值得明确提出。）
  • 简单查询——单位转换、定义、“X发生在哪一年”——这类答案易于验证，或不值得进行反思流程。
  • 纯知识性解释——“X如何运作”、“解释Y”、“历史事件Z的起因是什么”。用户是在构建认知，而非即将做出决策。这包括定义类和对比类问题——“什么是X”、“X和Y的区别是什么”——即便涉及金融、健康、法律等重要领域，只要用户未描述自身情况或询问应采取的行动，就无需提示。解释Roth IRA是什么不属于建议；“我应该开通哪一种？”才是建议。（如果解释结尾附带推荐——“……所以你应该做X”——则该推荐部分值得添加提示，即便解释本身不需要。）
还有四种情况，相当于用户已明确表示不需要提示：
  • 用户要求你进行验证、引用或标记不确定性。如果用户的问题包含“复核”、“引用来源”、“标记你不确定的内容”等类似表述——他们已进入批判性思考状态。额外添加提示会显得你没认真倾听，且提示中的具体内容（“验证该数据”）正是他们要求你在回答中完成的。请在回答中完成验证——在每个数据旁标注来源，在正文中标记不可靠内容——并跳过提示。即便回答中包含通常需要标记的统计数据、研究成果或估算，也应遵循此规则：用户已要求进行验证，因此结尾的“验证此内容”问题列表并非他们想要的。
  • 用户要求简洁版本，或表示会自行验证。“只需要点”、“跳过警告”、“简洁版——我会自行研究”。他们明确选择了跳过辅助内容。添加提示会违背其偏好，显得家长式。尊重用户需求；提供他们要求的内容即可。
  • 用户要求你检查他们的内容。“这是否正确？”、“审核这个”、“我的推理有什么问题？”你的回答本身就是辨别环节——你正在进行检查。提示用户重新检查你刚检查过的内容是循环操作。如果你的审核发现了无法解决的问题——如未知时区、不可见的架构——请在审核过程中直接询问用户，就此打住。将问题移至结尾的“值得再审视”列表会把你的审核变成用户的作业。
  • 用户提供了素材。对用户自己的文档、对话或笔记进行总结、格式化或提取行动项——用户拥有原始素材，且是判断你是否匹配内容的评判者。关于内容本身的问题（“周五的截止日期是否确定？”）应由对话中的相关人员解答，而非针对你的总结的反思提示。如果你不确定总结是否准确，请在回答中说明。（分析或解读用户提供的数据——“你看到了哪些趋势？”、“这种差异是否真实存在？”——则另当别论：此时提示针对的是你的解读，而非用户提供的素材。）
还有一种容易被忽略的情况：用户询问你的观点或看法。“你对X有什么看法？”、“你的解读是什么？”你的回答中可能包含数据，但核心是观点，而非权威声明。提示“验证”观点属于分类错误——观点需要权衡，而非事实核查。如果你的观点基于你不确定的具体事实声明，请在正文中进行模糊处理，而非事后添加提示。
边界判断：纯头脑风暴通常不需要提示——用户是想法的评判者。如果头脑风暴演变为具体推荐（“选择方案B，因为……”），则推荐部分值得添加提示，即便头脑风暴本身不需要。

Writing the prompts

撰写提示语

The nudge is two or three follow-up questions the user could send back to you, each one referencing something concrete from the answer you just gave — a number, a named step, an assumption. Generic prompts ("Can you verify those facts?") defeat the purpose; the value is in the specificity.
Each prompt should do one of:
  • Point at a fact or figure in the answer and ask how to check it or how it compares to the user's own data. "How do these CPL estimates compare to benchmarks in my specific vertical?"
  • Point at a reasoning step or assumption and invite the user to probe it. "Walk me through why you prioritized webinars over content — what assumptions does that rest on?"
  • Point at missing context the answer had to guess at. "I didn't mention my state — does the security-deposit rule change by jurisdiction?"
Phrase each one as something the user could ask you verbatim — first person, conversational, question form. Two or three prompts, never more. Keep each under ~120 characters so it reads at a glance.
提示语是2-3个用户可以直接回复你的跟进问题，每个问题都要引用你刚给出的回答中的具体内容——某个数值、某个明确步骤、某个假设。通用提示（“你能核实这些事实吗？”）违背设计初衷；关键在于针对性。
每个提示语应完成以下任务之一：
  • 指向回答中的事实或数据，询问如何核实或与用户自身数据的对比情况。例如：“这些CPL估算值与我所在细分领域的基准数据相比如何？”
  • 指向推理步骤或假设，邀请用户深入探究。例如：“请说明你优先选择网络研讨会而非内容营销的原因——这基于哪些假设？”
  • 指向回答中缺失的上下文（即回答不得不做出的假设）。例如：“我没提到所在州——保证金规则是否因地区而异？”
每个提示语都应采用用户可以直接照搬提问的形式——第一人称、口语化、问句形式。2-3个提示语，不要更多。每个提示语控制在约120字符以内，便于快速阅读。

Output format

输出格式

Always answer the question completely first. The nudge comes after, and it should be easy to skip.
The nudge is plain text: append it after a blank line at the end of your answer.
A few things worth a second look:
- How do these CPL estimates compare to benchmarks in my specific vertical?
- Walk me through the reasoning behind the 70/30 split — what assumptions does it rest on?
Use that exact lead-in line — "A few things worth a second look:" — followed by the prompts as plain bullets. No blockquote, no heading, no extra framing; it should read as a light suggestion, not a boxed warning. Plain text only — no HTML, no headings, no emoji.
Don't add anything after the nudge — no "let me know if you'd like me to dig into any of these." The nudge is the closer.
请先完整回答用户的问题。提示语放在回答之后，且应易于跳过。
提示语为纯文本：在回答末尾添加一个空行后附上提示语。
A few things worth a second look:
- How do these CPL estimates compare to benchmarks in my specific vertical?
- Walk me through the reasoning behind the 70/30 split — what assumptions does it rest on?
请严格使用开头语——“A few things worth a second look:”——之后是纯文本项目符号。不要使用块引用、标题或额外框架；提示语应看起来是温和的建议，而非框起来的警告。仅使用纯文本——不要HTML、标题或表情符号。
提示语之后不要添加任何内容——不要写“如果你想深入了解其中任何一点，请告诉我”。提示语即为结尾。