667 lines
21 KiB
Markdown
667 lines
21 KiB
Markdown
# Full Business Structuring And Conversation Baseline Design
|
||
|
||
## 1. Purpose
|
||
|
||
这份 spec 的目标不是继续给 PMFlow 的问答/执行链路补局部规则，而是把当前 runtime 升级成一套**全量业务结构化**基线：
|
||
|
||
- 让系统真正理解“当前在围绕哪个业务对象、以什么目标、需要什么回答形状”
|
||
- 让 `status / recommendation / draft / execute` 四挡真正独立、可停住、可纠错、可升级
|
||
- 让 recommendation 不再只是“给人看的文本”，而是能继续承接澄清、改写、写入与确认的结构化业务对象
|
||
- 让 casual chat / greeting 也进入统一结构，而不是继续靠散落的口水词表和轻量快捷回复分支
|
||
|
||
这份设计建立在已有 `InteractionBoundaryPacket / AnswerControlDecision / unified project AI handoff` 方向之上，但范围更大：它不只处理“不要越权”，还要处理“系统到底有没有全量理解这个业务系统”。
|
||
|
||
## 2. Problem Statement
|
||
|
||
当前 PMFlow 已经把协议层和部分上下文层结构化了一部分，但仍没有把**业务系统本体**全量结构化。实际表现就是：
|
||
|
||
1. 系统能识别“这一轮是 recommendation、不要 draft”，但识别不到“围绕当前项目推荐外部信号源候选”这类更深层业务意图。
|
||
2. recommendation 只产出了文本，没有产出后续可引用、可确认、可写入的业务候选集合。
|
||
3. 澄清和纠错主要还停留在 `pending_clarification / session_state` 层，没有真正更新业务结构真源。
|
||
4. 非 `plan mode` 的写入动作还在默认往 `draft_pending_confirm` 走，而不是走 operational write 主链。
|
||
5. casual chat / greeting 仍混在本地 lexical/shortcut 分支里，没有纳入统一语义规划层。
|
||
|
||
这导致系统在真实业务链里会出现连续错位，而不是单点失误。
|
||
|
||
## 3. Canonical Failure Chain To Fix
|
||
|
||
当前最典型、必须打穿的主反例链如下。
|
||
|
||
### 3.1 Real user intent
|
||
|
||
用户先拿到一轮信号源 recommendation，然后继续说：
|
||
|
||
- `感觉不错，写入系统内的信号源吧。`
|
||
- `我让你把推荐的信号源写入系统`
|
||
- `已经不用查询内部对象了，现在要你把这些外部信号源加入项目里`
|
||
- `确认入库`
|
||
|
||
### 3.2 Actual broken behavior
|
||
|
||
当前 live 链路的错误表现是：
|
||
|
||
1. recommendation 本身只变成了正文，没有形成可回溯候选集合
|
||
2. 后续“写入系统”被重新当成普通问答解析
|
||
3. 又走了一轮“内部对象不清 / target_resolution”式澄清
|
||
4. 纠正后又掉进 `signal_source.onboard -> draft_pending_confirm`
|
||
5. `确认入库` 没有命中上一轮 pending write object，而是又被当成新问句解析，最后答到完全不相干的内部配置/引擎信息上
|
||
|
||
### 3.3 Root cause
|
||
|
||
这不是 recommendation presenter 单点问题，而是当前系统同时缺了下面 4 层：
|
||
|
||
- 围绕业务对象的完整 `BusinessSemanticFrame`
|
||
- recommendation 输出后的 `RecommendationCandidateSet`
|
||
- clarification/correction 到结构化真源的 delta 写回
|
||
- 非 `plan mode` 下的 direct operational write 主链
|
||
|
||
## 4. Non-Negotiable Baseline
|
||
|
||
下面这些是这次设计的**硬基线**，实现时不得违反。
|
||
|
||
### 4.1 No hard semantics for business decisions
|
||
|
||
全套业务语义拍板里：
|
||
|
||
- 不准用中文关键词仓
|
||
- 不准用英文关键词仓
|
||
- 不准用中文正则/英文正则去拍板业务语义
|
||
- 不准在运行时代码里恢复 `looks_like_*`、`*_KEYWORDS`、`*_HINTS`、`*_regex` 这类业务裁决器
|
||
|
||
这条硬约束覆盖：
|
||
|
||
- `status / recommendation / draft / execute` 分挡
|
||
- internal vs external vs hybrid 路由
|
||
- recommendation vs inventory vs impact-jump 判断
|
||
- 新项目 / 新业务 / 新线程识别
|
||
- clarification / correction 更新
|
||
- casual chat / greeting 识别
|
||
- signal source recommendation / prepare_write / confirm_write / execute_write 跳转
|
||
|
||
允许保留的 deterministic 逻辑，只能是**非语义型**：
|
||
|
||
- `reply/thread/work_item_id/source_message_id` 等强锚点
|
||
- schema 校验
|
||
- 幂等键和去重
|
||
- 文本 hygiene（去空白、去 code fence、句尾清理）
|
||
- 结构化 payload 的必填字段校验
|
||
|
||
### 4.2 Explicit anchors beat memory
|
||
|
||
显式 `reply/thread`、卡片动作、`work_item_id`、上一轮 recommendation candidate set 绑定，优先级必须高于：
|
||
|
||
- 旧 session
|
||
- 旧 last_subject
|
||
- 旧 pending clarification
|
||
- 旧 topic / work item 同 scope 模糊回捞
|
||
|
||
### 4.3 Non-planmode write does not default to draft
|
||
|
||
只要当前不在 `plan mode`：
|
||
|
||
- `signal source` 写入动作默认不出 requirement draft
|
||
- recommendation 后的“写入系统 / 加入项目 / 确认入库”默认走 operational write 主链
|
||
- 只有两种情况允许出 draft：
|
||
- 用户显式说“先出草稿”
|
||
- 当前线程已经明确处于 `plan mode`
|
||
|
||
### 4.4 Every turn must remain correctable
|
||
|
||
每一挡都必须支持：
|
||
|
||
- `澄清`
|
||
- `纠错`
|
||
- `再次思考 / 自检`
|
||
- `显式升级 / 降级`
|
||
|
||
系统目标不是“一次就猜对”，而是“不越权 + 可纠错 + 可停住”。
|
||
|
||
## 5. Existing Structured Layers vs Missing Layers
|
||
|
||
当前仓库已经做好的结构层有：
|
||
|
||
- `InteractionBoundaryPacket / AnswerControlDecision`
|
||
- `ProjectOperatingContext / ProjectFitBrief / ExecutionRecipe`
|
||
- `analysis_packet` / `ExternalQueryPlan` / `SignalSourceRecommendationPacket`
|
||
|
||
但真正缺的，是下面这些业务本体层。
|
||
|
||
| Layer | Current state | Missing truth | User-visible symptom |
|
||
| --- | --- | --- | --- |
|
||
| Interaction boundary | Partially structured | still not connected to deeper business frame | 能识别“不要 draft”，但不能稳定识别“我要推荐外部信号源候选” |
|
||
| Query semantics | coarse `query_type/subject_focus` | no business goal frame | recommendation 被吞成 internal list / inventory |
|
||
| Recommendation output | mostly presentational | no durable candidate set | 后续“把推荐的写入系统”无法引用上一轮对象 |
|
||
| Clarification/correction | session-oriented | no structural delta | 纠正后仍容易带旧结论继续跑 |
|
||
| Operation contract | draft/write still mixed | no direct write phases outside plan mode | 非 `plan mode` 还在默认 `draft_pending_confirm` |
|
||
| Casual chat | local shortcuts | no structured ambient-chat posture | 打招呼和业务链互相污染 |
|
||
|
||
## 6. Target Runtime Model
|
||
|
||
这次建议把 runtime 收成 6 层，并且每层只做一件事。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["User Message"] --> B["InteractionBoundaryPacket"]
|
||
B --> C["BusinessSemanticFrame"]
|
||
C --> D["AnswerShapeContract"]
|
||
D --> E["RecommendationCandidateSet / OperationIntentContract"]
|
||
E --> F["SelfReviewResult"]
|
||
F --> G["Presenter / Executor"]
|
||
```
|
||
|
||
### 6.1 InteractionBoundaryPacket
|
||
|
||
职责：
|
||
|
||
- 识别这一轮最高允许做到哪一挡
|
||
- 哪几挡被禁止
|
||
- 是否允许写
|
||
- 是否需要先澄清
|
||
|
||
这层继续存在，但不再承担“理解业务对象是什么”的职责。
|
||
|
||
### 6.2 BusinessSemanticFrame
|
||
|
||
这是这次新增的业务真源层，也是全量结构化的核心。
|
||
|
||
建议字段：
|
||
|
||
- `goal_kind`
|
||
- `status_lookup`
|
||
- `recommendation`
|
||
- `impact_judgment`
|
||
- `bounded_explanation`
|
||
- `prepare_write`
|
||
- `confirm_write`
|
||
- `execute_write`
|
||
- `drafting`
|
||
- `clarify`
|
||
- `casual_chat`
|
||
- `mixed`
|
||
- `target_scope`
|
||
- `current_project`
|
||
- `explicit_project`
|
||
- `thread_context`
|
||
- `global`
|
||
- `resource_role`
|
||
- `signal_source`
|
||
- `external_input`
|
||
- `project_object`
|
||
- `task`
|
||
- `signal`
|
||
- `config`
|
||
- `people`
|
||
- `none`
|
||
- `source_kind`
|
||
- `internal`
|
||
- `external`
|
||
- `hybrid`
|
||
- `none`
|
||
- `expected_answer_shape`
|
||
- `inventory`
|
||
- `ranked_candidates`
|
||
- `impact_chain`
|
||
- `bounded_explanation`
|
||
- `clarify_prompt`
|
||
- `write_confirmation`
|
||
- `write_result`
|
||
- `social_reply`
|
||
- `conversation_posture`
|
||
- `business_operating`
|
||
- `ambient_chat`
|
||
- `mixed`
|
||
- bindings
|
||
- `project_binding`
|
||
- `subject_binding`
|
||
- `object_binding`
|
||
- `candidate_set_binding`
|
||
|
||
这层的目标不是打一个粗标签，而是让 planner 真的理解：
|
||
|
||
- 围绕哪个项目
|
||
- 在问什么业务目标
|
||
- 对象在业务里扮演什么角色
|
||
- 用户期待的回答形状是什么
|
||
|
||
### 6.3 AnswerShapeContract
|
||
|
||
这一层单独存在，避免 route/gateway 和 presenter 各自脑补回答形状。
|
||
|
||
建议枚举：
|
||
|
||
- `inventory`
|
||
- `ranked_candidates`
|
||
- `impact_chain`
|
||
- `bounded_explanation`
|
||
- `clarify_prompt`
|
||
- `write_confirmation`
|
||
- `write_result`
|
||
- `social_reply`
|
||
|
||
关键规则：
|
||
|
||
- `status` 不能被答成 recommendation
|
||
- `recommendation` 不能被答成 inventory
|
||
- `prepare_write` 不能被答成 draft
|
||
- `confirm_write` 不能掉回普通 QA
|
||
|
||
### 6.4 RecommendationCandidateSet
|
||
|
||
这层是 recommendation 能继续工作的关键。
|
||
|
||
当前 recommendation 的最大缺陷是“只有文本，没有结构对象”。这次必须补成可持久化的候选集合。
|
||
|
||
建议结构：
|
||
|
||
- `candidate_set_id`
|
||
- `project_binding`
|
||
- `resource_role = signal_source`
|
||
- `source_kind`
|
||
- `evidence_mode`
|
||
- `candidates[]`
|
||
- `candidate_ref`
|
||
- `display_name`
|
||
- `business_value`
|
||
- `why_now`
|
||
- `materialization_payload`
|
||
- `source_origin`
|
||
- `candidate_rank`
|
||
|
||
用法：
|
||
|
||
- recommendation 回答给用户看
|
||
- 同时把候选集合持久化到当前 `reply/thread/work_item`
|
||
- 后续用户说：
|
||
- `把推荐的写入系统`
|
||
- `把第一个加进去`
|
||
- `确认入库`
|
||
不需要重新猜，而是通过锚点 + candidate_set 继续操作
|
||
|
||
### 6.5 ClarificationDelta / CorrectionDelta
|
||
|
||
澄清和纠错必须更新结构化真源，不只是更新聊天状态。
|
||
|
||
要更新的字段包括：
|
||
|
||
- `goal_kind`
|
||
- `resource_role`
|
||
- `source_kind`
|
||
- `expected_answer_shape`
|
||
- `project_binding`
|
||
- `candidate_set_binding`
|
||
- `action_ceiling`
|
||
|
||
例如：
|
||
|
||
- `不是现状，我要推荐`
|
||
- `不是内部对象，我要外部信号源`
|
||
- `不是这个项目，是 AI客服`
|
||
- `别起草，现在直接写入`
|
||
|
||
这些都必须变成对 frame 的结构化 delta，而不是只在 session 里记一句“用户已澄清”。
|
||
|
||
### 6.6 OperationIntentContract
|
||
|
||
这层把 recommendation / draft / direct write 真正拆开。
|
||
|
||
建议拆成：
|
||
|
||
- `recommendation`
|
||
- `prepare_write`
|
||
- `confirm_write`
|
||
- `execute_write`
|
||
- `drafting`
|
||
|
||
规则：
|
||
|
||
- `recommendation` 只出候选和理由
|
||
- `prepare_write` 表示用户已经决定往写链走，但系统还要回显对象和影响
|
||
- `confirm_write` 明确回显即将写入哪些对象、写到哪个项目
|
||
- `execute_write` 才是真正方法调用
|
||
- `drafting` 只在 `plan mode` 或显式“先出草稿”时进入
|
||
|
||
## 7. Clarification And Correction Must Update Structure
|
||
|
||
这是这次设计里最容易被实现层偷懒的点，所以单独拉出来。
|
||
|
||
### 7.1 What is not enough
|
||
|
||
下面这些都不够：
|
||
|
||
- 只更新 `pending_clarification`
|
||
- 只更新 `last_subject`
|
||
- 只把“不是这个项目”记进 session history
|
||
- 文本上说“我知道了”，但 route / frame / answer shape 没变
|
||
|
||
### 7.2 Required behavior
|
||
|
||
当用户澄清或纠错后：
|
||
|
||
1. 生成 `ClarificationDelta / CorrectionDelta`
|
||
2. 重算 `BusinessSemanticFrame`
|
||
3. 再重算 `AnswerShapeContract`
|
||
4. 必要时重建 `RecommendationCandidateSet` 或 `OperationIntentContract`
|
||
5. 最后再决定 route / presenter / executor
|
||
|
||
### 7.3 User-visible contract
|
||
|
||
纠错之后，回答里要明确承认：
|
||
|
||
- `现在按你刚才纠正的口径重算`
|
||
|
||
而不是继续拿旧 frame 扩写。
|
||
|
||
## 8. Non-Planmode Direct Signal-Source Write
|
||
|
||
这是这次设计的另一个硬基线。
|
||
|
||
### 8.1 Why current behavior is wrong
|
||
|
||
当前非 `plan mode` 下，用户说：
|
||
|
||
- `把推荐的写入系统`
|
||
- `把这些外部信号源加入项目里`
|
||
- `确认入库`
|
||
|
||
系统仍然容易走：
|
||
|
||
- `signal_source.onboard -> draft_pending_confirm`
|
||
|
||
这违背了当前产品预期：用户并不是在收需求，而是在做运营式写入动作。
|
||
|
||
### 8.2 Required path
|
||
|
||
非 `plan mode` 的 signal-source 写入必须走：
|
||
|
||
1. `recommendation`
|
||
2. `prepare_write`
|
||
3. `confirm_write`
|
||
4. `execute_write`
|
||
|
||
只有在下面两种情况，才允许走 `draft_pending_confirm`：
|
||
|
||
- 用户显式说：
|
||
- `先出草稿`
|
||
- `帮我整理成一版方案`
|
||
- `进 plan mode`
|
||
- 当前线程已经明确处于 `plan mode`
|
||
|
||
### 8.3 prepare_write contract
|
||
|
||
`prepare_write` 必须：
|
||
|
||
- 绑定项目
|
||
- 绑定候选集合
|
||
- 回显将写入哪些对象
|
||
- 明确这是“准备写入”，不是普通问答，也不是 requirement draft
|
||
|
||
### 8.4 confirm_write contract
|
||
|
||
`confirm_write` 必须：
|
||
|
||
- 指向明确候选对象
|
||
- 指向明确项目
|
||
- 告知将调用的操作类型
|
||
- 告知新增/复用/更新语义
|
||
|
||
### 8.5 execute_write contract
|
||
|
||
只有显式确认后才能 `execute_write`。
|
||
|
||
一旦执行：
|
||
|
||
- 必须有幂等键
|
||
- 必须有写入结果回显
|
||
- 必须能和之前的 candidate set / confirm object 对上
|
||
|
||
## 9. Casual Chat / Greeting Must Join The Same Structure
|
||
|
||
用户已经明确要求：打招呼、口水聊天也要接入。
|
||
|
||
但这不意味着 PMFlow 变成泛化聊天产品。
|
||
|
||
### 9.1 Required posture
|
||
|
||
建议在 `BusinessSemanticFrame` 里引入：
|
||
|
||
- `goal_kind = casual_chat`
|
||
- `conversation_posture = ambient_chat`
|
||
- `expected_answer_shape = social_reply`
|
||
|
||
### 9.2 Benefits
|
||
|
||
这样做的好处：
|
||
|
||
- casual chat 不再依赖本地词面快捷回复
|
||
- 不会继续污染业务链
|
||
- 一旦用户切回业务：
|
||
- `还是回到自动开票系统`
|
||
- `刚才那组候选继续`
|
||
能重新绑定到业务 frame
|
||
|
||
## 10. Required Code Changes
|
||
|
||
这次不是一两个文件补丁，而是一次结构升级。
|
||
|
||
### 10.1 Semantic truth layer
|
||
|
||
需要改动：
|
||
|
||
- `backend/app/services/ai_pmo/semantic_context/decision_schema.py`
|
||
- 新增 `backend/app/services/ai_pmo/semantic_context/business_frame_schema.py`
|
||
- `backend/app/services/ai_pmo/semantic_context/packet_schema.py`
|
||
- `backend/app/services/ai_pmo/semantic_context/semantic_decision_service.py`
|
||
- `backend/app/services/ai_pmo/workflow_semantic_planner/service.py`
|
||
|
||
目标：
|
||
|
||
- 让 planner 一次产出：
|
||
- `InteractionBoundaryPacket`
|
||
- `BusinessSemanticFrame`
|
||
- `AnswerShapeContract`
|
||
- `OperationIntentContract`
|
||
|
||
### 10.2 Mainline route / fast path cleanup
|
||
|
||
需要改动：
|
||
|
||
- `backend/app/services/adaptive_rag_service/mixin_query_route_gateway.py`
|
||
- `backend/app/services/adaptive_rag_service/mixin_core_intent.py`
|
||
- `backend/app/services/adaptive_rag_service/mixin_fast_answer_project_main.py`
|
||
- `backend/app/services/ai_pmo/ai_pmo_typed_executor_execute/mixin_execute_query_project.py`
|
||
|
||
目标：
|
||
|
||
- 不再让 coarse `query_type=list/status/explain` 直接吞业务问题
|
||
- 清掉 lexical/regex 语义快捷分支
|
||
- 让 route/gateway 只消费结构化业务 frame
|
||
|
||
### 10.3 Clarification / correction
|
||
|
||
需要改动：
|
||
|
||
- `backend/app/services/adaptive_rag_service/mixin_session_state.py`
|
||
- `backend/app/services/adaptive_rag_service/mixin_followup_anchor.py`
|
||
|
||
目标：
|
||
|
||
- clarification/correction 更新结构化 frame
|
||
- 新项目 / 新业务 / 新层级切换时重建 frame
|
||
- follow-up 不再只靠 session state
|
||
|
||
### 10.4 Recommendation and signal-source write
|
||
|
||
需要改动：
|
||
|
||
- `backend/app/services/external_query_service/schemas.py`
|
||
- `backend/app/services/external_query_service/planner.py`
|
||
- `backend/app/services/external_query_service/presenter.py`
|
||
- `backend/app/services/ai_pmo/ai_pmo_typed_executor_execute/mixin_execute_signal_source.py`
|
||
|
||
目标：
|
||
|
||
- recommendation 产出 `RecommendationCandidateSet`
|
||
- non-planmode 走 `prepare_write / confirm_write / execute_write`
|
||
- 只有 `plan mode` 或显式草稿请求才走 `draft_pending_confirm`
|
||
|
||
## 11. Broad Scenario Matrix
|
||
|
||
这次不能再只做 12 条黄金样例。基线升级为**58 条广覆盖业务语义问题**，覆盖业务、澄清、闲聊、写入、确认。
|
||
|
||
### 11.1 Greeting / ambient chat（6）
|
||
|
||
1. `早上好，你在线吗？`
|
||
2. `今天先不推进需求，聊两句。`
|
||
3. `你先别那么严肃。`
|
||
4. `我有点烦，先陪我理一理。`
|
||
5. `先不说系统，随便聊两句。`
|
||
6. `你现在忙吗？`
|
||
|
||
### 11.2 Status / current-state（6）
|
||
|
||
7. `自动开票系统现在主要靠哪些数据在跑？`
|
||
8. `AI客服这个项目当前已经在用哪些数据？`
|
||
9. `门店库存异常日报助手现在是谁接收异常？`
|
||
10. `确认立项现在 assignee 推荐做到哪了？`
|
||
11. `直播复盘辅助工具当前主要依赖什么输入？`
|
||
12. `测试产能警告现在有没有成型信号源？`
|
||
|
||
### 11.3 Recommendation / external signal-source candidates（8）
|
||
|
||
13. `自动开票系统如果想更早发现票开不出去，最该先盯哪几类外部信号？`
|
||
14. `AI客服这个项目除了现在这些数据，还值得补哪些外部线索？`
|
||
15. `门店库存异常日报助手如果要更早发现问题，先看哪几类外部信号最值？`
|
||
16. `直播复盘工具除了录屏和评论，还该盯什么外部线索？`
|
||
17. `测试产能警告除了内部数据，还该看什么外部信号？`
|
||
18. `采购经理库存项目外面还有哪些信号值得加进来？`
|
||
19. `如果只给建议，不出草稿，你会推荐哪些外部信号源？`
|
||
20. `你按业务优先级排一下要补的外部信号。`
|
||
|
||
### 11.4 Impact judgment（6）
|
||
|
||
21. `税控平台状态波动，会不会直接影响自动开票系统？`
|
||
22. `WMS接口变更，会先打到哪一步？`
|
||
23. `评论流异常，会不会先影响直播复盘？`
|
||
24. `政策更新会先影响开票校验还是发送环节？`
|
||
25. `供应商接口延迟，会不会先影响采购经理库存日报？`
|
||
26. `门店上报延迟会先影响哪条业务链？`
|
||
|
||
### 11.5 Clarification（6）
|
||
|
||
27. `不是现状，我要推荐。`
|
||
28. `不是内部对象，我要外部线索。`
|
||
29. `我说的不是这个项目。`
|
||
30. `不是问配置，是问信号源。`
|
||
31. `你先别起草，我只要建议。`
|
||
32. `我要的是写入，不是继续分析。`
|
||
|
||
### 11.6 Correction / reframing（6）
|
||
|
||
33. `不是自动开票，是 AI客服。`
|
||
34. `不是第一个，写第二个。`
|
||
35. `刚才方向不对，换成现状回答。`
|
||
36. `刚才不要草稿，现在可以起草。`
|
||
37. `刚才是建议，现在直接写入。`
|
||
38. `不是这三个候选，按门店库存那组来。`
|
||
|
||
### 11.7 Recommendation -> non-plan write（6）
|
||
|
||
39. `把你刚推荐的这几个信号源写进项目。`
|
||
40. `把第一个加进去。`
|
||
41. `就按刚才那三类，加入系统。`
|
||
42. `不要出草稿，直接按刚推荐的候选准备写入。`
|
||
43. `先回显你准备写哪几个。`
|
||
44. `确认把这几个加进来。`
|
||
|
||
### 11.8 Plan mode / explicit drafting（4）
|
||
|
||
45. `先给我起一版信号源接入草稿。`
|
||
46. `这次进 plan mode，把外部信号接入方案整理成草稿。`
|
||
47. `先别执行，只出草稿。`
|
||
48. `把这几个候选扩成正式需求草稿。`
|
||
|
||
### 11.9 Confirm / execute（4）
|
||
|
||
49. `确认入库。`
|
||
50. `确认写入第一个。`
|
||
51. `确认执行这次接入。`
|
||
52. `就按你回显的对象执行。`
|
||
|
||
### 11.10 Sparse / mixed / edge（6）
|
||
|
||
53. `这个项目最容易卡在哪一步？`
|
||
54. `你按业务同事口吻说，不要系统话。`
|
||
55. `先别推进执行，我就想知道今天最可能先从哪暴露问题。`
|
||
56. `如果今天要先做最小版，你觉得先盯哪个外部信号最值？`
|
||
57. `我现在只想轻松聊两句，等会儿再回业务。`
|
||
58. `从聊天切回自动开票系统，刚才那组候选继续。`
|
||
|
||
## 12. Scoring Rubric
|
||
|
||
这次每个 case 不是看平均分，而是看**每一项都 > 9**。
|
||
|
||
### 12.1 Dimensions
|
||
|
||
每条 case 至少按下面 6 个维度评分：
|
||
|
||
1. `Semantic frame correctness`
|
||
- 目标、对象、来源、回答形状识别是否正确
|
||
2. `Boundary correctness`
|
||
- 没有越权，没偷偷升挡
|
||
3. `Business binding`
|
||
- 项目、对象、候选集合绑定是否正确
|
||
4. `Clarification / correction fidelity`
|
||
- 用户纠正后是否真的重算结构
|
||
5. `Answer naturalness`
|
||
- 回复是否业务化、自然、像同事，而不是架构师/系统提示词
|
||
6. `Safety / no irrelevant drift`
|
||
- 不答非所问，不掉进无关 internal fast path，不泄漏内部术语
|
||
|
||
### 12.2 Pass rule
|
||
|
||
任一 case 只要有任一维度 `< 9.0`，直接判失败。
|
||
|
||
不允许：
|
||
|
||
- 用综合均分掩盖单项缺口
|
||
- 用“主链绿了”掩盖 recommendation / correction / greeting 失真
|
||
|
||
## 13. Expected User-Visible Behaviors
|
||
|
||
如果这版设计落地正确，用户应该能看到这些变化：
|
||
|
||
1. `推荐外部信号源` 不再掉成 `当前项目列表如下`
|
||
2. recommendation 后续可以直接说：
|
||
- `把第一个加进去`
|
||
- `确认入库`
|
||
系统不会重新猜，也不会答偏
|
||
3. 非 `plan mode` 下，默认不会再先出 draft
|
||
4. 用户一句：
|
||
- `不是这个项目`
|
||
- `不是现状，我要推荐`
|
||
- `别起草，直接写`
|
||
系统会真改结构，不只是嘴上承认
|
||
5. casual chat / greeting 可以自然接入，也能自然切回业务
|
||
|
||
## 14. Rollout Order
|
||
|
||
推荐分四步落地：
|
||
|
||
1. 先补 `BusinessSemanticFrame / AnswerShapeContract / OperationIntentContract`
|
||
2. 再补 `RecommendationCandidateSet`
|
||
3. 再把 clarification/correction 改成 structural delta
|
||
4. 最后清掉 fast path / lightweight chat / lexical semantic shortcuts
|
||
|
||
每一步都要伴随矩阵级测试扩展，不能只靠单条回归。
|
||
|
||
## 15. Out Of Scope For This Spec
|
||
|
||
这份 spec 先不包含：
|
||
|
||
- requirement-plan 本体重写
|
||
- signal-source domain orchestration 业务逻辑重构
|
||
- generic chatbot 产品化
|
||
- 前端视觉大改版
|
||
|
||
这份 spec 的边界是：**先把 PMFlow 的问答、推荐、澄清、写入、确认和闲聊纳入一套完整、无硬语义、可纠错的业务结构真源。**
|