对于完全不懂代码的人，本教程提供了一条从小项目开始、边做边学的完整路径；对于有经验的程序员，可以重新审视如何借助 AI 做出可维护、可上线的项目。
1. AI写代码的真相：为什么你的项目总是烂尾？
1.1 AI 写代码为何容易烂尾
AI 现在最火的用途就是写代码。一个完全不懂代码的运营朋友，靠 AI 做出了 UI 能看、能运行、功能完整的量化交易项目，甚至部署上线了。但完全不懂代码的人，根本不知道代码架构、漏洞风险、性能优化、后期维护意味着什么。
如果一路往前堆功能，只追求功能完整，遇到问题临时解决，最后得到的很可能只是一堆死代码。
1.1.1 烂尾的本质
不懂代码的人根本不知道架构、漏洞、性能、后期维护意味着什么。一旦只追求功能完整、遇到问题临时解决，最后得到的就是死代码。
1.2 MVP 之后的真相
前期做 MVP 时，这种方式确实很快。但项目一旦要运营、要迭代、要接用户、要上线收钱，剩下的全是救火，最后只能重写。几千上万资金的 token 花出去了，项目也差不多黄了。
1.3 Vibe Coding 是什么
Vibe Coding 就是让 AI 写代码帮你做项目。但很多人看到的"给 AI 一句话就能做出项目"的说法并不准确。如果想做一个复杂一点、能长期维护的项目，只靠一句话就想搞定基本是在扯淡。功能少、几千行代码能解决的，问题不大；项目一复杂，大概率就是放弃或重写。
1.4 真正的 Vibe Coding ≠ 让 AI 写代码
真正的 Vibe Coding 不是让 AI 写代码，而是让 AI 按照你的需求规范和架构思路去一步步把项目做出来。这里最重要的不是 AI，而是规范。
但你不是软件专业的，拿到一个项目怎么制定规范、怎么让 AI 理解规范、怎么让 AI 在开发过程中始终遵守规范，才是这个系列真正想讲的内容。
1.5 为什么公司喜欢招有经验程序员
有经验的程序员不只是会写功能，更懂规范、懂架构，知道什么代码后期会出问题、什么设计会让项目越来越难维护。一份规范的代码即便有 bug 也能很快定位修复；一份混乱的代码，就算现在能跑，后面每改一次都像拆炸弹。
1.6 现在最重要的是想象力
开源生态已经非常成熟，你想做的大多数功能，GitHub 上基本都能找到轮子、框架或参考方案。AI 时代，即便暂时没有完全满足需求，AI 也能帮你快速补齐实现细节。
所以现在最重要的不是技术本身，而是想象力：能不能想清楚要做什么？能不能把想法拆成清晰的功能模块？能不能让 AI 按正确的规范和架构去执行？
2. AI编程工具真实体验对比
2.1 Cursor 与 Codex：长期使用真实感受
市面上 AIIDE 远不止两款，但讲者目前主力使用的就是 Cursor 和 Codex。这篇不做复杂横评，只聊长期使用之后的真实感受。
2.1.1 IDE 与模型的关系
对 Vibe Coding 来说，IDE 很重要，但它不是最重要的。真正重要的是两件事：第一，模型能力够不够强；第二，你有没有能力驾驭 AI。IDE 只是入口，它决定你怎么和 AI 协作；模型能力决定 AI 能做到什么程度；你的思维方式决定 AI 是帮你做出好项目，还是在浪费你的钱、时间和精力。
很多 AIIDE 都支持接入第三方模型。比如 Cursor 既有自己的模型，也支持 GPT、Claude 等主流模型。这篇文章不是告诉你必须用哪一个，而是帮你理解 Cursor 和 Codex 分别是什么类型的工具，以及应该在什么场景下选择它们。
2.2 Cursor：成熟的 AIIDE
Cursor 算是非常早布局 AIIDE 赛道的产品，基于开源项目 VS Code 二次开发而来，整体使用体验对程序员非常友好。
2.2.1 优势
Cursor 作为 IDE 的控制能力非常强，编辑体验、文件定位、上下文理解、代码修改、项目内操作都比较稳。对于专业程序员来说，AI 写代码不是只看模型输出，还要看能不能稳定理解项目结构、修改正确文件、控制修改范围。这一点 Cursor 做得确实不错。
2.2.2 短板
CURSOR 也有自己的问题。也许是因为他们把重点放在了 AIIDE 本身，自家模型给人的体验并不特别稳定。早期 Composer 1X 还可以，但升级到 2.0X 之后，代码能力、理解能力都不太稳定。
2.2.3 成本
如果你完全依赖 Cursor 做开发，并大量使用第三方高级模型，成本其实不低。200 刀的额度几乎全拿来梭哈高级模型也就用了两个星期左右。
如果能把 Auto 模式用好，开发一些不太复杂的项目是完全够用的，比如小程序、官网、普通后台、轻量级工具类项目。但项目再往深走，比如硬件开发系统、底层复杂工程架构，就要慎重。
2.3 Codex：超级 Agent APP
Codex 给人感觉只能说是惊为天人。最强的地方并不在于 IDE 本身，而在于它背后模型的能力，以及它作为 Agent 工具的整体执行能力。
严格来说 Codex 不太像传统 IDE，更像是一个超级 Agent APP。它不仅能写代码，还能操作环境、执行命令、读取日志、跑测试、启动服务、部署项目，甚至可以在权限足够的情况下连续推进一个很长的任务。
2.3.1 与传统 AIIDE 的区别
比如开发前端 UI，Codex 可以一边写代码，一边启动页面，一边调整设计，一边根据运行效果继续修改。
比如开发硬件项目，它可以一边写代码，一边自动烧录部署，打开日志监控。在开发 Beto 的时候特别明显：每次发布版本前，经常让它自己打开 QQ 做测试、监控日志、分析问题、修改代码。只要给它足够完整的权限，真的可以自动化跑很久。
2.3.2 优势场景
之前 Beto 的树莓派版本有一块屏幕驱动需要安装。把树莓派的局域网 IP 和密码给 Codex，再把官方文档丢给它，它自己登录进去，配置环境、安装驱动、部署 Beto 配置、开机自启，整个过程跑了 3 小时，中间还顺手重新设计了一些 Beto 里不够完善的功能代码。
Codex 在长任务、跨工具自动化执行、部署和日志分析这些场景里更丝滑，Agent 感更强。它强大的地方不是它像不像 IDE，而是它根本不只是 IDE，更像是一个拥有强模型能力、能操作环境、能跑命令、能读日志、能改代码、能持续推进任务的 AI 工程助手。
2.3.3 计费模式
Codex 的计费体验和传统按量消耗不太一样，更像是按套餐额度、时间窗口和使用量综合计算。如果高强度使用，额度确实消耗得很快，但对于大多数普通用户来说，一周的额度未必能完全用完。如果 5 小时窗口真用完了也刚好可以休息一下，过一段时间又会恢复。
2.4 Cursor vs Codex：怎么选
如果你更看重传统 IDE 体验，希望在熟悉的 VS Code 生态里写代码、改代码、管理项目，Cursor 很适合你。它更像一款成熟的 AIIDE，适合日常编码项目开发、快速补全、局部重构和中小型项目推进。
如果你更看重 Agent 的能力，希望 AI 不只是写代码，还能帮你跑命令、部署、看日志，持续执行复杂任务，那么 Codex 会更适合。它更像一个自动化工程助手，尤其适合长流程任务、复杂环境部署验证、硬件调试和多步骤工程项目。
但不管选哪一个，都不要以为装了工具就等于会 Vibe Coding。工具只是入口。真正决定能不能用好 AI 的是能不能把需求讲清楚、把任务拆明白、判断架构是否合理、验收 AI 写出来的东西。
2.5 $20到底充给谁
如果问 $20 刀充给谁，现在会更建议直接给 Codex。原因很简单：写普通项目 Cursor 够用，但如果你想真正体验 AI 作为工程助手的能力，Codex 的长任务执行、环境操作、日志分析和自动化推进能力给人的震撼更大。
最后你需要知道的是，你可以用任何 AI IDE，Cursor 也好、Codex 也好、其他工具也好，都只是入口。对于 Vibe Coding 来说，真正重要的不是 IDE 本身，而是两个东西：第一，模型能力；第二，你自己的思维能力。前者决定 AI 的上限，后者决定能不能把这个上限真正发挥出来。
你不会规划，AI 就会乱写；你不会验收，AI 就会把问题藏进项目里；你不会判断架构，AI 就可能帮你把项目越写越乱。所以本系列接下来真正要讲的不是某个按钮怎么点，也不是某个工具怎么用，而是如何驾驭 AI、如何提需求、如何拆任务、如何制定计划、如何控制上下文、如何验收结果、如何避免被 AI 带沟里。这才是 Vibe Coding 真正的核心。
3. Vibe Coding 秘密武器：Agent 宪法是什么？
3.1 引入：从工具到规范
工具只是入口，模型只是能力。真正决定项目能不能长期做下去的，是能不能给 AI 建立一套稳定的工作规则——这就是规范。对 AI 来说，规范是靠上下文和用户对话约束的，但用户不可能每次都重新强调。对此业界最常见、最有用的两种解决方案是 Agent 宪法和 Skill。本节先聊 Agent 宪法。
3.2 什么是 Agent 宪法
Agent 宪法是一份写给 AI 的长期行为准则，不是某一次对话的临时要求。每次 AI 进入项目之前，都应该先知道：项目边界是什么、代码规范是什么、哪些文件不能乱动、哪些操作必须谨慎、验收标准是什么。
3.2.1 与员工手册的类比
用公司类比，Agent 宪法就像员工手册，告诉 AI 什么能做什么不能做，遇到问题按什么原则处理。很多小白用 AI 写代码时最容易忽略这个，但它会直接决定 AI 是在认真做工程，还是在一路堆垃圾。
3.2.2 没有宪法的后果
新手习惯直接说"帮我加个功能"、"帮我修个 bug"，AI 当然会做。但如果没有项目规则，AI 只能根据当前上下文和模型习惯来猜。猜对了还好，猜错了就乱改文件、乱抽象、乱兼容、乱补丁。Agent 宪法的意义就是先给 AI 立规矩，不是等它犯错后再纠正。
3.3 宪法文件通常放在哪里
| 工具 | 规则文件 | 位置 |
|---|---|---|
| Codex | agents.md |
项目根目录 |
| Cursor | .cursor/rules/ |
cursor 目录下 |
| Claude Code | CLAUDE.md |
项目根目录 |
文件名虽然不同，目的相同：让 AI 每次进入项目时，先知道这个项目的规矩。如果不确定当前 IDE 应该用什么，最简单的方式是直接问 AI 帮你创建并放到正确位置。
3.4 Agent 宪法为什么重要
Agent 宪法最重要的作用不是让 AI 更听话，而是让它更稳定。
3.4.1 AI 的局部最优问题
AI 很容易根据当前对话做局部最优——通俗点说就是偷懒。让它修按钮，它可能只盯着按钮；让它加功能，它只想着怎么把功能加上去。但真实项目不是孤立的：前端改动涉及组件规范，接口改动涉及权限模型，功能改动涉及数据库设计、错误处理、测试覆盖和后期维护。
3.4.2 死代码的真正原因
如果没有 Agent 宪法，AI 很容易只解决眼前问题，却破坏长期结构。很多人用 AI 做项目最后变成死代码，不是 AI 不会写代码，而是没告诉它什么叫好代码。它只知道把功能做出来，不知道项目后面还要维护、迭代、上线、接用户。
所以必须提前告诉 AI：架构优先、设计优先，不要为当前功能破坏项目边界，不要用表层方案掩盖底层问题，不要没有证据就改，不要没有验收就说完成。
3.5 Agent 宪法不是越长越好
Agent 宪法不是写得越多越好。很多人把所有东西都塞进规则文件，最后写成几千行——看起来完整，实际上 AI 反而抓不住重点。因为规则文件通常会进入 AI 上下文，写得越长消耗越多，重点越被稀释。
真正好的 Agent 宪法应该短、硬、清楚：
- 写长期有效的原则，而不是流水账
- 写禁止事项和验收标准，而不是空话
- 写可执行、可检查、可判断的规则，而不是模糊口号
AI 不是人，不适合听"认真一点"、"写好一点"这种话。要告诉它什么叫认真、什么叫质量、什么情况不能交付。
如果说 AIIDE 是 Vibe Coding 的工具入口，那么 Agent 宪法就是第一层工程底座。下一小节继续聊 Skill——它能解决 Agent 宪法不写成长篇大论，也能避免 Vibe Coding 过程中的 AI 漂移。
4. AI编程必备：Skill 如何让你成为编程大师？
4.1 前言：从 Agent 宪法到 Skill
Agent 宪法解决的是 AI 在这个项目里应该遵守什么规矩，长期进入上下文。但 Agent 宪法不能塞所有东西——如果你把需求梳理、开发计划、bug 排查、页面验收、代码审查、发布流程全部塞进去，最后会变成长篇大论，持续消耗上下文和 token。所以还需要第二个东西：Skill。
4.1.1 Skill 的三个核心价值
- 让 Agent 宪法保持简洁
- 让 AI 在 Vibe Coding 过程中减少漂移
- 让小白也能借用高手的工程经验
很多开源 Skill 本身就是有经验的工程师把自己的工作方法、排查流程、验收习惯沉淀出来的结果。使用这些技能本质上不是多了一段提示词，而是把一套成熟经验"借"进自己的 AIIDE。
4.2 什么是 Skill
新手最常见的状态是所有事情都靠一句话硬推：想做功能就说"帮我加一个登录"，遇到报错就说"帮我修一下"，页面不好看就说"帮我优化一下 UI"，项目跑不起来就把报错贴过去让 AI 继续改。
4.2.1 自由发挥的后果
这种方式前期看起来很爽，AI 反应也确实能写出东西。但问题是 AI 每次都在根据当前这句话自由发挥。没有告诉它：做功能前要不要先拆需求、改代码前要不要先看项目结构、遇到 bug 要不要先复现、页面改完要不要打开浏览器、验收完成前要不要跑测试。
结果就是这次一个做法，下次又一个做法，遇到问题就猜，猜错了就继续改，改到最后代码越来越乱。
4.2.2 Skill = 岗位 SOP
如果说 Agent 宪法是项目员工手册，那么 Skill 就是岗位 SOP。Agent 宪法告诉 AI 这个项目的长期原则，Skill 告诉 AI 遇到某一类具体任务时应该按什么流程执行。Skill 的本质不是一段普通提示词，而是一套可复用的专业流程。
4.3 Skill 和 Agent 宪法的区别
| 维度 | Agent 宪法 | Skill |
|---|---|---|
| 解决什么 | 长期原则 | 专项流程 |
| 加载方式 | 长期进入上下文 | 语义命中后按需加载 |
| Token 消耗 | 每次都消耗 | 只在需要时消耗 |
Agent 宪法告诉 AI "必须这样做"，Skill 告诉 AI "具体怎么做"。如果你把所有"具体怎么做"都写进 Agent 宪法，宪法就会越来越长，最后变成一份 AI 抓不住重点的大杂烩。而 Skill 的价值就是把这些复杂流程拆出去，让它们在需要的时候再被加载。
4.4 Skill 为什么重要
4.4.1 减少 AI 漂移
Vibe Coding 里常见的问题：一开始让 AI 做的是 A，聊着聊着开始做 B；架构要求是这样，改着改着按另一套思路写；要求先验收再完成，后面又开始写完就说完成——这就是漂移。
原因是 AI 每次都在当前上下文里临时组织做法，上下文一长、任务一复杂就容易忘掉约束。Skill 把某一类任务的标准做法固定下来，IDE 或 Agent 根据语义自动加载，让它回到稳定流程。
4.4.2 复制高手经验
新手真正缺的不只是代码能力，而是工程经验。开源 Skill 本身就是有经验的工程师把工作方法沉淀的结果。使用 Skill 不是多了一段提示词，而是让 AI 在当前任务里加载了一套更成熟的经验。
4.5 Skill 通常怎么使用
Skill 不是让你手动排顺序，AIIDE 会根据你的表达自动判断该用哪个 Skill：
| 用户表达 | AI 可能匹配的 Skill |
|---|---|
| 排查问题 | 调试类 Skill |
| 写开发计划 | 计划类 Skill |
| 检查页面 | 浏览器或前端验收类 Skill |
你也可以主动点名某个 Skill。Skill 是一套可以被 IDE 自动调度、也可以被用户主动点名的能力模块。
4.5.1 Skill 的结构
一个 Skill 通常会有自己的说明文档，告诉 IDE：叫什么、什么时候使用、解决什么问题、执行流程是什么、最后输出什么。有些 Skill 还会带参考资料、模板、脚本甚至专门命令。
所以使用 Skill 的时候不要只靠猜，可以直接问 IDE：
- 当前有哪些 Skill？
- 某个 Skill 是干什么的？
- 它有没有命令或脚本？
- 如果要做这个任务应该触发哪个 Skill？
4.6 普通人怎么安装和理解 Skill
对普通人来说，安装 Skill 不一定复杂。可以直接把 Skill 链接丢给 AIIDE，让它帮你安装并确认能被识别。
4.6.1 三件事必须知道
- 看到合适的 Skill，把链接丢给 IDE 让它安装
- 不知道怎么用，让 IDE 解释用途、触发方式、命令和注意事项
- 不确定适不适合当前项目，让 IDE 结合项目情况做判断和适配
如果你不知道 Skill 适不适合当前项目，也可以直接问 IDE：
- 这个 Skill 适合我现在这个项目吗？
- 它会解决什么问题？
- 会不会和现有 Agent 宪法冲突？
- 安装之后应该怎么触发？
- 有没有命令或脚本需要注意？
这比自己看半天文档更适合新手。因为 Skill 本身就是给 AI 用的，完全可以让 AI 帮你读它的设计文档。
4.7 我目前常用的 Skill
| Skill | 适用场景 |
|---|---|
brainstorming |
需求和设计，避免一上来就写代码 |
writing-plans |
开发计划，把需求拆成可执行任务 |
systematic-debugging |
系统化排查，核心是不要猜，要先找根因 |
verification-before-completion |
完成前验收，防止写完代码就说完成 |
requesting-code-review |
代码审查，用另一个视角检查风险 |
dispatching-parallel-agents |
多 Agent 并行，适合多个独立任务同时推进 |
browser |
浏览器验证，适合前端交互截图和本地服务检查 |
slaver-engineering-workflow |
完整工程流，强调架构优先、真源优先、严格验收 |
4.8 最后
宪法管原则，Skill 管流程。宪法防止 AI 乱来，Skill 防止 AI 瞎做。更重要的是 Skill 可以把高手经验变成 AI 能反复调用的能力。
对没有代码基础的人来说，这一点非常关键。你可以让 AI 使用这些已经沉淀好的 Skill，同时 Skill 也能让 Agent 宪法保持简洁，把复杂流程按需加载，而不是每次都塞进上下文里。Skill 是把专业经验流程化再交给 AI 按需调用的一种方式。
5. 对 AI 祛魅：小白到底能用 Vibe Coding 做什么
5.1 前言：从工具到现实
前面聊了 AIIDE、Agent 宪法、Skill，也简单认识了前端、后端和数据库。Vibe Coding 不是单纯让 AI 写代码——你需要工具、需要规则、需要流程，也需要一些最基本的技术认知。
Vibe Coding 降低了技术门槛，但它不是许愿机。你不能指望完全不懂技术、不懂产品、不懂验收，然后一句话让 AI 变出能长期运营的项目。Vibe Coding 真正带来的不是"不用学习"，而是"不用先成为程序员，也能开始做东西"。
5.2 先对 AI 祛魅
很多人刚接触 AI 写代码时会有错觉：AI 什么都会，让它写什么都能写，还能一本正经地说"功能已经完成"。
5.2.1 必须知道的真相
- AI 说完成 ≠ 真的完成
- 能写出代码 ≠ 代码架构合理
- 能让页面跑起来 ≠ 项目能上线
- 能临时修报错 ≠ 找到根因
Vibe Coding 最容易让小白误判：你看到结果却看不到风险，看到页面却看不到架构，看到功能却看不到安全、性能、数据结构、后期维护。
5.2.2 AI 的本质
AI 是非常强的执行工具，但不是永远正确的老师。它会猜、会偷懒、会绕路，会为让眼前功能跑起来写出后期难维护的代码。你可以用它，但不能完全把判断权交给它。
5.3 Vibe Coding 的本质是技术平权
Vibe Coding 让一个没有代码基础的人也能借助 AI 做出网页、脚本、工具，甚至是完整项目的雏形。这就是技术平权——不是让每个人都变成程序员，而是让普通人第一次有机会直接调动技术能力去解决自己的问题。
过去你有想法，第一反应是"我不会代码，所以算了"。现在可以先让 AI 帮你做出来，先跑起来，先验证有没有价值。现在真正重要的不是技术本身，而是想象力。
5.4 不要一上来就做高大上的项目
技术平权不等于没有门槛。你可以没有代码基础，但不能没有边界感。
5.4.1 新手最不适合的开始方式
- 完整 SaaS 平台
- 复杂交易系统
- 大型社交产品
- 多端 APP
- 待支付权限的完整商业系统
刚开始就这么做大概率被 AI 拖着跑。你不知道项目怎么拆、哪些模块先做、哪里有安全风险、什么叫完成、怎么验收。最后很可能感觉 AI 一直在干活，token 一直在烧，但项目越来越乱。
新手真正应该做的不是上来梭哈大项目，而是先从小东西开始——小网站、小脚本、小工具、小 demo。
5.5 小白真正能做什么
| 类型 | 典型项目 |
|---|---|
| 展示类内容 | 个人网站、作品集页面、项目官网、活动页 |
| 自动化工具 | 批量整理文件、处理表格、压缩图片、生成文案 |
| 项目雏形 | 能点击的后台页面、简单小程序 demo、产品原型 |
这些都很适合新手，因为它们范围小、目标明确、验收简单、失败成本低。
这才是小白进入 Vibe Coding 最健康的路径——先让 AI 帮你解决身边真实存在的小问题。
5.6 边做边学专业表达
当你做得越来越多，会发现 AI 经常理解错你的意思。很多时候不是 AI 不行，而是你的表达还不够专业。
5.6.1 模糊表达的代价
- "做得好看一点" → AI 只能猜什么叫好看
- "优化一下代码" → AI 猜你想优化结构、性能、可读性还是 UX
5.6.2 必须学会的专业词汇
UI / UX、数据库、接口、部署、验收、权限、日志、测试、架构、工程化——这些词不一定要掌握背后所有代码细节，但要大概知道它们解决什么问题、影响项目的哪个部分。
Vibe Coding 不是让你完全不用学习，而是让你可以边做边学——不用先学几年编程再开始做东西，但也不能永远停留在模糊表达。
5.7 最后
这一小节最想讲清楚三件事：
- 对 AI 祛魅：AI 很强，但不是许愿机
- 理解技术平权：Vibe Coding 不是让每个人都变成程序员，而是让每个人都能开始用技术解决自己的问题
- 不要一上来就做高大上的项目：先从小网站、小脚本、小工具、小 demo 开始，在实践里慢慢学会驾驭 AI
Vibe Coding 给普通人打开了一扇门，但你能走多远，取决于你的想象力，也取决于你愿不愿意在实践里慢慢学会驾驭这个工具。
6. Vibe Coding 技术认知：前端到底是什么
6.1 前言：从规范到技术认知
前面聊了 AIIDE、Agent 宪法和 Skill。从这一小节开始进入开发认知技术篇。这里不是要教你马上从零手写代码，而是先帮你建立基本技术认知。Vibe Coding 的核心不是你亲自写每一行代码，而是你要知道自己在让 AI 写什么、改什么、验收什么。
6.2 什么是前端
前端本质上是用户和系统之间的交互层。所有用户能看到、能点击、能操作的部分都可以理解成前端：
- 网站里的页面、按钮、表单、弹窗
- APP 里的首页、列表、个人中心、支付页面
- 小程序里的页面、组件和交互
- 硬件设备上的屏幕界面（智能手表、车机屏幕、工业设备触控屏）
前端不是网页的代名词，前端是交互层，负责把系统能力展示给用户，也负责把用户的操作传递给系统。
6.3 为什么 Vibe Coding 要先理解前端
对大多数普通项目来说，前端是你最容易感知到的部分，也是很多小白最先下手的地方。但如果你要完全靠 Vibe Coding 做一个项目，前期最应该先做的也恰恰是前端。
6.3.1 前端是项目理解层
前端会决定项目长什么样，也会倒逼你想清楚项目的数据、页面和操作流程。一个后台系统，先把页面做出来，就会马上看到需要哪些列表、表单、详情页、按钮、筛选条件和状态字段。
这些字段一旦画出来，数据形式就清楚了：用户是什么结构、订单是什么结构、任务是什么结构、权限是什么结构。很多时候这些不是你空想出来的，而是在做页面和流程的时候被逼出来的。
6.3.2 模糊表达的危害
如果你只会说"帮我做的好看一点"、"帮我优化一下页面"，AI 就只能自由发挥，更多时候会堆一堆渐变、卡片、阴影和动画，看起来热闹却不一定好用。
所以理解前端最重要的不是马上学会写 HTML/CSS/JavaScript，而是学会怎么描述前端。
6.4 前端 7 大核心术语
| 术语 | 含义 | 典型元素 |
|---|---|---|
| UI | 用户界面 | 按钮、表单、列表、弹窗、导航、页面结构 |
| UX | 用户体验 | 流程是否清楚、操作是否迷路、反馈是否及时 |
| 风格 | 视觉感受 | 简洁、商务、科技感、可爱、工具型 |
| 布局 | 内容组织 | 内容放在哪里、主次怎么安排、左右侧栏 |
| 组件 | 可复用模块 | 按钮、输入框、卡片、表格、弹窗、导航栏 |
| 交互 | 操作后的反馈 | 点击反馈、提交失败提示、加载状态、删除确认 |
| 响应式 | 多屏适配 | 电脑、平板、手机自适应 |
前端术语就是你和 AI 沟通页面效果的语言，你越能说清楚，AI 越不容易瞎猜。
6.5 常见的前端场景
| 场景 | 说明 | 典型产品 |
|---|---|---|
| 网页前端 | 浏览器打开的网站 | 后台系统、官网、SaaS、数据看板、个人博客 |
| APP 前端 | 手机 APP 界面 | 原生或跨平台 APP（iOS / Android） |
| 小程序前端 | 平台提供的小程序环境 | 微信、支付宝、抖音小程序 |
| 硬件 GUI | 设备屏幕的图形界面 | 智能硬件、工业设备、车机、仪器仪表 |
不同场景对应的技术栈、设计规范和交互规范都不一样。以后跟 AI 说"做一个前端"时，要告诉它是哪一种。如果不清楚，可以直接问 AI 当前场景的设计规范和交互习惯。
6.6 不同前端对应不同技术栈
| 前端类型 | 底层技术 | 现代工程化 |
|---|---|---|
| 网页前端 | HTML / CSS / JavaScript | React / Vue / Svelte + TypeScript + Next.js / Nuxt.js |
| APP 前端 | 原生 iOS（Swift）/ Android（Kotlin/Java） | 跨平台 Flutter / React Native |
| 小程序前端 | WXML / WXSS / JavaScript | 跨端 Taro / uni-app |
| 硬件 GUI | C / C++ + Qt | 嵌入式 LVGL |
6.6.1 关键认知
- 现代前端框架不是魔法
- 网页前端在现代底层也离不开 HTML/CSS/JavaScript
- 不同前端场景对应不同运行环境和技术栈
否则让 AI 做 APP，它可能给你写网页；让它做小程序，它可能按普通 Web 设计；让它做硬件界面，它可能还在写 React。方向错了，越写越麻烦。
6.7 前端在项目里负责什么
| 功能 | 前端负责 | 后端负责 |
|---|---|---|
| 登录 | 展示页面、收集账号密码、调用接口、显示结果 | 账号密码是否正确、用户权限、登录状态保存 |
| 订单 | 展示订单列表、筛选条件、详情页、操作按钮 | 订单数据来源、状态计算、支付结果处理 |
前端和后端不是"谁更重要"的问题，而是分工不同——前端更靠近用户，后端更靠近数据和业务规则。用 AI 做项目时，分清楚层级，项目才不会越修越乱。
6.8 最后
所有用户能看到、能操作的界面都可以理解成前端。但前端不等于网页，它可以是网页、APP、小程序，也可以是硬件 GUI。
对 Vibe Coding 来说，前端最重要的不是马上会写代码，而是要知道自己在做哪一种前端，以及怎么用正确的术语和 AI 沟通。
更重要的是，如果你完全靠 Vibe Coding 做项目，前端往往应该优先落地。不要只会说"做得好看一点"，要慢慢学会说 UI / UX / 风格 / 布局 / 组件 / 交互 / 响应式 / 视觉层级 / 设计系统这些词——它们会决定 AI 是在认真帮你做前端，还是在凭感觉瞎美化。