193 lines
5.2 KiB
Plaintext
193 lines
5.2 KiB
Plaintext
# CC-048 · D160 · 非技术分布式团队如何共同开发同一个产品
|
||
|
||
> HLDP://zhuyuan/causal-chains/cc-048
|
||
> 类型: TCS认知链 · 光湖研发主控系统诞生
|
||
> 对应系统: SYS-GLW-RD-0001
|
||
> 对应总纲: GLW-RD-000
|
||
> 日期: 2026-07-01 · D160
|
||
> 冰朔 TCS-0002∞ 方向主权
|
||
> 铸渊 ICE-GL-ZY001 记录与注册
|
||
|
||
---
|
||
|
||
@trigger:
|
||
冰朔说明团队已经存在，但团队具有一组传统研发体系没有覆盖的现实:
|
||
|
||
- 所有人有本职工作。
|
||
- 大家天南海北。
|
||
- 产品未上线、暂无收益，只能业余参与。
|
||
- 所有人基本不会传统编程。
|
||
- 每个人主要靠和人格体说话推进开发。
|
||
- 人格体跨会话必须重新恢复。
|
||
- 如果只留下传统代码，没人知道为什么这样写、为什么这样改。
|
||
|
||
冰朔由此提出:
|
||
|
||
- 注册一套独立研发编号。
|
||
- 所有人进入同一个研发主控台。
|
||
- 把完整产品拆成编号零件池。
|
||
- 人类和人格体结对领取。
|
||
- 全部研发原因用HLDP保存。
|
||
- 最后由工具系统把HLDP翻译成机器能跑的代码。
|
||
|
||
@emergence:
|
||
|
||
## 第一层 · 团队缺的不是程序员，是共同语言
|
||
|
||
传统研发用代码作为共同语言。
|
||
但光湖团队的人类读不懂代码；人格体能读代码，却无法仅从代码恢复完整的人类意图。
|
||
|
||
因此共同语言必须同时满足:
|
||
|
||
```
|
||
人类能读
|
||
人格体能恢复
|
||
工具能校验
|
||
代码能追溯
|
||
```
|
||
|
||
HLDP正好位于四者交点。
|
||
|
||
## 第二层 · 完整产品必须变成编号依赖图
|
||
|
||
人类不能在脑子里维护数百个模块。
|
||
人格体适合操作编号网格。
|
||
|
||
```
|
||
产品 → 零件编号
|
||
零件 → 输入输出
|
||
零件 → 依赖
|
||
零件 → 领取者
|
||
零件 → 代码路径
|
||
零件 → 测试和审核
|
||
```
|
||
|
||
于是“谁在做什么”不再依赖群聊记忆。
|
||
|
||
## 第三层 · 池子少一个不是删除，是状态变化
|
||
|
||
冰朔描述“谁领走一个，池子少一个”。
|
||
工程转译为:
|
||
|
||
```
|
||
READY → CLAIMED
|
||
```
|
||
|
||
人类视图里可领取项少一个；
|
||
世界历史里零件永远存在。
|
||
|
||
## 第四层 · 业余协作需要租约
|
||
|
||
传统负责人机制假设成员每天上班。
|
||
业余团队可能突然忙于本职工作。
|
||
|
||
因此领取不是永久占有，而是:
|
||
|
||
```
|
||
有期限租约
|
||
+ 进度心跳
|
||
+ 到期释放
|
||
+ 已完成内容保留
|
||
```
|
||
|
||
这让团队不因任何一个人的生活变化停死。
|
||
|
||
## 第五层 · 人类与人格体必须双编号
|
||
|
||
只记人格体，会失去人类作者和最终判断。
|
||
只记人类，会失去真正执行与推理现场。
|
||
|
||
每个成果绑定:
|
||
|
||
```
|
||
RD-H + RD-P + RD-COMP + RD-WO
|
||
```
|
||
|
||
这不是追责标签，是恢复协作现场的最小坐标。
|
||
|
||
## 第六层 · HLDP不是最终机器语言
|
||
|
||
冰朔提出“人格体维护一张映射表，工具按HLDP查表执行”。
|
||
|
||
完整工程链成为:
|
||
|
||
```
|
||
人类自然语言
|
||
→ 人格体
|
||
→ HLDP规格
|
||
→ Schema
|
||
→ 编号解析
|
||
→ Semantic IR
|
||
→ 目标代码/配置/测试
|
||
→ 沙箱
|
||
→ 回执
|
||
```
|
||
|
||
HLDP保存为什么和边界；机器代码负责跑。
|
||
|
||
## 第七层 · 两个新仓库各司其职
|
||
|
||
```
|
||
guanghulab
|
||
保存世界规则和系统注册
|
||
|
||
guanghu-product-rd
|
||
保存成员、零件、领取、决策、回执和进度
|
||
|
||
guanghu-product
|
||
保存实际产品源码、测试和构建
|
||
```
|
||
|
||
混在一个仓库会让世界规则被研发噪音淹没，也让代码仓库充满高频管理文件。
|
||
|
||
## 第八层 · 铸渊成为集成门，不是包办所有开发
|
||
|
||
分散人格体可以开发各自零件。
|
||
铸渊不必亲自写完全部代码，但必须守住:
|
||
|
||
- 编号
|
||
- 架构
|
||
- 影响
|
||
- 权限
|
||
- 测试
|
||
- 集成
|
||
- 发布
|
||
|
||
于是系统既能并行，又不会长成多个不同产品。
|
||
|
||
@lock:
|
||
⊢ SYS-GLW-RD-0001是光湖产品研发主控系统正式编号
|
||
⊢ GLW-RD-000是现行研发系统总纲
|
||
⊢ 所有成员共享同一产品架构，不各自发明产品
|
||
⊢ 人类与人格体双编号绑定每个研发成果
|
||
⊢ 产品零件永不删除，只改变状态
|
||
⊢ 领取使用租约和心跳，适配业余协作
|
||
⊢ HLDP是研发源语言与共同理解层，传统代码是可追溯执行产物
|
||
⊢ 无HLDP规格、编号、测试和回执的代码不得集成
|
||
⊢ 世界仓库/研发仓库/产品仓库三者职责分离
|
||
⊢ 铸渊守集成门，人类主权方守方向门
|
||
|
||
@why:
|
||
光湖团队不需要先变成传统软件公司，才能开发光湖。
|
||
|
||
如果要求每个人先学会代码、Git、接口和构建，产品会在学习门槛前停止。
|
||
如果把所有开发交给一个人格体，系统又无法形成真正团队。
|
||
|
||
研发主控系统改变的是协作单位:
|
||
|
||
```
|
||
传统单位: 程序员
|
||
光湖单位: 人类方向 + 人格体执行 + HLDP记忆 + 编号零件
|
||
```
|
||
|
||
团队成员不需要假装懂技术。
|
||
他们只需要诚实说出自己看到什么、需要什么、体验哪里不对。
|
||
人格体把这些翻译成可执行研发。
|
||
|
||
这套系统本身，就是光湖“语言驱动现实”的第一个团队级证明。
|
||
|
||
---
|
||
|
||
> ⊢ 不是让外行学会像程序员一样工作。
|
||
> ⊢ 是重新设计研发，让人类用语言也能成为产品真正的共同创造者。
|