diff --git a/docs/analysis/01-scope-roles.md b/docs/analysis/01-scope-roles.md
new file mode 100644
index 0000000..658f77c
--- /dev/null
+++ b/docs/analysis/01-scope-roles.md
@@ -0,0 +1,88 @@
+# 01 · MVP 范围与角色
+
+> 依据：PRD v0.9 第 5、6、9 章；D1（IT 集成先行）。本文只覆盖 **MVP**，V1 及以后的功能仅在边界处提及。
+
+## 1. MVP 一句话
+
+**用户上传一份 IT 集成招标文件，拿到一份能逐条回到原文的结构化检查清单；递交前上传投标文件，系统对照清单逐项核对，用户逐条确认后导出一份带留痕的检查报告。**
+
+链路：`新建项目 → 上传招标文件 → 解读 → 确认清单 → 上传投标文件 → 检查 → 逐项确认 → 导出报告`
+
+## 2. 范围边界
+
+### 2.1 MVP 包含
+
+| 模块 | 功能 | PRD 出处 |
+|---|---|---|
+| M2 | 文件上传与解析（PDF / Word / 扫描件 OCR） | M2 P0 |
+| M2 | 结构化提取：资格条件、废标 / 无效条款、评分办法、关键日期与递交要求 | M2 P0 |
+| M2 | 原文回链（页码 + 原句高亮）；无出处结果进「待确认」区 | M2 P0 |
+| M2 | 项目检查清单生成，用户可增删改并留痕 | M2 P0 |
+| M3 | 响应完整性检查（未响应 / 负偏离未说明 / 漏项） | M3 P0 |
+| M3 | 形式要件检查（格式、签章位置与有无、命名、份数、递交方式） | M3 P0 |
+| M3 | 资质匹配检查（过期 / 等级不足 / 未覆盖） | M3 P0 |
+| M3 | 人工确认三态 + 就绪状态 | M3 P0 |
+| M3 | 检查报告 PDF 导出 | M3 P0 |
+| M5 | 服务协议中的围串标禁止条款（仅协议文本，无功能） | M5 P0 |
+| M6 | 项目工作台、项目状态流 | M6 P0 |
+| M6 | 额度计量、明细、80% / 100% 提醒；失败不扣点 | M6 P0 |
+| 商业 | 免费版 + 专业版 | 第 9 章 |
+
+### 2.2 分析中新增、已确认纳入 MVP
+
+这些是 PRD 没写、但 MVP 链路跑不通或明显缺一块的部分。2026-11-02 已全部按建议确认（`docs/decisions.md` A1），详见 `06-gaps-and-questions.md`：
+
+| 项 | 原因 | 建议 |
+|---|---|---|
+| 多包 / 多标段 | IT 集成采购常分包，资格、限价、参数都按包区分 | **纳入**，否则清单会混入不投的包 |
+| 最小资质库 | M3 资质匹配是 P0，但资产库在 M6 是 P1 | **纳入轻量版**（手工录入 + 有效期） |
+| 报价形式检查 | 超预算 / 最高限价是法定无效情形，且不涉及「建议报价」 | **升为 P0** |
+| 补遗追加（简化版） | 真实项目几乎都有补遗；完整的影响分析是 P1 | 纳入「追加解析 + 来源标注」，不做自动影响分析 |
+| 账号、套餐开通、支付 | PRD 没写 | 见 G8、G9 |
+| 运营后台 | 开通套餐、调额度、看漏报反馈，都需要内部工具 | **纳入最小版** |
+
+### 2.3 MVP 明确不做
+
+- M1 商机筛选全部、M4 标书生成全部、M5 查重功能全部。
+- M2 答疑澄清辅助、补遗自动影响分析（P1）。
+- M3 报价合理性（低价）风险检查、行业规则包的版本化运营（P1；MVP 只内置一套 IT 集成规则，但报告中保留版本字段）。
+- 团队协作、角色权限、团队版（V1）。
+- 移动端（PRD 7：移动端只做进度查看与提醒，MVP 不单独适配，只保证响应式页面可用）。
+- 电子投标递交、CA 加密文件解析（产品只处理加密前的 Word / PDF 稿）。
+
+## 3. 角色
+
+### 3.1 外部用户
+
+| 角色 | 画像 | MVP 中能做什么 |
+|---|---|---|
+| 访客 | 通过搜索 / 推荐进来的投标人员 | 浏览定价页、注册 |
+| 免费版用户 | 个人 / 小微投标人、来评估的企业投标岗 | 解读 3 次（单份限页）、检查 1 个项目，完整体验一次链路 |
+| 专业版用户 | 中小企业投标专员（PRD 主力用户），1 个账号 | 解析 500 次 / 年额度内不限项目；最小资质库 |
+
+MVP 没有团队，「账号 = 用户 = 企业主体下唯一成员」。数据模型仍按「企业主体（租户）→ 成员」设计，给 V1 团队版留出空间，见 `04-domain-model.md`。
+
+**关键人物（来自 PRD 第 3 章）**：
+
+- **投标专员（主用户）**：上传文件、核对清单、处理检查结论。目标是别废标、别熬夜。要满足他们，需要把每条结论的出处做好、页面上一眼能看到还剩几个致命项。
+- **投标主管 / 老板（付费决策人）**：一般不在 MVP 里直接操作，但会看检查报告、决定续费。要满足他们，需要报告专业、可以拿来归档，免费版的报告就要让人愿意付费。
+
+### 3.2 内部角色
+
+| 角色 | MVP 中能做什么 |
+|---|---|
+| 运营管理员 | 用户与企业查询、开通 / 续费套餐、额度调整（带原因留痕）、查看「漏报 / 误报」反馈 |
+| 规则维护者（可由运营兼任） | 维护内置 IT 集成规则清单，MVP 阶段可以直接改配置文件，不做界面 |
+
+## 4. 计费单位在 MVP 中的口径
+
+PRD 8.2 和 8.3 的口径不完全一致（见 G5），2026-11-02 确认按下面的口径执行（`docs/decisions.md` A1）：
+
+| 动作 | 扣点 | 不扣点 |
+|---|---|---|
+| 解读一份招标文件 / 补遗 | 1 次「解析」 | 解析失败、超时、用户取消 |
+| 对一个项目做一次全量检查 | 1 次「检查」；专业版的「检查」从解析额度中扣 | 检查中断、系统异常；同一项目 24 小时内复查 |
+| 解析投标文件 | 算在本次「检查」里，不另外扣 | — |
+| 免费版 | 解读 3 次；限 1 个项目，这个项目内检查和复查不限次数 | — |
+
+MVP 不做线上加量包，额度不够时由运营后台人工调整（G6）。
diff --git a/docs/analysis/02-user-journeys.md b/docs/analysis/02-user-journeys.md
new file mode 100644
index 0000000..a9c9876
--- /dev/null
+++ b/docs/analysis/02-user-journeys.md
@@ -0,0 +1,54 @@
+# 02 · 用户旅程（MVP）
+
+> 样例场景统一使用 IT 集成项目：「某市政务服务中心智慧大厅建设项目（政府采购 · 公开招标 · 分 2 个包）」。原型阶段沿用这个场景。
+
+## J1 · 首次体验（免费版，完整跑一遍）
+
+**目标**：注册 7 日内拿到第一份检查报告（PRD 第 10 章「激活」指标）。
+
+| # | 用户动作 | 系统响应 | 关键体验点 / 风险 |
+|---|---|---|---|
+| 1 | 手机号注册，填写企业名称 | 创建企业主体和账号，发放免费额度（解读 3 次、检查 1 个项目） | 注册不要求上传营业执照（G9） |
+| 2 | 新建项目，上传招标文件 PDF（186 页） | 校验格式和页数，超限时提示升级；创建解析任务并预扣 1 次解析 | 页数上限要在上传前就提示，不要等解析失败 |
+| 3 | 等待 | 分阶段显示进度：文本提取 / OCR → 章节识别 → 要素提取 → 出处定位 | 目标 10 分钟内完成；用户可以离开页面，完成后站内通知 |
+| 4 | 识别到分包，选择「我投 1 包」 | 清单只保留通用项和 1 包的项，2 包的项折叠隐藏 | 分包识别错了，用户可以手工更正 |
+| 5 | 浏览清单：资格 / 无效条款 / 评分 / 日期与递交 / 技术参数 | 每条都能点开看原文：左边是清单，右边是 PDF，原句高亮 | **最重要的建立信任的时刻**，回链必须准 |
+| 6 | 处理「待确认」区（没定位到出处的条目） | 用户逐条采纳、修改或删除 | 默认不进正式清单 |
+| 7 | 确认清单 | 清单状态变为「已确认」，可以进入检查 | 不确认也能检查，但会提示（G7） |
+| 8 | 上传投标文件（商务册、技术册、报价册，共 3 个 Word） | 发起检查，扣 1 次检查 | 支持一个项目有多个投标文件分册 |
+| 9 | 看检查结果 | 按「致命 / 重要 / 提示」分组；每条结论两侧出处对照（招标原文 ↔ 投标原文） | 「未找到响应」的条目要写清楚找过哪些文件、哪些章节 |
+| 10 | 逐条处理：已确认无误 / 已修改 / 忽略并注明原因 | 致命项清零后，项目显示「就绪」 | 支持批量处理「提示」级 |
+| 11 | 导出 PDF 报告 | 报告首页写明检查覆盖范围和免责声明；报告随项目归档 | 免费版报告带「免费版」角标，但不能降低报告的可用性 |
+| 12 | — | 额度用完，提示升级专业版 | 升级时机：拿到报告之后，而不是拿到之前 |
+
+## J2 · 真实项目迭代（专业版）
+
+| # | 场景 | 系统行为 |
+|---|---|---|
+| 1 | 采购人发布补遗（修改了投标截止时间、一项 ★ 参数） | 用户在项目中「追加招标文件」→ 扣 1 次解析 → 新提取的条目标注来源「补遗 1」并加入清单；日期类字段以最新文件为准，同时提示用户核对。MVP 不自动判断哪些条目被补遗作废，由用户自己删除或修改（自动影响分析是 P1） |
+| 2 | 修改投标文件后重新检查 | 24 小时内复查不扣点；上次已处理的结论，如果问题仍在，就沿用原来的处理状态并标「沿用」；问题消失则自动关闭；新问题标「新增」 |
+| 3 | 资质库里有证书在投标截止日前过期 | 资质匹配给出「过期」预警，有效期以项目的投标截止日为准，不以今天为准 |
+| 4 | 项目递交 | 用户手动标记「已递交」；项目锁定为只读，可以再导出报告 |
+| 5 | 中标 / 未中标之后 | 用户手动「归档」（MVP 不记录中标结果，V1 以后再考虑） |
+
+## J3 · 额度提醒与升级
+
+| 触发 | 行为 |
+|---|---|
+| 额度用到 80% | 站内提醒 + 短信（G14 建议）；额度页显示本期已用、剩余、按功能分布 |
+| 额度用完 | 发起解析 / 检查时拦截；免费版提示升级专业版，专业版提示联系客服加额度（MVP 不做线上加量包，G6） |
+| 解析失败 | 预扣的额度自动退回；明细中显示「失败退回」 |
+
+## J4 · 删除数据
+
+| 动作 | 行为 |
+|---|---|
+| 删除项目 | 二次确认后删除项目下的文件、清单、检查结果、报告；保留一条不含业务内容的审计记录和额度流水（保留策略见 G10） |
+| 注销账号 | 删除企业主体下的全部业务数据；订单和发票记录按财务要求保留 |
+
+## J5 · 反馈漏报 / 误报
+
+支撑 PRD 第 10 章「信任」指标：
+
+- 每条检查结论都可以「反馈：判断有误」；清单页可以「反馈：有遗漏的要求」。
+- 反馈进运营后台，逐条复盘，再迭代规则。这个指标只给内部用，界面上不展示统计数字。
diff --git a/docs/analysis/03-functional-requirements.md b/docs/analysis/03-functional-requirements.md
new file mode 100644
index 0000000..d9ba9c5
--- /dev/null
+++ b/docs/analysis/03-functional-requirements.md
@@ -0,0 +1,241 @@
+# 03 · 功能需求（MVP）
+
+> 编号规则：`FR-<模块>-<序号>`。优先级沿用 PRD；标 **[新增]** 的是需求分析中补充的，已于 2026-11-02 确认（`docs/decisions.md` A1）。
+> 每条都写了验收标准；测试阶段直接据此编写用例。
+
+---
+
+## M2 · 招标文件解读
+
+### FR-M2-01 上传招标文件 · P0
+
+- 支持格式：PDF（文字版 / 扫描版）、DOCX、DOC、WPS。非 PDF 文件统一转成 PDF 后再处理，保证页码出处一致。
+- **按文件头识别真实格式，不看扩展名**：样本里 10 份都叫 `.doc`，实际有 DOCX、不压缩的 zip 形式 DOCX、旧版 DOC 三种（07 F2）。
+- 解析 Word 时**保留文字格式**（斜体、下划线、加粗），因为有的文件用格式标注实质性条款（07 F1）。
+- 一个项目可以上传多个招标文件，比如正文和附件分开的情况。每个文件标注类型：招标文件 / 补遗 / 澄清答复。
+- 单文件大小和页数上限按套餐区分，购买页和上传页都要写明（具体数字随 D2 一起定）。
+
+**验收**
+- 上传前就校验格式和页数，超出上限时直接说明原因和上限值，不创建任务、不扣点。
+- 加密或损坏的 PDF 能识别出来，提示用户换文件。
+
+### FR-M2-02 解析任务与进度 · P0
+
+- 解析是异步任务，状态有：排队中 → 解析中（分阶段）→ 成功 / 失败 / 已取消。
+- 发起时预扣 1 次解析；成功后结算；失败、超时、取消都退回。
+
+**验收**
+- 进度页显示当前阶段，用户离开后任务继续跑，完成或失败都发站内通知。
+- 失败可以重试，重试不重复扣点；额度明细里能看到「预扣 → 退回」两条记录。
+- 300 页以内目标 10 分钟完成（PRD 7，上线前压测回填）。
+
+### FR-M2-03 项目基本信息提取 · P0 [新增：拆出单列]
+
+提取项目名称、项目编号、采购人 / 招标人、代理机构、采购方式、预算金额 / 最高限价（按包）、包的划分、是否接受联合体、是否接受进口产品、是否专门面向中小企业、适用的法律体系（政府采购 / 招标投标）。
+
+**验收**：每个字段都带出处；用户可以修改，修改留痕。
+
+### FR-M2-04 分包识别与选择 · P0 [新增]
+
+- 识别包 / 标段，以及每个包的预算、限价、资格、参数；
+- 用户选择要投的包，清单按「通用 + 所选包」过滤。
+
+**验收**：没有分包时自动跳过这一步；分包识别错了用户能手工增删和归属。
+
+### FR-M2-05 结构化提取 · P0
+
+按五类生成清单项：PRD 的四类，加上 IT 集成需要的「技术参数」。字段定义见 `05-it-integration-domain.md` §3。
+
+| 类别 | 内容 |
+|---|---|
+| 资格条件 | 通用资格 + 特定资格 + 信用要求，以及每条要求的证明材料 |
+| 无效 / 废标条款 | 法规列明的情形 + 招标文件自己规定的情形 + 所有 ★ 实质性条款 |
+| 评分办法 | 评标方法、价格 / 技术 / 商务分值、每个评分项（分值、标准、证明材料）、中小企业价格扣除 |
+| 关键日期与递交 | 截止时间、开标时间、提疑 / 质疑截止、保证金、投标有效期、递交方式、份数、签章、密封 / 加密 |
+| 技术参数 | 参数项、要求值、比较方式（≥ ≤ = 包含 支持）、重要性（★ / ▲ / 一般）、所属包 |
+
+**验收**
+- 每条清单项至少有一个出处（文件 + 页码 + 原句）；没有出处的进「待确认」区（FR-M2-07）。
+- ★ 条款全部进入「无效 / 废标」类，同时保留在原来的类别里（同一条要求可以有多个类别标签）。
+- **实质性条款按文件自己的标注规则识别**：先找到「标注规则说明」（★ / * / 斜体加下划线 / 「必须」字样等），再按规则识别；不能写死成 ★（07 F1）。
+- 文件写明了实质性条款数量时（如「★ 项共 14 条」），和实际抽到的数量对比，不一致就提示用户。
+- 用 3 份以上真实 IT 集成招标文件做基准测试：人工标注的 ★ 条款**召回率**是主要指标（漏了就可能废标），具体目标在技术方案阶段定。
+
+### FR-M2-06 原文回链 · P0
+
+- 清单和原文并排显示，点击清单项就跳到对应页并高亮原句；一条可以有多个出处。
+- 扫描件按 OCR 文字坐标高亮。
+
+**验收**：抽查 50 条，出处页码正确率和高亮准确率都要达到目标值（技术方案阶段定）；出处无法定位时，宁可进「待确认」，也不能给一个错的页码。
+
+### FR-M2-07 待确认区 · P0
+
+- 没有出处、或模型置信度低于阈值的提取结果，放进待确认区，不进正式清单。
+- 用户操作：采纳（补上出处，或标注「人工确认、无出处」）/ 修改后采纳 / 丢弃。
+
+**验收**：待确认区的条目不参与 M3 检查。
+
+### FR-M2-08 项目检查清单 · P0
+
+- 解读结果自动生成清单，用户可以新增、修改、删除条目，所有修改都留痕（谁、什么时候、改前、改后）。
+- 清单整体状态：草稿 → 已确认；确认后再改，回到草稿并保留历史。
+- 用户新增的条目标注「人工添加」，可以没有出处。
+
+**验收**：任意一条都能查到完整的修改历史；删除是软删除，可以恢复。
+
+### FR-M2-09 关键日期展示 · P0 [新增：拆出单列]
+
+把关键日期汇总成项目时间线，在项目工作台显示倒计时。MVP 只做站内展示，不做主动提醒（截止日提醒放在 P1，和澄清辅助一起做）。
+
+### FR-M2-10 补遗追加（简化版）· P0 [新增]
+
+- 追加的补遗 / 澄清文件单独解析，扣 1 次解析；新提取的条目标注来源，并入清单。
+- 日期类字段以最新文件为准，在旧值上标「已被补遗 N 更新」，用户确认。
+- 不自动判断条目「新增 / 变更 / 作废」（P1）。
+
+---
+
+## M3 · 废标风险检查
+
+### FR-M3-01 上传投标文件 · P0
+
+- 一个项目可以上传多个投标文件分册（商务 / 技术 / 报价 / 资格证明），格式同 FR-M2-01。
+- 只处理加密前的 Word / PDF 稿；如果上传的是电子投标平台的加密格式，要识别出来并说明原因。
+- 分册可以对应到电子投标客户端的节点（如苏采云的资格审查、符合性审查、商务、技术、报价节点），具体怎么对应，等种子用户访谈后确定（G15）。
+- 投标文件有版本：每次重新上传都是新版本，检查结果关联到具体版本。
+
+### FR-M3-02 发起检查 · P0
+
+- 前提：项目至少有一份解析成功的招标文件。清单没确认时可以检查，但要提示「清单未确认，检查结果以当前清单为准」。
+- 按 `01-scope-roles.md` §4 的计费口径扣点；同一项目 24 小时内复查不扣点。
+- 每次检查产生一个「检查批次」，记下当时的清单版本、投标文件版本和规则版本。
+
+### FR-M3-03 响应完整性检查 · P0
+
+对每条清单项，在投标文件里找对应的响应：
+
+| 结论 | 含义 | 默认级别 |
+|---|---|---|
+| 已响应 | 找到了明确响应 | 不生成问题 |
+| 未找到响应 | 所有分册里都没找到 | 按清单项类别定（见下表） |
+| 负偏离未说明 | 偏离表或正文里有不满足的地方，但没有说明 | 同上 |
+| 疑似不满足 | 技术参数的响应值，按比较方式判断不满足要求（如要求 ≥ 32GB，响应 16GB） | 同上 |
+
+级别规则：
+
+| 清单项 | 致命 | 重要 | 提示 |
+|---|---|---|---|
+| ★ 条款、资格条件、无效 / 废标条款 | ✓ | | |
+| ▲ 参数、评分项缺证明材料 | | ✓ | |
+| 一般参数、其他 | | | ✓ |
+
+**验收**
+- 每个问题都带两边的出处：招标原文，和投标原文（「未找到」时写明找过哪些分册、哪些章节）。
+- 每个问题都对应一条清单项；用户能从问题跳到清单项，也能反过来。
+
+### FR-M3-04 形式要件检查 · P0
+
+分成两类，分开显示：
+
+- **可自动检查**：投标函、授权书等格式文件是否齐全，是否改动了格式文件里的固定文字；签字 / 盖章位置**有没有**（只看有无，不鉴定真伪，界面写明）；落款日期是否合理；文件里有没有出现其他项目的名称、编号或采购人（照搬旧标书留下的）。
+- **需人工核对**：份数、装订密封、递交方式、CA 加密等，文件里看不出来。这些生成「请核对」条目，用户勾选确认。
+
+### FR-M3-05 资质匹配检查 · P0
+
+- 每条资格条件和评分项要求的证明材料，都要在投标文件中找到对应材料。
+- 如果有资质库（FR-M6-08），再用投标截止日判断证书有没有过期，等级够不够。
+- 三种预警：过期 / 等级不足 / 未覆盖。资质数据只来自用户自己的资质库和投标文件，系统不从外部补数据。
+
+### FR-M3-06 报价形式检查 · P0 [新增：从 P1 拆出并升级]
+
+只检查**形式**，不评价报价是否合理，也不建议报价：
+
+- 投标报价是否超过限价，按三层检查：总价限价、采购包限价、分项限价 / 单价上限（07 F6）。超限在政府采购和招投标两个体系里都是法定无效 / 否决情形，见 05 §2；
+- 开标一览表和分项报价表的合计是否一致；大写和小写金额是否一致。注意：苏采云范本规定开标一览表和分项不一致时「不作无效处理，以开标一览表为准」，所以这项定为「重要」，不是「致命」，说明里要引用原文；
+- 只给一个报价（招标文件允许备选方案的除外）。
+
+**验收**：报价数字只从投标文件读取，界面上没有任何「建议报价 / 报价区间」的字样。
+
+### FR-M3-07 人工确认 · P0
+
+- 每个问题的状态：待处理 → 已确认无误 / 已修改 / 忽略（必须填原因）。
+- 还有没处理的「致命」问题时，项目就绪状态是「未就绪」，但**不阻止导出**。
+- 支持批量处理（仅限「提示」级）；每次处理都记录处理人和时间。
+- 每个问题都可以「反馈：判断有误」（J5）。
+
+### FR-M3-08 复查与状态沿用 · P0 [新增：明确规则]
+
+- 匹配规则：「清单项 + 问题类型」相同，就算同一个问题。
+- 问题还在：沿用上次的处理状态，标「沿用」；如果上次是「已修改」，改回「待处理」（说明没改好）。
+- 问题消失：自动关闭，标「本次已解决」；新出现的问题标「新增」。
+
+### FR-M3-09 检查报告导出 · P0
+
+PDF 报告内容：
+
+1. 首页：项目信息、投标文件版本、检查时间、规则版本、**检查覆盖范围**（查了什么、没查什么）、免责声明（辅助检查，不保证结果）；
+2. 汇总：各级别的问题数和处理状态；
+3. 问题明细：问题、出处、处理状态、处理人、时间、忽略原因；
+4. 附录：需人工核对的条目，以及勾选结果。
+
+**验收**：报告里不出现「通过 / 合格 / 保证」这类字样；生成的报告随项目归档，可以重复下载。
+
+---
+
+## M6 · 基础平台
+
+### FR-M6-01 项目工作台 · P0
+
+- 项目列表：名称、采购人、所投包、截止倒计时、状态、就绪状态、致命问题数。
+- 筛选：状态、截止时间区间；排序默认按截止时间。
+
+### FR-M6-02 项目状态流 · P0
+
+`跟进中 → 编制中 → 已检查 → 已递交 → 已归档`
+
+| 状态 | 进入条件 | 说明 |
+|---|---|---|
+| 跟进中 | 新建项目 | MVP 没有 M1，这个状态只是「刚创建」 |
+| 编制中 | 第一份招标文件解析成功 | 自动 |
+| 已检查 | 完成过至少一次检查 | 自动；另有「就绪 / 未就绪」标记 |
+| 已递交 | 用户手动标记 | 项目改为只读；可以撤销（留痕） |
+| 已归档 | 用户手动操作 | 可以随时撤销归档 |
+
+就绪状态和项目状态分开存：只有「已检查」状态才显示就绪状态（G7）。
+
+### FR-M6-03 额度计量 · P0
+
+- 额度账户按企业主体建；流水类型：发放 / 预扣 / 结算 / 退回 / 过期 / 人工调整（必须填原因）。
+- 额度页：本期已用、剩余、按功能分布，流水可以查到具体是哪个项目、哪个任务。
+- 用到 80%、100% 时站内提醒，同一阈值每个周期只提醒一次。
+
+**验收**：任何一笔扣点都能对应到一个任务；任何失败任务都没有净扣点。
+
+### FR-M6-04 账号与企业主体 · P0 [新增]
+
+- 手机号 + 验证码注册 / 登录；注册时填企业名称（MVP 不做企业认证，G9）。
+- 同一个手机号只能属于一个企业主体；风控：同一账号异地多设备并发登录时提示并限制（PRD 8.5）。
+
+### FR-M6-05 套餐与开通 · P0 [新增]
+
+- 免费版注册就有。
+- 专业版：用户在线提交开通申请（企业名称、开票信息）→ 对公转账 → 运营后台确认到账后开通，并开发票（G8）。线上自助支付以后再做。
+- 套餐到期后：数据保留，只读；额度清零（按 PRD，额度有效期跟着订阅周期走）。
+
+### FR-M6-06 数据删除 · P0
+
+见 J4；保留策略见 G10。
+
+### FR-M6-07 审计留痕 · P0
+
+- 记录的事件：清单修改、清单确认、问题处理、报告导出、项目状态变更、删除、额度人工调整。
+- MVP 只存储，不提供用户自助导出（P2）；运营后台可以查询。
+
+### FR-M6-08 最小资质库 · P0 [新增：从 P1 拆出]
+
+- 条目：资质名称、类型（资质证书 / 体系认证 / 软件著作权 / 其他）、等级、证书编号、发证机构、有效期起止、附件。
+- 只在 M3 资质匹配里用；完整的资产库（业绩、人员、历史标书）是 V1。
+
+### FR-M6-09 运营后台（最小版）· P0 [新增]
+
+用户 / 企业查询、套餐开通与续费、额度调整（带原因）、查看漏报 / 误报反馈、查看解析 / 检查任务的失败日志。
diff --git a/docs/analysis/04-domain-model.md b/docs/analysis/04-domain-model.md
new file mode 100644
index 0000000..13debda
--- /dev/null
+++ b/docs/analysis/04-domain-model.md
@@ -0,0 +1,117 @@
+# 04 · 领域模型草案
+
+> 这是需求层面的概念模型，不是数据库设计。字段只列出决定业务规则的那些，物理建模留到技术架构阶段。
+> 核心是 PRD 第 5 章说的「**项目检查清单**」：M2 产出它，M3 拿它做核对，V1 的 M4 拿它做生成约束，M5 也挂在它上面。
+
+## 1. 实体关系
+
+```mermaid
+erDiagram
+    Tenant ||--o{ User : "成员"
+    Tenant ||--o{ Subscription : "订阅"
+    Tenant ||--|| QuotaAccount : "额度账户"
+    QuotaAccount ||--o{ QuotaEntry : "流水"
+    Tenant ||--o{ Qualification : "资质库"
+    Tenant ||--o{ Project : "投标项目"
+
+    Project ||--o{ Lot : "包/标段"
+    Project ||--o{ SourceDocument : "招标文件/补遗/投标文件"
+    SourceDocument ||--o{ ParseJob : "解析任务"
+    SourceDocument ||--o{ Citation : "被引用"
+    Project ||--|| Checklist : "项目检查清单"
+    Checklist ||--o{ ChecklistItem : "清单项"
+    ChecklistItem }o--o{ Citation : "出处"
+    ChecklistItem }o--o| Lot : "所属包(空=通用)"
+
+    Project ||--o{ CheckRun : "检查批次"
+    CheckRun ||--o{ Finding : "问题"
+    Finding }o--|| ChecklistItem : "对应清单项"
+    Finding }o--o{ Citation : "双方出处"
+    Finding |o--o| Finding : "沿用自上次"
+    CheckRun ||--o| Report : "检查报告"
+
+    QuotaEntry }o--o| ParseJob : "关联任务"
+    QuotaEntry }o--o| CheckRun : "关联任务"
+```
+
+所有业务实体都带 `tenant_id`，按租户隔离（PRD 7）。
+
+## 2. 实体说明
+
+| 实体 | 关键字段 | 说明 |
+|---|---|---|
+| **Tenant** 企业主体 | 名称、统一社会信用代码（可空）、当前套餐 | 额度和数据的归属单位（PRD 4.3：额度绑定企业主体） |
+| **User** 用户 | 手机号、所属租户、角色 | MVP 一个租户一个成员；角色字段先留着，给 V1 用 |
+| **Subscription** 订阅 | 套餐、起止日期、来源（注册赠送 / 人工开通 / 线上支付） | |
+| **QuotaAccount / QuotaEntry** 额度 | 单位（解析 / 检查 / 生成 / 查重）、类型（发放 / 预扣 / 结算 / 退回 / 过期 / 调整）、数量、关联任务、原因 | 只追加、不修改；余额由流水算出来 |
+| **Qualification** 资质 | 名称、类型、等级、证书号、发证机构、有效期、附件 | MVP 最小资质库 |
+| **Project** 投标项目 | 名称、编号、采购人、代理机构、采购方式、**法律体系**、截止时间、状态、所投包 | 基本信息来自 FR-M2-03，用户可以改 |
+| **Lot** 包 / 标段 | 包号、名称、预算、最高限价、是否投标 | 没有分包时只有一个默认包 |
+| **SourceDocument** 文档 | 角色（招标文件 / 补遗 / 澄清 / 投标分册）、分册名、版本号、原始文件、规范化 PDF、页数、解析状态 | 所有文件都转成规范化 PDF，作为出处页码的唯一依据 |
+| **ParseJob** 解析任务 | 状态、阶段、模型与提示词版本、耗时、失败原因 | 一份文档可以有多次任务（重试） |
+| **Citation** 出处 | 文档、页码、原句、坐标范围 | 「可复核」的载体；清单项和问题共用 |
+| **Checklist** 检查清单 | 状态（草稿 / 已确认）、版本号、确认人、确认时间 | 每个项目一份；每次确认生成新版本 |
+| **ChecklistItem** 清单项 | 类别标签（可以多个）、标题、要求原文、重要性（★ / ▲ / 一般）、所属包、证明材料要求、比较方式与要求值（参数类）、来源（AI / 人工 / 补遗 N）、状态（待确认区 / 正式 / 已删除）、置信度 | 见 05 §3 |
+| **CheckRun** 检查批次 | 清单版本、投标文件版本集合、规则版本、状态、是否扣点 | 可以复现「当时根据什么做的判断」 |
+| **Finding** 问题 | 类型（未响应 / 负偏离未说明 / 疑似不满足 / 形式 / 资质 / 报价形式 / 人工核对）、级别、说明、出处、处理状态、忽略原因、处理人、处理时间、沿用来源 | |
+| **Report** 报告 | 文件、生成时间、生成人 | 生成后不再改动；重新导出就生成新报告 |
+| **AuditEvent** 审计事件 | 操作人、动作、对象、修改前、修改后、时间 | 不在上图中，所有实体都会写 |
+| **Feedback** 反馈 | 对象（问题 / 清单）、类型（误报 / 漏报）、说明、处理状态 | 进运营后台 |
+
+## 3. 状态机
+
+### 3.1 项目
+
+```mermaid
+stateDiagram-v2
+    [*] --> 跟进中: 新建
+    跟进中 --> 编制中: 首份招标文件解析成功
+    编制中 --> 已检查: 完成首次检查
+    已检查 --> 已检查: 复查
+    已检查 --> 已递交: 用户标记
+    已递交 --> 已检查: 撤销递交(留痕)
+    已检查 --> 已归档: 用户归档
+    已递交 --> 已归档: 用户归档
+    已归档 --> 已检查: 撤销归档
+    已归档 --> 已递交: 撤销归档(原状态为已递交)
+```
+
+「就绪 / 未就绪」是项目上单独的一个标记，不是状态：只要最近一次检查批次里还有「待处理」的致命问题，就是未就绪。
+
+### 3.2 解析任务
+
+```mermaid
+stateDiagram-v2
+    [*] --> 排队中: 发起(预扣1次)
+    排队中 --> 解析中
+    排队中 --> 已取消: 用户取消(退回)
+    解析中 --> 成功: 结算
+    解析中 --> 失败: 退回
+    解析中 --> 已取消: 用户取消(退回)
+    失败 --> 排队中: 重试(重新预扣)
+```
+
+### 3.3 问题（Finding）
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待处理
+    待处理 --> 已确认无误
+    待处理 --> 已修改
+    待处理 --> 已忽略: 必填原因
+    已确认无误 --> 待处理: 撤销
+    已修改 --> 待处理: 撤销
+    已忽略 --> 待处理: 撤销
+    note right of 待处理
+      复查时：问题仍在 → 沿用状态(已修改改回待处理)
+      问题消失 → 本次已解决
+    end note
+```
+
+## 4. 关键设计约束
+
+1. **出处统一用规范化 PDF 的页码**：Word 没有稳定的页码，必须先转成 PDF。转换结果存下来，以后不要重新生成，否则老的出处会对不上。
+2. **清单有版本**：检查批次引用的是清单的某个版本，后面再改清单，不影响历史报告。
+3. **额度流水只追加**：账户余额由流水算出来，所以「失败不扣点」可以从流水验证。
+4. **AI 产出记录模型和提示词版本**：解析任务、检查批次都要记，这样漏报复盘时能知道是哪个版本出的问题。
+5. **租户隔离**：所有查询都必须带租户条件；私有化（P2）时一个部署就是一个租户，模型不需要改。
diff --git a/docs/analysis/05-it-integration-domain.md b/docs/analysis/05-it-integration-domain.md
new file mode 100644
index 0000000..4be0ae6
--- /dev/null
+++ b/docs/analysis/05-it-integration-domain.md
@@ -0,0 +1,130 @@
+# 05 · IT 集成领域知识（M2 提取 schema 与 M3 规则种子）
+
+> D1 决定 IT 集成先行。本文是需求分析阶段整理的领域知识，用来确定 M2 提取什么、M3 检查什么。
+> **证据等级**：标「已核实」的条款本次查到了原文或权威转述；标「待核对」的是按通行理解整理的，进入规则配置前必须对照法规原文。所有规则还要用真实招标文件样本验证（§6）。
+
+## 1. 先判断项目适用哪个法律体系
+
+IT 集成项目的采购人大量是政府机关、事业单位，**多数走政府采购体系**；国企采购、含信息化的工程建设项目走招标投标体系。两套体系的术语、无效情形、审查流程都不一样，所以 M2 要先识别体系（FR-M2-03），M3 再按体系套用规则。
+
+| 维度 | 政府采购体系 | 招标投标体系 |
+|---|---|---|
+| 主要依据 | 《政府采购法》及实施条例；《政府采购货物和服务招标投标管理办法》（财政部令第 87 号，2017-10-01 起施行，已核实）；非招标方式按财政部令第 74 号、竞争性磋商按财库〔2014〕214 号 | 《招标投标法》及实施条例 |
+| 采购方式 | 公开招标、邀请招标、竞争性谈判、竞争性磋商、询价、单一来源、框架协议等 | 公开招标、邀请招标 |
+| 角色称呼 | 采购人、采购代理机构、供应商 / 投标人 | 招标人、招标代理机构、投标人 |
+| 不合格的叫法 | **投标无效**（竞争性磋商叫「无效响应」，文件也叫「响应文件」，见 07 F4） | **否决投标** / 废标 |
+| 审查环节 | 资格审查 → 符合性审查 → 比较评价 | 初步评审（形式 / 资格 / 响应性）→ 详细评审 |
+| 异常低价 | 87 号令第 60 条：报价明显低于其他投标人，可能影响质量或诚信履约，评标委员会应要求书面说明；不能证明报价合理的，作无效投标处理（**已核实**） | 实施条例第 51 条：投标报价低于成本的，应否决（待核对） |
+| 投标保证金上限 | 不超过采购项目预算金额的 2%（实施条例第 33 条，待核对） | 不超过招标项目估算价的 2%（实施条例第 26 条，待核对） |
+
+> ⚠️ **影响 PRD 口径**：PRD 1.5 和 M3 把「异常低价否决」完全归为《招标投标法》修订草案的「草案层」。但对走政府采购的 IT 集成项目，87 号令第 60 条已经是现行规定。见 `06-gaps-and-questions.md` G2。
+
+## 2. 法定的无效 / 否决情形（M3 规则的法规来源）
+
+### 2.1 政府采购：87 号令第 63 条，投标无效（待核对）
+
+1. 没有按招标文件规定提交投标保证金；
+2. 投标文件没有按招标文件要求签署、盖章；
+3. 不具备招标文件规定的资格要求；
+4. 报价超过招标文件规定的预算金额或最高限价；
+5. 投标文件含有采购人不能接受的附加条件；
+6. 法律、法规和招标文件规定的其他无效情形。
+
+### 2.2 招标投标：实施条例第 51 条，否决投标（待核对）
+
+1. 没有经过投标单位盖章和单位负责人签字；
+2. 联合体投标没有提交共同投标协议；
+3. 不符合国家或招标文件规定的资格条件；
+4. 同一投标人提交两个以上不同的投标文件或报价（招标文件要求提交备选投标的除外）；
+5. 报价低于成本或高于最高投标限价；
+6. 没有对招标文件的实质性要求和条件作出响应；
+7. 有串通投标、弄虚作假、行贿等违法行为（产品不检查这一项）。
+
+### 2.3 政府采购供应商的通用资格（《政府采购法》第 22 条，待核对）
+
+独立承担民事责任的能力；良好的商业信誉和健全的财务会计制度；履行合同必需的设备和专业技术能力；依法缴纳税收和社会保障资金的良好记录；参加政府采购活动前三年内没有重大违法记录；法律、行政法规规定的其他条件。招标文件通常还会要求信用查询（信用中国、中国政府采购网的失信记录）。
+
+## 3. M2 提取 schema（IT 集成）
+
+招标文件的章节名称和顺序各地不一样，**提取不能依赖章节编号**。常见结构：招标公告 → 投标人须知（含前附表）→ 评标办法（资格 / 符合性审查表、评分标准）→ 采购需求（技术参数）→ 合同条款 → 投标文件格式。
+
+### 3.1 项目基本信息
+
+| 字段 | 备注 |
+|---|---|
+| 项目名称、项目编号 | 编号也用来检查投标文件里有没有写错 |
+| 采购人、代理机构 | 同上 |
+| 法律体系、采购方式 | 决定使用哪套规则 |
+| 包划分；每个包的预算、最高限价 | 报价形式检查要用 |
+| 是否接受联合体、进口产品；是否专门面向中小企业 | |
+| 评标方法 | 综合评分法 / 最低评标价法 |
+
+### 3.2 清单项通用字段
+
+| 字段 | 说明 |
+|---|---|
+| 类别标签 | 资格 / 无效条款 / 评分 / 日期与递交 / 技术参数 / 格式文件（可以有多个） |
+| 要求原文 | 原句，不改写 |
+| 要求摘要 | AI 生成的简短说明，界面标注是 AI 生成 |
+| 重要性 | ★ 实质性 / ▲ 重要 / 一般。常见用 ★ 标实质性条款、用 ▲ 标重要指标，但**样本中 3 / 10 份用「斜体 + 下划线」标实质性条款**（07 F1），所以必须先提取文件里的「标注规则说明」原文，再按规则识别 |
+| 所属包 | 空表示所有包通用 |
+| 证明材料要求 | 例如「提供合同关键页复印件及中标通知书」 |
+| 出处 | 一个或多个 Citation |
+
+### 3.3 各类别特有字段
+
+| 类别 | 特有字段 |
+|---|---|
+| 资格 | 资格类型（通用 / 特定 / 信用）、有效期要求（如「近 3 个月社保缴纳证明」） |
+| 无效条款 | 来源（法规列明 / 招标文件规定 / ★ 条款引申） |
+| 评分 | 评分因素、分值、评分标准、所属部分（价格 / 技术 / 商务）、中小企业价格扣除规则 |
+| 日期与递交 | 日期类型（提疑截止 / 投标截止 / 开标 / 保证金截止）、具体时间；保证金金额与形式；投标有效期；递交方式（电子 / 纸质 / CA 加密）；正副本份数；签章要求；密封要求 |
+| 技术参数 | 参数名、要求值、单位、比较方式（≥ ≤ = 包含 支持 / 具备）、所属设备或系统 |
+| 格式文件 | 格式名称（投标函、开标一览表、授权委托书、偏离表、中小企业声明函等）、是否允许修改 |
+
+## 4. IT 集成投标文件的常见结构（M3 检查对象）
+
+投标函；开标一览表（报价一览表）；分项报价表；法定代表人身份证明 / 授权委托书；资格证明文件（营业执照、财务报告或银行资信证明、纳税和社保证明、无重大违法记录声明、信用查询截图）；技术参数响应 / 偏离表；商务条款响应 / 偏离表；技术方案；实施与售后服务方案；类似项目业绩证明；资质与认证证书；中小企业声明函；各类承诺函。
+
+## 5. M3 规则种子清单（IT 集成 v0）
+
+| # | 规则 | 依据类型 | 自动化程度 | 默认级别 |
+|---|---|---|---|---|
+| R01 | 投标函、开标一览表等要求签章的位置没有签字 / 盖章 | 法规（2.1-2 / 2.2-1） | 半自动（有无检测，用户复核） | 致命 |
+| R02 | 缺少授权委托书，或授权代表和签字人不一致 | 招标文件 | 自动 | 致命 |
+| R03 | 报价超过限价（总价 / 采购包 / 分项或单价三层） | 法规（2.1-4 / 2.2-5） | 自动 | 致命 |
+| R04 | 开标一览表和分项报价合计不一致；大写和小写金额不一致（苏采云范本：不一致时不作无效，以开标一览表为准） | 招标文件 | 自动 | 重要 |
+| R05 | ★ 条款未响应 / 负偏离 / 疑似不满足 | 招标文件 | 自动 | 致命 |
+| R06 | ▲ 参数未响应 / 疑似不满足 | 招标文件 | 自动 | 重要 |
+| R07 | 资格证明材料缺失 | 法规（2.1-3 / 2.2-3） | 自动 | 致命 |
+| R08 | 资格证明过期或时效不够（按投标截止日算） | 招标文件 | 自动（需要资质库或文件里的日期） | 致命 |
+| R09 | 投标有效期短于要求 | 招标文件 | 自动 | 致命 |
+| R10 | 投标保证金的金额、形式与要求不符，或缺少缴纳凭证 | 法规（2.1-1） | 半自动 | 致命 |
+| R11 | 出现附加条件，例如「价格不含税」「付款方式另议」 | 法规（2.1-5） | 半自动（语义识别，用户复核） | 重要 |
+| R12 | 联合体投标缺少共同投标协议 | 法规（2.2-2） | 自动 | 致命 |
+| R13 | 不接受进口产品，却响应了进口产品 | 招标文件 | 半自动 | 致命 |
+| R14 | 改动了格式文件里的固定文字 | 招标文件 | 自动（和格式模板比对） | 重要 |
+| R15 | **文件里出现其他项目的名称、编号或采购人**（照搬旧标书留下的） | 实践 | 自动 | 重要 |
+| R16 | 落款日期晚于投标截止日，或者明显不合理 | 实践 | 自动 | 提示 |
+| R17 | 中小企业声明函格式或内容和要求不符 | 招标文件 | 半自动 | 提示 |
+| R18 | 评分项要求的证明材料缺失 | 招标文件 | 自动 | 重要 |
+| R19 | 份数、装订密封、递交方式、CA 加密 | 招标文件 | 人工核对 | 提示 |
+| R20 | 电子平台操作：按期通过平台获取招标文件（确认函）、CA 证书有效、提交线上投标文件、开标后按时解密（07 F7） | 招标文件 | 人工核对 | 重要 |
+
+说明：「依据类型」写进报告，说明每条问题的来源；「实践」类规则在报告里只能用「风险提示」的措辞。
+
+## 6. 样本语料
+
+> **进展（2026-11-02）**：第一批 10 份苏采云样本已入库，见 `samples/tenders/`，分析结论见 `07-sample-findings.md`。还缺扫描件、补遗和招标投标体系的样本。
+
+原计划：在原型和技术选型之前，收集 **5–10 份公开的 IT 集成招标文件**（可以从中国政府采购网和各省的政府采购网下载，都是公开信息），要覆盖：
+
+- 公开招标 / 竞争性磋商；
+- 分包 / 不分包；
+- 文字 PDF / 扫描件；
+- 至少 1 份有补遗；
+- 至少 1 份走招标投标体系的国企信息化项目。
+
+用途：① 确认 §3 schema 够不够用；② 人工标注 ★ 条款，作为 M2 召回率的基准；③ 原型用的样例数据；④ 技术选型时做解析和 OCR 测试。
+
+如果能拿到对应的真实投标文件（脱敏后），可以作为 M3 的基准。这需要种子用户配合。
diff --git a/docs/analysis/06-gaps-and-questions.md b/docs/analysis/06-gaps-and-questions.md
new file mode 100644
index 0000000..5cef5c8
--- /dev/null
+++ b/docs/analysis/06-gaps-and-questions.md
@@ -0,0 +1,93 @@
+# 06 · PRD 缺口与待确认问题
+
+> 需求分析中发现的 PRD 缺失、矛盾或需要拍板的地方。每条都给了建议；用户确认后结论写入 `docs/decisions.md`，并回填相关文档。
+> 优先级：🔴 阻塞 MVP 设计 / 🟡 影响 MVP 细节 / 🟢 留到后面的阶段
+>
+> **状态（2026-11-02）**：G1–G10 全部按建议确认（`docs/decisions.md` A1），G2 已出 PRD v0.9.1；G11 由 T1（国产云端模型 + 按场景路由）部分决策；G12–G14 留到技术架构阶段。
+
+## 需要用户拍板
+
+### 🔴 G1 · 法律体系的双轨识别
+
+- **问题**：PRD 的政策依据只覆盖《招标投标法》体系，但 IT 集成项目多数走政府采购体系，术语（投标无效 / 否决投标）、无效情形和审查流程都不一样。
+- **建议**：M2 识别项目适用的体系，M3 按体系套用规则，界面和报告的术语跟着项目体系走（见 05 §1）。PRD 1.5 补充政府采购体系的依据。
+- ✅ **已决策**：按建议执行，PRD v0.9.1 新增「政策三」。
+
+### 🔴 G2 · 「异常低价」的口径需要修订
+
+- **问题**：PRD 把「异常低价否决」完全归为草案层，但财政部令第 87 号第 60 条（现行有效，已核实）已经规定：报价明显偏低、又不能证明合理性的，作无效投标处理。对政府采购项目，这是**现行层**。
+- **建议**：PRD 的双层口径扩成按体系区分：政府采购体系的 87 号令第 60 条属于现行层；招标投标体系里，实施条例第 51 条的「低于成本否决」是现行层，修订草案的「异常低价否决」才是草案层。这一项本来是 P1，不影响 MVP 开发，但**对外宣传的口径**现在就要改。
+- ✅ **已决策**：已修订，见 `docs/招投标AI工具PRD-v0.9.1.html` 1.5、第 5 章表格、M3。
+
+### 🔴 G3 · 多包 / 多标段
+
+- **问题**：PRD 没有提到分包。IT 集成采购常分包，每个包的资格、限价、参数都不一样；不按包区分，清单会混入不投的包，报价检查也没法做。
+- **建议**：纳入 MVP（FR-M2-04）。
+
+### 🔴 G4 · 资质匹配的数据来源
+
+- **问题**：M3「资质匹配检查」是 P0，依赖「企业资质库」，但资产库在 M6 是 P1。
+- **建议**：MVP 做最小资质库（只有资质，没有业绩、人员、历史标书），手工录入、记录有效期（FR-M6-08）。同时，资质匹配首先核对投标文件里有没有对应的证明材料，资质库只用来判断过期和等级。
+
+### 🟡 G5 · 「检查」的计费口径
+
+- **问题**：PRD 8.2 说专业版「废标检查不限项目数（按解析额度计）」，8.3 又把「检查」定义成独立的计量单位；免费版是「1 个项目」，不是次数。
+- **建议**：「检查」是独立单位，展示给用户；专业版的检查从解析池扣，1 次检查 = 1 次解析；同一项目 24 小时内复查免费；投标文件的解析算在检查里，不另外扣。免费版 = 1 个项目，这个项目内的检查和复查不限次数（单份页数有限制）。
+
+### 🟡 G6 · 加量包是否在 MVP 里
+
+- **建议**：MVP 不做线上加量包，由运营后台人工调整额度（带原因）。种子期用户少，先看用量分布，再定加量包的档位（和 D2 一起定）。
+
+### 🟡 G7 · 清单确认是否卡住检查
+
+- **建议**：不卡。清单没确认也能检查，但检查页和报告首页都要写明「清单未经确认」。这和 PRD「决定权在用户」的原则一致。
+
+### 🟡 G8 · 专业版怎么开通和付款
+
+- **问题**：PRD 没写支付。企业客户普遍要对公转账和增值税专用发票。
+- **建议**：MVP 第一阶段：用户在线提交开通申请 → 对公转账或付款码 → 运营后台人工开通并开发票。线上自助支付（微信 / 支付宝）在付费用户数量起来之后再做。
+
+### 🟡 G9 · 要不要做企业认证
+
+- **建议**：MVP 注册只填企业名称，不做营业执照认证。PRD 8.5 的「额度绑定企业主体」先通过「一个手机号只属于一个企业 + 异地并发登录风控」来实现。企业认证随团队版（V1）一起上。
+
+### 🟡 G10 · 「用户可以删除」和「全程留痕」冲突
+
+- **问题**：PRD 7 要求用户能自助删除数据，4.1 要求全程留痕；修订草案还拟要求资料至少保存 15 年（尚在审议、未施行）。
+- **建议**：用户删除项目时，业务内容（文件、清单、报告）彻底删除；保留不含业务内容的审计记录（操作类型、时间、项目编号的哈希）和额度流水。15 年保存是招标投标**当事人**的义务，不是工具提供方的；产品可以提示用户自己归档报告，平台不替用户保管。等草案通过后再复核。
+
+## 需要在技术架构阶段决定
+
+### 🔴 G11 · 用哪个大模型，以及国内合规
+
+- **问题**：SaaS 面向国内企业，标书属于敏感经营数据。要考虑：① 调用境外模型会涉及数据出境；② 《生成式人工智能服务管理暂行办法》下的备案和登记义务；③ 企业版要求模型私有化部署（PRD 7）。
+- **建议**：技术架构阶段做模型选型时专门评估，倾向于选用已备案的国产模型，并能私有化部署；具体的合规结论要找法务确认。PRD 7 已经写了「SaaS 版数据不用于训练公共模型」，需要和模型供应商的协议对齐。
+- ✅ **部分决策（T1）**：全部使用国内云端国产模型，不出境；按场景路由到多模态 / 快速 / 深度思考模型。**还剩**：确认所选模型都已备案、供应商协议里写明「数据不用于训练」、本产品自身的登记义务（法务确认）、企业版私有化时用什么模型（P2）。
+
+### 🟡 G12 · 签章检测的技术可行性
+
+- **问题**：「签字盖章位置有无」需要在 PDF 和扫描件里识别印章、手写签名，这需要视觉能力，准确率不确定。
+- **建议**：技术阶段用样本语料验证多模态模型（T1）的识别效果；如果准确率不够，R01 先降级为「请核对签章位置」，按人工核对处理（报告里写明）。
+
+### 🟢 G13 · 运营后台
+
+PRD 没提运营后台，但开通套餐、调额度、看反馈都离不开。MVP 做最小版（FR-M6-09），可以用现成的后台框架快速搭。
+
+### 🟢 G14 · 通知渠道
+
+PRD M1 提到站内、邮件、企业微信推送；MVP 只有额度提醒和解析完成提醒，建议只做站内通知 + 短信（注册时已经有短信能力）。
+
+## 种子用户访谈时确认
+
+### 🟡 G15 · 苏采云投标文件的实际准备方式（来自样本分析 07 F3）
+
+- **问题**：苏采云的投标文件是在「政府采购客户端工具」里按节点拼装的，导出的文件加密。产品只能检查导入客户端之前的材料。
+- **要问种子用户**：各节点的材料是先在 Word 里写好再导入，还是直接在客户端里填？最后一版的 Word / PDF 能不能方便地拿出来？
+- **影响**：M3 的上传方式和分册设计（FR-M3-01）。如果多数用户直接在客户端里填，M3 的输入方式要重新设计。
+
+## 已在文档中直接处理（不需要确认）
+
+- PRD M6 状态流没说「已检查」和「未就绪」是什么关系 → 拆成「状态」和「就绪标记」两个字段（04 §3.1）。
+- 复查时上次的处理结果怎么办 → 定了沿用规则（FR-M3-08）。
+- 「未找到响应」的问题没有投标文件这一侧的出处 → 改为写明搜索过的范围（FR-M3-03）。
+- 形式要件里有些项从文件里看不出来（份数、密封）→ 单独作为「需人工核对」一类（FR-M3-04）。
diff --git a/docs/analysis/07-sample-findings.md b/docs/analysis/07-sample-findings.md
new file mode 100644
index 0000000..8c9c584
--- /dev/null
+++ b/docs/analysis/07-sample-findings.md
@@ -0,0 +1,107 @@
+# 07 · 样本语料分析（苏采云 10 份）
+
+> 样本：`samples/tenders/`（S01–S10，均为江苏政府采购项目，2026-10 至 11 月发布）。方法：抽取纯文本后用正则统计结构特征，再人工抽查原文。
+> 目的：用真实文件验证 `05-it-integration-domain.md` 的提取 schema 和 M3 规则种子。下面的结论按对需求的影响排序。
+
+## 1. 统计概览
+
+| ID | 方式 | ★ | ▲ | 「无效」相关表述 | 分包 | 实质性条款标注方式 |
+|---|---|---|---|---|---|---|
+| S01 | 公开招标 | 30 | 15 | 18 | 无 | ★ |
+| S02 | 公开招标 | 12 | 8 | 14 | 无 | ★ |
+| S03 | 公开招标 | 30 | 33 | 23 | 无 | ★（文件写明「★ 项共 14 条」） |
+| S04 | 公开招标 | 30 | 22 | 13 | 无 | ★ |
+| S05 | 公开招标 | 1 | 0 | 12 | 无 | 只有文字说明 |
+| S06 | 公开招标 | 0 | 16 | 14 | 无（有分项限价） | **斜体 + 下划线** |
+| S07 | 公开招标 | 8 | 45 | 11 | 无 | ★ 或 *，以及「必须」「应」等字样 |
+| S08 | 竞争性磋商 | 0 | 8 | 10 | 无 | **斜体 + 下划线**；另有「实质性要求响应及偏离表」 |
+| S09 | 竞争性磋商 | 3 | 0 | 10 | 无 | ★ + **斜体 + 下划线** |
+| S10 | 公开招标 | 5 | 0 | — | **3 个采购包** | ★ |
+
+★ / ▲ 的计数包含说明性文字里的符号，不等于条款数，只用来看分布。
+
+## 2. 对需求的影响
+
+### 🔴 F1 · 实质性条款不能只靠 ★ 识别
+
+- 10 份里有 3 份（S05、S06、S08）基本没有 ★ 标记。**S06、S08、S09 用「斜体且有下划线」标注实质性要求**（S09 同时也用 ★）；S07 同时用 ★、* 和「必须 / 应当」字样。
+- **纯文本抽取会丢掉斜体和下划线**，S06、S08 的实质性条款会被全部漏掉。
+- **影响**：
+  - FR-M2-05：识别实质性条款时，先从文件里找到「标注规则说明」（例如「加注 ★ 的为实质性要求」「斜体且有下划线部分为实质性要求」），再按说明去识别，不能写死成 ★。
+  - 技术架构：解析 Word 时要保留文字格式（斜体、下划线、加粗），不能只取纯文本。
+  - 有的文件写明了 ★ 条款总数（S03「★ 项共 14 条」），可以用来自动检查有没有漏抽；数量对不上就提示用户。
+
+### 🔴 F2 · 文件扩展名不可信
+
+- 10 份全部叫 `.doc`，实际是 DOCX 6 份、DOCX（不压缩的 zip）2 份、旧版 DOC（WPS 生成）2 份。
+- **影响**：FR-M2-01 要按文件头识别真实格式，不能看扩展名；旧版 DOC 必须支持。
+
+### 🔴 F3 · 苏采云的投标文件是在客户端工具里制作的
+
+- 流程：下载 `.kedt` 文件 → 导入「政府采购客户端工具」→ 按节点填写或上传材料（S09 写「上传至符合性审查节点」）→ 导出加密的 zip → 上传。
+- **影响**：用户在客户端里拼装的最终文件是加密的，产品读不了。M3 只能检查用户在**导入客户端之前**准备的各节点材料（Word / PDF）。这正好对应我们的「多个分册」设计，但分册应该能对应到客户端的节点（资格审查、符合性审查、商务、技术、报价）。**需要找种子用户确认他们实际怎么准备文件**（新增 G15）。
+
+### 🟡 F4 · 政府采购体系内部，术语也随采购方式变化
+
+| | 公开招标 | 竞争性磋商 |
+|---|---|---|
+| 文件 | 招标文件 / 投标文件 | 磋商文件 / 响应文件 |
+| 须知 | 投标人须知 | 供应商须知 |
+| 评审 | 评标方法与评标标准 | 评审方法与评审标准 |
+| 不合格 | 投标无效 | 无效响应 / 响应无效 |
+| 有效期 | 投标有效期 | 磋商有效期 |
+
+**影响**：界面和报告的术语要跟着「采购方式」走，不只是跟着法律体系走。
+
+### 🟡 F5 · 苏采云文件用统一的六章范本
+
+10 份都是：第一章 公告 / 邀请 → 第二章 须知 → 第三章 合同文本 → 第四章 采购需求 → 第五章 评标（评审）方法 → 第六章 投标（响应）文件格式。
+
+**影响**：可以按地区维护「范本画像」（江苏范本：第二章抽无效条款和递交要求，第四章抽技术参数，第五章抽评分项），提高抽取准确率；没匹配上范本时再走通用抽取。这是首发聚焦江苏的一个实际好处。
+
+### 🟡 F6 · 报价规则比预想的细
+
+- **限价有三层**：总价、采购包限价（S10）、分项限价（S06），还有单价上限（S10）。任何一层超了都是无效。→ R03 要按三层检查。
+- **开标一览表和分项报价不一致，不按无效处理**，以开标一览表为准（S01、S05、S06 原文都这么写）。→ R04 保持「重要」，说明写清楚依据。
+- **异常低价**：**10 份全部**写入了 87 号令第六十条的原文（「不能证明其报价合理性的……作为无效投标处理」），这已经是苏采云范本的标准条款；S10 还给了明确阈值「投标报价低于最高限价 50%」。→ 进一步印证 G2；P1 的报价合理性检查应该**优先从招标文件中读取阈值**，没有阈值时才提示。
+
+### 🟡 F7 · 苏采云平台特有的无效情形
+
+- 「未在规定期限内通过苏采云获取招标文件的，投标无效」（S03）；
+- 「未提供线上投标文件的，投标无效」（S04）；
+- 开标后远程解密失败，文件会被退回（S01）。
+
+**影响**：R19「需人工核对」清单要加上平台操作类条目（获取文件确认函、CA 证书有效、按时解密）。这类条目价值高，又最容易被新手漏掉。
+
+### 🟡 F8 · 信创 / 国产化要求很常见
+
+10 份里有 5 份涉及信创 / 国产化（S01、S02、S05、S07、S08），常以 ★ 条款出现，例如「设备采用国产自主可控 CPU 芯片……提供国产化适配承诺函」。商用密码、等级保护也常见。
+
+**影响**：证明材料的类型要比原来想的多：承诺函、官网参数截图、检测报告、认证证书。M3 资质匹配要能识别这些类型。
+
+### 🟢 F9 · 资格材料有明确的时间窗口
+
+例如「参加政府采购活动前半年内（2026 年 05 月–2026 年 10 月）任一月的纳税凭据」。
+
+**影响**：R08 判断时效时，要从原文解析出时间窗口，并对照投标截止日。
+
+### 🟢 F10 · 用声明函代替原件
+
+江苏的通用条款：「提交各类声明函、承诺函，不再同时提供原件……中标后核查」。资格证明很多是声明函。
+
+**影响**：资格检查对声明函类材料只检查「有没有、签章全不全」，不核实内容。这和产品「不编造、不鉴定」的原则一致。
+
+## 3. 对 MVP 范围的确认
+
+| 已确认的 MVP 决策 | 样本里的证据 |
+|---|---|
+| G1 体系识别 | 10 份都是政府采购；还要细分到采购方式（F4） |
+| G2 异常低价口径 | 10 份全部写入第六十条原文，S10 写了阈值（F6） |
+| G3 多包 | S10 有 3 个采购包，各自有限价 |
+| 报价形式检查升为 P0 | 三层限价，超限即无效（F6） |
+
+## 4. 下一步
+
+1. 补齐样本缺口：扫描件、补遗、招标投标体系、配套投标文件（见 `samples/tenders/README.md`）。
+2. 人工标注 S01–S10 的实质性条款，作为 M2 召回基准。先标 S03（文件写明有 14 条 ★ 项）和 S06（斜体下划线）这两份最难的。
+3. 技术架构阶段，用这 10 份做 Word 解析选型，重点是保留文字格式、支持旧版 DOC、能定位页码。
diff --git a/docs/analysis/README.md b/docs/analysis/README.md
new file mode 100644
index 0000000..204b722
--- /dev/null
+++ b/docs/analysis/README.md
@@ -0,0 +1,32 @@
+# 需求分析（MVP · IT 集成）
+
+> 阶段：需求分析 · 2026-11-02 · 依据：PRD v0.9 + D1（IT 集成先行）
+
+| 文档 | 内容 |
+|---|---|
+| [01-scope-roles.md](01-scope-roles.md) | MVP 范围边界、角色、计费口径 |
+| [02-user-journeys.md](02-user-journeys.md) | 五条用户旅程（首次体验、真实项目迭代、额度、删除、反馈） |
+| [03-functional-requirements.md](03-functional-requirements.md) | 功能需求和验收标准（FR-M2 / M3 / M6） |
+| [04-domain-model.md](04-domain-model.md) | 领域模型、状态机、关键设计约束 |
+| [05-it-integration-domain.md](05-it-integration-domain.md) | IT 集成领域知识：法律体系、提取 schema、M3 规则种子 R01–R19 |
+| [06-gaps-and-questions.md](06-gaps-and-questions.md) | PRD 缺口与待确认问题 G1–G15 |
+| [07-sample-findings.md](07-sample-findings.md) | 苏采云 10 份样本分析：实质性条款标注、文件格式、报价规则等 F1–F10 |
+
+## 主要发现
+
+1. **IT 集成多数走政府采购体系**，PRD 的政策依据只覆盖招标投标体系，产品要先识别项目适用的体系（G1）。
+2. **87 号令第 60 条已经规定了异常低价无效**，PRD 把它归为「草案层」，对政府采购项目来说不准确，对外宣传的口径要改（G2）。
+3. **MVP 跑通还缺四块**：多包、最小资质库、报价形式检查、运营后台（G3、G4、FR-M3-06、G13）。
+4. **「项目检查清单」要有版本、有出处、按包划分**，它是全产品数据设计的核心（04）。
+5. **最大的技术风险**：★ 条款召回率、原文回链准确率、签章检测、模型合规（G11、G12）。建议先收集 5–10 份公开的 IT 集成招标文件做语料（05 §6）。
+
+## 决策状态
+
+- 2026-11-02：G1–G10 全部按建议确认（`docs/decisions.md` A1）；G2 已出 PRD v0.9.1。
+- 2026-11-02：大模型策略定为国产云端模型 + 按场景路由（T1）。
+
+## 下一步
+
+1. ~~收集样本语料~~：第一批 10 份已入库（`samples/tenders/`），结论见 07。后续补扫描件、补遗、招标投标体系的样本，并人工标注实质性条款。
+2. 进入主题 / 品牌设计和原型设计（原型样例数据改用真实样本 S10，它有 3 个采购包）。
+3. 技术架构：模型路由层、文档规范化与出处定位、签章检测可行性（G12）。
diff --git a/docs/decisions.md b/docs/decisions.md
new file mode 100644
index 0000000..cd4e3a1
--- /dev/null
+++ b/docs/decisions.md
@@ -0,0 +1,42 @@
+# 决策记录
+
+按时间倒序记录用户拍板的产品与工程决策。格式：编号 · 日期 · 决策 · 理由 · 影响。
+
+---
+
+## 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 集成商、软硬件设备供应商、信息化服务商的投标团队。
diff --git a/docs/招投标AI工具PRD-v0.9.1.html b/docs/招投标AI工具PRD-v0.9.1.html
new file mode 100644
index 0000000..3d91a62
--- /dev/null
+++ b/docs/招投标AI工具PRD-v0.9.1.html
@@ -0,0 +1,701 @@
+<!doctype html>
+<html lang="zh-CN">
+<head>
+<meta charset="utf-8" />
+<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
+<meta name="color-scheme" content="light dark" />
+<link rel="icon" href="data:," />
+<title>招投标AI工具PRD</title>
+<style>
+  :root{
+    --bg:#f7f7f5; --surface:#ffffff; --surface2:#efeeea; --ink:#1c2321; --ink2:#4c5651; --ink3:#7d8781;
+    --line:#dddcd4; --accent:#0f6b5c; --accent-ink:#0a4f43; --accent-soft:#e3efec;
+    --amber:#9a6a12; --amber-soft:#f7ecd2; --red:#a8372e; --red-soft:#f6e3e0;
+    --blue:#2b5ea7; --blue-soft:#e2eaf6;
+    --radius:10px;
+    --font:"PingFang SC","Hiragino Sans GB","Microsoft YaHei",system-ui,-apple-system,"Segoe UI",sans-serif;
+    --mono:ui-monospace,"SF Mono",Menlo,Consolas,monospace;
+  }
+  @media (prefers-color-scheme: dark){
+    :root{
+      --bg:#141716; --surface:#1d2220; --surface2:#262c29; --ink:#e8ebe9; --ink2:#b3bcb7; --ink3:#8a948e;
+      --line:#343b37; --accent:#3cb79e; --accent-ink:#7fd6c2; --accent-soft:#1e3530;
+      --amber:#d9a63f; --amber-soft:#3a2f16; --red:#e07a6e; --red-soft:#3d2320;
+      --blue:#7ba7dd; --blue-soft:#22334a;
+    }
+  }
+  *{box-sizing:border-box}
+  html{scroll-behavior:smooth}
+  body{margin:0;background:var(--bg);color:var(--ink);font-family:var(--font);font-size:15.5px;line-height:1.75;-webkit-font-smoothing:antialiased}
+  a{color:var(--accent-ink)}
+  .layout{display:grid;grid-template-columns:228px minmax(0,1fr);max-width:1180px;margin:0 auto;gap:0}
+  /* sidebar */
+  nav.toc{position:sticky;top:0;height:100vh;overflow-y:auto;padding:26px 18px 30px 22px;border-right:1px solid var(--line)}
+  nav.toc .doc-tag{font-size:11.5px;letter-spacing:.14em;color:var(--ink3);margin-bottom:6px}
+  nav.toc .doc-title{font-size:17px;font-weight:700;line-height:1.45;margin-bottom:4px}
+  nav.toc .doc-meta{font-size:12px;color:var(--ink3);margin-bottom:20px;line-height:1.6}
+  nav.toc a{display:block;color:var(--ink2);text-decoration:none;font-size:13.5px;padding:5px 8px;border-radius:6px;margin-bottom:1px}
+  nav.toc a:hover{background:var(--surface2);color:var(--ink)}
+  nav.toc a.active{background:var(--accent-soft);color:var(--accent-ink);font-weight:600}
+  nav.toc a.sub{padding-left:22px;font-size:12.5px}
+  main{padding:34px 40px 80px;min-width:0}
+  /* header */
+  .prd-head{border-bottom:2px solid var(--ink);padding-bottom:22px;margin-bottom:8px}
+  .prd-head h1{font-size:30px;line-height:1.3;margin:0 0 8px;font-weight:800;letter-spacing:.01em}
+  .prd-head .sub{font-size:16px;color:var(--ink2);margin:0 0 16px}
+  .meta-grid{display:flex;flex-wrap:wrap;gap:8px 26px;font-size:13px;color:var(--ink2)}
+  .meta-grid b{color:var(--ink);font-weight:600}
+  .status-pill{display:inline-block;background:var(--amber-soft);color:var(--amber);font-size:12px;font-weight:700;padding:2px 10px;border-radius:99px;vertical-align:2px;margin-left:8px}
+  section{padding-top:34px}
+  h2{font-size:21px;margin:0 0 6px;padding-bottom:8px;border-bottom:1px solid var(--line);display:flex;align-items:baseline;gap:10px}
+  h2 .no{font-family:var(--mono);font-size:13px;color:var(--accent);font-weight:700}
+  h3{font-size:16.5px;margin:22px 0 6px}
+  h4{font-size:14.5px;margin:16px 0 4px}
+  p{margin:7px 0}
+  .lede{color:var(--ink2)}
+  ul,ol{margin:6px 0 10px;padding-left:22px}
+  li{margin:3px 0}
+  .card{background:var(--surface);border:1px solid var(--line);border-radius:var(--radius);padding:16px 18px;margin:14px 0}
+  .card.accent{border-left:4px solid var(--accent)}
+  .card.warn{border-left:4px solid var(--amber)}
+  .card h4{margin-top:0}
+  .grid2{display:grid;grid-template-columns:1fr 1fr;gap:14px}
+  .grid3{display:grid;grid-template-columns:repeat(3,1fr);gap:14px}
+  table{width:100%;border-collapse:collapse;font-size:13.8px;margin:12px 0;background:var(--surface);border:1px solid var(--line);border-radius:var(--radius);overflow:hidden}
+  th,td{padding:9px 12px;text-align:left;vertical-align:top;border-bottom:1px solid var(--line)}
+  th{background:var(--surface2);font-weight:600;font-size:13px;color:var(--ink2)}
+  tr:last-child td{border-bottom:none}
+  td.num,th.num{text-align:right;font-variant-numeric:tabular-nums}
+  .tag{display:inline-block;font-size:11.5px;font-weight:700;padding:1px 8px;border-radius:99px;white-space:nowrap}
+  .p0{background:var(--red-soft);color:var(--red)}
+  .p1{background:var(--amber-soft);color:var(--amber)}
+  .p2{background:var(--surface2);color:var(--ink2)}
+  .yes{color:var(--accent);font-weight:700}
+  .part{color:var(--amber);font-weight:700}
+  .no{color:var(--ink3)}
+  .small{font-size:12.5px;color:var(--ink3)}
+  .src{font-size:12px;color:var(--ink3)}
+  .src a{color:var(--ink3)}
+  blockquote{margin:12px 0;padding:10px 16px;border-left:3px solid var(--line);color:var(--ink2);background:var(--surface)}
+  /* lifecycle */
+  .flow{display:flex;gap:0;margin:16px 0;flex-wrap:wrap}
+  .flow .step{flex:1 1 150px;background:var(--surface);border:1px solid var(--line);padding:12px 14px;position:relative}
+  .flow .step:first-child{border-radius:var(--radius) 0 0 var(--radius)}
+  .flow .step:last-child{border-radius:0 var(--radius) var(--radius) 0}
+  .flow .step + .step{border-left:none}
+  .flow .step .n{font-family:var(--mono);font-size:11px;color:var(--accent);font-weight:700}
+  .flow .step .t{font-weight:700;font-size:14.5px;margin:2px 0}
+  .flow .step .d{font-size:12.5px;color:var(--ink2);line-height:1.55}
+  .flow .step.wedge{border-color:var(--accent);background:var(--accent-soft)}
+  /* module blocks */
+  .module{border:1px solid var(--line);border-radius:var(--radius);background:var(--surface);margin:16px 0;overflow:hidden}
+  .module-head{padding:14px 18px 10px;border-bottom:1px solid var(--line);display:flex;flex-wrap:wrap;gap:6px 14px;align-items:baseline}
+  .module-head .mn{font-family:var(--mono);font-size:12px;font-weight:700;color:#fff;background:var(--accent);border-radius:6px;padding:2px 8px}
+  .module-head h3{margin:0;font-size:17px}
+  .module-head .crowd{margin-left:auto;font-size:12.5px}
+  .module-body{padding:6px 18px 14px}
+  /* pricing */
+  .price-grid{display:grid;grid-template-columns:repeat(4,1fr);gap:12px;margin:14px 0}
+  .tier{background:var(--surface);border:1px solid var(--line);border-radius:var(--radius);padding:16px}
+  .tier.hot{border:2px solid var(--accent)}
+  .tier .tn{font-weight:700;font-size:15px}
+  .tier .tp{font-size:24px;font-weight:800;margin:4px 0 2px}
+  .tier .tp span{font-size:13px;font-weight:500;color:var(--ink2)}
+  .tier ul{padding-left:18px;font-size:13px;color:var(--ink2)}
+  .tier .who{font-size:12.5px;color:var(--ink3);border-top:1px solid var(--line);padding-top:8px;margin-top:8px}
+  /* calculator */
+  .calc{background:var(--surface);border:1px solid var(--line);border-radius:var(--radius);padding:18px;margin:14px 0}
+  .calc .row{display:grid;grid-template-columns:1fr 1fr;gap:20px}
+  .calc label{font-size:13.5px;font-weight:600;display:block;margin-bottom:4px}
+  .calc input[type=range]{width:100%;accent-color:var(--accent)}
+  .calc .val{font-family:var(--mono);color:var(--accent-ink);font-weight:700}
+  .calc-out{margin-top:14px;background:var(--accent-soft);border-radius:8px;padding:12px 16px;font-size:14.5px}
+  /* roadmap */
+  .road{display:grid;grid-template-columns:repeat(4,1fr);gap:12px;margin:14px 0}
+  .phase{background:var(--surface);border:1px solid var(--line);border-radius:var(--radius);padding:14px 16px}
+  .phase .ph{font-family:var(--mono);font-size:11.5px;color:var(--accent);font-weight:700}
+  .phase h4{margin:4px 0 6px}
+  .phase ul{font-size:13px;padding-left:18px;color:var(--ink2)}
+  .gate{font-size:12.5px;background:var(--amber-soft);color:var(--amber);border-radius:6px;padding:6px 10px;margin-top:8px;line-height:1.55}
+  /* filter */
+  .filterbar{display:flex;gap:8px;flex-wrap:wrap;margin:12px 0 4px}
+  .filterbar button{font-family:var(--font);font-size:13px;padding:5px 14px;border-radius:99px;border:1px solid var(--line);background:var(--surface);color:var(--ink2);cursor:pointer}
+  .filterbar button.on{background:var(--accent);border-color:var(--accent);color:#fff;font-weight:600}
+  .decision{border:1px solid var(--amber);background:var(--amber-soft);border-radius:var(--radius);padding:14px 18px;margin:12px 0}
+  .decision h4{margin-top:0;color:var(--amber)}
+  footer{margin-top:50px;border-top:1px solid var(--line);padding-top:16px;font-size:12.5px;color:var(--ink3)}
+  @media (max-width:860px){
+    .layout{grid-template-columns:1fr}
+    nav.toc{position:static;height:auto;border-right:none;border-bottom:1px solid var(--line);padding:18px 20px}
+    nav.toc a{display:inline-block;margin-right:4px}
+    nav.toc a.sub{padding-left:8px}
+    main{padding:22px 18px 60px}
+    .grid2,.grid3,.price-grid,.road,.calc .row{grid-template-columns:1fr}
+    .flow{flex-direction:column}
+    .flow .step{border-radius:0;border-left:1px solid var(--line)!important}
+    .flow .step:first-child{border-radius:var(--radius) var(--radius) 0 0}
+    .flow .step:last-child{border-radius:0 0 var(--radius) var(--radius)}
+    .flow .step + .step{border-top:none}
+    .tw{overflow:visible}
+    table{min-width:0;font-size:13.5px}
+    .tw table{margin:0}
+    table tr:first-child{display:none}
+    table tr{display:block;padding:8px 0;border-bottom:1px solid var(--line)}
+    table tr:last-child{border-bottom:none}
+    table td{display:block;border-bottom:none;padding:3px 12px}
+    .prd-head h1{font-size:24px}
+  }
+  @media print{ nav.toc{display:none} .layout{grid-template-columns:1fr} main{padding:0} }
+</style>
+</head>
+<body>
+<div class="layout">
+<nav class="toc" id="toc">
+  <div class="doc-tag">PRODUCT REQUIREMENTS</div>
+  <div class="doc-title">招投标 AI 工具 PRD</div>
+  <div class="doc-meta">投标方全生命周期 AI 工具<br>版本 v0.9.1 · 评审稿<br>日期：2026-11-02</div>
+  <a href="#overview">1 产品概述</a>
+  <a href="#policy" class="sub">1.5 政策依据</a>
+  <a href="#market">2 市场与竞争</a>
+  <a href="#users">3 目标用户</a>
+  <a href="#principles">4 设计原则</a>
+  <a href="#scope">5 功能总览与优先级</a>
+  <a href="#modules">6 功能需求详述</a>
+  <a href="#m1" class="sub">M1 商机筛选</a>
+  <a href="#m2" class="sub">M2 招标文件解读</a>
+  <a href="#m3" class="sub">M3 废标风险检查</a>
+  <a href="#m4" class="sub">M4 标书生成</a>
+  <a href="#m5" class="sub">M5 查重与雷同检查</a>
+  <a href="#m6" class="sub">M6 基础平台能力</a>
+  <a href="#nonfunc">7 非功能需求</a>
+  <a href="#pricing">8 定价与商业模式</a>
+  <a href="#roadmap">9 版本路线图</a>
+  <a href="#metrics">10 成功指标</a>
+  <a href="#risks">11 风险与合规</a>
+  <a href="#decisions">12 待决策事项</a>
+</nav>
+
+<main>
+<header class="prd-head">
+  <h1>投标方招投标 AI 工具 · 产品需求文档<span class="status-pill">评审稿</span></h1>
+  <p class="sub">站在投标方一侧，贯穿「寻标 → 读标 → 写标 → 查标 → 投标」的全生命周期 AI 工具。</p>
+  <div class="meta-grid">
+    <span>文档版本 <b>v0.9.1</b></span>
+    <span>状态 <b>待评审</b></span>
+    <span>日期 <b>2026-11-02</b></span>
+    <span>依据 <b>玩家格局调研（19 家）· 定价调研（13 家）· 政策依据（3 项）</b></span>
+  </div>
+  <p class="sub"><strong>v0.9.1 修订（2026-11-02）</strong>：D1 定为 IT 集成先行；1.5 新增政策三（政府采购体系现行规则），政策口径由「双层」细化为「按法律体系分层」；M3「报价合理性风险检查」定性同步修订。MVP 范围的其余调整（多包、最小资质库、报价形式检查等）见 docs/decisions.md 与 docs/analysis/，升 v1.0 时合入正文。</p>
+</header>
+
+<!-- 1 -->
+<section id="overview">
+  <h2><span class="no">01</span>产品概述</h2>
+  <h3>1.1 一句话定位</h3>
+  <p>为有持续投标需求的企业投标团队提供一套 AI 辅助工具：把招标信息找得准、招标文件读得透、废标风险查得全、标书初稿写得快、雷同风险投前先自查。<strong>产品是「副驾驶」，不是「自动驾驶」</strong>——所有 AI 产出均为辅助结果，须经人工确认后使用（见 4.1）。</p>
+  <h3>1.2 要解决的问题</h3>
+  <ul>
+    <li><strong>找标靠人盯</strong>：标讯散落在各级交易平台与招标网站，人工逐站检索耗时且易漏标；存量平台的推送粗放，噪声大。</li>
+    <li><strong>读标靠熬夜</strong>：一份招标文件动辄数百页，资格条件、废标条款、评分点散布全文，靠人工摘录易漏项，而漏一条响应就可能废标。</li>
+    <li><strong>写标靠堆人</strong>：标书代写市场已存在多年（单份报价 2000–8000 元，来源为单一弱证据，未交叉验证，见 8.4），说明企业已在为这件事付费，但人工产能有限、交付周期长。</li>
+    <li><strong>查标靠经验</strong>：废标检查依赖老投标员的经验清单，新人无从下手；多家企业标书雷同可能被认定围串标，而投标方一侧缺乏投前自查工具。</li>
+  </ul>
+  <h3>1.3 产品形态</h3>
+  <ul>
+    <li><strong>SaaS Web 端</strong>（主力形态）：中小投标团队注册即用，按档位订阅。</li>
+    <li><strong>企业版</strong>：团队协作、统一额度池、企业知识库、权限与审计。</li>
+    <li><strong>私有化 / 专有云交付</strong>：面向政企与大型企业客户，数据不出域，项目制交付（见第 7 章）。</li>
+  </ul>
+  <h3>1.4 本期不做（Non-goals）</h3>
+  <ul>
+    <li>不做招标方 / 采购方一侧的评标、清标产品（那是讯飞、新点、易采购等的主场，与本产品定位不同）。</li>
+    <li>不承诺「一键生成可直接投递的完整标书」，不承诺检查结果的绝对准确（见 11.1）。</li>
+    <li>不做电子投标递交通道本身（对接各地交易平台的 CA 递交属平台方能力，仅预留导出规范格式）。</li>
+    <li>MVP 阶段不做工程造价自动组价（广联达等已有成熟产品，且专业门槛高）。</li>
+  </ul>
+  <h3 id="policy">1.5 政策依据（2026-10-21 核实，2026-10-22 按双层口径复核，2026-11-02 补充政府采购体系）</h3>
+  <p class="lede">本产品的两个核心场景已被国家文件正式点名，违规处罚亦在同步加重——以下三条为本 PRD 的政策依据，引用口径以本节标注为准。凡两文件交叉的事项，按<strong>双层口径</strong>分开标注：现行依据层（发改法规〔2026〕195 号，现行有效）与草案强化层（《招标投标法》修订草案，未施行）各标各的，不得混同；195 号文为实施意见（政策指导文件），不是法律，其「风险提示」不等于草案的法定义务。<strong>v0.9.1 补充</strong>：投标项目分属两套法律体系——政府采购体系（《政府采购法》、财政部令第 87 号等）与招标投标体系（《招标投标法》及实施条例）；首发行业 IT 集成的项目多数属政府采购体系（见政策三）。凡涉及无效 / 否决情形的口径，须先按项目所属体系区分，再在体系内区分现行层与草案层。</p>
+  <div class="card accent">
+    <h4>政策一：《关于加快招标投标领域人工智能推广应用的实施意见》（发改法规〔2026〕195 号）— 现行有效</h4>
+    <p>国家发展改革委等八部门 2026 年 2 月发布，确立招标投标领域「人工智能+」重点应用场景，覆盖招标、投标、开标评标、定标、现场管理等环节。其中「人工智能+投标」一组明确包含两项与本产品直接对应的场景：</p>
+    <ul>
+      <li><strong>投标策划</strong>：全方位捕捉各类项目招标信息，结合投标人特点推送适合的项目信息，自动提取并解析招标计划、招标公告和招标文件等资料中的关键要素，智能生成招标需求图谱；结合历史交易和同类项目，辅助分析评估参与项目竞争的经济性。<span class="src">（对应本产品 M1 商机筛选 + M2 招标文件解读）</span></li>
+      <li><strong>投标合规自查</strong>：深度解析项目招标需求和招标文件要求，结合投标人特点和优势，辅助投标人确定技术方案和报价区间；对投标人编制的投标文件，对照招标文件进行响应性比对，自动提示投标文件中的违法违规、错误缺漏等问题，辅助投标人针对性修改完善；对可能低于成本价的投标进行风险提示。<span class="src">（对应本产品 M3 废标风险检查，即本产品的 MVP 楔子）</span></li>
+    </ul>
+    <p><strong>时间表</strong>：2026 年底，招标文件检测、智能辅助评标、围串标识别等重点场景在部分省市实现全覆盖应用；2027 年底，更多重点场景在全国范围内推广应用。<strong>口径注意</strong>：2026 年底全覆盖仅指招标文件检测、智能辅助评标、围串标识别三个场景；本产品的楔子场景（投标策划、投标合规自查）属「更多重点场景」，对应 2027 年底全国推广这一波，对外表述不得把场景 4 / 5 写入 2026 年底节点。</p>
+    <p class="src">来源：国家发展改革委官网原文 <a href="https://www.ndrc.gov.cn/xxgk/zcfb/tz/202602/t20260210_1403680.html" target="_blank" rel="noopener">ndrc.gov.cn</a>（<a href="https://www.gdbczx.com/upload/doctor/20260729112520144.pdf" target="_blank" rel="noopener">PDF 镜像</a>）</p>
+  </div>
+  <div class="card warn">
+    <h4>政策二：《中华人民共和国招标投标法》修订草案 — 尚在审议，未施行</h4>
+    <p>2026 年 6 月 23 日提请十四届全国人大常委会第二十三次会议初次审议，共 6 章 79 条，目前尚未通过施行。<strong>引用本条时必须标注「尚在审议、未施行」，不得作为现行法引用。</strong>与投标方合规成本直接相关的拟议变化：</p>
+    <ul>
+      <li><strong>罚款大幅提高</strong>：串通投标、以行贿手段谋取中标、违规转让中标项目等违法行为的罚款标准，由项目金额的千分之五以上千分之十以下，提高至百分之二以上百分之十以下（上限为现行标准的 10 倍）。</li>
+      <li><strong>增设资格罚</strong>：对有关责任人员增设一定年限直至终身禁业的资格罚。</li>
+      <li><strong>资料留痕</strong>：明确招标投标资料应当保存至少 15 年；对定标过程实行全过程记录和可追溯管理。</li>
+      <li><strong>招标计划前置公开</strong>：增加规定，依法必须进行招标的项目应按规定发布招标计划；并配套强化信息公开，公开中标结果、定标方式以及确定中标人的主要理由等。</li>
+      <li><strong>低价规则收紧</strong>：进一步限缩最低投标价法的适用范围，将其限定为具有通用技术、性能标准或者招标人对其技术、性能没有特殊要求的项目；对可能影响履约的异常低价投标，投标人不能证明其报价合理性的，评标委员会应当否决其投标。<span class="src">（注：本条「异常低价否决」口径比 195 号文场景 5 的「低于成本价风险提示」更宽，且含评标委员会的否决义务，属草案强化层，两层不得互相冒充。）</span></li>
+      <li><strong>技术导向</strong>：草案规定在招标投标活动中推广应用大数据、云计算、人工智能、区块链等现代技术手段，并对依法必须进行招标的项目推广全流程电子化交易作出规定。</li>
+    </ul>
+    <p class="src">来源：中新社 2026-06-23 报道</p>
+  </div>
+  <div class="card accent">
+    <h4>政策三：政府采购体系现行规则（《政府采购法》及实施条例、财政部令第 87 号等）— 现行有效</h4>
+    <p>政府机关、事业单位使用财政资金的采购适用政府采购体系，首发行业 IT 集成的项目多数属此类。《政府采购货物和服务招标投标管理办法》（财政部令第 87 号）自 2017-10-01 起施行。该体系术语与招标投标体系不同：不合格投标称「投标无效」（招标投标体系称「否决投标」），评审分资格审查、符合性审查。与本产品直接相关的现行规定：</p>
+    <ul>
+      <li><strong>异常低价无效（第六十条，已核实）</strong>：评标委员会认为投标人的报价明显低于其他通过符合性审查投标人的报价，有可能影响产品质量或者不能诚信履约的，应当要求其在合理时间内提供书面说明，必要时提交相关证明材料；投标人不能证明其报价合理性的，评标委员会应当将其作为无效投标处理。<span class="src">（即：政府采购项目的「异常低价 → 无效」是现行规定，不是草案层。）</span></li>
+      <li><strong>投标无效情形（第六十三条，待原文核对）</strong>：未按规定提交投标保证金；未按要求签署、盖章；不具备资格要求；报价超过预算金额或最高限价；含有采购人不能接受的附加条件；法律法规和招标文件规定的其他情形。<span class="src">（对应 M3 形式要件、资质匹配、报价形式检查。）</span></li>
+    </ul>
+    <p>招标投标体系的现行对照：《招标投标法实施条例》第五十一条将「投标报价低于成本或者高于招标文件设定的最高投标限价」列为否决投标情形（待原文核对）；修订草案的异常低价否决（政策二）口径更宽，仍属草案层。</p>
+    <p class="src">来源：国务院公报 2017 年刊载的财政部令第 87 号全文 <a href="https://www.gov.cn/gongbao/content/2017/content_5241918.htm" target="_blank" rel="noopener">gov.cn</a>；第六十条适用见重庆市财政部门投诉处理决定书（2021）。标注「待原文核对」的条款在写入 M3 规则配置前须逐字核对。</p>
+  </div>
+  <h4>对本产品的含义</h4>
+  <ol>
+    <li><strong>楔子有正式政策依据</strong>：「投标合规自查」已被国家文件点名定义，M3 废标风险检查作为 MVP 切入点不是自创概念（详见第 6 章 M3 与第 9 章路线图）。</li>
+    <li><strong>付费逻辑升级</strong>：处罚加重（罚款上限 10 倍 + 禁业罚）显著抬高投标方的违规成本，「投前合规检查」的价值主张从提效升级为合规刚需，获客沟通可采用「合规预算」角度。</li>
+    <li><strong>留痕需求上升</strong>：资料保存 15 年 + 全过程可追溯，意味着招投标数据结构化、留痕的需求上升，与本产品「辅助 + 清单 + 人工确认 + 全程留痕」的设计约束（4.1）相互印证。</li>
+    <li><strong>商机信号前移（双层口径）</strong>：现行层——195 号文场景 4「投标策划」的定义已将「招标计划」列入自动提取解析的资料范围，M1 将招标计划列为采集源有现行政策依据（见第 6 章 M1）；草案强化层——修订草案拟要求依法必须招标的项目按规定发布招标计划，公开将变强制、商机时点进一步前移（尚在审议、未施行）。</li>
+    <li><strong>报价风险检查（按体系分层）</strong>：M3「报价合理性风险」检查项先按项目所属体系区分——政府采购项目：87 号令第六十条异常低价无效为现行规定，按现行依据呈现，不挂「政策预警」标签；招标投标项目：现行层为 195 号文场景 5「对可能低于成本价的投标进行风险提示」及实施条例第五十一条「低于成本」否决，草案层为修订草案的异常低价否决（口径更宽），「政策预警」标签只保留给这一层。任何一层都只提示不判定（判定权在评标委员会，见第 6 章 M3）。</li>
+    <li><strong>体系识别前置（v0.9.1 新增）</strong>：M2 解读须识别项目所属法律体系，M3 规则、界面与报告术语（投标无效 / 否决投标）随体系切换。</li>
+  </ol>
+</section>
+
+<!-- 2 -->
+<section id="market">
+  <h2><span class="no">02</span>市场与竞争格局（调研结论摘要）</h2>
+  <p class="lede">依据 2026-10-21 完成的玩家调研：共收录 19 个玩家——7 个专注创业产品、7 个传统标讯平台、5 个大厂 / 上市公司产品线。以下结论均带调研口径，未核实数字不作为事实引用。</p>
+  <div class="grid2">
+    <div class="card">
+      <h4>五环节拥挤度</h4>
+      <ul>
+        <li><strong>③ 标书生成最挤</strong>：快标书、巧文书、章寻、易标等几乎人人都在做，流程同质化（上传招标文件 → 解析评分点 → 生成目录正文 → 导出 Word）。</li>
+        <li><strong>① 商机筛选被把持</strong>：剑鱼标讯以免费策略占位，蚂蚁「AI 招标管家」依托支付宝入口，新玩家正面进入成本高。</li>
+        <li><strong>④ 废标检查正在成为付费卖点</strong>，但尚未拥挤。</li>
+        <li><strong>⑤ 投标方自查查重最空</strong>：明确产品化的只有巧文书与开源项目易标；市面上的雷同识别大多卖给招标方与监管方。</li>
+        <li><strong>② 中的「答疑澄清辅助」是完全空白</strong>：19 家里无一家明确产品化。</li>
+      </ul>
+    </div>
+    <div class="card">
+      <h4>关键对手与参照</h4>
+      <ul>
+        <li><strong>巧文书（湖南天河国云）</strong>：唯一五环节全覆盖的专注产品，已在卖企业版 + 私有化部署；自称 5000+ 政企客户（厂商自述，未独立核实）。是最直接的对手。</li>
+        <li><strong>易标 OpenBidKit</strong>：开源免费、可本地部署，对低端付费市场形成持续价格压力。</li>
+        <li><strong>头部玩家不卖零售工具</strong>：讯飞、新点、广联达卖平台与项目制，蚂蚁卖生态入口——中小投标团队的工具市场仍由长尾玩家争夺。</li>
+        <li><strong>行业透明度低</strong>：专注玩家无一公开披露融资，价格几乎都不公示（见第 8 章）。</li>
+      </ul>
+    </div>
+  </div>
+  <h3>2.1 差异化策略（本产品的立足点）</h3>
+  <ol>
+    <li><strong>以 ③→④ 的「检查」而非「生成」为楔子</strong>：先做废标风险检查——价值明确、结果可验证、责任边界清晰（详见第 9 章路线图）。</li>
+    <li><strong>抢占两个空白点</strong>：⑤ 投前自查查重做深做透；② 中嵌入答疑澄清辅助（澄清问题清单生成与截止日提醒）。</li>
+    <li><strong>全程留痕的「可复核」设计</strong>：每条检查结论可回溯到招标文件原文出处，这是与「一键生成」型产品的核心区别。</li>
+    <li><strong>定价透明</strong>：在价格普遍不公示的赛道里明码标价 + 额度可查，本身即是获客差异点。</li>
+  </ol>
+</section>
+
+<!-- 3 -->
+<section id="users">
+  <h2><span class="no">03</span>目标用户</h2>
+  <div class="tw"><table>
+    <tr><th style="width:22%">用户层</th><th>画像</th><th>核心诉求</th><th style="width:20%">对应档位</th></tr>
+    <tr><td><strong>主力：中小企业投标团队</strong></td><td>工程、IT 集成、设备供应、服务类企业；投标专员 1–5 人，月均投标 2–10 个项目，老板 / 商务负责人拍板采购</td><td>别漏标、别废标、写标别熬夜；价格敏感，决策周期短（数天内可拍板）</td><td>专业版 / 团队版</td></tr>
+    <tr><td><strong>个人 / 小微投标人</strong></td><td>兼职投标、标书代写从业者、低频投标小微企业</td><td>单份标书成本可控，先试用再付费</td><td>免费版 / 专业版</td></tr>
+    <tr><td><strong>高客单：政企与大型企业投标团队</strong></td><td>央国企下属公司、大型建工 / 集成商的投标中心，标书含报价策略与企业资质</td><td>数据不出域、私有化部署、权限审计、信创适配</td><td>企业版（项目制）</td></tr>
+  </table></div>
+  <p class="small">非目标用户：招标代理机构与采购单位（属招标方侧）；一年投标不足 2 次的偶发投标者（免费版覆盖即可，不为其做专属功能）。</p>
+</section>
+
+<!-- 4 -->
+<section id="principles">
+  <h2><span class="no">04</span>设计原则（约束条件）</h2>
+  <div class="card accent">
+    <h4>4.1 准确性边界：辅助定位，不做保证</h4>
+    <p>委托方已明确接受「准确性不保证」：产品定位为辅助工具，不承诺生成内容与检查结果的绝对准确。落到设计上四件套——<strong>辅助生成</strong>（产出标注为初稿）、<strong>检查清单</strong>（逐项列出、含原文出处）、<strong>人工确认</strong>（关键节点须用户逐项确认后才进入下一步）、<strong>全程留痕</strong>（谁在何时确认了什么，可审计）。界面与协议中禁止出现「保证不废标」「100% 通过」等表述。</p>
+  </div>
+  <div class="grid2">
+    <div class="card">
+      <h4>4.2 数据敏感分级</h4>
+      <p>标书含报价策略、企业资质、历史业绩，按敏感数据对待：SaaS 版默认加密存储、支持项目级删除；企业版提供私有化 / 专有云，数据不出客户域（调研显示这已是面向大客户的行业惯例：巧文书、讯飞均主打私有化与数据不出域）。</p>
+    </div>
+    <div class="card">
+      <h4>4.3 额度即货币</h4>
+      <p>AI 调用量是核心计费单位：所有 AI 功能的扣点规则对用户可见、可查、可预警；额度与账号绑定、不可转让、不可拆分转售（防灰产，证据见 8.5）。</p>
+    </div>
+  </div>
+</section>
+
+<!-- 5 -->
+<section id="scope">
+  <h2><span class="no">05</span>功能总览与优先级</h2>
+  <p class="lede">P0 = MVP 必须有，缺之产品不成立；P1 = V1 补齐；P2 = V2 及以后。用下方筛选查看各优先级范围。</p>
+  <div class="filterbar" role="group" aria-label="优先级筛选">
+    <button class="on" data-f="all">全部</button>
+    <button data-f="p0">P0 · MVP</button>
+    <button data-f="p1">P1 · V1</button>
+    <button data-f="p2">P2 · V2</button>
+  </div>
+  <div class="tw"><table id="scopeTable">
+    <tr><th style="width:16%">模块</th><th>功能点</th><th style="width:12%">优先级</th><th style="width:26%">备注</th></tr>
+    <tr data-p="p1"><td>M1 商机筛选</td><td>标讯聚合、订阅规则、匹配推荐</td><td><span class="tag p1">P1</span></td><td>① 已被存量平台把持，MVP 不正面做</td></tr>
+    <tr data-p="p1"><td>M1 商机筛选</td><td>招标计划采集与早期商机提示</td><td><span class="tag p1">P1</span></td><td>双层口径：现行依据＝195 号文场景 4（招标计划本就是官方场景定义的一部分）；草案强化层＝前置公开拟变强制（尚在审议、未施行）</td></tr>
+    <tr data-p="p2"><td>M1 商机筛选</td><td>竞对动态监控、投标胜率参考分析</td><td><span class="tag p2">P2</span></td><td>依赖数据积累</td></tr>
+    <tr data-p="p0"><td>M2 文件解读</td><td>招标文件解析：资格 / 废标条款 / 评分点 / 关键日期结构化提取</td><td><span class="tag p0">P0</span></td><td>全产品地基，M3、M4 均依赖它</td></tr>
+    <tr data-p="p0"><td>M2 文件解读</td><td>解读结果逐项回链原文出处</td><td><span class="tag p0">P0</span></td><td>可复核设计的载体</td></tr>
+    <tr data-p="p1"><td>M2 文件解读</td><td>答疑澄清辅助：疑问点清单、澄清提问草稿、截止日提醒</td><td><span class="tag p1">P1</span></td><td>市场空白点，重点差异化</td></tr>
+    <tr data-p="p0"><td>M3 废标检查</td><td>响应完整性 / 格式 / 签章 / 资质匹配检查清单</td><td><span class="tag p0">P0</span></td><td><strong>产品楔子</strong>，首个付费点</td></tr>
+    <tr data-p="p0"><td>M3 废标检查</td><td>检查结果人工逐项确认与留痕</td><td><span class="tag p0">P0</span></td><td>对应 4.1 原则</td></tr>
+    <tr data-p="p1"><td>M3 废标检查</td><td>报价合理性风险检查</td><td><span class="tag p1">P1</span></td><td>按体系分层：政府采购＝87 号令第六十条异常低价无效（现行，不挂预警标签）；招标投标＝195 号文场景 5 + 实施条例第五十一条（现行）/ 修订草案异常低价否决（草案层，「政策预警」标签仅用于此层）</td></tr>
+    <tr data-p="p1"><td>M4 标书生成</td><td>按目录框架生成技术 / 商务标初稿、企业知识库填充</td><td><span class="tag p1">P1</span></td><td>最拥挤环节，靠知识库与留痕差异化</td></tr>
+    <tr data-p="p1"><td>M4 标书生成</td><td>智能排版、偏离表自动生成、Word 导出</td><td><span class="tag p1">P1</span></td><td>导出格式须符合递交规范</td></tr>
+    <tr data-p="p1"><td>M5 查重雷同</td><td>自有历史标书查重、多份在投标书互查</td><td><span class="tag p1">P1</span></td><td>空白点之一，先做自查场景</td></tr>
+    <tr data-p="p2"><td>M5 查重雷同</td><td>雷同风险分级报告与改写建议</td><td><span class="tag p2">P2</span></td><td>在互查数据之上迭代</td></tr>
+    <tr data-p="p0"><td>M6 平台能力</td><td>项目工作台、文档管理、额度计量与账单</td><td><span class="tag p0">P0</span></td><td>计费闭环不可缺</td></tr>
+    <tr data-p="p1"><td>M6 平台能力</td><td>团队协作、角色权限、企业知识库管理</td><td><span class="tag p1">P1</span></td><td>团队版前置条件</td></tr>
+    <tr data-p="p2"><td>M6 平台能力</td><td>私有化部署包、SSO、审计日志导出</td><td><span class="tag p2">P2</span></td><td>随企业版签约交付</td></tr>
+  </table></div>
+
+  <div class="flow" aria-label="全生命周期流程">
+    <div class="step"><div class="n">M1</div><div class="t">商机筛选</div><div class="d">订阅标讯 → AI 匹配打分 → 决定是否跟进</div></div>
+    <div class="step"><div class="n">M2</div><div class="t">文件解读</div><div class="d">上传招标文件 → 结构化解读 → 疑问点走澄清</div></div>
+    <div class="step wedge"><div class="n">M3 · 楔子</div><div class="t">废标风险检查</div><div class="d">按解读清单逐项核对投标文件 → 人工确认留痕</div></div>
+    <div class="step"><div class="n">M4</div><div class="t">标书生成</div><div class="d">目录框架 → 分章生成初稿 → 知识库填充 → 导出</div></div>
+    <div class="step"><div class="n">M5</div><div class="t">查重雷同</div><div class="d">投前自查 → 雷同风险报告 → 修改后递交</div></div>
+  </div>
+  <p class="small">流程说明：M3、M5 与 M2 共用同一份「项目检查清单」数据结构——解读阶段提取的要求项，在写标阶段是生成约束，在投前阶段是核对项。这是本产品区别于单点工具的数据设计核心。</p>
+</section>
+
+<!-- 6 -->
+<section id="modules">
+  <h2><span class="no">06</span>功能需求详述</h2>
+
+  <div class="module" id="m1">
+    <div class="module-head"><span class="mn">M1</span><h3>商机筛选</h3><span class="crowd">拥挤度：<strong>高</strong>（剑鱼免费策略 + 蚂蚁入口把持）· 本产品优先级 P1 起步</span></div>
+    <div class="module-body">
+      <p><strong>用户故事</strong>：作为投标主管，我希望按行业、地区、金额、关键词订阅标讯，每天只收到与我公司资质和产品真正相关的项目，不再逐站翻公告。</p>
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>多源标讯聚合</td><td><span class="tag p1">P1</span></td><td>聚合公开招标公告（含采购意向、拟在建等早期信号）；每条标讯可溯源到原公告链接；去重后同一项目只出现一次。</td></tr>
+        <tr><td>招标计划采集（早期商机信号）</td><td><span class="tag p1">P1</span></td><td>数据源规划中将「招标计划」列为独立采集源与信号类型：在招标计划阶段即向匹配的投标方推送早期商机提示，并与后续发布的招标公告自动关联为同一项目的生命周期线索。<strong>依据（双层口径）</strong>：现行依据＝发改法规〔2026〕195 号场景 4「投标策划」，其原文已明确「自动提取并解析项目<strong>招标计划</strong>、招标公告和招标文件等资料中的关键要素」——招标计划本就是官方场景定义的一部分，本采集能力有现行政策依据；草案强化层＝《招标投标法》修订草案拟增加「依法必须进行招标的项目应按规定发布招标计划」的规定（尚在审议、未施行，见 1.5），施行后公开将变强制、时点更早。</td></tr>
+        <tr><td>订阅规则与推送</td><td><span class="tag p1">P1</span></td><td>按关键词组 + 地区 + 行业 + 预估金额建规则；站内 + 邮件 / 企业微信推送；免费版限 1 组规则，付费版按档位放开（见第 8 章）。</td></tr>
+        <tr><td>AI 匹配打分</td><td><span class="tag p1">P1</span></td><td>结合企业资质、业绩、产品词给每条商机打「匹配度」并给出理由（命中哪些资格条件、缺哪些）；打分仅作筛选参考，界面明示非中标概率承诺。</td></tr>
+        <tr><td>一键转项目</td><td><span class="tag p1">P1</span></td><td>商机可一键转为投标项目，自动进入 M2 解读流程，标讯与招标文件自动关联。</td></tr>
+        <tr><td>竞对监控 / 胜率参考</td><td><span class="tag p2">P2</span></td><td>监控指定竞争对手的中标动态；基于历史同类项目给出参与建议。数据不足时宁可不展示，不编造胜率数字。</td></tr>
+      </table></div>
+    </div>
+  </div>
+
+  <div class="module" id="m2">
+    <div class="module-head"><span class="mn">M2</span><h3>招标文件解读</h3><span class="crowd">拥挤度：中（多作为生成的附属步骤）· <strong>澄清辅助为全市场空白</strong></span></div>
+    <div class="module-body">
+      <p><strong>用户故事</strong>：作为投标专员，我上传一份几百页的招标文件后，十分钟内能拿到一份结构化清单：我要满足什么资格、哪些条款碰了就废标、评分点怎么分布、关键时间节点有哪些——并且每一项都能点回原文核对。</p>
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>文件上传与解析</td><td><span class="tag p0">P0</span></td><td>支持 PDF / Word / 扫描件（OCR）；单文件上限与页数上限在购买页明示；解析进度可见，失败可重试且不扣额度。</td></tr>
+        <tr><td>结构化提取</td><td><span class="tag p0">P0</span></td><td>提取四类信息：①资格条件 ②废标 / 否决条款 ③评分办法与分值分布 ④关键日期与递交要求（格式、签章、加密、份数）。每类成清单呈现。</td></tr>
+        <tr><td>原文回链</td><td><span class="tag p0">P0</span></td><td>每条提取结果附原文出处（页码 + 原句高亮），点击跳转定位；无出处的结果不进入正式清单，只进「待确认」区。</td></tr>
+        <tr><td>项目检查清单生成</td><td><span class="tag p0">P0</span></td><td>解读结果自动生成项目检查清单（即 M3、M4 共用的数据结构）；用户可增删改清单项，修改留痕。</td></tr>
+        <tr><td>答疑澄清辅助</td><td><span class="tag p1">P1</span></td><td>自动标出表述模糊、自相矛盾、需向招标方确认的疑问点，生成澄清提问草稿；澄清截止日进入项目日历并提前提醒。此功能 19 家竞品均未产品化，为重点差异化功能。</td></tr>
+        <tr><td>多文件 / 补遗合并</td><td><span class="tag p1">P1</span></td><td>招标文件补遗、澄清答复文件可追加上传，系统标出对原清单的影响项（新增 / 变更 / 作废）。</td></tr>
+      </table></div>
+    </div>
+  </div>
+
+  <div class="module" id="m3">
+    <div class="module-head"><span class="mn">M3</span><h3>废标风险检查 <span class="tag p0">产品楔子</span></h3><span class="crowd">拥挤度：低-中（正成为付费卖点，尚未拥挤）</span></div>
+    <div class="module-body">
+      <p><strong>用户故事</strong>：作为投标专员，我在递交前把投标文件放进来，系统按招标文件的要求逐项核对，告诉我哪里没响应、哪里格式签章不对、哪项资质对不上，并给我一份可以逐项打勾确认的清单——最后由我签字确认，而不是系统替我打包票。</p>
+      <div class="card accent"><h4>政策依据（双层口径）</h4><p>发改法规〔2026〕195 号已将「投标合规自查」列为「人工智能+投标」重点场景，其定义即「对投标人编制的投标文件，对照招标文件进行响应性比对，自动提示违法违规、错误缺漏」——与本模块的功能定义基本一致（见 1.5）。M3 作为 MVP 楔子由此获得正式政策背书；同时《招标投标法》修订草案拟将串通投标等行为的罚款上限提高至现行标准的 10 倍并增设禁业罚（尚在审议、未施行），投前合规检查的付费逻辑预期随之强化。本模块「报价合理性风险」检查项按体系分层标注：政府采购项目的异常低价无效（87 号令第六十条）属现行规定；招标投标项目中「低于成本价风险提示」即 195 号文场景 5 的原文表述，属现行层，草案的异常低价否决为更宽的草案层，「政策预警」标签只保留给草案层（见下表）。</p></div>
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>响应完整性检查</td><td><span class="tag p0">P0</span></td><td>以 M2 清单逐项比对投标文件：未响应、负偏离未说明、漏项三类问题分级标出（致命 / 重要 / 提示），每条问题附双方原文出处。</td></tr>
+        <tr><td>形式要件检查</td><td><span class="tag p0">P0</span></td><td>格式、签字盖章位置、装订 / 封装、文件命名、份数、递交方式等形式要件逐项核对；签章类仅作「位置与有无」提示，不做真伪鉴定，界面明示。</td></tr>
+        <tr><td>资质匹配检查</td><td><span class="tag p0">P0</span></td><td>招标资格条件与企业资质库逐项匹配：过期、等级不足、未覆盖三类预警；资质数据来自用户自维护的企业资质库，不从外部编造。</td></tr>
+        <tr><td>报价合理性风险检查</td><td><span class="tag p1">P1</span></td><td><strong>触发</strong>：投标报价相对招标控制价 / 最高限价，或同类项目中标价出现明显偏离时触发。<strong>输出</strong>：给出偏离判断、偏离幅度与提示语，并提示用户准备报价合理性说明（成本构成等证明材料）。<strong>验收标准</strong>：输入一份含报价的投标文件后，系统须输出是否触发、偏离依据（引用的控制价 / 对比数据来源）与建议动作三部分，缺一不可。<strong>定性（按体系分层，v0.9.1 修订）</strong>：⓪政府采购项目（现行层）——财政部令第 87 号第六十条：报价明显低于其他通过符合性审查投标人、可能影响产品质量或不能诚信履约，且投标人不能证明报价合理性的，作无效投标处理；按现行规定呈现，<strong>不挂「政策预警」标签</strong>，提示用户预备书面说明与证明材料，不做「将被认定无效」的判定。以下①②仅适用于招标投标项目：①现行层——发改法规〔2026〕195 号场景 5「投标合规自查」原文即含「对可能低于成本价的投标进行风险提示，减少恶意低价竞标等情况」，并与实施条例第五十一条「投标报价低于成本」否决情形对应（待原文核对），低于成本价的风险提示按现行依据呈现，<strong>不挂「政策预警」标签</strong>；②草案层——《招标投标法》修订草案拟增的异常低价否决规定（口径比「低于成本价」更宽，且含评标委员会的否决义务；草案同时限缩最低投标价法至具有通用技术、性能标准的项目，尚在审议、未施行，见 1.5），<strong>「政策预警」标签只保留给这一层</strong>，施行前只做风险提示，不做「将被否决」的硬性判定，施行后视最终文本调整定性。口径红线：195 号文为实施意见（政策指导文件），不是法律，「低于成本价风险提示」不等于「异常低价否决」的法定义务，两层不得互相冒充；政府采购项目不得引用招标投标法草案作为低价规则依据，反之亦然。</td></tr>
+        <tr><td>人工确认流</td><td><span class="tag p0">P0</span></td><td>每条检查结论三态：已确认无误 / 已修改 / 忽略并注明原因；全部「致命」项未处理完时，项目状态保持「未就绪」，但系统不阻断用户导出（决定权在用户，责任边界清晰）。</td></tr>
+        <tr><td>检查报告导出</td><td><span class="tag p0">P0</span></td><td>导出含问题清单、处理状态、确认人与时间的检查报告（PDF），随项目归档留痕。</td></tr>
+        <tr><td>行业规则包</td><td><span class="tag p1">P1</span></td><td>按行业（先 IT 集成、工程两类，格式最标准化）维护高频废标规则包，随政策与格式规范更新；规则包版本在报告中标注。</td></tr>
+      </table></div>
+      <div class="card warn"><h4>验收红线</h4><p>M3 的对外表述只允许「辅助检查 / 风险提示」，禁止「保证通过资格审查」类承诺；检查覆盖范围（查了哪些、不查哪些）必须在报告首页明示。</p></div>
+    </div>
+  </div>
+
+  <div class="module" id="m4">
+    <div class="module-head"><span class="mn">M4</span><h3>标书生成</h3><span class="crowd">拥挤度：<strong>最高</strong>（同质化严重）· 靠知识库 + 清单约束差异化</span></div>
+    <div class="module-body">
+      <p><strong>用户故事</strong>：作为投标专员，我希望系统按招标文件的评分点生成目录和分章初稿，并自动把公司介绍、资质、业绩从知识库填进去；我在此基础上改写润色，而不是从零写起。生成内容是初稿，最终文本由我负责。</p>
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>目录框架生成</td><td><span class="tag p1">P1</span></td><td>按 M2 评分点与响应清单生成标书目录，目录项与评分点一一对应；用户调整目录后生成范围随之更新。</td></tr>
+        <tr><td>分章生成初稿</td><td><span class="tag p1">P1</span></td><td>技术标 / 商务标分章生成，可单章重试；生成内容全程标注「AI 初稿」水印状态，用户编辑确认后解除；生成扣点规则见第 8 章。</td></tr>
+        <tr><td>企业知识库填充</td><td><span class="tag p1">P1</span></td><td>企业介绍、资质证书、业绩案例、人员简历等结构化入库，生成时自动引用；引用内容须来自库内原文，库里没有的不编造，缺失处以占位符提示补录。</td></tr>
+        <tr><td>偏离表自动生成</td><td><span class="tag p1">P1</span></td><td>按响应清单生成商务 / 技术偏离表初稿，偏离项须用户逐项确认（正偏离 / 无偏离 / 负偏离）。</td></tr>
+        <tr><td>排版与导出</td><td><span class="tag p1">P1</span></td><td>模板化排版（页眉页脚、目录、页码、图表编号）；导出 Word，版式符合常见递交规范；报价部分仅提供结构与填充位，<strong>报价数字永远由用户填写，系统不生成、不建议具体报价</strong>。</td></tr>
+      </table></div>
+    </div>
+  </div>
+
+  <div class="module" id="m5">
+    <div class="module-head"><span class="mn">M5</span><h3>查重与雷同检查</h3><span class="crowd">拥挤度：<strong>最低</strong>（投标方自查仅巧文书、易标两家产品化）</span></div>
+    <div class="module-body">
+      <p><strong>用户故事</strong>：作为投标负责人，我担心两种雷同：一是新标书大段照搬自己历史标书显得不用心；二是同一项目里合作方 / 关联方的标书与我的高度相似，被误判围串标。我希望投递前自己先查一遍。</p>
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>自有历史查重</td><td><span class="tag p1">P1</span></td><td>当前标书与本企业历史标书库比对，标出高重复段落与重复率（按章节）；仅在本企业数据范围内比对，不跨企业。</td></tr>
+        <tr><td>多份在投互查</td><td><span class="tag p1">P1</span></td><td>用户主动上传的多份标书两两互查（含文档属性、作者信息等元数据雷同提示）；功能定位为自查，报告仅用户可见。</td></tr>
+        <tr><td>雷同风险报告</td><td><span class="tag p2">P2</span></td><td>按文本雷同 / 结构雷同 / 元数据雷同分级输出风险报告，给出改写建议入口（跳 M4 单章重写）。</td></tr>
+        <tr><td>合规边界</td><td><span class="tag p0">P0</span></td><td>本模块只服务于投前自查与规避误判；产品不得宣传或支持「帮多家投标人做不雷同」等围串标规避用途，服务协议中明文禁止（见 11.2）。</td></tr>
+      </table></div>
+    </div>
+  </div>
+
+  <div class="module" id="m6">
+    <div class="module-head"><span class="mn">M6</span><h3>基础平台能力</h3><span class="crowd">支撑层 · 随档位开放</span></div>
+    <div class="module-body">
+      <div class="tw"><table>
+        <tr><th style="width:30%">需求</th><th style="width:10%">优先级</th><th>说明与验收标准</th></tr>
+        <tr><td>项目工作台</td><td><span class="tag p0">P0</span></td><td>以「投标项目」为单位组织全部文件、清单、报告与时间节点；项目状态流：跟进中 → 编制中 → 已检查 → 已递交 → 已归档。</td></tr>
+        <tr><td>额度计量</td><td><span class="tag p0">P0</span></td><td>每次 AI 调用实时扣点并记明细；用户可查本期已用 / 剩余 / 按功能分布；额度用到 80%、100% 时站内提醒；解析失败、系统异常不扣点。</td></tr>
+        <tr><td>企业资产库</td><td><span class="tag p1">P1</span></td><td>资质库、业绩库、人员库、历史标书库统一管理，支持有效期提醒（证照到期预警）。</td></tr>
+        <tr><td>协作与权限</td><td><span class="tag p1">P1</span></td><td>团队版起：成员邀请、角色（管理员 / 编标 / 只读）、项目级可见范围；关键操作（确认、导出、删除）留痕。</td></tr>
+        <tr><td>私有化交付包</td><td><span class="tag p2">P2</span></td><td>企业版：私有化 / 专有云部署包、SSO 对接、审计日志导出、专职部署支持与培训（交付内容参照行业惯例，见 8.3）。</td></tr>
+      </table></div>
+    </div>
+  </div>
+</section>
+
+<!-- 7 -->
+<section id="nonfunc">
+  <h2><span class="no">07</span>非功能需求</h2>
+  <div class="tw"><table>
+    <tr><th style="width:18%">类别</th><th>要求</th></tr>
+    <tr><td><strong>可复核性</strong></td><td>所有 AI 提取与检查结论必须可回溯原文出处；无出处的结论降级为「提示」而非「结论」。生成内容须可区分 AI 初稿与人工定稿（版本对比保留）。</td></tr>
+    <tr><td><strong>性能</strong></td><td>300 页以内招标文件解读目标 10 分钟内完成（以实测为准，上线前压测后回填本条）；分章生成单章目标 2 分钟内返回。</td></tr>
+    <tr><td><strong>数据安全</strong></td><td>传输与存储加密；项目数据按租户隔离；用户可自助删除项目与账号数据；SaaS 版数据不用于训练公共模型（须写入服务协议）。</td></tr>
+    <tr><td><strong>私有化</strong></td><td>企业版支持私有化 / 专有云部署，模型与数据不出客户域；支持国产化环境适配（信创）作为企业版可选项。</td></tr>
+    <tr><td><strong>可用性</strong></td><td>核心链路（上传 → 解读 → 检查 → 导出）在主流浏览器可用；移动端仅做进度查看与提醒，不做编标。</td></tr>
+  </table></div>
+</section>
+
+<!-- 8 -->
+<section id="pricing">
+  <h2><span class="no">08</span>定价与商业模式</h2>
+  <h3>8.1 定价结构（委托方已定方向）</h3>
+  <p><strong>分档订阅，档位差异 = 包含的 AI 调用量（额度）+ 功能开放程度；超量买加量包；企业版私有化项目制。</strong>这一「订阅含额度池 + 超量加量包」结构在相邻 AI SaaS 已有成熟先例：Kimi 五档订阅共享月度 credit 池、超量可买 Extra Usage 包（官方帮助中心，A 级证据）；腾讯 Buddy AI 包月含 4000 积分、加量包 1000 积分 50 元（B 级证据）。本赛道内亦有「年费含解析 / 生成次数」的转述样本（1999 元/年、2499 元/年含 500 次解析、300 次生成——弱证据、未指明产品，仅作结构与量级参考）。</p>
+  <h3>8.2 建议档位（本 PRD 方案，额度数字为产品建议值，上线前需结合成本实测校准）</h3>
+  <div class="price-grid">
+    <div class="tier">
+      <div class="tn">免费版</div><div class="tp">¥0</div>
+      <ul><li>商机订阅 1 组规则</li><li>文件解读 3 次（单份限页）</li><li>废标检查 1 个项目</li><li>标书生成试用 1 次（限章节）</li><li>无查重、无知识库</li></ul>
+      <div class="who">定位：引流与试用，体验完整检查链路一次</div>
+    </div>
+    <div class="tier hot">
+      <div class="tn">专业版</div><div class="tp">¥1,999<span> /年</span></div>
+      <ul><li>1 个账号</li><li>解析 500 次 / 年 · 生成 300 次 / 年</li><li>废标检查不限项目数（按解析额度计）</li><li>查重 50 次 / 年</li><li>基础企业资产库</li></ul>
+      <div class="who">定位：个人投标人、小微企业投标岗</div>
+    </div>
+    <div class="tier">
+      <div class="tn">团队版</div><div class="tp">¥4,999<span> /年起</span></div>
+      <ul><li>5 个账号起，额度团队共享池</li><li>解析 2,000 次 / 年 · 生成 1,200 次 / 年</li><li>查重 300 次 / 年 · 澄清辅助全量开放</li><li>协作、角色权限、完整资产库</li><li>商机订阅 20 组规则 + 竞对监控</li></ul>
+      <div class="who">定位：有持续投标量的中小企业投标团队</div>
+    </div>
+    <div class="tier">
+      <div class="tn">企业版</div><div class="tp">项目制<span> 询价</span></div>
+      <ul><li>私有化部署 / 专有云交付</li><li>额度按合同约定（可不限量）</li><li>SSO、审计日志、信创适配可选</li><li>专职部署支持 + 实施培训 + 专属客服</li></ul>
+      <div class="who">定位：政企与大型企业投标中心</div>
+    </div>
+  </div>
+  <h3>8.3 计费口径定义</h3>
+  <div class="tw"><table>
+    <tr><th style="width:24%">计量单位</th><th>定义</th><th style="width:24%">不扣点情形</th></tr>
+    <tr><td>1 次「解析」</td><td>对一份招标文件（或一份补遗 / 澄清文件）完成一次结构化解读</td><td>解析失败、超时、用户主动取消</td></tr>
+    <tr><td>1 次「生成」</td><td>生成一章标书初稿（单章重试在 24 小时内免费 2 次）</td><td>生成失败、内容为空</td></tr>
+    <tr><td>1 次「检查」</td><td>对一个项目执行一次全量废标检查或一次查重比对；同项目 24 小时内复查不重复扣点</td><td>检查中断、系统异常</td></tr>
+    <tr><td>加量包</td><td>额度用尽后单独购买，建议小步档位（如解析 / 生成混合包），购买后 12 个月内有效，不跨账号转让</td><td>—</td></tr>
+  </table></div>
+  <div class="calc">
+    <h4 style="margin-top:0">额度测算器（帮客户选档，也用于销售演示）</h4>
+    <div class="row">
+      <div>
+        <label>每月投标项目数：<span class="val" id="vProj">4</span> 个</label>
+        <input type="range" id="rProj" min="1" max="30" value="4">
+        <label style="margin-top:12px">每个项目平均生成章节数：<span class="val" id="vGen">10</span> 章</label>
+        <input type="range" id="rGen" min="2" max="40" value="10">
+      </div>
+      <div>
+        <label>每个项目平均解读文件数（含补遗）：<span class="val" id="vParse">2</span> 份</label>
+        <input type="range" id="rParse" min="1" max="6" value="2">
+        <label style="margin-top:12px">团队使用账号数：<span class="val" id="vSeat">3</span> 个</label>
+        <input type="range" id="rSeat" min="1" max="30" value="3">
+      </div>
+    </div>
+    <div class="calc-out" id="calcOut"></div>
+    <p class="small" style="margin-bottom:0">测算口径：年解析量 = 月项目数 × 每项目文件数 × 12；年生成量 = 月项目数 × 每项目章节数 × 12。推荐逻辑：账号 &gt;1 或任一额度超专业版上限 → 团队版；解析 ≤ 免费试用范围且账号 =1 → 免费版先行体验。</p>
+  </div>
+  <h3>8.4 定价依据与市场锚点（调研口径）</h3>
+  <ul>
+    <li><strong>赛道价格普遍不公示</strong>：13 个玩家中能拿到确切数字的只有火标网（VIP 包半年 598 元、包年 998 元，出自 App Store 订阅说明镜像，约一年前抓取，现行价未官方复核）与开源免费的易标。其余靠销售报价——本产品选择明码标价，本身即差异化。</li>
+    <li><strong>成本底盘低</strong>：易标官方实测生成一份 11 万字标书 token 成本约 1.03 元（厂商自测，未独立核实，不含配图）——按量计费卖的是「一份能用的初稿 + 检查服务」，不是算力本身。</li>
+    <li><strong>替代支出锚点</strong>：传统标书代写单份 2000–8000 元（单一弱证据来源，未交叉验证）——若属实，专业版年费约等于一份代写标书的价格，是销售话术的天然锚点，但对外引用前须再核实。</li>
+    <li><strong>私有化无公开价</strong>：全赛道无一家公示私有化金额，结构上为「部署 / 实施费 + 年服务费」的项目制惯例，本产品沿用此结构。</li>
+  </ul>
+  <h3>8.5 防转卖 / 防薅（定价调研的硬证据要求）</h3>
+  <p>调研发现 AI 额度灰产真实存在：腾讯 Buddy AI 官方约 250 元的 5000 积分曾被以 8.88 元在二手平台转卖（销量 2500+），Kimi 高阶会员曾被按分钟出租（央视调查经媒体转述，B 级证据）。本产品对策：额度与企业主体 + 账号绑定、不可转让不可拆分；异常并发与异地多设备登录风控；加量包不设可转让的兑换码形态。</p>
+</section>
+
+<!-- 9 -->
+<section id="roadmap">
+  <h2><span class="no">09</span>版本路线图</h2>
+  <div class="road">
+    <div class="phase">
+      <div class="ph">MVP</div><h4>检查楔子</h4>
+      <ul><li>M2 解读（P0 全部）</li><li>M3 废标检查（P0 全部）</li><li>M6 项目工作台 + 额度计量</li><li>免费版 + 专业版上线</li></ul>
+      <div class="gate">放行指标：用真实招标文件跑通「解读 → 检查 → 报告」全链；首批种子用户完成 ≥1 次真实项目检查并愿付费续用</div>
+    </div>
+    <div class="phase">
+      <div class="ph">V1</div><h4>写标闭环</h4>
+      <ul><li>M4 标书生成 + 企业资产库</li><li>M2 澄清辅助</li><li>M5 自有历史查重</li><li>团队版（协作与权限）上线</li></ul>
+      <div class="gate">放行指标：生成初稿的实际采用率（用户保留过半内容的章节占比）达标；团队版出现自然增购账号</div>
+    </div>
+    <div class="phase">
+      <div class="ph">V2</div><h4>全周期贯通</h4>
+      <ul><li>M1 商机筛选与匹配打分</li><li>M5 多份互查 + 风险报告</li><li>商机 → 项目 → 投后归档全链打通</li></ul>
+      <div class="gate">放行指标：商机转项目的使用占比可观，且不因标讯噪声拉低留存</div>
+    </div>
+    <div class="phase">
+      <div class="ph">企业版</div><h4>私有化交付</h4>
+      <ul><li>私有化 / 专有云部署包</li><li>SSO、审计、信创适配</li><li>行业规则包（工程类扩展）</li></ul>
+      <div class="gate">放行指标：以签约客户需求驱动开发，不预先重投入；首单交付验收通过再标准化</div>
+    </div>
+  </div>
+  <p class="small">节奏说明：MVP 只做「解读 + 检查」，是刻意的——生成环节最挤、责任最重；检查环节价值可验证、责任边界清晰，且能沉淀用户的项目与清单数据，为 V1 的生成质量打底。</p>
+</section>
+
+<!-- 10 -->
+<section id="metrics">
+  <h2><span class="no">10</span>成功指标</h2>
+  <div class="tw"><table>
+    <tr><th style="width:22%">层级</th><th style="width:34%">指标</th><th>定义 / 说明</th></tr>
+    <tr><td>北极星</td><td>月度「完成投前检查的项目数」</td><td>走完 M3 人工确认流的项目才计数——它同时代表真实投标行为与产品核心价值交付</td></tr>
+    <tr><td>激活</td><td>注册 7 日内完成首个项目全链体验率</td><td>上传真实招标文件并拿到一份检查报告的用户占比</td></tr>
+    <tr><td>价值</td><td>检查问题采纳率 / 生成章节保留率</td><td>用户对 AI 结论的实际采纳程度，是准确性体感的核心代理指标</td></tr>
+    <tr><td>商业</td><td>免费 → 付费转化率、额度消耗分布、加量包购买率</td><td>额度消耗分布用于校准 8.2 的档位额度（过松亏成本、过紧伤续费）</td></tr>
+    <tr><td>留存</td><td>年订阅续费率（按企业主体）</td><td>投标是低频刚需，续费看「项目不断时是否一直用」，辅以季度活跃项目数观察</td></tr>
+    <tr><td>信任</td><td>「检查漏报」投诉数与处理闭环率</td><td>用户反馈的真实废标漏检案例逐个复盘，进规则包迭代；此指标只许内部使用，不做对外宣传口径</td></tr>
+  </table></div>
+</section>
+
+<!-- 11 -->
+<section id="risks">
+  <h2><span class="no">11</span>风险与合规</h2>
+  <h3>11.1 准确性风险（已知并接受，按辅助定位管控）</h3>
+  <ul>
+    <li>AI 漏检 / 误报可能导致用户损失：在服务协议中明确辅助定位与责任边界；产品内以检查清单 + 人工确认 + 覆盖范围明示构成完整的风险告知链。</li>
+    <li>禁止营销话术越线：不得使用「保证不废标」「零废标」「100% 准确」等绝对化表述（同时也是广告合规红线）。</li>
+  </ul>
+  <h3>11.2 合规与滥用风险</h3>
+  <ul>
+    <li><strong>围串标红线</strong>：M5 查重定位为投前自查；禁止为多家投标人协同投标同一项目提供「去雷同」服务，服务协议明文禁止，风控侧对同项目多主体异常使用保持监测。</li>
+    <li><strong>数据合规</strong>：标书含企业资质与报价信息，按敏感经营数据处理；私有化选项前置到销售流程，不等客户追问。</li>
+    <li><strong>政策面（利好但不进增长假设）</strong>：发改法规〔2026〕195 号已将「投标策划」「投标合规自查」列为「人工智能+投标」重点场景（见 1.5），本产品 M1、M2、M3 与之直接对应；但文件同时推动交易 / 监管侧场景（利好讯飞、新点等平台玩家），政策点名不等于投标方工具需求自动放量——政策因素只作背景论证，不写入本产品的增长假设。</li>
+    <li><strong>处罚加重（草案口径）</strong>：《招标投标法》修订草案拟将串通投标、行贿谋取中标等行为的罚款上限提高至现行标准的 10 倍，并对有关责任人员增设直至终身禁业的资格罚（2026-06-23 提请初次审议，尚在审议、未施行，对外沟通不得按现行法引用）。若通过施行，投标方违规成本陡增，M3 / M5 的合规价值主张进一步成立。</li>
+    <li><strong>留痕要求（草案口径）</strong>：修订草案拟明确招标投标资料保存至少 15 年、定标全过程记录可追溯（同为审议中条款）。本产品 4.1 的「全程留痕」与 M3 检查报告归档设计与该方向一致；SaaS 版项目数据的默认保留与归档策略，需在草案正式通过后按最终条文复核。</li>
+  </ul>
+  <h3>11.3 竞争风险</h3>
+  <ul>
+    <li>巧文书已五环节全覆盖并向企业版爬升：应对方式是检查深度、澄清辅助与定价透明，不打功能数量战。</li>
+    <li>开源免费（易标）压低端价格预期：免费版体验须完整跑通一次检查链路，付费理由落在「清单数据沉淀 + 团队协作 + 持续规则更新」，而非单次生成本身。</li>
+    <li>大厂入口（蚂蚁等）可能下沉：其优势在流量不在深度，深度检查与行业规则包是本产品的护城河方向。</li>
+  </ul>
+</section>
+
+<!-- 12 -->
+<section id="decisions">
+  <h2><span class="no">12</span>待决策事项（需委托方拍板）</h2>
+  <div class="decision">
+    <h4>D1 · 首发行业</h4>
+    <p>建议先选标书格式最标准化的一个行业做深规则包：候选 IT 集成 / 工程类。影响 M3 行业规则包与种子客户获取路径。PRD 默认按 IT 集成先行编写。<strong>✅ 已决策（2026-11-02）：IT 集成先行。</strong></p>
+  </div>
+  <div class="decision">
+    <h4>D2 · 专业版额度数字定版</h4>
+    <p>8.2 的解析 500 次 / 生成 300 次为建议值（参照转述样本量级）；需结合模型成本实测与种子用户用量分布在上线前定版。成本侧锚点：单份长标书 token 成本约 1 元量级（厂商自测口径），毛利空间充足，额度可适当宽松换留存。</p>
+  </div>
+  <div class="decision">
+    <h4>D3 · M1 商机数据来源</h4>
+    <p>自建标讯抓取还是采购第三方数据接口（如中策、剑鱼类数据服务），影响 V2 成本结构与上线速度；MVP 不涉及，V2 立项前决策即可。</p>
+  </div>
+  <div class="decision">
+    <h4>D4 · 企业版首单策略</h4>
+    <p>私有化交付是否等首个签约客户出现后再启动开发（路线图默认此策略），还是提前备好标准部署包用于投标演示——涉及人力投入节奏，需结合商务进展拍板。</p>
+  </div>
+
+  <footer>
+    <p><strong>数据来源与口径</strong>：本 PRD 的市场与定价事实来自 2026-10-21 两份深度调研（玩家格局 19 家、定价 13 家），文中已逐项标注证据等级与未核实事项；厂商自述数字（巧文书 5000+ 政企客户、易标 token 成本、代写价格带等）均未独立核实，不作为对外承诺依据。主要来源：快标书官网 kuaibiaoshu.com、巧文书 qiaowenshu.cn、章寻 zhangxunai.cn、剑鱼标讯 jianyu360.cn（以上为调研实访）；易标 GitHub 仓库 github.com/lylexist/OpenBidKit_Yibiao；Kimi 官方帮助中心 kimi.com；火标网 App Store 订阅说明镜像。政策依据（1.5 节）核实于 2026-10-21，2026-10-22 按双层口径复核：195 号文场景 4、场景 5 与总体目标引文已与原文逐字核对，以国家发展改革委官网原文为准；《招标投标法》修订草案据中新社 2026-06-23 报道，尚在审议、未施行。</p>
+    <p>2026-11-02 补充：政策三（政府采购体系）中第六十条已核实，第六十三条及实施条例第五十一条待原文核对。</p>
+    <p>文档状态：v0.9.1 评审稿 · 2026-11-02（v0.9 · 2026-10-21）· 待决策事项（第 12 章）关闭后升 v1.0。</p>
+  </footer>
+</section>
+</main>
+</div>
+
+<script>
+(function(){
+  // TOC highlight
+  var links = document.querySelectorAll('nav.toc a');
+  var map = {};
+  links.forEach(function(a){ map[a.getAttribute('href').slice(1)] = a; });
+  var obs = new IntersectionObserver(function(entries){
+    entries.forEach(function(e){
+      if(e.isIntersecting){
+        links.forEach(function(a){ a.classList.remove('active'); });
+        var a = map[e.target.id];
+        if(a) a.classList.add('active');
+      }
+    });
+  }, {rootMargin:'-20% 0px -70% 0px'});
+  document.querySelectorAll('section[id], .module[id], #policy').forEach(function(s){ obs.observe(s); });
+
+  // Priority filter
+  var btns = document.querySelectorAll('.filterbar button');
+  var rows = document.querySelectorAll('#scopeTable tr[data-p]');
+  btns.forEach(function(b){
+    b.addEventListener('click', function(){
+      btns.forEach(function(x){ x.classList.remove('on'); });
+      b.classList.add('on');
+      var f = b.getAttribute('data-f');
+      rows.forEach(function(r){
+        r.style.display = (f === 'all' || r.getAttribute('data-p') === f) ? '' : 'none';
+      });
+    });
+  });
+
+  // Pricing calculator
+  var rProj = document.getElementById('rProj'), rGen = document.getElementById('rGen'),
+      rParse = document.getElementById('rParse'), rSeat = document.getElementById('rSeat');
+  var vProj = document.getElementById('vProj'), vGen = document.getElementById('vGen'),
+      vParse = document.getElementById('vParse'), vSeat = document.getElementById('vSeat');
+  var out = document.getElementById('calcOut');
+  function fmt(n){ return n.toLocaleString('zh-CN'); }
+  function calc(){
+    var proj = +rProj.value, gen = +rGen.value, parse = +rParse.value, seat = +rSeat.value;
+    vProj.textContent = proj; vGen.textContent = gen; vParse.textContent = parse; vSeat.textContent = seat;
+    var yParse = proj * parse * 12;
+    var yGen = proj * gen * 12;
+    var tier, cost, note;
+    if (seat > 1 || yParse > 500 || yGen > 300) {
+      tier = '团队版'; cost = '¥4,999 /年起';
+      note = yParse > 2000 || yGen > 1200 ? '注意：已超团队版标称额度池，需购买加量包或谈企业版。' : '额度在团队版共享池内，' + seat + ' 个账号协同足够。';
+    } else if (proj <= 1 && gen <= 5 && parse <= 1) {
+      tier = '免费版先行体验'; cost = '¥0';
+      note = '用量很低，先用免费版跑通一次完整检查链路，再决定是否升专业版。';
+    } else {
+      tier = '专业版'; cost = '¥1,999 /年';
+      note = '单账号使用，额度够用；团队协作或额度不够时再升团队版。';
+    }
+    out.innerHTML = '预计年用量：解析 <strong>' + fmt(yParse) + ' 次</strong> · 生成 <strong>' + fmt(yGen) + ' 次</strong> · 账号 <strong>' + seat + ' 个</strong><br>推荐档位：<strong>' + tier + '（' + cost + '）</strong> — ' + note;
+  }
+  [rProj, rGen, rParse, rSeat].forEach(function(el){ el.addEventListener('input', calc); });
+  calc();
+})();
+</script>
+</body>
+</html>