08e3fe7eff
- 资质库（FR-M6-08）：增删改、证书扫描件（PDF/JPG/PNG，企业级密钥加密、签名下载）、 late_for 按进行中项目的投标截止日提醒、审计；前端资质库页和对话框，侧栏入口 - 资质匹配（FR-M3-05）：证书类别词表（16 类，产品证书、人员证书不进匹配）， QUAL.EXPIRED / LEVEL_LOW / NOT_COVERED；投标文字层按清单项定级，只有资质库记录的降一级， 出处显示「依据：资质库记录」（查标页、报告模板 v2）；一类证书一个问题；评分项不逐条找响应的也查 - 响应错位规则不再把资质表的证书名称格当成照抄的要求 - 评测：qual_defects.py 派生资质情况表，D12 3/3、D18 2/2、规矩的资质表 0 误报；开发集不退化 - 决策 QL1–QL7；方案和落地记录 docs/architecture/qualification-plan.md，评测 check-eval.md §13 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
225 lines
34 KiB
Markdown
225 lines
34 KiB
Markdown
# AGENTS.md — 标博士（bid-doctor）
|
||
|
||
本文件是所有 AI 编码代理（Claude Code、Codex、Cursor 等）的共用项目说明。`CLAUDE.md` 只做引用，**请只改本文件**。
|
||
|
||
## 项目概况
|
||
|
||
- **产品名**：标博士（代码仓库名 `bid-doctor`）
|
||
- **一句话定位**：站在**投标方**一侧，贯穿「寻标 → 读标 → 写标 → 查标 → 投标」全生命周期的 AI 辅助工具。产品是「副驾驶」，不是「自动驾驶」。
|
||
- **口号**：标博士，你的AI投标专家（固定写法，见决策 B5）。
|
||
- **当前阶段**：需求分析、品牌与 VI、产品界面设计规范 v0.2、MVP 原型 v0.2、技术架构 v0.3（含物理数据模型、接口契约）已完成；工程骨架已搭好，进入实现阶段。工作流：需求分析 ✅ → 主题 / 品牌设计 ✅ → 产品界面设计规范 ✅ → 原型设计 ✅ → UI 设计 ✅ → 技术架构 ✅ → 实现（进行中）→ 测试。
|
||
- **需求来源**：当前有效版本是 `docs/招投标AI工具PRD-v0.9.1.html`（`docs/招投标AI工具PRD.html` 是 v0.9 原稿，保留作对照），再加上 `docs/decisions.md` 和 `docs/analysis/` 里已确认的 MVP 细化需求。三者冲突时：decisions.md > analysis > PRD。发现矛盾或缺失时，记录问题并向用户确认，不要自行假设。
|
||
- **工作语言**：文档、界面文案、提交说明默认使用简体中文；代码标识符、文件名使用英文。
|
||
|
||
## 产品结构速览
|
||
|
||
| 模块 | 内容 | MVP（P0） |
|
||
|---|---|---|
|
||
| M1 商机筛选 | 标讯聚合、订阅、AI 匹配打分、招标计划采集 | 否（P1/P2） |
|
||
| M2 招标文件解读 | 上传解析（PDF/Word/OCR）→ 资格 / 废标条款 / 评分点 / 关键日期结构化提取 → 原文回链 → 生成项目检查清单 | **是** |
|
||
| M3 废标风险检查（楔子） | 响应完整性、形式要件、资质匹配检查 → 人工逐项确认 → 检查报告 PDF 导出 | **是** |
|
||
| M4 标书生成 | 目录框架、分章初稿、知识库填充、偏离表、Word 导出 | 否（V1） |
|
||
| M5 查重雷同 | 自有历史查重、多份互查、雷同风险报告 | 否（V1/V2，合规边界条款为 P0） |
|
||
| M6 基础平台 | 项目工作台、额度计量与账单（P0）；协作权限、资产库（P1）；私有化（P2） | 部分 |
|
||
|
||
**MVP 范围** = M2 全部 P0 + M3 全部 P0 + M6 项目工作台 + 额度计量 + 免费版 / 专业版。需求分析阶段确认新增：多包 / 多标段、最小资质库、报价形式检查、补遗追加（简化版）、最小运营后台。完整清单见 `docs/analysis/03-functional-requirements.md`。
|
||
|
||
**首发行业是 IT 集成**（D1）。IT 集成项目多数走**政府采购体系**（《政府采购法》、财政部令第 87 号），少数走招标投标体系。两套体系的术语不一样（投标无效 / 否决投标）、无效情形也不一样，产品要先识别项目属于哪一套，再套用对应规则。详见 `docs/analysis/05-it-integration-domain.md`。
|
||
|
||
**核心数据设计**：M2、M3、M4、M5 共用同一份「**项目检查清单**」数据结构——解读阶段提取的要求项，在写标阶段是生成约束，在投前阶段是核对项。任何建模与架构设计都必须围绕它展开。
|
||
|
||
**项目状态流**：跟进中 → 编制中 → 已检查 → 已递交 → 已归档。
|
||
|
||
## 必须遵守的产品红线
|
||
|
||
这些约束贯穿设计、文案与实现，评审时逐条核对：
|
||
|
||
1. **辅助定位四件套**（PRD 4.1）：辅助生成（产出标注为初稿）、检查清单（逐项列出、含原文出处）、人工确认（关键节点须逐项确认）、全程留痕（谁在何时确认了什么，可审计）。
|
||
2. **可复核**：每条 AI 提取 / 检查结论必须可回溯到原文（页码 + 原句高亮）；无出处的结果只能进「待确认」区或降级为「提示」。
|
||
3. **禁用绝对化表述**：界面、协议、营销文案中禁止「保证不废标」「零废标」「100% 通过 / 准确」等说法；M3 只能称「辅助检查 / 风险提示」，报告首页须写明检查覆盖范围。
|
||
4. **不阻断用户**：「致命」项未处理完时项目状态保持「未就绪」，但不阻止导出——决定权在用户。
|
||
5. **不编造**：资质、业绩、知识库引用只能来自用户自有数据；缺失处用占位符提示补录。胜率等数据不足时宁可不展示。
|
||
6. **报价数字永不由系统生成或建议**，只提供结构与填充位。
|
||
7. **签章检查只做「位置与有无」提示**，不做真伪鉴定，界面明示。
|
||
8. **M5 只服务投前自查**：不得支持或宣传「帮多家投标人去雷同」等围串标规避用途。
|
||
9. **额度即货币**（PRD 4.3）：所有扣点规则可见、可查、可预警；解析失败 / 超时 / 系统异常不扣点；额度绑定账号与企业主体，不可转让。
|
||
10. **数据敏感**：传输与存储加密、按租户隔离、支持自助删除；SaaS 数据不用于训练公共模型。
|
||
|
||
### 政策引用的「双层口径」
|
||
|
||
先按项目所属的法律体系区分，再在体系内区分现行层和草案层（PRD v0.9.1 1.5）。政府采购项目的异常低价无效（87 号令第六十条）是**现行规定**，不能写成草案层，也不能挂「政策预警」标签。招标投标体系里引用政策时，严格区分两层，不得混同：
|
||
|
||
- **现行依据层**：发改法规〔2026〕195 号《关于加快招标投标领域人工智能推广应用的实施意见》——现行有效，但属政策指导文件而非法律。
|
||
- **草案强化层**：《招标投标法》修订草案——**尚在审议、未施行**，引用时必须标注。「政策预警」标签只用于草案层（如异常低价否决）。
|
||
- 195 号文「2026 年底全覆盖」只指招标文件检测、智能辅助评标、围串标识别三个场景；本产品的楔子场景对应 2027 年底全国推广，对外不得混写。
|
||
|
||
## 待决策事项（PRD 第 12 章）
|
||
|
||
开工涉及以下事项时先向用户确认，不要默认：
|
||
|
||
- ~~**D1 首发行业**~~：✅ 已定为 IT 集成（2026-11-02，见 `docs/decisions.md`）。IT 集成项目多数走政府采购体系，术语和规则见 `docs/analysis/05-it-integration-domain.md`。
|
||
- **D2 专业版额度数字**：解析 500 / 生成 300 为建议值，待成本实测定版。
|
||
- **D3 M1 商机数据来源**：自建抓取 vs 第三方接口（V2 前决策）。
|
||
- **D4 企业版首单策略**：是否提前准备私有化部署包。
|
||
|
||
需求分析阶段的待确认事项 G1–G10 已全部确认，见 `docs/decisions.md` A1。
|
||
|
||
## 技术约束（已定）
|
||
|
||
- **大模型**（T1）：只用国内云端的国产大模型，数据不出境。按场景路由：多模态（扫描件、签章）/ 快速 / 深度思考。业务代码只声明需要什么能力，不直接写死供应商和模型；每个 AI 任务都要记下模型和提示词版本。
|
||
- **后端语言**（T2）：Python 单语言，业务接口和后台任务是同一套代码、两种进程。
|
||
- **桌面客户端**（T3）：连服务端的客户端外壳，界面和网页版同一套；前端从第一天起守住 `docs/architecture/architecture.md` §5.2 的约束。
|
||
- **部署**（T4）：同一批镜像，两种编排（Docker Compose / Helm）；SaaS 内测期用 Compose，商用后切到托管 K8s。
|
||
- **云厂商**（T5）：暂不定，只依赖 PostgreSQL、S3 兼容的对象存储、OpenAI 兼容的模型接口。
|
||
- **已确认的选型**（AR1–AR3、AR5–AR9）：模块化单体；前端用 Vue 3 + TypeScript + Vite 单页应用；数据库 PostgreSQL；文件存储用 S3 协议 + 本地磁盘驱动；单一仓库。详见 `docs/architecture/architecture.md` 第 11 节。
|
||
- **Valkey**（AR4）：只存丢了也没关系的数据（限速、验证码、推送、缓存）；权威数据（含会话、任务队列）都在 PostgreSQL。
|
||
- **UI 组件**（AR10）：不引入带样式的 UI 框架（如 Element Plus），视觉自己写，样式只来自 `tokens.css`；复杂交互用无样式组件库 Reka UI 打底；不用 Tailwind。
|
||
- 构建、运行、测试命令和代码目录见下方「工程」一节。
|
||
|
||
## 工程
|
||
|
||
骨架见技术架构 §13。后端 Python 3.12+（uv workspace），前端 Vue 3 + Vite（pnpm workspace）。
|
||
|
||
```
|
||
server/ 后端：api 和 worker 是同一个包、两种进程（bid-doctor api | worker | migrate）
|
||
src/bid_doctor/
|
||
core/ 配置、数据库与租户事务、错误码、加密、对象存储、队列、事件流、权限点
|
||
identity/ billing/ project/ document/ checklist/ ai/ audit/ notification/ 业务模块（架构 §3.2）
|
||
app.py worker.py cli.py
|
||
migrations/ Alembic；sql/0001_baseline/ 是 data-model 的建表脚本，按模块拆分
|
||
tests/ 集成测试（真实 PostgreSQL + 行级安全策略）和单元测试；fixtures/ 是虚构的小样例
|
||
apps/web/ 用户端单页应用
|
||
packages/api-client/ 由 docs/architecture/openapi.yaml 生成的类型 + 客户端（不手写接口类型）
|
||
prompts/ 带版本号的提示词（已发布的版本不再修改）
|
||
deploy/compose/ Docker Compose；deploy/docker/ 镜像
|
||
```
|
||
|
||
常用命令（都在仓库根目录执行）：
|
||
|
||
| 做什么 | 命令 |
|
||
|---|---|
|
||
| 装依赖 | `uv sync` 和 `pnpm install --ignore-scripts` |
|
||
| 起依赖（PostgreSQL、Valkey、Gotenberg） | `docker compose -f deploy/compose/compose.yaml up -d postgres valkey gotenberg` |
|
||
| 建表 / 升级数据库 | `cd server && ../.venv/bin/bid-doctor migrate` |
|
||
| 起后端 | `cd server && ../.venv/bin/bid-doctor api`（:8009），另开一个终端 `../.venv/bin/bid-doctor worker` |
|
||
| 起前端 | `pnpm dev`（:5173，`/api` 代理到 :8009）。dev 环境短信验证码固定是 `000000` |
|
||
| 后端检查 | `cd server && ../.venv/bin/ruff check src tests migrations && ../.venv/bin/ruff format --check src tests migrations && ../.venv/bin/pyright && ../.venv/bin/lint-imports && ../.venv/bin/pytest -q` |
|
||
| 前端检查 | `pnpm typecheck && pnpm build` |
|
||
| 改了 openapi.yaml 之后 | `pnpm gen:api`，重新生成的 `schema.d.ts` 一起提交（CI 会比对） |
|
||
| 全部用容器跑 | `docker compose -f deploy/compose/compose.yaml --profile app up -d --build` |
|
||
|
||
约定：
|
||
|
||
- 配置只走 `BD_` 前缀的环境变量（`.env.example`）；`BD_ENV=prod` 时检测到默认密钥、dev 短信、假模型会拒绝启动。
|
||
- 模型默认用确定性的假模型（`BD_AI_PROVIDER=fake`），测试和 CI 不调用真实模型。
|
||
- 数据访问都在 `tenant_tx(ctx)` 里；表结构以迁移为准，ORM 模型不声明外键，写入有先后时要自己 `flush`。
|
||
- 测试样例只能用虚构内容：真实招标文件样本不进 git（`samples/tenders/README.md`）。
|
||
|
||
## 品牌与设计资产（已定）
|
||
|
||
设计文档索引见 `docs/design/README.md`。做界面、文案、物料时先看这几条：
|
||
|
||
- **视觉方向**：A「校样」。蓝铅笔 #2F5BD3 = AI 标注 / 出处；墨 #1D2733 = 正文 / 人工确认。
|
||
- **界面风格**（U5，设计规范 v0.2）：
|
||
- 定稿样张是 `docs/design/ui-demo/explore/workbench-d5.html`。
|
||
- 页面白色主调，浅灰从墨色派生（页面底 #F8F8F9）；校样纸 #F5F6F3 只留在品牌色板里，不再作页面底色。
|
||
- 墨色渐变窄侧栏（96px，不折叠）。
|
||
- 圆角三档：标签 6、控件 8、卡片 12。
|
||
- 只用功能图标，少写说明。
|
||
- **两种红色不能混用**：印章红 #D9291C **只用于 logo**；致命红 #C4122F **只用于界面里的致命问题**。
|
||
- **界面规范**：`docs/design/design-system.md`；写界面代码时颜色、字号、间距只用 `docs/design/system/tokens.css` 里的变量。
|
||
- **字体**（均为 OFL，可免费商用）：思源宋体（标题、字标）、思源黑体 / 系统黑体（界面正文）、Libre Caslon（英文品牌字）、Barlow Semi Condensed（数字）。
|
||
- **Logo**：正式文件在 `docs/design/logo/svg/`、`png/`。要改 logo，改 `docs/design/logo/scripts/logo_lib.py` 里的参数，再运行 `scripts/build_assets.sh`，**不要手改 SVG**。工具环境（`logo/.work/`）不进 git，搭建方法见 `logo-spec.md` 第 6 节。
|
||
- **VI 手册**：`docs/design/vi/标博士-VI视觉识别规范-v1.1.pdf`，源文件是同目录的 `vi-manual.html`，重新导出方法见 `docs/design/vi/README.md`。logo 或口号变化后要同步重出。
|
||
- **红线**：logo 不能当作「通过 / 合格」章用在报告或任何结论上。
|
||
|
||
## 目录约定
|
||
|
||
```
|
||
docs/
|
||
招投标AI工具PRD.html # PRD v0.9 原稿（只读）
|
||
招投标AI工具PRD-v0.9.1.html # 当前有效版本；后续修订继续出新版本文件
|
||
analysis/ # 需求分析：用户旅程、用例、数据模型草案、样本分析
|
||
design/ # 品牌与设计（索引见 design/README.md）
|
||
brand-strategy.md # 品牌策略：定位、性格、口号、语气
|
||
brand-directions.html# 三个视觉方向对比（已选 A 校样）
|
||
logo/ # logo 正式资产、规范、构建脚本、历史版本
|
||
vi/ # VI 视觉识别规范（PDF + HTML 源文件）
|
||
design-system.md # 产品界面设计规范：原则、颜色、字体、组件、文案
|
||
system/ # tokens.css（设计变量）、components.css（组件样式）、components.html（预览）
|
||
prototype/ # MVP 可点击原型（HTML，说明见 prototype/README.md）
|
||
architecture/ # 技术架构、ADR（docs/architecture/adr/NNNN-*.md）
|
||
decisions.md # 产品与工程决策记录（含 D1–D4 的拍板结果）
|
||
samples/
|
||
tenders/ # 真实招标文件样本（README 是清单；原始文件不进 git，用 fetch.sh 获取）
|
||
```
|
||
|
||
以上目录按阶段推进时再创建，不要提前建空目录。代码目录见「工程」一节。
|
||
|
||
## 参考开源项目（opensource-ref/）
|
||
|
||
`opensource-ref/` 放的是别人的开源项目，只供用户本人对照参考，**不属于本项目**，已在 `.gitignore` 中忽略。
|
||
|
||
- `opensource-ref/bid-engine/`：标擎 BidEngine（github.com/panviviplus/bid-engine），招投标 AI 工作台，Go + Next.js。
|
||
- **不参与本项目的编码、文件查找和逻辑**：搜索代码、排查问题、设计架构、写需求时都排除这个目录；不要引用、复制或改写其中的代码、提示词、SQL 和文案，也不要把它的设计当作本项目的既定做法。用户明确要求「看一下参考项目」时才去读，读到的内容只作为讨论素材，结论仍以本项目的 decisions.md / analysis / PRD 为准。
|
||
- **许可证**：PolyForm Noncommercial 1.0.0，只允许非商业用途；本产品是商业产品，其代码不能进入本项目。
|
||
- 已清理掉其中与本项目无关的工程化文件（嵌套的 .git、.gitignore、.gitkeep、.DS_Store、它自带的 AGENTS.md、ESLint / Prettier 配置、第三方库的 CI 配置）；保留了运行它所需的 .env*、.npmrc、Dockerfile、docker-compose 和启动脚本，以及 LICENSE / NOTICE。
|
||
|
||
## 工作方式
|
||
|
||
- 每个阶段产出落到 `docs/` 对应目录，并在本文件「当前进度」中更新一行。
|
||
- 用户确认的决策写入 `docs/decisions.md`（日期 + 决策 + 理由），不要只留在对话里。
|
||
- 设计与文案产出提交前，对照上方「产品红线」自查一遍。
|
||
|
||
## 当前进度
|
||
|
||
- 2026-11-02：项目初始化，建立 AGENTS.md / CLAUDE.md。
|
||
- 2026-11-02：D1 定为 IT 集成；完成 MVP 需求分析（`docs/analysis/`）。
|
||
- 2026-11-02：G1–G10 全部按建议确认；出 PRD v0.9.1（补充政府采购体系）；大模型策略定为国产云端模型 + 按场景路由（T1）。
|
||
- 2026-11-02：从苏采云公开渠道收集了 10 份 IT 集成采购文件（`samples/tenders/`），分析结论见 `docs/analysis/07-sample-findings.md`。关键结论：实质性条款不能只认 ★（有的用斜体 + 下划线标注，解析时必须保留文字格式）；文件扩展名不可信；报价限价有三层。
|
||
- 2026-11-02：**品牌与 VI 完成**。
|
||
- 品牌策略：定位「投前审校员」，口号「标博士，你的AI投标专家」（B5）；视觉方向选 A「校样」（B1）。
|
||
- Logo v5.1：AI 生成的白文印「标」+ 思源宋体 SemiBold / Libre Caslon 字标，比例 H2、英文视觉内缩 C2（B3、B4）。中间经历的 v1–v4（Codex 精细化、SVG 程序化模拟印泥）归档在 `docs/design/logo/archive/`，教训见 `logo/seal-research.md`：印泥质感本质上是位图，不要再用 SVG 程序化模拟。
|
||
- VI 视觉识别规范 v1.1（A4 横版 24 页，含名片、信封、信纸、报告、演示文稿、网站等应用），见 `docs/design/vi/`。
|
||
- 2026-11-02：产品界面设计规范 v0.1（`docs/design/design-system.md` + `system/tokens.css` + `system/components.html`）。要点：红色只给致命问题（表单错误、额度、截止临近都用赭色）；问题级别靠实心 / 描边 / 无框区分，不只靠颜色（色弱模拟验证过）；字体全部自托管；出处是固定组件。U1–U4 全部按建议确认（只做桌面 Web、图标用 Lucide、致命问题确认无误也要写说明）。
|
||
- 2026-11-02：MVP 可点击原型 v0.1（`docs/prototype/`，13 个页面，覆盖 J1–J5）。中保真，直接用设计规范的组件；查标页可逐条处理、键盘操作、看原文。原型阶段的 P1（24 小时免扣从上一次扣点的检查算起）、P2（人工核对勾选按项目保存）已按建议确认。
|
||
- 2026-11-03：应用图标改为印泥铺满、不留白边，圆角按 Apple 连续曲率圆角由系统裁（B6）；VI 手册 v1.1 第 22 页改为 iPhone 18 Pro 主屏幕模拟（`docs/design/vi/mockup/`，Apple 素材不进 git，机身需本人同意 Apple Design Resources 许可后放入）。
|
||
- 2026-11-03：分析参考项目标擎 BidEngine 的架构、提示词和模型路由，整理出可参考的做法和避坑清单（`docs/architecture/ref-bid-engine-analysis.md`），留给技术架构阶段用。
|
||
- 2026-11-03：技术架构设计 v0.2（`docs/architecture/architecture.md`）。T2–T5 已确认：Python 单语言、桌面端做客户端外壳、SaaS 先 Compose 后 K8s、云无关。之后确认了 AR1–AR3、AR5–AR9，前端改为 Vue 3；AR4 复议后改为引入 Valkey（已确认）；AR10 定为不引入带样式的 UI 框架，用 Reka UI 打底。选型全部确认。编码前先做技术验证 S1–S4。
|
||
- 2026-11-03：种子用户走查结束，没有问题。进入 UI 精修前先做 UI demo（`docs/design/ui-demo/`，6 个页面）：控件、表单、卡片、列表，以及工作台、读标两个组合页；新增组件清单和待定问题 Q1–Q12 见其 index。
|
||
- 2026-11-03：技术验证 S1–S4 完成（`docs/architecture/tech-validation.md`，代码在 `spikes/`），四项都可行。要点：Word 转 PDF 要修正 WPS 字体字符集并改用行高调整过的字体；格式识别不需要 Docling；表格内切句要改进；DeepSeek 抽取要加第三道依据校验和规则兜底，单项抽取每份约 0.15 元。FR-M2-05 和 FR-M2-06 的目标值按建议确认（TV1）。
|
||
- 2026-11-03：UI 风格定稿（U5）。工作台经过六轮方案（`docs/design/ui-demo/explore/`），定为 D5：白色主调、墨色渐变窄侧栏、透明顶栏、圆角三档、只用功能图标、少写说明。设计规范和 `tokens.css` 升到 v0.2。
|
||
- 2026-11-03：UI demo 全部按 v0.2 重刷（控件、表单、卡片、列表、工作台、读标）。Q1–Q12 全部按建议确认，写入设计规范；各页的共用问题收回到 `components.css`、`demo.css`、`demo.js`。Q13（流水记 0 点的「免扣」行）、U 键（撤销当前条）按建议确认。
|
||
- 2026-11-03：MVP 原型 13 页全部按 v0.2 重刷：框架、项目头和标签页、对照布局、问题处理交互与 UI demo 一致，业务流程和红线内容不变。报告页脚与免责声明改为「本报告为辅助检查结果，仅供投标前自查参考」，规范 §7.17 和 FR-M3-09 同步，消除了「保证」字样。
|
||
- 2026-11-03：技术架构升到 v0.3，新增 §3.14。团队版、企业版、飞书 / 企业微信登录都是以后的版本，早期不做；MVP 的表结构先按多人、多登录方式建：人 / 登录方式 / 成员身份分三层，项目成员表和统一的权限检查点先建好，以后接入不用重构（AR11、AR12）。
|
||
- 2026-11-03：VI 手册第 20 页报告页脚去掉「保证」字样，改为与设计规范 §7.17 一致的「辅助检查结果，仅供投标前自查参考」，PDF 已重出。
|
||
- 2026-11-03：物理数据模型 v0.1（`docs/architecture/data-model.md` + `schema-draft.sql`，40 张表，PostgreSQL 16 上 16 项行为测试通过）。DM1–DM7 全部按建议确认：句子放对象存储不进库、外键都带租户、每个项目一把数据密钥、手机号不存明文、规则问题可以只挂规则编号、清单新增「报价」类别。
|
||
- 2026-11-03：接口契约 v0.1（`docs/architecture/api-design.md` + `openapi.yaml`，OpenAPI 3.1，64 个路径、81 个操作），覆盖 MVP 原型 13 页的主流程，运营后台另行定义。API1–API5 全部按建议确认：骨架搭好前以 `openapi.yaml` 为准，之后以 FastAPI 生成的快照为准；事件流用 fetch 读；异地登录确认后挤掉旧设备；扣点说明和实际不一致时拒绝、不扣点；报告后台生成。
|
||
- 2026-11-03：工程骨架完成（分支 `feat/engineering-skeleton`）。「上传 → 解析 → 显示清单」最小链路在真实样本 S02、S06 和虚构样例上跑通：分片上传、按文件头识别格式、Gotenberg 转 PDF、文字层与稳定句子编号、实质性条款抽取（假模型 + 三道校验 + 标注类规则兜底）、并入清单；额度预扣 / 结算 / 退回、行级安全策略、对象加密都有测试。后端 30 个测试、pyright 严格模式、import 规则全部通过；前端 5 个页面按设计规范 v0.2 实现，类型检查和构建通过。搭建中的调整记在架构 §13（SK1–SK8），SK1、SK2 待确认。
|
||
- 2026-11-03：测试环境接上真实模型（DeepSeek，配置在不进 git 的根目录 `.env`）。读标补齐五类清单和项目基本信息的抽取，修了国动样本暴露的 4 个问题（标注规则碎片、页码混入与跨页拆分、无效写法漏认、上级标题下的无效情形），见架构 §13 SK9、SK10。
|
||
- 2026-11-03：读标可以走完一份文件：待确认区采纳 / 补上出处后采纳 / 修改后采纳 / 丢弃，正式清单修改、补出处、删除恢复、人工新增、修改记录，确认清单生成不可变版本；右侧 pdf.js 原文查看器点出处跳页、按坐标框高亮原句，选句补出处。实现约定见 `docs/architecture/api-design.md` §10。
|
||
- 2026-11-03：审计待确认区：多数是好结果被校验误拦，根源在输入（表格框线被认成下划线）、提示词（要求逐项拆开）和模型没守规则。规则只修真正的缺陷，不迁就模型的错误输出；提示词出新版本（引文复制整句、并列不拆、跨页只引上一行，除实质性条款外输入改成纯文本）。国动的待确认 46 → 4，S02 17 → 13，S06 174 → 57。见架构 §13 SK11；离线评测工具 `evals/run_extract.py`。
|
||
- 2026-11-03：请 Fable 做顾问深读参考项目的解析流水线（`docs/architecture/ref-bid-engine-analysis.md` §5），采纳五项：待确认记原因码、分块重叠和截断后对半重跑、项目基本信息逐项表态、占位符不算值、提示词规则对应原因码。发现并修复了模型输出被截断时整块条目悄悄丢失的问题。见架构 §13 SK12。
|
||
- 2026-11-03：抽取模型定为只用 DeepSeek Flash，不再对比 Pro 和思考模式，效果靠规则和提示词优化（`docs/decisions.md` M1）。
|
||
- 2026-11-03：S01–S10 标注集评测 v1（`docs/architecture/extract-eval.md`，工具和标注集在 `evals/`）。1,829 个标注单元由 AI 标注、逐条裁定，未经人工复核。标注类实质性条款召回 99.7% 达标；写明无效类召回 85.4%、实质性条款准确率 87.8%、资格条件准确率 38.4% 不达标，主因是规则缺陷（合并时待确认条目被并进正式条目、表后「上述……否则无效」说明认不出、模型提前收尾的静默丢失），修复清单 F1–F8 见该文 §4。每份文件实测约 1.4 元。还发现产品转换流程缺 WPS 旧版 DOC 预处理（S07 正文全是乱字）。
|
||
- 2026-11-03：按评测修复 F1–F8，口径 Q1–Q4 按建议确认（`docs/decisions.md`）；请 Fable 当顾问审读修复，改了它指出的 7 个问题。修掉了几个确定的缺陷（合并时假致命、输出临近上限的静默丢失、WPS 旧版 DOC 乱码、表格串行）；报告分数是在同一批样本上调、又用同一批评的，请 Fable 评估后确认有过拟合：只按人工标注算，实质性条款准确率 72%、标注类召回 98.9%，泛化未测。
|
||
- 2026-11-03：读标召回率优化暂停。现状、遗留问题（含泛化风险）和下一步整理在 `docs/architecture/extract-status.md`；后续专项优化先建留出集（多省份、招标投标体系、扫描件）并人工标注。
|
||
- 2026-11-04：查标（M3）实现计划 v0.2（`docs/architecture/m3-plan.md`）。请 Fable 做顾问深读参考项目的查标实现（`ref-bid-engine-analysis.md` §6），对照读标教训复评；C1–C11、SK1、SK2 全部按建议确认（`docs/decisions.md`）。要点：先建评测集再写规则，金标准是虚构投标文件的响应清单；每条清单项都留带证据的结论（新增 `check_item_result`）；成本靠按章节打批、硬预算和复查复用结果控制；认不出、没查的都写进检查覆盖范围。用户的真实国动投标文件留到第 3 步冻结代码后再用。
|
||
- 2026-11-04：查标第 1 步（链路打通）完成：上传投标分册（类型、版本、加密格式识别）→ 检查（六个阶段，响应匹配先只有检索 + 模型判断，提示词 `check.match` v1）→ 每条清单项留带证据的结论 → 生成问题 → 逐条处理（致命确认无误要写说明并进误报反馈）→ 复查沿用状态；计费三种方式和失败退回都有测试，后端 80 个测试通过。前端加了上传投标文件并检查页和查标页。SK1、SK2 的补丁已做。真实模型在虚构样例上走通了链路，效果还没评。见 `docs/architecture/m3-plan.md` 进度一节。
|
||
- 2026-11-04：查标第 0 步（评测集）。规范 v0.2（`evals/check/GUIDELINES.md`，Fable 审查后修改）：响应方式按「文件 × 类别」记，规矩投标文件靠构造保证，问题只挂复核过的要求，留出集词库和风格 C 封存。C12（响应方式）、E1（复核由 Fable 做、用户抽查 20%）已确认。开发集 S02、S04、S10 六份试跑（`docs/architecture/check-eval.md` §1）：查标召回 38%，规矩投标文件的误报大头是不需要响应的条目、表格里看不见同一行的响应格、扫描件和格式文件找不到。
|
||
- 2026-11-04：用户抽查 Fable 的复核 17 条，全部同意。
|
||
- 2026-11-04：查标评测开发集第一版：7 份招标文件、14 份投标文件（风格 A / B 轮换），注入问题 222 个、Fable 复核通过 188 个。查标召回 40%（致命级 49%），带标志词的问题只有 22%；规矩投标文件报出 699 个问题，近一半在不需要响应的要求上（`docs/architecture/check-eval.md` §2）。
|
||
- 2026-11-04：用户抽查第二批复核 28 条，全部同意（两批合计 45 条）。
|
||
- 2026-11-04：查标第一轮改进：候选句带同一行的单元格、提示词 check.match v2。开发集 17 份上召回 30% → 50%，带标志词的问题 2% → 54%，误报略降，输入 token +44%；漏响应和响应对象错位变差（`docs/architecture/check-eval.md` §3）。评测集修了待修项、加了 3 份低密度投标文件，第三批复核 55 条、用户抽查 11 条全部同意。
|
||
- 2026-11-04：查标第二轮：评测集纠错（漏响应、错位的「变差」多是生成器只改了一处）；新增响应方式识别（C12，规则优先）和「这条要不要投标人回答」的判断。开发集 17 份上规矩投标文件报出的问题 639 → 229，误报 21.3 → 12.4 / 100，召回 68% → 65%，致命级 20 → 21 / 32；证明材料缺失几乎查不出（扫描件）。第四批复核 45 条，用户抽查 9 条全部同意（四批共 65 条）。见 `docs/architecture/check-eval.md` §4。
|
||
- 2026-11-04：查标第三轮：文件要在（按标题找文件名，不调模型）、扫描件兜底（C10，没找到的证明材料改为提示级「可能在扫描件里，请人工核对」）、响应方式存进清单并在清单页显示、可改（C12 的人工确认点，迁移 0007、0008）。开发集上规矩投标文件的致命问题 120 → 51，致命级召回不变（22 / 32）；证明材料缺失仍查不出，要靠 OCR / 多模态（S5）。见 `docs/architecture/check-eval.md` §5。
|
||
- 2026-11-04：查标第四轮：规则检查（`check/rules.py`，规则集 2026.11-r1，不调模型）——大小写金额、分项合计、超限价、多个报价、别的项目名称、没填的地方、落款日期、投标有效期、附加条件、响应表里的未响应；文字层的句子带上单元格框，表格按单元格分行。请 Fable 从真实投标文件角度审读，按「认不准的不给致命」改了定级和取值范围。开发集 17 份上规则问题 57 / 57 查出、规矩投标文件 0 误报，但规则是看着生成器和开发词库写的，这个分数说明不了泛化，要等留出集和国动真实投标文件。见 `docs/architecture/check-eval.md` §6。
|
||
- 2026-11-04：查标第 2 步收尾：需人工核对（份数、密封、递交、CA 签章加密、解密、保证金，从清单按主题合并，查标页勾选、按项目存，P2）；「报价」类清单项（C7，读标从清单表规则读出分项 / 单价上限）和规则 `PRICE.OVER_CEILING_ITEM`；评测集派生 4 份报价问题投标文件，21 份上规则问题 62 / 62、误报 0。见 `docs/architecture/check-eval.md` §7。
|
||
- 2026-11-04：查标第五轮（不调模型的后处理）：偏离栏直读（证据所在表格行的偏离格写着不满足就改判负偏离）、响应错位（照抄要求格 + 响应格写的是别的内容）；复查复用（送审内容没变的条目沿用上次的模型结论）和每次检查的硬预算。开发集 17 份召回 61% → 73%，负偏离未说明 64% → 90%，致命级 22 → 24 / 32，规矩投标文件的问题数不变（235）。见 `docs/architecture/check-eval.md` §8。
|
||
- 2026-11-04：查标第六轮：送给模型的「同一行」按单元格分行；修了「以合同签订时间为准」被当成中标后才交、业绩评分项被跳过的缺陷；重复条目按用户决定改为各自判断、只合并显示（C5 修订，`docs/decisions.md`）；致命项重问按数据（开发集致命级证据校验失败 0 条）暂不做。评测集裁定 1 条。开发集召回 74%、致命级 25 / 32。见 `docs/architecture/check-eval.md` §9。
|
||
- 2026-11-04：查标第 3 步冻结（`a60d16e`），跑留出集一次：S03、S06、S09 各一份风格 B 规矩 + 风格 C 马虎（风格 C 由封存一侧的会话实现），96 个注入问题 Fable 复核通过 79，用户抽查 19 条全部同意。留出集召回 54%（开发集 74%）、致命级 56%（开发集 78%）、负偏离未说明 25%（开发集 92%）、规则问题 13 / 20；S03 的规矩投标文件因响应方式识别过度触发报了 1094 个提示，人工确认响应方式后降到 45 个。开发集分数有相当一部分是调出来的；要修的 5 处见 `docs/architecture/check-eval.md` §11。
|
||
- 2026-11-04：按用户决定（E2）先修留出集暴露的 5 处（响应方式识别、偏离栏按「是不是明确满足」判断、另报价 / 附加条件按结构判断、空白栏、异体字），规则集 2026.11-r3。开发集不退化（召回 75%、规矩投标文件问题数不变）；留出集参考数字召回 54% → 69%、规矩投标文件问题 1134 → 82（已看过，正式成绩仍以冻结代码那次为准）。见 `docs/architecture/check-eval.md` §12。
|
||
- 2026-11-04：查标第 5 步检查报告：导出 → 后台用 Gotenberg 生成 A4 PDF（首页覆盖范围和免责声明、问题明细、需人工核对附录，页眉 logo、页脚免责一句和页码）→ 加密归档，可重复下载；前端加「报告」标签页（选项、导出、内嵌预览、历次下载）。补了项目状态流转（递交 / 撤销递交 / 归档 / 撤销归档，致命未处理也能递交，递交后只读，都留痕）。产品可以从上传招标文件一路走到导出报告、标记递交。见 `docs/architecture/m3-plan.md` 进度。
|
||
- 2026-11-04：查标第 4 步资质库和资质匹配（`docs/architecture/qualification-plan.md`，QL1–QL7 全部按建议确认）。资质库页可增删改、挂证书扫描件（企业级密钥加密），到期按进行中项目的投标截止日提醒；查标按证书类别词表（16 类，产品证书、人员证书不进匹配）核对有效期、等级、有没有覆盖，投标文字层按清单项定级，只有资质库记录的降一级、出处显示「依据：资质库记录」，规则集 2026.11-r4。开发集不退化；派生的资质情况表上 D12 3 / 3、D18 2 / 2、规矩的资质表 0 误报，但表和词表是对着同一批样本写的，泛化要等国动真实文件（`check-eval.md` §13）。
|
||
- 下一步：国动真实投标文件（用户晚些提供，到时先读标、请用户看清单，再查标一次；请用户按公司真实证书录资质库）；其余可做：第 6 步前端补齐（键盘操作、批量处理、判断有误反馈、日期选择器的日历弹层）、M6 剩下的 P0（额度流水、套餐开通、数据删除、运营后台）。
|