先定位变化发生在哪一层
长编号最后几位变动，不一定是Claude看错了原文。先对照原始材料、原始响应文本和程序解析后的值；如果响应还正确，JSON.parse后才变化，应先检查数字精度。
编号用于识别记录，通常不需要加减乘除。将它定义为字符串，可以保留长位数和前导零；这不意味着所有金额与数量也都应该改成字符串。
一个可以复现的18位编号
虚构原值为123456789012345678。若JSON写成数字，JavaScript解析成Number时无法保证该整数的所有末位；本例本地解析后String显示123456789012345680。若JSON写成带双引号的字符串，原值完整保留。
JavaScript安全整数上限为2的53次方减1，即9007199254740991。RFC 8259也说明常见双精度实现的整数互操作范围；JSON语法允许一个数字，不代表下游语言能无损保存任意长度整数。
从源头约束，再在应用验收
给Claude的提取要求应明确：id按原文逐字符输出为字符串，不补位、不改写；看不清就标待核对。如果使用结构化输出，Schema里的id应为string，基本形状仍不能替代逐字符事实核对。
文末parseRecord只接受18位ASCII数字字符串，并拒绝数字类型。真实业务的编号长度、字母或校验位应按实际规范调整，不把示例18位推广为身份证、银行卡或任何通用证件规则。
运行后观察四个字段
完整代码存为long-id-string.mjs，用Node.js 24 LTS运行：node long-id-string.mjs --demo。raw与stringAfterParse应一致，numberAfterParse会出现上述末位变化，safe为false。
这是离线构造JSON解析演示，没有向Claude提交编号，也没有使用真实身份信息。若你的环境输出不同，应先检查语言数值类型与解析库，不直接套用JavaScript结论。
已经变成数字，还能不能补救
对已经丢精度的Number再执行String，只会把错误值变成字符串。必须回到原始可信材料或尚未数值化的原始响应重新读取；不知道原值时应标记待核对，不能猜最后几位。
不要用普通全局替换给任意JSON数字补引号，可能改坏金额、科学计数法或字符串内部内容。若接口必须传大整数，应选择明确支持该约定的解析与传输方案，并对发送和接收两端一起验收。
把导出和表格也纳入检查
数据库字段、CSV导入、电子表格自动类型识别，都可能在后续环节再次数值化。验收不止看页面显示，还要从导出文件回读并逐字符比较，保存原始来源标识与版本。
本地测试验证了字符串保留、数字类型拒绝、长度和末尾换行拒绝；未执行真实数据库迁移或表格导入。上线修复应先用副本抽检，不覆盖未知原值。
参考资料与核验范围
资料核对日期：2026年10月20日。以下为官方原始资料；产品入口和可用范围仍以当前账户为准。
1. [官方资料1](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)
2. [官方资料2](https://www.rfc-editor.org/rfc/rfc8259)