从 0 到 1 做一款简历小程序：我的开发过程与心得
这是一篇关于独立开发一款简历相关小程序的复盘与感受。会聊一点技术上的取舍和踩坑，也会聊过程里的真实状态——纠结、返工、和第一次跑通时的松一口气。如果你也在考虑做自己的小程序，或者对「一个人从想法到上线」感兴趣，希望这篇能给你一点共鸣。
一、为什么想做这件事？
做开发久了，总会被朋友问：「帮我看看简历呗」「有没有好用的简历工具推荐一下？」
用了几款产品之后，我的感受是：要么功能堆得太多、用起来很重，要么模板长得都差不多，很难找到「刚好够用、又有点个性」的那种。加上自己一直想正儿八经做一个小程序练手，就动了念头：能不能自己做一个小而专的简历工具？
想法很简单：用户进来，填一填、选个模板、看看建议，最后能导出一份像样的 PDF。不追求大而全，就把这一条链路做顺。于是就有了「简小匠」这个项目。
真正动手是一个周末的下午，打开开发者工具、建项目、搭页面骨架。那时候还没想清楚要多少模板、导出要怎么做，只知道：先让「填完能导出一份东西」跑起来再说。 这种「先跑通再打磨」的节奏，贯穿了整个开发过程。
二、从「想做得很多」到「先做透一条线」
一开始列需求的时候，很容易什么都想加：多套模板、各种分析维度、一堆导出格式……列完自己都心虚：一个人做得完吗？
后来逼着自己做减法。问自己：用户最核心要完成的事是什么？ 无非就是：填好简历 → 看到效果 → 得到一点改进建议 → 能导出用。先把这条线打通，再谈别的。
所以第一版就死死盯住「填写 → 预览 → 简单优化建议 → 导出」这一条。模板也只保留了几种风格差异明显的，避免用户选花眼。事实证明，先让主流程跑顺，比堆功能重要得多。
三、开发过程中最耗心力的部分
3.1 「预览」和「导出」必须长得一样
这是整个项目里我花时间最多、也最较劲的地方。
用户在小程序里看到的预览，和最后导出的 PDF，如果风格、排版不一致，体验会非常割裂，甚至会有「被忽悠」的感觉。所以从第一天我就给自己定了个原则：预览长什么样，导出就得是什么样。
听起来简单，做起来要反复对齐：两边的布局、字号、颜色、分割线，都要一点点对。技术上说，这是两套完全不同的渲染环境——一端是小程序里的布局和样式，另一端是服务端按坐标和字体画出来的文档。两边没有「共享一套样式」的天然机制，只能人工对齐：改一边就要想到另一边，字体、行距、边距、颜色，一个不对就会露馅。
中间有几次为了「好看」在预览里加了一些小装饰，结果导出端实现起来要么成本高要么效果不对，最后干脆把这些都砍掉了，保证两边用同一套视觉语言。虽然少了一点花哨，但用户拿到手的和看到的完全一致，心里更踏实。
这件事给我的教训是：在「炫」和「稳」之间，优先选稳。 尤其是导出这种「交付物」，一致性比多一个装饰重要得多。
3.2 水印：从「能看」到「像样」
导出时带水印是早就想好的，但第一版就是页面中间一个大字，转个角度，看起来比较糙。后来参考了一些文档类产品的水印样式，改成了整页均匀铺开、不抢内容但又能看清的那种效果。前后改了好几版，才觉得「像样」了。
过程里会不断纠结：太淡了起不到标识作用，太浓了又影响阅读。最后是在「能看清」和「不打扰」之间取了一个平衡。做产品很多时候就是在做这种取舍，没有标准答案，只能多试几次，找到自己觉得舒服的那个点。
3.3 功能多了，反而要收一收
有一段时间我加了不少「看起来有用」的东西，比如更多模板、更多样式细节。加着加着发现：选项一多，用户反而不知道选啥；而且自己维护成本也上去了——每多一个变体，预览和导出都要多维护一份一致性。
后来狠心做了一轮精简：把风格接近的模板合并或删掉，只留差异明显的几款。少而清晰，比多而模糊要好。 对用户是这样，对自己开发也是这样。
四、技术上的几点体会
选型时的一些考虑，用比较概括的方式说一下，方便同路人体会，又不至于变成「照着做就能抄」的教程。
前端：小程序原生就够用。简历这种表单+展示的场景，不需要复杂状态和跨端，原生写起来直接、包体也小。把数据流想清楚：本地存什么、什么时候同步、预览和导出各读哪份数据，后面会少很多坑。
后端与导出：小程序端不能直接生成 PDF，只能把数据交给服务端，在服务端用文档库按页、按坐标画出来，再把文件地址或流返回。这里会碰到字体（中文要自己挂字体）、多页排版（内容超出一页时要算分页）、超时（生成慢的话要设好超时和重试）。云函数有冷启动，第一次调用会慢一点，可以在文案上稍微引导用户「首次生成可能稍慢」。
数据与调用：表单数据从端上发到云函数，云函数里再调别的服务（比如 AI 或文档生成），最后把结果回给端。链路过长时，错误要可感知、可重试：网络抖一下、某个服务慢一点，用户不该只看到一个「失败」。能重试的重试，不能重试的给明确提示，比泛泛的「请求失败」好很多。
整体感受是：个人项目，选「够用 + 省心」的技术，比追新追全更重要。 先把东西做出来、让人能用上，再考虑优化和扩展。
五、过程里的一些真实瞬间
写代码之外，有些时刻记得比较清楚。
有一次为了对预览和导出的一个细节（某条线、某个间距），反复改了好几版，在真机和模拟器之间来回切，最后对齐的那一刻，有种「终于不用再惦记这件事」的解脱感。独立开发就是这样，没有别人帮你兜底，每一个细节都是自己跟自己在较劲。
还有一次是主流程第一次完整跑通：填完表单、点预览、再点导出，文件真的出来了。虽然样式还很丑、水印也很糙，但**「从想法到能用的东西」这条线通了**，后面的迭代才有底气。
也遇到过「加了很多东西之后发现不对」的阶段。当时有点舍不得删，但后来想明白：留着的成本是每次改都要多考虑一堆分支，用户反而更懵。 做减法那几天心里会有点空，做完发现产品更清晰了，自己也更敢继续加真正有用的东西。
如果你也曾在周末或晚上一个人对着一个小需求反复改、或者纠结要不要砍掉某个「做了很久」的功能，这种状态大概很多人都经历过。把主流程做稳、把一致性做好，比堆特性更值得花时间。
六、一个人做项目的心得
- 先有一条能闭环的主流程。 从进入小程序到导出 PDF，中间每一步都要能走通。主流程不稳，后面加再多功能都是虚的。
- 预览和最终结果一致，是信任感的基础。 用户看到什么，拿到手就是什么。技术上就是两套渲染要人工对齐，费心但必要。
- 做减法比做加法难，但更值得。 想加的东西可以列一长串，敢删、敢合并，才能让产品更清晰。
- 云开发对独立开发者很友好。 不用管服务器，专注在产品和交互上，上线门槛低很多。
- 小程序的「轻」是优势。 不追求大而全，把一个小场景做透，用户反而更容易记住你。
七、写这篇文章的初衷
这个项目从想法到能上线用，前后断断续续花了挺长时间。过程中有纠结、有返工，也有「这样才对」的瞬间。写这篇，是想把过程、感受和技术上的取舍记下来，既不是功能说明书，也不是手把手教程——更多是「一个人做一个小程序会经历什么」。
如果你也在做自己的小程序、或者打算从 0 做一个副业项目，希望你能从里面得到一点「原来大家都会这么想」的共鸣。
如果你刚好在找工作、需要写简历，也欢迎来体验一下「简小匠」—— 微信里搜一搜就能找到。
感谢掘金这个平台，让开发者有机会把经验和感受分享出来。文中有不严谨的地方，也欢迎大家在评论区一起聊聊。
关于「简小匠」
一款专注简历填写、预览与导出的小程序，支持多种模板和简单优化建议。微信搜索「简小匠」即可使用。
