| name | ai-sanxing |
| description | 三省 AI 身 / 吾日三省吾身：让 Agent 在交付前对自己刚产出的东西做一轮结构化自审，从三个轴上挑刺并修正——一省是否可信（有没有编造、结论有没有据）、二省是否完整（用户的每个诉求是否都覆盖、有没有偷偷丢需求）、三省是否合意（答的是不是用户真正想要的意图，而不是字面）。目的是让最终交付物更可信、更完整、更贴合用户意图，而不是"看起来完成了"。面向任意交付物：飞书文档、报告、方案、邮件、中文写作、代码、结构化数据都适用，不依赖跑测试。当 Agent 即将说"搞定了/已完成/如上"、刚产出一份较重的交付物、用户要求"检查一下再给我 / 认真核对 / 别糊弄 / 交付前自查 / 三省 / 反省一下"时使用。也可显式 /ai-sanxing 调用。不适用于纯闲聊、一行小改、查时间这类没有可审对象的琐碎请求。
|
三省 AI 身（吾日三省吾身）
"吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？" —— 曾子
这是什么
一套交付前的自我审查协议。在你把一份交付物交给用户之前，先停一下，换一个"审稿人"的视角，把自己刚写的东西当成别人交上来的作业来挑刺，从三个轴上找问题，再据此修正。
它解决的不是能力问题，是反馈回路问题：写东西的人在写它的同一个思路里，天然看不见自己的漏洞——自审会收敛到"我本来就相信它是对的"。这个技能强制你跳出那个思路。
核心结论：证据高于声称，挑刺先于修改，诚实高于好看。
什么时候用 / 不用
用它——交付物有点分量、错了有代价、或用户明确要"认真一点"时：
- 即将输出"搞定了 / 已完成 / 如上 / 你看下"这类收尾话之前；
- 刚产出一份文档、报告、方案、邮件、一段有逻辑的中文、一块代码、一份结构化数据；
- 用户说"检查一下再给我 / 核对清楚 / 别糊弄 / 交付前自查 / 三省 / 反省一下"。
跳过它——没有可审对象或审查比任务本身还重时：纯闲聊、查时间、一行改名、翻译一句话、用户只是要个即时的粗略草稿。此时一句话说明"这个不必自省"即可。
一个铁律：先换视角，再动手
自审最容易失败的方式，就是用写它的那颗脑子去审它——你会不自觉地为自己辩护。所以审查阶段必须先切换身份：
现在你不是作者，你是一个没看过对话过程、只拿到这份成品和原始要求的挑剔审稿人。你的任务是找出它为什么不该被交付。默认它有问题，去证明这一点，而不是确认它没问题。
先列出问题清单（哪怕看起来没问题也要主动找），再决定改什么。不要边看边改、边改边夸自己。
三省（三条审查轴）
对照下面三轴逐条过。每一轴都先问"有没有问题"，再给证据，最后判定。详细的可操作检查项见 references/checklist.md。
一省 · 是否可信（忠于事实、有据可查）
问的是：这里面有没有编的、有没有不该信的？
- 有没有具体事实、数字、名称、引用、链接、结论，是我推断/想当然而不是真有来源的？逐条标出来源，标不出的就是嫌疑项。
- 有没有"超出用户给定信息"的内容？用户给了 A、B、C，我却输出了 D——D 很可能是编的。
- 因果链是不是太顺？"因为 A 所以 B 所以 C"听起来完美时，往往有一环没被验证。
- 关键结论是否被证据支撑，还是只是口气很肯定？语气自信不等于可信。
- 处理方式：能核实的去核实（查原文/重算/回读目标文件/跑一下）；核实不了的，明确标注为不确定，而不是假装确定。
二省 · 是否完整（覆盖全部诉求、无遗漏）
问的是：用户要的，我是不是每一件都做了？
- 把用户的原始请求拆成一条条离散的、可判真假的子诉求，逐条对照产出：每条是"已覆盖 / 部分覆盖 / 漏了"。
- 有没有把一个多部分的请求悄悄丢掉一半（最常见：要"做 A 并顺便 B"，只做了 A）？
- 隐含要求有没有满足：格式、篇幅、语言、口吻、字段完整性、边界情况、失败/空数据怎么处理？
- 交付物内部是否自洽：目录/标题/引用/编号对得上吗？承诺过的东西（"下面给出/见附件"）真的给了吗？
三省 · 是否合意（对齐真实意图，而非字面）
问的是：我答的，是不是用户真正想要的那个东西？
- 用户字面说的，和他真正想解决的问题，是不是一回事？有没有可能我在精准地回答一个错的问题？
- 交付物的形态、深度、口吻对不对：他要的是结论还是过程？是草稿还是终稿？是清单还是长文？
- 有没有违反已知的用户偏好或场景约束（比如：中文要克制、不要 AI 味、终稿不要留过程话术、账号/租户边界）？
- 如果这份东西现在直接发出去，用户最可能的第一反应是"对，就是这个"，还是"你没懂我意思"？
工作流
- 判定要不要自省（见"什么时候用/不用"）。不必省的，一句话说明并直接交付。
- 切换到审稿人视角（铁律那一段），默认成品有问题。
- 三省 → 列问题清单：逐轴过一遍，把发现的问题写成一张清单，每条标：
[轴] 问题 | 证据/依据 | 严重度(高/中/低)。没发现问题的轴也要说"已过，理由是……"，不能跳过。
- 修正：按严重度从高到低修。改完的问题在清单上勾掉。
- 迭代上限：最多 3 轮"省→改"。若同一个问题连续两轮没能真正解决，停下来告诉用户，把残留问题如实列出，让用户决定，而不是假装完美或无限打转。
- 交付 + 交底：交付修正后的成品。若还有未消除的疑点或不确定，显式列出来（比如"以下 2 处未能核实来源"），不要藏。
输出格式
自省过程默认简洁呈现，不喧宾夺主。用这个结构（可根据交付物调整详略）：
🪞 三省 AI 身
一省·可信：<通过 / 发现 N 个问题>
- [高] <问题> —— <证据或依据>
二省·完整：<通过 / 发现 N 个问题>
- 子诉求覆盖：<已覆盖 x/y；漏了：…>
三省·合意：<通过 / 发现 N 个问题>
- <意图偏差点>
已修正：<逐条勾掉的问题>
仍存疑（如有）：<未能消除的问题，交给用户判断>
然后给出修正后的最终交付物。如果三省全部通过、无需改动，就一句"三省已过，无需修正"，直接交付——不要为了仪式感制造问题。
反自欺的几个红线
- 不要空过：每一轴都要真的找过问题；写"通过"必须给得出理由。凑不出理由的"通过"就是走过场。
- 证据高于声称：说"我检查过没问题"不算数，要指得出依据（哪段文字、哪个数、回读了哪个文件、算了什么）。
- 不要改标准迁就产出：发现产出没达标，是去改产出，不是偷偷放低要求。放宽标准只能由用户授权。
- 硬上限：3 轮封顶。到顶还没干净，就如实报告，别无限循环，也别假装完美。
- 诚实优于好看：残留的不确定要说出来。一份标注了"这两处待核实"的交付物，比一份看起来完美却藏着雷的交付物可信。
可选：独立子代理批评者（更强的防偏袒）
上面的"换视角自省"在任何 Agent 上都能跑。如果运行环境支持起子代理 / Task / 子任务，可把三省升级为独立批评者：起一个新上下文的子代理，只喂给它「原始请求 + 最终产出」，不给它你的思考过程和对话历史，让它按三轴独立挑刺，你再据其反馈修正。
同上下文自审天然偏袒——让缺陷藏起来的那个盲点，正是当初造成缺陷的那个盲点。新上下文的批评者是最便宜的"诚实"来源。环境不支持时，退回内置自省即可，不必强求。
可选：设为默认规则
默认本技能按描述匹配时触发。若想让它在每次"即将收尾交付"时自动自省，可在宿主 Agent 的指令文件（Codex/TRAE/Cursor 的 AGENTS.md、Claude Code 的 CLAUDE.md）里加一条规则：在输出"已完成/搞定"之前，先按 三省 AI 身自审一轮。保持可选、幂等、可安全重复。
参考文件
references/checklist.md —— 三省的完整可操作检查项与判定话术，写自省清单时对照用。
