bid-doctor/docs/decisions.md

决策记录

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

---

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