半年前，一个能将论文转化为Galgame的软件悄然问世，当时许多人视其为一场玩笑。但如今，它已积累了十万用户，并即将登陆Steam平台。这背后，是一位独立开发者从零起步的探索历程，也是关于Vibe Coding、用户需求以及产品打磨的真实记录。

编程之路的起点

编程生涯始于高考结束后的那个暑假。彼时还是完全的新手，跟随网上的教程，从最基础的Python入门。看不懂报错信息，配置不好运行环境，教程中能顺利运行的代码，自己一写就问题频出——这些挫折几乎是每位初学者都会经历的必经阶段。

进入大学后，开始接触人工智能，并首次意识到大模型可能彻底改变软件开发的方式。那时尝试让AI协助编写代码、分析错误信息、解释相关概念。当时的AI代码工程远不如现在成熟，只能依靠最原始的方法——把代码发送给GPT，再粘贴回来。正是通过这种“土办法”，逐渐熟悉了AI的能力边界。

后来陆续完成了一些小项目，例如AI Gal、AI主播等。但现在回顾，当时的开发水平确实有限，许多功能仅是勉强运行，代码质量不高，架构和安全意识都很薄弱。更多时候是：有了想法，让AI先写一个版本，能运行就先运行着。在那个阶段，对开发的理解还很浅显，觉得能做出一个页面、功能可以点击、数据能够显示，就已经很了不起了。

直到开始开发Paper2GalGame，尤其是用户数量逐渐增多之后，才真正意识到：一个能上线、能长期运行、能服务大量用户的产品，与一个Demo完全不是一回事。

Paper2GalGame 的诞生

这个创意最初源于学校实验室。大学期间加入了一个实验室（就读于二本院校的机械设计专业，与计算机、人工智能几乎毫无关联）。和很多同学一样，导师会布置阅读论文的任务，并在周会上交流心得。起初确实认真阅读，但真正读起来才发现，这件事比想象中痛苦得多。许多论文动辄几十页，充满了公式、图表、专业术语，以及大量的前置知识。有时看了一下午，感觉自己一直在看，但真正理解的内容并不多。遇到复杂的推导时，经常看着看着就走神了，一页还没看完，人已经开始犯困。即便使用翻译工具辅助，效果也不明显。

那时就在思考：既然AI已经能够理解论文内容，为什么不让AI用一种更有趣的方式陪着我阅读论文？为什么阅读论文一定要打开一个PDF，然后一个人痛苦地从头读到尾？本身就喜欢Galgame，加上有开发AI Gal的经验，突然萌生了一个有点大胆的想法：如果把论文变成一部Galgame，会怎么样？不是简单地让AI总结一下，也不是把PDF丢进去生成几段摘要，而是让一个角色陪着一起读。她可以解释论文背景，讲解公式和图表，遇到看不懂的地方可以随时向她提问。整个过程不再像是在啃一篇冷冰冰的论文，而像是在和一个角色共同探索知识内容。

这个想法听起来有些奇特，甚至有点不正经。但越想越觉得有意思——因为它解决了一个非常真实的痛点：很多人不是不想学习，而是传统的学习材料太难坚持下去。论文尤其如此。

于是开始尝试将这个想法变为现实。第一个版本其实非常简陋，界面不美观，功能很少，许多地方只能算是“能运行起来”。解析效果也一般，有时论文中的公式会乱码，有时图片会丢失，角色也没有配音。但那时已经很开心了——至少把脑中的想法变成了一个可以完整体验的作品。对于一个开发水平并不高的人来说，这已经是很大的一步。

随后将它发布了出去。没想到的是，真的开始有人使用了。有人用它阅读论文，有人用它看教材，有人用它学习技术文档。后来还有些海外用户，将它分享到Reddit、X、Discord等社区。用户数量越来越多，Paper2GalGame也慢慢从一个小Demo，变成了一个真的有人每天在用的产品。

但用户一多，问题也开始集中爆发。以前只有自己使用的时候，很多Bug根本发现不了。一旦有大量用户上传各种各样的文档，使用各种各样的浏览器、设备、语言环境，问题就全都显现出来了。有些论文格式特别复杂，有些PDF结构很奇怪，有些用户网络环境不好，有些手机浏览器兼容性有问题。还有语音、登录、角色、数据库、文件存储、权限管理，各种各样的问题。那段时间，每天打开服务器后台，基本都能看到新的报错。有时候上午刚修完一个Bug，下午又出现三个新的。有一次只是一个很小的改动，就把整个解析流程搞崩溃了。还有一些问题特别难以复现，用户那边出错，自己这边怎么测试都没问题。这种时候就只能一点一点查阅日志，一点一点推断原因。

这半年下来，编写新功能的时间可能还没有排查Bug的时间多。但也正是因为这些Bug，才真正开始理解什么叫做产品开发——不是写出一个功能就结束了，而是要让这个功能在真实用户、真实环境、真实流量下，还能稳定运行。这才是最困难的部分。

从纯前端 Demo 到完整后端

Paper2GalGame最初更像是一个纯前端应用，很多东西都在浏览器中完成。当时觉得这样很简单，目标不是做一个特别复杂的系统，而是先让它跑起来，看看是否有人真的需要这个东西。但随着用户越来越多，很快发现纯前端是不够的。系统需要包含用户体系与数据库，支持文件上传和论文解析任务，具备角色管理与权限控制，能处理语音资源，并记录完整的操作日志。同时，后端要有消息队列来处理异步任务，接入错误追踪系统，并在整体架构上做好安全防护。这些东西，才是真正让一个产品变得复杂的地方。

后来一直认为，Vibe Coding开发者真正的分水岭，不是能不能做出一个好看的页面——现在AI做页面已经很快了，给它一个描述，就能生成一个看起来不错的界面。真正的分水岭，是能不能搭建起一个完整的后端系统。因为后端决定了这个产品能不能真的服务用户，能不能安全存取数据、处理文件与论文解析、管理用户权限、支撑语音、用队列扛流量、靠日志快速排错。

Paper2GalGame就是这样一步一步演变过来的。从最开始一个能跑的前端Demo，慢慢变成一个有完整后端、有用户系统、有角色系统、有语音资源管理、有文档解析流程、有错误日志和安全加固的产品。这个过程非常痛苦，因为并不是一开始就懂这些知识，很多概念都是后来被问题逼着学习的。比如接口为什么会被刷，为什么要做限流、权限校验，为什么需要日志，为什么上传文件要做检查，为什么有些任务不能同步执行，为什么用户变多以后，很多一开始看起来没问题的设计都会变成隐患。这些东西，如果只是看教程，可能没有那么深的感受。但当产品真的被人攻击过、被人恶意请求过、被各种扫描工具扫过，就会突然意识到：原来上线一个产品真的不是写完代码就结束了。安全、稳定、运维，都是产品的一部分。

Paper2GalGame被攻击过很多次。有接口被刷，有恶意请求，有各种奇怪的漏洞扫描，也有人试图绕过一些限制。刚开始遇到这些事情的时候很慌张，因为以前完全没有处理过。但后来也只能逼着自己学，和AI一起分析日志，请教身边的一些专业人士，讨论可能的风险点。加权限，加限制，加校验，调整接口设计，优化后台错误记录。慢慢地，整个系统才变得更稳定。

对 Vibe Coding 的理解变了

现在很多人谈论Vibe Coding，但我认为大家对其存在一个很大的误解。很多人觉得Vibe Coding就是打开AI，然后对它说“帮我写一个网站”、“帮我做一个功能”、“帮我修一个Bug”，然后AI给出代码，复制粘贴，结束。但实际体验完全不是这样。至少对于一个真正要上线、要长期维护、要服务大量用户的产品来说，Vibe Coding不是简单命令AI干活，它更像是一种和AI深度协作的开发方式。

很多时候，我不会一上来就让AI写代码，而是先和它讨论：这个功能应该怎么设计？有没有更好的架构？这样做以后会不会有安全隐患？用户变多以后会不会有性能问题？这个方案的缺点是什么？还有没有其他实现方式？现在遇到这个Bug，可能的原因有哪些？如果让你从头设计，你会怎么做？很多时候，和AI讨论半个小时，真正写代码可能只需要十分钟。因为真正重要的不是那几行代码，而是有没有想清楚这个功能为什么要这样做，有没有考虑边界情况，有没有考虑未来扩展，有没有考虑安全和稳定性，有没有知道出了问题应该怎么查。

AI很强，但它不是永远正确。它也会一本正经地胡说八道，也会给出看起来很合理、实际上有问题的方案。所以最终做决定的人，还是开发者自己。Vibe Coding并没有降低学习的重要性，恰恰相反，它让学习变得更快了。以前遇到一个不懂的概念，可能要看很多教程、查很多资料，才能建立起整体理解。现在可以直接和AI对话，不断追问，让它举例，让它比较不同方案，让它指出风险，让它帮助从一个完全不会的人，慢慢建立起系统性的认知。但前提是，不能只把它当成代码生成器，要把它当成一个技术伙伴，一个老师，一个可以不断讨论方案的人。真正有效的Vibe Coding不是“我命令AI帮我干活”，而是“我和AI一起把问题想清楚”。这两者差别非常大。

现在 AI 产品这么多，怎么杀出来？

现在Vibe Coding越来越普及，AI让开发门槛越来越低，每天都会有大量新产品出现。很多人可能一天就能做出一个小工具，一周就能上线一个网站。所以问题来了：当AI产品这么多的时候，一个独立开发者怎么脱颖而出？

到目前为止的答案是：一定要抓住一个非常具体的用户群体，解决他们非常具体的痛点。不要一上来就想做一个所有人都能用的平台，也不要只是因为某个AI技术很火，就做一个泛泛的AI工具。因为这样的产品太多了，用户为什么一定要用你的？你要找到的是一群真的每天都被某个问题困扰的人，他们的问题越具体，越容易做深。

Paper2GalGame就是这样来的。不是因为AI很火所以做了一个AI工具，而是因为自己真的要看论文，知道读论文这件事有多痛苦。知道看不懂公式的时候是什么感觉，知道面对几十页PDF时的压力，也知道很多学生、研究者、开发者并不是不想学习，而是很多内容的阅读体验太枯燥、太难坚持。所以Paper2GalGame解决的不是一个很抽象的问题，它解决的是：能不能让论文阅读变得更有趣、更轻松、更容易坚持？Galgame、角色、语音，这些看起来像是包装，但其实都围绕着同一个目标——让学习更有陪伴感，让知识不再那么冰冷，让用户愿意继续读下去。

这半年越来越相信一件事：Vibe Coding可以帮你快速做出一个产品，但真正决定这个产品能不能活下来、能不能被用户记住的，从来不是AI，而是你有没有抓住一个足够真实、足够具体的需求。先服务好一小群人，把他们的问题解决到极致，他们自然会告诉你下一步应该做什么，也会帮你传播。这比一开始就追求“大而全”，要现实得多。

10 万用户是怎么来的？

很多人问Paper2GalGame是怎么做到10万用户的。其实没有什么特别神奇的增长方法，也没有投什么广告，更多是靠用户自然传播，以及不断更新。最重要的事情有两个：第一，坚持更新。第二，认真听用户反馈。很多现在大家觉得理所当然的功能，其实最开始都不是自己想到的，而是用户在使用过程中不断提出来的。有人反馈语音不稳定，公式显示不好，手机端体验不舒服；有人希望角色更有表现力，支持更多语言，有更方便的开发者工具。这些反馈一条一条积累起来，就变成了后来的更新方向。

Paper2GalGame不是一个人的作品，它更像是一个和用户一起打磨出来的产品。很多时候，用户比开发者更清楚某个功能到底痛在哪里。作为开发者，不能闭门造车，而是要尽量听懂这些反馈背后的真实需求。当然，用户反馈不一定都要照做。有些需求可能不适合当前阶段，有些需求可能会让产品变得复杂，有些需求背后真正的问题和用户提出的解决方案并不完全一样。所以需要判断，需要取舍。这也是做产品最难的地方之一。但总体来说，Paper2GalGame能走到今天，离不开每一个愿意体验、愿意反馈、愿意分享的用户。10万用户这个数字，不仅仅是一个数据，它更像是一个提醒：原来这个看起来有点离谱的想法，真的有人需要。

Paper2GalGame 接下来会怎么做？

接下来，Paper2GalGame会继续围绕几个方向更新。第一，继续提升论文解析能力，尤其是复杂公式、图表、多模态内容、长文档结构理解这些部分，希望能更稳定地处理各种不同类型的论文和文档。第二，继续增强角色体验，包括表情、语音、角色记忆，以及更自然的互动方式和角色的局外养成系统。因为Paper2GalGame的核心不是把论文变成一段摘要，而是把学习过程变成一种有角色陪伴的体验。第三，继续优化移动端和跨平台体验，因为很多用户不一定总是在电脑前学习，手机、平板、桌面快捷方式、App，这些场景都需要更好的支持。第四，推进Steam版本，希望能承载更多游戏化内容，让它更像一个真正的AI学习Galgame平台。第五，继续完善开发者和高级用户工具，比如Paper2Gal CLI，未来也会考虑更多自动化、批量管理和社区创作相关能力。

总之，Paper2GalGame不会只停留在“把论文总结成对话”这个层面，希望它最终变成一个更有趣、更有陪伴感、更适合长期学习的AI产品。

结尾

回头看这半年，最大的感受是：AI并没有让学习变得可以跳过，它只是让有能力把脑子里的想法一个一个变成现实。从高考后开始接触编程，到大一接触AI；从最开始做一些很粗糙的小项目，到后来做出Paper2GalGame；从一个纯前端Demo，到现在有完整后端、用户系统、语音、角色、论文解析、安全加固和Steam计划。这一路真的踩了很多坑，也有很多次觉得自己搞不定。但每一次解决问题之后，都会发现自己又往前走了一点。

所以，如果现在也有一个想做的东西，但觉得自己技术不够、经验不够，可以先从一个很小的版本开始。不要一开始就想着做完美，先让它跑起来。然后不断问、不断学、不断改。AI不能替你走完整条路，但它可以陪你走出第一步。

最后，也非常感谢所有支持Paper2GalGame的用户。谢谢大家这半年提交的反馈、报告的Bug、提出的建议，以及每一次分享。Paper2GalGame能走到今天，不只是因为一个人在开发，更是因为有很多用户一直在使用它、打磨它、推动它变得更好。接下来会继续更新Paper2GalGame，也希望它能从一个把论文变成Galgame的小工具，慢慢成长为一个真正有趣、有人情味的AI学习平台。