第八章高级玩家怎么玩 Vibe Coding超越问答模式如果你把 AI 还停留在问答机器人阶段那你只用到了它能力的一小部分。高级玩家已经不只是让 AI 帮我写函数而是在玩Agent让 AI 自主规划并执行多步骤任务自动化开发流把 AI 嵌入开发流水线多模型协作不同模型分工干不同的事自动 PR / 测试 / review机械性工作全部自动化MCP给 AI 接上万能外设打通外部工具和数据Skills把常用能力封装成可复用的模块Hermes Engineering用工程化方法设计可靠的人机协作流上下文工程精心设计 AI 的工作环境什么是 Agent简单理解Agent 就是不只会回答还会自己采取一连串动作的 AI。比如你说“修复登录接口的 500 错误。”普通聊天模型给你一个分析思路你自己去改。Agent 则可能自己去读取项目代码查找相关日志分析错误原因修改文件运行测试验证修复是否有效给你一个改动摘要它像一个会干活的助理而不是只会出主意的顾问。Agent 的核心能力来自什么Agent 之所以能干活依赖的是工具调用能力Tool Use / Function Calling工具作用文件系统访问读文件、写文件、创建目录代码执行运行 Python / Shell 命令网络请求访问 API、查文档、搜索数据库操作查询和修改数据浏览器控制访问网页、截图、交互当这些工具组合起来AI 就从会说话变成了会干活。现实中 Agent 能干到什么程度目前2025 年中的现实是擅长的任务明确的、步骤可预测的任务如把这 50 个 CSV 文件合并并去重有明确验证条件的任务如改到测试通过为止重复性高的任务如给每个 API 接口生成对应的测试用例还不擅长的任务需要深刻理解业务规则的任务容易跑偏涉及产品判断的任务用户体验、优先级决策长链路、高度不确定的任务中途容易出错且难自我纠正自动化开发流怎么玩比较成熟的玩法通常是需求文档 ↓ AI 拆解任务生成任务列表 ↓ 每个任务 → 生成实现草案 ↓ 自动跑测试 ↓ 自动修复一轮低级问题lint、格式、简单 bug ↓ 生成 PR 描述 ↓ 人类 review 和验收这个流程适合什么团队最适合任务明确、规范清晰的团队有良好测试覆盖的项目没有测试自动化流没有安全网做内部工具、CRUD 类系统不适合需要频繁判断产品方向的项目测试覆盖率低的老项目改了就可能出问题但不知道创意型、探索型产品开发多模型协作像组建 AI 团队一样思考为什么要多模型协作不同模型的长处不一样模型擅长Claude长文推理、代码分析、安全审查GPT-4o对话理解、多模态、广度Gemini超长上下文、代码执行DeepSeek中文语境、性价比本地模型数据隐私、低延迟把它们像团队一样分工效果往往比只靠一个模型干到底更稳。实际案例三模型分工任务实现用户权限系统分工ChatGPT需求分析帮我把这个权限需求梳理清楚列出角色、权限点、场景Claude代码实现基于上面的分析帮我用 FastAPI 实现 RBAC 权限系统Claude / GPT-4oCode Review检查这段实现是否有安全漏洞和边界问题Prompt 示例让 AI 做 Code Review请从安全审查角度检查这段权限控制代码。 重点关注 1. 是否有权限绕过的可能 2. 是否有垂直越权低权限用户访问高权限资源 3. 是否有水平越权用户 A 访问用户 B 的数据 4. Token 验证是否完整 5. 是否有 SQL 注入风险 对于每个问题请 1. 描述漏洞 2. 给出攻击路径示例 3. 给出修复建议 [贴代码]自动 PR、自动测试、自动 Review 的价值不是完全替代工程师而是把大量机械工作自动化自动 PR 描述每次 commit 后让 AI 根据 diff 自动生成 PR 描述请根据以下 git diff生成一份 Pull Request 描述。 格式 ## 背景 [改动的原因是什么解决了什么问题] ## 改动内容 [用 bullet point 列出主要改动] ## 影响范围 [这次改动影响了哪些功能/接口] ## 测试说明 [如何验证这次改动] git diff [贴 diff]自动测试补全我刚写了这个函数请帮我生成对应的单元测试。 要覆盖 1. 正常输入的期望输出 2. 边界值空、None、极大值 3. 异常情况应该抛出什么异常 4. 如果有外部依赖用 mock 函数代码 [贴代码]自动化 Lint 修复这是 pylint 的报告请帮我修复所有 E 级Error和 W 级Warning的问题。 约束 1. 不要修改函数逻辑只修改代码风格和明显错误 2. 对于无法自动修复的问题标注原因 lint 报告 [贴报告]MCP给 AI 装上万能外设什么是 MCPMCPModel Context Protocol是 Anthropic 发布的开放标准解决的是一个核心问题AI 模型如何以统一、安全的方式接入外部工具和数据源在 MCP 出现之前每个 AI 工具想接入 GitHub、数据库、Slack 或本地文件系统都需要各自造轮子——接口不统一、权限模型各异、集成成本高。MCP 就像给 AI 定了一套USB 标准任何遵循 MCP 协议的服务AI 都可以直接调用不需要专门适配。MCP 的工作方式你 ←→ AI 模型Claude ↕ MCP 协议 MCP Server工具提供者 ↕ GitHub / 数据库 / 文件系统 / Slack / ...整个通信链路你给 AI 下指令“帮我查一下这个 PR 有没有安全问题”AI 通过 MCP 协议调用 GitHub MCP ServerGitHub MCP Server 读取 PR 的 diff 和评论数据返回给 AIAI 分析后给你结果你不需要手动复制粘贴 PR 链接和代码AI 自己去取数据。常见的 MCP ServerMCP Server能做什么mcp-server-github读写 GitHub 仓库、PR、Issue、Actionsmcp-server-postgres执行 SQL 查询、读取表结构mcp-server-filesystem读写本地文件、目录操作mcp-server-slack发送消息、读取频道历史mcp-server-brave-search网页搜索mcp-server-puppeteer控制浏览器截图、点击、填表mcp-server-memory跨会话记忆存储社区 MCP Server 数量还在快速增长基本覆盖了开发者日常用到的所有外部服务。MCP 如何改变 Vibe Coding没有 MCP 的工作流你说帮我看看 PR #123 里有没有 N1 查询问题 → 你手动打开 GitHub复制 diff → 粘贴到 AI 对话框 → AI 分析 → 你再去 GitHub 写评论有 MCP 的工作流你说帮我看看 PR #123 里有没有 N1 查询问题有的话直接在对应行加 review 评论 → AI 通过 GitHub MCP 读取 PR diff → AI 分析后通过 GitHub MCP 直接写入 review 评论 → 整个过程你不需要离开对话框AI 从只能说变成了能说能做。配置 MCP 的基本思路以 Claude Code 为例在.claude/settings.json里声明需要哪些 MCP Server{mcpServers:{github:{command:npx,args:[-y,modelcontextprotocol/server-github],env:{GITHUB_PERSONAL_ACCESS_TOKEN:your_token}},postgres:{command:npx,args:[-y,modelcontextprotocol/server-postgres],env:{POSTGRES_CONNECTION_STRING:postgresql://localhost/mydb}}}}配置完成后AI 就可以直接对 GitHub 和数据库执行操作你只需要用自然语言说需求。安全注意事项MCP 赋予 AI 操作外部系统的能力这意味着风险也在放大给 MCP Server 配置最小权限原则只读权限优先涉及写操作提交代码、发消息、修改数据库的第一次用时仔细确认 AI 的计划生产环境的 MCP 接入要谨慎建议先在测试环境验证Skills把 AI 能力封装成可复用模块什么是 SkillsSkills 是一种把特定 AI 能力封装成可复用、可分享单元的机制。类比到编程没有 Skills每次遇到code review需求你都要重新写一遍完整的 Prompt有 Skills你定义一次/review指令之后只需要输入/review就触发这个完整的能力Skills 解决的核心问题是Prompt 资产的标准化和复用。Skills 的三个特点特点一封装性一个 Skill 把角色设定、上下文要求、执行步骤、输出格式全部打包在一起。使用者不需要知道内部怎么写的只需要触发。特点二可调用性在支持 Skills 的工具如 Claude Code里Skills 通过斜杠命令/skill-name触发像调函数一样简单。特点三可分享性Skills 可以保存在项目目录里团队所有成员共用同一套标准化能力。也可以发布到公共仓库让社区复用。Skills 的实际用法在 Claude Code 中Skills 存放在.claude/skills/目录下每个 Skill 是一个 Markdown 文件示例/security-reviewSkill--- name: security-review description: 对当前分支的改动做安全审查 --- 你是一名资深安全工程师。 请对以下代码变更进行安全审查重点关注 1. **注入风险**SQL 注入、命令注入、路径遍历 2. **认证/鉴权**接口是否缺少权限校验是否有越权风险 3. **数据泄露**敏感信息是否会出现在日志、响应或错误信息里 4. **依赖风险**新引入的依赖是否有已知漏洞 输出格式 - 按严重程度分类Critical / High / Medium / Low - 每条问题给出位置、风险说明、修复建议 - 没有发现问题时明确说未发现明显安全风险 [读取当前分支与 main 的 diff]使用时只需要输入/security-reviewClaude Code 就会执行这整套审查流程。示例/docSkill--- name: doc description: 为指定函数或模块生成文档注释 --- 请为下面的代码生成文档注释。 规范 - 使用 docstring 格式Python或 JSDocJavaScript/TypeScript - 包含功能说明、参数说明类型 含义、返回值说明、可能抛出的异常 - 语言中文 - 风格简洁不废话 不要修改代码逻辑只添加注释。为什么团队应该维护一套 Skills 库好处说明标准化所有人的 code review 标准一致不再因人而异降低门槛新成员直接用现成 Skills不需要学习怎么写 Prompt持续改进Skills 可以迭代好的经验沉淀下来减少重复常见任务一键触发不用每次手写 Prompt一个成熟团队的 Skills 库可能包含/review— 代码审查/security-review— 安全审查/doc— 生成文档/test— 生成测试用例/refactor-check— 检查重构安全性/pr-desc— 生成 PR 描述/perf-check— 性能问题检查Hermes Engineering系统化构建可靠的人机协作什么是 Hermes EngineeringHermes 是古希腊神话中的信使之神掌管通信与协作。Hermes Engineering借用这个意象指的是以工程化方式设计、构建和维护人与 AI 之间通信协议的方法论。如果说 Prompt Engineering 关注的是怎么问一个好问题那么 Hermes Engineering 关注的是更宏观的问题如何让人机之间的每一次通信都可靠、可预期如何设计 AI 在工作流中扮演的角色和接口如何让 AI 的输出格式化、可验证、可组合Hermes 消息格式Hermes Engineering 的核心实践之一是结构化消息格式。混乱的消息是这样的帮我看看这段代码有没有问题顺便改一下然后给我解释一下Hermes 风格的消息是这样的tasktypecode_review_and_fixcontext这是一个 FastAPI 的用户认证接口使用 JWT/contextcodefileauth/router.py[代码内容]/codeinstructions1. 先列出所有安全问题不要改代码 2. 等我确认后只修复 Critical 和 High 级别的问题 3. 每处修改附上一句说明/instructionsconstraints- 不修改函数签名 - 保持现有错误处理方式/constraintsoutput_format[问题列表] → 确认 → [修复后代码]/output_format/task这种结构化格式的好处角色清晰AI 知道每部分内容代表什么步骤分离分析和执行分开防止 AI 跑偏可验证每个instructions里的要求都能单独核查可复用格式模板化后不同任务只换填充内容Hermes Engineering 的四个核心原则原则一消息即接口Message as Interface把每一次给 AI 的消息当成一个函数调用的接口来设计输入Input你传入的上下文和参数行为BehaviorAI 应该做什么输出Output你期望收到的格式和内容设计好这三者AI 的行为就会稳定可预期。原则二约定优于即兴Convention over Improvisation不要每次靠运气让 AI 猜你要什么。把频繁出现的模式变成约定所有 code review 消息遵循同一个模板所有 bug fix 请求包含同样的五个字段所有功能实现先分析再编码约定一旦确立就写进 RULES.md 或 Skills团队一起遵守。原则三步骤化执行Step-by-step Execution把大任务分解成带检查点的小步骤每个步骤完成后人工确认再推进Step 1分析 → 人工确认方向 Step 2设计方案 → 人工确认技术选型 Step 3实现 → 人工 review 代码 Step 4测试 → 人工验收不要把所有步骤合并成一步帮我做完整个功能——那是在赌运气不是在工程化。原则四可验证性Verifiability每次 AI 的输出都应该有明确的验证方式代码能跑通测试就是合格分析报告有具体文件名、行号可以去对应位置核查方案设计有明确的决策点可以和需求逐条比对没有验证方式的输出质量就只能靠运气。Hermes Engineering 在实际项目里的样子一个采用 Hermes Engineering 的团队他们的 AI 工作流可能是这样的1. 需求进来 → 用标准化 Prompt 模板做需求拆解 ↓ 2. 任务清单出来 → 每个任务用 Skill 触发对应能力 ↓ 3. 代码生成 → 自动触发 /security-review 和 /review Skill ↓ 4. Review 通过 → 用标准化模板生成 PR 描述 ↓ 5. PR 合并 → 触发 /test 生成回归测试用例整个链路每一步都有标准化的输入输出格式每一步都有明确的验收标准每一步都可以独立触发、独立验证这就是 Hermes Engineering 的核心价值把AI 帮你干活从碰运气的事变成工程化可控的过程。MCP Skills Hermes Engineering 的组合三者结合构成了高级玩家的完整工具箱层次技术解决的问题连接层MCPAI 如何访问外部工具和数据能力层SkillsAI 的标准化可复用能力协作层Hermes Engineering人机协作如何可靠、可持续没有 MCPAI 只能在对话框里干活要你不停复制粘贴没有 Skills每次任务都要重新写 Prompt无法积累没有 Hermes EngineeringAI 的输出不稳定协作靠运气三者缺一高级玩法就只能做到一半。上下文工程高级玩家的核心竞争力什么是上下文工程就是精心设计 AI 工作时能看到的信息。这是高级玩家和普通玩家最大的差距之一。策略一RULES.md项目规则文件在项目根目录创建一个规则文件每次给 AI 任务时都附上# 项目开发规则 ## 技术约束 - 前端React 18 TypeScript Ant Design - 后端FastAPI SQLAlchemy 2.0 - 数据库PostgreSQL 15 ## 代码规范 - 后端按 router/service/model/schema 分层 - 前端组件用函数式不用 class - 所有 API 请求通过 src/api 目录封装 - 错误处理统一用 AppError 类 ## 禁止事项 - 不引入未在 package.json 中的新依赖 - 不在组件里直接写 fetch/axios 调用 - 不修改 shared/types.ts 以外的类型定义 - 不做 SQL 字符串拼接 ## 命名约定 - 数据库表名snake_case 复数users, todo_items - API 路径/api/v1/resources - 组件文件PascalCaseUserList.tsx - 工具函数camelCaseformatDate.ts策略二分层上下文策略根据任务类型给不同级别的上下文任务类型应该给的上下文修小 bug报错信息 相关函数约 50 行新增功能项目规则 相关模块结构约 200 行架构决策项目说明 现有结构概览约 500 行完整模块项目规则 接口规范 相关模型约 1000 行策略三摘要压缩不要把整个文件塞给 AI先让它处理你的摘要这个项目的目录结构如下 [贴目录树] 主要模块说明 - src/authJWT 认证用户登录注册 - src/todosTodo CRUD支持标签和优先级 - src/users用户管理 我需要在 todos 模块里新增一个置顶功能 请问这个功能应该改哪些文件先列出来我再逐一贴给你看策略四任务分解流大任务分多个 Session 来做每个 Session 专注一个小目标Session 1确定数据库表改动 Session 2实现后端 service 层 Session 3实现后端 API 层 Session 4实现前端组件 Session 5接口联调 测试每个 Session 都是独立的只带当前 Session 需要的上下文。实际案例用 AI 自动处理低风险维护任务场景把所有金额显示统一保留两位小数这是非常适合 Agent 化的任务因为需求明确两位小数有验证标准肉眼可以看出来范围可控只改展示层低风险不影响数据计算执行 Prompt请把这个任务当成一个低风险批量修改任务来处理。 目标统一所有金额展示为两位小数。 执行步骤必须按顺序 1. 先搜索项目中所有展示金额的地方关键词price, amount, total, money, 金额 2. 按文件分类列出来不要直接改等我确认 3. 我确认后只改前端展示逻辑 4. 不要改 - 后端返回值格式 - 数据库存储格式 - 计算逻辑 5. 改完后列出所有修改点我来验证 注意如果某个地方你不确定该不该改列出来问我不要自作主张高级玩家的真实工作流一个常见套路规划阶段ChatGPT/Claude把需求和方案讲清楚得到清晰的任务分解实现阶段Cursor/Claude Code在本地项目里按任务分解依次实现Review 阶段另一个模型/同一个模型对生成代码做安全和质量检查收尾阶段AI 辅助生成测试计划和 PR 描述这里最重要的不是工具而是工作流意识——你是在设计一条让 AI 持续可靠干活的流水线而不是随机地问问 AI。高级玩家的心态把 AI 当流水线不当魔法棒高级玩家不会说让 AI 帮我解决这个问题而是说我来设计这个工作流让 AI 在里面稳定输出。前者把结果交给了 AI后者把控制权留在了自己手里。接受 70 分快速迭代AI 的第一版输出通常是 70 分。高级玩家不会等 AI 给出 100 分而是接受 70 分快速识别哪 30 分需要改精准反馈让 AI 迭代或者干脆自己补那 30 分这种节奏比追求完美 Prompt 一次就对快得多。建立属于自己的 Prompt 资产高级玩家会积累项目的 RULES.md各类任务的 Prompt 模板常见场景的 System Prompt一套稳定好用的工作流 SOP这些资产会让你的 AI 协作效率越来越高而不是每次都从零开始。一句话总结高级玩家玩 Vibe Coding不是更会下咒语而是更会设计一条让 AI 持续可靠干活的流水线。上一章第七章 — 如何用 AI 从零开发一个完整项目下一章第九章 — 普通人未来该如何应对 AI 编程时代