如何阻止AI代理编造尼日利亚邮编
内容提要
自2026年10月1日起，尼日利亚邮编从六位数字改为11位字符码。旧模型仍会自信输出旧格式，影响编写验证代码的编码代理及运行时读取邮编的代理。文章主张模型只负责提取字符串，由确定性代码校验格式、经NIPOST确认是否分配、按前缀路由，并给出失败状态表与工具权限限制。
延伸解读
为什么旧模型会自信输出错误邮编
文章指出，2026年10月1日前训练的模型仍会以六位数字格式描述尼日利亚邮编，因为新格式在训练数据中几乎不存在。实测中，即使允许联网搜索并告知当前日期，四个语言的编码代理仍凭记忆写出六位正则，且未搜索。这并非模型故意出错，而是其训练数据主导了输出。因此，不能依赖模型的置信度，而应通过外部规则或确定性代码来纠正。
编码代理与运行时代理的纠正策略
对于编码代理，文章建议在项目规则文件（如AGENTS.md）中明确写入新邮编格式和推荐库，实测可改变其输出。对于运行时代理，则需建立边界：模型仅负责从文本中提取字符串，后续的格式校验、NIPOST分配确认和前缀路由均由确定性代码完成。这种分工确保即使模型输出错误，系统也能通过解析器、API查询和路由表做出可靠决策。
失败状态处理与权限控制
文章详细列出了从旧格式、段位越界到API不可达等失败状态，并强调前三种检查在离线完成，不消耗网络。对于可能产生费用的操作，如二级查询，服务器默认不注册相关工具，需通过环境变量显式开启，且付费调用有次数上限。这种设计将权限控制放在配置中，避免模型通过提示绕过限制，同时确保纠正建议需经用户确认后才继续。
该方案的局限与注意事项
文章明确指出，即使邮编格式正确且已分配，仍可能是错误建筑（如用户提供了邻居的邮编），需通过展示解析地址等额外控制来确认。纯文本地址往往无法精确定位建筑，可能需要位置图钉。此外，二级查询返回的房屋地址属于个人数据，应遵守尼日利亚数据保护法，除非必要，否则保持一级查询。这些限制提醒读者，该方案解决的是格式和分配验证，而非身份或所有权验证。
Q&A
尼日利亚邮编从什么时候开始从六位数字改为11位字符码？
自2026年10月1日起，尼日利亚邮编从六位数字改为11位字符码，例如EK-01-A03-FK-01。
为什么AI代理会编造尼日利亚邮编？
因为语言模型在2026年10月1日之前训练，训练数据中几乎没有新格式，所以模型会自信地输出旧的六位数字格式。
如何防止编码代理写出错误的尼日利亚邮编验证代码？
在项目的AGENTS.md、CLAUDE.md或编辑器规则中明确说明新格式，并推荐使用ng-postcode等库，而不是让模型自己写正则表达式。
在运行时，如何确保AI代理提取的尼日利亚邮编是有效的？
建立边界：模型只负责提取字符串，然后由确定性代码进行格式校验、通过NIPOST确认是否分配，并根据前缀路由。
ng-postcode-mcp服务器默认提供哪些工具？
默认提供五个只读工具：validate_postcode、lookup_postcode、autocomplete_postcode、find_postcode_at_location、resolve_address。
如何处理AI代理产生的错误邮编？
根据失败状态表，解析器会拒绝格式错误的邮编，NIPOST会确认是否分配，对于疑似拼写错误会建议更正但需用户确认，所有失败状态都有对应的返回消息。
