AI 编程工具实战

概述

AI 编程工具的核心差异不在模型本身，而在于：如何给上下文、如何拆任务、如何审 diff、如何控制风险。

别把 AI 编程想成"需求丢进去，代码自动写好"。更常见的场景是：AI 写到一半方向歪了你得接回来；一次改太多文件你得拆小；测试没过你得顺着错误往回追。

CLI vs IDE：工具路线选择

维度	CLI（Claude Code / Codex CLI）	IDE（Cursor / Trae / Copilot）
适合任务	跨文件重构、批量修改、长任务自动化	局部补全、边看边改、随时调整
上下文管理	CLAUDE.md / 规则文件 / 显式文件引用	自动索引 + .cursorrules
输出粒度	完整文件 / diff / 多文件一次性	行级补全 / 局部修改
审查方式	git diff / 回滚 commit	内联 diff / accept/reject
并发能力	多 Agent 并行（Worktree）	单会话为主
最佳场景	明确的工程任务 + 已有测试	探索性编码 + 快速迭代

选型建议：不要纠结"哪个更强"，根据当前任务选择合适的工具。两者可以互补。

核心工具详解

Claude Code

定位：终端原生 AI Agent，适合复杂工程任务
核心能力：读/写文件、执行命令、搜索代码、多 Agent 并行
上下文管理：
- CLAUDE.md：项目级规则（架构约束、编码规范、常见坑）
- .claude/rules/：细粒度规则文件
- Auto Memory：自动记住用户偏好
- Skills：可复用的工作流模板

最佳实践：

markdown

# CLAUDE.md 示例结构
## 项目概述
简要描述项目用途和技术栈

## 架构约束
- 使用 XX 模式处理 YY
- 不要修改 ZZ 目录

## 编码规范  
- 函数命名：snake_case
- 错误处理：统一用 Result 类型

## 常见陷阱
- 数据库连接不要在 handler 里创建
- XX 配置必须先读环境变量

Cursor

定位：VS Code 改造的 AI IDE
核心能力：代码补全、Chat、Composer（多文件修改）
关键配置：
- .cursorrules：定义 AI 生成代码的规则和风格
- .cursorignore：保护不允许 AI 修改的核心文件
- @ 引用：精确指定上下文（@file / @folder / @web）

高效技巧：

大型项目先让 Cursor 分析代码库，生成架构文档作为基础上下文
用 Composer 做多文件修改，Chat 做单点问答
善用 .cursorrules 固化团队规范

OpenAI Codex

定位：云端 AI 智能体 + CLI 工具
特点：沙箱环境执行、多任务并行、支持 PR 级别操作
Spec Coding：通过规范文件（spec）驱动代码生成
- 定义清晰的输入输出规范
- 指定边界条件和异常处理
- 提供验收标准

Trae / Windsurf

Trae：字节跳动出品，集成 MiniMax/DeepSeek 等多模型
Windsurf：Cascade 模式支持复杂多步任务

Spec Coding vs Vibe Coding

对比	Vibe Coding	Spec Coding
风格	感觉驱动，边写边调	规范驱动，先设计后实现
适合	原型探索、个人项目	生产代码、团队协作
质量保障	事后补测试	测试先行 / 规范内置
风险	改着改着方向偏了	前期投入大，灵活性低
最佳实践	+ Git 频繁提交 + 范围管理	+ 模板化 + 自动验收

从 Vibe Coding 到工程化 AI Coding

很多 AI Coding 教程会从「一句话生成一个应用」讲起，这适合体验工具能力，但面试和生产更看重可控的开发闭环。可以把 AI 编程分成四个层级：

层级	典型行为	风险	升级动作
体验层	让 AI 生成 demo、页面、脚本	需求不清，改动发散	用 Git 固定检查点，先限定文件范围
任务层	让 AI 完成一个明确 issue	漏边界、漏测试	写清输入、输出、异常、验收标准
工程层	让 AI 读代码、拆计划、改多文件、跑测试	上下文污染、隐性破坏	用 spec、测试、diff review、分步提交控制
团队层	多 Agent 并行、代码审查、文档同步、CI 发布	互相覆盖、责任不清	拆分写入范围，保留审计日志和回滚路径

面试时不要把 AI Coding 讲成「我会用 Cursor」。更好的说法是：

我把 AI 当成结对工程师使用：先让它读项目约束和相关文件，再让它给实现计划；每一轮只改一个明确范围，改完必须跑测试和看 diff。复杂任务会拆成 spec、实现、review、修复、文档同步几个阶段，最后用 commit 保留可回滚边界。

Loop Engineering：让 AI 在小闭环里工作

AI 编程最稳定的模式不是一次生成，而是循环：

text

目标说明
  -> 选上下文：相关文件、错误日志、接口契约
  -> 小步修改：一次只解决一个可验证问题
  -> 自动验证：lint / test / build / screenshot
  -> 人类审查：diff、边界、安全、性能
  -> 反馈修正：把失败日志喂回下一轮

这个闭环比「给一个大 prompt 让 AI 全做完」更可靠。原因很简单：每轮都有证据，错误不会滚雪球。

上下文包模板

让 AI 修改代码前，最好给它一个小而完整的上下文包：

markdown

目标：要实现什么，不要实现什么
相关文件：入口、调用方、测试、配置
约束：接口兼容、性能、安全、UI 风格、不能改哪些目录
验收：运行哪些命令，看到什么结果算通过
风险：最容易破坏的边界条件

这也是 AI Coding 面试高频点：上下文不是越多越好，而是越相关越好。无关文件会稀释约束，历史对话太长会把过期决策带进来。

AI Coding 项目怎么写进简历

如果你把 AI 编程经验写进简历，重点不是「用了某某工具」，而是可复用的工程方法：

场景：在遗留项目中补测试、迁移框架、生成文档、修复 bug、重构模块。
流程：spec 拆解、上下文选择、AI 修改、测试验证、人工 review。
指标：交付周期、测试覆盖、缺陷率、review 返工次数、文档补全数量。
边界：敏感逻辑人工复核，安全相关代码不盲信 AI，复杂性能问题仍用 profiling。

可用一句话概括：

我不是让 AI 替我写代码，而是用 AI 扩大“读代码、生成候选方案、补测试、整理文档”的吞吐，最终质量仍由测试、review 和架构判断兜底。

多模型协同策略

不是所有任务都用最贵的模型：

任务	推荐模型	理由
架构设计 / 系统思考	Claude Opus / GPT-4o	需要深度推理
代码生成	Claude Sonnet / DeepSeek V4	性价比高
代码审查	Claude Opus	需要全局视角
简单补全 / 格式化	Fast 模型 / Haiku	速度优先
排错调试	按复杂度选择	简单用快模型，复杂用强模型

注意：分工不清楚时，多模型会把错误一起放大。

AI 生成代码的质量保障

审查清单

功能正确性：是否完成了需求？边界条件对吗？
安全性：有没有注入风险？敏感信息泄露？
一致性：和项目现有代码风格一致吗？
可测试性：能写测试吗？mock 合理吗？
变更范围：改动是否超出必要范围？

提交粒度控制

一次 AI 生成 → 一次 review → 一次 commit
大变更拆成多轮：先改接口 → 再改实现 → 最后改调用方
每个 commit 都应该能独立通过测试

回滚策略

bash

# AI 写坏了？
git stash                    # 暂存当前修改
git diff --stat HEAD~3       # 看最近改了什么
git checkout -- <file>       # 恢复单个文件
git reset --soft HEAD~1      # 撤销上次 commit 但保留修改

上下文管理原则

该给的上下文

项目规则（CLAUDE.md / .cursorrules）
相关文件（被修改的 + 依赖的）
报错日志（完整的 error stack）
验收标准（测试用例 / 预期行为）

不该给的上下文

无关文件（稀释关键约束）
过长的历史对话（增加噪音）
重复的规则（永久规则写进配置文件，不要每次对话都说）

分层管理

永久规则  →  CLAUDE.md / .cursorrules（全项目）
模块规则  →  .claude/rules/*.md（按目录/文件）
临时上下文 → 对话中 @ 引用或粘贴

高频面试题

1. AI 编程工具适合做什么？不适合做什么？

适合：代码生成、重构、测试编写、文档整理、代码审查辅助、排错

不适合：需求定义、架构决策（只能辅助）、安全审计（会遗漏）、性能调优（需要 profiling 数据）

2. 如何控制 AI 的变更范围？

拆小任务，每次只改一个明确的点
用 .cursorignore / 规则文件限制修改范围
频繁 commit，便于回滚
先写测试，再让 AI 实现

3. CLI 和 IDE 选择的核心依据？

CLI 强在上下文管理可控、多 Agent 并行、长任务自动化
IDE 强在即时反馈、局部修改、开发体验
跨文件重构/批量修改用 CLI，局部补全/探索用 IDE

4. 面试时如何描述 AI 编程经验？

不要只说"提升了效率"。要讲清楚：

在哪些环节用 AI（写代码/审代码/排错/写测试）
哪些环节 AI 反而增加了审查成本
怎么兜住风险（测试/回滚/变更范围控制）
具体案例：用了什么工具、做了什么任务、效果如何

5. AI 编程会削弱程序员能力吗？

关键是保留判断力：

能看出 AI 写的代码哪里不对
能判断方案是否合理（不盲信）
保持基本功（数据结构/系统设计/调试能力）
AI 是放大器，放大强者的效率，也放大弱者的盲区

6. CLAUDE.md 和 .cursorrules 应该写什么？

写不能从代码中自动推断的约束：

架构决策的理由（为什么用 X 不用 Y）
易犯的错误和陷阱
团队特定的规范和偏好
依赖服务的特殊行为

不要写：代码格式规则（用 linter）、显而易见的事实

AI 编程工具实战 ​

概述 ​

CLI vs IDE：工具路线选择 ​

核心工具详解 ​

Claude Code ​

Cursor ​

OpenAI Codex ​

Trae / Windsurf ​

Spec Coding vs Vibe Coding ​

从 Vibe Coding 到工程化 AI Coding ​

Loop Engineering：让 AI 在小闭环里工作 ​

上下文包模板 ​

AI Coding 项目怎么写进简历 ​

多模型协同策略 ​

AI 生成代码的质量保障 ​

审查清单 ​

提交粒度控制 ​

回滚策略 ​

上下文管理原则 ​

该给的上下文 ​

不该给的上下文 ​

分层管理 ​

高频面试题 ​

1. AI 编程工具适合做什么？不适合做什么？ ​

2. 如何控制 AI 的变更范围？ ​

3. CLI 和 IDE 选择的核心依据？ ​

4. 面试时如何描述 AI 编程经验？ ​

5. AI 编程会削弱程序员能力吗？ ​

6. CLAUDE.md 和 .cursorrules 应该写什么？ ​