procurement-offer-review

/procurement-offer-review — 审查供应商报价，确保采购资料包一致

仅负责采购的接收环节。供应商针对 IPPF ToR 提交技术和财务报价后，此技能会检查报价并提出意见；当决策发生变化时，确保内部资料包（ToR、豁免理由说明、最佳价值说明、采购检查清单）保持一致；在多投标方评估中比较评分。起草环节（编写 ToR）由上游的 tor-procurement 负责。

模式路由

• OFFER-REVIEW — 收到报价或修订后的报价；Ane 希望检查其是否符合 ToR，以及（如有）是否符合她上一轮的意见。只读供应商文件；可选择写入 _COMMENTS 副本。
• PACK-PROPAGATE — 一项采购决策发生变化（签约实体、预算金额、结构、日期）；在所有资料包文档中统一更新。
• SCORE-COMPARE — 进行包含评分工作簿的多投标方评估；创建或链接评估者与 AI 的对比结果。

如果模式不明确，请先用一行询问，再开始处理。

共享规则 — 适用于所有模式

• 绝不编辑供应商的文件。 报价是供应商的文档。意见应写入名为 <original>_COMMENTS.docx 的副本；分析写在聊天或内部备注中。如果报价是 PDF，则在聊天报告中给出意见（PDF 是供应商的冻结记录——这是优点而非问题：它也能防止过时的批注残留）。
• 事实可靠性。 绝不编造或估算金额、实体名称、SIREN/VAT 号码、日期或审批信息。报告中的每项数据都必须追溯到明确指出的文档或确认信息。缺失的信息应如实报告。
• ⚠ 财务确认约定。 此技能绝不认定符合 CERV、VAT、分包或采购手册要求。它只说明文档中的内容，指出其中的矛盾，并标记 ⚠ Finance to confirm: [question]。合规判断由财务部门和豁免签署人负责。
• 保留原件。 在处理任何内部资料包文档前，记录其时间戳；按照资料包的惯例，写入带版本号或后缀的副本。Ane 会在会话中手动编辑并重命名资料包文件——编辑前重新列出文件夹，并立即重新读取每个文件，绝不要依据之前读取的内容进行编辑。
• OneDrive 还原风险。 在非 git 的 OneDrive 文件夹中，同步可能会在几秒内静默还原刚写入的内容。写入任何文件后，务必重新读取已更改的行，确认内容已写入。在 git 文件夹中，应在同一代码块中写入并提交。
• 文本提取机制（docx 文本、修订、评论 XML、PDF 文本、openpyxl 公式）请参阅 references/docx-xlsx-mechanics.md。编写任何评论、就地编辑 docx 或编辑工作簿公式前，请先阅读该文件。

证据卡片——逐项标准综合（OFFER-REVIEW 和 SCORE-COMPARE）

两种评估模式都会为每项 ToR 要求或评分标准生成一张证据卡片。委员会成员阅读的是卡片，而不是分类结果或分数。

撰写每张卡片时，都要面向没有起草 ToR、也不是采购对象领域专家的读者。这描述了大多数采购委员会成员；只要主题不是监测、评估与学习（MEL），Ane 也属于这类读者。没有卡片的分类结果不算结论。没有来源位置的卡片不算证据。

也可以单独要求撰写卡片（“为每项标准整理证据”），并以现有评分工作簿或评审为依据。

六个字段，顺序如下：

1. 这项要求是什么。 用通俗英语写一句话。ToR 引用放在末尾的括号中，绝不能放在开头。
2. 为什么重要。 用一句话说明投标方在此项表现不佳会造成什么实际后果。内容要针对这份合同。泛泛而谈的风险描述不符合此项要求。
3. 投标方提供了什么。 写明证据及其位置（章节或页码）。如果判断取决于确切措辞，请引用关键短语。
4. 缺失或不清楚的内容。 清楚说明缺口。“未说明”是合理且有用的填写内容。
5. 判断。 符合／部分符合／缺失／不符，或按模板自带的评分等级填写分数及对应等级标签。
6. 需要什么才能改变判断。 具体说明哪些证据能将此项提高一个等级。这能让判断接受检验，也可直接用作发给投标方的澄清问题。

卡片的语言规则。 使用第 1 级工作简报的语言；读者是同事，不是专家。

• 每张卡片中的每个缩写都要写出全称。卡片会被打乱顺序单独阅读。
• 每个技术术语首次出现在卡片中时，都要用不超过六个单词解释。
• 用实际操作后果来说明。“合同结束时，我们无法取回自己的数据”胜过“供应商锁定风险”。
• 多用日常英语动词，少用拉丁词源的正式动词：用 not utilise，不用 utilise；用 run，不用 facilitate；用 check，不用 ascertain。
• 句子少于 25 个单词，用主动语态，并先写行动者。

两条硬性规则：

• 字段 2 的依据来自 ToR，只要 ToR 说明了理由。 如果 ToR 没有说明，卡片就写 (rationale inferred, not stated in the ToR)。绝不能把自己的推断说成 ToR 的意图。
• 字段 3 中的每项陈述都必须附带位置。 没有位置的陈述不得写入卡片。

交付前的读者测试。 选一张卡片，问自己：从未读过 ToR 的委员会成员，能否理解要求是什么、为什么重要，以及这家投标方为何得到这个判断？如果不能，这张卡片就不合格；应修改字段 1 或字段 2。问题几乎从来不是字段 3 的细节不够。

OFFER-REVIEW 模式

输入：报价文件（docx 或 PDF）、其对应的 ToR，以及——如果是重新提交的报价——Ane 上一轮的意见（边注和／或修订；从 docx XML 中同时提取两者，它们记录了谈判历史）。

1. 先提取全部三份材料，再作任何判断。对于重新提交的报价，整理 Ane 上一轮提出的要求：每条边注和每项修订插入都算作一项要求。
2. 逐条核查 ToR 条款。 针对每项 ToR 要求（范围项目、交付物、预算明细、知识产权与移交、VAT 声明、安全保障、报告），撰写一张证据卡。已满足／部分满足／缺失／不一致的分类是证据卡的第 5 栏，并非完整答案。另行记录报价中没有 ToR 依据的内容——新增范围项目需要经过明确接受，尤其是涉及安全或访问模型的内容。
3. 自行核算。 重新计算每一项合计：天数 × 费率、VAT（净额 × 税率 = 总额）、预算明细合计，以及每项上限与批准金额的对照。表格中的数字一致、但封面页的数字不一致，是常见的版本漂移——检查每个数字的所有出现位置，而不只是第一次出现的位置。
4. 核实上一轮意见的处理情况。 针对 Ane 上一轮提出的每项要求，判断为：已采纳／部分采纳／未采纳。未采纳的内容属于问题，不是脚注——它们是谈判中尚未解决的立场。
5. 留意已知陷阱（每个都会让审核多花一轮）：ToR 要求转让所有权，却只授予许可；许可范围被悄悄缩小（“仅限 X 网络内”）；ToR 和报价中列出的预付款触发条件名称不同；交付时间调整了，付款安排却没变；某个延期组件的安全影响未说明（例如提交内容没有审批关卡）；暗示会提供托管／维护服务，却从未作出承诺。
6. 按修复成本从低到高排列遗留问题，顺序如下：(a) 合同优先顺序——合同注明以哪份文件为准，无需重新出具文件；(b) 通过电子邮件作出一行书面确认；(c) 由供应商重新出具文件——仅对可能误导签署人或审计人员的错误采用此方式。尽量减少重新出具文件的轮次，这本身就是目标：每次重新出具都会耗费一周。
7. **先给出 BLUF：**先用一句话给出结论（符合／符合但有 N 项遗留问题／不符合），然后说明已采纳的内容（逐条确认），接着按编号列出遗留问题，并注明严重程度和修复方式，最后列出利好内容（新增范围、已解决事项）。证据卡作为附件列出，每项要求对应一张，方便读者无需通读报价即可核查任何一项判断。可提出代拟一封说明修复方式的回复。
8. 边注（仅应要求提供，且仅适用于 docx 报价）。 使用 scripts/add_offer_comments.py 在 _COMMENTS 副本中撰写锚定的评论。每条评论都应锚定到相关的具体段落；锚定到错误段落比不加评论更糟。

PACK-PROPAGATE 模式

一个决定，多个文档。此模式旨在避免以下问题：某个数字或实体在三个文件中发生变更，却悄然在第四个文件中保留旧值；或者替换整个段落时漏掉了两句，却无人察觉。

1. **编辑前，用一行说明决定：**旧值 → 新值，以及涉及哪些文档。如果决定是隐含而非明确说明的，请向 Ane 确认。
2. **清点文档包。**重新列出文件夹内容（文件名可能有变），然后搜索文档包中的每份文档，查找旧值的所有出现位置，包括衍生形式（由未含 VAT 的数字推算出的含 VAT 数字、已更名实体的旧缩写、页脚中的旧日期）。
3. **就地编辑，尽量缩小范围。**目标文件存在时，遵循 mel_wiki/wiki/concepts/edit-preservation-protocol.md：先阅读，严格限定编辑范围，并确保变更之外的所有内容与原始字节完全一致。对于 docx：匹配段落文本，只重写最小范围内的文本片段，保留 Ane 手动修改的内容。不要为了更改一个数字而替换整个段落——编辑前后都要统计句子数量；数量不符即表示内容有遗漏。
4. **扫描残留。**完成所有编辑后，重新提取文档包中的每份文档，再次搜索旧值及其衍生形式。逐文件报告：已更改（N 处）／已是最新／⚠ 发现残留。扫描结果是交付内容——只编辑而不扫描，就只完成了一半工作。
5. **标记，不做决定。**任何涉及合规声明的编辑（采购金额区间、豁免理由、VAT 处理、捐赠方规则），都要在报告中标记为 ⚠ Finance to confirm，即使编辑本身只是机械性修改。

SCORE-COMPARE 模式

用于多投标方评估，并配有评分工作簿（评估人的工作矩阵 + 官方评估表）。这是经过验证的做法；公式和注意事项见 references/docx-xlsx-mechanics.md § Workbook。

1. **先确定唯一事实来源。**将官方评估表的分数单元格（以及任何重复基准的工作表）通过公式关联到评估人的 Evidence Matrix，这样只需编辑一次分数，所有关联工作表都会随之更新。建立关联前，先对比工作表——工作表中的静默修订会在公式链接建立后立即改变官方分数。发现任何差异都要指出，并先备份工作簿。
2. **比较选项卡：**按评审标准并排显示评估人评分／AI 评分／差异，另列总分、排名和门槛一致性列。标记规则以模板自身的评分区间为准：红色 = 差异 ≥ 评审标准满分的 20%（一个完整评分区间）或总分相差 10 分以上；琥珀色 = 10–19%（或总分相差 5–9 分）；门槛分歧和排名变动 3 名及以上须分别标记。使用实时公式和条件格式，不要粘贴数值。
3. **在分数旁添加评分卡。**比较选项卡会显示评估人和系统在哪些地方存在分歧，但不会显示原因；只看分数的委员会无法核实任何一方的评分。添加 Criterion cards 工作表：每项评审标准占一行，评分卡的六个字段各为一列，文本自动换行；评审标准 ID 与比较选项卡保持一致，使红色差异单元格只需查找一次，就能找到背后的证据。评估人和系统评分不一致时，字段 6 应说明需要哪些证据才能作出判断。
4. **比较结果用于参考，最终由评估人决定。**AI 评分绝不覆盖评估人评分；设置该选项卡是为了让人关注分歧，而审阅者是 Ane。

范围边界

• 起草或评审 ToR 本身属于 tor-procurement（上游环节）。授标后的跟踪属于 implementation-pack。面向捐赠方的提案属于 /proposal。
• 合同起草、签署流转，以及每个 ⚠ 标记背后的合规判断，均由 Finance、预算负责人和豁免签署人负责。
• 内部文档包属于内部文件：列入 Tier 1 登记册，但无需添加外部发布用的版权页。如果评审结果要发送给供应商（评论副本、回复邮件），应采用 Ane 的口吻——合作、具体，不含糊。