一个人从0到1做AI产品，我踩过的坑比写过的代码多

16年移动前端，第一次独立做AI产品。
从"想做论文摘要"到"做决策过滤器"，从画功能全景图到砍到只剩一个核心功能，从纯开发思维到被产品思维反复打脸。
这篇文章不推销产品，只复盘过程中的真实决策和踩坑。

---

一、起因：不是因为AI火，是因为自己痛

做 TLDR Scholar 之前，我做了16年移动前端开发。写代码没问题，但一直觉得自己缺一个东西——产品判断力。每次拿到需求文档就是"怎么做"，很少想"该不该做"。

今年开始往产品经理方向转型。学了理论，看了书，但纸上得来终觉浅。你需要一个真实的战场。

为什么选论文速读这个方向？

因为我自己的痛点太真实了。转型过程中需要大量阅读AI/ML方向的论文，每篇摘要读3-5分钟，经常读完发现跟自己要找的东西没关系。更惨的是精读了一篇觉得方法不错，花两天尝试复现，结果代码不开源、关键参数缺失——两天白费。

这种"读了半天发现不该读"的经历，一个月来好几次。

痛点够痛，方向够具体，一个人能做——三要素齐了，开干。

回头看，这个起点本身就有个坑： 我以为自己痛的就是用户痛的，但"我"的样本量是1。后面验证下来，大方向没错，但很多细节假设是错的。这是后话。

---

二、定位之痛：从"论文摘要"到"决策过滤器"，差点做了个没人用的东西

第一次方向：做一个"AI论文摘要工具"

这是最直觉的方向。市面上已经有不少AI摘要工具了——丢一篇论文进去，输出300-500字摘要，涵盖背景、方法、结果、结论。

我一开始就是这么想的。甚至画了个功能全景图：摘要、翻译、问答、笔记、知识图谱……功能列表拉出来，自己看着都吓人。

然后我停下来了。问了自己一个问题：300字AI摘要和400字原文摘要，对用户来说有什么本质区别？

读完400字原文2分钟，读300字AI摘要1.5分钟——省了30秒。但认知负荷没本质变化，你依然要从这段话里"提炼"关键信息。这不叫提效，这叫微调。

更关键的是：市面上已经有几十个AI摘要工具了，我做一个第31个，意义在哪？

第二次方向：做"一句话总结"

Semantic Scholar的TLDR功能给了我启发——他们用20个词总结一篇论文，不是为了让你"了解论文内容"，而是帮你"快速判断论文相不相关"。

20个词的总结和200个字的摘要，服务的是完全不同的目的。前者是决策过滤器，后者是论文缩写版。

我回过头看自己的痛点：我缺的不是"更短的摘要"，而是"帮我快速判断值不值得读"。

定位从"帮你读论文"变成了"帮你判断论文"。 一字之差，产品逻辑完全不同。

转向之后发生的事

定位一变，功能设计跟着全变了：

• ❌ 长摘要 → ✅ 一句话总结
• ❌ 全面覆盖 → ✅ 只输出决策相关信息
• ❌ 功能全景图 → ✅ 一个核心功能做到位

这个转向救了产品。如果还是做"AI论文摘要工具"，我大概率会淹没在同质化产品堆里，做出一个60分的东西，然后没人用。

踩坑总结： 很多独立开发者（包括我）的第一个直觉是"做一个大而全的东西"，觉得功能越多越有竞争力。但真相是——功能越多，每个功能越平庸，核心价值越模糊。一个人做产品，资源有限，砍功能比加功能重要100倍。

---

三、技术选型的取舍：前端人怎么做AI产品

先说我的技术背景：16年移动前端，React Native、Flutter、小程序都写过。后端不是完全不会，但不是强项。

做AI产品，技术选型要回答三个问题：

1. AI能力怎么做？

三个选项：

方案	优势	劣势
自己训练模型	完全可控	成本高、周期长、一个人搞不定
调用大模型API	快速验证、灵活	依赖第三方、token成本
开源模型本地部署	数据隐私好	硬件成本、维护成本

作为MVP验证阶段，我的选择很明确：调用大模型API。

这不是技术最优解，但这是时间最优解。一个人做产品，最贵的不是服务器钱，是你的时间。花三个月训模型 vs 花三天调API——后者让你一周内就能验证核心假设。

具体的Prompt工程是核心难点。论文解析不是简单的"帮我总结一下"，而是需要结构化输出——四个维度各自有严格的归纳标准。这花了我大量时间调优，从最初的自由生成到后来的结构化Prompt，反复迭代了很多版。

关键决策：不要试图让AI"自由发挥"，要给它明确的框架和约束。 自由生成的信息密度波动太大，无法稳定支撑决策。结构化Prompt + 严格输出格式，才能保证结果的可用性。

2. 前端怎么做？

前端是我的主场，选了React + 现代工具链。没什么纠结的。

但有个容易忽视的细节：论文上传体验。PDF解析是后端的事，但用户在上传阶段的感知全是前端的——文件大小提示、格式校验、拖拽上传、进度反馈、错误状态。这些"小东西"做好了用户觉得理所当然，做不好用户立刻走人。

作为前端出身的独立开发者，这是我能做到超出平均水平的地方。AI产品的核心是AI能力，但用户的体感很大程度上取决于前端交互。

3. 部署怎么搞？

一个人没有运维精力。选了云服务一站式方案，尽量不碰基础设施。

原则：所有非核心的事，都用现成方案。 你是一个人，你的精力必须花在"只有你能做的事"上——产品定义、Prompt调优、用户洞察。服务器配置、CI/CD、运维监控……能托管就托管，能用SaaS就用SaaS。

踩坑总结： 技术选型最大的陷阱不是"选错技术"，而是"在技术上花太多时间"。独立开发者的时间分配应该是：产品思考50% > 核心实现30% > 体验打磨15% > 技术基建5%。很多人反过来了。

---

四、产品设计的核心决策：为什么是这四个维度

定位确定了——做"决策过滤器"，帮用户判断论文值不值得精读。那下一个问题：判断依据是什么？

这是整个产品最核心的设计决策，也花了我最多时间。

第一版：让AI自由生成

最简单的方案：丢论文给AI，让它自己总结。

问题很明显——不可控。有时候输出"本文提出了一种新方法"你不知道新在哪，有时候"在XX数据集上取得了SOTA"你不知道方法是什么，有时候"研究了XX问题"你连学科领域都不确定。

自由生成的信息密度波动太大。作为"决策过滤器"，输出必须稳定、可预期、每个字段都有明确的决策价值。

第二版：参考学术论文的标准结构

Introduction → Method → Results → Discussion，按论文结构拆解。

比自由生成好，但问题是——这是"论文缩写版"的思路，不是"决策过滤器"的思路。 照搬论文结构，输出的是"论文各部分说了什么"，而不是"帮我做判断的信息"。

第三版：从决策路径反推

我换了个思路：不从论文结构出发，而是从我的决策路径出发。

我自己读论文时，做"要不要精读"的判断，本质上在问四个问题：

1. 这是什么领域的？ → 先判断"跟我有没有关系"
2. 用的什么研究方法？ → 再判断"方法能不能迁移到我的问题"
3. 核心发现是什么？ → 知道"到底说了什么新东西"
4. 能复现吗？ → 最后决定"以什么深度读"

四个维度，层层递进，每个直接对应一个决策节点。

这不是拍脑袋想出来的。我把自己读论文的决策过程拆解了很多遍，也找了几位在读研究生聊他们的判断逻辑，最终收敛到这四个维度。没有冗余——不是"能想到的都加上"，而是"做决策最少需要什么"。

其中"可重现指标"这个维度最不常规，但我觉得最关键。因为可复现性是精读决策的重要输入——花两天精读一篇论文结果发现不可复现，等于白读。如果筛选阶段就知道，完全可以只快速浏览方法思路，不投入精力精读实验细节。

踩坑总结： 产品设计最容易犯的错是"我觉得用户需要XX"。每一个功能点都是假设，必须验证。我验证的方式很原始——拿着几篇论文找人聊，但比"自己拍脑袋"靠谱得多。

---

五、上线即裸奔：一个人做产品的现实

产品上线了。然后呢？

没有用户

上线第一周，访问量：个位数。全是自己测试的。

没有人知道你的产品存在。这是独立开发者最残酷的现实——你花了无数心血做出来的东西，没有分发渠道，没有市场团队，连让目标用户"看到"都很难。

没有反馈

没有用户 = 没有反馈 = 不知道产品做得对不对。

MVP的核心是"快速验证假设"，但验证需要用户数据。没有用户的时候，你只能靠直觉继续迭代，而直觉可能是错的。这是个死循环。

没有退路

团队开发可以AB测试、可以并行、可以有人专门做增长。一个人，同一时间只能做一件事。做功能就没时间做推广，做推广就没时间修bug，修bug就没时间想方向。

怎么破？ 我现在的方法是：

1. 内容驱动：写文章分享做产品的思考，产品自然引出。不是硬推，是让目标用户在阅读中自然接触到产品。你正在读的这篇文章就是这个策略的一部分。
2. 精准渠道：CSDN、知乎学术区、研究生社群——痛点最集中的地方。不撒网，只去鱼多的地方。
3. 把冷启动当产品问题而非营销问题：冷启动的本质不是"怎么获取用户"，而是"怎么让第一批用户觉得值"。产品本身的自传播力，比任何推广手段都重要。

一个人做产品的心理建设

说实话，这个过程比写代码难多了。写代码有明确的对错——跑通了对，报错了改。做产品面对的是不确定性——方向对不对？功能够不够？用户会不会来？这些没有标准答案。

最难的不是技术实现，而是在没有人告诉你对错的时候，依然能做决策并推进。这是开发者转产品最难跨越的一步。

---

六、那些我一开始没想清楚的事

复盘下来，有几个地方是后视镜里才看清的：

1. “我的痛点"≠"用户的痛点”

我因为复现论文踩过坑，所以觉得"可重现指标"很重要。但后来聊了几个用户，发现不做复现的人确实不太在意这个维度。

解决方案不是砍掉——因为做复现的人对它的需求非常强烈——而是在产品呈现上降低视觉权重，让不关心的人可以忽略，让关心的人一眼看到。

教训： 你的痛点只是假设的起点，不是假设本身。从"我觉得"到"验证过"之间，有很长一段路。

2. 一句话总结的质量是生命线

"决策过滤器"的价值完全取决于输出的质量。如果总结不准确，用户做了错误的筛选决策，比没有工具还糟糕——因为你会基于错误信息做出判断。

Prompt调优花了我远超预期的时间。从最初的"帮我总结这篇论文"到现在的结构化多轮Prompt，至少迭代了20+版。而且质量不是"60分就够"——对于决策工具，60分意味着40%的时候在误导用户，这是不可接受的。

教训： AI产品的核心不是"能不能用"，而是"能不能信"。信任建立很难，崩塌很容易。

3. 独立开发者的时间分配是个零和博弈

做功能 vs 做推广 vs 做内容 vs 优化体验——每一项都很重要，但同一时间只能做一项。我前期的分配有问题：花了太多时间在功能迭代上，推广几乎为零。

教训： 产品做到70分就应该开始推。等做到90分再推，可能已经没有力气推了，而且70分和90分对用户来说差别没那么大——能解决核心问题就行。

---

七、下一步：不急，但要清醒

TLDR Scholar 目前还在迭代。核心功能已上线：上传论文 → 输出四维度一句话总结，30秒出结果。

后续规划的方向有几个，但我不急：

• 批量处理：一次上传多篇论文，快速分类筛选——这是被用户问得最多的功能
• 个性化维度：不同研究方向关注的维度不同，允许自定义——需要更多用户数据才能做好
• 论文对比：同一方向多篇论文的核心发现横向对比——从"单篇决策"到"多篇决策"

但这些都还是假设，需要验证。我不会再犯"功能全景图"的错误了。

一个人做产品，最重要的能力不是"能做什么"，而是"不做什么"。

---

写在最后

从移动前端转型做AI产品，这条路不容易。16年的开发经验给了我执行力，但产品判断力是另一门课——只能在实战中学。

TLDR Scholar 不完美，但每一步决策都是认真想过的。做出来的不一定对，但至少不是拍脑袋的。

产品地址：https://www.tldrscholar.cn

如果你也在做独立开发，或者正在转型路上，欢迎交流。独立开发者最需要的不是鼓励，是真实反馈——哪怕是骂你的。

---

#独立开发 #AI产品 #从0到1 #产品复盘 #论文速读