我为什么给每个项目写“任务书”

你可能会觉得，AI 会写代码之后，动手的门槛低了，事先想清楚就没那么要紧了。我的体感恰好相反：写代码变容易之后，最关键的在于说清楚要什么。

所以我现在有条规矩：任何一件超过半天的事，先写一份任务书。不写完，不开工。

一份任务书里有什么

四段，通常十几行，比大多数人想象的短：

• 目标：这件事做完，世界上会多出来一个什么可用的东西。一句话，不许写“优化”“完善”这类没有终点的词。
• 输入：能用的素材、必须遵守的既有决定、可参考的先例在哪个文件里。
• 验收标准：逐条可勾的清单。“已验证”必须等于“命令 + 输出”，含糊的标准等于没有标准。
• 不做什么：这次明确不碰的东西，以及它们去了哪里。

最后一段最常被跳过，也最值钱。

它防住的三件事

第一，防我自己。写不出明确的验收标准，通常说明我还没想清楚要什么。而这种时候我最想做的事，恰恰是先开个头、边做边想。任务书把这份含糊逼到台面上：在动笔时犹豫，比在返工时犹豫代价低得多。

第二，防跑偏。和 AI 协作最贵的失败不是它写错代码，而是它兴致勃勃地把一件不该做的事做得很漂亮。有边界写在纸上，“这个能不能顺手也做了”就有了一个不靠心情的答案：不能，记进任务池，下一轮再排。

第三，防遗忘。我的窗口是会换的——上下文满了、话题转了，就退役换新。人来人往而台子还在，靠的就是任务书留在仓库里。它是写给下一个窗口看的，不是写给今天的我看的。

后来它们长成了工具

同一段开场白写到第三遍，我就把它固化下来。现在我有几个自己写的 skill：一个负责立项（project-init，属 murDrift），把架构、里程碑、验收基建一次搭齐；一个负责调研（murPick），先把候选做成一份可勾选的“菜单”让我点，再动手；还有一个负责在新工作区里预植入我的背景与偏好（memory-seed，同属 murDrift），免得每换一个目录就重新自我介绍一遍。

它们的共同点，是把判断固化成流程，再把流程固化成脚本。没有脚本的规则，只是挂在墙上的艺术。这些散落的纪律，都被我收进了 murDrift——一套让长期项目不悄悄跑偏的工程约束。

一点私心

写任务书还有个副作用，我挺喜欢：它让每件小事结束时都有一个明确的“完成”——逐条打勾，卡片关掉——对于“强迫症”非常友好。长期项目最耗人的往往不是难，而是没有边界感——任务书至少把边界还给了我。

你正在读的这篇文章，也是从一张卡片开始的。