npm#

大多数 coding agent 通过 npm 安装，这是 Node.js 的包管理器，可以到 Node.js 官网安装。

顺便解释几个新手容易混的东西：

• Node.js：让 JavaScript 能在浏览器外运行的环境。很多 Coding Agent 本身就是用它开发的。
• npm：Node.js 常用的包管理器，负责安装软件和依赖。
• npx：直接运行一个 npm 包，适合临时体验，不一定要全局安装。很多 skill 和 MCP 安装会用到。

一般流程就是：装 Node.js → 终端检查 node -v → 按对应 Agent 的官方说明安装 → 登录或配置模型。具体命令会更新，这里不硬抄一串迟早过期的命令。有问题优先看官方安装页。

Coding Agent#

1
npm install -g @anthropic-ai/claude-code

1
npm install -g opencode-ai

1
npm install -g @openai/codex

AI IDE（AI 代码编辑器）#

版本控制#

对 vibe coding 来说，版本控制相当重要，能避免 AI 乱改代码把项目搞报废，也能直观看到变更（diff）。直接用 Git 就行，一般在 AI IDE 侧边栏能找到。

建议每完成一个小功能就 Commit 一次，别等整个项目做完再提交。提交信息也别只写 update，至少写清这次完成了什么。这样就算 Agent 把项目改崩了，也能快速回到最近一个稳定版本。

还有一点：Commit 前一定要看 diff。Agent 说“已经完成”只代表它以为完成了，不代表真完成了。它可能顺手改了没让你改的文件，甚至删掉测试然后告诉你测试通过。emm，很有创造力，但这种创造力我们一般不需要。

了解不同的模式#

一般 Coding Agent 和 AI IDE 都有两个模式（不同软件可能有细微区别）：

• Plan（计划模式）：Agent 先根据你的需求提问、收信息，形成开发计划，再继续执行。
• Edit（编辑模式）：Agent 直接按你的指令改代码（如果其他提示词没有特殊要求的话）。

需求不明确、改动范围大、涉及多个文件时，先用 Plan。只改一句文案、一个样式或明确的小 bug，直接 Edit。不是所有事都要写十页计划，但复杂任务直接开写，往往要花更多时间擦屁股。

上下文管理#

上下文是 Agent 能读到的部分，包括系统提示词、用户消息、工具调用结果等。Agent 有上下文限制，过长会导致响应变慢、答非所问。所以别一个对话（Session）用到底，任务拆分，每个任务新开对话，既能防爆上下文，也减少上下文污染。

上下文不等于聊天记录。真正占空间的是 Token，消息、代码、图片、工具输出都会消耗。塞得越多不一定越聪明，有时只是让模型在一堆旧信息里迷路。

我习惯在任务阶段切换时开新 Session；如果当前对话开始忘约束、重复犯错或答非所问，就别舍不得，压缩上下文或直接开新对话。

还有个办法：用子代理开发，让强模型当编排者统揽全局，分配稍弱的模型去执行具体实现，能有效避免主 Agent 爆上下文。

常用命令#

下面是开发中常用的一些命令。不同 Agent 的命令可能不完全一致，以对应版本为准。

Skills#

Skill 可以理解成给 Agent 准备的可复用技能包。比如你常让它写博客、做代码审查或发布项目，就可以把固定步骤、检查清单、输出格式整理成 Skill，不用每次重新解释一大段。

社区也有不少大佬把工作流总结成 skill 分享，效果不错。我认为 Skill 最适合处理“经常重复，但又不能只靠一条命令完成”的工作——写得太泛失去约束，写得太死又难复用。可以去 GitHub 找些好的 skill，或把自己常重复的工作流整理成 skill。

MCP 与 CLI 工具#

MCP 让 Agent 连接额外的工具与数据源，比如文档、浏览器、数据库或其他服务。它解决的是“模型知道怎么做，但默认拿不到外部信息或工具”的问题。

不过 MCP 不是装得越多越好。工具越多，上下文和选择成本越高，权限范围也越大。我建议只接当前项目真需要的服务，别一股脑全塞进上下文。而且最近 CLI 工具正在兴起，有效解决了上下文容易爆满的问题，未来可能会逐步替代 MCP。

不要一句话塞十几个需求#

我以前也会直接说：“帮我把登录、支付、后台管理和 UI 一起做了。”看着省事，结果往往是每块都做了一点，但没有一块真正能用。

更好的是一次只做一个 Feature： 先讲清登录需求，完成、测试、提交，再开始支付。任务越明确，Agent 越不容易漂移，你也越容易检查结果。

Prompt 怎么写#

坏 Prompt 通常只有一句：

帮我优化一下这个页面。

这个“优化”可以是改颜色、改结构、提性能，也可以是重写整个页面。Agent 只能自由发挥，你再对着结果怀疑人生。

我更常用的写法：

先阅读首页相关文件，分析当前页面在移动端的布局问题。给出修改方案，暂时不要写代码。修改范围只限首页，不要调整全局主题。完成后运行现有测试，并列出改动文件。

不需要每次写成需求书。小任务一句话也可以，但至少要让“完成”这件事可以被判断。

用 AGENTS.md 固定项目规则#

AGENTS.md 或 CLAUDE.md 适合放长期有效、每个 Session 都要知道的项目规则。例如：

1
# 项目说明
2

3
- 项目类型：Minecraft Fabric Mod
4
- Java 版本：21
5
- 使用 Fabric API
6
- 不允许引入 Lombok
7
- 注释统一使用英文
8
- 修改后运行 ./gradlew test

但也别把全部细节塞进去。规则文件越长，重要内容越容易被淹没。只保留稳定事实、强约束和必要命令即可。

1. 一个 Session 从早聊到晚#

聊得越久，Agent 不一定越懂项目，还可能把已废弃的方案也记进上下文，造成严重污染。任务阶段切换时就开新 Session，别舍不得。

2. 没开 Git 就让 Agent 大改#

这是最刺激的玩法。改成功了很爽，改崩了只能重开。项目初始化后的第一件事就是启用 Git。

3. 一次让 AI 改几十个功能#

Agent 会很努力地给每个功能写一点，然后留下一个看着完成度很高、实际哪里都漏风的项目。拆任务、小步提交，永远比“一口气做完”稳。

4. 不写验收标准#

你说“做一个登录页”，Agent 做出页面就认为完成；但你心里可能还包括表单校验、加载状态、错误提示和移动端适配。需求没说清楚，它自然会挑最容易完成的理解。

5. 不 Review 就 Merge#

能跑不代表实现正确，测试通过也不代表没改坏别处。至少看一次 diff，确认没多改文件、硬编码密钥、吞异常或删测试。Vibe coding 可以让 AI 写代码，但不能把判断也外包掉。