四道门：我怎么判断一件事能不能往下走

我手上同时开着好几件事：数据标注的业务、一个准备上线的数据分析店铺、几个公众号、一个问卷系统的开发、一套自己攒的手册。每件都在动，每件都动得不太彻底。

前几年我给这个状态找的解释是精力不够。后来发现这个解释不准确。麻烦的地方在于我没有标准判断哪件事该往前走、哪件事该停。没有标准的时候，人会挑最容易的那件：改文档、调界面、翻资料、再想一想。

这几年我把「能不能往下走」这个问题，换成了四个能当场回答的问题。四道门，一道一道过。

「差不多了」是个假信号

我以前的判断方式是看状态：昨天改了代码，这周聊了三轮，文档写了两千字。有动静就算有进展。

这套方式有两个漏洞。

动静可以无限大。一件事可以改上半年，每天都有改动，一次都没被别人用过。改代码、改措辞、改配色，这些都能制造「在推进」的感觉。

另一头，越接近交付越容易原地打磨。最后阶段的界面和文案改动最小、反馈最快，所以最容易被反复摸。

所以我把问题换成了这一句：这件事现在能拿出来给别人看的东西是什么。

拿得出来，往下走。拿不出来，回去补。这个问法不管我累不累、想不想、有没有灵感，只管有没有东西。

四道门最早是给 AI 协作的项目设的，管它别乱写、别跳步。用了一段时间发现，被管住的主要是我。

第一道门：方向能不能讲给不懂这行的人听

第一道门管开头那一段。过门要凑齐这些：

• 一份立项文档，说清是什么、给谁用、解决什么问题、第一版做什么、第一版不做什么
• 一份功能清单，按角色、业务流程、模块三个角度都过一遍
• 一份阶段计划，第一阶段必须是能跑通核心流程的最小版本
• 一份选型说明，写清为什么用这套，为什么不选另外三个常见方案
• 一份架构设计文档，写清目录规则、接口规则、错误处理
• 一份给 AI 的规矩文件，内容是禁止事项和验收标准

判断方式很简单：找一个不做这行的人，讲三分钟。他如果问「这个跟 XX 有什么区别」，说明差异点没讲明白；他如果点头说「明白，就是给谁用的那个东西」，这道门就过了。

我在这道门上卡过很多次，卡的方式很固定：把「聊过」当成「有了」。和 AI 聊三个小时，脑子里非常清楚，一份文件都没写。第二天开新会话，这些清楚全部作废，重新聊一遍，聊出来的还不太一样。

后来我给自己加了条规矩：讨论得再清楚，没有文件就等于没有。文件是给下次的自己用的，也是给 AI 用的。AI 不记得昨天，它只读得到今天摆在面前的这几份东西。

第二道门：有没有真的跑起来一次

第二道门管骨架，要求是几件事各自跑通一次。

• 前端能启动，首页能打开，设计规范里的颜色、字号、间距已经生效
• 数据库能连上、能建表、能插数据、能查出来
• 后端四条线走通：服务能启动、示例接口能返回、业务逻辑能写进一条数据、日志和错误处理能用
• 前端能调通后端接口，跨域（前端能不能直接请求后端）、返回格式、出错场景都对得上

过门的证据只有命令和输出。启动一次给一次日志，查一次库给一次返回结果。

这道门拦的是「设计得很完整，一次都没跑」。我在这上面有过很长的沉迷期：架构文档越写越详细，目录规划、错误码、日志级别、权限入口全都想到了，一行代码没跑。文档里的世界很整齐，因为它还没碰上任何真实的东西。

跑起来一次会遇到的问题，基本都不在设计里：端口被占、时区不一致、字段类型对不上、跨域被拦、连接数不够。这些只能靠跑一次暴露。文档写得再详细，也换不掉那一次启动。

第三道门：核心流程能不能从头走到尾

骨架通了，接下来一个功能一个功能地加。这道门要的是完整路径走通，还要走通之后没把别的弄坏。

• 所有 P0 功能（第一版必须有的那部分）做完
• 每一轮开发都有验收记录，拿得出命令、输出、日志
• 完整路径从头走到尾，从第一步到最后一步，每一步真实调通
• 相邻功能回归过，没被这一轮的改动弄坏
• 权限和输入校验查过：这个接口谁能调、越权访问返回什么、用户 A 能不能拿到用户 B 的数据
• 关键操作留下了日志

判断的时候看路径，不看接口。接口各自返回 200 很容易，一条路径从第一步走到最后一步很难，中间会碰状态、权限、数据归属、失败回滚这些真问题。

我在这道门上最常见的样子是「演示得了一半」。前半段能点，后半段说下周补。下周有别的插进来，后半段就一直停在那里。演示只需要一段能看的路径，产品要一整条。

第四道门：有没有人真的在用

最后这道门问的是最不好答的问题：有没有人在用，有没有产生一次真实结果。

过门要四样：

• 上线前的整体检查没有阻断性问题
• 真的上线了
• 复盘写过一遍
• 这次的踩坑至少有一条写回了自己的工具库

第三样和第四样是我自己加的。不写复盘，下一个项目会把这次的坑再踩一遍；不回写工具库，这一次的经验只留在记忆里，过两个月就没了。

这道门最难，因为它必须有别人参与。前面三道门我一个人对着屏幕就能交证据，这一道要有人真的点进来、真的用一次、真的付一次钱，或者真的拿走一份交付物。别人参不参与，我说了不算。

所以它也是被我跳过次数最多的一道。跳过的方式特别体面：项目还在完善、等淡季、等把这个体验再改改。这些话我对自己说过很多遍，每一遍都成立，每一遍的效果都一样，事情停在了第三道门和第四道门中间。

四道门真正拦的是跳步

把四道门排在一起，能看清它们拦的是同一个动作：从想法直接跳到打磨。

完整走一遍要吃三段苦。讲清楚要被人追问，跑起来要处理报错，给人用要听「这跟我想的不一样」。这三段都没有好看的反馈。

打磨有反馈，而且马上就来。界面调一下立刻好看，文档改一遍立刻整齐。人在没有判断标准的时候，会自动走有反馈的那条路。走一年也没人拦，看上去一直在忙。

门要做的事就是把这条路堵住。想改界面，先问骨架跑起来没有；想优化体验，先问有没有人用。这两个问题很扫兴，它们让我少花了不少时间在第三道门里面装修。

顺序不能换

我自己也想过：前面几道简化处理，直接冲最后一道行不行。试过，代价是加倍的。

第一道门没过就往下走，后面每一轮都在改方向。AI 按模糊的方向写出一堆文件，方向一改，这些文件全部返工，返工的时候还分不清哪几份能用。

第二道门没过就开始加功能，问题会堆到联调那天一起出现。字段、权限、返回格式全对不上，查一个问题要翻十处。

第三道门没过就上线，第一次真实使用会变成第一次测试。运气好的丢一个用户，运气不好的丢一批。

四道门有先后，前面一道没过，后面的都不算数。风险是累积的，前面留的缺口会被后面放大。

门也能被糊过去。为了过第一道门，写六份文件，每份两页空话，看起来齐全，实际什么都没有。这种凑数的文件我自己写过。

判断的办法是拿文件去提问。立项文档里那句「解决什么问题」，能不能被追问三轮还站得住；功能清单里那个功能，能不能说清给谁用、输入什么、出错走哪条路。问两轮就空的，等于没写。

门还给了我一样东西：停下来的许可

以前我停不下来。停对我来说等于承认失败，所以宁可继续动，动什么都行。

现在有个更中性的说法：这道门没过。它不评价我，说的是缺哪样东西。缺文件就去写文件，缺一次启动就去启动，缺用户就去问一个人。

这个说法比「我觉得差不多了」和「我觉得还不行」都好用。前一句让人提前庆祝，后一句让人无限拖延，两句都给不出下一步。「这道门没过，缺的是启动日志」有下一步。

我现在怎么用它

想开一个新方向的时候，我先问两个问题：它现在站在第几道门前？四道门我打算付几道？

这两个问题的答案经常让我把方向放回去。一个想法从零走到第四道门，中间要写文件、要跑起来、要走通路径、要找到第一个用的人。以前开新方向不花成本，只花想象力，所以开得很多。现在能看出代价，开的就少了。

我以前以为自己是在多线并行，其实是在多线开头。开得少了之后，手头那几件反而开始动了。这套东西的效果是让我少开了几个，从来没让我变快。

如果一件事我说不清它现在在第几道门前，那它还没有开始，只是被谈论。