停三个月还能接回来：一人项目的断档复工手册

以下示例产品与人物均为虚构：示例产品叫“拾光手账”，是一个一人开发的手账记录小工具；示例人物沈一舟是它的开发者。本文讲的“复工手册”是写给未来自己的 continuity 文档，不是交给客户的交接文件，也不是交给 AI 的上下文包，区别在正文和划界说明里讲清楚。

一人项目最常见的死法不是做不出来，而是放下了就拿不起来。沈一舟的“拾光手账”就是这样死的第一次：去年秋天做到一半，工作一忙停了四个月，冬天想捡回来时，打开仓库像走进别人家——跑起来的命令忘了，数据库为什么分了两个表忘了，当时为什么没用某个现成的库也忘了。他花了整整一个周末翻提交记录、翻聊天记录、翻自己写了一半的笔记，最后还是没敢动核心代码，怕一改就把原来能跑的部分弄坏。项目就这样又停了三个月。第二次他学聪明了：不是在停下来之前把代码写得更完美，而是在还记得的时候，给三个月后的自己留了一份复工手册。手册只有几页，但再回来时，他一个下午就跑起来了，第二天就改了第一行代码。

断档是常态，不是失败。一人项目没有团队兜底，没有同事能告诉你“这个功能当时为什么这样写”，时间一长，连作者自己都会变成陌生人。所以复工手册要解决的不是“怎么写文档”，而是“怎么让未来的自己在最短时间内重新成为这个项目的主人”。它的读者只有一个，就是几个月后已经忘了大半细节的你；它的验收标准也只有一个，就是你照着它能不能在一天内跑起来、改动第一处、并且知道改动不会踩到哪些坑。达不到这个标准的手册，写得再漂亮也没用。

复工手册不是那几种常见文档

先把复工手册跟几种容易混淆的文档分开，免得写偏了。开发者文档是写给别人用的，讲接口怎么调、功能怎么用，读者是用户和接手的开发者；复工手册是写给未来的自己，讲“我当时是怎么想的、现在该从哪下手”，读者只有你。开工前先写 README 的做法是帮你在动手前想清楚要做什么，那是开工文档；复工手册是中途停下来时留的，讲的是“做到哪了、还剩什么、回来先干什么”。用户帮助中心是给最终用户的自助知识库，讲的是“这个功能怎么用”；复工手册讲的是“这段代码为什么长这样”，两者读者完全不同。

另外两种也容易混：交给客户的交接文件，重点是让客户方能独立运维、算账、对接，里面有商务和权责内容；交给 AI 的上下文包，重点是让 AI 在一次对话里快速获得足够上下文，格式为机器阅读优化。复工手册跟它们都不一样：它不追求全面，不追求正式，甚至不追求好看，它追求的是“失忆的自己能最快复工”。所以手册里可以写口语、可以写“别碰这里，原因我也忘了但测试会挂”这种不体面的话，只要未来的你看得懂、敢动手，就是好手册。把手册写成对外文档的样子，反而会因为怕写得不好看而拖着不写，最后什么都没留下。

复工手册的五件套

复工手册不需要长，五个部分齐了就够用。第一是一页现状：用最直白的话写项目现在是什么状态——能跑吗、哪里能跑、哪部分是半成品、哪部分是已知有坑但还没修。沈一舟的现状页只有六行：网页版能跑、手机端只有壳、导出功能做到一半会丢格式、登录用的是测试账号体系还没接正式的、图片存在本地还没上云、付费压根没开始。六行看完，未来的他立刻知道这个项目离“能用”还有多远，不用再靠翻代码猜。

第二是三十分钟启动清单：从零到跑起来的每一步，按顺序写，不跳步。包括装什么、命令是什么、要哪些环境变量、数据库怎么初始化、跑起来后打开哪个地址能看到什么。关键是每一步都要写“成功长什么样”，比如“跑完这条命令，终端最后一行应该是 Listening on 3000，浏览器打开 localhost:3000 应该看到登录页”。没有成功标准，未来你卡在某一步都不知道是自己错了还是环境错了。沈一舟还加了一条：如果某一步在新电脑上大概率会失败，把失败长什么样和绕过去的办法也写上，这一条帮他省了后来整整一晚上。

第三是决策日志：只记那些“换了别人会换种做法”的决定，每个决定三句话——当时选了什么、为什么选、放弃了什么。不是所有决定都值得记，只记那些回头看容易后悔的：为什么数据库分了两个表、为什么没用某个很火的库、为什么某个接口故意写得很绕。决策日志的价值在复工时最大：你看到一段别扭的代码，第一反应是“这谁写的蠢代码，我来改掉”，翻到决策日志才发现当时是因为某个第三方限制才绕的弯，改掉就会踩回同一个坑。沈一舟的决策日志只有九条，但每一条都拦住了一次“好心办坏事”的重构。

第四是坑位地图：列出已知的问题、复现方法、临时绕法。坑位地图不用等修好再写，恰恰是没修好的才要写：哪个功能在什么情况下会崩、哪个数据导出来格式会乱、哪个账号是测试用的别拿去真付费。写的时候带上日期，因为有些坑可能已经被顺手修了，日期能让未来的你判断这条还作不作数。第五是“给自己的交接”：账号、服务、密钥、域名、部署位置都在哪里，但注意，这里只写“东西放在哪、找谁拿、存在哪个密码管理器里”，绝不把密码和密钥明文写进手册。手册会进仓库、会同步、会备份，明文密钥写进去就是给未来的自己埋雷。

写给失忆的自己，要按失忆的写法写

复工手册的写作规则跟普通文档不一样，第一条是：假设读者什么都不记得。不要写“按老办法跑起来”，要写具体的命令；不要写“配置跟之前一样”，要写配置文件在哪、哪几项必须改；不要写“懂的都懂”，未来的你就是那个不懂的人。沈一舟给自己定的检验方法是：写完放三天，假装自己是新来的，看能不能照着手册一步不落地跑起来。凡是需要“想一想才知道”的地方，都是手册没写到位的地方。

第二条是：每条都带日期和“为什么”。日期帮未来的你判断信息新不新鲜，“为什么”帮你判断这个决定现在还成不成立。比如“2026 年 8 月，因为图片服务免费额度快用完了，所以图片先存本地，等用户过百再上云”，这句话里有时间、有原因、有触发条件，回来时一看就知道现在该不该改。只写结论不写原因的手册，复工时等于没写，因为你不知道结论背后的条件变了没有。第三条是：只记推不出来的东西。代码里一眼能看出来的，就不用抄进手册；代码里看不出来的——为什么这样写、当时试过什么失败了、哪个服务快到期了——才值得写。手册越短，越可能被维护；手册越长，越可能在下一次断档前就已经过时了。

还有一条很实际：手册要放在未来的你一定会看到的地方。放在某个云笔记的角落里，不如放在仓库根目录一个显眼的文件里，文件名就叫复工手册或者 CONTINUITY，让人打开仓库第一眼就能看到。沈一舟把它放在仓库根目录，名字叫 RETURN.md，里面第一行就是“停了很久回来看这里”。放对地方比写得漂亮重要得多，因为复工那天你最缺的不是信息，而是找到信息的耐心。

AI 协作断档，比人断档更难接

现在很多一人项目是跟 AI 一起做的，断档之后难接的地方又多了一层：你不光忘了自己怎么想的，还忘了 AI 当时是怎么被教会的。跟 AI 的对话记录动不动几万字，全翻一遍不现实，而且对话里很多是试错过程，真正留下的决定散在各处。复工手册里要单独留一小节给 AI 协作：当时给 AI 的关键约束是什么、项目有哪些不成文的规矩、哪些话是绝对不能让 AI 改的。比如“数据库结构改动必须先问我”“不要为了修一个 bug 把三个文件的结构全改了”“这个函数是手写的，别让 AI 重写”。这些约束当时是你跟 AI 磨合出来的默契，断档回来重新磨合一遍，成本不比重新理解代码低。

另外，AI 生成的代码有一个特点：看起来都挺像那么回事，但有些地方是你当时没细看就放过去的。复工手册里要诚实地标出“这几处是 AI 生成的、我没细审”，回来时优先复查这些地方，而不是默认它们是对的。沈一舟的手册里有一节就叫“没细看的清单”，列了三处：导出功能的格式转换、图片压缩的参数、登录的边界判断。回来复工的第一周，他就从这三处里找到两个真 bug。诚实标注没细看的地方，不是丢人，是给未来的自己省时间。还有一点：不要把长对话记录当手册存着，那叫存档，不叫手册。手册是从对话里提炼出来的几页纸，存档是万一要查才翻的东西，两者都要有，但不能互相代替。

复工第一天，按这个顺序来

手册写好了，复工那天也别凭感觉乱来，按固定顺序走最省时间。第一步是跑起来：照着三十分钟启动清单，把项目在本地跑起来，看到能用的界面再说别的。跑不起来的话，先修启动问题，不要顺手去改功能，启动问题和功能问题混在一起改，最容易把能跑的部分也弄坏。第二步是读现状页和决策日志，用半小时把“做到哪了、为什么这样写”重新装回脑子里，再看坑位地图，知道哪些地方现在不能碰。第三步才是改第一行代码，而且第一行最好选一个小而安全的改动：修一个文案、修一个已知的小 bug、给一个没测试的地方补个测试。小改动跑通一次，信心和手感就回来了，比一上来就动核心逻辑靠谱得多。

第四步是更新手册：把复工过程中发现的过时信息改掉，把新踩的坑补进去，把这次复工的日期写在手册开头。手册不是写一次就完事的文件，每次复工都是一次更新它的机会。沈一舟第二次复工时发现启动清单里有两条命令在新版本里已经变了，他当场改掉，第三次复工就没再卡在同一个地方。手册越用越准的前提是每次用完都顺手修一下，而不是每次都抱怨手册过时了却不动手。最后一步是定下一个检查点：这次回来打算做到哪、做到什么程度可以再次停下、停下之前手册里要补什么。断档不可怕，可怕的是每次停下都不留痕迹；只要每次停下前花半小时更新手册，下一次复工的成本就会一次比一次低。

多久更新一次手册才不烂尾

手册最大的敌人不是写不出来，而是写完就扔在那过期。更新频率不用高，关键是要跟项目节奏绑在一起。沈一舟的规矩是三条：每次发版后花十五分钟更新现状页和坑位地图，因为发版是最容易产生“现状变了但手册没变”的时刻；每次做了一个“换了别人会换种做法”的决定，当天就补一条决策日志，不要攒，攒着就忘了为什么；每个月不管有没有发版，花半小时通读一遍手册，把明显过时的删掉、把含糊的改具体。十五分钟加半小时，成本很低，但能保证手册在你真正需要它的那天还是可信的。

还有一种更新时机容易被忽略：决定暂停之前。很多人停项目是被动停的——工作一忙、热情一过，就悄悄放下了，等想起来时已经过了几个月。更好的做法是给自己立个规矩：只要预感到要停两周以上，就先花半小时写一页“暂停备忘”：现在做到哪、下一步本来要干什么、回来先看手册哪几节。这半小时是整个复工手册里性价比最高的一次投入，因为暂停备忘写的时候你还全记得，回来时它就是你的导航图。沈一舟后来每次暂停前都会写，哪怕只是停三周，他也写，因为三周足够忘掉一半细节了。

最后说一句：一人项目防烂尾，靠的不是意志力，而是给未来的自己留后路。代码会忘、决定会忘、连当初为什么做这个项目都可能忘，但一本几页纸的复工手册不会忘。它不需要写得全面，不需要写得漂亮，只需要做到三件事：让你一天内跑起来、让你知道哪些地方不能乱碰、让你改第一行代码时心里有底。趁你还记得的时候花一两个小时写下来，放在仓库最显眼的地方，这可能是你为这个项目做过的最划算的一次投入。项目可以停，但别让它死在“回来时看不懂自己写的东西”这件事上。

复工验收清单

手册写完后，对着这张清单自查一遍，缺哪项补哪项。第一，打开仓库第一眼能不能看到手册，文件名是不是一眼就能认出来；第二，照着启动清单，一个没接触过这个项目的人（或者三天后的你）能不能在三十分钟内跑起来，每一步有没有写成功长什么样；第三，现状页有没有写清楚哪些是半成品、哪些是已知有坑；第四，决策日志里有没有那几个“最容易被误改”的决定，每个决定有没有写为什么；第五，坑位地图有没有带日期、有没有写临时绕法；第六，账号和密钥有没有只写位置、没写明文；第七，AI 协作的约束和没细看的清单有没有单独列出来；第八，暂停备忘的规矩有没有定下来，下次停两周以上之前会不会先写一页。八项都过，这本手册才算真正能用。写手册的那一两个小时，换的是未来某个下午不用再花整个周末翻旧账，这笔账怎么算都划算。