惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
量子位
D
DataBreaches.Net
博客园 - 司徒正美
J
Java Code Geeks
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
aimingoo的专栏
aimingoo的专栏
B
Blog
The Cloudflare Blog
D
Docker
I
InfoQ
爱范儿
爱范儿
MongoDB | Blog
MongoDB | Blog
腾讯CDC
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
Vercel News
Vercel News
阮一峰的网络日志
阮一峰的网络日志
小众软件
小众软件
S
SegmentFault 最新的问题
GbyAI
GbyAI
有赞技术团队
有赞技术团队

博客园 - AlfredZhao

Git 提交代码:从报错到 SSH 免密推送 GitHub 克隆他人私有仓库:从授权到下载 理解Oracle Property Graph:以账户转账示例完成图特性最小测试 APEX 无法分配 SH 用户?一个存储过程轻松解决 SH 中文化样例数据使用手册 Oracle 排除非业务表:一份能直接抄的“全量过滤”SQL 进程都杀了,为什么 `netstat` 还能看到端口? MAC 空间告急?Codex 的 156GB 缓存垃圾,这样清! 人工清理问题数据:先查准,再删除 使用快捷键快速切换 Mac 外接显示器模式 客户环境 Nginx 配置:流式报表与超时排查要点 Security Central:数据库安全的统一控制与运营平台 Palantir 眼中的一次“订单可能延期”,如何成为实时决策的起点? 从一条订单消息到 Bronze、Silver、Gold:我的第一次 Kafka + Lakehouse 实验 UUID v4 与 v7:同样是唯一 ID,为什么数据库表现可能完全不同? 用 crontab 给 LLM 使用量装上“监控眼” DeepSeek 与 GPT API 价格调整:该关注什么? 查看 Oracle 数据库中的定时任务执行情况 Codex 专用用户登录后自动进入默认项目目录 Mac 小技巧:用方向键优雅处理超长网址 Oracle GDD 与 Raft:别把共识机制和数据主权混为一谈 在 Oracle APEX 中用 BGE_BASE 生成向量:从模型导入到历史数据更新 行业人+AI:真正有价值的四个关键要素 知识库文件解析失败:一次由 Domain Index 引发的定位记录 Unicode 码位数、UTF-8 字节数、中英文差异和 Oracle 长度别再混淆了 Skill 的使用:从路径到能力边界 切换 Embedding 模型时,千万别忽略历史向量维度 kbot 适配 GPT-5.6:一次参数兼容性排查 Git 打 Tag 上传 GitHub 遇到 SSH 超时,如何处理? SQL JOIN 写法:把多表关联条件写清楚
TK(Trusted Knowledge)为何而生?
AlfredZhao · 2026-09-06 · via 博客园 - AlfredZhao

2026-09-06 07:57  AlfredZhao  阅读(14)  评论()    收藏  举报

在使用 AI 工具时,我们常常会围绕一个问题反复追问。尤其是网页版 AI,随着对话上下文不断累积,答案会经历多次调整和补充,直到某个时刻,终于得到一个准确、真正解决问题的回答。

但问题在于:这个来之不易的准确答案,往往被淹没在漫长的对话历史里。 下次再遇到类似问题时,我们可能又要从头开始描述背景、重复提问,甚至难以找回之前那条已经验证有效的答案。

这种“解决了,但又没完全解决”的体验,正是 TK(Trusted Knowledge)诞生的起点。

01 | TK 是什么?

TK(Trusted Knowledge)是一套通过 Vibe Coding 实现的知识沉淀系统。它的核心思路非常直接:

当一个 AI 对话经过反复沟通、最终得到准确答案后,把最初的问题最终可信的答案提炼出来,存入数据库,形成可持续复用的知识。

它保存的不是整段冗长的聊天记录,而是一条经过验证、更清晰、更容易复用的知识条目。

02 | 从 AI 对话到可信知识的完整流程

下图采用流程图,说明从 AI 对话到可信知识沉淀的完整过程:

flowchart LR A[提出问题] --> B[围绕问题持续追问] B --> C[答案不断调整与补充] C --> D{是否得到准确答案?} D -->|否| B D -->|是| E[提炼最初问题] D -->|是| F[提炼最终可信答案] E --> G[存入数据库] F --> G G --> H[形成可复用的可信知识] H --> I[后续遇到类似问题可直接复用]

① 流程要点说明

  1. 提出问题:用户向 AI 描述一个具体问题或需求。
  2. 持续追问:围绕该问题与 AI 多轮交互,答案会不断调整和补充。
  3. 判断是否准确:只有当答案真正解决了问题,才进入沉淀环节;否则继续追问。
  4. 提炼关键内容:从对话中提取最初的问题描述和最终可信的答案。
  5. 存入数据库:将提炼出的问答对结构化存储。
  6. 形成可复用知识:后续遇到类似问题时,可以直接检索使用。

03 | 为什么需要 TK?——三个关键痛点

① 上下文越长,有效信息越难提取

AI 对话的上下文窗口有限,当聊天记录越来越长,早期的重要信息可能被后续内容覆盖或稀释。真正解决问题的答案,往往需要翻很久才能找到。

② 重复提问的成本被低估

每次重新提问,都需要重新描述背景、补充上下文。对于复杂问题,这个成本可能相当高——不仅是时间成本,还包括重新组织语言、梳理思路的认知成本。

③ 有价值的对话结果没有被沉淀

大多数 AI 对话是“一次性”的。对话结束后,那些经过验证的答案就停留在聊天记录里,没有转化为可检索、可复用的知识资产。

04 | TK 的解决思路:从“对话”到“知识”

TK 的设计哲学可以概括为:不保留全部,只沉淀精华。

维度 传统做法(保留全部对话) TK 的做法(提炼关键问答)
存储内容 整段聊天记录 最初问题 + 最终可信答案
检索效率 需要翻看大量上下文 直接定位关键问答
复用价值 低(信息混杂) 高(结构清晰)
知识积累 难以形成体系 可持续积累

05 | 适用场景与使用建议

TK 适合以下场景:

  • 高频问题:经常被问到、需要反复回答的问题;
  • 复杂问题:需要多轮追问才能得到准确答案的问题;
  • 经验沉淀:个人或团队希望积累 AI 使用经验,形成知识库。

使用时的几点建议:

  • 在对话得到准确答案后及时沉淀,避免遗忘;
  • 提炼问题时,尽量保持原始表述,便于后续检索;
  • 存入数据库时,可附加标签或分类,提升复用效率。

06 | 注意事项与常见误区

  1. 不是所有对话都值得沉淀:只有经过验证、真正解决问题的问答才有沉淀价值。
  2. 提炼而非截取:不是简单复制聊天片段,而是提炼出问题与答案的核心内容。
  3. 答案的时效性:AI 的答案可能随模型更新而变化,沉淀的知识需要定期审视和更新。
  4. 避免过度依赖:TK 是辅助工具,不能替代对问题本身的深入理解。

07 | 总结

TK(Trusted Knowledge)关注的不是保留全部对话,而是提炼已经解决问题的关键问答:

  • 保留最初的问题——让知识有明确的检索入口;
  • 保留最终可信的答案——让知识有可靠的内容支撑;
  • 将两者存入数据库——让知识结构化、可检索;
  • 让一次解决,成为后续可复用的知识——让每一次有效的 AI 对话,都能持续产生价值。

在 AI 对话日益频繁的今天,TK 提供了一种思路:让有价值的对话结果,不再被淹没在冗长的上下文中,而是成为可以持续积累和复用的可信知识。

关注我,和AI一起成长~