bid-doctor/docs/decisions.md

决策记录

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

---

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 集成商、软硬件设备供应商、信息化服务商的投标团队。