客户想用 AI 建站，真正要算哪些成本？
产品多、语种多的外贸企业想用 AI 降低独立站成本，却不知道省的是开发还是长期维护？这份成本拆解从产品结构、多语言、后台、审核和回滚入手，说明选型前真正要算的投入。
分享一个最近的客户咨询（客户信息已经脱敏，仅分享我们在其中的一些判断）。
客户是一家外贸工厂，准备利用 AI 建一个新的独立站。现有产品记录有几百条，计划覆盖英语和多个小语种。他不是第一次建站——之前参考同行网站做过一版，最后没能真正用起来。
这次他自己学了不少 AI 建站的东西，想法很明确：用 AI 把人力和成本降下来。
这个方向没错。但聊下来我发现，这类客户常有一个认知差——知道 AI 能省钱，却不知道在自己的项目里到底省哪一段。
下面是我们怎么跟他把这件事拆分清楚的。
我们做这类咨询，不是先推一个自己熟悉的技术栈，而是先梳理产品规模、内容量、维护方式和交付边界，再给出技术咨询和方案建议。网站用什么建，要从这些条件里推出来。
一、第一次建站为什么没能真正用起来？
客户坦诚，第一次建站是找人参考同行网站做的。这种做法很常见：没有成熟的判断标准时，同行网站可以帮助我们快速了解页面类型、信息展示和用户路径。
但参考不等于照搬。你看到的是同行网站呈现出来的页面，却很难看到它背后的产品规模、语言数量、更新频率和维护流程。
假设对方只需要管理几十个产品和一种语言，而你要管理几百条产品、多个语种，还要持续增加新品。即使页面看起来一样，内容结构和后台维护的复杂度也完全不是一个量级。
所以，第一次建站没能真正用起来，问题不一定是页面做得不好，而是当时采用的内容结构和维护方式没有按照自己的业务体量重新设计。
二、产品可以分批上，但结构要按未来规模设计
我们先确认了三件事：总共有多少产品，首期准备上线哪些，后续多久更新一次。
客户虽然有几百条产品记录，但没必要在首期全部做完。更合理的方式，是先选择核心品类和代表性产品，把主要语言的内容、询盘路径和后台维护流程跑通，再逐步补充其他产品和语种。
**但分批上线不等于先按一个小网站临时搭建。**产品总量和多语言需求，仍然会影响分类方式、内容字段、URL 规则和后台结构。如果前期完全不考虑扩展，首批产品上线可能很快，后面增加产品时，分类和内容结构还是要重新调整。
筛选功能也没必要一开始全部开放。前期更重要的是把材质、工艺、规格和系列等信息拆成规范的产品属性。等某个分类下的产品多起来，用户确实需要缩小范围时，再把合适的属性开放为筛选条件。
真正有独立搜索需求、也能提供独立内容的组合词，可以单独做落地页。筛选 URL 是否被收录，也要在上线前规划好。
所以这类项目真正要解决的，不是怎样一次做完几百个产品，而是首期做什么，以及以后怎么稳妥地扩展。
三、AI 能省成本，但不只是在建站阶段
很多关于 AI 建站的介绍，强调的是更快、更便宜地完成首版网站。这部分确实能省，我们也会根据项目情况，用 AI 缩短开发和内容整理的时间。
但对于产品多、语种多、还要持续上新的外贸站，首版开发只是阶段性投入。网站上线后，产品资料整理、多语言内容、页面更新和内容同步会不断发生，这些成本会随着时间持续累积。
AI 在这个项目里更适合承担两类工作：一是根据已经确认的资料和模板，辅助生成多语言内容初稿；二是在权限和规则明确的前提下，执行批量录入、格式调整和一部分页面改动。工艺事实、品牌表述和最终发布仍然需要人工确认。
能省下多少，不只取决于用了什么 AI 工具，也取决于建站时有没有把内容字段、导入导出、预览审核、版本记录和回滚机制设计好。
如果前期没有考虑这些，后面仍然可以接入 AI，但通常需要补做数据整理和接口改造。网站可能建得很快，后续维护却不一定轻松。
这就引出下一个问题：后台怎样设计，才能让运营人员看得见、改得动，也让 AI 的改动可审核、可回滚。
四、后台维护：选型决定的是明年谁能改这个站
客户一开始问的是：AI 维护是个黑盒，不知道它给你加了什么，是不是用 WordPress 更好？WordPress 有图形界面，后台看得见。
这个担心是合理的。但他真正需要的，不只是一个看得见的后台，还包括改动可追踪、发布前能预览、出了问题可以回滚。WordPress 是他先想到的方案，不是这个需求的唯一答案。
**我们先把页面分成两类。**产品名称、规格和参数经常变化，又直接影响询盘，运营人员需要能够在后台修改和确认。博客文章、采购指南和落地页，可以让 AI 根据资料和模板生成初稿，但工艺事实、采购建议和品牌表述仍要由人验收。
因此，选型时真正要比较的是四件事：运营人员能不能自己修改，AI 能不能批量处理，改动能不能追踪和回滚，以后换人能不能顺利接手。
围绕这些要求，我们选了三条有代表性的路线进行比较：Next.js 配合代码或 Headless CMS、WordPress，以及 Statamic 这类默认支持文件内容的 CMS。它们不是全部选项，而是代表三种不同的内容管理方式。
Next.js 路线。 Next.js 是开发框架，本身不等于内容后台。如果内容跟着代码管理，改动需要经过代码审核和部署；如果另外接入 Headless CMS，运营人员也能使用图形后台，但系统组成和维护复杂度会增加。
WordPress 路线。 WordPress 的后台比较成熟，运营人员容易上手。多语言通常通过插件或多站点方案实现，实际复杂度取决于产品结构和翻译流程。内容存在数据库里也不妨碍 AI 批量处理，可以通过 REST API 或导入导出完成，但权限、审核和回滚仍要提前设计。
Statamic 路线。 Statamic 默认可以把内容存成文件，同时提供图形后台和多语言结构。AI 在获得明确的仓库权限和操作规则后，可以处理内容文件，再经过预览和发布流程。它也能改用数据库，多站点属于 Pro 功能。需要考虑的是授权、PHP 运行环境，以及以后由谁继续维护。
结合这个项目的内容量、多语言需求和维护角色，我们建议优先评估 Statamic。原因不是它一定比其他方案更好，而是它在这个项目里同时兼顾了运营后台、文件型内容和 AI 批量处理。最终是否采用，还要看客户对交接成本和技术环境的接受程度。
不管最后选择哪条路线，比选型更要紧的是交付什么。
我们建议除了源代码，还把一套 AI skills 和一份 AGENTS.md 列入交付清单。说白了，就是写给 AI 看的项目说明书：内容放在哪里、改动要遵守什么规则、哪些地方不能碰。
版本记录、预览环境和改动前后的对比，可以让“AI 到底动了什么”变成看得见的东西。基础的查看、对比和回滚流程可以培训；涉及代码、部署或高风险数据改动时，仍应由开发人员处理。
后台和交付方式说清楚后，接下来还要确认一件事：多语言内容发布出去，搜索引擎能不能分别找到。
五、多语言：做搜索，每个语种最好有自己的链接
他问过一句挺关键的话：每个小语种都有单独的链接吗？
我们接触过的不少外贸站。有的是在站上嵌一个浏览器端翻译工具，语言一切换，页面看起来就有了多个语种——这也正是“省成本”最容易走错的地方。
问题不在于用了插件，而在于插件输出了什么。有些插件能生成独立 URL 和 hreflang，一样可以做多语言 SEO。**真正要看的是：有没有可抓取的独立 URL、完整译文、内链和站点地图。**如果只是用户点击后才临时换字，搜索引擎可能仍然只看到默认的英文内容。
**面向多语言 SEO，更稳妥的做法是给每个语言版本独立 URL，再配上 hreflang、内链和站点地图。**URL 可以放在子目录、子域名或独立域名里。这些设置能帮助搜索引擎理解各语言版本，但不保证收录和排名。最好建站时就定好；后补也能做，只是迁移成本更高。
而 AI 在多语言这件事上改变的，是内容生产的成本结构，不是 SEO 的基本做法。 以前因为成本太高而放弃完整翻译和持续更新的内容，现在更有机会做起来了。所以对这类客户来说，当下更值得先做的不是研究怎么讨好 AI 搜索，而是把过去因为成本放弃的基础工作补回来。
六、询盘进来以后：先搭 CRM 流程，不急着定制
此外，这次咨询还涉及一个与网站上线后承接询盘直接相关的问题：CRM。
外贸站上线时，至少应该有一套基本的询盘跟进流程。工具不一定是定制的 CRM，但谁来接、怎么记、什么时候跟、怎么交接，至少要说清楚。询盘少时靠人记还行，量一上来就容易乱。
但我们的建议是：这个阶段搭，不要定制。
他要的只是常规客户管理：潜在客户、现有客户、跟进记录。现成的 SaaS 或模板基本都能覆盖，上线更快，成本也低。等到深度集成、特殊流程或合规要求确实满足不了，再谈定制。在那之前，定制出来的东西大概率还不如成熟产品好用。
我们做定制 CRM 和 ERP，但前期该做的是把跟进流程跑起来，不是先花钱造一个工具。
最后
他最开始问的是“该用什么建”。聊到最后，我们先把三个问题说清楚：首期上什么、谁来维护、AI 参与到哪一步。
AI 可以缩短首版开发，也能减少后续内容处理和页面维护中的重复工作。前提是内容结构、权限、审核、版本记录和回滚机制在建站时就一起设计好。
整个过程，我们没有急着先报一个数字。先把项目体量、内容结构和维护方式弄清楚，再谈方案和价格。我们更愿意先把项目边界和长期成本说清楚，再给出可执行的方案。
相关阅读
需要进一步判断？
如果你正在评估 WordPress、AI 建站、多语言维护或技术交付方案，可以预约 Django Wong 做技术咨询。