有一件事我在很多待办应用里都反复遇到：某个任务已经拖了三周，每天打开应用，它都安安静静地待在列表里，和三周前刚加进去时一模一样。清单忠实地记住了“要做什么”，却完全不知道“事情进行得怎样”。等我意识到一个项目其实已经停了一个月，往往是在某个很糟糕的时刻，比如截止日前一天。
屿志（https://yuzhi.orangely.xyz/）是我为这个问题做的一次尝试。它不是一张更好的清单，而是一座等距视角的小岛：每个项目是岛上的一座村落，未完成的任务是村里走动的小人，新来的、还没安排的任务乘船停在码头。你负责定规则、做选择，小岛负责记账、提醒和讲故事。
这篇文章不打算逐个介绍功能，而是想回答做它时一直在想的一个问题：一个记录工具，怎样给出既诚实、又不压垮人的反馈？
清单为什么看不出“进行得怎样”
清单的基本单位是“条目”，它只有两个状态：做了，没做。可一个项目真实的状况往往在这两者之间——上周推进了两次，这周一次也没碰；某件事推迟了四回；另一件事其实已经不重要了，只是没人把它划掉。这些信息不是没有，而是散落在日期和勾选记录里，需要你自己去拼。
屿志的做法是把这些散落的事实翻译成画面。有推进的村落有人走动、夜里亮灯；每确认三块“砖”，村里多盖一间房。停滞的村落按“距上次真实推进的天数”慢慢变化：7 天后变安静，行人减少；14 天后屋顶蒙灰、路边长草；28 天后居民背着包袱走向码头。打开应用的第一眼不是列表，而是全景——哪座村落热闹、哪座冷清、粮仓里今天还剩多少时间、码头排了几条船。
画面的好处是不需要“读”。一座蒙了灰的村落传达的信息，和“该项目已 16 天无进展”是一样的，但前者不需要你停下来理解一句话。当然，这也有代价：画面越生动，越容易让人把它当成要讨好的对象。后面几条设计底线，很大程度上都是在处理这个代价。
确认才算数
屿志里有一条最早就定下的规则：过去的事件和任务不会默认算完成，必须由你确认。
很多工具会自动把日历上已经过去的会议当作“发生了”，或者把到期的任务悄悄挪到明天。这样省事，但记录会慢慢和现实脱节——你不知道哪些是真的做了，哪些只是时间流过去了。屿志的选择是每天晚上做一次结算：小岛进入黄昏，今天的日程和任务排成一列，每条只需一个动作。右滑是做了，变成一块砖飞进村落；左滑是没做，可以选一个原因（被打断、没精力、不重要了、推到明天）；轻点是做了一部分。顺利的日子按一下“全部做了”就结束，大多数时候一分钟以内。
这一步看似增加了负担，其实是整套反馈可信的前提。如果小岛的变化来自系统的猜测，它就只是一种装饰；只有变化来自你亲手确认过的事实，它才是一面镜子。为了不让“确认”本身变成压力，忘了结算也不会被惩罚：未结算的日子小岛被海雾笼罩，补上记录雾就散；超过三天仍未结算的日子自动归档为“未记录”，不算做了，也不算没做，不产生任何后果。
衰败要慢，恢复要快
反馈要诚实，就得让没做的事有可见的后果；但后果一旦太重，人就会开始回避打开这个应用——这和清单里那个拖了三周的任务被刻意略过，是同一种心理。我无法确定对每个人来说合适的力度在哪里，只能用一条不对称的规则来尽量降低风险：衰败按天慢慢累积，而任何一天的真实推进，都会让村落直接回退一整个阶段。荒了一个月的村落，认真做三四天就能恢复热闹。
原因也被区别对待。“推到明天”单次没有后果，同一件事累计推迟三次以上才会让村落额外加重一档；“没精力”和“不重要了”的日子完全不计入衰败。后者是我特别在意的一点：主动放弃不是失败。 标记一件事“不重要了”，是一个好的取舍，它腾出了空间，不应该和“被打断”或“拖着没做”算成一回事。
即使村落走到最后一个阶段，小岛也不会替你做决定。它只是问你：重新启动、缩小规模，还是正式关闭？项目不会自己消失，最后一步永远由人来做。
不能直接经营的岛
做到一半时，我给小岛加了四个培育区：农田、果园、鱼塘和花园。农田由最近 14 天确认过的任务推进培育；果园由真正经过了、并被你诚实结算过的日程培育；鱼塘反映最近结算的节律；花园由日记培育。
这里有一个很容易滑过去的陷阱。只要画面足够可爱，人就会想让它更好看——如果农田有一个“浇水”按钮，很快就会有人为了让农田长高而去点它，甚至为了它去创建一些本来不需要的任务。这正是古德哈特定律描述的情形：当一个指标变成目标，它就不再能很好地代表原来想衡量的东西。
所以培育区刻意没有任何浇水、施肥、喂鱼、收获的按钮。它们的长势只能由现实中的事实推出来，而且只看一段滚动窗口里的情况：不会枯死，不会清零历史，也不会因为你一周没写日记就给出羞辱性的反馈。设计文档里有一句我很喜欢的判断标准：创建现实记录本身不等于获得奖励，只有现实真正发生，或者你对现实留下了有意义、诚实的记录以后，小岛才生长。安排了很多会议，果园不会因此结果；会议真的开了、你也确认了，它才算数。
这条规则不能完全杜绝表演——一个人总可以为了花园去写几句敷衍的日记。但它至少让“表演”比“如实记录”更费事，而不是更省事。
每个项目都有一个结局
清单里的任务被划掉以后就消失了，一个持续半年的项目也是如此。屿志想保留的，是项目作为一段经历的完整性。项目完成时会有一个落成仪式，小岛暂停，展示它的“一生之书”：立项日期、用了多久、完成了多少事、推迟过几次、主要卡在哪里、有哪些转折点。然后由你选择，把它立为海岸上的一座永久地标，或者收进山顶灯塔里的档案馆。
地标沿着海岸一圈圈排开，一圈放满就向外长出一圈新陆地，像树的年轮。正式关闭的项目也不会被抹掉，它们进入“未竟之书”，之后还可以重新立起来。小岛白天和夜里不同，季节跟随现实日期变化；夜里窗户和灯塔会亮起来，那些落成的地标就站在岸边。
它适合谁，不适合谁
屿志没有账号，也没有云同步，所有数据都留在你的浏览器里（可以随时导出 JSON 备份）。它支持用 .ics 链接订阅 Apple、Google、Outlook 日历，第一次遇到一类事件时由你指定它属于哪座村落，之后同类事件自动归位。它也完全不调用 AI，衰败、恢复、指标和编年史都由规则计算，所有可调的数值都写在一个配置文件里。
它比较适合同时推进几件中长期事情、又常常在不知不觉中让其中某件停下来的人。如果你需要的是团队协作、复杂排期，或者跨设备同步，它目前并不合适。它也不是用来帮你“开始”的——那是 Meltdown 想解决的问题；屿志关心的是开始之后，那些日子留下了什么。
首次打开时可以选“先看看示例”，它会放下几座处在不同阶段的村落：一座刚从荒置中恢复，一座正在变安静，一座的居民已经开始搬离。比起读说明，看一看它们各自的样子，大概更能说明这座岛想做的事。
我仍然不确定，画面化的反馈在长期使用里会不会也慢慢变得让人麻木，就像那张看了三周的清单一样。这也许只能靠时间来回答——用一座小岛自己的方式，一天一天地记下来。