重读《人件》：
AI 越强，软件开发越是一场关于人的战争

AI 改变了软件生产的速度，却没有改变《人件》揭示的事实：软件项目最复杂的部分，从来不是代码，而是置身其中的人。

第一部分 · 被工具掩盖的人

01为什么今天应该重新阅读《人件》

第一次读《人件》时，我把它当作一本讲软件团队管理的书。书里那些问题都很具体：嘈杂的办公室、频繁的会议、不合理的工期、人员流动、团队凝聚力，以及管理者如何在不知不觉中毁掉一支原本优秀的团队。

AI 编程工具普及之后再读，我才意识到，Tom DeMarco 和 Timothy Lister 真正在追问的并不是办公桌应该怎样摆，而是一个更根本的问题：软件开发的主要瓶颈，究竟是技术，还是人？

过去，我们很容易把效率问题理解为“程序员写得不够快”。于是行业不断发明更高级的语言、更强的框架、更完善的 IDE、更自动化的流水线。今天，AI 又把这条路推到了新的极限：一个开发者可以同时让多个 Agent 搜索仓库、修改代码、生成测试、分析日志和更新文档。几天的实现工作，几小时就能看到候选结果。

可是，项目并没有因此获得无限速度。需求仍然会含糊，系统仍然有历史，边界仍然需要取舍，发布仍然可能失败，责任也仍然要落到具体的人身上。《人件》第三版在 2013 年更新时仍把软件开发的核心挑战概括为“人的问题，而非技术问题”；到了 Agent 时代，这个判断没有变弱，反而变得更锋利。^[1]

当执行变得便宜，定义、判断、验证与承担后果就会显得更昂贵。AI 没有消灭人的瓶颈，它只是把瓶颈从键盘前移到了决策链。

02瓶颈没有消失，只是换了位置

在传统开发里，最显眼的稀缺资源是实现时间。产品排期往往围绕“写完需要多久”展开。AI 降低了这部分成本，却没有按相同比例降低其他成本：理解需求、选择方案、评审变更、核对业务规则、证明安全性、处理迁移、观察上线结果，以及在事故发生时恢复系统。

于是，成本开始向下游移动。过去可能是四小时编码、一小时检查；现在也许是十分钟生成、两小时理解和验证。前者的等待发生在生产之前，后者的拥堵发生在生产之后。只看生成阶段，会觉得速度提高了几十倍；看完整价值流，提升可能很小，甚至变成返工。

2025 年 DORA 的 AI 辅助软件开发研究把这种现象描述为系统问题：AI 会放大团队和交付系统里已经存在的条件。强平台、松耦合架构、快速反馈能吸收更高的变更量；薄弱测试、缓慢流程和紧耦合系统则会把更高产出转化为不稳定。^[6]

这正是重读《人件》的起点：不要把工具的局部速度，误认成组织的整体生产力。

第二部分 · 注意力成为新的生产线

03AI 消除了等待，却制造了更多打断

《人件》中最经久不衰的主题之一，是不被打断的工作时间。对于程序员、设计师和架构师，高质量产出通常不在零散空隙里发生。问题背景、代码结构、业务约束和设计选项需要被同时装进大脑，经过一段连续时间，才会形成足以工作的心智模型。

进入状态可能要十五分钟，也可能要半小时。一条消息看似只占两分钟，真正损失的却是完整认知现场。心理学中的任务切换研究也反复观察到切换成本：人需要移动目标、重新激活规则，而规则越复杂，切换代价越高。^[2]

传统开发的打断大多来自人：产品经理问进度，测试人员反馈问题，领导临时拉会，同事请求协助。AI 时代，打断开始大量来自机器。

一个开发者同时运行三个、五个甚至更多 Agent：一个重构后端，一个生成前端，一个补测试，另一个分析生产日志。它们不断返回结果、提出问题、申请权限、报告失败或等待确认。于是开发者不再持续写一件事，而是在多个认知现场之间来回跳转：

• 检查 Agent A 修改了哪些文件，是否越过任务边界；
• 判断 Agent B 的测试失败来自代码还是环境；
• 回忆 Agent C 采用了哪条方案、放弃了哪些假设；
• 阻止 Agent D 顺手重构并不属于本次任务的模块；
• 把相互独立的输出重新合并进同一个系统上下文。

程序员从代码生产者变成了并发任务调度器。问题是，Agent 可以并行运行，人的理解、判断和责任承担仍然主要是串行的。

这解释了一种很有时代特征的疲劳：一天里没有持续敲键盘，身体看起来也没有高强度劳动，人却异常疲惫。真正消耗他的，是不停重建上下文、判断例外和关闭认知回路。

04真正稀缺的不是代码，而是高质量注意力

AI 编程最容易带来的误判，是把“实现成本下降”理解成“所有成本都下降”。实际上，当上游代码生成能力大幅增加，评审、测试、集成和决策会成为新的排队点。

代码可以并行生成，评审不能无限并行；方案可以批量产生，团队仍要逐个取舍；测试可以自动执行，失败原因仍需被理解；Agent 可以不断重试，生产事故最终仍由人承担。如果每条工作流都默认把异常抛给人，人的注意力就成了所有自动化共同争抢的单线程锁。

因此，管理者不能只问“还能再增加几个 Agent”，而要问一组完全不同的问题：

如果这些问题没有答案，增加 Agent 就像在一条已经拥堵的流水线上继续提高上游速度：结果不是更高的交付效率，而是评审积压、测试爆仓、架构漂移和线上风险增加。

当生产能力变得廉价，组织更需要保护注意力，而不是继续透支注意力。

05代码增长了，团队认知却没有同步增长

传统软件管理喜欢用可统计的活动代替难以衡量的价值：代码行数、提交次数、功能数量、任务完成率和迭代速度。AI 让这些指标变得更危险。

一个 Agent 几分钟就能生成几千行代码，一次建立十几个模块，也能把一个简单问题扩展成一场结构完整的重构。如果仍用产量衡量生产力，几乎每支团队的数据都能迅速变漂亮。

但代码不是资产本身。只有被团队理解、经过验证、能够演进并确实解决用户问题的代码，才可能成为资产。否则，AI 生成得越快，团队积累的不是能力，而是认知负债。

开发者亲手写代码时，通常经历过为什么这样设计、哪些边界最危险、哪些方案被放弃。就算文档不完整，这些决策至少曾进入某个人的思考。AI 生成的代码则可能绕过这个认知形成过程，直接进入仓库：它能运行、能通过测试，甚至更整洁，但团队中没有人真正拥有它。

这会产生一种项目幻觉：功能完成了，演示能运行，仓库也在增长；工程师面对的却是一个越来越陌生的系统。直到线上异常、业务规则变化或跨模块重构时，组织才发现，那些快速生成的代码并没有转化为可控制的软件能力。

METR 在 2025 年对 16 名熟悉成熟开源项目的开发者做随机对照研究，覆盖 246 个真实任务。在当时特定工具与样本条件下，允许使用 AI 的开发者平均反而多花约 19% 时间，而且主观上仍认为自己变快了。研究团队明确提醒这只是早期 2025 工具和特定人群的快照；到 2026 年，后续实验又受选择偏差影响，无法给出可靠的当前速度结论。它最值得保留的启示不是“AI 让人变慢”，而是：感觉更快不能替代对完整工作流的测量。^[7][8]

第三部分 · 团队不是可压缩的容器

06心理安全不是福利，而是 AI 可靠性的一部分

《人件》反复强调，真正凝聚起来的团队不是靠管理命令组装的。它拥有信任、共同目标、身份认同和一定程度的自主权。这些条件在 AI 时代不是变得次要，而是变得更关键。

当 AI 可以完成越来越多编码工作，工程师会自然地产生不安：我的经验是否正在贬值？公司引入 AI 是为了帮助我，还是为了减少人？如果我把工作方法沉淀成 Skill 或 Agent，以后还需要我吗？AI 生成的代码出了问题，责任到底算谁的？

管理者若回避这些问题，只重复“降本增效”，成员就会开始理性地自我保护：有人隐藏工作方法，不愿让经验成为组织资产；有人表面采用 AI，实际拒绝改变；有人制造只有自己能解释的复杂性；也有人对模型输出降低责任感，觉得“反正不是我写的”。

Amy Edmondson 将团队心理安全定义为一种共同信念：在这个团队里承担人际风险是安全的。她对 51 个团队的研究发现，心理安全与学习行为相关，而学习行为又连接到团队绩效。^[3] AI 协作恰好需要更多这种风险承担——成员必须愿意说：

• “我还没有理解这段生成代码。”
• “这个结果虽然通过测试，但我不相信它覆盖了真实风险。”
• “我刚才的提示方向错了，需要推翻重来。”
• “这个任务不适合继续自动化，应该先把需求说清楚。”

如果组织不允许人说“我不知道”，AI 就会放大虚假的确定性：模型自信地给出答案，工程师不敢提出异议，管理者又急于展示成果。三种力量叠加之后，一段无人真正理解的代码便顺利通过所有人的视线。

07AI 时代的 Teamicide：团队如何被更快地摧毁

《人件》用了一个尖锐的词：Teamicide，团队自毁。很多团队不是能力不足，而是被管理方式逐渐瓦解：不现实的期限、频繁调整成员、内部竞争、过度标准化，以及用流程替代信任。

AI 又增加了几种新的自毁方式。

把工程师变成 Agent 操作员

如果管理者认为模型已经能够完成大部分技术工作，于是逐渐收走工程师的设计空间，只要求接收任务、调用模型、提交结果，短期可能提高产量，长期却会让团队失去判断能力。一个长期不需要做设计决策的人，最终也会失去做设计决策的能力。

用 AI 强化个人产量竞赛

谁生成的代码更多、谁关闭任务更快、谁同时运行的 Agent 更多——这些指标看似客观，却会推动成员追求局部产出，减少共同评审、知识共享和集体责任。SPACE 生产力框架早已指出，开发者生产力涉及满意度与福祉、绩效、活动、沟通协作、效率与流动，不能由单一活动指标替代。^[4] 当生成成本下降，活动数量与真实价值之间的距离只会更大。

不断削减人数，直到系统失去组织记忆

管理者看到部分任务可以自动完成，便推断原来十个人的工作现在只需要三个人。可那十个人承担的不只是编码，还有业务记忆、异常判断、跨部门协调、值班经验、客户语境和风险缓冲。这些能力很少出现在任务统计里，却决定团队在意外发生时能否恢复。

裁掉的可能是“看起来没有直接产出的人”，失去的却是系统最难重新生成的上下文。

08最好的 AI 团队，不是人最少的团队

AI 时代很容易产生一种极端想象：未来的软件公司只需要一个创始人，加上一群永远在线的 Agent。这种模式确实可以快速产生原型，甚至运营边界清楚的小产品。但复杂系统的长期建设仍然需要团队，因为真正困难的问题很少只是“怎样生成代码”。

复杂系统需要不同责任视角之间的碰撞。架构师关注长期演进，开发者关注实现与可读性，测试人员寻找失败路径，运维人员关注运行时行为，产品人员判断用户价值，安全人员思考正常流程之外的攻击方式。

AI 可以模拟这些角色，列出它们可能关心的问题，却很难替代真实责任带来的判断。负责生产稳定性的人，会对一次看似无害的依赖升级保持警惕；经历过资金差错的人，会本能追问幂等性；长期服务某类客户的人，知道需求文档里哪一句话才是不能妥协的约束。这些判断来自经历、责任与后果，不只是来自知识。

所以，AI 时代优秀团队的目标不应该是无限减少人数，而是把人的时间从机械实现转移到更高价值的工作：定义问题、设计边界、验证事实、处理例外、积累知识、修复系统，以及在不同利益之间做出可以被解释的取舍。

第四部分 · 为人和 Agent 共同设计环境

09管理者的新职责：重新设计工作环境

《人件》认为，管理者的主要工作不是让人们忙起来，而是创造一个让人们能够完成工作的环境。到了 AI 时代，这句话依然成立，只是“环境”的边界扩大了。

它不再只包括安静的空间、合理的会议和稳定的团队，还包括：Agent 能访问什么资源；哪些操作必须由人批准；什么结果必须自动验证；一个任务允许修改多大范围；上下文如何保存与交接；多条工作流怎样避免互相覆盖；失败后系统如何停止、回滚和恢复；谁对最终结果负责。

这些规则不能靠一句提示词解决。如果组织只是给每个人购买 AI 工具，却不重新设计开发流程，AI 最终只会成为附加在旧系统上的加速器：它让代码更快地产生，却不能让需求更清楚、决策更合理，也不会让测试、发布和恢复能力自动提升。

真正的变化，是把软件流程设计成一个人和 Agent 共同工作的运行系统：机器负责搜索、生成、重复执行和初步验证；人负责定义目标、处理模糊性、判断取舍、识别风险并承担责任。两者之间需要清晰的接口，也需要不耗尽人的节奏。

10把人的注意力当作容量，而不是免费资源

AI 工作流最常见的设计错误，是只计算模型吞吐，不计算人的吸收能力。生成一个补丁的成本可以接近零，但把它变成可信变更，需要评审时间、领域知识、测试证据和发布窗口。任何一项不足，候选结果都会排队。

这意味着，一个团队即使拥有无限 Agent，有效吞吐仍然不会超过其最薄弱的控制环节。更糟的是，过量在制品会反过来损伤理解能力：未完成的评审、等待回答的问题、并行分支和悬而未决的方案占据工作记忆，增加每次切换的恢复成本。

因此，限制并行不是落后，而是保护认知完整性的工程措施。实践中可以从几个朴素动作开始：

• 给每位工程师设置活跃 Agent 工作流上限，而不是鼓励无限并发；
• 把低置信、重复和越界结果先由自动门禁过滤，再请求人的注意；
• 要求每个 Agent 交付变更摘要、关键假设、验证证据和未覆盖风险；
• 给复杂任务保留连续、无通知的理解与评审时段；
• 测量从开始到安全上线的周期，而不是只测模型生成用时。

生产力研究也支持这种多维视角：SPACE 框架拒绝单指标，DORA 强调平台、流程、架构和价值流对 AI 效果的调节。^[4][6] 管理者真正需要优化的不是“每个人调用多少次模型”，而是团队能否以更低认知负担、更稳定的质量，把正确价值交付出去。

11六条面向 AI 团队的《人件》原则

把《人件》带进 Agent 工作流，不需要先发明一套宏大的管理体系。更有效的起点，是把对人的尊重变成具体的系统约束。

12AI 越强，《人件》越重要

《人月神话》告诉我们，软件项目不能靠增加人力获得线性加速，因为沟通与协调成本会迅速上升。《人件》进一步提醒我们：即使人数不增加，即使工具更强，只要忽视人的认知、情绪、关系和工作环境，生产力仍会崩溃。

AI 没有推翻这两本书。它只是让旧问题换了一种形式。

过去，我们担心给延期项目增加更多程序员；今天，我们要警惕给失控流程增加更多 Agent。过去，管理者用会议、报表和流程占满工程师的时间；今天，工程师可能被模型输出、权限申请、评审请求和并行任务占满注意力。过去，团队因为办公室噪声无法进入心流；今天，团队可能因为永不停歇的 AI 工作流失去完整思考。

工具越强，人越容易被看成系统里缓慢、昂贵、可以继续压缩的部分。但恰恰在这个时候，人的判断、信任、责任感和创造力变得更珍贵。AI 可以生成代码，却不能替组织决定什么值得建设；可以提供方案，却不能替团队承担选择的后果；可以模拟协作角色，却不会自动创造真正的信任。

重读《人件》之后，我最大的感受，不是“人仍然不会被 AI 替代”这种简单的乐观判断，而是一个更严肃的结论：

AI 不会自动让软件组织变得更好。它只会放大组织原本的样子。

一个信任员工、保护专注、重视质量的组织，会借助 AI 获得巨大的能力提升；一个迷信指标、透支团队、追求短期产量的组织，则会用 AI 更快地制造技术债、认知债和组织债。DORA 在 2025 年把 AI 称为“放大器”，正好给了这个判断一份当代注脚。^[5]

未来真正领先的软件团队，未必拥有最多的 Agent，也未必永远使用最强的模型。它们更可能是那些最早明白：当代码不再稀缺，真正需要保护的，是人。