把自己作为方法：自研产品为什么“做完”还不算“做成”
从微信里的一个小变化说起
OpenClaw 我很早就装好了，能力一直都在，但我用得不多。每次想用，都要专门打开它，切到一个单独的地方，把自己重新放进它的语境。这几步都很小，小到任何一步都不足以劝退我，可它们叠在“我只是顺手想处理一件小事”这个念头前面，就够我在大多数时候选择算了。
前几天我把它接进了微信。变化很直接：我明显更愿意用了，体验也好了很多。值得停下来想的是，这段时间它的功能几乎没变，我让它做的还是那批事。变的只是它出现的位置，和我够到它的方式。
微信是我本来每天都待着的地方。当 OpenClaw 出现在这里，它就不再要求我先离开、再去找它。想到它和用上它之间，原本隔着好几步，现在几乎被压平成一个动作。
我后来把它理解成一个关于摩擦的问题。能力决定一个工具理论上能做什么，摩擦决定它现实中会被用几次。功能再全的系统，如果每次调用都要额外付一笔心理成本，它就会卡在“可用”，到不了“在用”。
这让我想把能力和使用分成两样东西。能力是存量，写进代码就一直在，不会因为没人用而减少；使用是流量，只在有人真把它用起来时才发生，一停就归零。我们习惯为存量骄傲，因为它看得见、留得住；可一个工具对生活的实际影响，几乎全由流量决定。而这次微信入口让我看清，存量到流量的转化，根本不是自动的。
做完不等于做成
我长期写后端，过去默认的验收标准很清楚：功能实现，逻辑正确，测试通过，系统不出错。但 OpenClaw 让我意识到，这套标准只回答了“它能不能工作”，而不是“它有没有真在我生活里起作用”——前者在代码里就能验证，后者只能看它是否被一个真实的人，在真实场景里，反复地、自愿地用起来。
“代码完成”是一条对工程师特别诱人的假终点线：功能逐项划掉，测试变绿，反馈即时而确定；而“有没有真在用”的反馈缓慢、模糊。于是我们很自然地停在能被确认的地方，把那条更难回答的线当成已经越过。
我得替后端说句公道话：难点确实常在系统内部，数据要准、服务要稳、异常要处理干净，这些又难又必要，体验从不是它的对立面，而是同一件事的另一半——让扎实的能力有一条低摩擦的路，抵达每天的使用。我过去几乎把全部精力投在前一半，默认后一半会自动补上。
所以我想把自研东西的验收往后挪一步：代码完成只是中间态，真正的验收发生在它进入日常、被持续使用之后。这里我很小心，不去编任何数字。我的证据更朴素：一个东西如果我每天都会不自觉地打开，它就通过了；如果要提醒自己、说服自己才去用，那不管它多完整，都还没做成。而使用本身很难自欺——我可以骗自己一个项目做得很好，却没法长期骗自己天天去用一个其实不想用的东西。
按这条更严的标准，我做过的很多东西，其实一天都还没真正开始。但我手里确实有一个通过了考验的例子。
番茄 App 为什么活了下来
那是我自己做的番茄 App。在我给自己写过的所有工具里，它是唯一一个我每天都用的。它值得拆开看，不是因为复杂，恰恰因为简单——简单里藏着让它活下来的几个原因。
它沿用了我早就熟悉的流程。我不是凭空设计，而是照着我用惯的那类番茄 App 重做了一个。第一次打开就不需要学任何新东西，它的节奏落在我已有的肌肉记忆上。熟悉本身就是极低的摩擦。
它足够克制。重做时我只留了自己真会用的功能，其他一概砍掉。市面上的番茄应用常堆着复杂统计、社交、成就系统，这些对别人也许有用，对我只是噪音，每个我不用的功能都在悄悄抬高我找到真正需要那块的成本。克制难，是因为加一个功能总比拒绝一个更容易被说服；但让它一直被用下去的，正是我狠心没加进去的那些。
它按我自己的习惯优化。我既是作者，又是唯一要讨好的用户，可以把每个细节都调到贴合自己的手感，不为想象中的别人做任何妥协。别人的产品要在无数偏好间取折中，我只要对准一个人。
它有即时的收益。坐下来，开始一个番茄钟，专注一段时间，当场就有回报：一段被保护、不被打断的时间，和一个清楚的开始与结束。我不必等一周后看统计才觉得它有用，它在使用的那一刻就兑现了价值。
还有一点是我一开始没想到的：它在被用的过程中，自然沉淀下了我需要的数据。我什么时候开始看书、看的哪些书，这些不是我特意去填的，而是正常使用时顺带产生的副产品。这和专门做一个庞大的统计模块不同——那本质上仍是又一件要你维护的事。这里的数据更像使用行为投下的影子，不向我索取任何额外动作，也就不会在我忙、我累、我懒的那些时刻第一个被牺牲掉。
这几点不是并列的，而是互相加强：正是一次次的回来，才让数据得以沉淀；而积累下来的数据，又让它随时间越来越贴合我，越来越难被替代。即时回报让我今天愿意打开它，长期沉淀让我明天更离不开它——缺一不可。
把自己作为方法，但别当成所有人
番茄 App 让我慢慢总结出一个做个人项目的方法，我叫它“把自己作为方法”：先不要去想象一个模糊的“别人”，而是先从自己出发，先让自己用得舒服、用得高频，再谈要不要开源、要不要做成产品。
它最直接的好处是我不必凭空猜用户。为一个想象出来的用户做设计很危险，因为我能把任何我喜欢的功能都合理化成“用户应该会需要”，而这个虚构的用户永远不会站出来反驳我。我那些做完却没做成的东西，很多就败在这里：我为一个不存在的人，解决了一个我猜出来的问题。而当我把自己当用户，需求就不是猜的了——我知道我什么时候真卡住，哪一步让我烦躁，什么东西我会一次次回来用。这条反馈回路短到几乎没有延迟。
但正因为我离自己太近，这方法也带着特有的盲区。我最熟的痛点，未必是这个领域里最重要的痛点，只是最先硌到我的那个。我用得顺的设计，可能只是顺应了我的坏习惯。作为唯一的用户，没有人反驳我的偏见，也没有人提醒我：有些我早已习惯、甚至绕过去都没察觉的障碍，对别人可能是迈不过去的坎。
所以我必须给它划一条界线：把自己作为方法，绝不等于把自己当成所有用户。我只是第一个真实的用户，一个方便、诚实、随时在场的样本，但终究只是一个样本。我用得顺，只能证明它对我这样的人有效。
于是我强迫自己分清三种东西。一种是我的高频真实问题：它频繁出现、让我真难受，最值得动手，因为需求强度是真的。一种是我的个人特例：我用得顺，可能只因为它恰好长在我特有的习惯上，换个人也许根本不需要。还有一种是可迁移的共性：某个我遇到的问题，剥掉我的特殊性之后，在很多人身上以不同形式反复出现。只有当我能从自己的经历里认出那份共性，并把它和纯粹的个人特例分开，我才有资格考虑让一个东西离开我。
私用、开源、产品化：三种归宿
把这个方法走到最后，一定会撞上一个问题：一个我自己已经每天离不开的东西，要不要让它离开我，去到更多人那里。这看起来像个进度问题——好像私用是第一级，开源第二级，产品化第三级，够好就该一路往上走。我一度也这么默认。但想清楚后，我觉得这个阶梯的比喻本身就错了。
私用、开源、产品化不是一条向上的升级路线，而是三种不同的价值归宿。它们面向不同的人，承担不同的责任，也向作者要不同的东西。
私用的价值核心，是它彻底贴合一个具体的人。番茄 App 好用，恰恰因为它只对准我，不做任何折中。但这份好用建立在大量我心知肚明、却从没写下来的隐含上下文上：我的习惯、我的节奏、我能容忍什么、我不在意什么。私用之所以轻，正因为这一切可以留在作者脑子里，不必说明、不必兼容。
开源改变的是它被谁看见、被谁使用。当我开源，我其实是在说：这里有一个解决某类问题的思路和实现，如果你的处境和我类似，拿去自己改。它交付的不是开箱即用的完整体验，而是一份能被理解、被复用的方案。所以开源真正要我多做的，往往不是把产品打磨得多完善，而是把藏在脑子里的隐含假设显影出来：讲清它解决什么问题、依赖什么前提、什么情况下根本不适用。最糟的开源，是把一堆只对作者有意义的代码直接倒出来，却摆出“拿去用”的姿态——它比诚实的私用更糟，因为私用不承诺什么，而它承诺了复用，却没交付复用所需的那份说明。
产品化责任最重，重到它几乎是另一件事。当我把东西推给我不认识、也无法预设其处境的人，我就得替他们把曾留在脑子里的每一个上下文都补齐。它真正的工作量常常不在核心功能上，而在核心之外那一整圈让陌生人也能用起来、出问题时有人负责的东西上：它得一直可用，得处理我没设想过的用法，得在坏掉时有人管。
所以我不再用“做到哪一步”看这三者，而是问一个问题：这个东西的价值，有多少能在离开我之后依然成立。如果它的好几乎全来自对我一个人的贴合，那它最诚实的归宿就是私用；如果内核里那个问题足够普遍，只是被我的习惯包着，它值得被开源，让别人拿走内核、自己重配外壳；只有当那个问题既普遍、我又愿意连同周围那一整圈责任一起扛起来，产品化才真正成立。
拿这个去看番茄 App，结论反而让我踏实。按“做完还是做成”，它是我做得最成的一个；但按这个问题，它恰恰该停在私用。它的好重度依赖我熟悉的流程和我砍功能时的私人取舍，这些很难原样迁移给别人。这不是缺陷，而是它成立的方式。看清这一点，我就不会因为它做得成，而误以为下一步理应把它推给更多人。做成和该外推，本就是两个独立的问题。
我现在正要面对这个判断。我想把从番茄 App 和微信入口里得到的经验，用到我给自己做的个人信息中枢、秘书这类系统上，避免再出现“做出来了、自己却不愿意用”的老问题。它们会不会有一天走向更多人，我此刻不急着回答。我先要做的，是让它们过番茄 App 过的那一关：先成为我自己每天真会用的东西。顺序不能颠倒——如果一个东西连我自己都留不住，那讨论它要不要走向更多人，就是在为一个还不存在的价值分配责任。
所以我愿意重新定义“完成”。完成不止是代码写完，也不止是它被一个人用了起来，还包括我终于看清它诚实的归属：该安静地留在我的日常里，还是把内核让给别人去改，或者由我扛起那一整圈责任，让一个陌生人也能每天用上它。做出来从来不是终点，被一个人每天用起来才勉强算开始，而想明白它到底属于谁，才是这件事真正的完成。