从0开发一套geo优化软件：系统定位与整体架构

很多企业都会遇到一个现实问题：业务本身不错，但线上内容覆盖不够，用户在豆包、文心一言、通义千问、DeepSeek、Kimi 等 AI 应用里搜索行业问题时，很难第一时间看到这家企业。

这类软件要做的事情，不是简单帮用户写一篇文章，而是把"用户会搜的问题"整理成关键词和选题，再结合企业知识库生成内容，最后持续发布到站点、媒体或自媒体账号上。本文就从这个实际需求出发，拆一下如果从 0 开发一套 GEO 优化软件，整体架构应该怎么设计。后面会结合一个实际桌面端 GEO 工具的工程结构来说明，但重点还是讲技术方案。

1. 为什么要做桌面端

GEO 优化的关键不只是调用大模型，而是让内容能持续进入搜索引擎、AI 问答、媒体站点和自有站点。桌面端有几个优势：

可以管理本地 Cookie、浏览器环境、文件和 FFmpeg 工具。
可以通过 Puppeteer 执行第三方平台发布动作。
可以在用户电脑上跑定时任务，降低服务端自动化压力。
可以兼容「平台统一 AI 服务」和「用户自备 API Key」两种模式。

在桌面端方案里，Electron 13、ee-core、Vue 2、Element UI、Puppeteer、FFmpeg 是一组比较常见的组合。它不是为了堆技术栈，而是因为这类软件天然需要「运营工作台 + 本地自动化执行器」两种能力。

2. 总体分层

理解了为什么要做桌面端之后，下一步才是架构。因为 GEO 软件不是单页面工具，它既要有内容生产能力，也要有发布执行能力，还要处理账号、任务和商业规则。一套 GEO 优化软件可以拆成四层。

第一层是业务前端。frontend/src/views/app 下是主要页面，包括 keywords.vue、article-creation.vue、content-settings.vue、auto-operations.vue、soft-articles.vue、distribution.vue、accounts.vue 等。前端负责把工作流做成可操作的台面。

第二层是后端业务 API。项目中的 frontend/src/api/backend.js 和 frontend/src/api/business.js 体现了接口边界。关键词、文章、知识库、转化目标、文章风格、账号、分发记录、自动运营、软文投放、AI 配额都通过后端接口管理。

第三层是 Electron 主进程服务。electron/service/rpa.js 负责本地数据、AI 配置、发布历史和工具类能力。electron/service/autoOperation.js 负责读取后端自动运营任务、注册本地定时任务、生成文章并调用发布能力。

第四层是平台适配。electron/platforms 下有面向不同平台的自动化脚本，例如知乎、CSDN、公众号等发布逻辑。它们把统一发布参数翻译成平台页面操作。

如果画成架构图，大致是下面这样：

text 复制代码

┌──────────────────────────────┐
│ Vue 2 工作台                  │
│ 关键词 / 知识库 / 文章 / 自动运营 │
└───────────────┬──────────────┘
                │ axios + token + X-App-Code
┌───────────────▼──────────────┐
│ 后端业务 API                  │
│ 用户 / 额度 / 文章 / 任务 / 投放 │
└───────────────┬──────────────┘
                │ 任务配置、账号、内容数据
┌───────────────▼──────────────┐
│ Electron 主进程服务           │
│ AI配置 / 定时任务 / RPA执行器   │
└───────────────┬──────────────┘
                │ 统一发布 payload
┌───────────────▼──────────────┐
│ 平台适配层                    │
│ CMS / 公众号 / 知乎 / CSDN 等  │
└──────────────────────────────┘

项目里的 API 作用域处理也体现了这个边界。前端页面只调用 /articles、/keywords 这样的业务路径，真正请求时再统一补成 /apps/geo_app/articles：

js 复制代码

const APP_CODE = process.env.VUE_APP_APP_CODE || 'geo_app'
const APP_API_PREFIX = `/apps/${APP_CODE}`

const APP_SCOPED_PREFIXES = [
  '/keyword-groups',
  '/keywords',
  '/articles',
  '/knowledge-bases',
  '/auto-operations',
  '/soft-articles',
  '/ai-generation-tasks'
]

const withAppPrefix = (url) => {
  const normalized = url.startsWith('/') ? url : `/${url}`
  const matched = APP_SCOPED_PREFIXES.some(prefix =>
    normalized === prefix || normalized.startsWith(`${prefix}/`)
  )
  return matched ? `${APP_API_PREFIX}${normalized}` : url
}

这段代码看起来不复杂，但它把「产品业务域」和「通用后端能力」隔开了。后面即使复用同一套后端做其他行业产品，也不用把接口写死在页面里。

3. 核心业务闭环

架构分层解决的是系统怎么搭起来，但产品真正能不能用，取决于业务闭环是否顺。很多 AI 工具失败，不是模型不好，而是生成完内容后没有后续动作。从 0 开发时，建议先按这条闭环设计：

用户配置转化目标：品牌、公司、官网、行业、产品描述。
用户建立关键词分组：手动录入或 AI 拓词。
用户维护知识库：上传资料、添加文本、沉淀产品事实。
用户配置文章风格：正文风格、标题风格分开管理。
AI 根据关键词、知识库、转化目标生成选题和文章。
文章进入内容库，可编辑、导出 Word、发布、投放。
发布记录和投放订单回写，用于统计和复盘。
自动运营任务按时间重复执行这条链路。

这个顺序比先做「一个 AI 生成按钮」更稳，因为 GEO 的价值来自持续生产和分发，而不是一次性生成内容。产品链路应该围绕这条闭环展开，用户不是生成完一篇文章就结束，而是继续进入发布、投放和自动运营。

4. 客户端和后端的边界

frontend/src/api/backend.js 里定义了 APP_CODE = geo_app，并把 /keywords、/articles、/knowledge-bases、/auto-operations、/soft-articles 等路径自动加上 /apps/geo_app 前缀。这是一个重要设计：同一个后端可以服务多个 App，GEO 只是其中一个应用域。

前端只关心业务接口，Electron 服务只关心执行动作。后端负责权限、数据、额度、订单、任务状态和审计。这种边界能避免把会员、配额、订单等商业逻辑散落到客户端。

5. 最小可用版本怎么做

做到这里，问题就变成：第一版到底做多大？MVP 不需要一开始就支持所有平台。建议先做这些模块：

用户登录和 token 持久化。
关键词分组和关键词管理。
知识库文本录入。
文章风格和转化目标。
AI 生成文章。
文章列表、编辑、导出。
一个发布目标，例如自有 CMS 或一个内容平台。
AI 配额和使用日志。

做到这里，系统已经能完成「准备资料、生成内容、发布内容」的主闭环。后续再扩展软文投放、自动运营、多平台 RPA、会员订单和数据看板，产品就会从一个 AI 工具逐步变成内容增长系统。下一篇就可以继续往下拆：这样的闭环背后，数据模型和 API 应该怎么设计。