版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
第 1 章 先把「算」和「猜」拆开
1.1 一个报价算错，比一句话说得别扭贵得多
跨境电商岗每天打交道的数字，几乎都是「有唯一正确答案」的那种：一笔订单要收多少、一个包裹按几公斤计费、这批货到目的国要缴多少税。这些数字手算错了，客户会来对账；如果是模型算错了，客户一样会来对账，只是错得更隐蔽、更难解释。
大模型（指能理解自然语言、并生成文本的大规模语言模型）最擅长的是「猜」：猜你想问什么、猜这句话属于哪个类目、猜怎么措辞更清楚。它不擅长的是「算」。这里的「不擅长」不是指它偶尔会算错，而是指它的计算过程本身不可复算——同样的输入多跑几遍，数字可能不一样。这件事连厂商自己也是承认的：Anthropic 官方的代码执行工具文档里就写明了分工，原文是：
Claude runs code when the request benefits from computation or file handling:
- Non-trivial math (large numbers, many steps, precision-sensitive results)
- Data analysis, file parsing, or visualization
- Algorithm execution or simulation
- Explicit requests to “run”, “compute”, or “execute”
也写明了哪些不用走代码：「Simple arithmetic and well-known math facts」以及「Simple unit conversions or translations」。也就是说，厂商划的线是：涉及多步、精度敏感的计算交给代码，常识性的一步运算才允许直接回答。
合规层面，这件事也有出处。《生成式人工智能服务管理暂行办法》第四条第（五）项要求提供者「基于服务类型特点，采取有效措施，提升生成式人工智能服务的透明度，提高生成内容的准确性和可靠性」。对做业务的团队来说，最实在的「有效措施」之一，就是把算不准的环节从模型手里拿走。
1.2 本文唯一的判据：可复算性
确定性计算（结果只由输入决定、不受随机性影响的计算）该不该交给模型，判断标准只有一条——可复算性：同一份输入，跑两次，结果必须完全一致，连小数点后两位都不能变。
这个判据的好处是能当场验证：把同一段输入连着跑三遍，把三次输出并排贴出来看。只要有一次不一样，这条链路就不该上生产。不需要讨论「它的能力有多强」，只要看输出稳不稳。
1.3 三条进场信号
把日常任务过一遍，凡是落进下面这张表下三行的，一律走工具。
表1：哪些活可以给模型，哪些活必须给工具
| 动作 | 做错了会怎样 | 该谁做 | 判据 |
|---|---|---|---|
| 判断客户在问价还是催发货 | 最多答非所问，重问一次 | 模型 | 容错，可复算性不适用 |
| 从聊天记录里抽币种、重量、尺寸 | 抽错字段，但能被下游校验拦住 | 模型（抽完必须校验） | 抽取结果要可被规则校验 |
| 把一句话改写成客服话术 | 语气不理想，不影响事实 | 模型 | 容错 |
| 汇率折算 | 收付款金额对不上，形成对账差异 | 工具 | 同一输入两次必须一致 |
| 体积重与计费重 | 运费报错，平台按自己的算法重算 | 工具 | 系数来自官方规则，必须可复算 |
| 满减券与折扣叠加 | 多收或少收，直接涉及资金 | 工具 | 顺序必须写死并留痕 |
| 分段税率计算 | 税额报错，可能产生争议 | 工具 | 分段阈值进配置表 |
这张表就是全文的骨架：上三行允许试错，下四行不允许试错。
第 2 章 汇率：同一个币种，官方页面上有五个价格
2.1 官网一行的五个数字
外汇牌价（银行挂出来的外币买卖报价）在银行官网上是一张表。以中国银行官网 2026-10-03 04:47 发布的牌价为例，美元这一行同时给出五个数字。
表2：中国银行官网牌价页「美元」一行（2026-10-03 04:47 快照）
| 列名（官网原样） | 该行数值 |
|---|---|
| 现汇买入价 | 669.87 |
| 现钞买入价 | 669.87 |
| 现汇卖出价 | 672.69 |
| 现钞卖出价 | 672.69 |
| 中行折算价 | 673.51 |
同一时刻，买入与卖出之间相差 2.82，相对差约 0.42%。这个差价不是舍入误差，是银行报价本身的结构。所以「用哪一列」不能靠模型去「理解上下文」，只能靠业务规则显式指定。
需要说清楚一点：该官网页面只有列名和数字，没有对这五列逐条给出释义文字。这五列各自的官方释义，本文只核到非官方转载来源，因此在附表 A 中标注「待验证」；下表只用列名与数值本身。人民银行的通知只明确了挂牌价的定价权在银行：银行可基于市场需求和定价能力自主挂牌人民币对各种货币汇价，「现汇、现钞挂牌买卖价没有限制，根据市场供求自主定价」。
2.2 「取哪一列」必须是显式参数
把汇率交给工具，做法是把「币种 + 取哪一列 + 取数日期」做成必填参数，模型只能填参数，不能填结果。
⚠️代码待验证
{"name":"get_bank_rate","description":"查询指定币种在指定日期的银行外汇牌价。汇率以银行官方渠道为准，模型不得自行推算。","input_schema":{"type":"object","properties":{"currency":{"type":"string","description":"币种三字母代码，如 usd、eur"},"rate_type":{"type":"string","enum":["cash_buy","spot_buy","cash_sell","spot_sell"],"description":"要取哪一列牌价，必须是这四项之一"},"trade_date":{"type":"string","description":"取数日期，格式 yyyy-mm-dd"}},"required":["currency","rate_type","trade_date"]}}enum的作用是把「用哪一个价」变成一道选择题：模型只能从四个选项里挑一个，挑不出来就得问用户，而不是自己编一个数。
2.3 汇率是取数，不是换算
模型在这条链路里该做的，是从「客户说下个月按美元结，能不能先按今天的价算一版」里抽出currency=usd、trade_date，并判断这属于哪一种报价场景。它不该做的，是凭记忆报一个汇率，或者「按大概七点几先算一下」。
一句话：把「取哪个数」变成参数，把「取数」变成调用，把「算」变成函数。
第 3 章 体积重与计费重：系数进配置，不进提示词
3.1 长 × 宽 × 高 ÷ 计费系数，再和实重取大
体积重（把一个包裹占的空间折算成的重量）和计费重（最终用来算运费的重量），在承运商官方说明里写得很直接。DHL 官方帮助中心的原文是：
Shipping charges for DHL eCommerce packages are calculated based on the greater of dimensional and actual weight, referred to as Chargeable Weight.
翻译过来就一句话：取尺寸重量和实际重量里较大的那个。计算式是三步，每一步都能复算。
3.2 同一个物流商，两套系数
问题出在「除以几」。同一个物流商，不同产品线的官方页面给的系数并不一样。
表3：同一包裹（40×30×50 厘米，实重 8 千克）在不同官方规则下的结果
| 官方页面 | 单位 | 计费系数 | 体积重 | 计费重（取大） |
|---|---|---|---|---|
| DHL eCommerce 帮助中心 | 厘米 | 6000 | 10.00 千克 | 10.00 千克 |
| DHL Express 说明页 | 厘米 | 5000 | 12.00 千克 | 12.00 千克 |
| DHL eCommerce 帮助中心 | 英寸 | 166 | —— | —— |
| DHL Express 说明页 | 英寸 | 139 | —— | —— |
两个厘米系数都来自 DHL 官方页面，同一家物流商的两套口径，算出来的计费重差 2 千克。所以任何一篇告诉你「体积重就是除以六千」的说法，最多只对了一半。系数是随承运商、产品线和计量单位变化的变量，不能写进提示词，也不能写死在代码里。
3.3 一条规则 = 一个可复算的函数
⚠️代码待验证
fromdecimalimportDecimal,ROUND_HALF_UPdefvolumetric_weight(length_cm,width_cm,height_cm,divisor):"""体积重 = 长 x 宽 x 高 / 计费系数。系数按承运商与产品线的官方规则传入，不写死。"""volume=Decimal(str(length_cm))*Decimal(str(width_cm))*Decimal(str(height_cm))return(volume/Decimal(str(divisor))).quantize(Decimal("0.01"),rounding=ROUND_HALF_UP)defchargeable_weight(actual_kg,length_cm,width_cm,height_cm,divisor):"""计费重 = max(实重, 体积重)"""dim_kg=volumetric_weight(length_cm,width_cm,height_cm,divisor)returnmax(Decimal(str(actual_kg)),dim_kg)这里刻意用Decimal（十进制精确小数）而不是普通浮点数。原因是浮点数存不下大多数十进制小数：Python 官方文档的原话是「Unfortunately, most decimal fractions cannot be represented exactly as binary fractions」，并且举了个非常贴近业务的例子——由于 0.1 不是精确的 1/10，三个 0.1 相加并不等于 0.3。同一份官方文档也直接建议：需要精确十进制表示的场景，用decimal模块，它「suitable for accounting applications」（适合账务类应用）。这句话是判断「钱要不要用浮点」时最省事的一条依据。
一句话：系数是配置，不是常量；规则是函数，不是提示词。
第 4 章 价格阶梯与优惠叠加：顺序不同，结果不同
4.1 同一组输入，三种答案
把「打折」和「满减券」放到一起，最容易被忽略的是顺序。原价 200 元，八折，另有一张「订单满 200 减 30」的券。
表4：同一组输入（原价 200、八折、满 200 减 30 券）在不同顺序下的结果
| 叠加顺序 | 第一步 | 第二步 | 最终价 |
|---|---|---|---|
| 先判满减门槛，再打折 | 200 ≥ 200，减 30 → 170 | 170 × 0.8 | 136.00 |
| 先打折，再判满减门槛 | 200 × 0.8 → 160.00 | 160 < 200，券不满足 | 160.00 |
| 先打折，再无条件减券 | 200 × 0.8 → 160.00 | 160 − 30 | 130.00 |
三个结果差了 30 元。重点看第二行：打折之后订单金额掉到 160，反而够不上 200 的门槛，券直接失效——这不是四舍五入的误差，是顺序变化带来的定性改变。这类差异，靠「把规则写清楚一点」是修不好的，只能靠代码把顺序钉死。
4.2 让模型只输出「规则名 + 参数」
模型要输出的不是136，而是「用哪条规则 + 这条规则需要哪些参数」。规则名从一个白名单里选（白名单 = 代码里允许出现的一组固定取值），代码只认白名单里的名字，认不出来就报错退出，绝不猜。
4.3 一个可复算的价格函数
⚠️代码待验证
fromdecimalimportDecimaldeffinal_price(list_price,discount_rate,coupon_threshold,coupon_amount,order):"""list_price 原价；discount_rate 折扣率（0.8 = 八折）； coupon_threshold / coupon_amount 为满减券的门槛与减额。 order 决定顺序，只允许 coupon_first 或 discount_first 两个取值。"""price=Decimal(str(list_price))iforder=="coupon_first":ifprice>=Decimal(str(coupon_threshold)):price=price-Decimal(str(coupon_amount))return(price*Decimal(str(discount_rate))).quantize(Decimal("0.01"))iforder!="discount_first":raiseValueError("order 不在白名单内")price=(price*Decimal(str(discount_rate))).quantize(Decimal("0.01"))ifprice>=Decimal(str(coupon_threshold)):price=price-Decimal(str(coupon_amount))returnprice用表4的数字代入order="coupon_first"得到 136.00，代入order="discount_first"得到 160.00，与手工算的一致。顺序参数必填、取值受白名单约束，这是把「规则不能被模型理解成别的样子」落到代码上的最小做法。
第 5 章 税额与关税：这是分段函数，不是乘法
5.1 官方规则里的分段与免征额
以中国寄递进境物品为例，官方规则不是「价格乘一个税率」这么简单，它至少有三层：分类、计税价格、免征额。国务院关税税则委员会公告 2024 年第 11 号公布的《进境物品关税、增值税、消费税征收办法》里，原文表述是「应纳税额按照计税价格乘以综合税率计算」，而综合税率要按《进境物品分类表》去查；计税价格则以实际购买价格为基础确定，必要时纳税人要提供真实交易价格的凭证。此外，对总值两千元人民币以内的寄递物品按简易征收办法合并征收，对应征税额在五十元人民币以内的寄递物品予以免税放行。
这几条合起来说明一件事：税额是分段函数，不是线性乘法。同一档税率内部是线性的，但跨过免征额就会跳变。
5.2 规则进表，不进提示词
假设某类物品综合税率为 20%、免征额为 50 元，看下面的跳变。
表5：同一档税率（20%）下，免征额造成的跳变
| 计税价格（元） | 应征税额（元） | 是否免征 | 实缴（元） |
|---|---|---|---|
| 200.00 | 40.00 | 是 | 0.00 |
| 250.00 | 50.00 | 是（不超过免征额） | 0.00 |
| 260.00 | 52.00 | 否 | 52.00 |
| 400.00 | 80.00 | 否 | 80.00 |
看第二、三行：计税价格只涨了 10 元，实缴税额从 0 跳到 52 元。如果让模型「按大概 20% 估一下」，它估不出这个跳变，因为它根本不知道门槛卡在哪里。海关总署官网的一份业务咨询答复里还有个更细的例子：同样是化妆品，按计税价格是否达到某个单价界限，会被归到不同类别，适用 50% 或 20% 两档综合税率。这类规则的共同点是：分档依据写在分类表里，不写在提示词里。
5.3 模型在这条链路里只剩一件事
⚠️代码待验证
fromdecimalimportDecimaldefimport_duty(taxable_value,rate,free_threshold):"""应纳税额 = 计税价格 x 综合税率。 rate 按《进境物品分类表》对应的分档传入； free_threshold 为免征额，不超过则免税放行。 两个参数都必须由规则表提供，不得由模型给出。"""duty=(Decimal(str(taxable_value))*Decimal(str(rate))).quantize(Decimal("0.01"))ifduty<=Decimal(str(free_threshold)):returnDecimal("0.00")returnduty模型在这里只需要做一件事：把商品描述归到分类表里的哪一类，也就是归类。归类错了，下游的规则表会查出不一样的结果，但至少这个错误是「可复核、可对账」的；而如果让模型直接报税额，你连它错在哪一步都看不出来。
这份《跨境电商算例规则表（Excel）》：把汇率取数列、体积重系数、满减顺序、税率分档这四类规则整理成一张可填写的表，正好对应本章讲的「规则进表」。放在资料包里，扫码即可获取：
第 6 章 工程上怎么「禁止模型自己算」
6.1 提示词里的禁止条令
光说「不要让模型算」没用，提示词里要写成可执行的约束。
⚠️代码待验证
你是跨境电商订单处理助手。你的任务只有三件事： 1. 从用户消息中抽取字段：币种、金额、实重、长宽高、目的国、订单原始金额。 2. 判断该走哪条规则：普通计价 / 含满减券 / 含体积重 / 含关税。 3. 用中文组织最终答复。 硬性约束： - 任何数值计算都必须调用工具完成，包括加减乘除、百分比、单位换算、汇率折算。 - 不要输出你心算的结果，即使数字很小、即使你很有把握。 - 缺少计算所需参数时先追问，不要用假设值补齐。 - 请求计算时，只输出结构化参数，不要附带结果。 输出格式： {"task": "calculate", "rule": "<规则名>", "params": { ... }}Anthropic 官方文档里还有一句很实用的话：如果你希望模型对处于边界情况的请求也去跑代码，就明确要求它，例如写成 “run code to verify this”。也就是说，「让不让它算」这件事，是可以由你在提示词里显式规定的，不是只能听天由命。
6.2 三道拦截
第一道是输入侧：抽取出来的字段必须做类型和范围校验，比如重量必须是正数、币种必须在三字母白名单里。第二道是计算侧：所有计算只走函数，函数内部不允许有「大概」「约等于」这类模糊处理，也不允许默认系数。第三道是输出侧：模型返回的规则名必须能在白名单里找到对应实现，找不到就整条链路判失败，而不是退化成让模型自己编一个答案。
三道里最关键的是第三道。它的意思很直白：宁可这次不回答，也不要给一个算出来的假答案。
6.3 留痕与对账
凡是走过工具的计算，中间参数都要落盘。这样月底对账时，能直接回答「这一单当时用的是哪一列汇率、哪个系数、哪一档税率」。
⚠️代码待验证
{"trace_id":"order_20261003_0007","model_extracted":{"currency":"usd","amount":1200,"destination_country":"us","package":{"length_cm":40,"width_cm":30,"height_cm":50,"gross_kg":8}},"tool_calls":[{"tool":"get_bank_rate","args":{"currency":"usd","rate_type":"spot_buy","trade_date":"2026-10-03"},"source":"bank_official_rate_page"},{"tool":"calc_chargeable_weight","args":{"divisor":5000},"result_kg":12.0}],"final_answer_basis":{"rule":"volumetric_greater_than_actual","chosen_kg":12.0}}这份记录里，rate_type和divisor是全文反复强调的两个东西：它们是规则，不是模型的判断。记录下来，规则就能被审计。
第 7 章 原来做跨境的，哪些经验能直接搬过来
7.1 你已经会的
做过跨境运营的人，手里有三样东西是纯技术背景的人没有的：第一，你知道哪些数字是「不能被四舍五入掉」的，因为你被对账差异追过；第二，你知道平台规则有多不讲道理——同一个概念在不同渠道有不同的定义，这正是前面体积重系数的翻版；第三，你习惯把一件模糊的客户诉求拆成可执行的字段，这恰好就是提示词里「抽取参数」那一步。
换句话说，你现在缺的不是业务理解，而是把业务理解写成函数和规则表的表达能力。
7.2 要补的三件事
第一件是「结构化输出」：让模型返回 JSON（一种键值成对的文本格式，机器可以直接读），而不是一段自然语言，因为只有结构化的东西才能被代码接住。第二件是「工具定义」：学会用一份 schema（字段说明）告诉模型有哪些工具、每个工具要哪些参数，本文第 2 章那份get_bank_rate就是最小样例。第三件是「可复算性测试」：给自己定一条规矩，凡是新上线的计算链路，同一输入跑三遍、结果必须一致，才算通过。
这三件事的难度都不在于算法，而在于愿不愿意把「大概」「差不多」从自己的表达里删掉。
7.3 一个可交付的最小项目
如果要从零做一个能拿出手的项目，建议就做「跨境订单计算助手」，范围压到最小：只处理一种币别、一种物流产品线、一条满减规则、一类商品税率。功能只有四步——对话里抽字段、按规则算、把中间参数落盘、用中文输出作答。规模小到你完全掌握得住，才能把「可复算性」这条判据真正跑通一遍。
项目的价值不在功能多，而在于它证明了一件事：你能把一个业务上不允许出错的环节，交出去之前先给它上锁。
这份《大模型应用转岗能力对照表》：把运营、外贸、多平台店铺这三类岗位的日常动作，逐条对应到工具调用、结构化输出、规则表这三项能力上，正好对应本章讲的「经验怎么搬」。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 事实 | 出处（文档名 + 发布方 + 链接） | 本文位置 |
|---|---|---|
| 「Claude runs code when the request benefits from computation or file handling: Non-trivial math (large numbers, many steps, precision-sensitive results)」（逐字引用） | Code execution tool，Anthropic 官方文档，https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool | 第 1 章 1.1 |
| 「Claude answers directly without running code for: Simple arithmetic and well-known math facts / Simple unit conversions or translations」（逐字引用） | 同上，Anthropic 官方文档 | 第 1 章 1.1 |
| 「If you want Claude to run code for a borderline request, ask explicitly (for example, “run code to verify this”)」（逐字引用） | 同上，Anthropic 官方文档 | 第 6 章 6.1 |
| 第四条第（五）项：「基于服务类型特点，采取有效措施，提升生成式人工智能服务的透明度，提高生成内容的准确性和可靠性。」（逐字引用；「提高生成内容准确性」的条款是第四条，不是派单初稿写的第七条） | 《生成式人工智能服务管理暂行办法》，国家互联网信息办公室等七部门令第 15 号，中国政府网国务院公报，https://www.gov.cn/gongbao/2023/issue_10666/202308/content_6900864.html | 第 1 章 1.1 |
| 第七条第（四）项：「采取有效措施提高训练数据质量，增强训练数据的真实性、准确性、客观性、多样性」（逐字引用；该条讲的是训练数据，不含「生成内容」字样） | 同上，中国政府网国务院公报 | 第 1 章（用于说明上述条号更正） |
| 「Unfortunately, most decimal fractions cannot be represented exactly as binary fractions.」（逐字引用） | Floating-Point Arithmetic: Issues and Limitations，Python 软件基金会官方文档，https://docs.python.org/3/tutorial/floatingpoint.html | 第 3 章 3.3 |
| 「since 0.1 is not exactly 1/10, summing three values of 0.1 may not yield exactly 0.3」（逐字引用） | 同上，Python 官方文档 | 第 3 章 3.3 |
| decimal 模块「suitable for accounting applications」（逐字引用） | 同上，Python 官方文档 | 第 3 章 3.3 |
| IEEE 754-2019 状态为 Active，出版日期 2019-07-22，页内摘要与本文所述浮点表示限制不冲突 | IEEE Standard for Floating-Point Arithmetic，IEEE Standards Association 官方标准页，https://standards.ieee.org/standard/754-2019.html | 第 3 章（仅作背景，不展开编号细节） |
| 中国银行官网牌价页美元一行五项数值：现汇买入价 669.87、现钞买入价 669.87、现汇卖出价 672.69、现钞卖出价 672.69、中行折算价 673.51，发布时间 2026/10/03 04:47:03（实时变动，此处为快照） | 中国银行外汇牌价页面，中国银行官网，https://www.boc.cn/sourcedb/whpj/ | 第 2 章 表2 |
| 「银行可基于市场需求和定价能力对客户自主挂牌人民币对各种货币汇价，现汇、现钞挂牌买卖价没有限制，根据市场供求自主定价」（逐字引用，第五条） | 《中国人民银行关于银行间外汇市场交易汇价和银行挂牌汇价管理有关事项的通知》，国家外汇管理局网站转载，http://m.safe.gov.cn/hubei/2014/0702/10.html | 第 2 章 2.1 |
| 待验证：现汇买入价／现钞买入价／现汇卖出价／现钞卖出价各自的官方逐条释义 | 只核到非官方转载（百科与财经媒体），中国银行官网牌价页只有列名与数值、无释义文字；未找到官方释义原文 | 第 2 章 2.1（已声明不使用其释义） |
| 「Shipping charges for DHL eCommerce packages are calculated based on the greater of dimensional and actual weight, referred to as Chargeable Weight.」（逐字引用）；英寸除 166、厘米除 6000 | Chargeable Weight，DHL 官方帮助中心，https://dhl.com/us-en/home/ecommerce/business-help-center/chargeable-weight.html | 第 3 章 3.1、表3 |
| 体积重 = 长(cm) × 宽(cm) × 高(cm) ÷ 5000；计费重取实际重量与体积重的较大者（本文按其示例转述） | Weight and Dimensions，DHL 官网说明页，https://www.dhl.com/discover/en-gb/ship-with-dhl/products-and-services/weight-and-dimensions | 第 3 章 表3 |
| 英寸口径除 139（原文：Inches/Pounds: Length x Width x Height / 139 per Piece） | DHL 官网门店页问答，https://locations.car.express.dhl.com/cayman-islands/george-town/71-eastern-avenue | 第 3 章 表3 |
| 「应纳税额按照计税价格乘以综合税率计算」；计税价格以实际购买价格为基础确定；总值两千元人民币以内的寄递物品按简易征收办法合并征收 | 《进境物品关税、增值税、消费税征收办法》，国务院关税税则委员会公告 2024 年第 11 号；计税价格确定原则见海关总署公告 2024 年第 175 号 | 第 5 章 5.1、5.3 |
| 应征税额在五十元人民币以内的寄递物品免税放行；化妆品按计税价格是否达到 10 元/毫升（克）分为两类，综合税率分别为 50% 与 20% | 海关总署官网「业务咨询」答复（非规章条文，属官方答复口径），http://www.customs.gov.cn/eportal/ui?pageId=374112&msgDataId=28581b4f886d4d319b33524bfb818e9a | 第 5 章 5.1、5.2 |
| 跨境电商的计费系数、免征额、税率分档均随平台、承运商与目的国变化；本文不给出通用数字，一律以对方官方规则页为准 | 综合上列各官方页面 | 第 3 章、第 5 章 |
附表 B：术语速查表
| 术语 | 一句话解释 | 本文哪里用到 |
|---|---|---|
| 大模型 | 能理解自然语言并生成文本的大规模语言模型 | 第 1 章 1.1 |
| 确定性计算 | 结果只由输入决定、不受随机性影响的计算 | 第 1 章 1.2 |
| 可复算性 | 同一输入跑两次，结果必须完全一致（本文唯一判据） | 第 1 章 1.2 |
| 容错性任务 | 做错了也只是体验变差、不会造成资金或合规后果的任务 | 第 1 章 1.3 |
| 外汇牌价 | 银行挂出来的外币买入、卖出报价 | 第 2 章 2.1 |
| 取数 | 按指定条件去官方数据源读一个值，而不是由模型推算 | 第 2 章 2.2 |
| 工具调用 / function calling | 让模型只提出「要调用哪个函数、参数是什么」，由你的代码真正执行 | 第 2 章 2.2 |
| schema | 一份字段说明，写清工具名、每个参数的类型与是否必填 | 第 2 章 2.2 |
| 白名单 | 代码里允许出现的一组固定取值，不在其中就拒绝 | 第 4 章 4.2 |
| 体积重 | 把包裹占的空间折算成的重量 | 第 3 章 3.1 |
| 计费重 | 最终用来算运费的重量，取实重与体积重中较大者 | 第 3 章 3.1 |
| 计费系数 | 体积重公式里「除以几」的那个数，随承运商与产品线变化 | 第 3 章 3.2 |
| 综合税率 | 寄递进境物品合并征收的关税、增值税、消费税合并税率 | 第 5 章 5.1 |
| 计税价格 | 计算税额所依据的价格，中国进境物品以实际购买价格为基础确定 | 第 5 章 5.1 |
| 免征额 | 应征税额不超过该数额时予以免税放行的门槛 | 第 5 章 5.1 |
| 分档 / 分段函数 | 按某个条件把取值范围切成若干段，每段用不同规则 | 第 5 章 5.2 |
| 结构化输出 | 让模型返回 JSON 这类机器可直接读取的字段化结果 | 第 7 章 7.2 |
| 留痕 | 把模型抽取的字段与工具调用的参数、结果都落盘，便于对账 | 第 6 章 6.3 |
写在最后：这篇用到的资料
写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。
