一、用户会告诉你产品该怎么改
简记往来上线后，我收到的最有价值的建议，几乎都来自用户反馈。
用户不会帮你写代码，但用户会告诉你"哪里不舒服"。找到"不舒服"的地方，就是产品迭代的方向。
二、第一批用户反馈：怎么这么难用？
简记往来上线第一周，我收到的反馈大多是负面的：
- "记一笔要填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技术的发展和算力成本的下降，未来这个决策可能会重新评估。但至少在目前，我们选择把精力投入到用户最需要、且我们有能力做好的事情上。
五、如何判断哪些反馈值得做
| 反馈类型 | 判断标准 | 处理方式 |
|---|---|---|
| 多个用户提到同一个问题 | 需求被验证 | 优先处理 |
| 单个用户提但影响核心体验 | 问题严重 | 评估后处理 |
| 与产品定位不符（如"能不能加股票功能"） | 偏离核心场景 | 搁置或拒绝 |
| 技术不成熟、成本过高 | 投入产出比低 | 暂缓或不做 |
六、总结
产品迭代的核心不是"加功能"，是"解决问题"。
用户能告诉你"哪里不舒服"，但不能告诉你"应该怎么做"。具体怎么改，还是得自己做判断。
简记往来的每一次更新都来自用户反馈，但实现方式、优先级排序，甚至"不做什么"的决策，都是基于对产品方向和技术成本的综合判断。
听用户的，但不全听用户的。做对的决策，不是做所有的决策。
评论区聊聊：你收到过最意外的用户反馈是什么？有没有"听起来很好但最终没做"的功能？