【从零学Vibe Coding】第八章：高级玩家怎么玩 Vibe Coding
第八章：高级玩家怎么玩 Vibe Coding
超越问答模式
如果你把 AI 还停留在"问答机器人"阶段，那你只用到了它能力的一小部分。
高级玩家已经不只是"让 AI 帮我写函数"，而是在玩：
- Agent：让 AI 自主规划并执行多步骤任务
- 自动化开发流：把 AI 嵌入开发流水线
- 多模型协作：不同模型分工干不同的事
- 自动 PR / 测试 / review：机械性工作全部自动化
- MCP：给 AI 接上"万能外设"，打通外部工具和数据
- Skills：把常用能力封装成可复用的模块
- Harness Engineering：工程化设计 AI 的"挽具系统"，让模型从会聊天变成能稳定干活
- 上下文工程：精心设计 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-4o（Code 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 装上"万能外设"
什么是 MCP？
MCP（Model 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 Server
- GitHub MCP Server 读取 PR 的 diff 和评论
- 数据返回给 AI
- AI 分析后给你结果
你不需要手动复制粘贴 PR 链接和代码，AI 自己去取数据。
常见的 MCP Server
| MCP Server | 能做什么 |
|---|---|
mcp-server-github |
读写 GitHub 仓库、PR、Issue、Actions |
mcp-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 里有没有 N+1 查询问题"
→ 你手动打开 GitHub，复制 diff
→ 粘贴到 AI 对话框
→ AI 分析
→ 你再去 GitHub 写评论
有 MCP 的工作流：
你说："帮我看看 PR #123 里有没有 N+1 查询问题，有的话直接在对应行加 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 能力封装成可复用模块
什么是 Skills？
Skills 是一种把特定 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-review Skill
---
name: security-review
description: 对当前分支的改动做安全审查
---
你是一名资深安全工程师。
请对以下代码变更进行安全审查，重点关注：
1. **注入风险**：SQL 注入、命令注入、路径遍历
2. **认证/鉴权**：接口是否缺少权限校验，是否有越权风险
3. **数据泄露**：敏感信息是否会出现在日志、响应或错误信息里
4. **依赖风险**：新引入的依赖是否有已知漏洞
输出格式：
- 按严重程度分类（Critical / High / Medium / Low）
- 每条问题给出：位置、风险说明、修复建议
- 没有发现问题时，明确说"未发现明显安全风险"
[读取当前分支与 main 的 diff]
使用时只需要输入 /security-review，Claude Code 就会执行这整套审查流程。
示例：/doc Skill
---
name: doc
description: 为指定函数或模块生成文档注释
---
请为下面的代码生成文档注释。
规范：
- 使用 docstring 格式（Python）或 JSDoc（JavaScript/TypeScript）
- 包含：功能说明、参数说明（类型 + 含义）、返回值说明、可能抛出的异常
- 语言：中文
- 风格：简洁，不废话
不要修改代码逻辑，只添加注释。
为什么团队应该维护一套 Skills 库？
| 好处 | 说明 |
|---|---|
| 标准化 | 所有人的 code review 标准一致，不再因人而异 |
| 降低门槛 | 新成员直接用现成 Skills，不需要学习怎么写 Prompt |
| 持续改进 | Skills 可以迭代，好的经验沉淀下来 |
| 减少重复 | 常见任务一键触发，不用每次手写 Prompt |
一个成熟团队的 Skills 库可能包含：
/review— 代码审查/security-review— 安全审查/doc— 生成文档/test— 生成测试用例/refactor-check— 检查重构安全性/pr-desc— 生成 PR 描述/perf-check— 性能问题检查
Harness Engineering：工程化设计 AI 的"挽具系统"
什么是 Harness？
Harness（挽具） 原本指给马套上的笼头、缰绳、鞍具——一匹野马有再强的力量，没有挽具你也驾驭不了；套上挽具，它才变成可以拉车、可以骑乘的工作伙伴。
在 AI 工程里，Harness 指的是 LLM 模型外层的一整套脚手架系统：
┌─────────────────────────────┐
│ Harness（挽具系统） │
│ ┌──────────────────────┐ │
│ │ LLM 模型（裸引擎） │ │
│ └──────────────────────┘ │
│ │
│ + 工具定义 │
│ + 系统提示词 │
│ + 上下文管理 │
│ + Agent 循环 │
│ + 权限与 Hooks │
│ + 子 Agent 调度 │
│ + 错误恢复 │
│ + 记忆与持久化 │
└─────────────────────────────┘
裸模型只能"输入文本 → 输出文本"。让模型能读文件、跑命令、调 API、连续推理多步、记住跨会话的偏好——所有这些能力都来自外层的 Harness，而不是模型本身。
Claude Code、Cursor、Cline、Aider 这些工具，本质上都是不同设计的 Harness 包着同样的几个底层模型。模型决定能力上限，Harness 决定实际能干多少活。
什么是 Harness Engineering？
Harness Engineering 是把 AI Agent 当作系统来工程化设计的方法论。
如果说 Prompt Engineering 关注"如何问一个好问题"，那么 Harness Engineering 关注一个更底层的问题：
- 在模型固定的前提下，如何通过设计外层系统，让 AI 输出从"碰运气"变成"可预期"？
- 如何把工具、上下文、流程、权限、记忆这些组件组合成一台可靠的工作机器？
- 如何让 Agent 在长任务、多步骤、跨会话场景下不跑偏、不崩溃、不失忆？
这不是"写更好的 Prompt"，而是"造一台更好的机器"。
Harness 的七个核心组件
组件一：工具定义（Tools）
Agent 能做什么，完全取决于你给它配了哪些工具。工具的设计直接决定 Agent 的能力边界和可靠性。
好的工具设计：
- 粒度合适：太粗（“做一切事”）模型不知道怎么用；太细（每个 shell flag 一个工具）选项爆炸
- 命名清晰：
Read/Write/Edit比file_operation_v2强一百倍 - 错误信息有用：失败时返回的不是"Error"，而是"文件不存在，你可能想用 Write 创建它"
- 副作用可控：明确哪些工具会改变外部状态，哪些只是读取
举例，Claude Code 内置了 Read / Write / Edit / Bash / Grep / Glob 等工具，每个工具的输入输出都是高度结构化的。
组件二：系统提示词（System Prompt）
写在 Harness 里的"出厂指令"，每次会话都默认加载。决定 Agent 的行为风格、安全边界、默认偏好。
# 典型系统提示词包含的内容
- 角色定位：你是一个软件工程助手
- 工作原则：先读再改、不越权操作
- 输出风格：简洁、不冗余解释
- 安全约束：不执行破坏性命令前先确认
- 工具使用规范：什么时候用 Edit，什么时候用 Write
组件三：上下文管理（Context Management）
模型有窗口限制（哪怕 1M token 也有上限），Harness 决定每一轮对话里塞什么进去：
- 加载策略：当前打开的文件？最近的 git diff？CLAUDE.md 项目说明？
- 压缩策略：会话过长时如何摘要历史
- 检索策略：什么时候主动 grep 代码、什么时候读文件
- 遗忘策略：哪些信息每次都要重新加载，哪些可以丢弃
差的上下文管理会让 Agent"看不到该看的"或者"被无关信息淹没"。
组件四：Agent 循环（Agent Loop）
这是把"问答模型"变成"会干活的 Agent"的关键。最简形式：
循环：
1. 模型基于当前上下文输出"下一步要调用哪个工具"
2. Harness 执行工具调用
3. 把工具结果塞回上下文
4. 模型继续推理
5. 直到模型说"完成"或人工打断
Harness Engineering 的精髓之一就是设计这个循环：什么时候停？怎么避免无限循环？多步任务中途如何让人介入？
组件五：Hooks 与生命周期（Hooks & Lifecycle）
Hooks 是 Harness 在关键时刻执行的钩子函数。常见的钩子点：
| 钩子 | 触发时机 | 典型用途 |
|---|---|---|
| PreToolUse | 工具调用前 | 校验参数、记录日志、阻止危险操作 |
| PostToolUse | 工具调用后 | 格式化输出、触发 lint、自动跑测试 |
| UserPromptSubmit | 用户输入提交时 | 注入额外上下文、做敏感词过滤 |
| Stop | Agent 停止时 | 发通知、生成总结、提交 commit |
举例：你可以配置 PostToolUse hook，每次 Agent 改完 Python 文件就自动跑 ruff format。Agent 不需要知道这件事，Harness 自动处理。
组件六：权限与沙箱（Permissions & Sandbox）
哪些操作 Agent 可以自主决定，哪些必须人工确认？Harness 通过权限配置控制：
{
"permissions": {
"allow": ["Read", "Grep", "Glob", "Bash(git status)", "Bash(git diff)"],
"ask": ["Edit", "Write", "Bash(npm install*)"],
"deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
}
}
这是 Harness Engineering 里最影响"日常体感"的部分——配得好，Agent 顺滑高效；配得差，要么每步都要点确认（烦），要么放任 Agent 乱动文件（险）。
组件七：子 Agent 与分工（Sub-agents）
让一个主 Agent 调度多个专精子 Agent，每个子 Agent 有自己的工具集、提示词和上下文窗口。
主 Agent（规划）
├─ Explore Agent（快速搜索代码，只读权限）
├─ Plan Agent（设计实施方案，不写代码）
├─ Review Agent（独立 code review）
└─ Test Agent（生成并运行测试）
好处：
- 上下文隔离：子 Agent 的搜索过程不会污染主 Agent 的上下文
- 并行执行：多个独立子任务可以同时跑
- 专精化：每个子 Agent 的提示词为单一职责优化
Harness Engineering 的四个核心原则
原则一：能力来自系统，不来自模型
不要遇到问题就想"换更强的模型"。先问：
- 工具够不够？是不是 Agent 想做但没有合适工具？
- 上下文对不对？是不是 Agent 看不到关键信息？
- 权限是不是配错了？Agent 该自主做的事在等确认，不该做的事却放开了？
90% 的 Agent 不靠谱问题，是 Harness 没设计好，而不是模型不够聪明。
原则二：可观察性优先（Observability First）
把 Agent 当成生产系统来对待。你需要能看见：
- 每一步调用了什么工具，参数是什么，返回了什么
- 上下文里有什么，没有什么
- Token 用在哪里了
- 哪些 hooks 触发了，做了什么
没有可观察性，调 Agent 就是在黑盒里摸索——出问题不知道为什么，改对了也不知道为什么。
原则三：失败要优雅（Fail Gracefully）
Agent 一定会失败——工具调用报错、上下文超限、模型给出乱码 JSON、外部 API 超时。Harness 必须设计失败路径：
- 工具调用失败时，是重试、降级、还是请求人工介入？
- 上下文塞不下时，按什么策略丢弃？
- 模型输出格式不对时，给一次重新格式化的机会还是直接抛错？
成熟的 Harness 在失败路径上花的力气，不亚于成功路径。
原则四：人在环（Human-in-the-loop）是默认值
Agent 越自主，权力越大，Harness 越要主动设计人工干预的入口：
- 关键决策点必须停下来确认
- 危险操作（删文件、推代码、发消息）默认要求确认
- 长任务每隔 N 步主动汇报进度
- 用户随时可以打断、回滚、调整方向
不要造一个"开机就跑到底"的 Agent，要造一个"愿意停下来等你"的 Agent。
Harness 配置实例：Claude Code 的 settings.json
把上面这些原则落到一个具体配置里：
{
"permissions": {
"allow": [
"Read", "Grep", "Glob",
"Bash(git status)", "Bash(git diff*)", "Bash(git log*)",
"Bash(npm test*)", "Bash(pytest*)"
],
"ask": ["Edit", "Write", "Bash(git commit*)"],
"deny": ["Bash(git push --force*)", "Bash(rm -rf*)"]
},
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "ruff format ${file_path} 2>/dev/null || true"
}
],
"Stop": [
{
"command": "echo '\\a'"
}
]
},
"mcpServers": {
"github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] }
}
}
这一份配置定义了：
- 哪些工具不用问就能用（读、搜索、看 git 状态、跑测试）
- 哪些工具要问一下（改文件、提交）
- 哪些工具直接禁掉（强推、递归删除）
- 改完代码自动 format
- Agent 停下时响铃提醒
- 接入 GitHub MCP
这就是一份小型的 Harness 配置文件。每往里加一行，Agent 的行为就更可预期一点。
MCP + Skills + Harness Engineering 的组合
三者结合，构成了高级玩家的完整工具箱：
| 层次 | 技术 | 解决的问题 |
|---|---|---|
| 连接层 | MCP | AI 如何访问外部工具和数据 |
| 能力层 | Skills | AI 的标准化可复用能力 |
| 系统层 | Harness Engineering | 如何把模型、工具、上下文、流程拼成一台可靠的工作机器 |
- 没有 MCP：AI 只能在对话框里干活，要你不停复制粘贴
- 没有 Skills：每次任务都要重新写 Prompt，无法积累
- 没有 Harness Engineering：Agent 行为不稳定、不可观察、不可控制
Skills 和 MCP 是给 Harness 添零件的方式，而 Harness Engineering 是决定这些零件如何组装、如何协同的整体设计哲学。
Harness Engineering 的核心信念：好的 Agent 不是被"提示"出来的，是被"造"出来的。
上下文工程：高级玩家的核心竞争力
什么是上下文工程？就是精心设计 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
- 组件文件：PascalCase（UserList.tsx）
- 工具函数：camelCase（formatDate.ts）
策略二：分层上下文策略
根据任务类型，给不同级别的上下文：
| 任务类型 | 应该给的上下文 |
|---|---|
| 修小 bug | 报错信息 + 相关函数（约 50 行） |
| 新增功能 | 项目规则 + 相关模块结构（约 200 行） |
| 架构决策 | 项目说明 + 现有结构概览（约 500 行） |
| 完整模块 | 项目规则 + 接口规范 + 相关模型（约 1000 行） |
策略三：摘要压缩
不要把整个文件塞给 AI，先让它处理你的摘要：
这个项目的目录结构如下：
[贴目录树]
主要模块说明：
- src/auth：JWT 认证，用户登录注册
- src/todos：Todo 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 持续可靠干活的流水线。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
29
0- 0
已为社区贡献12条内容
所有评论(0)