PRD — AI Specialist 价值输出("客户为什么选我们")
状态: 草案待评审 · Owner: Franky(产品)· 日期: 2026-07-06 战略上下文: PRODUCT_STRATEGY.zh.md —— 本 PRD 是当前两周聚焦的支柱②("AI Specialist 价值输出"),与支柱①(流水线可靠性)并行。 架构对齐: ADR-033(分层 Specialist 架构——状态:Draft)· ADR-034(模板作用域)· ADR-035(评测与 golden set——状态:Proposed,尚未接受)· ADR-037(运行时只读 + 人审批晋升——关闭 OQ-205)· ADR-008(KB K1/K2)· ADR-020(隔离) English version: prd-specialist-value-output.md
1. 问题陈述
我们的差异化是客户"雇了一个专业的数字同事",而不是买了一个软件。但这份专业度今天依赖:(a) 每个 Specialist 一段手写的 systemPrompt 大文本,(b) 4 个硬编码的角色模板,(c) 提交在代码仓库里的 SOUL.md / SKILL.md 文件——AM/运营完全看不见、改不了,(d) 一条不错的检索链。与此同时,我们收到的最富的质量信号(Expert 对草稿的编辑)被直接丢弃。
后果:
- 新客户/新领域的 onboarding 需要工程师干活(改仓库文件、做 prompt 手术)——"行业红线引擎"和 Specialist 能力无法沉淀为可复用的产品资产。
- 过长的 persona 会静默顶掉整个角色模板(prompt-loader 覆盖启发式,ADR-033 点名)——业界第一反模式。
- 我们无法证明 Specialist 是专业的——没有领域准确性度量,配置改动无法验证,价值主张无法自证。
2. 目标
- Specialist 的专业身份由五个运营可配置的资产定义——Soul(我是谁)、Skills(我怎么做)、KB(我知道什么)、Tools(我能做什么)、反馈闭环(我怎么变好)——在 Ops 后台管理,不在代码仓库里。
- 已知领域的新 Specialist 可以不经工程师完成配置、预览与验证。
- 每次配置变更都有版本、有审计、有 eval 门禁(不允许静默的质量回归)。
- 反馈闭环把 Expert/客户的纠正变成草稿质量每周可度量的提升。
每个目标都对应 §6 的一个指标(配置耗时、golden set 通过率、采纳率)。目标是 outcome;绝对目标值在度量基线落地后设定(见 §6 注)。
非目标(本 PRD 不做)
- Agent 对自身 skill 的写回(OQ-205 —— 已由 ADR-037 关闭:运行时只读;闭环提案、人审批)。
- 完全自主的工具执行:R6 把工具接到聊天主链路,但写类动作永远需要 Expert 审批——去掉这道闸不在范围内。
- 超出 registry/Nango/MCP 配置面的按客户定制工具集成(定制集成仍是工程工作)。
- 营销垂类专属工具(#3699/#3701 —— 以 ICP 扩张决策为闸)。
- ADR-033 完整 11 阶段流水线;本 PRD 实现其 L0/L1/L6 层、逐轮应用它们的运行时上下文组装主干(R5,L2/L3 的最小集),外加为配置变更做门禁所需的最小 L7。
3. 现状(基于 origin/dev,2026-07-06 核实;各行已按 2026-07-07 代码审计更正——见 master plan §2.1)
| 资产 | 今天在哪里 | 可配置? |
|---|---|---|
| 人设 | specialists.systemPrompt(/ops/specialists 里一个 textarea);SOUL.md 在仓库(orgs/<org>/...);合并逻辑由 PR #244 修正 | 部分(仅大文本) |
| 角色/领域模板 | agent/prompts/<key>.txt,经 specialists.prompt_template_key 的 4 个封闭枚举(ADR-034) | 可选择,不可编辑 |
| Skills | 仓库里的 orgs/<org>/skills/**/SKILL.md,只读 bind-mount(#226);M2 计划迁 R2——M2 的 runtime-config HTTP 通道已存在(agent 启动时 GET /v1/internal/org/{slug}/runtime-config 下发 soul_md + config_yaml + skills[]) | 否(仓库文件;下发通道已建成) |
| KB | K1/K2(ADR-008);客户上传 UI 已上线(#297);混合检索+rerank(ADR-032);kb_retrieval_event 遥测可与消息关联(#3189) | 是(文档);无 golden answers / 结构化规则 |
| 反馈 | Correction 实体 + POST /learning/corrections;编辑差异并未被丢弃——releaseDraft/respond 已将 wasEdited + editRatio + correctionCategory 写入 Message.metadata(#3323 已上线);correction_embeddings 已被读取用于 few-shot 注入(#3406,flag correction_fewshot_enabled 默认 OFF);纠正→KB 处理器已完整但曾无审批自动写入——现按 ADR-037 由 correction_auto_ingest_enabled 门禁默认关闭 | 部分(信号已捕获;消费侧 flag 门禁,人审批待 R4.4) |
| 评测 | ADR-035 为 Proposed(eval sandbox + golden sets——尚未接受);agent/evals/domain/ golden-set + LLM 评审 + 预置 KB 的 harness 已存在(#3324;judge 未经人工校验) | 未接到配置变更上 |
4. 需求
用户故事
- 作为 AM,我想不依赖工程师、直接从客户 brief 配置出新 Specialist 的 Soul/Skills/KB,让新客户一天内上线。
- 作为 SuperAdmin,我想要目录级原型,可按 org 物化和覆盖,让领域能力成为跨客户复用的资产。
- 作为 Expert,我想在每份草稿上看到它由哪个 skill、哪些 KB 来源产出、有无红线违规,让我审得快、发得放心。
- 作为 Expert,我希望我的编辑被自动捕获为改进信号,让"好好服务客户"本身就是在训练 Specialist。
- 作为客户用户,我想在每个渠道遇到同一个人格、拿到专业正确的回答,感觉是在和一位靠谱的同事共事——而不是一个带设置项的机器人。
- 作为 AM,我想给 Specialist 授予限定范围的工具(如订单查询、CRM 只读),让它用真实数据回答,而不是只会谈论这个领域。
权限与发布流程
编辑 ≠ 发布。 起草配置变更是自由的;发布是独立动作,必须过 eval 门禁(R4.6)且全程审计。
| 资产 | 编辑 | 发布(过 eval 门禁) | 备注 |
|---|---|---|---|
| 目录级 Soul / Skill(原型) | SuperAdmin | SuperAdmin | CD-19:SA 管 Specialist |
| org 实例的 Soul / Skill 覆盖 | AM + SuperAdmin | AM + SuperAdmin | Org × Specialist 作用域(ADR-020) |
| K2 KB(Specialist 全局) | AM + SuperAdmin | AM + SuperAdmin | |
| K1 KB(客户文档) | 客户 admin(现有 UI) | 不适用——检索时资产,无发布步骤 | |
| 工具绑定(按 Specialist 实例) | AM + SuperAdmin | AM + SuperAdmin | 授予数据访问;读类工具白名单放行,写 类工具逐次 Expert 审批(R6.4) |
非功能需求
| # | 约束 |
|---|---|
| NFR1 | 延迟:组装 + 检索级联相对现有起草路径的额外开销 ≤ 300ms(p95);级联各级可按预算跳过(R5.3)。 |
| NFR2 | 异步发布:eval 门禁永不阻塞实时聊天;发布进入"发布中(eval 运行中)"状态,异步完成。 |
| NFR3 | token 压力下的截断顺序:few-shot → 历史 → 补充 KB → skill 模板。红线与 Soul 身份永不截断。 |
| NFR4 | trace 数据:R5.4 的 trace 行按 Org × Specialist 作用域(实体 docstring 声明 ADR-020 行),默认保留 90 天。 |
| NFR5 | 配置内容安全:运营录入的所有 Soul/Skill/模板内容须通过 AI 输出纪律校验(#3054/#3500——不得嵌入基础设施细节或服务器路径)。 |
| NFR6 | 工具输出是不可信输入(R6):永不被解释为指令、有注入防护,进入任何客户可见草稿前按 #3054/#3500 清洗。 |
R1 — Soul:独立人格,后台可配置 【P0】
Specialist 拥有独特、持久、跨渠道跨会话一致的人格,以结构化数据定义,不是 prompt 大文本。
| # | 需求 |
|---|---|
| R1.1 | 每 Specialist 的结构化 Soul schema:身份(名字、角色、简介)、语气与文风规则、边界(绝不做/绝不说)、语言、署名习惯。平台侧存储(DB;大资产放 R2),不在代码仓库。 |
| R1.2 | Ops 后台编辑器(/ops/specialists):表单化 Soul 编辑 + 组装后 prompt 实时预览;取代裸 systemPrompt textarea。裸 textarea 仅作"高级"逃生口保留,并带显式弃用判据:全部在管 Specialist 迁移完成、且连续 4 周未使用后移除(它绕过结构化红线,不能永久存在)。 |
| R1.3 | Agent 侧分层 prompt 组装:Soul 永不取代角色模板——修掉 persona 覆盖启发式(ADR-033 设计规则:层必须保持可分离)。 |
| R1.4 | 版本化 + 审计:每次 Soul 变更记录谁/何时/改了什么;一键回滚到历史版本。 |
| R1.5 | 迁移:存量仓库 SOUL.md 内容导入新存储;平台管理的 Specialist 退役仓库文件路径。运行时对人格内容保持只读(ADR-037)。 |
验收标准(R1):
- 创建/编辑 Soul 产生带版本的记录(作者、时间戳);回滚精确恢复此前的组装输出。
- 组装 prompt 预览与 agent 在同一配置版本下实际收到的内容逐字节一致。
- Soul 超出 token 预算时在保存时被拒绝并给出字段级报错——运行时绝不静默截断。
- 给定超长 persona,角色模板段仍出现在组装结果中(覆盖启发式的回归测试)。
R2 — Skills:领域场景能力,后台可配置 【P0】
Skill = 一个场景作用域的指令包(触发条件 + 操作规程 + 模板 + 红线),让 Specialist 胜任一类具体任务(如"Launchpad campaign 线程"、"制裁核查升级")。
| # | 需求 |
|---|---|
| R2.1 | Skill 数据模型:平台侧 skill 注册表;每个 skill 含触发条件(场景/主题)、指令、回复模板、升级规则、结构化红线段(草稿必须遵守的硬规则),以及预留的 tools 字段——声明该 skill 依赖哪些工具能力(由 R6 消费;现在预留,避免 Phase 6 返工)。按 ADR-020 以 Org × Specialist 作用域;尊重目录原型 vs 物化实例的区分(#3447)。 |
| R2.2 | Ops 后台 CRUD:创建/编辑/克隆 skill;绑定到 Specialist 实例;导入存量仓库 SKILL.md。 |
| R2.3 | Agent 运行时从平台存储(R2/DB)加载 skill,替代仓库 bind-mount;保持只读契约(#226)。 |
| R2.4 | 逐轮 skill 选择:扩展 ADR-034 的解析链,按触发匹配选出当轮激活的 skill,角色模板兜底——永不静默跨域回退(#1203 那类串味)。 |
| R2.5 | 红线执行钩子:激活 skill 的结构化红线 (a) 起草时注入为约束,(b) 起草后校验并向 Expert 标记违规。(完整护栏引擎是后续工作;本条先建立它的数据基座。) |
| R2.6 | 原型 → 实例继承语义:目录 skill 物化到 org 为 copy-on-materialize;目录更新永不 静默传播——实例侧看到显式的"上游已更新,是否拉取?"入口,拉取后重跑 eval 门禁。(静默传播会绕过 R4.6。) |
验收标准(R2):
- 消息命中 skill 触发条件即激活该 skill,组装 trace 中列出 skill id + 版本。
- 无命中的消息兜底到角色模板 + 弃答姿态;绝不激活其他领域的 skill(#1203 回归测试)。
- 编辑 skill 产生新版本;进行中的会话继续使用轮次开始时的版本。
- 违反输出纪律规则(NFR5)的 skill 内容在保存时被拒绝。
- 目录 skill 更新在被显式拉取并重跑 eval 之前,不改变任何已物化实例。
R3 — KB:领域知识,后台可配置 【P0】
大部分已建成——本需求做补全而非重建。
| # | 需求 |
|---|---|
| R3.1 | Golden answers 成为一等 KB 类型:每个 Specialist 领域的精编 Q→A 对,优先检索,按"原文+适配"使用(ADR-033 L1)。 |
| R3.2 | 结构化领域规则:政策/资格/流程类事实作为结构化条目(检索已支持 effective_date / audience / jurisdiction 元数据——在编辑 UI 中暴露)。 |
| R3.3 | AM/Ops 侧 K2(Specialist 全局)内容编辑面,与客户侧 K1 上传 UI 互补。 |
| R3.4 | KB 覆盖率报告:哪些客户问题没有/只有弱检索命中(kb_retrieval_event × 消息)——AM 的内容编写待办清单。 |
| R3.5 | KB 摄取连接器:从外部源(Notion / Drive / 网站,经 MCP 或 Nango)定时同步进 K1/K2。同步内容走与上传相同的精编/版本/eval 路径——实时外部数据永不绕过 KB 存储直接进检索(那会破坏版本化、eval 和隔离;实时数据属于 Tools,见 R6)。 |
验收标准(R3):
- 存在匹配 golden answer 的问题,检索结果中它排在混合检索之前。
- Golden answers / 结构化规则携带 effective_date / audience / jurisdiction 元数据,检索时按其过滤。
- 覆盖率报告列出无命中/弱命中轮次,并链接到源会话。
- 连接器同步的文档变更时重新版本化并重嵌入;连接器故障退化为"陈旧但可用"的 KB,绝不阻塞检索。
R4 — 反馈闭环:可度量的持续提升 【P1】
每次 Expert 编辑和客户反应都成为信号;信号变成 KB/skill/校准的改进;改进在看板上可见。
| # | 需求 |
|---|---|
| R4.1 | releaseDraft 编辑差异捕获(#3323):持久化 wasEdited、diff、编辑距离、编辑类别。建议前置:它是一切度量的基线——虽然 R4 整体是 P1,建议把这条拉进两周窗口先做。 |
| R4.2 | 草稿质量指标:采纳率(未编辑直发 %)、编辑距离趋势,按 Specialist × Org × skill 维度;可与 KB 检索事件关联。 |
| R4.3 | 发送时一键纠正分类(事实错误/语气/漏步骤/错误动作)——补上现有 Correction 捕获的 UI 缺口。 |
| R4.4 | 纠正 → KB 精炼消费者(完成 #303):纠正生成建议的 KB/golden answer 修改;人(AM/Expert)审批;不自动生效(ADR-037)。是行为纠偏,不是从零新建:处理器今天已会分类、去重并直接写 KB(无审批)——ADR-037 用 correction_auto_ingest_enabled 把该行为门禁关闭;R4.4 以"提案→审批"流程取而代之。 |
| R4.5 | Few-shot 复用:检索相关历史纠正(correction_embeddings,当前只写不读)注入起草上下文。 |
| R4.6 | 配置变更 eval 门禁(ADR-035):每 Specialist 的 golden set;编辑 Soul/Skill/KB 触发沙箱 eval;回归即阻断发布(可带审计强制通过)。没有这条,R1–R3 的可配置化就是回归轮盘赌。 |
| R4.7 | 客户反馈捕获:客户 portal 中每条回复的轻量反应(👍/👎 + 可选评论),汇入同一信号存储。 |
验收标准(R4):
- 100% 已发送草稿持久化了
wasEdited+ diff + 类别(对发送日志做抽样审计)。 - 配置变更的 golden set 得分低于基线 − 阈值时,发布被阻断; 强制通过必须填写理由并进审计日志。
- 纠正驱动的 KB 提案未经人显式审批绝不生效。
R5 — 运行时应用:上下文组装与逐轮执行 【P0】
R1–R3(以及 R6 的工具绑定)定义了可配置资产;R5 是它们的消费者——没有它,它们只是几张配置表。R5 规定一条入站客户消息如何被 Soul + Skills + KB 确定性地、可追溯地变成一次专业起草。
参考轮次流程(Kaito 实例——客户问"XYZ launchpad 怎么参与?"):
1. 路由定位 org=kaito, specialist=Amy → 加载她的配置
2. 触发匹配 消息命中 skill「Launchpad FAQ 分诊」
→ 操作规程 + 回复模板 + 红线(不谈价格/分配/vesting)
3. 知识检索 golden answer 优先(参与步骤+官方链接)→ 不足则混合检索 K1/K2
4. 纠正复用 few-shot:过去类似回复被 Expert 怎么改过
5. 分层组装 角色模板(打底)← Soul(身份/语气)← 激活的 skill
← KB 引用 ← 会话历史 ← few-shot
优先级:红线 > crisis > active directives > skill 规程 > Soul > 模板;各层有 token 预算
6. 起草 → { 草稿, 置信度, 风险 }
7. 校验 起草后逐条核对红线;违规标红给 Expert
8. 弃答 无 skill 命中 + KB 弱命中 → 转升级姿态,永不硬编
| # | 需求 |
|---|---|
| R5.1 | 确定性上下文组装器:固定层序、显式优先级(红线 > crisis directive > active directives > skill 规程 > Soul > 角色模板)、每层 token 预算、KB 内容必须带引用 。吸收 R1.3 的 agent 侧部分。crisis directive 与 active_directives(L0.5,#3692)是已上线的层,组装器必须保留其行为,不是新增工作。 |
| R5.2 | 触发评估:多 skill 命中的合并/裁决规则;显式无匹配兜底到角色模板 + 弃答姿态(实现 R2.4 的运行时部分;#1203 那类串味永久封死)。 |
| R5.3 | 检索编排级联:golden answers → K1/K2 混合检索 → 纠正 few-shot,按序执行,各级可按预算跳过(消费 R3.1、R4.5)。 |
| R5.4 | 逐轮组装 trace:持久化每次起草用了哪个 Soul 版本、哪些 skill、哪些 KB 块与预算——可与消息、编辑差异、eval 运行关联。同时服务调试、eval 归因、以及未来面向客户的质量凭证。trace 行按 Org × Specialist 作用域,默认保留 90 天(NFR4)。 |
| R5.5 | 弃答 / 出界改道:组装输入置信度低时的标准姿态("我确认后回复您" + Expert 升级,ADR-033 L5)——Specialist 永不在配置能力之外硬答。 |
验收标准(R5):
- 同一消息 + 同配置版本 + 同 KB 快照 → 组装出的上下文完全一致(确定性测试)。
- 无论 token 压力如何,红线段在每次组装结果中完整出现(截断顺序测试,NFR3)。
- 每份草稿都有 trace 行(Soul 版本、skill id+版本、KB 块 id、预算)——驱动 §6 的 trace 覆盖率指标。
- 组装输入低于置信下限时,草稿为标准弃答回复,且队列项带相应标记。
R6 — Tools:Specialist 可执行的能力,后台可配置 【P1】
KB 回答"Specialist 知道什么";Tools 回答"它能做什么"。没有工具,Specialist 只能谈论 KYC/订单/数据;有了工具,它能取真实事实、执行真实(经审批的)动作——这是价值天花板和定价锚点。建立在既有基础设施上:静态 AGENT_TOOL_REGISTRY(bespoke | Nango)、ADR-029 执行运行时、ActionPolicyService 策略门禁(#689 跟踪 MCP 方向)。注意:tool_specialist_bindings(ADR-020 中命名的那一行)待新建——今天并不存在;现状是 specialists.tools[] string 数组 + 静态注册表(需 expand-contract 迁移)。
为什么 Tools 不属于 KB: 知识是静态、精编、有版本、可 eval 的;工具是实时、可执行、有副作用的。把实时工具数据混进 KB 检索会破坏版本化(golden set 无法针对活数据出题)、隔离(外部源没有 Org × Specialist 边界)和层分离规则(ADR-033)。
| # | 需求 |
|---|---|
| R6.1 | 工具来源:注册表支持 bespoke、Nango,以及 MCP server 作为第三类工具来源;MCP server 配置(端点、认证、允许的工具子集)是运营管理的集成数据,遵循 ADR-030 凭证隔离。 |
| R6.2 | 按 Specialist 的工具绑定在 Ops 后台可配置(新建 tool_specialist_bindings——待创建,从 specialists.tools[] 迁出);目录原型声明默认工具集,实例可覆盖——适用 R2.6 继承语义。 |
| R6.3 | 聊天主链路接入:组装器(R5)只向起草引擎暴露 激活 skill 声明的工具 ∩ Specialist 绑定 ——无激活 skill,无工具。 |
| R6.4 | 每次调用过策略门禁(ActionPolicyService):读类工具按绑定白名单放行;写类工具在 Expert 队列生成审批项——工具审批是复核环的一部分,永不绕过它。 |
| R6.5 | 工具输出是不可信输入(NFR6);每次调用带 osa_id 进审计(现有 ToolCall 审计);工具报错 fail-open 为"无工具起草 + 标记给 Expert",绝不产生坏轮次。 |
验收标准(R6):
- 未同时满足"绑定到该 Specialist"且"被激活 skill 声明"的工具,绝不暴露给起草引擎(默认拒绝测试)。
- 写类工具调用生成 Expert 审批项;审批前不执行任何动作。
- MCP/工具凭证按隔离作用域存储,绝不出现在 prompt、trace 或客户可见输出中。
- 含对抗性指令的工具输出不改变 Specialist 行为(注入回归测试)。
- 起草中工具故障产出"无工具草稿 + Expert 标记"——绝不向客户暴露错误。
5. 设计原则
- 层保持可分离(ADR-033):Soul(L0)、Skills/规则(L1/L3)、KB(L1)、校验(L4)、反馈(L6)是彼此独立的资产——永不重新塌缩成一 个 prompt。
- 配置是数据,不是散文:带校验的结构化字段,不是更大的 textarea。
- 先度量、边配置(measurement-first):没有 eval 门禁 + 编辑信号基线(R4.1、R4.6),任何可配置化都不发布。
- 人审批的改进:闭环只提案;运营审批(OQ-205 只读默认,现为 ADR-037)。
- 隔离即构造:每张新表按 ADR-020 携带 Org × Specialist 作用域;新实体的 docstring 必须声明其隔离矩阵行。
- 每一轮可追溯:任何一份草稿都能被解释——它由哪些资产版本、哪些 skill、哪些 KB 块产出(R5.4)。
6. 成功指标
| 指标 | 定义 | 方向 |
|---|---|---|
| 草稿采纳率 | 未经 Expert 编辑直接发送的草稿 % | 每周 ↑ |
| 平均编辑距离 | 被编辑草稿的归一化 diff 大小 | ↓ |
| 配置耗时 | 从"新客户 brief"到"验证通过的 Specialist 配置"(无工程师)的小时数 | < 1 天 |
| KB 无命中率 | 无/弱检索命中的客户轮次 % | ↓ |
| Golden set 通过率 | 每 Specialist 的 eval 分,每次配置变更都跑 | ≥ 基线,永不静默 ↓ |
| 信号捕获率 | 已发送草稿中记录了编辑差异+类别的 % | → 100% |
| 组装 trace 覆盖率 | 拥有完整逐轮资产 trace 的草稿 %(R5.4) | → 100% |
基线与目标值: 绝对目标值刻意留空——在 T0.1 落地两周后(拿到首个编辑信号 基线)设定。测量来源:采纳率/编辑指标来自 T0.1 的发送日志捕获;无命中率来自
kb_retrieval_event;golden 通过率来自 ADR-035 eval 运行;trace 覆盖率来自 R5.4 行与已发送草稿的关联。
7. 任务拆解
图例:[BE] NestJS · [FE] 前端 · [AG] agent · [DS] 设计/决策。阶段内顺序 = 建议次序。规模为相对估计(S/M/L)。
Phase 0 — 地基(最先做,本窗口内)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T0.1 | [BE] releaseDraft 编辑差异捕获(R4.1,#3323):发送时持久化 wasEdited/diff/距离/类别;可安全回填 (已完成——2026-07-07 落地,feat/specialist-value-output-phase0) | S | — |
| T0.2 | [BE] 草稿质量指标端点 + 最小 /ops 看板卡片(R4.2) (已完成——2026-07-07 落地) | S | T0.1 |
| T0.3 | [DS] Soul 与 Skill 的 schema 设计文档(字段级),含红线段、版本模型、R2-vs-DB 存储切分,以及原型→实例继承语义(R2.6:copy-on-materialize + 显式拉取);对照 ADR-033 L0/L1 评审 (设计文档已于 2026-07-07 起草——统一配置资产模型,待评审) | M | — |
| T0.4 | [DS] 确认 OQ-205 默认(运行时只读;闭环提案、人审批)——升格为 ADR (已完成——ADR-037,2026-07-07) | S | — |
Phase 1 — 可配置 Soul(R1)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T1.1 | [BE] Soul 实体 + 迁移(版本化、审计;org 覆盖时按 Org×Specialist 作用域,原型层归目录) | M | T0.3 |
| T1.2 | [BE] Soul CRUD API + 校验;从仓库 SOUL.md 与存量 systemPrompt 的导入脚本 | M | T1.1 |
| T1.3 | [FE] /ops/specialists Soul 编辑器:结构化表单 + 组装 prompt 预览 + 版本历史/回滚 | M | T1.2 |
| T1.4 | [AG] 分层 prompt 组装:经 agent-api 消费结构化 Soul;移除 persona 覆盖启发式;Soul 永不顶掉角色模板 | M | T1.2 |
| T1.5 | [BE/AG] 平台管理 Specialist 退役仓库 SOUL.md 路径;运行时只读 | S | T1.4 |
Phase 2 — 可配置 Skills(R2)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T2.1 | [BE] Skill 实体 + 绑定(新建绑定表——现无此表;ADR-020 行)+ 迁移;按 #3447 区分原型/实例 | M | T0.3 |
| T2.2 | [BE] Skill CRUD API + 仓库 SKILL.md 导入(以 Kaito/Acme 的 skill 文件做种子) | M | T2.1 |
| T2.3 | [FE] Skill 管理 UI:目录、编辑器(触发/指令/模板/红线分区)、绑定到 Specialist | L | T2.2 |
| T2.4 | [AG] 平台加载 skill 替代仓库 bind-mount;基于触发的逐轮 skill 选择,扩展 ADR-034 链;显式无匹配兜底(不允许静默跨域默认) | L | T2.2 |
| T2.5 | [AG/BE] 起草时红线注入 + 起草后违规标记,呈现在 Expert 工作台 | M | T2.4 |
Phase 3 — KB 补全(R3)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T3.1 | [BE] Golden answer KB 类型 + 优先检索路径 | M | — |
| T3.2 | [FE] AM/Ops 的 K2 编辑面(结构化规则,元数据:effective_date/audience/jurisdiction) | M | T3.1 |
| T3.3 | [BE/FE] KB 覆盖率报告:kb_retrieval_event × 消息("我们答不上的问题") | M | — |
Phase 4 — 反馈闭环收口(R4)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T4.1 | [FE] 发送时一键纠正分类(R4.3) | S | T0.1 |
| T4.2 | [BE] 纠正 → 建议的 KB/golden answer 修改,人审批队列(R4.4,完成 #303) | M | T3.1, T4.1 |
| T4.3 | [AG/BE] 历史纠正 few-shot 检索注入起草上下文(R4.5,激活 correction_embeddings) | M | T0.1 |
| T4.4 | [BE/AG] Eval 门禁:每 Specialist golden set 存储 + Soul/Skill/KB 发布时沙箱运行;回归阻断 + 审计化强制通过(R4.6,ADR-035) | L | T1.x, T2.x, T3.1 |
| T4.5 | [FE/BE] 客户每条回复 👍/👎 + 信号摄入(R4.7) | S | — |
| T4.6 | [BE/FE] 提升看板:采纳率/编辑距离/无命中率/golden 通过率的时间序列(§6 指标) | M | T0.2, T4.4 |
Phase 5 — 运行时应用(R5)
T1.4 与 T2.4 的 agent 侧工作在本模块内实现:T5.1 拥有组装器(吸收 T1.4),T5.2 拥有触发选择(吸收 T2.4 的运行时部分)。两者在上文保留列出以便追溯,但共享同一份 spec 与同一个 owner。
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T5.1 | [AG] 确定性上下文组装器:层序、优先级(红线>crisis>active directives>skill>Soul>模板,同 R5.1)、每层 token 预算、强制 KB 引用(R5.1) | L | T0.3, T1.2, T2.2 |
| T5.2 | [AG] 触发评估引擎:多 skill 合并/裁决,显式无匹配 → 弃答姿态(R5.2、R5.5) | M | T2.2 |
| T5.3 | [AG/BE] 检索编排级联:golden → 混合检索 → 纠正 few-shot(R5.3) | M | T3.1 |
| T5.4 | [AG/BE] 逐轮组装 trace,持久化并可与消息/编辑差异/eval 运行关联(R5.4)。最小版(现有组装路径:模板 key、prompt 哈希、KB 块)进两周窗口 (最小版已于 2026-07-07 落地);完整版跟随 T5.1 | M | —(最小版)/ T5.1(完整版) |
Phase 6 — 可配置 Tools(R6)
| ID | 任务 | 规模 | 依赖 |
|---|---|---|---|
| T6.1 | [BE] 注册表新增 MCP 工具来源类型 + MCP server 集成配置(ADR-030 隔离) | M | T0.3 |
| T6.2 | [BE/FE] 按 Specialist 的工具绑定配置 UI(目录默认 + 实例覆盖) | M | T6.1, T2.2 |
| T6.3 | [AG] 经组装器的聊天主链路工具暴露(skills ∩ 绑定)+ 经策略门禁执行 | L | T5.1, T6.2 |
| T6.4 | [BE/FE] 写类动作在 Expert 队列的审批项 + 审计接线 | M | T6.3 |
| T6.5 | [BE] KB 摄取连接器(R3.5):外部源定时同步进 K1/K2 | M | — |
依赖主干
T0.3 ──► T1.x(Soul)──┐
T0.3 ──► T2.x(Skills)─┼──► T5.1/T5.2(组装器)──► T4.4(eval 门禁)──► T4.6(看板)
T3.1(golden)─┴──► T5.3(检索级联)
T0.1(编辑信号)──► T0.2 ──► T4.1/T4.2/T4.3
T5.4 trace:最小版先行 ──► 完整版随 T5.1
T2.2 + T5.1 ──► T6.x(工具:绑定 → 主链路 → 审批)
两周窗口切法(与团队公告对齐):T0.1–T0.4 + T5.4(最小 trace)+ 启动 T1.1/T1.2 与 T2.1/T2.2。其余全部排后。
容量说明: 本窗口与支柱①(流水线可靠性)并行推进,两者用的是同一批后端工程师。T0.x 刻意按 S/M 规模 切,使两个支柱能并排放下;若资源冲突,支柱①优先,顺延的是 Phase 1/2 的启动——T0.x 度量任务不顺延。
8. 上线与迁移
本 PRD 风险最高的时刻,是把**正在付费的活客户(Kaito/Amy)**从旧 prompt 路径切到新组装器。规则:
- 先影子模式。 新组装器与旧路径并行:两路都产草稿、都记录、都做 eval 比对;客户看到的始终是旧路径的草稿,直到正式切换。影子差异回灌 golden set。
- 按 Specialist 逐个切换的 feature flag(复用现有 feature-flags 模块),一键回退旧路径。没有全局开关。
- 切换顺序: dogfood 先行(Eleanora / Acme)→ 非关键 Specialist → Kaito(Amy)最后,且必须满足 N 天影子对齐(eval 差值 ≥ 0、无新增红线违规)。
- 内容迁移可演练: SOUL.md / SKILL.md / systemPrompt 导入脚本(T1.2、T2.2)支持 dry-run + diff;导入的配置必须先过 eval 门禁才能首次发布。
- 旧路径退役: 仓库文件与裸
systemPrompt路径,仅在全部在管 Specialist 完成切换、且逃生口连续 4 周未使用后移除(R1.2 弃用判据)。
9. 开放问题
| # | 问题 | Owner | 是否阻塞 |
|---|---|---|---|
| Q1 | OQ-205 正式关闭:确认"运行时只读 + 人审批晋升"为 ADR 化默认 (已解决——ADR-037,2026-07-07) | 产品 / E | |
| Q2 | Soul/Skill 存储切分:哪些进 PG、哪些进 R2(体积、版本化、eval 沙箱访问) | 工程(T0.3) | 阻塞 —— 卡 T0.3 |
| Q3 | prompt_template_key 的封闭枚举保留,还是 skill 最终吸收角色模板?(短期保留枚举;Phase 2 后重审) | 工程/产品 | 非阻塞 |
| Q4 | 客户可见反馈(R4.7)的文案与位置——不能引导客户以"给 AI 打分"的方式削弱人设 | 设计 | 非阻塞 |
评审节奏:Phase 1 交付后重新定 scope;成功指标每周对照 §6 复盘。本文档与英文版 prd-specialist-value-output.md 保持同步。