质量是「收敛」出来的：Qwen3.7-Max 仅凭调研文档全自动交付双端应用实验
让 Agent 改一个按钮、修一个 Bug，今天已不算新闻。但只给它一份调研文档，让它从 0 写出高度还原的完整应用呢？这是一条横跨规划、架构、十几个模块编码、验证、修复的超长程任务：几个小时、成百上千个决策、前后强依赖，错一步就会沿着后面几十步一路放大。这正是今天大多数 Agent 最容易翻车的地方。
最近，我们和 Efflora 团队基于 Qwen3.7-Max 模型，做了一场实验：仅凭一份产品调研文档，在隔离环境中从 0 交付了移动端和 Web 端两套可运行应用。这场实验也揭示了一个被忽视的工程真相：质量不是模型一次「生成」出来的，是被闭环「收敛」出来的。
我们用 Qwen3.7-Max 做了啥
给 Qwen3.7-Max 一份产品调研文档，让它在隔离环境里，从 0 交付能真实跑起来的应用——而且移动端、Web 端各一套，发现页瀑布流、商城分类与商品卡、内容详情页的图文与评论流，核心界面与主要交互都被几近还原。
- 唯一输入：「图文社区 + 商城」形态产品的用户流程文档 + 关键页面拆解报告，合计 约 15 万字、拆解 12 个核心页面（覆盖 8 大功能模块、7 条用户流程）；
- 没有给的：设计稿、现成代码、分步骤的人工拆解、后端逻辑；
- 耗时：单端从 0 到可运行 约 4 个多小时全自动完成，中途无人工接管。
本次实验亮眼的地方在于：
1、它没「看」过任何一张图，却把界面还原了。Qwen3.7-Max 不具备图像理解能力，整个过程它没有看过任何一张设计稿或截图——还原靠的不是模型的眼睛，是约束。
2、它写的是真应用，不是点击演示。在未提供后端逻辑的前提下，模型自行设计了一套完整的关系型数据模型（近 20 张表，含多对多关联表与索引），并写出带字段校验、分页过滤、错误处理的真实接口逻辑；前端则真实调用这些接口取数据、刷新、给用户反馈，而不是把数据写死在页面里。这是有建模意识、有副作用、有错误处理的真实工程，不是占位桩。
⚠️ 本次仅作为技术能力验证，目标 App 为一款图文社区 + 商城形态的生活方式产品（已匿名化）。文中界面均为模型自主复刻的还原效果，数据为预置的种子数据，不含任何真实用户数据，不作商业用途。
怎么做到的：分阶段注入约束 + 分层验收
与其说我们让模型写了应用，不如说我们设计了一套约束闭环：把整个 0→1 过程拆成有序的阶段，在每个阶段把「要做成什么样」翻译成机器可校验的硬约束，再用一道比一道更严的验收机制，把模型逐步逼到达标。标准的制定与验收，全部不交给模型——它只负责在每一格里做决策。
值得强调的是：移动端和 Web 端用的是同一套方法论。技术栈不同，约束闭环不变——这恰恰说明，决定交付质量的是这套控制方法，而不是某一种框架、或某个模型的单点能力。
这套约束闭环控制系统，不是「给模型一个写代码的地方」，而是一条「分阶段注入约束 → 逐层验收 → 带错纠正」的可收敛流水线。
1️⃣ 分阶段，把约束「种」进每一步
约束不是一次性丢进去的，而是跟着阶段逐层加码：规划阶段约束目标边界（从调研结论先推出页面 / 模块清单，想清楚「做成什么样」再动手）；架构阶段约束技术选型与数据建模，并把真实 UI 的像素坐标反推成布局约束；编码阶段约束实现规则，并要求每个模块写完先自查、逐条指认「哪行代码落地了哪条约束」。
不让模型看一段「页面描述」就拍脑袋，而是把真实界面的像素事实，直接翻译成它必须遵守的布局约束。
但约束能落地，有一个隐含前提——模型得真的守规矩。我们给的硬规则（长文件分段读取、动手前先用 Glob探查、改文件前先读原文）Qwen3.7-Max 在近 30 分钟、数百次工具调用里逐条照做，而不是盲写；它甚至会按真实依赖关系重排执行顺序（先把所有页面建好，再回头补路由），而非机械按编号推进。一个不守约束的模型，再好的约束工程也落不了地。
2️⃣ 分层验收，一道比一道更接近「人」
写完不算交付。我们架了一条逐级加码的验收阶梯，失败时把上一步的报错原文喂进下一次重试，让偏差当场收回：
- 静态检查（命名、未用引用、空安全等）
- 编译自检（必须 0 error 才算过）
- 路由完整性（每个页面都接得上、点得到）
- 功能扫描（空按钮、占位页、假加载等交互缺陷）
- 部署到真实运行环境，冷启动，像人一样跑起来看
这一步，是我们最想强调的认知
机器可验 ≠ 应用可用。编译通过、0 error、路由齐全、功能扫描干净，这些只证明「代码成立」，不证明「应用可用」。一个真人怎么评价一个 App？他不会去看你静态检查过没过，他会打开它、在真机上点一遍、看顺不顺、像不像。所以验收标准必须贴近人——闭环的终点，是把应用装进真实运行环境冷启动、像人一样用一遍。
3️⃣ 确定性兜底，长程里别丢步
整条阶梯由一层确定性调度兜底：每个模块必然被执行、失败必然重试、中断可断点续跑。模型负责「智能」，调度负责「可靠」——用确定性的脚手架，包住非确定性的 Agent。
细节 / 日志：约束是怎么被「执行」和「判定」的
细节一：让模型照着真实 App 的「像素坐标」写布局，而不是照着文字描述
问题：文字描述是有损压缩 复刻一个界面，最自然的做法是把调研报告喂给模型：「首页是两列视频网格，顶部有个推荐位」。它照着做出来，往往是——看着像、处处不对：列宽不对、卡片忽高忽矮、顶部那张大图被硬塞进了两列网格里。根因在于：这种文字描述本身是一次有损压缩。
洞察：坐标是跑不掉的事实 但在真机界面里，每个元素的像素坐标是确定的、无损的。ui_summary.txt——从真机界面 dump 出来的元素清单，一行一个控件，带着它的精确边界框。流水线立了一条原则：bounds 是真相，描述是衍生物。布局必须由坐标反推，而不是由文字描述拍板。
做法：把坐标换算成几条「不许违反」的事实 一段程序会自动扫描坐标、做几何换算，生成「布局硬约束」清单。例如：
- 滚动根容器：网格 → 实现时用网格组件
- ⚠️ 检测到 1 张通栏头卡（宽度 ≥ 90% 屏宽）→ 必须含全宽头卡
- ⚠️ 混合宽高比：{0.55 瘦长卡, 0.85 近方卡} → 禁止用单一比例
- 图标位：1 行 6 列，边长 ≈ 168px → 必须用矢量图标
细节二：怎么知道一个 Agent「到底成没成」
三层判定，逐层兜底
- 编排层：CLI 异常退出、撞上轮数上限，直接判失败。
- 产物层：不信 Agent 的「我做完了」，亲自查文件存不存在。
- 协议层：约定文本暗号（如 ANALYZE_RESULT: PASS），再用字符串匹配判定。失败时，Agent 这一轮的全部输出会原样变成下一轮的 prompt 上文。重试不是从头再来，而是带着上次的残局接着打。
从这个实验我们发现了什么？
一、没有「自动判据」的闭环，只是伪闭环 同一个模型，放进「能自动判定成败」的闭环里，长程交付的成功率明显高于「只给它一个编辑器」。判定能力必须一路建到贴近人的真机层。
二、约束越多，模型越爱「哄骗」校验 约束要做减法，不要做加法。删掉模糊的关键词校验，换成可被字面匹配的硬规则后，产出反而更稳。只保留「能被机器明确验证」的约束。
三：工具层能补位，但补不了「地基」 模型的「长程指令遵循稳定性」是地基，工具层只是装修。Qwen3.7-Max 的表现证明了在长上下文、强指令、多轮自洽下不掉链子的重要性。