FDS-22 · B13 业务规则可维护

1. 业务说明

让业务人(会议域负责人)不找开发就能调业务规则:精修怎么去口水、抽取里"什么算风险"、纪要用哪套模板、复盘怎么叙述——这些"换套说法/换套判定"的规则,都写在各技能的正文里(技能 = 一份描述"这件事怎么做"的说明文件,引擎照着执行,详 FDS-04)。

本章不是再建一个新技能,而是把"业务人在站内改这些技能"这件事做成有版本、能自动测试、要人审、可回退的闭环:业务人在站内编辑技能正文 → 提交即生成一个版本(git 一次提交=一版,等于业务决策演进史)→ 自动跑该技能的 eval 样例(eval=预先写好的"输入→应得结果"自动测试用例,改坏了机器立刻报)→ 人审通过才生效 → 上线后发现不对,一键回退到上一版本。

价值:把"什么算风险、纪要长什么样、精修删到什么程度"的知识沉淀进文件、可协同、有历史,而不是锁在某个开发脑子里或某段硬编码里;调一次规则从"提需求等排期"变成"自己改、当场看测试结果、审过即上"。

边界(承接 FDS-04 三条不让步,本章只是把它做成业务人可用的能力):可被业务人改的只有"业务判断"那部分技能正文;正确性硬规矩永远是代码,不进技能——出处校验(引文是否真在原文,B6)、事实库写入与版本失效(B8)、待办状态机与跨会归并(B9)、权限与项目隔离,这些错了会算错数据/出假结论,不交给模型自律,业务人也改不到。

2. 用户操作与界面

业务人入口在项目工作台的"业务规则"页(仅会议域负责人/管理员可见,普通参会人看不到也改不了)。一条编辑闭环全程站内,不接任何外部 IM/平台:

• 规则列表:四项技能(精修/抽取/纪要/复盘)各一行,显当前生效版本号、上次改动人、上次改动时间。
• 在线编辑器:左编辑技能正文(只暴露白话规则那段,frontmatter 的契约/工具权限等机器字段不让业务人乱动,系统侧锁定),右侧并排显示"当前生效版"做对照;改抽取规则时旁边给"现有 eval 样例"清单,提醒"动了判定记得补样例"。
• 提交:必填一句"这次改了什么"(进版本历史的说明)。
• 自动测试结果:同页实时显示该技能 eval 跑没跑完、几条过几条挂;挂的样例直接列"输入摘要 / 期望 / 实际"差异,业务人据此回去改。
• 人审:测试全绿才进"待人审";审批人(技能 owner 或管理员)在站内待办面板收到提醒,看 diff(新旧正文逐行对照)+ eval 报告,点通过/驳回,驳回需写理由。
• 版本历史 + 回退:每版可看谁/何时/改了什么/当时 eval 结果;选任一历史版"回退",系统把旧正文作为一次新提交(同样过 eval + 人审,不绕闸)。

3. 数据与接口

被维护对象 = FDS-04 定义的技能文件,不新增结构;本章新增的是"编辑/版本/测试/评审/回退"这套流程的数据与接口。

被维护对象(沿用 FDS-04,不改):

skills/custom/<技能名>/
  SKILL.md          # frontmatter(机器读,系统锁) + 业务规则正文(业务人改)
  references/        # 模板/细则(正文按需引用)
  eval/cases.jsonl   # 必需:验收样例,改完必跑;无样例不准进生产

版本载体：git。一次提交 = 一个版本，commit message 带 [技能名] 改动说明 by <业务人>，对应 frontmatter 里 version 升一位（业务决策演进史 + 回退点）。技能正文与 eval/cases.jsonl 同仓同提交，规则与样例绑定演进。

流程状态记录(acdm-backend，按项目隔离):一张技能改动评审表,字段——

字段	含义
id	改动单号
project_id	所属项目(隔离)
skill_name	哪个技能(精修/抽取/纪要/复盘)
editor_sub / submitted_at	谁提交、何时
change_note	业务人填的"改了什么"
git_ref	该版本提交号(回退锚点)
eval_status	自动测试:跑中/全过/有挂
eval_report	挂了哪些样例、期望 vs 实际
review_status	待人审/通过/驳回
reviewer_sub / review_note	谁审、驳回理由
effective	是否当前生效版

接口(都在 acdm-backend,技能不直连库、不接外部 IM,承接 FDS-04 §5):

• 取技能正文与版本历史(列表/编辑器/历史页用)。
• 提交改动:落 git 一版 + 建评审单 + 触发该技能 eval。
• 查 eval 进度与报告(页面轮询/推送)。
• 人审动作:通过(置生效、引擎切新版)/ 驳回(回编辑态)。
• 回退:取某历史版正文作为一次新提交,走同一闸。
• 所有写操作经 acdm-backend,强一致与权限由代码侧保证;通知一律站内待办/消息。

4. 技术实现(分步)

1. 入口与权限:工作台"业务规则"页,后端 require_project_access + 会议域 owner/管理员角色双校验;非授权角色看不到入口、调接口也被拒(沿用项目既有授权层)。
2. 编辑与契约保护:编辑器只放出技能正文白话段;frontmatter(inputs/outputs/allowed-tools/eval 路径等机器字段)系统侧锁定不可编辑——防止业务人误删工具权限或改坏契约导致引擎装配失败。
3. 提交即一版:点提交→写技能正文(必要时连同新增/改的 eval 样例)→ 一次 git 提交(message 带技能名+说明+人)→ 建评审单(状态=测试中)。
4. 自动跑该技能 eval(复用现有 CI):复用项目已有 CI 跑 eval/cases.jsonl——逐条把样例输入喂该技能、比对输出是否满足样例期望;只跑这一个技能的样例(快、聚焦),结果与差异写回评审单。
5. 不过即回:任一样例挂→状态=有挂,页面列差异,业务人回第 2 步改;没绿不进人审(机器闸,不靠人记得跑)。
6. 人审:全绿→状态=待人审,审批人站内待办收到提醒;审批人看正文 diff + eval 报告,通过则置该版生效、引擎下次执行加载新版;驳回回编辑态并记理由。
7. 生效切换:生效版指针更新到新 git_ref;引擎按指针取技能正文执行(老的不删,留作回退源)。
8. 回退:版本历史选旧版→把旧正文作为一次新提交重走第 3~7 步(同样自动测试+人审),保证"回退也是一次受控变更",不留绕过后门。
9. 可逆与留痕:历史不物理删;每次生效/回退/驳回均留谁/何时/原因,可审计、可追责、可复原(沿用项目可逆与留痕原则)。

5. 技能 or 代码

• 被维护对象 = 技能:精修/抽取/纪要/复盘四个技能的业务规则正文(怎么去口水、什么算风险、纪要模板、复盘叙述)——业务人可读可改、版本化(规范见 FDS-04)。
• 这套编辑/版本/测试/评审/回退流程 = 代码 + 复用既有能力:权限校验、提交落 git、触发并解析 eval、状态机(测试中→待人审→生效/驳回)、生效指针切换、回退、留痕——确定性、关乎"改动是否受控",必须代码,且复用项目现有的知识库协同编辑思路与 CI,不另起炉灶。

边界(承接 FDS-04 三条不让步):正确性硬规矩(出处校验/写库/状态机/隔离)不在可编辑范围,代码实现、业务人改不到;每个被维护技能必须带 eval 样例,无样例不准进生产;任何改动必须自动测试通过 + 人审通过才生效,业务人能改 ≠ 直接上线。

6. 二开归类

• 🟢 复用 deer-flow:技能机制本身(SKILL.md 装配、引擎按技能执行、git 版本化)——直接用,FDS-04 已锁定的原生能力,本章不改内核。
• 🟡 基于现有流程扩展:站内编辑界面、提交即测、人审闸接到项目现有知识库协同编辑流程与 CI——在既有扩展位/流水线上加这条受控变更链路,不动 deer-flow 内核,也不新建一套测试/评审系统。
• 🔴 从头自建:无(不需要新地基,流程数据表是轻量记录,挂在 acdm-backend 既有授权与可逆体系内)。

7. 与人机协同模型关系

对应人机协同模型里"人配置/规则、AI 按规则做事"的配置-执行分工:业务人通过本闭环配置 AI 怎么做(改技能规则),AI(引擎+技能)按生效版执行精修/抽取/纪要/复盘。改动不是即时生效而是走"提交→自动测试→人审→生效"的受控流,正是模型强调的AI 与人共写、关键变更人把关、全程可回滚:测试是机器把第一道关、人审是人把第二道关、回退保证任何一版都能撤回,知识沉淀在文件与版本历史而非个人。

8. 验收(可证伪)

• 可用:授权业务人能在站内改四个技能任一的规则正文并提交;非授权角色看不到入口、调接口被拒。
• 可用:一次提交确实产生一个可见 git 版本,版本历史能看到谁/何时/改了什么。
• 可用:提交后自动跑且只跑该技能 eval;故意把样例改挂→状态显"有挂"并列出期望 vs 实际,且该改动无法进入人审(机器闸有效)。
• 可用:eval 全绿后进待人审,审批人站内收到提醒;驳回回编辑态并留理由;通过后引擎下次执行用新版(可用新旧规则差异在产出上验证,如换抽取"什么算风险"措辞后产出随之变)。
• 可用:从版本历史选上一版回退,回退同样走自动测试+人审,生效后产出回到旧规则行为;全程留痕可审计。
• 反例(必须做不到):业务人改不到出处校验/写库/状态机/权限这类代码硬规矩;未过自动测试或未过人审的改动不会生效;无 eval 样例的技能不准进生产。

9. 现状

没有。当前业务规则散在硬编码或某段大提示词里,业务人想调"什么算风险/纪要模板/精修删多狠"只能提需求等开发排期,无版本、改坏了没自动测试兜底、也没受控回退。本章把"业务人在站内可改 + 提交即版本 + 自动测试 + 人审 + 可回退"这条闭环补齐,让规则成为业务人可维护、可协同、有历史的资产。

10. 风险与取舍

• 风险:业务人把规则改坏(如精修删过头丢信息、抽取判定改乱)。取舍:每技能必带 eval 样例 + 改动强制走自动测试 + 人审(FDS-04 三条不让步落地);机器闸先拦,人审再拦,生效后还能一键回退。
• 风险:业务人误改 frontmatter 契约/工具权限导致引擎装配失败。取舍:编辑器只放出白话规则段,机器字段系统侧锁定,业务人改不到。
• 风险:改了规则却没补对应 eval 样例,自动测试"假绿"。取舍:改抽取/判定类规则时界面提示并要求关联样例;评审人审 diff 时一并看"判定变了样例是否同步";样例与规则同提交、绑定演进。
• 风险:业务人试图绕开测试/人审直接上线,或把正确性逻辑塞进技能让模型"自律"。取舍:生效指针只认"测试过+人审过"的版本,无旁路;正确性硬规矩在代码、不在可编辑技能范围,业务人触达不到。
• 取舍:回退也强制走自动测试+人审而非"秒回",牺牲一点应急速度换"任何生效版都受控、不留后门"的一致性。