## 实地商户核验：公开招募说明了什么，三种技术检查又证明不了什么
这是本系列研究页的第二篇——按独立开发者动手写代码前真正会做的方式：先看真实已发布的需求，再真实测试要完成这项工作所需要的技术手段，如实报告结果，包括那些行不通的部分。
### 1. 谁有这个问题，他们实际在要求什么？
在目录里搜索"实地核验、site verifier、business verification"这类需求，找到了由 **65 条真实、带发布预算的自由职业任务**（Freelancer.com，公开发帖，已脱敏；这是截至 2026-09-10 冻结的快照——对应特性下的任务数后来又涨到了69条，但本文引用的数字固定指这已归档的65条）构成的三个已发布特性——全部可追溯到同一个真实的、有名有姓的发布方：**Confirmis**，一家新加坡的企业信息与贸易情报服务商。在我们找到的发帖记录里，从 2026 年 7 月 10 日到 9 月 10 日，Confirmis 持续发布新的"需要实地核验员"任务——超过两个月的重复需求，不是一次性的波峰。代表性来源发帖：[Site Verifier Needed in Paris - France](https://www.freelancer.com/projects/photography/Site-Verifier-Needed-Paris-France)、[Site Verification in Dammam, Saudi Arabia](https://www.freelancer.com/projects/photography/Site-Verification-Dammam-Saudi-Arabia-40573670)、[Site Verifier Needed in Bengaluru, Karnataka, India](https://www.freelancer.com/projects/photography/Site-Verifier-Needed-Bengaluru-Karnataka)。
模式在每一条发帖里都高度一致：雇一名当地自由职业者前往指定商户地址，拍照确认该商户真实存在并正常营业，提交一份简短报告。预算大多在每单 10-95 美元（少数达到 140-150 美元，另有两条以卢比计价，折合约 150-450 美元）。城市分布覆盖了同一个时间窗口内几十个国家、几乎每个有人居住的大洲：敖德萨、科伦坡、塔科拉迪、伊斯坦布尔、哈尔吉、班加罗尔、蒙得维的亚、利沃夫、贝尔格莱德、亚的斯亚贝巴、索尔诺克、汉堡、温州、萨那、卡拉奇、雪兰莪、巴格达、普吉岛、墨尔本、马尼拉、科莫蒂尼、吉隆坡、比尔根杰、利比亚、维罗纳、巴黎、博卡拉顿、迈阿密、越南多个省份、首尔、科威特城、金奈……不胜枚举。
**一处对本研究初稿的重要修正：[Confirmis 自己的官网](https://www.confirmis.com/)明确写着，他们拥有"超过 6,000 名遍布全球的受训实地核验员"。** 这是 Confirmis 自己披露的数字，不是我们独立核实过的实际规模，官网也没有说明这个网络是怎么招募、培训、调度的——所以这没法告诉我们他们内部的调度系统到底是好是坏、甚至是不是根本不存在。但这直接推翻了本文初稿的一个说法：初稿把这些自由职业发帖读成了"Confirmis 没有常设核验员网络"、"纯手工"运营的证据。那个说法是错的，至少是没有依据的——一家公司完全可以既有一个规模不小的、有名有姓的网络，又出于我们不知道的原因（覆盖缺口？紧急程度？成本？）额外通过一次性自由职业发帖来补充特定城市的需求。发帖内容实际能说明的是**持续通过公开自由职业市场采购实地核验的人力或产能**——不能说明其他系统不存在。
### 2. 这些需求本质上是同一个需求吗？
把三个特性合并来看，这在全球范围内是同一个底层任务：把一个实地核验请求派给一个可信的当地人，拿回能证明商户确实存在且在正常营业的照片证据，并且有把握这些照片没有被伪造或挪用。发帖内容里能看到的真正变量只是司法辖区（登记信息质量不同）和紧急程度（部分发帖标注了当周加急）。
发帖内容**说明不了**、而一个对这个机会的真实评估需要知道的是：Confirmis 现有的 6,000+ 核验员网络实际是怎么组织的（自助App？电话名单？区域协调员？）、如果这个网络已经覆盖了这些城市为什么还要在公开市场发帖、他们内部的接单率和周转时间是什么样、以及他们通过自己的渠道给每单支付的费用相比这里看到的公开市场价格是高是低。这些都没法只靠自由职业发帖回答。
### 3. 为什么现有工具还不够用？
我们没有假设"查一下 GPS 就完事了"（这种泛泛的说法），而是搭建并运行了三项真实的技术检查，用真实输入实测。其中一项——图像篡改检测——实际做的实验范围，比本文初稿描述的要窄得多，这个修正比下面任何一个具体数字都更重要。
**地理编码（OpenStreetMap Nominatim，免费公开 API）**：用新加坡、美国、德国、日本、英国的 5 个真实地址实测。5 个里 4 个成功；英国地址（`Unit 4B, 100 Commercial Road...`）按原样提交返回了空结果。这是一次单一的观察，不能当作 Nominatim 处理单元/套间号的一般性结论——我们测试的地址数量不足以说明这种情况出现的频率。同样，新加坡地址只解析到道路级而不是具体建筑，这也是一次单一观察，不能当作"系统性几百米误差"这类一般性证据。
**EXIF GPS 交叉核验**：构造了测试用例——一张真实相机拍摄、带 GPS 元数据的照片（来自公开的 [ianare/exif-samples](https://github.com/ianare/exif-samples) 测试样本仓库，不是真实的商户核验照片）、两张手动标注匹配真实目标坐标的合成照片、一张故意标错位置的照片（声称是新加坡，实际标注的是吉隆坡坐标）、以及一张完全剥离了 GPS 信息的照片。交叉核验的判断逻辑正确标记出了错标照片（偏差 316.7 公里，明确无法通过），也正确地把无元数据照片报告为"无法核验"而不是悄悄放行。**我们没有测量真实场景下有多大比例的照片上传会保留可用的 GPS EXIF**——本文初稿里那些具体的留存比例和各平台剥离数字，不是这次实验产出的，已经删除。我们能如实说的只有：任何已经被剥离了 GPS 元数据的照片（不管是因为经聊天软件转发、被重新保存、还是被编辑过），单靠这一项检查都无法核验，仅此而已。
**追加测试：伪造这些标签到底有多容易？** 用免费的命令行工具 `exiftool`（一条命令：`exiftool -GPSLatitude=1.2849361 -GPSLatitudeRef=N -GPSLongitude=103.8504269 -GPSLongitudeRef=E photo.jpg`），把一个真实目标的精确坐标写进一张事先完全没有GPS数据的普通合成图片。这条命令耗时0.48秒。用同一套距离核验逻辑跑一遍结果：距离目标0.00米，判定为VERIFIED_LOCATION（已核验）。**EXIF交叉核验根本分不清"真的在这个地点拍的照片"和"随便一张图、事后填对了坐标数字"这两种情况**——这在本文初稿里只是一个"已知存在但未测试"的攻击手段，现在已经实测确认。
**图像篡改检测（Error Level Analysis）——对这个实验实际是什么的修正说明**：我们从零实现了 ELA（JPEG 重压缩差异可视化），对五张图片跑了这个流程，其中两张是我们自己故意编辑过的（画上假招牌文字、用色块覆盖部分画面）。**重要说明：脚本是在我们自己编辑过的那个已知像素区域内计算压缩差异统计——它没有独立检测或定位任何篡改。** 这里没有定位步骤，没有阈值，也没有通过/不通过的分类器；"哪个区域可疑"是脚本的输入，不是输出。所以这次实验没法支持"ELA 成功识别出了篡改"这类说法，也没法支持一个误报"率"——因为从来没有发生过任何分类判断。我们能诚实报告的是：在我们的样本里，已知编辑区域内的压缩差异特征，跟周围背景相比有可测量的差异；而一张干净、未经编辑的高对比度图形（矢量风格招牌转成 JPEG）单纯因为正常压缩伪影，产生了量级相当的差异特征——这是一个真实的理由，让人不该信任一个简单粗暴的"差异大=篡改"阈值，尽管我们自己从未搭建或测试过这样一个阈值。完整数据和确切方法已随本文归档。
**关于三项技术检查的诚实结论**：地理编码需要先做地址清洗，在低于建筑级精度的结果上不能直接采信；EXIF 交叉核验只有在元数据留存时才是真实有用的信号，而我们不知道现实中这种情况有多常见；我们做的 ELA 工作，经过修正后，是在已知区域上做压缩伪影可视化——或许能作为人工复核的辅助，但不是一个经过测试的篡改检测器，更不能诚实地给它安一个"检出率"。
### 4. 一套软件真正需要做到什么？
基于第 3 节修正后的发现，下面每一条都是**未经测试的设计假设，不是已验证的建议**：
- **地址标准化层**（如 `libpostal` 这类库，或专门写的正则规则集），记录里保留完整原始地址——包括单元/套间/楼层号——同时为地理编码器另外生成一个清洗过的查询字符串，并对免费 API 的失败和低精度情况，回退到商业地理编码服务（Google Places、Mapbox、HERE）。 - **端内即时拍照，而不是相册上传**：在拍摄瞬间直接从相机/浏览器 API 获取位置，而不是事后信任已拍摄照片的 EXIF。这在理论上是一种可能（不是一定能）降低"上传一张旧照片或无关照片"这种失败模式的办法，但我们没有针对任何对抗性输入搭建或测试过它——我们不知道这是否真的能阻止一个有意造假的核验员，只知道它去掉了一个具体的薄弱点（EXIF 本来就不该被完全信任）。 - **按单动态生成的实体挑战**（例如"拍照时手持一张写有验证码 CF-8492 的卡片，与店铺招牌同框"）——这是一个纸面上看起来能对抗简单照片复用和翻拍攻击的设计想法。我们同样没有搭建或测试过它。一个真实实现在对其效果下任何结论之前，需要考虑的未测试攻击手段包括：拿一张该地点的旧照片配合一张打印或数字合成的验证码卡片（这比单纯伪造GPS坐标更难——需要验证码文字真的出现在照片画面里，不只是改一个元数据字段，但本文没有实测这一项）、真实到访但配合一个摆拍的道具、以及普通的用户操作失误（验证码错误、卡片模糊、拒绝配合、补拍带来的成本和对任务时限的影响）。有一项相邻的攻击手段现在从"假设"变成了"实测确认"：见第3节的EXIF伪造测试——那一条命令的执行本身不到半秒就能做到（不是说攻破整套核验流程的总耗时也是这个数），这正是这里的验证码设计要依赖"照片画面里真实可见的内容"、而不是单靠一个元数据字段的原因。虚拟定位软件和翻拍攻击本次研究仍未测试；确认一种针对单项被动检查的低成本攻击，不等于对上面这个设计做了完整的对抗测试。 - **真正独立的篡改检测步骤**，如果确实需要图像取证的话——意味着一个真正的定位/分类模型或算法，在它事先不知道答案的样本上做评估，而不是我们这次跑的这种"已知区域可视化"。 - **默认把任何模糊情况交给人工复核**，因为上面三项检查都没有被验证为可以自动通过/拒绝的信号。
以上都不应被读作"答案"——这是本次研究暴露出来的一系列未经测试的工程问题，不是一套已经证明可行的设计。
### 5. 哪些是事实、哪些是推断、哪些还没有验证
| 条目 | 状态 | |---|---| | Confirmis 在公开自由职业市场持续按城市发布核验任务（典型预算 10-95 美元，几十个国家，持续两个多月） | **事实**——直接观察自 65 条有来源的发帖 | | Confirmis 运营着一个超过 6,000 名受训核验员的网络 | **事实，公司自述**——来自 Confirmis 官网；具体规模和实际调度机制未经独立核实 | | Confirmis 完全依赖临时自由职业招募，没有常设网络 | **不成立**——被 Confirmis 官网自己的说法推翻；本文初稿曾错误地做出这一断言 | | Confirmis 为什么在已有网络的情况下仍在公开市场发帖（覆盖缺口？紧急程度？成本？） | **未验证**——需要直接和 Confirmis 或类似公司对话才能知道 | | Confirmis 通过自己网络的内部接单率、周转时间和单次成本 | **未验证**——无法从公开发帖推导出来 | | 一个派单平台相比 Confirmis 目前的做法能显著降低成本或缩短周转时间 | **未验证的假设**——单纯从发帖内容读出的"运营拖累"不足以作为证据 | | 本文实测的地理编码、EXIF 交叉核验、ELA 能可靠拦截造假提交 | **本次研究不支持这个结论**——见第3节；ELA 尤其不是一次检测实验 | | 端内即时拍照+按单验证码，比三项被动检查更有效 | **未经测试的设计假设**——没有做过对照实验 | | EXIF GPS标签可以被廉价、快速地伪造成任意目标位置 | **事实，已实测**——免费命令行工具（`exiftool`）在0.48秒内把精确目标坐标写进一张事先没有GPS数据的图片；第3节里用来正确识别出真实错标案例的同一套距离核验逻辑，判定这张伪造图片为已核验 | | 现实场景下未加约束的照片上传，GPS EXIF 的真实留存比例 | **未测试**——没有任何实验测量过这个数字 |
一个试点还需要独立于任何技术设计、提前定好：照片和位置数据的保留期限、核验员提交被拒后如何处理、对被实时采集位置的自由职业者的知情同意与告知义务、以及核验员实地前往陌生地址执行任务的基本安全考量——这些本次研究都没有涉及。
### 6. 那么——值得做吗？
**需求信号是真实的，而且被异常完整地记录了下来——一个具体的、有名有姓的、目前仍在运营的买家，跨几十个国家持续发帖超过两个月。但软件机会本身未经验证，不是已经证实可行，本次研究更站得住脚的解读，比初稿的说法要窄：** 公开市场上确实存在一项真实的、反复发生的实地核验劳务采购，单从发帖内容本身，并不能明显看出一家自称拥有 6,000+ 核验员网络的公司为什么还要通过 Freelancer.com 采购——这个缺口，恰恰是在做任何开发决策之前，需要和 Confirmis（或一家类似的贸易情报公司）真实对话才能回答的问题。技术层面，本文实测的三项检查——按它们实际测量的内容做修正之后——目前都不支持"防伪"这个产品定位；它们是进一步、更严谨的工程和测试的起点，不是一个能用的检测器。正确的下一步是上面事实表里列出的那场对话，不是继续往下开发。
*证据来源：3 个已发布的需求信号页面，基于 65 条真实、带发布预算、已脱敏的 Freelancer.com 任务（按特性链接如上），全部可追溯到 Confirmis（confirmis.com），于 2026-07-10 至 2026-09-10 期间发布。技术验证：OpenStreetMap Nominatim 地理编码 API，Pillow 10.2.0 / exifread 3.0.0 / piexif 1.1.3 用于 EXIF 提取与合成，一个从零实现的、基于 Pillow 的 JPEG 重压缩差异可视化（不是独立的篡改检测器——见第3节），于 2026-09-10 针对 5 个真实地址和若干图像测试用例实测；2026-09-15 追加了基于 `exiftool`（libimage-exiftool-perl 12.76）的EXIF伪造测试；完整脚本、原始 JSON 结果与冻结的65条任务来源清单已归档至 docs/low-value-2026-09-05/verifier-research-scripts/（含说明复现步骤的README与 task-snapshot-65.md）。这篇文章经过了多轮内部事实/方法论审核，加上网站负责人本人的直接人工核实——核实过程中发现并修复了第1节的商业前提错误、原图像篡改检测方法论描述的错误，以及上面这处EXIF伪造测试的缺口——但尚未经过独立的外部开发者试读。请把这篇文章当作"已经过事实核查、有证据支撑"看待，而不是"已经过目标读者验证"。*