企业官网建设流程全解析

11张截图进，6张海报出，这个数字对比听起来很魔幻，但确实是我在云栖大会结束之后，用 WorkBuddy 完成的一次视觉重构。当时我相机里存了一堆现场照片，手机里又截了一堆官网页面和议程表，零零散散堆在相册里，既不方便发给团队，也没法直接拿去做展示。后来我把这些原始素材全部丢给 WorkBuddy，让它从信息筛选到版式设计重新走了一遍，最后得到6张风格统一、可以直接投屏展示的海报。这篇不聊大道理，就讲讲我具体怎么操作、中间踩了哪些坑，以及为什么我这次会选择 WorkBuddy 而不是直接打开设计软件硬干。

1. 先搞清楚：这次重构到底要解决什么问题

1.1 原始素材长什么样

我这次收上来的11张截图，来源很杂。有3张是现场随手拍的展区照片，光线忽明忽暗，画面里还混着路过的人；有2张是大会官网首页的整页截图，信息密密麻麻；有3张是论坛议程的截图，每张里都塞了十几个演讲标题；还有1张展区地图、1张产品数据页、1张扫码立牌的现场照。这堆素材放在一起，最大的问题不是“不够好看”，而是“没法直接当作品展示图用”。

比例完全不统一只是表面问题，真正麻烦的是信息层级混乱。官网截图里的小字在缩小后根本看不清，现场照片里的展板又因为透视角度导致文字变形，议程截图里真正重要的几个场次反而被一堆装饰性线条抢了注意力。如果直接把这些截图拖进PPT或者设计软件，出来的效果一定是“一眼假”——观众能明显看出来这是拼接的素材，而不是一套有规划的作品展示。

所以我一开始就明确：这次重构的目标不是把截图美化一下，而是先从这些混乱素材里抽出有效信息，再把信息重新组织成视觉语言。换句话说，我要做的是信息架构层面的重构，而不是简单的滤镜美化。

1.2 为什么选择 WorkBuddy 而不是直接开设计软件

可能有朋友会问，这类活儿用设计软件也能做，为什么要绕一道用 WorkBuddy？我当时的判断是这样的：如果手工做，我至少要经历三个耗时环节。第一，逐张打开截图，把里面的标题、数字、时间地点等信息手动摘出来，这个过程枯燥且容易漏；第二，摘出来的信息要人工统一口径，比如某张截图写的“超4万平米”，另一张写“4万+平方米”，到底是同一个数据还是不同数据，需要逐一核对；第三，六张海报要保持同一种视觉规范，所有标题字号、正文字体、间距比例、配色都要保持一致，手工一张张调，很考验耐心。

WorkBuddy 在这三个环节上正好是我的强项。它不是一个传统的绘图软件，而是一个能够承载多步骤任务的AI工作台。你可以理解成它像一个能听懂自然语言的项目助理：给它一堆素材，它能做识别、分类、结构化，再按照我定的规则批量产出代码和版式。尤其是“批量”这一点，设计软件里我要复制样式到每一张画板，WorkBuddy 里我只需要改一条规则，所有海报会重新按新规则生成一遍。对我这种不是专业设计师、但又经常要给活动做展示物的人来说，这种“规则驱动”的工作方式比手工拖拽高效太多了。

而且，WorkBuddy 支持把规则保存成全局配置，后续所有对话和任务都会自动加载。这意味着这次的视觉规范一旦定了，下次做其他大会的展示图，我可以直接把整套规则复用到新项目里，不用从零开始再调一遍样式。

2. 信息重构：比画海报更先要做的事

2.1 给截图分优先级：哪些信息有资格上墙

截图的原始信息量很大，但海报的承载能力有限，所以第一步是筛选。我按这样的标准给11张截图的内容分了级：

• 保留：项目名称、大会主题、明确的时间地点、可验证的数据指标、行动入口（比如扫码、访问链接）。
• 降级：装饰性文案、重复出现的背景信息、小到无法辨认的次级说明、与展示目标无关的现场氛围描述。
• 直接丢弃：模糊的照片区域、大面积的留白或遮挡、与其他截图重复的内容。

举例来说，那2张官网首页截图里，顶部导航栏和底部备案信息肯定不上墙，但首页主视觉里的口号和核心按钮文案要保留；3张议程截图里，我只需要提取“主论坛”“圆桌讨论”“发布仪式”三个关键场次的信息，其余每个演讲的详细时间轴，在6张海报的体量里放不下，直接舍弃。

这一轮筛选做完，11张截图的信息被压缩成了大约4个主题：大会总览、技术发布、现场体验、数据回顾。这就是6张海报的内容基础。筛选完之后才轮到 WorkBuddy 上场做结构化，而不是一上来就让它“设计好看点”，那样它只会给你一堆漂亮的空壳。

2.2 用一套 JSON 结构统一信息口径

筛选出的信息不能直接丢给排版环节，中间需要一个标准格式。我让 WorkBuddy 把所有提取结果统一成一个 JSON 数组，每张海报对应一个对象，字段固定，便于后续校验和渲染。

结构是这样的：

[ { "scene": "大会总览海报", "title": "2026云栖大会 · 智能进化现场", "subtitle": "从大模型到具身智能，一天看完技术落地", "stats": [ { "label": "展区面积", "value": "超4万m²" }, { "label": "主题论坛", "value": "3场" }, { "label": "互动体验", "value": "12项" } ], "cta": "扫码回顾现场", "source": ["screenshot_01", "screenshot_03"] } ]

为什么用 JSON 而不是让 WorkBuddy 直接输出文案段落？因为海报是一个典型的“结构化渲染”场景。每一张海报都是由标题、副标题、指标、行动入口等固定插槽组成，用 JSON 定义好字段，后面才能让 WorkBuddy 批量生成六个页面时保持字段顺序一致、排版位置一致。如果第一阶段让 WorkBuddy 自由发挥写散文式文案，第二阶段再想统一成海报版式，字段对不上，会很痛苦。

在使用 JSON 的时候，我加了一条关键规则：数据不能编。WorkBuddy 提取的信息必须能从某一张截图里找到出处，来源字段要标注截图编号。比如“超4万m²”这个数据，如果直接从某张展板照片里读出来的，那没问题；如果截图里没有这个数字，而是模型根据“规模很大”推测出来的，我会在实际核对后删掉或者改成定性描述。做展示图最忌讳的就是数字失真，尤其是挂在现场的海报，被人发现数据对不上，非常尴尬。

2.3 让 WorkBuddy 提取信息时的任务规则怎么写

第一次我把截图拖进 WorkBuddy 就开始提问“帮我做成海报”，结果它回了一堆泛泛的设计建议，没什么用。后来我把任务拆成两轮，第一轮只做信息提取，第二轮才做视觉生成，任务描述也写得非常具体。

第一轮任务描述大概是这样的：

“请分析我提供的11张截图，这些素材来自云栖大会现场和官网。你要完成以下工作：1. 忽略所有导航栏、页脚、装饰性图形；2. 提取可用于海报展示的核心事实，包括大会主题、时间地点、关键演讲场次、可验证的数据指标、行动入口文案；3. 把内容聚类为6组，每组对应一张海报；4. 输出 JSON 数组，每个对象包含 scene、title、subtitle、stats、cta、source 字段；5. 所有数据必须能在截图中找到对应证据，并在 source 里标注截图编号；6. 对没有明确数据支撑的内容，一律标记为 null，不得自行填充。”

这一段看起来不复杂，但里面每一条都在约束行为。第1条避免了它把截图里的广告横幅也识别成内容；第5条把握住了真实性；第6条给了它一个安全出口，没有信息就别硬编。实际跑完第一轮后，输出结果基本能用，但还是有两处需要我人工修正：一处是某张展板照片因为透视变形，WorkBuddy 把“12项”误读成了“12个”，我对照原图改成统一的单位；另一处是它把官网截图中一个轮播图的临时文案当成大会主题抓了出来，我在 review 时删掉了，则以现场主舞台背景上的大会正式名称为准。

这一轮跑完，我手里就有一份经过校验的 JSON 信息底稿。到这一步，信息重构的工作算是完成了，后面的视觉重构都建立在这份底稿之上。

3. 视觉重构：六张海报的统一规范从哪来

3.1 先把“统一”翻译成具体参数

很多人以为统一风格靠的是审美，其实在批量生产海报的场景里，更重要的是把“统一”落实成一个个可以被执行的参数。我一开始就跟 WorkBuddy 定了这样一套规则，你可以直接抄：

• 画布尺寸固定为 1200x1600 竖版。这个比例在手机端阅读舒服，在展位上竖放也比横版显眼。如果将来需要投屏或者打印，再按比例放大就行。
• 采用12列栅格系统，所有元素的对齐都以列为单位，间距只允许使用8的倍数。这样无论哪张海报，元素的边距关系都在一个可预期的节奏里，不会出现某张海报紧凑、某张海报松散的情况。
• 中文字体用思源黑体，英文字体用 Inter，不引入其他字体。字体一旦多了，海报的“团队感”就散了。
• 主色用深蓝 #0B24FB，强调色用亮橙 #FF6A00，底色固定为浅灰 #F7F8FA。这套配色是从大会主视觉里提取的，既延续了现场的品牌感，又比原截图的杂乱背景干净。
• 标题不超过16个字，超过就强制拆成两行；正文行宽控制在35到45个字，保证阅读舒适度。
• 每张海报右下角必须预留 120x120px 的二维码区域，并标注“扫码观看现场记录”。

这些规则不是凭感觉定的，是我结合前面那个 JSON 里的字段数量和大会现场的展示需求推出来的。12列栅格和8的倍数间距看着约束人，实际上大大减少了“这里要不要再挪一挪”的决策成本，也让六张海报之间互相切换时，视觉节奏是一致的。

3.2 用 CSS 变量当视觉规范的可执行版本

因为 WorkBuddy 可以通过生成 HTML 和 CSS 来输出海报版式，所以我干脆把视觉规范直接写成了 CSS 变量。这样做的好处很明显：想调整主色调的时候，我只改一个变量的值，六张海报会全部跟着变，不用一张一张手动联动。

我用的变量长这样：

:root { --wb-font: "PingFang SC", "Microsoft YaHei", sans-serif; --wb-maxwidth: 1200px; --wb-grid-columns: 12; --wb-gap: 8px; --wb-radius: 16px; --wb-bg: #F7F8FA; --wb-ink: #1A1A1A; --wb-primary: #0B24FB; --wb-accent: #FF6A00; --wb-qr-size: 120px; }

CSS 变量本身不复杂，但在这个流程里它起到了“视觉宪法”的作用。六张海报的 HTML 是各自独立的文件，通过引用同一个 style.css 获得全部样式变量，这样即使每张海报的内容完全不同，底层的字体、颜色、圆角、间距体系也是一套的。我在实操中还加了一条，所有组件的高宽、边距都直接引用 var()，而不是写死像素值。这样做的好处是，后面如果决定把画布从 1200x1600 改成 1080x1920，我只需要调整一个变量，整个版式会按比例重新排布，不至于出现内容错位。

3.3 版式模板：不同海报的信息动线

有了全局规则，接下来就是每张海报内部的布局。我把6张海报分成了三类版式模板，分别对应不同内容结构：

第一类是“总览型”，用于大会主视觉海报。信息从上到下依次是：大会名称、主口号、两个核心数据、活动信息。这类海报不需要放太多内容，重点是气势，所以留白空间很大，主标题占整张海报高度的四分之一以上。

第二类是“结构化型”，用于展区介绍、体验项目这类有多条并列信息的海报。我会把信息切成卡片，每张卡片占据3列，一行放3个，正好填满12列。卡片内部结构固定：图标区、标题、说明文字、引用来源。这种模板最大的优点是可扩展，如果某张海报的卡片数量从6个变成9个，栅格自动重排，不需要改样式。

第三类是“数据型”，用于数据回顾和成果展示。统计指标用大数字排版，数字用强调色，标签用次级灰色。数据型海报最容易做乱的地方是数字单位不统一，所以我在 JSON 阶段就让 WorkBuddy 把所有数字格式化成同一风格，保留合理的小数位，并且同一张海报里单位用了“m²”就全部用“m²”，不能忽而“平方米”忽而“m²”。

这三类模板不是每个都从零画出来的，而是 WorkBuddy 根据我给的规则自动生成的初始版本，我再在浏览器里逐张看效果、微调细节。有了模板之后，第二轮的批量生成就变成了一件非常机械的事：六张海报往模板里填内容，真正花时间的反而是校对文案，不是排版。

4. 实操流程：跑通 11 到 6 的完整链路

4.1 素材入库与规则加载

实际操作时，我在 WorkBuddy 里新建了一个项目，命名为“云栖大会展示图重构”。这个命名不是随便起的，因为后续所有对话、中间产物、输出文件都会挂在这个项目下，名字清晰一点，后面回溯时就不用在多个项目之间翻找。

新建完项目，我先把11张截图按原始顺序拖入素材区。这里有个细节：拖入素材后，我在第一轮对话里先把全局规则文件的内容粘贴出来，明确告诉 WorkBuddy “以下规则后续对本项目的所有任务都生效”。这一步非常关键，因为 WorkBuddy 的规则加载是按项目维度的，如果你不在项目开始之前就声明规则，中途再补，部分已经生成的结果不会自动重新应用新规则，我试过一次，中途改规则导致前面出的两张海报样式跟后面完全不一致，只能重新生成。

素材和规则都就位后，我才发出第一个任务指令，就是前面提到的信息提取那套话术。这样处理，保证素材在前、规则在中、任务在后，WorkBuddy 在没有歧义的状态下开始工作。

4.2 第一轮处理：从截图到结构化 JSON

第一轮处理我全程盯着它的输出。WorkBuddy 在完成信息提取后，会把识别到的内容分成若干片段，归类、去重，并生成 JSON。这一步它会自动做很多好事，比如它会发现官网截图和现场照片里都提到了同一个展区名称，然后合并成一条记录，来源标注里写清楚这张是从哪两张截图里对出来的；它也会把“4万+平米”和“超4万平方米”识别为同一数据，统一成“超4万m²”。

但机器识别的结果不能直接信。我拿到第一版 JSON 后，做了一次人工校验，重点看三件事：一是数据是否存在，二是单位是否准确，三是名称是否与现场主视觉一致。校验过程中我发现一个问题：某张现场照片里有一块展板，上面写着“2026云栖大会”，但那张展板其实是往届回顾展区的内容，WorkBuddy 把它当成了本届大会的主标题，我在核对时把它改成了官网首页上带有本届日期的主标题。这个错误不严重，但如果不改，最后总览海报上的年份就会出错。

人工校验完成后，我把修正版的 JSON 回传给 WorkBuddy，同时发给它一份简短的字段说明：“以下 JSON 已经人工确认，请以它为准生成后续内容。”这里要让 WorkBuddy 明确知道，后续生成不要再去原生截图里猜测数据，一切以 JSON 里的内容为最终事实来源。

4.3 第二轮处理：批量生成 6 张海报底稿

第二轮的任务描述我开始往视觉细节上聚焦。大概是这样：

“基于已确认的 JSON 数据，生成6张海报页面。要求：每张海报是一个独立的 HTML 文件，目录结构为 /posters/01-total/index.html 这样的格式；所有页面必须引用同一份 /assets/style.css；严格按照全局视觉规则排版；数据只来自 JSON，不得新增、删减或修改数据；每个页面要预留二维码区域，用 120x120 的占位符表示。”

WorkBuddy 很快生成了6个 HTML 文件和一份样式表。我在浏览器里逐个打开，整体效果已经接近成品，只有两处需要微调：一是有张海报的标题太长了，按16字上限一拆，第二行只剩一个词，视觉重心不稳，我把它简化成更短的口号；二是另一张海报的副标题行宽超过了45字，我调整了字号系数，让它在视觉标准内自动缩放。

这一步的体验让我觉得 WorkBuddy 最顺手的地方不是“一次生成完美”，而是“出了偏差容易修”。因为底层是 HTML 和 CSS，我可以在浏览器里实时调试，改一个间距、调一个字号，刷新就能看到效果，不用回到复杂的图像编辑界面里逐像素拖动。它相当于把“设计”这件事从图像空间搬到了代码空间，修改成本低了很多。

4.4 导出与命名规范

海报底稿确定之后，我需要把它们导出成图片。WorkBuddy 可以直接把 HTML 页面渲染成 PNG 或 JPG，我选择了 PNG，因为海报里文字多，PNG 的清晰度更稳。导出时我统一用浏览器渲染的方式，保证样式与预览完全一致，不会出现“导出后字体被替换”或者“圆角被裁掉”这类意外。

文件命名我用了固定的规则：两位数字编号 + 海报用途 + 版本号。比如 01-total_v1.png、02-launch_v1.png。不要用“最终版”“最终版2”这种命名，做项目的人都知道，过两天你就会因为“最终版3”找不到之前的版本。生产环境里的文件命名越机械化越好，我连日期都按 YYYYMMDD 的格式处理：01-total_20260412.png。

命名规范这件事看起来稀松平常，但其实非常影响后续协作。我把6张图发给团队后，大家直接在文件名上就能定位“02 是发布主题的”“05 是数据回顾的”，要提修改意见也不用先打开图片确认是哪一张，沟通成本直接就降下来了。

5. 六张海报的统一检查清单：避免“六人六色”

5.1 对照检查清单逐项过一遍

WorkBuddy 生成的六张海报，单看每一张都没什么问题，但放在一起，人眼会立刻察觉到不和谐感。我总结了一个检查清单，每次批量出图后都逐项过一遍：

• 标题长度。所有海报的主标题是否都控制在16字以内，有没有一张的标题因为太长而换行变成三行。
• 间距节奏。所有元素的外边距和内边距是否都遵循8的倍数，有没有出现 5px、13px 这种突兀的间距。
• 数字与单位。全场的数字是否统一样式，比如统一用“m²”就不要出现一张写“平方米”。
• 二维码区域。每张海报右下角的二维码占位是否都在 120x120，位置是否完全对齐，不能有的一张靠边、一张偏中间。
• 字体渲染。中文字体是否统一，有没有出现某张海报因为缺字而回退到宋体的情况。
• 色彩使用。主色、强调色、底色是否严格从变量里取，有没有某张海报“顺手”用了一个颜色代码里不存在的灰色。

这个检查清单里，大部分项目可以在 WorkBuddy 里通过规则自动确保，但有一些必须人眼确认，比如标题拆行后的重心、副标题的长短视觉差异。我建议你把这份清单保存下来，每次批量生成文件后不急着发，先花五分钟对着过一遍。

5.2 把规则沉淀成全局配置和 Skill

这次项目结束之后，我把整套视觉规范从项目里抽出来，保存成了 WorkBuddy 的全局规则文件。以后再新建任何展示图项目，WorkBuddy 会自动加载这些规则，而不需要我重新复制粘贴一遍。这一步做起来很简单，但价值很大，尤其对经常需要做活动物料的人来说，等于把“个人品牌视觉风格”固化成了可复用的资产。

更进一步，我把“从截图到海报”的完整流程做成了一个 Skill。Skill 相当于一段封装好的工作流，里面包括任务拆解顺序、JSON 字段定义、文案规则、版式模板、检查清单。下一次我再拿到一堆活动截图，只需要调用这个 Skill， WorkBuddy 会自动按我预设的流程推进：先提取信息、再生成 JSON、再套模板出图，最后还会主动提醒我跑一遍检查清单。这个方法极大地降低了每次做展示图的启动成本，让我可以把精力省下来去做内容判断，而不是反复做重复劳动。

6. 翻车记录与排查技巧

6.1 文字量溢出导致海报标题被截断

第一次生成的时候，有一张海报的标题被截成了半行，原因是 JSON 里那段标题文本太长，超过了 CSS 里设定的一行高度。排查时我先在浏览器控制台里看了一下元素的高度，确认不是字体渲染问题，而是标题字数超出了预期。修复办法很简单：缩短文案，而不是调小字号。在海报里，标题被截断的根因几乎都是文案太长，强行缩小字号会破坏视觉层级。我把标题从20字压到14字，问题立刻消失。

6.2 二维码被拉伸变形

有一张海报导出后，二维码区域的二维码图片被拉伸了。正常情况下二维码区域是一个固定 120x120 的容器，但那张海报的 HTML 里给容器加了 flex 属性，导致子元素被拉长。排查时我发现是模板里对图片的 object-fit 属性定义遗漏，修复方式是给二维码容器加上 object-fit: contain，并把容器尺寸固定死。这类小错误在手动设计软件里不容易出现，但在代码生成环节很常见，检查清单里加上“二维码是否变形”这一项很有必要。

6.3 截图背景被识别为正文内容

第一次跑信息提取时，WorkBuddy 把某张截图里展板上的装饰线条描述也识别成了内容，放进副标题里，导致海报文案读起来很奇怪。这说明图像识别阶段需要更明确的过滤指令。后来我在任务规则里补充了一条“忽略装饰性线条、图形、水印、人物面部信息”，并在第二轮提取时用了重跑机制，问题没有再犯。

6.4 缓存目录占满磁盘

做这个项目的时候，我发现 WorkBuddy 的缓存目录占用涨得特别快，跑了几轮高清渲染之后，系统盘空间直接告急。后来我在设置里把缓存目录改到了数据盘，并定期清理临时渲染缓存。这里有一个提示：改缓存路径不会删除对话记录和项目文件，只是把临时文件搬走，所以可以放心操作。如果你也遇到缓存占用问题，优先检查渲染输出和临时文件目录，而不是清理项目数据。

6.5 新开会话后规则丢失

有一次我新开了一个会话想继续调整海报，结果 WorkBuddy 没有自动带上项目规则，生成了完全不符合规范的版本。后来我发现规则需要在项目初始化阶段声明，或者调用已经保存的 Skill 来加载。跨会话记忆不是默认开启的，它是一个可以被训练的能力。我现在会在项目开始的第一条消息里就把规则声明清楚，或者直接在项目描述里写“本项目的视觉规范见 /rules/visual-rule.md，所有任务必须遵守”，这样即使新开会话， WorkBuddy 也会先把规则文件读进来再执行任务。

我个人经验是，做这种多轮迭代的视觉重构项目，比提示词技巧更重要的，是先想清楚信息架构和视觉规范。WorkBuddy 真正帮到我的地方，不是替我做审美判断，而是让我把“信息筛选—文案结构化—批量排版—统一检查”这一整套流程串成了一条流水线，我能把精力放在内容质量上，而不是不断重复地调整像素间距。最后再分享一个小技巧：把每次任务的规则文件和检查清单都沉淀成文本放在项目目录里，这个习惯能让你在三个星期后打开一个旧项目时，依然比当事人更清楚当时到底定过哪些规则。