夜雨聆风一个很小的工具，第一次让我理解技术结构
这几天我在做第二个小工具，暂时叫「字字复习」。之前大概介绍过背景，是给姐姐用的。姐姐家里有低年级小朋友，语文里有词语表、写字表、识字表，家长每天要听写、复习、记录错字。这个需求本身不大，看起来只是一个小学生生字复习本，但真正做下来，我反而第一次比较完整地体验了一次“技术视角”。以前我更多是在想产品问题，比如这个需求真不真实，用户会不会用，页面是不是好理解。现在我开始关心另一层问题：这个功能依赖什么，数据应该放在哪里，如果某个能力没接好，整个主流程会不会被卡住。
技术视角不是写代码，而是拆清楚依赖
我以前会把一个网页工具看成一个整体，好像页面能打开、按钮能点，就算差不多了。但这次我才慢慢意识到，一个很小的工具背后也有好几层：前端负责展示和操作，数据库负责保存课文、生字、错字和复习记录，登录负责区分不同用户，OCR 负责降低录入成本，部署负责让别人真的能打开使用。这些东西最后当然要连在一起，但在早期不能混在一起验证。技术视角对我来说，不是突然学会了多少代码，而是开始能看清楚一个系统由哪些部分组成，以及每一部分和主流程之间是什么关系。
除了产品 MVP，功能也要拆开验证
这次最明显的例子是 OCR。刚开始我觉得，既然是课本生字表，最好能拍照识别，这样家长录入会轻松很多。于是我去接腾讯云 OCR、云函数、CloudBase 权限和前端调用。技术上不是不能做，但如果一直卡在这个点上，整个工具就推不下去了。后来我先绕开它，用其他 OCR 软件识别，再人工整理成 Excel，把数据导入 demo。这个方案不完美，但主流程可以继续往前走。也是到这里我才更清楚地理解，除了产品上的 MVP，功能本身也要拆开验证。产品 MVP 是验证这个工具对姐姐有没有用，功能验证则是看某个技术模块值不值得接、能不能跑通、会不会拖住主流程。
不是所有自动化，都值得一开始就接上
以前我会觉得，能自动化就应该自动化，能做完整就尽量做完整。现在我会先问一句：这个自动化现在真的值得接吗？它是在帮助我验证主流程，还是让我提前陷进一个技术坑里？「字字复习」现在还不是完整产品，但它已经让我对做工具这件事有了更具体的感觉：先搭出能跑的框架，再拆清楚技术结构和依赖关系，最后判断每个功能什么时候接入。这个小工具不大，但麻雀虽小，五脏俱全。对我来说，它像是一个很小的起点，也是我第一次用非技术人的视角，真正摸到一点技术方案评估的边。
