那次增强一款桌面协作应用时，事情卡在一个很具体的地方：如果要验证真实发送，就必须重新扫码授权。偏偏当时用户不方便操作，扫码这一步没有办法立刻完成。
这类情况很容易把人的判断带偏。任务原本是分析应用、整理能力、建立可复用入口，真实发送只是其中一个需要账号状态的验证环节。可一旦看到“还没登录”或“还要扫码”，我们常常会下意识地把整个任务判定为暂停，仿佛没有授权，就什么都不能做。
我后来重新看这段过程，发现真正值得留下来的，不是某个应用的内部细节，而是一个很普通、也很容易被忽略的工作判断：一个必须由用户完成的授权动作，只应该阻断依赖它的那一小段，不应该吞掉整条任务线。
当时卡住的不是整个任务
这件事一开始并不是从发送开始的。用户先要求分析桌面应用，并创建一个可复用的工作入口。后续又多次追问是不是已经全部做好、是不是还可以继续增强。于是工作逐渐分成了几层：先看应用能做什么，再整理已有能力，补充可复用的分析入口，最后才是把某些业务动作放进真实环境里验证。
前面的很多工作并不需要用户扫码。应用包可以做静态分析，已有文件和结构可以做只读盘点，脚本入口可以在本地重新运行，交接说明也可以先写出来。这些动作的共同点是，它们不需要代表用户进入账号，也不会替用户向任何联系人发送内容。
真正受扫码影响的，是需要真实账号状态的那一段。比如确认某个发送路径是否能走通，或者验证业务接口在当前账号下能否完成写入。它们当然重要，但重要不等于能够支配全部进度。
如果不把边界分清，后果很直接：已经完成的分析会被一起标成“未完成”，可复用入口不会被整理，交接材料也不会留下。等用户终于有时间扫码时，团队还得重新回忆之前看过什么、验证到哪里、哪些结论已经确认。一个局部阻塞，就这样变成了记忆成本和重复劳动。
授权缺口为什么会制造停摆感
授权动作有一种特殊的心理重量。它通常发生在用户设备上，必须由用户亲手确认，而且还会影响后续的真实操作。执行者既不能代替用户完成，也不能假装已经完成。于是最稳妥的反应，似乎就是停下来等。
但“不能代替用户扫码”和“现在没有其他工作可做”是两句话。前一句是权限边界，后一句是未经检查的推断。
这件事让我重新意识到，阻塞点之所以危险，不只是因为它让某个动作无法继续，而是因为人很容易把它解释成整个目标无法继续。表面上是在等授权，实际上是在等待一个未经授权的结论：等它恢复之后，所有事情自然就能接上。
现实往往不是这样。没有明确的中间状态，等到授权恢复时，之前的探索会散在聊天记录里，已经验证的内容和仍然未知的内容混在一起，下一步还要重新判断。等待并不会自动产生交接；它只会让上下文变旧。
所以我会先问一个更窄的问题：当前动作到底依赖什么？如果依赖的是账号、联系人、写权限或用户确认，那就把它单独标成待授权。其他只读、可本地验证、不会产生外部副作用的工作，继续向前推进。
最容易误判的两个捷径
第一个错误捷径，是遇到扫码就停掉整个项目。它看起来很谨慎，因为没有越过用户授权，也没有冒险发送。但它把安全边界扩大成了工作边界。结果是该做的分析没有做，该写的交接没有写，最后只剩一句“等扫码后继续”。
第二个错误捷径，是为了让状态看起来完整，绕过授权或用静态推断替代真实发送。比如已经看到应用里存在某个能力，就把它写成“发送已经验证”；已经抽出了某条入口，就把它写成“外部调用一定可用”。这会让报告比事实更完整，却让用户无法分辨哪些是已确认、哪些只是推断。
我判断这两种做法都不对，是因为它们分别牺牲了不同的东西：前者牺牲进度，后者牺牲可信度。授权缺失时，最重要的不是让所有状态都变成绿色，而是让状态保持真实，同时让不依赖授权的部分继续产生价值。
不能代替用户完成授权，恰恰意味着要把授权动作单独排队，而不是把整个任务一起冻结。
这也是为什么当时没有把真实发送说成已完成。已经做完的部分可以如实交付，无法验证的部分就明确写成待授权、待真实环境验收。短期看，这样的结果不如“全部完成”好看；长期看，它避免了用户依据一个虚假的完成状态继续往下操作。
把任务拆成4种状态
我现在更习惯把类似任务拆成4类，而不是只看一个总进度。
第一类是只读分析。它包括查看应用结构、整理能力目录、区分直接观察到的内容和推断内容。这类工作通常不需要账号，也不改变外部状态。
第二类是本地可验证工作。比如重新运行一个分析入口、检查输出是否产生、比较前后版本差异、确认交接材料是否包含必要信息。它可能需要本机环境，但不需要用户授权。
第三类是需要用户授权的动作。扫码、登录、确认设备、允许访问某个账号，都属于这一类。它们不能被执行者代做，也不能被静态材料替代。
第四类是真实外部动作。发送消息、创建业务记录、触发对外通知，都要在权限、目标和验收条件明确后执行。授权只是它的前置条件，不是它的全部验证。
这样拆分以后，进度就不再是“完成”或“没完成”两种颜色，而是可以同时存在几种状态：分析已完成，本地入口已验证，授权待用户操作，真实发送待验收。它们互不冲突，反而比一个模糊的总状态更诚实。
在那次工作里，应用分析和能力整理继续推进，重新分析的入口也做了可重复运行的验证；真实账号相关的发送没有被伪装成成功；后续用户要求交接和归档时，已有成果也没有因为扫码缺口一起消失。
交接不是附属品，而是解除阻塞的准备
很多人把交接理解成任务结束后的文档工作。其实在存在授权阻塞时，交接本身就是推进任务的一部分。它要回答的不是“我们做过哪些事”，而是“授权回来以后，最少还需要做什么”。
我会把内容写成3种状态。第一种是已完成：例如哪些能力已经从本地结构中确认，哪些分析入口可以重复运行。第二种是待授权：明确需要用户在哪个设备、哪个应用页面完成什么动作，但不把操作细节写成已经发生。第三种是待验收：授权恢复后，要用什么真实场景确认发送成功，成功的标志是什么。
这3种状态的价值在于，它们把“以后再说”变成一条可以重新接上的路径。用户不用重新解释背景，执行者也不用从聊天记录里猜测上次停在哪里。
如果没有这份交接，授权完成后最容易出现另一种浪费：大家先争论之前到底做没做完，再重新跑一遍分析，最后才回到原本只差一次真实验收的地方。成熟的流程不是完全没有阻塞，而是阻塞解除后能够准确地从原位置恢复。
这里还有一个很重要的克制：交接里要保留未知。某个入口只是从静态材料中抽取出来，就写“已发现，未做外部验证”；某个端口的用途只是推测，就写“推测，未确认”。未知并不会让交接变差，反而能阻止下一位执行者把推测当成承诺。
这套方法可以迁移到很多工作
扫码只是最明显的一种授权阻塞。类似情况还包括等待客户提供文件、等待管理员开权限、等待设备回到手边、等待用户确认联系人，甚至等待一个必须由业务负责人做出的选择。
遇到这些情况，我会先画出依赖关系，而不是先问“什么时候能继续”。凡是不依赖外部授权的，就在本地完成；凡是依赖授权但可以提前准备的，就把输入、步骤和验收标准写清；凡是必须等授权才能发生的外部动作，就明确排队，不用模糊语言掩盖。
方法可以浓缩成一句话：先分类，再推进；先留证，再等待；授权恢复后，只做仍然欠缺的那一小段。
这件事让我重新理解了“继续推进”。继续推进不是不顾边界地往前冲，也不是把所有风险都推给用户，而是在边界以内把能完成的工作做完，把不能完成的原因说清楚，并为下一次动作留下入口。工具真正改变的不是等待时间，而是我们能不能在等待发生时，仍然把判断过程保存下来。
下次我会怎么做
下次再遇到扫码或登录卡住，我会先在记录里写明：被阻断的具体动作是什么，它依赖哪项授权，授权缺失是否影响其他工作。只要答案是“只影响真实写入或发送”，我就继续做只读分析、本地验证、能力整理和交接准备。
我会把最终状态分成已完成、待授权、待验收3栏，并在每栏里只写能被证据支持的内容。已经看到的就写看到，已经运行的就写运行结果，尚未真实发送的就不写成发送成功。
等用户方便扫码后，我也不会从头开始，而是直接回到待授权项，再按预先写好的验收标准完成真实动作。这样做的意义不在于把进度表填得漂亮，而在于让一个人的暂时不方便，不至于让整条工作链失去方向。
我更愿意把它看成一种工作习惯，而不是一个技巧：局部阻塞只暂停局部动作，真实边界要保留，其他可验证的价值要继续产生。