13 · 业务原子 Skill 架构(skill-first 业务实现范式)

2026-05-19 领导补充:业务相关实现尽量用 skill,提出"业务原子 skill"概念——目的:深入实现业务逻辑、知识沉淀与管理、业务人易懂可协同可编辑、清晰版本管理、整体技术难度不高、更快做出 AI 原生应用、快速发挥业务价值。严格按 11 框架 v2:§C 实现真实性闸 / §D 四角色对抗 / §E 原子业务需求为单元 / §F 底座级判据 / §G PMO 诚实。本文是 12 的实现表达范式层,不改 §0 三裁决与 §1 修正架构,只回答"业务逻辑用什么形态落地"。

§1 "业务原子 Skill" 概念定义

定义:一个业务原子 skill = 把 12 §2 的一个原子业务需求(ABR)封装成一份自描述、可组合、业务人可读可改、git 版本化的 deer-flow 原生 SKILL.md 单元;它声明:意图、输入/输出契约、验收、责任人、版本、所用工具白名单、与事实集/HITL 的契约、评测样例。

它不是新机制——它就是 deer-flow 原生 skill(skills/custom/<name>/SKILL.md + 渐进式加载,03 §1 T1 已核),只是加一套"业务原子"约定让它成为业务逻辑的承载与知识沉淀单元。一一映射:

原子业务需求(ABR,doc12 §2)  ──1:1──▶  业务原子 skill(SKILL.md)
任务流(05 任务卡内)节点      ──调用──▶  一个或多个业务原子 skill
项目事实集(project_facts)    ◀─读/写─   skill 经 BFF tool 契约访问
可疑点                       ──触发──▶  HITL 澄清(interrupt,doc12 §0 裁决2)

为什么"原子":粒度 = 一个独立有业务价值、可独立验收、可独立版本演进的最小业务能力(如"会议精修""按类型抽取决策事实""周报复盘")。原子化才可组合、可替换、可被业务人单独理解与编辑、可单独评测回归。

§2 为什么 skill-first 对本项目成立(§D 四角色对抗审,含反模式)

角色	支持点	反方/红线(必须同时满足,否则 skill-first 变花架子)
业务顾问	SKILL.md 是 markdown,业务人能读/审/提改;业务知识沉淀在 skill 而非散落代码与人脑;版本=git 历史=业务决策史	业务人改的是"业务说明",不是可执行真值的唯一防线;确定性正确性不能依赖业务人写对 prompt
吹毛求疵架构师	skill = 组合契约边界,换实现不动编排;新增业务=加 skill 不改核心;天然低耦合	组合关系若无显式契约(输入/输出 schema)就是"prompt 黑箱拼接",会双源漂移;契约必须显式
AI 系统专家	渐进式加载(描述进系统提示、正文按需读)省 token;skill 边界=评测边界,可单测回归	LLM skill 不可承担防幻觉硬闸/事务/校验;无 eval 回归的 skill = 业务人一改就不知坏没坏
PMO	技术难度下移(写 markdown 业务规则 > 写分布式代码),交付更快,范围可按 skill 切片	"都做成 skill"会用 LLM 干确定性该干的活(慢/贵/不可靠);范围必须按"该不该是 LLM"划线

结论(诚实):skill-first 成立且与本项目三大已验证事实强契合——(a)deer-flow 原生 skill T1 真实可用([03] 已核);(b)ABR 已是天然原子单元(doc12 §2);(c)05 任务流节点天然是 skill 调用点。但有三条不可让步红线(见 §6):确定性硬闸用代码、每 skill 必带 eval、业务人编辑走 review/CI gate。

§3 借鉴的开源项目与最佳实践(可借鉴点 / 不可照搬点)

知识级参考(非本仓 T1),用于扩展思路;落地以本项目 v2 框架与源码裁决为准。

来源	可借鉴	不可照搬/警惕
Anthropic Agent Skills / SKILL.md(渐进式披露 + allowed-tools)	三级渐进披露(名+描述→正文→引用文件)省上下文;能力即文件夹、可移植;`allowed-tools` 收敛权限	官方面向通用 agent,业务契约/验收/owner/版本/eval 字段需我们补约定
Spec-driven dev:GitHub Spec Kit / Amazon Kiro	"规格即源、人审、再生成";业务意图与实现分离、可版本管理、可评审	它们生成代码;我们是 skill 即"可执行规格",别把规格当实现还要再手写一遍(双源)
低代码 AI 编排:Dify / Coze / Flowise	业务人可视编辑、模板复用、版本、快速出 AI 应用——印证"业务可编辑+快交付"诉求真实	黑箱编排、厂商锁定、难做强一致与可溯源硬闸;我们要的是"业务可读的 skill+确定性代码硬闸",不是纯可视黑箱
Semantic Kernel plugins / "skills"	能力即可组合插件、清晰输入输出契约	偏 .NET 工程化;我们走 markdown-skill 降门槛
LangGraph(确定性编排)	确定步骤用图编排,LLM 与确定性显式分层(本项目 doc12 D-1 选 ba_report 范式)	别把图节点都塞 LLM;skill 是节点的"业务大脑",图是"确定性骨架"
知识库即能力(RAG-as-skill)/ BMAD-method(agent 即方法论)	知识沉淀进可检索/可执行单元;方法论显式化、可复用	知识需带出处(对齐本项目 A4 引文校验硬闸),不可"检索即可信"

提炼的统一最佳实践(本项目采用):"业务可读的 skill = 可执行规格 + 渐进披露 + 显式契约 + 自带 eval + git 版本 + 确定性硬闸下沉到代码"——融合 Agent Skills 的形态、spec-driven 的治理、低代码的业务可及性,规避其黑箱与双源。

§4 业务原子 Skill 架构(落到本项目)

4.1 三层(谁是 skill,谁必须是代码)

确定性骨架(LangGraph,ba_report 范式,doc12 D-1)         ← 代码:编排/checkpoint/interrupt/续跑
  └─ 任务流节点 = 调用业务原子 skill                       ← skill:业务大脑(LLM)
       ├─ 组合 skill(编排多个原子 skill 的业务剧本)        ← skill:业务级组合
       └─ 原子 skill(1 ABR 1 skill)                       ← skill:最小业务能力
  └─ 硬闸/事务/检索 = 代码 tool,不是 skill                 ← 代码:A4 引文校验/A6 事实集写/查询

该是 skill(LLM 判断/生成,业务规则常变):A2 精修、A3 按类型抽取、A7 关联归并的"同义判断"、A9 Check 叙述、A10 PDCA 复盘、各类报告。 必须是代码(确定性/正确性/事务/防幻觉,不容 LLM 漂移):A4 引文⊂源文校验、A6 project_facts 事务写入与查询、HITL 待办状态机、权限与隔离、版本/缓存失效。 → 这条分界线是 skill-first 不塌方的关键(§6 红线1)。

4.2 与已验证底座咬合(承 doc12 §1,T1)

skill 读写事实集:原子 skill 不直连 DB;经 acdm-backend BFF tool(project_facts.query/commit,代码侧强一致+审计)——skill 表达"要什么",代码保证"对不对"。
skill 触发 HITL:skill 内判定可疑→产出结构化可疑点→确定性骨架 interrupt(ba_report 范式,doc12 §0 裁决2)→ BFF awaiting_clarification 待办→人答 update_state 回灌→骨架续跑→skill 重算受影响项。
skill 即 05 任务卡内的"怎么做":人配工作台/卡片(是什么),skill 在任务流里落地(怎么做)——天然实现 05 双主体分工。

4.3 治理:知识沉淀 + 版本 + 业务协同

真源:业务逻辑真源 = skills/custom/<biz-atomic-skill>/SKILL.md(+ references/scripts/eval),git 版本即业务演进史与回滚点。
业务人协同:业务人通过工作台/Wiki 视图读改 SKILL.md 文案与业务规则 → 提 MR → CI 跑该 skill 的 eval 回归 + 人审 gate → 合并即上线(deer-flow skill 运行时按目录扫描,[03] T1)。低技术门槛、清晰版本、可协同——满足领导四诉求,且不破正确性。
注册表:延续 [ai-roles-registry] 思路,建"业务原子 skill 注册表"(名/owner/版本/ABR 映射/eval 状态/启用),extensions_config.json 控启用。

§5 业务原子 Skill 规范(模板 · 约定)

skills/custom/<biz-skill>/SKILL.md frontmatter 业务原子约定(在 deer-flow 原生字段上补):

yaml

---
name: meeting-refine                 # = ABR 标识
description: >                       # 渐进披露第一级 + LLM 选用判据
  会议口水稿精修:分块·说话人归一·去噪·结构化。当任务流需要把原始
  口水稿转为可抽取的干净文本时使用。
owner: 业务方-会议域                  # 业务责任人(协同/审批)
abr: A2                              # 映射 doc12 §2 原子业务需求
version: 1.0.0                       # 语义化版本=业务演进史
allowed-tools: [read_file, write_file]   # 权限收敛(原生字段)
io_contract:                         # 显式契约(防黑箱拼接)
  input:  { transcript_md: string }
  output: { refined_md: string, segments: list }
acceptance:                          # 可证伪验收(对齐 doc01 双 bar)
  usable: "长会不丢中段;说话人归一一致"
  good:   "结构化分段可被 A3 直接消费"
determinism: llm                     # llm | code —— 标注边界(§6 红线1)
facts_contract: none                 # 读/写 project_facts 的契约(none/read/commit)
eval: eval/cases.jsonl               # 必带评测样例(§6 红线2)
---
# 工作流(业务人可读可改的业务规则正文,渐进披露第二级)
1. ……(分块策略/说话人归一规则/禁止臆造,业务规则写这里)
## 引用(第三级,按需)
- references/segmentation-rules.md

确定性硬闸 skill 反例:A4 引文校验不写成 skill,写成代码 tool;若需 skill 形态也必须 determinism: code 且正文是"调用校验工具"的说明,不让 LLM 自行判断"引文是否在原文"。

§6 风险与不可让步红线(§C/§F/§G)

红线·确定性下沉:防幻觉硬闸/事务/校验/权限/隔离必须代码;skill 只表达业务意图。违反=又一个"看着像、其实不可靠"(本研究三次教训的同型)。
红线·eval 回归:每个业务原子 skill 必带 eval 样例 + CI 回归;否则业务人改 prompt 后无人知道效果塌方(§09§1 已现"关 thinking 质量塌方"型)。无 eval 的 skill 不准进生产。
红线·业务编辑 gate:业务人可编辑 ≠ 直推生产;走 MR + eval + 人审(skill-first 不等于无治理)。
skill 泛滥治理:原子粒度有判据(独立价值+独立验收+独立版本);禁"一个意图拆十个碎 skill"或"一个巨 skill 干全部"(后者=回到 mega-prompt,§09§1 根因)。
底座性(§F):这套"业务原子 skill 约定 + 注册表 + eval gate + 与 project_facts/HITL 的契约"必须领域无关,会议只是首批 skill;否则北极星(A-CDM 真底座)不成立。
诚实(§G):本文是范式与规范,非成果;skill-first 降门槛/快交付的论证仍待 M1 的 skill 化实现 T0 跑通。

§7 对 doc12 / 路线 / 契约的影响

ABR→skill 映射(实现表达):A2/A3/A7(同义判断部分)/A9/A10 → 业务原子/组合 skill;A4/A6/HITL 状态机/查询 → 代码 tool;A1 摄入 → 确定性节点。doc12 §2 表新增列"实现形态"按本文 §4.1 归类(skill/代码)。
M1 不变但实现以 skill 表达:M1(A1–A6 单会闭环)中 A2/A3 做成业务原子 skill,A4/A6 代码;M1 验收门加一条:A2/A3 skill 各自 eval 回归通过(T0)。
OpenSpec 契约:底座 OpenSpec change(doc12 §5 开放问题5)须纳入"业务原子 skill 规范(§5)+ 确定性边界(§6 红线1)+ eval gate(红线2)",让 skill-first 成为有契约的底座而非又一份会被打叉的 spec。
审计联动:[10 §3 台账] 增审"16 SKILL 技能系统"章节真实兑现度(渐进披露/allowed-tools/扫描加载是否如 wiki 所述,§C 闸),作为 skill-first 的依赖前置核验。

§8 PMO 结论

采纳 skill-first + 业务原子 skill:与三大已验证事实契合、降技术门槛、加速 AI 原生交付、知识沉淀与版本治理强——领导四诉求成立。
三条不可让步:确定性硬闸用代码 / 每 skill 必带 eval / 业务编辑走 gate。失守任一条,skill-first 立即退化为"业务人写 prompt 的不可靠黑箱",重蹈本研究三次教训。
不改方向只加表达层:doc12 §0 三裁决、§1 修正架构、ba_report 范式、自建 PG 事实集不变;skill 是"业务逻辑怎么写"的范式,不是"底座对不对"的替代。
续探讨点:业务原子 skill 注册表与 ai-roles-registry 是否合一;skill eval 框架选型;业务人编辑 UI(Wiki 协编 vs 专用);组合 skill 的编排是写在 skill 还是确定性骨架(倾向骨架,skill 保持原子)。
下一步(承 doc12 §6,合并本文):1 止损重部署 → 2 OpenSpec 底座契约(含 §5 skill 规范)→ 3 M1(A1–A6,A2/A3 skill 化 + eval,T0)→ 4 开放问题逐定。无 T0 不称达成。

13 · 业务原子 Skill 架构(skill-first 业务实现范式) ​

§1 "业务原子 Skill" 概念定义 ​

§2 为什么 skill-first 对本项目成立(§D 四角色对抗审,含反模式) ​

§3 借鉴的开源项目与最佳实践(可借鉴点 / 不可照搬点) ​

§4 业务原子 Skill 架构(落到本项目) ​

4.1 三层(谁是 skill,谁必须是代码) ​

4.2 与已验证底座咬合(承 doc12 §1,T1) ​

4.3 治理:知识沉淀 + 版本 + 业务协同 ​

§5 业务原子 Skill 规范(模板 · 约定) ​

§6 风险与不可让步红线(§C/§F/§G) ​

§7 对 doc12 / 路线 / 契约的影响 ​

§8 PMO 结论 ​