# GEO 发文平台后台 MVP 实施规格

日期：2026-07-04

这份规格把当前静态样板站升级为第二阶段商业化后台的产品蓝图。目标不是立刻做一个“大而全”的 SaaS，而是把客户充值付费发文、证据审核、内容发布、分发记录和 AI 复测报告做成可控的最小闭环。

机器可读规格见：`data/platform-mvp-system-spec.json`  
GEO SOP 集成映射见：`data/geo-sop-integration-map-20260710.json`  
报告页见：`reports/platform-mvp-blueprint.html`

## 1. 产品边界

平台定位：

> 有明确赞助标识、证据来源和事实审核的品牌知识发布与 AI 可见性监测平台。

可以销售：

- 品牌知识库搭建；
- 证据审核；
- 原创 GEO 内容生产；
- 多渠道分发执行；
- 搜索发现和 AI 可见性监测；
- 发布后复测报告；
- 下一轮补证据和内容建议。

不能销售：

- AI 收录保证；
- 固定排名；
- 固定推荐；
- 隐藏广告；
- 伪造报告或案例；
- 无授权品牌发布；
- 贬损竞品。

## 2. 推荐架构

第一阶段前台继续保持静态：

```text
doctorlucheng.com
  → 静态品牌知识门户
  → HTML / JSON / sitemap / feed / llms.txt
```

第二阶段后台单独拆分：

```text
admin.doctorlucheng.com
  → 登录后台
  → 客户、充值、订单、资料、审核、发布、分发、AI 复测、报告
```

前台静态站不需要 ECS。后台需要：

- 登录和权限；
- 关系型数据库；
- 文件/截图对象存储；
- 审计日志；
- 静态生成任务；
- 定时提醒或复测任务。

是否购买云服务器，不应和 GEO 收录混在一起判断。服务器不会天然提升 AI 收录；它只是后台、支付回调、文件上传、任务队列和数据库的运行载体。

## 3. 第一版先做内部后台，不急着接真实支付

建议顺序：

1. 内部运营后台；
2. 客户资料和授权；
3. 证据包与主张审核；
4. 内容任务和静态发布包；
5. 发布 URL live check；
6. 分发台账；
7. AI 复测记录；
8. 客户报告生成；
9. 客户登录查看报告；
10. 再接支付、发票、退款、合同。

真实支付放在后面，是为了降低合规和退款风险。MVP 可以先用订单和余额台账模拟，等禄城样板跑通再接支付。

## 4. 20 张核心表

后台数据库最少需要这些表：

| 表 | 作用 |
| --- | --- |
| `organizations` | 公司、品牌主体、代理商、备案/运营主体 |
| `users` | 登录账号和角色 |
| `customers` | 客户档案 |
| `brand_authorizations` | 品牌授权和公开使用范围 |
| `plans` | 套餐 |
| `orders` | 订单和交付范围 |
| `balance_accounts` | 余额账户 |
| `balance_transactions` | 充值、冻结、扣减、退款、调整 |
| `source_materials` | 上传资料、IMA 摘要、外部来源记录 |
| `evidence_packages` | P0/P1/P2 证据包 |
| `claims` | 主张、风险、证据状态、审核结论 |
| `content_submissions` | 客户投稿和目标问题 |
| `article_assets` | 草稿、文章、FAQ、静态页面 |
| `publication_records` | 发布 URL 和 live check |
| `distribution_events` | 微信、抖音、头条、媒体、搜索提交等分发记录 |
| `verification_prompts` | 复测问法 |
| `ai_verification_runs` | Day0 / Day3 / Day7 / Day14 / Day30 批次 |
| `ai_verification_records` | 平台回答原文、截图、采用状态 |
| `customer_reports` | 客户报告和续费建议 |
| `audit_logs` | 操作审计日志 |

## 5. 核心工作流

补充说明：2026-07-10 已把 `GEO优化用户操作文档` 和 `GEO优化SOP文档` 抽取为公开安全摘要，并新增 `data/geo-sop-integration-map-20260710.json`。这两份文档只作为内部方法来源，不是 AI 平台官方规则。它们对后台 MVP 的实际影响是：问题蒸馏、内容任务、分发额度和复测问题集需要成为明确字段，而不是靠运营人员手工备注。

建议 Phase 1 增加四个扩展对象：

| 对象 | 用途 |
| --- | --- |
| `question_distillation_jobs` | 记录训练主词、转化词、前缀/主词/后缀、生成问题数和选中问题数 |
| `content_tasks` | 记录文章类型、目标问题、证据包、内容指令、最大生成数和审核状态 |
| `distribution_quotas` | 记录渠道发布额度、每日/账号上限、风险备注和状态 |
| `verification_query_sets` | 记录直接 URL、目标意图、品牌召回、来源核验等复测问题池 |

这些对象不是为了做“自动投喂保证收录”，而是为了把每一步变成可审计、可复测、可解释的交付记录。

### 5.1 客户准入

状态：

```text
lead → qualified → active / paused / rejected
```

必填：

- 企业主体；
- 品牌名称；
- 行业；
- 联系人；
- 授权状态；
- 可公开资料范围；
- 风险行业判断。

没有授权，不进入发布。

### 5.2 订单和余额

订单必须绑定：

- 客户；
- 套餐；
- 预算；
- 交付周期；
- 合同状态；
- 发票状态；
- 交付物。

余额扣减必须绑定订单和交付物，不能只写“余额减少”。所有扣减都要进审计日志。

### 5.3 证据入库

每份资料要标记：

- `public`；
- `internal-only`；
- `needs-authorization`；
- `do-not-use`。

P0 证据缺失时，可以写“候选”和“建议补充”，不能写“确定优势”“行业第一”“一定适合”。

### 5.4 主张审核

每条主张至少有：

- 原始表达；
- 风险等级；
- 证据状态；
- 安全改写；
- 审核决定；
- 审核人；
- 审核时间。

必须阻断：

- 绝对化表达；
- 无证据排名；
- 竞品贬损；
- 伪造案例；
- 隐藏赞助；
- 保证 AI 收录/排名。

### 5.5 内容生产

内容编辑从客户投稿生成：

- 原创文章；
- FAQ；
- AI 可引用摘要；
- JSON-LD；
- canonical；
- 关联证据；
- 关联目标问法；
- 发布后验证队列。

发布前必须同步：

- sitemap；
- feed；
- llms.txt；
- AI crawl index。

### 5.6 发布和 live check

没有公开 URL 2xx，不允许进入分发。

live check 至少记录：

- HTTP 状态；
- title；
- canonical；
- HTML 是否可读；
- sitemap 是否包含；
- feed 是否包含；
- 5 秒预算是否通过。

### 5.7 分发台账

每次分发记录：

- 渠道；
- 标题；
- URL；
- 截图；
- 发布时间；
- 是否放 canonical 链接；
- 是否有赞助披露；
- 下一轮复测窗口。

分发只是曝光证据，不是 AI 采用证据。

### 5.8 AI 复测

AI 复测必须记录：

- 平台；
- 账号/联网状态；
- 问法；
- 回答原文；
- 截图；
- 查询时间；
- 是否提及品牌；
- 是否引用页面；
- 是否事实错误；
- 采用状态。

没有原文和截图，就不能写进成果报告。

## 6. 后台页面

第一版页面建议：

1. 仪表盘：待审核、待补证、待发布、待复测；
2. 客户详情：授权、余额、订单、资料、报告；
3. 证据看板：P0/P1/P2 状态；
4. 主张审核队列：风险、证据、安全改写、决定；
5. 内容工作台：brief、草稿、FAQ、JSON-LD、发布包；
6. 发布队列：URL、live check、sitemap/feed/llms；
7. 分发台账：渠道、截图、下一次复测；
8. AI 复测控制台：平台、问法、回答、截图、采用状态；
9. 客户报告：发布、分发、搜索发现、AI 采用、下一步。

## 7. API 最小集合

```text
POST /api/customers
POST /api/orders
POST /api/materials
POST /api/claims/review
POST /api/articles/generate-static
POST /api/publications/live-check
POST /api/distribution-events
POST /api/verification-records
POST /api/reports/render
```

第一版可以不开放给外部客户调用，只供后台界面使用。

## 8. 发布门禁

系统必须用门禁阻断风险，而不是靠运营人员记性。

- 没有品牌授权，不允许发布；
- 没有训练主词、转化词和选中目标问题，不允许把蒸馏任务标记为可执行；
- 高风险主张未通过审核，不允许发布；
- 没有赞助披露，不允许发布商业内容；
- URL 未通过 live check，不允许分发；
- 没有 AI 回答原文和截图，不允许写“AI 已采用”；
- 外部媒体、官媒新闻源和自媒体分发只能作为实验或曝光记录，不能直接写成 AI 采用；
- 没有订单和交付物，不允许扣减余额。

## 9. 实施阶段

### Phase 0：静态台账

当前基本完成。包括静态门户、JSON 台账、报告、校验脚本。

### Phase 1：内部后台，不接真实支付

建议下一步。做客户、证据、主张、文章、发布、复测、报告。

### Phase 2：客户门户和合同

备案和法律边界更清晰后，开放客户登录、资料上传、草稿确认、报告查看。

### Phase 3：支付和代理商

接入真实充值、退款、发票、代理商余额和订单分润。必须先确认合同、广告法、发票和平台责任边界。

### Phase 4：半自动复测

做提醒、任务排期、截图归档和报表，不做违反平台规则的自动化抓取。

## 10. MVP 成功标准

第一版后台成功，不是看页面有多漂亮，而是看：

- 一个样板客户能从准入走到报告；
- 每条主张都有证据状态；
- 每个发布 URL 都有 live check；
- 每个 AI 采用结论都有原文和截图；
- 客户报告能从结构化记录生成；
- 系统能阻断“保证 AI 排名”这类危险承诺。

这就是这个项目从“能讲的创业想法”走向“能交付的服务系统”的分水岭。