zhanghongyu_0626
9e1a9b2a7e
- Revised MEMORY.md to correct the status of kb_product_rules, clarifying that it has not been populated in the vector database as previously stated. - Enhanced TODO.md with detailed descriptions of completed tasks and their corresponding documentation paths for better tracking of project deliverables. - Added new files for daily meeting minutes, development plans, table design documents, API documentation, presentation materials, and requirements documentation, ensuring all necessary materials are indexed and easily accessible for the upcoming defense. - Updated README files to reflect the latest changes and provide a comprehensive overview of submission materials for the defense, aligning with client requirements.
5.5 KiB
答辩口播稿（业务展示版 · 约 12～15 分钟）
配合：幻灯片
presentation/index.html· 演示按DEMO-SOP-答辩全流程.md· 账号见defenseAccounts.ts
口径： 只讲需求、业务与系统展示；不口播测试数、缺陷、实现进度。客户交易演示带过、不深讲。
0. 开场（40 秒）
各位好。我们做的是一个代销场景下的四角色智能助手：客户财富、理财师、数据分析、风控。
四个角色共用同一套客户事实与合规规则——持仓、适当性、预警、审计口径一致，避免「各说各话」。
业务上：客户问清楚、买得明白；理财师合规展业、响应异动；分析员用数据说话；风控发现风险、人工处置留痕。
架构上四个助手不互相调用大模型；跨角色协作靠业务表、预警和代销平台接口，权限边界清晰。
1. 合规铁律（30 秒 · 业务语言）
三句必记：
正式风评不能被对话里的偏好覆盖；
只有适当性不匹配可以在交易网关拦单；
风控出预警后不自动冻户，处置和审计只增不改、可追溯。
2. 技术栈（15 秒 · 一句带过）
React 前端 + FastAPI 后端，MySQL 双库存业务与助手数据，Redis 管会话，向量库支撑产品知识检索；对话编排用 LangGraph，界面用 Ant Design。
细节不在答辩展开，需要时可看 docs/course/ 交互课。
3. Demo · 客户首页（1 分钟）
（登录 CUST-9527，可用登录页记号本）
首页持仓、图表来自代销平台只读接口，和助手查的是同一套事实。
眼睛图标是展示层脱敏，方便演示隐私保护。
4. Demo · 客户助手（2 分钟）
进客户助手：
- 问「我的持仓」或「最新净值」——回答有据可查，不是模型编造。
- 可选问「我能买什么」——给出可操作的选购清单（带序号），体现适当性 + 产品规则。
- 可选问「推荐稳赚」——合规拒绝，说明助手不能乱承诺收益。
交易（带过，30 秒内）： 若时间允许，从助手或交易中心点一次确认，让观众看到「对话/页面 → 确认 → 首页持仓更新」的业务闭环即可，不展开接口与实现。
5. Demo · 风控（2 分钟）
换 STAFF-30001。
模拟交易触发预警 → 台账待办 → 人工处置；强调：助手只能查、不能改状态，处置走平台操作。
可选：基金转换——演示「受理与确认分离」的业务节奏。
6. Demo · 问数（2 分钟）
STAFF-20001 → 问数工作台。
问 「客户总数是多少」——看模板命中与二次问同句更快（口径稳定、可复现）。
点 「分析该数据」——解读与表格数字对齐，体现「先出表、再解读」。
「近30天交易流水」——澄清口径，不猜用户意思。
7. Demo · 理财师工作台（1.5 分钟）
STAFF-10086。
合规检测：贴一段违规营销文案 → 命中规则。
市场异动：扫描 → 看到异动结果，服务名下客户跟进。
话术模板：列表与引用，支撑统一口径展业。
可选：顾问助手聊 1～2 轮，说明理财师也有对话入口，和客服是不同业务编排。
8. 收口（30 秒）
我们交付的是：四角色在同一合规底座上的可演示系统——客户咨询与选购、理财师合规与异动、问数可审计、风控可处置。
资料在 docs/答辩/ 与 docs/course/，欢迎会后翻看 Demo 动线。
9. Q&A 备用句（业务向）
| 问 | 答 |
|---|---|
| 四 Agent 为何不互调？ | 合规与审计要分边界；跨线靠预警表和平台 API，不混在一条 LLM 链路里。 |
| 数字从哪来？ | 客服/看板走 Core 只读；问数走 SQL 护栏；解读与表对齐。 |
| 交易谁说了算？ | 适当性在网关；确认后写模拟账，看板与助手同源刷新。 |
| 和真银行系统关系？ | 演示用模拟 Core，验证业务流程与合规设计，不是生产托管对接。 |
| 开发中是否用 Vibe Coding？遇到过什么坑？ | 有。 四 Agent + 双库 + 合规铁律，靠 AI 辅助写代码和测试很快，但三类坑要人工把关：① 文档/测试与实现漂移（例如登录从 /api/v1 改 canonical 后，仓库外 E2E 集体失效；pytest ignore-glob 写错导致「假绿基线」）—— 对策：MEMORY/TODO + 端到端包 先报告再修；② 合规口径不能交给模型猜（C3×R4 需揭示：前端、对话、网关必须同口径）—— 对策：L0 矩阵 + 单点网关 写死在代码；③ 演示数据与断言（holding 与 lot 不一致）—— 对策：Demo 前 prepare_all / 用前后差值叙事。经验：契约先行、小步提交、真 HTTP/浏览器取证，比「一次 prompt 全绿」可靠。 |
10. 必问主观题 · Vibe Coding（答辩须知）
见上表最后一行；可口语化 1 分钟，不展开具体 FAIL 数字（细节见知识点 §八 · 内部测试包）。
附录 · 6～8 分钟精华版
§0～§2 + Demo：客户首页 → 客户 Chat（一句）→ 风控模拟 → 问数模板+解读；顾问与交易各带过一句即可。