主题
FDS-04 · 业务原子技能规范
业务逻辑尽量做成"业务人能读能改、能版本管理"的技能文件;但正确性的硬规矩必须是代码。本章把边界、文件长什么样、怎么版本与评审讲死。
1. 什么是"业务原子技能"
一份 markdown 说明文件(SKILL.md),描述一项独立业务能力怎么做;deer-flow 引擎能按它执行;业务人能读、能改、用 git 管版本。
- "原子" = 一件独立、能单独验收的事(如"精修一篇口水稿""按风险类型抽取")。
- 它就是 deer-flow 原生技能机制,只是加一套"业务"约定(负责人、版本、输入输出、验收、自带测试)。
- 一个原子业务(B3/B4/B5/B12 等)对应一个技能;复杂的拆成"主技能 + 引用文件"。
2. 技能 or 代码:边界(这条不让步)
| 必须是技能(业务规则会变、靠模型判断) | 必须是代码(正确性不容漂移) |
|---|---|
| B3 精修(怎么分段、怎么归说话人、去哪些口水) | B6 出处校验(引文是否真在原文——程序比对) |
| B5 抽取(什么算决策/风险/待办、怎么措辞) | B8 事实库读写(事务、强一致、版本失效) |
| B4 纪要(模板风格、详略) | B9 待办状态机、跨会归并的判定执行 |
| B12 复盘叙述、B10 跨会叙述 | 权限/项目隔离、B7 中断-续跑控制 |
判据一句:"错了会算错数据/出假结论"的 → 代码;"换种说法/换套规则"的 → 技能。 防瞎编、写库、状态流转永远代码。
3. 技能文件结构(模板)
skills/custom/<业务技能名>/
SKILL.md # 必需:下方 frontmatter + 业务规则正文
references/ # 可选:模板、规则细则(正文按需引用)
eval/cases.jsonl # 必需:验收样例(给自动测试用)SKILL.md 顶部(机器读)+ 正文(业务人读改):
yaml
---
name: meeting-refine # 技能标识
description: 何时用这个技能(一句话,引擎据此判断是否调用)
owner: 业务方-会议域 # 谁负责、谁审
version: 1.2.0 # 改一次升一版,即业务演进史/回退点
inputs: { transcript: 文本 } # 输入契约(业务人也能看懂)
outputs: { refined: 文本, segments: 列表 } # 输出契约
acceptance: # 验收(可证伪)
可用: 长会不丢中段;说话人归一一致
好用: 分段结果能被抽取直接用
allowed-tools: [读文件, 写文件] # 这个技能能用的工具(收敛权限)
eval: eval/cases.jsonl # 必须有自动测试样例
---
# 业务规则(业务人写、业务人改)
1. 分段规则:……
2. 说话人归一规则:……
3. 禁止:不得臆造原文没有的内容……frontmatter 让系统能装配/校验/版本化;正文是业务人维护的业务规则白话。两层分开,各看各的。
4. 版本、评审、测试闭环(业务人能改但不失控)
- 版本:每次改 = 一个 git 版本 = 业务决策演进史,可一键回退。
- 测试:每个技能必须带
eval样例;改完自动跑,改坏了立刻看得见(不靠人肉发现)。 - 评审:自动测试过 + 人审过才生效;业务人能改 ≠ 直接上线。
5. 技能与其它部分的契约(不直连数据库、不接外部 IM)
- 技能不直接读写数据库:要事实库的数据,经 acdm-backend 提供的工具接口(读/写),由代码侧保证强一致与权限。
- 技能产出"拿不准/冲突"的条目时,不自己拍板:标记为存疑,交给代码侧的站内确认流程(B7)派给负责人。
- 技能不依赖飞书等外部 IM;通知一律站内。
6. 三条不让步(skill-first 不塌方的前提)
- 正确性硬规矩(B6 校验、B8 写库、B9 状态机)永远是代码,不写进技能让模型自律。
- 每个业务技能必须带 eval 样例;无样例不准进生产。
- 业务人改动必须走 自动测试 + 人审 才生效;可回退。
下一章 FDS-05:把人机协同模型(工作台/任务卡/任务流)逐项对到本模块。