最有望从 AI 中获益的团队，往往是最晚部署 AI 的。一家能够利用 AI 实时发现用药错误的医疗机构，其 AI 采纳率仅为 39%；而一家运行 AI 代码审查的软件公司，采纳率高达 92%。两者的 ROI 差距悬殊——然而采纳率却完全颠倒。这就是 AI 采纳悖论，而且它绝非偶然。
人们的本能是将这种差距解释为规避风险、监管恐惧或官僚惰性。这些因素确实存在。但更深层的原因是结构性的：在高风险领域释放价值所需的准确率阈值，从根本上高于自主部署所能证明合理的水平，而大多数团队尚未构建出弥合这一差距的架构。
你的团队比以往任何时候都能发布更多代码。PR 速度提升了，周期时间缩短了，积压也在减少。在管理者看得到的每一块仪表板上，一切都看起来很好。然而，每个 PR 对应的事故数量正悄悄地以每年 23.5% 的速度攀升。
这就是 AI 代码审查的悖论。AI 工具让工程师写代码更快，审查代码也更快——但最关键的缺陷正以比以前更高的比率漏过审查。这个悖论的两面相互叠加，而大多数团队并没有在衡量正确的指标来察觉这一点。
AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。
问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。
一家金融科技公司的产品团队发布了一款基于大语言模型 (LLM) 的文档摘要生成器。他们的评估数据集包含 200 个经过人工筛选并附带人工评分的示例，质量得分达到 87%。在生产环境中，当用户上传短备忘录时，系统偶尔会返回比原始文档更长的摘要。评估数据集中没有任何篇幅少于 300 字的备忘录。而“对于摘要任务，输出长度 ≤ 输入长度”这一属性从未被测试过。直到一位客户截下了这个荒唐的界面并将其发布到网上，才有人察觉到这个问题。
这就是属性测试 (Property-Based Testing, PBT) 所填补的核心空白。评估数据集衡量的是你“想到的”测试场景中的准确性。而属性测试衡量的则是，在所有可能发生的情况中，你的系统是否始终遵守了预定义的契约。
一个人如何用自主 AI Agent 替代了一个 15 人的工程团队——以及这一路上的惨痛失败。
本文内容为休斯顿大学 CIVE 7397 课程客座讲座材料。衷心感谢 张汝达教授 的邀请，以及 吕海 分享的诸多想法，正是这些启发塑造了本次讲座。
我大学没学过计算机。我在北京读的是管理专业。不知怎么地，我最后去了耶鲁读计算机硕士，然后去了 Uber 开发服务 9000 万用户的系统，接着又去了 Brex 和 Airbnb，最终创办了自己的公司。
我告诉你这些是因为谁能开发软件的游戏规则正在被重写——而你的背景可能比你想象中更有优势。
每个工程师的起点都一样。空白的编辑器。闪烁的光标。一个写着“开发订阅计费系统”的任务。
一位资深工程师——有着十年经验的人——每天大约产出 100 到 150 行生产环境代码。剩下的时间都花在了会议、代码审查、调试和上下文切换上。这就是天花板。
“10x 工程师”是我们追逐的神话。但即使是 10x 工程师也依然只有一个人。生产力随人数线性增长。想交付得更快？那就招更多的人——而每招一个人都需要三到六个月的入职培训。
最糟糕的部分是什么？知识只存在于人们的脑子里。为什么那个系统要那样设计？去问 Chen。哦，Chen 离职了。祝你好运。
在 Uber，任何任务最难的部分从来不是写代码。而是调研阶段——弄清楚哪里需要改，以及改什么。
当代码库极其庞大、文档缺失，而前任负责人已经离职时，你会花费 80% 的时间来建立对他人的系统的心理模型。瓶颈始终是人——他们的可用性、他们的上下文窗口、他们的单点故障风险（Bus Factor）。而不是算力。也不是想法。
然后，有些东西出现在了工作室门口。
你发现了 Copilot。接着是 Cursor。然后是 Windsurf。按下 Tab 键，整个函数就凭空出现了。这就像是在经历了多年的手动练级后，有人递给了你一颗“神奇糖果”（Rare Candy）。
这种提升是真实存在的——我们现在有了实地研究：
但即使有了这些提升，**天花板依然是你。**你砍柴的速度变快了，但你并没有建立起一家工厂。你依然是那个阅读规格说明、做决定、在凌晨两点调试代码的人。
神奇糖果强化的是你。它并没有给 你一只宝可梦。而打破天花板的唯一方法，就是彻底把自己从生产线中抽离出来。
就在这一刻，一切都改变了——而且它简单得令人难以置信。
你写一个规格说明。不是代码，而是规格说明（spec）。验收标准、约束条件、边界情况。你把它交给像 Claude Code 这样的自主 Agent。然后你走开。
Agent 读取你的代码库，规划方案，编写代码，运行测试，读取错误，修复错误，循环往复。等你回来时，一个 Pull Request 已经准备好了。你刚刚收服了你的第一只宝可梦。
这与 Cursor 或 Copilot 有着本质的区别。那些是电动工具——它们增强你的产出。而自主 Agent 是一个独立的劳动力。核心技能从提示词工程（Prompt Engineering）转向了上下文工程（Context Engineering）：设计你的宝可梦所运行的世界。
我总是从“计划模式”（Plan Mode）开始。Agent 分析代码库并提出方案。我审查方案，进行调整，然后说“执行”。
我有一条从不打破的原则：“你自己去调试。我只要结果。” Agent 必须自己 curl API、阅读日志，并编写测试来证明自己的工作。如果它无法自我验证，说明规格说明写得不够好。
你已经收服了第一只宝可梦。你该如何让它变强？
Anthropic 官方指南指出，Agent 的质量与其说取决于模型本身，不如说取决于其上下文的结构和管理方式。模型是引擎。而上下文——规格说明、代码库结构、反馈信号——则是技能书。你教给它什么，决定了它的战斗力。
三种输入至关重要：
你的 Pokémon 编写了代码。代码编译通过。你感觉棒极了。
然后你运行了测试。一半失败了。代理幻觉出了一个不存在的 API 端点，使用了一个已弃用的库，并引入了一个微妙的竞态条件。
这是核心挑战： 没有质量控制的 Pokémon 会规模化地制造缺陷。你构建的最重要的东西不是生产系统 —— 而是质检线。
代理在一个紧密的循环中运作：编写 → 测试 → 失败 → 读取错误 → 修复 → 重复，直到每一项检查都变成绿色。神奇之处不在于第一次尝试就能得到完美的输出 —— 它永远做不到这一点。神奇之处在于反馈循环是在几秒钟内运行的，而不是几小时。
我在实践中的质检线：
从代理中获得真正价值的团队并不是那些拥有最好模型的团队。而是那些拥有最严密质检线的团队。
一只 Pokémon 处理一个有边界的任务。真实的软件项目有许多移动部件。你需要一个阵容 —— 而为了让阵容协同工作，你需要共享的工具集和共享的剧本。
MCP（模型上下文协议） 就是道具包。任何 Pokémon 都可以伸手进去拿取任何工具、任何 API、任何数据源。它给了你的代理一双手。
CLAUDE.md 和自定义技能 是训练师手册。自定义斜杠命令 —— /today、/blog、/ci —— 编码了可重复的组合招式。CLAUDE.md 是每个代理在启动时都会阅读的规则手册：相同的上下文，相同的标准，不需要时刻盯着。
正如 Anthropic 所建议的：寻找尽可能简单的解决方案，只有在需要时才增加复杂性。
你的阵容已经集结完毕。一切都在运行。在白板上看起来很完美。然后，它崩溃了。
最危险的失败不是响亮的失败 —— 而是静默的失败。
我曾有一个编程代理所做的修改通过了所有现有测试，在代码审查中看起来很正确，并发布了。几天后，我发现它破坏了一个任何测试都没有覆盖的微妙不变量。没有错误日志。没有崩溃。只是错误的行为，花了几天时间才追溯到代理的提交记录。
那是噩梦般的场景：一个 Pokémon 产生了 通过了质检 的缺陷工作。你的质检线存在盲点，而代理会找到每一个盲点。
这不仅仅是我的经验。一项 NeurIPS 2025 的研究分析了跨越七个多代理框架的 1,600 个执行追踪，发现：
在遭遇挫折后的直觉是：“我需要更多代理。” 这种直觉是错误的。
Google DeepMind 和 MIT 对此进行了严格测试 —— 180 种配置、5 种架构、3 个模型家族：
教训是：不要增加 Pokémon 的数量。要增加 正确 的 Pokémon。
盲目的乐观已经消失。取而代之的是：来之不易的知识。
SWE-Bench 排行榜评估了 80 种独特的代理编程方法，发现没有单一架构能始终获胜。但有四个原则屹立不倒：
关于成本的一个实用说明：你不需要一大笔钱来开始。Claude.ai 免费层、GitHub Copilot 学生计划和 Cursor 免费层能让你走得很远。我通过 CLI 到 API 代理，在多个每月 200 美元的订阅上运行我的整个操作 —— 成本大约是直接调用 API 的 1/7 到 1/10。
这不是比喻。这是我今天的真实配置：
yarn blog loop 24/7 全天候产出 SEO 内容。这是典型的一天是如何运作的：
/today。一个代理审查我的 TODO.md，检查进度，并提出优先事项。运行这套系统两年后，我总结了六条原则。每一条都源自惨痛的教训：
这是一个令人不安的事实。Google 关于软件交付的年度研究——DORA 2025 报告发现，虽然 80% 的个人开发者表示 AI 提高了生产力，但组织的交付指标却没有显示出任何改善。 AI 放大的是现有的质量。宝可梦（Pok émon）无法修正策略。
宝可梦处理的是琐碎的商品化工作：样板代码、测试、需求转代码、文档、定义明确的 bug。这些东西的成本正在迅速下降。
训练师（trainer）处理的是困难的部分：定义构建什么以及为什么构建。设计可测试的系统。编写值得转化的需求文档。在不确定性下做出架构决策。
拥有 CS 背景的人在面对智能体能力的边界时往往趋于保守。他们对什么是“难点”了解得太多，所以会自我审查。“智能体不可能处理分布式事务。”他们甚至从不尝试。
非 CS 背景的人则发挥想象力。他们会说“如果我直接让它这么做呢？”然后发现成功的几率远比专家预期的要高。他们不断突破边界，因为他们不知道边界在哪里。
那就是我。我不知道什么是“理应”困难的，所以我尝试了一切。这就是为什么我构建了一套比我有十年经验的人都没尝试过的系统。
这篇文章中的一切都指向一个更大的目标——软件构建方式的根本性转变。
将 AI 作为“高级自动补全”使用，就像给蒸汽机装上电动机。你会获得多一点动力，但你仍受困于旧的架构。真正的革命是彻底拆除蒸汽机。
支柱 1：AI 优先设计。 停止询问“AI 如何帮助我的工作流？”开始询问“我可以消除哪些障碍，以便让 AI 独立完成工作？”这种心态区分了获得 2 倍收益的训练师和获得 100 倍收益的训练师。
支柱 2：闭环迭代。 将人类从执行环中移除。让 AI 在拥有完整环境访问权限的情况下自主迭代。将可靠的自主性从几分钟延长到几小时是价值万亿美金的问题——每一次提升都能让一个人所能构建的东西产生指数级的增长。
支柱 3：治理工程 (Harness engineering)。 人类定义边界。将架构解耦为最小组件。使用多智能体交叉验证。你不是在写代码——你是在设计保持系统诚信的治理框架。
这些是讲座结束后，学生和从业者提出的真实问题。
问：你的实际机器配置是什么样的？需要高性能服务器吗？
完全不需要。我在 Mac 上本地运行 Claude Code——它通过 API 与 Anthropic 的云端通信，重计算都在云端完成。为了隔离和沙箱化（防止智能体意外影响主环境），我也会在 Cloudflare 沙箱中运行 Claude Code。本地机器用于交互式工作，沙箱环境用于任何需要控制爆炸半径的任务。
问：你说用 Claude Code 处理一切数字工作，真的是所有事吗？
是的。代码、博客文章、社交内容、邮件草稿、数据分析、日程规划、客服模板。只要是有明确输出标准的数字工作，我都会先尝试用智能体处理。在手动做任何事情之前，我会问自己："我能用一段话写出这个任务的规格说明吗？"如果能——先试试智能体。
问：你怎么让智能体 24/7 不间断运行，又不需要时刻盯着？
无限循环：一个 bash 循环调用 Claude 斜杠命令，检查退出条件，然后重新运行。工作流的每个阶段都有自己的技能——/brainstorm（头脑风暴）、/research（调研）、/write（写作）、/polish（润色）、/validate（验证）、/publish（发布）。当每个技能都足够稳定且能自我验证时，就可以串联起来。链条上每一环都可靠，整条链就能持续运转。这就是五个写作智能体能够全天候产出内容的原理。
关键洞察：你运行的不是一个漫长的智能体会话，而是许多短小的、可组合的、可检查的步骤。步骤越短，失败半径越小。
问：长时间运行的智能体难道不会超时或跑偏吗？
确实会 ，这正是为什么我要并行运行多个智能体。任何一个智能体在复杂任务上可能需要 20 到 40 分钟，或者撞上上下文限制，或者在意外错误上卡住。并行运行意味着一个卡住不会阻塞全局。我把智能体当成队列里的异步 worker，而不是同步函数调用。
问：你如何区分处理常规任务和复杂任务？
常规任务用斜杠命令。/ci、/blog、/today、/commit——这些命令一次性编码了完整的上下文、工具和验收标准。调用时零边际思考成本。技能即规格说明。
复杂或全新的任务由我亲自指挥：写规格说明、审查方案、批准思路，然后让智能体执行。我只负责构建什么以及为什么——而不是怎么构建。
问：每个月实际花多少钱？
一个人全职运行 10 个以上智能体，每月不超过 1,000 美元。我使用订阅制访问（Claude Max 及类似档位），而非按 token 付费的原始 API——成本大约是后者的 1/7 到 1/10。相比之下，一名初级工程师每月全成本 8,000 到 12,000 美元。经济账根本不在一个量级。
问：什么时候用 API，什么时候用聊天/智能体产品？
API 用于定义明确、高频率、程序化的任务：翻译流水线、结构化数据提取、我能完全控制调用的内容转换。可预测、可审计、可组合。
聊天/智能体（Claude.ai、Claude Code）用于复杂、开放性的任务：架构决策、调试新问题、需要判断力的写作。智能体需要在模糊中导航、读取上下文、调用工具——这才是编排层真正发挥价值的地方。
经验法则：如果我能把完整提示词写成模板且没有意外，用 API。如果任务需要智能体自己判断下一步做什么，用智能体产品。
问：多迭代几次结果一定更好吗？
不一定——很多人在这里踩坑。更多轮次不自动等于更好的输出。关键是每一轮都有清晰、不同的目标：起草 → 事实核查 → 语气 → 结构 → 终稿。没有方向的"再来一遍"循环往往会回归平均水平。每个阶段有明确验收标准的定向、可检查的步骤——这才是质量复利的来源。
目标是每个阶段投入常规精力，而非马拉松式会话。可靠、可检查、可重复，胜过野心勃勃却难以预测。
问：应该在什么基础上构建智能体？一切变化这么快，怎么选？
是的，一切都在变化——而这正是策略所在。我的假设：市场上的模型和智能体每个季度都在变强。你构建在更强基础之上的一切，会免费跟着变强。
这意味着：不要押注于那些抽象远离前沿的工作流编排引擎（n8n、LangChain）。它们在设计上就落后于最新技术。相反，在前沿智能体之上构建技能和封装层：Claude Code、Gemini CLI、OpenCode。当底层模型提升，你的封装层自动继承收益。
构建薄层，靠近前沿。避免把你锁死在昨天能力上的框架。
问：智能体行业竞争极其激烈，怎么脱颖而出？
不要在智能体本身上竞争——在你能带来的独特优势上竞争。
我看到三种有效模式：
研究者和学者：你的优势是声誉和学术公信力。构建能放大你研究影响力的智能体——让你以 10 倍速度发表、综合和协作的工具。智能体放大的是一个花了多年建立起来的品牌。
领域专家：你了解通用模型所不了解的行业知识。用智能体分析患者流程的外科医生，自动化采购决策的供应链专家——智能体是放大器，领域知识是护城河。在你的垂直领域比任何人解决得都好。
KOL 产品：如果你已经拥有大量忠实受众——比如 Cuely 依靠高流量公众关注度构建的 GTM 策略——分发渠道就是护城河。智能体产品成为你已建立信任的漏斗。公开构建，向已经关注你的受众交付。
智能体是商品。你带来的独特资产，才是防御壁垒。
你最初是一个孤军奋战的苦力——只有你和一个闪烁的光标。你得到了神奇糖果（Rare Candy），事情变得快了一些，但天花板依然是你自己。你捕捉了你的第一只宝可梦，学习了上下文工程，建立了检查线，组建了一支队伍——然后目睹了它的惨败。
然后你重建了它。更聪明。带着约束。带着辛辛苦苦换来的原则。
宝可梦会持续变强——每个季度都会有新的模型、新的协议、新的框架。但那个设计系统、决定构建什么、如何检查以及何时发布的人——那个人不会被自动化取代。
那个人可以是你。
今晚：挑选一个项目。写一页需求文档。把它交给 Claude Code。查看返回的结果。
你刚刚捕捉到了你的第一只宝可梦。
AI 编程代理最危险的误解是，它们让你放松工程纪律。实际上恰恰相反。代理系统会放大你已拥有的一切：坚实的基础产生速度，薄弱的基础则以机器般的速度制造混乱。
值得关注的转变不是代理为你编写代码。而是约束条件发生了变化。编写代码不再是昂贵的部分。这几乎改变了你构建流程的一切。
一个团队在采用 AI 编程智能体（AI coding agents）后，交付的拉取请求（PR）增加了 98%。这听起来像是一个成功的故事——直到你注意到评审时间增长了 91%，PR 的规模膨胀了 154%。代码交付的速度超过了任何人的验证能力。
这就是 80% 问题。AI 编程智能体非常擅长生成看起来似懂非懂（plausible-looking）的代码。当剩下的 20% 需要架构判断、边缘情况意识或任何比“编译通过了吗？”更复杂的反馈循环时，它们就会陷入停滞或悄然失败。在编程智能体上取得成功的团队，并不是那些提示词（prompt）写得最激进的团队，而是那些构建了更好的反馈循环、更短的上下文窗口（context windows）和更严谨的工作流的团队。
问问任何一个交付过真实智能体（agentic）系统的团队，最难的部分是什么。几乎没有人会说是 “LLM 调用”。无论是 Claude Code、Cursor，还是自研的财务自动化工具，每个生产环境中的智能体运行的核心循环几乎都是一模一样的。有趣的工程挑战 —— 即区分一个好用的智能体与一个失控的成本中心的部分 —— 完全存在于那个循环之外。
一个团队最初运行智能体循环的费用是每周 127 美元。四周后，账单达到了 47,000 美元。一个没有 token 上限的失控循环将每一次迭代复合成了财务灾难。模型一直在运行，没人告诉它停止。
大多数AI智能体项目失败，并非因为模型能力不足——而是因为构建这些系统的工程师在尚未积累足够经验时就急于引入复杂性。通过对数十个生产环境部署案例的深入研究，一个清晰的规律浮现出来：那些成功落地可靠智能体的团队，都从最简单的系统出发，只有在指标数据确实需要时才增加复杂度。
本文将系统梳理那些能将稳健智能体系统与容易幻觉、陷入循环、在真实负载下崩溃的系统区分开来的核心思维模型、架构模式和实践技巧。
G. Pascal Zachary的《观止》（Showstopper!）不仅仅是一本书，它是一座纪念碑，记录了软件开发史上最宏大、最艰巨的工程之一——Windows NT的诞生。这部著作将我们带入了一场改变计算机世界的“战争”的中心，将一群天才工程师的智慧、汗水、矛盾与荣耀栩栩如生地呈现在读者面前。
故事的帷幕在一位传奇人物——Windows NT项目的灵魂人物大卫·卡特勒（Dave Cutler）——的身上拉开。他的成长与磨砺，为整部史诗奠定了坚实的基础。卡特勒出身于密歇根州的一个工人家庭，逆境塑造了他独立而坚毅的性格。少年时代，他在体育场上初露锋芒，展现出非凡的领导才能和永不服输的好胜心，队友们对他的评价极高，认为“只有他自己才可能与他匹敌”。然而，大学时一场严重的腿伤终结了他的橄榄球生涯，迫使他将全部精力转向学业。正是在这里，他在数学和工程领域的天赋开始闪耀。
毕业后，卡特勒投身于新兴的计算机编程领域，并在数字设备公司（DEC）迅速声名鹊起。他为经典的PDP-11小型机开发的实时操作系统，已显露出他在系统架构上的过人之处。不久，他便被委以重任，领导DEC新一代32位系统VAX/VMS的开发。VMS的巨大成功，为他赢得了“世界上最出色的操作系统编写者”的美誉。然而，盛名之下的卡特勒却在DEC后期日益僵化的官僚作风中备感沮丧。当他倾注心血主持的下一代计算机项目Prism/Mica被公司高层无情取消时，这位桀骜不驯的天才愤然离职。
卡特勒的才华早已引起了另一位行业巨擘——比尔·盖茨的注意。早在1983年，DEC的高管戈登·贝尔就曾将卡特勒介绍给盖茨，为未来的合作埋下了种子。1988年，Prism项目被砍的消息传出后，盖茨亲自出马，力邀卡特 勒加盟微软。他交给卡特勒一个使命：启动一个代号为“NT”（New Technology的缩写）的全新操作系统项目。卡特勒的经验、斗志和在操作系统领域的卓绝才干，正是微软敢于押注下一代操作系统的关键所在，也为后续波澜壮阔的NT开发故事埋下了最重要的伏笔。
与此同时，在微软帝国的心脏地带，另一位“代码之王”——比尔·盖茨——正酝酿着一场将改变行业格局的风暴。从他的视角，我们得以窥见微软在1980年代末的战略雄心以及NT项目诞生的宏观背景。与卡特勒的工人家庭背景不同，盖茨出生于富裕之家，从小就表现出超凡的智慧和叛逆精神。少年时代，他与保罗·艾伦一同痴迷于计算机编程，敏锐地嗅到了软件商业化的巨大机遇。他们为Altair 8800微型机开发的BASIC语言解释器，不仅是微软的创业之作，也开启了个人电脑软件的商业时代。
到80年代中期，微软凭借MS-DOS和初代的Windows系统，已在PC市场奠定了霸主地位。但盖茨清醒地认识到，这些基于16位架构的系统，其局限性将很快无法满足未来的计算需求。他敏锐地预见到，一个“面向21世纪”的全新操作系统势在必行，它必须具备高可靠性、强大的多任务能力和跨平台的可移植性，才能在未来的企业级和个人计算领域重新定义标准。
当时，微软正与IBM合作开发OS/2系统，但项目进展缓慢且市场反响平平。OS/2缺乏对海量DOS和Windows应用的良好兼容，图形界面也未达到预期，令盖茨日益失望。他不愿与IBM公开决裂，却在暗中筹划着自己的“B计划”——这正是NT的真正起点。1988年前 后，盖茨决心另起炉灶。他与时任战略副总裁的内森·麦沃尔德（Nathan Myhrvold）等人共同确立了新系统的愿景，并最终将目光锁定在因Prism项目受挫而离开DEC的卡特勒身上。盖茨以开发OS/2改进版本的名义，成功将卡特勒招至麾下，实则让他着手开发一个全新的、可移植的操作系统。
盖茨被刻画为一位既有顶尖技术直觉，又具备非凡商业远见的战略家。他对NT项目高达5年时间、15亿美元的投入承诺，体现了他对未来技术下注的魄力。盖茨识人用人的眼光，以及他所倡导的**“聪明人治国”**的独特工程文化——即招揽全世界最顶尖的才智之士来攻克最艰难的技术难题——为NT项目的启动提供了决定性的支持。正是盖茨的远见和微软强大的资源，为卡特勒和他的团队提供了施展才华的舞台。
卡特勒的空降，在微软内部引发了一场不小的震动。他并非孤身一人，而是携着一支忠诚的“编程部落”入驻微软，随之而来的是剧烈的文化碰撞与严峻的团队融合挑战。卡特勒加盟的消息一出，他在DEC西雅图实验室的众多旧部纷纷响应。不到一周，七位顶尖的DEC程序员便追随他加入了微软，构成了NT项目的核心班底。这支“DEC部落”几乎清一色是经验丰富的男性工程师，平均年龄远高于典型的微软员工，他们紧密团结，自成一体。
团队到岗的第一天，就爆发了著名的**“入职风波”**。微软要求新员工签署一份包含苛刻竞业禁止条款的合同。卡特勒的部下们认为这极不公平——如果DEC也有此条款，他们根本无法跳槽到微软。于是，他们集体拒签，并以“罢工”的形式离场 去吃午饭。卡特勒闻讯后亲自出面交涉，凭借其强硬态度迫使微软法务部门做出了让步，删除了不合理的条款。这一插曲迅速传遍微软园区，也让所有人见识到了这个“部落”不妥协的行事风格。
“部落”之名恰如其分。他们在二号楼占据了一整个走廊，工作方式步调一致，与微软原有的文化格格不入。由于年龄和背景的悬殊，这群DEC“叛将”与年轻的微软员工之间摩擦不断。他们自视甚高，嘲讽微软的年轻同事为“微废人”（Microsoft Weenies），认为自己带来的才是真正的工程艺术。反过来，微软内部也对这群抱团排外、目中无人的新人充满戒备。卡特勒本人虽对这种紧张气氛一笑置之，但也感受到了融入微软的困难，他一度感慨：“我在这边没有威信。”
然而，微软高层迅速采取了高超的**“部落整合”策略**。时任系统软件部门负责人的史蒂夫·鲍尔默（Steve Ballmer）扮演了卡特勒“导师”的角色。比尔·盖茨亲自将微软内部资深的程序员史蒂夫·伍德（Steve Wood）调入NT团队，作为连接新旧文化的桥梁。同时，鲍尔默巧妙地任命保罗·马瑞兹（Paul Maritz）负责OS/2相关事务，避免他与卡特勒直接冲突，又让他能在外围提供支持。
尽管初期困难重重，卡特勒和他的“部落”很快开始描绘Windows NT的宏伟蓝图。他们确立了三大核心目标：可移植性、可靠性和灵活性。为了实现可移植性，团队决定采用C语言编写内核，并设计一个硬件抽象层（HAL）来屏蔽底层CPU的差异。为达到“防弹”级别的可靠性，他们采用了微内核架构，将各个功能模块隔离，防止单个应用崩溃导致整个系统瘫痪。为了灵活性，NT被设计为一个模块化的、支持多种“个性”（Personality）的系统，通过不同的子系统来兼容OS/2、POSIX乃至未来的Windows应用 。这些在当时极为超前的技术决策，标志着Windows NT这艘巨轮，在克服了初期的文化阵痛后，正式启航。
项目进入开发中期，一系列重大的挑战接踵而至，NT团队一度仿佛驶入了“死胡同”，面临着内部矛盾、技术瓶颈和关键的战略转折。首先，微软内部形成了**“双线作战”**的紧张局面：一边是卡特勒团队从零开始构建全新的NT内核，另一边是传统的Windows团队在既有的DOS内核上继续迭代Windows 3.x。两支团队在资源、人才和公司高层的关注度上展开了激烈的竞争，政治博弈暗流涌动。
一个核心争议点在于向后兼容性。鲍尔默等高管反复强调，NT必须能够运行现有的OS/2、DOS及Windows程序，否则将无法赢得市场。但卡特勒起初对此极为抵触，他固执地认为，既然是全新的系统，就应该彻底抛弃过去的包袱。他那句“与DOS兼容？与Windows兼容？没有人会想要那个”的名言，让管理层捏了一把冷汗。这种对理想架构的偏执，一度使项目陷入脱离市场现实的危险。
技术上的挑战同样严峻。NT创新的微内核架构虽然带来了模块化和高可靠性的优势，但也引发了性能上的巨大担忧。客户/服务器式的子系统调用模式，不可避免地增加了系统开销。比尔·盖茨在第一次听取汇报时，就凭其敏锐的技术直觉断言：“这样会有巨大的额外开销……我认为我们不能这么做。”他深知，如果NT的速度过慢，必将被市场和媒体“钉死”。为了说服老板，卡特勒团队据理力争，提交了长达十二页的分析报告，用数据证明性能是可控的。盖茨最终勉强同意了方案，但疑虑并未消 除。
与此同时，NT工程的规模远超预期，卡特勒钟爱的小团队模式已难以为继。在微软的坚持下，团队规模最终扩充至近200人，迫使卡特勒不得不调整管理风格，接受大团队协作的现实。
而将NT项目从“死胡同”中拯救出来的，是一个决定性的外部事件：1990年，微软与IBM在OS/2上的合作彻底破裂。这一决裂标志着微软战略的重大转向，公司决心将全部赌注押在自己的Windows NT上。NT团队的使命也随之发生了根本性改变：其开发重点从兼容OS/2 API，转向了全面兼容并超越Windows。因为就在那一年，Windows 3.0取得了空前的商业成功。微软意识到，NT的未来必须与Windows紧密相连。正如麦沃尔德所言：“客户需要一座桥。”于是，团队开始了艰苦卓绝的“跑道切换”，将Windows的API扩展为32位，并重写了整个图形子系统。尽管困难重重，他们最终还是**“让它跑起来了”**，成功实现了对旧有Windows应用的兼容。这次关键的重定向，使Windows NT摆脱了迷航，找到了通往未来的正确航向。
随着项目进入快车道，压力也骤然升级。团队的工作状态变得紧张而激烈，充满了情绪的碰撞和咆哮，正如“嗥叫的熊”这一比喻所描绘的那样。在微软，盖茨和鲍尔默坚持**“优秀的程序员才能当经理”**的理念，要求管理者必须亲力亲为，不能脱离一线的编码工作。这使得NT项目的经理们既要统筹规划，又要深入代码细节，承担着双重负荷。
在这种高压环境下，卡特勒火爆的脾气和严苛的要求更是将团队逼到了极限。他对任何未达标的工作都毫不留情地斥责， 他那句著名的狠话——“你们的屁股就是青草，我就是割草机”——让每个下属都绷紧了神经。然而，正是这种不近人情的严苛，锻造了团队强大的纪律性和执行力。随着项目的推进，卡特勒自身也在发生转变，他开始学会在高压之余给予团队肯定和激励，逐渐从一个独断的专家成长为一位真正的技术领袖。
与此同时，NT团队与Windows阵营的融合也在加深。原Windows图形部门的查克·维特莫（Chuck Whitmer）等人加入了NT图形系统的重写工作；莫申·唐尼（Moshe Dunie）出任首席测试官，建立起一套严格的质量保证体系；罗伯特·穆格利亚（Robert Muglia）作为项目经理的加入，则加强了技术团队与市场需求的连接。穆格利亚反复强调，软件的功能取舍必须务实，要集中资源解决企业客户最关心的安全、网络和兼容性问题。
团队的文化也因融合而变得更加丰富。在高强度、以男性为主导的开发环境中，女程序员黛蕾丝·斯托威尔（Therese Stowell）以幽默的方式发起了一场别开生面的“女权运动”，为紧张的工作氛围带来了一丝轻松和反思。项目中期通过磨合与调整，NT团队凝聚成一支战斗力极强的成熟团队，为最后的冲刺做好了准备。
上桌玩牌要有足够的筹码 —— 招聘足够数量的高水平人才，这些人才要足够重视质量、足够聪明。你要向她们反复强调公司重视质量的文化，形成正式的惯例检验大块工作，该修的修。
战术上，有这样一条最佳实践 —— 降低做正确事情的难度。Stripe 技术团队做出了各种各样的取舍，以便能够保证任何工程师都能够改进系统的任何部分。鼓励责任感（ownership）。
有专门的内部工具检查国际化的水平，很无聊，但是得花时间做。要注意，这又回到了公司的文化问题，当一个做这件事情的 IC 说：“我上周花了一些时间做 i18n ” 的时候，他应该会默认，领导层足够重视这件事情，以至于会回答说：“当然你花了时间做了这件事情，棒棒哒。”
“开个工单给相应的组，会有相应的人来处理” 是个好实践，但是如果你能够推动这个系统更快更好地把这个工单修掉，你就更能够激励人去开工单。
公司会给专门的途径，比如邮件组的别名，来上报产品的质量 bug。有专门的组来 triage 这些任务，或者把任务分配到合适的组来修，有专门的惯例告诉整个公司质量 bug 的修复速率。
在做重大 API 变化之前，既要做内部测试，也要做外部测试。经常 问一下“谁有一个真真正正的 Stripe 账号在手头？能不能更新到 beta 版本试一下？” 人们需要专门抽出时间来做这件事情，并且详尽地记录下来形成文档 —— 想象一下，你有一群挑三拣四的客户，虽然你很可能无法像用户那样深入地、广泛地使用自家的产品，但是这样做已经比瞎猜要好很多了。
发现“一块支付代码 5 年没有碰过了，不知道它是怎么工作的，竟然没有测试”，这种情况虽然很少见，但是对于工程团队来说，是宝贵的财富。
以上所有都不是什么高科技，也都不是能够保证质量的充分条件。Stripe 从来都不会满足当下的质量水平，不会被动地说说“我们的标准很高”，而是保持“主动地一直在去做”。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建 自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
