为什么我偏爱小而明确的工具
我喜欢从一个具体问题开始：它发生在什么场景，真正让人困扰的步骤是哪一个。边界足够清楚，才知道什么应该做，什么不应该放进去。
小工具并不等于粗糙。相反，它要求我更认真地处理启动速度、反馈、文字和异常状态。没有庞大的功能列表可以遮掩时，每一个细节都会变得更诚实。
开发随笔
Personal notes
开发札记
写下做项目时遇到的问题，以及我当时为什么那样选择。内容不求系统，只求诚实、清楚。
设计笔记
少一点功能，也是一种设计
做个人项目最容易陷入的误区，是不断添加“以后也许会用到”的能力。功能数量增加得很快，真正的使用路径却越来越模糊。
我现在更愿意先确认核心任务，把完成任务需要的步骤压缩到足够短。克制不是做得少，而是让留下来的内容各自有明确的理由。
阶段记录
个人项目教会我的三件事
第一，先解决真实问题，再选择技术；第二，能稳定维护的范围，比一开始的宏大设想更重要；第三，发布不是结束，使用中的反馈才会让判断逐渐可靠。
这些经验没有多么惊人，但它们持续影响着我之后的每一个作品：把范围说清楚，把细节做扎实，也允许项目在合适的时候保持安静。
开发随笔
第一次把工具交给别人使用以后
自己使用时，我会自动绕过不顺手的地方，也知道每个按钮背后的意图。换一个人打开，原本被忽略的问题就会立刻出现：名称是否准确、入口是否明显、失败时有没有说明。
这让我开始把“第一次使用”当作独立场景。少依赖解释，多观察真实操作，往往比继续增加功能更能改善作品。
阶段记录
维护往往比完成更难
写出第一个可用版本需要专注，长期维护则需要节奏。依赖会变化，系统会更新，曾经合理的判断也可能需要重新检查。
我开始为个人项目保留更清楚的记录：为什么这样设计、数据从哪里来、下一次更新前要验证什么。文档不一定很长，但它能帮未来的自己更快回到正确的位置。