Action Resilience：当我和 AI 一起工作

我发现自己需要一种 action resilience。

过去谈 resilience，我首先想到的是面对压力、负担和环境变化时的心理韧性。但最近让我不适的，常常是行动节奏的变化：有时很多任务可以并发推进，有时一件事就要占据整整一个上午；有时 AI 很快就能把工程代码搭起来，有时我必须亲自下场，花很长时间理解问题、试错、调整。

我有很强的惯性。习惯了一种完成事情的节奏，就容易期待下一件事也以相似的速度推进。尤其当节奏变慢时，我会很不舒服。

写下这些想法前的两天，我在处理灵活的爬虫问题，以及新的 API 调用费用和结果控制，前后花了将近十个小时。也是写代码，却和让 AI 一次性搭好基本工程的体验完全不同。如果只数完成了几个任务，我几乎会觉得自己“完败”。但两种工作都需要有人做。

这里的 action resilience，是我给这个具体需求起的名字：面对不同任务和协作方式带来的节奏变化，能够重新校准预期，而不是让昨天的速度直接决定今天应该多快。 它是一个用来理解自身经验的说法，还不是经过验证的心理学概念。

昨天的速度，为什么成了今天的标准

我把这件事拿去和 Claude 讨论。它一开始理解成：我不喜欢单个任务耗时太久，需要更频繁地获得完成感。于是建议我把任务拆开，看见那些微小的判断和进展。

但我不需要安慰，也不觉得问题只是一个任务花了很长时间。

真正让我在意的是，昨天更快地完成了工作，给我建立了不同的预期。今天任务变了，工作性质变了，我却还在用昨天的速度评价今天。这才是失调的来源。

当然，我可以试着建立更多维的评价体系：除了数量，也看质量、判断、学习和探索。但这里又有一个困难。完成了几件事、用了多久，至少容易记录；工作质量、判断是否正确、理解是否深入，就难得多。给自己增加几个评分项，并不意味着我真的有能力准确地评估这些东西。

继续想下去，我发现还有一个更基础的问题没有厘清：昨天那些工作，到底是谁做的？

我做了什么，AI 做了什么

我很容易享受更快完成更多任务的感觉：付出似乎少了，成果却多了，甚至会觉得自己变得更加高效、更加厉害。

但这个“我”可能已经混进了 AI 的部分。

我们作为一个团队整体输出，当然可以交付更多东西。可是，如果我把 AI 完成的工作直接替换成“我完成的工作”，再把团队的产出速度当作自己的工作速度，就会形成一个错误的参照。等到下一次需要自己长时间探索和判断时，我又拿这个参照来要求自己。

我想区分的不是哪些成果值得骄傲，而是：我做了什么，AI 做了什么。我不应该占有它的工作，也不应该夸大或缩小自己的工作。

这个想法也带着一点对自己的批判。一个管理者可能把下属的产出当成自己的能力证明；和 AI 合作时，我也可能产生类似的自我归因。意识到这一点，是为了对自己保持诚实，也为了更认真地对交付物负责。承认某部分由 AI 完成，并不会自动免除我检查和判断的责任。

我原来基于 Notion 的任务管理体系，主要是对外的：任务什么时候到期，完成了没有。对于交付，这样记录很有用。但在一个勾选框里，AI 很快生成的东西和我长时间试错才完成的东西，最终看起来没有区别。

它记录了结果，却没有帮我看见协作中自己的位置。

Human as an Organization

我以前想过“AI 组织”，但当时更多是在想工具：如何组织一些 AI，让它们完成任务。这次我想改变的是看待自己的方式。

如果我已经在和 AI 协作，就需要从组织管理者的角度来考虑：如何交付更高质量的东西，如何彼此配合，如何把合适的任务分给合适的参与者——包括我自己。

在这个意义上，我同时扮演三个角色。

Manager，管理者。 我决定要做什么，如何拆解，什么交给 AI，什么由自己完成，以及什么时候需要调整分工。它的产出可能是一个判断、一种安排，未必是一段代码或一份文档。

Reviewer，审核者。 我检查 AI 的产出，判断它是否符合要求、有没有遗漏、能不能用于最终交付。这部分工作不会因为代码已经生成而消失。很多时候，真正耗时的恰恰是理解和核对。

Creator，创作者。 我亲自探索问题、设计方案、写出内容，承担那些不能直接委托出去的部分。

它们不是三份彼此隔离的工作。一个任务里，我可能不断在这几个角色之间切换。但它们的工作性质和时间节奏确实不同。只数最终完成了几个任务，很容易把管理和审核的投入藏起来，又把 AI 的快速产出算进自己的创作速度。

我需要看清自己在哪个角色上花了时间，以及这些时间解决了什么问题。至于每一种角色做得好不好，则是另一个仍然需要判断的问题。

代码量，无法告诉我还剩多少工作

写代码时，这种错位尤其明显。当时我觉得，至少有三类任务，AI 还不能让我放心地交出去。

第一类是外部 API 在变化，需要阅读复杂文档、理解实际行为，再不断调整策略。写出调用代码只是其中一部分，真正的困难在于弄清楚外部系统到底怎样工作。

第二类是复杂的状态转换和大量边界情况。AI 即使把代码写得很好，我也需要花很多时间检查。生成快，并不等于审核快；有些逻辑，只有自己重新理解一遍，才能判断是否可靠。

第三类是探索性的任务，没有成熟方案可以直接照着做。问题本身可能还需要在尝试中逐渐明确。

所以，快速搭出基本前后端，看起来像完成了“90% 的代码量”，剩下的“10%”却可能最难。这里的比例只是对工作体验的描述，不是一个测量结果。它提醒我，代码量和剩余工作量之间并没有我直觉中那么直接的关系。

这几类任务也解释了为什么角色的区分有用。在外部系统和探索问题上，我可能要投入大量创作、试错和判断；在复杂状态逻辑里，即使主要代码来自 AI，我也可能花很长时间做审核。把这些时间都概括成“今天只完成了一件事”，会丢掉对工作性质的理解。

这些是我在 2025 年 11 月使用工具时的判断。我不想把它们写成 AI 永远能做什么、不能做什么的分类，因为它的能力本身还在变化。

组织视角下，最难的是分工

把自己和 AI 看作一个组织，并不意味着要照搬公司的所有管理工具。

我当时列了几个自己在意的组织要素：按时、高质量地对外交付；统一的目标和愿景；高效、协调的内部分工；消除信息差；持续迭代进步。

其中，对外交付和我作为个人工作时的要求基本一致，只是能够承担的工作量可能变大了。持续进步则从个人能力，扩展到了工作流的整合：不只是我做得更好，也包括我和 AI 如何配合得更好。

目标和信息传递当然也需要处理，但在这个个人协作场景里，我当时更关心的是自己有没有把任务说清楚，有没有耐心补足上下文，而不是建立一套传统组织中的目标协调机制。人脑中的信息不会自动、无损地传给 AI，这个类比有边界。

真正让我觉得困难的，是高效的内部分工与协作。它的前提是对自己和合作者“心中有数”：

哪部分交给谁，为什么这样分？
AI 在哪里容易出问题，需要多少检查？
我在哪些问题上需要更多时间？
各部分怎样衔接，什么时候应该收回任务或改变方法？

如果这些都不清楚，分工就只能凭感觉，时间预期也很难准确。更麻烦的是，AI 的表现还会反过来影响我对自己的认识：我以为自己变快了，却没有分辨到底是哪一部分变快。

所以我需要同时了解 AI，也了解自己在协作中的真实投入。

能力还在变化，记录有什么用

如果是过去，我尝试一种新的工作方法，可能会设计实验、积累数据，再判断是否有效。但当时让我犹豫的是：AI 的迭代速度似乎比我调整工作方式还快。等我建立起一种比较稳定的认识，工具可能又更新了。

这并不意味着记录没有价值，而是我很难再期待一次记录就能得到长期有效的结论。今天的经验，未必能直接拿来预测之后的任务。我需要的认识可能更接近持续校准：这一次的任务是什么，这一次的 AI 能做到哪里，我这一次需要承担什么。

讨论到这里，我的诉求其实可以分成两层。

主观上，我想 fully recognize my effort，也 fully admit AI 完成的工作，不把二者混为一谈。

客观上，我想更好地和 AI 协作，并且能够更准确地预期时间和结果。

两者都需要我进一步了解：在不同种类的任务中，我扮演什么角色，花了多少时间，AI 的产出又需要多少修改和检查。这些记录不能直接回答质量好坏，却至少能帮助我看到自己到底在做什么。

最后，我差点又写了一个新工具

既然缺少这些信息，很自然就会想到：做个小工具，每天记录一下。

但我也不想为了改善自我管理，再花大量时间搭一个系统。我已经有高度数据化的日常管理习惯，单靠每天在心里回顾几分钟，又不太符合我的方式。

接着我开始想数据库、后端、服务器。觉得麻烦，又想到可以用飞书表格当数据库。讨论了一圈，最后承认：我可能只是又突发奇想，想做新东西了。

而且我确实在意好不好看。一个没有吸引力的界面，我可能根本没有动力每天打开。

不过，放回现有的 Notion 体系，仍然是当时最合适的选择。它已经在我的每日项目管理习惯里，不需要为了增加一种认识，再建立一套新的使用习惯。角色、时间投入、AI 产出需要怎样处理，可以作为现有任务记录的补充，之后慢慢尝试。

写下这篇时，我还没有验证一套有效的记录方法。先想清楚这件事，对我已经很重要：当我觉得“今天怎么这么慢”时，需要重新看一眼，今天做的是什么工作，我承担了什么，以及我正在拿什么作为参照。