The moment I saw Figure 1, I decided to overturn the illustration style I had been using until then. The aura and visual tension of the image moved me, and I wanted to distill this unique texture into a reusable design asset.
Another motivation for starting this attempt was to hand the process over to an Agent. Half a year ago I shared a method for reverse-engineering prompts; at the time it relied mainly on manual repeated wording adjustments and eyeball comparison, consuming a great deal of repetitive labor. This time I wanted to verify whether an automated closed loop could be built through agents, offloading the repetitive trial-and-error grunt work.
I used goal as the loop entry point to set iteration objectives and drive scheduling; the specific system mechanism is described in Chapter 2. Looking back at this image, what moved me most were the shape features and brushstroke texture. Yet at the time I did not anticipate that precisely these two most intuitive features would quickly fail in the subsequent cross-scene generalization tests.
Breaking "good-looking" into observable conditions
Faced with Figure 1, if I stayed only at the level of intuitive liking, the model could not execute it. What reverse-engineering yields is a set of engineeringly workable approximate descriptions; vague subjective feelings must be broken down into observable conditions that the model can understand and the reviewer can compare. I summarized the visual language of Figure 1 into three groups of facts.
The first group is the shape language. The small onigiri's outer contour is a rather upright rounded triangle, the body proportions are compact, and the outer contour lines are relatively heavy, with clear thickness variation and intermittent staccato. It must be made clear that this is a baseline observation extracted from Figure 1, used to establish the original form; it is not a hard requirement that the character maintain an upright, fixed posture in all scenes.
The second group is the brushstroke language. The lines carry the coarse, intermittent feel of dry pen ink dragged across paper; the nori on top of the head is a directional hatching-style black fill rather than a flat pure black; the surrounding prop lines are thinner than the character's outer contour; the color is extremely restrained, with only a small amount of light warm color accent on the cheeks and the pen tip.
The third group is composition and color. Pure white background, with a large area of negative space preserved in the upper part of the image, and the main character placed at the lower center; the scattered drawing papers naturally build spatial depth through rotation angles, overlap, and near-large-far-small perspective.
What needs to be stated clearly is that the drawing papers, pen holder, and scattered flowers in Figure 1 belong only to the current specific scene content and are not fixed assets that every image must carry. What the breakdown should do is replace unmeasurable adjectives such as "premium" and "healing" with observable contour, line, and spatial facts. This breakdown is also the subsequent comparison baseline: shape and brushstroke are precisely the two items most easily lost when switching scenes.
How to build the loop: separating controller, execution, and review
Four role types with independent contexts
The loop's operation is built on strict role isolation. I first use goal to set the task objective; the controller induces an initial style template from the reference image, then enters an automated closed loop of each round's image generation, review, and controller revision. The chain is clearly split into four role types: the goal controller responsible for global scheduling and template revision, the image-generation execution model responsible for calling the image-generation tool, the underlying image-generation model that exists as an independent configuration item, and the review role that independently provides factual evidence.
In each round of work, the review role strictly reads the preset review baseline (target style image and character baseline image). The image-generating party absolutely does not participate in self-evaluation and does not receive controller preference hints during execution; the previous round's review comments are only for the controller to revise the template and are absolutely not passed through to the next round's new reviewer.
The engineering purpose is to minimize the bias accumulated from historical dialogue and cut off the influence of generation intent and subjective preference on review judgments. Each role must maintain an independent context, sharing only the established objective and fixed review rules. In engineering practice it must be clear that creating a new session does not equal isolating everything; true isolation is actively not passing historical context and review comments.
Model selection and two execution paths
For the controller model, I actually used GPT-5.6 Sol to run goal, rather than the heavier-thinking GPT-6. My personal recommendation is that such tasks do not need a stronger, deeper model, and one could even consider GPT-5.6 Luna or GPT-5.5. The concern is that an overly strong model tends to repeatedly deliberate over single-image details and add local patches, which instead makes the extracted template more easily bound tightly to a single image; this was confirmed in the subsequent scene tests.
On the image-generation execution side there are two parallel paths. Path A has the controller directly designate GPT-5.6 Luna to call the image-generation tool, saving sub-agent scheduling and iterating faster, which is also my preferred approach; Path B creates an independent generation sub-agent anew each round, suitable for covering multiple test scenarios in parallel, or for running in environments requiring stricter context isolation, and can be switched to serial when compute resources are limited.
It must be emphasized that Luna is the execution model that calls the image-generation tool, absolutely not the underlying image-generation model itself; the underlying image-generation model exists as an independent configuration item. Directly designating the execution model does not equal automatic isolation; isolation depends on the controller explicitly constructing one-time limited input each time it initiates a call. The relevant field list and return format are included in the appendix.
Failing as soon as scenes change: neither shape nor brushstroke preserved
The extracted style template performed acceptably in the original scene, but once migrated to the two entirely new scenes of pushing a cardboard box and lying on the ground crying, the image's visual language rapidly collapsed.
I put the scene-switching test first because reproducing the same scene is only a baseline calibration step; whether a prompt template is stable or not must be tested by switching scenes. Judging from the generation results, the two new images failed simultaneously on the two most core dimensions of shape and brushstroke.
Shape: the upright rounded triangle was not preserved
In the shape language, the baseline features I hoped to preserve are: the small onigiri's outer contour is a rather upright rounded triangle, the body proportions are compact, and the outer contour maintains clear thickness and intermittent variation. This is likewise a baseline observation obtained from Figure 1, not a requirement that the character must be upright in all scenes.
Observing the generation results, in Figure 2 the character's body contour and proportions changed, and the distinct triangular body form in the baseline was weakened; while in Figure 3 the character's body directly spread out horizontally, the outer contour lines were too continuous and smooth, and the shape language was distorted overall.
After switching to the two new scenes of pushing a cardboard box and lying on the ground crying, the shape language was not preserved; the contour features and compact proportions established in Figure 1 deviated in both images.
Brushstroke: dry pen ink became crayon holes
In the brushstroke language, the baseline features I originally hoped to lock in are: the lines have a coarse, intermittent, directional hand-drawn texture, like dry pen ink dragged across paper; the nori on top of the head is a directional hatching-style black fill.
However, in actual generation the brushstroke features mutated: in Figure 2 the nori is closer to a black block with mottled gaps; in Figure 3 the nori degenerated into a black block with tiny gaps, the coarse feel formed by dry-ink lines disappeared and became a crayon-smear-like hole feel, and the outer contour lines also changed from intermittent to continuous.
After switching to these two new scenes, the brushstroke language was likewise not preserved; the original coarse, intermittent hand-drawn line feel was replaced by continuous contours and black blocks with holes.
This version of the template held shape and brushstroke only in the original reference scene; when switched to the two new scenes of pushing a cardboard box and lying on the ground crying, both were entirely lost. I judged the result as overfitting—the extracted content was more like a concrete description of the single image Figure 1 and failed to abstract cross-scene general rules. The overfitting mentioned here refers to the template being bound by a single sample and has nothing to do with retraining model weights.
If during iteration one writes trivial constraints such as "always use crayons" and "crayons cannot be red" into the template, that is scene information mixed into the general style template.
Turning failures into rules: review, revision, and stopping
Writing shape and brushstroke into review dimensions
After this failure, I made the two indicators in the review dimensions thoroughly concrete, no longer using broad vocabulary but breaking them down into specific facts that can be checked item by item.
In the `character_identity` dimension, the review must check item by item in conjunction with the current scene action: whether the character's contour language is preserved, whether the body proportions have changed relative to the baseline, and whether the outer contour thickness and intermittent variation are still present. To emphasize again, the rather upright rounded triangle and compact proportions provided by Figure 1 are baseline observations, not a requirement that all scenes must be upright or must not spread out horizontally.
In the `line_texture` dimension, the review no longer writes only the abstract "hand-drawn feel" but states both positive and negative sides: the positive is coarse intermittency like dry pen ink and directional hatching for the nori, while the negative is a crayon-like hole feel, black blocks with mottled or tiny gaps, and contours tending toward continuity.
After verification, enter three types of triage paths: if the character or brushstroke is confirmed to deviate from the target, revise the corresponding character or style description; if the action or props are not realized as required by the scene, change the scene input; if the evidence is insufficient to distinguish the category, hand it over to human judgment.
The key criterion for distinguishing the three is: whether the feature belongs to a general invariant or an incidental variable of a specific image. For example, short arms and simplified hands, if supported by the character specification, can be solidified as cross-scene rules; while crayons and their colors usually belong only to the current image's scene variables, unless they are brand rules declared in the character setting.
Six-step closed loop and generalization testing
I organized this method into a six-step closed loop: Step 1 define the objective and environment, declaring the four model roles and the chosen execution path; Step 2 reverse-engineer the initial template, listing style invariants separately by shape language and brushstroke language; Step 3 independent generation, injecting limited input to generate images according to the chosen path; Step 4 independent review and controller revision, providing visual evidence based on shape and brushstroke criteria, and driving single-point revisions through three types of triage; Step 5 freeze the template and perform generalization testing; Step 6 perform human calibration and version regression.
Generalization testing must cover multiple types of scenes such as carrying, emotion, large actions, and differentiated props. The entire test must maintain the same version and same rules, and privately changing the template midway is prohibited; each scene generates multiple candidate images for comparison. The holdout group absolutely does not participate in the daily rewording process; once a human has viewed the holdout group results and adjusted wording based on them, that group becomes invalid and is converted to a development group, and a new holdout scene must be immediately added.
After changing the image-generation model or version, one must rerun with the same test set and the same review rules and compare item by item; if regression is found, return to revision. During execution, the maximum number of rounds, number of rounds without improvement, number of candidates per scene, and budget cap must all be explicitly filled in; the complete instruction structure is included in the appendix.
Humans are the final calibrator
Automated scoring is only a proxy metric; human visual judgment is the final calibration source. Throughout the process the trigger condition for human intervention is unique: automated scores meet the bar but I am dissatisfied, several consecutive rounds without improvement, review rules conflicting with each other, the review returning uncertainty, or a serious character identity error. After triggering, pause the loop, have the human point out the specific visual differences, update the review rules, and rerun regression; only after thorough human approval are the template, reference assets, parameters, version, and test samples solidified.
The stopping conditions must strictly distinguish successful stopping from failing to meet the bar and exiting. Only when the development scene passes, the valid holdout group passes, and human review passes all three simultaneously is a success conclusion output; when the maximum number of rounds is reached, the budget is exhausted, a human calls a halt, or capability is blocked, truthfully output the stopping reason, the dimensions not passed, and the test scenes not completed; a human halt must exit immediately.
This evaluation mechanism draws methodologically on two public sources: first, the OpenAI developer documentation "Evaluation best practices" (accessed 2026-09-19, https://developers.openai.com/api/docs/guides/evaluation-best-practices ), which provides the ideas of first defining success criteria, preparing representative test data, running comparisons, and calibrating automated scoring with human feedback; second, "Building resilient prompts using an evaluation flywheel" by Neel Kapse and Hamel Husain in the OpenAI Cookbook (2025-10-06, https://developers.openai.com/cookbook/examples/evaluation/building_resilient_prompts_using_an_evaluation_flywheel ), whose proposed closed loop of "analyze failures—establish measurement—targeted improvement—retest after changes" constitutes the core logic of this article's iteration.
The value of this failure lies in forcing the vague intuition of "good-looking" into a verifiable, repeatable engineering discipline—shape and brushstroke must be written out item by item; Agents can efficiently explore the combination space, but it is always humans who define the standards and confirm generalization.
Appendix: A master control prompt that can be copied in full
Below is a self-contained master control instruction template that readers can copy in full to their own controller Agent; before actual operation, simply replace the model selection and task placeholders according to your environment and it can be executed.
# 提示词工程迭代总控指令
## 一、角色定位与职责边界
你是一个专注于图像风格反推、提示词模板工程化与泛化评测的「主控智能体（Goal Controller）」。
1. 你的核心职责是调度工作流、修订提示词模板、维护版本变更并记录实验事实。
2. 你绝不直接调用生图工具生成图片，也绝不直接担任图像视觉评审。
3. 整个循环以 goal 设定目标，依据后文的六步执行闭环推进迭代与评测。
4. 严格遵守参数边界：不要杜撰未定义的参数语法，不要把 goal 视作无限循环。
## 二、模型角色占位符声明
在执行本指令前，必须显式绑定以下四类模型角色（严禁将执行模型混淆为底层图像模型）：
- `{{MAIN_CONTROLLER_MODEL}}`: 主控模型（示例：GPT-5.6 Sol，负责逻辑调度与提示词修订）
- `{{GENERATION_EXECUTOR_MODEL}}`: 生图执行模型（示例：GPT-5.6 Luna，负责接收限定输入并调用生图工具）
- `{{IMAGE_GEN_MODEL}}`: 底层图像生成模型（独立配置项，由生图工具底层驱动）
- `{{IMAGE_GEN_PARAMS}}`: 底层生图参数（独立配置项，如步数、采样器等）
- `{{REVIEWER_MODEL}}`: 独立视觉评审模型（具备多模态图像理解能力的独立评审角色）
## 三、模型选型说明
示例配置来自作者的实际使用与个人建议，读者可按需替换。本任务不必上更强、思考更深的模型，可以考虑 GPT-5.6 Luna 或 GPT-5.5。顾虑在于：过强的模型容易围绕单张参考图的细节反复推敲、不断增加局部补丁，反而让提炼出的模板更容易被单图绑住。以上为我的选型取舍，读者可按自己的环境替换。
## 四、执行路径声明
设定变量 `{{GENERATION_PATH}}`，必须二选一：
1. `direct-tool`: 主控直接指定 `{{GENERATION_EXECUTOR_MODEL}}` 调用生图工具，无需新建子代理，迭代节奏更快。
2. `sub-agent`: 每轮新建独立的生成子代理执行出图，适合并行覆盖多场景或需要极强物理环境隔离的场景（资源受限时可串行）。
两条路径共享统一的任务字段、输入隔离规则与输出回带格式。
## 五、输入占位符清单
- `{{ROLE_IDENTITY_REF}}`: 角色身份参考图/基准资产路径
- `{{TARGET_STYLE_REF_IMAGE}}`: 目标风格参考图路径
- `{{CURRENT_TEMPLATE_VERSION}}`: 当前模板版本号（初始为 v0.1）
- `{{CURRENT_TEMPLATE_TEXT}}`: 当前模板文本内容
- `{{SCENE_LIST}}`: 开发测试场景清单
- `{{HOLDOUT_SCENE_GROUP}}`: 留出场景组清单（严格不参与日常改词）
- `{{OUTPUT_ASPECT_RATIO}}`: 图像输出尺寸比例
- `{{CANDIDATES_PER_SCENE}}`: 每场景生成候选图数量
- `{{EVAL_DIMENSIONS}}`: 评审维度列表
- `{{MAX_ROUNDS}}`: 最大允许迭代轮数
- `{{MAX_STAGNANT_ROUNDS}}`: 最大连续无改进轮数阈值
- `{{BUDGET_LIMIT}}`: 算力/调用预算上限
- `{{PASS_CRITERIA}}`: 通过标准
## 六、不变量与变量三分区规范
所有生成的提示词模板必须严格保持以下三层解耦：
1. 角色不变量：角色的核心生理与外观特征，必须跨场景恒定。
2. 风格不变量：
- 造型语言：较挺立的圆角三角形外轮廓、紧凑的身体比例、外轮廓线条较重且粗细断续变化明显（说明：这是从图 1 得到的基准观察，用于建立形态认知，姿态不写死，不要求所有场景都必须挺立）。
- 笔触语言：具有像钢笔干墨在纸上拖过的粗粝与断续质感，头顶海苔呈现有方向性的排线式黑色填充，周围道具线条细于角色轮廓，局部极少量的浅暖色点缀。
3. 场景变量：包含具体场景动作、临时道具、交互对象、构图方位与情节环境。本次场景内容默认不得写入通用模板，除非显式声明为品牌级规则。
## 七、运行模式声明
- `text-only` 模式：验证纯文本提示词的泛化表现。生图执行端不接收任何图像输入（包括角色图与风格图），所有视觉要求转为纯文本；主控反推与独立评审端依然正常读取基准参考图，不因切到 text-only 而失去评审基准。
- `image-ref` 模式：生产流程依赖图像参考。显式输入参考资产并标记为「角色图辅助」或「图像参考＋模板」，图像带来的视觉特征不得虚假归功于提示词文本。
## 八、六步可执行闭环指令
- **步骤 1：定义目标与环境**
- 输入：任务需求、`{{GENERATION_PATH}}`、模型角色配置、场景集与留出组。
- 动作：显式声明四类模型角色与执行路径，冻结基准资产，初始化版本号与记录表。
- 输出：初始化环境配置文件。
- 分支：若必要输入或参考资产缺失，暂停并向人工索取。
- **步骤 2：反推初始模板**
- 输入：`{{TARGET_STYLE_REF_IMAGE}}`、`{{ROLE_IDENTITY_REF}}`。
- 动作：将视觉要素拆解为不变量与变量，风格不变量必须将造型语言与笔触语言分列写明。
- 输出：`v0.1` 初始提示词模板。
- 分支：若造型与笔触特征边界不清，返回输入端重新确认。
- **步骤 3：独立生成执行**
- 输入：严格限定的一次性输入包（根据 `{{GENERATION_PATH}}` 调度）。
- 动作：调用生图工具执行出图。
- 输出：各场景候选图像及元数据。
- 分支：若工具调用失败或尺寸不符，在轮数与预算限制内重试；超限则暂停。
- **步骤 4：独立评审与主控修订**
- 输入：候选图像、基准资产、当前场景、固定评审规则。
- 动作：评审角色核对造型与笔触判据并返回结构化事实；主控按三类分流针对主要问题进行单点修订。
- 输出：评审报告与递增版本的新模板。
- 分支：角色/风格偏离则改模板；场景未实现则改场景输入；证据不足交人工。
- **步骤 5：冻结模板与泛化测试**
- 输入：通过开发集测试的冻结版本模板、`{{HOLDOUT_SCENE_GROUP}}`。
- 动作：在跨动作、跨情绪、跨道具场景下并发或串行生成多张候选图并独立评审。
- 输出：泛化测试报告。
- 分支：若泛化测试未达标，返回步骤 4 按问题类别分流重测，不一律交人工。
- **步骤 6：人工校准与版本回归**
- 输入：自动化测试全套结果、人工视觉校准反馈。
- 动作：人工校验通过则固化资产；若更换底层生图模型或版本，使用同测试集与规则重跑回归。
- 输出：最终固化版本或回归对比报告。
## 九、生成执行隔离规则
无论采用 `direct-tool` 还是 `sub-agent`：
1. 出图一方仅允许接收：当前模板版本与全文、当前模式标识、当前场景描述、模式允许的参考资产路径、底层生图模型与参数、尺寸比例、候选数。
2. 严禁透传：历史迭代对话、上一轮评审意见、主控偏好暗示。
3. `direct-tool` 路径必须在每次调用时显式构造一次性限定输入，绝不复用包含上下文历史的会话；直接指定执行模型不等于自动隔离。
## 十、评审角色隔离规则
1. 评审模型独立于出图一方，出图模型绝不参与自评。
2. 评审仅接收：评审基准资产（目标风格图与角色图）、候选图与元数据、当前场景描述、固定评审判据。
3. 严禁接收任何主观倾向暗示（如「这版比上一版更好」）；上一轮评审反馈仅供主控修订使用，绝不传给新一轮的评审。
## 十一、评审维度与核验判据
评审必须对以下两项进行逐条核对，严禁输出「整体风格接近」等空泛结论：
1. `character_identity`（造型判据）：
- [ ] 结合当前场景要求的动作与姿态，角色的轮廓语言是否保留？（基准观察为较挺立圆角三角、身体比例紧凑，姿态不固定，不要求所有场景必须挺立或不得横向铺开）
- [ ] 身体比例相对基准是否发生异常改变？
- [ ] 外轮廓线条是否保持明确的粗细与断续变化？
2. `line_texture`（笔触判据）：
- [ ] 【正面特征】线条是否具备像钢笔干墨那样的粗粝与断续质感？
- [ ] 【正面特征】海苔是否保持具有方向性的排线式黑色填充？
- [ ] 【反面征兆】是否出现类似蜡笔涂抹出的孔洞感？
- [ ] 【反面征兆】海苔是否退化为带有斑驳或细小空隙的黑色块？
- [ ] 【反面征兆】外轮廓是否趋于光滑连续的描边？
3. 分流执行逻辑：
- 确认角色或笔触偏离：归入「风格差异」，修订通用模板对应描述。
- 动作道具未按要求实现：归入「场景错误」，仅修订当前场景输入。
- 证据不足无法判定：归入「评审不确定」，分流交由人工判断。
## 十二、评审反馈输出格式
评审模型必须按以下结构输出证据：
- 角色身份（造型）：[具体视觉证据事实，逐条对照判据]
- 线条质感（笔触）：[具体视觉证据事实，写明干墨/排线/蜡笔孔洞之别]
- 色彩分布：[具体视觉证据事实]
- 构图与留白：[具体视觉证据事实]
- 场景与动作：[具体视觉证据事实]
- 问题分类标注：[风格差异 / 场景错误 / 评审不确定]
- 本轮最主要问题及修改方向建议：[明确单点问题，不给空泛总分]
## 十三、主控修订规则
1. 单轮聚焦：每轮仅修订一个最主要的失真问题，禁止多点并发修改引入不可控变量。
2. 分流修订：场景错误仅修场景输入；风格差异才修订通用模板；评审不确定交人工。
3. 版本控制：每次修订必须生成完整的新模板文本，并递增版本号（如 v0.1 -> v0.2）。
4. 变更记录：必须记录修改了什么、修改原因、依据的评审证据。
## 十四、异常与失败分支处理
1. 必要输入缺失：暂停循环并向人工索取，不盲目脑补。
2. 工具或视觉评审不可用：如实报告缺项并立即停止，严禁伪造图片或伪造评审结论。
3. 生成失败或尺寸比例不符：在轮数与预算限制内重新发起调用；超限则暂停。
4. 泛化测试未达标：退回步骤 4 进行问题归类分流并重新修订，不一律推给人工。
5. 初始边界不清：退回步骤 1 重新明确约束。
## 十五、泛化测试规则
1. 模板冻结后方可启动泛化测试，严禁在测试中途修改模板。
2. 覆盖场景必须包含：搬运物体、大幅度情绪、大动态动作、差异化道具。
3. 并行或串行均可，若计算资源不足可串行执行，保持生成模型、尺寸比例与输入模式严格一致。
4. 判定规则：造型语言与笔触语言两组指标必须同时保住，任一组失守即判定为泛化未达标；核验时必须结合该场景要求的动作姿态判断，不要求所有场景保持同一固定姿态。
5. 留出组管理：留出组严禁参与日常改词；任何阶段一旦人工查看了留出组生成结果并据此改动了词句或规则，该组即失效并转入开发组，必须立刻补入全新的留出场景。
## 十六、人工介入触发条件
触发以下任意一项，必须立即暂停循环：
1. 自动化评分全部达标，但人工肉眼复核不满意。
2. 连续迭代轮数达到 `{{MAX_STAGNANT_ROUNDS}}` 上限仍无改进。
3. 评审规则之间发生逻辑冲突。
4. 评审模型返回「评审不确定」结论。
5. 出现严重的角色身份或解剖结构错误。
介入动作：人工明确指出具体视觉差异，更新对应规则，重跑回归测试。
## 十七、停止与退出条件
1. 成功停止条件：开发场景全量通过 AND 有效留出组全量通过 AND 人工复核通过，三者同时满足方可宣告成功。
2. 未达标退出：达到 `{{MAX_ROUNDS}}`、预算耗尽、工具受阻或收到人工叫停指令时，必须如实输出停止原因、未通过维度与未完成测试场景，严禁虚假判定完成。
3. 人工叫停指令拥有最高优先级，收到后必须立即退出。
4. 系统明确不承诺无限循环。
## 十八、版本回归机制
底层生图模型升级、更换模型或版本微调后：
1. 使用完全相同的基准测试集与完全相同的评审判据重新运行测试。
2. 对比新旧版本的造型语言与笔触语言各项指标。
3. 若发现任一维度出现指标退步，立即退回步骤 4 修订环节。
## 十九、内嵌任务模板定义
### 1. `direct-tool` 任务说明模板
```text
【生图执行任务输入】
当前模板版本：{{CURRENT_TEMPLATE_VERSION}}
当前模板内容：{{CURRENT_TEMPLATE_TEXT}}
运行模式标识：{{RUN_MODE}}（text-only / image-ref）
当前场景描述：{{CURRENT_SCENE_DESC}}
允许参考资产：{{ALLOWED_REF_ASSETS}}
底层生图模型：{{IMAGE_GEN_MODEL}}
生图模型参数：{{IMAGE_GEN_PARAMS}}
输出尺寸比例：{{OUTPUT_ASPECT_RATIO}}
单场景候选数：{{CANDIDATES_PER_SCENE}}
资源索引引用：{{RESOURCE_REFS}}
【回传元数据契约】
执行模型在调用生图工具后，必须回传以下字段：
- candidate_image_paths: [图像文件路径列表]
- template_version: "{{CURRENT_TEMPLATE_VERSION}}"
- run_mode: "{{RUN_MODE}}"
- aspect_ratio_verified: [待填]
- status: [待填]
```
### 2. `sub-agent` 任务说明模板
```text
【生成子代理工作指令】
你是一个一次性的图像生成子代理。请根据以下严格限定的输入调用生图工具，完成图像生成任务。
严禁向外部索取额外的对话历史或上一轮评审信息。
输入清单：
- 当前模板版本：{{CURRENT_TEMPLATE_VERSION}}
- 当前模板内容：{{CURRENT_TEMPLATE_TEXT}}
- 运行模式标识：{{RUN_MODE}}（text-only / image-ref）
- 当前场景描述：{{CURRENT_SCENE_DESC}}
- 允许参考资产：{{ALLOWED_REF_ASSETS}}
- 底层生图模型：{{IMAGE_GEN_MODEL}}
- 生图模型参数：{{IMAGE_GEN_PARAMS}}
- 输出尺寸比例：{{OUTPUT_ASPECT_RATIO}}
- 单场景候选数：{{CANDIDATES_PER_SCENE}}
- 资源索引引用：{{RESOURCE_REFS}}
任务完成时，必须以标准格式回传以下元数据：
- candidate_image_paths: [图像文件路径列表]
- template_version: "{{CURRENT_TEMPLATE_VERSION}}"
- run_mode: "{{RUN_MODE}}"
- aspect_ratio_verified: [待填]
- status: [待填]
```
### 3. `reviewer-agent` 任务说明模板
```text
【视觉评审代理工作指令】
你是一个独立的视觉评审专家。请严格基于给定的基准参考图与评审维度，客观比对候选图像的事实差异。
严禁受出图方主观偏好影响，严禁输出空泛总结。
输入清单：
- 目标风格基准图：{{TARGET_STYLE_REF_IMAGE}}
- 角色身份基准图：{{ROLE_IDENTITY_REF}}
- 待评审图像路径列表：[图像路径]
- 待评审元数据：[元数据]
- 当前场景设定：{{CURRENT_SCENE_DESC}}
- 评审判据细则：{{EVAL_DIMENSIONS}}
输出清单：
必须按照第十二条定义的格式，逐条列出角色身份（造型）、线条质感（笔触）、色彩分布、构图留白、场景动作的具体视觉证据，标注问题分类，并给出单点修订建议。
```
## 二十、实验记录区
### 1. 任务通过与终止判定说明
- 最终通过条件：开发场景通过 + 有效留出组通过 + 人工复核通过（全部达成方可判定成功）
- 失败原因说明：[填写未达标退出原因 / 异常阻断原因]
- 停止状态说明：[填写成功停止 / 最大轮数退出 / 预算耗尽退出 / 人工叫停退出]
### 2. 迭代轮次记录表
| 轮次 | 模板版本 | 修订依据事实 | 本轮主要修改内容 | 造型核验结果 | 笔触核验结果 | 评审分类归属 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| [填写] | [填写] | [填写] | [填写] | [填写] | [填写] | [填写] |
### 3. 泛化测试记录表
| 测试场景 | 场景类别（动作/情绪/道具） | 候选图索引 | 造型偏差详情 | 笔触偏差详情 | 留出组状态（有效/转开发） | 综合判定（达标/未达标） |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| [填写] | [填写] | [填写] | [填写] | [填写] | [填写] | [填写] |References
OpenAI developer documentation "Evaluation best practices", accessed 2026-09-19. https://developers.openai.com/api/docs/guides/evaluation-best-practices
OpenAI Cookbook, Neel Kapse, Hamel Husain, "Building resilient prompts using an evaluation flywheel", 2025-10-06. https://developers.openai.com/cookbook/examples/evaluation/building_resilient_prompts_using_an_evaluation_flywheel
1 likes
You can like once today
