AI作为外部化上下文——重获个人开发动力

2026年5月12日·4分钟阅读·Patrick Schless

AI作为外部化上下文

个人项目曾因会话间隙而夭折。但当我停止试图将所有上下文都装入大脑后，情况发生了变化。

像大多数开发者一样，我脑中总有一些有用的项目想法。在年轻（有孩子之前）的日子里，我每周轻松花20到30小时摆弄个人项目、有趣的语言或新框架。随着时间推移和个人时间的减少，这变成了零星的几小时。个人开发项目难以保持动力，最终被完全放弃。有几年，我打开一个项目，做一两个周末，然后搁置一个月，再也不回来。原因不是缺乏兴趣，而是数学问题。

旧数学

有了两个年幼的孩子和一份需要专注的正职，副项目必须跨越一个隐含的门槛：“如果我今晚兴奋地将所有内容加载到脑中，我是否真的会很快回到这段代码？”通常诚实的答案是否定的。例如，GoalChasr是一个小型VueJS项目，销售5美元的iFit相关磁铁。我有一小群回头客和一些关于增长和粘性的想法。我很急切，但发现很难在更大的更改上取得进展。摩擦不在于“下一步要做什么”，而是每次在几天后打开项目时，都要重建心理模型，弄清楚代码处于什么状态。在开始写一行代码之前，一半的会话时间已经耗尽。

所以我大多不开始事情。业余爱好转向更离散、自包含的活动：徒步、游乐场、适合一个周六的Home Assistant自动化。

变化

我并不是一下子注意到变化的。它是悄悄潜入的。哄孩子睡觉后的一小时个人编码曾经是30分钟上下文加载和30分钟实际流程。但某个时刻，它变成了一整小时的生产力，因为项目的状态不再存在于我脑中。计划文件就在那里，写着“我们上次在这里停下，下一步是这个。”我完全跳过了重新熟悉的过程。这不是轻量级的vibe coding，而是“真正”的键盘开发工作，上下文基于事先的协议和计划被喂给我。

对我而言，最有效的外部化形式是一次长时间的前期规划对话，产生一个书面计划，然后针对它进行小的实施单元。这种形式中的一个工作流程（不是我唯一使用的，但有代表性）是Matt Pocock的“grill-me”技能，Claude就一个特性对我进行盘问，直到设计具体化，然后是乒乓球式TDD（Claude编写一个失败测试，我手工使其通过）。盘问阶段占据了总时间的不小部分，需要专注，因为许多实施决策正是在这里做出的。之后，路径就铺好了，分解成足够小的部分，任何一个都能在一个晚上完成。

重获动力

最近我在开发PushForward。它很有趣，虽然并不新颖：一个对话式AI健身教练，将我的Hevy（举重）和Google Health（步数等）数据拉入一个持续的线程，让模型了解我的训练历史。2026年有几十个AI健身教练，其中一些已经做了跨追踪器综合，所以我不声称这个想法独特。我构建它是因为我是用户，而且交付一个真正工作的端到端代理比阅读关于它们的文章要好。

最近，我给代理添加了新的Google Health API集成。一个大的前期规划会议涵盖了架构、OAuth流程、新的代理工具（get_step_count、get_weight_history等），以及它如何融入现有的编排。这被分成了离散的单元，每个都有自己可以在一个或两个晚上完成的小计划。大计划保持方向；小计划则是我一周后回来时会发现的等待我的下一步。一年前，我不会开始这个。不是因为工作更难，而是因为会话间隙会杀死它。

延迟容忍度

我读到的多数AI编程见解都是关于每小时产出、每天代码行数、“10倍生产力”。这些只是程度上的差异，而非种类。对我来说，真正的变化是别的：延迟容忍度。我可以允许的会话间隙从“也许几天”变成了“几周没问题”。这使得开发在这个人生阶段重新成为一种可行的爱好，我怀疑相对于速度框架，这一点被低估了。大多数有小孩、要求高的正职或注意力分散的开发者都会认识到这个数学变化，就像他们认识到速度变化一样。