10 个小时上线 Product Radar：真正加速我的不是写代码

最近，我用五个晚上的下班时间做完并上线了 Product Radar，总投入大约 10 个小时。

它是一个很简单的产品：从一个真实存在的产品出发，分析它所押注的用户需求、使用场景和解决机制。第一版只有需求分析报告、报告陈列页，以及一条很轻的反馈链路。

10 个小时并不是一个足以让人焦虑的速度。现在用 Claude Code、Codex 或 Vibe Coding 产品，几小时做出并上线一个 Web 应用已经不罕见。

这次真正让我满意的，是产品在两个关键时刻收了回来。最后做出来的东西也没有因为快而变成一个只有页面能跑、内部无法理解的半成品。前端、后端和分析链路都很简单，但完整而有效；领域概念、数据结构和接口契约是对齐的；页面的视觉和阅读体验也比我过去直接让 Coding Agent 自由生成时更接近自己的预期。

这是我第一次用上一篇文章里介绍的 AI-Native 研发方式完整走到上线。这篇想具体复盘，10 个小时究竟花在了哪里。

最开始，我只有一种模糊的感觉

我一直有一种焦虑：我不知道社会上正在出现什么需求。

对于创业早期的人来说，这件事很现实。你想做产品，却不知道大家正在为什么问题花时间和钱，也不知道市场上的产品分别在押注什么变化。

但一开始，我并没有把问题说得这么清楚。我只有「想知道外面有什么需求」这种模糊感觉。在这种情况下，脑海里最先出现的自然是一组功能：

• 持续发现新产品；
• 让用户搜索产品；
• 用 AI 分析产品背后的需求；
• 推荐近期值得关注的需求和机会。

听起来已经很像一个产品，但其实我只是在想方案。我还回答不了最简单的问题：什么人会在什么场景下遇到什么困难，他为什么需要这个产品，又为什么可能愿意为它付费？

第一次收敛：从发现产品退回到理解需求

在 BRD 阶段，我和 AI 先围绕用户、场景和痛点反复梳理，再去研究市场上已经有哪些选择。

最后，我把问题收敛成了这句话：

创业早期的人，希望知道市场中正在出现哪些需求，以及现有产品分别在解决什么问题。

这句话看起来没有多大变化，却直接改变了产品的重心。

「发现新产品」不再是价值本身，搜索也不是第一版必须存在的入口。用户真正需要的，是从一个已经存在的产品出发，看清楚它服务谁、发生在什么场景、原来的方式有什么损失，以及这个产品通过什么机制解决问题。

Product Radar 因此不再是一个我最初想象中的「需求发现平台」，而变成了一个更具体的产品：从真实产品反推它背后的用户需求。

这次收敛发生在写大量代码之前。否则我很可能会先搭一套产品采集和搜索系统，再花很多时间解释为什么这些产品值得被发现。

第二次收敛：MVP 只验证报告有没有帮助

问题明确以后，可以做的功能仍然很多。

每日自动挖掘、搜索、推荐、用户输入产品后由 AI 生成分析、账户、历史记录，这些功能都能放进一个完整的产品想象里。而且在 Coding Agent 的帮助下，它们似乎也没有那么贵，很容易产生「顺手一起做了」的念头。

在 MVP PRD 阶段，我继续追问：如果第一版只能验证一件事，最需要知道的到底是什么？

最后答案是：

对一个产品背后需求的分析，能不能帮助我更好地理解这个产品和它所处的市场？

如果报告本身没有帮助，搜索只是让人更快找到一份没有价值的报告，推荐和每日更新则是在持续分发它。用户登录和历史记录也不会让核心价值变得更强。

所以第一版最终只保留了三件事：

1. 产品需求分析报告；
2. 报告陈列和阅读页面；
3. 阅读结束后，直接询问「这篇报告是否帮助你更清楚地理解这个产品背后的需求？」

登录、搜索、推荐、用户自行生成报告都被明确放到 MVP 之外。

现在网站上只有小红书、Manus、Tencent WorkBuddy、Codex、Replit 和 Lovable 等几份报告。数量并不多，但已经足够让我开始判断：报告的分析框架是否成立，结论是否清楚，读者看完有没有得到新的理解。

UX 对齐让我没有停在「功能正确」

MVP 确认以后，我没有直接让 Coding Agent 按 PRD 自由生成网站，而是继续做了一轮 UX 对齐。

这个产品的路径很短：用户进入首页，看到一组报告，打开其中一份，完成阅读，然后给出反馈。正因为短，每一个页面决定都直接影响用户是否能理解产品。

我和 AI 具体对齐了这些问题：

• 首屏怎样用一句话解释 Product Radar；
• 卡片上应该先呈现产品名称，还是需求结论；
• 用户从卡片进入完整报告时，怎样保持阅读上下文；
• 报告标题、产品摘要、需求结论、研究日期和证据怎样组织；
• 加载、空数据、请求失败和报告不存在时分别怎样表现；
• 用户读完以后，怎样用尽可能低的成本留下反馈。

最后的页面并不复杂，也没有为了显得像一个「正式产品」加入多余的导航和功能。首页只有一句「从真实产品出发，理解它们在解决什么需求」，下面直接陈列报告。打开报告后，最先看到的是「从某个产品看：某种需求」，再进入完整分析。

我对第一版的视觉体验是满意的。它不是因为用了多复杂的设计，而是页面层级、信息密度、阅读路径和状态处理都经过了具体选择。相比我过去直接使用 Claude Code，或者让 Vibe Coding 工具自由生成页面，这一版更像是我自己做出的产品。

上线以后，我也没有马上补搜索和登录。现在主要精力仍然放在产品需求分析报告的优化上，因为那才是 MVP 真正要验证的东西。

快速上线没有让我失去对工程的理解

我对这次结果满意的另一个原因，是它不只是一个前端 Demo。

Product Radar 的前端、后端和分析链路都做了完整实现：

• 前端负责报告陈列、阅读交互、各种页面状态和反馈入口；
• 后端提供报告列表、报告详情、访问、阅读会话和反馈等清晰契约；
• 分析链路负责调研真实产品，并产出结构一致的需求分析报告；
• 数据结构围绕报告、阅读和反馈这些 MVP 概念展开，没有混入暂时不存在的账户、推荐和生成任务。

这些部分都不复杂，甚至可以说很朴素。但它们共同实现了一个完整闭环：报告被生成和发布，用户可以发现并阅读，系统知道一份报告是否被打开、有效阅读了多久，以及读者是否认为它有帮助。

更重要的是，我做完以后仍然知道每一部分为什么存在。

以前用 AI 一把梭哈实现产品时，我经常面对一种尴尬：页面已经出现，代码也有很多，但我说不清领域边界在哪里，前后端依赖什么契约，一个问题究竟来自交互、接口、数据还是生成逻辑。继续迭代时，只能再让 AI 读一遍代码，猜测应该修改哪里。

这次的顺序反了过来。先确认产品问题和 MVP，再对齐领域、UX 和架构，最后进入实现。Coding Agent 当然仍然写了大量代码，但代码在表达一组我已经理解并确认的决定。

所谓工程上的「完整」，对这个小产品来说并不是服务多、抽象多，而是三个很基本的要求：

• 领域里的概念在前端、后端和数据中指向同一件事；
• API 的输入、输出和失败行为清楚，前端可以据此处理完整状态；
• 出现问题时，我知道应该沿着哪条链路定位，而不是把整个代码库重新交给 AI 碰运气。

它依然是一个很小的系统，但不是代码黑箱。这一点对后续迭代很重要。

产品和内容暂时是同一条验证链路

第一版没有搜索和推荐，怎样获得用户？

我现在的做法也很简单。一方面，我自己就是报告的第一位消费者。我会实际阅读这些分析，判断它是否帮助我理解一个产品背后的需求，再持续调整报告结构、研究证据和结论表达。

另一方面，每份报告都可以继续转成小红书内容。读者可以先在内容平台看到一个具体结论，感兴趣时再进入 Product Radar 阅读完整报告。

所以现阶段的链路是：

生成并消费报告
  → 把有价值的结论做成内容
  → 吸引第一批读者阅读完整报告
  → 收集是否有帮助的反馈
  → 继续优化报告

内容不是产品完成以后另外开始的一项运营任务，而是 MVP 获得第一批用户和验证报告价值的一部分。至少在现在这个阶段，我不需要先做一个复杂的站内发现系统。

真正节省的，是在错误方向上实现的时间

回看这五个晚上，AI 确实加快了研究、设计和编码。但真正决定产品形态的，是编码之前的两次收敛。

第一次，我从「想发现社会上有什么需求」退回到一个具体问题：创业早期的人怎样从现有产品理解市场需求。

第二次，我从搜索、推荐、生成等大量可能性里，只留下一个需要验证的核心：需求分析报告是否真的有助于理解。

后面的 Domain Model、UX 和 Architecture 没有让产品变重，反而让前端、后端和分析链路都围绕这个核心保持简单。UX 对齐也让我得到了一版在视觉和使用体验上更符合预期的产品，而不是接受一个「反正能用」的生成结果。

所以我现在对 Product Radar 第一版整体是满意的。但上线不是成功结论。接下来我不会急着把它扩成一个功能齐全的平台，仍然会把注意力放在报告本身：分析是否足够具体，证据能否支撑判断，结论是否真的帮助创业早期的人看懂需求。

如果这件事不能成立，其他功能都没有意义。如果它成立了，搜索、推荐和用户生成才有继续讨论的基础。