前言

工具选好了，接下来很容易遇到另一个问题：同样是让 AI 写代码，为什么有时一次就改对，有时却越改越乱？

很多时候，不是模型不够聪明，而是我们把角色规则、当前需求和验收方式全塞进了一句“帮我做个小游戏”里。AI 只能自己猜：做什么类型的游戏、有哪些操作、什么情况下算完成，最后生成出来的东西当然也容易偏题。

这篇咱们就用一个熟悉的 2048 小游戏，把 System、User、Assistant 这三种对话角色拆开讲清楚，再一步步把需求写成 AI 能执行、我们也能检查的任务。

一、System、User、Assistant 分别是什么？

在常见的 AI 对话或 API 消息结构里，我们会看到 System、User 和 Assistant 这样的角色标记。它们描述的是一条消息由谁提供，并不是每次使用 AI 都必须手动打出这三个标签。

System：提供较稳定的行为指引和任务边界，例如让 AI 先读项目、保留现有技术栈。
User：提出当前这一轮要完成的具体需求，补充背景、功能和验收条件。
Assistant：AI 给出的回复，可能是问题分析、实施计划、代码修改或结果汇报。

实际产品的实现方式会有差异。有的工具把系统指令隐藏在产品内部，有的提供项目规则或自定义指令；编程代理还可能调用终端、编辑器等工具。咱们用这三个角色，是为了把沟通内容整理清楚，不代表所有产品都要用完全相同的格式。

二、System：先把长期规则说清楚

System 更适合放稳定、重复使用的要求。比如这个项目一直使用原生 HTML、CSS 和 JavaScript；修改前先阅读现有文件；不要随意引入新依赖；完成后要说明改动和检查结果。

这些约束如果每次都重新打一遍，不仅麻烦，也容易漏掉。可以把它们写进工具支持的项目指令、系统提示或规则文件里。

2048 项目的 System 示例

你负责实现和修改一个可在浏览器里直接运行的小游戏。具体玩法以当前需求为准，不要提前假设。

技术约束：
- 使用原生 HTML、CSS 和 JavaScript。
- 沿用现有文件结构和代码风格，不新增依赖。
- 只做当前需求需要的最小改动，不额外加功能。

工作方式：
- 修改前先阅读相关文件。
- 涉及游戏规则时，先写明状态变化、无效操作和边界情况，再改代码。
- 代码里没有出现的行为，不要凭空补上。

交付：
- 说明改了哪些文件、实现了什么。
- 列出实际运行或检查过的行为。
- 没验证的部分直接标明，不要写成已经通过。

这段规则没有指定 2048 的具体功能，因为它描述的是 AI 在项目里长期应该怎么工作。游戏需求本身留给下一层说明。

三、User：把这一轮的任务说具体

User 消息才是这次要解决的问题。只说“帮我做个 2048”，模型得自己猜一堆细节：页面放什么、键盘怎么操作、数字如何合并、游戏结束怎么办、手机能不能玩？

把需求拆成背景、目标、功能、约束和验收标准，AI 才比较容易照着完成，我们也能逐条确认结果。

先列出 2048 的核心规则

这个小游戏的第一版可以先约定：

棋盘是 4 × 4，开始时随机出现两个数字方块，数字为 2 或 4。
玩家用键盘方向键移动全部方块；同方向的相同数字碰到时合并成它们的和。
每次有效移动后，只在空格中生成一个新方块；没有发生变化的操作不生成方块。
每次合并所得分数累加到当前分数，并记录最高分。
棋盘出现 2048 时提示获胜；棋盘填满且没有可合并方块时提示游戏结束。
提供重新开始按钮，并支持窄屏浏览器使用方向键以外的触控操作。

把需求交给 AI

请先检查当前项目结构，再实现一个可以直接在浏览器运行的 2048 小游戏。

功能需求：
- 使用 4×4 棋盘，开局随机生成两个 2 或 4。
- 支持键盘方向键移动方块；相同数字在一次移动中最多合并一次。
- 只有棋盘状态确实改变时，才生成一个新方块。
- 显示当前分数和最高分；最高分保存在浏览器本地。
- 出现 2048 时显示获胜提示；棋盘已满且无法移动时显示游戏结束提示。
- 提供重新开始按钮，并支持手机上的滑动操作。

约束：
- 先沿用项目现有技术栈、页面结构和样式，不要擅自安装依赖。
- 不要只生成静态棋盘，所有游戏操作都要能实际使用。
- 修改范围聚焦在这个小游戏需要的文件。

验收标准：
- 连续按同一个方向时，方块按 2048 规则移动与合并。
- 一次移动中，合并后的新数字不能再次合并。
- 无效移动不增加分数，也不生成新方块。
- 重新开始会清空棋盘与当前分数，但保留最高分。
- 可以触发获胜和无可移动步数两种结束状态。
- 完成后说明修改文件、运行方式和实际检查结果。

这就比“做个 2048”清楚多了。尤其是“每次合并最多一次”和“无效移动不生成新方块”这两条，都是很容易漏掉、但一玩就能发现的问题。

四、Assistant：别只看它有没有写出代码

Assistant 是 AI 的回应。一个靠谱的编程助手不一定一上来就贴一大段代码；它可能先确认项目结构、说明实现计划，再修改文件并汇报结果。使用编程代理时，它还可能调用编辑器或终端工具完成操作。

拿 2048 来说，收到回复后可以按这些点检查：

项目是否真的有 4 × 4 棋盘和可操作的方块，而不是只有静态示意图？
向左或向右移动时，相邻相同数字是否正确合并？
同一格新合出来的数字有没有在同一次移动里再次合并？
没有移动的按键是否错误地增加了分数或生成了新数字？
满盘且仍可合并时，游戏有没有误报结束？
重新开始后，棋盘、当前分数和最高分是否符合预期？

AI 说“已完成”只是它的汇报，不等于以上行为都已经验证。要看它实际运行了什么检查，也要自己玩几轮关键情境。

五、把需求变成可检查的开发闭环

有了清楚的 System 规则和 User 任务之后，开发过程可以这样走：

先读项目：确认入口文件、已有样式和启动方法。
先讲计划：让 AI 列出准备修改的文件，以及移动、合并和结束状态的实现思路。
分步实现：先完成棋盘移动与合并，再加分数、结束状态和界面细节。
检查规则：用具体局面验证移动、合并、无效操作和结束判断。
反馈修正：指出哪种局面不对，并给出可复现步骤，让 AI 针对问题修复。

例如发现“向左移动时，4、4、8 被合成成 16”，就把棋盘初始状态、按键方向和预期结果写清楚。比起一句“合并逻辑有 Bug”，这种反馈更容易让 AI 定位问题。

六、一份可以直接复用的写法

把三个角色放在一起，大致会是这样：

[System / 项目规则]
先阅读项目，沿用现有技术栈和代码风格；改动保持聚焦。完成后说明改动和实际验证情况。

[User / 当前需求]
背景：这是一个浏览器里的 2048 小游戏。
目标：实现 4×4 棋盘、方向键和触控操作、方块合并、分数、最高分、胜利与结束提示、重新开始。
约束：不安装新依赖；无效移动不生成新方块；一个方块在一次移动中最多合并一次。
验收：分别检查有效移动、无效移动、合并计分、重新开始、获胜和无路可走的情况。

[Assistant / 交付反馈]
说明修改了哪些文件、如何运行、检查了哪些游戏局面，以及仍未验证的部分。

在真正的工具里，System 规则通常保存在项目配置或自定义指令中；每次对话主要补充 User 当前需求即可。Assistant 的结果则需要检查和反馈，不要把它的总结直接当成测试报告。

七、实战检查清单

长期有效的工作方式放在 System 或项目规则里。
当前任务说明背景、目标、功能和约束。
验收条件可以通过实际操作或测试逐条确认。
2048 的边界规则写清楚：一次移动最多合并一次，无效移动不生成方块。
检查 AI 修改的代码和实际运行结果。
让 AI 汇报修改内容与验证范围；未验证的部分要明确标出。

小结

System、User、Assistant 不是三句神奇咒语，而是帮我们分清稳定规则、当前任务和 AI 回应的消息角色。做 2048 时，System 交代协作方式，User 写清游戏规则和验收条件，Assistant 根据要求分析、实现并汇报；最后再用实际棋盘情况确认逻辑对不对。

Vibe Coding 不是把一句模糊想法丢给 AI 就等着成品出现。需求说得越清楚，结果越容易检查；反馈越具体，下一轮修改也越容易到位。

提示词三大类型：System、User、Assistant 怎么用？