让AI做报价计算器，先把算例讲清楚

用自然语言生成报价计算器之前，先明确阶梯价格、固定费用、空值与舍入规则。通过边界算例检查工具是否算对，避免把可运行界面误当成可对外发送的正式报价。

一个报价计算器可以很快做出界面：填数量，选包装，显示总价。难的是销售和财务看见同一组输入，是否会算出同一个结果。规则没有说清，AI仍然可能生成一个能运行的工具，只是它替你选择了某种解释。

AWS在9月1日公布Amazon Quick自然语言创建自定义应用的能力。对想做内部小工具的外贸团队，这减少了从想法走到可操作界面的阻力。但“做一个报价计算器”距离完整需求还很远。官方公告介绍的是通用应用能力，并没有替企业定义报价方法。

先写出人工怎么算，再描述按钮长什么样

阶梯价格就是容易被省略的细节。达到某个数量后，是全部商品采用新单价，还是只有超过门槛的部分享受新价？两种算法都能写成程序，结果却不同。给AI一句“支持阶梯折扣”，无法替代这个选择。

固定费用也一样。制版费可能按订单收取，包装费用可能随件数变化；样品费能否抵扣，又可能取决于后续订单条件。把它们都放进“附加费用”输入框，界面更整齐，计算含义却变得模糊。先为每项费用注明计价对象，再考虑是否需要合并显示。

数量的单位应当紧挨着输入框。买家输入的是件、盒还是整套，决定了价格乘以什么。若商品还有组合装与最小起订量，先厘清包装数量与订购单位的区别，再写计算公式。不能靠页面底部一段说明，补救上方字段的歧义。

可以准备几组人工能够复算的输入：刚好达到阶梯门槛、略低于门槛、没有选择附加服务，以及费用尚未确认。每组先写预期结果和理由，再让工具计算。这样查出来的是规则差异，而不仅是按钮能不能点。

“空白”和“零”尤其值得分开。运费留空可能表示尚待确认；运费为零则可能表示不收取。若系统都按零处理，总价会显得完整，实际上漏了一项待定成本。更合适的呈现是保留商品小计，同时明确哪些部分尚未计入。

舍入也需要固定顺序。逐行取整后相加，与先加总再取整可能不同。涉及多币种时，原币金额、所用汇率和报价币种不能只剩最后一个数字。这些规则应由负责报价的人确定，再交给工具执行，不能由生成过程默默补齐。

测试并不需要一次覆盖所有商品。先选规则明确、例外少的一类产品，把正常输入和容易出错的边界都走通。遇到必须临时谈判才能决定的折扣，让结果标记为待确认，比把谈判判断塞进默认公式更可靠。

内部计算器的输出可以帮助整理成本和生成报价草稿，却不应自动代表交期、有效期或付款条件已经获准。界面可以把计算依据与待确认事项一起展示，销售据此检查，再决定是否发给买家。

对于中国供应商，第一版工具真正需要证明的，是同样的输入会得到符合公司规则的结果。漂亮界面、可分享链接和自动生成文案，都可以往后放。先拿出几组双方认可的算例，才能知道这个工具究竟替团队省下了重复计算，还是把分歧藏到了屏幕后面。