史蒂夫·利普纳走进微软 Windows 团队经理的办公室时，用他自己的话说，「有一半心理准备会被轰出去」。他的提议是：让 Windows 停止开发。每个开发者先去上安全培训，再回到现有代码里找漏洞。
一位同事回忆，当时的 Windows 是「一艘九千人的超级油轮」。业务负责人起初只肯停两天，利普纳的团队要一个月。
据微软自己的记述，2002 年 2 月，整个 Windows 部门停了下来。利普纳说，目标是让「全部 8500 名一线开发者」在安全上跟上来。内容保密，公司能用的最大房间是微软简报中心，坐得下 950 人。一天两场，连开五天，场场坐满。「这个培训我们办了十次。」利普纳说。
先算代价：随后的安全攻坚持续了两个月。再算走进大厅的是什么。利普纳后来写过，团队把开发者需要知道的东西压缩成一门四小时的课，由三个人来讲。
会走路的小时
第二笔账，英特尔总裁安迪·格鲁夫给过它一个名字。1983 年出版的《格鲁夫给经理人的第一课》里，他把它叫作杠杆：「任何一项管理活动所产生的产出的度量」。
经理的一小时，能左右别人几百个小时，往好往坏都可能。
格鲁夫列了三种情形：一个经理的工作，影响到很多人；简短而切中要害的几句话，长期改变一个人的工作方式；一个人掌握的关键知识，整个团队都靠它。第一种，他举的是自己的例子：在英特尔的新员工入职课上讲两个小时，台下大约两百人。第二种，他举的是绩效评估，准备加面谈不过几个小时，对下属工作的影响却可能「非常大」。
一对一会谈，他也算过账：每两周一次、每次九十分钟，「能提升下属两周、也就是八十多个小时的工作质量」。
微软那门课属于第一种：三位讲师，十场四小时的课，内容被带回几千张办公桌。之后微软又造了工具，成立了内部安全审计小组，到 2004 年，形成了一套强制执行的「安全开发生命周期」。
杠杆往反方向撬
「杠杆也可以是负的。」格鲁夫写道。身为关键人物开会却没准备，浪费的是一屋子人的时间。仗着自己更懂，把下属的问题接过来自己处理，次数多了，下属就不再自己解决问题，而是把问题交给你。别人在等的决定迟迟不做，「没有绿灯就是红灯，整个组织的工作都可能停下」。
一堂课同样有两面。格鲁夫举过一位英特尔工程师给销售讲产品线的例子：讲得好，销售更好卖；「讲得差，造成的损害又大又明显」。
杠杆也不打包票。2003 年 7 月，微软把 Windows 处理远程过程调用的组件里的一个漏洞评为「严重」，受影响的版本里就有 Windows Server 2003，正是那次攻坚梳理过代码的系统。格鲁夫的杠杆，是他从管理英特尔的经验里总结的思考方式，不是测出来的定律。它没有仪表，只能估。
每个智能体都会读的那份文件
编程智能体如今也有了自己的「入职课」。很多团队会在代码库里放一份上下文文件，常叫 AGENTS.md 或 CLAUDE.md，智能体每次接活之前都会先读。
2026 年，苏黎世联邦理工学院和 LogicStar.ai 的研究者检验了这类文件到底有没有用。他们让几种编程智能体做两组任务：一组来自热门代码库，配上 AI 生成的文件；另一组是 12 个不太出名的 Python 代码库里的 138 个任务，配的是开发者自己提交的文件。
智能体确实照着文件做。文件里提到 uv 这个工具时，智能体平均每个任务用它 1.6 次；没提到时，不到 0.01 次。可在这项研究里，文件没有显著改变解出的任务数，运行却变贵了，作者给出的平均涨幅在两成以上。各家指南推荐写的代码库概览，也没让智能体更快找到该改的文件。作者建议，人写的文件只放智能体需要、又在 README 里找不到的东西，比如特定的约定；任何改动，先测过再上。
这正是格鲁夫说的杠杆，两头都撬：每一行都会传到每一次运行里，有用的和多余的一样。
你可以量一量自己的文件。挑五个智能体最近做过的任务，在代码库的副本上，带文件跑一遍，不带文件再跑一遍，每种跑几次，因为每次结果会有出入。比一比测试过没过、走了多少步、花了多少钱。然后读一读，运行时真正照着做的是哪几行。
你多等的那一通电话
假设你带一个六人的团队，大家在等你定下用哪家支付服务商。两家差不多，你想再和两边各通一次电话，电话约在下周。
工程师们没有停下。两个人做了一层适配，好让代码两家都能接；第三个人给两家都写了测试数据。没人说这是白干，因为没人知道哪一半是白干。
九天后，你选了第一天就倾向的那家。那两通电话什么也没改变。适配层如今只包着一家服务商，另一家的测试数据被整批删掉。