别再对 AI 写代码持怀疑态度了——Charity Majors

• 2025 年 3 月，Charity 和 Fred Hebert 在 SREcon 做闭幕演讲，当时"vibe coding"这个词刚被造出来。他们台上说"你们应该试试"，换来的是全场停顿 + 能听见的呻吟声。她当时的说法是"大家应该去学 AI，因为学了才能骂得更到位"——她说这话是认真的。 → 详细
• 那时她把 AI 定位成"比一门编程语言更大、像云那么大，但不是划时代的"，并且认为这个判断在当时是准确的。她个人的转折点是 2025 年 11 月 Opus 4.5 发布；但事后回看，苗头更早——"真正在变的其实不是模型，是 harness（脚手架），是围绕它的那一整套工具链"，从 7 月左右就有人在说"这东西来得比你以为的快"。 → 详细
• 她拒绝把过去的怀疑说成愚蠢："我不认为我们第一次怀疑是错的。"因为软件史上这类主张反复出现过（神经网络、无代码/低代码），当年怀疑是对的，"现在我们又怀疑，这次我们错了"。她和 Gergely 都强调：尊重会改变主意的人。 → 详细

• 她把话题从争论拉到工程："争论它会不会发生、什么时候发生都没有意义。要聊的是需要什么条件——要满足什么条件，你才会觉得把一段自己没读过、没理解的代码发上线是可以接受的？因为那才是工程。" → 详细
• Gergely 给出的两个条件很具体，也很像组织里的真实信任是怎么建立的：① 我能看到这次变更，并且知道它在某种仿真靶场里被锤过；② 类比 AI 之前——"如果有个团队成员说'我为这个背书，我已经把它锤过一遍了'，而我信任那个人"。 → 详细
• 第三个条件是并肩跑一段时间攒出的统计："你和 AI 并肩干上几个月，你就会摸出来：它抓出了多少问题？我抓出了多少？大致相当吗？更多还是更少？"她的结论是方向明确、时间不定："不管这要花五天、五年还是多久，方向上很明显。" → 详细
• 她同时保持了克制，这点很值得记："任何做过一次艰难数据库迁移的人，都应该对'我们有能力把那些契约抽取出来、存起来'这件事保持真正的谦卑……我不是那种说'太好了，我们要生成全部代码'的人。我不知道能生成多少。我相信我们能朝那个方向走出一段距离，而且这对我们是好事。我不知道能走多远。我相信能比现在走得更远。" → 详细

• 这是全期最好用的一个心智模型。她的原话："如果你在'代码创作'这个账户上支取信任，它就必须在别的地方被重新攒起来。" → 详细
• 补在哪儿？她先点名 测试和 evals（evals = 对输出好坏做自动化打分），然后指出传统测试的门槛其实很低："如果我们把代码当成一个可信的产物、试图用人脑去预测一切，那我们写的测试就只能覆盖我们能预想到的故障"；出了事再补一个回归测试，"这个门槛并不算高"。 → 详细
• 她真正想推的是 一致性测试（conformance testing）——不是问"跑得多快"，而是问"它有没有偏离太多"。她的提法："如果我不打算读这段代码，我怎么知道它的表现还在我上一次生成的代码的边界之内？"配套还有冒烟测试、性能测试、压力测试、模糊测试（fuzz testing，往里灌乱七八糟输入看它崩不崩）。 → 详细
• 她给这件事换了个框架，比"AI 不 AI"更有用：不要想成"AI 系统"，要想成"确定性系统与非确定性系统必须好好共处"。"确定性不会消失，它极其有价值。而我们得学会把 AI 变得无聊……它满天飞，但它太有价值了。所以我们必须给它开凿出通道、圈出场地，在它是超能力的地方用它，而不是在它侵蚀我们地基的地方用它。" → 详细
• Gergely 补了一个把"非确定性有多贵"讲透的例子：Hacker News 上有人拆了一个 HackerRank 外包出去的 ATS 简历评分系统（开源、可本地跑，推荐用 Google 的小模型 Gemma）。同一份简历跑 100 次，分数从 66 分飘到 99 分，而大多数公司把门槛设在 85 分。"他们宣传成'帮你做招聘'的工具，我们刚刚证明了它就是掷硬币。"Charity 的回应是："我们得能够说出'这很糟'。AI 不是每一个使用场景的正确工具。" → 详细

• 她大量引用 Chad Fowler 的 Phoenix architecture。Gergely 念了原文：不可变基础设施、无状态服务、容器、蓝绿部署、基础设施即代码，共享一个前提——永远不要去修一个正在运行的东西，把它替换掉；AI 把这个前提从基础设施推进到了应用代码本身，"当重写变得便宜，原地修改就变成了一件有风险的事。修改会累积熵，替换则把熵清零。" Charity 的回应只有四个字："代码即缓存（Code is cache）。" → 详细
• 支撑它的是经济账："你生成一个函数的一万个变体，比你手写一遍还快。"而软件昂贵的部分一直绑在维护上、绑在"我们信任它是因为我们一直在用它"这件事上。 → 详细

• 她讲了 Parse 的真实代价：六个月写出的 Ruby on Rails API，花了两年用 Golang 重写（Golang 当时还不成熟，得自己写 MongoDB 驱动）。用"绞杀榕（strangler fig）"模式时，"你是靠一个接一个地把用户的用法搞崩，来发现你和用户之间到底有哪些契约的"——她说这"实在不像是理想的产物"。 → 详细
• 她的主张：契约应该被存在某个地方，我们应该能有"可以评审、可以讨论、并按规格生成代码"的架构图。Gergely 立刻指出这就是 90 年代 Rational Software 的 UML 旧梦（Grady Booch 本人未必想让它走到那步），当年失败是因为复杂度 + 生成和评审代码都太贵——"但我在想，这些想法现在是不是就变得可行了。"Charity："这正是我的希望。" → 详细

• 起点是 Gergely 的一句实话："作为工程师我从来就不喜欢做代码评审……但一旦对面是 AI，我其实不太在乎。" → 详细
• Charity 的诊断：这个词在不同人那里意思差太多，所以里面有大量投射——"很多人一听你说你不想做代码评审，就自动理解成你不想跟同事说话、不想带新人。这不是真的。我们只是把太多东西打包塞进了这一个词里。" → 详细
• 她引用前 Parse 同事、现在在 GitHub 做 Pull Request 的 David Poll 的定义作为"该保留的那一半"："代码评审就是我们决定'这东西我们要不要放进产品里'的那一刻。" Charity："那正是人类擅长的事。我们应该讨论：这个心智模型自洽吗？我们该不该加这个？" 还有 API 设计、架构。 → 详细
• 该交出去的那一半是"逐行读语法、找 bug"——"它不邪恶，但感觉它可以不必是这样"，而且"在我这本账里，'验证'是排在最后面的"。理想情况下"你应该在写这段代码之前就讨论完"要不要做。 → 详细
• 她还点了一个组织级的病根：新人评审之所以必要，常常是因为"什么都没有写下来、没有指引、没有能替你做这件事的 lint 规则"——"如果我们没有把护栏建起来，我们可以用自己的时间去填这些缝……但在'构建并验证软件'这个过程里，有太多东西我们从来没想过要把它抽取出来固化，所以我们只能靠人。" → 详细

• 数字：一个 Ruby 单体应用，每次发布 10–15 分钟，一天几百次。她说这一点都不容易。她引用 Intercom CTO 十年前那句话："发布是你公司的心跳。" → 详细
• 他们是"AI 之前就成立、有很强工程纪律、后来变成 AI 原生"这一类里的高水位线；他们写过怎么做 AI 验证过的 PR，门槛设得极高——相当于把最资深工程师的全部智慧装上去看每一个 diff，于是人不用再去记、去盯、去挑刺（"那些本来我们就不擅长的事"），可以只谈方向对不对。 → 详细

• 她先给两边都留了体面："问题在于，两边都不是在编故事。"热情派"非常清楚这有点像一场赛跑"，看到别的公司跑得更快、甚至弯道超车，"他们没有错。我们从没见过这么快的技术变革，我们正处在一条指数曲线的内部"。 → 详细
• 最锋利的一个观察：两边都觉得自己是被压制的少数派——"都觉得寡不敌众，都觉得自己是在面对'AI 大佬们'或者'大怀疑派们'时挺身捍卫真理的那一方。" → 详细
• 而真正的断层线是："这件事往往归结为'谁在值班（on call）、谁不值班'。" 因为责任最终落到谁头上，谁就在眼睁睁看着"心智模型在融化"、看着垃圾代码、看着自己所有的辛苦成果在溶解，而且看不到尽头。 → 详细
• 反向的镜像效应同样致命：值班的人根本不相信那些收益是真的，"他们觉得那全是编的，因为他们没听到那句被咽下去的话——是的，我们看到了这个收益，但这是它的代价，我们现在还在收拾这个烂摊子"。 → 详细

• Gergely 给的一手信息：Meta 内部跟踪 SEV0（最高等级故障），过去大概两个月出了一大堆，而且集中发生在 Instagram 和 WhatsApp——那里的"信任与安全"、基本上就是可靠性那批人被砍掉了。"这东西藏不住，这可是 Meta，非黑即白。"他补了一句时间尺度：Meta 已经将近十年没有过这种记录了。 → 详细
• 这不是孤例。他在会议上讲完这个故事后，有人来说"我们不是 Meta，但同样的事情正在发生"；而所有人给他的第一反应都是同一句："我以为只有我们这样。" → 详细
• Intercom 是少数把难看数据也公开的公司：有 18 个月，可靠性和代码质量是往下走的；最近才刚刚"有可能开始回升"，但还没回到原来的水平。Charity 对此的评价是"他们不粉饰……终于有人这样了"。 → 详细

• 原话："我们需要听到胜利，我们需要听到什么是可能的，我们需要听到令人兴奋的东西。但你必须把代价一起讲出来。你必须一起讲：这值得吗？我们在干什么？" → 详细
• 她同时承认收益是真的："软件领域现在确实有一些非常惊人的事情在发生，比如重写、比如把真正的苦力活自动化掉。我聊过的人里没有一个愿意把它交回去。" → 详细
• 而只讲收益的后果是人身攻击化："一半的人只看到了收益，却没有把它跟代价连起来。这让他们觉得同事就是一群脑子有病的人、'只是不想丢饭碗'。不，兄弟，你去值一次班，然后再看看你什么感受。" → 详细

• Honeycomb 内部做了一系列关于 AI 规范与价值观 的讨论。她的时间线很诚实："一年前，我不信任我们自己。一年前如果我们说'对，我们应该用 AI'，不行，我们懂得还不够多。" 而现在，同事说"AI 不是干这活的正确工具"，她的反应是"我信你"。她给这个过程的定性是："你得先变差，才能变好。" → 详细
• 第一条价值观：承认所有人的标准都被抬高了，"当我们从新工具那里拿到力量时就会发生这种事"；而定义这个标准的唯一可行方式是"更好的结果"，并不断问"这好吗？这更好吗？好长什么样？"。她也承认现在是"在旷野里游荡"的阶段——"但你不能不游荡，否则你就会被落下。" → 详细
• 第二条价值观，也是最狠的一句："没有'人在回路中（human in the loop）'这回事。你就是那个回路的主人。这个回路是你的……如果不是因为我，它根本不会存在。所以我是所有者。没有什么'哦，是 Claude 这么说的'。不不不。这是你的活儿，你对它负责。" → 详细

• 底线一条："你不能把一个你自己都没读过的东西发给别人。" → 详细
• 判据一条（这条极好用）："如果对方读它花的时间比你生成它花的时间还长，那它多半就是垃圾。" 理由是成本转嫁——"任何时候我给你一个东西，我都是在向你索取时间和注意力。如果我给你的东西我自己都不知道里面写了什么，然后我把它甩给你，那成本就从我身上转嫁到了你身上。" → 详细
• 分界线一条："你可以把 AI 当成一条捷径，让自己不用怎么动脑；你也可以用 AI 帮自己想得更深、更严谨。这两类用法大多数都有它们的位置。但当涉及你的核心工作职能时，我们主要想要的是第二种。" → 详细
• 她特意留了例外，不搞绝对主义：英语是第二语言的人、神经多样性的人用它，"那同样是尊重"。总结："这不是'不许用 AI'，而是互相提出合理的要求……我们不需要为质量和尊重重新发明一套标准，我们本来就有。" → 详细

• Gergely 的推断：五年后面试就是一场对话，"你会根据我怎么回应来判断我"；候选人里有些人把思考外包给了 AI，"他们身上会有一块空白，因为那部分是关掉的"。Charity 的呼应是她自己不用 AI 写作的理由——"写作就是在纸上思考，而那份思考没有任何捷径"，她只用它做结构和反馈。 → 详细

• 她写过一句被 Gergely 引用的话："代码行不是理想的评审对象。做这件事的工具还不存在，但很多想法已经存在了，而且大多来自运维和 QA——这两个领域一直被软件工程有点势利地看不起。" → 详细
• 她给出的分工差异极精炼：运维和 QA 一直更关心"是什么"，软件工程一直更关心"应该是什么"；前者关心验证、正确性、"它是不是按预期在工作"。 → 详细
• 由此那句名言："我一直觉得很怪的一点是，软件工程师竟然真的那么相信'世界就存在于代码仓库里'。不是的，是生产环境。"以及："生产环境不是开发之后才发生的事，它就是开发的一个阶段。"这也是她当年反对"周五别部署"和反对搞 UAT 环境的同一条逻辑——合并即上线，"应该是要拉手刹才能让代码在合并之后不进生产"。 → 详细
• 她对 AI 最真诚的赞美也在这儿："真正让我对 AI 兴奋的地方在于，它正在把这个行业往我们早就迫切需要去的方向上推。" → 详细

• 她的历史判断毫不留情："在我心里，二十年的 DevOps 其实就是关于一件事：试图创造一个把'写代码的人'和'代码在生产环境里的样子'连起来的反馈回路。而它失败了。" 第一波"运维学写代码"她认为成功了；第二波"软件工程师学着在生产环境里理解自己的代码"没那么成功。 → 详细
• 但她明确不反对职责分离，而且给了一条很干净的切分线："我负责的是'你把代码放上去的那个东西'的稳定性，还是我负责'我放上去的那段代码'？这是一条很好的接缝"——因为你希望基础设施稳定、能自我保护、有韧性；而希望代码面向"每一个用户是不是都有好的体验"。这两件事可以一个成立、另一个不成立，它们是可解耦的。 → 详细
• Gergely 给了个有意思的旁证：连 Anthropic 这样"从一张白纸起步、运作方式和大多数公司很不一样"的公司，内部也分成 平台团队（云平台） 和 Applied AI（更接近功能/集成团队）；他两边都聊过，世界观差异大到连"软件工程师会不会被淘汰"都答得完全相反——平台团队说"不会，我们正拼命干活呢"，Applied 那边说"嗯，也许会吧"。Charity："这一点都不让我意外。" → 详细
• 她认为 agent 正在打破这条旧分界："要做一个好工程师，你需要快速的反馈回路……如果你只住在'理论上它应该怎么运行'的国度里，那不行。" → 详细

• 教科书答案是"可观测性有三大支柱：指标（metrics）、日志（logs）、链路追踪（traces）"。她直接把前两个降级："指标和日志是系统的尾气，是排气管。" 它们永远不会消失，因为每个团队都要跑一堆第三方软件——不是你写的、不归你所有、你只能运行它，而它在往外吐东西。"你应该把它放在便宜的地方。这类数据量巨大，价值不算特别高，但你确实需要它。" → 详细
• 然后是分水岭那段，也是本期最该背下来的一段："然后是你自己的代码，那是你的皇冠明珠——那是让你成为一家公司的代码。对这部分代码，你的遥测（telemetry）应该是一个产品决策。" → 详细
• 为什么值得当产品做："你应该带着全部的连接组织把它存一次，因为丰富数据的价值增长不是线性的，甚至不是指数的，而是组合式的。如果你有一个宽事件（wide event）或者一条 trace，上面已经有 29 个字段，你再加第 30 个，那第 30 个比前面所有字段都更有价值。"（宽事件 = 一次请求发生的所有上下文塞进同一条记录，而不是散成一堆日志行。） → 详细
• 收尾一句把它和 AI 直接焊上："面对非确定性软件，你一上来就知道你无法预测它会做什么……捕获那条 trace 本身，就是一个产品决策。" → 详细

• 她详细复盘了"以前为什么没人愿意做"：拿到一点数据，你得逐层决策——它是指标、日志、trace、异常、错误还是 profiling？如果是指标，它是计数器还是仪表量？它是不是高基数（high cardinality，即取值极多的字段，比如用户 ID）？如果是日志，用哪个级别？ "你花在给代码埋点上的时间可以是写代码时间的两倍、三倍、四倍，而且还没弄完。"部署完还有第二关："我知道我加的那个东西叫什么名字，可我要怎么找到它？怎么显示？怎么建一个 dashboard？" → 详细
• 而现在结论反过来了："近几年自动埋点（auto instrumentation）已经好得不得了了。如果你在用 OpenTelemetry——而所有人都应该用 OpenTelemetry——所有常见的模式，所有模型都是在这些东西上训练过的。所以现在带着埋点去构建，字面意义上比不带更快、更省事。" → 详细
• 她给埋点的定位升级了一档："这就是开发者意图的一部分。这是你声明意图的方式，也是你在生产环境里回头验证自己意图的方式。" Honeycomb 已经做到让 agent 主动提示"你刚写的那个东西，也许你想看看这个"，而且可控严密程度——"它应该是你开发回路的一部分"，不用离开开发环境去别处取。 → 详细

• 基础定义（她给的白话版）：trace 其实就是一条带了一些花哨字段的结构化日志；span 是 trace 里构成整段时长的那些子段。 Gergely 引了一句概括："应用可观测性的基本思路就是，别用日志、也别用指标，把所有东西都放进 span 里。"（引述人名 ASR 存疑。） → 详细
• 关键判断："自从 Web 出现以来，默认的基本构件一直是'事务（transaction）'。那个东西现在不管用了"——具体就是在 AI 场景下。 → 详细
• Honeycomb 因此发布了一个建在 span 之上的新原语 Timeline。她给的场景就是 Intercom 式的客服对话：客户来投诉 → 你启动一个主管 agent，它又启动更多 agent，每个 agent 都在调 API、调存储后端 → 然后客户又回来一次……"这可能跨越好几个小时。你需要能够拉远视角、把整件事可视化出来。" Gergely 的总结："它像是一条元 trace"、"trace 的 trace"。 → 详细

• Gergely 提的是真问题：agent 现在能连上可观测性数据仓库去干活，但 agent 的上下文窗口有限，可观测性数据很容易就把它撑爆。 → 详细
• Charity 的答案有两层。第一层是承认："外面有大量垃圾数据……很多传统遥测数据——指标、日志、trace——往往会把你的上下文窗口塞满垃圾，而数据里最重要的部分是数据之间的关系。" → 详细
• 第二层是一个很有信息量的实地观察：几个月前一家做 AI SRE 的创业公司发文说，他们看到自己部署在真实环境里的 agent，大多数时候会绕开可观测性数据，直接往上游去找更丰富、更完整的遥测数据。她的结论："重要的是关系——因为那才是真正帮 AI 做判断的东西。" → 详细
• 她自己最期待的下一步是三样东西合流：测试 + 遥测 + evals。 → 详细

• 篇幅：第一版 250 页，第二版 600 页，六个部分，第一、六部分由她本人执笔；合著者 Liz、Austin、George；客座内容包括 Hanson Ho 写前端/移动端、ClickHouse 写列式存储、CI/CD 若干篇、Fin 的 Kesha 写他们怎么迭代式做可观测性。 → 详细
• 第二、三部分讲怎么埋点、怎么理解，并且分成"用 AI"和"不用 AI"两条并行路径。 → 详细
• 第六部分是她的心头肉：原计划三章，最后写成全书三分之一、200 页，讲面向管理者的可观测性治理。开篇是一封写给 CTO 的公开信："你们所有宏大的 AI 目标，都卡在'我们能不能看懂自己的系统'这件事后面。" 后续章节包括：怎么向财务量化可观测性的影响、什么时候该把它当成本中心、什么时候该当投资（"因为它会继承你所观测的那类软件的属性"）、Rick Clark 写的"没有正式权力怎么推动巨大变革"、以及自建/采购/开源怎么选。她还说这一部分"没有任何时髦词，只有系统论"，喜欢 Donella Meadows 的人会喜欢。 → 详细

• 她最喜欢的章节之一。核心论点：大多数转型失败，成功的那些之所以成功，是因为组织内部有人拥有信任和信誉——"你说什么，人们就相信那是真的。这种信誉能像热刀切黄油一样切开官僚层。" → 详细
• 最好的供应商关系是"你真心觉得他们的成功就是你的成功……那种感觉就像你们是同一家大公司里的两个不同团队"。她也承认这很罕见，大多数关系就是握手、钱货两清，"这也挺好"。她把这类能力定性为 AI 时代的"持久能力（durable skills）"。 → 详细

• 她的论证很短："正因如此，我们可以把护栏烤进去，把检查烤进去，把验证烤进去——而这在我们生活的其他部分、在其他应用里，我真不知道该怎么做。"对照组是法庭已经开始起诉提交幻觉内容诉状的律师——那种东西你怎么检查？ → 详细
• Gergely 把它推成一条更强的判据：AI 在软件行业之外能跑通的东西，会是它在软件行业里能跑通的东西的一个子集——"如果我们都做不到，那你就自求多福吧，因为我们这个领域是能验证东西的领域"，而且有海量"能编译通过"的高质量训练数据。 → 详细
• 一个反直觉的经验数据点：Gergely 本以为 AI 最强的是写作（他每出新模型就让它"用 The Pragmatic Engineer 的风格写一篇"），结果每一次都能认出来是 AI，因为重复、有固定腔调。他的结论："AI 写散文其实没有它写代码那么好"——写代码时他觉得"这东西我自己也能写出来"，写文字时却是"这句话我永远不会这么写"，而模型是有他的训练数据的。Charity 的解释："软件是为某个目的而简化过的语言。" → 详细

• 五年前他们各自写过答案，结论一致：可以度量某些维度，但给不了全貌，尤其不会告诉你团队状态如何、某人是不是团队真正关键的一环；作为好管理者"你是会知道的，但你得有数据来支撑它"（否则就是古德哈特定律的坑）。 → 详细
• 她在 AI 时代的新回答是把靶子挪了："如果 AI 这波浪潮里有一件让我振奋的事，就是它在逼着我们所有人尽早并且反复地问自己：'好'到底长什么样？'生产力'是什么意思？'更好'会是什么样子？" 而她的批评是："我们所有人都那么快地跳到了'速度'上……我慢慢觉得，那是对'更好'一种非常不成熟的定义。" → 详细
• Gergely 的佐证：他看到 Spotify 工程负责人讲"每天/每周 4,500 个变更"，但"他们在讲速度，我们没在讲质量，没在讲更多的功能、更好的功能，或者人们真正想要的东西"；而他自己有几期播客压根没能发上 Spotify，因为服务挂了。他补的那句尤其适合贴在需求评审室墙上："用户真的想要 App 上的按钮一直挪来挪去吗？我不觉得。" Charity："它是最容易度量的东西。" → 详细

• 她被引用的原话："最有效的领导者是善良、关心人的人，同时是熟练的生意操盘手。第二有效的领导者是糟糕的人，但也是熟练的生意操盘手。再往后才是其他所有人。" 她澄清自己未必把马斯克算作"熟练操盘手"，但事实是 Twitter 有 16 年没把生意想明白，而 X 现在用原来 20% 的人在跑——核心产品约 30 个工程师、总共约 60 个，之前是 1,700 个。 → 详细
• 结论那句很硬："如果我们不自己动手——不给自己定高标准、不高效地构建、不持续地想变得更好——就会有人来替我们做。" 以及："如果我们想继续留在领导位置上、想设定文化和调性、坚持我们相信的伦理，我们首先必须在生意上赢。" → 详细
• 她用 2010 年代硅谷"钱多时搞 DEI、日子难过就全砍掉"作为反例，得出："光做个好人是不够的……善良的人在同样岗位上通常确实比反社会者做得更好，但前提是他们得懂生意。学生意，离生意近一点。" → 详细

• 第一条变化："每个人都必须、也都有机会亲自动手了"——具体说是去生成一些代码、把东西发到生产环境，"你应该知道提交一个 diff 是什么感觉，知道把一个 PR 推过去是什么感觉"。她的判断是"现在就是没有借口不这么做了"。 → 详细
• 她明确反对"反管理"的时髦叙事，同时承认管理层确实会膨胀（"官僚体系会自己长出来，说'是'总比说'不'容易"）。但她的结论是："我相信管理、尤其是中层管理，是极其必要的。" → 详细
• 角色的重新定义是本期最值得抄走的一句："管理者、中层管理者的角色是'意义建构（sense-making）'和'给上下文'。因为我不相信那种世界：工程师只是被丢过来一堆任务——这是你的 DRI，去干吧。那种事 AI 就能做。" 她要的是"理解我们在试图做什么、理解我们打算怎么做、或者能帮我们一起搞清楚该怎么做的人"，因为"如果不理解，你就没法在情感上、创造性上、协作上真正投入"，而"那种理解极难建立，它很脆弱，而且从来维持不了多久"。 → 详细

• 她的战术建议直白："先回去做一段时间 IC，哪怕你知道那不是你想干的。" → 详细
• 更硬的一条："你必须把 AI 写进你的简历，你必须。这是一个巨大的职业风险：如果你所在的地方让你学不到这些技能，那是巨大的风险。" → 详细
• Gergely 用市场数据佐证了这条窗口正在关：有两三年 AI 工程经验的人"抢手得不得了"，他做就业市场研究时听到的是"史上最好的就业市场"；而零经验、又刚好失业的人非常难，"没人愿意给他们一个疑罪从无的机会"。Charity 的补刀："下一次你出去面试，任何人都会被问到这个。如果你没有，你就会被筛掉……有那么一段时间入门非常容易；现在门还开着，但时间越久，追上去就越难。" → 详细
• 给总监（通常已做管理十年、恐惧"技术变太多了"）的那段，是本期结尾被主持人单独拎出来的金句："我们体验焦虑的方式和我们体验兴奋的方式，在生理上几乎是一样的。但两者的区别在于能动性（agency）。" 她拿弹钢琴上台前的发抖出汗举例——同样的身体反应，你告诉自己是兴奋。"如果你往后一靠、等着水漫上来，你就只会崩溃。但如果你朝着浪跑过去……认下它。就跟自己这么说，不必是真的：我太兴奋能重新做 IC 了。" → 详细

• 她先把度量问题挑明："量化初级工程师价值最难的地方在于，我们本来就不知道怎么量化任何工程师的价值。所以全是凭感觉。" → 详细
• 她朋友 Boris（在做一家新的可观测性创业公司）天天跟高中生、大学生聊，评价是："这帮孩子简直在起飞。他们不知道软件开发生命周期是什么，但他们正在做超多酷东西。" 她的结论："我相信这帮孩子会没事的。我们只需要雇他们，只需要给他们一个机会。"Gergely 的实例：某开源贡献者特别出色，公司想招，发现是个 17 岁的孩子，照招不误，现在评价是"这孩子做的事太厉害了"。两人都推荐用实习切入——低风险、短周期。 → 详细

• 她先拆分"AI 疲劳"到底指什么：① 天天收到 AI 垃圾（slop）；② 炒作；③ 她引用 Cal Newport 造的词 "末日钓鱼（doom trolling）"——形容 Anthropic 和 OpenAI 的 CEO 一直在说"这可能是某某某的终结"，"他们该停下来，因为他们把所有人都吓得半死"。她补了一句技术史对照：以前新技术是"酷、好玩、让你生活更好"（比如 iPhone），"而现在只剩下恐惧"；她自己已经因为受不了 AI 垃圾帖而不上社交媒体了。 → 详细
• 她给的解法是把普遍的挫败感当成变革窗口："这种挫败感的普遍性，恰恰说明现在是提出实验、把控制权拿回来的好时机。" 具体到可以明天就跑的实验："也许你和你的团队达成一致：我们其实不想再要 AI 生成的 PR 描述了。或者：我们周三都不用 AI。" → 详细
• 而作为 CTO 她给的授权方式很有意思——不是审批制，是事后汇报制："更好的是：别提前告诉我，事后来告诉我什么管用、什么不管用、你学到了什么。" 理由是"在它跑通之前我们根本不知道该给什么许可，自下而上效果好得多"。 → 详细
• Gergely 的历史类比给这条加了权重：iPhone/Android 刚出来时，最猛的 iOS 工程师通常是 18、19 岁的孩子，两年后就成了主要专家——"Staff 工程师是个 22 岁的人，而入门级工程师是个 40 岁的人"。他的结论："当变化这么大的时候，你真的可以在很短的时间里成为专家……而且也不会真有人对你说不，因为没人知道什么才管用。" → 详细

• Honeycomb 是完全分布式公司（本来想做混合，但办公室没回来）。她说自己"爱不出门"，但"我不喜欢一整天在 Slack 上，在 agent 和人之间来回聊天的感觉，它们太像了，让人不舒服"，所以她很珍惜面对面。她的落点是："我们才是机器的主人，它们是伺候我们的。这才是真正重要的东西。" → 详细

问：有没有一两本书给了你一些东西？（本期没有标准闪电问答环节，只有这一个收尾提问）

• 《Catastrophe Ethics》（灾难伦理学）· Travis Rieder（生物伦理学家）——她说"真正的哲学发烧友会嫌它通俗，不读哲学的人又会嫌它哲学太多"。核心是现代生活的困局：每一个选择你都被牵连（喝牛奶——奶牛被虐待；喝杏仁奶——水资源问题），不管做什么都在伤害某个人，而问题大到让人觉得自己的决定无关紧要。 作者走了一遍功利主义等传统框架，证明没有任何一个人人可照做的配方不会把你带向愚蠢结论，最后落在"无神也无主"：要过有正直感的伦理生活，你需要去了解世界，然后往内听——哪一种苦难真正打动你，"因为没人能告诉你什么才重要，你必须自己决定"。她说这种内省"跟那种表演式的愤怒截然相反"。 → 详细
• 《More Everything Forever》· Adam Becker（旧金山记者，哲学本科 + 天体物理学博士）——她已经推荐过好几次。这本书把奇点论、有效利他主义、加速主义、以及"永远无限增长"那一整套"AI 宗教"拆了个稀巴烂。她最爱引的一句："各位，宇宙会热寂的。关于指数增长，我们唯一确切知道的一件事就是它必然会结束——要么以 S 型曲线结束，要么以崩溃结束。"作者还有一记重击：谈到那些拼命做延寿的人时写道"这就是一群想念爸爸的可怜小男孩"，Charity 的反应是"这是人类最古老的恐惧，对死亡的恐惧。你一旦看见它，就没法再假装看不见了"。 → 详细

主持人的收尾提炼（他自己挑出的两个要点）：① 信任账户——从代码创作支取的信任，必须靠测试、evals、护栏在别处补回来；② 两个阵营都不算错，但应该多跟对方说话——"如果你在 AI 上看到了收益，就分享给更大的团队；但当它带来更多工作、降低可靠性、让质量退化的时候，也要把这些讲出来。" → 详细

本期未给出嘉宾的社交账号或邮箱。可追的公开物是：《Observability Engineering》第二版（O'Reilly，600 页），以及她本人的博客（本期多次引用她"让 AI 变无聊""AI 只是技术""2025 是 AI 的 2010"等文章）。Honeycomb 的产品线里与本期直接相关的是新发布的 Timeline（span 之上的"元 trace"）。 → 详细