企业官网建设流程全解析

做营销的人手里最不缺的就是图：投放素材、竞品截图、用户晒单、线下物料，每天成百上千张。过去我团队的做法是人肉看，一张一张看，早上看完下午还要手动整理分析结论进表格，效率低到怀疑人生。后来我拆了一个Marketing Analysis Agent，分两个能力模块来做：1-vision是视觉识别层，负责看懂图片里的信息，2-use_case是业务用例层，负责把看懂的东西套进营销分析模板，输出结论。这篇文章就聊聊这个Agent我是怎么设计的、为什么这么分、落地过程中踩了哪些坑，以及两条腿怎么配合才能真正省人力。

这套东西适合谁看？如果你也在做品牌营销、广告投放、电商运营，或者正在尝试用多模态AI处理非结构化视觉信息，不用是算法工程师，读起来也不会费力，因为核心是业务拆解和工程落地经验，不太涉及太难的技术底层。

1. 项目全貌与设计思路

1.1 三段式需求拆解

动手写代码之前，我先花了两天把需求掰开揉碎。营销分析这个活儿听起来很笼统，但它其实包含三个层次的需求，每一层对应的问题和解决方案都不一样。

第一层是信息获取。大量视觉物料存在图片里，文案、价格、卖点、视觉元素，过去靠人眼看，不仅慢，而且人的注意力是会衰退的，看到第50张之后，细节遗漏率明显上升。这一层核心要解决的是把图片里的营销信息变成结构化文本。

第二层是业务解读。信息有了，不等于分析结论有了。同一张海报，发给渠道运营、品牌经理、创意设计师，三个人关心的点完全不同。渠道运营关注有没有价格优惠，品牌经理关注调性和卖点有没有偏离，设计师关注构图逻辑和排版细节。所以第二层需要一套可配置的业务视角，把原始信息加工成某个岗位能用的结论。

第三层是流程沉淀。分析完的结果如果不归档、不追踪、不对比，下次做素材复盘时又要重新翻聊天记录，等于白做。这一层要求Agent输出的结果必须是结构化、可检索的，能进入团队已有的文档管理系统。

这三层需求用一句话总结就是：从图到信息，从信息到洞察，从洞察到资产。Marketing Analysis Agent这套项目的整体架构，就是围绕这三层逐层构建的。

1.2 为什么拆成vision和use_case两个维度

先说我最初的设计失误。早期我试图把所有的分析逻辑都写在一个大Prompt里，输入图片，输出分析报告，看起来一步到位，但实践下来发现两个致命问题：第一，视觉识别能力和业务规则耦合在一起，一旦业务侧换品类、换渠道，整条提示词链路都要重写，迭代成本极高；第二，模型的视觉理解结果难以校验，它说图上有一个“限时秒杀”，我看不到它判断的依据，出了问题只能干瞪眼。

后来我把整个系统拆成两条独立的链路，也就是标题里写的1-vision和2-use_case。

vision模块只负责一件事：图片识别与信息结构化。它接收一张图片，输出这段图片里有哪些文本、哪些商品、哪些视觉元素、动作按钮在哪里、整体版式大概是什么样。这一层和业务规则完全无关，无论你是卖美妆还是卖3C数码，它做的都是同一件事：把像素变成字段。

use_case模块负责另一件事：基于结构化信息执行业务分析模板。它不直接看图，它只看vision层输出的JSON数据和用户补充的业务上下文。比如你告诉它“这是某品牌新品的电商详情页，目标人群是Z世代女性”，它就拉取对应的用例模板，结合详情页里的文本、画面结构、CTA分布，输出合规性风险提示、卖点突出度评价、转化元素完整性检查结果。

这个拆法的好处，类比一下就很好理解：vision是给Agent装了一双会看图的“眼睛”，use_case是给它配了一套不断更新的“检查表手册”。眼睛负责看清楚，检查表负责盯住业务重点。换业务场景时，眼睛不动，只换检查表，迁移成本低到我团队里实习的同学都能半天上手。

1.3 这个Agent的核心技术选型思路

技术选型上，我没有从零训练任何模型，而是基于现成的多模态视觉语言模型做应用层开发。主流的VLM模型，识别营销素材里的图文混排内容已经够用。真正的竞争力不在模型本身，而在工程侧的三点组合：视觉抽取用多模态模型，精确文本先用OCR保证兜底，业务规则用代码实现而非靠大模型“自由发挥”。

这么选的原因很现实：营销分析场景容错率极低。你说一张海报里有“199元”和“299元”，如果看错一个数字，整个促销方案的定价分析全部作废。纯依靠视觉模型的文本识别会存在幻觉风险，所以我在流水线里前置了一个OCR步骤，把可见文本全部提出来，再让多模态模型基于这些文本去做语义理解。后面会详细讲这部分的实现。

2. 视觉识别层：Agent怎么“看懂”营销物料

2.1 营销物料四大类，识别重点各不同

做营销分析，首先要承认一个事实：营销图片不是一个均质的数据集，它至少分成四大类，每一类需要视觉层关注的重点完全不同，用同一个Prompt包打天下一定会翻车。

第一类是广告素材图，包括信息流大图、朋友圈海报、Banner横幅。这种图的核心特征是“传播导向”，里面的文案高度浓缩、利益点直给，视觉上通常有明确的视觉重心。识别这种图，重点是抽取短文案、价格锚点、行动号召语、品牌Logo露出程度、主色调和调性氛围。

第二类是界面截图，比如落地页、小程序页面、电商商品详情页。这种图的核心特征是“结构化信息密度高”，一个页面上有标题、卖点、参数表、评价、购买按钮多个区域。识别这种图，不能只靠整体扫描，得按照页面版块做区域理解。

第三类是数据图表截图，投放后台的消耗曲线、转化漏斗、区域分布图，还有各种数据看板。这种图的识别难点不是“看见图表”，而是“把图表里的数字准确抽出来”，并且还原出枯燥数字背后的趋势关系。

第四类是线下物料，海报、易拉宝、门头招牌、单页。这类物料拍摄角度乱、光照不均、可能还有遮挡，识别起来比电脑里的截图难得多，对视觉层的鲁棒性要求最高。

在设计vision模块的输入协议时，我给每类图片打了一个type标签，不同类型走不同的识别模板。这么做比统一处理准确率高出一截，因为每类图片的关注点和输出字段都不一样。

2.2 视觉识别的双通道方案：OCR兜底+VLM语义化

这一节重点讲实践方案。我刚才提过，纯VLM有幻觉风险，纯OCR只能给文字给不出语义，所以我用的是一套双通道组合流程。

第一步，图片进来之后先做标准化预处理。统一把最长边resize到1600像素，控制调用成本；检测格式，兼容jpg、png、webp，甚至部分扫描件；如果图片方向有明显旋转，先做自动矫正。

第二步，跑OCR通道。我用的OCR引擎除了输出文字内容，还会输出每个文本框的坐标位置，这个信息在后续版块分析里非常有用。所有识别出的文本拼起来，作为后续的“可信文本锚点”传给VLM。

第三步，VLM通道。把原图（或压缩后的版本）连同OCR提取的文本一起传给视觉语言模型，Prompt里明确要求它结合OCR文本做语义理解，不要凭空捏造文本。

第四步，结构化整合。模型输出遵循我在Prompt里定义的JSON Schema，字段包括texts（核心文本列表）、products（商品信息）、visual_elements（视觉元素）、layout（版式结构）、cta_buttons（行动按钮）、color_style（色彩调性）等。OCR文本和VLM输出互相校验，如果出现了OCR里没有但VLM声称“看见”的文本，就标记为低置信度，由下游规则引擎决定是否采信。

这套方案实际运行下来，中文素材的文本识别准确率比纯VLM高很多，尤其是遇到促销信息区域小字极多的设计图，效果尤其明显。如果你只接一个VLM指望一步到位，大概率会在复杂素材上翻车。

2.3 Prompt设计的关键：把“结构化”焊死在输出里

视觉识别层的Prompt，我迭代了大概六七个版本，最后沉淀出一个原则：别让模型自由发挥，把输出规范用JSON Schema的形式焊死在Prompt里。

我给出一个简化示例，这是我给VLM用的结构化指令模板：

VLM_PROMPT_TEMPLATE = """ 你是一个营销素材视觉分析器。请分析用户提供的图片，并严格按以下JSON结构输出： { "scene_type": "ad_material | ui_screenshot | chart_screenshot | offline_material", "texts": ["图中所有可见文本，按视觉重要性排序"], "key_visual": "对图片主视觉内容的客观描述，不超过50字", "products": [ {"name": "商品名称", "category": "品类", "prominent": "是否为主体展示商品"} ], "cta_areas": ["行动号召位置描述"], "layout": { "structure": "描述整体版式结构", "reading_order": ["按人眼阅读顺序描述主体元素"] }, "confidence": {"overall": "high|medium|low", "note": "任何不确定内容的说明"} } 注意： 1. 文本内容必须与图片实况一致，禁止补全不存在的文字。 2. OCR提供的文本可以辅助你判断，但要以你在图中看到的内容为准。 3. 字段缺失时留空字符串，不要编造。 """

这个模板定下两个硬规矩：结构必须按Schema走，字段缺失宁可留空也不要瞎编。实测下来，Generate式输出比自由文本靠谱得多，后续解析JSON的成本也低。

2.4 图像处理里容易忽略的细节

几个预处理细节，建议直接抄作业。图片方向信息一定要保留，很多手机拍出来的照片在exif里带旋转角度，直接读取会变成横躺的图，极大影响识别效果。图片压缩要适度，营销素材里常有大量细节文字，压缩太狠小字直接模糊，我压到80%质量一般可以接受。截图型的图不要随意放大，放大会产生马赛克伪影，影响VLM对边缘和按钮的识别。

另外还有个小技巧：对于信息密度极高的长图（比如整页详情页截图），直接整张丢给模型很浪费，还会让模型注意力涣散。我实现了一个切图逻辑，按高度等比切成上下几段，每段单独过VLM，最后把结果按顺序拼接。实测无论识别准确率还是关键信息捕获率都明显提升，但要注意段与段之间重叠20～30像素，避免正好切断关键区域。

3. 用例封装：把“看懂”变成“能用的洞察”

3.1 用例不是Prompt，是带规则的业务SOP

很多人会把use_case理解为“换一个Prompt问模型”，这就是为什么他们做出来的Agent不够落地。真正的用例封装，是一套“输入模板 + 分析规则 + 输出模板 + 校验逻辑”的组合，Prompt只是其中最表层的一部分。

举一个最典型的例子：广告素材合规性检查。一个品牌方投放广告前，要确认素材有没有违规风险，比如极限词（“国家级”“最佳”“第一”）、虚假宣传表述、竞品商标露出、未授权的肖像元素。

在use_case层，这个用例的输入是“vision层输出的素材结构化数据 + 商品的合规规则库”；分析规则是用代码实现的敏感词列表、禁用词正则、竞品品牌名匹配；输出模板是一份带风险等级的判断报告。这里面的合规规则完全不需要大模型“思考”，直接跑规则引擎更稳定、更可解释。

再举一个偏洞察的用例：竞品卖点提炼。输入是竞品广告图的VLM识别结果，分析规则是“提取产品描述文本、和自家产品做卖点差异对比”，这部分的语义对比可以用LLM来做，但我会限定它必须基于vision输出的字段，不允许自由发挥。

3.2 五类高频用例组合

项目上线几个月，我沉淀下来最常用的五类用例，每次营销部门的需求基本都能落进这些盒子里：

广告素材合规审查，输入单张或一批广告图，输出违规风险分级，高风险直接拦截进入人工复核队列。

竞品视觉监控，定时抓取竞品渠道素材，视觉层先识别，用例层自动做卖点标签分类，跑出竞品高频卖点TOP榜。

UGC内容筛选，在小红书、微博等渠道收到用户晒单图后，判断图片里有没有品牌产品实物、有没有过度P图、有无违规风险，筛选出可二次转载的内容。

详情页转化力评估，输入电商详情页截图，识别结构完整性、卖点层次、CTA是否存在，对照品类基准给出评估分。

线下物料一致性检查，扫描各门店的促销物料，对比总部的标准模板，检查价格、活动时间、Logo是否一致，防出错降低客诉风险。

这几类用例的共同特征是：输入的视觉信息种类不同，业务规则不同，输出物也不同，但都复用了同一套vision能力和同一套用例执行框架。

3.3 用例执行链路的工程细节

每个usecase的执行链路我会统一抽象成五个步骤：参数校验、上下文组装、规则跑批、模型推理、结果校验。参数校验检查用户传入的业务字段是否齐全，比如做合规审查但没有传入品牌名称就拒绝执行；上下文组装把vision输出、OCR文本、业务参数拼成一个内部统一的事件对象；规则跑批是纯代码执行的逻辑，速度极快；模型推理只在规则跑批结果不足以得出结论时才触发，避免不必要的Token消耗；结果校验最后跑一遍，检查输出JSON是否合法、风险字段是否越界，有问题就打回重试。

这套五段式链路帮我解决了一个很关键的问题：工作流确定性。营销团队用Agent，最怕的就是同一个输入今天跑一个结果明天跑一个结果。通过把大部分判断逻辑放进代码层、让模型只做语义理解和归纳，输出稳定性明显提升。

3.4 用例层的Prompt安全与隔离

这里要提醒一个重要细节：用例模板里的提示词，绝对不能直接让用户输入的自由文本拼接进去。因为营销素材本身是外部内容，图片里的文本如果被坏人精心构造，可能会引导模型输出异常内容。我踩过一次坑，一张竞品素材里出现了恶意Prompt，险些污染下游报告。

解决方案也很简单：用户输入的图片文本和业务参数，只作为数据传入，不进Prompt主体字符串的模板拼接位。举个例子，如果Prompt里要引用“品牌名”，必须预先定义好变量位，而不是直接拼接用户传上来的字符串。所有外部输入过一道清洗函数，剔除特殊字符和控制序列。

4. 工程落地与实操细节

4.1 技术栈与依赖清单

下面列一下我实际用到的技术栈，你没必须一模一样，但可以参考选型思路。

Python 3.10是主力开发语言，生态最成熟。多模态识别依赖视觉语言模型的API，我用的某国内云厂商的VLM服务，主要看中它对中文素材的支持。OCR这块借助开源OCR引擎，在服务端自建了识别服务，因为调用量大了走外部API太贵。队列用的是Redis Stream，视觉识别是耗时的IO操作，并发一高必须排队。业务用例的调度我用Python自研了一个Worker脚本，没什么高深的，就是一个循环消费任务、分发用例的处理进程。

整个项目部署在一台8核16G的云服务器上，日均处理大约3000张图片，高峰期用容器扩到两台节点，目前运行稳定。

4.2 核心流程代码骨架

下面这段代码是我抽取的结构简化版，核心链路都在里面，你可以作为参考骨架跑通流程：

import json import redis import requests class MarketingAnalysisAgent: def __init__(self, ocr_endpoint: str, vlm_api_key: str): self.ocr_endpoint = ocr_endpoint self.vlm_api_key = vlm_api_key self.redis_cli = redis.Redis(host="localhost", port=6379, decode_responses=True) self.case_registry = self._register_cases() def handle_image(self, image_url: str, use_case: str, biz_context: dict): # step1: 标准化图片，读取并压缩 image_bytes, image_meta = self._fetch_and_preprocess(image_url) # step2: OCR双通道，获取可信文本锚点 ocr_result = self._call_ocr(image_bytes) # step3: VLM结构化识别，OCR文本作为锚点传入 vlm_result = self._call_vlm(image_bytes, ocr_result) # step4: 断言用例存在，走独立执行链路 if use_case not in self.case_registry: raise ValueError(f"unknown use_case: {use_case}") return self.case_registry[use_case].execute(vlm_result, biz_context)

这段代码展示的核心是：每一步的输出都是下一步的输入，OCR的结果不单独展示给用户，而是作为VLM调用时的一个参考参数传进去。这样避免了重复抽取，也降低了模型生成不一致内容的概率。

4.3 成本控制：Visual Token有多烧钱

VLM调用的费用大头在视觉token上，一张1600px的图片进来，视觉token消耗是文字token的好多倍，跑得越多越心疼。我做了三层成本控制：

第一层是缓存。同一张图片（用MD5去重）在短时间内反复请求的话，直接命中Redis缓存，不重新调用VLM。第二层是分级调度。不是所有图片都需要走VLM，有些图片只要提取几个关键文本字段，纯OCR就够了，我把这类请求直接分流到轻量级通道。第三层是批量复用。同一批投放素材，规划好一次分析尽量把能合在一起的多张图打包请求，降低网络等待和限流概率。

算笔账给你看：如果每张图平均消耗3000个视觉token，单价按主流服务约在几厘钱每千token量级浮动，一张图成本大约一两分钱，月均十万张图也就是几千块人民币。相比一个专职初级分析师的人工成本，这个价格已经很低了。

4.4 系统可观测性设计

做这类Agent项目，最怕的就是模型“黑盒感”，出了问题不知道是视觉识别错了还是用例规则错了。我在每一步都打了结构化日志：原始图片URL、OCR文本摘要、VLM返回的JSON、用例执行的规则匹配详情，全部落库。

这带来一个巨大的好处：每次出问题，我可以直接回放到某一步中间结果，快速定位责任模块。有一次合规审查误报，顺着日志一路查到某个敏感词被误匹配（竞品品牌名是“某某优选”，和我们的商品名有重叠），几分钟就修掉了。没有日志的情况下，这种问题查起来会绝望。

5. 踩坑记录与排查方法

5.1 视觉层翻车四连

第一个坑是中文密集小字识别混乱。第一次测试某品牌电商详情页，长图里塞了十几条卖点小字，VLM输出的文本出现明显错乱，几个卖点文案串行甚至合并。解决手段就是前面说的切图分段处理，加上OCR文本做锚点，VLM哪怕在小字区域看走眼，OCR的结果会把它拽回来。

第二个坑是图中数字幻觉。我遇到过一张定价图，VLM宣称“限时特惠价99元”，但OCR提取的实际是“199元”。排查后确认是VLM在语义推理时把原图背景里的“1980”原价信息干扰了，误生成了“99”。这个问题的化解方式是校验逻辑：凡是OCR有明确文本的区域，VLM输出的对应字段必须与OCR一致，不一致时以OCR为准，并降低置信度。

第三个坑是表格结构还原困难。投放数据截图里的表格，如果直接用VLM转JSON，经常出现行列错位，数据张冠李戴。后来我在OCR阶段就启用表格识别模式，先把表头、行索引、单元格坐标定位出来，再交给下游做结构化，问题大大缓解。

第四个坑是彩色背景干扰文本识别。深色背景、渐变底色里嵌白色小字，OCR很容易漏提，VLM则会被背景元素带偏。我在预处理里加了对比度增强和背景分离逻辑，实测漏提率下降约三成。

5.2 用例层的隐性坑

用例层最大的坑是规则库更新不及时。合规用词是有时效性的，不同渠道的管理规定会调整，旧的词库里如果残留大量已经过时的敏感词，会导致误报率奇高。我加了一个规则版本管理机制，每次规则调整都带版本号，用例执行日志里能查得到是哪个版本的规则做出的判断。

第二个坑是任务重复提交。营销同事手动上传素材时，经常重复拖同一张图，如果没有去重，不仅浪费调用额度，还会导致结果被覆盖。解决方式是提交时用图片MD5加业务ID做唯一索引，重复任务直接返回既有结果。

第三个坑是下游系统对接格式不一致。团队内部的文档系统要的是Markdown表格，报表系统要的是CSV，企业微信机器人要的是纯文本摘要。我实现了一个输出适配层，用例执行的核心结果存JSON，展示层按目标渠道动态转换。

5.3 排查方法速查表

如果你也遇到了类似问题，可以参考这个速查表，按图索骥能省不少时间：

这个表我打印出来贴在工位上，新来的同学遇到问题先自己查表定位，很少需要来问我。

6. 版本迭代与后续扩展方向

6.1 从单图分析到批量流水线的升级路径

v1版本上线时只支持单张图片分析，营销同学天天抱怨一次只能看一张太慢。迭代到v2，我把架构改成了批处理流水线：用户上传一个素材包（几十张图），系统自动拆任务、并发调用、按用例汇总输出一份批量分析报告。

这个升级带来的一个额外好处是：批量处理天然适合做数据对比。比如投放了20条素材，批量跑完全部合规审查后，可以立刻按风险等级排序，哪些素材可以马上投放、哪些需要修改、哪些直接废弃，一目了然。

6.2 可以继续拓展的方向

下一步我准备做时间序列分析：把不同周期的素材分析结果存进数仓，就能对比“这个月投放素材和上个月相比，视觉风格、卖点侧重、文案表达有什么变化”。这本质上是把单次分析变成趋势追踪。

第二块可以做RAG知识库。把历史分析报告全部索引起来，营销人员直接问Agent：“之前有没有类似我们这次主打功效卖点的竞品素材？当时的卖点措辞是什么？”Agent会先检索，再用检索结果辅助回答，避免空对空的幻觉输出。

第三块是生成侧的能力，基于视觉识别结果反向生成新素材建议。比如识别出一张竞品海报强调整体质感，Agent可以给建议：使用高保真产品图、底色改为冷灰调、CTA按钮放到右上角。这个方向还在试验中，但业务价值很大。

这些扩展方向都建立在同一个底子上：视觉识别层足够稳定，用例层足够标准化。底子打好了，上面长什么业务分支都不慌。

6.3 给想上这套系统的团队几句肺腑之言

如果你也想在团队里搭一个类似的营销分析Agent，我的建议是别一上来就追求大而全。先选一个最痛的点，比如“广告素材合规审查”，把这一条链路完整跑通，让业务团队真实用起来，再逐步扩展其他用例。

没有业务团队持续反馈的Agent项目，很大概率会死在工程师的自嗨里。我们收集到的反馈里有不少看起来“不专业”的细节，比如“数字后面不要带小数点”“报告标题不要全是尖括号符号”，但就是这些细节让一线同事愿意每天点开去看，系统才能真正活下来。

还有一个小经验：视觉识别结果的置信度标注很重要。哪怕只是给每个字段贴一个low/medium/high，业务人员看到low的区域会主动复核，这种“人机配合”的信任感是系统能不能长期被使用的关键。不要追求百分之百自动化，让系统在该不确定的时候承认不确定，反而比硬撑着给一个错误答案更值钱。