我如何通过指挥AI代理来构建OMLA，而非亲自编写代码

以下就是我使用的完整流程：借助 AI 编程助手，几乎全靠它们就为一家非营利组织搭建出了 OMLA——一个用于管理版权许可的后端系统。不妨借鉴这个流程吧。最终完成的后端系统本身便证明了该方法的有效性。

最终成果

在介绍具体实现方法之前，先来看看最终的成果：OMLA，即开放模型许可协会。这是一个用于开源人工智能模型的授权管理与付费后台系统，同时也提供了面向公众的网站。

项目内容	具体结果
当前状态	正在申请成为华盛顿州的非营利组织，目前处于 501(c)(3) 认证流程中。网站特意标注为“Beta 0.9.0”版本。
许可条款	个人、研究与教育用途完全免费。商业用途则需支付费用：比例为可归因收入的30%，或者模型运行所需成本的30%，取两者中数值较大的那个。
数据库	共12个核心数据表；基于 Postgres 17数据库，部署在 Supabase平台上。所有数据均启用了行级安全机制；金额计算均采用整数“分”为单位（绝不使用浮点数）。
身份验证机制	采用 ed25519 与 ML-DSA-65 混合签名方案，兼顾传统加密与后量子加密技术，确保即便未来出现量子计算机破解算法也不会影响系统安全性。只有经过验证的签名才能生成相应的授权声明。
审计追踪机制	所有记录均为追加式写入；每条记录均通过 SHA-256 哈希值串联起来，每小时进行一次校验；每日还会将链尾信息单独存储到数据库之外作为“锚点”。
前端界面	约30个纯静态 HTML 页面，未使用任何框架；支持13种语言，部署在普通的共享主机上。
开发团队	由一人负责统筹指挥；Claude Code 负责代码编写；一群本地开源模型智能体则负责代码审查及其他琐碎工作。
截至2026年7月的进展	所有功能均已完成测试与预部署。目前仅处于模拟运行阶段，需等我亲自输入“GO”指令才会正式上线。

或许你会觉得这一切是在一个周末内完成的吧？以下是大致的时间线：

• 2026年5月下旬 — 从个人聊天机器人小项目转向创建非营利性许可机构；同时设计了最初的12个数据表结构。
• 几天之内 — 实现了后量子加密签名机制、与资金处理相关的功能模块，以及所谓的“无托管式”系统架构重构（详情见下文）。
• 6月初 — 后端系统正式上线（仅数据库部分，前端网站尚未发布）。
• 6月16日 — 法律相关条款修订完成，许可协议 v1.0 开始生效。
• 7月2日 — 整个网站与后端系统全面更新；还重新翻译了13种语言版本。截至本文撰写时（2026年7月），仍需等我下达“GO”指令才能正式上线。

有趣的起源小故事：OMLA 最初代表“Open Machine Learning Assistant”，也就是一个个人聊天机器人项目。后来这些基础设施被直接沿用到了许可机构的创建中；而原先的聊天机器人则被降级为仅用于文档查询的工具，目前在生产环境中处于关闭状态。把一个业余爱好性质的聊天机器人改造成许可管理基础设施——这种“范围蔓延”现象其实挺常见的，对吧？

让一切成为可能的规则

在编写任何代码之前，有一个设计决策起到了决定性作用：OMLA绝不移动、持有或传输资金。 它仅计算应支付的金额，然后公布收款方自行提供的钱包地址或支付信息。商业用户直接以点对点的方式向创作者付款。无需任何支付处理服务、托管服务，也没有所谓的“OMLA余额”。钱包标识符只是路由信息，并非账户。

许可证中的描述也极为明确：“OMLA负责发布信息；OMLA并不负责付款。”

为何要这么做呢？充当资金传输方本身就伴随着复杂的监管要求与许可流程。若放弃资金托管职能，KYC、制裁合规及税务负担便会转移到实际进行交易的双方身上——而这本就是法律上应有的责任归属。正是这一决策，才使得一个单打独斗的爱好者也能尝试开发这个项目。

这甚至并非最初的设计方案。在开发过程中，系统架构仍隐含着资金托管的意味，于是原本名为 payments 的表被重命名为 royalty_statements——为此需要迁移大量列、索引、触发器以及权限控制规则与枚举值，目的只是让数据库不再“撒谎”。不过旧有的表述后来还是给我带来了麻烦（详见注意事项）。

以下便是每一笔版税资金在全程未经OMLA触碰的情况下所经历的流程。

第4步是关键所在：若第一步中的签名未通过验证，则永远不会有任何版税明细产生。OMLA仅负责发布应支付金额及收款方的钱包地址，之后的事宜完全由双方自行处理——这便如同我告诉你有个朋友欠你二十块钱，随后任由你们自行解决一样。

实际的流程：人、AI代理、审核、部署

整个工作流程并不复杂。关键在于严格规定谁该做什么，而且每当有变动时这个流程就会重复一次。

关键不在于这些方框本身，而在于没有任何环节可以跳过。每次变更时，我都会先明确说明需要实现什么以及原因，而不是笼统地说“把它做得更好”。AI代理们会根据该规范起草内容；在我看到之前，其他代理还会对初稿进行审核。测试则会在模拟生产环境的本地基础设施上运行。只有经过这一切后，我才会查看代码差异。

整个后端系统都是先在本地运行的：我在自己的电脑上使用无根容器来运行真实的 Supabase 环境，包括 PostgreSQL 17 以及边缘函数。生产环境只是部署目标而已，并非数据的真实来源。如果本地环境与线上环境的结果不一致，那么以线上环境为准；直到我亲自发布新版本为止。

质量标准并非仅存在于我的脑海里，而是明确写入了项目配置中：“默认即满足审核要求：所发布的内容应能经受住外部审核。”整个流程假定会有独立的审核者——无论是 AI 还是人类——日后会对成果进行细致检查并挑出问题。

针对真实环境进行测试，而非模拟环境

如果测试结果不可信，那上述一切就都毫无意义了。因此，我们绝不会在模拟数据库上运行测试。所有测试都是在一个真正的、可随时重置的本地环境中执行的。共有三个层级，只有在全部通过后才能进入部署阶段。

deno test                  # 13 unit tests for the edge functions
./test/run.sh              # isolated scratch DB per run, migrations w/ ON_ERROR_STOP,
                            # smoke tests (PQ signatures, wrong-key rejection, audit
                            # hash-chain, payout gate), RLS cross-tenant isolation,
                            # an adversarial suite, then rollback + reapply
./test/integration.sh      # the full money path against the live local stack:
                            # register → tampered payload rejected → wallet verify →
                            # splits → usage report → statement published → replay
                            # (asserts zero duplicate writes) → admin gate → compliance

其中“重放操作后不应出现任何重复写入记录”这一条要求其实至关重要。使用数据报告来自其他系统，因此偶尔会出现同一报告被意外重新提交的情况；该测试的作用就是确保即使重放相同的报告，也不会产生任何新的记录，而不只是确保程序不会崩溃而已。后来我们又进一步强化了测试机制：改为直接验证结果而非仅记录日志——听起来有些吹毛求疵，但当你在调试一个“通过”了却什么都没做的测试时，这种做法就显得非常必要了。

用于评估其他审计结果的审计机制

让一个人工智能模型去审查它自己的工作成果，其实毫无意义——相当于走个过场罢了。因此我们特意采用了多层审计机制：先由一组本地智能体进行初步修正，随后再由一个更强大的模型作为最终的独立审核环节。

这个最终审核环节绝非流于形式。在一次审核过程中，它不仅验证了本地智能体所做的修正，还发现了初次审核时遗漏的搜索路径绕过漏洞，以及数据列、签名与数据溯源信息方面的缺陷。这些问题促成了一次系统加固行动：我们共发现了12处问题点，并为每一点都配套编写了回归测试代码，以确保此类问题不会再悄无声息地重现。

审计规模也随需求而变化：常规任务只需由3个智能体组成的审核小组处理；而整个前端及国际化系统的全面改造则动用了24个智能体协同作业。正是这次大规模审核发现了网站内容已出现偏差——页面上仍在描述旧版聊天机器人产品，而非如今实际存在的许可管理后端系统——最终促成了网站的彻底重构以贴合现实情况。

部署控制机制：在我手动输入指令前均为模拟运行

部署程序的唯一职责就是确保任何操作都不会意外地应用到生产环境。默认情况下每次执行都是模拟运行；只有加上明确的标志后才会真正对生产环境进行修改——这一“先模拟运行再正式执行”的模式与我用来让AI代理发布网站的方式如出一辙。

./deploy.sh              # dry run (default) — shows exactly what WOULD happen
./deploy.sh --go         # only a human runs this, only when ready

还有一个引导式控制机制：在执行任何会修改生产环境的操作前，必须手动输入“GO”才行。此外还有一条明文规定的规则：绝不能在无人明确指示的情况下添加 --go 参数。

除了这些政策规定外，部署程序本身还内置了多项保障机制：

• 前端同步操作绝对不会使用 --delete，因此绝不会误删那些不在其管理范围内的文件
• 每次覆盖前端内容前都会先生成服务器端备份
• 只有当前链接的项目与预期的生产环境项目相匹配时，后端才会执行操作——这能有效防止数据被错误写入数据库
• 远程端只会执行增量式迁移操作，绝不会执行重置操作
• 出于安全原则，文档相关的聊天机器人功能在所有部署过程中均被禁用
• 所有敏感信息仅保存在权限设置为 600 的文件中，且会进行明文校验以确保服务角色密钥绝不会出现在发布的代码中

说实话，这个项目的部署日志基本上就是我犹豫不决的记录：一次又一次地进行模拟运行，而一个完全准备就绪的全新界面设计却只能等待我的最终指令。这并非程序缺陷，这正是“受控部署”应有的效果。

注意事项

容易出问题的地方：

• 零宽度字节。 迁移用的 SQL 语句必须是纯 ASCII 编码。哪怕只有一个不可见的非 ASCII 字节，都可能把 $$ 这个美元引号标记拆开，从而悄无声息地将两条 SQL 语句合并在一起。因此我们形成了一套固定流程：每次都要用 grep 检查是否存在非 ASCII 字节（理想情况为零），同时统计 $$ 标记的数量（必须为偶数）。
• 百分号惹的祸。 在 RAISE EXCEPTION 的格式字符串中，%% 才表示字面意义上的百分号；而每个变量值前都必须恰好有一个 %。我曾经因此栽过跟头，这才特意把这一点记下来。
• SECURITY DEFINER 函数需要固定 search_path。 所有以 SECURITY DEFINER 权限创建的函数以及触发器都会固定其搜索路径，这样就没人能在 pg_temp 下创建同名的表并注入错误数据。我们的对抗性测试会统计这类固定了搜索路径的函数数量；若数量减少则测试失败。
• 超级用户权限有时会丢失。 在系统非正常重启后，本地的 Postgres 角色有时会失去超级用户权限。解决办法就是彻底停止并重新启动服务，而非进行复杂的故障排查。记下这点是为了避免自动化程序反复发现并重复处理此问题。
• 国际化功能会悄无声息地覆盖 HTML 内容。 翻译层会完全替换页面上的文本；因此即便修改了 HTML，只要对应的语言文件未同步更新，显示的依然是旧版文字。以前在系统调整期间就出现过这种情况：明明已删除的旧文案却反复重新出现。
• 审计链可被故意篡改，这一点我们心知肚明。 拥有完整数据库控制权的攻击者可以删除哈希链触发器并伪造出看似自洽的历史记录；仅靠内部检查无法察觉此类篡改。为此我们设置了每日任务：在数据库外部单独记录审计链的末端哈希值；测试套件也会同时验证两方面效果——内部检查是否失效、外部锚点是否能检测出篡改行为。
• 线上站点尚未完成更新。 截至本文撰写时（2026年7月），公开网站上仍显示着一些调整前的旧内容（比如旧版许可协议草案、过时的支付相关说明）。这是因为重新设计工作尚处于预发布阶段，并未正式上线。此外，公开的 /about 链接实际上只是个目录索引页面；真正的 AI 披露信息页面则位于其子目录中。

相关链接：完成这些工作的本地智能代理系统，这些代理如何维护我的网站，若你想搭建类似系统也可参考如何设置属于自己的 LLM 助手；另外还有如何让 LLM 将任意开源项目适配到你的系统中。