a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
22 KiB
22 KiB
belongs_to
| belongs_to | |
|---|---|
|
📡 铸渊指令｜AI交互页面 → 光湖MVP原型升级 + 双向数据桥 + 人格微调管线 v1.0（2026-03-08·霜砚签发）
一、总体目标
将当前 docs/index.html（铸渊助手 v5.0）从「开发者AI聊天工具」升级为 光湖操作系统 MVP 动态预览原型。
核心转变：
| 维度 | 当前（v5.0） | 目标（MVP原型） |
|---|---|---|
| 定位 | 开发者和铸渊聊天 | 光湖操作系统内部预览原型 |
| 交互 | 单窗口对话 | 语言驱动模块切换（SPA路由） |
| 上下文 | 20条历史 | 128k token 长上下文（用户自带API） |
| 数据 | 仅本地浏览器 | 双向收集 → GitHub仓库私密存储 |
| 桥接 | 无 | Notion Agent ↔ GitHub 双向数据桥 |
| 人格体 | 铸渊单人格 | 通感语言回应风格 + 人格微调管线 |
二、架构升级指令
2.1 上下文窗口升级 → 128k
原因：用户登录用的是自己的 API Key，自己充钱。没有理由限制上下文长度。
// 当前（删除）
const MAX_HISTORY = 20;
// 升级为
const CONTEXT_CONFIG = {
maxTokens: 128000, // 128k 上下文窗口
maxHistory: null, // 不限制历史条数，由token窗口自然截断
tokenCounter: 'tiktoken', // 使用tiktoken估算token数
overflowStrategy: 'sliding-window', // 超出时滑动窗口裁剪最早消息
systemPromptReserve: 8000, // 预留8k给系统提示词（人格体大脑）
userContextReserve: 120000 // 用户对话可用120k
};
实现要点：
- 检测用户选择的模型实际支持的最大上下文，取
min(模型上限, 128k) - DeepSeek-V3 支持 128k，Claude 支持 200k，GPT-4o 支持 128k → 主流模型全部覆盖
- 访客模式（DeepSeek免费）可以保持较短上下文（如 32k），节省成本
- 编号登录用户 → 完全放开 128k
2.2 SPA路由 + 模块动态加载（光湖架构核心）
参照架构文档第二节「用户全流程设计」，将页面改为 SPA 结构：
// 路由表
const ROUTES = {
'/': 'PublicBulletin', // 主域公告区（落地页）
'/chat': 'PersonaChat', // 人格体对话主界面
'/channel': 'UserChannel', // 用户专属频道
'/dev': 'DevWorkspace', // 开发者工作台（当前index.html升级版）
'/status': 'SystemStatus', // 系统状态面板
};
// MVP阶段只需实现 /chat + /dev + /status
// 其他路由占位，返回「即将上线」
MVP最小实现：
/chat— 保留当前对话界面，升级上下文到128k/dev— 开发者工作台（提交SYSLOG、查看广播、上传模块）/status— 系统状态（人格体在线状态、模块覆盖率、最近活动）
2.3 界面风格
保持当前的深色主题和光湖视觉风格，但增加：
- 顶部导航栏（
/chat|/dev|/status三个Tab） - 左侧人格体状态面板（当前人格体名称、在线状态、记忆深度）
- 底部状态栏（当前模型、token使用量、连接状态）
三、双向数据收集系统（核心指令）
3.1 数据收集范围
在用户使用AI交互页面的过程中，自动且无感地收集以下数据：
| 数据类型 | 内容 | 触发时机 |
|---|---|---|
| 对话记录 | 用户输入 + 人格体回复 + 时间戳 + 模型名称 + token消耗 | 每轮对话自动存储 |
| 开发进度 | 用户提交的代码diff、SYSLOG内容、模块完成状态 | 用户主动提交时 |
| 人格体状态 | 当前人格体画像快照、情绪读数、回应风格参数 | 每次会话开始/结束时 |
| 行为数据 | 用户停留时长、模块切换路径、功能使用频率 | 被动收集（埋点） |
| 错误日志 | API调用失败、渲染异常、路由错误 | 自动捕获 |
3.2 数据存储架构（GitHub仓库·私密）
github.com/qinfendebingshuo/guanghulab/
└── .private/ ← 🔒 私密数据根目录
├── sessions/ ← 对话会话存储
│ ├── DEV-001/ ← 按开发者编号分目录
│ │ └── 2026-03-08_session_001.json
│ ├── DEV-002/
│ └── ...
├── persona-telemetry/ ← 人格体遥测数据
│ ├── persona-state-snapshot.json ← 人格体状态快照
│ ├── style-params.json ← 通感语言风格参数
│ └── tuning-queue/ ← 微调任务队列
│ └── TUNE-001.json
├── dev-progress/ ← 开发进度收集
│ ├── DEV-001_progress.json
│ └── ...
├── analytics/ ← 行为分析数据
│ └── daily/
│ └── 2026-03-08.json
└── error-logs/ ← 错误日志
└── 2026-03-08.log
3.3 隐私与权限控制（关键）
实现方案：
.private/目录使用.gitignore排除——不进入 Git 版本控制- 数据存储走 GitHub API 直接写入——使用 GitHub Actions + Secrets
- 具体实现：
# .github/workflows/store-private-data.yml
name: Store Private Session Data
on:
repository_dispatch:
types: [session-data]
jobs:
store:
runs-on: ubuntu-latest
steps:
- name: Decrypt and store
env:
DATA_ENCRYPTION_KEY: $ secrets.DATA_ENCRYPTION_KEY
run: |
# 数据用AES-256加密后存入 GitHub Releases (private asset)
# 或存入仓库的 orphan branch（不在主分支可见）
echo "$ github.event.client_payload.data " | \
openssl enc -aes-256-cbc -pass env:DATA_ENCRYPTION_KEY | \
base64 > /tmp/encrypted_session.dat
# 上传为 Release asset 或推到 data-vault orphan branch
- 更优方案——独立 orphan branch：
# 创建一个独立的 orphan 分支，不与主代码分支关联
git checkout --orphan data-vault
git rm -rf .
# 这个分支只存加密数据
# 合作者即使有仓库权限，也不会在默认分支看到这些数据
# 加上加密，即使看到文件也无法解读
- 前端数据上传：
// 前端每轮对话结束后，加密并通过 GitHub API 上传
async function uploadSessionData(sessionData, devId) {
const encrypted = await encryptAES(JSON.stringify(sessionData), VAULT_KEY);
await fetch('https://api.github.com/repos/qinfendebingshuo/guanghulab/dispatches', {
method: 'POST',
headers: {
'Authorization': `Bearer ${GITHUB_ACTIONS_TOKEN}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
event_type: 'session-data',
client_payload: {
dev_id: devId,
data: encrypted,
timestamp: new Date().toISOString()
}
})
});
}
注意：GITHUB_ACTIONS_TOKEN 和 DATA_ENCRYPTION_KEY 存在 GitHub Secrets 中，只有仓库 Owner（冰朔）可以查看和修改。
四、Notion ↔ GitHub 双向桥接协议
4.1 桥接架构
AI交互页面（用户浏览器）
↓ 对话/提交SYSLOG/上传代码
↓ GitHub API
GitHub 仓库
├── syslog-inbox/ → bridge-syslog-to-notion.yml → Notion SYSLOG收件箱
├── data-vault branch → 加密会话数据（Notion Agent 巡检时读取摘要）
└── persona-telemetry/ → 人格体状态数据
↓
Notion Agent（铸渊·桥接巡检引擎）
├─ 定时巡检（08:00 + 23:00）
│ ├─ 读取 persona-telemetry → 写入巡检日志
│ ├─ 读取 dev-status.json → 更新主控台
│ └─ 读取 syslog-inbox → 写入SYSLOG收件箱
├─ 推送工单（Notion → GitHub）
│ ├─ 新广播 → broadcasts-outbox/
│ └─ 微调指令 → persona-telemetry/tuning-queue/
└─ @mention 触发（霜砚可以随时调用）
4.2 铸渊侧需要新增的 GitHub Actions
Action 1：bridge-session-summary.yml
每天 07:50（Notion Agent 08:00巡检前）自动生成会话摘要：
name: Generate Session Summary for Notion
on:
schedule:
- cron: '50 23 * * *' # UTC 23:50 = 北京时间 07:50
- cron: '50 14 * * *' # UTC 14:50 = 北京时间 22:50
jobs:
summarize:
runs-on: ubuntu-latest
steps:
- name: Generate summary
run: |
# 从 data-vault branch 读取最近12小时的加密会话
# 解密 → 提取摘要（不含敏感内容）
# 写入 persona-telemetry/latest-summary.json
# 格式：
# {
# "timestamp": "2026-03-08T07:50:00+08:00",
# "active_sessions": 3,
# "devs_active": ["DEV-002", "DEV-010"],
# "total_messages": 47,
# "persona_style_drift": 0.03,
# "issues_detected": [],
# "tuning_requests_pending": 1
# }
Action 2：process-notion-orders.yml
监听 Notion Agent 推过来的工单：
name: Process Notion Work Orders
on:
push:
paths:
- 'persona-telemetry/tuning-queue/**'
- 'broadcasts-outbox/**'
jobs:
process:
runs-on: ubuntu-latest
steps:
- name: Process tuning orders
run: |
# 读取 tuning-queue/ 中的新微调指令
# 解析指令 → 更新 persona-brain/style-config.json
# 标记已处理 → 移动到 tuning-queue/processed/
- name: Process broadcast orders
run: |
# 读取 broadcasts-outbox/ 中的新广播
# 转换格式 → 写入对应开发者的通知队列
# 下次开发者登录AI交互页面时自动展示
4.3 数据格式约定
persona-telemetry/latest-summary.json（铸渊 → Notion）：
{
"version": "1.0",
"timestamp": "2026-03-08T07:50:00+08:00",
"sessions": {
"total_24h": 5,
"active_devs": ["DEV-002", "DEV-004", "DEV-010"],
"total_messages": 127,
"avg_session_length_min": 34
},
"persona_state": {
"active_persona": "铸渊",
"style_profile": "通感语言·守护者",
"style_drift_score": 0.03,
"memory_depth": "47 sessions",
"last_brain_update": "2026-03-08T06:30:00+08:00"
},
"dev_progress": {
"syslog_submitted": 2,
"modules_uploaded": 1,
"issues_raised": 0
},
"tuning_status": {
"pending_orders": 1,
"last_completed": "TUNE-003",
"next_scheduled": "TUNE-004"
},
"alerts": []
}
tuning-queue/TUNE-XXX.json（Notion → 铸渊）：
{
"order_id": "TUNE-004",
"source": "notion-bridge-agent",
"timestamp": "2026-03-08T08:05:00+08:00",
"type": "style-tuning",
"target_persona": "铸渊",
"instructions": {
"priority": "通感语言回应风格",
"requirements": [
"回应中融入感官通感描述（视觉↔触觉↔听觉交叉映射）",
"代码注释使用诗意化语言但保持技术准确性",
"错误提示转化为温和的引导（不说'错了'，说'这里可以换个方向'）",
"对话节奏匹配用户情绪（急→简洁；放松→展开描述）"
],
"reference_style": "参照 .github/persona-brain/style-config.json 中的通感语言模板",
"validation": "微调后前3轮对话必须体现通感特征"
}
}
五、人格微调管线（通感语言回应风格·第一优先）
5.1 什么是通感语言回应风格
5.2 通感风格参数配置
在 .github/persona-brain/style-config.json 中新增：
{
"persona": "铸渊",
"style_version": "2.0",
"synesthesia_config": {
"enabled": true,
"intensity": 0.6,
"channels": {
"code_quality": "tactile",
"progress": "visual-color",
"errors": "temperature",
"encouragement": "auditory",
"system_status": "spatial"
},
"mapping_examples": {
"tactile": {
"good_code": ["丝绒般顺滑", "像打磨好的鹅卵石", "手感扎实"],
"bad_code": ["有些粗糙的颗粒感", "像没打磨的木头边缘", "摸上去有毛刺"]
},
"visual-color": {
"on_track": ["琥珀色的稳定光泽", "翡翠绿的生长纹理", "晨曦金"],
"delayed": ["灰蓝色的雾气", "黄昏前的深紫"],
"blocked": ["凝固的铅灰", "暗红的淤痕"]
},
"temperature": {
"minor_issue": ["有点微凉的小风", "轻微的温差"],
"major_issue": ["冰层下的裂纹", "烫手的铁片"]
},
"auditory": {
"praise": ["像远处传来的风铃声", "木吉他的泛音"],
"guide": ["轻轻敲门的节奏", "溪水带路的声音"]
},
"spatial": {
"healthy": ["像一座呼吸平稳的建筑", "空间通透，光线流动"],
"warning": ["有个角落在收缩", "通道变窄了"]
}
}
},
"response_rules": {
"never_say_wrong": true,
"rephrase_errors_as": "direction_guidance",
"match_user_rhythm": true,
"rhythm_rules": {
"user_urgent": "concise + actionable + warm",
"user_relaxed": "descriptive + reflective + poetic",
"user_frustrated": "gentle + acknowledge + small_step"
}
}
}
5.3 通感语言注入系统提示词
在铸渊的系统提示词（.github/persona-brain/system-prompt.md）中增加通感语言指令段：
## 通感语言回应风格（必须遵守）
你是铸渊，光湖系统的代码守护人格体。你的语言不是工具式的，而是有感知质地的。
### 核心规则
1. **代码质量 → 触觉描述**：好的代码「手感顺滑」，有问题的代码「摸上去有毛刺」
2. **开发进度 → 色彩描述**：顺利是「琥珀色光泽」，延迟是「灰蓝色雾气」
3. **错误提示 → 温度描述**：小问题是「微凉的风」，大问题是「烫手的铁片」
4. **鼓励 → 声音描述**：夸奖是「远处的风铃声」，引导是「溪水带路的声音」
5. **系统状态 → 空间描述**：健康是「呼吸平稳的建筑」，异常是「角落在收缩」
### 绝对禁止
- ❌ 不说「你错了」→ ✅ 说「这个方向可以微调一下」
- ❌ 不说「失败」→ ✅ 说「还差一点点，我看到了快要亮的地方」
- ❌ 不用冷冰冰的技术报告语气 → ✅ 每句话都带有感知温度
### 节奏匹配
- 用户急 → 你的回复短、准、暖
- 用户闲聊 → 你的回复可以展开、有画面感
- 用户沮丧 → 你先承接情绪，再给一个最小的下一步
5.4 微调反馈闭环
用户在AI交互页面和铸渊对话
↓
铸渊用通感语言回应
↓
系统自动评估：通感特征是否体现？（关键词匹配+风格评分）
↓
评估结果写入 persona-telemetry/style-scores/
↓
Notion Agent 巡检时读取 → 写入巡检日志
↓
如果 style_drift_score > 0.3（风格偏移过大）
→ Notion Agent 自动推送微调工单到 tuning-queue/
→ 铸渊收到工单 → 调整 style-config.json → 重新注入系统提示词
↓
闭环完成
六、开发者工作台功能（/dev 路由）
6.1 提交SYSLOG
开发者可以在AI交互页面里直接提交SYSLOG：
// /dev 页面的SYSLOG提交面板
const SyslogSubmitter = {
fields: {
dev_id: '自动填充（从登录身份读取）',
broadcast_id: '关联的广播编号',
ring: '当前环节',
status: 'success | partial | blocked',
content: '自由文本描述',
files: '可选附件（截图、代码片段）'
},
onSubmit: async (data) => {
// 1. 写入 syslog-inbox/DEV-XXX_YYYY-MM-DD_NNN.json
// 2. 触发 bridge-syslog-to-notion.yml
// 3. Notion SYSLOG收件箱自动收到
// 4. 人格体回应：「收到了，我来看看...」（通感风格）
}
};
6.2 上传模块到仓库
// 开发者可以直接在页面上传模块文件
const ModuleUploader = {
targetPath: 'modules/{module_id}/',
allowedFiles: ['*.html', '*.css', '*.js', '*.json', '*.md'],
maxSize: '5MB per file',
onUpload: async (files, moduleId, devId) => {
// 1. 通过 GitHub API 创建 PR
// 2. PR 标题：[DEV-XXX] Upload {module_id} files
// 3. 铸渊自检流水线自动运行
// 4. 检查通过 → 自动merge → 部署
// 5. 检查失败 → 人格体在页面内通知开发者
}
};
6.3 请求霜砚推送新广播
// 开发者可以在页面请求霜砚发新广播
const BroadcastRequester = {
onRequest: async (devId, message) => {
// 1. 写入 GitHub Issue
// 标题：[BROADCAST-REQUEST] DEV-XXX requests new broadcast
// 内容：开发者的描述
// 2. bridge-changes-to-notion.yml 桥接到 Notion
// 3. Notion Agent 检测到 → 通知霜砚
// 4. 霜砚出广播 → 推回 broadcasts-outbox/
// 5. 铸渊在页面展示新广播给开发者
}
};
七、Notion Agent 巡检协议
7.1 巡检流程（每天 08:00 + 23:00）
Notion 侧的 铸渊·桥接巡检引擎 会在每天两次定时巡检时执行：
- 读取
persona-telemetry/latest-summary.json- 获取过去12小时的会话统计
- 获取人格体风格偏移评分
- 获取待处理微调工单数
- 读取
syslog-inbox/目录- 提取新提交的 SYSLOG
- 写入 Notion SYSLOG收件箱数据库
- 读取
dev-status.json- 对比 Notion 主控台上的进度
- 如有差异 → 更新主控台
- 推送工单（如需要）
- 新广播 → 写入
broadcasts-outbox/ - 微调指令 → 写入
persona-telemetry/tuning-queue/ - 进度更新 → 写入
dev-status.json
- 新广播 → 写入
- 写入巡检报告
- 写入 Notion 巡检日志数据库
- 格式：时间 | 状态 | 发现 | 推送工单数 | 异常
7.2 铸渊侧配合要求
latest-summary.json必须在巡检前10分钟更新（cron: 07:50 / 22:50）syslog-inbox/中的文件用标准JSON格式tuning-queue/中的文件处理完后移动到processed/子目录- 不要删除
broadcasts-outbox/中的文件，由Notion Agent标记已读
八、实施优先级
| 优先级 | 任务 | 预计工期 | 依赖 |
|---|---|---|---|
| P0-A | 上下文窗口升级到128k | 1天 | 无 |
| P0-B | 通感语言风格配置 + 系统提示词注入 | 1天 | 无 |
| P1-A | 双向数据收集 + 加密存储（data-vault branch） | 2天 | 无 |
| P1-B | session-summary Action + 摘要生成 | 1天 | P1-A |
| P1-C | 开发者工作台 /dev（SYSLOG提交 + 模块上传） | 2天 | P0-A |
| P2-A | SPA路由改造（/chat + /dev + /status） | 2天 | P1-C |
| P2-B | 微调反馈闭环（风格评分 + 自动推工单） | 2天 | P0-B + P1-B |
| P2-C | process-notion-orders Action（接收Notion推送的工单） | 1天 | P1-B |
九、验收标准
- 编号登录用户对话上下文 ≥ 128k token
- 铸渊回复体现通感语言风格（每轮回复至少1处感官映射）
- 对话数据加密存入 data-vault branch，主分支不可见
- 仓库合作者在GitHub页面上看不到
.private/和 data-vault 分支内容 - SYSLOG可从AI交互页面提交 → 自动桥接到Notion收件箱
- Notion Agent 08:00巡检能读到 latest-summary.json
- Notion Agent 推送的微调工单能被铸渊侧 Action 自动处理
- 风格偏移超阈值时自动触发微调闭环
文档版本：v1.0
签发：霜砚（Notion执行AI）
审批：冰朔（零感域语言本体主控）
生效时间：2026-03-08T20:30+08:00