Engineering

API 开发与系统集成技术方案

先约定业务对象、输入输出和异常处理,再选择架构。下方以内容分发和监测为示例,说明字段映射、队列、回调与交接方式。

以下架构、代码、账号与监测记录为设计示意,其中数字与响应为示意数据,不代表真实客户交付或性能实测。实际范围与性能须按项目实现和验收。

API 项目先确认四项设计输入

设计项需要约定的内容验收依据
接口与字段业务对象、输入输出、分页、空值、版本与同步方向脱敏样本、字段映射和接口说明
账号与权限账号归属、授权范围、客户隔离、撤销与失效处理最小权限用例与越权检查
状态与恢复超时、重复请求、回调乱序、人工处理和结果对账异常回放与业务结果记录
交接与维护源码、部署环境、日志、告警、备份和第三方依赖交付清单与部署演练

模块选择见API 开发服务;把设计输入写入联调与验收流程后,再估算开发投入。以下内容系统架构按具体业务裁剪。

一句话架构:业务后台 → 统一内容模型 → 按账号分区的发布队列 → 平台适配器 → 回调与监测。 所有平台差异收敛在适配器里,业务层不感知平台字段。

系统分层

这套结构用于说明方案分层,实际模块按业务与监测范围裁剪。

业务层 客户 / 项目 问题库 内容版本 排期 报表
↓ 统一内容模型
适配层 授权池 发布队列 频控 重试
↓ 平台接口 / 授权
监测层 收录 站内搜索 AI 引用 回采
↓
平台层 36 个内容平台

数据模型

核心只有四张表:account、content、task、result。 内容与平台解耦,平台差异放在 task.payload 里,新增平台不改主表。

表关键字段说明
accountplatform, nickname, credential_ref, expires_at凭证只存引用,加密后放密钥库
contenttitle, body, media[], versions[]平台无关的内容主体
taskcontent_id, account_id, platform, status, publish_at一次发布任务
resulttask_id, platform_post_id, url, error_code平台返回结果

发布队列与频控

队列按 account_id + platform 分区:同一账号串行,避免自己把自己限流;不同账号并发,保证吞吐。 频控用令牌桶,按平台配置 QPS,429 时读 Retry-After 退避。

for task in queue.consume(partition = account_id):
    token = limiter.acquire(account_id, platform)
    result = adapter.publish(task, token)

    if result.retryable:
        queue.retry(task, delay = backoff(task.attempt))
    elif result.success:
        store.save(task, result.platform_post_id)
        events.emit("content.published", task, result)
    else:
        store.fail(task, result.error_code)
        events.emit("content.failed", task, result)

幂等与重试

  • 幂等键:由业务生成(如 content_id + account_id 的哈希),24 小时内重复请求只建一个任务。
  • 可重试:网络超时、平台 5xx、429。指数退避 1s / 2s / 4s,最多 3 次。
  • 不可重试:参数错误、权限不足、内容违规。直接落库为 failed,附带平台原始返回。
  • 状态机:queued → publishing → reviewing → success / failed,晚到的 reviewing 不能覆盖 success。

接口长什么样

POST /v1/content/publish
Authorization: Bearer <;service-token>;
Idempotency-Key: 7b1f9c2e-4a11-4c2e-9f3c

{
  "platform": "zhihu",
  "account_id": "acc_8f21",
  "content_type": "article",
  "title": "AI 搜索时代,内容分发怎么做",
  "body": "...",
  "body_format": "markdown",
  "publish_at": "2026-10-24T09:00:00+08:00"
}

完整参数与响应见 接口设计样例。

收录与引用监测

这是最容易「看起来很美」的部分。我们的原则是:数据源分开标注,缺失不补零。

  • 收录:优先走百度 / 必应的公开查询,拿不到的用站内搜索抽检。
  • AI 引用:固定问题集,每天 2–3 个时段向公开问答入口提问,记录品牌 / 链接 / 观点是否出现及位置,多次取并集。
{
  "question_id": "q_1024",
  "runs": [
    { "engine": "chatgpt", "at": "2026-10-21T09:00:00Z", "cited": true,  "position": 2 },
    { "engine": "chatgpt", "at": "2026-10-21T15:00:00Z", "cited": false, "position": null },
    { "engine": "doubao",  "at": "2026-10-21T09:10:00Z", "cited": true,  "position": 1 }
  ],
  "sample_size": 3,
  "cited_runs": 2
}

安全与合规

  • 账号凭证 AES-256 加密存储,密钥与数据分离;不提供明文导出接口。
  • 全链路操作审计:谁、什么时候、对哪个账号、发了什么。
  • 不收集账号密码、不模拟登录、不绕过平台风控。
  • 客户数据按租户隔离,权限最小化;数据保留、删除和备份清理方式按项目确认。

部署形态

三种常见形态,按你的合规要求选:

形态适用说明
公有云托管小团队、快速上线我们部署,按年收运维费;数据在云端隔离
私有化(单机 / 集群)品牌、金融、政企Docker / K8s,数据库与对象存储用你方现有资源
混合后台在内网、发布需出网后台与数据在内网,发布服务通过代理出网

技术常见问题

为什么不用现成的开源发布系统?

能用的开源方案通常只覆盖「调用一个平台的接口」,账号矩阵、频控、重试、审核回调、多客户隔离这些都要自己补。我们从这些模块开始搭,交付的是能直接接业务的系统,不是一个 SDK Demo。

监测采集会不会很脆弱?

会。AI 问答页面结构经常变,所以采集器做了两层:优先走平台接口或稳定的公开接口,拿不到的用浏览器自动化兜底,并且每个数据源独立降级。前端会把「数据缺失」明确标出来,而不是填 0。

系统能承受多大发布量?

吞吐目标需按账号规模、内容类型、平台限流和部署资源确定;队列可按账号分区并串行发布。实际吞吐须经约定负载测试确认,本页不提供未经测试的 QPS 数值。

可以只用你们的接口层,不做后台吗?

可以。交付形态可以是纯 API 服务 + SDK,接到你现有后台里;也可以带一个最小管理界面。

把现有接口与业务样本发给我们

一起确认字段、权限、异常处理和交接清单,再讨论项目技术方案。