21 KiB

Raw Blame History

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 已经把协议层和部分上下文层结构化了一部分，但仍没有把业务系统本体全量结构化。实际表现就是：

系统能识别“这一轮是 recommendation、不要 draft”，但识别不到“围绕当前项目推荐外部信号源候选”这类更深层业务意图。
recommendation 只产出了文本，没有产出后续可引用、可确认、可写入的业务候选集合。
澄清和纠错主要还停留在 pending_clarification / session_state 层，没有真正更新业务结构真源。
非 plan mode 的写入动作还在默认往 draft_pending_confirm 走，而不是走 operational write 主链。
casual chat / greeting 仍混在本地 lexical/shortcut 分支里，没有纳入统一语义规划层。

这导致系统在真实业务链里会出现连续错位，而不是单点失误。

3. Canonical Failure Chain To Fix

当前最典型、必须打穿的主反例链如下。

3.1 Real user intent

用户先拿到一轮信号源 recommendation，然后继续说：

感觉不错，写入系统内的信号源吧。
我让你把推荐的信号源写入系统
已经不用查询内部对象了，现在要你把这些外部信号源加入项目里
确认入库

3.2 Actual broken behavior

当前 live 链路的错误表现是：

recommendation 本身只变成了正文，没有形成可回溯候选集合
后续“写入系统”被重新当成普通问答解析
又走了一轮“内部对象不清 / target_resolution”式澄清
纠正后又掉进 signal_source.onboard -> draft_pending_confirm
确认入库 没有命中上一轮 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 层，并且每层只做一件事。

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

当用户澄清或纠错后：

生成 ClarificationDelta / CorrectionDelta
重算 BusinessSemanticFrame
再重算 AnswerShapeContract
必要时重建 RecommendationCandidateSet 或 OperationIntentContract
最后再决定 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 写入必须走：

recommendation
prepare_write
confirm_write
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）

早上好，你在线吗？
今天先不推进需求，聊两句。
你先别那么严肃。
我有点烦，先陪我理一理。
先不说系统，随便聊两句。
你现在忙吗？

11.2 Status / current-state（6）

自动开票系统现在主要靠哪些数据在跑？
AI客服这个项目当前已经在用哪些数据？
门店库存异常日报助手现在是谁接收异常？
确认立项现在 assignee 推荐做到哪了？
直播复盘辅助工具当前主要依赖什么输入？
测试产能警告现在有没有成型信号源？

11.3 Recommendation / external signal-source candidates（8）

自动开票系统如果想更早发现票开不出去，最该先盯哪几类外部信号？
AI客服这个项目除了现在这些数据，还值得补哪些外部线索？
门店库存异常日报助手如果要更早发现问题，先看哪几类外部信号最值？
直播复盘工具除了录屏和评论，还该盯什么外部线索？
测试产能警告除了内部数据，还该看什么外部信号？
采购经理库存项目外面还有哪些信号值得加进来？
如果只给建议，不出草稿，你会推荐哪些外部信号源？
你按业务优先级排一下要补的外部信号。

11.4 Impact judgment（6）

税控平台状态波动，会不会直接影响自动开票系统？
WMS接口变更，会先打到哪一步？
评论流异常，会不会先影响直播复盘？
政策更新会先影响开票校验还是发送环节？
供应商接口延迟，会不会先影响采购经理库存日报？
门店上报延迟会先影响哪条业务链？

11.5 Clarification（6）

不是现状，我要推荐。
不是内部对象，我要外部线索。
我说的不是这个项目。
不是问配置，是问信号源。
你先别起草，我只要建议。
我要的是写入，不是继续分析。

11.6 Correction / reframing（6）

不是自动开票，是 AI客服。
不是第一个，写第二个。
刚才方向不对，换成现状回答。
刚才不要草稿，现在可以起草。
刚才是建议，现在直接写入。
不是这三个候选，按门店库存那组来。

11.7 Recommendation -> non-plan write（6）

把你刚推荐的这几个信号源写进项目。
把第一个加进去。
就按刚才那三类，加入系统。
不要出草稿，直接按刚推荐的候选准备写入。
先回显你准备写哪几个。
确认把这几个加进来。

11.8 Plan mode / explicit drafting（4）

先给我起一版信号源接入草稿。
这次进 plan mode，把外部信号接入方案整理成草稿。
先别执行，只出草稿。
把这几个候选扩成正式需求草稿。

11.9 Confirm / execute（4）

确认入库。
确认写入第一个。
确认执行这次接入。
就按你回显的对象执行。

11.10 Sparse / mixed / edge（6）

这个项目最容易卡在哪一步？
你按业务同事口吻说，不要系统话。
先别推进执行，我就想知道今天最可能先从哪暴露问题。
如果今天要先做最小版，你觉得先盯哪个外部信号最值？
我现在只想轻松聊两句，等会儿再回业务。
从聊天切回自动开票系统，刚才那组候选继续。

12. Scoring Rubric

这次每个 case 不是看平均分，而是看每一项都 > 9。

12.1 Dimensions

每条 case 至少按下面 6 个维度评分：

Semantic frame correctness
- 目标、对象、来源、回答形状识别是否正确
Boundary correctness
- 没有越权，没偷偷升挡
Business binding
- 项目、对象、候选集合绑定是否正确
Clarification / correction fidelity
- 用户纠正后是否真的重算结构
Answer naturalness
- 回复是否业务化、自然、像同事，而不是架构师/系统提示词
Safety / no irrelevant drift
- 不答非所问，不掉进无关 internal fast path，不泄漏内部术语

12.2 Pass rule

任一 case 只要有任一维度 < 9.0，直接判失败。

不允许：

用综合均分掩盖单项缺口
用“主链绿了”掩盖 recommendation / correction / greeting 失真

13. Expected User-Visible Behaviors

如果这版设计落地正确，用户应该能看到这些变化：

推荐外部信号源 不再掉成 当前项目列表如下
recommendation 后续可以直接说：
- 把第一个加进去
- 确认入库 系统不会重新猜，也不会答偏
非 plan mode 下，默认不会再先出 draft
用户一句：
- 不是这个项目
- 不是现状，我要推荐
- 别起草，直接写 系统会真改结构，不只是嘴上承认
casual chat / greeting 可以自然接入，也能自然切回业务

14. Rollout Order

推荐分四步落地：

先补 BusinessSemanticFrame / AnswerShapeContract / OperationIntentContract
再补 RecommendationCandidateSet
再把 clarification/correction 改成 structural delta
最后清掉 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 的问答、推荐、澄清、写入、确认和闲聊纳入一套完整、无硬语义、可纠错的业务结构真源。

21 KiB Raw Blame History Unescape Escape

Full Business Structuring And Conversation Baseline Design

1. Purpose

2. Problem Statement

3. Canonical Failure Chain To Fix

3.1 Real user intent

3.2 Actual broken behavior

3.3 Root cause

4. Non-Negotiable Baseline

4.1 No hard semantics for business decisions

4.2 Explicit anchors beat memory

4.3 Non-planmode write does not default to draft

4.4 Every turn must remain correctable

5. Existing Structured Layers vs Missing Layers

6. Target Runtime Model

6.1 InteractionBoundaryPacket

6.2 BusinessSemanticFrame

6.3 AnswerShapeContract

6.4 RecommendationCandidateSet

6.5 ClarificationDelta / CorrectionDelta

6.6 OperationIntentContract

7. Clarification And Correction Must Update Structure

7.1 What is not enough

7.2 Required behavior

7.3 User-visible contract

8. Non-Planmode Direct Signal-Source Write

8.1 Why current behavior is wrong

8.2 Required path

8.3 prepare_write contract

8.4 confirm_write contract

8.5 execute_write contract

9. Casual Chat / Greeting Must Join The Same Structure

9.1 Required posture

9.2 Benefits

10. Required Code Changes

10.1 Semantic truth layer

10.2 Mainline route / fast path cleanup

10.3 Clarification / correction

10.4 Recommendation and signal-source write

11. Broad Scenario Matrix

11.1 Greeting / ambient chat（6）

11.2 Status / current-state（6）

11.3 Recommendation / external signal-source candidates（8）

11.4 Impact judgment（6）

11.5 Clarification（6）

11.6 Correction / reframing（6）

11.7 Recommendation -> non-plan write（6）

11.8 Plan mode / explicit drafting（4）

11.9 Confirm / execute（4）

11.10 Sparse / mixed / edge（6）

12. Scoring Rubric

12.1 Dimensions

12.2 Pass rule

13. Expected User-Visible Behaviors

14. Rollout Order

15. Out Of Scope For This Spec

21 KiB

Raw Blame History