HaHafeng
dc6b292308
ASL Tool 3 Development Plan: - Architecture blueprint v1.5 (6 rounds of architecture review, 13 red lines) - M1/M2/M3 sprint checklists (Skeleton Pipeline / HITL Workbench / Dynamic Template Engine) - Code patterns cookbook (9 chapters: Fan-out, Prompt engineering, ACL, SSE dual-track, etc.) - Key patterns: Fan-out with Last Child Wins, Optimistic Locking, teamConcurrency throttling - PKB ACL integration (anti-corruption layer), MinerU Cache-Aside, NOTIFY/LISTEN cross-pod SSE - Data consistency snapshot for long-running extraction tasks Platform capability: - Add distributed Fan-out task pattern development guide (7 patterns + 10 anti-patterns) - Add system-level async architecture risk analysis blueprint - Add PDF table extraction engine design and usage guide (MinerU integration) - Add table extraction source code (TableExtractionManager + MinerU engine) Documentation updates: - Update ASL module status with Tool 3 V2.0 plan readiness - Update system status document (v6.2) with latest milestones - Add V2.0 product requirements, prototypes, and data dictionary specs - Add architecture review documents (4 rounds of review feedback) - Add test PDF files for extraction validation Co-authored-by: Cursor <cursoragent@cursor.com>
92 lines
6.1 KiB
Markdown
92 lines
6.1 KiB
Markdown
# **📦 工具 3 开发计划敏捷拆分与三步演进路线图**
|
||
|
||
**制定人：** 资深架构师 & 敏捷教练
|
||
|
||
**核心思想：** 垂直切片（Vertical Slicing）。不要等所有功能做完再联调，而是先打通一条“最简且极陋”的全链路，再逐步往上叠加复杂度和体验。
|
||
|
||
**拆分目标：** 将原计划的 22 天长周期，拆分为 3 个可独立提测、独立 Demo 的 Milestone（里程碑）。
|
||
|
||
## **🎯 为什么原计划需要拆分？**
|
||
|
||
原计划的 Sprint 1（12天）虽然限制了只做“标准模板”，但它的**技术复杂度密度依然极高**。它要求后端同时搞定 PKB 跨模块 ACL、pg-boss Fan-out 扇出、MinerU 视觉大模型调用，还要前端搞定复杂的 SSE 状态水合、React Query 混编以及复杂的审核抽屉。
|
||
|
||
一旦前端的抽屉渲染出 Bug，后端的 Fan-out 扇出测试就会被阻塞；一旦 MinerU 接口超时，前端的进度条联调就无法进行。
|
||
|
||
**解决方案：按“业务价值”分为 3 个独立交付物（M1, M2, M3）。**
|
||
|
||
## **🚀 里程碑 1 (M1)：打通“骨架”与底层基建 (The Skeleton Pipeline)**
|
||
|
||
**🎯 核心目标：** 证明“从 PKB 拿数据 \-\> 后端 Fan-out 分发 \-\> 大模型盲提 \-\> 数据存入 DB”这条核心管线是通的。
|
||
|
||
**⏱️ 建议时间：** Week 1 (约 5-6 天)
|
||
|
||
**👁️ Demo 形态：** 用户点个按钮，系统能在后台静默跑完流程，数据库里能看到 JSON 数据。前端只有一个非常简陋的列表。
|
||
|
||
### **📦 包含的核心任务：**
|
||
|
||
1. **\[后端\] 基础设施与防腐层：** 建立 Prisma 表、写好 PkbExportService (PKB侧) 和 PkbBridgeService (ASL侧)。
|
||
2. **\[后端\] Fan-out 调度核心：** 跑通 Manager Job 派发 10 个 Child Job 的逻辑。
|
||
3. **\[后端\] 纯文本降级提取 (Mock MinerU)：** ⚠️ *关键妥协*。在 M1 阶段，**暂时不接 MinerU**，直接用 PKB 里现成的 extractedText（纯文本）加上写死的“标准 RCT Schema”喂给 DeepSeek。
|
||
4. **\[前端\] 极简进度与列表：** 完成 useTaskStatus 轮询和极简的数据列表（不带抽屉，只看状态是否变成 Completed）。
|
||
|
||
**🌟 M1 的价值：**
|
||
|
||
彻底排除了最容易出错的“并发死锁”和“跨模块读写”问题。后端基建稳固后，可以甩开膀子在 M2 加特性。
|
||
|
||
## **🎨 里程碑 2 (M2)：血肉丰满与人机交互 (The HITL Workbench)**
|
||
|
||
**🎯 核心目标：** 接入视觉大模型解决准确率问题，完成前端最复杂的人机协作（HITL）双联屏抽屉。
|
||
|
||
**⏱️ 建议时间：** Week 2-3 (约 8-9 天)
|
||
|
||
**👁️ Demo 形态：** 完整的 V1 体验。前端有漂亮的打字机日志、右侧能滑出包含 Quote 高亮的比对抽屉，并能导出 Excel。
|
||
|
||
### **📦 包含的核心任务：**
|
||
|
||
1. **\[后端\] 接入 MinerU 表格引擎：** 将 M1 中的纯文本提取，升级为 纯文本 \+ MinerU 高保真 HTML，并引入 Clean Data OSS 缓存机制。
|
||
2. **\[前端\] SSE 终端日志：** 补齐 ProcessingTerminal 组件，实现 SSE 状态水合。
|
||
3. **\[前端\] 智能审核抽屉 (核心战役)：**
|
||
* 完成 ExtractionDrawer。
|
||
* 采用 Collapse 折叠面板进行性能优化。
|
||
* 实现 \[强制认可\] 和 \[手动覆写\] 交互闭环。
|
||
* 签名 URL 懒加载防过期。
|
||
4. **\[后端\] 算法辅助：** 上线 fuzzyQuoteMatch 模糊匹配与置信度算法。
|
||
5. **\[全栈\] 导出闭环：** 完成标准宽表 Excel 导出。
|
||
|
||
**🌟 M2 的价值：**
|
||
|
||
这个阶段结束时，工具 3 已经是一个“完全可用且高度可用”的产品了。它虽然不能自定义字段，但用来提取标准 RCT 文献已经足够惊艳。
|
||
|
||
## **🧠 里程碑 3 (M3)：注入灵魂的动态引擎 (The Dynamic Template Engine)**
|
||
|
||
**🎯 核心目标：** 让系统从“死表单”变成真正的“动态模板引擎”，支持各专科自定义。
|
||
|
||
**⏱️ 建议时间：** Week 4 (约 5-6 天)
|
||
|
||
**👁️ Demo 形态：** 前端有炫酷的“配置模板”弹窗，用户能随心所欲添加“糖尿病比例”等字段，AI 能听懂并精准提取。
|
||
|
||
### **📦 包含的核心任务：**
|
||
|
||
1. **\[前端\] 模板设计器：** 完成 Step 1 的系统基座选择器和“添加自定义字段” Modal 交互。
|
||
2. **\[后端\] 动态 Schema 组装：** DynamicPromptBuilder 升级，支持将用户的自定义字段动态合入 JSON Schema。
|
||
3. **\[后端\] 安全护栏：** 针对用户的自定义 Prompt，加上严格的 BEGIN/END 隔离区和防逃逸提示词，防止大模型被注入攻击。
|
||
4. **\[前端\] 抽屉动态渲染兼容：** 审核抽屉的 UI 能够自适应展示用户新增的 Custom 字段（带蓝色 ⚡ 标签）。
|
||
5. **\[QA\] 自动化护城河：** 补充 Playwright E2E 测试脚本，封版。
|
||
|
||
**🌟 M3 的价值：**
|
||
|
||
赋予了产品极高的商业扩展性和商业壁垒。
|
||
|
||
## **📊 拆分后的研发管理优势**
|
||
|
||
| 维度 | 原计划 (22天大版) | M1/M2/M3 拆分版 |
|
||
| :---- | :---- | :---- |
|
||
| **联调阻塞** | 高。前端等后端写完，后端等算法调完。 | **极低**。M1 让前后端通过简单的 JSON 走通了握手；M2 前端画抽屉时，后端可以安心调 MinerU。 |
|
||
| **风险暴露** | 晚。最后一周才发现 pg-boss 会重试死锁。 | **极早**。M1 第一周就会用大量并发测试扇出模式，逼出所有分布式 Bug。 |
|
||
| **团队士气** | 疲惫。一个月才能看到最终结果。 | **高昂**。每周五都能组织一次 Demo，看着产品像搭积木一样变强。 |
|
||
| **上线灵活性** | 只能全量上。 | 如果项目赶进度，甚至可以只把 M1+M2 拿去给真实医生试用，M3 作为 v2.1 版本后续迭代发布。 |
|
||
|
||
## **👨💻 给研发负责人的执行建议**
|
||
|
||
1. **并行开发池 (Parallel Tracks)：** M1 期间，前端其实比较闲（因为只有个简单列表）。此时应该让前端核心骨干提前启动 M2 中 ExtractionDrawer（抽屉）的静态 UI 开发（使用 Mock JSON），这样 M2 联调时会极快。
|
||
2. **重防 M1，重攻 M2：** M1 是防守（架构防腐、防并发死锁）；M2 是进攻（让用户觉得 AI 抓取极其准确、交互极其顺滑）。 |