ArrivalReady：从 AI 预审到人工确认与整改复测

国际访客到来前，店铺的菜单、入口和支付说明是否已经准备好？我做 ArrivalReady，想让商户和场馆运营人员提前检查这些材料，发现问题后整改，再交一份新材料复测。目前做出的是一个可演示原型，还没有真实商户使用的验证记录。

项目速览	内容
阶段	2026 年 9 月的比赛技术切片，尚无真实商户验证
我的职责	决定产品方向、交付范围、关键规则和验收标准
AI 协作	全部代码由 AI 编程工具生成和修改，我没有手写代码
可核对成果	固定版本保留了证据上传、真实模型预审、人工确认、确定性评分及整改复测的本地验证记录

比赛版本先做到哪一步

最初的设想很大：从游客发现店铺、看懂服务，一直检查到支付和求助。但我还没有做商户访谈，这些需求是否值得解决，需要验证。

比赛有截止时间，我决定先做出一条能走完的流程：上传图片，查看 AI 预审及其引用的证据，人工确认后生成报告，再处理整改和复测。URL 自动抓取、PDF 解析和真实材料评测先放下。

AI 提出方案和实现建议，我决定哪些采用、哪些延期。协作日志里保留了这些确认：比赛交付按技术切片来说明，人审和评分采用哪套规则，来不及做的功能明确记为未完成。固定版本协作记录

报告刚生成有分数，重新读取就没了

比赛交付前，我要求 AI 做一次代码检查，再用浏览器走完整个流程，录下演示作为备用。协作日志记下了一个很具体的问题：报告确认完成后，分数出现了，却在大约两秒后消失。回到已经完成的检查，页面也看不到分数。

AI 定位到，生成报告时返回了评分，但再次读取这轮检查的接口没有带回已经保存的评分。页面刷新数据后，就失去了刚才显示的结果。这里需要补的是报告的读取链路，继续调整模型提示词帮不上忙。

修复覆盖了接口和页面：接口返回已冻结的评分，页面在检查完成后显示这份固定结果。验收也随之具体了：点击完成时看到分数还不够，重新打开报告仍然要能看到。9 月 8 日的协作记录保留了这次修复及完整流程检查的结果。

这段代码定位和修改由 AI 完成。我负责要求把流程实际走完，并确认产品应该留下什么结果。

材料不够时，不能把空白算成通过

看到 AI 的判断后，运营人员可以回到原图，查看它指向了哪里，再选择确认、修改、驳回或标记不适用。我保留了这四种操作，修改和不适用都要填写理由。

材料不够，就标为 UNKNOWN，表示还不能判断。这会降低检查覆盖率，没有检查到的内容也不会算作通过。等人确认完，程序再按固定规则算分，冻结这份报告。之后回头查，仍能找到分数对应的结论。

固定版本 ea00b32 演示视频的 00:01:28.5 画面。界面展示四种人审操作，输入为演示材料，尚无真实店主审核记录。

逐条确认会花时间。我还不知道运营人员要审多久、会改掉多少条 AI 结论。下一轮拿到真实材料后，要把这些都记下来，才能判断确认步骤有没有帮上忙。

整改入口是空的，前后对比也没有数据

同一轮检查还发现了两个会截断流程的问题。发现问题后，整改面板一直为空；做了复测，前后对比又没有显示真实结果。单看上传和 AI 预审，这些问题不会露出来。

前一个问题出在检查项的读取接口：它没有返回页面需要的整改任务。AI 补上任务信息，让还没有实际建立任务的检查项也能展示待处理入口。后一个问题更小——后端输出的是 Parent、Child，页面读取的是 parent、child。字段大小写没有对上，数据到了页面却用不起来。修复统一了字段名，并让对比结果按规则稳定排序。

整改之后，我希望能查清楚：上次发现了什么，这次补了什么材料，结果有没有变化。因此，提交新材料会开启一轮新检查，旧报告保留，前后结果按同一规则比较。没有复测结果，工作人员就不能直接把问题标为已解决。

这条限制也要落实到接口。修复后的规则要求，同一检查项在后续复测中得到人工确认的 PASS，整改任务才能转为已解决。直接跳过复测会被拒绝。协作记录中的浏览器检查走了两条路径：先尝试直接关闭，确认被拒绝；再完成复测和人工确认，检查任务可以关闭。相关失败路径也补进了集成测试。

同一固定版本演示视频的 00:01:52.2 画面，展示前后状态和复测入口。画面不证明真实商户已经完成整改。

录好了演示，讲解却还是一堆工程术语

能操作之后，还要让人听懂。第一版讲解里出现了“哈希指纹”“持久化”和内部评分缩写。我反馈，这些说法不适合面向评审的产品演示，要求换成普通人能理解的表达。

AI 随后重写了旁白和其中一页说明，用“给店铺做体检”解释产品，把重点放回店铺提交什么、哪里需要人确认、整改后怎么看变化。界面里的 UNKNOWN 保留，讲解时说明它表示材料不足、暂时不能判断。修改后重新生成音频和视频，并检查画面。

这次返工提醒我，演示稿也要验收。后台规则即使写得严密，听众不知道为什么要点下一步，几分钟的展示仍然讲不清产品。

这些修复验证到了哪一步

2026 年 9 月 7 日的交付声明保留了 PostgreSQL、MinIO、StepFun 和浏览器流程的本地验证记录，以及 Go、AI、Web、contracts 的离线 CI 结果。真实模型演示用的是自制英文菜单：有证据的检查项返回判断，材料缺失的项返回 UNKNOWN。

这次演示跑通了样例流程。换成真实商户材料，判断是否准确，还没有足够的评测结果。交付声明与未完成项

这些记录对应固定版本 ea00b32e19c74803f13484fc206f131b15fb605c，本次整理没有重跑模型、E2E 或 CI。该版本仍使用开发测试身份，URL 抓取、PDF 解析和完整评测集也没有完成。

下一步，找一家店试一次

下一轮，我会请一家店铺提供授权材料，从提交到审核记一次时间，看看人改了哪些结论。更关键的是，店主看完是否愿意整改，改完是否愿意再测一次。

如果店主觉得这些问题不值得处理，我就需要重新考虑做什么。原型已经能演示，真实需求和业务收益还要靠这类任务来验证。

ArrivalReady: From AI pre-check to human confirmation and retest

Before international visitors arrive, are a shop’s menu, entrance, and payment instructions ready? I built ArrivalReady to help merchants and venue operators check those materials in advance, fix problems, and submit a new set for retesting. What exists today is a demonstrable prototype, with no record of use by a real merchant.

Snapshot	Details
Stage	September 2026 competition slice; no real-merchant validation yet
My role	Product direction, delivery scope, key rules, and acceptance criteria
AI collaboration	All code was generated and modified by AI coding tools; I did not hand-write code
Checkable output	A fixed version preserves local validation records for evidence upload, a real-model pre-check, human confirmation, deterministic scoring, and remediation retesting

What the competition version had to do

The original idea was broad: check everything from discovering a shop and understanding its service to payment and getting help. I had not interviewed merchants, so whether all of those problems were worth solving still needed validation.

With a competition deadline, I narrowed the first slice to one complete flow: upload images, inspect the AI pre-check and its evidence references, confirm the findings as a person, generate a report, then handle remediation and retesting. Automatic URL fetching, PDF parsing, and evaluation on real materials were deferred.

AI suggested approaches and implementation changes. I decided what to accept and what to defer. The collaboration log records those choices: the competition delivery was described as a technical slice, the human-review and scoring rules were made explicit, and unfinished work was left marked as unfinished. Fixed-version collaboration record

The score appeared, then disappeared on reload

Before delivery, I asked AI to inspect the code and then walked through the complete flow in a browser, recording the demo as a backup. The log captured a specific failure: after a report was confirmed, the score appeared and then disappeared roughly two seconds later. Reopening the completed check also showed no score.

The cause was in the read path. Report generation returned a score, but the endpoint that read the check again did not return the saved score. Once the page refreshed its data, the result was gone. The missing piece was the report read chain; changing the model prompt would not have fixed it.

The fix covered both the endpoint and the page: the endpoint returns the frozen score, and the page displays that fixed result after confirmation. Acceptance became concrete too: the score must still be visible when the user finishes, and it must still be visible after reopening the report. The September 8 collaboration record preserves the fix and the full-flow check.

AI completed the code investigation and edits. I required the flow to be exercised and decided what result the product needed to retain.

Missing evidence cannot count as a pass

After seeing the AI’s finding, an operator can return to the original image, inspect the referenced area, and choose confirm, edit, reject, or not applicable. I kept all four actions; edits and not-applicable decisions require a reason.

When evidence is missing, the item becomes UNKNOWN: it cannot be judged yet. That lowers coverage, and an unchecked item cannot count as a pass. Once the person confirms each item, the program calculates the score using fixed rules and freezes the report. The score can still be traced back to the conclusions later.

A frame at 00:01:28.5 from the fixed-version ea00b32 demo video. It shows four human-review actions using demo materials; it is not a record of a real shop owner review.

Reviewing items one by one takes time. I do not yet know how long an operator would need or how many AI findings they would change. With real merchant materials, the next round needs to record both before deciding whether the confirmation step helps.

The remediation panel was empty, and the comparison had no data

The same flow exposed two more interruptions. After a problem was found, the remediation panel stayed empty. After a retest, the before-and-after comparison showed no real result. Neither issue would have appeared if I had only checked upload and AI pre-check.

The first problem was in the check-item read endpoint: it did not return the remediation tasks needed by the page. AI added the task information so items without an existing task could still show a pending remediation entry. The second was smaller but just as concrete: the backend returned Parent and Child, while the page read parent and child. The data arrived but could not be used. The fix aligned the field names and made comparison results sort deterministically.

After remediation, I want to answer a precise question: what was found last time, what material changed this time, and did the result change? Submitting new material starts a new check, keeps the old report, and compares both results under the same rules. Without a retest result, a worker cannot simply mark an issue resolved.

That limit also belongs in the endpoint. The fixed rule requires the same check item to receive a human-confirmed PASS in a later retest before its remediation task can be closed. Skipping the retest is rejected. The browser checks followed both paths: first trying to close directly and seeing it rejected, then completing a retest and human confirmation so the task could close. The failed path was added to integration tests as well.

A frame at 00:01:52.2 from the same fixed-version demo video, showing the before-and-after state and retest entry. It does not prove that a real merchant completed remediation.

The demo was recorded, but the explanation was still too technical

Once the flow worked, it still had to be understandable. The first explanation used terms such as “hash fingerprint,” “persistence,” and internal scoring abbreviations. I said those terms did not fit a product demo for reviewers and asked for ordinary language.

AI rewrote the narration and one explanation page, describing the product as a “health check for a shop” and returning the focus to what a shop submits, where a person must confirm, and how changes appear after remediation. UNKNOWN stayed in the interface, with the explanation that it means there is not enough material to judge yet. The audio and video were regenerated and checked again.

That rework was a reminder that the demo needs acceptance too. Backend rules can be precise while a few minutes of narration still fail to explain why someone should take the next step.

What this validation does and does not cover

The September 7 delivery statement preserves local validation records for PostgreSQL, MinIO, StepFun, and the browser flow, as well as offline CI results for Go, AI, Web, and contracts. The real-model demo used a self-made English menu: items with evidence received a finding, while items without enough material returned UNKNOWN.

The sample flow ran through successfully. There is not enough evaluation evidence to say whether the findings are accurate on real merchant materials. Delivery statement and unfinished work

These records correspond to the fixed version ea00b32e19c74803f13484fc206f131b15fb605c. This edit did not rerun the model, E2E checks, or CI. That version still uses development test identities; URL fetching, PDF parsing, and a complete evaluation set are unfinished.

Next: try it with one shop

Next I want one shop to provide authorized materials. I would record the time from submission to review, which findings the person changed, and whether the owner would choose to remediate and retest.

If the owner does not find the problems worth addressing, I need to reconsider what the product should do. The prototype can be demonstrated; real need and business value still need this kind of task-based evidence.