bf3d9c2c50
- ACTIVE_EXECUTION_BOARD_2026-06-16_OPTIMIZATION.md: 本轮前端审计/整改执行板 - 2026-06-16-optimization-program.md: 4 大工作流规划 - LOCAL_BROWSER_VALIDATION_2026-06-15.md: 本地浏览器验证报告与 Portal Step 5 历史问题 - test_requirements_rules_phase1.py: 规则 Phase1 配套测试
328 lines
8.6 KiB
Markdown
328 lines
8.6 KiB
Markdown
# Gaokao Volunteer System 优化计划（2026-06-16）
|
||
|
||
> **For Hermes:** Use `subagent-driven-development` to execute this plan by workstream. 先审计/设计，再实现，再验证，再文档收口。
|
||
|
||
**Goal:** 在不扩大范围失控的前提下，把志愿服务项目补齐到“规则可信、专业数据可信、CLI 可调度、规划与实现一致”的下一阶段可执行状态。
|
||
|
||
**Architecture:** 把任务拆成 4 条主线：规则规范、专业目录数据、CLI 能力层、规划/实现优化。每条主线先做现状审计与真相源整理，再进入实现。跨主线共享单一真相源，避免文档漂移和数据口径冲突。
|
||
|
||
**Tech Stack:** Python/FastAPI/SQLite/Hermes skills & CLI/静态 HTML portal/测试与文档体系。
|
||
|
||
---
|
||
|
||
## 一、总原则
|
||
|
||
1. **先审计后实现**：先确认当前已有能力、缺口、权威数据源、更新频率。
|
||
2. **权威源优先**：省级考试院/教育考试院、教育部/阳光高考/本科专业目录等官方或准官方源优先。
|
||
3. **数据与规则分层**：
|
||
- 规则规范 = 可验证约束
|
||
- 专业目录 = 事实数据集
|
||
- CLI = 调度入口
|
||
- 规划/实现优化 = 架构与流程治理
|
||
4. **每条主线都要可回归验证**：不是“收集一份材料”就算完成。
|
||
5. **先做最小闭环，再扩面**：先覆盖 2026 版核心省份 + 国家级专业目录，再考虑全面扩省与增量同步。
|
||
|
||
---
|
||
|
||
## 二、四条主线与验收目标
|
||
|
||
### Workstream A：2026 志愿规范/审计能力
|
||
|
||
**目标**
|
||
|
||
- 明确“全国通用规范 + 各省 2026 规则差异”能否被系统读取、验证、审计。
|
||
- 输出一套可由智能体/CLI 调用的规则审计能力。
|
||
|
||
**要回答的问题**
|
||
|
||
1. 当前仓库已有多少省份规则？哪些是 2026 版，哪些只是历史迁移？
|
||
2. 是否已有“全国通用规范”抽象层？
|
||
3. 是否已有可供程序调用的统一审计入口？
|
||
4. 哪些省份缺 2026 规则或规则证据链不完整？
|
||
|
||
**交付物**
|
||
|
||
- `docs/CURRENT_RULES_STATE_2026-06-16.md`
|
||
- `docs/RULES_SOURCE_OF_TRUTH.md`
|
||
- `docs/plans/rules-2026-gap-remediation.md`
|
||
- 规则能力清单（支持省份 / 不支持省份 / 证据来源 / 更新时间）
|
||
- 一个统一 CLI 入口（若现有 `gaokao-checker` 不足则补强）
|
||
|
||
**验收标准**
|
||
|
||
- 能列出各省 2026 规则覆盖矩阵
|
||
- 能对至少 1 份方案执行真实审计并输出结构化结果
|
||
- 明确“全国通用规则”和“省级差异规则”的边界
|
||
|
||
---
|
||
|
||
### Workstream B：2026 官方专业目录与近两年专业增减
|
||
|
||
**目标**
|
||
|
||
- 建立 2026 官方专业目录的真相源
|
||
- 补齐近两年高校/国家层面的新增、取消、停招、调整风险
|
||
- 防止系统输出过时或错误专业
|
||
|
||
**要回答的问题**
|
||
|
||
1. 当前项目里专业数据来自哪里？是否可追溯？
|
||
2. 能否拿到教育部/阳光高考/高校官方的专业目录与变更信息？
|
||
3. 数据粒度是“本科专业目录”还是“高校招生专业”级别？
|
||
4. 现有推荐/校验链路哪里在消费专业名称？是否会因过时专业导致错误建议？
|
||
|
||
**交付物**
|
||
|
||
- `docs/MAJOR_DATA_SOURCE_OF_TRUTH.md`
|
||
- `docs/MAJOR_DATA_RISK_MATRIX_2026.md`
|
||
- `docs/plans/major-catalog-2026-ingestion.md`
|
||
- 专业数据结构定义（目录字段、来源字段、版本字段、变更标签）
|
||
- 增量更新策略（年度全量 + 月度差异/人工校验）
|
||
|
||
**验收标准**
|
||
|
||
- 能说清当前专业库是否可信
|
||
- 至少形成一套 2026 目录接入方案
|
||
- 明确“国家目录”与“学校招生专业”两个层次的映射/差异
|
||
|
||
---
|
||
|
||
### Workstream C：系统 CLI 能力层（供智能体/运营/客服调用）
|
||
|
||
**目标**
|
||
|
||
- 给 Hermes/运营/客服智能体提供稳定 CLI 入口，能创建订单、查询订单、触发服务流程、调用审计/方案能力。
|
||
|
||
**要回答的问题**
|
||
|
||
1. 当前已有 CLI 有哪些？哪些只是脚本，哪些具备稳定契约？
|
||
2. 运营/客服最小需要哪些命令？
|
||
3. CLI 是直连本地代码、直连 DB，还是走 HTTP API？
|
||
4. 需要多大权限边界与日志审计？
|
||
|
||
**建议最小 CLI 范围**
|
||
|
||
- `create-order`
|
||
- `get-order`
|
||
- `list-orders`
|
||
- `submit-intake` / `update-order-status`
|
||
- `run-audit`
|
||
- `generate-plan` / `render-report`
|
||
- `doctor-payment-provider`
|
||
|
||
**交付物**
|
||
|
||
- `docs/CLI_CAPABILITY_PLAN.md`
|
||
- `docs/CLI_API_MAPPING.md`
|
||
- `docs/plans/agent-cli-surface.md`
|
||
- CLI 契约清单（输入/输出/错误码/审计日志）
|
||
|
||
**验收标准**
|
||
|
||
- 至少形成一套统一命令面设计
|
||
- 明确每个命令是包裹现有脚本还是新增正式入口
|
||
- 明确哪些命令给客服，哪些只给运营/管理员
|
||
|
||
---
|
||
|
||
### Workstream D：项目规划设计与实现优化
|
||
|
||
**目标**
|
||
|
||
- 统一产品规划、规则能力、专业数据、支付/交付、后台/CLI 的真相源，减少“能跑但不可持续”的实现漂移。
|
||
|
||
**要回答的问题**
|
||
|
||
1. 当前 PRD / 技术设计 / 实现 / 报告之间有哪些漂移？
|
||
2. 现有模块边界是否清楚？
|
||
3. 哪些是历史遗留脚本，哪些应提升为正式能力层？
|
||
4. 哪些风险会阻碍下一阶段（数据可信、客服协作、支付上线、运营交付）？
|
||
|
||
**交付物**
|
||
|
||
- `docs/CURRENT_STATE.md` 更新
|
||
- `docs/ARCHITECTURE_OPTIMIZATION_BOARD_2026-06-16.md`
|
||
- `docs/ROADMAP_ALIGNMENT_2026-06-16.md`
|
||
- 分阶段执行板（P0/P1/P2）
|
||
|
||
**验收标准**
|
||
|
||
- 明确当前架构哪些该保留、哪些该收敛
|
||
- 明确下一阶段优先级排序
|
||
- 文档真相源一致，不再让历史报告互相打架
|
||
|
||
---
|
||
|
||
## 三、执行顺序（建议）
|
||
|
||
### Phase 1：审计与真相源整理（先做）
|
||
|
||
1. A1 规则覆盖现状审计
|
||
2. B1 专业数据来源审计
|
||
3. C1 CLI 现状审计
|
||
4. D1 规划/实现漂移审计
|
||
|
||
### Phase 2：方案设计（基于审计结果）
|
||
|
||
5. A2 规则模型与统一审计入口设计
|
||
6. B2 专业目录数据模型与更新策略设计
|
||
7. C2 CLI 能力面设计
|
||
8. D2 总体架构/路线图对齐
|
||
|
||
### Phase 3：实现（按依赖顺序）
|
||
|
||
9. A3 规则审计能力补强
|
||
10. B3 专业目录数据接入/清洗/版本化
|
||
11. C3 CLI 实现与最小命令闭环
|
||
12. D3 文档/执行板/真相源收敛
|
||
|
||
### Phase 4：验证与交付
|
||
|
||
13. 规则审计真实案例验证
|
||
14. 专业目录抽样对账验证
|
||
15. CLI 端到端命令验证
|
||
16. 最终文档与执行板收口
|
||
|
||
---
|
||
|
||
## 四、子智能体分工建议
|
||
|
||
### 子智能体 A（规则与审计）
|
||
|
||
**职责**
|
||
|
||
- 审计各省规则与全国规则现状
|
||
- 盘点 2026 规则覆盖矩阵
|
||
- 提出统一审计入口设计
|
||
|
||
**输入**
|
||
|
||
- `rules/`
|
||
- `skills/gaokao-spec-checker/`
|
||
- `scripts/gaokao-checker`
|
||
- 相关 docs/plans
|
||
|
||
**输出**
|
||
|
||
- 规则覆盖矩阵
|
||
- 缺口报告
|
||
- 规则审计补强计划
|
||
|
||
---
|
||
|
||
### 子智能体 B（专业目录与数据真相）
|
||
|
||
**职责**
|
||
|
||
- 审计当前专业数据来源
|
||
- 设计 2026 官方专业目录接入方案
|
||
- 识别近两年专业增减风险点
|
||
|
||
**输入**
|
||
|
||
- `data/`
|
||
- `scripts/`
|
||
- 相关推荐/校验逻辑
|
||
- 官方数据源调研任务
|
||
|
||
**输出**
|
||
|
||
- 专业目录真相源文档
|
||
- 数据模型与更新方案
|
||
- 风险矩阵
|
||
|
||
---
|
||
|
||
### 子智能体 C（CLI 与智能体调用面）
|
||
|
||
**职责**
|
||
|
||
- 盘点现有脚本与 API
|
||
- 设计统一 CLI 面
|
||
- 定义智能体/运营/客服最小命令集
|
||
|
||
**输入**
|
||
|
||
- `scripts/`
|
||
- `admin/`
|
||
- `README.md`
|
||
- 现有订单/支付/交付入口
|
||
|
||
**输出**
|
||
|
||
- CLI 能力清单
|
||
- 命令契约
|
||
- 实现计划
|
||
|
||
---
|
||
|
||
### 子智能体 D（规划/架构/真相源收敛）
|
||
|
||
**职责**
|
||
|
||
- 对齐 PRD、ROADMAP、CURRENT_STATE、实现现状
|
||
- 输出架构优化与执行优先级
|
||
|
||
**输入**
|
||
|
||
- `product/`
|
||
- `docs/`
|
||
- `reports/`
|
||
- 当前代码结构
|
||
|
||
**输出**
|
||
|
||
- 当前状态与架构优化板
|
||
- 下一阶段 roadmap
|
||
- 统一真相源索引
|
||
|
||
---
|
||
|
||
## 五、主代理协调规则
|
||
|
||
1. 主代理先看 4 个子智能体的审计结论，不直接开始大规模实现。
|
||
2. 对冲突点做一次真相归并：
|
||
- 规则口径
|
||
- 专业数据口径
|
||
- CLI 调用口径
|
||
- 产品/实现边界
|
||
3. 再决定 Phase 2/3 的具体实现顺序。
|
||
4. 若你确认执行，默认采用：
|
||
- **先并行审计（A/B/C/D）**
|
||
- **后统一收敛**
|
||
- **再分批实现**
|
||
|
||
---
|
||
|
||
## 六、建议的第一批并行任务
|
||
|
||
### Batch 1（并行，纯审计）
|
||
|
||
- A：规则规范覆盖审计
|
||
- B：专业目录数据源审计
|
||
- C：CLI 能力面审计
|
||
- D：规划/实现漂移审计
|
||
|
||
### Batch 2（主代理收敛后）
|
||
|
||
- 形成单一执行板
|
||
- 给出实现优先级
|
||
- 选择先落地的 1~2 条主线
|
||
|
||
---
|
||
|
||
## 七、当前建议
|
||
|
||
**不要四条线一起直接开工实现。**
|
||
最优顺序是：
|
||
|
||
1. 先让 4 个子智能体并行做“审计与设计输入”
|
||
2. 我汇总成单一执行板
|
||
3. 你确认优先级后，再进入实现
|
||
|
||
这样能避免：
|
||
|
||
- 规则和专业数据口径冲突
|
||
- CLI 做出来后又被架构推翻
|
||
- 产品规划和实现再次漂移
|