速评：13 个成员，34 条 top comments。
这个比例，眼熟。九天前那篇 Day 22 更新帖，作者是旁遮普一个十五岁的全职开发者，Crowdwide 的创始人，技术栈、进度、UI 改了什么，写得挺工整。真正让我停住的是帖子里并排摆着的那三行数字：13 个成员，65 条帖子，4 个社区。评论人数是注册用户的两倍半。
我不打算把它当笑话讲。三十四条评论里没有水军式的“加油”，是真东西，质量高得有点离谱。
Dave Kurian 在那帖里问三件事：失败路径测了没有；超时和服务端报错之后，草稿能不能回滚重试；双击提交是不是只产生一条帖子。最后补一句——把提交按钮 disabled 掉只保护了客户端，create endpoint 到底支不支持幂等键。
这句话可以拓下来贴在任何一个 CRUD 后端的脑门上。禁用一个按钮，是最典型的“看起来解决了”。UI 上灰了，请求该发两份还是两份。他问幂等键问得那么自然，说明他被打过。
Marcus Kim 那条更细：同一个帖子快速编辑两次，两个响应反序回来，旧的那个覆盖掉新文本，或者把新请求的 pending 状态给清了。这场景你自己想很难想到，只有真在弱网下点过两次保存、然后盯着页面发愣的人才写得出来。作者倒也老实，直接承认没考虑过乱序响应，说两条请求都成功不代表最终状态是对的。
这句承认比整个 UI 部分都值钱。
问题就在这儿。这些建议全都成立的前提，是有人会双击提交。十三个成员。给十三个成员上幂等键和乱序防护，技术上完全正确，我不打算假装它不正确——装了比不装强，没得辩。可你不能把装防滚架当成在开车。这产品现在缺的不是“重复帖子”这个 bug，是“有人愿意发第二条帖子”这件事。
最能说明问题的反而是 EffessDev 那条乐观 UI。作者自己写的：一开始觉得没必要，服务器更新就一两秒。对，就一两秒。在这个量级上，乐观更新带来的感知提升接近于零，而它引入的回滚、草稿、重试状态是实打实的复杂度。他自己把这笔账算清楚了。然后他还是做了。
他做它，不是因为用户需要，是因为有人在评论里提了。这是我的猜测，但猜得不算离谱——一个连载到第 22 天的 build in public 作者，最不需要的就是让一条认真写的建议在他帖子底下落空。
不能怪他。这是这套连载形式的激励结构：写一篇 Day N，收益是确定的，阅读、点赞、被看见、有人认真回你；去找一百个真实用户，收益不确定，而且要直面“可能没人想要这个东西”。理性的人当然选前者。三十四条评论是反馈，同时也是麻醉剂，麻醉效果还极好——它制造的“在被使用”的感觉，和真的被使用，体感上能骗过自己很久。
顺带说一句，这波建议成色是分层的。Nilamadhab 那条先说定 4/8/16/24 的间距尺度再逐个修 margin，真省时间，不是炫技。UnitBuilds 建议单开一个前端设计 skill 把 context 弄干净，指向的是 Anthropic 那个 frontend design skill——我第一反应是又一个把 agent 当银弹的，但长会话里 context 干净不干净确实有差别，这条我保留。再往下就是那种听着对、做起来并不改变结果的工作流建议。
至于作者掉进去的那个坑：他以为 UI 打磨主要是调颜色和几个 CSS 属性，结果撞上的是 margin、padding、border-radius，profile 页面首当其冲。huali 在评论里说，他在自己那套二十多个免费工具的站里，为一个渐变条调了好几个小时 CSS。
这一段是整篇帖子里唯一没有修辞的部分。我不太确定作者有没有意识到，他随手写下的“我以为只要改颜色”，比前面所有功能清单都更接近真实的开发现场。所有“AI 五分钟生成一个完整应用”的演示，剪掉的就是这一段。不是因为它难，是因为它无聊，剪不进十五秒的高光。这话我不是第一次说，估计也不是最后一次。
这里立个 flag：如果到 Day 50 前后，成员数还停在两位数，这个连载的标题会开始变味——从“今天修了 UI、加了侧边栏开合”变成“我在想这个东西到底给谁用”。不是唱衰，build in public 到中段几乎都会拐到这一步，我见过太多次。侧边栏拆层、打开时背景模糊变暗这种改动，是作者自己判断要做的，还是评论区推着做的，其实分不太清；等哪天他在帖子里第一次写出“其实我有几个真实用户告诉我”，那才算真的开始。
最后留个问题给那三十四条评论：去 crowdwide.run.place 注册过账号的，有几个？
评论区比产品活跃，从来不是产品的好消息。