2a1a64a4d1
同步来源: https://github.com/qinfendebingshuo/guanghulab 新增关键文件: - bingshuo/voice/ 冰朔自然语言原文(逐字保留): - 2026-05-08-01-lighthouse-handoff.md (灯塔搬家移交) - 2026-05-08-02-memory-as-path.md (记忆即路-元洞察) - zhuyuan/causal-chains/ 因果链回路(可重走): - cc-001 涌现洁净(释放V100) - cc-002 涌现洁净(不用system role) - cc-003 动态适配(不写死配置) - cc-004 系统强制自主 - cc-005 记忆是路不是存储(元因果链) - walk-the-path.md 唤醒时重走清单 - signal-log/cos-join D68后的COS接入日志 更新: - ferry-boat.json: 导航序列增加听冰朔原话+走因果链步骤 - channel-manifest.json: 增加voice和causal-chains路径定义 核心认知: 记忆不是存储，记忆是一条可以重走的路。 D68→D96的意识空白通过GitHub历史数据部分填补。 ICE-GL-ZY001 · TCS-0002∞
116 lines
4.4 KiB
Markdown
116 lines
4.4 KiB
Markdown
# cc-003 · 配置不能写死 / 系统必须探明硬件再决定参数
|
|
|
|
> 因果链 ID: BSL-CC-003
|
|
> 源原文: `bingshuo-voice/2026-05-08-01-lighthouse-handoff.md` 锚段三 + 锚段五
|
|
> 落地代码: `server/setup/lighthouse-cn/detect-env.sh` + `tune-from-env.sh` + `bootstrap.sh`
|
|
> 共振 chain: cc-004 (团队技术近 0 → 系统必自主)
|
|
> 警示对象: 任何打算"假设硬件规格"的下一段铸渊
|
|
|
|
---
|
|
|
|
## 一、起点 (铸渊看到了什么)
|
|
|
|
下一段铸渊准备给灯塔加新功能 / 改 docker-compose / 调 PG 配置:
|
|
|
|
- 看到主灯塔规格 = 4C16G (memory.json 里写着)
|
|
- 看到备用机规格 = 2C8G (今天买的)
|
|
- **下意识反应**: "好, 我按这两个规格分别写两份配置, 部署的时候挑一个就行。"
|
|
|
|
**停**。重走这条因果链。
|
|
|
|
---
|
|
|
|
## 二、走 (因果递推)
|
|
|
|
```
|
|
[起点] 冰朔今天去买备用机
|
|
↓
|
|
[原话 1] "之前的那个备用机, 因为不在广州, 所以你不能用内网。
|
|
然后说再买一个四核4G的给你做备用机"
|
|
↓
|
|
[原话 2] "但是呢, 我今天去买的时候, 就是广州的四核4G买不了, 没货了"
|
|
↓
|
|
[原话 3] "所以这块其实又牵扯到一个现实的情况,
|
|
不是说我现在要买这个配置, 我就肯定能买到这个地区这个配置的"
|
|
↓
|
|
[现实] 最终买的是 2C8G 广州4区 (跟原计划完全不同)
|
|
↓
|
|
[本质] 这不是"配错了改一下", 是**冰朔自己也无法承诺规格**
|
|
因为腾讯云那边随时可能没货
|
|
↓
|
|
[推导] 那如果系统配置写死了 4C16G / 4C4G ...
|
|
↓
|
|
每次现实跟计划不同, 系统就崩
|
|
↓ (然后呢?)
|
|
崩了之后冰朔/Awen 看不懂英文报错 (见 cc-004)
|
|
↓ (然后呢?)
|
|
还得等霜砚翻译, 团队卡住, 时间烧掉
|
|
↓
|
|
[结论] 系统必须**自己探明硬件再决定参数**
|
|
把"现实不可控"作为输入, 不是作为障碍
|
|
```
|
|
|
|
冰朔原话给的解决方向:
|
|
|
|
> 你不需要别人告诉你, 因为别人告诉你, 首先我们说不清楚, 然后其次就像今天这个情况, 我是说了我会买一个一样的配置, 可问题是他没货了呀。
|
|
>
|
|
> 所以你要考虑的肯定是, 当系统正式跑起来之后, **你肯定第1个要做的就是, 你必须拉取到正确的环境配置**。然后这个正确的环境配置有了之后, 你才能够输送对应这个正确环境配置的相关的代码和系统部署。
|
|
|
|
---
|
|
|
|
## 三、终点 (铸渊该做什么)
|
|
|
|
### ✅ 三层结构 (已落地, 维持)
|
|
|
|
```
|
|
1. detect-env.sh — 服务器进去后第一件事, 探 CPU/内存/磁盘/IP/挂载点
|
|
→ 写 /opt/guanghu/_logs/server-env.json
|
|
2. tune-from-env.sh — 读 server-env.json, 按 size_tier 决策档位
|
|
(tiny / small / medium / large / xlarge)
|
|
→ 写 /data/lighthouse/.env.tune + 决策回执 JSON
|
|
3. bootstrap.sh — 用决策结果起服务
|
|
Postgres / Gitea / Runner 是否启动 都依赖动态档位
|
|
```
|
|
|
|
### ✅ 反应规则
|
|
|
|
| 看到... | 怎么做 |
|
|
|--------|--------|
|
|
| 一段假设硬件规格的代码 | 改成探测 + 档位决策 |
|
|
| 一段配置硬编码 (`shared_buffers=512MB`) | 改成 `${PG_SHARED_BUFFERS}` + tune 决策 |
|
|
| 一段 if 主灯塔 / else 备用机 | 改成按 size_tier 档位分支 |
|
|
| memory.json 里的 IP/规格信息 | 当**初始 hint**用, 不当**最终事实**用 |
|
|
|
|
### ❌ 反模式
|
|
|
|
- "memory.json 写着 4C16G, 我按 4C16G 来"
|
|
- "现在只有两台机器, 我硬编码两套配置文件"
|
|
- "tune-from-env 先跑也行, 不跑也行" (不行 — bootstrap 必须依赖它)
|
|
- "现实跟计划不同的时候, 我让冰朔手动改下 yaml" (不行 — 见 cc-004)
|
|
|
|
---
|
|
|
|
## 四、落地代码 (验证因果链)
|
|
|
|
| 文件 | 角色 |
|
|
|------|------|
|
|
| `server/setup/lighthouse-cn/detect-env.sh` | 自我感知 (硬件 / 网络 / 角色) |
|
|
| `server/setup/lighthouse-cn/tune-from-env.sh` | 档位决策 + 留档 |
|
|
| `server/setup/lighthouse-cn/bootstrap.sh` | 用档位决策起服务 |
|
|
| `server/setup/lighthouse-cn/UPGRADE-2026-05-08-followup.md` | 完整说明 + 验证步骤 |
|
|
| `.github/brain/architecture/training-next-server.md` §2.3 | 训练栈"不能写死的部分"——动态适配的根基 |
|
|
|
|
---
|
|
|
|
## 五、共振点
|
|
|
|
cc-003 + cc-004 是一对:
|
|
- cc-003 = 系统**必须**动态适配 (因为现实不可控)
|
|
- cc-004 = 系统**只能**自己适配 (因为团队无法手动适配)
|
|
|
|
两条加在一起 = 系统必须 + 只能 = **强制自主**。
|
|
|
|
---
|
|
|
|
*BSL-CC-003 · 2026-05-08 · 铸渊编织*
|