KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

04 · STAR 与话术：把交付经历讲成一个可信的故事 — keel 龙骨

这一章回答：怎么把"我配了一条流水线"讲成"我有工程判断力"。同样一段经历，讲法不同，结论完全不同。

这一章回答：怎么把"我配了一条流水线"讲成"我有工程判断力"。同样一段经历，讲法不同，结论完全不同。

一、为什么交付类经历特别适合 STAR

交付工作的成果通常是消除了尚未发生的麻烦：一条流水线跑得好，表现为"什么事都没发生"。这让你的经历天然难以讲述——所以要用人造的结构把它显现出来。

STAR 在这里的用法：

要素	交付话题下该怎么填	反面样例
S（情境）	说清规模与约束：单人/小队、几个服务、发布频率、有没有 K8s	只说"公司项目"
T（任务）	说清你被要求解决的是哪一类风险：怕发错、怕改了忘跑测试、怕发布过程不可重复	说"负责 CI/CD"这种空话
A（行动）	必讲设计取舍：为什么这么拆 job、为什么选 X 不选 Y、做了什么保证可重跑	只罗列步骤
R（结果）	机制 + 可验证事实：链路可重跑、免长期令牌、发布前置 Junior 检查；多处可公开查	编出来的百分比

二、三份可直接使用的 STAR 卡

卡片 A：完整发布链（开源主牌）

S  个人开源 CLI 工具，多系统多 Python 版本用户，手工发版既慢又容易漏校验。
T  目标不是"自动发"，而是"发布过程可重复、发错了能安全地再来一次"。
A  拆成两个工作流：CI 在 push/PR 跑矩阵测试（3 OS × 2 Python，fail-fast: false）
   + ruff/mypy strict + 构建 + wheel 冒烟；Release 才触发发布链，三段有依赖顺序
   （PyPI → npm → Homebrew，因为下游引用上游产物）。四件事是刻意做的：
   ① 版本号以 tag 为事实源，构建前写回清单并做三方一致性校验；
   ② 每个渠道都做成幂等（skip-existing / 查重 / 读已发布产物），部分失败可以整体重跑；
   ③ 用 OIDC 换取发布凭证，仓库里不留长期令牌，npm 加 provenance；
   ④ 冒烟测的是产物不是源码——干净环境装 wheel 再跑 CLI。
R  有任何一段失败都可以原地重跑而不产生半成品；发布权限不再依赖某串需要保管的 token；
   全过程在 GitHub Actions / PyPI / npm 上公开可查。

关键点：A 段的四件事每一件都能被追问"为什么这么做"，这才是这段讲的杀伤力所在。

卡片 B：发布过程的固化（公司侧，诚实版）

S  公司项目多服务（API + 异步 worker + Redis + MySQL），Compose + Nginx 部署，发布频率低但每次影响面大。
T  当时的痛点不稳定：每次上线步骤不完全一样，回滚靠人记。
A  我没有引入重平台（考虑过，但不划算：服务数不多、没有专人维护），做的是把变量消掉：
   ① 写清楚依赖启动顺序与健康判断；② 发布脚本化并保留可逆性；
   ③ 日志与版本号带上，出问题能定位到具体版本；④ 回滚步骤写进文档而不是记在某人脑子里。
R  发布从"看谁值班"变成"按文档执行"；回滚有明确步骤。
   局限我也清楚：这条链路没有自动化触发，仍依赖人按一下。

这张卡的价值在于证明你有"取舍能力"——知道什么时候不该上重方案，比会上方案更稀缺。

卡片 C：一次被流水线挡住的错误（体现 CI 的目的）

S  一次重构的中间提交，本地只用了一个环境验证。
T  提交时我以为改动很小。
A  推送后矩阵里的另外两个平台报红，类型检查与某个平台的路径处理同时出问题。
R  这个红 run 我没有绕过它去合并，而是修完再推。它把"我以为改完了"挡在了发布之前——
   这恰恰是 CI 的目的：它提供的价值是信息，不是装饰。

这张卡的妙处在于用一次"失败"证明你理解 CI 的目的，而且完全诚实。

三、时间版：30 秒与 90 秒两个模板

30 秒版（被问"讲讲你做过的 CI/CD"）：

"我的开源项目有一套完整链路：CI 侧是三系统两版本的矩阵测试，串了 pytest、ruff、mypy strict 和 wheel 冒烟；CD 侧是打 Release 才触发的多渠道发布链，用 GitHub OIDC 换发布凭证、仓库里不留长期令牌，每一段都做成幂等，任何一段挂了都能原地重跑。整套东西在 Actions、PyPI、npm 上都可以直接查。"

90 秒版（技术深聊 / 追问展开）：

30 秒版 + 补充三段：
"① 版本管理上 tag 是唯一事实源，构建前会写回清单并做三方一致性校验，因为发布产物不可变，所以构建前必须校验；
② 发布链有依赖顺序，因为 npm wrapper 和 Homebrew formula 都引用 PyPI 上的产物，上游没有下游必失败——这是数据依赖不是拍脑袋；
③ 我还处理了跨系统的最终一致性：PyPI 刚发出来的版本 JSON API 可能还没可见，所以要轮询等待，这个问题形态和处理消息队列的消费滞后其实是一样的。"

第二段的三句分别展示：规范、依赖推理、问题迁移能力——第三句是最容易让人记住的一句。

四、雷区清单（交付话题专属）

❌ 把公司项目的脚本化部署说成 CI/CD            → 三问之内必露
❌ 说"我们用了 XX 平台"但说不出 job 与依赖      → 说明只见过别人搭的
❌ 编"提升了 X% 效率"                          → 追问数据来源就崩
❌ 把没实际运营过的东西说成"我在 DevOps 上很深"  → 方向不对：目标是够用不是转岗 SRE
❌ 被问"这一趴没做过的吧"时辩解                → 承认 + 转向我做过什么
❌ 主动提起 K8s/GitOps 却讲不清适用边界         → 懂名词不懂取舍是减分项
❌ 把 AI 自动修 CI 描述得像万能方案       → 必须同时讲边界，否则显得没真放过权限

五、给面试加分的两个反问

技术面后半段的反问环节，可以用这类问题把对话拉到同等层面：

反问	它在表达什么
"你们现在的发布频率大概是怎样的？回滚一般需要多久？"	你关心的是交付健康度，而不是单点技术栈
"流水线这边，最让团队难受的是排队慢、还是 flaky 测试？"	你有运营流水线的具体经验，能分辨不同类型的痛

这两个问题对方一答，你就知道这家公司的工程成熟度——这也是它们真实的价值：你在面试对方。

动手：可观察结果

动作	产出物	判断标准
把三张 STAR 卡写进自己的话术文档	三份文字稿	每张都能在不看稿的情况下讲完
录一遍 30 秒 + 90 秒版本	音频	时长达标；无"呃/那个/大概"超过 3 次
自测雷区清单	逐条打勾	七条里有哪条是自己会犯的，标出来改
准备两个反问	文字	能在对方回答后接得上话，而不是问完就断
找人做一次 15 分钟模拟	反馈记录	对方的复述里出现了"幂等/OIDC/产物冒烟"中的至少两个

故障注入

注入方式	观察什么	说明的现象
讲完被人复述一遍	对方记住了哪几个词	记住的是"搭过流水线"还是具体机制，差别很大
让对方打断追问某一步	能否展开三层	只能展开一层说明没动手做过
对方说"这些平台都能自动做啊"	你的回应	好答案：是工具能自动做，但幂等与权限边界是设计出来的不是自动的
讲公司项目时被人一句"所以没有 CI？"打断	会不会慌	标准处理：承认 + 解释为什么当时那样是合理的 + 转向开源实绩
反问后对方说"我们没统计过"	能否顺势	可以顺势讲 DORA 指标，这是加分机会

自测题

为什么交付类经历特别需要用 STAR 显式地讲出来？
卡片 A 的四个刻意设计，各自对应的"为什么"是什么？
卡片 B 证明了哪一种比"会上重方案"更稀缺的能力？
90 秒版里最能体现"问题迁移能力"的是哪一句？
雷区清单里，你自己最可能踩的是哪一条？打算怎么提前纠正？

进入 keel 阅读