• 每个想法在被允许真正算作一个想法之前，都要通过一个单句测试

  • 大多数想法因三种具体原因而死去，而不是因为模糊的缺乏热情

  • 一个想法只有在真正接触到真实且反复出现的问题后，才能获得构建名额

  • 也许稍后列表会故意保留其余想法，而我查看它的频率远低于人们的假设

在任何想法成为想法前，我运行的单句测试

我产生的想法比我能构建的多得多。这不是夸耀，而是如果我不好好管理，就成了责任，因为那些想法中的每一个都只会在大约二十分钟内感觉兴奋，而兴奋是筛选真正值得我投入晚上的糟糕过滤器。所以在允许一个想法出现在任何列表上之前，它必须通过一个测试：我能否用一句话描述它最小的实用版本，中间没有“和”。

这听起来微不足道，但它比流程中的任何其他步骤都扼杀了更多的想法。“一个跟踪我 Claude 使用情况并同时显示分析并同时具有社区功能的工具”通不过。“一个在我达到使用限制前警告我的工具”通过了。第一句话是一个平台的推销。第二句话是一个星期二晚上的推销。我想要第二种，因为第二种是我真正能完成的。

我以前不是这样工作的。早些时候，一个想法只要听起来有趣，就能在我的列表上获得空间，而我的列表变成了一个充满半描述计划的坟场，所有这些计划都需要一段文字来解释。一段文字现在是一个警告信号，而不是一个特性。如果我需要不止一句话来说明最小的版本做了什么，那么这个想法实际上还没有成形，它只是获得了热情，而那是两码事。

这个测试还迫使我在投入任何实际时间之前，尽早对范围保持诚实。一个需要“和”的想法通常是两到三个想法披着一件风衣，在句子阶段把它们分开，比在构建三周后我终于注意到范围蔓延时再分开要便宜得多。我在《为什么我坚持发布小工具而不是一个大产品》中写过没有尽早这样做所付出的代价，而诚实的回答是，大部分这种纪律实际上从这里开始，从句子开始，早在任何代码存在之前。

在我打开编辑器之前，一个想法被剪掉的原因

通过句子测试的想法仍然不断被剪掉，而它们几乎都是因为三个具体原因之一而失败，而不是模糊地感觉它们不够好。

第一个原因是这个想法听起来好只是因为它是新的。新颖性是最廉价的兴奋，而它消退得很快。我对此的检查很简单，我让一个句子至少坐几天再做决定。如果在最初的火花消退后它听起来仍然值得构建，那是一个真实的信号。如果它只是在我想到的那个晚上听起来不错，那通常是晚上在说话，而不是想法。

第二个原因是它复制了我已经在发布的东西，即使包装不同。每个新想法都会与工作室中已经存在的东西进行诚实的比较：Git Dojo、OhNine、Statusline Builder、Claude Blueprint、RAXXO Studio 和商品线。如果诚实的回答是“这是基本相同的 OhNine，只是名字不同”，它不会作为新东西被构建，而是被折叠成关于改进 OhNine 的笔记。以两个不同的名字两次追逐同一个底层问题，浪费了任何一个版本都可以充分利用的注意力。

第三个原因是我无法想象一个具体的人遇到它解决的具体问题。不是人口统计学，而是一个实际的时刻。对于 Git Dojo，时刻是明确的：某人第一次输入 rebase -i 并因为这里的错误感觉代价昂贵而僵住。当我无法具体地想象那个时刻时，这个想法通常会永远保持抽象，这是一个强烈的信号，它在解决一种感觉而不是一个问题。

以这种方式剪掉想法曾经感觉像是浪费，就像我在扔掉潜力。我已经逐渐认识到这恰恰相反。我早早剪掉的每个想法，都是我可以用来完成其他事情的时间，而不是开始第四个未完成的东西。在《如何为多个产品构建单体仓库》中，我探讨了将单独产品保持分离的结构性方面，而不是出于内疚将剪掉的想法合并回现有工具，而这两种纪律相互强化：前期严格剪裁，保留幸存者并在之后保持清晰分离。

什么实际上能让一个想法获得构建名额

在剪裁中幸存下来是必要的，但还不够。一个想法只有在我自己不止一次遇到底层问题，并且具体到我能精确描述修复会是什么样子时，才能获得实际的构建名额。

这个规则存在是因为我不信任自己对别人需要的猜测。我信任我自己亲自反复遇到的东西，因为重复是将真实反复出现的问题与我再也不会想到的偶发烦恼区分开来的部分。Statusline Builder 的存在是因为我不断手动编辑同一类状态栏的 JSON 配置，并且在手动操作时不断犯同样的小错误。那不是关于开发者可能想要什么的预感，而是一个我亲自重复足够多次以至于构建修复不再是可选的烦恼。

具体性要求与重复性同样重要。“我想要更好的开发者工具”不够具体，无法据此构建，它只是一种情绪。“我想在一个错误不造成任何代价的仓库中练习 rebase”具体到可以当天坐下开始。当一个想法在没有我强迫的情况下自己达到这种详细程度时，那通常是我拥有的最清晰的信号，表明它已经准备好了。

在这两者之下还有一个更安静的检查，即我是否能想象用一句话向某人解释完成后的东西，同样的测试从一开始就存在，只是第二次应用于结果而不是推销。如果最终版本仍然需要一段文字来解释它实际上做了什么，那么在构建过程中有东西偏离了，而这值得在发布前而不是发布后捕获。我之前写过关于我在称呼一个工具为已发布之前对其运行的审查过程，而这个句子级别的检查实际上是同一习惯的最早版本，只是应用于一个想法而不是成品。

这一切都不是保证一个想法会成功。它保证的是，获得构建名额的想法至少是从真实的东西开始的，一个反复的、具体的、可描述的问题，而不是一个晚上感觉像是一个的情绪。

我故意忽略的也许稍后列表

并非所有未能通过剪裁的想法都会被删除。很多都会进入一个我认为是也许稍后的单独列表，而故意的部分是我实际上故意打开那个列表的频率有多低。

任何待办事项列表的诱惑都是把它当作一个需要不断照料的活物，重新排序优先级，重读旧条目，确保没有什么被遗忘。我以前正是这样做的，而它悄悄地变成了自己形式上的拖延，审查我没有在构建的东西的列表，而不是构建我面前的东西。现在，也许稍后列表只在设定的时刻打开，主要是在我构建之间并且真的有空间做新东西的时候，而不是每当我想浏览旧想法来获得多巴胺冲击时。

那个列表上的大多数条目从未毕业。一个想法在那里坐了几个月而我的情况没有任何改变，通常是一个信号，表明这个想法从一开始就不是那么强，它只是当时避免被直接剪掉。那些真正毕业的想法几乎总是因为某些具体的事情发生了变化，我在其他地方再次遇到同样的问题，或者我已经在发布的工具揭示了一个旧想法恰好能填补的空白。

我还学会了让想法安静地从那个列表上消失，没有任何仪式。并非每个想法都需要正式的拒绝，有些想法只是随着工作室实际产品的变化而停止相关，而修剪一个陈旧的想法的代价与出于模糊的义务感每隔几周重新考虑它所付出的代价相比，微不足道。在《经营单人 AI 工作室的实际日常》中更详细描述的，保持五个独立工具不合并成一个臃肿平台的同一种直觉，也是让这个列表不变成第二种更安静的范围蔓延形式的直觉，只是被推迟而不是发布。

底线

这个过滤器在纸面上很简单：一句话，没有“和”，在几天不觉得兴奋后仍然存在，不复制已经在发布的东西，并且可以追溯到我实际上不止一次遇到的具体问题。让它起作用的是当一个想法感觉紧急时拒绝跳过步骤，因为紧急性正是过去说服我构建从未完成的东西的那种感觉。

这一切都没有让我对错误的决定免疫，我仍然会在一些星期剪掉一些可能值得更多耐心的想法。但是替代方案，构建当下感觉兴奋的任何东西，是这个工作室从未发布过粗稿以外任何东西的版本。这个过滤器不是为了让想法完美。它是为了确保任何幸存下来的东西实际上都能完成。

如果有一个习惯值得单独命名的话，那就是对剪裁的耐心。我在句子阶段、重复性检查阶段或安静地在也许稍后列表上让死的每个想法，都是重新投入到完成已经赢得其位置的东西的时间。这种权衡并不光鲜，在一个听起来不错的想法被剪掉的那一刻，它也不感觉像是在进步。它后来看起来像是在进步，在那些真正发布的东西的列表中。