项目文件夹里躺着十几个名字叫“新建文件夹”“未命名文档”“【无标题】”的东西，这大概是每个做事的人都会经历的阶段。我自己的硬盘里曾经有个叫“【无标题】”的文档，从建立到被我真正打开，中间隔了将近四个月；等终于打开时，里面只有三行字和一个不知道从哪复制来的链接。后来我花了一个下午把它做完，交付出去，才发现当初拦着我的根本不是内容难度，而是那四个字：无标题。

这篇东西想聊的就是这件事——当手上拿着一个“【无标题】”的项目、草稿、想法，怎么把它从一团模糊推进到能交付的状态。它不挑领域：写文档、做设计、搭个小工具、整理一份资料、准备一场分享，只要开局是“无标题”，流程都相通。适合两类人看：一类是手里正压着几个“无标题”文件不敢打开的，另一类是习惯性把所有想法都先建个文档然后永远不动的。我会把自己踩过的坑、用过的拆解方法、命名规则、验收清单都摊开讲，能直接抄的部分我会写清楚，剩下的你自己按情况改。

1. 先别急着起名：把“无标题”当成一个诊断信号

1.1 “无标题”背后通常藏着四类不同的问题

绝大多数人看到“无标题”的第一反应是“起个名字就好了”，但我试过很多次，名字起完了，文件照样不动。后来我总结出来，“无标题”只是个表象，底下压着的其实是四种完全不同的东西，处理方式差得很远：

这四类的解法不能混用。我犯过最典型的错误，是拿“拖延型”的办法去处理“想法型”的项目——给自己定了个“今天必须写完初稿”的目标，结果坐了三个小时，写出来的东西第二天全删了。因为那个项目连“要解决什么问题”都没想清楚，逼自己产出只是在制造垃圾。

判断自己属于哪一类，有个很土但很准的办法：关掉电脑，用嘴跟别人讲三十秒，看你能不能讲明白。讲得出来但不想写，是拖延型；讲不出来但素材一堆，是素材型；讲出来自己都觉得没意思，是想法型；讲得出来一半就卡住，是半成品型。三十秒测试比任何自我分析都管用，因为它绕过了“我该怎么写”这个问题，直接暴露“我到底想说什么”。

1.2 为什么命名拖延是成本最高的一种拖延

有一种拖延特别隐蔽，就是反复给项目起名。你会觉得这是在推进工作，实际上是在做最没有风险的那部分。我自己有过一个阶段，为了一个内部小工具的名字，列了二十几个候选，还专门做了个对比表，权衡“要好记”“要专业”“要能扩展”。结果那个工具本身的核心逻辑，一行代码都没写。

命名拖延之所以危险，是因为它感觉很像在思考。但名字是结果的压缩，不是过程的开端。你对一个东西的理解越深，名字自然越准；反过来，靠名字去倒推理解，基本推不出来。就像给小孩起名，你不可能靠起名来决定他将来干什么。

所以我的做法改成了：允许自己用一个临时的、丑的、随时会换的名字开工。临时名字只要满足一个条件——三个月后你自己还能认出来这是哪个项目。比如“素材归并-试验”“方案对比-v0”，这些名字丑得要命，但它们是工作名，不是交付名。等工作推进到七成，真正的名字往往自己就冒出来了，而且是那种一看就对的。

注意：临时名一定要带一个能区分场景的词，别用“项目1”“文档2”这种纯序号。序号的问题是你隔两周回来，完全想不起1和2的区别，又得重新翻一遍，成本白付。

2. 从一句话说清它是什么：项目定义的三个锚点

2.1 锚点一：谁在什么场景下会用到它

任何东西要落地，都得先回答“给谁、什么时候用”。这个问题听起来像废话，但我见过太多“无标题”项目死在这里——做的人从头到尾没想过使用者是谁，做出来的东西自己看着挺完整，一放到真实场景里就没法用。

举个我自己踩过的例子。有一年我想整理一套内部用的操作手册，素材攒了几十页，截图、命令、注意事项全都有，但一直没动笔。后来我强迫自己写下“谁会用”：结果是新人入职第一周，遇到具体操作不确定时，会翻一下。这一句话直接改掉了整个方案——原来我打算按“功能模块”组织，改成按“任务”组织；原来我准备写得很全，改成只覆盖高频的二十来个操作，剩下的用一句话指向更详细的地方；原来我打算做成一个长文档，改成做成可搜索的清单，每条自带关键词。

同一个素材，换个使用场景，结构完全不一样。所以这一步别偷懒，把下面三句话写下来，写不出就说明还没想清楚：

• 用的人是___（具体的角色，不是“大家”）
• 他会在___的时候打开它（具体的时间点或触发条件）
• 他打开它，是想在___分钟/小时之内解决___这件事

第三句里的时间特别关键。它决定了内容的深度和颗粒度。五分钟要解决的问题，你不能给人家五千字；反过来，需要花半天研究的问题，你给三行结论就是敷衍。

2.2 锚点二：用反向定义法把边界划出来

正向想“这东西应该包含什么”，很容易越想越多，最后变成一个什么都能装进去的筐。反向想“如果不做它，会出什么问题”，边界一下就清楚了。

我常用的一张纸是这么画的：左半边写“不做它的后果”，右半边写“做它的代价”。后果那一栏，如果写不出具体的、能说出来的损失，那这个项目大概率不值得做，可以直接存档。代价那一栏，如果明显超过后果，也先放着。这个方法救过我不少时间，至少砍掉了三四个纯粹是“觉得应该做”的项目。

反向定义还有个好处：它会自动帮你划出不做什么。比如整理一份素材库，正向想会想把所有素材都收进去；反向想“不做会怎样”，答案是“找不到某个具体案例时会浪费半小时”，那结论就是只收可检索、会被复用的部分，那些一次性用过就扔的东西根本不用进库。范围一缩，工作量直接降一半。

2.3 锚点三：定下最小可交付形态

这一条是让“无标题”项目能活下来的关键。所谓最小可交付形态，就是哪怕只做到这一步，也能拿出去用的那个版本。它必须满足两个条件：一是完整，别人拿到能独立使用，不需要你在旁边解释；二是小，小到你在一到两个工作段之内能做完。

我见过太多项目死在“追求完整”上。开头雄心勃勃，规划了五个模块，做完第一个就没劲了，剩下四个永远停在计划里。而如果一开始就只做一个能用的最小版本，哪怕粗糙，它是活的，后面可以迭代；死在规划里的东西，连被用的机会都没有。

定最小形态有个很好用的问法：“如果明天就要交，我会砍掉哪些部分？”答案里剩下的，就是最小形态。这个问法比“什么最重要”有效得多，因为人在压力假设下做的取舍，往往比平静时更接近真实。

3. 命名这件事，其实是收束思路的过程

3.1 好名字的四个硬指标

等思路收得差不多了，再回来处理名字。我对名字的要求就四条，按优先级排：

第一，能搜到。在你的文件系统、笔记软件、协作工具里搜一个关键词，它得能被搜出来，而且不会和一堆东西撞在一起。所以“总结”“方案”“草稿”这类词不能单独用，必须带上区分度高的词。

第二，能看懂。隔三个月自己回来看，不用打开就知道里面是什么。这条听着简单，但很多人起名喜欢用缩写，当时觉得省事，后来完全想不起来。

第三，能排序。同一类东西放在一起时，名字本身要能排出先后。最省事的办法是在名字前加日期，格式统一成20250115这样，别一会儿“1月15日”一会儿“0115”。

第四，不带情绪。别用“最终版”“真的最终版”“绝对最终版”这种，它们没有任何信息量，只会让文件越来越多。版本用数字或者日期，清楚了当。

3.2 一套可以直接套用的命名公式

我自己在用的是这个结构，领域不同稍作调整就能用：

日期_对象_动作或状态_版本

举几个具体的例子：

这个公式的好处是每一段都有用：日期负责排序，对象负责检索，动作负责判断进度，版本负责区分。四个字段全填上，一个名字就能说清“这是什么、到哪一步了”。缺点是有时候名字会长，但对个人项目来说，长一点远比看不懂划算。

注意：版本号别用“定稿”当终点，用“定稿”意味着你认为它不会再变了，实际上一变就得再造一个新词。我现在的做法是数字版本一直往上加，只在大阶段变化时换“动作”字段，比如从“初稿”变成“可交付”。

3.3 文件与目录的组织方式

光有名字还不够，位置也很重要。我吃过最大的亏是文件散在十几个地方，找的时候靠记忆，记忆一失效就全乱。现在我的做法很笨但有效：每个项目一个根目录，根目录下固定四个子目录。

• 01_素材：所有原始材料，链接、截图、片段、参考，不做任何加工，进来越多越好
• 02_工作：正在处理的中间产物，可以乱，可以有多个版本
• 03_交付：只放能拿出去给人看的东西，任何带“草稿”“试验”字样的不准进
• 04_归档：做完的、放弃的、过期的，统一挪进来，不删

这四个目录的作用是让“进度”变成物理位置。你打开项目，看一眼03_交付里有没有东西，就知道这个项目到哪了。这个方法比任何进度表都直观，因为它不需要你主动维护，挪文件这个动作本身就是维护。

关于“不删”这条，我要多说一句。我以前有清理强迫症，看到没用的文件就想删，结果删过两次之后发现，被删的东西里总有一小部分三个月后会用到。后来改成全部挪进04_归档，硬盘又不是放不下，留着不占什么成本，但省掉了很多“当初那个东西哪去了”的懊恼。

4. 把草稿变成可推进的计划：拆解与排序

4.1 用“动词加产物”的方式拆任务

“写文档”“做方案”这种表述没法执行，因为它们不是一个动作，是一堆动作的集合。我把任务拆到能执行的粒度，用的是一句话格式：

动词 + 具体产物 + 完成标志

对比一下就很清楚：

拆到这个粒度，好处是所有任务都有了明确的“做完”标准。没有完成标志的任务是最容易拖的，因为你可以无限期地“正在做”。

这里有个小技巧：拆任务的时候不要顺便估时间。估时间会让拆解变味，你会不自觉地往“看起来能在一天内做完”的方向凑，结果拆得不彻底。先纯拆，拆完再看哪些能塞进当天的空档，分开做效果更好。

4.2 排序原则：先做不确定性最大的那件事

任务排优先级，常规思路是按“重要紧急”排。但对“无标题”类项目，我更推荐另一个原则：先做最不确定的那个。

理由是，这类项目最大的风险不是做不完，而是做到一半发现方向错了。方向错得越晚发现，浪费越大。所以我会先挑那个“如果它不通，整个项目就得改”的任务来做，哪怕它最难、最不想碰。

具体怎么找这个任务？问自己一句：“哪一步做完之后，我心里会踏实一半？”答案通常就是它。比如整理手册那个项目，最不确定的是“新人到底会在什么情况下翻它”，那我就先去问两个刚入职的人，把这个问题解决掉，后面的结构、篇幅、写法全都跟着定了。如果不先做这一步，我可能花两周写出一份没人用的东西。

这个原则还有个副作用是好的：最难的部分先啃掉，后面的任务做起来心态完全不一样，会是那种“剩下的都是收尾”的轻松感。反过来，先做简单的，越往后压力越大，最后大概率崩在倒数第二步。

5. 实操演练：一个“无标题”项目从零到能交付的完整记录

我把前面那套方法用在一个真实的小项目上走了一遍，过程记录得比较细，你可以对照自己的情况看哪一步能抄。

5.1 阶段一：清点素材，先归堆再取舍

这个项目的起点是一个叫“【无标题】”的文档，里面有 23 条零散记录：一些截图、几段从别处摘的说明、三条自己随手写的想法、还有一个只有标题没有内容的段落。我打开它的第一件事不是写，而是全部倒出来。

具体做法：新建一个表格，一行一条，只填四个字段。

23 条全部过一遍，我花了大概四十分钟。结果是：明确有用的 8 条，可能有用但需要确认的 5 条，可以直接归档的 7 条，剩下 3 条是我自己都看不懂当时在写什么的，直接进归档。

这个动作的价值不在于分类本身，而在于它把模糊的焦虑变成了具体的数量。原来打开那个文档，感觉是一整团乱麻，压得人不想动；清点完之后变成“8 条要做、5 条要查”，一下就具体了，能排进日程。

提示：清点时千万别顺手开始加工。看到一条素材就想“我把它改好”，那清点会无限延长。这一步只做判定，不动内容，加工放到下一步。

5.2 阶段二：搭骨架，先定容器再装东西

清点完之后，我拿着那 8 条明确有用的素材，找它们的共同点。发现其中 5 条都在说“操作步骤”，2 条在说“为什么这么做”，1 条是“出问题时怎么办”。这个分布直接给了我结构：

• 第一部分：怎么做（对应 5 条）
• 第二部分：为什么这样设计（对应 2 条）
• 第三部分：出问题怎么排查（对应 1 条，但我知道这部分实际最重要，得扩写）

骨架就是这么来的，从素材的共同点里长出来，而不是先想一个漂亮框架再往里塞。这个顺序很关键。先想框架的话，你会不自觉地往“看起来完整”的方向凑，加很多用不上的章节；从素材长出来，结构天然贴合内容，也不会有空章节。

搭骨架时我有个固定动作：每个章节标题下面先写一句“这一节要让读者拿到什么”。这句话写不出来的章节，直接砍掉。上面那个结构里，我一开始还想过加一个“背景介绍”，结果那句“让读者拿到什么”怎么也写不出来，问自己“读者需要背景吗”，答案是“不需要，他们只想知道怎么做”。砍掉，省了一大块时间。

5.3 阶段三：填内容与验收，用清单过一遍

填内容这一步没什么花活，就是按骨架一节一节写，每节写到“这句话说清楚了”为止。我倒是有个习惯值得说：每节写完立刻标一个状态，用三种标记——完整、能用但粗糙、空着。全部写完之后只看标记，就知道还差多少。

这次填完的状态是：两节完整、一节能用但粗糙、一节空着（就是“出问题怎么排查”那节，因为当时我还真没遇到什么典型问题）。空着那节我没有硬编，而是先留着，等实际用了一段时间、真出了问题再补。这个决定后来证明是对的——硬编出来的排查表，条目都是想象出来的，实际用的时候一条都对不上；而用了一个月后真实踩到的三个坑，才是那份清单里最有价值的部分。

验收我用的是一张固定清单，每项都是能明确回答“是/否”的：

• [ ] 名字符合命名规则，能在文件里搜到
• [ ] 放在03_交付目录里，没有任何“草稿”字样
• [ ] 拿给一个不了解背景的人看，他能在不提问的情况下用起来
• [ ] 每节都有明确结论，没有“可能”“大概”“视情况而定”这类没定论的话
• [ ] 所有数字、参数、步骤都复核过一遍
• [ ] 三个月后的自己能看懂里面每个术语

第三条是最狠的一条，也最有用。我这次找了个完全不了解背景的人看了一遍，他卡在第二步，原因是我默认他知道某个前置条件。这个漏洞我自己看了三遍都没发现，因为我知道那个前置条件，会自动补上。

6. 常见问题与排查技巧实录

6.1 卡住时的五种典型症状与对应解法

项目推进不下去，症状其实就那么几种。我把遇到的整理成一张表，卡住的时候对着找，比干坐着强。

最后一条我特别有体会。项目做到八成的阶段最难受，前面的新鲜感没了，剩下的又都是硬骨头。这时候我的办法是只承诺二十分钟，二十分钟一到就停，不管做没做完。绝大多数情况下，二十分钟之后我会接着做下去，因为启动才是难点；偶尔真的停了也不亏，至少推进了一点。这个方法我用了一年多，比任何“今天必须完成”的目标都有效。

6.2 几条从实际踩坑里换来的经验

第一条：不要在建文件的那一刻就想好全部内容。我曾经有个习惯，新建文档时必须先把大纲写全，否则觉得不踏实。结果是新建成了一堆空壳，每个都写了两行就停。后来改成先允许它是“无标题”的空文件，随手丢素材进去，等素材够了再整理。这个改动让我的完成率明显上去了，因为建文件的心理门槛降到了零。

第二条：把“收集”和“加工”彻底分开。这两件事混在一起做，效率会掉一半。收集的时候只管往里扔，不管有没有用、不管格式；加工的时候只管整理，不再找新素材。混着做的问题是，你会在整理到一半时被一个新素材吸引走，回来时思路断了，得重新捡。

第三条：留一版“丑的但完整的”。我现在的习惯是，第一版允许自己写得很难看，但必须是完整的一条线，从头到尾能走通。有了这一版打底，后面怎么改都不慌，因为最坏情况是退回这一版。而没有完整版本的项目，改到一半容易把自己改乱，越改越不敢动。

第四条：定期做一次“无标题清理”。每个月花半小时，把所有叫“无标题”“新建”“未命名”的文件过一遍，能做判断的当场判断：要么改个正经名字进项目目录，要么直接进归档。我坚持了半年，硬盘里这类文件从四十多个降到个位数。这件事最大的收益不是省空间，是减少了那种“我好像有事没做”的背景焦虑，那堆文件躺在那里，每次看到都在消耗一点注意力，清掉之后人是轻松的。

第五条：警惕“准备工作”变成新的拖延。找模板、选工具、研究最佳实践，这些事都有明确的即时反馈，做起来很有成就感，但它们不是项目本身。我现在的判定标准很简单：如果这个动作不会让项目里多出一个字、一张图、一行代码，那它就是准备，不是推进。准备可以做，但得限时，比如二十分钟封顶。

最后分享一个我一直在用的小动作。每次面对一个“无标题”的东西，我不再问自己“这个该怎么做”，而是问“如果只能做一件事，做什么能让我明天还想打开它”。这个问题的答案通常是一件很小、很快能做完、做完有明确成果的事。而只要明天还想打开，这个项目就活着，剩下的都是时间问题。