资料整理 · 已去标识

专家知识整理与审核反馈闭环

项目方把合规专家的知识和分析步骤分别编码为文件与recipe，之后用专家纠错、自动最小补丁、盲测回放、回归测试和人工PR审核形成可追溯的改进闭环。

资料 · 已去标识不含企业、人物与原始链接；数值为来源方披露，非独立审计；编辑归纳处均已标注。

01Background

业务背景

场景: 软件通信 · 知识与合规
现状: 在特定合规领域，专家需要查阅大量组织立场、历史判断与外部材料才能完成评估。关键知识往往散落在文档或专家脑中，简单RAG每次仍要从原始片段重新推断规则，导致评估耗时、解释不一致，也难以把一次人工纠错可靠地保存下来。

02Pain points

核心痛点

01
在特定合规领域，专家需要查阅大量组织立场、历史判断与外部材料才能完成评估
02
关键知识往往散落在文档或专家脑中，简单RAG每次仍要从原始片段重新推断规则，导致评估耗时、解释不一致，也难以把一次人工纠错可靠地保存下来

03Solution

解决方案

项目方团队将200多个文件整理为立场、术语、路由和准入规则，使用YAML依赖关系形成可追踪知识图；高密度常用知识进入结构化wiki，稀疏资料按需RAG检索。另以可组合recipe规定分析步骤，与知识事实分离。专家在检查点审核或对模糊问题升级；纠错再经根因归类、最小文件修补、盲测回放、回归测试和专家批准后合并。

用到的能力

结构化知识wiki
YAML双向依赖图
RAG检索
可组合recipe工作流
专家检查点与升级
自动纠错编译管线
确定性lint
盲测回放与回归测试

改造链路

01离线整理内部与外部资料，形成200多个立场、术语、路由和准入文件
02每个文件用YAML声明适用场景、depends_on与referenced_by，便于依赖追踪
03常用高密度知识进入结构化wiki，低频参考资料通过语义或词法RAG检索
04顶层recipe选择下游分析步骤，按阶段加载必要知识和指令
05关键检查点向专家展示中间分析，证据不充分或存在歧义时升级
06从专家纠错中区分知识缺口、流程缺陷与真正歧义，生成最小补丁
07独立评审、结构lint、盲测回放和回归测试后提交人工审核PR

04Human in the loop

人机分工

人工把关

领域专家负责在关键检查点确认、纠正或改写分析，并对真正模糊的判断作决定；自动修改只形成待审差异和证据链，由专家审核后才能进入知识库。独立评审Agent与确定性结构校验用于发现冲突，但不能取代专家最终责任

05Outcome

效果

−80%

每轮消耗的token约减少80%来源方披露

来源方说明来源方称，3个开发冲刺、约6周后，单次评估由数天缩至数分钟；改为分阶段recipe后，每轮消耗的token约减少80%；团队报告改进周期中没有回归。文章未给出评估样本量、完整时间基线、回归测试数量或独立审计。

这是项目方特定合规领域的系统，不应与另一个面向知识工作者的专家知识库项目混同。
数天到数分钟没有公开样本量和统计口径；零回归也没有公开测试总量。
文中没有证明组织级普遍上线，故记为特定领域内部系统而非全公司规模化部署。

06Method & limits

做法与边界

FDE 在现场做了什么编辑归纳

01选择一个判断标准密集、专家负荷高的合规领域
02先从既有文档与专家判断中提炼可审查的组织立场，而非直接全量检索
03把知识事实和分析程序拆开，建立路由与依赖关系
04将专家介入点和歧义升级条件写入流程
05把每次纠错诊断成知识、流程或歧义问题，再做最小修改
06要求独立检查、原场景回放、回归测试和专家批准后上线

可以借鉴

专家知识应编码为可版本化、可审计的事实与程序，而非只依赖向量索引
对高风险判断，纠错流程比自动生成答案更值得工程化
让专家纠错变成带回归用例的版本化变更
内部效率提升数字需说明样本和基线缺口

资料透明度

业务背景来源披露
解决方案与编辑
改造链路来源披露
FDE 做法与编辑
效果来源披露

来源披露与编辑编辑归纳资料不足

专家知识整理与审核反馈闭环

业务背景

核心痛点

解决方案

人机分工

效果

做法与边界

同类案例

客服、网络运维、员工助手与软件研发的企业级AI组合

企业软件研发与验证闭环

数据底座、员工知识助手与网络自愈的企业AI组合