AI生成文档中的隐藏信任问题
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照您的要求保留源链接、格式和技术术语，仅将正文翻译为简体中文。谢谢！
AI 生成文档中的隐藏信任问题
第一次 AI 为我的项目生成文档时，它看起来完美无缺：结构清晰，语气自信，语言专业。
这正是问题所在。
一周后，当我尝试审阅它时，我无法回答一个基本问题：
这份文档的哪些部分来自我的需求，哪些部分是 AI 编造的？
所有内容都写得同样自信。没有办法判断哪些内容值得信任——哪些内容需要我去核实。
当 AI 创建文档时，它并不区分：
- 你明确提供的事实
- 从已有文档中推断的信息
- 为填补空白而做出的假设
- 一般行业惯例
这些在页面上看起来都一样。起初，这似乎很方便。后来，它变得危险，因为你再也分不清哪些是真实的，哪些只是听起来合理而已。
为每个陈述标记来源
这个修复在概念上很简单，但在实践中非常强大：要求 AI 为每个陈述标记其来源。每个声明必须说明它来自何处。
标记定义
| Tag | 含义 | 可信级别 |
|---|---|---|
[explicit] | 直接由用户提供 | 高 — 按原样使用 |
[inferred] | 从现有文档中推导得到 | 中 — 需要验证 |
[assumed] | 由于缺少信息而使用的占位符 | 低 — 需要输入 |
[general] | 来自一般知识的填充 | 低 — 如有需要可覆盖 |
示例改写
[explicit] The API uses REST architecture with JSON responses.
[inferred] Authentication requires Bearer tokens.
└─ "All endpoints require authentication" (REQUIREMENTS.md L.23)
[assumed] Rate limiting is set to 100 requests per minute.
[general] Error responses follow RFC 7807 format.现在审查工作一目了然：我能准确知道该关注哪些地方。[inferred] 标记被证明是最危险的，因为 AI 非常擅长事后合理化——它可以先得出结论，然后寻找听起来支持该结论的文本。
强制可验证的推断
规则： 每条 [inferred] 声明必须包含来自其来源的原文引用。
[inferred] Retry policy allows 3 attempts
└─ "External API calls should retry up to 3 times" (API_DESIGN.md L.28)如果引用不能支持结论，问题会立刻显现。没有引用，我必须自己去文档中搜索；有了引用，验证只需几秒钟。
当需要标签时
并非所有文档都必须使用标签。规则很简单：对其他人将依赖其为真相的文档打标签。
| 文档类型 | 是否需要标签 | 验证方法 |
|---|---|---|
| 工作日志 | 否 | 即时记录 |
| 设计规范 | 是 | 人工审查 |
| README / 指南 | 是 | 人工审查 |
| 测试规范 | 是 | 交叉引用 |
| 源代码 | 否 | 可执行测试 |
源代码已经拥有验证机制（测试），而文档没有。源标签提供了缺失的验证元数据。
处理术语漂移
Source attribution alone breaks down when terminology drifts.
# API_DESIGN.md
[explicit] Retry policy allows 3 attempts
# SERVICE_SPEC.md
[inferred] Re‑execution strategy permits 3 tries
# TEST_SPEC.md
[inferred] Fault recovery mechanism uses 3 retries对同一概念使用三个不同的名称会导致 grep 和影响分析失效，削弱信任。
对话式统一
与其使用静态术语表，不如在 AI 与人类的对话中统一术语：
Human: “重新执行的次数应增加到 5。”
AI: “您提到的‘重新执行’是指现有文档中的‘retry policy (#retry‑policy)’吗？”
Human: “是的。”
AI: “已了解。将 retry policy 更新为 5 次尝试。”
漂移在进入点被捕获，而不是在损害扩散后才发现。这在单用户工作流中效果良好，但在多用户环境下会出现并行真相。要解决此问题，需要共享基础设施：同步的术语表、版本化的术语或序列化的工作流——这属于另一类问题。
实用指南
- 新项目： 从第一天起就让 AI 参与；标签和统一术语保持整洁。
- 遗留系统： 采用问题驱动的集成方式，然后在后续强制执行标签规则。
- 边界： 新工作遵循协议；遗留系统保持不变，直至进行修改。
来源归属并不能让 AI 完美——它也无法阻止错误的发生。它所做的，是让错误变得可见。当你能够看到 AI 确信的地方与它猜测的地方时，就能知道该在哪里运用人工判断。这种可视性是 AI 协同开发中信任的基石。
本文是 超越提示工程 系列的一部分，探讨系统化——而非偶然——的 AI 工作方式。