# 客户字段改错了，怎样定位错误发生在哪一步？ | EasyNet

Source: https://easynet.run/cases/problems/trace-wrong-customer-update

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 客户字段改错了，怎样定位错误发生在哪一步？

客服让助手更新客户的收货地址，客户档案里的开票地址却被覆盖了。此时最急的不是再问模型一次，而是确认：它读错了原文、映射错了字段，还是另一名同事在同时修改？

CRM 已有字段历史和操作日志时，先在那里查看前后值。单系统内能查清的事故，不需要另造一套追踪工具。问题跨越多个助手和服务时，才需要把它们的操作关联回同一条业务修改。

可以把“提出修改”和“确认写入”分成两步。前一步返回客户编号、目标字段和差异供人确认；后一步接收批准过的变更及预期记录版本。EasyNet 连接这两个受限操作，不向助手开放任意字段更新。

写入服务核验调用者是否有权修改这个客户，再检查记录版本是否仍然一致。模型传来的字段名不能绕过允许清单；发生并发修改时应停下来重新核对，而不是用旧值覆盖新结果。

排错记录只需保留业务变更编号、获准字段差异和相关调用，不必把整份客户资料复制进日志。还要由 CRM 接入方补上版本检查和纠错审批；一次接口成功返回，并不能说明地址本身就正确。

在测试客户上分别制造字段映射错误和并发修改，检查两种情况是否能被区分。需要纠正时，由负责人确认恢复哪些字段，并保留纠正记录，避免自动回滚又覆盖其他人的有效更新。

01

提议改收货地址

展示目标字段与前后值

02

比较记录版本

并发修改则停止

03

批准后纠正

只恢复确认的错误字段

先审字段差异，再校验版本写入。

拒绝旧版本写入

纯内存示例，不操作CRM；实际版本检查与写入必须在业务存储中原子完成。
本地示例 · python

```
record = {"version": 8, "shipping_address": "new valid address"}
approved_change = {"expected_version": 7, "shipping_address": "stale proposal"}
if approved_change["expected_version"] != record["version"]:
    print("version-conflict")
else:
    record["shipping_address"] = approved_change["shipping_address"]
assert record["shipping_address"] == "new valid address"
```

预期结果：输出version-conflict，保留版本8的有效地址。

接入时的检查项

旧记录版本不匹配时不会继续覆盖，错误能够指向版本冲突。

诊断可以指出错误在读取、映射或写入哪个阶段，未知项保持未知。

调试材料不包含完整客户档案，恢复操作仍要求适当授权。

源码与接入资料

[让 Agent 调用业务操作，而不是拿到后台凭证](https://easynet.run/cases/enterprise-tool-boundary)

[函数接入指南](https://easynet.run/docs/connect/function)