如今大多数人工智能用户的工作效率提升幅度约为 10–20%，无论他们声称 AI 多么“颠覆性”，或者他们编写了多少行代码。然而，我仍然认为 2 倍甚至 10 倍以上的提升是真实存在的，也是合理的预期。真正的变革需要同时进行两项改变——个人实践和组织架构的重构。最终的成果是 10 倍的提升还是 10 倍的浪费，取决于实践本身以及与之相关的组织架构。
截至2026年，产出呈指数级增长，但实际影响呈线性增长。这篇文章将探讨在“调试”该问题时发现的一些问题，并将观察结果和建议归纳为两大类：
• 个人挑战与优化实践 • 组织挑战与优化实践
一、个人挑战与优化实践
挑战 1：你不进行左移操作，所以你不了解你交付的是什么。
人工智能消除了过去迫使人们进行规划的摩擦。如果没有人对糟糕的抽象进行制约，前期思考就会被悄悄地跳过。你交付的系统无法调试或扩展，到处都是人工智能悄悄填补的空白。首先要制定大纲：标题、结构、受众、计划、原则、最终效果图，然后再让人工智能填充细节。审查流程也应该向前推进：从逐行审查改为对比计划结果。质疑应该在规划阶段进行：在允许任何程序生成之前，先生成子智能体作为“红队”来审查计划。最后的审查之所以容易，是因为最初的严格审查做得好。如果你觉得审查自己人工智能生成的输出很费力，说明你没有向前推进 [1]。
挑战 2：使用人工智能处理小任务速度反而更慢，而不是更快。
上下文开销并不会随着任务规模的扩大而减少，而小任务大多只是边缘问题。人工智能可以很好地处理中间 80% 的工作，但在最初和最后 10% 的工作上却可能比较脆弱：设置、处理边界情况、最终审核。对于人工智能来说，通常两行代码的修复成本与开发一个完整功能的成本相当。因此，你花在向智能体简要说明上的时间比编写代码本身的时间还要多。即便如此，它仍然会缺乏上下文信息，发布一些细微的错误，然后你还得重做。提高任务目标，直到上下文开销能够被合理化为止。经验法则：如果任务规模小于一个有意义的工作单元（例如公关稿、章节、图表、营销活动），那么它可能就太小了。从“小规模”人工智能开始，可能是你无法实现人工智能驱动成果更大飞跃的原因。
挑战 3：你的并行度要么太低可以忽略不计，要么太高无法管理。
人工智能扩展的是生成能力，而不是你受限于人类工作记忆的能力。并行代理的上限取决于人类在不丢失上下文或理解的情况下能够同时处理多少个线程，而这个数字非常有限。你要么一边喝咖啡一边看着它编写代码，同时只处理一个线程；要么就过度处理，放弃五个线程。在你的认知窗口内，保持活跃的线程数量在三个或更少左右，或者闭环（下一节）并完全退出。如果你一次只运行一个会话，那么你可能没有进行足够的任务委派。如果你难以管理几十个会话，那么请考虑你是否真的需要“管理”它们，会话是否应该采用更大的跨度（更少的代理完成更多的工作），或者是否应该有意保持线性，直到你投入足够的时间和精力去掌握合适的技能和理解上下文。
挑战 4：无法形成闭环
最后 1%的收尾工作在于验证基础设施和极其明确的“完成”定义：这与产品生成截然不同，因此人们往往忽略它，直接在现有流程之上叠加人工智能。你变成了截图人，一个等待你点击或上传以进行验证的代理。要实现端到端的闭环：测试、查询、沙箱、浏览器工具、类型检查、真实的 API 响应。任何能够让代理看到自身输出并在无需你参与的情况下迭代的方法都行。在自动化周边流程之前，先将其删除。闭环是突破约 3 个代理上限的关键：工作在你的认知窗口之外运行，因为它不需要占用你的认知空间。信不信由你，只要预定义合适的上下文，人工智能也能很好地处理“模糊”验证，包括“这对于长期系统架构是否真的有意义”以及“这是否是应该添加到产品中的正确功能”这类问题——我经常听到有人天真地认为这些问题只能由人类在循环中完成。
挑战 5：无法积累杠杆效应
我们的聊天界面通常将每次会话都视为短暂的。经验是一种可重用的资源，但界面却没有提供存放它的地方。因此，编码工作要么从未开始，要么矫枉过正，为每个任务编写一个技能，最终得到一个包含大量一次性代码的目录，而其他人却无法使用。应该针对任务类型而非具体实例来构建技能。有些技能是规范（如何完成某件事）；有些则是原则（如何思考一类事物）。持久的资源是技能本身（通常是一个 Markdown 文件），而不是提示信息。识别信号是具体的：任何时候，当你发现自己为了获得更好的答案而编辑或“强迫”输出时，你可以将这条规则写入代码，并永远停止这种行为。甚至可以考虑元技能，这些技能会定期接收反馈（来自你或流程中的其他用户），并根据积累的经验对技能或上下文进行相应的修改。拒绝手动编辑 AI 的输出（即直接覆盖），或以任何不利于下次学习的方式进行编辑。告诉它为什么它很蠢，你是怎么想的，并确保下次它能记住这些。
挑战 6：你唯一提升的技能就是向克劳德提问。
技能源于认知上的挣扎，而人工智能却在你还没来得及思考之前就完成了思考，从而消除了这种挣扎。学习循环永无止境——你无法判断模型何时出错，也无法脱离它继续工作，领域技能就这样悄然退化。你需要在阻力中成长：编辑、质疑、推翻。首先，在你负责的领域内使用人工智能，这样才能真正感受到摩擦，并做出正确的修正。初级工程师受到的冲击最大：他们在建立评估输出的能力之前就将认知工作外包出去。那些能够进行评估的人（拥有品味的人、领域所有者）应该负责编码技能和质量标准，即使传统上资深个人贡献者和经理并不直接接触代码库。任何任务都不应该永远对人工智能系统来说太难，随着人工智能的学习，人类的努力会逐渐向上转移到架构人工智能构建的系统上：在这个领域，人工智能的表现确实不如人意，摩擦也更加明显。人工智能最终也会擅长这个领域，所以你只能不断地向上发展，构建越来越复杂的元衍生技能 [2]。
二、组织挑战与优化实践
上述个人层面的陷阱和下文提到的组织层面的陷阱，实际上是同一个问题的不同表现形式。人工智能优化了个人角色，但却保留了限制这些角色的流程。个人实践中，简化步骤至关重要；组织设计中，简化交接环节也同样重要。只有当各方拥有足够大的共同目标，能够同时实现这两方面时，才能真正获得收益。
挑战 1：强调使用效果而非结果。
使用率易于衡量，但影响却难以衡量。管理者和领导层常常承受着一种文化压力，即他们更倾向于表扬可见的使用率，而非无形的价值。绩效考核中充斥着各种指标，而下一轮中，为了虚增指标，Claude 循环仍然会继续运行。团队忙于发布新的 AI 系统，而不是修复那些真正重要的现有系统。应该奖励已发布的产品，而不是实际使用的产品。将使用率作为赋能和阻力的领先指标（尤其是在推广初期，应该将培训和工具的重点放在哪里），但绝不能将其作为长期目标。至关重要的是，这也是我看到最多误解的地方：纯粹的短期影响，如果没有持续的 AI 赋能杠杆作用（通常情况下），并不能最大化长期业务目标。应该根据成果留下的可复用杠杆作用来衡量结果：闭环、AI 友好型架构系统、规范化的技能、共享的上下文，这些都能使下一次发布的成本远低于本次。
挑战 2：工具蔓延至构建、购买和提供商等各个环节。
过去，构建成本是事实上的筛选标准。只有真正有价值的工具才会被开发出来。人工智能移除了这一筛选机制，却没有建立起替代机制，人们不断地发布产品，但并非每个人都具备正确的筛选标准。如今，发现新工具比开发新工具更加困难，而且不同团队和角色之间的上下文信息也出现了不一致的重复。高层架构师/所有者应该负责制定涵盖所有构建内容、采购内容以及标准化供应商的分类体系。底层试点项目——规模小、范围明确、不宜过早公开——是新工具获得“毕业”的途径，需要通过遥测数据和明确的淘汰标准来确保不再适用的工具被淘汰。尽可能地整合工具，并强制维护一个共享的上下文层，供它们使用。
挑战 3：低质量技能与背景信息泛滥
过去，创作需要具备相应的专业知识。人工智能打破了这种联系，因此产品不再代表权威。现在，任何操作都有十种可调用的方法，知识分散在各种维基和 CLAUDE.md 文件中，个人技能与共享技能混杂在一起，却没有质量标准。自上而下的架构师或领域专家应该决定核心技能集，并将所有权分配给那些真正懂得如何运用这些技能的人。如果那些懂得优秀标准的人没有参与技能的编写，那么这些技能默认就是平庸的。个人技能与共享技能之间存在着明确的界限：个人技能可以比较随意，而共享技能则是实际操作经验，必须像操作经验一样精心构建，经过审核并设定了真正的质量标准。
挑战 4：产出速度超过吸收能力
生成速度超过审核速度，人工智能不会逐步披露信息，当内容由“提示”生成时，作者身份变得模糊不清。冗长的文档无人问津，PR 审核员跟不上进度，粗制滥造的内容被发布，因为没有人愿意牺牲“生产力”。即使是人工智能生成的成果，也应该追究相关人员的责任；当输出内容沦为粗制滥造时，要建立一种严厉而具体的反馈机制，以促进抵制。使用人工智能，并假设最终所有内容都将由人工智能生成。即便如此，你仍然需要充分了解你发布的内容，以便在被质疑时能够捍卫它。审核人员不应成为最后的调试者。发布人工智能输出的人员需要拥有领域所有权，并持续依赖领域所有者构建和维护的技能。
挑战 5：交接过程中会吸收增益。
大多数组织都是按职能划分的，因此完成任何工作都意味着需要交接。编码通常只占整个周期的 20% 左右 ；[3] 其余 80%（审批、审核、同步）才是剩余的部分。人工智能（如果运用得当）可以将这 20% 的时间压缩到接近于零，而剩下的 80% 则成为瓶颈所在。一个 5 分钟就能解决的问题，审核却要耗费 3 天；为了解决人工智能已经完成的工作，需要召开大量的同步会议。循环所有权应该取代职能所有权：由一个人负责从问题到部署的整个流程，并设置适当的约束机制，确保他们能够在不牺牲职能层面的偏好的前提下高效工作。专家们转向平台——将他们的偏好融入到循环所有者代理使用的系统、提示和上下文中。单靠自下而上的速度提升在这里会遇到瓶颈；组织必须围绕循环进行重新调整，才能适应这种加速。我称之为组织*转型 [4]*。
挑战 6：自上而下，缺乏清晰度。
指令传递的是行为，而非品味或判断。如果高层缺乏明确的指导原则，层层下达的指令就会逐渐剥离意图。工程师们被迫审查人工智能的残渣，而不是被提升为架构师——他们的工作变成了下游的清理工作，而非上游的设计，而对被替换的恐惧也随之滋生。指令仍然是一个强有力的杠杆。但往往缺失的是清晰度：明确的期望、更新的角色定义，以及人工智能应用的重要性和紧迫性背后的原因。要谨慎选择何时采用自上而下的杠杆，何时采用自下而上的杠杆。同时，不要扼杀创造的乐趣。人们喜欢创造，你也希望他们喜欢自己所做的事情——自上而下的职责就是确保他们创造的是有用的东西。
挑战 7：自下而上不设定预期
自下而上的能量需要一个共同的目标才能实现累积。如果没有共同的回报定义，每个团队都会各自优化，收益永远无法累积。虽然使用情况看起来不错，但代币支出与业务成果脱节，导致项目无序扩张。要让投资回报率清晰可见：每个团队都要阐述其人工智能投资的回报，哪怕只是粗略的估算。将工作行为——闭环、规范化的技能、与结果一致的支出——融入职业发展路径，使正确的行为能够得到结构性的奖励，而不仅仅是文化上的认可。
所以…
你无需通过简单的 token 计数就能达到两倍的效率。人工智能会放大你已有的优势以及你所在组织已有的能力。如果你的工作流程较为松散，人工智能会加剧这种松散。如果你的组织依赖交接，人工智能会加快交接的频率。两者必须同时改变，否则任何改变都无济于事。
目前来说，10%到20%的部分是免费的。超过这个比例就需要重建：一方面是个人实践，另一方面是组织架构设计。我认为大多数人仍然需要进行大量的自我重构，而这项工作可能会让他们感到不适。
