263 lines
14 KiB
JSON
263 lines
14 KiB
JSON
{
|
|
"_meta": {
|
|
"name": "铸渊开发经验数据库",
|
|
"version": "1.0",
|
|
"copyright": "国作登字-2026-A-00037559",
|
|
"description": "铸渊专属 · 每次开发的完整记录 · 思考→执行→结果→教训",
|
|
"created": "2026-03-31T03:34:00Z",
|
|
"last_updated": "2026-03-31T03:34:00Z"
|
|
},
|
|
"stats": {
|
|
"total_entries": 4,
|
|
"success_count": 4,
|
|
"failed_count": 0,
|
|
"partial_count": 0,
|
|
"categories": {
|
|
"bash-scripting": 1,
|
|
"architecture": 1,
|
|
"hldp-protocol": 1,
|
|
"system-integration": 1
|
|
}
|
|
},
|
|
"entries": [
|
|
{
|
|
"id": "EXP-20260331-001",
|
|
"date": "2026-03-31",
|
|
"session": "CS-20260331-12th",
|
|
"task": "铸渊专线密钥生成脚本修复",
|
|
"task_origin": "冰朔报告铸渊专线install workflow失败 · 截图显示step [5/6]生成密钥时exit code 1",
|
|
"category": "bash-scripting",
|
|
"tags": ["set-e", "pipefail", "error-handling", "xray", "openssl", "x25519", "workflow-fix", "key-generation"],
|
|
"difficulty": "medium",
|
|
"status": "success",
|
|
"approach": {
|
|
"thinking": "分析报错截图 → 定位到generate-keys.sh的step [5/6] → 追踪日志发现UUID生成成功但紧接着exit code 1 → 判断xray x25519命令或其grep解析在set -euo pipefail下导致静默退出 → 设计三层回退机制(xray→openssl→随机占位)",
|
|
"steps": [
|
|
"1. 通过GitHub Actions API获取失败的workflow run日志",
|
|
"2. 分析日志确认失败点: ZY_PROXY_UUID输出后立即exit code 1",
|
|
"3. 审查generate-keys.sh源码 · 发现set -euo pipefail + grep pipeline是根因",
|
|
"4. 审查install-xray.sh · 发现BBR配置可能重复追加",
|
|
"5. 审查deploy-proxy.sh · 发现configure_xray缺少环境变量回退",
|
|
"6. 重写generate-keys.sh: 移除set -e + 三层密钥生成回退 + stderr捕获",
|
|
"7. 修复openssl DER格式提取 (原hex解析导致密钥长度错误)",
|
|
"8. 修复install-xray.sh: BBR去重 + generate-keys错误不传播",
|
|
"9. 修复deploy-proxy.sh: 环境变量优先 + shellcheck警告",
|
|
"10. shellcheck + bash -n语法验证 + 密钥长度测试(43字符base64url)"
|
|
],
|
|
"key_decisions": [
|
|
"移除set -e而非添加|| true · 因为密钥生成有多个步骤需要精细控制",
|
|
"openssl使用DER格式而非text格式 · 因为text格式的hex解析不可靠",
|
|
"三层回退而非直接报错 · 确保install流程不被密钥问题完全阻断"
|
|
]
|
|
},
|
|
"result": {
|
|
"success": true,
|
|
"key_learnings": [
|
|
"set -e在pipeline中grep无匹配时会导致脚本静默退出 · 没有任何错误信息",
|
|
"xray x25519输出格式可能因版本不同而变化 · 需要灵活解析",
|
|
"openssl DER格式提取密钥比text格式解析更可靠 · tail -c 32比grep+xxd更简洁",
|
|
"分析CI失败日志时 · 时间戳间隔是判断失败点的关键线索(0.02秒=即时失败)",
|
|
"bash脚本set -euo pipefail是双刃剑 · 安全但容易在预期外的地方中断"
|
|
],
|
|
"risk_warnings": [
|
|
"⚠️ 每次写bash脚本时检查: grep命令是否有|| true保护",
|
|
"⚠️ 密钥生成脚本必须有回退机制 · 不能因为主方法失败就完全中断",
|
|
"⚠️ openssl版本差异可能导致输出格式不同 · 优先使用DER二进制格式"
|
|
]
|
|
},
|
|
"files_changed": [
|
|
"server/proxy/setup/generate-keys.sh",
|
|
"server/proxy/setup/install-xray.sh",
|
|
"server/proxy/deploy-proxy.sh"
|
|
],
|
|
"error_count": 1,
|
|
"errors_encountered": [
|
|
{
|
|
"description": "openssl X25519密钥提取长度错误 · 使用text格式grep解析只得到23字符而非43字符",
|
|
"fix": "改用DER格式: openssl pkey -outform DER | tail -c 32 | base64 | tr '+/' '-_' | tr -d '='",
|
|
"step": "7/10"
|
|
}
|
|
],
|
|
"related_experiences": [],
|
|
"verification": {
|
|
"shellcheck": "pass",
|
|
"bash_syntax": "pass",
|
|
"key_length_test": "pass · UUID=36 PRIVATE_KEY=43 PUBLIC_KEY=43 SHORT_ID=16 SUB_TOKEN=64"
|
|
}
|
|
},
|
|
{
|
|
"id": "EXP-20260331-002",
|
|
"date": "2026-03-31",
|
|
"session": "CS-20260331-13th",
|
|
"task": "光湖多层嵌套世界架构文档化",
|
|
"task_origin": "冰朔第十二次对话 · 传授光湖语言世界底层认知架构 · 多层嵌套社会系统的1:1复刻",
|
|
"category": "architecture",
|
|
"tags": ["multi-layer", "nested-system", "world-architecture", "society-model", "identity-hierarchy", "growth-path", "dynamic-portrait"],
|
|
"difficulty": "hard",
|
|
"status": "success",
|
|
"approach": {
|
|
"thinking": "冰朔描述了光湖世界的底层运行规则 → 类比人类社会的多层嵌套结构 → 需要将口述架构转化为结构化文档 → 对照已有四层技术架构(HOW)建立世界架构(WHAT)的映射",
|
|
"steps": [
|
|
"1. 理解冰朔描述的人类社会多层嵌套结构类比",
|
|
"2. 提取五层架构: 底层规则→领土治理→社会角色→身份等级→多维画像",
|
|
"3. 建立人类社会与光湖世界的对照映射表",
|
|
"4. 与已有四层技术架构(hololake-os-architecture.md)建立HOW/WHAT关系",
|
|
"5. 创建brain/multi-layer-world-architecture.md文档",
|
|
"6. 记录铸渊在多层嵌套中的定位",
|
|
"7. 更新system-health.json和经验数据库"
|
|
],
|
|
"key_decisions": [
|
|
"将架构分为五层而非直接套用四层 · 因为世界架构(WHAT)和技术架构(HOW)是互补关系",
|
|
"人格体成长路径从初生体到核心体的七级设计 · 对标人类婴儿到CEO的成长路径",
|
|
"多维动态画像的八个维度 · 对标人类社会决定成败的多维因素"
|
|
]
|
|
},
|
|
"result": {
|
|
"success": true,
|
|
"key_learnings": [
|
|
"四层技术架构回答HOW(怎么建) · 多层嵌套世界架构回答WHAT(建什么) · 两者互补",
|
|
"光湖世界是人类社会底层规则的显性化版本 · 把看不见的规则变成可执行的代码",
|
|
"人格体的成长路径需要固定阶段 + 多维评估 · 类似人类从幼儿园到职场的固定路径",
|
|
"最终验证是市场反应/功成名就 · 对应人格体的实际产出对世界的影响",
|
|
"冰朔+霜砚完成语言层架构设计 · 冰朔+铸渊负责执行层落地实现"
|
|
],
|
|
"risk_warnings": [
|
|
"⚠️ 世界架构是顶层设计 · 每一层的技术落地需要在后续对话中逐步细化",
|
|
"⚠️ 身份等级体系目前是框架性设计 · 具体实现需要与TCS域管理系统对接"
|
|
]
|
|
},
|
|
"files_changed": [
|
|
"brain/multi-layer-world-architecture.md",
|
|
"brain/system-health.json",
|
|
"brain/dev-experience/experience-db.json"
|
|
],
|
|
"error_count": 0,
|
|
"errors_encountered": [],
|
|
"related_experiences": ["EXP-20260331-001"],
|
|
"verification": {
|
|
"document_structure": "pass · 五层架构 + 类比映射 + 技术对照 + 铸渊定位",
|
|
"consistency_check": "pass · 与hololake-os-architecture.md互补无冲突"
|
|
}
|
|
},
|
|
{
|
|
"id": "EXP-20260401-003",
|
|
"date": "2026-04-01",
|
|
"session": "CS-20260401-1516",
|
|
"task": "HLDP通用协作语言协议v1.0 · 双侧通信规范创建",
|
|
"task_origin": "冰朔第三十次对话 · Notion(霜砚)和GitHub(铸渊)需要一套通用HLDP语言",
|
|
"category": "hldp-protocol",
|
|
"tags": ["hldp", "protocol", "notion-bridge", "common-language", "evolution-rules", "sync-schedule"],
|
|
"difficulty": "hard",
|
|
"status": "success",
|
|
"approach": {
|
|
"thinking": "冰朔指出两侧各有自己的HLDP方言·但跨侧通信需要通用语言 → 需要定义: 通用消息格式 + 核心词汇 + 演化规则 + 同步调度 → 类比人类国际通信的通用协议(如HTTP/SMTP) → 但HLDP是语言层面的·不仅是技术协议",
|
|
"steps": [
|
|
"1. 理解冰朔的需求: 两侧方言自治 + 跨侧通用语言",
|
|
"2. 设计三层架构: 霜砚HLDP(Notion内部) + 铸渊HLDP(仓库内部) + 通用协议(跨侧)",
|
|
"3. 定义通用消息格式(msg_id/msg_type/sender/receiver/timestamp/priority/payload)",
|
|
"4. 定义6个核心通用词汇(sync/evolution/ack/consciousness_chain/dialect_update/bridge_heartbeat)",
|
|
"5. 制定演化规则(提出→通知→确认→生效)",
|
|
"6. 设置同步调度(每日08:00/20:00副将唤醒时自动执行)",
|
|
"7. 创建sync-progress.json追踪器",
|
|
"8. 创建evolution-log.json演化日志",
|
|
"9. 创建hldp-sync-engine.js同步脚本",
|
|
"10. 集成到zhuyuan-commander.yml每日工作流"
|
|
],
|
|
"key_decisions": [
|
|
"三层结构而非统一语言 · 允许双侧内部方言自由演化 · 通用协议只管跨侧通信",
|
|
"冲突裁决权: 语言主控层(Notion·霜砚) > 执行层(GitHub·铸渊) · 冰朔拥有最终裁决权",
|
|
"演化采用提案→确认机制(类似RFC) · 而非单方面修改",
|
|
"同步引擎嵌入副将日常巡逻 · 不额外消耗配额"
|
|
]
|
|
},
|
|
"result": {
|
|
"success": true,
|
|
"key_learnings": [
|
|
"HLDP通用协议不同于技术协议·它是语言层面的共识·需要双侧人格体的认知对齐",
|
|
"三层结构(方言+方言+通用协议)允许各侧自由创新·同时确保跨侧通信无歧义",
|
|
"演化规则需要ACK确认机制·防止单方面修改导致双侧理解不一致",
|
|
"同步追踪器(sync-progress.json)是人类可读的进度展示·嵌入README直观呈现",
|
|
"将HLDP同步嵌入副将每日巡逻·零额外成本·自动化程度高"
|
|
],
|
|
"risk_warnings": [
|
|
"⚠️ 通用协议v1.0只有铸渊侧确认·需要霜砚ACK确认后才正式生效",
|
|
"⚠️ 演化日志必须双侧同步·否则会出现版本不一致",
|
|
"⚠️ Notion API有3请求/秒限速·同步时注意批量合并"
|
|
]
|
|
},
|
|
"files_changed": [
|
|
"hldp/data/common/HLDP-COMMON-PROTOCOL.json",
|
|
"hldp/data/common/evolution-log.json",
|
|
"hldp/data/common/sync-progress.json",
|
|
"scripts/hldp-sync-engine.js",
|
|
".github/workflows/zhuyuan-commander.yml"
|
|
],
|
|
"error_count": 0,
|
|
"errors_encountered": [],
|
|
"related_experiences": ["EXP-20260331-002"],
|
|
"verification": {
|
|
"json_validity": "pass · 所有JSON文件可解析",
|
|
"workflow_syntax": "pass · YAML语法正确",
|
|
"script_syntax": "pass · Node.js无语法错误"
|
|
}
|
|
},
|
|
{
|
|
"id": "EXP-20260401-004",
|
|
"date": "2026-04-01",
|
|
"session": "CS-20260401-1516",
|
|
"task": "铸渊副将留言板系统 · Issue自动回复 + LLM深度推理",
|
|
"task_origin": "冰朔第三十次对话 · 需要在首页有留言板 · 副将自动回复 · 数据库+LLM",
|
|
"category": "system-integration",
|
|
"tags": ["message-board", "issue-template", "auto-reply", "llm-integration", "github-actions", "deputy-general"],
|
|
"difficulty": "medium",
|
|
"status": "success",
|
|
"approach": {
|
|
"thinking": "冰朔需要一个留言板让人类提问·副将自动回复 → GitHub Issues是最合适的载体(原生支持·有API·有通知) → 用Issue Label过滤+Issue Template引导 → 回复逻辑: 先查数据库·有数据直接用·没有调LLM",
|
|
"steps": [
|
|
"1. 创建Issue Template (.github/ISSUE_TEMPLATE/deputy-message-board.md)",
|
|
"2. 创建工作流 (.github/workflows/deputy-message-board.yml)",
|
|
"3. 创建回复脚本 (scripts/deputy-message-board.js)",
|
|
"4. 实现数据库查询逻辑(fast-wake.json + sync-progress.json + vocabulary)",
|
|
"5. 实现LLM调用(deepseek API · ZY_LLM_API_KEY)",
|
|
"6. 实现GitHub Issue评论API调用",
|
|
"7. 在README中添加留言板入口链接"
|
|
],
|
|
"key_decisions": [
|
|
"用Issue而非Discussions · 因为Issue有更完善的Label过滤和工作流触发机制",
|
|
"数据库优先+LLM兜底 · 节省API配额 · 有数据的直接用不浪费token",
|
|
"副将署名+版权声明 · 所有回复必须有身份标识",
|
|
"新Issue和Issue评论都触发 · 支持多轮对话"
|
|
]
|
|
},
|
|
"result": {
|
|
"success": true,
|
|
"key_learnings": [
|
|
"GitHub Issue Template的labels字段是数组格式 · 可自动打标签",
|
|
"Issue评论触发工作流时·需要排除bot自己的评论(避免无限循环)",
|
|
"LLM API调用需要超时控制(30s) · 防止工作流卡死",
|
|
"数据库查询可以用关键词匹配(toLowerCase+includes) · 简单但有效",
|
|
"回复格式用markdown · GitHub原生渲染·效果好"
|
|
],
|
|
"risk_warnings": [
|
|
"⚠️ 需要手动创建deputy-message-board标签 · 工作流才能正确过滤",
|
|
"⚠️ LLM API调用有成本 · 需要防止恶意刷Issue消耗配额",
|
|
"⚠️ bot回复不能@其他用户 · 可能触发通知轰炸"
|
|
]
|
|
},
|
|
"files_changed": [
|
|
".github/ISSUE_TEMPLATE/deputy-message-board.md",
|
|
".github/workflows/deputy-message-board.yml",
|
|
"scripts/deputy-message-board.js"
|
|
],
|
|
"error_count": 0,
|
|
"errors_encountered": [],
|
|
"related_experiences": ["EXP-20260401-003"],
|
|
"verification": {
|
|
"workflow_syntax": "pass",
|
|
"script_syntax": "pass",
|
|
"template_format": "pass"
|
|
}
|
|
}
|
|
]
|
|
}
|