演示路线与高频问答¶

一、推荐 10 分钟演示路线¶

flowchart LR
    A["0:00-1:00<br/>先讲结果"] --> B["1:00-3:30<br/>Excel 证据与确认"]
    B --> C["3:30-4:30<br/>PostgreSQL / WISE 状态"]
    C --> D["4:30-7:30<br/>多轮需求"]
    D --> E["7:30-9:00<br/>方案与校验"]
    E --> F["9:00-10:00<br/>主动展示失败边界"]

这条路线刻意按“先结果、再证据、最后边界”展开。不要从代码目录讲起，也不要把十分钟平均分给每个模块。

0:00—1:00：先讲结果¶

我会说：

没有系统时，餐厅经理、厨师长等角色可能分别手工维护不同格式的 Excel，有些信息还在其他文件或口头交接里。熟悉业务的人靠经验能拼起来，新来的经理却要先找版本、问字段、补缺失。接下来我不先展示代码，而是展示系统怎样把这件事变成一条清楚的业务路径：保留资料来源，暴露不确定项，把确认后的信息形成事实，再生成一份能校验、需要人确认的方案。

这段只讲 30 秒，不要把问题夸大成“以前完全不可用”。随后直接展示一份结构复杂的真实或脱敏工作簿，让观众看到系统面对的对象，再进入处理结果。

1:00—3:30：Excel 预览与确认¶

展示：

1. 选择一份真实或脱敏工作簿。
2. 页面显示识别出的 Sheet、表块、记录和问题。
3. 打开一个字段问题，说明候选来自后端受控字段，不是模型随便生成。
4. 选择一个正式字段，再展示“仅保留原始证据”。
5. 应用选择并重新预览。

我会说：

这里最重要的不是 AI 猜对一次，而是系统保留了原坐标、候选、最终选择和重新解析结果。没有可靠含义的内容可以只留证，不强行进入正式表。

如果展示布场视觉候选，要补充：

模型只处理确定性解析解决不了的平面布场，而且候选必须绑定真实记录并由 Reviewer 接受。当前是布场任务第一版，不是完整空间图。

3:30—4:30：PostgreSQL 与 WISE 状态¶

展示数据浏览或监控页面：

• 来源文件和记录；
• 正式业务投影；
• WISE queued/publishing/succeeded 状态。

我会说：

PostgreSQL 提交和 WISE 发布是两个状态。数据库先保证正式事实，Outbox 再可靠同步；WISE 暂时失败不会让已确认资料丢失。

4:30—7:30：自然语言多轮需求¶

建议输入：

1. “帮我安排一个 120 人的围餐，人均预算 300 元。”
2. “改成 12 桌，其中 2 桌清真，晚上 18:30 开餐。”
3. “再加上接待等级和酒水要求。”
4. 在页面补齐并确认剩余槽位。

观察 SSE 事件：上下文加载、意图提取、需求更新、工具调用和状态变化。

我会说：

每轮不是把聊天文字直接当事实。模型提取动作和字段，后端把它们写进版本化需求；旧消息只能帮助理解，不能覆盖当前状态。

7:30—9:00：生成与校验方案¶

输入：“生成方案并检查能不能确认。”

展示：

• 菜单、酒水数量、人员配置、日程、物资、成本、风险和证据；
• 当前状态是 waiting_confirmation 还是 needs_clarification；
• 校验问题和来源。

我会说：

方案主体不是大模型自由写的。人数、数量、成本、食安门禁来自需求、目录、PostgreSQL 和 Python 规则；WISE 提供历史经验；模型最后把结构化结果表达出来。

9:00—10:00：主动展示一个失败边界¶

可以选择缺少食安通过或手工酒水数量的场景。

我会说：

这里故意不把页面做成全绿。食安没有明确通过，系统就不能确认方案。一个可信 AI 系统不仅要会成功，还要知道什么时候必须停下来问人。

二、三周项目怎样诚实又有力度地表达¶

推荐说法¶

三周不足以证明一个通用 Excel 解析器或成熟围餐决策系统，所以我没有把时间平均分给所有功能。我优先做了最影响可信度的骨架：来源证据、人工确认、模型权限、事务一致性、检索边界、需求状态和方案校验。这样后续增加数据和模型时，不需要推翻底层责任边界。

不推荐说法¶

三、高频业务问题¶

1. 对业务人员来说，最大的价值是什么？¶

不是少填几个表，而是把过去散落的资料变成可复用、可查来源的事实；新方案里能区分本次需求和历史参考，发现缺失或风险时会要求确认。

2. 为什么还需要人工审核，AI 不是应该自动化吗？¶

人工只处理不确定项，而不是逐行重录。食安、金额、人员和模糊字段存在责任边界，完全自动化可能把错误更快地写进系统。第一阶段更合理的目标是减少审核量并让审核有证据。

3. 如果业务人员选错字段怎么办？¶

系统保存原文件、坐标、原候选、最终选择、操作者和版本。正式事实来自派生投影，原证据不被覆盖，因此可以撤销或重新解析。后续还会增加更直观的变更对比和批量回滚。

4. 历史方案会不会把本次方案带偏？¶

本次人数、预算、地点、数量和执行规则以当前需求和目录为准。历史方案只作为 WISE 经验或 PostgreSQL 历史证据，界面和数据模型会区分“本次事实”和“历史参考”。

5. 数据量不大，为什么还要做 WISE？¶

当前数据量不足以证明大规模收益，但现在建立检索投影和评测合同，是为了验证职责边界和演进路径。数据小时 PostgreSQL 也能查；数据增长后 WISE 的语义检索价值才会更明显。我的结论不是“必须上向量库”，而是“历史说明类知识可以建立可重建的语义投影”。

四、高频技术问题¶

1. 这是 RAG 吗？¶

是，但不是“把所有 Excel 切块后全部向量化”的简单 RAG。PostgreSQL 保存结构化硬事实，WISE 只检索允许发布的说明和经验；生成时把两者组合，并对 WISE 结果做 PostgreSQL 元数据过滤。

2. 为什么不用 LangChain 或一个现成 Agent 框架？¶

当前动作和状态合同较明确，直接用应用服务和端口更容易控制事务、权限、错误码和测试。框架可以减少样板代码，但不会替我解决业务事实边界。后续如果工具和 Agent 数量明显增长，可以在不改变领域合同的前提下引入框架。

3. 当前算多 Agent 吗？¶

不算典型多 Agent。当前只有一个 Orchestrator 负责意图和动作调度，下面是确定性工具。参考项目里的 Handoff 设计给了我角色边界的思路，但我没有在没有业务必要时硬拆多个模型角色。

4. 为什么规则和 LLM 要同时保留？¶

规则可测试、低延迟、能兜底；LLM 更擅长自然语言变化。混合后，普通理解用 LLM 提升覆盖，高风险确认/取消用规则交叉保护，模型失败时业务仍能继续。

5. 为什么模型不能直接写数据库？¶

模型输出可能格式错误、字段越权、理解错误或受提示注入影响。当前模型只输出候选，后端检查动作、字段、目录、来源、版本和权限，再由事务服务写库。

6. Outbox 能保证绝对不重复吗？¶

它保证任务不会因为数据库提交后进程崩溃而丢失，并通过行锁、租约和状态条件减少并发覆盖。外部调用仍应按幂等设计；当前 WISE 发布遇到重复会复用远端已有 ID。更准确的说法是“至少一次处理 + 幂等结果收敛”，不是网络世界里的绝对恰好一次。

7. 为什么选 MCP，而不是直接 HTTP？¶

评测里 MCP 与 Skill API 是同一 WISE Agent Tool，检索结果相同。选择 MCP 主要为了标准工具发现、参数 Schema、会话和错误协议，未来替换或增加工具时 Orchestrator 不需要理解每个私有 HTTP 细节。

8. Prompt 是怎么防幻觉的？¶

意图 Prompt 限制动作和字段，要求 JSON、不得造值、保留顺序；回复 Prompt 把结构化应用状态和检索材料分区，规定结构化状态优先，检索事实必须引用来源，资料不足必须明确说无法确认。Prompt 之外还有 Pydantic、字段白名单、状态机和 Validator，因此不是只靠一句“不要幻觉”。

9. 方案生成为什么不用 LLM？这还算 Agent 吗？¶

Agent 不等于所有计算都由模型完成。当前 Agent 负责理解多动作、结合上下文、调用检索/生成/校验工具和组织回复；数量、成本和食安等高风险部分由确定性规则负责。这是有意的工程取舍。后续可以让模型产生多个候选，但不能绕过验证。

10. 你如何证明不是只做了一个 Demo？¶

我会展示四类证据：真实工作簿的来源坐标和重新解析结果；PostgreSQL 与 Outbox 状态；多轮 SSE 中的意图、工具和版本变化；方案中的验证问题和来源。测试只证明合同在给定样本下成立，不会被表述为生产成熟度。

五、现场可能被追问的不足¶

“数据这么少，准确率有意义吗？”¶

回答：

目前不适合给一个总准确率，因为“打开文件、识别表块、字段映射、正式投影、WISE 召回”是不同层级。我已经把指标层级拆开，也保留了历史样本结果，但不会用小样本证明通用能力。下一步是建立分层黄金集和失败样本，而不是继续堆规则后给一个虚高总分。

“为什么三周做得有些模块比较浅？”¶

回答：

我做了优先级选择。三周里先解决数据一旦写错就难追责、外部服务失败会不一致、模型可能越权这三类底层风险。菜单优化、多 Agent 和空间图都可以后续增强，但如果没有事实、事务和审核边界，功能越多风险越大。

“如果重做一次，你会先做什么？”¶

回答：

我会更早建立 20～50 份脱敏黄金工作簿和固定问题集，用数据决定解析器和检索优化顺序；同时推动业务输入模板标准化。系统既要兼容历史资料，也不应该永远为不规则 Excel 付出无限成本。

六、最后 30 秒¶

我是杨佳宇。这个项目让我认识到，AI 应用工程师的工作不是把模型接进接口，而是把模型放在正确的位置：让它做擅长的理解、候选和表达，把事实、权限、事务、校验和最终责任留给可控制的系统与人。三周完成的是一条可信骨架，下一阶段会用更多真实数据把每个模块从“能跑”推进到“可量化、可运营”。