1. 个人GTD搬进团队后，最先崩掉的不是工具而是假设

GTD这套东西，我从十多年前就开始自己用，收件箱、下一步行动、等待清单、每周回顾这一套跑下来，个人的事情确实很少漏。也正因为自己用得顺，我第一次把整套流程原样推到团队里的时候，信心是很足的——建一个共享收件箱，拉一张项目清单，定一个周回顾会，剩下的事情按书上写的来就行了。结果两周不到，共享收件箱里堆了六十多条没人认领的条目，项目清单上一半的"下一步行动"写着"推进XX事项"这种谁也看不懂的话，周回顾会开了四十分钟，全程在报进度，没有人真正处理阻塞。

那次之后我花了很长时间才想明白一件事：GTD在团队中失效，不是因为团队成员不自律，而是因为GTD的底层假设在团队里根本不成立。这套方法论是为"一个人对自己时间有完全支配权"这个场景设计的，一旦进入多人协作环境，你面对的不是"我该先做哪件事"，而是"这件事到底谁来做、什么时候做完、做完了谁在等"。这是两个性质完全不同的问题，硬套同一套清单结构，必然水土不服。

这篇内容偏向实战复盘，适合三类人看：自己GTD用得不错、想把它扩展到团队的管理者；被要求"团队搞个任务管理系统"但推不动的协调角色；以及正在犹豫要不要给团队买一套专业工具的技术负责人。我下面讲的不是理论推演，是实际跑过、反复改过、也推翻过一些做法的东西，中间踩的坑我会尽量讲透，包括哪些改造最后被证明是多余动作。

提醒一句：如果你打算照搬任何一本GTD书里的流程到团队，先停一下。个人GTD的收益来自"减少心智负担"，团队GTD的收益来自"减少协作盲区"，目标不同，结构就必须重做。

1.1 GTD的三条隐含假设在团队里逐条失效

我们先把底层逻辑拆开看，这样后面的改造才有依据。

第一条假设：捕获成本极低。个人场景下，你把一件事记进收件箱，动作只有三秒，成本几乎为零，所以"先记下来再说"是划算的。但在团队里，捕获一件事意味着你要通知另一个人、要让对方确认、要占用一个共享位置、后续还要有人清理。捕获成本从三秒变成了几分钟，而且每一次捕获都会给别人增加阅读负担。这就是为什么团队共享收件箱在第一个月必然爆炸——所有人都以为自己在做"低成本的捕获"，实际上是在往公共空间倾倒噪音。

第二条假设：理清可以由当事人独立完成。个人理清一件事，你自己判断它是不是可行动、下一步是什么，不需要跟任何人商量。团队里不行。一件事的"下一步动作"往往取决于别人的排期、别人的判断、别人的资源，你单方面定义了也没用。我见过太多团队清单上写着"完成接口联调"，但这个条目实际卡在另一个人手上，写着它的人以为自己在推进，实际上是在等。

第三条假设：回顾是自我校准。个人每周回顾，本质是你跟自己开一次会，检查有没有漏、有没有偏。团队每周回顾，参与者各自有各自的优先级和压力，你开的不是"自我校准会"，而是"多方谈判会"。用个人回顾的议程去开团队会议，结果就是变成流水账——每个人念一遍自己做了什么，念完散会，阻塞项一个没解决。

把这三条摆在一起看，结论就很清楚了：团队GTD不能是个人GTD的放大版，必须是重新设计的一套东西。我在后面的章节里会重点讲这个重新设计的核心是什么。

1.2 三张主力清单在团队场景下的具体失效点

光讲假设还是太抽象，落到清单上会更直观。个人GTD里最核心的几张清单，搬到团队后各自出了什么毛病，我整理成了一张对照表：

这张表里最反直觉的一行是"等待清单"。在个人GTD里，等待清单只是一个提醒工具，防止你忘了催别人，地位不高。但在团队里，等待清单实际上是整个协作系统的瓶颈图——谁在等谁、等多久了、卡在哪个环节，这些信息全部藏在里面。我在改造过程中把等待清单的地位提到了跟下一步行动同级，甚至更高。

反过来，"某天/也许"这张清单在团队里基本可以砍掉。个人存一些"以后可能想做"的想法是健康的，团队层面存这种东西，最后往往变成责任不明的地带——没人认领、没人推进、也没人删除，纯粹占位。

1.3 一个容易忽略的前提：团队GTD解决的是"承诺"而不是"任务"

这里要插一个我认为最关键的认知转变。个人GTD处理的单元是"任务"，团队GTD处理的单元应该是"承诺"。

区别在哪？任务是你对自己的交代，做不完顶多自己焦虑；承诺是你对别人的交代，做不完会影响别人的计划和判断。一个团队里如果只有任务清单而没有承诺关系，就会出现一种很典型的现象：每个人手上都有一堆事情在做，但关键路径上的事情一直在等，谁也没有意识到自己是别人的阻塞点。

我在第二次改造的时候，把系统里每一条事项都强制加了一个字段——"谁在等这条"。这个字段填不上，说明这条事项其实不需要进系统，你自己记着做就行；填得上的，它就是一个承诺，必须有责任人、有期限、有状态。这个改动听起来很小，但它把系统的性质从"任务池"变成了"承诺网"，后面所有的改造都是围绕这个性质展开的。

2. 二次改造的核心动作：把清单系统改造成承诺网络

意识到上面那个问题之后，我做了一次比较大的重构。重构的原则很简单：能不建清单就不建清单，能合并就合并，留下来的每一张清单都必须回答一个具体问题。个人GTD有六七张清单不算多，因为那是你一个人的脑子；团队有六七张共享清单就是灾难，因为每多一张，就多一个需要维护、需要教育、需要定期清理的东西。最后我只保留了两个核心视图和一张会议机制，其他全部砍掉或者合并。

这个裁剪过程不是一次到位的，中间我还加回去过两张清单，后来又删掉。我把最终稳定下来的结构讲清楚，同时也讲讲哪些东西被证明是多余的。

2.1 只留四张清单，其余一律合并或砍掉

最终保留的四张是：

统一入口（Inbox）。所有事项的唯一入口，不管来自会议、私聊、邮件还是口头，必须落到这里。这张清单的唯一规则是"只能进，不能就地处理"——也就是说，任何人看到一条新事项，不许直接在自己脑子里消化掉，必须落到入口里。这条规则听起来很笨，但它是整个系统能跑起来的地基，因为团队最大的信息损耗就发生在"我以为他会记得"这个环节。

行动清单（Next Actions）。从入口里经过理清之后，确认可执行、有明确责任人、有完成标志的条目。这张清单是全团队唯一在跑的事情列表，任何"正在做的事"如果不在上面，就等于没在推进。

依赖追踪表（原来叫等待清单）。记录"我在等谁"和"谁在等我"，双向的。这是我在改造中改动最大的一张，后面单独讲。

挂起池（Someday/Maybe 的团队版）。只在一种情况下使用：这件事确实有价值，但当前周期内启动不了。挂起池里的东西每季度清一次，要么启动，要么删掉，不允许长期挂着。这条规则是我吃了亏之后加的——之前挂起池里堆了三十多条，半年后回头看，八成的条目已经没有任何意义了。

日程表我单独处理，它不算清单，只放硬约束（固定会议、交付节点、外部依赖的截止日），不放"打算做的事"。这一条区分很重要，很多人习惯把"计划周三写文档"放进日程，结果日程表变成了愿望清单，真正的时间锚点反而被淹没了。

2.2 入口的收敛：把"随时可以派活"变成"必须走一个通道"

这一步是整个改造里阻力最大的，因为它直接改变人的行为习惯。

在改造之前，团队里派活的渠道有：当面说、私聊发消息、开会时提一句、邮件、以及各种群里的@。每个人都觉得这些渠道很自然，符合直觉。但问题在于，渠道越多，落到系统里的比例越低，漏掉的事情就越多。我们做过一个粗略统计，同一周内，通过非正式渠道发出的事项大约有二十多项，最终真正进入系统并被执行跟踪的不到一半，剩下的靠"记性好"和"事后想起来"解决。

改造的做法是保留渠道，但加一条硬规则：任何口头或私聊下达的事项，发起方必须在当天之内把它落到统一入口，落不进去的视为没提过。这条规则的重心在"发起方"而不是"承接方"，这一点很关键。如果要求承接方自己记，那等于把责任推给了最被动的一方，规则必然执行不下去。

配套的是一个"分诊轮值"机制。入口每天会进很多东西，如果没人负责清理，三天就积压。我的做法是每周轮一个人做分诊，每天花十分钟，只做三件事：判断这条是不是真的可行动、指定唯一责任人、给它一个粗分类。分诊的人不做决策，遇到判断不了的直接扔回给发起方，要求补充信息。

这套机制跑下来，我得到两个经验。第一，分诊每天必须做，不能攒到周五，攒着做的时候信息已经凉了，很多条目的上下文得重新问一遍，成本翻好几倍。第二，分诊人必须轮换，固定一个人做，两周之后这个人就会开始抱怨"所有活都堆给我"，而且他对业务的理解会逐渐偏移，判断越来越不准。

2.3 依赖追踪表：团队GTD里被严重低估的那张表

单独拿一节讲这个，因为我认为它是整个改造里价值最高的部分。

个人GTD的等待清单很简单，就是一行"等某人回复邮件"，记着就行。团队场景下，这张表要承载的信息多得多。我最终设计的字段是这样的：

这张表跑起来之后，团队里出现了一个很有意思的变化：大家开始能看见自己的"被依赖数"了。有些人在表上被等十几条，他自己完全没意识到；有些人基本没被等，说明他手上的事不在关键路径上。这个可视化的效果，比任何一次"要重视协作"的宣讲都管用。

我还加了一条软规则：被等超过三次且没有回应的事项，必须升级到周会处理。这里的"三次"不是精确指标，是我们试出来的一个经验值——等一次可能是对方忙，等两次可能是优先级问题，等三次基本就是排期冲突了，靠私下催是催不动的，必须放到公开场合对齐。

2.4 责任人的唯一性：为什么"共同负责"等于没人负责

这条规则看起来是最基础的，但实际推行的时候，很多团队会本能地违反它。

在改造初期，我们的行动清单里大约有三成条目写着两个或以上的责任人。当时的理由都很充分："这块需要两个人配合""他俩谁有空谁做""需要前后端一起看"。结果三个月后复盘，这三十多条里有超过一半处于停滞状态，而且没有人觉得是自己的问题——因为责任被分摊了，分摊到每个人头上的时候，就变成了"对方应该会做"。

后来我定了一条不留余地的规则：每一条行动只能有一个责任人，其他人只能作为协作方出现在备注里。需要多人协作的事情，拆成多条，每条一个责任人，通过依赖关系串起来。比如"完成接口联调"不能由两个人共同负责，要拆成"后端提供接口文档（责任人A）"和"前端完成联调验证（责任人B）"，B的条目依赖A的条目。

拆分之后，条目数量确实变多了，但每一条都能追踪到具体的人和具体的状态。这时候清单的价值才真正体现出来——它不是用来记录工作量的，是用来定位阻塞的。

3. 每周回顾的团队化改造：从流水账汇报到阻塞清理会

个人GTD里的每周回顾，是整个系统运转的发动机。没有它，清单会腐烂，收件箱会积压，承诺会漂移。团队场景下这个环节更重要，但也更容易走形。我参加过也组织过很多次所谓的"周回顾"，绝大部分最后都变成了进度汇报会——每个人轮流说自己这周干了什么，说完结束，没有任何决策产生。

问题不在参会的人，在议程设计。个人回顾的隐含目标是"自我校准"，团队回顾的目标必须是"消除阻塞和对齐承诺"，这两件事需要完全不同的议程结构。

3.1 回顾会变成流水账的三个典型原因

我先讲讲我们踩过的三个坑，因为这三个坑非常普遍，而且很多人身在其中而不自知。

第一个原因：没有会前材料，全靠现场回忆。一开始我不要求提前准备，觉得大家都很忙，开会的时候打开清单讲就行。结果是现场有一半时间在翻记录、找上下文、回忆上周说了什么。四十五分钟的会，真正用于决策的时间不到十分钟。后来改成会前一天自动把清单快照发出来，要求每个人必须提前看过，会议从"信息同步"直接跳到"决策处理"，效率差别非常大。

第二个原因：议程按人排，不按事排。按人排就是"每个人讲五分钟"，这是汇报会的排法。按事排是"把所有阻塞项拉出来，逐条定动作"，这是处理会的排法。前者天然鼓励大家挑好听的说，后者天然逼着大家暴露问题。这个转变说起来简单，实际操作中需要主持人有意识地把话题从"我做了什么"拉回到"什么卡住了"。

第三个原因：会开完没有产出物。这是最要命的。一次回顾会如果没有产生新的条目、没有修改状态、没有明确下一步，那它就白开了。我们现在的要求是：会议结束前必须产出三类东西——新增条目、状态变更、规则调整，哪怕每类只有一条，也必须有。这个要求逼着会议往有结论的方向走。

3.2 四十五分钟议程的具体时间切分

我把最终稳定下来的议程直接列出来，这个结构我们跑了大概两个多月才调顺，中间改过四五版。

0到5分钟：静默阅读。所有人打开清单快照，安静看五分钟，不允许说话。这五分钟的作用是让大家进入同一个上下文，避免会议前二十分钟都在补信息。刚开始有人觉得浪费，实际跑下来这五分钟能省掉后面至少十分钟的解释时间。

5到15分钟：阻塞项处理。只处理状态为"等待"或者超过约定时间的事项。每一条的处理方式只有三种：催一次并记录、改责任人、或者判定作废。不允许在这里讨论"为什么卡住"的来龙去脉，那是会后的两人沟通。这个环节的关键是快，平均每条不超过两分钟。

15到30分钟：承诺对齐。这一步是核心。把当前周期内的关键交付物拉出来，逐条确认：谁在做、什么时候能给、有没有人等着它。发现"有人在等但做的人不知道"的情况，当场解决。我发现这个环节最能暴露问题，因为很多阻塞不是因为有人拖延，而是因为双方对优先级理解不一致。

30到40分钟：容量确认。每个人报一下自己下个周期手上同时在办的事项数量，超过三条的要当场做取舍。这一步在个人GTD里没有对应概念，但在团队里非常必要，因为承诺是互锁的——一个人超载，所有等他的人都会受影响。设置"同时在办不超过三件"这条软约束之后，我们的平均交付周期明显缩短了，不是因为大家变快了，而是因为切换变少了。

40到45分钟：规则修订。留五分钟专门讨论系统本身的问题——哪条规则执行不下去、哪个字段没人填、哪个环节多余。这一小段时间看着不起眼，但它是系统能持续演化的关键。很多团队的系统是在三个月内腐烂的，就是因为从来没人正式地、定期地审视规则本身。

3.3 回顾会的产出物怎么落地

会议开完，如果不落地，第二次会就没人认真开了。我们的做法是把产出物分三类，各自有明确的落地路径。

新增条目直接进统一入口，由当周的分诊人当天处理，不留在会议纪要里。这一条很重要——会议纪要里的行动项，生命周期通常不超过一周，因为没人会去翻纪要。只有进入行动清单的条目才有跟踪机制。

状态变更当场改，不隔夜。会开完再改，很容易忘，而且改的时候上下文已经丢了。我们现在的习惯是主持人边开边改，投屏可见，所有人都能看到状态变化。

规则调整记到一个单独的规则文档里，带版本号和修改原因。这个文档不长，现在也就二十来条，但它记录了系统是怎么一步步演化的。我个人的体会是，这份文档比任何一次培训都管用，新人进来直接读它，比口头讲解清楚得多。

4. 工具与字段：不要为GTD单独买一套系统

工具选型这块，我的观点可能跟很多人不一样：团队GTD落地的成败，八成取决于规则和习惯，两成取决于工具，而且这两成里的大部分用一张共享表格就能覆盖。我见过太多团队在选型上花了两个月，工具买回来用了一个月就荒废了，因为规则没想清楚，再好的工具也只是把混乱数字化。

下面讲讲我们实际用过的两种方案，以及字段设计的最小集。

4.1 表格方案与专业工具的取舍

我们先后用过两个阶段：第一阶段是一张共享表格，第二阶段迁移到了一个更结构化的协作工具。两个阶段各自的体验差别很明显。

我的建议是分阶段：团队规模在十人以内、事项总量不超过一百五十条的时候，共享表格完全够用，先跑规则，别急着上工具。等规则稳定了、大家习惯养成了、表格确实撑不住了再迁移。反过来先上工具，很容易出现"工具很强大但我们不知道怎么用"的局面，最后变成一堆没人维护的空字段。

迁移的时候有个细节要注意：不要一次性把所有历史数据搬过去。我们当时把表格里所有条目都导入了新工具，结果新系统一上线就有四百多条历史遗留，其中一大半是已经完成或者已经失效的。新用户打开就看到一屏陈旧数据，第一印象直接崩掉。后来我们重新做了一次，只导入活跃条目，历史数据留在表格里归档，体验好很多。

4.2 字段设计的最小集与冗余字段的代价

字段设计上，我的原则是"每个字段都必须有人用它做决策"。如果一个字段填了但从来没人看，那它就是在消耗填写者的耐心。

最终保留的字段如下：

事项编号 自动生成，用于追溯 事项描述 动词开头的短语，必须包含完成标志 唯一责任人 一个人，不允许为空，不允许填多人 承诺对象 谁在等这条，可以为空（空则说明是自发事项） 状态 待启动 / 进行中 / 等待中 / 挂起 / 已关闭 下一步动作 当前状态下具体要做的动作 约定完成时间 可以为空，但"等待中"状态必须填 最后更新 自动记录，用于识别僵尸条目

这里面有几个设计取舍值得说一下。

"优先级"字段被我删掉了。一开始有，取值是高/中/低。跑了三周发现，几乎所有人都填"高"，字段完全失去区分度。后来改成用"承诺对象"和"约定完成时间"来隐式表达优先级——有人在等、有明确时间的，自然优先。删掉这个字段之后，填写负担降低了，信息质量反而提高了。

"状态"用了五档而不是三档。三档（未开始/进行中/完成）的问题是没法区分"我在做但卡住了"和"我在等别人"。加了"等待中"这一档之后，依赖追踪表才能自动生成，这是整个系统的关键连接点。

"最后更新"必须是自动的。手动填的东西一定会失效。这个字段的用途是识别僵尸条目——超过三十天没更新的，下次回顾会上必须处理，要么重启要么关闭。我们靠这条规则清掉了大量"看着在跑其实早就死了"的条目。

4.3 命名规范：一条被严重低估的规则

这一节内容很短，但价值很高。

事项描述怎么写，直接决定了清单能不能被快速扫读。我们最初的要求是"写清楚"，结果出现了大量"跟进XX项目""处理XX问题""推进XX事项"这种描述。这类描述的问题是：它描述的是一个状态，不是一个动作，任何人看了都不知道具体要做什么，包括写它的人自己一周之后。

后来我们定了一条硬规范：事项描述必须是"动词 + 对象 + 完成标志"三段式。

对比一下就很清楚：

这条规范推行的时候遇到了不少抵触，理由是"有些事情确实一开始说不清楚"。这个理由成立，但处理方式不是允许含糊，而是在理清阶段把它拆到能说清楚为止。如果拆不出来，说明这件事还没到可以行动的阶段，应该进挂起池，而不是挂在行动清单上占位。

5. 落地过程中的三轮反复：哪些改造被推翻，哪些被保留

前面讲的都是改造后的稳定状态，但实际过程远没有那么顺。这一节我把三轮比较大的反复讲清楚，因为我认为失败经验比成功经验更有参考价值——成功的做法往往依赖具体情境，失败的原因则通常是通用的。

5.1 第一轮：入口放开导致系统被淹没

第一轮改造我犯的最大错误是只建了入口，没有建分流机制。

当时的想法很朴素：先让大家养成"什么都往入口扔"的习惯，等习惯养成了再考虑清理。结果两周之内入口积压了六十多条，其中大概三分之一是重复的，三分之一是"知道了但不需要行动"的信息，真正有效的事项不到一半。更糟的是，因为积压太多，没人愿意去做清理，形成了一个负反馈。

这次失败的教训是：捕获和清理必须同时上线，不能分阶段。只鼓励捕获不建立清理机制，等于鼓励大家往公共空间倒垃圾。后来加的分诊轮值机制，本质上就是把清理成本显性化、责任化。

还有一个细节值得说：清理规则必须极简。我们最开始设计了一套挺复杂的分类体系，七八个类别，结果分诊的人自己也记不住，每次都要查。后来砍到三个粗分类（要做、在等、不做），执行率立刻上来了。规则复杂度和执行率是强负相关的，这一点在团队系统设计里是铁律。

5.2 第二轮：清单被当成考核工具后的全面失真

第二轮出的问题更隐蔽，也更危险。

系统跑顺之后，有些管理者开始拿清单数据看"谁的事情多、谁的事情少"，甚至在绩效沟通里引用清单条目。这个动向一出现，清单的质量在两周内急剧下降——大家开始把条目写得含糊（防止被追问细节）、开始拆分条目凑数量、开始回避把难的事情写进去。

我当时意识到一个很基本的问题：任何被用于评价个人的工具，都会立刻失去作为管理工具的准确性。清单的作用是让协作可见，一旦它变成考核依据，人就会开始管理"清单上的形象"而不是"实际的工作"。

后来我们明确了一条规则并反复宣讲：清单数据不进入任何个人评价体系，只用于协作协调。为了落实这条，我们还做了一个动作——把"条目数量"这类容易引发联想的统计视图从默认界面去掉，只保留按状态和按阻塞的视图。这个改动之后，清单的填写质量明显回升。

5.3 第三轮：中层不用系统怎么办

第三轮的问题不是系统本身，而是人。

系统跑起来之后，一线执行的人用得挺好，但中间层有几个角色始终不用。他们的理由很实际："我手上的事情都是随时变化的，写进清单反而不灵活""我记在脑子里就行""我主要是在协调，没有什么具体的行动项"。

这个问题如果不解决，系统就会出现断层——一线的事情进了系统，中层的决策和协调不进系统，导致很多阻塞的源头在系统里看不见。我们试过强制要求，效果很差，填进来的都是应付性的内容。

最后起作用的是一个间接办法：把周会材料的唯一来源定为系统。也就是说，会上讨论什么，完全取决于系统里有什么，不在系统里的内容不上会。这一招比任何强制要求都有效，因为中层必须上会，必须让自己的议题被讨论，就不得不把东西写进去。

配套的还有一条：协调类工作也要有具体条目。"协调"不是一个动作，"跟某方确认排期并回填到计划表"才是。把协调工作拆解成具体动作之后，中层发现自己在系统里其实有大量条目，只是以前没有用这种方式描述过。

5.4 三轮反复之后的稳定形态

三轮折腾下来，最终稳定的形态比我最初设想的要简单得多：

• 一个入口，每天分诊，每周轮值
• 一张行动清单，唯一责任人，三段式描述
• 一张依赖追踪表，双向可见，超期标红
• 一个挂起池，季度清理
• 一次周会，四十五分钟，五段议程
• 一份规则文档，二十来条，带版本

就这些。没有复杂的分类体系，没有多层级的项目树，没有自定义工作流。我一开始觉得这套东西太简陋，后来发现简陋恰恰是它能活下来的原因——维护成本足够低，低到大家愿意持续维护。

6. 可以直接抄的几条硬规则和长期维护心得

最后这一部分我把实践中最有用的几条规则整理出来，都是可以直接拿去用的，同时也讲讲系统长期运行需要注意什么。这些东西没有一条来自书本，全部是被实际问题逼出来的。

6.1 五条我认为最有价值的硬规则

规则一：口头事项由发起方负责落地。这条前面提过，之所以再强调一次，是因为它是整个系统信息完整性的地基。责任放在承接方，规则必死；放在发起方，才有可能执行。

规则二：一条事项只能有一个责任人。多人负责等于无人负责，这个结论在我们团队被反复验证过。需要协作就拆条目，用依赖关系串起来。

规则三：描述必须包含完成标志。"确认报价并回填对比表"和"推进报价"的差别，不是文风差别，是可验收性的差别。没有完成标志的条目，永远没法判断它是否完成。

规则四：超过三十天未更新的条目必须在下次回顾会上处理。处理方式只有三种：重启、改期、关闭。不允许"再看看"。

规则五：清单不进考核。这条是保护系统本身。工具一旦被用于评价，数据的真实性就没了。

这五条规则我建议直接写进团队的规则文档，新人进来第一天就要讲清楚。规则越少越好记，越少越可能被执行。

6.2 系统腐烂的三个前兆和对应的处理

长期运行下来，我发现系统开始腐烂之前通常有三个前兆，识别出来就能及时处理。

前兆一：分诊开始拖延。分诊从每天做变成隔天做，再变成一周做一次，这是最早的信号。处理方式不是催分诊人，而是检查分诊的工作量是不是太重了——如果一天要处理二三十条，那说明入口上游出了问题，需要从源头减少无效捕获。

前兆二：描述开始变长变模糊。条目描述从"确认报价并回填表"退化成"跟进报价相关事宜"，说明填写者开始应付。这通常发生在系统被忽视一段时间之后，处理方式是下次回顾会专门花十分钟，把最近新增的条目逐条过一遍描述，当场改。

前兆三：依赖追踪表上出现长期不动的高龄条目。有些条目挂着"等待中"已经一个多月，没人催也没人改。这种条目的存在会逐渐侵蚀大家对整张表的信任。处理方式是设一个硬性上限——等待超过约定时间两倍的条目，强制升级到周会，由集体决定是继续等还是换方案。

6.3 关于节奏：不要追求一次到位

我最后想分享的一点体会，跟方法论无关，跟节奏有关。

我做这个改造前后折腾了大半年，中间推翻过两次，第三次才稳定下来。回头看，最快见效的做法反而是最简单的：先只做两件事——建一个入口、开一次周会，其他全部先不管。等这两件事稳定运行一个月、大家形成肌肉记忆之后，再往上加依赖追踪和字段规范。

很多团队失败的原因，不是方法不对，是一开始就想把所有环节都做到位，结果每个环节都是半吊子，跑了一个月集体放弃，还得出一个"GTD不适合团队"的结论。实际上不是方法论的问题，是节奏的问题。

我个人现在的做法是：每季度只改进一个环节，改完之后观察一个月，确认稳定了再动下一个。宁可慢，也不要推倒重来。这套东西真正的价值不在设计得多精巧，而在于它能不能连续跑上一年还不用大修——能跑住的简陋系统，胜过设计完美但活不过三个月的复杂系统。