夜雨聆风整理手上的 AI 项目时，我重新打开了一个图片去背景工具。
它已经能完成不少事情：上传图片、检查格式、预览效果、比较处理前后、更换背景，再导出常用图片格式。为了避免单一服务临时不可用，项目里还做了多服务商降级和运营状态查看。
功能清单越看越像一个完整产品，可我最后没有把项目状态写成“已完成”，而是写了五个字：上线前验收。
因为做项目做到这里，我越来越清楚一件事：AI 可以很快把功能写出来，但“能运行”距离“能放心交给别人使用”，中间还隔着一段最考验人的路。
AI把开发速度提起来，也会把欲望一起放大
以前做一个小工具，新增功能意味着评估工期、协调开发、安排测试。每一个想法都要掂量一下值不值得做。
有了 AI 编程后，门槛突然低了很多。
想加一个图片拖拽上传，可以试；想增加前后对比，可以试；想支持白色、黑色、自定义背景，也可以继续试。一个需求描述清楚，AI 很快就能阅读现有代码，找出需要修改的位置，补齐页面、接口和说明。
这种速度很容易让人兴奋，也很容易让项目失控。
因为功能做得快，不代表功能就该做。页面上每多一个选项，用户就多一个需要理解的决定；系统里每多一条调用链路，就多一种需要测试的失败方式；每接入一个服务，就多一份配置、额度和稳定性管理。
AI降低了实现成本，却没有替我们降低产品复杂度。
图片去背景工具做到后面，我关注的重点已经不再是“还能加什么”，而是“哪些能力组成最小闭环，哪些问题会让这个闭环在真实使用时断掉”。
第一层验收：用户能不能顺利走完一次
最基础的验收，不是打开首页看见页面正常，而是用一个普通用户的视角，把完整流程走一遍。
他可能点击上传，也可能直接拖进来，甚至从剪贴板粘贴。图片可能符合要求，也可能格式不支持、体积过大或文件本身有问题。处理完成后，他要看懂前后差异，选择透明或其他背景，再导出需要的格式。
这条主流程里，每一步都应该有明确反馈：
图片有没有被正确接收？ 处理进行到哪里，用户要等多久？ 失败时说的是人能看懂的话，还是一串技术错误？ 换背景以后，边缘和透明区域是否符合预期？ 导出的文件，格式、尺寸和背景是否与选择一致？
AI 可以帮我列测试点、补校验、修页面，但最后仍要有人像第一次使用那样去点击、等待、返回和重试。
开发者知道按钮背后发生了什么，所以很容易自动绕过那些不清楚的地方。用户不知道，他只会在某一步卡住以后直接离开。
第二层验收：顺利时能用，出错时会不会失控
图片处理依赖外部能力时，最怕的不是一次明确失败，而是半成功、长时间等待或者结果忽好忽坏。
这个项目设计了多服务商自动降级：一个服务出现问题时，可以尝试其他服务。听起来像是稳定性保险，但真正验收时，问题反而更多了。
什么时候应该切换？超时算失败，还是继续等？前一个服务已经处理但返回中断，会不会重复消耗额度？不同服务的图片边缘效果有差异，系统怎样知道哪一路最近质量不稳定？所有服务都失败时，用户看到什么，运营者又能看到什么？
这些都不是“再写一个接口”就结束的问题。它需要产品、技术和运营一起给出边界。
所以失败路径至少要检查三件事：系统有没有兜底，用户有没有解释，维护者有没有线索。
没有兜底，服务一抖整个工具就停；没有解释，用户只觉得页面坏了；没有线索，维护者连问题发生在哪一路都不知道。
第三层验收：产品能不能被长期维护
一个工具偶尔在自己电脑上跑通，并不等于它适合长期运行。
图片工具还要面对隐私、调用额度、恶意使用和后台权限。项目的设计目标是不由网站主动保存用户上传及处理后的图片，但这句话不能只写在说明里，还要落实在实际链路和日志边界中。后台需要看到路由、延迟和质量反馈，却不应该因此保存用户原图。
同时，服务商凭证必须留在服务端，管理入口要限制访问，公开页面不能泄露内部配置。额度限制也不能只防别人，还要防一个异常请求把自己拖垮。
到了这一层，验收已经从“功能测试”变成了“运营准备”。我会问：
出现异常时，能不能定位问题而不接触用户原图？ 某个服务不可用时，系统是否按预期降级？ 配置和权限有没有被前端或日志意外暴露？ 部署后是否真的能访问，关键流程是否重新验证过？ 如果明天需要暂停某个服务，有没有安全而清楚的操作方式？
这也是为什么项目目前仍停在上线前验收。功能存在，只能证明开发走到了这里；完成真实部署、按清单走通、确认失败路径以后，才有资格讨论下一阶段。
用AI做项目，人最该守住的是判断权
这次做图片去背景工具，我感受到的 AI 优势非常直接：它能快速理解代码结构，执行明确修改，补齐重复工作，也能在排查问题时提供多个方向。
但它越快，人越要守住三个判断：为什么做、做到哪里停、什么才算通过。
如果没有这三个判断，AI 会成为一台非常勤奋的功能制造机。它不断回应新的想法，项目也不断长出新的页面和按钮，最后却没有一个稳定、清楚、真正可交付的核心流程。
反过来，当目标和验收标准明确以后，AI 的速度才会变成优势。人不必亲手敲完每一行代码，却必须对结果负责：真实用户能不能完成任务，异常情况会不会失控，隐私和运营边界有没有守住。
AI编程真正省下来的，应该是重复实现的时间，而不是思考和验收的责任。
下次再用 AI 做一个小工具，我不会先问它还能生成多少功能。我会先写下三张清单：用户怎样完成一次任务，系统可能怎样失败，上线以后由谁看见并处理问题。
代码写出来，只是项目开始有了形状。
能经得住真实流程、失败和长期维护的检查，它才算真正开始成为产品。
说明：本文基于作者真实项目记录，AI参与资料整理、内容辅助与配图，事实、观点及最终发布均由作者审核确认。
