AI 辅助开发提效实操指南
这份文档的目的是解决一个核心痛点：为什么你觉得 AI 写出来的代码总是不达标？
原因通常只有一个：沟通方式不对。
核心心法（The Core Mindset）
流程是死的，人是活的。 你不需要机械地执行下面每一步，但请务必遵守一个核心原则：
把你的想法（哪怕是乱糟糟的碎片）全部告诉 AI，让 AI 帮你理清楚、写成文档或画出图，等你确认完全理解了，再开始写代码。
不要让 AI 猜你的心思，也不要让 AI 在混乱中开工。磨刀不误砍柴工。
场景一：功能与逻辑（先想清楚，别急着写代码）
不要一上来就让 AI “写一个某某功能”。这是无效沟通。你需要先帮它（也是帮你）理清思路。
1. 抛出想法 (Rough Idea)
用大白话告诉 AI 你想要什么。
- ❌ 错误示范：“写个签到功能。”
- ✅ 正确示范：“我想在这个 App 里做一个‘每日签到’功能，目的是增加用户粘性。”
2. 追问与细化 (Discussion)
让 AI 充当产品经理，向你提问，或者你主动补充细节。
- 指令：“你觉得这个功能需要包含哪些字段？数据库怎么设计？用户如果断签了怎么办？请帮我列出这些细节进行讨论。”
- 结果：你们会讨论出“连续签到奖励”、“补签卡”、“积分系统”等具体逻辑。
3. 生成需求文档 (Documentation)
这是最关键的一步。让 AI 把刚才讨论的一堆话，整理成一份清晰的文档。
- 指令：“请根据刚才的讨论，生成一份《每日签到功能需求文档》 (Markdown格式)。必须包含：功能列表、数据库表结构定义（SQL或字段说明）、交互流程图（Mermaid）。”
- 作用：这份文档就是开发的“宪法”。后续写代码时，直接把文档发给 AI，它就不会乱发挥。
4. 人工确认 (Confirmation)
仔细看一遍文档。逻辑对不对？缺不缺东西？
- 动作：如果发现问题，直接让 AI 修改文档。文档没定稿，绝对不允许写一行代码。
场景二：UI 与视觉（不要让 AI 猜你的审美）
不要用“大气”、“高端”、“简约”这种虚词。AI 的“简约”和你的“简约”可能差了十万八千里。
1. 可视化原型 (Visualization)
让 AI 用代码画草图给你看。
- 指令：“请用 HTML + CSS 生成三个版本的签到页面设计：1. 极简风格（大白留白）；2. 游戏化风格（卡通色彩）；3. 商务风格（深色金字）。直接给我看效果。”
- 指令：“请用 HTML给我生成10种方案，让我选择， 如果需要热门的可以带上全球最热门的十种或者国内最热门的十种”
2. 挑选与微调 (Selection)
在浏览器里打开它生成的 HTML，挑一个最顺眼的。
- 指令：“我喜欢XXX方案 2，但是把背景颜色换成淡黄色，按钮改大一点，字体换成圆体。”
3. 生成定稿图 (Asset Generation)
确定样式后，让 AI 生成最终的 SVG 图片代码，或者截图。
- 指令：“请把调整后的样式生成一个 SVG 代码，我需要把它放入需求文档中作为视觉标准。”
- 动作：把这张 SVG 图（或代码）放进第一阶段的《需求文档》里。
场景三：代码实现（照图施工）
现在，你手头已经有了两样神兵利器：
- 明确的逻辑（需求文档）
- 确定的样子（UI 原型图/SVG）
直接把这两样东西发给 AI，它就只能乖乖干活了。
- 终极指令：“请仔细阅读这份《需求文档》和参考这张 UI 原型图，为我编写代码。严格遵守文档中的字段定义和 UI 布局。”
场景四：代码优化与重构
不要简单地对 AI 说“把代码优化一下”。这通常会导致 AI 为了“炫技”而写出难以维护的压缩代码（比如把清晰的 if-else 改成五层嵌套的三元运算符），或者破坏原有的稳定逻辑。
1. 诊断先行 (Diagnosis)
在修改代码前，先让 AI 像医生一样指出问题。
- 指令：“请阅读这段代码，分析目前存在的问题。是性能太差？可读性太差？还是逻辑有冗余？”
2. 索要对比方案 (Comparison)
让 AI 提供不同维度的优化策略，而不是直接覆盖代码。
- 指令：“请针对上述问题，提供三种优化方案，并展示修改前 vs 修改后的代码对比：
- 保守方案：仅提取重复逻辑，保持结构不变，提升可读性。
- 激进方案：使用高级语法特性，追求代码量最少。
- 性能方案：牺牲部分可读性，换取运行速度。”
3. 决策与执行 (Decision)
根据你的团队情况选择。
- 话术示例：“我选择方案 1。因为这段代码将来需要多人维护，清晰比简短更重要。请按方案 1 执行修改。”
总结：
- 想不清楚，就别让 AI 动手。
- 看不见图，就别让 AI 写界面。
- 没有对比，就别让 AI 瞎优化。