我想给这类问题留一个简单的写作入口。
笔记可以只有三行：
我想解决什么？
我试了什么？
现在知道了什么，还有什么没弄明白？
例如，整理一个文件夹时，原始记录可能只是「按主题分类很快混乱；按项目分类似乎更容易找到；旧文件还没处理」。这还不是文章，但已经有了文章最重要的材料：问题、尝试和保留意见。
过几天再看这条笔记，我会先问自己：如果读者没经历过这件事，能不能知道我为什么要改？如果不能，就补一小段背景。然后按发生顺序写下尝试，最后说清楚目前采用的办法。
这时可以把标题从「文件整理」改成更具体的「我怎样给项目文件找一个更容易回看的位置」。标题不用承诺一套通用方法，它只需要准确描述这篇文章讲什么。
发表前再检查两件事：是否把猜测写成了事实；是否留下了只有自己才懂的缩写或上下文。如果有，就补充说明。遇到暂时没有答案的问题，也可以直接写「还没验证」，留待以后更新。
不是每条笔记都要扩成完整教程。有的记录写到三四段就足够：交代问题，写一次尝试，留下下一步。等同类记录积累多了，再把它们串成一篇更完整的文章。
对我来说，开始写博客的门槛也许可以定得更低：先把一件小事写得让未来的自己看得懂。下一篇文章，就从下一条值得回看的笔记里找。
]]>如果真的开始做，我更想先建一个小入口，围绕正在进行的事来组织，而不是一次性给所有知识分类。
一个项目页可以只回答四个问题：我为什么做它，现在做到哪里，重要的资料放在哪，接下来要处理什么。比如「个人博客」这个项目，入口页可以链接到站点设计、写作想法和待解决的问题。
遇到一个具体问题时，再新建单独的笔记，并从项目页链接过去。这样，笔记不是被迫塞进某个目录，而是有一个清楚的来处。以后同一条笔记关联到另一个项目，也可以再加一个链接。
Wiki 里的文字可以是不完整的。它服务于查找和继续思考，允许草稿、清单和未解决的问题同时存在。博客文章则需要给不了解背景的人一条读得通的线索。
我设想的顺序是：先在笔记里保存原始材料；当一个问题有了值得回看的过程，再整理成 Wiki 页面；如果其中的经验能独立讲清楚，就写成博客文章。写博客时也可能发现笔记缺了关键步骤，再回去补。
这不是每条笔记都必须走完的流程。有些内容只适合留在私人空间，有些问题经过几次尝试就足以写成短文。判断标准可以很简单：公开之后，别人能否理解它，它又是否真的值得我保留。
我会先用少量页面试这个结构，而不是从一套庞大的分类规则开始。隔一段时间回看：有没有找不到的内容，项目页是否能带我回到重要记录，哪些链接一直没有用上。只有真实的使用问题出现时，再调整目录或命名。
个人 Wiki 对我来说更像一张逐渐画出来的地图。先标出常走的路，再决定哪里需要路牌。
]]>后来我想，博客可以先从记录开始。
平时遇到一个问题，我会查资料、试办法、改变主意。事情解决后，过程往往散落在聊天记录、浏览器标签和笔记里。过一段时间再碰到类似的问题，又要从头想起当时为什么那样做。写一篇文章，至少能把问题、尝试和当下的判断放到一起。
第一类是做事的过程。比如搭建这个站点时，我怎样安排文章和项目页面，哪些地方改过几次，最后为什么保留现在的做法。这些记录可能不够完整，却能帮未来的自己接着做。
第二类是还在形成中的想法。工具怎么选、笔记怎么整理、一个小项目值不值得继续，都可以先写出当前的判断，再随着使用经验修订。文章不需要在发布当天就成为定稿。
第三类是可以交给别人的经验。如果一段记录曾经帮我弄清一个问题，把它整理得更清楚，也许能帮到遇到同样问题的人。
私人笔记允许我写得很乱：一句提醒、一张截图、一个没想完的问题，都有保存的价值。博客文章多走一步：给读者交代背景，说清楚我做了什么，也说明哪些地方还没有验证。
这一步不一定很大。一篇短文只要能回答「我遇到了什么」「我现在怎么理解」「下次会怎么做」，就已经比留在收藏夹里的链接更有用了。
我希望这个博客慢慢长成一份可回看的记录。起初只有几篇也没关系。重要的是，当我再次遇到相似的问题，能找到过去的自己写下的线索，并且愿意继续补充它。
]]>