KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

03 · 高频问答三十题（附回答骨架） — keel 龙骨

这一章回答：交付话题下真正会被问到的问题，以及每个问题的回答应该包含哪几个必答点。注意——这里给的是骨架（必答点），不是逐字稿；照着念会显得很假。

每题的标准格式是：一句话结论 → 一到两个具体例子 → 一句"我为什么这么做"。 缺任何一段都会显得要么空、要么像背的。

一、流水线设计类（8 题）

#	问题	必答点
1	讲讲你做过的 CI/CD	双 workflow（CI 验证 + Release 发布）；CI 是 push/PR、CD 是 release；三段发布链与依赖顺序；三个亮点（OIDC / 幂等 / 产物冒烟）
2	CI 和 CD 有什么区别？	触发不同、目标不同（验证 vs 交付）、CD 必须包含 CI 的全部检查；"发版前重跑测试"是防'上次绿了这次偷偷改了'
3	流水线为什么要用矩阵？fail-fast 怎么设？	覆盖版本/系统差异；`false` 是为完整诊断信息，代价是耗时——CI 的目的是信息
4	缓存和产物有什么区别？	丢了产物会失败，丢了缓存只会变慢；清了缓存就跑不过=藏着隐式环境依赖
5	如何保证流水线本身是可靠的？	幂等设计、 minimally 权限、定期禁用缓存跑一次、记录 flake 率
6	你们怎么处理 flaky 测试？	隔离 + 修 bug 预算 + 记录 flake 率；核心观点：随机变红会让所有人学会不看红
7	流水线太慢怎么优化？	先量：队列等待 vs 运行耗时；再优化：分层缓存、并行、测试选择；先修不可预测，再优化平均速度
8	Merge queue 解决什么问题？	两个 PR 各自绿、合起来红；代价是 CI 成本上升

#	问题	必答点
9	版本号怎么管理？	tag 为唯一事实源 → 构建前写回清单 → 三方一致性校验；本地 bump 只为 review
10	为什么 agent build 要"锁"依赖？	范围语法 = 非确定性；`uv sync --frozen` / `npm ci` / `--require-hashes` / digest 固定基础镜像
11	产物测过一次就够了吗？	不够：源码测试 ≠ 产物能用；干净环境安装 + 跑 `--version/--help`；四类只有这么测才发现的错误
12	为什么每个环境要复用同一个产物？	否则测过的字节和上线跑的不是同一个东西
13	多阶段构建解决什么？	编译器/构建工具不进运行时；伴随的好处：体积、攻击面、拉取时间
14	镜像为什么按 digest 而不是 tag 部署？	tag 可移动；对移动的目标做签名和验证等于没做

#	问题	必答点
15	部署策略有哪几种？怎么选？	重建/滚动/蓝绿/金丝雀/开关；按停机容忍度、资源预算、指标可用性三问往下选
16	就绪探针和存活探针的区别？	readiness 决定能不能接流量（可以查关键依赖）；liveness 决定要不要重启（绝不能依赖下游）
17	滚动更新为什么要优雅退出？	否则每次发布都是一次小范围用户报错；注意终止宽限期 vs 最长请求耗时
18	金丝雀的前提是什么？	可分辨的新旧指标；没有就是盲开。补完观测再谈自动化
19	有数据库迁移时怎么发布？	expand → migrate → contract 三阶段；加字段与删字段不在同一个版本里；这样回滚才便宜
20	发布后你应该盯什么？	健康检查 → 版本确认 → 核心路径 → 四条曲线；忘了确认版本号，就不知道自己发了什么
21	什么时候回滚？	条件必须提前翻译成数字：错误率/延迟/新错误类型/数据正确性；线上讨论三分钟=用户承担三分钟
22	回滚和 revert 代码有什么区别？	回滚=换回旧产物（快速止损）；revert=修代码（真实修复）。先回滚止损，再 revert 修因

#	问题	必答点
23	GitHub Actions 有什么安全风险？	第三方 action 篡改风险（2025 年 `tj-actions` 事件：tag 被回溯指向恶意 commit，凭据从 runner 内存 dump 到公开日志，影响逾 2.3 万仓库）→ SHA 固定 + 最小权限 + fork PR 不给 secrets
24	为什么用 OIDC 代替 API token？	令牌生命周期=一次 job；权限粒度收敛到哪个 workflow；不需要轮换
25	凭据泄露了怎么办？	轮换，而不是删提交——Git 历史是删不掉的
26	扫描、SBOM、签名、provenance 分别防什么？	扫描=已知 CVE；SBOM=里面有什么；签名=有没有被换过；provenance=谁在什么时候用什么构建的；前两者 ≠ 后两者

#	问题	必答点
27	AI 会让发布更容易吗？	不会自动。DORA 2025：AI 采用与吞吐上升、不稳定性上升同时相关；AI 是放大器。写变便宜了，"验、合、放、退"变贵了
28	AI 能放在流水线的哪些位置？	六个落点：PR 摘要/风险评分 → AI 评审 → 测试选择与生成 → 失败归因 → 金丝雀自动分析 → 受限自动修复
29	让 AI 自动修 CI 安全吗？	三条边界：限定确定性错误类型、修复必须过同一条流水线（CI 既审 agent 代码也审它的修复）、改动可审计可逆 + 敏感动作留人工 + 成本可见
30	怎么衡量 AI 带来的收益？	不能靠感觉。METR 的 RCT 显示感知与实际可能背离（以为快了实则更慢）；要用 DORA 五指标 + 流水线健康度（等待/P90/绿率/flake 率）来判定

① 结论先行：第一句话给判断，不要先铺垫背景
② 带上代价：任何方案都补一句"它的代价/适用边界是……"
    ——"什么时候不该用"是区分背答案和真懂的分水岭
③ 主动露出边界：答完补一句"这里我没验证过的是……"
    ——自曝边界，反而让前面说过的部分全部变得可信

另外，在讲任何流水线的设计时，主动邀请对方去看：开源项目的 Actions 历史、PyPI/npm 上的发布记录都是公开的。"你可以直接查"这句话本身，就是最强的一张信任牌。

注入方式	观察什么	说明的现象
让对方在你答完后追问"为什么不用另一种方案"	是否答得出取舍	答不出=背的
让你画流水线结构图	结构是否清晰	画不出=没真的理解过它的形状
追问一个具体实现细节（比如幂等怎么落地）	能否说出具体手段	说得出 `skip-existing`/查重/读远端事实=真做过
追问"你刚才说的 x% 是怎么算的"	数据来源	没有来源的答案要立刻降级为估算
让你评价面试官公司的方案	是否有边界感地提建议	只会说"应该用 XX"=缺乏取舍能力