42天冲刺：用认知敏捷法替代年度计划

年度计划的死亡

2024 年初，我认真地做了一份年度计划。目标清晰，时间线合理，甚至精确到了每个季度的里程碑。

到年中时，我发现这份计划已经面目全非：

• Q1 计划学的技术栈，Q2 就被新工具淘汰了

• 原以为需要一个团队才能做的事，一个人 + AI 就搞定了

• 年初完全没预料到的机会出现了，但计划里没有为它留空间

问题不在于计划做得不好，而在于做年度计划这件事本身可能就是错的——至少在 AI 时代。

2024 年初，Claude 还不能写超过 200 行的代码。到 2025 年底，我用 Claude Code 完成了 LogiNexus 72 万行代码的核心开发。这个变化发生在不到两年内。在这样的变化速度下，12 个月的规划周期太长了。

42COG：一种替代方案

在反复摸索之后，我逐渐形成了一套自己的方法论——42COG 认知敏捷法。名字听起来有点唬人，但核心理念很简单：

用 42 天的短周期迭代，替代 12 个月的长周期规划。

为什么是 42 天？

• 6 周 x 7 天 = 42 天

• 足够长：能完成有意义的交付物（一个功能模块、4-6 篇文章、一个开源项目的 MVP）

• 足够短：能快速校准方向（如果方向错了，最多浪费 6 周而不是一整年）

• 有节奏感：6 周的结构自然分为"聚焦-沉淀-回顾"三个阶段

RCSW 工作流

42COG 的核心是 RCSW 工作流，四个字母代表四个层次：

Real（现实约束）
  ↓
Cog（认知模型）
  ↓
Spec（规约文档）
  ↓
Work（实际作品）

Real：先承认现实

很多计划失败，是因为它们建立在愿望之上而非现实之上。

RCSW 的第一步是写下你的现实约束——不是你希望的约束，而是真实的约束。比如我的约束：

• LogiNexus 的商业成功是一切根基，不能为了个人成长牺牲产品交付

• 每天有效工作时间大约 8-10 小时

• 睡眠不能低于 7 小时（这是硬约束，不可协商）

• AI 工具在快速迭代，今天的"最佳实践"可能 3 个月后就过时了

写下这些约束的价值在于：它让你在做规划时有一个"现实检查"的底线。每当我想往计划里塞更多东西时，就回来看看这些约束——时间不够用，必须砍。

Cog：建立认知模型

认知模型是你对"世界如何运作"的理解。在成长计划中，它包括：

• 你是谁： 核心能力、独特优势、当前差距

• 你要去哪： 不是精确的终点，而是大致的方向

• 世界在往哪走： 行业趋势、技术变化、机会窗口

我的认知模型核心是"混合智能"——人和 AI 协作的效率远超任何一方单独工作。这个认知指导了我的所有决策：学什么技术、做什么产品、写什么文章。

认知模型不是一成不变的。每个 42 天冲刺结束时，都要回来审视：我的认知模型是否需要更新？有没有新的信息推翻了之前的假设？

Spec：写下规约

有了现实约束和认知模型，下一步是写下具体的规约——每个冲刺要做什么、怎么做、怎么衡量。

一个 42 天冲刺的规约包括：

• 1-3 个核心目标： 不能超过 3 个，超过就说明你还没想清楚优先级

• 明确的交付物： 不是"学习 React"，而是"用 React 搭完个人网站并上线"

• 红线指标： 什么情况下应该停下来重新评估

规约不需要精确到每天每小时。它更像是一个方向标——让你在执行过程中有一个可以反复对照的参照物。

Work：产出作品

最后一步，也是最重要的一步：产出实际的作品。

42COG 强调"作品优先"——不是学了什么、读了什么、想了什么，而是做出了什么。文章是作品，代码是作品，演讲是作品，开源项目是作品。

为什么强调作品？因为作品是唯一能被外界验证的东西。你可以觉得自己学到了很多，但如果没有作品来证明，这些学习就只存在于你的脑子里。

42 天冲刺的执行节奏

每个 42 天冲刺分为三个阶段：

Week 1-2：聚焦交付

前两周的关键词是"做"。集中精力完成冲刺的核心交付物。

这个阶段要做的：

• 把冲刺目标拆解为每周可完成的任务

• 每天的核心时间（上午）用于最重要的工作

• 每天花 5-10 分钟写知识卡片——遇到问题时顺手记下来

这个阶段不该做的：

• 不去想"这个能不能写成文章"

• 不去优化不需要优化的东西

• 不去开新的分支任务

Week 3-4：沉淀输出

中间两周的关键词是"写"。把前两周积累的知识卡片整理成文章。

这个阶段的核心动作是：

• 回顾过去两周的知识卡片，找到有共性的主题

• 把 3-5 张相关卡片组合成一篇 800-1500 字的短文

• 每周发布 1-2 篇文章

这个阶段的效率诀窍：不要从零开始写文章。知识卡片就是你的素材库——当你每天都在记录时，写文章只是"组装"而非"创作"。

Week 5-6：回顾校准

最后两周的关键词是"想"。回顾整个冲刺，为下一个冲刺做准备。

回顾时要回答三个问题：

1. 我交付了什么？ 对照冲刺开始时的目标，哪些完成了，哪些没完成？

2. 我学到了什么？ 不是技术知识，而是关于自己工作方式的认知——什么有效，什么无效？

3. 下一个冲刺我要调整什么？ 基于这次的经验，下一个冲刺的目标和方式需要怎么调整？

红线检查也在这个阶段进行。如果触碰了任何红线指标（如连续两个冲刺无交付物），就要暂停计划进行深度反思。

Sprint 0：一个真实案例

我的第一个冲刺（Sprint 0）是项目初始化，目标很简单：

目标：

1. 搭建个人网站并上线

2. 建立 42COG 方法论文档体系

3. 发布第一批文章

交付物：

• huangyibin.com 上线 ✅

• .42cog 目录结构建立完成 ✅

• 第一篇文章发布 ✅

学到了什么：

• AI 辅助建站的效率确实高，但"最后 20%"的打磨仍然很耗时间

• 方法论文档不能太长——我的成长计划第一版有 700 行，后来精简到了只保留核心约束

• "先完成再完美"是对的，但需要为"完美"留出足够的时间

下一冲刺调整：

• 减少方法论文档的篇幅，聚焦可执行的约束

• 文章先从短文（800-1500 字）开始，不要一上来就写深度长文

• 建立知识卡片习惯，从每天 5 分钟开始

和其他方法论的区别

vs OKR

OKR 通常以季度为周期，强调"对齐"和"透明"。42COG 的 42 天冲刺比 OKR 短一半（6 周 vs 12 周），更适合快速变化的环境。而且 42COG 不强调组织对齐——它本质上是一个个人成长框架。

vs GTD

GTD 关注的是"事务管理"——如何处理收件箱、如何分类任务、如何确保不遗漏。42COG 关注的是"方向管理"——确保你在做正确的事，而不只是高效地做事。两者可以互补：用 GTD 管理日常事务，用 42COG 管理成长方向。

vs 敏捷/Scrum

42COG 借鉴了敏捷的很多思想（短迭代、回顾、持续交付），但有两个关键区别：

1. 冲刺周期是 42 天而非 2-4 周——个人成长比软件开发需要更长的消化周期

2. 强调"认知模型"层（Cog）——不只是"做什么"，还要"为什么这样做"

关于"过度规划"的自省

写到这里，我需要诚实地说：42COG 本身也有过度规划的风险。

我的成长计划第一版有 700 行，包含了 10 年路径、12 个能力维度、5 个阶段。写完之后我自己都笑了——我在文档里写着"一切拖慢混合智能循环的事物，注定会被淘汰"，结果这份 700 行的文档本身就在拖慢我的循环。

后来经过元反空审视（一种三维度自审方法），我把计划精简到了核心三件事：

1. 把 LogiNexus 做成功

2. 每周写一篇文章

3. 持续提升品味

其他所有事情，都是这三件事的副产品。

这个精简过程本身就是 42COG 的一次实践：Real（现实约束告诉我时间不够）→ Cog（认知模型告诉我核心只有三件事）→ Spec（规约精简到最小可行版本）→ Work（开始执行）。

行动建议

如果你也觉得年度计划不好使，想试试短周期迭代，我的建议是：

1. 从一个 42 天冲刺开始。 不需要先建立完整的方法论体系，先试一个冲刺看看效果。

2. 目标不超过 3 个。 如果你觉得 3 个不够，说明你还没想清楚优先级。

3. 必须有交付物。 "学习 XX"不是交付物，"写一篇关于 XX 的文章"才是。

4. 冲刺结束时做回顾。 哪怕只花 30 分钟，回答那三个问题。

适应速度比规划精度更重要。在 AI 时代尤其如此。