self-reflextion
自我反思（Self-Reflection）提示词技术：给初学者的系统讲解
自我反思（也常叫 Reflection / Critique / Self-Review）是一类提示词写法：先让模型产出一个“初稿/解答”，再让模型站在“审稿人/质检员/专家复盘”的角度检查缺陷，并据此给出改进版。它本质上是在同一次对话内引入“二次思考与质量控制”的流程，降低遗漏、提升结构与可读性，尤其适合复杂任务。
关键词：先生成 → 再批判/检查 → 再修订（或多轮循环）
1) 它解决什么问题？（通俗 + 要点）
核心作用
- 减少漏项：第一次回答常“够用但不全”，反思可以补齐边界条件、例外、步骤。
- 提升正确性与一致性：能抓到一些自相矛盾、概念混用、推导跳步。
- 改进表达与结构：把“想到哪写到哪”的输出，变成更像交付稿（有标题、要点、结论）。
- 贴近验收标准：把“用户要求/规则/格式”当成检查清单，逐条对齐。
常见实现形态
- Critique-then-Revise（先批判后修订）
输出初稿 → 输出问题清单 → 输出改进稿 - Rubric-based Reflection（按评分标准反思）
给模型一份“评分量表/验收标准”，让它按条打分并修订 - Checklist Reflection（检查清单）
例如：完整性、准确性、可执行性、风险、边界条件、格式等 - Multi-pass Reflection（多轮迭代）
反思—修订循环 2~3 次，直到满足阈值（注意成本与收益）
2) 适合的应用场景（建议用它的地方）
- 长文本写作：方案、报告、论文段落、产品 PRD、投标书、公众号长文
- 需要“符合规范”的交付：固定格式、必须覆盖某些要点（如面试题答案、课程作业）
- 复杂推理/多约束任务：计划制定、系统设计、架构权衡、策略分析
- 代码与工程文档：需求→设计→实现建议→测试点；或代码审查、边界条件检查
- 对外沟通内容：邮件、公告、客服话术（反思可查“语气/风险/歧义”）
- 安全与合规敏感：让模型专门做“风险审查与措辞修订”（但仍需人工最终把关）
3) 不适合 / 容易踩坑的场景（以及原因）
- 强实时、低成本场景：例如即时聊天随口问答
- 反思会增加 token、延迟、费用
- 需要外部事实强校验的任务：如引用最新数据、法律条文、具体论文结论
- 反思并不等于“查证”，模型可能会“自信地修订成更像真的错话”
- 你希望模型不要暴露中间推理且输出要短
- 反思天然更长；可用“仅输出修订结果+简短问题清单”缓解
- 目标很明确、输出很短：例如一句广告标题、一个简单定义
- 反思收益不大，容易过度优化
- 反思提示写得太空：只说“请反思一下”
- 模型会给泛泛而谈的自我夸/自我批，改动不实质
4) 怎么写？一个好用的“自我反思”提示词模板
经典三段式
- 初稿：按任务产出
- 反思/审查：按标准找问题（明确维度/清单/评分）
- 修订稿：根据问题清单重写；要求“修订稿要可直接交付”
你可以这样写（可直接复制）：
提示词骨架
- 任务：……
- 输出要求：格式/长度/受众/风格/必须包含点
- 反思要求：按【清单】逐条检查，列出问题与修改建议
- 修订：输出最终稿；必要时给“改动摘要”
5) 至少 3 个中文实战示例（可复制）
下面给你 4 个例子，覆盖写作、方案、代码、客服话术。你可直接替换括号内内容使用。
示例 1：写一段“产品方案介绍”，先初稿再反思再修订（适合运营/产品）
提示词：
你是资深产品经理。请为【一款帮助大学生背单词的 App】写一段产品介绍文案（200-300字），受众是【大一新生】，语气【轻松但不油腻】。必须包含：
- 解决的痛点；2) 核心功能 3 个；3) 与竞品的差异点 2 个；4) 一个明确的行动号召。
输出分三部分：
A. 初稿
B. 自我反思（质检清单）：按以下维度逐条检查并指出问题：完整性（是否缺项）、具体性（是否空泛）、一致性（是否自相矛盾）、可读性（是否拗口）、说服力（是否有理由/例子）。
C. 修订稿：在不改变事实设定的前提下重写，使其更具体、更有说服力；最后附“改动摘要（3条以内）”。
写法要点：
- 用“必须包含点”避免漏项
- 反思要给明确维度，否则容易空话
- 修订稿要求“可直接交付”
示例 2：项目计划（带风险与验收标准的反思）（适合管理/咨询）
提示词：
你是项目经理。我要在【4周内】完成【公司官网改版】。请先给出一个可执行的计划：按周拆分任务、负责人角色（产品/设计/前端/后端/测试/运营）、里程碑与交付物。
然后进行自我反思：
- 有没有遗漏关键环节（如内容迁移、SEO、埋点、回滚方案、验收标准）？
- 时间是否不合理？哪些任务是关键路径？
- 风险清单（至少5条）+ 对应缓解措施。
最后输出“修订后的最终计划”，并在计划末尾给出“验收清单（10条）”。
写法要点：
- 反思里加入“关键路径、风险、回滚、验收”能显著提高工程可用性
- “最终计划 + 验收清单”就是把反思落实成可执行条款
示例 3：代码/算法题的自我审查（适合程序员学习与面试准备）
提示词：
你是资深后端工程师。用【Python】实现：给定数组 nums 和整数 k，返回和为 k 的连续子数组个数。
输出结构：
- 解题思路（简洁）
- 代码实现（可运行，包含函数与必要注释）
- 复杂度分析
- 自我反思与审查：
- 是否覆盖边界条件（空数组、全负数、k=0、大数）？
- 是否有潜在 bug（哈希表初始化、计数更新顺序）？
- 是否能用一个小例子手算验证？
- 修订版代码：根据审查结果修正；并给出 3 组测试用例（含期望输出）。
写法要点：
- 代码类反思最有效的是“边界条件 + 常见坑点 + 手算验证”
- 强制“修订版代码+测试用例”能避免只说不改
示例 4：客服话术合规与歧义检查（适合对外沟通）
提示词：
你是电商平台的资深客服主管。请为【用户投诉：包裹延迟且外包装破损】写一段客服回复（150字内），要求：
- 表达同理心但不过度承诺
- 提供明确的处理路径（补发/退款/理赔的条件）
- 不使用可能引发纠纷的绝对化用语（如“保证”“一定”“马上”）
输出：
A. 初稿
B. 自我反思：找出可能的歧义、过度承诺、推责、刺激用户情绪的措辞（逐条列出）
C. 修订稿：更稳健、更清晰，保留解决方案的可执行性
写法要点：
- 反思维度要贴近业务风险（过度承诺/歧义/推责）
- “禁用词”约束很实用
6) 常见变体与工程实践建议（让它更稳定）
变体 1：用“验收量表”驱动反思（Rubric）
你提供一个 1-5 分量表，例如：正确性、覆盖度、可执行性、结构、语言。让模型逐项打分，低于 4 分必须修订并说明改动。
变体 2：反思只输出“问题清单”，修订再单独输出
适合你想控制长度，或把“审查”和“改写”分两步做。
变体 3：先让模型“提出检查清单”，再按清单自查
当你不确定该检查什么时很有用：
- 第一步：生成适用于该任务的 checklist
- 第二步：按 checklist 反思并修订
工程建议：如何避免“越反思越胡编”
- 对事实类任务加约束：“不确定就说不确定；不要编造来源；需要引用时请标注需检索”
- 给“可用信息边界”：只允许基于你提供的材料反思
- 引入外部资料（RAG/检索）再反思：先检索→再写→再反思
7) 你可以直接套用的“通用自我反思模板”（精简版）
请完成任务：【……】
输出要求：【格式/长度/受众/必须包含点】然后进行自我反思：按以下清单逐条检查并列出问题与修改建议：
- 是否满足所有硬性要求？
- 是否有事实不确定/推断过度？
- 是否有逻辑跳步/自相矛盾？
- 是否足够具体可执行？
- 是否有更清晰的结构与表达？
最后给出修订后的最终版本，并附 3 条以内改动摘要。
如果你告诉我你最常用的场景（写作/代码/方案/学习/客服/数据分析），我可以把上面的模板改成最适合该场景的一页“固定提示词”，并给你“短版（省 token）”和“长版（高质量）”两个版本。