docs(requirements): 收紧报送版式与飞书闭环要求

docs/需求分析/1.V1总需求文档.md

@@ -68,9 +68,9 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 ### 4.2 V1 可接受的简化
 
 1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
-2. 首版允许分阶段完成 Word 输出能力，但目标交付应包含“生成新的 Word 文档并支持导出”，同时尽量保留原始格式。
+2. 首版即要求具备“生成新的 Word 文档并支持导出”的能力，且输出版式必须达到可直接报送级别。
 3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
-4. 首版主体仍以 Web 工作台为主，但应纳入飞书接入方案，至少预留飞书消息触发、结果回传和责任人通知链路。
+4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
 5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
 
 ## 5. 业务闭环
@@ -89,6 +89,12 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
 2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
 
+其中法规知识维护方式应固定为：
+
+1. 按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
+2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
+3. 提供后台管理页面，支持人工校订和知识库更新。
+
 在法规维度上，建议把完整流程理解为：
 
 1. 识别当前审核任务属于“注册申报”主流程。
@@ -144,7 +150,11 @@ V1 需求分析按项目现有主模块拆分，不做过度细分：
 
 ### 7.6 系统需要具备“多入口访问能力”
 
-V1 主体虽然仍以 Web 端演示为主，但系统应预留并逐步实现飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话、飞书机器人和文档评论协作场景。
+V1 除 Web 工作台外，还需要实际支持飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话和飞书群聊机器人场景。
+
+### 7.7 系统需要具备“后台治理能力”
+
+除前台审核能力外，V1 还需要提供后台管理能力，用于维护规则包、模板库、责任人映射和知识库更新入口。
 
 ## 8. 后续文档与实现衔接建议