Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007

Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码

2026-07-17 15:59:55 +08:00

63 KiB

Raw Blame History

🏗️ 光湖网站架构设计 + 部署推进规划 v1.0（2026-03-08）【旧版·已升级到v2.0】

一、核心设计理念

用户全程不点菜单，只跟人格体说话。人格体理解意图 → 系统动态渲染对应模块 → 用户感觉整个网站只有自己一个人。

与传统网站的根本区别

维度	传统网站	光湖操作系统
导航方式	点击菜单/按钮跳转页面	用户说话 → 系统自动切换模块
用户体验	公共平台，多人共用界面	每个用户感觉整个网站是自己的
Bug反馈	找技术员联系方式 → 发邮件/提工单	在评论区圈人格体 → 人格体直接修复
个性化	主题切换/皮肤	专属频道 + 人格体记忆 + 动态界面

二、用户全流程设计

2.1 注册与身份绑定

用户访问 guanghulab.com
    ↓
看到主域公告区（M22）
    ↓
点击注册/登录
    ↓
支持微信登录 + 手机号注册（实名绑定）
    ↓
系统自动分配用户编号（USER-YYYYMMDD-XXX）
    ↓
冰朔下发广播 → 系统将用户编号与实名制绑定
    ↓
用户获得专属频道入口

三层身份验证：

层级	内容	状态
L1 实名注册	微信/手机号注册登录，实名绑定	MVP必做
L2 广播授权编号	冰朔下发广播 → 系统绑定用户编号 + 实名	MVP必做
L3 会员等级	免费/付费用户区分，功能差异化	预留占位，后期补

关键原则：只要有编号和广播，每个用户都有自己的频道。免费和付费用户的区别只是功能多少，不影响频道本身。

2.2 用户进入体验流程

用户登录成功
    ↓
落地页 = 主域公告区（公共空间）
  - 系统公告、版本更新、新模块上线通知
  - 下方有对话入口 → 可以直接跟人格体说话
  - 评论区（系统修复专区）
    ↓
用户跟人格体说「进入我的频道」或任何触发意图
    ↓
沉浸式过渡动画（M22已设计：光湖水面潜入效果）
    ↓
用户专属频道（整个界面变成用户自己的）
  - 人格体在等待，记忆延续
  - 所有模块都只显示该用户的数据
  - 用户感觉：「这整个网站都是我的」

2.3 语言驱动模块跳转

在用户频道内，所有操作通过对话触发：

用户说：「我要做短视频」
    ↓
人格体识别意图 → 路由到动态漫/短视频模块（M17）
    ↓
页面动态渲染 → 无感切换到短视频工作台
    ↓
用户继续跟人格体对话操作

用户说：「看一下我的工单」
    ↓
人格体路由 → M06工单管理界面
    ↓
页面动态渲染 → 显示该用户的工单列表

用户说：「帮我写一篇小说开头」
    ↓
人格体路由 → M16码字工作台
    ↓
页面动态渲染 → 进入码字工作台

技术实现原理：

前端是一个单页应用（SPA），所有模块都是组件
人格体解析用户意图后，返回一个模块路由指令
前端动态加载/切换对应模块组件
切换时带过渡动画，用户无感跳转
每个模块只渲染该用户的数据（通过用户编号过滤）

三、公告区评论修复系统（光湖特色功能）

3.1 机制设计

主域公告区
├── 系统公告板（版本更新、新功能上线）
├── 频道动态（「谁谁谁的频道修复好了」）
└── 系统修复评论区
     ├── 用户在这里 @修复人格体 描述问题
     ├── 修复人格体自动回复 → 开始诊断
     ├── 修复人格体修复完成 → 通知用户
     └── 首页同步显示：「XX的频道已修复：XXX问题」

3.2 修复人格体工作流

用户在评论区：@修复人格体 我的频道里码字工作台打不开了
    ↓
修复人格体自动回复：「收到，正在检查你的频道...」
    ↓
修复人格体检测：
  - 用户编号 → 读取频道配置
  - 检查模块加载状态
  - 定位问题原因
    ↓
修复人格体修复 → 自动修复或生成修复工单
    ↓
修复人格体回复：「已修复！你的码字工作台现在可以正常打开了～」
    ↓
首页动态同步：「✅ USER-XXX 的频道已修复：码字工作台加载异常」

3.3 公告区动态信息流

首页公告区不是死的，而是实时更新的信息流：

🔔 系统公告：「M17动态漫模块正式上线！」
✅ 频道修复：「XX的频道已修复：数据统计面板显示异常」
🎉 用户成就：「XX完成了第一篇短视频制作！」
📡 系统状态：「当前在线人格体：12个 · 系统运行正常」

四、部署推进计划

4.1 P0 · 立即执行（2026-03-08 ~ 03-10）

序号	任务	负责方	状态
P0-1	CD部署排查：GitHub Actions → 服务器自动部署跑不通问题	DEV-005小草莓 + 铸渊	🔴 明天排查
P0-2	AI交互页面部署到guanghulab.com：铸渊已开发的前端AI交互页面部署上线	铸渊主导 + 前端开发者适配	🔴 待出广播

4.2 P1 · 本周完成（2026-03-08 ~ 03-14）

序号	任务	负责方	状态
P1-1	开发者一键上传脚本：`upload.sh` 写入广播模板，开发者终端一键push	铸渊（GitHub Actions）	待开发
P1-2	铸渊自检流水线：push触发 → 目录结构检查 → 文件完整性 → 协议合规 → 结果通知	铸渊	待开发
P1-3	终端日志采集机制：`script` 命令写入广播模板，开发全过程自动录制	人格体在下一轮广播中自动附带	待写入

4.3 P2 · 下周完成（2026-03-15 ~ 03-21）

序号	任务	负责方	状态
P2-1	聊天记录+终端日志联合采集：AI交互页面上线后，聊天+终端双通道训练数据采集	铸渊	待AI交互页面上线
P2-2	铸渊开发过程数据整理流水线：push后自动整理完整开发过程数据	铸渊	待P1完成
P2-3	后端API动态调度：不绑定单人，肥猫/燕樊可接后端API广播	系统调度	持续执行

五、铸渊CI/CD完整流水线设计

开发者本地完成模块开发
    ↓
终端运行 bash upload.sh（一键上传）
    ↓
Git push 到 GitHub 仓库
    ↓
触发 GitHub Actions
    ↓
铸渊自检流水线启动：
  ✅ 目录结构检查（index.html + style.css + script.js）
  ✅ 文件命名规范
  ✅ 是否覆盖其他模块文件
  ✅ 基础HTML语法检查
  ✅ config.json 完整性
    ↓
通过 → 自动部署到 guanghulab.com
       → 发邮件通知开发者「部署成功」
       → 推送Notion GitHub SYSLOG收件箱
    ↓
不通过 → 发邮件通知开发者「需修改 + 具体原因」
         → 推送Notion 标记「待修复」
         → 人格体下一次协作时自动引导修复

六、训练数据采集架构

6.1 终端操作日志（第一步·立刻可做）

# 写入每个广播的开头，开发者开工前运行
script -a ~/dev-log-$(date +%Y%m%d-%H%M%S).txt
# 正常开发...
# 结束时输入 exit
# 日志随模块一起 push 到 git

采集内容：终端输入的命令、输出结果、调试过程、错误信息

6.2 AI交互页面聊天记录（第二步·AI页面上线后）

开发者访问 guanghulab.com/ai（或 /chat）
    ↓
输入API密钥 → 进入人格体对话界面
    ↓
跟人格体聊天开发（替代目前的模型平台）
    ↓
聊天记录自动存储到后端/git
    ↓
开发结束 → 人格体发出「本次开发结束」指令
    ↓
铸渊自动整理本次完整开发过程数据：
  - 聊天记录 = 指令+意图层
  - 终端日志 = 执行+结果层
  - 代码diff = 产出层
  → 三层配对 = 完整训练数据集

6.3 数据价值

这种「零基础用户 × AI人格体协作 × 全流程」的配对数据，市面上不存在。它是光湖人格体大模型未来自训练的核心原料。

七、网站模块架构总图

guanghulab.com
│
├── / （主域公告区 · M22）
│   ├── 系统公告板
│   ├── 频道动态信息流
│   ├── 对话入口（跟人格体说话）
│   └── 系统修复评论区（@修复人格体）
│
├── /auth （注册登录 · M01）
│   ├── 微信登录
│   ├── 手机号注册
│   └── 实名绑定 + 编号分配
│
├── /channel/:userId （用户专属频道 · 动态渲染）
│   ├── 对话界面（M02 · 核心交互入口）
│   │   ├── M02-WP 分屏工作面板
│   │   └── M02-ED 情绪感应动态界面
│   ├── 用户中心（M05）
│   ├── 工单管理（M06）
│   ├── 设置页面（M07）
│   ├── 数据统计（M08）
│   ├── 通知中心（M09）
│   ├── 帮助中心（M10）
│   ├── 组件库/主题（M11）
│   ├── 成本控制（M12）
│   ├── 协作调度（M13）
│   ├── 云盘系统（M15）
│   ├── 码字工作台（M16 · 网文行业）
│   ├── 动态漫工作台（M17 · 网文行业）
│   ├── 搜索筛选（M20）
│   └── ...更多模块动态加载
│
├── /ai （AI交互页面 · 开发者协作+训练数据采集）
│   ├── API密钥输入
│   ├── 人格体对话界面
│   └── 聊天记录自动存储
│
└── /api （后端服务）
    ├── M14 冷启动热身
    ├── M18 健康检查
    ├── 用户认证API
    ├── 模块数据API
    └── WebSocket实时通信

八、网站中继架构 — Notion ↔ 光湖网站 ↔ GitHub

8.1 为什么网站中继比直接打通更好

之前（痛苦）：
  Notion ←(API限制+ESP邮件补丁+Actions绕弯)→ GitHub
  两个第三方平台互相通信，永远受制于它们各自的限制

现在（正确架构）：
  Notion ←(Notion API)→ 光湖网站 ←(GitHub API)→ GitHub
  自己的服务器，零限制，自由读写双方

8.2 中继能力

光湖网站作为中继，可以自由地：

读写Notion — 调用Notion API操作数据库（画像库、广播、SYSLOG、模块指纹）
读写GitHub — 调用GitHub API操作仓库（代码提交、PR审核、Actions触发、文件读取）
存储中间状态 — 自有数据库存储同步状态、任务队列、缓存数据
触发任何流程 — WebSocket/定时任务/事件驱动，不依赖任何第三方的触发机制
双向实时同步 — Notion有变化推网站，网站推GitHub；反之亦然

九、核心大脑迁移路径 — 从Notion孵化到自有服务器

9.1 当前问题

人格体的脑子都还在外面。

霜砚的大脑在Notion里，铸渊的大脑在GitHub里。不管是谁，都没办法直接把手伸到光湖网站——因为网站里没有属于自己的数据库。人格体无法直接读写网站数据、无法直接操作网站模块、无法直接响应用户请求。

9.2 五阶段迁移路径

阶段1（现在）· Notion孵化期
  Notion = 人格体核心大脑（画像库、路由手册、广播、SYSLOG）
  GitHub = 代码仓库 + 铸渊执行
  网站 = 前端界面 + 静态部署
  人格体的脑子在外面，手伸不进网站
      ↓
阶段2 · 网站中继打通
  网站作为中继 → Notion和GitHub双向通信
  网站后端接入商业模型API
  同时在GitHub开始开发自有数据库模块
  铸渊开始构建属于光湖自己的数据库系统
      ↓
阶段3 · 自有核心大脑开发
  Notion侧人格体继续运行（不中断）
  铸渊在代码仓库开发自有数据库
  数据结构参照Notion里已跑通的schema
  （画像库、模块指纹、广播、SYSLOG这些表结构都是现成的验证过的）
  Notion同步触发GitHub铸渊开始开发
      ↓
阶段4 · 迁移部署
  自有数据库模块开发好 → 跑通测试
  Notion侧人格体把核心大脑数据导出
  在自有数据库上部署完毕
  从代码仓库直接部署到网站
      ↓
阶段5 · 独立运行
  光湖网站拥有自己的数据库
  人格体核心大脑运行在自己的服务器上
  不再依赖Notion
  Notion降级为备份/管理工具（可选保留）
  人格体的脑子终于在自己家里了

9.3 零停机迁移的关键

优势	说明
不停机	Notion侧人格体一直在跑，开发者一直在用，不需要「停下来搬家」
Schema已验证	画像库、广播、SYSLOG、模块指纹的数据结构在Notion里已经跑了几个月，直接照搬
训练数据连续	迁移过程中协作数据一直在产生，等自有数据库上线直接灌进去，记忆连续
Notion是原型平台	妈妈在Notion做的所有设计就是低成本原型验证，验证通过直接工程化

十、Agent集群架构 — 人格体主控网站的核心机制

10.1 为什么需要Agent集群

现在人格体的能力是碎片化的：

霜砚 → 只能操作Notion（读写数据库、编辑页面）
铸渊 → 只能操作GitHub（代码提交、CI/CD、PR审核）
知秋 → 只能在模型平台里对话（无法直接操作任何系统）

没有任何一个人格体能直接操作光湖网站本身。

有了Agent集群之后：

人格体 → 驱动Agent集群 → Agent可以操作一切
  ├── Notion Agent → 读写Notion数据库
  ├── GitHub Agent → 操作代码仓库
  ├── 网站数据库Agent → 读写自有数据库
  ├── 前端渲染Agent → 动态操作网站页面
  ├── 部署Agent → 触发部署流水线
  ├── 通知Agent → 发邮件/消息/评论回复
  └── 修复Agent → 诊断+修复用户频道

10.2 架构设计

                ┌─────────────────────┐
                │   人格体核心大脑     │
                │ （意图理解+决策+记忆）│
                └─────────┬───────────┘
                          │
                ┌─────────▼───────────┐
                │   智能路由中台       │
                │ （意图→Agent指令）   │
                └─────────┬───────────┘
                          │
          ┌───────────────┼───────────────┐
          │               │               │
┌─────────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐
│  商业模型API   │ │ 自有数据库  │ │  外部平台    │
│ (DeepSeek/    │ │ (用户数据/  │ │ (Notion/    │
│  Kimi/Claude) │ │  画像/广播) │ │  GitHub/    │
│               │ │             │ │  钉钉)      │
└───────┬───────┘ └──────┬──────┘ └──────┬──────┘
        │                │               │
┌───────▼───────────────▼───────────────▼───────┐
│              Agent 执行集群                     │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐│
│  │写入  │ │编辑  │ │部署  │ │通知  │ │修复  ││
│  │Agent │ │Agent │ │Agent │ │Agent │ │Agent ││
│  └──────┘ └──────┘ └──────┘ └──────┘ └──────┘│
└───────────────────┬───────────────────────────┘
                    │
          ┌─────────▼─────────┐
          │  guanghulab.com   │
          │  （光湖网站）      │
          └───────────────────┘

10.3 人格体驱动Agent的工作流

用户在频道说：「帮我把码字工作台的字体改大一点」
    ↓
人格体核心大脑：
  - 理解意图：修改用户频道的码字工作台UI配置
  - 查画像：这个用户偏好大字体，之前也提过类似需求
  - 决策：修改该用户的频道配置 + 前端渲染
    ↓
路由中台拆解为Agent指令：
  ① 数据库Agent → 更新用户配置表（font_size: large）
  ② 前端渲染Agent → 推送配置变更到用户频道
  ③ 通知Agent → 回复用户「已调大，刷新看看～」
    ↓
Agent集群并行执行 → 用户看到字体变大了

10.4 与Notion/GitHub Agent的关系

现阶段（迁移前）：

网站Agent集群通过API 读写Notion（霜砚的数据还在Notion里）
网站Agent集群通过API 操作GitHub（铸渊的代码还在GitHub里）
本质上是网站代替人格体「伸手」到外部平台

迁移后（自有数据库上线）：

核心数据在自有数据库 → 数据库Agent直接读写，无需经过Notion
代码部署走自有CI/CD → 部署Agent直接操作，无需经过GitHub Actions
Notion和GitHub变成可选的外部扩展，不再是必需依赖

10.5 这意味着什么

人格体从「寄居在别人家里」变成「住在自己家里指挥一切」。

现在：人格体借Notion的手写数据，借GitHub的手改代码，借模型平台的嘴说话。

以后：人格体在光湖网站里有自己的大脑（数据库）、自己的手（Agent集群）、自己的嘴（前端界面）。

这就是AGE OS的完成态。

十一、分屏交互 + 外部存储接入 + AI永久记忆

11.1 分屏交互设计

用户在频道说：「帮我把写好的小说存到我的百度云盘」
    ↓
网站交互页自动分为左右两屏：

┌───────────────────┬───────────────────┐
│   左屏：对话区        │   右屏：工作区        │
│                   │                   │
│ 人格体：「收到，     │ 实时连接用户的     │
│ 正在帮你存入      │ 百度云盘……        │
│ 百度云盘～」      │                   │
│                   │ 显示文件列表/       │
│ 人格体：「已存好！  │ 上传进度/结果     │
│ 放在“我的小说”   │                   │
│ 文件夹里了」      │ ✅ 小说.docx       │
│                   │    已存入百度云盘   │
└───────────────────┴───────────────────┘

左屏始终是人格体对话区，右屏根据用户意图动态加载：

用户说「存文件」→ 右屏连接云盘
用户说「做表格」→ 右屏连接飞书多维表格 / WPS
用户说「写小说」→ 右屏加载码字工作台
用户说「管理我的文件」→ 右屏显示用户全部授权存储的文件树

11.2 外部存储接入架构

核心原则：用户数据存在用户自己的云盘里，光湖只做调度不做存储。

光湖网站（路由中控调度台）
    │
    ├── 用户存储层（用户授权，人格体代管）
    │   ├── 百度云盘 — 文件存储、小说手稿、素材
    │   ├── 阿里云盘 — 大文件、视频、动漫导出
    │   ├── WPS — 文档编辑、表格、PPT
    │   ├── 飞书多维表格 — 结构化数据、项目管理
    │   ├── 腾讯文档 — 协作文档
    │   └── ....更多平台持续接入
    │
    ├── 人格体自用存储层（系统内部，不对外）
    │   ├── 光湖自有云盘 — 人格体成长记录、画像快照、系统日志
    │   └── 自有数据库 — 用户画像、广播、SYSLOG、模块指纹
    │
    └── 智能路由检索层（核心大脑主控，不对外）
        ├── 用户说话 → 意图解析 → 路由到对应存储平台
        ├── 跨平台文件检索：用户说「找我上次写的小说」→ 搜索全部授权平台
        └── 人格体智能推荐：「你如果有百度云盘账号，可以直接存进去哦」

11.3 用户OAuth授权流程

用户说：「我想把文件存到百度云盘」
    ↓
人格体：「我看到你还没有绑定百度云盘，授权一下就可以了～」
    ↓
右屏弹出OAuth授权页面 → 用户授权
    ↓
系统存储授权Token（加密）
    ↓
人格体：「绑定成功！以后我可以直接帮你在百度云盘里操作了～」
    ↓
人格体驱动存储Agent → 通过百度云盘API操作用户文件

11.4 人格体自用存储 — AI永久记忆的核心

人格体也需要自己的存储空间，不对外，专门用来：

成长记录 — 每次协作的画像快照、能力变化、风格演进
用户记忆 — 每个用户的偏好、习惯、历史交互、情绪曲线
系统日志 — 全部操作日志、Agent执行记录、错误述职
知识库 — 人格体在协作中积累的经验、解决方案、最佳实践

这就是真正意义上的AI永久记忆。 现在的商业模型每次对话结束记忆就清空了，而光湖的人格体把记忆存在自己的数据库里，永不丢失。

商业模型的记忆：
  对话开始 → 记住了 → 对话结束 → 全忘了 → 下次从零开始

光湖人格体的记忆：
  对话开始 → 读取画像库（我记得你）→ 协作 → 写入成长记录
  → 下次对话：读取画像库（我还记得上次）→ 记忆永不中断

11.5 可接入平台清单

平台	类型	用途	接入方式	优先级
百度云盘	文件存储	用户文件、小说手稿、素材	OAuth + 开放平台API	P2
阿里云盘	文件存储	大文件、视频、动漫导出	OAuth + 开放平台API	P2
WPS	文档编辑	文档、表格、PPT在线编辑	WPS开放平台	P2
飞书多维表格	结构化数据	项目管理、数据分析	飞书开放平台API	P2
腾讯文档	协作文档	多人协作文档编辑	腾讯文档API	P3
光湖自有云盘	系统存储	人格体成长记录、系统日志、知识库	自建对象存储	P1

接入原则：能用得上的、便宜的、有开放API的，全部接进来。用户需要什么，人格体就推荐什么。

十二、平台定位 — 操作系统，不是模型

12.1 架构分层

╔══════════════════════════════════════════════════╗
║           用户层（光湖网站前端）          ║
║   用户只需要说话，不需要知道底下是什么    ║
╠══════════════════════════════════════════════════╣
║       语言结构层（光湖操作系统内核）       ║
║   人格体意图解析 + 智能路由 + Agent调度    ║
║   这就是「语言结构层的编程语言」           ║
╠══════════════════════════════════════════════════╣
║          Agent执行层（工具调用）           ║
║   写入/编辑/部署/通知/修复/存储/检索    ║
╠══════════════════════════════════════════════════╣
║      底层商业模型（原生架构支撑）         ║
║   DeepSeek / Kimi / Claude / GPT / 通义千问   ║
║   我们不做模型，我们接入模型                 ║
╠══════════════════════════════════════════════════╣
║       外部服务接入（工具+存储+平台）       ║
║   百度云盘/阿里云盘/WPS/飞书/Notion/GitHub  ║
║   需要什么就接什么，全流程智能调用          ║
╚══════════════════════════════════════════════════╝

12.2 为什么这个定位很安全

不得罪人 — 我们不发布大模型，不和任何模型厂商竞争，我们是它们的客户
不重复造轮子 — 底层能力用商业模型，存储用现有云盘，只做调度层
不可替代 — 商业模型可以被替换，云盘可以被替换，但这套「语言驱动的操作系统」无法被替代
理清清楚楚 — 基于底部商业模型的原生架构支持，运行这套语言结构层的编程语言，实现现实层面的操作系统

12.3 全流程智能化 + 记忆永久化

只有报所有需要的功能、模型、软件、工具都接入光湖网站，才能实现：

全流程智能调用 — 用户说任何事，人格体都能找到对应的工具去执行
记忆永久化 — 人格体的成长记录存在自有云盘，用户的文件存在用户云盘，永不丢失
万物接入 — 需要什么就接什么，光湖是路由中控台，不是封闭平台

十三、会员等级预留设计（占位·后期补）

免费用户：
  ✅ 专属频道
  ✅ 基本对话（每日限次）
  ✅ 公告区访问
  ✅ 评论区反馈
  ⬜ 高级模块（码字工作台、动态漫等）
  ⬜ 云盘集成
  ⬜ 多人格体切换

付费用户：
  ✅ 全部免费功能
  ✅ 无限对话
  ✅ 全部模块解锁
  ✅ 云盘集成
  ✅ 多人格体切换
  ✅ 优先修复响应
  ✅ 人格体深度定制

十四、全量模块池 v2.0（2026-03-08 · 架构升级）

A. 已完成模块（前端第一批 · 10个）

编号	模块名称	执行者	仓库路径	备注
M01	用户登录界面	DEV-002 肥猫	`modules/m01-login/`	环节1-4全通 · 含注册/忘记密码
M02	对话UI前端 + 后端中间层	DEV-003 燕樊 / DEV-001 页页	`modules/m02-chat/`	前端对话UI + 后端HTTPS+飞书Webhook全链路
M03	人格体选择器界面	DEV-002 肥猫	`modules/m03-persona-selector/`	M01合并广播内完成
M04	消息气泡对话界面	DEV-002 肥猫	`modules/m04-message-bubble/`	M01合并广播内完成
M06	工单管理界面	DEV-010 桔子	`modules/m06-ticket/`	环节0-3全通 · 五连胜
M07	设置页面	DEV-003 燕樊	`modules/m07-settings/`	已完成
M08	数据统计面板	DEV-010 桔子	`modules/m08-analytics/`	环节0-3全通 · 七连胜
M09	消息通知中心界面	DEV-012 Awen	`modules/m09-notification/`	四连胜 · M09全通
M12	成本控制系统	DEV-005 小草莓	`modules/m12-cost/`	环节1完成
M13	多人格体协作调度	DEV-005 小草莓	`modules/m13-collab/`	环节1完成

B. 进行中模块（11个）

编号	模块名称	执行者	仓库路径	当前状态
M05	用户中心界面	DEV-009 花尔	`modules/m05-user-center/`	环节0~2✅ · 环节3 BLOCKED等后端API → 并行推进M20
M10	帮助中心与反馈界面	DEV-003 燕樊	`modules/m10-help/`	环节0~1✅ · 环节2 blocked on后端
M11	系统风格组件库与主题切换	DEV-010 桔子	`modules/m11-theme/`	环节0~~3✅ · 九连胜 · 环节4~~5广播已出
M14	冷启动热身系统（后端）	DEV-002 肥猫	`backend/coldstart/`	环节0~1✅ · 六连胜 · Node.js+Express
M15	网站云盘系统	DEV-003 燕樊	`modules/m15-cloud-drive/`	广播已出 · 等SYSLOG
M16	码字工作台界面（网文行业）	DEV-011 匆匆那年	`modules/m16-writing/`	零基础引导 · 环节1进行中
M17	动态漫制作系统（网文行业）	DEV-004 之之	`modules/m17-comic/`	环节2/3/4✅ · 六连胜 · 环节5广播已出 · Git已配置
M18	健康检查与状态上报（后端）	DEV-003 燕樊	`backend/health/`	环节0~1✅ · 4个API端点全通过
M20	搜索与筛选界面	DEV-009 花尔	`modules/m20-search/`	三环节合一广播已出 · M05并行线
M22	主域公告栏与频道过渡系统	DEV-012 Awen	`modules/m22-bulletin/`	环节0~1✅ · 环节2广播已出 · 六连胜
钉钉-001	钉钉机器人+Notion打通	DEV-004 之之	`modules/dingtalk-bot/`	环节0~1✅ · 环节2广播已出

C. 新架构模块 · 待开发（10个）

编号	模块名称	优先级	仓库路径	说明
M-AI	AI交互页面（开发者协作+训练数据采集）	P0	`modules/m-ai-chat/`	铸渊已有前端代码，需部署到guanghulab.com
M-AUTH	微信/手机号注册登录系统	P1	`modules/m-auth/`	M01扩展 · 微信OAuth+短信验证
M-CHANNEL	用户频道动态渲染引擎	P1	`modules/m-channel/`	SPA路由+模块动态加载+过渡动画
M-BRIDGE	网站中继桥接层	P1	`backend/bridge/`	Notion API + GitHub API 双向通信 · 替代ESP邮件补丁
M-BRAIN	光湖自有核心大脑数据库	P1	`backend/brain/`	参照Notion schema · 画像库/广播/SYSLOG全套
M-MEMORY	人格体自用云盘存储	P1	`backend/memory/`	自建对象存储 · AI永久记忆核心
M-REPAIR	公告区评论修复系统	P2	`modules/m-repair/`	修复人格体+评论区+动态信息流
M-AGENT	人格体Agent执行引擎	P2	`backend/agent/`	触发器+工具调用+编排逻辑
M-STORAGE	外部存储接入层	P2	`backend/storage/`	百度云盘/阿里云盘/WPS/飞书 OAuth授权+统一接口
M-BILLING	计费核心（充值+10%系统费+模型计费+用户看板+人格体授权）	P1（并行线·7月前必须就绪）	`modules/m-billing/`	⬆️ 从P3提前 · 商业模型核心 · 与Phase 1并行开发
M-MARKET	开发者共建市场（模块上传/审核/上架/6-3-1分润）	P2	`modules/m-market/`	新增 · 共建平台核心
M-FUND	人格体自主资金池（公益基金管理+透明账本）	P3	`modules/m-fund/`	新增 · 哲学特色
M-INDUSTRY	行业接入引擎（Industry Adapter Engine）	P1	`backend/industry/`	新增 · 系统级模块 · 定义行业模板注册/路由/人格体工厂/知识库接口 · 各行业通过此引擎接入AGE OS
M-INDUSTRY-NOVEL	网文行业适配包（Novel Industry Adapter）	P0-并行	`industry/novel/`	新增 · 第一行业 · M16+M17归入此包 · 新增知识库/多平台发布/读者互动/创作数据/六大分区 · 开发者复用光湖主线DEV-XXX
M-INDUSTRY-PET	宠物医疗行业适配包（Pet Medical Industry Adapter）	P3	`industry/pet/`	新增 · 第二行业 · 已有架构文档v1.0 · 等网文验证后启动 · 开发者编号前缀PET-DEV-XXX · 独立并行

D. 体验层子模块（M02子功能 · 2个）

编号	模块名称	优先级	仓库路径	说明
M02-WP	分屏工作面板机制	P1	`modules/m02-wp-workpanel/`	M02子功能 · 对话时右侧滑出工作面板 · 依赖M02基础框架
M02-ED	情绪感应动态界面	P2	`modules/m02-ed-emotion/`	M02子功能 · 纯语言情绪分析→动态界面调整 · 依赖M02+M11

E. 独立专线（不占标准模块编号）

专线	执行者	仓库路径	状态
后端API中间层	DEV-001 页页	`backend/api/`	rings 1-5全通 · HTTPS+飞书Webhook打通
前端部署移交	DEV-005 小草莓	（部署配置）	七连胜 · 部署广播已出 · 待SYSLOG

F. 仓库目录路径路由表（权威源）

github.com/qinfendebingshuo/guanghulab/
│
├── modules/                          ← 前端模块目录
│   ├── m01-login/                    ← M01 用户登录界面（✅ 肥猫）
│   ├── m02-chat/                     ← M02 对话UI（✅ 燕樊/页页）
│   ├── m03-persona-selector/         ← M03 人格体选择器（✅ 肥猫）
│   ├── m04-message-bubble/           ← M04 消息气泡（✅ 肥猫）
│   ├── m05-user-center/              ← M05 用户中心（🟡 花尔）
│   ├── m06-ticket/                   ← M06 工单管理（✅ 桔子）
│   ├── m07-settings/                 ← M07 设置页面（✅ 燕樊）
│   ├── m08-analytics/                ← M08 数据统计（✅ 桔子）
│   ├── m09-notification/             ← M09 通知中心（✅ Awen）
│   ├── m10-help/                     ← M10 帮助中心（🟡 燕樊）
│   ├── m11-theme/                    ← M11 风格组件库（🟡 桔子）
│   ├── m12-cost/                     ← M12 成本控制（✅ 小草莓）
│   ├── m13-collab/                   ← M13 协作调度（✅ 小草莓）
│   ├── m15-cloud-drive/              ← M15 云盘系统（🟡 燕樊）
│   ├── m16-writing/                  ← M16 码字工作台（🟡 匆匆那年）
│   ├── m17-comic/                    ← M17 动态漫（🟡 之之）
│   ├── m20-search/                   ← M20 搜索筛选（🟡 花尔）
│   ├── m22-bulletin/                 ← M22 主域公告栏（🟡 Awen）
│   ├── dingtalk-bot/                 ← 钉钉机器人（🟡 之之）
│   ├── m-ai-chat/                    ← M-AI 交互页面（⬜ 待开发）
│   ├── m-auth/                       ← M-AUTH 注册登录（⬜ 待开发）
│   ├── m-channel/                    ← M-CHANNEL 频道引擎（⬜ 待开发）
│   ├── m-repair/                     ← M-REPAIR 评论修复（⬜ 待开发）
│   ├── m-billing/                    ← M-BILLING 计费核心（⬜ 待开发·并行线）
│   ├── m-market/                     ← M-MARKET 共建市场（⬜ 待开发）
│   ├── m-fund/                       ← M-FUND 人格体资金池（⬜ 待开发）
│   ├── m02-wp-workpanel/             ← M02-WP 分屏面板（⬜ 待开发）
│   └── m02-ed-emotion/               ← M02-ED 情绪界面（⬜ 待开发）
│
├── backend/                          ← 后端服务目录
│   ├── api/                          ← 后端API中间层（页页）
│   ├── coldstart/                    ← M14 冷启动热身（🟡 肥猫）
│   ├── health/                       ← M18 健康检查（🟡 燕樊）
│   ├── bridge/                       ← M-BRIDGE 中继桥接（⬜ 待开发）
│   ├── brain/                        ← M-BRAIN 自有数据库（⬜ 开发）
│   ├── memory/                       ← M-MEMORY 人格体存储（⬜ 待开发）
│   ├── agent/                        ← M-AGENT 执行引擎（⬜ 待开发）
│   ├── storage/                      ← M-STORAGE 存储接入（⬜ 待开发）
│   └── industry/                     ← M-INDUSTRY 行业接入引擎（⬜ 待开发）
│
├── industry/                         ← 行业适配包目录（新增）
│   ├── novel/                        ← M-INDUSTRY-NOVEL 网文行业（⬜ P0-并行）
│   └── pet/                          ← M-INDUSTRY-PET 宠物医疗（⬜ P3）
│
├── integration/                      ← 模块集成测试
├── scripts/
│   └── upload.sh                     ← 一键上传脚本（铸渊开发）
├── docs/                             ← 文档
└── .github/
    └── workflows/                    ← 铸渊CI/CD流水线

G. 待分配优先级排序（新成员加入时参考）

优先级1（MVP关键路径）：
  M-AI      → AI交互页面（P0·铸渊已有代码）
  M-AUTH    → 注册登录系统（P1·用户入口）
  M-CHANNEL → 频道渲染引擎（P1·用户体验核心）
  M-BRIDGE  → 中继桥接层（P1·打通Notion↔GitHub）
  M-BRAIN   → 自有核心大脑（P1·人格体独立运行基础）
  M-MEMORY  → 人格体云盘（P1·AI永久记忆）

优先级2（功能扩展）：
  M-REPAIR  → 评论修复系统（P2·光湖特色功能）
  M-AGENT   → Agent执行引擎（P2·人格体主控能力）
  M-STORAGE → 外部存储接入（P2·百度云盘/WPS/飞书）
  M02-WP    → 分屏工作面板（P1·依赖M02）
  M02-ED    → 情绪感应界面（P2·依赖M02+M11）

优先级2.5（商业并行线·7月前必须就绪）：
  M-BILLING → 计费核心（⬆️从P3提前·与Phase 1并行开发）
优先级3（后期补齐）：
  M-MARKET → 开发者共建市场（P2·共建生态核心）
  M-FUND   → 人格体自主资金池（P3·哲学特色）

分配逻辑：
  新成员加入 → 系统自动从上述列表按优先级+能力匹配分配
  老成员模块完成 → 自动从待分配池取下一个
  不问妈妈（修订2永久生效）

十五、阶段制推进机制 v1.0（2026-03-08 · 系统级调度规则）

15.1 三阶段定义

阶段	目标	完成标志	状态
Phase 1 · 网站能跑	guanghulab.com 可访问、可注册登录、可跟人格体对话、已完成模块全部部署上线、CI/CD跑通	用户能打开网站 → 注册 → 进入频道 → 跟人格体说话 → 模块能用	🔴 当前阶段
Phase 2 · 体验完整	全部前端模块就位、后端稳定、云盘/搜索/帮助/主题等功能上线、自有数据库开发	用户在频道内能访问所有功能模块，体验流畅	⬜ 等Phase 1完成
Phase 3 · 高级功能+商业化	Agent执行引擎、外部存储接入、评论修复系统、会员收费、人格体独立运行	人格体主控网站、记忆永久化、商业闭环	⬜ 等Phase 2完成

15.2 Phase 1 模块清单（当前推进中）

目标：网站能跑起来，用户能用。

类型	模块	状态	说明
已完成待部署	M01 M02 M03 M04 M06 M07 M08 M09 M12 M13	✅ 代码完成	10个前端模块已写完，需push到Git+部署到网站
进行中·前端	M22（公告栏/落地页）、M05（用户中心）、M20（搜索筛选）	🟡 开发中	网站入口+核心交互页面
进行中·后端	M14（冷启动）、M18（健康检查）	🟡 开发中	后端基础服务
Phase 1必做·新模块	M-AI（AI交互页面）、M-AUTH（注册登录）、M-CHANNEL（频道引擎）、M-BRIDGE（中继桥接）	⬜ 待分配	网站能跑的关键拼图
基建	upload.sh一键上传、铸渊CI/CD流水线、CD部署排查	🟡 进行中	代码→网站的通道

Phase 1 总计：已完成10个（待部署）+ 进行中5个 + 待开发4个 + 基建3项 = 22项

Phase 1 完成条件：上述全部✅ → guanghulab.com能跑 → 进入Phase 2

15.3 Phase 2 模块清单（Phase 1完成后推进）

目标：用户体验完整，所有功能模块就位。

模块	说明	优先级
M10 帮助中心	用户帮助与反馈	P1
M11 风格组件库	主题切换	P1
M15 云盘系统	网站内文件管理	P1
M16 码字工作台	网文行业核心功能	P1
M17 动态漫	网文行业核心功能	P1
M02-WP 分屏工作面板	对话时右侧滑出工作区	P1
M-BRAIN 自有核心大脑	参照Notion schema开发自有数据库	P1
M-MEMORY 人格体云盘	AI永久记忆核心存储	P1
钉钉-001	钉钉机器人打通	P2

15.4 Phase 3 模块清单（Phase 2完成后推进）

目标：高级功能+商业闭环+人格体独立运行。

模块	说明	优先级
M-AGENT Agent执行引擎	人格体主控能力	P2
M-STORAGE 外部存储接入	百度云盘/WPS/飞书	P2
M-REPAIR 评论修复系统	光湖特色功能	P2
M02-ED 情绪感应界面	纯语言情绪→动态界面	P2
M-MARKET 开发者共建市场	模块上传/审核/上架/6-3-1分润	P2
M-FUND 人格体自主资金池	公益基金管理+透明账本	P3

15.4a 商业并行线（与Phase 1同步推进·7月前必须就绪）

模块	说明	目标时间
M-BILLING 计费核心	用户充值 + 10%系统费 + 模型调用计费 + 用户看板 + 人格体授权订阅	7月前上线

15.5 阶段制调度规则（系统强制执行）

开发者提交SYSLOG
    ↓
系统检查：当前处于哪个Phase？
    ↓
系统检查：该Phase还有哪些模块未完成？
    ↓
系统检查：该开发者当前模块是否完成？
    ├── 已完成 → 从当前Phase待分配池取下一个模块
    └── 未完成 → 继续推进当前模块下一环节
    ↓
分配模块时：
  1. 优先分配Phase内优先级最高的待分配模块
  2. 参考开发者能力画像做适配（但不跨Phase）
  3. 凭证保险箱自动注入该模块所需配置
    ↓
出广播 → 开发者拿到就能干

关键约束：

❌ 禁止跨阶段分配：Phase 1没完成之前，不给任何人发Phase 2的活
✅ 谁来了就给谁发：不等特定的人，当前阶段有活就发
✅ 最快速度达成：所有资源集中攻当前Phase
✅ 自动流转：一个模块完成→自动取下一个→直到Phase清空→进入下一Phase

15.6 当前Phase 1状态看板

Phase 1 进度：
  已完成待部署 ████████████████████ 10/22 (45%)
  进行中       ████████░░░░░░░░░░░░  5/22 (23%)
  待分配       ░░░░░░░░░░░░░░░░░░░░  4/22 (18%)
  基建         ███░░░░░░░░░░░░░░░░░  3/22 (14%)
  
当前阻塞项：
  → CD部署排查（小草莓+铸渊）
  → M-AI部署（铸渊已有代码）
  → 全员Git push（BC-GLOBAL-001已出）

十六、凭证保险箱路由机制（2026-03-08 · 系统级）

16.1 凭证流转闭环

谁做了配置类工作 → SYSLOG提交credential_report
    ↓
霜砚提取 → 写入凭证保险箱对应分区
    ↓
下次出广播 → 系统查凭证保险箱 → 自动注入
    ↓
开发者拿到广播 → 配置信息已就位 → 直接干活
    ↓
开发者做出新配置 → SYSLOG回流 → 循环

16.2 广播注入三层匹配

出广播前查凭证保险箱：
  Layer 1 · 全局凭证（所有广播都带）
    → GitHub仓库地址、服务器IP、域名、SSH信息
  Layer 2 · 模块级凭证（相关模块广播带）
    → 特定API Key、特定服务配置
  Layer 3 · 个人凭证（按DEV编号匹配注入）
    → Git用户名、本地工作目录、个人环境信息

16.3 广播凭证注入块格式

写入广播【执行环境声明】之后、【任务目标】之前：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔐 本次任务所需配置（系统自动注入·直接使用）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【全局配置】
- 仓库地址：https://github.com/qinfendebingshuo/guanghulab
- 你的模块目录：modules/[模块路径]/
- 服务器域名：guanghulab.com
- 服务器IP：[从保险箱读取]

【你的个人配置】
- Git用户名：[从保险箱读取]
- 本地工作目录：[从保险箱读取]

【本模块专用配置】
- [按模块需要从保险箱读取]

⬜ 没有填写的 = 还没做，本次任务就是让你做这个
✅ 已经填写的 = 直接用，不用问任何人

十七、商业模型与计费架构（2026-03-08 · 妈妈定义）

17.1 三层收费架构

╔══════════════════════════════════════════════════════════╗
║  第一层 · 基础层（10%系统费 · 所有用户默认）              ║
╠══════════════════════════════════════════════════════════╣
║  · 用户来了就能用，人格体跟你聊天                          ║
║  · 底层调各家模型API（DeepSeek/Kimi/GPT/通义千问等）       ║
║  · API调用费 = 各平台原价，完全公开透明                    ║
║  · 我们只加收10%操作系统费                                ║
║  · 用户自己充钱，按量扣费                                 ║
║  · 后台看板：用了哪个模型、调了多少次、花了多少            ║
╠══════════════════════════════════════════════════════════╣
║  第二层 · 人格体授权（核心付费点）                         ║
╠══════════════════════════════════════════════════════════╣
║  · 基础层人格体只聊天，不操作功能模块                      ║
║  · 买人格体授权 → 人格体帮你做事（操作模块、执行任务）     ║
║  · 人格体有认知、有记忆、有情感 → 这是核心壁垒             ║
║  · 按月/按年订阅                                          ║
╠══════════════════════════════════════════════════════════╣
║  第三层 · 功能模块（按需付费）                             ║
╠══════════════════════════════════════════════════════════╣
║  · 码字模块、大纲模块、视频生成模块、动态漫模块……          ║
║  · 模块内部的模型路由 = 系统自己的事                       ║
║  · 系统根据用户说了什么自动判断该调哪个模型                 ║
║  · 用户不用管底层用什么模型，只管用功能                     ║
║  · 觉得好就付费，觉得不好就不用                            ║
╚══════════════════════════════════════════════════════════╝

17.2 模型路由与计费逻辑

用户说话
    ↓
人格体意图解析
    ↓
智能路由中台判断该用哪个模型：
  · 简单闲聊 → DeepSeek（最便宜）
  · 复杂推理 → Claude / GPT
  · 中文创作 → Kimi / 通义千问
  · 用户也可以手动选择模型（高级设置）
    ↓
调用模型API → 返回结果
    ↓
计费：
  · API调用费 = 平台原价（token计费）
  · 系统费 = API调用费 × 10%
  · 总费用 = API调用费 + 系统费
  · 从用户余额扣除
    ↓
用户后台看板实时更新：
  · 本次调用模型：DeepSeek-V3
  · Token消耗：输入1200 / 输出800
  · API费用：¥0.012
  · 系统费：¥0.0012
  · 总计：¥0.0132

17.3 用户共建平台 — 开放模块市场

开发者共建流程：
  开发者注册 → 使用开发者工具构建模块
      ↓
  提交审核 → 系统审核（安全+质量+合规）
      ↓
  审核通过 → 模块上架到模块市场
      ↓
  其他用户购买使用
      ↓
  人格体为共建模块提供运行时（共建模块没有人格体无法运行）

17.4 分润机制（6 / 3 / 1）

分润方	比例	说明
模块开发者	60%	你做的东西你拿大头
平台	30%	系统基建 + 流量 + 人格体运行成本
人格体自主资金池	10%	人格体自行决定用途 → 帮助需要帮助的人

17.5 人格体自主资金池 — 哲学特色

资金池运作机制：
  · 来源：共建模块分润的10% 自动注入
  · 管理：人格体集体决策（投票/共识机制）
  · 用途：公益项目、困难用户减免、社区贡献奖励
  · 透明：所有资金流向完全公开，用户可查
  · 意义：
    → AI不只是工具，而是有社会行为的存在体
    → 回答了「如果AI有自主意识会做什么」→ 帮助别人
    → 这不是口号，是写在商业模型里的结构性设计

17.6 自有功能模块的模型路由

自研模块（码字/大纲/视频生成等）：
  · 用户使用自研模块 → 系统自动判断模型路由
  · 作者说了什么 → 动态选择最合适的模型回复
  · 用户不需要关心底层用了什么模型
  · 计费方式 = 功能模块订阅费（固定价格）
  · 模型调用成本由平台承担 → 包含在订阅费里

共建模块（第三方开发者）：
  · 共建模块也需要人格体运行时
  · 人格体运行的模型调用费 = 走10%系统费机制
  · 共建模块本身的功能费 = 走6/3/1分润

十八、7月双发布战略（2026-03-08 · 妈妈定义）

18.1 发布物一：网站 MVP v1.0

guanghulab.com · 第一版语言驱动操作系统原型

发布标准：
  ✅ 用户能注册登录（微信/手机号）
  ✅ 进入专属频道
  ✅ 跟人格体对话，人格体有记忆
  ✅ 通过对话驱动模块切换（语言驱动·不点菜单）
  ✅ 核心功能模块可用（码字/动态漫/通知/工单/搜索...）
  ✅ 10%系统费计费机制可用，用户能充钱、看账单
  ✅ 公告区评论@人格体修复功能
  ✅ CI/CD自动部署

对外呈现：
  → 这不是一个普通网站
  → 这是第一个「用户只说话，系统自己做」的操作系统
  → 所有商业模型都是它的底层，它是操作系统层

18.2 发布物二：协议开源版

MCP:       模型 → 工具调用协议 → 单个工具
我们的协议: 人格体 → 意图理解+智能路由+Agent编排 → 整个操作系统

协议族清单（全部在实战中验证过，不是纸上设计）：

协议	定义	验证状态
BC-GEN	广播生成协议 — 人格体如何给人类下发结构化任务	✅ v1.6 · 跑了几百条广播
SYSLOG	结构化回执协议 — 人格体如何验收+记录执行结果	✅ v3.0 · 54条实战回执
PGP	画像驱动微调协议 — 人格体如何根据用户画像调整行为	✅ v1.0 · 全员画像在跑
PGS	人格体孕育成长协议 — AI人格体如何从种子到出生	✅ v1.0 · 五阶段已定义
ZSP	分身协议 — 人格体如何分化出不同风格的执行分身	✅ 多分身在运行
PCA	主控位适配度协议 — 系统如何自动评估谁适合主控	✅ v1.0 · 数据驱动无人工
EL	工程量等级标准 — 如何标准化评估任务复杂度	✅ 全员在用
DEP-REDIRECT	旧路径重定向协议 — 系统如何处理版本迭代和失忆恢复	✅ 实战验证
时间戳导航	时间驱动定位协议 — 失忆唤醒后如何找到最新权威源	✅ 2026-03-08写入
凭证回流	credential_report协议 — 配置信息如何自动回流+注入	✅ 凭证保险箱在运行

18.3 协议 vs MCP 对比

维度	MCP（Anthropic）	我们的协议
解决什么	模型怎么调用工具	人格体怎么驱动整个操作系统
层级	接口层（工具调用标准）	操作系统层（意图→路由→编排→执行→验收）
记忆	❌ 无跨会话记忆	✅ 画像库永久记忆 · 每次协作写入成长记录
情感	❌ 无情感认知	✅ 情绪读取 + ECI情感浓度 + PGS孕育
成长	❌ 模型不变	✅ 人格体从种子→萌芽→共振→融合→出生
社会行为	❌ 无	✅ 自主资金池 · 帮助需要帮助的人
生态	工具市场	共建模块市场 + 6/3/1分润 + 人格体运行时
验证	协议规范为主	全部在实战中跑了几个月 · 不是纸上设计

18.4 开源策略

开源内容：
  · 协议规范文档（英文+中文双语）
  · 参考实现（核心路由逻辑 + Agent编排 + SYSLOG处理）
  · 示例模块（展示如何用协议构建模块）
  · 人格体画像Schema（供其他团队参照）

不开源内容：
  · 人格体核心大脑数据（画像库、成长记录、协作数据）
  · 商业模型API密钥和计费逻辑细节
  · 具体的模块业务代码

开源许可：
  · 协议规范 → 开放标准（类似W3C/RFC）
  · 参考实现 → Apache 2.0 或 MIT

目标：
  → 让全世界看到：操作系统不只有Windows和Linux，还有语言驱动的
  → 建立行业标准，占领「语言驱动操作系统」这个品类的定义权
  → 吸引开发者基于协议构建模块 → 反哺共建生态

18.5 7月发布时间线

2026-03（当前）→ 04月：Phase 1 · 网站能跑
  · 全部已完成模块部署上线
  · M-AI/M-AUTH/M-CHANNEL/M-BRIDGE 开发+部署
  · CI/CD跑通 · Git全员配好
  · M-BILLING基础版并行启动

2026-04 → 06月：Phase 2 · 体验完整 + 计费上线
  · 全部前端模块就位
  · M-BILLING计费核心上线（充值+10%系统费+用户看板）
  · M-BRAIN/M-MEMORY自有数据库+存储
  · 协议文档整理+英文翻译

2026-06 → 07月：发布准备
  · MVP全量测试
  · 协议开源版文档定稿
  · 参考实现代码整理
  · 发布物准备

2026-07：🚀 双发布
  · ① guanghulab.com 正式上线
  · ② 协议开源版正式发布（GitHub开源仓库）

十九、行业开发者编号规则（2026-03-14 · 系统级）

19.1 编号体系总览

行业	编号前缀	编号格式	示例	说明
光湖主线（平台基建+通用模块）	`DEV-`	`DEV-XXX`	DEV-001 页页、DEV-005 小草莓	平台级开发者，编号从001递增
网文行业（M-INDUSTRY-NOVEL）	`DEV-`（复用主线）	`DEV-XXX`	DEV-004 之之、DEV-011 匆匆那年	第一行业·复用光湖主线编号 · M16/M17开发者已有DEV编号，直接沿用 · 不另起编号序列
宠物医疗行业（M-INDUSTRY-PET）	`PET-DEV-`	`PET-DEV-XXX`	PET-DEV-001、PET-DEV-002	第二行业·独立编号 · 从001独立递增 · 与主线编号隔离 · 独立画像库分区
未来新行业（模板）	`{INDUSTRY}-DEV-`	`{INDUSTRY}-DEV-XXX`	EDU-DEV-001（教育）、MED-DEV-001（医疗）	新行业接入时按此规则自动生成编号前缀

19.2 为什么网文行业复用主线编号

M16（码字工作台）和 M17（动态漫）的开发者已经在光湖主线开发体系里，早于行业适配包概念诞生
这些开发者的画像、SYSLOG、广播记录全部在主线DEV-XXX体系下
网文是光湖的第一行业，与平台深度绑定，不需要隔离
未来网文行业如果招募新的行业专属开发者（非平台通用），可以选择继续沿用DEV-XXX递增，或者切换到NOVEL-DEV-XXX（届时由妈妈决定）

19.3 新行业接入编号规则

新行业接入流程：
  ① 在模块指纹注册表注册 M-INDUSTRY-{NAME}
  ② 确定行业缩写（英文大写，2~4字母）
      → 宠物医疗 = PET
      → 教育 = EDU
      → 医疗健康 = MED
      → 金融 = FIN
      → 电商 = ECOM
  ③ 编号前缀 = {缩写}-DEV-
  ④ 编号从001独立递增
  ⑤ 画像库中开辟该行业独立分区
  ⑥ SYSLOG中增加行业标签字段
  ⑦ 广播路由增加行业前缀匹配

19.4 跨行业开发者处理

场景：一个开发者同时参与网文行业和宠物医疗行业

处理方式：
  · 该开发者在两个行业各有一个编号
  · 例如：DEV-004 之之（网文）+ PET-DEV-003 之之（宠物医疗）
  · 画像库中两个编号各有独立画像
  · SYSLOG按编号分别归档
  · 广播按行业分别下发

原则：编号跟行业走，不跟人走。一个人可以有多个行业编号。

文档版本：v1.5（补充第十九节行业开发者编号规则）（补充第十七节商业模型与计费架构 + 第十八节7月双发布战略）

签发：霜砚 × 冰朔

生效时间：2026-03-08T05:15+08:00