背景
Issue #54 / PR #55 让 routing.match() 完整消费 matcher 4 字段(includeAny/includeAll/excludeAny/excludeAll)。今日又同步了配套的知识库与规则:
rules/f2s-topic-authoring(三端 + Core templates)加了「§3 matcher 分片字段语义」写作准则,写清何时用 AND / 何时用排除词
.Knowledge/topics/kb-routing-summary.md(+ Core templates 双语)补了字段语义小节
.Knowledge/index.md、三端 f2s-flow2spec-unified-entry 同步 4 字段口径
现状梳理(能力窗口已开,但没有自动填充)
扫盘确认:
- 引擎侧:
kb apply 只做透传——delta 里显式带这 3 个字段就保留,不带就不管;kb build 不动 matcher 分片;flow2spec init 分发的默认分片模板也只有 includeAny
- skill 侧:目前所有
f2s-kb-* 技能都没有"自然语言→matcher 排除词/AND 词"的提取或生成逻辑
- git 历史:自 2026-08-03 引入 schema(#9ab1197)至今,任何真实 matcher 分片从未被赋过这 3 个字段的值
结论:这 3 个字段目前是"按需人写"——用户遇到误路由 / AND 组合词需求时,由 Agent 依 f2s-topic-authoring §3 手写进特定 matcher。
备忘诉求
有精力时评估以下方向,不阻塞任何现有流程:
方向 A — 在 f2s-kb-* skill 里加轻量提取逻辑
在 f2s-kb-feat / f2s-kb-fix / f2s-kb-add / f2s-kb-sync 里,当用户描述含以下语义线索时,提示 Agent 在 kb-delta 的 matcher 部分自动带上对应字段:
- "不要命中 X / 避免误路由 X / 排除 X 场景" → 建议
excludeAny: [X]
- "只有同时出现 A 和 B 才算 / A + B 才生效" → 建议
includeAll: [A, B]
- "A 和 B 同时出现明确不属于本域(但单个不否决)" → 建议
excludeAll: [A, B]
产出:kb-delta 里带上这些字段 → kb apply 透传落盘 → routing.match() 即刻生效。
方向 B — 新增 f2s-kb-tune-matcher 技能
专门审阅现有 matcher 的召回质量,给出增补 excludeAny / includeAll 的建议供用户确认;可以扫 .Knowledge/matchers/*.json 与路由 miss 数据交叉分析。
方向 C — 保持现状
「按需人写」也是一种合理选择——毕竟大部分 matcher 只用 includeAny 就够,写作准则已经完备,是否值得投入自动化取决于实际误路由发生频率。
建议判断标准
先跑一段时间,如果:
- 生产 matcher 里
excludeAny 使用率 ≥ 20% → 上方向 A(轻量提取)
- 频繁需要审阅已有 matcher 质量 → 上方向 B(专用技能)
- 一直是 0 或极低 → 保持方向 C
相关
背景
Issue #54 / PR #55 让
routing.match()完整消费 matcher 4 字段(includeAny/includeAll/excludeAny/excludeAll)。今日又同步了配套的知识库与规则:rules/f2s-topic-authoring(三端 + Core templates)加了「§3 matcher 分片字段语义」写作准则,写清何时用 AND / 何时用排除词.Knowledge/topics/kb-routing-summary.md(+ Core templates 双语)补了字段语义小节.Knowledge/index.md、三端f2s-flow2spec-unified-entry同步 4 字段口径现状梳理(能力窗口已开,但没有自动填充)
扫盘确认:
kb apply只做透传——delta 里显式带这 3 个字段就保留,不带就不管;kb build不动 matcher 分片;flow2spec init分发的默认分片模板也只有includeAnyf2s-kb-*技能都没有"自然语言→matcher 排除词/AND 词"的提取或生成逻辑结论:这 3 个字段目前是"按需人写"——用户遇到误路由 / AND 组合词需求时,由 Agent 依
f2s-topic-authoring§3 手写进特定 matcher。备忘诉求
有精力时评估以下方向,不阻塞任何现有流程:
方向 A — 在
f2s-kb-*skill 里加轻量提取逻辑在
f2s-kb-feat/f2s-kb-fix/f2s-kb-add/f2s-kb-sync里,当用户描述含以下语义线索时,提示 Agent 在 kb-delta 的matcher部分自动带上对应字段:excludeAny: [X]includeAll: [A, B]excludeAll: [A, B]产出:kb-delta 里带上这些字段 →
kb apply透传落盘 →routing.match()即刻生效。方向 B — 新增
f2s-kb-tune-matcher技能专门审阅现有 matcher 的召回质量,给出增补
excludeAny/includeAll的建议供用户确认;可以扫.Knowledge/matchers/*.json与路由 miss 数据交叉分析。方向 C — 保持现状
「按需人写」也是一种合理选择——毕竟大部分 matcher 只用
includeAny就够,写作准则已经完备,是否值得投入自动化取决于实际误路由发生频率。建议判断标准
先跑一段时间,如果:
excludeAny使用率 ≥ 20% → 上方向 A(轻量提取)相关
rules/f2s-topic-authoring§3 「matcher 分片字段语义」.Knowledge/topics/kb-routing-summary.md§「matcher 分片字段语义」packages/core/lib/routing.js:match()scripts/test-routing-semantics.js