做 DAMA 这个电商生图智能体时，我先把商品理解、展示策略和质检闭环拆开了

1. 这个项目一开始最卡我的，是生成前到底要不要先理解任务

刚起这个项目时，我脑子里最先冒出来的做法其实很直接：

• 用户上传商品图
• 输入一句需求
• 模型出图
• 不满意再重试

这条链当然能跑。

但电商场景里，光能跑远远不够。因为用户要的往往不是一张泛化的好看图，而是一张有业务目的的图。

比如同样是一件衣服：

• 有时候用户要的是卖点图，重点是主体清楚、卖点明确、信息组织稳
• 有时候用户要的是种草图，重点是代入感、场景感、上身状态自然
• 有时候用户只说“做高级一点”，里面到底偏详情页、偏海报还是偏社媒，其实都不一样

所以我后面慢慢收敛下来的想法是，不能把这个项目理解成“给生图模型包一层网页”。

它更像是：先判断当前任务到底在生成什么，再决定后面那条生图链怎么走。

2. 商品理解我先拆成了两层：商品事实卡和电商解读卡

我这次最先做的一件事，就是不让模型一上来直接写营销话术。

因为商品图识别这一步如果一开始就营销化，后面很容易越走越飘。

比如面料看不清、结构看不清、五金看不清的时候，模型很容易脑补出很多“高级感”“功能性”“工艺亮点”。这些词一旦提前写进 prompt，后面生成图就很容易跟原商品越拉越远。

所以我把前置理解拆成了两层：

1）商品事实卡

先尽量只拿可见事实，比如：

• 类目
• 颜色
• 版型轮廓
• 口袋、领型、下摆这些结构信息
• 纹理、走线、五金这些必须保留的细节

看不清的地方就老实写“未能确认”。

2）电商解读卡

有了事实以后，再往上补一层业务表达：

• 这件商品适合强调什么卖点
• 视觉上更该突出哪里
• 更像通勤、户外、桌面还是生活方式场景
• 哪些点不要硬强调

这样拆完以后，我心里会更踏实一点。

因为后面的所有推理，至少是站在“商品是什么”这个底上往上长，而不是一开始就让营销语言把事实盖过去。

3. 同一张商品图，卖点图和种草图我现在当成两种任务来处理

这个项目里我目前先收成了两个 feature：

• selling_point_image
• seeding_image

这么拆对我帮助很大。

因为以前很容易把“电商图”当成一个大桶，最后所有请求都走到一套逻辑里。这样做短期省事，后面会越来越别扭。

卖点图和种草图的差别，不只是 prompt 风格不同，后面的规则其实也会跟着变：

• 卖点图默认是商品主导，最好能有清晰营销信号
• 种草图更强调生活方式感、社媒感、真实分享感
• 穿戴类商品做种草图时，很多情况下应该优先上身或佩戴展示
• 卖点图不一定需要人物，种草图里人物有时反而是必要的

把它显式拆开以后，后面的 brief、策略选择、prompt 结构、critic 判断标准，才有地方分别落。

这个改动对我来说挺关键，因为它把“用户说一句话，系统自己猜着往下跑”这件事，拉回到了一个更清楚的任务框架里。

4. 我中间又补了一层 PresentationPlan，专门决定“这件商品该怎么展示”

做到这里以后，我发现还有一个问题：

即便商品识别对了、任务类型也分对了，画面仍然可能很别扭。

最常见的情况就是场景很泛。

比如功能型外套，最后给它放到一个没什么意义的硬背景前；又或者种草图想做生活方式感，结果出来的还是海报味很重的商业图。

所以我后来又加了一层 PresentationPlan，专门在正式生图前先回答几个问题：

• 当前更适合 product_only、lifestyle_product 还是 human_tryon
• 应该落在什么 usage scene 里
• 当前任务允许不允许人物，需不需要人物
• 哪些场景是明确不合理的

这一层补上去以后，后面的 scene 生成就不是乱飘了，而是围着这份展示策略往下收。

我现在越来越觉得，很多生图项目的问题，往往不是 prompt 写得不够长，而是生成之前根本没把“为什么要这样展示”想清楚。

5. 流程越来越长以后，我把整条链迁到了 LangGraph

前面步骤一多，继续手写串行逻辑就开始乱了。

尤其是这类链路里还有：

• 中间状态
• 多轮重试
• 最优结果选择
• critique 反馈回流
• feature 切换时的状态重置

这些东西一多，纯靠 if else 往前顶，后面很难看清楚整个任务现在到底走到哪一步。

所以我后面把主链收成了一条 graph，大致顺序是：

1. recognize_product
2. build_interpretation
3. build_brief
4. build_presentation_plan
5. create_scene
6. select_strategy
7. build_prompt_package
8. generate_image
9. critique_image
10. update_attempt_record
11. 重试或者 finalize

这样做最直观的好处，就是状态终于有地方放了。

我现在会把 product、brief、presentation plan、prompt package、latest critique 这些东西都当成中间结果来保留，而不是一次函数调用里跑完就没了。

对智能体类项目来说，这种“中间结果可见”比我一开始预想得更重要。

6. Prompt 我也不再一段写完了，而是拆成 fidelity、composition、final 三层

这个项目里，服装和商品一致性是很硬的要求。

如果 prompt 只有一段，通常很容易出现一种情况：

前半段在强调保真，后半段又在强调氛围、卖点、人物、场景，最后这些要求全堆在一起，模型到底优先听哪边就很不稳定。

所以我后面把 prompt package 拆成了三层：

1）fidelity_prompt

专门锁商品身份：

• 参考图就是商品真值
• 颜色、纹理、版型、走线、五金这些细节要尽量保持
• 不要擅自新增结构
• 不要把原商品改成另一件“像它的商品”

2）composition_prompt

专门负责图型表达：

• 当前是卖点图还是种草图
• 该不该有人
• 构图该怎么偏
• 场景和视觉重点怎么组织

3）final_prompt

最后再把前两层和本轮反馈整合起来。

我现在比较认可这种拆法。

因为它至少把“商品保真”和“画面表达”这两个经常打架的目标分开了，后面改也更容易知道该改哪一层。

7. 参考图这条链，我这次也比较在意“系统到底有没有真的走到 image edit”

这个坑其实很现实。

很多时候大家会说“模型支持图生图”“支持参考图约束”，但项目里真正跑起来时，能力在接口层、调用层、状态层可能会掉链子。

所以这次我比较在意的一点，是不能只看模型能力表面上支不支持，还得继续确认：

• 当前策略是否真的要求参考图
• runtime 有没有把商品图带进去
• 最终调用走的是 images.edit 还是退回了 images.generate
• 如果参考图链路失败，fallback 到 prompt-only 以后，日志里能不能明确看出来

这类验证做完以后，我会更清楚地区分两件事：

• 模型能力本身有没有
• 我自己的系统有没有正确把这项能力接上

这两者差别挺大，后面查问题时也能少绕很多弯。

8. Critic 对我来说，更像是在给重试提供依据

我现在对闭环这件事越来越在意。

因为如果只是“生成 -> 用户看 -> 不行再来一次”，很多重试其实没有信息增量，顶多是多抽几次卡。

所以我这版里会在生成后加一轮 critic，去看几件事：

• 商品身份有没有漂
• 场景和展示策略有没有对齐
• 卖点图到底像不像卖点图
• 种草图到底有没有种草感
• 当前问题更像保真问题、表达问题，还是策略问题

然后再把结果收成：

• approved
• score
• retry_action
• revision_instructions
• protect_best_attempt

这样下一轮重试时，我至少知道是在：

• 原策略下继续改 prompt
• 直接切换策略再试
• 还是保护当前最好结果，别继续越改越坏

我现在会觉得，闭环真正有用的地方就在这里：它不是拿来做表面上的“更像智能”，重点是让系统知道下一步该怎么改。

9. 这项目现在已经不只是 Agent demo 了，后面还得继续往后端真相收

做到这一步以后，另一个很明显的变化是：

我已经不太满足于让它只停留在“本地能跑”的状态了。

因为一旦要接前端、接会话、接历史记录、接真实上传和生成结果，后端里很多东西就必须补齐：

• session
• message
• event
• run
• artifact
• 持久化存储

我最近也在把这块往更稳的方向收。

比如上传图和生成图，我现在更倾向于围绕 artifact_id / object_key / remote_url 这套语义来转，而不是继续把本地路径当系统真相。前端需要看的也不该只是一串日志，而应该能看到一轮任务里每一步的结构化过程。

不过这块我心里也很清楚，现在还在补路上。

比如后台执行这层，当前还是偏 demo 形态，后面我还想继续补 durable worker / queue，把 run、attempt、event 真正串稳。

10. 我现在对 DAMA 这个项目的阶段判断：它已经从“会生图”走到“会组织一次任务”了

这应该是我最近最明确的感受。

我现在再看这个项目，关注点已经不只落在这些地方了：

• 图漂不漂亮
• prompt 长不长
• 模型强不强

我更在意的是：

• 输入进来以后，系统有没有先理解商品
• 有没有先判断这是卖点图还是种草图
• 有没有先决定展示方式
• 参考图链路是不是确实生效了
• 结果不好时，系统能不能知道该往哪改
• 这些中间状态后面能不能被前端和后端共同消费

如果这些东西都没有，项目更像“生图页面”。

如果这些东西逐步补齐，它才更像一个真正的智能体项目。

DAMA 现在还远没到完全收口的时候，但至少这条主线我已经看清楚了：

电商生图里的智能体，不只是替用户多写一段 prompt。它还得在商品理解、任务分型、展示策略、模型调用和质检重试之间，先搭出一条能持续推进的工作流。

我先把这一版记在这里。等后面把 run、attempt、SSE、worker 这些工程部分继续补下去，再回来看这篇，应该还能接着往下写。