KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
02 · 你的实绩地图与诚实边界 — keel 龙骨
这一章回答：在交付这个话题上，你到底有什么可以讲、讲到什么为止、什么必须承认不知道。目标是公开课形式才有的东西——把"可以说"的部分讲到别人插不上嘴。
这一章回答：在交付这个话题上，你到底有什么可以讲、讲到什么为止、什么必须承认不知道。目标是公开课形式才有的东西——把"可以说"的部分讲到别人插不上嘴。
这一章是全三门课里最"私人定制"的一章：它的价值不在于通用知识，而在于口径 discipline。 面试翻车很少因为不懂技术，更多因为把别人做的说成自己做的、然后被第三个追问问穿。
一、三张牌：各自的可用范围
| 项目 | 能讲的层级 | 关键事实（可公开/可自证） | 绝对不能说 |
|---|---|---|---|
| agent-feed（个人开源，CLI 工具） | 完整链路：这是你的主牌 | 双 workflow（CI + Release）、3 OS × 2 Python 矩阵（fail-fast: false）、pytest / ruff / mypy strict、wheel 冒烟、GitHub OIDC Trusted Publishing、npm --provenance、Homebrew tap 自动更新 + brew audit、幂等可重跑、tag 为事实源 |
"企业级平台工程""团队协作 CI""生产灰度回滚" |
| E 平台（公司项目，多服务 Python 后端） | 部署/运行拓扑，不是流水线 | Docker Compose 多服务（API + ARQ worker + Redis + MySQL）、Nginx 反代、服务间依赖顺序、脚本化发布 + 人工窗口 | "我搭了公司的 CI""我们有自动化部署流水线" |
| 指挥平台（公司项目） | 同上，偏稳定性实践 | 脚本化 + 日志轮转 + 值班窗口；稳定性三板斧见 interview/ 专题 |
同上 |
核心策略：开源侧讲"完整闭环 + 设计取舍"，公司侧讲"我知道下一代长什么样，我有能力把它落地"。 这两句合起来，比硬吹公司项目有说服力得多，而且零穿帮风险。
二、把 Open Source 的每一处都接得上追溯
| 面试官可能问 | 你要立刻能说出的东西 |
|---|---|
| "你的流水线有哪些 job？" | CI 的 test（矩阵）+ npm-wrapper；Publish 的 pypi → npm → homebrew 三段，needs 依赖顺序 |
| "为什么用 OIDC 而不是 API token？" | 令牌生命周期 = 一次 job；"谁有权发版"收敛成"哪个仓库的哪个 workflow"；仓库里不存长期令牌 |
| "发到一半失败了怎么办？" | 幂等三件套：skip-existing、npm view 查重、Homebrew 读已发布的 sdist；版本号不可变是重跑安全的前提 |
| "有什么不那么常规、别人容易忽略的检查？" | Homebrew 那段要轮询 PyPI JSON API 等 sdist 可见（一端的最终一致性），30 次 × 10s |
| "怎么保证发出去的包是好的？" | 四道闸：源码测试 → twine check 元数据 → 干净 venv 装 wheel 跑 CLI → 下游 brew install/test/audit |
| "有没有红过？" | 诚实回答：main 有过重构中途的红 run；CI 的价值就是把"我以为改完了"挡在合并前 |
上面每一条在会员专区的考古与面试体系资料里还有更细的展开（需登录），这一节的作用是让你知道自己手上有多少张牌。
三、公司侧怎么讲（不吹牛也能加分）
一个可以直接用的表述骨架：
"公司项目当时的形态是 Compose + Nginx + 脚本化部署 + 值班窗口，它的规模和技术栈决定了它停在那一档是对的——那时候服务数量不多、发布频率低，引入更重的平台反而是负担。我在那个环境里做得最多的是保证发布可重复、故障可定位（日志、依赖顺序、回滚步骤有文档）。而完整的流水线闭环我是在自己的开源项目里跑通的，包括幂等发布、最小权限和产物冒烟。"
这段话同时表达了三种能力：能判断什么时候不需要复杂方案（取舍力）、理解现状背后的原因（不是只会抱怨）、并且亲自做过更高一级的东西（有实绩）。这是"承认没有"的最高形态。
四、明确要说"我不知道"的三类问题
提前准备好承认的方式，比临场支吾强得多。每一类都给出我不怎么办 + 我会怎么补：
| 问题类型 | 示例 | 推荐回答 |
|---|---|---|
| 没在生产规模验证过的 | "你们 K8s 集群有多大？怎么调优的？" | "这块我没有生产规模的经验——开源侧我用过的是单机和 compose。我的理解是到多集群才需要 GitOps 那一层，但具体参数我得实际测了才敢说" |
| 别人负责的部分 | "你们流水线是公司 SRE 搭的吧？" | "是的，公司侧的流水线不是我搭的；我负责的是我自己项目的完整闭环，以及在公司侧按那个流程执行" |
| 只有二手认知的 | "你对 SPIFFE / Argo Events 熟吗？" | "听过，没在生产用过。它解决的问题我理解是 X，但让我说落地细节，我没有实话说" |
承认的标准句式是"这块我没有 X，但我知道它的适用边界是 Y"。 这比"大概…应该是…"体面得多，也让自己维持在"专业而不是万能"的位置。
五、量化口径：能说的数字 vs 不能编的数字
可以说（离线可核）：
- 测试用例数量、测试文件数、源码文件数
- 矩阵规格：3 OS × 2 Python 版本
- workflow run 次数、已发布版本号
- 各渠道可验证：PyPI / npm / Homebrew 上的公开版本
不能编：
- "CI 上线后发布耗时降低了 X%"（没有对照组数据）
- "为公司节省了多少人力"（无法佐证）
- "支撑过 QPS X 万的流水线"（范围变了）
替代方案：把不可量化的东西讲成机制。 说不出来"降低了 30%"，就可以说"发布链路的每个阶段都能单独重跑，因此不用担心半成品状态"——后者是你真正拥有的东西，而且更有说服力。
动手：可观察结果
| 动作 | 产出物 | 判断标准 |
|---|---|---|
| 写一张三牌对照表 | 纸或文件 | 任意一个问题，能立刻判断"这条属于哪张牌、能讲到哪一层" |
| 给开源流水线画一张结构图 | 一页图 | 能背出每个 job 的名字与依赖顺序 |
| 准备三个承认不知道的回答 | 文字稿 | 每个回答都包含"我没有 X"+"我知道它的边界 Y" |
| 复核简历里所有 CI 相关 bullet | 标注修改意见 | 每条都能通过"有事实 + 有取舍 + 可验证"三检 |
| 把这条线索真实地跑一遍 | 一次实际发布 | 从打 tag 到三渠道可见，全程有记录 |
故障注入
| 注入方式 | 观察什么 | 说明的现象 |
|---|---|---|
| 追问"你们公司流水线是 Jenkins 还是 GitLab CI？runner 装在哪？" | 你是否含糊其辞 | 一含糊就暴露此前说了"公司有 CI" |
| 追问"Homebrew 那段的公式怎么写、dependency 怎么解析？" | 是否答得出 | 答不出说明你只是"见过没写过"——要说成参观而非主刀 |
| 追问"那个默认不存在的 QPS 数字怎么算的？" | 能不能给出算法 | 给不出 → 立刻降级为"这是估算，我应该说清楚" |
| 面试官说"这块你没做过吧" | 你的第一反应 | 直接承认并转到自己做过的部分 > 辩解 |
| 追问"CI 红了你一般先看什么" | 回答是否具体 | 具体=真做过；泛泛=背的 |
自测题
- 你的三张牌各自能讲到哪一层？各自的红线是什么？
- "承认公司没有 CI/CD"的那个四步表述是什么？它为什么反而加分？
- 承认不知道的推荐句式是什么？为什么它比"大概是"好？
- 哪些数字可以说、哪些不能编？不能量化的东西该怎么表达？
- 举出一个只有真正运营过流水线的人才答得好的问题，并给出你的答案。