# 决策记录

按时间倒序记录用户拍板的产品与工程决策。格式：编号 · 日期 · 决策 · 理由 · 影响。

---

## E3 · 2026-11-05 · 国动真实投标文件暴露的 6 处全部修

- **决策**：国动真实投标文件跑完一次（`check-eval.md` §14）后，暴露的 6 处全部修：响应错位的复合肯定写法、附加条件的否定句、扫描件判断、不需要这家投标人回答的条目、提纲式的「方案应明确……」、同一批片段的出处核对。规则集 `2026.11-r5`。
- **理由**：用户决定。致命、重要两级报出来的都是误报，而且都是真实投标文件最常见的写法。
- **影响**：国动的正式成绩以 §14（修之前）为准，修后的数字只作参考（看过结果才修的）。真实文件仍然只有这一份，泛化要等更多真实投标文件。

## Q2（修订）· 2026-11-05 · ★ 一律按实质性条款处理

| # | 决策 | 理由 |
|---|---|---|
| Q2 | 修订原决策：文件把 ★ 定义成计分项（如 S02「加★为核心技术参数」、不满足只扣分）时，**也不再降为「重要」**，★ 一律按实质性要求；不再生成 meaning = important 的标注规则 | 用户在读标、查标走查后决定。走查时 S02 的 ★ 条款显示「重要」、负偏离只报「重要」，和用户对 ★ 的理解不一致。按实质性处理的代价是计分类 ★ 的负偏离会报成致命，用户可以「确认无误」并写说明（会作为误报反馈）；降级的风险是漏掉真正导致无效的条款 |

- **影响**：`checklist/extract.py` 删掉 `star_scored` 和 `STAR_IMPORTANT`；已解析的项目要重新解析才会变。查标评测开发集里 S02 的级别分布会变（致命级多出 ★ 条款），下次跑评测时注意和旧数字不可直接比。

## AD1–AD6 · 2026-11-05 · 补遗追加：全部按建议

依据 `docs/architecture/addendum-plan.md` §7。

| # | 决策 | 理由 |
|---|---|---|
| AD1 | 补遗的新条目按招标文件同一套规则进正式清单（没出处、校验没过的进待确认区），标「补遗 N」；并入后清单回到草稿，要求重新确认 | 新旧条目都查，宁可多报，不漏报；全放待确认区的话，不逐条采纳就查不到补遗的新要求 |
| AD2 | 只对日期类条目自动标「已被补遗 N 更新」（同一种日期、时间不同）；参数等条目的逐条对照是变更判断，P1 | 按 FR-M2-10；没有补遗样本，先看真实写法 |
| AD3 | 字段的新值在概览页逐个「采用 / 不采用」，日期条目在读标页逐条确认；采用投标截止时间时清单里的「投标截止」条目一起确认；采用时清掉人工值，以补遗为准 | 截止时间两处一次确认；补遗是更新的正式文件 |
| AD4 | 没确认之前查标用旧值，确认后生效；检查预览提示还有几处没确认，不阻止检查 | 数据模型原定「确认后生效」；不阻断用户（红线 4） |
| AD5 | 招标文件解析成功后才显示追加补遗的入口 | 没有招标文件时补遗的日期没有可关联的旧值 |
| AD6 | 用真实模型对虚构的更正公告样例跑一次解析，结果只记录，这次不调提示词 | 看抽取对「原为……现更正为……」写法的表现，花费几分钱 |

## PI1–PI7 · 2026-11-04 · 项目基本信息修改和分包选择：全部按建议

依据 `docs/architecture/project-info-plan.md` §8。

| # | 决策 | 理由 |
|---|---|---|
| PI1 | 做「概览」标签页，这一步只做项目要点、采购包、关键日期三张卡；检查记录、文件、AI 摘要卡留到第 6 步 | 原型就是在概览页改；只做对话框以后还得重做 |
| PI2 | 删掉最后一个包时回到「不分包」（自动建回默认包），不报 `last_lot`；另加「这个项目不分包」一键操作 | S06 把 5 个分项识别成 5 个包，要能一步改好 |
| PI3 | 删包时原属这个包的清单项归为各包通用，确认框写明条数 | 误识别的包里的条目多半本来就通用；宁可多查，不漏查 |
| PI4 | 只识别到 1 个包时按不分包处理：跳过选包页，这个包的限价照用 | S01、S08 是单包项目写了包号 |
| PI5 | 检查记下当时用的项目依据（截止时间、限价、所投的包、法律体系），报告按检查时的值写；之后改了信息，查标页提示「重新检查后生效」，不自动重新检查 | 报告首页和问题明细要一致；重新检查可能扣点，由用户决定（红线 9） |
| PI6 | 换了所投的包，清单的确认状态不变 | 清单内容没变，变的只是查哪些 |
| PI7 | 金额按元存，界面可以写「286 万」「2,860,000」，显示用万元 | 招标文件两种写法都常见 |

- **影响**：`openapi.yaml` 删包不再返回 `last_lot`，新增 `POST /projects/{id}/lots/clear`，清单列表加 `lot_scope`；检查覆盖范围加 `basis`；不加迁移。

## QL1–QL7 · 2026-11-04 · 资质库和资质匹配：全部按建议

依据 `docs/architecture/qualification-plan.md` §7。

| # | 决策 | 理由 |
|---|---|---|
| QL1 | 资质匹配用规则 + 证书类别词表，不调模型；认不出类别的不判断，写进检查覆盖范围 | 资质名称是有限集合，规则可解释、不花钱 |
| QL2 | 投标侧没有出处、只有资质库记录时也出问题，级别降一级，出处显示「依据：资质库记录」 | 资质库是用户自己录的数据，不是 AI 结论，不违反红线 2；真实投标的证书多是扫描件，不出就基本查不出过期 |
| QL3 | 「未覆盖」只在资质库有记录、但没有这一类时报，级别「重要」；资质库是空的不报，只写覆盖范围 | 用户没录不等于没有；空库报一片未覆盖是误报 |
| QL4 | 投标文字层和资质库冲突时以投标文件为准，说明里提资质库里有新证书 | 评审看的是投标文件 |
| QL5 | 免费版也能用资质库 | 不花额度、没有成本；免费版用来试用完整的查标链路 |
| QL6 | 删除资质不做撤销，只留确认框 | 撤销要软删除，和「彻底删除」（G10）冲突 |
| QL7 | D14（证书主体不一致）、D15（业绩 / 人员时间窗口）不在第 4 步做 | 不在 FR-M3-05 的三种预警里；证书主体只在扫描件上；业绩、人员库是 V1 |

- **影响**：资质库不加迁移；`Qualification` 响应加 `late_for`、列表加 `q`；规则集升到 2026.11-r4；评测规范 D14、D15 的实现阶段改为「OCR 之后 / V1」；原型 f6 的「请上传换发后的证书」不进产品（说明不写整改建议）。

## E2 · 2026-11-04 · 先修留出集暴露的 5 处，国动真实投标文件之后再跑

- **决策**：留出集跑完后（`check-eval.md` §11），先修暴露的 5 处（响应方式识别过度触发、偏离栏只认开发集写法、附加条件 / 另报价按措辞枚举、「精确到年月日」误报、PDF 异体字），国动真实投标文件用修好以后的代码跑，而不是冻结代码。
- **理由**：用户决定。真实文件晚一点提供；先修明确的缺陷，真实文件上测到的是改进后的水平。
- **影响**：国动真实投标文件不再是「冻结代码」的成绩；留出集的正式成绩以冻结代码那一次为准（修复后留出集上的数字只作参考，因为修的时候已经看过留出集的漏报）。

## C5（修订）· 2026-11-04 · 重复条目不合并判断，只合并显示

| # | 决策 | 理由 |
|---|---|---|
| C5 | 修订原决策：清单里的重复要求**每条照常单独判断**，不聚组共用一个结论；只在查标页把文字完全相同的问题折叠显示「此要求出现在 N 处」，处理一条时可以连同组一起处理 | 开发集上按相似度 0.9 估算，文字几乎相同的条目常是不同的要求：「缴纳税收材料」和「缴纳社会保障资金材料」；共用一段评分说明的几个评分项；两台服务器各写一遍的同一条参数（一台响应了不代表另一台响应了，正是「响应对象错位」要查的）。合并判断会把这些判错。代价是多花一点 token（每份约 5%～10%） |

- **影响**：`check_item_result.group_key` 不写入；问题接口按「问题类型 + 要求原文」给出同组信息，前端折叠显示。

## C12、E1 · 2026-11-04 · 响应方式按建议处理；评测集挂问题的要求由另一个模型复核、用户抽查 20%

| # | 决策 | 理由 |
|---|---|---|
| C12 | 按 `m3-plan.md` §7 C12 的建议：读标新增「响应方式」抽取（类别 × 方式 × 出处，规则优先、模型兜底，条款写了证明材料的按条覆盖并记投标时 / 中标后，清单页显示、可改）；两处写法冲突按逐条处理并引两处原文；默认接受的一般要求没找到响应不出问题、结论注明「按招标文件默认接受」并带出处，实质性 / ★ 出提示级「请人工核对」；中标后才交的证明材料投标时不查；识别不出按逐条处理，标明「招标文件未写明是否要求逐条响应」，项目上给「本项目只列偏离」开关 | 10 份样本里响应方式按类别不同、同一份文件常有几种，S07 自相矛盾（`evals/check/GUIDELINES.md` §2）；不区分会在默认接受的文件上大量误报致命问题 |
| E1 | 评测集里挂了问题的要求（核对要求本身和响应方式），由另一个模型（Fable）复核，用户抽查 20%；不由用户逐条复核 | 节省用户时间。代价：读标阶段已经证明 AI 复核偏宽，评测结论要注明「金标准未经全部人工复核」；复核模型和写投标文件的模型（Opus）、查标模型（DeepSeek）都不同 |

- **影响**：读标增加一项抽取（查标第 2 步做，和投标侧结构识别一起）；`check_item_result.verdict` 要加「默认接受」；评测报告的头条数字都带「金标准由模型复核、用户抽查 20%」的说明。

## C1–C11、SK1–SK2 · 2026-11-04 · 查标（M3）实现计划的待定事项：全部按建议，C1 补充真实样本

依据 `docs/architecture/m3-plan.md` v0.2 §7。v0.2 是请 Fable 做顾问，深读参考项目的查标实现（`ref-bid-engine-analysis.md` §6），对照读标优化的教训重新评估后的结果。

| # | 决策 | 理由 |
|---|---|---|
| C1 | 评测集按 `m3-plan.md` §4 自己写：用招标文件自己的格式章写虚构投标文件，同时写「响应清单」作为金标准，按招标文件整体留出，人工只裁定开发集上响应清单漏记的问题。**补充**：用户有一份真实的国动小程序投标文件，作为留出集里唯一的真实样本，第 3 步冻结代码后再要来跑一次，之前不看、不按它调 | 读标的三个坑（AI 标注偏宽、评分照搬规则、规则照样本调）分别由响应清单、只对照响应清单打分、多写法 + 留出来堵。真实样本只有一份，用来检验泛化最有价值 |
| C2 | 不先定元数。按 token 设计预算；按投标文件章节打批，同一段正文只送一次；每次检查有硬预算，超出没查的条目写进覆盖范围；24 小时内复查时按「清单项内容哈希 + 分册版本哈希 + 提示词版本」复用结果。第 3 步实测后再定元数 | 参考项目每个项目只判约 90 条，我们 216～1348 条，量级不能照搬；可见的覆盖范围比一个上限数字更诚实 |
| C3 | 模型说已响应，但证据没通过校验：不判已响应，记「未找到响应」，级别不降，记原因码，界面可筛；致命项允许重问一次（只给模型指的那一页）；这类问题占致命问题的比例单列指标，目标 < 10% | 红线 2；原因码和单列指标来自读标待确认区噪音的教训 |
| C4 | 签章只提示位置和有无。主要检查格式文件里该填的地方（投标人名称、签字人姓名、落款日期）有没有填；「（盖单位章）」这类括注不算问题；图像检测只看签章位置附近有没有图像，结论只到「提示」；Word 稿和 PDF 稿都走规范化 PDF，同一套检查 | 电子签章常在投标平台里加盖，稿子里本来没有章；括注盖章后通常仍保留 |
| C5 | 重复条目在检查时分组：同类别、同一个包、保守相似度；问题挂在组里编号最小的清单项上，其他成员的出处附上；复查对齐时组内任一成员对上就算同一个问题；分组记在检查快照里。读标阶段合并以后再做 | 读标同一要求常抽成三条，直接查会出三个一样的问题 |
| C6 | 正式清单全查；待确认区、不在所投包、超出预算的条目写进覆盖范围 | 「全部都查，或者明确说没查哪些」 |
| C7 | 补 `extract.price`，规则优先，模型只做结构化；允许手工新增「报价」类条目；不卡住总价和采购包两层 | 10 份里只有 S06、S10 两份有分项限价或单价上限 |
| C8 | 分册类型：整本（默认）/ 资格证明 / 商务 / 技术 / 报价 / 其他，加自填名称；类型只用来排序检索候选，不限制范围；电子投标平台加密格式维护一张识别表 | 很多投标人一个文件装全部；用户常标错类型 |
| C9 | 新增 `check_item_result`（检查批次 × 清单项的结论、所走的层、投标侧出处、校验状态、原因码、token）；问题仍只为没响应好的条目生成 | 「已响应」也是 AI 结论，按红线 1、2 要能复核、能反馈；复用结果和覆盖范围也靠它 |
| C10 | 扫描件：候选分册里图片页占比超过阈值的条目不出「未找到响应」，改出「请人工核对」；资格类按名称回到资质库匹配；覆盖范围列出没有文字层的页码。OCR（S5）排在 M3 之后 | 真实投标的资格证明多是扫描件，不处理会出一大片致命级「未找到」 |
| C11 | 检索用内存 BM25 + jieba，不用 PostgreSQL 的 pg_trgm / 全文检索 | 句子不进库（DM1）；中文全文检索要第三方扩展；内存索引便于测试和评测 |
| SK1 | 确认：进度推送用 Valkey stream。补：发布用的客户端设短超时，SSE 连接池设上限 | 现在 `valkey()` 没设超时，Valkey 挂掉时会卡住 worker |
| SK2 | 确认：集成测试连 Compose 起的 PostgreSQL。补：CI 直接跑 `init-roles.sh`、加 Gotenberg；架构 §8 同步 | CI 里的建角色 SQL 和部署脚本是两份，会漂移；投标样例有 Word |

- **影响**：`m3-plan.md` 按此执行；`data-model.md` 加 `check_item_result`（迁移在第 1 步）；架构 §8、§13 同步；`ref-bid-engine-analysis.md` §5.4 的检索写法已改。

## Q1–Q4 · 2026-11-03 · 实质性条款的四个口径：全部按建议

依据 `docs/architecture/extract-eval.md` §5（S01–S10 标注时遇到、规范里没定的情形）。

| # | 决策 | 理由 |
|---|---|---|
| Q1 | ★ 标在节标题上（「三、★商务要求」「★（一）技术要求」），节里的条款都是实质性要求 | 文件自己这样声明（S01 还写明商务条款负偏离即无效）；节的范围到下一个同级编号为止 |
| Q2 | 文件把 ★ 定义成计分项（「加★为核心技术参数」、不满足只扣分），而且没有任何地方说 ★ 是实质性要求或写明无效后果，★ 降为「重要」，标注规则记 meaning = important | 否则用户会把扣分项当成废标项（S02）。条件从严：要有计分证据、全文没有带 ★ 的后果写法，拿不准就按实质性 |
| Q3 | 文件声明「必须」「应」字样的要求都是实质性要求时（S07），只在文件层面记一条标注规则（marker = keyword），不逐句抽 | 逐句抽会把几百条一般要求都标成致命，清单失去意义 |
| Q4 | 政府采购项目的资格条件一律带「无效」类别，重要性依据记 statute | 87 号令第六十三条：不具备招标文件规定的资格要求的，投标无效；磋商同理。这是现行规定，不是草案层 |

- **影响**：`extract.build_doc`、`structure.star_sections`；界面上 statute 来源的「无效」要和「文件写明」分开展示（查标阶段做）。

## M1 · 2026-11-03 · 抽取模型只用 Flash，靠规则和提示词优化

- **决策**：读标的全部抽取任务都用 DeepSeek Flash 不思考模式（`deepseek-chat`，接口返回 `deepseek-flash`），不再对比 Pro 和思考模式。提升效果只在规则（校验、兜底、文字层、结构识别）和提示词之间做。
- **理由**：SK11 在实质性条款任务上比较过 Flash 不思考、Flash 思考（`deepseek-reasoner`）和 `deepseek-v4-pro`，抽到的条款大体一致、互有多少，后两者慢 15～45 倍，输出 token 多 7～12 倍，看不出更准。
- **影响**：S01–S10 标注集评测只跑 Flash 基线，用来找规则和提示词的问题；按能力路由（`BD_AI_MODELS`）的机制保留，不配置。tech-validation §4.3 里「D2 定价前补测 Pro 或思考模式」不再做。

## API1–API5 · 2026-11-03 · 接口契约的取舍：全部按建议

依据 `docs/architecture/api-design.md` §9；契约文件 `openapi.yaml`。

| # | 决策 | 理由 |
|---|---|---|
| API1 | 后端骨架搭好前以 `openapi.yaml` 为准，前后端据此同时开发；之后以 FastAPI 生成的文档为准，存成 `openapi.json` 提交，CI 检查是否最新，`openapi.yaml` 不再维护 | 避免两份契约长期并存、互相偏离；契约改动在合并请求里可见 |
| API2 | 事件流（SSE）用 fetch 读取，不用 EventSource | EventSource 带不了 Bearer 头，桌面版用不了 |
| API3 | 同一账号在其他设备已登录时，新设备登录先提示，用户确认后挤掉旧设备 | 落实 FR-M6-04「提示并限制」；「旧设备不退出就不让登录」会让换了电脑的用户登不上 |
| API4 | 会扣点的接口都带「预期扣点」，和服务端当下算的不一致就拒绝、不扣点，并返回最新的扣点预览 | 红线 9：用户看到的扣点说明和实际扣点必须一致 |
| API5 | 报告在后台生成，完成后推送事件 | 生成 PDF 要几秒到十几秒；api 只做短事务 |

- **影响**：架构 §12 第 3 步完成；`data-model.md` 的清单项 `spec` 改为按类别分组。

## DM1–DM7 · 2026-11-03 · 物理数据模型的取舍：全部按建议

依据 `docs/architecture/data-model.md` §9；建表脚本草案 `schema-draft.sql` 在 PostgreSQL 16 上跑通了 16 项行为测试。

| # | 决策 | 理由 |
|---|---|---|
| DM1 | 文字层和句子放对象存储，**不进数据库**；数据库只存页摘要和出处快照 | 每份文件约 2400 句，一年十亿行级；用到句子的地方都在 worker 里整份读取 |
| DM2 | 状态和枚举用 `text` 加 `CHECK`，不用 PostgreSQL 枚举类型 | 改值只改约束；信创数据库兼容性更好 |
| DM3 | 业务表之间的外键都带 `tenant_id` | 关掉行级安全策略时仍能防止跨租户引用 |
| DM4 | 每个项目一把数据密钥，资质附件用企业级密钥；删除项目时销毁 | 落实 G10「彻底删除」，备份里的数据随之不可读 |
| DM5 | 手机号不存明文：查找用 HMAC，发短信用密文，界面显示掩码 | 数据库泄露时拿不到号码 |
| DM6 | AI 判断的问题必须挂清单项；规则问题有对应条目时挂，没有时用规则编号 | 大小写金额不一致、出现其他项目名称这类问题，招标文件里没有对应要求 |
| DM7 | 清单新增类别「报价」，承载分项限价和单价上限；总价限价放项目字段，包限价放分包 | 三层限价（07 F6）都要有确定的落点 |

- **另外**：新增 `notification` 模块（站内通知）；项目内部的外键一律级联删除，平时清单项只做软删除。
- **影响**：架构 §3.2、§3.11、§9、§12；05 §3.2–3.3；FR-M2-05、FR-M3-03；04 指向物理模型。

## AR11–AR12 · 2026-11-03 · 早期只给多人、多登录方式留结构

- **原则**：团队版、企业版（多席位、按角色和项目分权限）、飞书 / 企业微信登录、私有化 SSO 都是以后的版本，早期版本不做；但 MVP 的架构和表结构要先考虑到，以后能直接接进来，不用重构。理由：用户要求。
- **AR11 身份分三层**：人（`user_account`）、登录方式（`login_identity`）、成员身份（`membership`），MVP 就按这个结构建；「一个手机号只属于一个企业」（FR-M6-04）在服务层检查，不写进表结构。
- **AR12 权限检查点先建好**：`project_member` 表（建项目的人自动成为负责人）、service 层统一的 `authz.require`、列表查询统一按可见范围过滤；MVP 里唯一的成员是所有者，检查总是通过。具体角色、可见范围、飞书 / 企业微信的接入规则都到对应版本立项时再定。
- **影响**：技术架构 v0.3 §3.14；04 领域模型的用户拆成 User / LoginIdentity / Membership，增加 ProjectMember，订阅增加席位数。

## Q13、U 键 · 2026-11-03 · 按建议

- **Q13 额度流水记录「免扣」行**：24 小时内复查不扣点时，也记一行流水，类型「免扣（24 小时内复查）」，数量 0，关联到这次检查。理由：红线 9 要求扣点规则可见、可查，用户能自己核对复查确实没扣点。影响：FR-M6-03 和 04 领域模型补「免扣」类型。
- **快捷键 U 撤销「当前条」**：和规范 §8.2 一致，不再是「撤销最近一次」。为此调整了交互：本次处理过的问题留在原位，显示署名行；处理完自动跳到下一条，按 K 可以回到刚处理的那条再按 U。页面加载前已处理的仍然折叠在「已处理」里。

## Q1–Q12 · 2026-11-03 · UI demo 的待定问题：全部按建议

来源：`docs/design/ui-demo/index.html`。按设计规范 v0.2 重刷 demo 时一并落实，写入 design-system.md 对应章节。

| # | 决策 |
|---|---|
| Q1 | 额度流水的「+」用墨色，靠「+ / −」符号区分；绿色只表示「有人确认过」 |
| Q2 | AI 产出的正文始终墨色；AI 身份靠「AI」小标签和左侧蓝铅笔虚线，确认后换成署名行 |
| Q3 | 选中统一为浅灰底加左侧 3px 墨色竖条；蓝色只留给原文高亮和出处链接 |
| Q4 | 开关：圆角 6 的矩形轨道加「开 / 关」文字，不用胶囊形。分页：当前页浅灰实底加粗。下拉：选中项加粗加墨色 ✓。日期选择：不可选日期只变灰，不加删除线 |
| Q5 | 参数对照表保留「级别」列，色弱用户不能只靠颜色判断 |
| Q6 | tokens.css 补悬停、按下、遮罩等颜色变量，清掉裸色值 |
| Q7 | 数字字阶：28（统计）/ 15 / 13 |
| Q8 | 骨架屏静止，不做明暗起伏 |
| Q9 | 顶栏额度用到 ≥ 80% 时，数字变赭色加粗；用完时悬停说明续费方式；不用红 |
| Q10 | 日期输入格式「2026-11-20 09:30」（24 小时制，配日期选择器）；显示格式「11月20日 09:30」 |
| Q11 | MVP 不做项目卡片视图，工作台只用列表 |
| Q12 | 「一屏一个主按钮」按上下文算：页面级一个，对话框可以有自己的主按钮；陈列页不受限 |

## U5 · 2026-11-03 · UI 风格定稿：白色主调 + 墨色渐变窄侧栏

- **背景**：种子用户走查结束，进入 UI 精修。用户看了 UI demo，认为细节没问题，但整体风格「像 Windows 2000」：处处描边框、2px 圆角、灰色凹陷表头、四张一样的统计卡。
- **过程**：在工作台页面上做了六轮方案（`docs/design/ui-demo/explore/`）。
  - 第一轮 A 留白文档、B 工作面板、C 截止线：用户反馈 C 排除，A 像只读报告，B 有点乱，校样纸底色太绿灰。
  - 第二轮 D 明亮工作区、E 下一步、F 列表 + 详情：用户选 D，但觉得太白。
  - 之后在 D 上迭代：侧栏改墨色；顶栏改透明；试过装饰图标后去掉；侧栏融合方式和选中样式调了几版；最后改为不折叠的窄侧栏。
- **定稿**：`docs/design/ui-demo/explore/workbench-d5.html`。规则写入设计规范 v0.2 和 `tokens.css` v0.2：
  - **页面**：白色主调。浅灰全部从墨色派生（`--c-n50` #F8F8F9 页面底、`--c-n100`、`--c-nline`），不再用校样纸作页面底色。只有一种容器，即白卡片加发丝线边框；表头无底色。
  - **圆角三档**：标签 6、控件 8、卡片 12；按钮高 36 / 32 / 40。
  - **侧栏**：
    - 96px，单一状态，不折叠。
    - 墨色到深墨蓝的竖向渐变，底部有淡点阵。
    - 顶部是竖版反白 logo，居中；菜单上图标、下文字（house / award / wallet）。
    - 选中态是圆角矩形的半透明浅底。
    - 底部是大头像、姓名、套餐标签。
  - **顶栏**：透明，滚动后变为半透明白加毛玻璃；搜索框靠右。
  - **图标**：只用功能图标，不用装饰图标（统计卡、区块标题、列表行首都不加）。
  - **项目行**：「下一步」左对齐，悬停只让箭头右移；「更多」单独一列，常驻显示；「致命」列居中。
  - **文案**：少写说明，用户原话「文案多了反而会增加 AI 感」。产品红线要求明示的扣点说明和签章说明保留。
  - **套餐标签**：金色阶梯（免费版灰、专业版浅金、企业版金色实底），从赭色派生。作为例外只用于账户区，以便将来区分专业版、企业版。
- **不变**：颜色语义（红只给致命、赭给提醒、蓝铅笔给 AI 和出处、绿给确认署名）、三套字体、问题级别的形状规则、产品红线。
- **影响**：
  - 其余 UI demo 页（控件、表单、卡片、列表、读标）和 MVP 原型，仍是 v0.1 的结构。它们引用 `tokens.css`，颜色、圆角、控件高度已经随变量更新，但侧栏、表头这类结构要按 v0.2 重刷。
  - UI demo 的待定问题 Q1–Q12 在重刷时一并回答。

## TV1 · 2026-11-03 · 技术验证 S1–S4 后确定的目标值：按建议

验证报告见 `docs/architecture/tech-validation.md`，代码在 `spikes/`。

| 需求 | 目标值 | 依据 |
|---|---|---|
| FR-M2-05 | 标注类实质性条款（★ / 斜体下划线等）召回率 ≥ 99%，靠规则兜底加模型实现；进入正式清单的条目准确率 ≥ 95% | S4：DeepSeek 单模型 ★ 召回约 96.6%，斜体下划线 99.8%；加第三道依据校验后采纳条目 95.2% 属实。漏掉的都是表格里的参数行，要靠规则兜底补足 |
| FR-M2-06 | 出处页码正确率 100%；原句高亮准确率正文 ≥ 98%、表格内 ≥ 95% | S3：几何回读 300/300；文本保真正文 97.5%、表格 78%。表格要改成按单元格切句后再验收 |

- **影响**：架构文档 §3.5 加入两步预处理（修正 WPS 错标的字体字符集、改用行高调整过的开源字体包），§3.6 的证据校验改为三道并加规则兜底。
- **还缺**：「写明投标无效」类条款需要人工标注才能测召回；深度思考模式和更高档模型的效果与成本，要在 D2 定价前补测。

## AR10 · 2026-11-03 · 不引入带样式的 UI 框架

- **决策**：用户端不用 Element Plus 这类带样式的 UI 框架。视觉全部用 Vue 单文件组件和 `tokens.css` / `components.css` 自己实现；对话框、下拉选择、日期选择、弹出层、菜单、轻提示、标签页、复选框等交互复杂的组件，用无样式组件库 **Reka UI**（原 Radix Vue，MIT）打底。表格需要排序、筛选时用 TanStack Table，长列表用 TanStack Virtual；表单用 Zod 加一个自写的 `useForm`。不用 Tailwind 和 shadcn-vue。
- **理由**：先调研了 Element Plus（推荐）、TDesign 等带样式框架；用户提出产品有一套自己的高保真设计，引入它反而会限制开发。复核后同意：核心业务组件框架都不提供；基础件的默认行为（红色危险按钮、红色必填星号、转圈的加载按钮、固定结构的错误提示）和设计规范第 7 节冲突，改造要覆盖框架内部样式，升级时容易失效；两套样式体系并存，开发时容易偏离设计稿。完全手写又难以保证焦点管理、键盘导航和浮层定位的质量，所以用无样式组件库补上这一块。
- **影响**：`packages/ui` 分基础件、交互件、业务组件三层，预计 2～3 人周，可以和页面并行；每个组件有预览页（延续 `components.html`）；交互件补键盘操作测试。运营后台的选型等做到时再定。详见架构文档 §4.3。

## AR1–AR9 · 2026-11-03 · 架构草案的选型：AR2 改为 Vue 3，AR4 复议后修订，其余按建议

依据 `docs/architecture/architecture.md` 第 11 节。

| # | 决策 |
|---|---|
| AR1 | 模块化单体 + 按负载拆进程（api、worker、converter、ocr），不拆微服务 |
| AR2 | **前端用 Vue 3 + TypeScript + Vite 单页应用**（用户把建议的 React 改为 Vue 3）；不做服务端渲染。UI 组件库另行调研，见 AR10 |
| AR3 | 数据库用 PostgreSQL，以兼容 PostgreSQL 的信创数据库作为迁移路线；行级安全策略作为第二层租户隔离 |
| AR4 | **任务状态和队列放在 PostgreSQL（Procrastinate），另外引入 Valkey，只存丢了也没关系的数据**（模型接口限速、验证码、登录限流、进度推送、短期缓存），不持久化、不备份；会话放在 PostgreSQL，只存令牌哈希。v0.1 原本建议「MVP 不引入 Redis」，用户追问后复议：不引入能省下的只是一个轻量容器，而限速、防刷、多实例推送三件 MVP 必做的事用 PostgreSQL 做都很别扭（架构文档 §6.1） |
| AR5 | 文件存储用 S3 协议 + 本地磁盘驱动，不用 MinIO（社区版已停止发布和维护） |
| AR6 | 桌面外壳倾向 Electron，桌面版立项时再定；前端现在就守住 §5.2 的 7 条约束 |
| AR7 | 私有化代码保护：Nuitka 编译核心包 + 签名授权文件 + 提示词加密 |
| AR8 | 服务端会话，可吊销；网页端用 cookie，桌面端用 Bearer 令牌 |
| AR9 | 单一仓库（monorepo） |

## T2–T5 · 2026-11-03 · 技术架构的四项基础选择：全部按建议

架构草案见 `docs/architecture/architecture.md`；其余选型（AR1–AR9）待确认。

- **T2 后端用 Python 单语言**：业务接口（FastAPI）和后台任务是同一套代码、两种进程。理由：团队小；核心价值在文档解析、OCR 和大模型流水线，这些生态 Python 最强，用单语言就不会把领域逻辑拆在两种语言里。代价：私有化交付会暴露源码，用 Nuitka 编译和授权文件缓解（AR7）。
- **T3 桌面客户端定位为「连服务端的客户端外壳」**：界面和网页版是同一套，连 SaaS 或私有化服务器；外壳只提供本地文件、通知、钥匙串、更新这些本地能力，不内嵌后端和模型。影响：第一阶段的前端必须守住架构文档 §5.2 的 7 条约束（纯静态构建、接口地址可配置、同时支持 cookie 和 Bearer 鉴权、平台能力走抽象层等）。
- **T4 SaaS 先用 Docker Compose，商用再上 K8s**：内测期用 1～2 台云服务器跑 Compose，数据库和对象存储用云厂商的托管服务；公测前用同一批镜像切到托管 K8s（Helm）。理由：Compose 本来就是私有化小客户的交付形态，内测期间顺带打磨。
- **T5 云厂商暂不定，按云无关设计**：只依赖 PostgreSQL、S3 兼容的对象存储、OpenAI 兼容的模型接口这三类标准接口；上线前比较价格后再选。

## B6 · 2026-11-03 · 应用图标改为印泥铺满

- **决策**：应用图标不再是「白底 + 印章占 80%」，改为印泥铺满整个方形、不留白边；圆角按 Apple 的连续曲率圆角（squircle）由系统裁切，图标文件保持方形、不带透明。VI 手册第 22 页用 iPhone 18 Pro 主屏幕模拟展示：Apple 官方黑色机身、iPhone 18 Pro 深色壁纸 Black、iOS 系统图标只放 4 行，第四行只有股市和标博士两个。
- **理由**：白边让图标在主屏幕上显得小而虚，和其他应用放在一起不像一枚印章；铺满后红色块面完整，辨识度更高。
- **影响**：`logo/scripts/build_logo.py` 新增 `svg/app-icon.svg`，`build_assets.sh` 由它渲染 180 / 192 / 512 / 1024px 图标；VI 手册 v1.1 第 22 页重排（邮件签名移到左栏）。Apple 素材不进 git，用 `vi/mockup/fetch.sh` 获取，机身需本人同意 Apple Design Resources 许可后手动放入。

## P1–P2 · 2026-11-02 · 原型阶段的待确认事项：全部按建议

- **P1 24 小时免扣的起算点**：从**上一次扣了额度的检查**算起；窗口内的复查不扣点，也不重新计时。理由：如果从上一次检查算起，每天复查一次就能一直不扣点，额度规则形同虚设。**影响**：FR-M3-02。
- **P2「需人工核对」的勾选按项目存**：整个项目共用一份勾选结果，复查时保留；报告写明勾选人和时间。理由：份数、CA 加密、递交回执这类事项和投标文件版本无关，每次检查重新勾选只会增加负担。**影响**：FR-M3-04。

## U1–U4 · 2026-11-02 · 产品界面设计规范 v0.1 的待确认事项：全部按建议

规范见 `docs/design/design-system.md`（第 12 节）。

- **U1 红色只给致命问题**：表单错误、系统错误、额度用完、截止临近都用赭色（小字 #8A5200），不用红。理由：让红色只代表「可能导致投标无效」；色弱模拟显示红 / 赭本来就要靠形状和文字区分，错误提示照样有文字和图标。
- **U2 只做桌面 Web**：MVP 最小宽度 1280，不做手机适配和暗色模式。理由：读标和查标需要原文并排；变量已按语义分层，以后可加暗色。
- **U3 图标用 Lucide**（ISC 许可）：线性风格和校样方向一致，可商用。
- **U4 致命问题「确认无误」也要写说明**：对致命问题说「没问题」等于认为系统判断错了，说明既用于审计，也作为误报反馈。**影响**：FR-M3-07 已同步修改。

## B5 · 2026-11-02 · 口号改为「标博士，你的AI投标专家」

- **决策**：品牌口号由「每一条，都有出处。」改为 **「标博士，你的AI投标专家」**，固定写法：AI 两侧不加空格，结尾不加标点。
- **范围**：品牌策略、VI 手册（品牌概述、名片、演示文稿、网站、封底、字体样张）、方向对比板等所有出现口号的地方。
- **保留**：「每一条，都有出处」作为产品原则「出处看得见」保留（可复核是核心差异），不再作为口号。
- **注意**：「专家」只表示懂行、查得细；产品和报告里的结论仍然只用「辅助检查」「风险提示」，不承诺结果（产品红线不变）。

## B4 · 2026-11-02 · 横版比例 H2，中文字标用思源宋体 SemiBold（英文待选）

- **比例 H2**：印章的实心边缘上下对齐文字块（中文顶端到拼音底部），再放大 2%，补偿颗粒边缘显虚的问题。
  - 依据：v5 实测印章只有文字块的 96%，原因是抠图时印章四周各留了 2% 的透明边。中国银行、招商银行、中华老字号等「图形 + 中英两行文字」的组合，图形高度通常和整个文字块相同；方形本身就比圆形显大，所以不需要再放大。
  - 对比见 `docs/design/logo/compare/index.html`。
- **中文字标**：思源宋体 SemiBold（F2），比 Black 更清秀，和印章的轻重对比更明显。
- **英文字体**：中英文用不同字体（这是品牌组合里的常见做法）。用户选定 **E5 Libre Caslon**（OFL，Caslon 类老派衬线），候选对比见 `compare/english.html`。
- **英文视觉对齐**：几何上两端对齐时，英文看起来比中文宽。原因是「标」「士」两端只有细横画尖，而英文两端是 B、I 的粗竖画，按墨迹浓度算英文左超 6.5、右超 7.7（中文字高 = 100）。真实品牌两种做法都有：中银香港内缩了英文；清华、进出口银行只做了几何对齐。排版理论主张按视觉边缘对齐。补偿档位 C0–C3 见 `compare/alignment.html`。用户选定 **C2**（左内缩 5.0、右内缩 5.8，约为完全补偿的 3/4）。
- **已执行**：全套正式资产按 H2 + F2 + E5 + C2 重新生成（logo v5.1）。排版逻辑集中在 `docs/design/logo/scripts/logo_lib.py`，正式资产由 `build_assets.sh` 生成，对比页由 `wordmark_compare.py` 生成，三者共用同一套参数。

## B3 · 2026-11-02 · Logo 暂定 v5：AI 生成的白文印 + 矢量字标

- **决策（暂定）**：印章采用用户用 ChatGPT 图像生成的白文印「标」（`docs/design/logo/image-gen/exec-8232d0a3-…png`），经脚本处理后作为正式 logo；字标用思源宋体 Black + Cinzel（W1）。规范见 `docs/design/logo/logo-spec.md`。
- **过程**：v1 由 Codex 精细化草稿 1；v2–v4 尝试用 SVG 程序化模拟印泥质感，效果都不理想（调研见 `seal-research.md`）。结论是印泥质感本质上是位图，所以改用位图生成，再矢量化。
- **颜色调整**：印章红从 #D2282E 改为朱砂色 **#D9291C**（原图实测 #E21B0A，偏亮、超出印刷色域，略压深）。界面「致命」红 #C4122F 不变，两者一橙一洋红，可以区分。
- **小尺寸**：16px 仍用方案 B（加粗简化的「标」字），32–64px 用白色笔画加粗的印章。
- **待办**：AI 生成图形的著作权认定有不确定性，商标注册前要做检索并咨询知识产权顾问；以后可以考虑照这个设计刻一方真章，扫描后替换。

## B2 · 2026-11-02 · 16px 图标与英文名

- **16px 图标**：用方案 B，加粗简化的「标」字。红底白勾（方案 A）是待办类应用的常见图标，辨识度低。
- **英文名**：统一用拼音 **BIAOBOSHI**，不用 Bid Doctor。代码仓库名继续用 `bid-doctor`。
- **logo 第二阶段**：用户要求增加真实印章质感、重新考虑对勾（它破坏了平衡），并给字标换更有性格的开源字体。设计说明见 `docs/design/logo/BRIEF-v2.md`，先出方案对比页，用户选定后再更新正式资产。

## B1 · 2026-11-02 · 视觉方向 A「校样」+ 用户的印章 logo

- **决策**：视觉方向选 A「校样」（`docs/design/brand-directions.html`）：蓝铅笔表示 AI 标注 / 出处，墨表示人工确认，红只用于问题。Logo 不用 A 方向原来的示意，改用用户提供的草稿 1（红色方形印章 + 白色「标」字 + 穿出边框的对勾 + 藏青字标），草稿 2（学士帽）不采用。
- **理由**：盖章是投标人每天都在做的事，印章比「博士帽」更贴近用户、辨识度更高，也适合做应用图标；对勾表达「逐项核对」。
- **约束**：
  - 印章红只用在 logo 上；界面中的「致命」红单独定义，两者要能区分。
  - 「印章 + 对勾」不能当作「通过 / 合格」章用在报告或任何结论上（产品红线：不承诺结果）。
- **执行**：由 Codex 按 `docs/design/logo/BRIEF.md` 精细化，交付物在 `docs/design/logo/`。

## T1 · 2026-11-02 · 大模型策略：国产云端模型，按场景路由

- **决策**：全部使用国内云端的国产大模型，不考虑数据出境。按业务场景匹配模型能力：多模态（扫描件理解、签章检测）、快速（分类、短文本抽取、交互类）、深度思考（复杂条款推理、响应性比对）。
- **影响**：
  - 架构中需要一个**模型路由层**：业务代码只声明「需要什么能力」，由路由配置决定用哪个供应商、哪个模型，方便替换和对比。
  - 解析任务、检查批次都要记下实际使用的模型和提示词版本（04 §4.4）。
  - G11 中「数据出境」一项消除。待办：确认选用的模型都已完成生成式 AI 备案，确认供应商协议里「数据不用于训练」的条款（PRD 7），本产品自身的登记义务请法务确认。
  - 企业版私有化（P2）时，路由层要能切换到客户域内部署的模型。
  - G12（签章检测）交由多模态模型做可行性验证。

## A1 · 2026-11-02 · 需求分析待确认事项 G1–G10：全部按建议

依据 `docs/analysis/06-gaps-and-questions.md`，用户确认全部采纳建议：

| # | 决策 |
|---|---|
| G1 | 区分政府采购 / 招标投标两套法律体系；M2 识别体系，M3 按体系套用规则，术语随体系切换；PRD 1.5 补充政府采购依据 |
| G2 | 修订 PRD 的异常低价口径：政府采购项目适用 87 号令第六十条（现行层）。已出 **PRD v0.9.1** |
| G3 | 多包 / 多标段纳入 MVP（FR-M2-04） |
| G4 | MVP 做最小资质库（FR-M6-08）；资质匹配首先核对投标文件里的证明材料 |
| — | 报价形式检查（超限价、大小写和合计一致）从 P1 拆出，升为 P0（FR-M3-06） |
| G5 | 「检查」是独立计量单位；专业版检查从解析额度扣；24 小时内复查免费；投标文件的解析算在检查里；免费版 1 个项目内检查不限次数 |
| G6 | MVP 不做线上加量包，由运营后台人工调额度 |
| G7 | 清单没确认也能检查，但要提示 |
| G8 | 专业版开通：在线申请 → 对公转账 → 运营人工开通并开发票；线上支付以后再做 |
| G9 | MVP 不做企业认证，注册只填企业名称 |
| G10 | 删除项目时业务内容彻底删除，只保留不含业务内容的审计记录和额度流水 |

## D1 · 2026-11-02 · 首发行业：IT 集成

- **决策**：MVP 首发行业为 IT 集成（信息化系统集成、软硬件设备采购及配套服务类项目），工程类延后。
- **理由**：PRD 第 12 章默认建议；IT 集成类招标文件格式最标准化，★ / ▲ 实质性条款标记、技术参数偏离表等结构便于结构化提取与逐项核对。
- **影响**：
  - M2 提取 schema、M3 检查规则、原型样例数据均以 IT 集成项目为准，详见 `docs/analysis/05-it-integration-domain.md`。
  - IT 集成项目多数走**政府采购**法律体系（《政府采购法》、财政部令第 87 号等），与 PRD 1.5 所引的《招标投标法》体系并存，产品需识别项目适用的法律体系，见 `docs/analysis/06-gaps-and-questions.md` G1。
  - 种子用户获取方向：IT 集成商、软硬件设备供应商、信息化服务商的投标团队。