跑三天的活怎么交接：一人公司最容易漏的四个记录

结论先行：当一个人替客户跑一个要花几天的活，最容易出事的不是中途出错，而是中途「换了个人」——不是真的换了人，是你自己隔了一天再回来，已经不记得昨天为什么那样做了。这份工作现在有了现成解法：把每一次改动都记下来，并且能查到它出自哪次对话。四份记录就能解决，而绝大多数一人公司一份都没留。

十月底的工具动态里出现了两条看起来不相干、实际指向同一件事的消息。一条是某主流开发工具厂商新推的代码管理产品，它的做法是把每一次人和 AI 的改动都关联到产生它的那次对话，用一张因果关系图把中间状态保留下来。另一条是另一个厂商在智能体托管服务里公开预览的一项能力，核心是让跑长时间的任务在被打断之后能够恢复，而不是从头再来。

两件事合起来的意思很直白：工具厂商已经默认「AI 参与的工作必须可追溯」这件事，而这件事在你自己的生意里才刚刚开始需要。

一、为什么「我能记住」在今天不再成立

过去一个人接一个长活，靠的是记性加习惯：打开文档看一眼上次做到哪、翻一下聊天记录想想当时为什么这么写。这套办法在两个前提下成立——一是你自己写的东西，二是你还记得住。

现在两个前提都不成立了。你的活儿里越来越多是 AI 参与产出的，AI 不解释理由，它给你一段结果，你顺手就用上了；你自己隔一天回来，面对的是一堆自己当时没细想就接受下来的内容。更麻烦的是，这些内容往往在几十个不同的对话窗口里产生——脚本在一个窗口、图在另一个窗口、客户的修改意见在第三个窗口。你要回答「这个为什么是这样」的时候，得同时翻三个窗口。

二、四份记录，缺一个就会出问题

• 决策记录：为什么这么做。每次你做出一个会影响结果的判断（选了这个方案、用了这个参数、砍掉了那个需求），记一行：判断是什么、依据是什么、什么时候做的。这一份是四份里最容易被跳过、也最值钱的一份——因为它决定了你能不能在三天后做出同样的选择。
• 改动记录：动了什么。每次改一个文件、一段文案、一个参数，记一行：改了什么、从什么状态改成什么状态。它不需要长，但必须能倒推。工具厂商那套因果关系图干的就是这件事的完整版。
• 来源记录：这段东西从哪来。每一份交付物里用到的素材、参考、数据，标一句来源：客户给的、公开资料查到的、模型生成的、自己写的。这一份在验收和纠纷时是护身符，也帮你下次复用。
• 状态记录：现在到哪了。哪怕只是一句话：今天做到哪、下一步做什么、卡在哪。这一份看起来最简单，但它决定了你被打断之后能不能接着跑，而不是从头再想一遍。

三、这套东西什么时候真的派上用场

不是所有活都值得这么干。判断标准是「这个活儿中间要不要离开」：

• 值得记的：周期跨天的项目；客户中途会提修改意见的活儿；一次要交付好几样东西的活儿（脚本、图、文案、多版本）；涉及金额和验收标准的活儿——因为对方随时可能问你「当时为什么是这样」，你需要当场答上来。
• 不值得记的：一次一小时内做完、当场验收结清的活儿。为这种活儿建记录体系是浪费自己的时间。

判断错了也不要紧。这类记录的成本比想象的低——每天几行字，用一个纯文本文件或者一张表就够，不需要任何专门工具。真正贵的是回头补：活儿做完三周再想补记录，你已经想不起来当初为什么那样做了。

四、三个坑

• 把记录写成流水账。「今天做了 A，今天做了 B」这种记录没有价值，因为三天后你看它还是不知道任何事。记录要写判断和依据，不是写动作流水。
• 只记成功不记否决。「我们决定不做多语言版本」比「我们做了中文版本」更有价值——半年后有人问为什么没做多语言，翻到这一行就明白了。被否决的方案是决策记录里最值钱的部分。
• 把记录当成给客户的交付物。这些是你的工作记忆，不是给客户的报告。客户要看的是结果，不是你的过程记录。搞混了会两个后果：自己嫌麻烦不再记，或者客户以为你没干活。

五、三个今天就能做的动作

• 开一个记录文件，就三行：决定、状态、来源。放在你天天会看的地方，别放在一个需要努力想起来的文件夹里。
• 设一个固定的记录时间：每天收工前花五分钟把当天三行补上。这个动作本身比记录格式重要——能坚持下来的格式才是好格式。
• 今天就把手头最长的那个活儿补一次状态。你有多久没回看某个活儿的进度了？那个久到你已经说不清「上次做到哪」的项目，就是这套东西第一个该救的对象。

这四份记录同时也是下一份交付物的原料——一份能说清「我们为什么这么设计」的说明，往往比结果本身更能建立信任。本站的公众号图文工具可以把其中的一部分整理成对外可读的版本，但记录本身先得有，这是你自己的活儿，工具替不了。