过去我对 AI 编程的理解，更多是“让它帮我写代码”。
但最近 7 天，我对它的用法变了：我开始把 AI 当成一个可以随时拉进来的协作者，用来拆问题、查原因、补体验、做研究。它不是替我做决定，而是帮我把很多原本混在一起的问题拆开。
先把生产问题稳住
这周最现实的工作，还是处理线上问题。
有一次，商场数据上传时出现错误。另一次，POS 点餐菜单在选择某些产品时会出错。这类问题最麻烦的地方不是“改一行代码”，而是先判断问题到底在哪里：是数据不符合预期、配置缺失、前端状态异常，还是后端处理逻辑没有覆盖边界情况。
我和 AI 的协作方式是：先描述用户看到的现象，再让它帮我列出排查路径。接着看日志、看数据、看触发条件，最后再收敛到可执行的修复方案。
这比单纯让 AI 直接写代码更有用。因为生产问题真正需要的是“定位能力”，不是马上生成一段看起来正确的代码。
Demo 不是按钮，是一整条体验链路
另一个让我印象很深的点，是官网 Demo。
一开始问题看起来很简单：Book a demo 按钮没有反应。但往下拆之后，发现真正要解决的是一整条链路：用户点了按钮之后去哪里？演示账号是什么？本地和生产数据是否一致？进入系统后应该先看什么？员工账号和经理账号看到的东西是否不同？排班导览能不能顺畅走完？
我让 AI 帮我把这些拆成任务，然后逐步补齐：演示账号、演示数据、POS 登录动线、排班导览、角色权限说明。
这件事给我的提醒是：很多产品问题表面是“一个按钮坏了”，本质是“客户第一次理解产品的路径断了”。
小体验问题，其实很影响信任
这周还集中处理了一些中英文体验问题。
比如英文界面里还有大量中文；英文状态下打开 POS 后，登录页和后续系统又变回中文；导航区域在英文文案变长后出现按钮和图标重叠。
这些都不是宏大的功能，但很真实。尤其是面向新加坡客户时，中英文体验是否一致，会直接影响客户对产品成熟度的判断。
AI 在这里很像一个耐心的 QA：帮我根据截图和描述还原问题，列出检查点，再把修复范围控制在真正相关的地方。对一个人做产品来说，这种“有人陪你把细节查完”的感觉很重要。
研究新方向，但不急着堆功能
除了修产品，我也用 AI 做了一些方向研究。
我研究了 AI 财务类产品、视频生成网站的工作机制，以及政府补贴数据采集工具的产品化可能。重点不是看别人有什么功能就立刻照搬，而是判断：这些能力适不适合放进现在的膳云？是应该集成，还是应该单独做一个小工具？我现在有没有交付和维护能力？
这类研究最有价值的部分，是 AI 可以帮我快速建立功能地图和实施路径，但最终取舍仍然要回到业务：客户是谁、痛点是否足够具体、我能不能用最小版本验证。
我这周真正学到的
这一周下来，我越来越觉得 AI 协作的重点不是“自动化一切”。
真正有效的用法，是把一个模糊问题变成几步可验证的行动：先复现，再定位，再修复，再验证；先明确客户路径，再补最小闭环；先研究可能性，再决定是否值得做。
AI 没有让我少负责，反而让我更清楚哪些决定必须自己做。
如果你也在做产品，尤其是一个人或小团队，我会建议从真实问题开始用 AI：线上报错、用户卡点、Demo 流程、文案体验、竞品研究。不要只问“能不能帮我做一个功能”，多问“这个问题真正影响了什么”。
接下来我会继续记录膳云 MakanCloud 的开发过程，也会把这些 AI 协作方法整理成更具体的案例。欢迎留言告诉我：你现在最想让 AI 帮你解决哪类问题？