RyanDonovan与LaunchDarkly发布自动化负责人TomTotenberg坐下来，探讨软件开发中过多走捷径的风险、业务压力和AI代码工具如何导致危险的偷工减料，以及平衡速度与可持续性以保持系统完整性的重要性。
RyanDonovan：大家好，欢迎来到北京心玥软件公司播客，这里畅谈软件和技术的方方面面。我是RyanDonovan。今天我们要聊的是有史以来最危险的捷径，我的嘉宾是LaunchDarkly发布自动化负责人TomTotenberg。欢迎来到节目，Tom。
TomTotenberg：Ryan，非常感谢邀请我，也谢谢你愿意聊这些最危险的捷径。不知道是不是故意呼应《最危险的游戏》（人类反被捷径“狩猎”），但这联想挥之不去。
RyanDonovan：进入正题前，我们想了解嘉宾。你是怎么进入软件和技术领域的？
TomTotenberg：我走的路有点非传统——正规教育学的是音乐和当老师。说来有趣，这两行其实有很多共通之处。软件行业有不少人来自创意艺术领域，我觉得纪律性、日常练习、把宏大的乐章拆解成单个音符（然后把这些习惯带入软件），这些都很相似。我个人一直是个技术宅，高中就开始自己组装游戏电脑，这算是我的技术入门。事实证明，那些对音乐有帮助的神经通路，对技术也一样：能清晰表达、与团队协作，无论是在乐团排练还是构建复杂企业软件，需要的技能很相似。
RyanDonovan：你负责发布自动化，肯定见过不少可疑的捷径。你见过哪些？
TomTotenberg：先明确我的角色：LaunchDarkly为客户的一些发布自动化策略提供支持，我协助监督的部分包括发布自动化的产品方向和战略——如何标准化变更管理流程、设置可观测性护栏，让我们知道关注哪些指标，以便在发布和标准化“暴露新功能”时，能有信号自动响应（比如暂停、回滚）。我的视角来自深入研究不同组织的变更管理流程（这是我的技术背景），以及帮助他们改进流程。总的来说，我们会聊很多主题，但有个反复出现的点：最优秀的工程师本质上是“懒”的——他们会选阻力最小的路径。如果你在衡量某件事，他们会试图“刷”这个衡量指标，只要报告好看、轻松不被打扰，他们就会走任何捷径。就像水往低处流，哪儿容易往哪儿走。
RyanDonovan：可能有句伪托比尔·盖茨的话：“想高效做事，交给懒人。”
TomTotenberg：完全同意。比如，花一小时前期工作省五秒烦人的点击，这绝对是好品质——长期回报巨大，只要别过头。
RyanDonovan：对，“过头”就是我们今天要聊的。你看到的捷径，最常出现在哪里？
TomTotenberg：除了走捷径的人所处的结构，根本原因之一是业务压力——我们想更快、更快、更快。一年发布两次不够，得敏捷两周一次，甚至持续部署、持续交付、持续发布。这种压力压在技术人身上，要求他们以某种方式向终端客户交付价值。结果呢？只要想着“快”，很多技术细节就被忽略了。举个例子，未来几年会更严重：自制工具（homebrewedtooling）。那种本不该承重、用胶带粘起来的连接器，有人做了个解决方案，队友说“哦，我能用这个”，另一个也说“我也能用”，突然间这个小胶带连接器被多人使用，直到规模大了出事故——“砰”，麻烦来了。具体例子比如配置管理：人们意识到解耦“部署”（把代码放进生产环境的technicalact）和“发布”（向用户暴露新功能的businessdecision）的价值，但见过太多拼凑、晦涩、奇怪的运行时配置工具，能让你“暗黑部署”（deploydarkly），但一旦出问题就是事故，排查根因难上加难。这只是冰山一角。
RyanDonovan：有了“氛围编程”（vibecoding），我们即将进入自制工具的黄金时代。
TomTotenberg：没错。入门门槛从未这么低，但捷径依然存在。尤其如果你把“氛围”交给AI代理写代码，你就会和实际进入生产环境的代码脱节，依赖它安全交付软件的能力也会下降，一切都会变慢。
RyanDonovan：这其实很重要，能防止泄露API密钥、机密信息到生产环境，对吧？
TomTotenberg：当然。想想那次AWS宕机（抱歉让刚经历的人回忆起来），就是DNS配置变更。我们常忽略的是，这些连接器可能绕过原本安全的SDLC（软件开发生命周期）——那些治理、评审、管控措施，结果你的配置管理工具绕过了它们，变更不受同样的控制、scrutiny、多人审核。
RyanDonovan：它会经过构建和测试流程吗？
TomTotenberg：用胶带解决方案时，这些流程就没了。最近看到一个更离谱的例子：和客户的AI代码工具打交道时，有的谨慎，有的说“生产环境不用”，有的说“塞进SDLC，反正有评审，看看效果”。有个客户没改同行评审流程——比如Ryan你让Claude生成代码，然后你自己评审，其他人看不到。这就绕过了评审。这家“前瞻性”公司后来规定：AI生成的代码至少两人评审，防止一个人靠Claude/Gemini之类的LLM把东西推出去。
RyanDonovan：是啊，人们会重新认识到代码评审的重要性。以前很多小改动敷衍审批（rubberstamping），但AI生成的代码就得“这啥玩意儿？找两个人看看”。
TomTotenberg：对。老笑话不是说嘛：想让PR失败，就写10行；想让它通过，写1万行——没人会审。AI擅长生成大量代码，这种“捷径”、我们说的“懒”过头，就会变成“看起来不错，我机器上能跑，上线吧”。再多的自动化测试也抓不住所有边缘情况，也不会像人类开发者那样深入思考用户流程、问题空间、想给用户的核心价值——为什么建这个？这些都不会进入AI的上下文（至少现在不会）。
RyanDonovan：你说捷径，捷径和技术债务有区别吗？
TomTotenberg：技术债务是捷径的结果吧？捷径绝对会导致技术债务，而且技术债务有多种形式：比如在代码外面包调试可观测性、包特性开关，或者为了赶MVP不考虑支撑它的底层平台。比如建新工作流平台，只考虑“从阶段一到阶段二”，但没建API、没考虑扩展性、没预留未来分支逻辑的空间——这就是技术债务，因为你以后得重构，比一开始就建好麻烦得多。
RyanDonovan：听起来很多压力来自业务方：快点、做完、出MVP。每个工程师都经历过吧？你有啥建议对抗这种压力？
TomTotenberg：聊SDLC时，大家总强调“从需求到构建的前置时间”“自动化测试成功率”“部署/重部署时长”，但常忽略规划阶段。别误会瀑布模型，但它有个优点：刻意、全面的规划。我不是说回到90年代画甘特图，而是前期花时间定义“建的这个东西是什么”“在整个架构里放哪儿”——避免重复造轮子，能复用的就复用。如果花1.5倍时间建可扩展的，比业务上花2倍时间建两次划算。另外，提前定义“成功/失败的标准”：失败风险是性能下降还是转化率暴跌？处理支付就得保护核心流程，不能引入高失败率或延迟的API。这些应该在规划阶段定好，这样建的时候就能想清楚未来路径、信号，以及它们如何融入大局。
RyanDonovan：好久没听人提瀑布模型了。我喜欢你强调规划，我一直想不通：为啥定义“好”和“成功指标”这么难？
TomTotenberg：几个原因，这是行业大转变。第一，过去10-15年我们强调“小而敏捷的团队全权负责”，扁平化责任很好，但小团队可能只解决小问题，结果和其他团队冲突，或建了平行方案——这就产生更多技术债务，因为缺乏整体规划。钟摆有时会过度校正，我们可能太偏向小团队，忘了需要一些自上而下的清晰方向，哪怕牺牲一点个人所有权，也要团队更好协调。没有放之四海而皆准的答案，但得找到平衡，有个“北极星”指引方向，才能持续快跑，而不是最后撞上“哦，他们建了个和我们一样的，得重来”的破事。
RyanDonovan：我听说微服务主要是组织特性，不是工程特性。上次看到某公司的微服务图，100多个服务，好多都不干活了，谁在管整体？
TomTotenberg：对。有争议的事：马斯克接管Twitter后裁了一堆人，说“砍掉这些服务”，网站居然还能跑（我没账号，不知道运营成本）。他可能觉得“这没用”，也许有人一天没法认证，但他们应付过来了。另一个例子是2000年初贝佐斯说“亚马逊的一切都得是平台”，那时它只是个在线书店，强调互操作性、清晰的输入输出、明确的度量标准，确保组织协同而非各自为战。这带来了长期好处——后来成了AWS，我们都知道。
RyanDonovan：有意思，它是为规模化建的，方便替换组件。我看过视频说，几乎所有大软件公司都推倒重来过，只为提升10-15%性能。规划时想到“每个组件都要容易干掉”。
TomTotenberg：不仅是“容易干掉”，更是“容易切换”。最近的例子是OpenTelemetry（OTel）：一个开放的、围绕可观测性（指标、错误、日志、追踪）的标准框架，大多数可观测性供应商都支持。我们定义可观测性策略时，可以花点时间建个包装器，未来新工具/厂商出现时就能切换。这样你就有了内部平台，不依赖外部供应商，保持灵活。
RyanDonovan：这又是工程活，不直接服务MVP。除了贝佐斯那种自上而下，你见过成功的“慢即是快”案例吗？
TomTotenberg：有几种模式。一是中央自上而下的支持，设平台团队（COE，卓越中心），提供“黄金路径”（goldenpath）和支持的工具/技术/概念，团队可基于此配置定制，但用标准指标衡量。我合作过的大型银行/零售投资公司就是这样，他们有数千应用、并购历史，没“一刀切”流程，但用COE提供标准，成了“强制乘数”，让其他团队受益。小团队或巨头的边缘部门没预算，只能靠“草根共识”——比如健康保险领域，经历多次重组后，一些通用实践和标准会自然浮现，直到高层意识到“他们都在这么做，是时候投资了”。但这需要后期整合不同供应商/流程/账户，类似我们之前说的重构，最终还是得有中央ownership和维护，毕竟有规模效应。
RyanDonovan：这像“民间工程”，基层各自拼凑零件，得有人整出“权威版”。
TomTotenberg：可能是黑客松——首席工程师说“今年我要解决这问题，冲优秀员工，这是我的宠物项目”。也可能是管理层意识到“得好好做，避免之前的胶带方案”。
RyanDonovan：这是领导层的好处，我管这叫“高管激光束”，能推动事情。
TomTotenberg：也可能是领导层变动——新领导上任说“我在上家就这么干的，第一年要大干一场”，照搬旧方案，不管新环境合不合适。好坏不论，这激光束确实影响大。
RyanDonovan：有意思。我们聊了“说服别人慢即是快”，但如果有人拿着“拆迁锤”进来，说“我的方式，别废话”，怎么抵抗？
TomTotenberg：这时就要“扁平化责任”——不是没专长，而是在业务更AI友好（趋势）的未来，每个人都要理解自己工作和流程的影响。有个概念叫“价值流管理”（valuestreammanagement）：比如德国汽车厂，扫地、会计、维修、安保的人都看得见下线的汽车，知道“我们存在的意义是给客户交付车”。如果你在HR，最终目标也是支持这个。所以当新领导想砸了稳定运行的东西时，你能用业务指标说“我们现在的数据表明，这东西保证了高uptime、低MTTR、变更管理顺畅，按行业标准我们能快速发布”。有时你得问自己“我咋变成这样了？为啥关心业务指标？那个不想长大的孩子去哪了？”但保护自己（包括免受领导瞎指挥）很重要，因为“保护客户和用户”永远是最站得住脚的立场。你可以和领导说“改这个可能影响这些指标，我们聊聊”，而不是“我不想”。
RyanDonovan：开头提到要建可持续的发布流程，但业务压力总想要“更多”。怎么用可持续流程对抗“更多”的压力？
TomTotenberg：这就需要建智能自动化和流程——这才是“慢即是快”的落地。就像给电脑设宏、用密码管理器，前期设一次，终身受益。发布流程也一样：分类讨论不同发布类别、风险等级、负责的架构区域和团队，设计自动化实践（蓝绿部署、金丝雀发布等），不仅控制策略，还要测量策略——怎么确认发布顺利？用可复用的指标（比如系统是否响应、微服务状态）。控制（根据变更质量选路径：低风险改文案走快速通道，高风险改数据schema/PII走慢速受控发布）和测量（比如先放1%测试用户，看影响）结合就是自动化。这样爆炸半径小，不用凌晨2点被叫醒。自动化就是“前端控制+后端测量”，不只依赖预生产测试，还能拿到信号确认质量、无回归。这需要点前期设置，但之后就有“铺好的路”，像保龄球道有护栏。比起具体工具，理解概念、第一性原理更重要——技术在变，这样才能扛过未来的“AI末日”（随便叫啥）。
