Skip to content

FDS-31 · 风险与红线

这套方案最容易死在哪、怎么防;哪些是不可逾越的红线。每条:触发 → 缓解 → 对应章。

1. 最容易踩的"花架子陷阱"

陷阱触发缓解对应章
摘要孤岛(分析做了,没人用、追不动)待办只在某页显示,不进任何人会看的地方待办进项目工作台站内待办面板,默认待确认、可流转、跨会归并;下次开会自动把上次进度摆桌面FDS-18/20
AI 瞎编(结论看似合理实则原文没有)出处靠模型自报、没人核抽取每条带原文位置 → 程序校验引文确在原文,假的丢弃或转人工FDS-14/15
跨会"智能"是错觉(只按开会日期凑)关联用日期/弱规则,实体语义没接看板只读事实库,关联用实体消歧+语义相似,非日期FDS-19
又慢又卡(单场等好几分钟)一个大提示词一次抽全部、串行、每次重啃录音分类型分别抽、先精修、下游只读事实库不重啃FDS-12/14/17
业务人一改就坏且无人知规则散在代码或改了没测业务规则做成技能、每个必带自动测试、改动走评审可回退FDS-04/22

2. 项目红线(不可逾越)

红线说明对应章
不改 deer-flow 内核只在扩展位接(技能目录/流水线注册/会话注入位/acdm-backend)FDS-03
本期不接飞书等外部 IM/任务系统通知与闭环全部站内;外部平台仅留可插拔出口,不实现不依赖FDS-00 〇
正确性硬规矩用代码,不交模型自律出处校验、写库事务、待办状态机、权限隔离=代码;技能只管业务判断FDS-04/15/17
事实库是唯一真相,不双源下游一律只读事实库;上游变→版本失效重算;不允许各下游各存一份FDS-17
每个业务技能必须带自动测试无测试样例的技能不准进生产FDS-04/22
技能改动走测试+人审才生效业务人能改 ≠ 直接上线;可回退FDS-22
录音原始材料不物理删除软删可逆+回收站FDS-10/17

3. 三条不让步(skill-first 不塌方的前提,再次强调)

  1. 防瞎编/写库/状态机/隔离 永远是代码
  2. 每个业务技能必须带自动测试,改完能自动看出有没有改坏。
  3. 业务人改动必须自动测试+人审才生效,可回退。

失守任一条 → 这套就退化成"业务人写一堆不可靠的模型提示词",重蹈现状覆辙。

4. 其它风险与取舍

  • 事实库 schema 改动代价:核心可查字段固定成列+索引,类型差异放 jsonb;向量检索后置,先全文索引拿大头(FDS-17/19)。
  • 人确认任务久挂没人答:设到期,超期降级为"AI 暂定+标低可信"入库并持续提醒,不永久卡住流程(FDS-16)。
  • ASR 合规/质量:本期直接接 API(Qwen-3ASR/fun-ASR),接口可切换防锁定;差录音转人工兜底;合规收紧只换实现不动主干(FDS-11)。
  • 范围蔓延:严格按 FDS-30 五步,先单会闭环再扩,不并行铺开。

5. 一句诚实话

到目前为止,这套是想清楚、查证过真实代码、写成可落地方案——还没开始写代码。它"成立"与否,要等 FDS-30 第1步:用一场真实会议跑通"建档→精修→抽取→出处校验→入事实库",随机抽 20 条 100% 能回原文且校验通过、无效 0 条进库、比现状明显快。那一步真实达标,才算真的开始有价值;在此之前不宣称"已做到"。

公司内部参考 · 由 claude-wiki-gen 基于源码自动生成的二次分析