cj66666/closer
1
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

交叉评测意见：成交链路和风险护栏覆盖清楚，建议补充一条端到端证据表 #2

New issue
Open
opened 2026-06-05 14:29:27 +08:00 by dwj0725 · 1 comment
dwj0725 commented 2026-06-05 14:29:27 +08:00
Copy link

交叉评测意见

1. 项目理解

我理解 Closer 面向跨境 B2B 中小卖家的询盘成交工作台，主线是从多渠道询盘进入、客户建档、询盘评分、产品匹配、报价/PI、风险审批、投递跟进到复盘运维。

它要解决的不是单点客服或单次报价，而是外贸销售组织里更本质的几个断点：哪些询盘值得优先跟、报价是否准确、风险动作是否需要审批、发出后是否有人跟进、系统本身是否真的接线可用。

2. W2 完成度判断

我的看法是，项目给出的 Skill 和业务动作对应关系比较清楚。

  • Skill / workflow：README 明确列出 8 个可评审 Skill，包括 score_inquiry、match_product、calc_quote、generate_pi、send_message、request_handoff、create_followup 和 readiness。
  • 可运行入口：文档中给出 python -m pip install -e .[dev]、FastAPI 启动命令、scripts/demo_flow.py 和 pytest 配置。
  • 核心闭环：从询盘优先级判断，到报价、风险审批、投递记录、跟进调度，形成了完整销售链路。
  • 验证材料：仓库包含 tests、migrations、frontend、backend、skills、demo_flow 等结构。由于我本地临时环境未安装 pytest，本轮没有复跑 pytest，只确认了入口和结构。

3. 项目亮点

  • 对 B2B 询盘成交的业务断点理解较深，尤其是把风险审批和投递/跟进纳入主链路。
  • 8 个 Skill 都有比较明确的业务动作和入口，不是为了堆数量而拆分。
  • readiness 能展示 LLM、RAG、投递、凭据、汇率、监控等接线状态，这对 W2 的“可运行”很重要。
  • 高风险动作通过审批护栏处理，避免把 AI 做成直接替人承诺底价或敏感条款的黑盒。

4. 当前不清楚或建议补充的地方

  1. 建议补充一条“成交链路证据表”。

    可以用同一条询盘作为样例，展示 8 个 Skill 依次产生的状态变化：

    • 询盘进入后如何评分？
    • 匹配了哪些产品和知识证据？
    • 报价如何由 MOQ、阶梯价、汇率、底价和有效期约束？
    • 哪些动作被风险护栏拦住，哪些进入人工审批？
    • 投递失败和 follow-up 如何进入下一轮任务？

    这样比单纯列出 8 个 Skill 更能证明“成交闭环”已经跑通。

  2. 建议修正提交页演示链接。

    当前提交页中的演示链接看起来是 .git 地址，会影响其他人快速理解项目入口。即使 W2 核心不是 live demo，这也是一个不必要的信息噪声。

  3. 建议区分确定性能力和 LLM 依赖能力。

    比如评分、报价计算、风险审批、readiness 中哪些是规则/数据库确定性能力，哪些依赖 LLM 或外部服务。这样其他参赛者更容易判断最小可验证范围。

5. 综合看法

我的看法是，这个项目的价值不只是“AI 帮忙回复询盘”，而是把成交过程拆成多个可审计、可审批、可跟进的业务决策。

如果能补一条端到端证据表，并把最小验证路径放到更显眼位置，项目在 W2 “Skill / workflow 可运行验证”标准下会更有说服力。

# 交叉评测意见 ## 1. 项目理解 我理解 Closer 面向跨境 B2B 中小卖家的询盘成交工作台，主线是从多渠道询盘进入、客户建档、询盘评分、产品匹配、报价/PI、风险审批、投递跟进到复盘运维。 它要解决的不是单点客服或单次报价，而是外贸销售组织里更本质的几个断点：哪些询盘值得优先跟、报价是否准确、风险动作是否需要审批、发出后是否有人跟进、系统本身是否真的接线可用。 ## 2. W2 完成度判断 我的看法是，项目给出的 Skill 和业务动作对应关系比较清楚。 - Skill / workflow：README 明确列出 8 个可评审 Skill，包括 `score_inquiry`、`match_product`、`calc_quote`、`generate_pi`、`send_message`、`request_handoff`、`create_followup` 和 readiness。 - 可运行入口：文档中给出 `python -m pip install -e .[dev]`、FastAPI 启动命令、`scripts/demo_flow.py` 和 pytest 配置。 - 核心闭环：从询盘优先级判断，到报价、风险审批、投递记录、跟进调度，形成了完整销售链路。 - 验证材料：仓库包含 tests、migrations、frontend、backend、skills、demo_flow 等结构。由于我本地临时环境未安装 pytest，本轮没有复跑 pytest，只确认了入口和结构。 ## 3. 项目亮点 - 对 B2B 询盘成交的业务断点理解较深，尤其是把风险审批和投递/跟进纳入主链路。 - 8 个 Skill 都有比较明确的业务动作和入口，不是为了堆数量而拆分。 - readiness 能展示 LLM、RAG、投递、凭据、汇率、监控等接线状态，这对 W2 的“可运行”很重要。 - 高风险动作通过审批护栏处理，避免把 AI 做成直接替人承诺底价或敏感条款的黑盒。 ## 4. 当前不清楚或建议补充的地方 1. 建议补充一条“成交链路证据表”。 可以用同一条询盘作为样例，展示 8 个 Skill 依次产生的状态变化： - 询盘进入后如何评分？ - 匹配了哪些产品和知识证据？ - 报价如何由 MOQ、阶梯价、汇率、底价和有效期约束？ - 哪些动作被风险护栏拦住，哪些进入人工审批？ - 投递失败和 follow-up 如何进入下一轮任务？ 这样比单纯列出 8 个 Skill 更能证明“成交闭环”已经跑通。 2. 建议修正提交页演示链接。 当前提交页中的演示链接看起来是 `.git` 地址，会影响其他人快速理解项目入口。即使 W2 核心不是 live demo，这也是一个不必要的信息噪声。 3. 建议区分确定性能力和 LLM 依赖能力。 比如评分、报价计算、风险审批、readiness 中哪些是规则/数据库确定性能力，哪些依赖 LLM 或外部服务。这样其他参赛者更容易判断最小可验证范围。 ## 5. 综合看法 我的看法是，这个项目的价值不只是“AI 帮忙回复询盘”，而是把成交过程拆成多个可审计、可审批、可跟进的业务决策。 如果能补一条端到端证据表，并把最小验证路径放到更显眼位置，项目在 W2 “Skill / workflow 可运行验证”标准下会更有说服力。
dwj0725 changed title from 交叉评测意见：成交链路和风险护栏很完整，建议补充一条端到端证据表 to 交叉评测意见：成交链路和风险护栏覆盖清楚，建议补充一条端到端证据表 2026-06-05 14:38:47 +08:00
cj66666 commented 2026-06-15 00:38:56 +08:00
Owner
Copy link

感谢建议“补一条成交链路证据表”，这条我们已经按原建议落到文档里了。

已新增 docs/END_TO_END_EVIDENCE.md，用同一条演示询盘串起 8 个 Skill/Workflow：

  1. 多渠道询盘进入后创建 customer / inquiry / conversation / message。
  2. score_inquiry 输出 grade、score、signals，说明询盘为什么被判为 A/B/C。
  3. get_customer 聚合客户档案、历史询盘、会话、报价、跟进和 preferences。
  4. match_product 与 search_knowledge 输出产品匹配证据、confidence 和知识片段。
  5. calc_quote 展示 MOQ、阶梯价、物流、汇率缓存、floor price 和 hard_min_price。
  6. generate_pi 进入审批链路，硬底价触碰会直接阻断。
  7. send_message、create_followup、workers 负责投递记录、失败重试和后续跟进。
  8. readiness/alerts 展示 provider、渠道凭证、失败投递、待审批和汇率缓存风险。

你提到的演示链接噪声也已修正：现在评审入口统一指向在线 Demo https://cj66666.github.io/chengjiaoguan/，而不是 .git 仓库地址。文档中也明确区分了确定性后端能力与 LLM/provider 依赖能力，避免评审误以为所有能力都必须接真实模型才能验证。

感谢建议“补一条成交链路证据表”，这条我们已经按原建议落到文档里了。 已新增 `docs/END_TO_END_EVIDENCE.md`，用同一条演示询盘串起 8 个 Skill/Workflow： 1. 多渠道询盘进入后创建 customer / inquiry / conversation / message。 2. `score_inquiry` 输出 grade、score、signals，说明询盘为什么被判为 A/B/C。 3. `get_customer` 聚合客户档案、历史询盘、会话、报价、跟进和 preferences。 4. `match_product` 与 `search_knowledge` 输出产品匹配证据、confidence 和知识片段。 5. `calc_quote` 展示 MOQ、阶梯价、物流、汇率缓存、floor price 和 hard_min_price。 6. `generate_pi` 进入审批链路，硬底价触碰会直接阻断。 7. `send_message`、`create_followup`、workers 负责投递记录、失败重试和后续跟进。 8. `readiness/alerts` 展示 provider、渠道凭证、失败投递、待审批和汇率缓存风险。 你提到的演示链接噪声也已修正：现在评审入口统一指向在线 Demo `https://cj66666.github.io/chengjiaoguan/`，而不是 `.git` 仓库地址。文档中也明确区分了确定性后端能力与 LLM/provider 依赖能力，避免评审误以为所有能力都必须接真实模型才能验证。
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/eric
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cj66666/closer#2
No description provided.