1.2 选对大脑，搭起 AI 开发指挥链

很多老师第一次用 AI 写代码时，会有一种很熟悉的错觉：好像只要换一个更强的模型，项目就稳了。

今天用这个工具，明天换那个模型，后天又听说某个 Agent 更聪明。折腾了一圈，代码确实生成得更快了，但项目还是容易散。

前面说过的需求，后面忘了。刚改好的页面，下一轮又被改回去。报错修着修着，连自己都不知道现在系统到底能不能跑。

这时候问题不一定出在模型本身。更常见的原因是：你还没有搭起一条稳定的 AI 开发指挥链。

不要只盯着最强模型

选模型当然重要。但对 Vibe Coding 来说，模型不是越贵越好，也不是越新越好。复杂问题，需要能理解长上下文、能看懂工程结构、能调用工具、能耐心推理的模型。

比如我们后面要做“机房固定布局与班级轮换动态排座系统”，它不只是一个页面。它至少会涉及这些问题：

• 机房座位是固定布局。
• 不同班级要有不同座位表。
• 学生不能重复占座。
• 同一台电脑不能同时分给两个人。
• 老师改完座位后，数据要能保存。
• 后面还可能导出打印表。

这种任务，就不能只看模型会不会写一段漂亮代码。它得记得住前面的约定，能理解文件之间的关系，还要能在修改时尽量不把旧功能弄坏。但如果只是改一个按钮文字、调整一点间距、把提示语写得更像老师说话，就不必每次都动用最强模型。

简单任务用轻量模型，复杂问题用更强的推理模型。这比盲目追求“最强”更实在。

三类工具，各司其职

Vibe Coding 不是只靠一个聊天框。更稳的做法，是把工具分成三类来看。

第一类是可视化 IDE。

比如 VS Code、Cursor、Trae 这类工具。它们适合看项目结构、打开文件、改页面、观察前端效果。

第二类是命令行 Coding Agent。

比如 Codex、OpenCode 这类能在项目目录里读文件、改文件、跑命令的工具。它们更像一个能进工地干活的助手，不只是隔着聊天窗口给建议。

第三类是通用对话模型。

Claude、Gemini 等模型适合头脑风暴、推敲需求、帮你把一句模糊想法整理成更清楚的文档。这三类工具不是互相替代的关系，更像学校里不同岗位的配合：有人负责讨论方案，有人负责看现场，有人负责动手执行。

你要做的，不是到处换工具，而是知道什么时候该叫谁上场。

Python 和 Node.js 是两条基础路

上一篇我们已经知道，一个校园 Web 项目不是单个 HTML 文件就能长期撑住的。到了真正做项目时，你至少会遇到两条基础路。

一条是 Python。

它适合脚本、数据处理、后端辅助和很多 AI 相关工具。比如整理学生名单、批量处理 Excel、做一些小型接口，Python 很顺手。

另一条是 Node.js。

它是现代前端项目绕不开的基础。你要用 Vite、Vue、组件库、前端构建工具，基本都会碰到 Node.js 和 npm。这一篇先不讲怎么安装。

你只需要先记住：后面想让 AI 帮你把校园 Web 项目跑起来，电脑上至少要有这两条路。下一篇我们专门处理它们最容易卡住的地方。

真正的开发，从写代码之前开始

很多项目烂尾，不是因为 AI 不会写代码，而是因为一开始就把“需求、设计、开发、测试”全搅在一起。

老师只说了一句“帮我做个排座系统”，AI 就开始写。写到一半，才发现班级轮换没考虑；再改，发现数据保存没设计；继续改，又发现页面和数据库对不上。

这就像没备课就直接上公开课。不是不能讲，而是很容易现场翻车。比较稳的 AI 开发流程，可以先这样走：

flowchart TD
  A[头脑风暴<br/>把校园痛点说出来] --> B[明确需求<br/>筛掉不必要功能]
  B --> C[生成 PRD<br/>写清用户、功能、边界]
  C --> D[生成技术方案<br/>前端、后端、数据怎么配合]
  D --> E[保存 Markdown 文档<br/>放进 docs 目录]
  E --> F[AI 审阅文档<br/>找遗漏、歧义和风险]
  F --> G[确认最终方案<br/>排功能优先级]
  G --> H[Plan Mode 开发<br/>先规划再动手]
  H --> I[人工确认<br/>老师验收关键结果]
  I --> J[功能测试<br/>跑起来、点一遍、查边界]
  J --> K[沉淀规范<br/>更新 agents.md]

这张图看着比“让 AI 写代码”麻烦。但它能省掉后面大量返工。

文档是 AI 的黑板

老师都知道，课堂上不能只靠嘴说。重点要写在黑板上。AI 开发也是一样。

你每次在对话框里解释需求，AI 不一定能长期记住。更麻烦的是，换一个会话、换一个工具，前面说过的东西可能就断了。所以要把关键内容写进 Markdown 文档。

比如：

• docs/prd.md：写清产品需求。
• docs/tech-design.md：写清技术方案。
• docs/todo.md：记录功能优先级和开发计划。
• agents.md：沉淀项目里的开发规范和注意事项。

这些文档就是项目的公共记忆。以后你让 AI 接着开发，不用从头讲一遍，只要让它先读这些文档。这比在聊天框里反复解释要稳得多。

AI 也要被审阅

不要因为代码是 AI 写的，就默认它是对的。更好的做法，是让一个 AI 帮你写，再让另一个 AI 帮你审。审什么？

不是审得很玄。就审这些具体问题：

• 需求有没有遗漏？
• 有没有一句话存在歧义？
• 哪些功能应该先做，哪些可以以后再说？
• 技术方案会不会太复杂？
• 后续维护会不会很难？
• 有没有明显的安全或数据风险？

这件事很像磨课。第一次备课稿不一定差，但拿给同组老师看一眼，往往能发现自己没想到的地方。AI 审阅文档，也是这个意思。

不必把 Web Search 当唯一入口

遇到技术问题，搜索当然有用。但在 AI 开发里，很多时候更重要的是本地上下文。AI 需要先知道你的项目结构、已有文件、需求文档和当前报错。否则它就算搜到一堆资料，也不一定能落到你的项目上。

如果工具支持 MCP，可以连接官方文档、数据库、Sequential Thinking 这类能力。这些能力的价值，不是让你显得很高级，而是让 AI 少猜一点，多看一点真实依据。但这一篇不展开配置。

先记住一个原则就够了：

先让 AI 看你的项目和文档，再让它查外部资料。

老师仍然是最后的负责人

Plan Mode 很有用。它能让 AI 先规划，再开发，避免一上来乱改文件。但最终确认的人还是你。

因为只有你知道，机房实际有多少台电脑，班级轮换是怎么安排的，同事会不会用这个页面，打印出来的座位表够不够清楚。AI 可以帮你写代码。但它不能替你理解学校现场。

从这一刻开始，你的角色就不再是“问 AI 要一段代码的人”。你更像一个项目指挥者。你负责把真实问题说清楚，把关键结果验到位，把开发规范沉淀下来。

下一篇，我们就要回到电脑本身。指挥链搭起来了，还得让本地环境真的能跑。Python、Node.js、pip、npm、环境变量和黑窗报错，这些看起来烦人的东西，都是项目落地前必须打通的路。

封面