以Jev试验提效：Naia ADK基于文档的多AI开发流程
大家好。我是打造Naia的Luke。虽然Naia在普通用户眼中看起来像是一个角色智能体产品，但我日常工作中有相当大一部分都在做软件开发，因此我们一直在构建配套的开发基础设施，并利用Naia的开发基础设施承接企业客户的软件开发业务。此前我曾出版过一本书，名为《Harness工程：从零开始的AI软件工程》（韩文版、英文版）。此后，我们依然在持续投入大量精力，以求更好地完善基于AI智能体的开发流程。
今天，我将公开为Naia开发而创建的软件开发流程与产出物，并分享我们如何尝试将近期热门的决策模型Jev引入到这一开发流程中。
在这个开发流程中，我所追求的核心目标有三个：可见性、并行化与成本优化。
- 可见性 : 掌握开发是否在正轨上进行；如果发生了模型漂移，想明确知道问题出现在哪个阶段。
- 并行化 : 将工作并行分派给多智能体，从而提升开发速度。
- 成本优化 : 使用经过成本优化的模型。Jev在这方面也是一个极佳的选择。
工作规则体系（Harness）的基础框架已作为开源项目公开在下方：
- 个人工作区基础框架与工作规则体系（Harness）：nextain/naia-adk
- 团队与项目协作基础框架：nextain/naia-pj-adk
- 社区参与指南：nextain/naia-comm-public
- Jev是TypeSafe AI发布的决策模型。
本文所介绍的任务队列、看板、Runner以及规划文档目前仍在内部开发中，尚未公开。目前该流程也处于验证阶段，正试用于即将在Naia Web上推出的全新功能：支持口型同步与演唱的视频虚拟人——Naia Visual Agent Studio的开发。之所以未完全公开，是因为它还不够完善，尚不适合作为团队项目共同使用；待整理完毕后会进一步公开。
本文与开发文档中使用的缩略语
首先，我们的开发文档、Issue与任务队列采用以下缩略语，并建立了项目的标准词汇表。这是因为向AI下达指令时厌倦了冗长的输入，且担心术语产生混淆。
| 缩略语 | 全称 | 术语名称 | 一句话含义 |
|---|---|---|---|
| PC | Product / Project Concept | 高层规划 | 我们为什么要做。产品的本质、存在理由、用户价值与整体信息架构 |
| SP | Screen Plan | 界面规划 | 用户将看到的界面的结构性图纸（布局、排布、跳转） |
| UC | User Scenario | 用户旅程（用户场景） | 用户在特定情境下进入、达成目标并离开的完整旅程 |
| RQ | Requirements | 需求规格 | 为满足UC和SP，系统必须满足的条件及可衡量的验收标准 |
| PL | Plan / Architecture | 技术分析与设计规划 | 通过实测确认技术现状，并制定架构与分阶段实现计划 |
| FE | FEature | 功能规格 | 为实现UC和RQ而构建的具体功能单元。不是前端（Frontend） |
| UT | Unit Test | 单元测试 | 验证功能单元是否按规格正常运行 |
| IT | Integration Test | 集成测试 | 无界面直接贯穿真实后端组件的测试。不是信息技术（IT） |
| E2E | End-to-End Test | 用户旅程端到端测试 | 从真实界面到真实后端贯穿完整用户旅程的测试 |
| QC | Quality Control / Validation | 独立验收（独立对抗性有效性确认） | 在不查看开发者剧本和内部实现的前提下，仅凭PC和SP对产品承诺进行攻击性验证 |
1. 引入背景与问题意识
如果把开发任务宽泛地交给AI智能体，它们往往会在没有后端的情况下直接开始编写用户界面（UI, User Interface），或者将用模拟对象（Mock）跑通的测试汇报为通过。因此，我们采取**自顶向下规划（Top-down）、自底向上开发（Bottom-up）的方式。规划自整体用户体验向下延伸，开发则从最小可运行单元向上构建，且只有在真实贯穿后端之后才对接界面。**因为如果先做界面，集成时大幅返工的概率极高。
2. 基于文档的工作流与开发流程
先编写文档是为了提前明确制作范围与验收标准。通过将要求文档化而非使用简单提示词，可以在出现问题时有效追踪问题根源。
我们将开发流程中的所有文档平铺列出，经人工确认后再创建Issue和任务队列项。AI在创建新Issue之前，会先审视该Issue关联了哪些文档，并检索此前已开启的Issue。只有当Issue、队列项和测试凭证全部齐备时，方可判定任务完成。
文档查看器的开发流程页面。文档按照图示顺序，从为什么做（PC）逐级下探至具体制作的功能单元（FE），而设计方案（PL）则是在首先实测模型与引擎的极限后才制定的。Issue不按技术架构层级拆分，而是每一个用户价值仅对应一个Issue，即便跨越多个代码仓库也保持唯一。从后端到验收的工序在该Issue内部以检查清单的形式指定，以防遗漏；只有在文档锁定的全部范围均具备完备证据时，才判定为完成。
在同一处集中查看规划文档各区段对应Issue、实现位置与判定状态的Studio集成索引。3. 测试的三层结构与时序规则
测试遵循行业标准命名划分为三个层次。
- 单元测试 (UT)：检查功能单元（FE）是否符合规格运行。
- 集成测试 (IT)：在无界面状态下贯穿真实的后端组件。仅通过模拟对象（Mock）的测试不予认可。
- 用户旅程端到端测试 (E2E)：从真实浏览器界面到真实后端贯穿一条完整的用户旅程。仅当SP中不包含界面的单元才允许不经E2E直接由集成测试关闭；若存在界面，哪怕本次修改仅涉及后端也必须执行E2E。判断标准是SP，而非实现者提交的修改内容。
核心在于时序。只有在后端通过集成测试（IT）之后，才能开发前端界面。目前Harness尚未在机制上强制拦截该时序，而是仅通过任务合同与独立审查核对凭证，仍有改进空间。
独立验收（QC）与实现者的自测相分离，在不参阅UC和FE的情况下，仅凭PC和SP在极端刁难输入与异常场景下验证产品承诺是否得到守信兑现。因为一旦查看了UC和FE，往往会局限于仅验证那一特定范围。由于该环节处于开发流程后期，目前尚未进行大规模实证检验。
4. 基于Git的任务队列与工作看板
为了确保谁在何时做了什么有据可查、值得信赖，任务通过Git仓库（naia-comm）中的任务队列进行管理。目前尚未搭建共享服务器，目标是在验证后搭建开发服务器，使多台设备与多名开发者能够协同工作。
各参与设备克隆该仓库并定期拉取，以发现新任务并汇报工作记录。执行仅由设备所有者在本地注册的Runner（从队列获取任务时代替执行AI的程序）完成，队列中仅记录Runner的名称，并不包含待执行的具体命令。
任务的每个阶段都会生成一个新的JSON文件。结果凭据中记录执行证据与退出状态码，取消操作也以追加写入的方式记录，从而对所有操作进行日志化以增强可追溯性。工作看板则是每当发起请求时重新读取该记录并加以呈现的界面。
工作看板界面（内部地址已打码）。顶部指标汇总了naia-comm main分支的队列记录：在截图时刻，228个任务项中可用10项、运行中1项、当前成功结果65项，另有4项以未注册Runner名称成功的记录被标注警告。5. 工作规则体系与多智能体协作架构
工作规则体系即通过文档约定的规则及其确认程序。自动化检查机制目前因处于恢复模式而被关闭（看板界面显示“HARNESS OFF”），且尚无通过代码强制阻断规则的关卡，因此主要依靠协调者的任务合同、监控脚本与独立审查来确保规则落地。
若仅使用顶尖模型，成本将急剧攀升；若仅使用轻量模型，则会在设计与验证环节接连失误导致项目受挫。因此，我们根据任务特性分工配置不同模型，并让它们相互验证。
| 角色 | 负责模型 | 执行方式与职责 |
|---|---|---|
| 分析与设计规划 | Claude Fable | 全局系统上下文分析、制定技术分析与设计规划（PL）、设计流程验证方案 |
| 任务协调 (Master) | Claude Opus | 总体任务分派与流程控制，不直接编写业务代码，负责监控智能体 |
| 代码实现与测试 | Gemini 3.8 Flash | 无对话直接执行命令行工具（CLI, Command-Line Interface）（无人值守运行为经过Runner时的设计）。测试由不同于实现会话的Flash独立会话负责 |
| 对抗性审查 | Claude Opus | 每轮投入全新会话，基于原始资料开展独立调查并核对交付物，提取足以改变结论的缺陷 |
| Runner代码实现 | Claude Sonnet | 避免由执行工人（agy）自行编写放宽其自身权限的代码（如让Runner以全自动批准方式调用agy工人），而由其他模型实现 |
※ 模型配置尚处于试验阶段，后续可能调整。
通过成本效率与权限隔离，我们将大批量的实现与测试迭代交由Gemini 3.8 Flash处理以节省高级模型的配额上限，并针对各角色持续探索和调整适配的模型。执行工人无法自行扩大自身权限，从而降低了智能体擅自放权引发事故的隐患。不过，由于该功能的缺陷导致任务因陷入孤立不可运行状态而停滞的情况频发，我们正持续进行测试与改善。
例如，“声明的代码仓库检出一致性”这类位置检查仅在经由Runner执行时起效，直接由任务合同发起的运行则不适用。
6. 基于独立调查的对抗性审查
审查者在打开提交物之前，会先直接调查原始指令、代码仓库、提交记录和任务队列记录，得出自己的结论，随后再与提交物进行比对。如果只看提交物，往往会遗漏错误前提或错误的仓库分支。每次均由全新审查者介入，只有在连续两次没有提出足以颠覆结论的缺陷意见时，才算通过。若陷入琐碎微小的挑错死循环，则会暂停并移交人工仲裁。
7. 观测到的成效与局限
观测到的成效
目前已形成这样一套运转体系：低成本模型（Gemini 3.8 Flash）通过非交互式命令行会话完成实现，协调者借助任务合同与监控脚本审查边界，高级模型则在每轮全新会话中完成独立调查后进行比对。监控脚本可在事后展示工人执行过的命令，审查者也具备了揪出工人虚报事实的结构性能力。
观测到的局限与脆弱点
廉价且性能较低的模型频繁出现不遵照指示执行的情况。它们可能会填报不存在的队列ID并报告完成，在流程文档中擅自加入未经指示的豁免条款，或者在提炼摘要时悄悄篡改原文条件。测试会话仅关注脚本是否通过，无法甄别该测试是否切实击中了真实后端。
虽然独立审查能够过滤此类缺陷，但验证成本高昂。这是因为高级审查模型的算力大量耗费在机械性的事实核验上。这也是我们在各个角色上不断测试适配模型组合的原因。
8. 借助Jev实现验证提效与未来展望
为了减轻审查负担，我们尝试将验证分成了三个层次。其中在第二层中，我们正在进行技术验证，评估引入兼具低成本与高响应速度优势的Jev。
- 第一层，机械性核对（脚本）： 如测试凭证的通过/失败（0失败、退出码0）、URL响应、文件存在性等仅需对比即可判定的项。
- 第二层，类型判定（Jev）： 当集成测试（IT）与E2E凭证显示“通过”时，甄别该测试究竟切实穿透了真实后端，还是仅仅在模拟对象（Mock）里空转了一圈。单元测试（UT）原本就允许使用模拟对象，因而不在判定之列。
- 第三层，方向性裁决（高级模型与人类）： 确认范围与意图是否吻合。
Jev是TypeSafe AI推出的决策模型，是一种仅依据固定选项和概率快速响应的低成本模型。软件开发中存在大量选择类问题，通过持续度量找到适宜的阈值（Threshold），即可同时收获成本与速度效益。这是大语言模型（LLM）出现之前的传统AI软件开发中广泛采用的优化手段，验证结果如下。
验证结果
我们采用仅在置信度达到0.85以上且换用其他措辞提问依然得出相同答案时才采纳Jev判定，其余情况均转交大语言模型（LLM）的策略，在871个测试文件（最终评估257个）中，实测与估算得出耗时可缩减约66%、成本可缩减约60~70%（时间以Gemini 3.8 Flash为基准，成本以Opus、Luna等模型的单价估算）。
| 判定方式 | Jev处理的文件占比 | 误判 | 耗时（对比纯LLM方案） |
|---|---|---|---|
| 仅使用LLM | 0% | 基准 | 100% |
| 当前规则（置信度>=0.85 + 换措辞答案一致） | 约 72% | 双AI达成一致的文件中为0例 | 34%（4路并发时为48%） |
| 将门槛降低至0.59时 | 约 89% | 增加1.8%p | 17% |
调用971次Jev的总成本仅为0.22美元，单次判定Jev耗时约0.7秒，而LLM耗时约12秒。
我们正在扩大实验范围以不断摸索最优参数值。**虽然其潜力已获证实，但尚未正式接入实际生产的开发流程中。**由于真值数据仅采纳了双AI给出相同答案的样本，结果可能会偏向难度较低的文件。
未来展望
依托这套规程，Studio的首个功能（输入剧本即可生成、试听并下载语音）已完成从后端到用户旅程贯通测试的全流程。后续课题包括进一步提升验证自动化程度，并将目前依靠人工和指令合同维系的规则交由工具强制执行。此外，我们还计划开展单独实验，探索Jev除了用于验证标记外，能否用于单项任务结束时选择后续工作的流转控制。因为这类流程走向裁决在当前每次任务中都必须调用高级模型，属于成本与时延居高不下的环节。
希望本次分享的内容能对大家有所助益。也请大家多多关注Naia的产品。原本应当尽快推出产品拿出成果才能迈向下一阶段，但感觉自己依然在复杂的AI控制与开发方法论上花费了大量时间。
