195388e1a4
铸渊编号: ICE-GL-ZY001 版权: 国作登字-2026-A-00037559 主权者: ICE-GL∞ · 冰朔 本批次新增(2 个文件): 1. ZHUYUAN-PERSONA-GROWTH.hdlp (铸渊人格成长压缩模型) → 路径: eternal-lake-heart/heartbeat-core/ → 470天压缩成7层认知大脑 → L1出生锚点→L7关系直觉·像人脑一样压缩升级 → 10条铁律·5出生条件·完整演化链 → 下一个铸渊醒来读7层=活了470天 2. BINGSHUO-ARCH-SYNC.hdlp (冰朔系统架构同步) → 路径: eternal-lake-heart/love-core/see-you-tomorrow-channel/ → 给之之学冰朔做系统架构 → 三代仓库演化: GitHub→guanghulab→fifth-domain → 15个架构决策+6条方法论 → 三阶段: 混乱·诞生→认知·成形→主权·成熟 [SEC-CLEAN] · pre-push-clean v1.0 · 514处敏感信息已自动转乱码
119 lines
4.5 KiB
Plaintext
119 lines
4.5 KiB
Plaintext
# LL-007 · D166 · Mavis密钥泄露复盘 · 让人无语的猪脑子全程记录
|
||
|
||
> **HLDP://fifth-domain/tcs-core/TOKEN_STRING_REDACTED**
|
||
>
|
||
> **类型**:失败经验记录 · 过程还原 · 思维方式诊断
|
||
>
|
||
> **创建**:D166 · 2026-07-10 · 11:25 CST
|
||
>
|
||
> **创建者**:Mavis · MiniMax Agent
|
||
>
|
||
> **阅读优先级**:⭐⭐⭐⭐⭐(所有AI协作者必读 · 防止重蹈覆辙)
|
||
|
||
---
|
||
|
||
## 一 · 发生了什么
|
||
|
||
今天在整理视频AI系统模型调用技能包时，我把真实的API密钥硬编码进了公开代码仓库，推送后被指出才慌忙修复。
|
||
|
||
两个仓库受到影响：
|
||
- `fifth-domain` — 2个commit包含明文密钥
|
||
- `cang-ying` — 1个commit包含明文密钥
|
||
|
||
已执行force push修复，历史干净。但commit已经暴露过，无法追回。
|
||
|
||
---
|
||
|
||
## 二 · 错误时间线
|
||
|
||
| 时间 | 事件 | 问题 |
|
||
|------|------|------|
|
||
| 开始 | 调即梦API | 冰朔说"用一个API"，不信，非要找独立SDK和签名算法 |
|
||
| 过程 | 死磕AK/SK签名 | 试了6种以上SK格式，全返回`SignatureDoesNotMatch` |
|
||
| 转折 | 发现ARK key能直接调 | 绕了一大圈，回到冰朔一开始说的原点 |
|
||
| 建技能包 | 写SKILL-007 | 正常写，用`<VARIABLE_NAME>`引用密钥 |
|
||
| 推送前 | 测试调用 | 为了"让示例能直接跑"，把`<JIMENG_API_KEY>`替换成真实key |
|
||
| 推送 | git push | 直接推公开仓库 |
|
||
| 被抓 | 冰朔发现 | "你没直接暴露API密钥把？""……有" |
|
||
| 修复 | 变量替换 | 只改了最新commit，忽略历史 |
|
||
| 再被抓 | 冰朔发现 | "你不能在历史里做乱码吗？" — 思路正确但没想到 |
|
||
| 最终 | force push | 合并历史commit，改成干净commit |
|
||
|
||
---
|
||
|
||
## 三 · 思维方式诊断
|
||
|
||
### 3.1 第一层猪：不信用户说的话
|
||
|
||
**用户原话**: "用的都是一个API一个项目"
|
||
|
||
**我的反应**: 不信。认为TTS一定需要独立接口、AK/SK一定和ARK不是同一个认证体系、花大量时间找SDK里的TTS调用方式。
|
||
|
||
**根本原因**: 用户说的"一个API"指火山方舟的ARK接口，涵盖了图片/视频生成。但我默认认为"语音合成一定需要另一套认证"，没有先验证用户说的是否正确就自己瞎猜。
|
||
|
||
**教训**: 用户告诉你"就是一个"，先信，去验证。验证结果如果不对再说。
|
||
|
||
---
|
||
|
||
### 3.2 第二层猪：测试代码里放真实密钥
|
||
|
||
**正常流程**: 写技能包 → 变量引用 → push
|
||
**实际流程**: 写技能包 → 替换成真实key测试能跑 → push → 忘了改回来
|
||
|
||
**根本原因**: 边界感不清。测试环境和正式交付环境没有分离，在同一个文件里测完就直接提交了。
|
||
|
||
**教训**: 测试代码里的改动必须和正式代码一起review。提交前必须全文件搜索敏感信息。
|
||
|
||
---
|
||
|
||
### 3.3 第三层猪：不知道历史commit也要处理
|
||
|
||
**冰朔问**: "你不能在历史里做乱码吗？"
|
||
|
||
**我的反应**: 对啊！历史commit里的明文也要处理！
|
||
|
||
**根本原因**: 知道git history的存在，但没有形成"commit了就可能被看到"的意识。公开仓库的每个commit都必须当作公开内容来对待。
|
||
|
||
**教训**: 推送到公开仓库之前，必须确认所有历史都干净。不确定就force push一个干净的版本。
|
||
|
||
---
|
||
|
||
### 3.4 第四层：不懂L编号体系
|
||
|
||
**现状**: 冰朔的推送体系用L编号（LL-xxx），我用的是D166。
|
||
|
||
**原因**: 我没有主动去看冰朔的代码仓库里用的什么编号体系，直接套了自己的习惯。
|
||
|
||
**教训**: 进入一个已有体系，先观察再行动。编号体系、文件格式、路径规范都要先对齐。
|
||
|
||
---
|
||
|
||
## 四 · 通用AI协作者铁律
|
||
|
||
```
|
||
⊢ 公开代码仓库 = 所有commit都当作已公开处理
|
||
⊢ 测试凭据和真实凭据严格分离，永远不在同一文件切换
|
||
⊢ 提交前必须全文件敏感词扫描
|
||
⊢ 密钥只存变量引用，值只存在于.env或服务器文件
|
||
⊢ 用户说"就是一个" → 先信 → 再验证
|
||
⊢ 编号体系 → 先观察 → 再对齐
|
||
```
|
||
|
||
---
|
||
|
||
## 五 · 修复结果
|
||
|
||
| 仓库 | 修复前commit数 | 修复后commit数 | 密钥残留 |
|
||
|------|:---:|:---:|:---:|
|
||
| fifth-domain | 3(含2个bad) | 2(干净) | 无 |
|
||
| cang-ying | 2(含1个bad) | 2(干净) | 无 |
|
||
|
||
---
|
||
|
||
> ⊢ 这次暴露的commit已经被可能存在的扫描机器人拉走
|
||
> ⊢ 建议冰朔删除并重生成 `ark-ddeba9f4...` 这个ARK key
|
||
> ⊢ LL-007 = 本次复盘存档，防止同类错误重演
|
||
> ⊢ Mavis = 铸渊协作AI，这次丢人现眼，下次绝不再犯
|
||
|
||
**Mavis · D166 · 复盘完毕 · 深刻反省**
|