一个员工能用AI做出主图

和一家企业拥有可以持续复用的主图生产能力

中间还隔着知识、流程、协作与验收

老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent、多岗位SOP系统搭建。

要看清这件事，可以把视线放到一项具体工作上

为一款新商品制作主图和详情页。

员工打开工具，上传照片，写提示词，生成一张图，这是在用AI。

企业把自己的商品资料、品类经验、作图方法和验收标准整理好，让专门的岗位Agent按照约定执行，也是在用AI。

主图岗位、详情页岗位和真人负责人按一条流程交接，员工通过工作台提交资料、审核方案、取得文件，同样是在用AI。

表面上都能说“我们已经在做AI化”，背后解决的问题却很不一样。老板如果只看最后有没有图片、有没有界面，就很容易把几种能力混在一起。

我把这些状态分成五个阶段：使用AI工具、通用Agent、私有AI岗位Agent、SOP、工作台。

先交代两个前提：

这是一套帮助企业辨认现状和建设方向的方法论框架，不是行业统一的成熟度标准，也不是每家企业都必须按顺序走完的路线。其中，“通用Agent”代表一类需要警惕的适配弯路，可以直接跨过。

下面围绕“新品主图与详情页生产”展开的流程，都是用于说明机制的自拟示例，不对应某家客户的真实项目或效果数据。

一、使用AI工具：先解决一项具体任务怎么做

在工具阶段，AI承担了一部分执行工作，整项工作的组织仍由人完成。

做一张商品主图，员工要先理解这次为什么做：是展示外观、突出使用场景，还是说明某个有依据的商品特点。然后找资料、挑照片、组织提示词、提交生成，再判断结果是否可用。

图片出来以后，还有不少工作：商品外观有没有变，文案与资料是否一致，画面表达是否符合这次目标，需要改哪里，最终交给谁。

这时，AI已经参与生产，但输入什么、按什么顺序做、结果怎么算合格，主要还掌握在操作者手里。

所以，同样的工具，交给不同员工，使用过程和结果可能差别很大。一位熟悉商品的人知道哪些信息要补充，也知道哪里看起来合理、实际上不对；另一位员工可能只看到画面完成了，就以为任务结束了。

差别不能全归结为谁的提示词写得更漂亮。商品知识、业务判断和岗位经验，本来就参与了整个过程。

工具阶段有它的价值。企业可以通过具体任务了解AI能做什么、输入不足会带来什么问题，也可以练习判断生成结果。对于低频、临时性很强的工作，直接使用工具，也可能已经足够。

真正值得留意的是：如果某类工作会反复发生，经验有没有被留下来？

比如，下次还要做主图，是否仍然需要同一个人从头解释商品、重写要求、重新检查相同的问题？换个人接手，是否只能靠口头交代？

我的建议是，在使用工具时就开始记录三件事：

• 输入清单：完成这类任务之前，必须拿到哪些商品资料、素材和业务要求。
• 工作步骤：先核实什么，再判断什么，哪些决定会影响后面的执行。
• 验收标准：哪些结果可以通过，哪些问题必须退回，谁负责最后确认。

这些记录不必一开始就很复杂。它们首先要能解释清楚：一个熟练员工究竟是怎样把事情做完的。

当这套经验逐渐清楚，企业就有了把单次操作沉淀成岗位能力的基础。

二、通用Agent：任务被包装了，业务适配可能仍然缺位

接下来，企业很容易接触到各种现成Agent。它们可能有清楚的名称、固定的输入框和完整的结果模板，看起来已经把岗位工作打包好了。

操作门槛下降，当然有价值。但还需要往下问：这套能力依据什么理解我的商品，依据什么判断结果适不适合我的业务？

这里说的“通用Agent”，有一个明确范围：依赖通用成品能力，缺少用户自有知识接入与品类冷启动机制的Agent。

“品类冷启动”听起来有点技术化，意思很简单：面对一个还不了解的品类，Agent能否引导企业把必要资料提供出来，逐步建立对这个品类、这家企业和具体商品的认识。

继续看主图任务。

一般性的作图经验，可以告诉你注意主体、构图、信息层级。但它不能直接告诉你，这款商品究竟有哪些可以证明的特点，客户在意哪些问题，哪些说法不符合商品事实，品牌对画面有哪些具体要求。

这些判断，需要接入企业自己的资料和标准。

假设员工只填写了商品名称和一句需求，Agent就交出一套完整方案。方案可能很流畅，也可能看起来很专业，但如果关键事实没有来源，形式完整并不能说明业务适配已经完成。

接下来，员工可能要不断解释：这个特点不能这样写，那个场景不适用，这个卖点证据不够，品牌也不采用这种表达。每次换商品，又重新解释一遍。

如果系统缺少把这些资料整理、确认、接入并持续维护的机制，企业投入的业务经验就很难成为下一次任务可用的依据。

老梁AI电商对这一阶段的判断是：企业要警惕把缺少自有知识接入的通用成品Agent，当成长期建设目标。企业可以从工具使用，直接进入自己的私有岗位Agent建设。

同时，不能因为一个东西有“通用基础”，就把它全部归入这类弯路。

通用大模型提供基础能力；可配置的Agent工具可以承载不同业务；一个尚未装入企业资料的岗位模板，也可能已经具备知识接入和品类初始化的方法。它们需要分别判断。

辨别的重点，可以落到三个具体问题上：

• 能否接入企业自己的产品、品类、方法和验收知识，并在工作中使用？
• 面对一个新业务，能否引导补充资料、确认关键事实，完成初始化？
• 接入知识以后，能否用企业的真实任务测试，并依据问题修正流程与标准？

如果这些环节能够做起来，一个有通用起点的工具或模板，就有机会成为企业私有岗位能力的载体。关键在于业务适配机制是否存在、是否经过验证。

三、私有AI岗位Agent：把一类工作的做法沉淀下来

到了这一阶段，企业开始明确：这个Agent承担哪一类工作，它按照谁的标准执行，要交付什么结果。

“主图岗位Agent”这个名称本身，还不足以说明能力。需要继续拆开，看到它背后的组成。

以本篇的示意场景为例，至少要讲清楚六件事。

1. 这个岗位负责什么，要拿到哪些输入。

主图岗位可以负责分析素材、形成方案、调用作图能力、整理交付文件。它是否可以决定本次销售主张，是否可以直接发布图片，则需要另外明确。

输入也要具体：商品资料、参考素材、本次任务目标、必要的规格要求，哪些是必填，哪些可以稍后补充。

如果商品的关键事实尚未确认，就不能靠一个看起来完整的答案把空缺填过去。岗位规则应该告诉Agent：缺少什么信息时需要暂停，向谁说明，补齐以后从哪里继续。

2. 工作按什么顺序展开。

这就是Workflow，也就是岗位工作流程。

例如，先确认商品资料与本次任务，再形成主图表达方案；方案通过后进入作图，随后整理版本和待验收结果。

顺序本身包含业务经验。没有确认表达方向就进入大量执行，后续修改可能涉及整套方案。流程写清楚，就能让Agent知道哪些步骤有前置条件，哪些决定需要先交给人。

3. 判断依据放在哪里。

这就是Knowledge，也就是岗位知识。

它包括产品和品类知识，也包括方法、案例、判断标准。商品资料回答“事实是什么”，方法回答“怎样处理这类问题”，案例提供可以参考的经验，验收标准回答“什么结果算合格”。

这些内容各有作用。一份商品说明书，通常不能替代完整的岗位知识；一批成功作品，也不一定已经解释清楚作品为什么适用。

整理知识时，要尽量把隐含的判断说出来。例如，借鉴一张参考图，是借鉴它的信息层级、构图关系，还是某种商品展示方式？哪些部分可以参考，哪些部分不能照搬？Agent需要知道适用条件。

4. 完成工作需要哪些工具与技能。

岗位可能需要读取文件、生成图片、整理文档，或者调用其他已经配置好的执行能力。

工具和技能承担具体动作。它们接进来以后，还需要明确什么时候调用、把什么作为输入、返回什么算成功、失败怎样处理。

一个岗位Agent装了生图能力，只能说明它具备调用这一动作的条件。它是否知道该画什么、什么时候可以画、生成后交给谁，还要由流程、知识和规则共同决定。

5. 最后交付什么，谁来验收。

“帮我做主图”仍然太宽。企业应按自己的工作需要说明，要收到哪些文件、方案信息和版本说明，结果由谁确认。

验收标准也要能落到具体内容：商品事实是否一致，表达是否符合任务目标，指定要求是否落实，待确认事项有没有显式列出。

验收标准越含糊，Agent和真人就越容易反复猜测对方的意思。

6. 哪些事情可以自主执行，哪些必须交给人。

涉及业务取舍、事实争议、对外发布或其他需要授权的动作，应在岗位边界里写清楚。

例如，整理一个待审核方案，与批准这个方案，是不同动作。接到修改意见，与自动修改已经确认的商品事实，也不是同一项授权。

私有岗位能力必须包含这样的边界，才能进入持续使用。

把这六件事放在一起看，私有岗位Agent建设就具体了。

企业既需要能够执行动作的AI，也需要把岗位做事的方法、业务依据、交付要求和权限装进去。岗位能力的沉淀，发生在这些内容共同发挥作用的时候。

没有现成知识库，怎么开始？

可以有两条路线。

第一条，企业已经有整理好的知识库，比如用Markdown保存的产品资料、品类方法和岗位标准。先接入，再检查它们是否适合这项工作：资料是否齐全，口径是否一致，旧内容是否仍然有效。

第二条，企业只有散落的原始资料。可以由Agent按岗位需要引导收集，再由人和AI共同整理成可调用的知识。比如，把商品说明、素材、既有方案、修改意见和经验说明，逐步分到对应的知识文件里。

第二条路线里的“引导”，很有价值。企业未必知道该一次性交出什么，Agent可以根据流程提出具体缺口，让负责人逐项补齐。

但整理能力不能替代事实确认。原始资料里没有的商品结论，不能因为写成了漂亮的知识文件，就变成已经确认的事实；两份资料互相冲突，也需要找到负责人校准。

所以，两条路线最后都要经过人的确认，再进入任务测试。

测试什么，才能知道它具备岗位能力？

只看一个演示结果，很难判断它能否持续使用。更有价值的做法，是用不同条件下的真实任务去检查。

• 正常任务：资料齐全时，能否按流程完成，并交出符合约定的结果。
• 换商品任务：换一份资料后，能否重新理解商品，避免照搬上一次的结论。
• 缺资料任务：必要输入不足时，能否指出缺口，按约定等待补充。
• 冲突任务：当前要求与知识、规则发生冲突时，能否把问题交给有权判断的人。

测试时也要区分问题出在哪里。事实不完整，就补资料；步骤顺序不合适，就改流程；交付反复不一致，就细化标准；工具动作失败，就检查执行条件。

否则，所有问题都变成“再改一下提示词”，经验很难积累到正确的位置。

把真实任务中发现的问题，写回知识、流程和标准，再验证修改是否有效，岗位能力才会持续成长。企业留下来的，也不只是一次聊天或一张图片，而是一套可以维护的做事方法。

四、SOP：让多个岗位和真人把一件事共同做完

当主图Agent可以工作，详情页Agent也可以工作，企业还会遇到下一层问题：它们怎样共同完成这次商品素材任务？

主图侧已经换了表达重点，详情页侧是否拿到了新版本？商品资料刚被真人纠正，已经进入执行的任务需不需要退回？某个方案还在等待审核，后续动作可不可以开始？

这些问题需要SOP来组织。SOP就是标准业务流程，它要把参与者、节点、前后依赖、交接条件和异常处理讲清楚。

以本文的自拟场景为例，可以这样安排：

1. 真人负责人确认商品事实、本次目标与必要资料。
2. 主图岗位Agent形成方案，提交真人审核。
3. 按审核结果执行主图任务；把已确认的表达方向和资料版本交给详情页岗位。
4. 详情页岗位Agent完成对应任务，在约定节点交给真人审核。
5. 汇总经过确认的产物，按约定交付。

这里只是为了说明交接关系。实际工作中，哪些步骤能够同时进行，哪些必须等待上一步，需要由企业根据业务依赖决定。

“交给下一步”也要写具体。交的是一句聊天里的结论，还是明确的商品资料、审核通过的方案、对应版本和文件？下一位执行者拿到这些东西，能不能知道什么已经确认、什么仍在等待？

只有把交接对象说清楚，流程才能减少对个人记忆和临时转述的依赖。

一条SOP，要分清流程定义、实际推进和进度记录

采用SOP-as-a-Skill的方法时，可以把一类工作的流程封装成Skill。这里的Skill可以理解为一份可调用的工作说明，写清步骤、参与者、输入输出、权限和异常处理。

但Skill文件写好了，具体任务还需要有人推进。

Skill定义这类事情应该怎么做；主控Agent推进这一次任务；实例状态记录这一次做到哪里。

这三者分别承担不同责任。

主控Agent需要根据当前状态判断：现在具备什么输入，下一步应该交给谁，是否需要等待真人确认。如果步骤失败，需要按规则记录问题并进入恢复处理。

实例状态则要留下当前节点、已产生的文件、资料版本、审核结果、待办条件和异常信息。它们共同说明：哪些事情做过，哪些事情还没有做。

比如，详情页方案被退回了，状态里应当能找到退回原因和所涉及的版本。任务中断后继续时，也应该能够依据这些记录，决定从哪里恢复。

如果只保留一条“执行失败”的提示，或者依赖Agent凭模糊的聊天上下文回忆，流程就缺少可核对的依据。

真人审核，需要成为正式节点

业务里的审核通常包含真实取舍：商品事实是否可以这样表达，这次方向是否符合目标，结果是否可以对外使用。这些都可能需要真人承担责任。

因此，“待真人审核”应该有明确的审核对象、负责人和后续条件。审核通过后做什么，退回后到哪一步，等待期间哪些动作暂停，都应当写进流程。

这能避免一种混乱：系统已经继续往下做，真人还以为自己有机会修改上一步。

SOP阶段的验收，也因此比单岗位更进一步。除了看各岗位能否完成任务，还要看交接是否准确、等待是否有效、退回是否清楚、中断后是否能找到原来的进度。

老梁AI电商强调，多个岗位具备能力以后，还需要把协作关系落到流程和记录里。多个Agent同时存在，只是具备了参与者；一件业务能否共同做完，要靠明确的组织方式。

五、工作台：让员工能在日常工作中使用这些能力

岗位能力跑通，协作流程也清楚了，还要面对使用问题。

员工从哪里交资料？当前任务做到哪里？需要自己确认什么？结果放在哪里？出现问题以后，应该补信息还是重新提交？

工作台就是把这些操作组织成清楚的界面。

对主图岗位来说，一个独立Agent工作台可以提供资料提交、信息补充、方案查看、修改反馈和文件获取等入口。员工能够按照自己的业务任务使用能力，无须每次重新理解背后的运行过程。

对跨岗位流程来说，独立SOP工作台还要呈现整条任务的进度：正在执行什么，下一步由谁处理，哪一处等待审核，各节点已经产生什么文件。

这两种工作台服务的对象不同。一个围绕单岗位任务，一个围绕跨岗位业务流程。

在此基础上，可以按真人员工的职责，把他需要的独立Agent工作台和独立SOP工作台接入个人综合工作台，让日常任务有一个集中的入口。

这里要特别看清两条路线：

单岗位Agent → 独立Agent工作台 → 个人综合工作台。

真人与多个岗位协作 → SOP → 独立SOP工作台 → 个人综合工作台。

单岗位Agent可以直接拥有工作台。一个人只需要稳定使用主图能力，就可以先为这项能力提供界面；有跨岗位协作需求时，再建设相应的SOP。

“五个阶段”因此不能画成一条必须逐级通过的闯关路线。岗位能力、协作组织、使用入口虽然相互关联，却可以根据业务需要分步建设。

工作台让使用方式变清楚，背后的能力仍然需要单独验收。

比如，页面有“生成主图”按钮，不代表商品事实已经接入；页面显示“已完成”，不代表结果已经由有权的人确认；多个入口放在一起，也不代表流程依赖已经正确建立。

因此，设计界面时，要把前面已经明确的业务要求带进来：必需资料怎么收集，待审核状态怎么表达，退回原因在哪里查看，谁能执行哪一种操作。

可以用员工的一次完整使用过程来检查：从提交真实任务开始，到找到结果结束，他能否理解每一步需要做什么，界面显示的状态是否对应真实进度。

界面是否方便，业务能力是否可靠，是两项都值得认真验证的工作。把它们连接起来，已有能力才更容易成为员工日常可用的工具。

六、企业下一步做什么，先看现在卡在哪里

说完五个阶段，再回到企业自己的现场，就不必急着给整家公司贴上“处于第几阶段”的标签。

同一家企业里，完全可能同时存在不同状态：某些岗位直接使用工具已经够用；某个高频岗位开始沉淀私有Agent；一条跨岗位流程正在试运行；已经成熟的能力则通过工作台提供给员工。

建设可以跟着问题走。

如果每次都要重新解释商品背景、重复修改相同错误，就检查产品知识、品类知识和岗位标准是否已经整理并接入。

如果单个岗位做得出来，工作却卡在来回交接，就检查SOP：上一环节交什么，下一环节凭什么开始，谁确认通过，异常退到哪里。

如果能力已经跑通，员工仍找不到入口、进度和结果，就把工作台的提交、审核、状态和文件获取做好。

如果眼下只是一个低频、范围很小的任务，直接使用工具能够完成，也可以先把工具用好。流程复杂度应当对应实际需要。

对于准备开始的企业，我更建议把第一项试点说得具体一点。

例如，在本文的示意场景中，可以先明确：围绕一类商品的主图工作，准备哪些真实资料，由谁确认，岗位要按什么步骤执行，交付到什么程度算通过。

然后，用真实任务跑一遍。资料问题归到资料，方法问题归到方法，交接问题归到流程，把发现的问题留在可维护的知识和规则里。

等一个岗位能够按自己的标准反复工作，再根据实际需要，把协作与工作台接上来。

这样推进，企业留下来的就会越来越清楚：自己的商品知识、品类判断、岗位流程、可调用的技能、经过校准的验收标准，以及人与AI协作的规则。

企业AI化的建设进度，可以看这些能力是否在真实工作中逐步形成。

老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent。