tor-procurement

/tor-procurement — 编写、审阅和评估采购 ToR

目标只有一个：让采购 ToR 达到公开市场标准。核心依据是 references/open-market-checklist.md——AI-for-Research ToR 经手动修改四轮（v0.4→v0.7，2026 年 7 月）才达到的 22 项标准。新 ToR 从这一标准起步；现有 ToR 则按此标准评估。

模式路由

• build — 尚无 ToR，或 Ane 想从头开始。
• review — 已有 ToR；Ane 想了解优缺点并获得评级。只读。
• respond — 指定的审阅者对 Ane 撰写的 ToR 提出了意见，她需要回复审阅者。生成回复文本，不编辑文档。仅在同意让步的情况下交由 finalise 处理。
• finalise — 已完成审阅，或 Ane 提供了已达成一致的修订内容；只应用这些修订，不做其他修改。

如果模式不明确，先用一句话提问，再开始处理。

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

• 修改 ToR 前，先阅读 references/open-market-checklist.md。
• 事实可靠性。 绝不编造预算金额、姓名、日期、地址或资金来源。任何未经确认的信息都要放在方括号内，并加入“内部准备说明 — 发布前删除”清单（检查清单第 21 项）。在已发布的 ToR 中，貌似合理的占位内容可能会被当作事实并据此采取行动。
• 构建前先收集信息。 开始编写前，先与 Ane 确认关键信息；工作文件会变得过时（会话效率协议）。
• 已发布的 ToR 面向外部：采用 Tier 1 通俗英语，通过可译性测试（投标人往往并非英语母语者），缩略语首次出现时须写出全称。
• 如果 ToR 包含 MEL 内容（指标、评估设计、学习问题），则须遵循 /mel-framework-citation 的引用标准。

构建模式

1. 收集信息 — 通过一条批量消息询问五项关键信息：(a) 采购内容和交付成果；(b) 预算上限、增值税处理方式、资金来源，以及任何捐助方的支出期限；(c) 时间节点——发布日期、合同签署日期、最终验收日期；(d) 评审小组，以及有人休假期间由谁负责问答；(e) 合同类型——个人／团队／公司、咨询还是服务、公开市场采购还是单一来源豁免。
2. 逐项核对清单 — 应用每一项，或记录其不适用的原因（适配说明涵盖服务合同和豁免）。起草前，根据资深人员的合理工作日数检查预算上限是否合理；如有冲突，应明确指出——报价过低是评审时的主要关注点。
3. 生成 — 将 scripts/tor_docx.py 复制到项目中，保存为 <project>/generators/gen_tor_v01_docx.py，保持构建器不变，按规范章节顺序将 ToR 正文写成线性构建器调用，然后运行并确认 docx 正确呈现。与交付文件放在一起的生成器才是事实来源；切勿同时编辑 docx。版本文件名依次为 v0.1、v0.2 等。
4. 验证写入的文件，而非运行过程 — 重新打开保存的 docx，并断言其中存在页眉部分、徽标关系和页脚色带。生成器顺利退出并不能证明品牌元素已应用：AI-for-Research ToR 的 v0.4 到 v0.9 都报告成功，但交付的文件都没有品牌元素，因为构建器从空白的 Document() 开始。python scripts/test_tor_docx.py 会针对两种页眉模式运行这些断言。
5. 交付 — 提供 docx 路径、生成器路径、需要 Ane 决定的清单事项，以及尚未处理的准备备注。

构建器为何会打开信笺模板。 字体和颜色可以在代码中设置，但徽标、页眉联系信息块和支柱页脚色带只存在于 ippf_en_letterhead_base.docx 中。因此，TorBuilder 会打开该素材并清空正文，同时保留节属性；它还会从 ane_package.reporting.brand 导入品牌值，而不是重新声明——在构建器中复制一份颜色值，无法在模板变更时自动更新，这也是项目 CLAUDE.md 将其视为 QA 驳回理由的原因。

页眉模式。 TorBuilder(header="slim") 是默认模式，也是多页 ToR 的理想选择：保留品牌色带和徽标，同时移除联系信息块，以免它占据每页顶部空间。header="full" 会保留联系信息块，适合单页封面说明。运行生成器时使用 --header full|slim 即可切换。

构建器已处理的两个陷阱 — 除非测试过替代方案，否则不要改动。信笺模板没有 Table Grid、List Bullet 或 List Number 样式，因此表格会自行绘制边框，列表会自行写入项目符号；尝试使用这些样式名称会引发 KeyError，事后捕获该错误会留下孤立段落，过去曾因此导致每个项目符号都重复一遍。联系信息块还以两种形式存储：mc:Choice 绘图和 mc:Fallback VML 副本，因此精简模式会移除整个 mc:AlternateContent 父元素——只移除绘图会导致文本仍然显示。

如果生成器找不到 ane_package，请将 WORK_FOLDER_ROOT 设置为工作文件夹。构建器会优先解析该变量，然后从自身所在位置逐级向上查找。找不到时会明确报错，而不会退回到硬编码的品牌值，因为静默回退会导致未带品牌元素的文件看起来一切正常并被交付。

审查模式

只读：此模式绝不编辑 ToR。对于 docx 输入，先提取文本（使用 python-docx 读取）；对于 markdown 或生成器源文件，直接读取。

1. 阅读 ToR 和清单。
2. 视角 1——资深采购官。 审查流程可辩护性和资金：清单 A、B、C、E 组。面对落标方、审计员或捐助方的质疑，这份文件能否经受住考验？
3. 视角 2——任务领域专家。 审查范围是否现实、验收标准、工作天数是否符合预算上限、方法是否适用，以及优秀顾问能否仅凭文本准确报价。
4. 输出，先给结论摘要（BLUF）：结论句；优点；缺点（各自对应一个清单条目并附上建议修改措辞）；评分 1–10；偏差说明。

评分基准：5 分或以下 = 不可发布，存在结构性缺陷；6–7 分 = 按所列修改完善后可发布；8 分 = 符合公开市场标准；9–10 分 = 仅适用于已通过外部审阅的 ToR。必须始终包含偏差说明：

同一模型对自己参与编写的本文档自评为 N/10——请将此视为上限。建议由 [具名同事] 对 [最薄弱章节] 进行外部审阅，再行发布。

回复模式

审查与定稿之间的阶段。具名审阅者对某个条款提出异议，任务是回应对方。通常正确的处理结果是不修改文档：四种判定中有三种会使 ToR 保持原样发布。

判定	含义	ToR 是否修改
defend	条款按现有措辞是正确的，以下说明其实际含义。	否
concede	审阅者的意见是正确的。指出最小限度的修改，不作其他扩展。	是
defer	问题确实合理，但不适用于本合同。估算后续工作的规模。	否
escalate	这是 ToR 无法解决的治理问题。指出负责人。	否

复合答复由一个主要判定和一个次要判定组成。defend + defer 是参考情形：保留条款，并将审阅者要求的工作作为单独合同进行估算。拒绝 defend + concede，因为条款不可能既按现有措辞正确，又需要修改。

步骤

1. 阅读 ToR 和 references/open-market-checklist.md。 异议往往就是从外部送来的清单。
2. 提取异议。 python scripts/tor_respond.py extract "<ToR>.docx" --json round.json。它会报告每个讨论串、所在章节以及是否已有答复。它会告诉你评论列表无法告诉你的三件事：
   • 锚点不是条款。 审阅者选中一个短语，写下的却是对其背后论点的意见。起草前应阅读整个章节，而不只是高亮文字。
   • 她自己的页边批注会单独列出。 那些是工作笔记，不是异议；没人等着收到答复。
   • also commented here 会列出在单独讨论串中评论过同一段落的人。只有使用回复按钮时，Word 才会将内容记录为回复，因此她已输入的答复可能会紧挨着异议，看起来像一条新评论。回答之前先读一遍，避免重复作答。
3. 作答前，先陈述异议最有力的版本（默认先质疑）。针对最弱的解读作答，往往会让一项异议变成四轮讨论。审阅者有道理时就承认；什么都辩护，谁也说服不了。
4. 依据文件内容作答（确保事实可靠）。每项辩护都要引用其依据所在的 ToR 章节或治理文件。切勿断言无法找到来源的机构事实：一份日期为 2026-07-31 的答复草稿中曾有一句“我们可能没有 DPO”的附注，从未核实过，却可能会被当作事实发给外部读者。守卫会拒绝没有任何引用依据的辩护。
5. 起草两种长度的答复。 完整版用于电子邮件或会议；精简版用于 Word 评论窗格，因为扫一眼看不完的答复就不会有人读。字数上限默认分别为 500 和 180 字，这是可配置的设置，不是固定值。
6. 对于暂缓处理的裁定，明确后续工作的规模。 列出选项、说明顾问档案与之有何不同、标明未经成本估算的参考范围，以及足以证明委托这项工作的触发条件。用禁止回应合理意见，只会引来下一轮；用计划回应，才能让讨论结束。
7. 编译。 python scripts/tor_respond.py compile round.json --out <dir> --docx。生成 replies.md（每项异议各有两种长度的答复，并附规模估算草案）和 response-register.md（每项异议一行，另附 finalise 模式使用的修订清单）。--docx 会将两份文件渲染为带品牌样式的 Word 文档。

守卫会拒绝什么

compile 会在写入前运行所有守卫，并且拒绝自相矛盾的答复轮次，因为 finalise 模式会据此执行操作。会阻止写入的情况包括：裁定相互矛盾、编辑项关联的并非让步、让步没有注明任何编辑、暂缓处理却未说明后续工作的规模、辩护没有引用来源、答复为空、选项估算为零天。仅发出警告但仍会写入的情况包括：答复过长、缺少最有力的异议陈述，以及 ane_package.qa.prose_lint 检查出的常见行文问题（模棱两可、填充语、破折号）。

界限设在错误会传到 Ane 以外的人手上的地方。长度和语气属于写作技巧，她可以在窗格中修正。矛盾或无来源的主张会发送给具名的外部审阅者，撤回的代价高于及时发现。--force 可以覆盖限制，并会明确说明。

规模估算草案中不会凭空捏造任何内容。 未经任何人估算的选项会标为未经成本估算，而非估算为零；采购路径仅依据已提供的阈值进行评估。此技能本身不设阈值。

答复之后

只有让步的异议才会列入 finalise 模式的修订清单。其他所有异议都会随答复一并结案。如果 Ane 将答复作为 Word 评论回复发送，她会手动粘贴；此模式不会写入她的文档。

定稿模式

1. 确认已商定的修订清单（来自审阅意见或 Ane）。范围仅限该清单，不得扩展。
2. 如果目标文件存在，则遵循 mel_wiki/wiki/concepts/edit-preservation-protocol.md——Ane 当前的内容是权威基准；先阅读，再使用 Edit 工具严格按范围编辑，范围外的所有内容都必须逐字节保持不变，并按照 EDIT-PRESERVATION DELIVERY 格式报告范围外的观察结果。绝不能从头重新生成。
3. 对于 docx 交付物，编辑目标是生成器源文件：将当前的 gen_tor_v0N 复制到 v0N+1，在那里应用商定的编辑，然后重新运行，并报告新的 docx 路径。绝不能编辑 docx 二进制文件。
4. 收尾时，逐项列出每项商定内容及其落点，并列出发布前仍未处理的准备说明事项。

范围边界

• 在采购渠道发布、财务与 VAT 确认、签约实体及法律签署仍由各自负责人负责——在他们确认之前，ToR 保留相应占位符。
• 回复对 Ane 自己的 ToR 提出意见的审阅者，属于上文所述的回复模式。审阅 Ane 已评论的第三方草稿，方向正好相反，这不属于此技能：在那种情况下她是审阅者；在这里她是回应外部意见的作者。不得根据其中一方重新构建另一方。
• 评估收到的报价并确保豁免文件包保持一致，属于下一阶段生命周期（procurement-offer-review，构建于 2026-07-22），不属于此技能。
• 在 IPPF 之外发布的 ToR 属于 AI 辅助出版物：应提供 mel_wiki/wiki/concepts/ai-use-in-publications.md 中的标准署名说明（仅涉及常规语法的编辑除外）。