起点：一个模糊的想法
很多小工具一开始都不是完整产品，而是一句很朴素的话：我能不能把这个重复动作变简单一点？
这次的目标也是这样。先把想法写成一句话，再让 AI 帮我拆成用户场景、功能边界和可交付版本。这个过程的重点不是让 AI 一次写完所有代码，而是让它持续参与判断：哪些功能现在必须做，哪些可以先放后面。
先拆需求，再写代码
我会先让 AI 输出一个很小的 MVP：
- 用户打开就能理解这个工具解决什么问题；
- 核心功能路径不超过三步；
- 不依赖复杂登录或后台；
- 失败时有清楚提示；
- 页面足够轻，手机上也能快速使用。
这样做的好处是，代码实现不会一开始就被复杂设计拖住。先把能用的版本跑起来，再根据真实使用感受继续调整。
AI 更适合做协作工程师
实际开发时，AI 最有价值的地方不是替我“全自动开发”，而是帮我更快完成这些工作：
- 把口语化需求改写成清晰任务；
- 根据现有代码结构找到应该修改的文件；
- 生成第一版实现；
- 帮我检查边界情况和遗漏；
- 把上线前检查整理成清单。
人负责方向和取舍，AI 负责加速执行和补齐细节。这个分工比单纯追求“一句话生成产品”更稳定。
上线前的检查
一个小工具真正可用，通常不只看功能是否跑通，还要看这些细节：
- 空输入、异常输入有没有处理；
- 移动端布局是否舒服；
- 首屏加载是否足够快；
- 隐私风险是否可控；
- 用户是否能马上知道下一步该点哪里。
这些检查不复杂，但很容易被忽略。把它们固定下来，每个新工具都按同一套流程过一遍，质量会稳定很多。
结论
AI 编程不是把工程师替换掉，而是让个人开发者可以用更低成本完成从想法到上线的闭环。对我来说，最重要的是持续把想法做成真实可用的东西，而不是停在灵感和原型里。