AI 负责筛选,人负责拍板

简介: ContextDB提出“AI筛选+人工拍板”知识治理模式:AI自动捕获、去重、评估事实,但关键决策(如知识入库、冲突裁决、删除降级)必须由人确认。兼顾效率与可靠,满足合规审计需求,通过分层治理将人工评审聚焦于20–30%高风险信息。

让 AI 自己决定什么该记、什么该忘,你敢用吗?

一个真实的两难

你的 AI Agent 每天与团队成员进行上百次对话。每次对话都可能产生有价值的信息:一个技术决策、一个业务规则、一个架构变更、一个 bug 的修复方案。

你需要一个系统把这些信息沉淀下来。但谁来决定什么值得记、什么可以丢?

让 AI 全权决定,听起来很酷。但 AI 可能把一句关键的架构决策当成闲聊丢掉,也可能把一句随口吐槽当成重要偏好存下来。在企业场景里出了事谁担责?

让人逐条审核,万无一失。团队每天产生数百条信息,每条都要人确认,没有人有时间和精力做这件事。

两条路都走不通。一边是效率,一边是可靠,中间有张力。我们在设计 ContextDB 的知识治理时,选了第三条路:AI 做筛选和整理,人做最终决策。

这不是什么独创的哲学——大多数成熟的知识管理系统最终都会走到类似的人机分工。但具体怎么划分边界,值得展开聊聊。

这个流程怎么运作

ContextDB 的知识治理流程分四个阶段,每个阶段清晰划分了 AI 和人的职责边界。

信息捕获(AI 主导)。 Agent 与用户的每次交互,AI 自动从中提取原子事实。不需要人工干预。捕获阶段的原则是宁可多捕不可漏掉——一条信息被捕获不代表会被永久保留,但如果在捕获阶段就丢了,再也找不回来。

AI 筛选与整理(AI 主导,人监督)。 捕获到的原子事实进入筛选阶段。AI 做语义去重(重复的合并并强化置信度)、冲突检测(矛盾的标记等待处理)、置信度评估(根据信息来源和上下文强度打分)、分类与关联(归到对应的 Entity Card,建立关联)。

这一步 AI 可以自主完成大部分工作,但有两条红线。AI 不能删除已有知识,即使判断某条信息已过时,也只能降低置信度。冲突不能由 AI 单方面裁决,它负责标记和提供判断依据,最终拍板的是人。

人工评审(人主导,AI 辅助)。 这是整个流程中最关键的环节。系统提供了一个评审界面,把 AI 筛选后需要人工确认的内容列出来:

置信度高、即将被标记为"知识"的事实,需要人确认。两条互相矛盾的信息,AI 给出了初步判断和建议,人来最终拍板。长期存在但置信度始终不高的事实,是否正式纳入知识库。长期未被引用的事实,是否归档或删除。

AI 在这个阶段的角色是辅助决策——它会给出推荐理由,比如"这条事实已被引用 23 次,建议晋升为知识",或者"这两条事实存在矛盾,根据时间戳建议保留较新的一条"。但点下确认或驳回按钮的,永远是人。

分发与权限(规则驱动)。 评审通过的知识进入分发阶段。通过 Workspace + 权限模型控制可见范围:某些知识对团队内所有 Agent 可见,某些仅限特定 Agent 访问(比如只有代码审查 Agent 能访问编码规范),某些标记为敏感需要额外授权。规则设定好后自动执行。

为什么不让 AI 全权做主

这个选择背后有具体的考量。

错误的代价不对称。 AI 漏掉一条有用信息,代价是下次需要重新获取, inconvenience。AI 错误地删掉一条关键信息,代价可能是一次线上事故。两种错误的代价不在一个量级。在不对称风险的环境中,宁可多记一些可能没用的信息,也不能冒丢失关键信息的风险。人类评审就是最后一道保险。

AI 缺乏业务上下文。 AI 可以从语义层面判断"这两条信息矛盾",但它很难判断"在这个业务场景中,哪条信息更重要"。

举个例子。用户三个月前说"我们的支付系统不做幂等处理",今天说"支付系统必须保证幂等性"。从技术角度看,后者是更合理的设计。但从业务角度看,前者可能是一个已经上线的事实,后者是一个尚未实现的规划。AI 区分不了"应该怎样"和"实际怎样",而这个区分对知识的准确性很关键。

合规与审计需求。 金融、医疗、政务等行业,知识的变更记录需要可追溯、可审计。"AI 自己决定删掉了这条记录"在审计中不可接受。"张三在 2024 年 3 月 15 日审核并归档了这条记录"才是合规的。人工评审环节天然提供了这种审计线索。

当然,这套机制也有代价——它意味着知识沉淀的速度受限于人的审核带宽。如果你的团队每天产生大量需要评审的信息,评审队列可能会积压。我们在设计中尽量通过分层治理来缓解这个问题(后面会说),但这个问题不可能完全消除。

记忆晋升:从"我记得"到"我们确认"

ContextDB 中有一个概念叫记忆晋升——一个原子事实从"记忆"升级为"知识"的过程。

触发条件包括:同一事实被不同用户在不同时间多次确认,置信度累积超过阈值;事实被 Agent 在回答中频繁引用,说明实际价值高;管理员在评审界面主动将某条记忆标记为知识。

晋升之后的知识享有更高的置信度基准和更低的衰减速率。它从"可能正确的记忆"变成了"经过验证的知识"。

背后的想法很朴素:团队知识不应该建立在"某个人说过"的基础上,应该建立在"团队认可"的基础上。记忆晋升机制把这个认可的过程显性化了。

知识量大了怎么办

有人可能会质疑:人工评审听起来好,但每天几百条信息都要人看,不现实。

我们的解法是分层治理。低风险信息自动处理——置信度极高、与已有知识一致、无冲突的事实,自动入库,不进评审队列。据我们观察,这类信息大概占日常交互的 70-80%。不过这个数字因团队而异,如果你的团队讨论中有很多争议性的技术决策,需要人工评审的比例可能会高不少。

中风险信息推荐评审——有一定价值但存在不确定性的事实,AI 给出建议推入评审队列,但不设紧迫的截止时限。高风险信息强制评审——涉及冲突、删除、降级操作的事实,必须经过人工确认才能执行。

人只需要关注那 20-30% 真正需要判断力的决策,剩下的交给 AI 和规则。

这里有一个我们还没完全想清楚的问题:冷启动阶段的评审压力。团队刚开始用的时候,知识库是空的,大量信息都是"新知识",需要评审的比例会远高于稳态。怎么让团队愿意在初期投入时间做评审,熬过这段积累期,说实话我们还没有特别好的办法。目前主要靠 Entity Card 的即时可用性来提供早期价值,但激励效果因人而异。

知识生命周期

把整个流程串起来:

启动(热启动导入文档 / 冷启动从零积累)
捕获(AI 从交互中提取原子事实)
筛选(AI 去重、冲突检测、置信度评估)
评审(人确认高价值/高风险决策)
入库(成为正式知识,进入 Entity Card 和 Memory Graph)
分发(按权限分发给不同 Agent)
演进(置信度衰减、冲突消解、记忆晋升)
归档/删除(长期未用,人工确认后归档)

每个环节的职责划分清晰:AI 做它擅长的大规模筛选和模式匹配,人做它擅长的价值判断和最终决策。

小结

AI 能力越来越强,它能做的事越来越多。但这不意味着它应该做所有决定。

知识治理尤其如此。什么该记、什么该忘、什么该更新,这些决策累积起来决定了整个知识体系的可靠性。

"AI 筛选 + 人工拍板"这个分工不是什么哲学宣言,只是目前看来比较可行的折中方案。AI 承担效率,人承担责任。这个方案肯定有改进空间——比如更智能的分层策略、更好的评审界面、更精准的 AI 推荐。但至少在当前阶段,这大概是企业 AI 系统比较合理的人机协作方式。


目录
相关文章
|
2天前
|
存储 JSON 运维
阶跃星辰:从日志排障到 PB 级Agent 实时可观测,我们为什么选 SelectDB 做数据底座
阶跃星辰选用SelectDB构建Agent可观测平台StepTrace,依托其存算分离、VARIANT半结构化支持、倒排索引、异步物化视图与Stream Load秒级实时写入能力,高效支撑SWE-Bench评测、智能座舱等生产场景,实现Trace数据秒级可见、多维分析与成本治理,成为AI基础设施统一数据底座。
49 2
|
6天前
|
缓存 NoSQL 双11
高吞吐缓存实战:Tair 多线程性能增强型在电商大促的应用
电商大促(双 11、618、年货节)是缓存数据库吞吐能力的终极考场——峰值 QPS 可达日常的 50~100 倍,每一次缓存未命中都意味着后端数据库多承受一次请求。瑶池数据库旗下的 Tair(Redis 企业版)性能增强型以多线程架构实现单节点 51 万 QPS,已在多届阿里双 11 中经受住了亿级流量考验,是电商大促高吞吐缓存的首选方案。本文从实战角度拆解 Tair 多线程性能增强型如何在电商大促中保障极致吞吐和稳定体验。
54 1
|
开发框架 前端开发 网络协议
使用 DataAnnotations(数据注解)实现模型的通用数据校验
在实际项目开发中,无论任何方式、任何规模的开发模式,项目中都离不开对接入数据模型参数的合法性校验,目前普片的开发模式基本是前后端分离,当用户在前端页面中输入一些表单数据时,点击提交按钮,触发请求目标服务器的一系列后续操作,在这中间的执行过程中(标准做法推荐)无论...
44070 1
使用 DataAnnotations(数据注解)实现模型的通用数据校验
|
2天前
|
数据可视化 前端开发 开发工具
DeepSeek Harness插件实战:四款开源插件补齐编码Agent全部短板详解
当我们把DeepSeek Harness(简称DSH)作为主力本地编码Agent运行环境之后,很容易产生直观感受:框架本体如同一套尚未装修的毛坯房,核心运行逻辑、Agent循环、工具调用能力全部具备,但原生界面简陋、缺少图像解析、任务管理、可视化交互等实用能力,日常开发体验比较基础。得益于它“一切皆插件”的核心设计理念,底层依托Cordis微内核,模型适配器、工具调用模块、会话存储、前端界面全部以插件形式实现,开发者无需修改项目源码,依靠配置就可以新增、替换任意功能模块。社区已经沉淀出大量高质量开源插件,只需要简单终端命令,就可以完成能力扩展,把基础运行时改造为体验完整的开发助手环境。
143 0
|
2月前
|
自然语言处理 前端开发 数据挖掘
阿里云Qwen3.7 Max与Plus实测对比:纯文本旗舰与多模态全能王全维度解析
阿里云Qwen3.7系列推出Max与Plus两款核心商用模型,二者均标配100万Token超长上下文与35小时长时自治执行能力,但在底层架构、模态支持、性能侧重、计费成本上存在本质差异。Max定位纯文本旗舰,专攻复杂推理、代码与长链路智能体;Plus定位多模态全能,兼顾视觉理解、文本推理与端到端任务闭环。本文基于官方实测数据,从基础架构、模态能力、文本/代码/数学性能、计费成本、落地场景五大维度完整对比,为个人开发者、中小企业、政企团队提供精准选型依据。
348 3
|
3月前
|
JSON 自然语言处理 前端开发
谷歌深夜发布 Gemini 3.5:多模态能力再升级,开发者该怎么抓住这波机会?
Gemini 3.5 Flash于2026年5月发布,主打原生多模态与实时智能体能力:支持图文音视一体化理解、帧级视频诊断、100万token长上下文,并在编码(76.2%)、Agent任务(83.6%)等实测中超越前代。速度快4倍、成本更低,已免费开放。
|
5月前
|
运维 应用服务中间件 nginx
运维常用软件及高频命令汇总
本文精炼汇总Linux与Windows双平台高频运维命令,涵盖系统监控(★top/free/df)、网络诊断(★ping/netstat)、进程服务管理(★ps/systemctl/tasklist/taskkill)及Nginx、Docker等专项工具,标★命令均为每日必用核心指令,兼顾新手入门与日常速查,实用性强。
609 2
|
7月前
|
JSON 人工智能 机器人
什么是数据集 —— 大模型微调的 “燃料” 核心解析
本文系统解析大模型微调数据集的核心要点:从定义分类(分类/生成/对话/知识/混合类)、标准格式(JSON/JSONL/CSV),到质量五大要求(准确、相关、多样、无冗余、无偏见),再到构建清洗五步法与电商客服实操案例,助开发者夯实微调基础。(239字)
|
8月前
|
人工智能 运维 监控
AI领域优质知识类博主深度推荐:技术、商业与伦理的跨界布道者
2025年AI浪潮中,十位知识博主脱颖而出,覆盖技术、工程、商业与伦理四大维度。他们以学术深度与实战经验,打通从理论到落地的闭环,构建AI时代的学习生态,成为从业者的“认知加速器”。
1378 0
|
JavaScript 前端开发 API
在线三维CAD中创建一个三维管道模型(网页浏览编辑三维CAD)
本文介绍了如何使用mxcad3d创建三维管道模型。mxcad3d提供了丰富的API,使复杂的管道结构设计变得直观简便。首先需安装mxcad包并初始化项目。接着,通过编写JavaScript函数实现圆角方管的绘制,并将其添加到web界面中。点击绘制按钮即可生成管道模型并实时展示。这为网页CAD中的三维建模任务提供了强大支持。相关代码与项目可在[mxcad3d官方仓库](https://gitee.com/mxcadadox/mxcad_docs/tree/master/examples3D/Test3dPipe.7z)获取。
574 113
在线三维CAD中创建一个三维管道模型(网页浏览编辑三维CAD)