Bruce/DEMO-AGENT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(ui): 重构注册审核平台原型界面

Browse Source
This commit is contained in:
bruce
2026-06-03 08:41:48 +08:00
parent 77166b5cd3
commit b2c1da3f02
24 changed files with 2563 additions and 536 deletions
Download Patch File Download Diff File Expand all files Collapse all files

376
docs/superpowers/plans/2026-06-03-registration-agent-prototype.md Normal file
View File

@@ -0,0 +1,376 @@
# Registration Agent Prototype Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Build a new high-fidelity, demo-ready prototype UI for the registration review agent platform across homepage, knowledge base, document processing, agent workspace, MCP, Skills, and leadership dashboard screens.
**Architecture:** Keep the existing Django monolith and template routing boundaries, but replace the current visual system with a unified prototype shell and add a dedicated platform app for new governance pages. Use shared presentation data in service/view code so the pages tell one coherent business story without coupling design code to the existing agent execution internals.
**Tech Stack:** Django templates, Django views/URLs, Python service helpers, shared inline CSS in base template, existing forms/models where useful.
---
## File Structure
- Modify: `F:\PyCharm\DEMO-AGENT\templates\base.html`
- Modify: `F:\PyCharm\DEMO-AGENT\templates\scenarios\index.html`
- Modify: `F:\PyCharm\DEMO-AGENT\templates\documents\document_list.html`
- Modify: `F:\PyCharm\DEMO-AGENT\templates\documents\upload.html`
- Modify: `F:\PyCharm\DEMO-AGENT\templates\chat\index.html`
- Create: `F:\PyCharm\DEMO-AGENT\apps\platform_ui\__init__.py`
- Create: `F:\PyCharm\DEMO-AGENT\apps\platform_ui\apps.py`
- Create: `F:\PyCharm\DEMO-AGENT\apps\platform_ui\views.py`
- Create: `F:\PyCharm\DEMO-AGENT\apps\platform_ui\urls.py`
- Create: `F:\PyCharm\DEMO-AGENT\apps\platform_ui\services.py`
- Create: `F:\PyCharm\DEMO-AGENT\templates\platform_ui\knowledge_base.html`
- Create: `F:\PyCharm\DEMO-AGENT\templates\platform_ui\mcp_center.html`
- Create: `F:\PyCharm\DEMO-AGENT\templates\platform_ui\skill_studio.html`
- Create: `F:\PyCharm\DEMO-AGENT\templates\platform_ui\command_center.html`
- Modify: `F:\PyCharm\DEMO-AGENT\config\settings.py`
- Modify: `F:\PyCharm\DEMO-AGENT\config\urls.py`
- Test: `F:\PyCharm\DEMO-AGENT\tests\`
### Task 1: Register the new platform prototype app
**Files:**
- Create: `apps/platform_ui/__init__.py`
- Create: `apps/platform_ui/apps.py`
- Create: `apps/platform_ui/views.py`
- Create: `apps/platform_ui/urls.py`
- Modify: `config/settings.py`
- Modify: `config/urls.py`
- [ ] **Step 1: Add the Django app module skeleton**
```python
from django.apps import AppConfig
class PlatformUiConfig(AppConfig):
default_auto_field = "django.db.models.BigAutoField"
name = "apps.platform_ui"
```
- [ ] **Step 2: Register the app in settings**
```python
INSTALLED_APPS = [
# ...
"apps.platform_ui",
]
```
- [ ] **Step 3: Add prototype page routes**
```python
urlpatterns = [
path("platform/", include("apps.platform_ui.urls")),
]
```
- [ ] **Step 4: Define view names for prototype pages**
```python
urlpatterns = [
path("knowledge-base/", views.knowledge_base, name="knowledge-base"),
path("mcp-center/", views.mcp_center, name="mcp-center"),
path("skills/", views.skill_studio, name="skills"),
path("command-center/", views.command_center, name="command-center"),
]
```
- [ ] **Step 5: Run framework validation**
Run: `python manage.py check`
Expected: PASS with no URL or app import errors
### Task 2: Create shared presentation data for the new prototype
**Files:**
- Create: `apps/platform_ui/services.py`
- Modify: `apps/platform_ui/views.py`
- [ ] **Step 1: Define one coherent demo dataset**
```python
def get_platform_demo_context():
return {
"batch": {...},
"knowledge_sources": [...],
"mcp_connectors": [...],
"skills": [...],
"workflow_steps": [...],
}
```
- [ ] **Step 2: Keep each page view thin**
```python
def knowledge_base(request):
context = get_platform_demo_context()
return render(request, "platform_ui/knowledge_base.html", context)
```
- [ ] **Step 3: Run framework validation**
Run: `python manage.py check`
Expected: PASS with importable views and service helpers
### Task 3: Replace the global visual system and navigation shell
**Files:**
- Modify: `templates/base.html`
- [ ] **Step 1: Rewrite the global shell**
```html
<body>
<div class="app-shell">
<aside class="sidebar">...</aside>
<main class="main-shell">
<header class="topbar">...</header>
{% block content %}{% endblock %}
</main>
</div>
</body>
```
- [ ] **Step 2: Define the new design tokens and shared components**
```css
:root {
--bg: #eef3f7;
--surface: #f8fbfd;
--panel: #ffffff;
--ink: #102033;
--accent: #1e5eff;
--signal: #d77a2b;
}
```
- [ ] **Step 3: Add global helpers for panels, metric cards, timelines, tables, pills, and section headers**
```css
.panel { ... }
.metric-card { ... }
.section-heading { ... }
.timeline-step { ... }
.data-table { ... }
```
- [ ] **Step 4: Render shared navigation links to all prototype surfaces**
```html
<a href="{% url 'scenarios:index' %}">任务总览</a>
<a href="{% url 'platform_ui:knowledge-base' %}">知识库配置</a>
<a href="{% url 'documents:list' %}">文件中心</a>
<a href="{% url 'platform_ui:command-center' %}">工作台大屏</a>
```
- [ ] **Step 5: Open a few pages manually**
Run: `python manage.py runserver`
Expected: the shell renders and every nav item resolves
### Task 4: Redesign the homepage as the business-closure entry point
**Files:**
- Modify: `templates/scenarios/index.html`
- Modify: `apps/scenarios/views.py` if extra presentation fields are needed
- [ ] **Step 1: Add a structured homepage context if needed**
```python
return render(
request,
"scenarios/index.html",
{
"scenarios": list_scenarios(),
"scenario_issues": list_scenario_issues(),
"hero_metrics": [...],
"workflow_overview": [...],
},
)
```
- [ ] **Step 2: Replace the page body with hero, metrics, workflow strip, risk board, and quick-entry modules**
```html
<section class="hero-band">...</section>
<section class="metrics-grid">...</section>
<section class="workflow-strip">...</section>
<section class="two-column-board">...</section>
```
- [ ] **Step 3: Verify the homepage**
Run: `python manage.py runserver`
Expected: `/` shows the new dashboard-like homepage
### Task 5: Redesign the document pages around parsing and slicing workflow
**Files:**
- Modify: `templates/documents/document_list.html`
- Modify: `templates/documents/upload.html`
- Optionally modify: `apps/documents/views.py`
- [ ] **Step 1: Add any lightweight display-only summary fields in the view if needed**
```python
return render(
request,
"documents/document_list.html",
{
"documents": documents,
"processing_summary": {...},
"exception_items": [...],
},
)
```
- [ ] **Step 2: Rebuild the list page into upload stats, pipeline board, anomaly box, and structured directory table**
```html
<section class="metrics-grid">...</section>
<section class="tri-column">...</section>
<section class="panel">
<table class="data-table">...</table>
</section>
```
- [ ] **Step 3: Rebuild the upload page into a guided import experience**
```html
<section class="dropzone-panel">...</section>
<section class="checklist-panel">...</section>
```
- [ ] **Step 4: Verify both pages**
Run: `python manage.py runserver`
Expected: `/documents/` and `/documents/upload/` match the new prototype style
### Task 6: Redesign the chat page as a controlled audit workspace
**Files:**
- Modify: `templates/chat/index.html`
- Optionally modify: `apps/chat/views.py`
- [ ] **Step 1: Add presentation-only helper blocks if the existing context is too sparse**
```python
return render(
request,
"chat/index.html",
{
...
"task_modes": [...],
"result_highlights": [...],
},
)
```
- [ ] **Step 2: Replace the template with a three-zone workspace**
```html
<section class="workspace-grid">
<div class="left-rail">...</div>
<div class="conversation-stage">...</div>
<div class="result-rail">...</div>
</section>
```
- [ ] **Step 3: Preserve the real form submission path while upgrading the visual output areas**
```html
<form method="post">...</form>
{% if result %} ... {% endif %}
```
- [ ] **Step 4: Verify one scenario page**
Run: `python manage.py runserver`
Expected: `/chat/<scenario_id>/` still submits and now renders as a workbench
### Task 7: Implement the governance and platform pages
**Files:**
- Create: `templates/platform_ui/knowledge_base.html`
- Create: `templates/platform_ui/mcp_center.html`
- Create: `templates/platform_ui/skill_studio.html`
- Create: `templates/platform_ui/command_center.html`
- Modify: `apps/platform_ui/views.py`
- Modify: `apps/platform_ui/services.py`
- [ ] **Step 1: Build the knowledge base page**
```html
<section class="three-column-board">...</section>
<section class="panel">...</section>
```
- [ ] **Step 2: Build the MCP center page**
```html
<section class="connector-grid">...</section>
<section class="import-flow">...</section>
```
- [ ] **Step 3: Build the Skill studio page**
```html
<section class="editor-layout">...</section>
<section class="version-board">...</section>
```
- [ ] **Step 4: Build the leadership command center page**
```html
<section class="command-stage">...</section>
<section class="risk-heatmap">...</section>
<section class="evidence-matrix">...</section>
```
- [ ] **Step 5: Verify page routing**
Run: `python manage.py check`
Expected: PASS and all `/platform/...` routes resolve
### Task 8: Regression, polish, and documentation sync
**Files:**
- Modify: `README.md` if navigation or page descriptions need updating
- Modify: `AGENTS.md` only if current implementation status needs sync
- [ ] **Step 1: Run core validation**
Run: `python manage.py check`
Expected: PASS
- [ ] **Step 2: Run targeted tests if template/view assumptions changed**
Run: `pytest`
Expected: PASS or clearly identified existing failures unrelated to the prototype
- [ ] **Step 3: Review the new screens for consistent terminology**
Check: page titles, batch name, product name, risk labels, and workflow terms all match the new design spec
- [ ] **Step 4: Update high-level documentation if needed**
```markdown
## 当前原型页面
- 任务总览
- 知识库配置
- 文件中心
- 审核工作台
- MCP 中心
- Skill Studio
- 工作台大屏
```
## Self-Review
- Spec coverage: the plan covers homepage, knowledge base, document center, chat workspace, MCP, Skill studio, and leadership dashboard.
- Placeholder scan: no TODO/TBD markers remain.
- Type consistency: route names, app names, and page concepts are consistent across tasks.

185
docs/superpowers/specs/2026-06-03-registration-agent-prototype-design.md Normal file
View File

@@ -0,0 +1,185 @@
# 注册审核智能体平台产品原型设计
## 目标
本次原型围绕“试剂盒临床注册文件准备与审核智能体平台”重新设计一套高保真、可点击、适合复试演示的 Web 产品界面。设计不沿用当前前端视觉，而是以新版需求分析为准，突出资料治理、法规知识底座、Agent 审核闭环、平台治理能力和可解释工作台。
## 设计范围
本次原型聚焦一条完整演示主线：
1. 首页进入批次级任务总览。
2. 查看法规知识库与结构化规则配置。
3. 上传并解析申报资料，查看切片、页数、章节点归类和异常状态。
4. 进入 AI Agent 审核工作台执行完整性检查、字段抽取和一致性核查。
5. 查看外部 MCP 能力接入情况。
6. 查看和编辑 Skill 编排能力。
7. 进入领导演示型工作台大屏查看 Agent 工作流程、解释依据和风险态势。
## 设计原则
### 1. 业务闭环优先
页面组织必须服务“资料准备到审核闭环”，而不是把系统包装成泛化 Agent 工具箱。
### 2. 高层能看懂，操作员也能讲清
首页与大屏承担讲故事职责；知识库、文件中心、Agent 工作台承担业务可信度职责；MCP 与 Skill 页面承担平台能力说明职责。
### 3. 可解释性强于炫技
任何页面都应尽量展示来源、阶段、规则命中、风险等级、人工复核状态，而不是堆叠模型术语。
### 4. 信息密度高但不压抑
整体风格走“专业监管科技工作台”，采用明亮底色、深色信息层、铜橙风险强调、清晰分栏和大面积结构化留白。
## 视觉方向
### 色彩
- 主背景采用浅米白与冷灰蓝混合渐变，强调专业与稳定。
- 主强调色采用深青蓝，承担导航、激活态、关键信息。
- 风险强调采用铜橙与深红，用于高风险、缺失、待处理。
- 成功状态采用低饱和绿色，用于已完成、已入库、规则已生效。
### 排版
- 页级标题使用强对比的中文大标题，突出“阶段感”。
- 模块级标题使用中等字号与清晰副标题。
- 指标数字使用紧凑等宽风格，强调可视化汇报感。
### 组件风格
- 顶部为平台导航与当前批次状态条。
- 页面内部以大面板、信息条、时间线、矩阵卡片、指标舱和结构树为主。
- 尽量避免传统后台里大量相同卡片堆叠，强化带状布局、流程图感和分析板感。
## 页面设计
### 1. 首页 / 任务总览
**目标：**
让评委在 10 秒内理解系统价值和当前批次进展。
**核心内容：**
- 批次概览 Hero：当前申报批次、产品名、流程阶段、批次状态。
- 四个关键指标：资料齐套率、法规命中率、字段抽取完成度、高风险项数量。
- 演示主流程带：资料进入、规则配置、解析入库、审核执行、结果输出。
- 今日待办与高风险问题板。
- 快速入口：知识库、文件中心、审核工作台、大屏。
### 2. 知识库搭建与配置页
**目标：**
把“双层知识底座”讲透。
**核心内容：**
- 左侧法规规则树：按章、条、要求项、模板字段展示。
- 中部知识源列表：法规依据、业务资料、模板库、公告附件包。
- 右侧切片与生效配置：切片策略、召回阈值、适用流程、最近更新时间。
- 底部人工校订记录与知识更新入口。
### 3. 文件上传、切片与解析中心
**目标：**
展示 Documents 模块是“资料治理中心”。
**核心内容：**
- 顶部上传拖拽区与批次选择。
- 左侧批量导入队列：文件名、类型、页数、识别状态。
- 中部处理流水：保存原件、提取文本、识别表格、页数统计、章节点归类、切片入库。
- 右侧异常箱：疑似扫描件、归类待确认、页数低可信度、切片失败。
- 下方目录总览表：章节点、资料名称、状态、模板命中情况。
### 4. AI Agent 审核工作台
**目标：**
把自由问答升级为受控审核任务工作台。
**核心内容：**
- 顶部任务切换：目录汇总、完整性检查、字段抽取、一致性核查、综合风险报告。
- 左侧自然语言输入与资料范围选择。
- 中间 Agent 对话流与执行阶段条。
- 右侧结构化结果舱：结论摘要、字段表、缺失项、冲突项、风险建议。
- 下方证据区：法规条款引用、文档片段、来源页码、人工复核提示。
### 5. 外部 MCP 导入页
**目标：**
说明平台可扩展但不喧宾夺主。
**核心内容：**
- MCP 连接卡：法规源、飞书通知、模板服务、文档转换、企业数据源。
- 接入状态、鉴权方式、最近同步时间。
- 输入输出能力摘要。
- 一个简单的导入向导区块。
### 6. Skill 编辑与使用页
**目标：**
展示 Agent 可配置、可维护、可复用。
**核心内容：**
- Skill 列表：完整性检查、字段抽取、一致性核查、Word 回填、飞书通知。
- 中部编辑区：角色说明、工具绑定、输入输出约束、启停配置。
- 右侧运行预览：最近测试结果、命中工具、失败原因。
- 底部版本历史和发布状态。
### 7. Agent 工作台大屏
**目标：**
作为演示高潮页，向领导/评委解释“这一轮审核发生了什么”。
**核心内容：**
- 顶部大标题与批次状态。
- 左侧流程总览：资料进入、规则装载、字段池建立、一致性比对、风险汇总。
- 中央主舞台：Agent 工作流时间轴，展示每一步的输入、动作、输出和解释。
- 右侧风险热力与关键告警。
- 底部证据矩阵：法规依据、命中文档、责任人、待补动作。
## 跳转与演示动线
推荐演示顺序：
1. 首页说明平台定位。
2. 进入知识库页说明法规与规则如何维护。
3. 进入文件中心说明资料如何入库、切片、归类。
4. 进入审核工作台发起一次完整性或一致性检查。
5. 进入 Skill 页解释为何 Agent 行为可控。
6. 进入 MCP 页说明可接飞书与外部能力。
7. 最后切到大屏汇总整轮审核过程。
## 数据策略
本轮原型以高保真演示为优先，允许使用页面级演示数据，但必须满足：
- 术语与字段名称来自新版需求分析。
- 状态设计贴近真实业务流程。
- 页面间批次名称、产品名称、风险项和规则口径保持一致。
## 实现策略
基于当前 Django 模板工程直接重构前端：
1. 保留现有 Django 应用与路由边界。
2. 新增平台页应用承接知识库、MCP、Skill、大屏页面。
3. 重做 `base.html` 及所有主要模板的布局和样式。
4. 使用共享演示数据构造页面内容，保证视觉统一和讲解一致。
## 测试与验证
原型完成后至少验证：
1. Django 路由可访问。
2. 首页、知识库、文件中心、审核工作台、MCP、Skill、大屏页面均可打开。
3. 页面导航互通。
4. `python manage.py check` 通过。
5. 如无模板语法问题，关键页面可在本地服务下正常渲染。

597
docs/需求分析/9.业务确认问答清单.md Normal file
View File

@@ -0,0 +1,597 @@
# 业务确认问答清单
## 1. 文档目的
本文档用于和业务方进一步确认需求边界、交付口径和演示重点。
它和 `0.需求重构总览与待确认事项.md` 的区别是：
1. 总览文档更偏内部需求分析。
2. 本文档更偏“可直接拿去问业务”的沟通清单。
3. 每个问题尽量使用业务语言，避免陷入实现细节。
建议使用方式：
1. 按章节逐条和业务确认。
2. 每个问题尽量记录“明确答案 + 备注 + 示例材料来源”。
3. 若业务方回答不确定，可先记为“当前默认口径”。
4. 沟通完成后，再回填更新需求分析和设计文档。
---
## 2. 当前已确认口径摘要
以下内容目前已经有较明确的方向，和业务确认时可以先作为“我们的当前理解”说给对方听，请对方确认是否同意：
1. 系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，不是只服务某一个固定产品。
2. 一致性核查当前按完全一致处理，不采用“语义差不多即可”的宽松口径。
3. 风险按高 / 中 / 低三级，任一高风险即不允许通过。
4. 输出结果必须支持生成新的 Word 文档，并达到可直接报送级版式。
5. 用户后续编写的新模板可以纳入模板库，后续按模板回填。
6. 规则来源以公告附件包为主，`附件 4` 视作同源补充材料。
7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。
9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。
---
## 3. 建议的沟通原则
和业务沟通时，建议优先确认四类问题：
1. 交付结果长什么样。
2. 哪些结论能自动判，哪些必须人工复核。
3. 哪些材料算输入，哪些材料算规则依据。
4. Demo 要演示到什么深度。
对于每个问题，建议都尽量追问到这三个层次：
1. 业务目标是什么。
2. 验收标准是什么。
3. 出现例外时怎么处理。
---
## 4. 业务确认问答清单
## 4.1 业务目标与使用场景
### Q1 当前系统最核心要解决的业务问题是什么？
建议提问方式：
> 如果这次 Demo 只能重点解决 1 到 2 个最关键问题，您最希望它解决什么？
建议记录答案：
- 主问题：
- 次问题：
- 不在本次范围的问题：
为什么要问：
- 这个问题决定首页主叙事和演示主线。
- 也决定后续是偏“审核”还是偏“生成回填”。
### Q2 这个系统的主要使用人是谁？
建议提问方式：
> 这个系统主要是给注册专员、法规人员、项目经理，还是管理层演示用？是否会有不同角色看到不同内容？
建议记录答案：
- 主要用户角色：
- 次要用户角色：
- 是否区分角色权限：
为什么要问：
- 决定页面表述是否偏专业操作型。
- 决定飞书通知和责任人配置逻辑。
### Q3 业务更看重“审核发现问题”还是“自动生成报送材料”？
建议提问方式：
> 在您看来，这套系统最有价值的是先帮您发现资料问题，还是直接帮您产出可报送材料？
建议记录答案：
- 更偏审核：
- 更偏生成：
- 两者权重：
为什么要问：
- 决定 Demo 讲解时主功能排序。
- 决定开发时优先打磨哪个闭环。
---
## 4.2 输入资料范围
### Q4 本次 Demo 是否允许以第 1 章样本作为主演示材料？
建议提问方式：
> 目前样例材料主要集中在第 1 章，Demo 是否可以以第 1 章为主要演示对象，同时在规则上覆盖第 2 到第 6 章？
建议记录答案：
- 是否允许：
- 若不允许，需要补哪些章的样本：
为什么要问：
- 决定当前实现是否以“第 1 章内容级演示 + 全章规则级覆盖”为主。
### Q5 第 2 到第 6 章后续是否会补充真实业务样本？
建议提问方式：
> 如果希望 Demo 展示第 2 到第 6 章的抽取、比对和回填效果，后续是否会补充真实样本或脱敏样本？
建议记录答案：
- 是否补充：
- 预计补充哪些章：
- 预计补充时间：
为什么要问：
- 决定系统当前只做“结构合规”还是还能做“内容级审核”。
### Q6 当前样例中的跨产品材料混杂，是刻意测试异常，还是后续会统一资料包？
建议提问方式：
> 当前样例里存在不同产品名称的材料混在一起，这种情况是有意作为异常样例，还是后续会再整理成同一产品的一套资料？
建议记录答案：
- 属于刻意异常：
- 属于样例混杂：
- 后续是否会统一：
为什么要问：
- 决定一致性冲突是“核心演示点”还是“样本噪声”。
---
## 4.3 自动审核与人工复核边界
### Q7 哪些类型的问题可以由系统直接判定，哪些必须人工复核？
建议提问方式：
> 对您来说，哪些问题系统可以直接下结论，哪些问题必须保留给人工复核？
建议引导业务按下列类型回答：
1. 文件缺失
2. 章节点归类错误
3. 字段不一致
4. 模板格式不符合
5. 历史申报事项解释
建议记录答案：
- 可自动判定：
- 必须人工复核：
- 自动判定后是否仍需人工确认：
为什么要问：
- 决定结果页里哪些内容标“通过/不通过”，哪些标“待复核”。
### Q8 “完全一致”的范围是否适用于所有字段？
建议提问方式：
> 我们当前理解是：同一审核范围内，相同字段默认按完全一致处理。请确认是否所有关键字段都按这个标准执行，还是有少数字段允许格式差异但含义一致。
建议引导业务按字段类别回答：
1. 产品名称
2. 申请人名称
3. 规格型号
4. 适用范围
5. 储存条件
6. 样本类型
建议记录答案：
- 必须完全一致的字段：
- 允许人工判断等价的字段：
为什么要问：
- 虽然当前默认口径是完全一致，但和业务再确认一次更稳。
### Q9 风险评分结果里，“不通过”是否只看高风险，还是还要加总分门槛？
建议提问方式：
> 当前理解是“任一高风险即不通过”。除此之外，是否还需要总分门槛，比如中风险积累到一定程度也不通过？
建议记录答案：
- 是否仅以高风险阻断：
- 是否需要总分门槛：
- 是否需要“有条件通过 / 整改后复核”状态：
为什么要问：
- 决定风险报告的最终判定逻辑。
---
## 4.4 Word 生成与模板管理
### Q10 业务侧对“可直接报送级版式”的验收标准是什么？
建议提问方式：
> 对于导出的 Word，您认为达到“可直接报送”的最低标准是什么？哪些版式元素是绝对不能错的？
建议引导业务从以下维度回答：
1. 标题层级
2. 段落格式
3. 表格样式
4. 页眉页脚
5. 页码
6. 盖章位
7. 附件格式
建议记录答案：
- 必须严格保留的版式元素：
- 可接受微调的版式元素：
- 不可接受的典型错误：
为什么要问：
- 这是 Word 导出能否被认为“可交付”的关键。
### Q11 是否需要同时导出 PDF 归档件？
建议提问方式：
> 除了 Word 报送稿，是否还需要系统同步导出 PDF 作为归档、流转或内部审核附件？
建议记录答案：
- 是否需要 PDF：
- Word 和 PDF 哪个是主交付件：
为什么要问：
- 决定导出链路和验收文件类型。
### Q12 新模板进入模板库后，谁来确认它是正式模板？
建议提问方式：
> 如果后续由您这边提供新的模板，系统纳入模板库之前，是否需要指定某个角色进行确认、审批或启用？
建议记录答案：
- 模板提供方：
- 模板审核方：
- 模板启用规则：
为什么要问：
- 决定后台模板管理页是否需要版本和审批状态。
### Q13 模板是按什么维度区分的？
建议提问方式：
> 模板需要按哪些维度区分，例如注册申报 / 变更 / 延续、不同章节点、不同产品类型，还是不同企业内部模板版本？
建议记录答案：
- 按流程类型：
- 按章节点：
- 按产品类型：
- 按企业版本：
为什么要问：
- 决定模板库数据结构。
---
## 4.5 法规规则与知识库治理
### Q14 当前法规规则源是否只以现有公告附件包为准？
建议提问方式：
> 当前 Demo 是否可以只以现有公告附件包和附件 4 为规则依据，不额外纳入其他外部法规文件？
建议记录答案：
- 是否只用现有规则包：
- 是否还要补充其他规则源：
为什么要问：
- 决定知识库首版范围。
### Q15 后台知识库更新入口由谁使用？
建议提问方式：
> 后台的知识库更新和人工校订功能，预计是只有管理员可用，还是法规/注册业务人员也会参与维护？
建议记录答案：
- 仅管理员：
- 管理员 + 业务人员：
- 是否需要操作留痕：
为什么要问：
- 决定后台权限模型和审计范围。
### Q16 人工校订主要校订哪些内容？
建议提问方式：
> 您希望人工校订功能主要用于改哪些内容？是法规切片、字段映射、模板字段、责任人映射，还是审核结论备注？
建议记录答案：
- 允许校订的内容：
- 不允许业务侧直接改的内容：
为什么要问：
- 决定后台管理页具体有哪些编辑入口。
### Q17 知识库更新后，是否需要重新审核历史项目？
建议提问方式：
> 如果法规规则或模板更新了，历史项目是否需要按新规则重新检查，还是仅影响新项目？
建议记录答案：
- 仅影响新项目：
- 历史项目需要重跑：
- 是否保留旧版本结果：
为什么要问：
- 决定规则版本管理和历史审计口径。
---
## 4.6 飞书接入与责任人通知
### Q18 飞书群聊机器人里，业务最希望怎么触发任务？
建议提问方式：
> 在飞书群聊里，您更希望通过固定命令触发，还是通过菜单、卡片按钮、表单方式选择任务？
建议记录答案：
- 命令式：
- 卡片式：
- 菜单式：
- 其他偏好：
为什么要问：
- 决定飞书端交互体验复杂度。
### Q19 飞书里“结果查看”希望看到多详细？
建议提问方式：
> 在飞书里，您更希望看到简短摘要，还是希望直接看到缺失项、风险等级、责任人、下载链接这些完整信息？
建议记录答案：
- 仅摘要：
- 摘要 + 关键问题：
- 尽可能完整：
为什么要问：
- 决定飞书卡片内容设计。
### Q20 责任人是如何定义的？
建议提问方式：
> 责任人是按章节点、按资料类型、按项目角色，还是按项目具体人员来分配？
建议记录答案：
- 按章节点：
- 按资料类型：
- 按项目角色：
- 按具体人员：
为什么要问：
- 决定责任人配置表结构。
### Q21 责任人通知只要 `@人`，还是还要带整改动作？
建议提问方式：
> 飞书通知时，您是只希望 `@` 到对应责任人，还是希望同时带上问题摘要、整改建议、资料链接和截止时间？
建议记录答案：
- 只需 `@人`：
- 需要问题摘要：
- 需要整改建议：
- 需要截止时间：
为什么要问：
- 决定飞书通知卡片结构。
### Q22 是否需要支持多人负责同一项问题？
建议提问方式：
> 同一章节点或同一风险项，是否可能对应多个责任人，例如主责人 + 复核人？
建议记录答案：
- 是否支持多人：
- 是否区分主责 / 协同 / 复核：
为什么要问：
- 决定责任人映射是否是一对一还是一对多。
---
## 4.7 审计、追溯与管理要求
### Q23 业务最关心审计记录里看到什么？
建议提问方式：
> 如果后续回看一次审核记录，您最希望一眼看到哪些信息？
建议引导业务回答：
1. 审核时间
2. 审核人
3. 使用的资料范围
4. 风险等级
5. 不通过原因
6. 导出文件
7. 飞书通知记录
建议记录答案：
- 必看信息：
- 次要信息：
为什么要问：
- 决定审计列表和详情页优先展示字段。
### Q24 是否需要区分“系统自动结论”和“人工修改后结论”？
建议提问方式：
> 如果系统先给出自动判断，后续又经过人工校订或人工确认，是否需要把这两个结果区分记录？
建议记录答案：
- 是否区分：
- 是否保留修改原因：
- 是否保留修改人：
为什么要问：
- 决定审计模型是否需要版本链。
---
## 4.8 Demo 演示与验收方式
### Q25 Demo 现场最希望看到哪条完整链路？
建议提问方式：
> 如果现场只演示一条最完整的链路，您最希望看到哪一种？
建议给业务三个选项帮助回答：
1. 导入资料 -> 自动检查缺失 -> 输出风险报告
2. 导入资料 -> 抽取字段 -> 自动生成 Word
3. 飞书群聊触发 -> 查看结果 -> 通知责任人
建议记录答案：
- 首选演示链路：
- 次选演示链路：
为什么要问：
- 决定 Demo 讲解脚本和开发优先级。
### Q26 本次 Demo 的“通过标准”是什么？
建议提问方式：
> 对您来说，这次 Demo 达到什么程度，就可以认为是比较成功的？
建议引导业务从以下角度回答：
1. 能看出业务理解到位
2. 能自动发现主要问题
3. 能自动生成较完整材料
4. 能在飞书里顺畅演示
5. 能展示后台治理能力
建议记录答案：
- 必须达到：
- 加分项：
- 本次不强求：
为什么要问：
- 这是项目收敛范围的总开关。
---
## 5. 建议的会议记录模板
建议你每次和业务沟通时，按下面格式记录：
```text
问题编号：
问题主题：
业务回答：
是否已明确：是 / 否
当前默认口径：
是否影响需求文档：是 / 否
是否影响设计文档：是 / 否
需要补充材料：
备注：
```
---
## 6. 沟通优先级建议
如果时间有限，建议优先确认以下 8 个问题：
1. Q4 Demo 是否允许以第 1 章作为主演示材料
2. Q6 当前混档样例是否是刻意异常
3. Q7 哪些结论可自动判、哪些必须人工复核
4. Q10 “可直接报送级版式”的验收标准
5. Q12 新模板进入模板库后的确认机制
6. Q18 飞书群聊机器人希望如何触发任务
7. Q20 责任人如何定义
8. Q26 本次 Demo 的通过标准
---
## 7. 结论
这份问答清单的目标，不是把所有问题一次性问完，而是帮助你优先确认真正影响范围和验收的关键信息。
如果后续拿到新的业务回答，建议同步更新：
1. `docs/需求分析/0.需求重构总览与待确认事项.md`
2. `docs/需求分析/1.V1总需求文档.md`
3. 对应模块需求分析文档
4. 后续新增的设计文档