企业官网建设流程全解析

1. 为什么说 AI 编程 Agent 是“从零开始能用”的分水岭

过去两年里，“AI 编程”经历了三个阶段：最早是聊天窗口里的代码问答，你问一段、它答一段，复制粘贴还得自己改；后来是 IDE 里的补全插件，能在你打字时预测下一行，但对整个项目的理解始终隔着一层。到了这一轮，终端里的 AI 编程 Agent 才是真正改变工作方式的东西——它不再是一个“给建议”的助手，而是一个能自己打开文件、运行命令、看报错、再改代码的协作者。

我自己的经历是这样的：上个月用 Claude Code 接了一个小需求，修改一个内部工具的前端页面，涉及布局调整、接口字段变更和三处状态管理逻辑。放到以前，我得自己翻半天代码再动手。这次我只是在终端里描述了目标，它自己定位了组件文件，改了样式，跑了测试，看到 TypeError 后又回头修了类型定义，最后还帮我提交了 commit。整个过程里我做的事情基本就是“提出要求”和“在关键节点确认方向”。

这就是终端 Agent 和普通 AI 编程工具的本质区别：它具备“感知—决策—行动—验证”的循环能力，能在真实的项目环境里自主工作。而支撑这个循环的，除了底层模型本身，还有两套生态——Skills 和 MCP。Skills 解决的是“模型怎么知道你这个项目的具体规范”，MCP 解决的是“模型怎么安全地接入外部工具和数据”。这两个概念，加上五款主流终端 Agent 的横向对比，就是这篇内容要讲透的核心。

这篇文章适合三类人：刚接触 AI 编程、想知道“从零开始能用的 AI 编程”到底怎么入门的初学者；已经在用 AI 补全工具、但感觉效率没到质变的开发者；以及想在团队里推动 AI 编程落地、需要做技术选型的技术负责人。

2. Agent 的核心工作方式与“可用性”三个维度

2.1 为什么 Agent 不能只看模型能力

很多人选 AI 编程工具时只盯着底层模型跑分，这是一个误区。Agent 的表现不只看“脑子好不好”，更看它能不能在终端环境里稳定地把任务执行完。

我对 Agent 的理解是：它像一个刚入职的实习生，模型是它的学习能力，但真正决定它能不能干活儿的，是它能不能看懂你的项目结构、会不会正确使用工具、遇到报错时能不能自己调整策略。这些能力分散在三层：

• 模型层：负责理解和生成代码。这是 Agent 的推理基础，但不是全部。
• 工具层：Agent 通过调用终端命令、文件读写、代码搜索、浏览器操作等工具与真实环境交互。
• 方法论层：告诉 Agent 你的项目规范、代码风格、测试要求、发布流程。这一层目前主要由 Skills 承担。

三层缺一不可。模型再强，如果工具调用经常出错、或者不了解你的项目规范，产出的代码依然不能用。这也是为什么我会把“终端 Agent + Skills + MCP”放在一起讲——它们是同一个系统的三个部分。

2.2 判断 Agent 能不能用的三个硬指标

根据我的实际体验，评价一个终端 Agent 是否“从零开始能用”，主要看三个维度：

任务完成率。在一个中等规模项目里，让它实现一个需要改多个文件的功能，它能独立完成多少？是完全不用管，还是需要频繁纠正？

工具调用的可靠性。Agent 在终端里跑命令、读写文件、处理报错，这些操作的成功率直接决定体验。我见过一些 Agent 模型很强，但工具调用经常超时或传错参数，根本没法用。

上下文管理能力。项目一大，上下文就容易被无关内容塞满。好的 Agent 会主动忽略 .gitignore 里的内容、跳过 node_modules、只读取跟当前任务相关的文件。差的 Agent 会把半个项目都读进去，然后开始胡说八道。

如果一款工具在这三个维度上都能达到及格线，那么它在“真的拿来干活”这件事上才算过关。

2.3 终端 Agent 和 IDE Agent 的区别

现在市面上的 AI 编程工具分两类：IDE 插件型（比如 Cursor、Trae、GitHub Copilot）和终端型（比如 Claude Code、Codex CLI、Gemini CLI、Aider、OpenCode）。

IDE 插件的优势是图形界面直观，代码补全和行内编辑体验好，适合日常开发中“边写边改”的场景。但它的边界感更强——AI 的活动范围基本被限制在编辑器内部，要操作终端、跑测试、改配置，需要额外的权限和配置。

终端 Agent 的优势是权限边界更宽，能干更多“重活”。它就是在命令行里运行的，天然能执行任意 shell 命令、读写文件、调用版本控制。这意味着它可以自己跑测试、查日志、改配置文件、甚至部署预览环境。对于“给我实现一个功能”这种任务，终端 Agent 明显更有优势。而且终端不依赖特定 IDE，你用什么编辑器都不受影响，SSH 到远程机器上也能用。

我个人的习惯是两者配合：用 IDE 插件做日常编码时的即时辅助，用终端 Agent 做独立功能的实现和重构任务。

3. Skills 与 MCP：两套生态到底在解决什么问题

3.1 Skills：给 Agent 一份“项目使用说明书”

Skills 这个概念，我理解得更简单一些：它是一组结构化的指令和参考材料，告诉 Agent 在特定场景下应该怎么做事情。早期 Agent 只有一个 system prompt，你要把项目背景、编码规范、常用命令全部塞进去，很快就超长。Skills 把这些问题拆成了一个个独立模块，按需加载。

比如你在开发一个 Flutter 项目，有一个flutter_skill的 SKILL.md 文件，里面写清了状态管理用的是 Riverpod、目录结构是 feature-first、测试命令是flutter test、常见坑有哪些。Agent 在接手任务时会先读取这个文件，然后按里面的规范执行。这相当于给 Agent 配了一个“老师傅的经验清单”。

Skills 的目录结构通常长这样：

skills/ └── frontend-dev/ ├── SKILL.md └── references/ ├── code-style.md └── component-library.md

其中SKILL.md是这个技能的说明书，Agent 通过它了解技能用途、启用条件和操作步骤。references/目录放详细参考文档，Agent 需要时再读取，避免一次性占用太多上下文。

3.2 MCP：把 Agent 的“手”伸向外部世界

如果 Skills 是给 Agent 装“方法论”，那 MCP（Model Context Protocol）就是给它装“新器官”。MCP 是一个开放协议，标准化了 AI 应用与外部数据源、工具之间的通信方式。你可以把它理解为 AI 世界的 USB 接口——只要设备支持 MCP，接上就能用。

MCP 的架构分两层：MCP Server（提供工具和数据的一方）和 MCP Client（调用这些工具的一方）。你的 Agent 是 Client，它通过 MCP 连接各种 Server，就能访问 GitHub、浏览器、数据库、设计稿、文件系统等。

实际价值举个例子：接上 Playwright MCP 之后，Agent 可以自己打开浏览器、访问页面、检查布局、截图验证，再根据截图上看到的问题调整代码。这在做前端开发时简直是质变——Agent 不再只能“猜”页面的效果，而是能“看”到实际渲染结果。

我在实践中常用的几个 MCP Server 包括：

3.3 Skills 和 MCP 的分工关系

很多人分不清 Skills 和 MCP，其实它们有清晰的边界。Skills 是“知识和规范”，没有执行能力。MCP 是“能力和连接”，没有领域知识。一个告诉 Agent 怎么做是对的，一个给 Agent 提供做的工具。

打个比方：桌椅组装。Skills 是操作手册——告诉你螺丝要拧几圈、板子的朝向、顺序是什么。MCP 是电钻和螺丝刀——让你真正能把木板固定在一起。

把技能提到一个高度，就理解了为什么我建议新手先学 Skills 再折腾 MCP。Skills 是纯文本文件，写起来没有门槛，维护也简单。MCP 涉及服务端部署、权限管理、配置调试，复杂度高得多。先把 Skills 用明白，日常效率已经有明显提升；再逐步接入 MCP，就能处理更复杂的自动化场景。

4. 五款终端 Agent 横评：选型之前要看懂的差异

4.1 横评范围与打分逻辑

这轮横评我选了目前社区讨论度最高的五款终端 Agent：Claude Code、Codex CLI、Gemini CLI、Aider 和 OpenCode。每个我都实际用过一段时间，任务涉及新项目脚手架搭建、老项目 bug 修复、前端页面还原、测试补写等。整体打分维度是：

• 任务完成率（40%）：能不能独立把活干完。
• 工具调用可靠性（20%）：终端命令、文件操作的成功率。
• 上下文管理（15%）：会不会被无效信息干扰。
• 可配置性（15%）：能不能接入私有模型、自定义工具。
• 成本与上手难度（10%）：综合开销和学习曲线。

4.2 五款 Agent 对比表

4.3 逐一拆解：各自的性格和场景适配

Claude Code是当前综合完成率最高的终端 Agent，没有之一。它的优势在于 Claude 模型本身的长上下文能力和工具调用准确性，在实际任务里很少出现“说了做但做错”的情况。它还有个很好的习惯：每完成一步都会主动告诉你下一步计划，让你有掌控感。缺点是它捆绑 Anthropic 的服务，部分地区访问体验一般，而且用了 Cursor Pro 模式额度用完后单独续 Claude Code 的成本不低。

Codex CLI的优势在于 OpenAI 模型对代码的理解深度，眼下最强的代码能力就在这里。它的 GitHub 集成体验尤其好，可以实现从 Issue 到 PR 的自动化链路。我实际测试过它自动创建 PR 的全流程，包括分支创建、commit、push、PR 描述，体验很流畅。但它的上下文管理目前还不够聪明，大项目里容易“丢三落四”，需要频繁提醒。

Gemini CLI的核心特色是超长上下文。百万级 token 意味着什么？你可以把整个仓库塞给它都不爆。适合做“代码库级”的问答和分析，比如重构前了解全局再动手、跨模块排查 bug 这类任务。它还能读图片，你截图给它看 UI 问题，它能理解并定位代码。不过单看代码生成质量，它和 Claude、GPT 的旗舰模型还有差距。

Aider是开源界的老将，陪伴了很多 AI 编程玩家从 0 到 1 的整个过程。它的设计很极客：通过 git 管理 Agent 的每次修改，每次改动都有 diff，回滚方便。它支持接入本地模型，数据完全私有，这对有保密要求的项目尤其友好。但它的“终端 Agent”属性比较基础，没有复杂的选择器机制和前摄性规划，需要用户自己掌握主导权。

OpenCode是最年轻的一档，UI 做得漂亮，支持多模型切换且开源免费。它适合想低成本入门的用户：不用订阅、用自己的 API Key 就行。社区迭代非常快，每月都有一堆新功能。缺点是稳定性还有待锤炼，偶尔会出现卡死或上下文错乱的情况。

4.4 我的选型建议

如果你在乎完成任务的质量，团队预算充足，直接上 Claude Code。如果你深度使用 GitHub 生态，想体验从 Issue 到 PR 的自动化，Codex CLI 值得认真试。如果你要分析大型仓库、跨模块理解代码，Gemini CLI 最合适。如果你有模型偏好、爱折腾、想省订阅费，Aider 或 OpenCode 是开源阵营里的首选。

我自己的日常工作流里，Claude Code 和 Codex CLI 是主力，Gemini CLI 作为超大项目的分析工具备用。根据任务类型切换，比死守一款工具高效得多。

5. Skills 的创建与安装：从零开始写一个可复用的技能包

5.1 Skills 的本质是结构化知识库

Skills 不是什么黑魔法，它的本质就是把“一个领域内的高质量操作方法”结构化地写下来，让 Agent 只能在需要时读取。跟直接塞进 system prompt 相比，Skills 最大的价值是“按需加载”和“模块化复用”。

社区里最活跃的 Skills 项目之一是 Superpowers。这个项目提供了一系列已经写好的技能，覆盖代码 review、前端开发、调试、文档写作等场景。安装方式很简单——把它 clone 下来，然后把对应目录配置到客户端的 skills 路径里，Agent 就能识别。

我自己测试过它的前端开发技能，里面明确写了“分析组件前先看设计稿标注”“样式改动后用浏览器验证”等具体步骤。乍一看有点像“多此一举”——这些都是开发常识，为什么还要写下来？关键原因在于：模型不是人，它不知道你的项目里这些常识具体怎么落地。一个通用的“前端开发技能”并不够，你需要写上“本项目用 Tailwind，不用 CSS Modules”“颜色全部取自 design-tokens.css”这种项目特有的规范。Skills 存在的意义，就是把“你脑子里的项目上下文”搬到 Agent 能读到的地方。

5.2 手把手：写一个信息收集类 Skill

从我做过的一个需求出发：我需要让 Agent 在写周报前自动收集这周的 commit、PR 和 Issue 动态。我写了一个weekly-reportSkill，目录结构如下：

skills/ └── weekly-report/ ├── SKILL.md └── scripts/ └── collect_git_log.sh

SKILL.md的核心内容如下：

--- name: weekly-report description: 收集当前项目的 Git 提交记录和 PR 信息，生成周报草稿。 当用户说“生成周报”“总结本周工作”时使用。 --- ## 当使用本技能时 1. 先运行 `scripts/collect_git_log.sh` 获取本周 git log。 2. 根据 commit 类型（feat/fix/docs）分类整理。 3. 如果仓库关联 GitHub，可调用 GitHub MCP 查询本周 PR 列表。 4. 输出周报，语言简洁，直接列举成果，不写套话。

对应的 shell 脚本负责拉取数据：

#!/bin/bash SINCE=$(date -d "7 days ago" +%Y-%m-%d) git log --since="$SINCE" --pretty=format:"%h %ad %s" --date=short

这个 Skill 的核心逻辑在于：把“收集信息 + 整理 + 输出”的流程固定下来，下次说到“生成周报”，Agent 不会临场发挥，而是按照明确路径操作。你只需要把这段流程固化沉淀下来，以后每次复用都是在为自己节省时间。

5.3 安装社区 Skills 的三个判断标准

社区 Skills 数量越来越多，质量参差不齐。根据我的经验，拿到一个陌生的 Skill 包，先看三件事：

看 SKILL.md 是否有足够具体的操作步骤。如果内容都是泛泛而谈的套话，比如“认真分析用户需求、编写高质量代码”，基本没什么用。好的 Skill 必须包含明确的检查清单和操作顺序。

看 references 目录的厚度。技能包有没有配套的参考文档、示例代码、常用命令速查表。这个决定的不是“能不能用”，而是“效果好不好”。

看你自己的项目是否匹配。这是最关键的。Skills 是高度领域化和个性化的，别人的技能用在你的项目里可能水土不服，需要你调整。社区 Skills 最合理的用法是“参考它的结构，写自己的内容”，而不是“装完就完事”。

6. MCP 协议的配置与实战：从安装到排查一整套流程

6.1 MCP 为什么是“协议级”的标准

在 MCP 之前，每个 AI 工具都自己写一套工具接入方案，互不兼容。MCP 的出现相当于行业约定了一个统一的“插头标准”。你只需要把 MCP Server 配置一次，任何支持 MCP 的 Client 都能复用这套接入。

这两年的生态发展非常快，从官方仓库到社区自建，各种 MCP Server 琳琅满目。除了一开始提的 Playwright、GitHub、Filesystem，还有一批面向特定场景的服务，比如蓝湖 MCP 就是给设计稿到前端还原场景准备的，它能读取设计稿上的标注、导出切图，直接喂给 Agent 去写样式。实测下来，这类设计类 MCP 能把前端开发里最繁琐的“量尺寸、凭感觉”环节压缩掉一大半。

6.2 配置实例：在 Claude Code 里接上 Playwright MCP

下面是在 Claude Code 中配置 Playwright MCP 的实际过程。首先打开 Claude Code 的 MCP 配置文件（一般在~/.claude.json或项目根目录.mcp.json），添加如下内容：

{ "mcpServers": { "playwright": { "command": "npx", "args": [ "@playwright/mcp@latest" ], "env": { "BROWSER": "/usr/bin/google-chrome" } } } }

配置完成后重启 Claude Code，在对话中敲/mcp命令，就能看到 playwright 的状态为 connected。这个过程中有一个经验值得分享：env里的BROWSER变量最好显式指定浏览器的可执行文件路径，否则在某些 Linux 环境下 MCP 会找不到默认浏览器，启动失败。

配置好之后，你可以直接对 Agent 说：

打开 http://localhost:3000，检查首页导航栏在 768px 宽度下是否换行，如果有问题，直接修复并让我截图确认。

Agent 会调用 Playwright MCP 打开浏览器，执行视口切换，截图，分析问题，再回头修改代码。整个闭环非常流畅，比我手动开 DevTools 反复验证省力太多了。

6.3 排查 MCP 故障的实践方法

MCP 配置看着简单，但实际用起来一定会遇到问题。我把自己的排查经验总结成一套签核流程：

第一步：确认服务注册成功。启动 Agent 后先查看 MCP 连接状态，没连上的直接看启动日志里的报错。很多问题在这一步就能发现。

第二步：用 Client 侧的命令做最基本的连通性测试。先在终端里手动把 MCP Server 命令跑一遍，确认能正常启动并输出 JSON 响应。比如对于 Playwright MCP，你可以手动运行一次启动命令，看是否输出{"jsonrpc":"2.0"}之类的握手信息。

第三步：逐项检查业务请求是否正常。让 Agent 调用一个最简单的 MCP 工具，比如列目录或读文件，确认链路通了，再逐步增加复杂度。

**第四步：排查网络。**部分 MCP Server 需要访问外部服务，比如 GitHub 或 Figma API，这类服务如果你的网络环境有问题，MCP 调用就会超时。遇到这种情况，只能先确认你本地到目标服务的连通性是否正常，再回头排查配置文件里的代理和超时设置。

这套排查流程解决了我遇到的绝大多数 MCP 问题。它不依赖具体哪款工具，出差到任何项目里都能复用。

6.4 MCP 权限设置的两个重要原则

MCP 接入的工具越多，Agent 的权力就越大，安全隐患也随之上升。我在项目中一直遵循两个原则：

最小权限。MCP Server 能给只读就只读，能给单目录就单目录。比如 Filesystem Server，不要让它直接挂载根目录，而是挂载项目下的workspace目录，防止它误读或误改无关文件。

操作前确认。配置 Agent 执行高风险操作（删除、覆盖、提交、推远程）前，必须停下来向用户确认。Claude Code 里可以启用 permission mode，Codex CLI 有沙箱模式，这些都是默认该开启的设置。宁可多两步确认，不要图一时方便关闭保护。

7. 一个完整案例：设计稿到前端页面的全自动实现

把 Skills、MCP 和 Agent 串起来看一次，比看十篇介绍都有用。下面是我最近做的一个真实需求：把一个 Figma 设计稿还原成 React 页面，并且要求响应式细节和设计稿保持高一致性。

7.1 任务拆解与工具准备

这个任务需要的核心能力包括：读取设计稿标注、获取设计资源、编写组件代码、在浏览器里验证效果。我在项目里预装了三个 MCP Server：Figma MCP（读取设计稿 svg/section 树、组件标注）、Playwright MCP（浏览器渲染验证）和 Filesystem MCP（保存生成的页面文件）。Skills 层面挂了前端开发的组件规范和代码风格文件。

一切就绪后，我用一句话发起了任务：

根据 Figma 设计稿【登录页 v2.3】，在 src/pages/Login 下重新实现这个页面。要求代码遵循项目的组件规范，最终用浏览器验证还原度。

7.2 实际执行过程中的若干关键节点

Agent 的第一步不是写代码，而是去 Figma MCP 里搜索设计稿、读取页面结构。这个过程我观察到它拿到了设计稿里的图层树和关键元素定位，包括按钮尺寸、间距值、色值标注等。

第二步，它读取了项目已有的设计 token 文件，发现了设计稿里的某些色值不在 token 范围内。按照项目规范，它没有硬编码新色值，而是在 Skill 定义的规范里找到“新增 token 需在 design-tokens.css 中登记”的规则，自动完成了 token 扩展。

第三步，它编写组件，调用了项目的 Button、Input 等公共组件，然后打开浏览器预览。Playwright MCP 的截图返回后，它发现导航栏标题在移动端有溢出现象，于是回到代码里调整了字体尺寸和间距，再次验证通过。

整个流程大概花了 8 分钟，期间没有人为干预。输出的代码通过了项目已有的 lint 规则，commit 信息也写得清晰合规。设计稿里的间距、圆角、字号等细节，达到了能直接交付的水平。

这种“设计稿到代码”的自动化能力，对前端开发效率的提升是革命性的。以前这类改动怎么也要忙活大半天，现在一个 Agent 会话基本就能消化。

8. 高频问题与避坑指南：真金白银换来的教训

8.1 常见问题速查表

8.2 几个容易踩但没人提醒的坑

坑一：让 Agent 直接读超大文件。有一次我让 Claude Code 优化一个 5000 行的组件文件，它直接把整个文件读进上下文，导致后面任务根本没法展开。正确做法是让 Agent 先用 grep 定位关键逻辑，只读取相关代码段。这个习惯能显著降低 token 消耗，也能减少上下文污染。

坑二：忽略了终端复用工具对 Agent 工作流的增强。我发现把终端 Agent 和 tmux 这类复用工具搭配使用很顺手：开多个窗格，一个窗格跑 Agent 做主任务，一个窗格手动验证，一个窗格看日志。不用来回切换 IDE 和终端，Agent 干活的同时你能实时观察。特别是长任务，你需要同时盯几个实时过程。tmux 的会话保持功能还意味着 SSH 断开后任务不会中断，这对远程开发场景是刚需。

坑三：把社区 Skills 原样拿过来就用。我一直强调 Skills 是高度个性化的。我见过有人装了 Superpowers 之后效果反而不如默认提示词——因为那个技能里的规范跟他项目的实际情况完全对不上。安装社区 Skills 的正确姿势是：先通读里面的 SKILL.md，理解它设计了哪些步骤，再针对你的项目做修改。

坑四：在嵌入式开发场景里对 Agent 过度信任。热搜里有 ESP32 终端相关的关键词，恰好说明硬件圈子也在尝试 AI 编程 Agent。但我实测下来，Agent 在嵌入式项目里的完成率和软件项目差距很大，因为硬件代码高度依赖芯片手册、寄存器配置和具体硬件行为，模型训练数据里这部分覆盖不够。能用的场景是代码生成和重构，不能放心的是配置寄存器、调引脚这类“写错一次就烧板子”的操作。Agent 生成的代码你最好逐行 review，必要时在硬件抽象层包一层模拟器测试。

坑五：忽略 git 回滚的重要性。不管用什么 Agent，我强烈建议你每次让 Agent 大改前先建一个新的 git 分支或者至少 commit 一次。Agent 改坏了代码不可怕，可怕的是没有快速回退的锚点。Aider 在这点上做得最彻底，它的每次改动都走 git diff；其他工具也可以自己手动操作：任务开始前git checkout -b agent-task，任务结束后验证通过再合并。

8.3 关于无代码编程的周边困惑

每次聊 AI 编程都会有不太写代码的朋友问：我不会编程，能用 Agent 从零写出一个完整项目吗？我的答案是：能，但别指望完全躺平。

“从零开始能用的 AI 编程”这句话，准确的理解是“从零开始搭项目框架、实现基础功能的难度大幅降低了”，而不是“完全不需要人参与”。你还是需要能描述清楚需求、会在关键节点做出决策、能判断 Agent 给的方案是否正确。这更像是一个“产品经理 + 代码审查者”的角色，而不是“程序员”的角色。

如果你想往这个方向发展，我建议的入门路径是：先用自然语言让 Agent 做一个极简的 demo 项目，比如一个待办事项应用，理解 Agent 的工作习惯；然后尝试让它在 demo 上迭代加功能，逐步建立“需求拆解—生成代码—验证结果”的感觉。这个过程不是要你变成程序员，而是要你学会“管理一个能写代码的智能体”。

9. 终端复用工具与 Agent 的高效协作姿势

9.1 长任务的正确打开方式

很多人用终端 Agent 几分钟就着急，因为看到 Agent 一直在滚动输出，不知道在干嘛。这个时候，终端复用工具的价值就出来了。我现在已经形成了一套固定的工作流：

在 tmux 里开三个窗格，第一个是主力窗格，跑对话式 Agent 主任务；第二个窗格手动跑测试、检查服务端口、手动验证页面；第三个窗格用tail -f盯着应用日志。Agent 改完代码，你在第二个窗格验证，日志在第三个窗格实时滚动。整个调试闭环完全不用切出终端。

tmux 的会话保持功能也非常有用。有一次我在远程服务器上跑一个耗时的 Agent 任务，中途本地网络断了一分钟，重新连上后发现任务还在继续执行——因为 Agent 跑在 tmux 会话里，不受 SSH 断连影响。这个体验对我来说已经变成刚需。

9.2 给 Agent 预留“手动操作点”

Agent 在执行任务时，有时会出现它无法自行决策的情况。比如一个设计决策：按钮是放左边还是右边，规范里没写，设计稿也没标注。这时我会在任务描述里给 Agent 写一句“遇到这类开放性问题，停下来问我，不要自行决定”。这就是给 Agent 预留“手动操作点”。

具体到终端场景，我会在 tmux 里让 Agent 跑主任务，同时保持第二个窗格随时可以输入命令。Agent 说“我需要你确认一下……”的时候，我切过去给个指令，再回到主窗格让它继续。这种“人机配合”的节奏，比完全放手或者完全掌控都更高效。

9.3 让多个 Agent 并行工作

终端复用工具的另一个场景是并行。我经常开两个 tmux 会话，一个跑前端任务，一个跑后端任务，两个 Agent 各干各的。最后我在主窗格里负责整合它们的产物、跑联调测试。

并行工作的前提是任务之间没有强依赖。如果两个 Agent 改同一个文件，冲突会让你爆炸。所以我会在任务描述里明确各自的目录边界，并尽量让它们操作不同的模块。这个习惯让我把“一个人同时带两个 AI 实习生”变成了现实。

10. 说点掏心窝子的个人体会

这篇文章写得比较长了，最后想聊几句主观感受。

我自己的经验是，AI 编程 Agent 的提升确实是“指数级”的——但它不是替代你的技能，而是放大你的能力边界。代码写得越好、对项目理解越深的人，用 Agent 的效率提升越明显。原因很简单：你越能准确描述需求和判断输出质量，Agent 就越能高质量执行。一个完全不懂代码的人拿到 Agent，大概率也只能生成一堆“看起来能用但其实有问题”的代码。

还有一点很重要的是，这个领域的变化速度和工具迭代都太快了。我写这篇文章时提到的某些细节，可能一两个月后就过时了。所以不要指望“学会一个工具就一劳永逸”，更重要的是理解背后的原理——记住“模型、工具、方法论”三层架构这个框架，无论以后哪款工具崛起，你都能快速适应。

我给新人的建议是：选一款最顺手的终端 Agent，从一个小项目开始，用一到两周时间把它跑熟。然后试着写一个属于你自己项目的 Skill，把你常用的“套路”沉淀下来。等熟练了再接入 MCP，把外部工具纳入 Agent 的能力范围。这个路径，是我自己一步步走过来的，也是我目前认为从零开始上手 AI 编程 Agent 最稳妥的路。