一、重做 UI：别让 AI 一次改整页#

对现有界面不满意时，直接把”重做 UI”丢给 AI，结果通常是替换得乱七八糟。有效的做法有三条：

1. 给参考截图 + 具体描述：把你想要的 UI 截图直接发给它，文字描述越具体越好（例如”雾面透光感""玻璃拟态”这类关键词）。纯文字远不如一张参考图。
2. 按组件逐个改：让它一次性改整个页面，必然牵一发动全身。把页面拆成单个组件，一个一个来，虽然慢一点，但结果可控。
3. 明确锁定不动的部分：一定要告诉它”只改这个组件，产品逻辑和其他部分不要动”。加上这句，能减少大量无关的连带改动。

改完记得同步更新之前建立的 design system，否则新旧组件会脱节。另外要接受一个现实：通过 MCP 对接设计工具，AI 也很难做到 100% 像素级还原，细节在提审前若没时间逐一抠，流程正确即可。

二、数据库：AI 默认给你的是”玩具版”#

这是最容易踩的坑：AI 在不知道你部署环境时，会默认降级——比如用 SQLite 或纯 mock 数据应付。本地跑得欢，上线才发现根本不是生产标准。阻止它的办法是在提示词里写清楚：

• 明确”按生产级标准做，不要因缺服务器就降级”：不说这句，它很可能默认你没有数据库、没有服务器，然后优雅地给你一个简化方案。
• 让它自查一遍数据库设计：例如提示它检查”是否有冗余字段、是否缺索引、是否符合生产级标准”，它会找出你没注意到的问题。
• 明确数据安全：提醒它用户数据涉及隐私，敏感字段要加密存储；同时检查你的 API Key 是否被提交到了公共代码仓库——密钥绝不能暴露在公开域。

前期用户量不大时，选择一个托管的生产级方案（如 Render 这类平台同时托管后端和静态页面）往往就够了，不必自己折腾服务器。

三、遇到具体问题，找专门解法#

功能越多、越难一次生成成功。更好的习惯是：遇到一个具体问题，先搜有没有针对性的工具、插件或现成的 skill。比如多机型自适应总是做不好，就可以让 AI 先写一个专门处理这件事的 skill，之后用它来约束 AI 的输出，问题会稳定得多。

小结#

这一阶段的两件事都指向同一个原则：别让 AI 自由发挥。改 UI 时给参考、拆组件、锁边界；做数据库时明确生产标准、要求自查、盯住安全。把”降级”和”越界”在提示词里提前堵死，AI 才会交出能上线的东西。