AI 写不好，多半是你没说清楚
AI 写不好，多半是你没说清楚
这份文档只解决一个核心痛点：为什么你觉得 AI 写出来的代码总是不达标？
原因通常只有一个：沟通方式不对。
核心心法
流程是死的，人是活的。 你不需要机械执行下面每一步，但请务必遵守一条原则：
把你的想法（哪怕是乱糟糟的碎片）全部告诉 AI，让 AI 帮你理清楚、写成文档或画出图；等你确认完全理解了，再开始写代码。
不要让 AI 猜你的心思，也不要让 AI 在混乱中开工。磨刀不误砍柴工。
写提示时，把「信息点」说清楚
给 AI 下指令时，真正有用的往往不是整句，而是句里的约束点。写的时候可以自己先标出来；读别人的示例时，也优先盯这些加粗部分。
例如：
- 不要只说「写个签到」，而要说「每日签到」——周期决定表结构、重置逻辑、是否连续。
- 不要只说功能名，而要补「目的是增加用户粘性」——目的决定要不要连续奖励、补签、积分。
后文示例会继续用加粗标出这类信息点，方便你对照自己的提示。
场景一：功能与逻辑（先想清楚，别急着写代码）
不要一上来就让 AI「写一个某某功能」。这是无效沟通。你要先帮它（也是帮你）理清思路。
1. 抛出想法 (Rough Idea)
用大白话告诉 AI 你想要什么。
- 错误示范：「写个签到功能。」
- 正确示范：「我想在这个 App 里做一个『每日签到』功能，目的是增加用户粘性。」
正确示范里，真正抬高质量的是：
| 信息点 | 作用 |
|---|---|
| 每日 | 约束周期：自然日？时区？跨天重置？ |
| 目的是增加用户粘性 | 约束产品目标：连续签到、补签、积分才有理由 |
你给 AI 的不是「功能名」，而是约束。约束越多，瞎发挥越少。
2. 追问与细化 (Discussion)
让 AI 充当产品经理，向你提问；或者你主动补细节。
- 指令：「你觉得这个功能需要包含哪些字段？数据库怎么设计？用户如果断签了怎么办？请帮我列出这些细节进行讨论。」
- 结果：通常会讨论出「连续签到奖励」「补签卡」「积分系统」等具体逻辑。
3. 生成需求文档 (Documentation)
这是最关键的一步。让 AI 把刚才讨论整理成清晰文档。
- 指令：「请根据刚才的讨论，生成一份《每日签到功能需求文档》（Markdown）。必须包含：功能列表、数据库表结构定义（SQL 或字段说明）、交互流程图（Mermaid）。」
- 作用：这份文档就是开发的「宪法」。后续写代码时直接把文档丢给 AI，它就不容易乱发挥。
「必须包含」三个字比「帮我写个文档」有用得多——它规定了交付物清单。
4. 人工确认 (Confirmation)
仔细看一遍文档：逻辑对不对？缺不缺东西？
- 动作：有问题就让 AI 改文档。文档没定稿，绝对不允许写一行代码。
场景二：UI 与视觉（不要让 AI 猜你的审美）
不要用「大气」「高端」「简约」这种虚词。AI 的「简约」和你的「简约」可能差了十万八千里。
1. 可视化原型 (Visualization)
让 AI 用代码画草图给你看。
- 指令 A：「请用 HTML + CSS 生成 三个版本 的签到页面：1. 极简（大白留白）；2. 游戏化（卡通色彩）；3. 商务（深色金字）。直接给我可打开的页面，不要只描述。」
- 指令 B：「请用 HTML 生成 10 种 方案供我选择；可以参考当前全球/国内较常见的产品视觉方向，但每种方案要有可区分的特征。」
信息点在于：
- 介质（HTML，不是形容词）
- 数量（3 个 / 10 种，强制对比）
- 风格标签（极简 / 游戏化 / 商务，比「好看」可执行）
- 交付形态（可打开的页面，而不是一段审美散文）
2. 挑选与微调 (Selection)
在浏览器里打开生成的 HTML，挑一个最顺眼的。
- 指令：「我喜欢 方案 2，但把背景换成淡黄色，按钮改大一点，字体换成圆体。」
点名 方案编号 + 具体属性（背景 / 按钮 / 字体），比「再好看一点」有效一百倍。
3. 生成定稿图 (Asset Generation)
样式确定后，让 AI 产出可沉淀的视觉标准。
- 指令：「请把调整后的样式生成 SVG 代码，我要放进需求文档当视觉标准。」
- 动作：把 SVG（或截图）放进第一阶段的《需求文档》。
到这里，逻辑文档和视觉标准绑在一起了。
场景三：代码实现（照图施工）
现在你手里应该有两样东西：
- 明确的逻辑（需求文档）
- 确定的样子（UI 原型 / SVG）
直接把这两样发给 AI：
- 终极指令：「请仔细阅读这份《需求文档》和 UI 原型，为我编写代码。严格遵守文档中的字段定义和 UI 布局，不要自行发挥未写明的需求。」
「严格遵守 + 遵守对象」比「帮我写一下」更能压住胡编。
场景四：代码优化与重构
不要简单对 AI 说「把代码优化一下」。这常常会让它为了炫技写出难维护的压缩代码（比如把清晰的 if-else 改成五层三元），或者破坏原本稳定的逻辑。
1. 诊断先行 (Diagnosis)
改之前，先让 AI 像医生一样指出问题。
- 指令：「请阅读这段代码，分析目前存在的问题。是性能太差？可读性太差？还是逻辑冗余？」
先问「病在哪」，再谈「怎么治」。
2. 索要对比方案 (Comparison)
让 AI 给不同维度的策略，而不是直接覆盖代码。
- 指令：「请针对上述问题，提供 三种 优化方案，并展示 修改前 vs 修改后 的代码对比：
- 保守方案：仅提取重复逻辑，保持结构不变，提升可读性。
- 激进方案：使用高级语法特性，追求代码量最少。
- 性能方案：可适当牺牲可读性，换运行速度。」
「三种 + 前后对比 + 方案标签」强迫 AI 把选择权交还给你。
3. 决策与执行 (Decision)
按团队情况选。
- 话术示例：「我选择 方案 1。因为这段代码将来需要多人维护，清晰比简短更重要。请按方案 1 执行修改。」
把选择结果和选择理由一起说，后续改动更不容易跑偏。
小结
- 想不清楚，就别让 AI 动手。
- 看不见图，就别让 AI 写界面。
- 没有对比，就别让 AI 瞎优化。
- 写提示时，把周期、目的、交付物、约束对象这些信息点写明白——必要时自己先加粗标一遍。
一句话：
先把「要什么」说成文档和原型，再让 AI 写代码；优化时先诊断、再对比、后决策。
自测：几道实践考题
读完不等于会用。下面几题不求标准答案，但要求你写出可直接丢给 AI 的指令，并能标出其中的信息点（可自行加粗）。
题 1：改写一条烂指令
原始指令：
帮我写一个用户中心。
请改写成「正确示范」风格，至少补齐这三类信息点：
- 对象边界（做什么 / 不做什么）
- 目的（为什么做，决定优先级）
- 交付物（要文档？表结构？接口？页面？）
题 2：标出信息点
下面这条指令里，哪些词是真正约束 AI 的？请全部圈出来，并说明每个词约束了什么。
请用 HTML + CSS 做 3 个版本的订单详情页：极简、电商促销风、后台管理风；直接给我可打开的页面，不要只描述。
题 3：补全流程缺口
同事说：「需求和 UI 都在我脑子里，你直接让 AI 开写后端就行。」
请指出这里最少缺了哪两步，并各写一句你会用来补齐的 AI 指令。
题 4：拒绝一次「瞎优化」
有人甩给你一段可运行代码，只说：「让 AI 优化一下。」
请写出你会发出的连续 3 条指令（诊断 → 对比方案 → 决策执行），并且：
- 第 2 条必须要求 修改前 vs 修改后
- 第 3 条必须包含 选择结果 + 选择理由
题 5：场景实战（综合）
任务：给博客后台加一个「文章定时发布」。
请按本文顺序，各写一段可复制指令：
- 抛出想法（含 周期/触发方式 与 目的）
- 追问细化（至少点名 3 个必须讨论的议题）
- 生成需求文档（写明 必须包含 的交付清单）
- 代码实现（写明 严格遵守 的对象）