第 1 章：Vibe Coding 入门与 Claude Code 环境搭建
第 1 章：Vibe Coding 入门与 Claude Code 环境搭建
本章是专栏的开篇，我们先搞清楚「Vibe Coding 到底是什么」，再从零搭建 Claude Code 的开发环境，理解配置文件的三级体系和权限管理机制。学完本章，你将拥有一个配置合理、权限可控的 Claude Code 开发环境。
1.1 什么是 Vibe Coding
1.1.1 定义
Vibe Coding（氛围编程 / 体感编程）是一种新兴的软件开发范式，核心特征是：开发者不再逐行编写代码，而是通过自然语言描述需求、意图和约束，由 AI 编程助手（如 Claude Code、Cursor、GitHub Copilot）生成、修改和重构代码，开发者的角色从「代码撰写者」转变为「需求描述者 + 结果验证者 + 方向把控者」。
这个词最早在 2025 年初由开发者社区自发形成，用来描述那种「跟 AI 聊着天就把代码写了」的开发状态。但随着实践深入，人们发现 Vibe Coding 远不是「随便聊」那么简单——没有纪律的 Vibe Coding 很快会变成「AI 乱写、你乱擦屁股」的灾难。
1.1.2 Vibe Coding 与传统编程的本质区别
| 维度 | 传统编程 | Vibe Coding |
|---|---|---|
| 代码生成方式 | 开发者手动逐行编写 | AI 根据自然语言描述生成 |
| 开发者核心能力 | 语法掌握、算法实现、API 记忆 | 需求拆解、结果验证、方向把控 |
| 修改粒度 | 手动定位并修改具体行 | 描述「要改成什么样」，AI 批量修改 |
| 错误来源 | 开发者自己的笔误和逻辑错误 | AI 的幻觉、遗漏、过度修改 |
| 回退需求 | 偶尔需要（改之前心里有数） | 高频需要（AI 改了什么不一定全知道） |
| 上下文管理 | 开发者自己的大脑 | AI 的上下文窗口（有限且会遗忘） |
关键洞察：Vibe Coding 把「写代码的成本」降到了接近零，但把「验证代码、管理上下文、控制方向」的成本提到了前所未有的高度。本专栏的所有内容，本质上都是在教你如何应对这三个新成本。
1.1.3 Vibe Coding 的四大支柱
一套工程化的 Vibe Coding 工作流建立在四大支柱之上，这也是本专栏十章内容的组织逻辑：
┌─────────────────────┐
│ Vibe Coding │
│ 工程化工作流 │
└─────────┬───────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ 安全回退 │ │ 效率提升 │ │ 质量保障 │
│ (第4章) │ │ (第2/5/10章)│ │ (第6/7/8章)│
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└───────────────────┼───────────────────┘
│
┌─────▼─────┐
│ 成本可控 │
│ (第3/9章) │
└───────────┘
- 安全回退：Git 版本控制、会话级回退、远程备份——任何 AI 的修改都可以撤销，代码不会丢失。
- 效率提升：上下文压缩、自定义 Skill、进阶技巧——减少重复劳动，让 AI 专注于真正需要智能的部分。
- 质量保障：代码审查、Subagent 多代理、Hook 自动化门禁——AI 生成的代码必须经过检查才能进入主分支。
- 成本可控：记忆体系、Token 优化——在保证质量的前提下，最小化 API 调用成本和上下文消耗。
1.1.4 本栏课程以 以 Visual Studio Code 的 Claude Code插件 + deepseek-v4-pro API为背景展开讲解
Claude Code 是 Anthropic 推出的命令行 AI 编程助手，也是本专栏的实践工具。选择它的核心理由：
- 长上下文支持：默认 200K 词元（Token）上下文窗口，Opus 4.6+ 和 Sonnet 4.6 模型可选 1M 词元窗口，足以容纳大型项目的代码库。
- 强大的工具调用能力：内置文件读写、Shell 命令执行、Git 操作等工具，能真正「动手」改代码而不只是「动嘴」给建议。
- 完善的扩展生态：支持自定义 Skill、Hook 钩子、MCP 服务器、Subagent 子代理，可以构建高度定制化的工作流。
- CLI + IDE 双模式：既可以在终端中使用，也有 VS Code 和 JetBrains 插件，适应不同开发习惯。
说明：本专栏的操作基于 Claude Code CLI（截至 2026 年 8 月版本）。如果你使用 Cursor、GitHub Copilot 等其他工具，核心方法论（上下文管理、回退策略、质量门禁）完全通用，只是具体命令和配置方式有所不同。
1.2 Claude Code 安装与初始化
1.2.1 环境要求
- 操作系统：macOS 12+、Ubuntu 20.04+、Windows 10+（推荐 WSL2）
- Node.js：18+（Claude Code CLI 基于 Node.js 运行）
- 网络：能够访问 Anthropic API（或配置了第三方 API 代理）
- API 密钥：Anthropic Console API Key（或 Claude.ai 订阅账户）
1.2.2 安装 CLI
# 方式一：通过 npm 全局安装（推荐）
npm install -g @anthropic-ai/claude-code
# 验证安装
claude --version
安装完成后，在终端输入 claude 即可启动交互式会话。首次启动会引导你登录账户或配置 API 密钥。
1.2.3 安装 VS Code 扩展
如果你习惯在 IDE 中工作，可以安装 Claude Code 的 VS Code 扩展：
- 打开 VS Code 扩展面板（
Ctrl+Shift+X/Cmd+Shift+X） - 搜索「Claude Code」
- 安装官方扩展
- 安装后，编辑器侧边栏会出现 Claude Code 图标，点击即可打开对话面板
VS Code 扩展提供了以下增强功能：
- 选中代码后
Cmd+Shift+L直接发送给 Claude - 内联编辑建议（在代码文件中直接显示 AI 的修改建议）
- 文件 diff 预览（可视化对比 AI 修改前后的代码）
1.2.4 项目初始化：/init 命令
在一个新项目中，首次启动 Claude Code 后，建议运行 /init 命令：
/init
这个命令会交互式地引导你创建项目的 CLAUDE.md 文件（项目级记忆，第 3 章详细讲解），内容包括：
- 项目概述和技术栈
- 构建和运行命令
- 项目目录结构
- 编码规范和重要约定
/init 会自动扫描项目文件，提取技术栈信息和常用命令，然后让你确认和补充。这比手动从零写 CLAUDE.md 高效得多。
1.3 配置文件三级体系
Claude Code 的配置采用「三级叠加」机制，理解这个体系是定制化工作流的基础。
1.3.1 三级配置的优先级
| 级别 | 文件路径 | 作用域 | 优先级 | 说明 |
|---|---|---|---|---|
| 项目本地级 | <project>/.claude/settings.local.json |
当前项目，个人专用 | 最高 | 个人偏好，不纳入 Git，不共享给团队 |
| 项目共享级 | <project>/.claude/settings.json |
当前项目，团队共享 | 中 | 团队约定的配置，纳入 Git，所有团队成员生效 |
| 用户全局级 | ~/.claude/settings.json |
所有项目，个人全局 | 最低 | 跨项目通用的个人配置 |
叠加规则：Claude Code 启动时会按「低优先级 → 高优先级」的顺序依次加载配置，高优先级的配置会覆盖低优先级的同名键。最终生效的配置是三级合并后的结果。
最终配置 = 用户全局配置 ⊕ 项目共享配置 ⊕ 项目本地配置
(底层) (中层覆盖) (顶层覆盖)
1.3.2 每级配置应该放什么
用户全局级（~/.claude/settings.json）：放所有项目通用的个人偏好。
{
"theme": "dark",
"effortLevel": "medium",
"permissions": {
"allow": ["git status", "git diff", "git log"]
}
}
项目共享级（<project>/.claude/settings.json）：放团队约定的配置，纳入 Git 版本控制。
{
"permissions": {
"allow": ["npm test", "npm run lint", "npm run build"],
"deny": ["git push --force origin main"]
},
"hooks": {
"PreToolUse": {
"matcher": "Bash(git commit*)",
"command": "./scripts/pre-commit-check.sh"
}
}
}
项目本地级（<project>/.claude/settings.local.json）：放个人在当前项目的特殊偏好，不纳入 Git（应加入 .gitignore）。
{
"effortLevel": "high",
"env": {
"ANTHROPIC_BASE_URL": "https://api.my-proxy.com/anthropic"
}
}
1.3.3 settings.json 完整配置项
一个完整的 settings.json 可以包含以下配置块：
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com",
"ANTHROPIC_AUTH_TOKEN": "sk-ant-xxx",
"ANTHROPIC_MODEL": "claude-sonnet-4-6",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
},
"effortLevel": "medium",
"theme": "dark",
"permissions": {
"allow": ["npm test", "git status"],
"allow-dry-run": ["git push"],
"deny": ["rm -rf /", "git push --force origin main"]
},
"hooks": {
"PreToolUse": {},
"PostToolUse": {},
"Stop": {}
},
"skills": {
"deploy-staging": "Deploy to staging: npm run build && npm run deploy:staging"
},
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-server-github"]
}
}
}
各配置块的含义：
env：传递给 Claude Code 子进程的环境变量，常用于配置 API 代理和模型选择effortLevel：AI 的分析深度（low / medium / high / xhigh），第 9 章详细讲解permissions：工具调用权限规则，1.5 节详细讲解hooks：事件钩子配置，第 8 章详细讲解skills：简单技能的指令模板，第 5 章详细讲解mcpServers：MCP（Model Context Protocol）服务器配置，第 10 章详细讲解
1.4 目录结构总览
理解 Claude Code 的文件存储结构，有助于你在需要时手动查找、备份或清理数据。
1.4.1 用户全局目录（~/.claude/）
~/.claude/
├── settings.json # 用户全局配置（跨所有项目生效）
├── MEMORY.md # 用户级自动记忆（Claude 自动学习的偏好）
├── memory/ # 分文件的记忆存储（独立记忆条目）
├── history.jsonl # 命令历史记录
├── keybindings.json # 自定义快捷键配置
├── plugins/ # 自定义技能插件目录
│ └── my-skill/
│ └── skill.md
├── backups/ # 文件备份目录（Claude 修改文件前的备份）
├── file-history/ # 文件修改历史记录
├── sessions/ # 会话存档（历史对话记录）
├── projects/ # 项目级数据（按项目存储）
│ └── {project-hash}/
│ ├── memory/ # 项目级自动记忆
│ └── settings.json # 项目共享配置
├── agent-memory/ # 代理级记忆（按 Subagent 类型存储）
└── plans/ # Plan Mode 保存的计划文件
1.4.2 项目级目录（<project>/.claude/）
<project>/
├── CLAUDE.md # 项目级记忆（每次会话启动时全量加载）
└── .claude/
├── settings.json # 项目共享配置（纳入 Git，团队共享）
├── settings.local.json # 项目本地配置（不纳入 Git，个人专用）
├── MEMORY.md # 项目级自动记忆（Claude 自动学习）
├── memory/ # 项目级分文件记忆
└── markers/ # 自定义标记文件（如质量门禁的 PASS/FAIL 标记）
1.4.3 关键目录的用途说明
| 目录/文件 | 用途 | 是否纳入 Git | 手动编辑建议 |
|---|---|---|---|
CLAUDE.md |
项目宪法，AI 每次会话必读 | ✅ 推荐 | 经常编辑，保持最新 |
settings.json（项目共享） |
团队共享配置 | ✅ 推荐 | 团队协商后编辑 |
settings.local.json |
个人项目配置 | ❌ 应加入 .gitignore | 个人自由编辑 |
~/.claude/settings.json |
全局个人配置 | ❌ 个人文件 | 个人自由编辑 |
MEMORY.md |
Claude 自动学习的记忆 | ❌ 通常不纳入 | 不建议手动编辑，让 Claude 管理 |
plugins/ |
自定义技能插件 | 视情况 | 开发技能时编辑 |
sessions/ |
历史对话存档 | ❌ | 不需要手动编辑 |
backups/ |
文件修改备份 | ❌ | 可定期清理释放空间 |
注意：
MEMORY.md和CLAUDE.md是两个完全不同的东西。CLAUDE.md是你手动编写的「指令和规则」，而MEMORY.md是 Claude 在工作过程中自动学习和记录的「经验和发现」。第 3 章会详细拆解两者的区别和使用场景。
1.5 权限管理四级别
Claude Code 在执行工具调用（如运行 Shell 命令、修改文件）时，会根据权限配置决定是否需要用户确认。理解权限机制是安全使用 AI 编程的关键。
1.5.1 四级权限模型
| 权限级别 | 配置键 | 行为 | 适用场景 |
|---|---|---|---|
allow |
permissions.allow |
无需确认，直接执行 | 安全的只读命令、项目固定命令 |
allow-dry-run |
permissions.allow-dry-run |
先展示执行计划，用户确认后执行 | 有副作用但可预期的命令 |
ask |
默认行为（不配置即 ask） | 每次执行前询问用户 | 大多数命令的默认行为 |
deny |
permissions.deny |
完全禁止执行，不询问 | 危险命令，绝对不允许 AI 执行 |
1.5.2 权限配置示例
{
"permissions": {
"allow": [
"npm test",
"npm run lint",
"git status",
"git diff",
"git log"
],
"allow-dry-run": [
"git push",
"npm run deploy:*",
"docker compose up"
],
"deny": [
"rm -rf /",
"rm -rf ~",
"git push --force origin main",
"git reset --hard origin/main"
]
}
}
规则说明：
allow中的命令匹配支持通配符（如npm run deploy:*匹配所有 deploy 开头的脚本）deny的优先级高于allow——如果一个命令同时匹配 allow 和 deny，deny 生效- 未在任何列表中出现的命令，默认行为是
ask（每次询问）
1.5.3 权限匹配的格式
权限规则使用 工具名(命令模式) 的格式来精确匹配：
Bash(npm test) # 匹配 Bash 工具执行 "npm test"
Bash(git commit*) # 匹配 Bash 工具执行以 "git commit" 开头的命令
Edit(*) # 匹配所有文件编辑操作
Read(*) # 匹配所有文件读取操作
这种格式可以精确控制「哪个工具的哪种操作」被允许或拒绝。
1.5.4 /fewer-permission-prompts：自动优化权限配置
如果你觉得每次都要手动确认很烦，可以使用 /fewer-permission-prompts 技能。Claude 会分析你的历史使用记录，自动生成一份合理的 allow 列表建议，你确认后写入配置文件。
/fewer-permission-prompts
执行后，Claude 会输出类似这样的建议：
根据你最近的使用记录，以下命令频繁执行且从未出现问题，建议加入 allow 列表：
- npm test（执行了 23 次，全部安全）
- git status（执行了 45 次，只读操作）
- npm run lint（执行了 12 次，安全）
是否将以上命令添加到 permissions.allow？
确认后，这些命令就不再需要每次手动确认了。
1.5.5 权限管理的安全原则
- 默认保守：不要把太多命令加入
allow，保持默认ask是最安全的。 - 危险命令必须 deny：
rm -rf、git push --force、格式化磁盘等命令必须明确加入deny。 - 有副作用的命令用 allow-dry-run：
git push、部署命令等有外部影响的操作，先看计划再确认。 - 定期审查：每隔一段时间 review 一次
allow列表，移除不再需要的权限。 - 项目级和全局级分开：全局
allow只放所有项目通用的安全命令，项目特定的命令放在项目级配置中。
1.6 本章小结
本章我们完成了 Vibe Coding 专栏的环境搭建，核心知识点：
- Vibe Coding 的本质：开发者从「代码撰写者」转变为「需求描述者 + 结果验证者 + 方向把控者」，核心挑战从「写代码」转向「验证、上下文管理、方向控制」。
- 四大支柱：安全回退、效率提升、质量保障、成本可控——这是本专栏十章内容的组织逻辑。
- 安装与初始化：CLI 通过 npm 安装，VS Code 扩展提供 IDE 集成，
/init命令交互式创建项目记忆。 - 配置文件三级体系：用户全局（
~/.claude/settings.json）→ 项目共享（.claude/settings.json）→ 项目本地（.claude/settings.local.json），高优先级覆盖低优先级。 - 目录结构：
~/.claude/存储全局数据，<project>/.claude/存储项目数据，关键区分CLAUDE.md（手动指令）和MEMORY.md（自动记忆）。 - 权限四级别：
allow（直接执行）/allow-dry-run（先看计划）/ask（每次询问，默认）/deny（完全禁止），/fewer-permission-prompts可自动优化权限配置。
环境搭建完成后，下一章我们将进入第一个核心主题：上下文管理——学习如何让 AI 在长对话中保持专注、不遗忘、不幻觉。
第 1 章课后思考参考答案
基础题：Claude Code 的三级配置文件分别是什么？优先级顺序是怎样的？如果你想让团队所有成员都遵循同一个代码审查流程，应该把配置写在哪一级？
三级配置文件：
| 级别 | 文件路径 | 作用域 |
|---|---|---|
| 项目本地级 | <project>/.claude/settings.local.json |
当前项目，个人专用 |
| 项目共享级 | <project>/.claude/settings.json |
当前项目，团队共享 |
| 用户全局级 | ~/.claude/settings.json |
所有项目，个人全局 |
优先级顺序（从高到低）：
项目本地级 > 项目共享级 > 用户全局级
高优先级的配置会覆盖低优先级的同名键。最终生效的配置是三级合并后的结果：
最终配置 = 用户全局配置 ⊕ 项目共享配置 ⊕ 项目本地配置
团队共享代码审查流程应该写在哪一级：
写在项目共享级（<project>/.claude/settings.json）。
原因：
- 这一级配置纳入 Git 版本控制，团队所有成员 clone 项目后自动生效
- 作用域是「当前项目，团队共享」，正好匹配「团队所有成员遵循同一流程」的需求
- 不应该写在用户全局级（只对个人生效，团队其他人看不到）
- 不应该写在项目本地级（不纳入 Git，个人专用，团队其他人看不到）
2. allow、allow-dry-run、ask、deny 四种权限的行为分别是什么？git push 命令你会配置为哪种权限？为什么？
四种权限的行为：
| 权限级别 | 行为 | 适用场景 |
|---|---|---|
allow |
无需确认，直接执行 | 安全的只读命令、项目固定命令 |
allow-dry-run |
先展示执行计划，用户确认后执行 | 有副作用但可预期的命令 |
ask |
每次执行前询问用户（默认行为） | 大多数命令的默认行为 |
deny |
完全禁止执行，不询问 | 危险命令，绝对不允许 AI 执行 |
git push 应该配置为 allow-dry-run。
原因：
git push有副作用——它会修改远程仓库，一旦 push 了错误的代码，撤销成本较高（需要 force push 或 revert）allow-dry-run会先展示执行计划（push 哪些分支、包含哪些 commit），用户确认后才执行，给了一个「最后检查」的机会- 不配置为
allow：因为 push 是有外部影响的操作，不能完全不确认 - 不配置为
ask：因为ask只是笼统地问「是否执行」，不展示具体计划；而allow-dry-run会先展示 push 的具体内容（哪些 commit、推到哪个分支），信息更充分
补充：deny 中应该明确加入 git push --force origin main——强制推送主分支是极其危险的操作，必须完全禁止。
3.CLAUDE.md 和 MEMORY.md 有什么本质区别？如果你的项目有一条硬性规定「所有 API 请求必须经过统一的 request 封装」，这条规定应该写在哪里？为什么？
本质区别：
| 维度 | CLAUDE.md |
MEMORY.md |
|---|---|---|
| 谁写的 | 你（用户手动编写） | Claude（AI 自动学习和记录） |
| 内容性质 | 指令和规则（Instructions & Rules） | 经验和发现（Learnings & Patterns） |
| 加载方式 | 每次会话启动时全量加载 | 启动时加载前 200 行（约 25KB），其余按需检索 |
| 是否纳入 Git | ✅ 推荐纳入，团队共享 | ❌ 通常不纳入，个人专属 |
| 手动编辑建议 | 经常编辑，保持最新 | 不建议手动编辑，让 Claude 管理 |
| 典型内容 | 技术栈、编码规范、构建命令、硬性约定 | 反复出现的构建命令、调试经验、踩过的坑、AI 发现的偏好 |
一句话总结：CLAUDE.md 是你给 AI 下的「规矩」，MEMORY.md 是 AI 在工作中自己总结的「经验」。
「所有 API 请求必须经过统一的 request 封装」这条规定应该写在 CLAUDE.md 中。
原因：
- 这是一条硬性规则，不是经验发现——它是项目的编码规范，需要 AI 每次都遵守，属于「指令和规则」的范畴
- 需要全量加载——
CLAUDE.md每次会话全量加载，AI 从第一轮对话就知道这条规则；而MEMORY.md只加载前 200 行，这条规则可能不在前 200 行中，AI 可能看不到 - 需要团队共享——这条规则是项目级的约定，所有团队成员都应该遵守，
CLAUDE.md纳入 Git 后团队共享；MEMORY.md是个人专属，不纳入 Git - 需要手动维护——这条规则是人为制定的，需要人来编写和更新；
MEMORY.md是 AI 自动学习的，不适合放人为制定的硬性规则
4. 如果你在一个团队项目中，既想共享一部分 Claude Code 配置（如统一的代码审查 Hook），又想保留个人偏好（如深色主题、自定义快捷键），应该如何分配三级配置？请给出具体的文件分配方案。
具体文件分配方案：
| 配置内容 | 放置级别 | 文件路径 | 原因 |
|---|---|---|---|
| 统一的代码审查 Hook | 项目共享级 | <project>/.claude/settings.json |
团队共享，纳入 Git，所有人 clone 后自动生效 |
| 团队统一的编码规范、构建命令 | 项目共享级 | <project>/CLAUDE.md |
团队共享的项目规范，纳入 Git |
| 团队统一的权限规则（如禁止 force push） | 项目共享级 | <project>/.claude/settings.json |
安全规则需要对所有团队成员生效 |
| 项目级自定义 Skill（如项目特有的部署流程） | 项目共享级 | <project>/.claude/plugins/ |
项目特有的工作流，团队共享 |
| 深色主题 | 用户全局级 或 项目本地级 | ~/.claude/settings.json 或 .claude/settings.local.json |
个人偏好，不需要共享，不纳入 Git |
| 自定义快捷键 | 用户全局级 | ~/.claude/keybindings.json |
个人操作习惯，跨所有项目通用 |
| 个人的 Effort Level 偏好 | 用户全局级 或 项目本地级 | ~/.claude/settings.json 或 .claude/settings.local.json |
个人对分析深度的偏好，不影响团队 |
| 个人的 API 代理配置 | 项目本地级 | <project>/.claude/settings.local.json |
个人网络环境不同，代理地址不同，且包含敏感信息，不能纳入 Git |
| 个人的自动记忆 | 用户全局级 | ~/.claude/MEMORY.md |
AI 自动学习的个人偏好，个人专属 |
核心原则：
- 团队共享的、需要统一的 → 项目共享级（纳入 Git）
- 个人偏好的、不需要共享的 → 用户全局级（跨项目）或项目本地级（仅当前项目）
- 包含敏感信息的（API Key、代理地址）→ 项目本地级（加入
.gitignore，绝对不能纳入 Git）
.gitignore 中必须包含：
.claude/settings.local.json
.claude/MEMORY.md
.claude/memory/
5. Vibe Coding 把「写代码的成本」降到了接近零，但把「验证代码、管理上下文、控制方向」的成本提高了。结合你自己的编程经验，你认为这三个新成本中，哪一个最难应对？为什么？
参考答案（以「验证代码」最难为例，也可以选择其他两个，言之有理即可）：
我认为验证代码是三个新成本中最难应对的。
原因分析：
1. 验证代码需要专业判断力，无法完全自动化
- 管理上下文有明确的工具（
/compact）和量化指标（Token 用量、对话轮数），可以按规则执行 - 控制方向有明确的方法论（需求文档、Plan Mode、竞品分析），可以通过流程规范来保障
- 但验证代码需要判断「这段代码逻辑对不对」「这个边界场景有没有考虑到」「这个性能问题会不会在生产环境触发」——这些需要深厚的技术功底和业务理解，比如路由守卫，权限隔离等场景，AI无法理解，他不知道要进行场景区分，所以AI 可以辅助审查，但最终判断还是要靠人
2. AI 生成的代码量太大，人工逐行验证不现实
- AI 一次可以生成几十个文件、几百行代码，人工逐行审查需要大量时间，而且人在疲劳时容易遗漏
- 自动化审查（
/code-review）可以发现语法错误、安全漏洞、规范问题，但无法判断业务逻辑是否正确——AI 不了解你的业务背景，可能把「符合业务规则但看起来奇怪」的代码标记为问题，也可能把「看起来正常但违反业务规则」的代码漏掉
3. 验证需要「运行起来看」，但运行环境复杂
- 很多问题只有在实际运行时才会暴露（环境变量配置错误、跨域问题、CSS 优先级冲突、并发竞态条件）
/verify可以辅助运行验证，但复杂系统的端到端验证需要完整的测试环境、测试数据、测试用例，搭建和维护成本很高- 个人项目往往没有完善的测试覆盖，验证主要靠手动点一遍，覆盖度有限
4. 验证是「最后一道防线」，一旦漏掉问题就进入生产
- 上下文管理不好，后果是 AI 幻觉、改不动代码，可以通过压缩和开新对话补救
- 方向控制不好，后果是做了不需要的功能，可以通过需求管理和迭代来修正
- 但验证漏掉了问题，代码可能直接进入主分支甚至生产环境，后果可能是线上故障、数据丢失、安全漏洞——修复成本远高于前两者
应对策略：
- 建立多层验证体系：自动化审查（
/code-review）→ 自动化测试（单元测试 + 集成测试）→ 手动验证（/verify）→ 人工复核核心逻辑 - 小步提交，每次只改少量代码，降低每次验证的复杂度
- 为核心业务逻辑编写完善的测试用例，用自动化测试覆盖大部分验证场景
- 培养「AI 的输出必须经过验证」的意识，不要因为 AI 说「没问题」就相信
注：这是开放题，选择「管理上下文」或「控制方向」也可以。选择「管理上下文」的核心理由可以是：上下文窗口有限且 AI 的遗忘是渐进的、不易察觉的，你很难精确知道 AI 「忘了什么」；选择「控制方向」的核心理由可以是：需求变更和蔓延是软件开发的经典难题，AI 时代需求变更成本更低导致蔓延更快，且方向错误会导致所有后续工作白费。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
9
0- 0
已为社区贡献3条内容
所有评论(0)