一、用户会告诉你产品该怎么改简记往来上线后我收到的最有价值的建议几乎都来自用户反馈。用户不会帮你写代码但用户会告诉你“哪里不舒服”。找到“不舒服”的地方就是产品迭代的方向。二、第一批用户反馈怎么这么难用简记往来上线第一周我收到的反馈大多是负面的“记一笔要填3个页面太多了。”“这个按钮点了没反应。”“我不知道怎么查看我记录的东西。”这些反馈让我意识到产品功能没问题但流程有问题。第一轮迭代的核心就是“减少步骤”。把“记一笔”从3个页面压缩到1个页面把入口从二级菜单移到首页底部。三、简记往来的6次关键更新以下是简记往来上线以来由用户反馈驱动的6次关键更新更新一批量记礼容错增强用户反馈“我输入‘张叔叔800’没空格解析不了。”解决方案增加无空格格式支持正则从第一版迭代到第五版。覆盖率从50%提升到95%以上。更新二多人协作权限细分用户反馈“我老婆要帮忙记但她手滑删了一条记录能不能让她只能加不能删”解决方案从两级权限创建者/普通成员改为三级权限创建者/编辑者/只读编辑者只能修改自己的记录。更新三数据导出功能用户反馈“我想把礼金记录导出到Excel备份。”解决方案增加CSV导出功能支持一键导出全部记录。上线后使用率超过30%。更新四多账本模式用户反馈“我既想记日常开销又想记礼金。”解决方案增加日常账本和礼账本两种类型。日常账本按“时间分类”统计礼账本按“人净额”统计两套逻辑完全独立。更新五搜索性能优化用户反馈“搜索名字的时候有点慢。”解决方案优化数据库索引增加(book_id, contact_id)复合索引查询时间从600ms降到80ms。更新六金饰记录支持用户反馈“别人送的金镯子怎么记账”解决方案增加备注字段支持用户输入“克重估价”后续版本增加了图片上传功能。四、关于拍照识别功能——我们为什么没做在迭代过程中有一个需求反复被用户提起“能不能加个拍照功能直接拍一下礼账本自动识别出姓名和金额”这个需求听起来很合理。用户收到一堆红包拍照→识别→自动生成记录——如果真能做出来确实很方便。我们认真对待了这个需求花了近两周时间做了技术调研。测试过程我们拿了几本真实的礼账本做测试——有婚礼现场手写的有满月酒的有年代久远字迹已经模糊的。测试对象包括DeepSeek、文心一言、豆包等主流大模型的图像识别能力同时也测试了几款成熟的OCR商业方案。测试结果并不理想。主要问题出在三个地方第一手写礼账本的字体差异极大。有的人写字工整有的人潦草有的人写的是行书有的人用的是繁体。同一个“张”字在不同账本上有十几种写法。人眼辨认都需要上下文机器更难。第二账本年代久远导致字迹模糊。有个用户提供的礼账本是2008年的纸张泛黄、墨水褪色、页面还有污渍。人眼看都费劲放大镜勉强辨认机器几乎无能为力。第三不同人的书写习惯差异巨大。有的人金额前面加“¥”有的人加“”有的人什么都不加。有的人写“1000元”有的人写“1,000”有的人写“1000.00”。数字格式本身就五花八门再加上手写体的变形识别的错误率远高于可接受范围。综合下来识别准确率不到60%。这意味着每10条记录就有4条是错的用户需要逐条核对修正——反而比手动录入更费时间。为什么选择不做如果是一家大公司资源充足砸钱做算法优化、买算力、养AI团队也许能把准确率提升到可接受的水平。但我们是独立开发者资源有限。如果硬要做这个功能需要投入的成本包括大量的算力成本每次识别都要调用大模型API或OCR服务长期的算法迭代成本不同字迹、不同场景的适配持续的运维成本识别失败后的错误处理和数据修复而简记往来是完全免费的产品没有任何收入来源来覆盖这些成本。把这些资源投入到拍照识别上意味着要牺牲其他核心功能的迭代速度。产品决策的逻辑最终我们决定不做拍照识别功能。这个决策的核心逻辑很简单好钢用在刀刃上。刀刃是什么是批量记礼的准确率、是差额统计的响应速度、是多人协作的权限控制——这些才是简记往来的核心体验。而对于“拍照识别礼账本”这个需求我们的判断是用户真正需要的不是“拍照”而是“快速录入”。批量记礼功能已经解决了“快速录入”的问题——用户把礼单敲成文本一次性粘贴导入几十秒搞定200条记录。这个过程虽然需要手动敲字但录入效率已经足够高而且准确率是100%——机器识别再准也比不上用户自己输入的数据可靠。与其做一个准确率60%的“智能”功能不如把现有的批量录入做到极致。当然随着AI技术的发展和算力成本的下降未来这个决策可能会重新评估。但至少在目前我们选择把精力投入到用户最需要、且我们有能力做好的事情上。五、如何判断哪些反馈值得做反馈类型判断标准处理方式多个用户提到同一个问题需求被验证优先处理单个用户提但影响核心体验问题严重评估后处理与产品定位不符如“能不能加股票功能”偏离核心场景搁置或拒绝技术不成熟、成本过高投入产出比低暂缓或不做六、总结产品迭代的核心不是“加功能”是“解决问题”。用户能告诉你“哪里不舒服”但不能告诉你“应该怎么做”。具体怎么改还是得自己做判断。简记往来的每一次更新都来自用户反馈但实现方式、优先级排序甚至“不做什么”的决策都是基于对产品方向和技术成本的综合判断。听用户的但不全听用户的。做对的决策不是做所有的决策。评论区聊聊你收到过最意外的用户反馈是什么有没有“听起来很好但最终没做”的功能