一句话需求 → 专家团协作 → 真实站点落地。本文以「Lumicore Optoelectronics 外贸 B2B 灯饰官网」为例，拆解从需求到上线的完整节点、工具调用与踩坑修复，可直接照做。

一、需求起点：一句"随意"的话

用户的原始需求只有一句话：

「帮我创建一个灯饰的品牌官网，外贸 B2B 询盘类型的，页面需要的图片和产品以及新闻、询盘，你按照需求自行处理补充。」

这句话信息量很大，但留白也很大——品牌名、语言、页面清单、产品/新闻内容、配图来源、询盘表单怎么绑，全部需要补全。这正是「可运营网站」与工作流的价值所在：把模糊需求结构化为可执行、可验收的交付。

要点：遇到"自行补充"类需求，不要闷头瞎猜，也不要逐条追问打断节奏。正确做法是——先按行业*实践给出假设清单，在动手前用一次确认收口，既尊重用户授权，又保留 AI 补全的发挥空间。

二、谁在做：专家团 + 连接器架构

本任务由 「云指建站运营专家团」 承接。它不是一个人在写代码，而是一套标准协作机制：

底层依赖一个已发布的 yunzhi-mcp 连接器：用户在进入对话前完成 SiteID + Token 授权，连接后在「连接器 → 自定义连接器」统一管理。专家调用工具时无需手动处理凭据，所有线上读写都走这个连接器。

2.1：找到建站专家团

2.2:链接通过id和token链接mcp

2.3:获取建站后台的站点id和token

2.4:填入获取到的id和token 链接mcp

三、工作流总览（四阶段 SOP）

【阶段 0】澄清与建团 — 定目标、建团队、通报上下文

【阶段 1】路由与调度 — 按类型派单、下发子任务

【阶段 2】连接确认 — test 站点、核对现状

【阶段 3】落地与收尾 — 专家执行、主理人核对、上线

本次是复合型任务（新建整站），主路由给「建站专家」一次跑完，SEO/GEO/获客作为后续可接力的阶段。动线上站点前，阶段 2 的连接确认是铁律。

四、阶段 0 · 澄清与建团

4.1 先确认连接器连通

调用 yunzhi-mcp.test 做健康检查（回显通过即说明连接器在线）。它只回显文本、不含站点信息，所以真正确认"连的是哪个站点"要靠读真实数据。

4.2 读取现状 + 建团

主理人并行发起 6 次查询（get_site_seo / list_page / list_product_class / list_news_class / list_custom_form / get_enquiry_form_id），确认这是一个全新空白站点：无页面、无分类、无新闻、无自定义表单，但系统已自动初始化一个在线询盘表单 72931。

随后主理人亲自 TeamCreate 建立团队 yunzhi-lumicore-b2b，向成员通报边界与上下文（严禁成员代建团队、严禁成员互相直连）。

4.3 假设清单 + 一次确认

基于"外贸 B2B 灯饰"*实践，主理人给出假设并请用户确认：

铁律：联系页与询盘页的表单必须是不同 ID，平台约束不允许两页共用同一表单。因此联系页需 add_custom_form 新建一个。

五、阶段 1 · 路由与调度

新建整站属于「建站专家」主责，主理人下发一份自包含子任务：把已确认的站点状态、品牌设定、产品/新闻规划、表单绑定、全部平台约束一次性写清，专家据此独立执行，无需再回头追问。

子任务关键约束（直接决定成败，必须写进派单）：


六、阶段 2 · 连接确认（动线上站点）

专家开工前再次 test 确认目标站点，并基于阶段 0 的空白站点现状开始写入。关键提醒：本次连接的实际 SiteID 是 82572，与用户旧记忆里的 80676 不同——动线上站点一律以 MCP 实际返回的 SiteID 为准，不沿用旧记忆。

七、阶段 3 · 建站专家落地（核心实操）

建站专家按以下顺序在空白站点上从零搭建，每类资源先建后取 ID，再被后续步骤引用：

7.1 公司信息

edit_company_info 设置：站点名 Lumicore Optoelectronics、公司全称、邮箱 sales@lumicore-led.com、电话、广州地址等。页尾联系信息可读取系统值，也可直接写。

7.2 产品分类（6 个一级，parentId=0）

add_product_class 逐个创建，记录返回 ClassID：

7.3 AI 配图 + 上传

用 ImageGen 生成产品主图与新闻配图（产品图建议压缩为 WebP 节省生图额度），再通过 upload_product_image（产品图）和 upload_file（新闻图）上传，取回文件名用于后续绑定。

7.4 上架产品（10 款）

add_product 立即发布，按分类分配，mainImage 用上传返回的文件名原样传入。每款写 summary 与 content（JSON 多详情，含 Product Description + Specifications 表，参数含功率/光通量/色温/尺寸/CE RoHS 认证）。

7.5 新闻分类 + 5 篇新闻

add_news_class 建 Company News (1)；add_news 发 5 篇（status=1），含配图、英文 HTML 正文、descriptor 摘要与 SEO 三项。示例 ArticleID：8806158–8806162。

7.6 联系表单（独立自定义表单）

add_custom_form 建 Contact Us，返回 FormID = 151453。字段用临时 ID 起步：公司名 / 联系人 / 邮箱(邮箱校验) / 电话 / 国家(国际地区) / 产品兴趣(下拉) / 留言。开启邮件通知至 sales@lumicore-led.com。

7.7 页面构建（8 页）

save_ai_page 逐页保存，设计系统统一：深海蓝 #0f3d5e + 琥珀金 #ffb400，移动端 1024/768 双断点 + 汉堡菜单。

八、阶段 3 · 主理人独立核对（不要只信汇报）

专家说"全部建成"不等于真的建成。主理人独立发起核对，不采信专家汇报，直接读真实数据：


为什么这步不能省：get_product_list(0) 返回的 ClassID 字段为空，若只信列表会误判"分类没绑上"。必须用具体 classId 反查验证，才能确认筛选功能真实可用。

九、可复用操作清单（Checklist）

照着这份清单，任何人都能复现一次标准建站：

十、关键经验与避坑

十一、结语

从一句"帮我建个灯饰官网"到 8 个页面、10 款产品、5 篇新闻、双表单询盘的真实站点上线，耗时约 35 分钟。真正的"可运营"不仅在于页面能打开，更在于：需求被结构化、资源 ID 可追溯、平台约束被遵守、交付被独立核对。这正是 WorkBuddy 建站工作流的价值——把一次性的 AI 生成，变成可复盘、可复用、可接力的标准动作。