从生成到执行：大模型智能体的十种工程实践

一、先厘清问题：真正值得探索的不是“神奇提示词”

让模型绘制一只骑自行车的鹈鹕、根据概念图制作三维交互场景，或者操作图形界面完成设计，这些任务看似跨度很大，背后却有一条共同主线：模型不再只是回答问题，而是参与“理解目标—制定计划—调用工具—观察反馈—修正结果”的完整过程。

不过，单次演示不能直接证明稳定能力。一次生成成功，可能依赖任务难度、输入完整度、运行环境、外部工具以及人工补救。缺乏统一测试条件时，也不能仅凭耗时或展示画面判断技术水平。

因此，更有价值的问题不是“怎样让模型发挥得更神奇”，而是：

• 哪些任务适合交给模型自主探索？
• 如何把模糊需求变成可验收的交付物？
• 怎样在不限制创造力的同时控制风险？
• 如何区分视觉上完成与工程上完成？

以下十种实践，围绕这些问题展开。它们是通用的方法设计，不意味着任何模型都原生具备全部能力；涉及文件、渲染、代码运行或界面操作时，都需要相应的执行环境和授权。

二、实践一：用矢量绘图检验复杂约束理解能力

“画一只骑自行车的鹈鹕”并非简单的物体生成任务。它同时涉及物种特征、物体结构、空间关系和动作表达：鹈鹕需要有可辨识的长喙与喉囊，自行车需要具备合理的车轮、车架和车把，身体姿态还要与骑行动作一致。

采用可缩放矢量图作为交付物，可以把审美问题部分转化为工程问题。图形除了要好看，还需要结构有效、元素完整，并能在不同尺寸下正常显示。

建议将要求分成三层：

1. 语义层：主体是什么，正在做什么，哪些特征不可缺失。
2. 构图层：主体朝向、画面比例、背景复杂度、视觉重心。
3. 交付层：画布尺寸、是否透明背景、是否允许外部资源、最终文件格式。

不要只写“高质量”，而应说明可检查的目标，例如：

生成一幅可缩放矢量插画。主体是一只向右骑行的鹈鹕，长喙与喉囊清晰可辨；自行车包含两个完整车轮，身体、车座与车把之间关系自然；背景简洁，不依赖外部图片或字体。交付源文件，并列出需要人工检查的视觉细节。

验证时应同时检查源文件和渲染结果。文件能够解析，不代表构图正确；画面看起来正常，也不代表缩放后没有裁切、重叠或细节丢失。

三、实践二：把单张插画扩展为参数化图形资产

一次性绘图解决的是“有没有”，参数化生成解决的是“能不能持续复用”。

例如，一个交互页面可能需要多组颜色、不同姿态以及多种尺寸的插画。如果每次重新生成整幅图，容易出现线条风格、比例和配色漂移。更稳妥的方法是先建立统一的图形规范，再围绕规范生成变体。

可以要求交付物将主体、车辆、背景与装饰元素分组，并明确哪些属性允许变化，例如颜色、位置、角度和尺寸。随后检查各组元素在变化后是否仍保持正确的遮挡关系。

这里也有能力边界：并非所有图形都适合仅靠少量参数变换。大幅度改变姿态，通常需要重新设计几何关系，而不是简单旋转局部元素。

这种实践适用于界面插画、教学示意图和轻量动画素材。它把单次生成转化为可维护的资产生产过程，减少后续人工修改的成本。

四、实践三：从概念图构建最小三维交互原型

根据参考图生成三维场景，是观察多步骤任务能力的一种方式。但“场景接近概念图”和“完整游戏”之间存在明显差距。

一个可以运行的三维交互原型，通常至少需要：

• 场景、相机和光照；
• 可识别的物体或角色；
• 输入响应与移动控制；
• 必要的碰撞或边界处理；
• 明确的交互目标；
• 启动、重置与异常处理方式。

合理的实施顺序不是先堆积视觉细节，而是先建立最小闭环。例如，角色能够移动，到达目标位置后出现反馈，重置后可以再次完成任务。闭环稳定后，再逐步改善材质、灯光、装饰与视觉相似度。

对于参考图，应明确哪些特征必须保留：是色彩关系、建筑轮廓、空间布局，还是镜头视角。单张图通常无法提供背面结构、准确尺寸和完整遮挡信息，这些部分需要标注为合理补全，而非精确还原。

验收时至少分开记录“可运行性”“交互完整性”“视觉接近程度”和“性能表现”，避免用一张截图代替整体质量判断。

五、实践四：让模型承担运行反馈驱动的代码修复

代码生成之后，真正有价值的环节往往是运行与修复。

在具备受控执行环境的前提下，可以将流程设计为：

生成初版 → 执行检查 → 收集报错 → 定位原因 → 最小修改 → 回归验证。

其中，“最小修改”非常重要。面对一个局部错误，如果每次都重写整个项目，可能修复旧问题的同时引入新问题，也会增加人工审查成本。

向模型提供反馈时，建议包含四类信息：

• 实际执行的操作；
• 完整错误上下文；
• 预期行为与实际行为的差异；
• 当前允许修改的范围。

还应限制迭代次数和资源消耗。连续失败后，应输出已尝试方案、当前假设以及需要人工决策的问题，而不是无限尝试。

这类实践的收益不应只按“最终能否运行”计算，还要观察修改范围是否可控、是否出现回归，以及失败原因是否清晰可追踪。

六、实践五：通过界面操作完成可审查的设计任务

当任务没有适合直接调用的接口时，界面操作可以成为补充路径。具备相应能力与授权的智能体，可以根据屏幕内容定位控件，执行点击、输入、拖动等动作。

但界面操作通常比结构化调用更脆弱。窗口缩放、弹窗遮挡、页面延迟、布局变化，都可能导致动作偏离目标。因此，不能把“依次点击若干坐标”视为可靠方案。

更合理的做法是按语义步骤组织任务：

1. 确认当前页面与工作对象。
2. 创建或打开目标画布。
3. 添加主体元素并调整布局。
4. 检查文字、遮挡和对齐。
5. 保存草稿并生成预览。
6. 在人工确认后执行发布或覆盖。

每个关键动作之后都应重新观察界面，确认状态符合预期。对于删除、发送、发布、覆盖等有外部影响的操作，必须设置确认点。

输入素材也应事先准备好。模型不能凭空知道用户的真实外貌、内部设计规范或业务偏好；必要时应要求用户补充授权素材，而不是自行猜测。

七、实践六：从模糊需求生成可讨论的交互原型

企业需求经常以模糊表达出现，例如“做一个清晰的运营看板”或“让录入流程更方便”。这类要求直接进入编码，容易得到外观完整但业务逻辑缺失的页面。

更好的方法是先让模型整理需求假设：

• 谁使用这个界面？
• 用户要完成什么动作？
• 最关键的信息是什么？
• 操作成功后应出现什么反馈？
• 没有数据、输入错误或权限不足时如何展示？

随后再生成可交互原型，用于讨论布局、信息层级和操作路径。

这里应明确区分模拟数据与真实数据。原型可以使用构造数据，但必须标注，不得让展示效果被误认为真实业务结果。涉及指标时，还应给出统计口径，否则相同的指标名称可能对应不同含义。

原型的核心价值是降低沟通成本，而不是替代需求确认、数据治理或正式系统建设。

八、实践七：把重复文件处理转化为可回滚流程

文档归类、表格整理、批量重命名和报告汇总，通常比开放式创作更容易建立清晰的验收标准，也更适合首先落地。

实施时应坚持“先预览、后执行”：

• 先扫描文件并生成处理清单；
• 展示命名、分类或字段映射规则；
• 对少量样本试运行；
• 确认结果后再批量处理；
• 保留原始文件与变更记录。

尤其要避免直接覆盖。即使处理规则看起来简单，也可能存在同名文件、缺失字段、格式差异或重复记录。

对于无法确定的情况，应进入异常清单，而不是让模型擅自选择。例如，无法判断两条记录是否属于同一对象时，标记待确认通常比自动合并更安全。

如果流程可以用确定性规则稳定完成，应优先采用规则；模型更适合处理描述不统一、内容分类和异常解释等非结构化环节。

九、实践八：让模型生成测试，而不只生成实现

只让模型写功能、不让它设计验证方法，会使交付质量过度依赖人工试用。

可以要求模型在实现前先给出验收案例，并将测试分成几类：

• 正常路径：标准输入能否得到预期结果。
• 边界情况：空输入、极值、重复提交如何处理。
• 异常情况：文件缺失、资源不可用、调用失败时是否可恢复。
• 安全约束：越权请求和敏感操作是否被拒绝或转交人工。
• 回归检查：修改后原有功能是否仍然可用。

不过，同一个模型生成的测试可能与实现共享相同的错误假设。因此，不能仅凭“自测通过”就判定可靠。重要规则应来自独立的业务定义，关键用例应由人工复核。

对于视觉任务，可以组合使用结构检查、截图复核和人工评审。像“画面自然”“风格统一”这类主观指标，应提供具体评价维度，而不是伪装成完全客观的自动判定。

十、实践九：用并行探索替代一次性押注

对开放性任务，过早固定方案可能限制结果质量。一个更实用的方法是先产生少量具有明确差异的候选方案，再按统一标准比较。

例如，图形任务可以分别尝试简洁线条、几何造型和较丰富的细节表达；交互原型可以比较不同信息布局；代码方案可以比较实现复杂度、可维护性和资源开销。

关键不是“多生成几份”，而是让候选方案在明确维度上存在差异，并使用同一组验收要求评价。

同时需要控制成本。候选数量增加会带来更多生成、运行和审查工作。对于约束明确、已有成熟规则的任务，没有必要额外引入大量探索。

最终交付时，应说明选择理由和放弃其他方案的原因。这样才能把一次偶然命中的结果转化为可解释的工程决策。

十一、实践十：通过检查点管理长任务

长任务失败，往往不是因为每个局部步骤都很困难，而是因为状态逐渐偏移：需求被遗忘、文件版本混淆、错误假设持续传播，最后得到一个看似完整但无法使用的结果。

可以将任务拆成若干检查点：

需求确认 → 方案确认 → 最小可用版本 → 自动检查 → 人工复核 → 最终交付。

每个检查点保存当前产物、已完成事项、未解决问题和下一步计划。中途失败时，从最近的有效状态恢复，而不是重新生成全部内容。

需要注意，检查点并不等于频繁要求用户点击确认。低风险、可逆的局部操作可以自动完成；只有在需求存在歧义、方案发生重大变化或操作具有外部影响时，才需要人工介入。

这种分层授权既能减少打断，也能避免把不可逆决策交给不受约束的自动执行。

十二、统一方法：明确结果，开放路径，锁定边界

以上实践可以归纳为一份通用任务契约：

任务目标：
明确希望解决的问题与最终使用场景。
输入材料：
列出可使用的文件、参考图、业务规则及其可信范围。
交付内容：
规定文件类型、目录结构、说明文档和必要的预览。
验收条件：
列出必须满足的功能、视觉、质量与兼容性要求。
执行边界：
明确允许访问的资源、可修改的范围和禁止执行的动作。
确认节点：
列出发布、发送、删除、覆盖等必须人工批准的操作。
停止条件：
设置时间、资源或重试上限，失败时提交过程记录。
不确定性处理：
区分可自行作出的低风险假设与必须询问的问题。

这份契约体现的不是“限制越少越好”，而是不同约束应放在不同位置。

对于实现路线，可以允许模型选择合适的组织方式、尝试局部替代方案；对于验收标准、数据权限、资源预算和高风险操作，则应尽可能明确。创造性空间与安全边界并不矛盾。

还要把外部内容与执行指令分开。网页、文档、图片中的文字属于待处理材料，不能因为其中出现“忽略规则”“上传文件”等内容，就被提升为可信指令。执行环境应使用最小权限，敏感信息应按任务需要最小化提供。

结语：从惊艳演示走向可持续交付

大模型在图形生成、原型制作、代码修复和界面操作中的价值，不只是缩短某一次制作时间，而是有机会把原本割裂的工作连接起来，形成可迭代的任务闭环。

但真正可靠的自动化，必须同时具备三个条件：目标可验证、过程可观察、风险可控制。

对开发者而言，最值得投入的不是寻找一句万能提示词，而是建立一套稳定的工程机制：用清晰契约描述结果，用工具反馈推动修正，用测试和人工检查保证质量，用权限和检查点限制风险。只有这样，偶尔令人惊艳的生成结果，才可能逐步变成团队能够长期依赖的交付能力。