围餐智能体答辩材料¶

答辩人：杨佳宇｜AI 应用工程师
项目周期：3 周
适用观众：业务人员、产品人员、技术人员

这套材料不是代码百科，而是可以直接面对观众讲述的答辩稿。建议先讲 00，演示时按 05 执行；评委追问哪个技术点，再打开对应模块。

为什么要做这个系统¶

没有统一系统时，围餐信息可能由餐厅经理、厨师长、服务、食安等不同角色分别维护：每个人手里的 Excel 结构不同，标题和备注东一块西一块，有些信息还停留在其他文件或口头交接里。熟悉业务的人可以依靠经验把它们拼起来，但新来的餐厅经理首先要解决的往往不是“怎么出方案”，而是“哪份是最新的、每一列是什么意思、还有什么没有写”。

改造前	系统建立后的变化
多人手工维护，文件格式和字段叫法不统一	原文件保留，同时把可确认内容整理成统一业务字段
信息可能残缺、散落或只靠口头传递	缺失和歧义被显式暴露；口头信息必须录入或由责任人确认
新人依赖老员工解释，理解和交接成本高	可以查看来源、坐标、版本和确认状态，不必先猜整份表的隐含规则
每次出方案都重新找资料、核数字、问历史情况	本次硬事实与历史参考分开管理，Agent 再按规则生成和校验方案

这里的效果不是“从此不需要 Excel，也不需要人”，而是把反复找资料、猜含义和追问版本，变成一次证据化整理，以及对少量不确定项的明确确认。

一张图看懂整个项目¶

flowchart TB
    X["真实 Excel"] --> P["确定性解析<br/>保留坐标与证据"]
    P --> R{"业务 Reviewer<br/>确认含义"}
    L["LLM / 视觉模型"] -. "只提候选" .-> R
    R --> PG[("PostgreSQL<br/>正式事实源")]
    PG --> O["Transactional Outbox"]
    O --> W[("WISE<br/>可重建检索投影")]

    U["业务人员<br/>本次需求"] --> A["Agent Orchestrator"]
    PG -- "本次硬事实" --> A
    W -. "历史经验" .-> A
    A --> V["Python 规则生成与校验"]
    V --> H{"人工确认"}
    H --> PLAN["可执行围餐方案"]

现场只需要记住两条线：离线把资料变成可信事实，在线把本次需求变成可确认方案。模型可以参与理解和候选生成，但正式事实与最终确认始终由受控程序和人负责。

本地网站预览¶

在仓库根目录运行：

./serve-defense-docs.sh --open

也可以不自动打开浏览器，直接运行 ./serve-defense-docs.sh，再访问 http://127.0.0.1:8123。

页面会在 Markdown 修改后自动重建。
服务只监听本机地址，不会上传或公开答辩材料。
首次启动会由 uvx 下载锁定版本的 Zensical，之后复用本机缓存。
按 Ctrl+C 停止服务。

建议阅读顺序¶

00-现场讲述总稿.md：15～20 分钟主线。
01-Excel解析-怎样把复杂表格变成可信数据.md：重点技术模块。
02-PostgreSQL-Outbox-WISE-可信知识链路.md：事实库、可靠发布和检索选型。
03-Agent意图识别与多轮对话.md：自然语言如何变成受控动作。
04-方案生成-哪些地方用了Agent.md：透明说明 Agent、规则和 Prompt 的边界。
05-演示路线与高频问答.md：现场演示、三周项目话术和答辩问答。
06-小黑配图脚本.md：五张正文插图的放置位置与可直接生图 Prompt。

整套答辩只坚持四个判断¶

PostgreSQL 保存可追溯的业务事实，WISE 保存可重建的检索投影。
大模型负责理解、候选和表达，不直接决定正式业务事实。
方案不是模型凭空写出来的，而是当前需求、结构化事实、历史经验和校验规则共同生成的。
三周没有做成“万能系统”，但把最危险的边界和可继续演进的骨架搭了起来。

配图说明：Mermaid 技术图负责解释架构、流程、时序和状态；小黑插图负责增强节奏与记忆点。正文即使不依赖插图也能完整讲述，生成提示词与 QA 记录保留在 06。