e29c40ec41
- PRD v0.9.1：补充政府采购体系依据（87 号令），异常低价口径按体系分层 - decisions.md：D1 首发 IT 集成、A1 需求分析 G1–G10、T1 国产云端模型路由 - docs/analysis：范围与角色、用户旅程、功能需求、领域模型、 IT 集成领域知识、缺口清单、苏采云样本分析 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
94 lines
7.6 KiB
Markdown
94 lines
7.6 KiB
Markdown
# 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）。
|