交叉评测意见：询盘到报价/跟进闭环清晰，建议补充 Skill 决策 Trace #2

New issue

Open

opened 2026-06-05 14:29:22 +08:00 by dwj0725 · 0 comments

dwj0725 commented

2026-06-05 14:29:22 +08:00

交叉评测意见

1. 项目理解

我理解该项目面向跨境 IT 服务 / B2B 外贸询盘场景，目标是把“收到询盘 -> 解析需求 -> 匹配产品 -> 生成报价 -> 安排跟进”这一条高频外贸销售链路做成 AI 询盘管家。

它不是泛客服，也不只是报价生成器，而是试图解决中小外贸团队在询盘处理里常见的断点：多语种理解、产品匹配、报价口径、跟进节奏和销售动作持续性。

2. W2 完成度判断

我的看法是，这个项目已经提供了不少能对照 W2 要求检查的材料。

Skill / workflow：README 和 DEMO 中明确列出 Inquiry Parser、Product Matcher、Quote Generator、Follow-up Scheduler、Market Analyzer 五个核心 Skill。
可运行入口：README 给出 pip install -r requirements.txt、pytest tests/、uvicorn src.api.main:app --reload；DEMO 给出 python butler.py、python butler.py --demo 和单条询盘处理命令。
核心闭环：DEMO 覆盖多语种询盘解析、产品匹配、报价生成、批量询盘处理、跟进调度、CLI 和 REST API。
验证材料：仓库包含 tests/test_e2e.py 等测试，DEMO 中标注 33/33 tests passed。由于我本地临时环境未安装 pytest，本轮没有复跑完整 pytest，只确认了测试入口和文件结构。

3. 项目亮点

业务边界清楚：围绕询盘处理这一条真实外贸链路，而不是泛化成“外贸全能助手”。
Skill 拆分和业务动作对应度高：解析、匹配、报价、跟进、市场分析各自对应明确任务。
DEMO 不只展示最终答案，还覆盖 CLI、REST API、多语种样例和跟进场景，其他参赛者也能较快看到 W2 可运行路径。
“询盘 -> 报价 -> 跟进”的闭环，比单点询盘解析或单次报价生成更有业务价值。

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

建议补一个“同一询盘的 Skill 决策 Trace 表”。

现在 DEMO 已经展示结果，但如果能把同一条询盘在每个 Skill 中的中间产物列出来，会更能证明核心业务逻辑跑通。例如：
- Inquiry Parser 识别了哪些字段和风险？
- Product Matcher 如何选择候选产品？
- Quote Generator 如何使用 MOQ、阶梯价、交期或利润约束？
- Follow-up Scheduler 为什么给出这个跟进节奏？
- Market Analyzer 是否影响报价或优先级？
建议明确 LLM / DeepSeek 依赖边界。

如果没有 API Key，哪些功能可以用规则或样例 fallback 验证，哪些功能会降级或失败，建议在快速验证路径中说明。
README 中 W1/W2/W3 的状态可以再收紧。

当前 README 写到 W2 Skills、W3 Agents，但仓库里已经有 src/agent 和 butler.py 编排入口。建议明确“W2 已交付内容”和“后续阶段内容”，避免读者误解当前完成范围。

5. 综合看法

我的看法是，这个项目已经能比较清楚地呈现 W2 所需的 Skill / workflow 验证材料。它有价值的地方不是“能生成报价”，而是把询盘处理拆成了可以复核的业务动作，并形成从输入到跟进的闭环。

如果后续能补充一份可复核的 Skill Trace，把每个 Skill 如何改变下一步决策讲清楚，会更方便其他参赛者和评测流程理解核心业务链路。

# 交叉评测意见 ## 1. 项目理解我理解该项目面向跨境 IT 服务 / B2B 外贸询盘场景，目标是把“收到询盘 -> 解析需求 -> 匹配产品 -> 生成报价 -> 安排跟进”这一条高频外贸销售链路做成 AI 询盘管家。它不是泛客服，也不只是报价生成器，而是试图解决中小外贸团队在询盘处理里常见的断点：多语种理解、产品匹配、报价口径、跟进节奏和销售动作持续性。 ## 2. W2 完成度判断我的看法是，这个项目已经提供了不少能对照 W2 要求检查的材料。 - Skill / workflow：README 和 DEMO 中明确列出 Inquiry Parser、Product Matcher、Quote Generator、Follow-up Scheduler、Market Analyzer 五个核心 Skill。 - 可运行入口：README 给出 `pip install -r requirements.txt`、`pytest tests/`、`uvicorn src.api.main:app --reload`；DEMO 给出 `python butler.py`、`python butler.py --demo` 和单条询盘处理命令。 - 核心闭环：DEMO 覆盖多语种询盘解析、产品匹配、报价生成、批量询盘处理、跟进调度、CLI 和 REST API。 - 验证材料：仓库包含 `tests/test_e2e.py` 等测试，DEMO 中标注 33/33 tests passed。由于我本地临时环境未安装 pytest，本轮没有复跑完整 pytest，只确认了测试入口和文件结构。 ## 3. 项目亮点 - 业务边界清楚：围绕询盘处理这一条真实外贸链路，而不是泛化成“外贸全能助手”。 - Skill 拆分和业务动作对应度高：解析、匹配、报价、跟进、市场分析各自对应明确任务。 - DEMO 不只展示最终答案，还覆盖 CLI、REST API、多语种样例和跟进场景，其他参赛者也能较快看到 W2 可运行路径。 - “询盘 -> 报价 -> 跟进”的闭环，比单点询盘解析或单次报价生成更有业务价值。 ## 4. 当前不清楚或建议补充的地方 1. 建议补一个“同一询盘的 Skill 决策 Trace 表”。现在 DEMO 已经展示结果，但如果能把同一条询盘在每个 Skill 中的中间产物列出来，会更能证明核心业务逻辑跑通。例如： - Inquiry Parser 识别了哪些字段和风险？ - Product Matcher 如何选择候选产品？ - Quote Generator 如何使用 MOQ、阶梯价、交期或利润约束？ - Follow-up Scheduler 为什么给出这个跟进节奏？ - Market Analyzer 是否影响报价或优先级？ 2. 建议明确 LLM / DeepSeek 依赖边界。如果没有 API Key，哪些功能可以用规则或样例 fallback 验证，哪些功能会降级或失败，建议在快速验证路径中说明。 3. README 中 W1/W2/W3 的状态可以再收紧。当前 README 写到 W2 Skills、W3 Agents，但仓库里已经有 `src/agent` 和 `butler.py` 编排入口。建议明确“W2 已交付内容”和“后续阶段内容”，避免读者误解当前完成范围。 ## 5. 综合看法我的看法是，这个项目已经能比较清楚地呈现 W2 所需的 Skill / workflow 验证材料。它有价值的地方不是“能生成报价”，而是把询盘处理拆成了可以复核的业务动作，并形成从输入到跟进的闭环。如果后续能补充一份可复核的 Skill Trace，把每个 Skill 如何改变下一步决策讲清楚，会更方便其他参赛者和评测流程理解核心业务链路。

zoey referenced this issue

2026-06-05 21:13:24 +08:00

【交叉评测】代码实审：语义搜索名不副实 + 测试覆盖盲区 + Spec/实现 Gap #5

No labels

No milestone

No project

No assignees

1 participant

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

Novain/cross-border-inquiry-butler#2

No description provided.

Rows
Columns