Vibe Coding工具选型与实战：从意图传递到全局MD文档

1. 先说清楚一件事：vibe coding 选工具，选的是“意图的传递效率”

我的一个真实感受是：vibe coding 这个说法被用烂了。很多人以为 vibe coding 就是打开一个 AI 编辑器，把需求往对话框里一贴，等着代码自己长出来，遇到问题就让 AI 再改一次。这样做不是 vibe coding，是买彩票。真正靠 vibe coding 持续把项目做出来的人，几乎都在工具选择上花过不少心思。他们问的问题不是“哪个工具最火”，而是“我的项目、我的团队、我的使用习惯，到底适合什么样的工具组合”。这篇内容我会把 vibe coding 常用工具怎么选这件事拆开讲透，包括主流工具的真实差异、个人和团队两种场景下的组合方案、全局 md 文档的用法，以及一套从零搭建开发环境到实战交付的完整流程。

1.1 vibe coding 的核心不是代码，而是意图

先抛一个结论：vibe coding 真正改变的不是写代码的动作，而是“意图传递”的方式。传统开发里，你要把需求翻译成函数、类、接口、数据结构，AI 只是辅助你补全语法、跳转定义、查文档。vibe coding 反过来，你只需要把目标、约束、验收标准说清楚，把“你想要什么结果”描述到位，剩下的编码细节由模型来完成。

所以选工具，本质上是在选“意图传递的效率”。如果一个工具能让你用更少的语言把背景讲清楚，又能准确读取项目上下文，那它就是适合你的。反之，如果一个工具交互很酷，但每次对话都要你反复解释项目结构、重新粘贴代码片段，那它再有名也会拖累你。

这也是为什么我坚持认为，工具评测不应该只看生成代码的质量。生成质量只是结果，更关键的是：它支持哪些模型，模型的更新和切换是否方便；它的上下文管理能力怎么样，能不能自动索引整个项目；它的 Agent 能力有多强，是只能改单文件，还是能跨文件搜索、执行命令、跑测试。

1.2 决定工具选型的三个底层变量

• 模型接入方式。有些工具自带模型订阅，比如 Cursor、Copilot 这类，打开就能用；有些工具需要你自己配 API Key，比如 Aider，还有部分基于开源模型的方案。自带订阅的好处是省事，坏处是模型选择和升级不完全由你控制。自己配 Key 的灵活性更高，但成本和对技术栈的要求也更高。

• 上下文管理能力。这是最容易被忽略、实际影响最大的变量。AI 能不能看懂你的项目结构，取决于它有没有建立索引、能不能读全局文档、能不能在对话中引用具体文件。上下文管理差的工具，你每次都要手动把相关代码贴进去，等于把意图传递的负担又甩回给你。

• Agent 能力。简单说就是 AI 能不能自己动手。基础补全只需要看当前文件；好一点的聊天模式能结合对话和当前文件给出修改建议；更强的 Agent 模式可以自己列计划、搜索代码库、修改多个文件、执行命令、根据报错自动调整。项目越复杂，Agent 能力越重要。

我遇到过不少朋友，工具选得很随意，项目做一半卡住了，跑来问我是不是模型不行。其实多半是工具和场景不匹配。你要做的是先想清楚自己属于哪种玩家，再去对比工具，而不是反过来。

2. 主流工具挨个说透，别只看谁名气大

市面上能用来 vibe coding 的工具非常多，但真正值得放在一起比较的，其实就那么几款：Cursor、GitHub Copilot、Trae Code、Claude Code，以及终端派的 Aider 等。我会把它们的差异尽量说清楚，包括使用体验和适用边界。

2.1 Cursor：目前最像“AI 原生编辑器”的那个

Cursor 是我个人用得最久的主编辑器。它的定位不是给现有 IDE 加一个 AI 插件，而是把 AI 能力直接设计进编辑器底层。Tab 补全、行内编辑、对话框、Agent 模式，这些功能之间切换得很顺，你可以一边跟 AI 对话，一边看它改代码，改完直接验证。

它对大型代码库的支持是明显优势。项目索引建立之后，AI 能理解模块之间的关系，当你提到一个函数名，它能自动找到定义和调用处，不需要你手动去翻文件。对于需要跨文件修改的重构任务，这一点非常关键。

不过 Cursor 也有槽点。第一是订阅费用不算低，而且不同模型的调用配额分开计算，用量大的时候容易触顶。第二是功能更新快，快捷键和界面经常变，团队协作时需要花一点时间同步习惯。如果你愿意折腾，并且以 IDE 为主要工作环境，Cursor 是很均衡的选择。

2.2 GitHub Copilot：IDE 工程流的减负款

GitHub Copilot 是最早出圈的产品，很多人对它印象还停留在“Tab 补全神器”，但现在的 Copilot 已经不是一个补全插件了。它在 VS Code 和 JetBrains 家族里都有深度集成，支持 Chat、Edit、多文件编辑，还能借助 GitHub 仓库的上下文，对代码仓库级别的任务做处理。

Copilot 的优势在哪儿？如果你是重度 VS Code 用户，平时写代码本来就在这个环境里，那么 Copilot 几乎不需要改变任何工作习惯。它把模型能力放进你熟悉的地方，你原来看代码、调试、提交的流程都不变，只是多了一个随时可以叫出来的 AI 助手。团队层面，它提供统一的管理策略，管理员可以规范模型使用、控制权限，这对企业团队很重要。

它的短板是 Agent 能力相对克制，复杂重构时更多需要你一步一步引导，不像 Cursor 那样可以放给 AI 自己去跑。但如果你需要的是稳定、不打断工程流程的提效工具，Copilot 很值得优先考虑。

2.3 Trae Code：免费、中文友好、上手成本低

Trae Code 是字节跳动推出的 AI IDE，我把它列为新手上路的第一推荐也不为过。最大的优点是免费，且对中文用户极其友好。它内置了对多种主流模型的接入，不用自己配 API Key，打开就能开始 vibe coding。全中文的界面和提示词生态，让很多英文一般的新手也能顺利上手。

它的 Builder 模式，我认为对做前端原型特别友好。你描述一个页面的布局、交互、样式，AI 会直接帮你生成可运行的代码，并试图在预览里展现出效果。如果做内部小工具、验证灵感、课程作业这类项目，Trae 的效率和体验都相当好。

当然，作为较新的产品，它在大型项目的索引性能和生态丰富度上还没法和 Cursor 比。我通常把 Trae 当第二工具用，处理轻量任务、快速验证想法，以及给团队里刚入门的新同学做演示。它足够轻、足够快、足够省事。

2.4 Claude Code / Aider：终端派 Agent，复杂重构更敢下手

如果你平时习惯命令行工作流，可以把眼光放到 IDE 之外。Claude Code 是 Anthropic 推出的终端 Agent 工具，安装之后直接在项目目录里跑，AI 通过命令行访问代码库，可以自己搜索代码、修改多个文件、执行测试、调用 Git。它不是编辑器，而是一个住进你项目的助手。

使用 Claude Code 的感受很特别。在 IDE 里，AI 更像是和你一起看代码的同事；在 Claude Code 里，AI 更像是那个说“我去看一眼整个仓库再回来改”的人。遇到大型项目重构、迁移、调试棘手 bug，这种仓库级理解能力非常有价值。

Aider 是另一个我很喜欢的轻量终端工具。它本身不绑定某个模型，支持自己配置多个后端模型。它和 Git 结合得很深，每次 AI 修改都会形成独立的提交记录，你可以随时回退，查看它到底动了哪些位置。对于习惯用 Git 管理一切的人来说，这种模式让人很有安全感。

2.5 一张表帮你快速分流

为了让你有一个大致的判断，我做了个表格。注意它不是绝对排名，而是帮助你理解差异。

简单分流的话：想免费快速上手，选 Trae；离不开 VS Code 并且想团队统一管理，选 Copilot；想要全面极致的 AI 原生体验，选 Cursor；要处理复杂重构，再把 Claude Code 或 Aider 作为补充接入工作流。

3. 工具组合的实战玩法：个人和团队的两种搭法

单一工具解决不了所有问题，这是我在实际项目里最深的体会。vibe coding 常用工具怎么选，看似在选个别工具，其实更重要的是把它们组合起来，形成工作流。

3.1 个人全链路组合：一个 IDE + 一个 CLI + 一个全局文档

我自己长期用的一套组合，可以浓缩成“一个 IDE 加一个 CLI 再加一份全局文档”。IDE 负责日常写代码、预览、调试，承担 80% 的交互场景；CLI 工具在复杂重构和疑难 bug 时登场，因为它能站在整个仓库的视角看问题；全局文档负责让每一次新对话都站在同一套约定上开始，避免 AI 对着一个陌生的项目反复瞎猜。

举个例子。我最近在维护一个中型的内部管理后台，前端 Vue、后端 Go。日常新增页面、改接口字段，我都在 Cursor 里完成，因为这类任务改的文件少，上下文容易控制。但有一次要做一次数据库字段迁移，涉及几十个文件，我还让 AI 把相关接口文档和查询逻辑都梳理一遍。这种时候我直接用 Claude Code 扫全仓库，让它先列迁移影响面，再批量改代码，最后跑测试。如果没有 CLI 这一层，这种任务会让 IDE 里的对话变得很冗长，上下文也容易乱。

组合里最容易被忽略的是全局文档。你可能会问，文档也算工具？我的回答是，在 vibe coding 工作流里它比很多工具都重要。因为所有 AI 工具都是“无记忆的”，每次新对话它都是第一次见你的项目。全局文档就是给它补上“项目背景记忆”的唯一稳定方式，具体怎么写我放在后面专门讲。

3.2 团队协作时 vibe coding 怎么不翻车

团队协作和单人开发完全是两个物种。单人用 vibe coding，出问题个人补；团队一旦多人同时用 AI 改代码，如果约定不一致，仓库会迅速变成灾难现场。

第一个建议是：工具数量要收敛。团队充分对比后，用一种 IDE 作为主流，比如统一 Cursor 或统一 Trae；CLI Agent 可以作为少数人的进阶工具，但版本和模型要尽量统一。不然就会出现这种情况：你用 Cursor 把代码格式化好了，队友用 Copilot 又按另一种风格改了一遍，diff 里全是无意义改动。

第二个建议是：全局规则进仓库。把项目的代码规范、目录约定、常用命令、禁止事项，全都写进根目录的 AGENTS.md 文件并提交到版本控制。这样不管谁开新对话、谁用哪个工具，AI 都能读到同一份约束。这里强调一句，文件一旦进仓库，它就是契约，不能再是某个人本地自己维护的小抄。

第三个建议是：AI 生成代码必须走 review。我的原则是，任何 AI 生成的大段代码，合入之前一定要有真人看一眼 diff。不是说 AI 一定写得不好，而是它可能会写出看似正确但不该存在的逻辑，或者破坏你完全没预料到的边界情况。团队里最好约定：提交时标注一下哪部分来自 AI，评审时重点看这些区域。

第四个建议是：上下文要分享。做过团队协作的人都懂，一个需求从提出来到交付，中间会经历很多轮讨论。AI 不会参与这些讨论，如果你不把结论写进文档，它只能从代码里猜意图。所以需求定型后，把背景和验收标准落到文档里，AI 的输出会稳定很多。

3.3 组合背后几个原则，少走弯路

• 每件事只让一个工具负责。写日常代码用一个 IDE，做复杂重构用一个 CLI，管理上下文用一套文档。不要十个工具轮着用，切换成本比工具收益大得多。
• 上下文尽可能沉淀到仓库里。凡是希望 AI 每次都遵守的规则，都放进仓库内文档，而不是只写在某个工具的对话记录里。对话会消失，仓库不会。
• 可回退第一。选择工具组合时，优先看它是否支持 Git 集成、是否方便查看 diff、是否容易撤销。vibe coding 安全性靠的不是模型能力，而是你能不能在出问题时快速回到安全状态。
• 保留人工审查环节。AI 负责干活，你负责把关，这个分工在团队协作里尤其重要。

4. 全局 md 文档就是项目的“长期记忆”

聊到这里，全局 md 文档这个词已经反复出现。接下来我详细讲讲它到底是什么，以及怎么写才能真正发挥作用。这也是“vibe coding 全局 md 文档”这个热词背后大家真正关心的问题。

4.1 为什么没有文档，AI 会越写越乱

你可能有这种体验：同一个项目，上午让 AI 写了一个模块，风格看着还挺像样；下午新开一个对话让它写另一个模块，它突然不认识项目里的公共工具函数，又自己造了一个类似的。这是因为 AI 每次对话的上下文是隔离的，项目结构、命名风格、已存在的工具函数，它只能通过上下文来发现。如果你不给它足够的线索，它就只能根据模型权重里的“常识”来推测。

全局 md 文档的作用，就是把这个“发现”过程变成“读取”过程。AI 在新对话开始时会读取项目规则文件，相当于你提前做了一份项目说明书。说明书里写清楚：项目技术栈是什么，目录结构怎么组织，命令怎么跑，命名和代码风格有哪些要求，哪些操作是禁区。这样 AI 就不会在每次对话里从零摸索。

很多人误以为文档是写给人看的，所以在项目里不重视。在 vibe coding 时代，文档是写给两种读者看的：人，还有 AI 模型。而且 AI 对文档的依赖程度远高于人类。

4.2 一套可以直接抄的 AGENTS.md 模板

目前比较通用的约定是把规则文件命名为 AGENTS.md，不过 Cursor 也支持 .cursorrules，Claude Code 会关注 CLAUDE.md。为了避免分散，我的习惯是直接维护一份 AGENTS.md，然后根据工具需要做软链接或复制引用。文件建议放在项目根目录，内容不要太长，够用就行。

下面这个模板是我在多个项目里迭代出来的，你可以直接复制后按项目改：

# AGENTS.md ## 项目简介 一句话说明项目是做什么的，面向谁，核心价值是什么。 ## 技术栈 - 前端：Vue 3 + TypeScript + Vite - 后端：Go + Gin + PostgreSQL - 部署：Docker / Nginx ## 项目结构 - src/pages：页面组件，按路由组织 - src/components：公共组件 - src/api：接口请求统一封装 - internal/service：业务逻辑层 - internal/store：数据访问层 ## 常用命令 - npm install：安装依赖 - npm run dev：启动前端开发服务 - go test ./...：运行后端全部测试 - make migrate：执行数据库迁移 ## 代码规范 - 接口请求必须走 src/api 下统一封装，禁止在组件里直接 fetch - 后端错误统一返回 { code, message } 结构 - 新增数据库字段必须同步更新迁移文件和文档 - 组件命名使用 PascalCase，文件名使用 kebab-case ## 禁止事项 - 不要修改公共工具函数，除非有明确理由 - 不要跳过现有测试 - 不要在前端代码里硬编码接口地址 - 不要擅自定义新的错误码 ## 常用模式 举例说明项目里最常见的代码样板。比如创建一个新表单页需要改哪几个文件。

这份文档最核心的部分是“技术栈、项目结构、常用命令、代码规范、禁止事项”这五段。前四段让 AI 知道项目长什么样，最后一段约束它不要乱来。有这些东西打底，AI 每次的输出都会稳定很多。

4.3 维护细节：什么时候更新、哪些别写

文档不是写一次就完事。我个人的维护原则是：只要项目发生了结构级改动，比如新增目录、切换框架、调整接口规范，就必须同步更新 AGENTS.md。这里很容易犯的错是把文档写成流水账，什么都往里面堆。文档越长，AI 越难提取有效信息，效果反而下降。

我见过很典型的一个翻车案例：一个人写了一个 400 行的 AGENTS.md，把每次对话的琐碎记录都塞进去，结果 AI 每次读取时上下文被无关内容占满，代码越写越跑偏。后来我们把文档缩减到 80 行，只保留项目结构、命令、规范、禁区，效果立刻好了很多。

还有一个技巧：文档里要放置 AI 能直接用得上的内容。比如“新增页面时一般要修改哪几个文件”，这种操作级别的指引，AI 按照执行起来非常顺。反而是很多概念性描述，AI 读完也不知道怎么落地，属于无效信息。

5. 从零搭建 vibe coding 开发环境：以 Trae Code 为例

工具再好，不实际配好环境都是空的。这一节我以 Trae Code 为例，带你完整走一遍 vibe coding 开发环境的搭建过程。整个流程大概 15 分钟，配好之后你就能在日常项目里直接开工。

5.1 安装与模型配置

Trae Code 的安装比较简单，去官网下载对应系统的安装包，装好打开就是一个完整的 AI IDE。第一次启动它会引导你选择偏好，比如界面语言、主题，直接选中文就行。

接下来是关键步骤：把项目导入进来。如果你是已有项目，选择“打开文件夹”，让 Trae 索引一遍项目文件；如果是新项目，直接在 IDE 里初始化一个文件夹，然后放上 AGENTS.md 和基础工程文件。

模型配置方面，Trae 内置了主流模型的选择入口，你在设置里能看到模型列表，选一个适合当前任务的即可。如果你的项目对模型有特殊要求，也可以手动配置 API Key。但新手我建议直接用内置模型，先跑通流程，再考虑个性化。

有一点要提醒你：打开项目后，要给 Trae 一点时间完成索引。我见过有人刚打开项目就立刻开始对话，然后抱怨 AI 看不懂代码，其实就是索引还没建好。你可以在界面右上角或状态栏看到索引状态，等它完成再开始。

5.2 接 MCP 和外部工具，补上最后一块短板

如果你只让 AI 改代码，它能做的有限。但当你希望 AI 能访问外部数据、操作浏览器、读写文件系统，就需要用到 MCP。MCP 可以理解为“AI 工具的数据插座”，通过统一的协议把外部服务接入 AI 的对话上下文里。

所谓 MCP，全称是 Model Context Protocol。你可以把它当成一种标准接口，让 AI 工具统一地去调用本地或远程的资源。比如你想让 AI 访问 GitHub 仓库、读取数据库 schema、操作浏览器，都可以通过 MCP server 实现。

以 Trae 为例，你可以在项目配置里添加 MCP server。下面这段 JSON 是一个简单的 GitHub MCP 配置示例：

{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] } } }

配置好之后，AI 就可以在对话中直接查询或操作 GitHub 资源。不过我的建议是，MCP 不是越多越好。每接一个 MCP，都会增加上下文的复杂度，也会引入外部服务的安全风险。一开始只接入你真正需要的，比如数据库、文件系统、代码托管平台，后面有明确需求了再逐步增加。

5.3 每天开工前我固定做的几件事

环境配置好之后，日常使用要养成稳定的开工习惯，这也是避免“AI 突然变笨”的一个关键手段。

第一件，git pull，把合作分支的最新代码拉下来。AI 是基于你当前工作区的内容来思考的，如果你的代码不是最新的，它会基于旧代码做出错误判断。

第二件，打开 AGENTS.md，快速扫一遍。确认没有新的规则或结构调整，如果你自己改了规则，更要确认已经保存并提交。

第三件，重新加载 IDE 的索引。这个动作很多人会忽略，但当你切换分支、拉取新的依赖之后，索引经常是过期状态。在 Trae 里可以触发重新索引，Cursor 也有类似功能，花几秒时间，能避免后面一堆冤枉路。

第四件，在对话开始时，先给 AI 一个“项目定位”。不要上来就直接说“帮我改这个页面”，而是简单说一句“我们这是一个 Vue 3 + Go 的内部管理后台，项目结构见 AGENTS.md，现在我要做的是……”。你可能会觉得多余，但这几次操作能大幅提升 AI 第一次输出的准确率。

6. 实战方法：从模糊需求到可发布结果，我的完整流程

工具也好、环境也好，最后都要落到具体干活上。这一节分享我的实战流程，核心是“把需求拆成任务单，让 AI 只干它擅长的事，你来干它不擅长的事”。

6.1 需求拆解：把“我想要个什么东西”变成任务单

vibe coding 最大的敌人，不是代码能力，而是模糊表达。你跟 AI 说“给我做一个商品列表页”，它大概率会给你一个中规中矩的页面，但极可能不符合你的真实需求。所以开工之前，我会把需求整理成任务单，再喂给 AI。

一个可复用的任务单模板长这样：

## 任务 新增一个商品列表页，支持按分类筛选和关键词搜索。 ## 背景 商家后台目前只有订单页，没有商品管理入口。需要在此页面上完成商品的上下架操作。 ## 验收标准 - 页面路由为 /admin/products - 列表展示商品名称、分类、价格、状态 - 支持按分类筛选和关键词搜索 - 点击“下架”按钮后，弹窗确认，成功后状态更新为下架 - 接口需走既有 api 封装，不直接 fetch ## 注意事项 - 参考现有订单页的布局风格 - 分页组件复用 src/components 下的 Pagination - 不要新增数据库字段

这个任务单的长度只有几段话，但效果比“帮我做个商品列表页”好太多。因为它把背景、验收标准、约束都交代清楚了，AI 在动手之前就知道边界在哪里。做出来的东西即使有偏差，也是细节层面的偏差，不会是方向性的错误。

6.2 生成后三道审查关卡，拒绝当免费 QA

AI 生成完代码，别急着合入。我已经养成了过三道审查关卡的习惯，任何 AI 生成的内容都必须先过这三关。

第一关，结构检查。打开 git diff，看它到底动过哪些文件。这里最容易发现的问题：AI 改了不该改的文件，或者新增了一个多余的命名空间。如果 diff 里有你不熟悉的大段改动，一定要弄清楚原因，不要让不明不白的修改混进主分支。

第二关，业务逻辑对照。拿着任务单里的验收标准，一条一条过。比如任务单要求“分页组件复用既有组件”，AI 有没有这么做？要求“接口走 api 封装”，它有没有老老实实走封装？这一关能拦住大部分“看起来能跑但不符合要求”的代码。

第三关，安全与边界。检查输入校验、错误处理、权限控制。AI 生成代码时经常在正常路径上表现良好，却在异常输入和边界条件下翻车。比如一个删除接口，AI 可能没做重复提交保护，或者没有正确处理空值，这些都是容易出问题的地方。

如果你比较熟练，这三关可以很快过完；如果项目要求高，可以再补上自动化测试和 lint。流程不复杂，但它决定你是在“用 AI 提效”，还是在“给 AI 打工”。

6.3 AI 反复改不对，通常是上下文出了问题

实战里最让人抓狂的场景，就是 AI 改了一遍又一遍，还是不对。这个时候千万不要继续在同一个对话里刷“再试一次”，你大概率只是在喂养同一个错误的上下文。

我的排查思路是：先停下来，把问题缩小。原对话如果已经聊了很久，上下文里堆了大量历史信息，我会新开一个对话，把任务背景简化后重新描述一遍。很多时候新对话的第一次输出，会比老对话的第十次输出准确得多。

如果新对话还是不行，下一步是检查 AGENTS.md。项目里是不是有什么隐藏约定没写进去？AI 是不是因为不知道某些约束，所以给出了一个“看起来合理但违背项目现实”的方案？把缺失的约定补进文档，再重新开对话。

最后一个办法，是把大任务拆小。AI 一次处理的任务越复杂，出错的概率就越高。与其让它一次改十个文件，不如拆成三四个小步骤，每步验证完再继续。这很像你带新人：你不会让一个实习生第一天就独立负责整个模块，你会先给它一个小任务，熟悉了再逐步放权。

6.4 几个长期受益的习惯

• 每个对话只干一件事。对话一旦开始发散，立刻新建一个。
• 完成一个阶段就提交。AI 的修改要经常入库，回退时才有安全感。
• 保留有效提示词。遇到效果好的任务单或对话开头，我会存档，方便以后复用。
• 定期更新全局文档。项目规范变了一次，文档就更新一次，别拖。
• 永远保留人工审查。AI 帮你写出代码，但你得对代码负责。

7. 关于 vibe coding 面试，我观察到的考题和答题框架

现在“vibe coding 面试题”也成了热门搜索词，我顺便聊聊我观察到的面试题和答题思路。这个方向其实很值得重视，因为越来越多的团队开始把 AI 编码能力放入考察范围。

7.1 高频面试题和回答思路

实际面试里，团队问得比较多的有这么几类问题：

• “你理解中的 vibe coding 是什么？” 不要只回答“用 AI 写代码”。更好的表述是：vibe coding 是一种以意图为导向的开发方式，人负责定义目标和验收标准，AI 负责具体实现，关键在于意图传递的准确性和对生成结果的审查能力。

• “你常用哪些工具，为什么这么选？” 这里要体现选型思路，而不是罗列工具名。你可以说：日常开发用某个 IDE，因为上下文管理强；复杂重构用终端 Agent，因为它具备仓库级理解能力；团队协作时用全局文档统一规则，保证多人的 AI 行为一致。

• “AI 生成代码出 bug 了，你怎么排查？” 比较好的回答是讲链路：先看 diff，锁定修改范围；再对照验收标准，确认是否逻辑偏离；然后缩小上下文，在新对话里带上错误堆栈和最小复现；最后补测试并修正文档。这个回答展示了你有完整的闭环意识，而不只是会点“生成”按钮。

• “如何让团队 AI 协作效率更高？” 可以围绕几个点展开：统一工具版本、把规则写进仓库、强制 code review、通过全局文档共享上下文。

7.2 被质疑“太依赖 AI”时，我会这样回应

很多面试官会担心：你什么都让 AI 写，自己是不是不会写代码了？我的回应思路是，工具是放大器，不是替代品。真正需要的能力，是判断 AI 生成结果是否正确、是否安全、是否高效。你仍然需要懂代码，而且要能读懂 AI 写的代码。只是因为工具变了，你把更多精力分配给了更上游的设计和更下游的审查。

我也会主动承认，依赖本身不可怕，可怕的是失去辨别能力。如果一个人根本看不懂 AI 生成的内容，也没法在两套方案之间做出选择，那他确实不应该把这个责任完全交出去。但只要你可以解释清楚每一段生成代码的作用，并且能在出错时快速定位问题，那么 AI 只是一个很听话的初级工程师，而你是有判断力的技术负责人。

我个人在实际带团队的时候，选人的标准也慢慢倾向于这种能力：能不能把模糊想法变成清晰任务，能不能在 AI 输出面前保持判断力，能不能在技术债务和安全风险上把住关。我觉得这才是 vibe coding 时代真正的“核心竞争力”，也是所有工具选型最后要回到的那个原点。