知识工作者怎么用 AI，下面是实战经验，供参考。

我用 Claude Code 做知识型工作（评估、决策、文档）。一周前还是"打开对话框问问题"的状态，一周后变成了一套有记忆、有管道、有自动校验的工作系统。这篇讲怎么做到的，包含可以直接抄走的数据结构和评分算法。

⚡ 先看效果

一句话概括

AI 提效的上限，不取决于模型有多强，而取决于你给它搭了多好的工作系统。

核心变化是：把原本全部存在对话窗口里的状态（记忆、判断、案例、规则）外置成有结构的文件系统，让 AI 每次对话都"带着记忆和管道"工作，而不是从零开始。

00 问题出在哪

大部分人用 AI 的方式：打开对话框 → 问 → 拿答案 → 关掉。三个硬伤：

• 不可追溯——结论没出处，会话一关就没了
• 不可累积——每次对话从白纸开始，上次搞清楚的东西下次要重来
• 不可校验——AI 编的和 AI 对的，语气一模一样

共同根因：所有状态都放在对话窗口里。对话窗口相当于内存——断电就清空。而工作需要的是硬盘。

解法不是"写更好的 prompt"，而是把状态搬出对话窗口，给它定义结构、检索路径、校验机制。这就是下面这套六层系统。

01 六层架构

  L6  反幻觉校验     让”不知情”的 AI 挑刺  L5  决策留痕       记决定 + 跨案例聚合  L4  自动化规约     重复琐事交给规则  L3  可追溯输出     结论必须带出处 + 离散化  L2  多源验证       按证据强度排队查  L1  知识分层       按访问模式分四层存  ─────────────────────────────────────  依赖方向：严格自下而上

每层解决一个问题，下层是上层的前提。其中 L3（离散化输出）是关键枢纽——如果结论是"基本支持"这种模糊自然语言，上面的聚合和校验都跑不起来。

L1 知识分层：别按"文档类型"归档

一句话

知识不要按"这是需求文档还是设计文档"归档，要按"多久看一次、看的时候要多细"归档。

读取频率 ▲     高  │  Memory      导航图，每次会话自动加载，必须极小         │  概念卡      结构化能力卡，检索首命中         │  语义库      长文档全量，按需取     低  │  结构化对象   精确条件查询         └────────────────────────────▶ 内容长度

每层的写入规则必须硬约束：Memory 只写指针和规则（禁止写内容）；概念卡一卡一能力（含边界/限制/版本）；语义库放完整长文档；结构化层放对象和稳定 schema。混着写就会互相污染。

为什么要加"概念卡"这一层？直接让 AI 在长文档堆里搜，只会命中零散片段，而一个能力往往散落在好几篇文档里，搜索工具没法自动拼起来。人工写一层结构化能力卡，相当于给图书馆做了套精编索引卡片——先翻卡片定位，再决定要不要下钻原文。实测这一层带来的准确率提升，比换一个更贵的搜索模型明显得多：瓶颈从来不是算法，是知识粒度。

为什么 Memory 只能放目录？因为它每次对话都自动加载。塞进大段内容，就等于每次开头都强制 AI 先读几十 KB——挤占空间、拖慢响应、分散注意力。它的定位只能是一张导航图。

L2 多源验证：按"证据强度"排队查

一句话

人工核对过的 > 已对外承诺的 > 内部草稿 > 自动检索。 命中高等级证据就返回，不再往下问。

需求点  │  ├─▶ ⑤ 人工案例库      人已核对过的判定 → 直接采信，命中即返回  ├─▶ ③ 公开文档        ”已对外承诺的能力” → 最强外部证据  ├─▶ ① 概念卡          快速定界  ├─▶ ② 语义库          设计意图，需下钻时看  └─▶ ④ 结构化对象      排期/状态信息  ▼verdict + evidence[] + gaps[]

为什么"人核对过的"排第一？这条最反直觉。自动检索只能回答"某篇文档写了支持"，人工核对才能回答"在具体苛刻的验收标准下是否真的满足"。文档写着"支持数据源连接"，但对方要接的是一个很具体的数据库品牌——检索看到"支持"就判 supported，人工一核对发现该品牌其实不支持，正确判定是 partial。

所以人工逐条核对过的结论，是全系统质量最高的一批数据。放在链路最前面，等于装了一层"人工校准过的缓存"——人工投入一次，可以被无限次复用。

另外，"内部草稿"和"已对外承诺"必须分开看：前者是"我们打算做什么"，只能内部对齐；后者才是能拿出去的依据。

L3 可追溯输出：结论必须能被拆开检查

一句话

"基本支持"看着挺人性化，但它是死胡同——机器没法处理它，你三个月后也没法处理它。

每条结论固定用这个结构输出（可以直接抄）：

- name: 数据接入# 能力名（聚合用的 key）  criteria: ”支持 S3/MinIO/HDFS…”# 原始需求文本，一字不改  verdict: partial# ← 三选一，禁止模糊  evidence: <链接或截图># 出处  gaps:# partial 必须写清缺什么    - <某数据源品牌>

四个字段各自的作用：

verdict   →  三选一（支持/部分/不支持）   →  能被程序统计evidence  →  一个链接或截图              →  三个月后能复查gaps      →  缺什么，列清楚              →  直接变成下一步要做的事criteria  →  原始需求原文                →  防止转述丢信息

为什么 verdict 必须是三档而不是一句话？因为它是下游统计的 key。"基本支持某品牌之外"只能人一条条读，读完就忘；verdict: partial + gaps: [某品牌] 才能分组、计数、加权求和。这里图省事写成模糊表述，上面所有自动统计都会跟着失效。

criteria 保留原文也容易被忽略：一旦转述，"支持基于时间戳的周期性增量同步"会被压缩成"支持增量同步"，丢掉验收关键词。转述是有损压缩，评估场景不能有损。

L4 自动化规约：把重复琐事交给规则

一句话

每天做几十次的"文件叫什么、放哪、开不开、存不存"这类小决定，能写成规则就别再想第二次。

把这些琐碎习惯写成声明式规则（不用写代码），交给 AI 每次自动执行：生成 HTML 后自动打开浏览器、统一放 docs/、命名用中文、重要决策自动写 ADR、关键事件自动追加到时间轴文件……

省下的时间不是"少敲了几次键盘"，而是把注意力从"这个文件叫什么"这种 O(n) 消耗里救出来，集中到"这个需求到底做不做"这类真正难的判断上。注意力是稀缺资源，微决策是它最大的消耗源。

L5 决策留痕 & 跨案例聚合

一句话

重要决策就写一份 ADR；有一批结构化案例后，"哪些能力反复缺失"就能被一段脚本算出来。

ADR（Architecture Decision Record）就是一张简单表，记录"当时面临什么问题、选了什么、还考虑过哪些方案、为什么没选、代价是什么"。最有价值的字段是 alternatives——三个月后回看，能清楚地知道"这条路当初就想过、当时否掉了"，不会再兜圈。

还有一条容易被忽略的字段：status: 已被 ADR-{N} 取代。决策会被推翻很正常，可怕的是新决策做完了、旧 ADR 还挂着——后来的人读到旧的当成现行。这个字段就是决策链路的版本控制。

当结构化案例攒到一定量，就可以做跨案例聚合——问一个单个案例答不出的问题：哪些能力被反复要求、却反复不满足？

WEIGHT = {”not_supported”: 1.0, ”partial”: 0.5, ”supported”: 0.0}IMPORTANCE = {”high”: 1.5, ”default”: 1.0}def pain_index(capability_key, cases):    score = 0    for case in cases:        cap = case.get(capability_key)        if cap is None: continue        w = WEIGHT[cap.verdict]        imp = IMPORTANCE.get(case.scenario, IMPORTANCE[”default”])        score += w * imp    return scoredef tier(score):    if score >= 3.0: return ”P0 🔴”# 进版本规划    if score >= 1.5: return ”P1 🟠”# 进话术库    if score >= 0.5: return ”P2 🟡”# 观察    return ”低 ⚪”

单个案例只能回答"这一家覆盖多少"；一批案例聚合，就能回答"这块能力是不是该独立立项"——这种洞察只能从聚合里长出来，单看任何一份评估都看不到。

还有一点：能力名要人工归一，禁止让 AI 自动模糊匹配——不同案例对同一能力叫法不一样，错聚合会让指数虚高，误导规划。宁可漏聚，不可错聚。

L6 反幻觉校验：让"不知情"的 AI 来挑刺

一句话

让同一个会话"自己检查自己"是没用的，必须换一个不知情、有怀疑立场的独立 AI 来核对。

三种常见但无效的"伪校验"：

• 同会话重问一次——它带着刚才的错误前提继续推理，只会复述
• 让它自我反思——同一次思考的延伸倾向于自我一致，不会自我否定
• 让它给整段话打个可信度分——一个整体分数没法定位到"具体哪句是编的"

有效的做法只有一个：另开一个上下文完全干净的 AI，只把待核对的断言列表发给它——不给它主对话历史、不给它 memory、不告诉它"你要支持我的结论"，让它默认站在怀疑立场，允许它上网查证。然后把每条断言归入三档：

✅ 有据       常识 / 公开权威事实 / 可快速查证⚠️ 推断       基于事实的合理推理，但含主观外推❌ 幻觉可能    具体数字/引用/URL/人名/日期，且没有独立证据

为什么必须换一个干净的 AI？因为主对话里已经埋了错误前提，同一个上下文的"再检查"仍然带着这个前提。这跟"用同一个信源的噪声验证这个信源"是一回事——只有引入独立信源才能打破环路。

02 六条设计原则（速记）

03 五个反模式

别再把 AI 当成"问一句答一句"的答题机（stateless），把它当作一个需要你为它设计运行时的进程（stateful）：

stateless:   output = model(prompt)stateful:    output = model(prompt, memory, pipeline, schema, verifier)

知识怎么分层、检索按什么顺序、结论用什么类型、校验怎么隔离——这些系统性设计的回报，远大于反复打磨 prompt。