AI 原生系列 · 信任工程
文章提出了预言账本，代码十七分钟后就上线了。
一分钟速览——读完你能带走什么
提出基建方案的文章通常都以「应该有人把这个做出来」收尾。而这一次，在「预言账本」那篇文章合并的十七分钟后，OEC 完整性链就已经合并进了 kingdom-come 的主分支——一个真实、开源的神学院平台——化作约 330 行代码、10 个 API 路由，以及一套测试名称本身就是这篇文章思想实验的测试套件：婚礼矛盾、无法证伪的话语、延迟时钟、过期的背书。教训不是速度，是体裁。一份能跑通测试套件的提案，是另一种性质的承诺——而智能体化工程，刚刚让这种承诺变成了默认选项。
这是完整性技术栈故事的第二部分：从论证到git push，同一个下午完成。约 7 分钟阅读。
上一篇文章 提出了一个主张：像可信的系统对待任何有后果的输出一样，去对待公开的属灵宣告——可观测性 （宣告仅可追加、哈希链式的提交）， 评估 （声明式判定标准、三档诚实评级、矛盾与延迟检测）， 控制 （一道平台闸门，其后果与计分卡挂钩）。和这类文章一样，它最后也附上了一张架构图。
这类文章都有一种失败模式，我自己在文中就点明过："policy without observability is a sermon about logging."「中译：没有可观测性的政策，只是一场关于日志记录的布道。」同一把剃刀，也照样削向我自己： 没有实现的提案，只是一场关于闸门的布道。 于是就有了这第二篇——它之所以存在，是因为这篇文章的后续不是一个讨论帖，而是一次提交。
心智模型：可执行的提案。 在旧有的建造经济学里，写文章和做实现是两个不同的项目——文章只要一天，代码却要一个季度，于是世界上堆满了文章。智能体化工程把这道差距压平了：写出论证的那个下午，也写出了约 330 行代码、10 个 API 路由，以及在真实平台主分支上的 12 个测试。当实现变得这么便宜，「某人应该把这做出来」就不再是一句结论，而变成了一句自白。
载体：一个早已在为「先知话语」称重的平台
这些代码，可不是落在某个玩具仓库里。 kingdom-come 是一个开源的神学院培育平台（FastAPI、实时演示、200+ 项测试），其中已经有一样了不起的东西： 牧养祷告与预言账本，其中每一句先知话语，都由三位指定「称重人」中的两位来裁定通过与否——把《哥林多前书》14:29 逐字实现为一台状态机——随后追踪其应验情况，并要求提供见证。文章提案中「牧养」的那一半，早在文章写成之前就已经存在。
它所缺的，是「完整性」那一半：牧养账本记录下的，是群体 所决定的结果，但没有任何机制能保证记录本身不会被悄悄改写，没有要求宣告必须具备可证伪性，更没有把后果和过往记录绑定在一起。这恰恰就是 2026 年那起事件暴露出的三个漏洞。于是，新的模块——backend/services/integrity.py ——就安放在牧养账本旁边，把这三个漏洞一并补上。
代码强制的，而非建议的
- 过去，仅可追加。 每一个事件——主张、结论、修正、异议、背书——都是一次哈希链式提交（commit）。修订本身就是一次新的事件；「这只是个异象」会在该主张的历史记录里留下一条清晰可见的差异（diff）。谁若悄悄改写过去的某条记录，
verify_chain就会精确报出断裂处的序列号。 - 无法证伪的话，赢不了。 一项主张在提交时就必须声明其判定标准与时限。若试图把一个未设标准的「预言」判为「应验」，API 会以 422 拒绝。这条规则就写在源码自身的文档字符串里，让下一个维护者绝无可能错过：「一句永远不可能为假的话，也永远不能被算作真。」
- 矛盾，当天现形。 同一位讲者，同一个主题，说法相悖，却都未被更正——在第二次提交时就已侦测出来，远早于任何应验期限。闸门便告失效，就在当天。.
- 更正的延迟，是一个数字。 一句公开落空的预言，会附带一个不断累积的「未更正天数」计时器；一次公开更正会让它停止计时，并重新打开闸门。案例中那个出卖了时机的信号——道歉偏偏只在曝光压力逼近时才姗姗来迟——如今不再是捕风捉影的猜测，而是一项被公开发布的指标。
- 闸门会说明理由。
platform_gate只依据可测量的证据来判定失败，而每一次失败都会给出一句话作为解释：「open contradiction(s) on: marriage:couple-a」·「failed public word uncorrected for 400 days (policy: 30)。」 无法测量的话，永远不会被判定为通过或失败——它们根本不计入其中。 - 背书是有保质期的。 一份背书是一个持续对照闸门重新验证的「活」对象。它不可能比自己的证据多存活二十年——因为它根本无法脱离自身的计时器而存在。
测试套件，就是那个思想实验
第一部分以一个思想实验收尾：老老实实地把这桩记录在案的事件，重放一遍这整套系统。到了第二部分，这次重放不再是文字叙述——而是tests/test_integrity.py，重点就在这些名字本身。以下逐字摘自测试套件，任何人都可以在公开仓库里读到 [1]：
test_wedding_contradiction_fires_same_day——私下里说的「这不是主的旨意」，和婚礼当天出现的天使，被记为两次独立的提交；矛盾检测器无需等到天使的话落空，就已经触发。test_unfalsifiable_word_grades_not_measurable_only——「突破的季节即将来临」这类话，可以被归档，却永远赢不了。test_latency_to_correction_is_computable——一句被证伪已达400天却始终未获更正的话：闸门会给出具体天数作为拒绝理由；一旦当事人公开更正，闸门随即重新开启。test_endorsement_expires_and_reverifies——同一份背书，今天报告状态为 「现行有效」，之后会报告为 「失败」——就在其发言人自己的记录变为失败的那一天，无需任何人再做新的裁决。test_dissent_is_logged_beside_the_claim——母亲的反对意见，被记录在那句压过她意见的话语旁边，永远留存在该主张的历史记录中。test_chain_tamper_is_detected_and_named——针对账本本身发起的「语义退守」手法：悄悄改写一条历史记录，会在序号0处打断哈希链；一旦账本断裂，闸门就会让它所覆盖的所有人全部未通过。
这个模块共有十二项测试；平台的完整闸门—— make check ——在发布这个模块的那次提交上通过了227项测试 [1]。其中有一项测试值得单独成句，因为整套设计最终都要向它交代： test_gate_passes_a_clean_speaker。一位诚实的讲道者，说出一句可衡量的话，如实兑现，便畅通无阻。这套体系不会让诚实的牧者付出任何代价——这一点本身，恰恰说明代价从来都不是重点。
当天上线，证明了什么，又没证明什么
说句实话，关于那十七分钟：代码是与文章的最终审阅同步完成的，出自撰写文章的同一套「人类+智能体」工作流——这个数字衡量的，只是两次 合并操作，而不是什么超自然的打字速度。而且，主分支上的 v1 版本也并不等于一套已经落地的制度：哈希链目前是内存实现，持久化留待后续（文档中已注明）；矛盾检测是结构性的（比对声明的主题与立场），而非语义层面的——模块的文档字符串已经明白写出这一点，不让读者误以为背后有什么 NLP 魔法；至于第一部分提到的采纳难题，再多代码也无济于事，因为最需要账本的那些领导者，恰恰不会自愿套上它。平台，依然是那个可以撬动一切的支点。
它真正证明的，范围更窄，但我认为也更有用： 借口清单变短了。 「总得有人把这个做出来」，现在有了一个带 commit hash 的回答。当一篇文章的提案能够在真实平台的主分支上运行、通过测试，甚至早于这篇文章的推广素材被点击发布之前，那么无论是教会的标准文档，还是任何人的标准文档，诚实的问题就不再是「这是不是个好主意」，而变成了「它凭什么还只是一份 PDF」。
好做法 / 坏做法
- 好做法——提案与闸门一起上线。 如果你在为一项标准辩护，真正算数的是可执行的强制手段，而不是论证本身。
- 好做法——用促成测试的那个失败案例为测试命名。
test_wedding_contradiction_fires_same_day这比任何注释块都更能让下一位维护者读懂历史。 - 好做法——让诚实的评级成为强制执行的评级。 not_measurable 就是一个 422 错误，而不是一条脚注。
- 反模式——永恒的白皮书。 一份「即将发布」的标准，等待的时间早已超过了真正把它做出来所需要的时间。
- 反模式——演示仓库式的证明。 只在吹捧它的文章旁边才能运行的代码。这条完整性链，活在一个有真实用户、有测试、有部署的平台里——就在它所补全的牧养账本旁边。
- 反模式——把速度本身当成美德。 十七分钟是工作流程的属性，不是作者的功劳。如果说有什么功劳，那就是——拒绝在没有日志记录之前，先把布道稿发出去。
机制，命名如下： 可执行的提案——当智能体化工程把「论证」与「构建」之间的成本差距压缩掉之后，实现本身，就成了检验论证是否真诚的试金石。
第一性原理，一句话说完： 如果你提议一道闸门，就把这道闸门做出来——没有落地的标准，只是一篇关于记录日志的布道词，而如今，会众可以自己去查提交记录。
出处说明——哪些已核实，哪些只是说法
本文引用的全部代码与测试名称，均可在 kingdom-come 公开仓库的以下提交中核实——commit 1c5869f [1]，包括源码内那条规则："a word that can never be false can never be counted true."（中译：「永远不可能为假的话，也永远不能被算作真。」）227 个测试全部通过——这一数字来自我自己跑的一次 make check 运行结果，记录在该仓库的成绩单里（编号 rc0001，位于其 docs/reportcards/collection.json）。十七分钟的间隔，指的是我自己仓库日志里两次合并（merge）的时间戳之差——kingdom-come 那一份是公开的，portfolio 那一份是私有的，所以这个数字只能算是我本人的报告，读者可以对照这两份材料的发布时间，大致核验其可信度。2026 年那起案例，第一部分已经按照完整的出处规范做了交代。
参考资料
- wjlgatech/kingdom-come（公开仓库）—— backend/services/integrity.py · tests/test_integrity.py · commit
1c5869f, 2026-08-02. - Wu, P. J. (2026)。凡事察验，善美的要持守——如今，我们有了工具。 第一部分——案例、古老的规范、OEC 设计。 agentic-portfolio-lovat.vercel.app/articles/prophetic-integrity-stack.html
- Shekinah Worship Center（2026）。 《关于 Sadhu Sundar Selvaraj 的声明》 ——测试用例命名所依据的原始案例；引文已在第一部分核实。 shekinahworship.com
- 经文： 《新国际版圣经》（NIV）——哥林多前书 14:29（"Two or three prophets should speak, and the others should weigh carefully what is said"（中译：至于说预言的，只好两个人，或是三个人，其余的人应当分辨）），已对照 biblegateway.com 核实；在 kingdom-come 中实现为「2 of 3」权衡规则。
相关文章
写于代码上线当天，依据公开仓库、通过的测试套件，以及第一部分核实过的案例档案。——Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app