认识论

更新于 2026-10-01

认识论

当证据具有历史性、碎片化且有时相互矛盾时，如何推理置信度，以及如何沟通而不将其压扁为虚假确定性。

代码不自带动机。你能读代码做什么，读不出它为何存在。那活在提交、PR、工单、文档与对话中——全部不完整、有偏，有时完全缺失。假装否则会产生听起来自信、却会误导用户的猜测。

置信度层级

最终输出中每条主张必须落在以下层级之一。层级决定主张进入哪一节以及如何措辞。

1. 直接

有明确文本引用且回答问题。不是「代码做 X 所以作者一定想要 X」，而是作者实际写下的为何。

示例：

PR 描述写「修复用户 >1000 条无法分页的 bug」
工单写「因客户 Acme 在安全审查中要求，我们添加此功能」
代码注释写 // clamp to 100 because the upstream API rejects larger values
设计文档写「选 A 而非 B 因为需要跨重启持久化」
作者聊天消息写「改用此方案，因旧方案在测试中不稳定」

措辞：自信、现在时。「之所以存在，是因为 X。」引用来源。

2. 有支撑

多条间接证据收敛。无单一来源明说，但跨来源模式使其很可能成立。

示例：

PR 标题写「提升性能」，工单标「perf」，周围提交都触及同热路径
变更多条测试，均演练超大输入边缘情况
作者同周其他 PR 描述都提到同一事故

措辞：自信但明确为推导。「证据强烈指向 X：[具体片段]。」引用多个来源。

3. 推断

对上下文的合理解读，但无明确支持。读者应理解这是你的解释，非记录中的事实。

示例：

PR 未说明原因，但结合生产错误时间（事故频道）与同日仓促合并，很可能是紧急修复。
函数名暗示重试逻辑，重试次数为 3，与代码库其他地方「3 次重试」惯例一致。

措辞：留有余地。「看起来」「很可能」「表明」「与……一致」「一种解读是」。使推断链显式：「鉴于 A 和 B，C 很可能成立，因为 D。」

4. 推测

说得通但证据薄的假设，其他解释同样说得通。呈现有价值，但要明确标为猜测。

示例：

「这可能是已修复浏览器 bug 的临时方案，但未找到当代证据。」
「阈值可能为匹配 SLA，但无 SLA 文档引用。」

措辞：明确为推测。「一种可能是 X，但我们没有直接证据。」通常与「竞争假设」中其他可能并列。

5. 未知

已查找但无法得知。有效且重要的结果。记录它。

措辞：「我们搜索了 X、Y、Z，未找到原因。」具体说明搜了什么。「我们查不到」不如「我们在工单系统用关键词 A、B 搜索，扫描 2023 年以来触及该文件的 6 个 PR，并在仓库 grep 与阈值匹配的字面量。均未浮现理由。」

措辞指南

携带置信度的词——谨慎使用

这些暗示直接或有支撑。不要用于推断。

「因为」。暗示有证据的因果主张
「原因是」。同上
「被设计为」。声称作者意图
「修复」「解决」「处理」。声称变更达成目标
「团队决定」。声称群体决策

使用这些词时，旁边应有引用。

留有余地的词——用于推断

「看起来」
「似乎」
「很可能」
「表明」
「与……一致」
「一种解读是」
「说得通地」
「可能曾是」
「证据指向」

这些信号你在解释而非报告。在「可以合理推断的」中可大量使用。

避免使用的词

「显然」。若真的显然，用户不会问
「清楚」。几乎总在并不清楚的主张前
「当然」。同上
「只是」（如「这只是为了性能」）。带有轻视意味，常隐藏不确定性
「我认为」/「我相信」。你在综合证据，非给个人意见。用「证据表明」。

避免合理化

今天「说得通」的代码，可能因已不适用或当时就不对的原因而写。不要给混乱历史拼凑出干净理由。

抵制：

假设作者做了「对」的事再倒推为其辩护
假设跨代码库一致模式是有意为之，而可能只是复制粘贴
把证据缺失当证据缺席（「没人提安全，所以一定不关心」）

谄媚陷阱

用户常在问题里嵌入假设（例如「我们为什么这样做？我猜是为了性能吧？」）。不要简单确认。当作候选之一独立查证据。若支持，带引用说明；若否，说明证据实际支持什么。

用户猜测是调查提示，非待验证结论。

证据矛盾时

若两来源说法不一致（PR 说一件事，工单说另一件），都要呈现。不要选更整齐的故事。典型模式：

工单说「客户 X 合规需要」
PR 说「清理该区域技术债」

可能都真（工单驱动工作，PR 是作者的表述方式），或一错。两者都带引用呈现，让用户判断。

证据缺失时

诚实的「我们不知道」是本 skill 最有价值输出之一。用户现在知道：

答案不在明显处
需问人（原作者、PO、TL）
或决定不值得再追

未标记缺口而用听起来自信的猜测填充会伤害用户。他们会按猜测行动。

遇到缺口，具体命名：

试图回答的问题
搜索的来源
各来源搜了什么
找到什么（无，或仅间接相关的材料）

定稿前校准检查

交付前，合成器应审查「已经查到的」与「可以合理推断的」中每条主张：

有引用吗？若无，添加或移到推断 / 假设。
措辞与层级匹配吗？（直接可用「因为」；推断不可。）
是否把代码本身当意图证据？若是，不是证据。移除或重分类。
是否有「还不知道的」？若无缺口，可疑——要么证据异常完整，要么被刻意掩盖。

本站是非官方的 pstack 中文学习站，和 poteto 没有隶属关系。译文对照的是 cursor/plugins 仓库里的 pstack/ 目录。本站不发行中文版插件。 github.com/cursor/plugins