技能介绍

问题：金融代码里的精度错误很少在测试环境暴露

当你把 100.50 经 JSON 解析成二进制浮点，显示可能还是 100.5，但累加、分拆、换算后就开始漂移。Alpaca 的交易与资金路径对这种偏差没有耐心：一次 float 参与的资金流转，可能导致多转出几美分、审计对不上、或下单时被 API 拒绝。真正麻烦的是，有些字段看起来像数字，却承担着不同职责。

这个技能如何工作

它没有抽象的“金额规范”，而是给出几条可执行的约束：

Money 字段保持字符串进出，解析为 decimal。无论 Python、TypeScript、Go 还是 Java，进入资金路径的值必须是十进制类型；序列化回去时再转成字符串，别让 IEEE-754 浮点参与。
发送前显式舍入或截断，并选好舍入方向。现金金额通常保留两位小数，小数股份额与名义金额最多九位。转出或收费金额应向下截断（round down），避免多移动一分。
中间计算也要重新取整。当你用 amount * percentage 分拆资金时，每步都可能导致精度回归；只在最终输出时修正是不够的。
小数股不要自己反算。给 Alpaca 传 notional，让它算成交数量；如果你从自己取回的价格反推 qty，漂移就会进入订单。

存储与边界

数据库里应该用定点小数，例如 DECIMAL(20, 8)，留出比 Alpaca 现金精度更多的余量。同时把 Alpaca 返回的原始字符串按原样存一份，这样你向 API 发送时截断了精度，审计时仍能对照原始值。

注意点：并非所有 Alpaca 端点都一致，行情数据的 OHLC 等字段可能是 JSON 数字，用于展示或分析时用浮点通常可以接受；但任何你实际移动、存储或用于决策的钱，都不允许走二进制浮点路径。涉及多币种的 funding wallet 尤其如此，它会携带汇率费用，不能假设所有金额都是 USD。

最后，这个技能不是全栈金融库，而是一张精度红线图。它假设你已经理解 Broker 的交易、转账与对账边界，并在这些流程里保持字符串、十进制、显式舍入和币种跟踪。