最近一周，我用 AI 修了哪些真实问题
最近一周，我用 AI 做的事，没有太多“炫技感”。
更准确地说，是把一些真实产品里会影响用户体验、交付节奏和后续维护的问题，一个个拆开处理掉。
这也是我现在对 AI 协作最大的体感：它不只是写代码工具，更像一个能陪我把混乱问题整理成执行路径的开发搭档。
小文案背后，是现场流程
膳云 MakanCloud 里有一个 POS 扫码点单场景：桌台服务、先下单后付款。
原来的提示是“下单成功”。这句话本身没错，但在真实门店流程里不够清楚。顾客完成扫码点单后，还需要到柜台付款。如果系统只说“成功”，前台、顾客、服务员之间就可能多一次解释成本。
所以这次我让 AI 协助把提示调整为“下单成功，请到柜台付款”，并同步处理中英文内容。
这类改动看起来很小，但它解决的是产品和线下流程之间的缝隙。
权限问题不能靠感觉放过
另一个更关键的问题是：订阅逾期后，用户仍然可以登录并正常使用功能。
这不是简单的界面问题，而是产品边界和权限控制问题。我的做法不是直接让 AI 改代码，而是先让它帮我整理下一步：
- 哪里需要判断状态
- 哪些入口可能绕过限制
- 修完后要怎么验证
等问题拆清楚，再进入修复、提交、打标签和部署。
这一轮让我更确定一件事：当问题有一点复杂度时，AI 最有价值的不是立刻给答案，而是先帮我形成一份可执行的检查清单。
扫码点单的刷新，是移动端体验问题
还有一个问题发生在扫码点单：不同手机扫描同一张桌台二维码后，公共点单内容不会自动刷新；在苹果手机上，页面又缺少明显的手动刷新入口。
这类问题很容易被误判成“小 bug”。但真实体验里，它会影响多人点单的协作感：A 点了菜，B 看不到；页面没更新，用户也不知道该怎么办。
这次处理的重点，是同时考虑自动刷新和手动兜底，而不是只修一个表面现象。
新项目先设计协作框架
除了膳云，我还用 AI 做了一个算命网站/App 的产品框架设计。
这次没有急着让 AI 直接写完整功能，而是先让它输出后续开发可用的框架文件：每一步做什么、如何测试、如何验收、下一段 AI 对话如何继承上一段的结果。
后面还顺手修了一个页面显示问题，并补全出生地选项里缺失的大量中国城市。
这件事给我的提醒是：如果一个项目要长期和 AI 一起做，最该先建设的不是某个页面，而是协作方式本身。
结尾
这一周下来，我对“最近我用 AI 做了什么”的答案其实挺朴素：修提示、修权限、修刷新、搭框架。
它们都不是特别夸张的功能，但都在解决真实问题。
如果你也在用 AI 做产品或开发，可以留言说说：你现在最希望 AI 帮你解决的是写代码、排查问题，还是规划下一步？