diff --git a/docs/风控业务演示文档/答辩问题.txt b/docs/风控业务演示文档/答辩问题.txt
new file mode 100644
index 0000000..bdefc9a
--- /dev/null
+++ b/docs/风控业务演示文档/答辩问题.txt
@@ -0,0 +1,85 @@
+可以按下面这套结构准备答辩，既讲业务，也能体现技术深度和 AI Coding 协作反思。
+
+**1. 项目背景与解决的问题**
+
+可以这样讲：
+
+- 项目面向公募基金模拟交易场景，系统会产生客户、产品、交易、资金、持仓、登录和工单等数据。
+- 过去风险识别依赖人工排查，存在预警分散、证据不完整、处置过程不留痕、规则不可解释等问题。
+- 风控模块的目标不是直接替人做决定，而是把异常交易自动扫描成可解释、可追溯、可处置的预警。
+- 系统通过固定规则引擎识别风险，结合证据查询、人工处置、通知、日报和只看不办的 Agent，形成从“产生风险”到“人工闭环”的完整链路。
+- 模块最终解决的问题是：风险发现自动化、证据集中化、处置留痕化、统计报表化。
+
+**2. 核心功能**
+
+建议按业务链路讲：
+
+- 风险概览：展示当前未闭环预警、高中低风险分布、待处理和超时数量。
+- 预警队列：按风险等级优先排序，支持客户、产品、规则、时间和风险等级筛选，每页 10 条。
+- 规则扫描：支持手动扫描和定时扫描，使用 `RW-003`、`RW-007`、`RW-012`、`RW-015`、`RW-018`。
+- 证据查询：聚合客户、产品、交易、资金流水、持仓、登录记录、预警和通知。
+- 人工处置：确认接收、进入调查、关闭误报、完成结案和升级处理。
+- 证据归档：支持图片和常见文档上传，记录归档状态。
+- 通知与邮件：高风险预警生成站内提醒和邮件通知，发送失败可回查。
+- 日报：九段式结构日报，支持流式生成、编辑和邮件发送。
+- 奶龙风控智能助手：支持只读查询、证据解释、研判草案、回访话术和工单摘要，不直接执行处置。
+- 权限和数据范围：通过主项目 JWT、RBAC、客户数据范围控制访问。
+
+**3. 业务和技术讲解**
+
+业务层重点讲：
+
+- 规则引擎按数据库事实判断，不依赖模型自由发挥。
+- 同一交易命中多条规则时合并为一条预警，避免重复打扰。
+- 预警状态机保证确认、调查、误报和结案顺序可控。
+- 结案按风险等级扣减客户行为分，误报和未闭环不扣分。
+- 所有时间按 UTC 保存、北京时间展示和计算。
+- 演示机数据只准备上游业务数据，预警和通知由扫描器生成。
+
+技术层重点讲：
+
+- 采用 MVC+S，Controller 负责路由，Service 负责业务，Repository 负责数据访问。
+- 使用 FastAPI、异步 SQLAlchemy、MySQL、Alembic 管理数据库。
+- Worker 处理异步 Agent Run、消息持久化和配置。
+- Agent 使用 `/api/v1/agent-runs` 和 SSE，前端实现流式输出。
+- 列表使用游标分页，分页信息放在 `meta`。
+- 写接口使用 `Idempotency-Key`，扫描和处置具备幂等保护。
+- Redis、Milvus 或模型不可用时支持降级，不阻断核心预警链路。
+- 所有关键操作写审计记录，保证可追溯。
+
+**4. 难点和亮点**
+
+可以重点讲这几个：
+
+- 规则条件复杂：金额、比例、时间窗口、客户年龄、设备状态、工单留痕和适当性等级都要同时满足。
+- 证据链完整：预警不能只有一句结论，还要能追溯到交易、资金、持仓、登录和工单。
+- 去重和幂等：同一交易和同一规则只生成一次，关闭后重新扫描不能重复生成。
+- 时间口径：数据库为 UTC，业务判断和日报按北京时间，避免凌晨和当天统计错位。
+- Agent 边界：Agent 只读，不能确认、关闭、升级预警，也不能修改客户和交易事实。
+- 会话记忆：同一会话复用 `session_id`，Worker 从 MySQL 读取最近 10 轮，风险 Agent 把历史传给模型。
+- 降级设计：模型超时或返回异常时使用规则化输出，不影响扫描和查询。
+- 前后端协作：预警详情、分页、权限、通知和 Agent 上下文已接入正式前端。
+- 演示数据责任清晰：本机不承担演示机初始化，演示机按数据插入规则准备上游数据。
+
+**5. 开发中的收获，包括 AI Coding 工具和沟通**
+
+做得好的地方：
+
+- 我们把需求拆成扫描、查询、处置、通知、日报、Agent 和前端等独立模块，逐步开发和验证。
+- 你提供了明确的业务规则、错误日志、页面现象和测试结果，很多问题因此能快速定位。
+- 重要决策都要求写文档，例如接口、状态机、分页、演示机数据插入规则。
+- 每一轮修改后都执行专项测试和静态检查，再提交推送，降低了回归风险。
+- AI Coding 工具在跨文件分析、规则梳理、测试补齐、文档生成和小范围修复上效率很高。
+- 你坚持“先分析影响面，再修改代码”的工作方式，有效避免了盲目改动。
+
+做得不好的地方：
+
+- 有些关键边界前期没有一次性说清，例如“本机演示”和“演示机插入数据”是不同目标，导致我一度写错本机造数脚本。
+- “继续做”这类指令依赖历史上下文，如果没有明确目标分支、目标环境和交付物，容易理解偏差。
+- 需求在执行中会持续调整，部分功能在边界未冻结前就进入编码，返工成本较高。
+- AI Coding 工具容易主动补全未明确的需求，因此必须让人类先确认业务边界和数据责任。
+- 我在个别问题上过早进入实现阶段，应该先确认是“本机验证、演示机交付、主项目合并还是文档输出”。
+
+答辩时可以用一句话收尾：
+
+> 这个项目的核心价值不是让 AI 代替风控人员，而是用确定性规则和完整证据提高风险发现效率，再由风控人员完成最终判断和处置。AI 和 Coding Agent 的价值，是把这种复杂业务链路的开发、测试和文档化变得更快，但业务边界和最终判断仍然必须由人负责。
\ No newline at end of file