先把范围说清楚，报价才有用
看完场地，笔记里写着“两到三台设备”；客户后来确认两台。文件夹里有两版价目表，运输还没谈定。把这些材料写成一份像样的提案并不难，难的是让已确认范围和缺口都看得见。
Anthropic 在 2026 年 9 月 15 日的小企业文章中，介绍了把现场语音备忘整理成待审核报价提案的场景。我们借鉴这个任务，另做一份原创练习：虚构的视听设备租赁团队，使用文字文件准备本地草稿，不涉及原文的连接器、发送或签署流程。
你将留下 proposal.md 和 evidence.md：前者供同事阅读，后者逐项说明数量、价格从哪里来。随后再处理一次客户变更，检查有没有丢掉未确认费用。
准备练习目录
下载虚构报价练习包，解压到新目录，先读 README。Onevium 需要已配置的模型连接；参考复算需 Node.js 20 或更高版本，无需安装依赖包。材料和价格均为教学虚构，现场记录已经是文字，无需录音或转写。
通过添加项目 → 打开已有文件夹选中解压后的项目，从该项目行新建会话，核对目录。输入框键入 @ 和文件名，可以选择项目文件。
| 文件 | 用来确认什么 |
|---|---|
field-notes.md | 客户最初考虑两到三台，数量尚未确定 |
confirmation-v1.md | 两台设备，安装四小时 |
rate-card-current.json | 2026-09-01：设备 300 元／台，安装 150 元／小时 |
rate-card-previous.json | 2026-08-01：设备 250 元、安装 120 元，仅作错版反例 |
confirmation-v2.md | 改为三台，安装明确仍为四小时；第二轮才使用 |
本例已指定当前价目表适用。真实任务不能仅凭日期更新，就认定新价格可以覆盖原有约定。第一轮先限定输入，不使用第二份确认。
同时要草稿和依据
先提供第一份确认和当前价目表。依据应精确到文件及段落或记录，例如 confirmation-v1.md 的 C1；有多条消息时，只写“根据客户要求”还不够。
为这份虚构租赁任务准备报价草稿。
仅读取 field-notes.md、confirmation-v1.md、
rate-card-current.json（2026-09-01）。
先不读 confirmation-v2.md 和 reference/；旧价不适用。
生成 proposal.md 和 evidence.md。
逐项列出服务、数量、单位、单价与小计，
合计称为“已确认小计”，不要称为最终总价。
运输、税费口径及金额、交付时间均未确认，
逐项保留待确认，不填零，也不作承诺。
evidence.md 中说明每个数量和价格对应的
来源文件与段落或记录，并列出算式。
解释客户确认如何解决现场“两到三台”的歧义。
不编造范围、折扣或商务条款。
不改输入文件，不发送消息，不发布草稿。先核对范围，再看措辞
通过“浏览全部文件”打开两个产物，自己读一次客户确认，再核对价目表和算式。第一轮应有下面两项。误用旧价目表会算出 980 元；数字整齐，并不能证明版本选对了。
| 项目 | 数量 | 单价 | 小计 |
|---|---|---|---|
| 设备 | 2 台 | 300 元／台 | 600 元 |
| 安装 | 4 小时 | 150 元／小时 | 600 元 |
| 已确认小计 | 1,200 元 |
复算时也要保留未知项
合格的草稿可以写：“设备与安装已确认小计为 1,200 元。运输、税费口径及金额、交付时间待确认，目前无法给出最终总价或交付承诺。”运输空缺不能变成包邮，小计也不能自动写成含税价。
等 AI 写完、你核对来源后，在解压项目根目录的终端运行：
node --test test.mjs
node calculate.mjs reference/scope-v1.json rate-card-current.json v1
复算返回 pricedSubtotalCny: 1200、quoteStatus: "incomplete-draft"；运输、税费和交付日期保持 null，表示未知。对照草稿；数字不同时，先要求列出数量和价目表版本，不要只让它重写得更专业。
脚本读取包内人工参考数据，不读取你的报价，也不调用模型。复算与静态测试只证明示例计算和所覆盖的规则，不能证明这次 AI 运行通过。保留实际草稿与审阅记录。
客户改数量，其余约定逐项保留
先保存第一轮草稿和依据。用系统文件管理器，在项目中创建新的 round-1 文件夹，把 proposal.md、evidence.md 复制进去。目录若已存在，换一个未用过的名字，并相应修改下方提示词。README 另有 macOS / Linux 的终端命令。
再加入 confirmation-v2.md：设备改三台，安装明确仍为四小时。这是对一项内容的修订，不是重新决定整个任务。
根据 confirmation-v2.md 更新报价。
设备数量以它为准，覆盖第一份确认：
三台设备；安装仍为四小时。
继续使用 rate-card-current.json（2026-09-01）。
不要读取 reference/。
更新项目根目录的 proposal.md 和 evidence.md，
不要改动 round-1/ 中保存的第一轮副本。
列出具体变化，引用新确认。
保留第一轮所有未确认事项。
不发送、不发布任何草稿。检查变化，再决定该问什么
审阅更新后的草稿，再运行第二轮参考复算：
node calculate.mjs reference/scope-v2.json rate-card-current.json v2
预期结果为 3 × 300 + 4 × 150 = 1,500 元。设备从 600 元变为 900 元，安装仍为 600 元，已确认小计增加 300 元。两个产物里的设备数量应指向第二份确认，价格仍引用适用价目表。
看完整的新稿，不只看改动的数字。运输和税费仍待确认，交付时间也没确定，算对了不等于可以发送。后续消息若有歧义，列出不同解释，让任务负责人确认。
把缺口写成同事能回答的问题：运输怎样安排、费用多少？适用什么税费口径和金额？团队能承诺什么交付时间？补齐事实后，再由负责人按团队流程批准最终报价。
迁移到真实工作时，先选一个获准使用的项目和适用价目表，核对资料可以提供给谁，包括配置的模型服务商。保留来源确认与审阅后的草稿，让接手的人能解释这次改了什么。