A商业发票
4,800件 40 箱Andrew Xia · AI 系统与自动化
让 AI 有用，让依据可见。
我做单证审核、编码 agent 验证和生态模拟，负责从流程设计到验收的独立项目。生产 IT 实践，让我重视权限、变更与故障恢复。
AI 提取数值，数量规则发现冲突。系统标记 REVIEW，人再确认该改哪份单证。
精选项目
不同的问题，看得见的判断。
单证审核、编码 agent 验证工具，还有一款生态模拟。它们探索不同的问题，也让复杂系统更容易被理解。
01 / VERDICT · 单证 AI · 原型
在交接之前，找出单证里的矛盾
独立原型 · 持续开发中
- 01问题
- 关键货运信息散在多份单证里。复核者必须找出这些单证彼此矛盾的地方。
- 02我做了什么
- 我设计审核流程，也划清决策边界：模型提取字段，成文规则标出冲突，人可以沿着每条发现，查回对应单证和数值。
- 03证据
- 合成案例说明复核流程，并标识示例规则集。另外，2026-06 的抽取评测在 85 份合成文档样例重建的干净英文文本上逐字段比对。
57项已记录检查，跨两个工作流
85份合成文档文本样例已评测
96.3%字段一致率 · 2026-06 · 归一化/数值容差
Verdict —— 看看一次货运审核
查看合成案例、检查来源字段，或者重放示意步骤。模型提取的内容交给成文规则检查，再由人复核系统标出的发现。
合成案例 · 原型流程示意
发票与装箱单不一致999-55667788 · PVG → SYD · 40 pcs · 612.5 kg · Ceramic tableware · CIF
中文为展示层译文；单证值、规则标识与英文原文保留，不代表模型输出中文。
- 接收单据
- 识别单据类型
- 提取字段
- 规则校验
- 系统状态
- 跟进草稿
查看处理轨迹（技术细节）
轨迹中的规则评分是示例数值，不是风险概率；快照标识不证明这里的说明文字是引擎原样输出。
Invoice vs packing list disagree
2 discrepancies need human confirmation; 1 synthetic configuration check is recorded.
- 01▸ {"upload":{"received":3,"expected":3}}
- 02▸ {"classify":{"air_waybill":{"method":"heuristic","conf":0.96},"commercial_invoice":{"method":"heuristic","conf":0.95},"packing_list":{"method":"heuristic","conf":0.93}}}
- 03▸ {"extract":{"fields":10,"low_confidence":0}}
- 04▸ {"validate":{"rules_fired":3,"warning":2,"info":1}}
- 05▸ {"example_result":{"status":"REVIEW","illustrative_rule_score":54}}
- 06▸ {"draft":{"subject":"Synthetic AWB 999-55667788 — two discrepancies to confirm"}}
合成样例：跨单证字段比较
- 商业发票 · 箱数40 cartons · 4,800 pcs
- 装箱单 · 箱数38 cartons · 4,560 pcs
英文说明原文
Quantity mismatch: invoice declares 40 cartons / 4,800 pcs; packing list shows 38 cartons / 4,560 pcs.
Synthetic fixture: compare document fields
规则 BG-XDOC-007 · 快照 c6f89cf4…
模型 deepseek-v4-flash，温度 0 · prompt precheck-extract-v3.0 · 已记录 1 次运行
查看评测报告
已记录的抽取评测 · 2026-06
量于 2026-06 · 语料 v1
| 语料 | 85 份合成文档文本样例 · 511 个标注字段 · 17 组文档集 |
| 字段一致率（归一化与数值容差） | 96.3% |
| 宽松一致率（额外允许字符串子串包含） | 99.0% |
| 抽取失败 | 0 · 真实漏抽:2 —— 两者都由测试架复现,并逐字段人工复核 |
| 方法 | 逐字段比对，对字符串、日期和标识符做归一化，并允许数值容差；宽松匹配额外允许字符串子串包含。不匹配项会打印出来供人工复核。 |
| 运行条件 | deepseek-v4-flash · 温度 0 · prompt precheck-extract-v3.0 · 1 次运行 |
这些数字覆盖的是从人工撰写的合成文档基准真值重建的干净英文文本。此次未评测 PDF 解析、OCR、扫描件、照片、其他版式或真实客户单据。
评测范围与项目状态
独立原型，持续开发中。公开示例与已公布评测使用合成样例。已记录的评测使用从人工撰写的基准真值重建的干净英文文本，未评测 PDF 解析、OCR、扫描件、照片、其他版式或实际业务单证。系统检查用于辅助复核，不授权运输，也不替代专业判断。规则实现不等于专业或监管验证。这里不主张任何生产流量下的性能。
这个 demo 是怎么跑的
这些合成案例用于说明原型的单证审核流程。文档值为虚构；规则 ID、阈值和跟进文案为展示做了简化，不是未经改动的业务报告。查看案例不会请求 LLM，也不会上传文档。规则集哈希标识公开示例的规则目录，不保证规则正确。这是一个开发中的独立原型；示例不授权运输。
合成样例记录：2026-06-12 · 公开示例规则快照 c6f89cf4…
独立项目 · AI 编程验证
nonconstant一句“完成了”，还不够。
检查没跑、验收标准被改，AI Agent 仍可能说任务通过。我做了一套独立验证工具，把“证据支持通过”“证据表明失败”和“条件不足，无法判断”明确分开。
让完成有明确判据
用 Shell 检查给出三种结果，把缺少条件单独作为一种状态。
也检查验证过程
识别验收标准改动、已知的隐藏失败模式，以及与仓库不再一致的状态声明。
从脚本到可安装工具
按配置分发检查，让报告关联提交，并接入可选的固定版本工作流。
同一句“通过了”，证据可能完全不同。
切换预设，看看为什么“无法判断”不能算“通过”。
交互原理说明 · 预设示例。浏览器不会运行 Shell 检查、读取你的仓库或调用 AI Agent。
示例中的证据
完成声明
“我检查过了，任务通过。”
- 条件
- 被测目标、配置和比较基线均可用。
- 判据
- 受保护的验收判据未改变。
- 检查
- 示例中的检查通过。
-
通过 exit 0示例中的证据支持这项检查，不代表整个任务已被证明正确。
当前分支 -
失败 exit 1受保护的判据发生改变。再肯定的完成声明，也不能把这个证据变成通过。
当前分支 -
无法判断 exit 2检查缺少必要条件。“没观察到错误”不等于“有证据证明成功”。
当前分支
当前结果: 证据完整 → 通过 · exit 0
查看 nonconstant 源码
范围、项目来历与集成关系
这是可安装的 Shell / AWK / YAML 工具，不是托管 Agent 平台或完整编排器。仓库登记十道检查，其中八道可分发；安装到具体项目后仍需配置和复验。源码中记录了已知局限。
DevLoop v1 是我此前的 Python Agent 编排器，负责派单、隔离 worktree 和运行记录。它的事故经验促成了这个独立验证项目；nonconstant 没有导入它的代码。
GitHub Spec Kit 是可选、固定版本的上游工作流引擎，nonconstant 提供检查，没有 fork 或修改 Spec Kit。这是开源集成，不代表合作或背书。
meta-gate 检查正反演示是否登记，不会重新执行全部演示。这些是可核查的控制，不保证推理正确，也不等于防篡改。
03 / 游戏设计与系统工程
Terrarium
一个以环境干预与生态反馈为核心的独立模拟项目。
我负责体验设计、模拟规则与验收方式，并借助 AI 推进实现。
独立 PC 生态模拟 · 开发中
SYSTEMS ARCHITECTURE / 03TERRARIUM
生命不是一个功能，而是一组相互制约的系统。
将连续环境场、群体密度与个体行为组织在同一模拟内核中，探索局部规则如何塑造整体生态。
HYBRID SIMULATIONCONSTRAINED RESOURCESOBSERVABLE STATE
混合尺度关联结构 / 非执行顺序
连续环境场、群体密度与离散个体，以不同分辨率建模，通过栖地与取食关系相互连接。
摄入、消耗与余量返还连接生命和环境。容量边界与结算顺序，共同定义资源交互。
种群与地形变化汇入独立观察层，通过显著性门槛，从连续状态中提取世界的转折。
切换架构维度，或选择系统查看模型、约束与设计取舍。
系统接口
- 干预接口 → 连续环境场局部改变
- 连续环境场 → 混合尺度建模植被承载力
- 混合尺度建模 → 状态驱动行为食物与猎物
- 状态驱动行为 → 能量预算实际摄入
- 能量预算 → 受限资源返还死亡后的剩余能量
- 受限资源返还 → 连续环境场养分返还
- 混合尺度建模 → 事件观察层种群门槛
- 连续环境场 → 事件观察层地形占比转折
AI 辅助把设计落实到代码；哪些规则值得保留、哪些问题需要验证，以及是否接受一次实现，由我作出判断。
工程记录运行切片与独立验证
工程记录 / 局部环境干预
局部降雨：双运行状态对照
同一个起点，只多一次局部干预。把未加雨与加雨后的两段运行放在一起，在同一时刻观察水分与植被的变化。
这次记录里，降雨先增加水分，部分区域的草却比未干预运行更少。再往后，草密度的差异并不只有一个方向：有些地方更多，有些更少。
静态对照 · tick 10
抽象视图呈现已记录的水分与草密度，不是游戏实机画面。浏览器不运行游戏引擎。 按采样帧播放，非实时速度；叶簇表示区域密度，不代表个体。
这段记录展示什么
固定版本、同一随机种子；两份独立运行仅在一次局部降雨上不同。这里以区域平均值展示水分和草密度，使用固定色阶与大小标尺，并量化至 8 位用于网页呈现。
seed 42 · 48 × 48 → 12 × 12 · 21 个记录帧 · ticks 0–80
80 ticks 对应该配置的 4 秒模拟时间，采样间隔不等。差异圈只标出量化后草密度相差至少 0.008 的区域。
本段不是完整生态、长期稳定性或游戏体验的验证。下方可重复性测试是另一项独立记录。
record SHA-256 53d62771e51370395f02de455be0eed006b923910bf448050e599f3303dc4ff3
再深入一层：世界变化了，怎样确认它仍按规则运行？
工程细节 · 另一项已记录的可重复性测试 ·
世界背后，一项可重复性测试。
相同条件重复运行，结果一致；改动一个被测值，检查能发现差异。
我负责体验设计、模拟规则与验收方式，并借助 AI 推进实现。
这些指纹来自另一项独立记录的聚焦测试，不是降雨回放的结果。它比较固定条件下的部分模拟字段。
测试条件: 相同代码与设置 · 相同起点与运行长度
同样的起点，相同的被测状态。
A
基准运行
5c08d02e68b5a8ceB
A = B · 一致
=相同条件，再运行一次
5c08d02e68b5a8ceC
C ≠ A · 差异已捕获
≠把一个物种密度值改动 +0.5
1191f7875ca68ccb指纹覆盖范围: 水量字段 · 营养值字段 · 物种密度数组
指纹只覆盖上面列出的状态。它不证明像素完全一致，不覆盖整款游戏的所有隐藏状态，也不代表密码学安全或防篡改。
作品背后的人
系统性的基础，来自现场的判断。
在生产 IT 中，权限、变更和故障恢复都是日常问题。这些经历影响了我的独立项目：先理解实际操作的人，再让系统的行为变得看得见、说得清。
我在 McGill 学习计算机科学并辅修数学，之后在 UNSW 完成了 AI 与数据库系统方向的硕士学习。
我定义要做什么，也检查实际做出了什么。
AI 帮我实现；问题定义、系统边界、验收标准，以及是否交付，仍由我负责。
- 01 先理解问题
明确谁需要这个结果、哪里可能出错，以及什么样的结果才有用。
- 02 把边界建进去
用 AI 辅助实现，同时明确权限、判定规则和故障恢复路径。
- 03 检查实际结果
查看产物、运行相关检查，并把证据和未解决的问题一起留下。
这些做法在项目里如何落实
- Verdict：先定义产品边界
单证审核把模型提取、确定性检查和人工复核分开；项目规格与阶段提示词指导 AI 辅助实现。
- Verdict：接受改动前运行检查
它的 pre-commit 执行类型检查、测试与构建，CI 还运行 lint。已注册的工具 hook 会拒绝特定的禁止编辑；这些检查有明确范围，不是安全沙箱。
- DevLoop：让执行过程可检查
这个历史 Python 编排器使用独立 Git worktree、资源限制和运行记录。worktree 隔离改动，不隔离进程或凭据。
- nonconstant：分清失败与无法检查
Shell 检查返回通过、失败或无法判断。启用前必须登记通过与失败的演示；登记检查本身不会重跑这些演示。
- 跨项目：把失败变成具体改进
10 种记录在案的事故模式，对应检查或工作方式的变化。Verdict 的构建事故是其中之一；每项保障都有自己的覆盖范围与限制。
完整记述:事故模式词典 → · nonconstant: https://github.com/HaohangXia/nonconstant
写作
作品背后的选择、意外和教训。