AI 科技生态总体蓝图 v2.0 · 全文

飞创未来科技 · AI 科技生态总体蓝图 v2.0

文件性质：规划文档，不含任何开发产物。本版未创建网站、数据库、代码或部署动作。 编制日期：2026-09-22 ｜ 主体：飞创未来科技（广西南宁） 开发授权：未授权。仅在收到"开始第一阶段开发"后启动工程实现。

卷首：本版的方法论与三条现实约束

一、与 v1.0 的关系

v1.0 回答的是"现在该做什么"（减法、生存、现金流）。本版 v2.0 回答的是"最终要长成什么"（完整生态蓝图）。两者不冲突：v2.0 是目的地地图，v1.0 是出发时的路线选择。导航用 v2.0，迈步用 v1.0。

二、核心方法论：能力 ≠ 产品 ≠ 商业

你列出的 20 大生态里，有相当一部分是能力，而不是产品。这个区分是本蓝图最重要的判断依据：

结论：能力层 100% 内聚到 AI Gateway，绝不单独做成产品对外卖。 你列的"AI基础设施 21 项"里，至少 17 项是能力，不是产品。把它们当成产品去做，是生态规划里最典型的浪费——用户不会为"向量数据库"买单，只会为"用向量数据库解决的问答"买单。

三、三条不可违背的现实约束（贯穿全部规划）

四、20 大生态总览（P级 + 阶段 + 形态）

P0 只有 6 个：AI基础设施、AI创作、AI智能体、AI自动化、AI广告营销、商业基础设施（+农业轻量切入）。这就是阶段 1-3 的全部战场。

第一部分 · 战略定位

1.1 一句话定位

飞创未来科技 = 面向"内容生产与垂直行业"的 AI 应用生态平台。 不做通用 AI 入口，做"把 AI 变成可交付成果"的工业化管线。

1.2 三层定位拆解

1.3 差异化：为什么不是大厂的对手而是补充

大厂做通用能力（模型、对话、搜索），做不了垂直交付： - 大厂人力成本结构不允许做"重交付的内容管线" - 大厂不会为广西甘蔗做病虫害数据集 - 大厂不会为一个 30 章的原创 IP 做角色一致性引擎

我们的护城河 = 垂直工作流 × 行业数据 × 成本结构。

1.4 明确不做什么（战略边界）

• ❌ 不自研基础大模型
• ❌ 不做通用 AI 聊天/搜索入口（作为平台内嵌能力即可）
• ❌ 不自建 IaaS 云服务与算力集群
• ❌ 不做社交网络
• ❌ 不追求功能数量对标大厂

第二部分 · 用户群体

2.1 五类目标用户（按获取难度排序）

2.2 关键判断

阶段 1 只服务 ① 和 ③。 企业主给现金流，农业给政策和项目机会，两者都不需要海量用户。 创作者（②）看似最契合，但付费能力弱、流失高，放到阶段 2 用内容生态去承接，不作为起步用户。

2.3 用户生命周期设计

陌生人 → 小程序免费体验（AI成片/病害识别）
      → 注册（手机号/微信，进 OneID）
      → 免费额度用完 → 首次付费（小额积分包）
      → 产生项目数据 → 沉淀为留存
      → 重度用户 → 会员/企业版
      → 企业用户 → SaaS/定制 → 年框

第三部分 · 20 大生态产品矩阵

（总览表见卷首第四节。此处补充每个生态的能力归属与是否独立成产品的裁决。）

3.1 AI 基础设施（21 项能力裁决）

21 项里 0 项独立成产品。 但其中 内容审核、成本管理、日志 三项必须在阶段 1 就有最小实现——前者是合规红线，后两者是"能不能算清账"的生死线。

3.2 AI 助手（15 项能力裁决）

AI 助手不是产品，是交互范式。 它应该出现在创作中心、企业空间、农业助手里，而不是做一个独立的"飞创 ChatGPT"。

3.3 AI 创作中心（4 大类 · 裁决）

核心原则：所有生成内容统一进入 Project（项目）→ 文件系统 → 素材库，这是创作中心与内容生态、游戏生态复用的关键。

3.4 AI 智能体 / Workflow / 办公 / 企业服务

见第八、九、十部分详述。裁决摘要：

• Agent Builder：用开源底座（Dify/Coze 开源版）二次开发，不自研编排引擎；自研只做"行业 Agent 模板 + 工具市场"。
• Workflow：同上。第一条工作流 = 漫剧生产 SOP。
• AI 办公：P2，阶段 5+。文档/表格/PPT 是重投入红海，优先级低。
• AI 企业服务：服务先行（代运营）→ SaaS 沉淀。数据隔离是硬要求，见第十四部分。

3.5 其余生态裁决（摘要）

第四部分 · 产品层级

4.1 五层产品模型

L5 商业层   会员 / 积分额度 / SaaS / 项目制 / 分成 / 代运营
L4 场景层   创作中心 · 企业空间 · 农业助手 · 内容平台 · 游戏 · 电商
L3 编排层   Agent Builder · Workflow Engine · 行业模板库
L2 能力层   AI Gateway · RAG · File · Search · 多模态 · 审核
L1 底座层   OneID · 组织权限 · 积分计量 · 支付 · 通知 · 审计

层级规则： 1. 上层可以调用下层，下层不得反向依赖上层 2. 能力层（L2）不做用户入口，只提供 API 3. 场景层（L4）每个产品必须有独立入口与独立价值主张 4. 任何新功能先问：它属于哪一层？落在 L2 的就不该做成产品

4.2 产品形态决策矩阵

第五部分 · 信息架构

5.1 统一信息架构树

飞创 AI 生态
├─ 统一入口（Portal）
│   ├─ 官网（营销/获客，已上线）
│   ├─ 控制台 Console（登录后统一工作台）
│   └─ 小程序矩阵（获客入口）
│
├─ 我的项目 Project ★一等公民
│   ├─ 对话 / 文件 / 图片 / 视频 / 音频
│   ├─ Agent / Workflow / 知识库 / 任务 / 成员
│   └─ （例：「飞旅游戏项目」= 剧本+人物+图+视频+代码+Agent+Workflow）
│
├─ 创作中心
│   ├─ 文字 · 图片 · 视频 · 音频 · 数字人
│   └─ 产出 → 素材库 → Project
│
├─ AI 助手（统一对话入口，可调用全部能力）
│
├─ 智能体 Agent
│   ├─ 我的 Agent · 预置 Agent（导演/文案/营销/客服/农业…）
│   └─ 模板库（阶段1-3 内部）
│
├─ 工作流 Workflow
│   └─ 可视化编排 · 运行记录 · 定时/Webhook
│
├─ 知识库
│   ├─ 个人 · 项目 · 企业（隔离）
│   └─ 文档 → 向量 → RAG
│
├─ 文件与素材库（统一文件系统）
│
├─ 企业空间（组织/部门/成员/权限/企业知识库/企业Agent）
│
├─ 开发者中心（阶段5+）：API Key · 文档 · 调用统计 · 账单
│
├─ 应用市场（阶段6+）：Agent/Workflow/模板/插件
│
├─ 用户中心：账号 · 会员 · 积分 · 钱包 · 订单 · API Key
│
└─ Admin 后台（独立系统）

5.2 Project（项目）为什么是一等公民

Project 是生态内部的粘合剂，解决"AI 产物碎片化"问题： - 创作中心的图/视频 → 归入项目素材 - Agent 的运行结果 → 挂在项目下 - 知识库 → 按项目隔离 - 团队协作 → 以项目为单位授权

对《飞旅》这类长周期 IP，Project 就是它的一站式工作空间——这是普通"文件夹"做不到、而你能做好的差异点。

第六部分 · 系统架构

6.1 总体分层（前后端分离，核心能力 API 化）

┌──────────────────────────────────────────────┐
│ 前端层  Web Console / 官网 / 小程序 / Admin    │
├──────────────────────────────────────────────┤
│ API Gateway（鉴权 · 限流 · 路由 · 日志）        │
├──────────────────────────────────────────────┤
│ Auth 认证授权服务                              │
├──────────────────────────────────────────────┤
│ 业务服务层（模块化）                           │
│  Project · Creation · Agent · Workflow        │
│  Knowledge · File · Search · Commerce         │
│  Enterprise · Notify · Analytics              │
├──────────────────────────────────────────────┤
│ AI Gateway（★统一出口）                        │
│  模型路由 · Prompt · Token计量 · 审核 · 降级    │
├──────────────────────────────────────────────┤
│ 模型层  DeepSeek / 混元 / 通义 / 豆包 / SD…     │
└──────────────────────────────────────────────┘
旁路服务：RAG · File · Search · DB · Payment · Analytics · Notify

6.2 模块化边界（每个服务可独立部署/替换）

"Agent / Workflow 引擎可替换"是刻意设计——阶段1-3 用开源，将来有能力再自研，业务代码不重写。

6.3 部署形态演进

禁止在阶段1做微服务——小团队做微服务 = 用 3 倍成本换来 0 收益。

第七部分 · AI 架构

7.1 AI Gateway 设计（整个生态的技术心脏）

职责：所有模型调用的唯一出口。业务服务不允许直连模型厂商。

业务服务
   ↓ 统一协议（OpenAI 兼容格式）
AI Gateway
   ├─ 模型路由（按任务/成本/可用性选模型）
   ├─ Prompt 管理（模板 + 版本）
   ├─ Token 计量 & 成本归因（到用户/项目/功能）
   ├─ 内容审核（输入+输出双向）
   ├─ 限流 & 配额（用户/企业/Key）
   ├─ 降级 & 重试（模型不可用时自动切备选）
   ├─ 缓存（相同请求复用，省成本）
   └─ 日志 & 追踪
   ↓
模型层：DeepSeek / 混元 / 通义 / 豆包 / OpenAI / Anthropic / Google / 本地 SD

7.2 模型路由策略（省钱的核心）

路由能直接省 30-50% 的 API 成本。 这是阶段1投入产出比最高的一项工程。

7.3 不绑定单一模型的三条硬规则

1. 所有调用走 OpenAI 兼容协议的抽象层
2. 模型配置存数据库，支持热切换（不动代码）
3. 每个任务至少配置 1 个备选模型 + 降级策略

7.4 多模态与 RAG 接入节奏

7.5 成本与安全的两道闸门（阶段1 必须）

• 成本计量：每次调用记录 user_id / project_id / feature / model / tokens / cost，能按天算出毛利
• 内容审核：输入输出双向审核 + AI 生成内容标识（国内合规硬要求）

第八部分 · Agent 架构

8.1 原则：不重复造轮子

┌─ 自研部分（差异化）────────────┐
│ · 行业 Agent 模板库（导演/农业/营销）│
│ · 飞创工具集（创作/文件/知识库/项目）│
│ · Agent 与 Project 的深度绑定      │
│ · 权限与数据隔离                   │
└──────────────────────────────┘
┌─ 开源底座（不自研）─────────────┐
│ · 对话编排 / 工具调用 / 记忆      │
│ · 推荐：Dify / Coze 开源版        │
└──────────────────────────────┘

自研一个 Agent 引擎需要 3-6 人月且持续维护。用开源 + 自研工具层，2-4 周就能上线可用版本。省下的时间去做行业模板，那才是壁垒。

8.2 Agent 数据模型（核心字段）

8.3 预置 Agent 清单（11 个）

预置 Agent 不需要一次做完。 阶段1 只做 AI 导演一个，把它打磨到能真的参与生产，比做 11 个半成品有价值得多。

8.4 Multi-Agent 协作

阶段3+ 规划，阶段1-2 明确不做。理由：多智能体编排在没有足够真实任务验证前，做出来的只是 demo。

第九部分 · Workflow 架构

9.1 节点体系

9.2 第一条工作流：漫剧生产 SOP（阶段1 的样板）

[输入] 主题/创意
   ↓
[AI] 生成剧本大纲 ×3
   ↓
[人工确认] 选定大纲
   ↓
[AI] 拆解分镜表（镜头/画面/台词/时长）
   ↓
[AI-图像] 批量生成分镜图（角色一致性约束）
   ↓
[AI-TTS] 生成配音
   ↓
[文件] 归入项目素材库
   ↓
[输出] 可剪辑素材包 + 分镜文档

这条工作流的价值：它既是产品功能，又是内部生产工具。自己先用它做出 1 集，产品才算验证通过。

9.3 引擎选型

同 Agent：开源优先（Dify Workflow / n8n 思路）。自研只在出现"开源无法满足的垂直需求"时启动。

9.4 必须支持的运维能力

调试（单节点试跑）、运行日志、版本管理、定时触发、Webhook、失败重试、运行成本统计。

第十部分 · 数据架构

10.1 数据分层

L1 业务数据（OLTP）  用户/项目/Agent/Workflow/订单…  → PostgreSQL
L2 向量数据          Embedding 检索                  → pgvector（不独立建集群）
L3 文件对象数据       图片/视频/音频/文档              → 对象存储（腾讯云 COS）
L4 日志与观测        调用日志/审计/AI日志              → 日志表 + 对象存储归档
L5 分析数据（OLAP）  DAU/收入/成本/留存                → 阶段1 用 SQL 看板，阶段3+ 再考虑数仓

10.2 核心表设计（覆盖你要求的 24 张表并扩展）

身份与组织 | 表 | 关键字段 | |---|---| | user | id, phone, email, password_hash, nickname, avatar, status, created_at | | organization | id, name, type(企业/团队), owner_id, status | | member | id, org_id, user_id, role_id, status, joined_at | | role | id, org_id, name, code | | permission | id, code, name, group |

项目与内容 | 表 | 关键字段 | |---|---| | project | id, owner_id, org_id, name, type, cover, status, created_at | | conversation | id, project_id, user_id, agent_id, title, model, status | | message | id, conversation_id, role, content, tokens, cost, model, files(jsonb), created_at | | file | id, project_id, uploader_id, type, url, size, tags(jsonb), version, permission, created_at |

AI 能力 | 表 | 关键字段 | |---|---| | model | id, provider, name, type, pricing(jsonb), status, priority, is_default | | agent | id, project_id, creator_id, name, avatar, role_prompt, model_id, config(jsonb), visibility, version, status | | agent_tool | id, agent_id, tool_code, config(jsonb), permission | | workflow | id, project_id, creator_id, name, graph(jsonb), version, status, schedule | | workflow_node | id, workflow_id, node_type, config(jsonb), position | | workflow_run | id, workflow_id, status, input(jsonb), output(jsonb), cost, started_at, ended_at | | knowledge_base | id, project_id, org_id, name, type(个人/项目/企业), embedding_model, status | | knowledge_document | id, kb_id, file_id, title, chunk_count, status, indexed_at |

商业与计量 | 表 | 关键字段 | |---|---| | membership | id, user_id, plan, started_at, expired_at, status | | usage | id, user_id, org_id, project_id, feature, model, tokens, cost, created_at ★成本归因核心 | | order | id, user_id, type, amount, status, paid_at | | payment | id, order_id, channel, transaction_id, amount, status | | credit_account | id, user_id/org_id, balance, total_consumed |

开发者与运营 | 表 | 关键字段 | |---|---| | api_key | id, user_id, org_id, key_hash, scopes, rate_limit, status, last_used_at | | api_log | id, api_key_id, endpoint, request, response_code, tokens, cost, latency, created_at | | application | id, developer_id, type(agent/workflow/plugin), name, price, status, install_count | | notification | id, user_id, type, title, content, channel, is_read, created_at | | audit_log | id, actor_id, action, target_type, target_id, ip, detail(jsonb), created_at |

10.3 数据隔离策略（企业服务的硬要求）

隔离必须在数据访问层（DAO/Repository）强制实施，不能靠业务代码自觉——这是企业客户审计时唯一认可的做法。

第十一部分 · 技术架构

11.1 技术选型（务实、够用、便宜）

11.2 技术铁律（阶段1-3）

1. 不自建模型、不自建向量集群、不搞微服务
2. 单体应用 + 单库 + 单队列 先跑起来
3. 所有 AI 调用只走 AI Gateway 一个出口
4. 任何第三方能力都做抽象层（可替换）
5. 基础设施全用第三方云，只做统一资源抽象，不碰 IaaS

11.3 分阶段技术演进

第十二部分 · 商业架构

12.1 会员体系（五级）

12.2 积分（额度）体系设计

原则：积分是"AI 成本的内部货币"，所有 AI 能力统一用积分计价。

积分定价 = 实际模型成本 × (1 + 毛利率)
例：一次剧本生成成本 0.3 元 → 定价 30 积分（1 积分 ≈ 1 分钱）→ 毛利 0 
   实际建议加价倍率 2-3x：0.3 元成本 → 60-90 积分（0.6-0.9 元）

12.3 四条收入线（按启动难度）

12.4 服务定价参考（阶段1 可执行）

12.5 商业闭环

内容产线（能力）→ 代产接单（现金流）→ 沉淀工具（产品）
      ↑                                      ↓
   数据反哺优化                        企业客户转化 → SaaS 订阅
      ↑                                      ↓
   农业项目（大单）← 政府/合作社资源 ←──────────┘

关键一跳：每个代产订单都是一次需求调研。同一需求被第 3 个客户提出 → 做成产品功能 → 从卖人力（毛利 30%）转向卖产品（毛利 70%）。

第十三部分 · 用户体系

13.1 注册登录

13.2 用户中心信息架构

用户中心
├─ 基础：头像 · 昵称 · 账号 · 安全设置
├─ 资产：会员 · 额度/积分 · 钱包 · 订单 · 发票
├─ 资产（创作）：项目 · 文件 · Agent · Workflow · 知识库
├─ 开发者（阶段5+）：API Key · 调用统计 · 账单
└─ 消息：通知 · 系统消息

13.3 OneID 设计要点

• 一个账号贯通：Web / 小程序 / 企业空间 / 未来 App / API
• 统一 user_id 作为所有数据归属主键
• 会员/积分/额度账号级，不按产品分割（这是"统一"的核心体现）

第十四部分 · 企业体系

14.1 企业数据模型

Organization（企业）
├─ Department（部门）
├─ Member（成员）→ 关联 user
├─ Role / Permission（角色权限）
├─ Project（企业项目）
├─ KnowledgeBase（企业知识库，隔离）
├─ Agent（企业 Agent）
├─ Workflow（企业工作流）
└─ Usage / Billing（企业计量与账单）

14.2 隔离要求（硬指标）

14.3 企业服务落地顺序

1. 阶段1：不做系统，靠人工交付（代运营）
2. 阶段2：轻量企业空间（多成员 + 共享项目 + 统一账单）
3. 阶段4：完整企业 SaaS（知识库、Agent、自动化、客服）

第十五部分 · 开发者体系

15.1 开放前置条件（不满足则不开放）

这五条缺一不可。 不具备就开放 = 招来白嫖用户 + 拖垮服务 + 差评。宁可不做。

15.2 API 体系

15.3 开发者控制台

调用量、Token、额度、错误率、请求日志、账单 —— 阶段5 一次性做齐，不分期。

15.4 SDK

阶段5+，优先级：Python → JavaScript → Java → Go。

第十六部分 · 应用市场

16.1 分阶段建设

16.2 市场品类

AI 应用 · Agent · Workflow · 插件 · Prompt · 模板

16.3 分成机制（阶段6+）

先积累 50+ 可用模板再谈市场。 空市场上线 = 用户来了就走。

第十七部分 · 内容生态

17.1 内容形态与阶段

17.2 内容平台功能

创作 → 发布 → 观看 → 互动（收藏/评论/分享）→ 推荐（远期）

17.3 关键判断

内容平台必须在创作中心成熟后才做。没有稳定的内容供给，平台就是空货架。 顺序：先有 20 部自制内容 → 再开放创作者入驻（邀请制）→ 最后才是公开平台。

第十八部分 · 游戏生态

18.1 现状与资产

《飞旅：王朝末路》已有：30 章/4 卷剧情、1097 条对白、15 背景、25 角色立绘、6 CG、Godot 4 实现、网页版。

18.2 游戏生态规划

18.3 关键判断

《飞旅》是生态的 IP 母舰，不是孤立产品。 - 它的剧本 → 进创作中心作为样例 - 它的角色 → 进角色一致性引擎作为训练数据 - 它的美术 → 进素材库 - 它的玩家 → 是内容生态与互动故事的第一批用户

第十九部分 · 教育生态

19.1 裁决：P3，阶段9+，且需重新评估

19.2 建议

不要在 3 年内投入教育生态。 它需要的教研能力、内容积累、资质要求与你现有资源（内容产线、农业、本地企业）都不匹配。 如果未来要做，唯一合理的切入点是"AI 技能培训"（教企业/农户用 AI），因为它能复用你的产线经验与本地渠道。

第二十部分 · 电商生态

20.1 裁决：只做农产品电商，通用商城不做

20.2 农产品电商的协同价值

助农：识别病害 → 指导种植 → 产出农产品
                                ↓
内容：用创作中心做农产品营销短视频 ← 你的强项
                                ↓
电商：销售 → 数据回流农业数据平台

这是大公司做不到的组合：内容能力 + 农业场景 + 本地供应链。

第二十一部分 · 营销生态

21.1 裁决：P0，阶段2 启动（能立刻收钱）

21.2 落地路径（重要）

代运营服务 → 沉淀 SOP → 做成 Workflow 模板 → 变成 SaaS 功能

这是"服务先行、工具沉淀"的典范路径，低成本验证需求，且过程中有收入。

第二十二部分 · 助农与智慧农业生态

22.1 三阶段（按你的规划，补充裁决）

阶段1（轻量，现在可做） - 农业 AI 助手 ✅（对话问答） - 甘蔗 AI 助手 ✅ - 农业知识库 ✅（公开资料 + 农技手册，RAG 即可） - 种植问答 ✅ - 农产品营销 ✅（复用创作中心，最高性价比）

阶段2（需数据与合作） - 病虫害识别 ✅（小程序，公开数据集冷启动） - 天气 / 农情 / 农田管理（需数据源与合作基地） - 农业数据平台（需积累）

阶段3（重资产，需资金与合作伙伴） - GIS / 遥感 / 无人机 / 传感器 / 农业设备 / 供应链

重资产部分建议寻找合作伙伴（农机企业、科研院所、政府项目），不要自己投硬件。 飞创的角色应是"AI 算法与软件层"，不是设备商。

22.2 战略价值

农业是唯一能形成区域壁垒的生态：广西甘蔗产区、本地政府关系、多年数据积累——这些都是外部公司无法复制的。

第二十三部分 · 数据生态

23.1 裁决：P2，阶段12+，需积累

23.2 建议

阶段1-4 只做内部数据分析（DAU/成本/收入/毛利），把它当作经营工具而非产品。 对外数据服务等到你真的拥有别人没有的数据（如广西甘蔗农情数据）再说——那时它才有壁垒。

第二十四部分 · 云服务与基础设施

24.1 裁决：长期不建议自建 IaaS

24.2 理由

自建 IaaS 的门槛：机房/带宽/硬件/运维团队/SLA 保障 —— 投入以千万计，且与 AI 应用生态的核心价值无关。 你该做的是统一资源抽象层（一套 SDK 封装多家云），保持可迁移性，而不是自己当云厂商。

唯一例外：若未来农业项目涉及边缘计算（田间传感器网关），可做轻量边缘节点，仍不自建中心云。

第二十五部分 · 社交与团队协作

25.1 裁决：拆分，一半做一半不做

25.2 关键判断

协作 ≠ 社交。 协作是"围绕项目完成任务"，社交是"围绕人建立关系"。前者是你生态必需的粘合剂，后者是另一个战场（且需要海量用户才能成立）。

第二十六部分 · 后台管理系统

26.1 Admin 功能清单

26.2 建设节奏

阶段1 做最小 Admin：用户查询、额度调整、模型配置、成本看板、内容审核队列。其余按需扩展。

第二十七部分 · 安全系统

27.1 安全能力矩阵

27.2 合规红线（国内，必须提前处理）

内容标识是最容易漏、且最容易被处罚的一项。 成本极低，建议阶段1 就做进 AI Gateway（所有生成物自动打标）。

第二十八部分 · 运营与数据分析

28.1 核心指标体系

28.2 最重要的三个经营指标（阶段1 只盯这三个）

1. 单用户 AI 成本（当月 AI 总成本 ÷ 活跃用户数）—— 判断单位经济模型
2. 毛利率（收入 - AI成本 - 服务器成本）÷ 收入 —— 低于 40% 说明定价或路由有问题
3. 付费客户数 —— 生存指标，比 DAU 重要得多

28.3 实现建议

阶段1 用 SQL + 简单图表即可，不要引入重型数仓/BI。阶段3+ 再考虑。

第二十九部分 · 商业模式（汇总）

29.1 收入结构（按阶段）

29.2 定价原则

1. AI 成本高、感知价值高的功能（视频生成）→ 高毛利定价（2-3x 成本）
2. AI 成本低、感知价值高的功能（剧本、方案）→ 高毛利（5-10x 成本）
3. 引流功能 → 免费或极低定价
4. 企业 → 按席位 + 额度包组合

29.3 毛利目标

第三十部分 · 团队规划

30.1 分阶段团队配置

30.2 关键岗位说明

30.3 用人形式建议

• 核心岗（1-3 人）：全职或半固定，保证连续性
• 执行岗：兼职/按件/分成（符合你现有的时薪制模式）
• 专业岗（UI/法务/财务）：外包或顾问

第三十一部分 · 成本规划（五档估算）

以下为保守估算，含服务器/存储/AI API/带宽/CDN/安全/第三方服务，不含人力。 广西南宁 2026 年行情，单位：人民币/月。

关键说明

1. AI API 成本是绝对大头（占总成本 70-85%）。模型路由优化、缓存、小模型优先，能把这块砍 30-50%。
2. 1 万用户是关键分水岭：此时月成本约 2-5 万，需要月收入达到 5-8 万才能健康运转。
3. 100 万用户档仅供参考：届时必然需要自建部分能力（如图像生成本地化）与商务议价，实际成本会显著低于线性推算。
4. 视频生成是成本杀手：单次成本是文本的 10-50 倍，必须做额度限制与排队机制。

省钱三招

1. 模型路由（省 30-50%）
2. 图像生成本地化（你已有 ComfyUI/SD + NVENC 环境，边际成本接近电费）
3. 缓存相同请求 + 小模型优先

第三十二部分 · 风险

第三十三部分 · 产品优先级（P0-P3）

33.1 评估维度

用户需求 · 商业价值 · 开发成本 · AI 成本 · 技术难度 · 获客难度 · 数据价值 · 技术壁垒 · 生态价值

33.2 P0（阶段1-3 必须做，共 6 个生态）

33.3 P1（阶段2-4 重要）

AI 助手（内嵌）、AI 企业服务、AI 搜索与知识、AI 内容娱乐、AI 游戏、项目协作

33.4 P2（阶段5+ 未来）

AI 办公、AI 开发者生态、AI 应用市场、AI 电商（农产品）、数据与信息服务

33.5 P3（远期探索或不做）

AI 教育、云服务自建、社交网络、通用电商商城、数字员工、虚拟世界

第三十四部分 · MVP 清单（第一阶段）

MVP-1：飞创内容工作台 v0.1（🥇 最高优先级）

范围（严格限定）：

输入：主题/一句话创意
 → ① AI 生成剧本大纲 ×3
 → ② 选定 → 自动生成分镜表（镜头/画面/台词/时长）
 → ③ 导出素材清单
输出：可交付的分镜文档 + 素材需求表

明确不做：视频自动合成、在线编辑、协作、会员、多租户。

成功标准：用它完成 1 集漫剧，工时比原来少 50%；兼职人员按输出能独立完成成片。

MVP-2：AI Gateway + 成本计量

范围：统一模型调用出口、OpenAI 兼容协议、模型路由（按任务选最便宜）、Token/成本归因到用户与功能、基础限流、内容审核+生成标识。

成功标准：API 成本下降 30%+；能按天算出每个功能/用户的成本与毛利。

MVP-3：OneID + 积分 + 支付（最小版）

范围：手机号/微信登录、统一 user_id、积分账户（1 积分≈1 分钱）、微信支付、订单记录。

成功标准：能完成一笔真实付费。

MVP-4：小程序「飞创 AI 成片」（引流）

范围：输入主题 → 30 秒短片（图+配音+字幕）→ 分享；每日免费 1 次，超出用积分。

成功标准：3 个月 1,000 用户，转化 10 个企业线索。

MVP-5：小程序「甘蔗病虫害识别」（农业敲门砖）

范围：拍照 → 识别 5-8 类常见甘蔗病害 → 防治建议。公开数据集冷启动。

成功标准：能拿去谈下 1 个合作社/农业部门意向。

MVP 共同原则

1. 4 周内必须能演示
2. 必须复用底座（不重复开发账号、支付、模型接入）
3. 必须有人提前表达过兴趣
4. 做不出来就砍掉

第三十五部分 · 三年发展路线

三个生死线检查点

第三十六部分 · 长期生态路线（3 年以上）

终局形态

统一入口（Portal）
  ↓
OneID（一个账号）
  ↓
统一 AI 能力（AI Gateway / RAG / 多模态）
  ↓
统一编排（Agent / Workflow）
  ↓
场景产品（创作 · 企业 · 农业 · 内容 · 游戏 · 电商）
  ↓
开放（开发者 · 应用市场 · 第三方模型/工具/数据）
  ↓
商业（会员 · 额度 · SaaS · 项目 · 分成）

长期原则（最重要）

不要把"功能数量"当成"平台实力"。 真正的平台实力来自：用户、技术、数据、生态、开发者、企业客户、内容、工作流、AI 能力、商业模式、品牌。

发展节奏的哲学

• 生态是长出来的，不是建出来的
• 每进入一个新生态，必须有前一个生态的真实用户/数据/收入作为支撑
• 允许放弃：如果某个生态在 12 个月内无法回答"谁付钱"，就砍掉

商业验证门禁（每个生态开发前必须回答）

这是防止"大而全没用户"的最重要机制。回答不了，就暂缓。

附录一 · 飞创未来科技 AI 生态总架构图

flowchart TB
    subgraph U["统一入口层"]
        P1["官网 Portal"] 
        P2["Console 控制台"]
        P3["小程序矩阵"]
        P4["Admin 后台"]
    end
    subgraph B["底座层 OneID"]
        B1["统一账号"] 
        B2["积分/额度"]
        B3["支付/订单"]
        B4["组织权限"]
        B5["通知"]
    end
    subgraph A["AI 能力层"]
        A1["AI Gateway"]
        A2["模型路由"]
        A3["RAG/知识库"]
        A4["多模态/OCR/TTS"]
        A5["内容审核+标识"]
        A6["成本计量/日志"]
    end
    subgraph O["编排层"]
        O1["Agent 运行时"]
        O2["Workflow 引擎"]
        O3["模板库"]
    end
    subgraph S["场景层"]
        S1["创作中心"]
        S2["企业空间"]
        S3["农业助手"]
        S4["内容平台"]
        S5["游戏生态"]
        S6["营销云"]
    end
    subgraph M["模型层"]
        M1["DeepSeek/混元/通义/豆包"]
        M2["OpenAI/Anthropic/Google"]
        M3["本地 SD/ComfyUI"]
    end
    U --> B --> S
    S --> O --> A
    A --> M
    B -.旁路.-> A
    S -.旁路.-> B

附录二 · 20 大生态产品地图

flowchart LR
    CORE["统一底座 OneID + AI Gateway"]
    CORE --> E1["1 AI基础设施"]
    CORE --> E2["2 AI助手"]
    CORE --> E3["3 AI创作 ★P0"]
    CORE --> E4["4 AI智能体 ★P0"]
    CORE --> E5["5 AI自动化 ★P0"]
    CORE --> E8["8 搜索与知识"]
    CORE --> E15["15 广告营销 ★P0"]
    CORE --> E16["16 助农农业 ★P0轻"]
    E3 --> E11["11 内容娱乐"]
    E3 --> E12["12 游戏生态"]
    E3 --> E20["20 电商(农产品)"]
    E4 --> E7["7 企业服务"]
    E5 --> E7
    E8 --> E7
    E4 --> E10["10 应用市场"]
    E5 --> E10
    E10 --> E9["9 开发者生态"]
    E7 --> E18["18 数据服务"]
    E16 --> E20
    E16 --> E18
    E2 --> E6["6 AI办公"]
    E6 -.P2.-> CORE
    E13["13 AI教育 P3"] -.暂缓.-> CORE
    E19["19 云服务 P3"] -.用第三方.-> CORE
    E17["17 协作(P1)"] --> CORE
    E14["电商/营销"] --> E20

附录三 · 产品依赖关系图

flowchart TD
    USER["用户"] --> PROJ["项目 Project"]
    PROJ --> AI["AI 能力"]
    AI --> AGENT["Agent"]
    AGENT --> WF["Workflow"]
    WF --> MODEL["模型层"]
    FILE["文件"] --> KB["知识库"]
    KB --> RAG["RAG"]
    RAG --> AGENT
    AGENT --> MARKET["应用市场"]
    MARKET --> USER2["其他用户"]
    ORG["企业"] --> ORGKB["企业知识库"]
    ORGKB --> ORGAG["企业Agent"]
    ORGAG --> ORGWF["企业Workflow"]
    ORGWF --> ORGAUTO["企业自动化"]
    DEV["开发者"] --> API["API"]
    API --> APP["应用"]
    APP --> MARKET
    CREATOR["创作者"] --> CREATE["AI创作"]
    CREATE --> CONTENT["内容"]
    CONTENT --> PLATFORM["内容平台"]
    PLATFORM --> AUDIENCE["观众"]
    AGRI["农业"] --> AGRIAI["AI助农"]
    AGRIAI --> AGRIDATA["农业数据"]
    AGRIDATA --> PRODUCT["农产品"]
    PRODUCT --> SHOP["电商"]

附录四 · 技术架构图

flowchart TB
    FE["前端层<br/>Web Console / 官网 / 小程序 / Admin"]
    GW["API Gateway<br/>鉴权 · 限流 · 路由 · 日志"]
    AUTH["Auth 认证授权"]
    BIZ["业务服务层（模块化）<br/>Project · Creation · Agent · Workflow<br/>Knowledge · File · Search · Commerce<br/>Enterprise · Notify · Analytics"]
    AIGW["AI Gateway ★统一出口<br/>模型路由 · Prompt · Token计量<br/>审核 · 限流 · 降级 · 缓存"]
    ML["模型层<br/>DeepSeek / 混元 / 通义 / 豆包<br/>OpenAI / Anthropic / Google / 本地SD"]
    SIDE["旁路服务<br/>RAG · File · Search · DB<br/>Payment · Analytics · Notify"]
    FE --> GW --> AUTH --> BIZ --> AIGW --> ML
    BIZ -.-> SIDE
    AIGW -.-> SIDE

附录五 · 三年发展路线图

timeline
    title 飞创未来科技 AI 生态三年路线
    section 阶段1 · 活下来 (0-6月)
        内容工作台 v0.1 : P0
        AI Gateway + 成本计量 : P0
        OneID + 积分 + 支付 : P0
        小程序 AI成片 : 引流
        小程序 甘蔗病虫害 : 敲门砖
        目标 : 月入2-5万 · 5个付费客户
    section 阶段2 · 跑通 (6-12月)
        代运营规模化 : 现金流
        营销云公测 : 产品化
        农业项目破冰 : 机会
        目标 : 月入5-10万
    section 阶段3 · 平台化 (12-18月)
        Agent + Workflow 上线 : P0
        企业 SaaS 收费 : 毛利
        漫剧平台 v1 : 差异化
        目标 : 月入10-20万
    section 阶段4 · 生态萌芽 (18-24月)
        创作者入驻 : 邀请制
        角色引擎对外 : 壁垒
        区域品牌建立 : 心智
        目标 : 月入20-35万
    section 阶段5 · 第二曲线 (24-36月)
        农业数据平台 : 数据壁垒
        开发者平台 : 条件具备才开
        机器人 + AI : 探索
        目标 : 月入35万+

附录六 · 第一阶段 MVP 清单

共同原则：4 周内能演示 · 复用底座 · 有人提前表达兴趣 · 做不出来就砍

文档状态

如果多个产品可以共用一个平台，本文档已将其设计为统一底座而非重复开发。所有规划以"低成本 → 快上线 → 拿用户 → 收钱 → 攒数据 → 成能力 → 再扩张"为准则。