Agent-System-Dev/.task/genui-u1/report.md

U1 受控价值与选型试验报告（A/B）

日期：2026-10-11。任务：feature/generative-ui-u1。主记录：r1 提案 U1 节（用户 2026-10-11 裁定试验参数并指示开工）。 全部材料为合成样本；模型 MiniMax-M3 与 MiniMax-M2.7-highspeed（官方通道）；结果 JSON 在 results/，本报告为唯一汇总。

一、结论摘要

1. R1 结构分化成立：同料不同目标的 6 组对照全部结构分化（类型多重集 Jaccard 0.17–0.50， 全部 <0.6 阈值），模型确实按目标重排信息结构，不是模板换标题。
2. 生成臂可用但文本通道有硬地板：M3 首过合法 60%、一次修复后 83%（低于 r1 的 90%/98% 建议目标）；终判失败 5 例全部为长中文 JSON 语法违纪（无一是目录形状类错误为主因）。 工具参数通道探针证明该类失败可消除（平台保证 JSON 序列化，仅剩可修复的语义错误） ——直接印证 KTD2「页面规格作为工具参数产生」的必要性，r2 将其升为硬约束。
3. 成本可忽略：M3 生成 ¥0.067/任务（B 基线 ¥0.013），三臂加探针总开销 ≈¥3.0， 远低于 ¥200 上限。
4. M2.7-highspeed 不适合当生成档：文本通道合法率 20%（10 任务仅 2 份通过）， source 纪律也弱（覆盖 0.25）；维持「生成=M3、轻量=highspeed」的既有路由结论。
5. 外部 renderer 本期不引入：json-render 端到端可用但组件契约重（{element,slots,emit, bindings,children}）+自带状态/动作/可见性全家桶与我方 store/SSE/cmdbus 职责重叠； A2UI 导入即要求 DOM 且客户端 signal 绑定与 KTD4「宿主服务端解析」结构性冲突。 建议 U2 借鉴其「目录即 schema 即校验」，渲染继续扩展现有 UIRenderer。
6. 超生成倾向：order/handover 目标下模型倾向塞入未被要求的 form/actions（rc-03 19 节点 含 form+actions），r2 目录需按目标类别收窄可用词汇并加「最小充分」提示。

二、主要指标

指标	B（Markdown 基线）	G（M3 生成）	G-hs（highspeed 生成，子集）
任务数 / 调用数	30 / 30	30 / 42（含 12 次修复）	10 / 20
规格首过合法	—（无规格）	18/30（60%）	0/10
一次修复后合法	—	25/30（83%）	2/10（20%）
结构契合（预期类型命中）	0（无结构选择；compare 目标 3/3 用了 markdown 管道表）	0.66（ri 0.88 / to 0.58 / rc 0.54）	0.89（n=2，不具统计意义）
source 覆盖（引用材料源占比）	—	0.87	0.25
稳定 nodeId 提供	—	25/25（合法规格全部提供）	2/2
prompt/completion tokens	13.6k / 41.0k	43.7k / 221.0k（中位 4.8k）	18.2k / 24.5k
费用（¥，保守无缓存折价）	0.38（¥0.013/任务）	2.00（¥0.067/任务）	0.50
平均单任务耗时	~15s	~59s	~37s

R1 分化明细（同料三目标 facts-A / facts-B，6 组两两对照）：Jaccard 0.17 / 0.32 / 0.44（A 组）与 0.26 / 0.45 / 0.50（B 组），6/6 判 distinct。示例：同一份三工具档案， compare 目标 → section×4+table+kv+markdown（8 节点）； risk 目标 → section×7+tree+kv×3+table+markdown×6（18 节点）； order 目标 → steps+timeline+tree+form+actions+doc-ref×4 等（19 节点）。

三、失败归因（G 臂 5 例终判失败）

• 无一例接近 14k token 上限（max 13366）——不是截断，是长中文串中的 JSON 语法违纪 （未转义字符等）；修复轮 4 例仍语法错、1 例语义错（ri-02 修复轮出现 null 节点）。
• 探针 1（ri-10 + response_format=json_object）：仍语法失败——不解决。
• 探针 2（ri-10 + 工具调用 present_page）：解析干净通过，仅剩「children 内非对象」类 语义错误（修复环可处理）。生产通道定型：工具参数。
• 首过失败 12 例中除语法外，目录形状错误集中在 tabs（active 放错层级）与 form（多余包装层）， 提示目录文档需给「完整最小示例」而非仅字段表（r2 修订）。

四、renderer 选型挑战（详见 renderer-spike.md）

• @json-render/core+react 0.21.0（Apache-2.0，React 19 peer）：defineCatalog(zod)+validateSpec+ createRenderer+renderToString 端到端跑通（含嵌套 children 组合）。买它主要买「schema 驱动校验+ 目录即提示」，但组件契约与状态/动作/可见性运行时与我们重复；仅用 render+validate 子集则增量 价值不足以抵消适配层（扁平 elements ↔ 嵌套 UINode 双向转换 + SurfaceVersion 联动 + 16 组件包装）。
• @a2ui/react 0.13.0：导入即引用 HTMLElement（无 DOM 环境抛错，~20M 依赖）；客户端 signal/binder 数据绑定与「宿主服务端解析数据」信任边界冲突。本轮未做完整渲染 spike（部分完成）。
• 结论：首期扩展自研 UIRenderer；json-render 记为 U5 交互期重评项。

五、对 r1 的修订要点（r2）

1. 生成通道硬约束：页面规格只能经插件命令的工具参数提交（exposeAsTool）， 不接受聊天文本 JSON；校验器语义错误回传、原 Agent 至多重提一次（维持）。
2. 目录文档必须携带每类型「完整最小示例」+ 按目标类别的推荐/禁用词汇表 （收窄 order/handover 下 form/actions 的随意使用）。
3. 校验器升级为 schema 驱动（借鉴 json-render 目录思路）：目录=提示=校验三同源， 减少手写字段检查。
4. 生成模型默认 MiniMax-M3；M2.7-highspeed 不进入生成路径（本轮 20% 合法率）。
5. 规格有效率目标修订：工具通道下首过 ≥90%、修复后 ≥98% 维持为 U3 验收线； 本轮 60%/83% 记为文本通道下界，不作为能力否决依据。
6. U2 优先级确认：稳定 nodeId/页面信封/启禁闭环先行（本轮 nodeId 纪律良好， 25/25 合法规格全部提供稳定 id）。

六、局限与 NOT_RUN

• 人类可用性对照（任务成功率/耗时/满意度）未做——本轮全部为机器可判定指标； 「20% 效率改善才扩大自动模式」的判据仍需后续人工评审任务。
• 合成材料、n=30、每任务 1 次采样（rule-of-three：单项差异不足 3 例勿过度解读）； G-hs 有效样本 n=2，其质量类指标不具统计意义。
• 评分口径：结构契合按「预期类型出现比例」计，模型用 table 替代 compare 等合理替代 会被低估（rc 族 0.54 部分源于此）。
• 首轮 harness 缺陷（max_tokens=6000 被内联 挤占导致 JSON 截断）已修复为 14000 并重跑；首轮失败样本被重跑覆盖（错误信息留存于本报告第三节与运行日志）， 由此产生的额外调用量未入 results 统计（费用影响 <¥0.5）。
• renderer spike 为 /tmp 隔离环境一次性运行，未入仓、未做视觉/可访问性验收。