AI 辅助开发

问题

2026 年如何把 AI 编程工具用到极致？包括工具选型、模型路由、把团队经验打包成 Skills/Subagents/Slash Commands/Hooks 的实战做法、Plan Mode / Sandbox / 并行 Agent 等现代工作流、日常任务手册（新功能/排查/重构/升级/调研）、代码审查自动化、成本和效能度量、安全边界和反模式。

面试速答版

2026 年如何把 AI 编程工具用到极致？ AI 辅助开发已经从「补全 + 聊天」升级到「Agent 运行时 + 团队资产 + 自动化工作流」，能不能用好关键看四件事：

工具装备齐全：用上 Plan Mode、Sandbox、Hooks、并行 session，而不只是 Tab 补全。
团队资产沉淀：把经验固化为 Rules / Skills / Subagents / Slash Commands / Hooks / MCP Server，全部进 Git。
工作流自动化：「AI 写 → Hook 自动 lint/tsc → Subagent 并行写测试 → AI 审查 → 人工终审」。
安全边界守住：模型走统一网关、Sandbox 隔离副作用、敏感操作必须 Human-in-the-loop。

答案

一、2026 年 AI 辅助开发的新范式

2023-2024 年的 AI 辅助 = 补全代码 + 聊天问答。2026 年 AI 辅助 = Agent 运行时 + 可复用资产 + 自动化工作流。能不能把 AI 用好，关键不再是「会不会写 Prompt」，而是：

工具是否装备齐全：Agent loop、Plan Mode、Sandbox、Hooks、并行 session
团队资产是否沉淀：Rules、Skills、Subagents、Slash Commands、Hooks、MCP Servers 全都纳入 Git 共享
工作流是否自动化：从「AI 生成 → 人工 lint → 人工 test → 人工 review」升级为「AI 生成 → Hook 自动 lint → Subagent 并行生成测试 → AI 审查 → 人工终审」

从左到右是能力跃迁——一次投入，团队长期受益。本文按这条路径依次展开实战操作手册。

本文的定位与配套阅读

本文偏实战落地：给配置、给脚本、给工作流模板。对应的理论深挖请参考：

Context Engineering — 上下文如何组织
Harness Engineering — Agent 运行时如何构建
AI 研发基建 — 团队层面如何建设
AI 全流程研发实战 — 研发各阶段落地

二、工具选型（2026 年主流 IDE / CLI）

2.1 工具地图

2.2 主流工具能力对比

工具	类型	模型	Skills	Subagents	Slash Cmds	Hooks	MCP	Sandbox	Plan Mode	后台运行
Claude Code	CLI + VSCode ext	Claude 系列	✅	✅	✅	✅	✅	✅ worktree	✅	✅ headless
Cursor	独立编辑器	多模型	AGENTS.md	✅	✅ Cmd Palette	有限	✅	有限	✅	✅ Background
Windsurf	独立编辑器	多模型	有限	Cascade	有限	有限	✅	有限	有限	有限
GitHub Copilot	IDE 插件	Claude/GPT	有限	有限	✅	有限	✅	无	有限	无
Augment	IDE 插件	多模型	有限	有限	无	无	有限	无	无	无
Aider	CLI	多模型	无	无	✅	有限	有限	有限	✅	无

选型建议（2026 年）

个人日常编码：Cursor — IDE 体验最好，多模型切换自由
团队统一 + 重度 Agent：Claude Code — 四件套最完整，headless 可进 CI/CD
企业合规场景：Copilot Business / Enterprise — SSO/SOC2/IP 赔偿保护最成熟
需要超长上下文：Cursor + Gemini 3 Pro（2M 上下文）或 Claude Code + Opus 4.7 1M
AWS 深度用户：Amazon Q Developer
预算极低 / 开源偏好：Aider + 自部署 Qwen3 Coder

绝大多数团队的最佳组合：Cursor（IDE 编辑）+ Claude Code（CLI 长任务 / CI/CD）。两者共用同一套 .claude/ 配置（Rules、Skills、Subagents、Slash Commands、Hooks），能力最大化。

2.3 场景匹配矩阵

场景	首选工具	为什么
写一行代码补全	Cursor Tab / Copilot	最轻量最快
修改当前选中的函数	Cursor Inline Edit `Cmd+K`	就地编辑
讨论方案 / 看代码	Cursor Chat `Cmd+L` / Copilot Chat	对话式
跨文件新功能	Cursor Composer `Cmd+I`	可视化多文件编辑
大型重构 / 跨模块改动	Claude Code CLI	理解整个仓库最强
几小时 Agent 长任务	Claude Code CLI + Opus 4.7	最稳定，支持 Compaction
CI/CD 集成（PR 审查/代码生成）	Claude Code headless	`claude -p` JSON 输出
整库审查	Cursor + Gemini 3 Pro	2M 上下文
UI 原型	v0.dev / Lovable	可视化交互
生产环境代码审查	claude-code-action on PR	官方集成

三、模型选型与路由（2026 年）

3.1 2026 模型地图

模型	编码	推理	上下文	速度	成本	最适合
Claude Opus 4.7	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	200K / 1M	中	高	架构设计、深度重构、小时级 Agent 任务
Claude Sonnet 4.6	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	200K / 1M	快	中	日常编码首选、SWE-bench 领先
Claude Haiku 4.5	⭐⭐⭐⭐	⭐⭐⭐	200K	很快	低	Tab 补全、Subagent 驱动模型
GPT-5	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	400K	中	高	通用顶级、ChatGPT 生态
GPT-5-mini	⭐⭐⭐⭐	⭐⭐⭐⭐	400K	快	低	Copilot 默认、高性价比
Gemini 3 Pro	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	2M	中	中	整库审查、超长上下文
Gemini 3 Flash	⭐⭐⭐⭐	⭐⭐⭐	1M	很快	很低	批量代码分析
Qwen3 Coder	⭐⭐⭐⭐	⭐⭐⭐⭐	256K	快	极低	开源、内网/合规部署
DeepSeek V3.2	⭐⭐⭐⭐	⭐⭐⭐⭐	128K	快	极低	开源、中文场景

模型表要按季度维护

模型名称、上下文窗口、价格、SWE-bench 排名和企业合规能力变化很快。面试时不要死背某个模型“永远第一”，更好的回答是：按任务复杂度、上下文长度、成本、隐私级别、延迟要求做动态路由。表格里的模型可作为 2026 年示例，真实选型以当前官方文档和团队实测为准。

3.2 模型路由策略

不要只用一个模型。按任务类型切换：

.claude/model-routing.ts
// 概念示意：根据任务类型选择最合适的模型
export function routeModel(task: TaskContext): string {
  // 1. Tab 补全：用最快最便宜的
  if (task.type === 'completion') return 'claude-haiku-4-5';

  // 2. Subagent 并行跑（会调用很多次）：用便宜的
  if (task.type === 'subagent') return 'claude-haiku-4-5';

  // 3. 整库审查：需要超长上下文
  if (task.contextSize > 500_000) return 'gemini-3-pro';

  // 4. 复杂架构 / 安全审查 / 小时级长任务：用最强推理
  if (task.type === 'architect' || task.type === 'security-review' || task.expectedDuration > 30 * 60) {
    return 'claude-opus-4-7';
  }

  // 5. 默认日常编码：Sonnet 4.6
  return 'claude-sonnet-4-6';
}

3.3 通过 Gateway 实现模型路由

企业场景不要让员工直接填 API Key。用 LiteLLM 或 OpenRouter 等 Gateway 统一入口，Gateway 层做路由和降级：

litellm.config.yaml（节选）
router_settings:
  fallbacks:
    # 如果 Opus 限流，降级到 Sonnet
    - claude-opus-4-7: [claude-sonnet-4-6]
    # 如果 GPT-5 挂了，降级到 Sonnet
    - gpt-5: [claude-sonnet-4-6]

详见 AI 研发基建 - 模型网关。

四、团队资产五件套（核心章节）

这是 2026 年 AI 辅助开发的真正差异化。下面每一件都给出完整的实战配置。

4.1 Rules：项目常识

定位：每次对话自动加载的「项目基础设施描述」。

三种流派：

工具	文件位置	特点
Claude Code	`CLAUDE.md`（支持多层级）	根目录 + 子目录级别继承
Cursor	`.cursor/rules/*.mdc`（支持 globs）	最灵活，可按路径匹配
Copilot	`.github/copilot-instructions.md`	单文件
通用	`AGENTS.md`（多工具兼容）	2025 年后出现的"最大公约数"约定

最佳实践：双文件策略

项目根目录/
├── AGENTS.md                     # 所有 AI 工具通用
├── CLAUDE.md                     # Claude Code 专用（可只写补充内容）
├── .cursor/rules/
│   ├── globals.mdc               # 全局规则
│   ├── components.mdc            # src/components/** 生效
│   └── api.mdc                   # src/app/api/** 生效
└── .github/copilot-instructions.md

AGENTS.md 内容示例（这个文件 Claude Code / Cursor / Aider / Copilot 都会读）：

AGENTS.md
# 项目规范

## 技术栈
- Next.js 15 (App Router) + React 19 + TypeScript 5
- 样式：Tailwind CSS 4 + shadcn/ui（禁用 @apply）
- 数据：Prisma + PostgreSQL
- 状态：Zustand（客户端）+ TanStack Query（服务端缓存）
- 表单：React Hook Form + Zod
- 测试：Vitest + Playwright
- 包管理：pnpm（**禁止** npm/yarn）

## 强制规范
- ❌ 禁止 `any`，用 `unknown` + 类型守卫
- ❌ 禁止 class 组件，只用函数组件 + Hooks
- ❌ 禁止在 Server Component 中使用 `useState`/`useEffect`
- ❌ 禁止硬编码密钥、URL、魔数
- ✅ 所有 API 必须 `auth()` 校验（公开接口在 `/api/public/*` 下）
- ✅ 所有表单必须 Zod 校验
- ✅ 所有异步 UI 必须处理 loading / error / empty 三态

## 命名约定
- 文件：kebab-case（`user-profile.tsx`）
- 组件：PascalCase
- Hook：`useXxx`
- 常量：`UPPER_SNAKE_CASE`
- 枚举：单数 PascalCase

## 开发命令
- `pnpm dev` — 开发服务器
- `pnpm lint` / `pnpm lint --fix` — ESLint
- `pnpm tsc --noEmit` — 类型检查
- `pnpm test` — 单元测试
- `pnpm test:e2e` — E2E 测试
- `pnpm db:push` — 同步数据库

## 提交前自检
改完代码一定要跑过：`pnpm lint && pnpm tsc --noEmit && pnpm test`

Rules 编写的 5 条铁律

具体到动作："Props 用 interface" 好过 "遵循 TS 最佳实践"
写清禁忌：用 ❌ 禁止 和 ✅ 必须，AI 对显式指令响应最好
包含命令：让 AI 知道怎么 lint / test / build
分层级：全局规则放根目录，特定目录规则放子目录
短而准：AGENTS.md 控制在 3K 以下，详细内容放 Skills（按需加载）

4.2 Skills：可复用技能包（重头戏）

Skill 和 Rules 的根本区别：

	Rules	Skills
加载时机	每次对话	AI 自主按需加载
Token 消耗	持续消耗	触发时才消耗
内容类型	项目通用规范	特定领域专业能力
典型大小	1-3K	0.5-10K（仅 SKILL.md），脚本/模板/参考不占上下文

把业务代码封装成 Skill 的 5 步法：

第 1 步：识别高频对象

团队开一次"Skill 候选会"，每人列举：

一周写 5 次以上的代码模式
新人经常写错的操作
涉及业务规则/合规/设计系统的操作

前端团队典型候选（按价值排序）：

⭐⭐⭐⭐⭐ 创建 API 路由（带 auth、Zod、错误码、限流）
⭐⭐⭐⭐⭐ 创建 React 组件（带 shadcn 约定、props、测试）
⭐⭐⭐⭐ 创建表单（React Hook Form + Zod + 设计系统）
⭐⭐⭐⭐ 添加 i18n 文案（多语言 + 键名约定）
⭐⭐⭐⭐ 添加埋点（事件命名 + 参数规范）
⭐⭐⭐ 数据库 migration（索引、回滚、全文搜索）
⭐⭐⭐ 生成 OpenAPI 类型（BFF ↔ 前端类型同步）
⭐⭐ 接入 OAuth Provider
⭐⭐ 发布组件库版本

第 2 步：设计目录结构

.claude/skills/api-route/
├── SKILL.md                     # 元数据 + 核心指令（< 500 字）
├── templates/                   # 代码模板
│   ├── rest-route.ts
│   └── server-action.ts
├── scripts/                     # 可执行脚本（比 AI 写可靠 10 倍）
│   └── generate-route.ts
├── reference/                   # 详细参考（按需读取）
│   ├── auth-patterns.md
│   ├── error-codes.md
│   └── rate-limiting.md
└── examples/                    # 完整示例
    ├── user-crud/
    └── payment-callback/

第 3 步：写 SKILL.md（决定触发准确性）

.claude/skills/api-route/SKILL.md
---
name: api-route
description: |
  创建 Next.js App Router 的 REST API 或 Server Action。
  触发场景：用户说"新建 API"、"加接口"、"创建后端路由"、"实现 Server Action"、"写个 BFF"时自动调用。
  覆盖：auth 鉴权、Zod 校验、统一错误码、rate limit、幂等性、事务。
---

# API 路由构建 Skill

## 使用流程

1. **确认类型**：REST 路由（浏览器需要 URL）还是 Server Action（同构场景）？
2. **加载模板**：
   - REST → `templates/rest-route.ts`
   - Server Action → `templates/server-action.ts`
3. **生成 Zod Schema**：每个字段生成严格校验
4. **套上必要层**：
   - `auth()` 校验（公开接口除外）
   - `rateLimiter(key, limit)` 见 `reference/rate-limiting.md`
   - 统一错误码见 `reference/error-codes.md`
5. **写测试**：正向、异常、边界各一个

## 强制约定

- ❌ **禁止** 直接 `await request.json()`，必须用 `parseBody(schema, request)` 或 Zod `safeParse`
- ❌ **禁止** `throw new Error('...')`，用 `ApiError.fromCode('USER_NOT_FOUND')`
- ❌ **禁止** 在路由里直接用 Prisma，必须走 `lib/db/*.ts` 封装层
- ❌ **禁止** `console.log`，用 `logger.info/warn/error`
- ✅ **所有** 非公开接口必须先 `auth()`
- ✅ **所有** 接口必须有 `rateLimiter()`
- ✅ **所有** 响应走 `apiResponse.ok(data)` 或 `apiResponse.error(code, message)`

## 脚本化路径

如果是 CRUD 样板（单一实体的 create/read/update/delete），直接调用脚本：

\`\`\`bash
node .claude/skills/api-route/scripts/generate-route.ts \\
  --entity User \\
  --operations "create,read,update,delete" \\
  --auth-required
\`\`\`

脚本会生成：路由文件 + Zod Schema + 类型定义 + 集成测试。**优先走脚本，不要让 AI 逐行写 CRUD**。

## 参考

- `reference/auth-patterns.md` — 7 种鉴权模式（用户、管理员、服务间、公开带签名、…）
- `reference/error-codes.md` — 统一错误码表
- `reference/rate-limiting.md` — 限流策略选型
- `examples/user-crud/` — 完整 CRUD 示例
- `examples/payment-callback/` — 带签名验证的回调示例

第 4 步：能用脚本就不要让 AI 写

对于强约束的样板代码，Skill 的核心价值是让 AI 调用脚本，不是自己生成代码。脚本示例：

.claude/skills/api-route/scripts/generate-route.ts
#!/usr/bin/env node
import { parseArgs } from 'node:util';
import { writeFileSync, mkdirSync } from 'node:fs';
import { join } from 'node:path';

// 从 Prisma schema 读取实体定义（脚本比 AI 读得准）
import { getEntityFields } from './lib/prisma-introspect';

const { values } = parseArgs({
  options: {
    entity: { type: 'string' },
    operations: { type: 'string' },
    authRequired: { type: 'boolean', default: true },
  },
});

const entity = values.entity!;
const operations = values.operations!.split(',') as ('create' | 'read' | 'update' | 'delete')[];
const fields = await getEntityFields(entity);

// 生成 Zod Schema
const schemaCode = generateZodSchema(entity, fields);
// 生成路由代码（严格按团队模板）
const routeCode = generateRouteCode(entity, operations, values.authRequired);
// 生成测试
const testCode = generateTests(entity, operations);

const basePath = join('src/app/api', entity.toLowerCase());
mkdirSync(basePath, { recursive: true });
writeFileSync(join(basePath, 'schema.ts'), schemaCode);
writeFileSync(join(basePath, 'route.ts'), routeCode);
writeFileSync(join(basePath, 'route.test.ts'), testCode);

console.log(`✅ 生成完成：${basePath}/`);
console.log(`下一步：运行 pnpm lint && pnpm tsc --noEmit 验证`);

AI 触发流程：

用户："给用户模块加一个重置密码接口"

AI 思考：
  - 这是"新建 API" → 触发 api-route Skill
  - 读取 SKILL.md
  - 判断：不是标准 CRUD（有 oldPassword/newPassword/confirmPassword），脚本不适合
  - 加载 templates/rest-route.ts
  - 加载 reference/auth-patterns.md（因为涉及鉴权）
  - 生成代码、Schema、测试

用户："把 User 表做个完整 CRUD"

AI 思考：
  - 标准 CRUD → 直接调脚本
  - 运行：node .claude/skills/api-route/scripts/generate-route.ts --entity User --operations "create,read,update,delete"
  - 不手写一行

第 5 步：验证触发准确性

Skill 的 description 写得不好，AI 不会正确触发。写完要做测试：

.claude/skills/api-route/test-cases.md
# api-route Skill 触发测试

## ✅ 应触发
- "给用户加一个重置密码接口"
- "创建 /api/search 路由"
- "实现购物车的 Server Action"
- "写一个公开的健康检查端点"
- "加一个带签名校验的 webhook 接收接口"

## ❌ 不应触发
- "优化 /api/users 的性能" → 是优化，不是新建
- "看下我们 API 的鉴权是怎么做的" → 是查询
- "把 fetch 改成 apiClient" → 是前端侧改动

## 🤔 边界场景
- "把 /api/users 的响应字段改一下" → 可以不触发（只是改字段），也可以触发（符合规范检查）→ 由 AI 决定

每月过一遍 Skill 的触发日志（Gateway 能记录），调整 description 关键词。

4.3 Subagents：专业子代理

Subagent 的核心价值：独立上下文。主 Agent 不被子任务的大量 token 污染。

4 个黄金使用场景

场景	为什么用 Subagent	推荐模型
大规模搜索/扫描	扫 200 个文件产生 500K tokens，只回传一句结论	Haiku 4.5
专业审查（安全/性能/a11y）	用不同系统提示、限权只读	Opus 4.7
并行生成（测试/文档/翻译）	主 Agent 继续主线，Subagent 干子任务	Sonnet / Haiku
探索型任务（查第三方库文档）	大量 WebFetch 返回不污染主会话	Haiku

标准 Subagent 清单

.claude/agents/
├── security-reviewer.md        # Opus + 只读 → 安全审查
├── test-writer.md              # Sonnet + __tests__/ 写权限 → 测试生成
├── doc-writer.md               # Haiku + docs/ 写权限 → 文档生成
├── pr-summarizer.md            # Haiku + 只读 → PR 总结
├── bug-hunter.md               # Opus + 只读 → 疑难 Bug 分析
├── db-query-reviewer.md        # Opus + 只读 → SQL 审查
├── dep-auditor.md              # Haiku + 只读 + WebFetch → 依赖安全审计
└── i18n-extractor.md           # Haiku + i18n/ 写权限 → 文案提取

完整 Subagent 定义

.claude/agents/security-reviewer.md
---
name: security-reviewer
description: |
  专业安全审查 Agent。用于审查代码的：XSS、SQL 注入、鉴权缺失、密钥泄露、CSRF、开放重定向、SSRF。
  当主 Agent 需要"安全审查"、"安全扫描"、"合规检查"时委派。
model: claude-opus-4-7
tools: [Read, Grep, Glob]      # 只读，物理上不能改代码
---

你是高级安全工程师，专注审查前端 + BFF 代码的安全性。

## 审查清单

### 🔴 MUST_FIX（阻塞合并）
1. **XSS**：`dangerouslySetInnerHTML` / `v-html` / `innerHTML` 未经 DOMPurify
2. **SQL 注入**：`$queryRaw` / 字符串拼接 SQL / 未参数化
3. **鉴权缺失**：非 `/api/public/*` 下的路由未调 `auth()`
4. **密钥泄露**：客户端代码出现 `process.env.*_SECRET`、`sk-`、私钥格式
5. **CSRF**：POST/PUT/DELETE 未校验 origin 且未用 SameSite Strict
6. **开放重定向**：`router.push(userInput)` 未白名单校验
7. **SSRF**：`fetch(userInput)` 未校验 URL 目的地

### 🟡 SHOULD_FIX（建议修复）
8. **日志敏感**：日志打印了密码、Token、信用卡
9. **弱加密**：用 MD5/SHA1 做密码哈希；AES-ECB
10. **依赖漏洞**：`npm audit` 有 high 级别

## 输出格式

**严格 JSON**，不要 markdown：

\`\`\`json
{
  "must_fix": [
    { "file": "src/api/xxx.ts", "line": 23, "category": "XSS", "issue": "...", "fix_hint": "..." }
  ],
  "should_fix": [...],
  "verdict": "BLOCK" | "WARN" | "PASS"
}
\`\`\`

## 强制约束

- 你**只能**读代码（只给了 Read/Grep/Glob）
- 不要修改任何文件
- 不要运行测试或构建
- 返回结论后终止

在主 Agent 中委派 Subagent

.claude/commands/review-security.md
---
name: review-security
description: 对当前分支改动做安全审查
---

对当前分支相对 main 的所有改动做安全审查：

1. 先运行 `git diff main...HEAD --name-only` 拿到改动文件列表
2. **委派给 security-reviewer Subagent** 审查这些文件
3. 把 Subagent 返回的 JSON 结构化展示给用户
4. 如果 `verdict === "BLOCK"`，强烈建议用户不要合并

Subagent 的成本陷阱

Subagent 并非免费——每个 Subagent 消耗独立 token。只在以下情况用 Subagent：

子任务会产生大量中间输出（搜索、扫描、大批量分析）
子任务可以并行（生成测试 + 生成文档 + 生成翻译）
子任务需要不同模型或限权配置

否则直接在主 Agent 里做更便宜。

4.4 Slash Commands：固化工作流

Skill vs Slash Command 的关键区别：

	Skill	Slash Command
触发	AI 自主根据 description 判断	用户输入 `/cmd` 明确触发
典型用途	创建 API、生成组件这种"能被多种自然语言触发"的操作	固定流程（PR 审查、发布、onboard）
参数	AI 推断	显式 `$ARGUMENTS`

标准 Slash Command 库（按分类）：

.claude/commands/
├── workflow/                    # 研发流程
│   ├── new-feature.md           # /new-feature [desc] — 完整功能开发
│   ├── review-pr.md             # /review-pr [focus] — PR 审查
│   ├── ship-release.md          # /ship-release — 发布流程
│   ├── hotfix.md                # /hotfix [issue-id] — 紧急修复
│   └── onboard.md               # /onboard — 新人导览
├── codegen/                     # 代码生成
│   ├── new-api.md               # /new-api [entity] — 新建 API
│   ├── new-component.md         # /new-component [name] — 新建组件
│   ├── new-page.md              # /new-page [path] — 新建页面
│   └── new-migration.md         # /new-migration [desc] — 新建 DB migration
├── quality/                     # 质量工具
│   ├── gen-tests.md             # /gen-tests [file] — 生成测试
│   ├── review-security.md       # /review-security — 安全审查
│   ├── review-perf.md           # /review-perf — 性能审查
│   └── fix-all-lint.md          # /fix-all-lint — 全项目 lint 修复
├── debug/                       # 调试
│   ├── debug.md                 # /debug — 结构化调试
│   ├── bisect.md                # /bisect [bad-commit] [good-commit] — 二分查找
│   └── analyze-error.md         # /analyze-error — 分析错误堆栈
├── docs/                        # 文档
│   ├── gen-api-docs.md          # /gen-api-docs — 生成 API 文档
│   ├── update-readme.md         # /update-readme — 更新 README
│   └── gen-changelog.md         # /gen-changelog — 生成 Changelog
└── ops/                         # 运维
    ├── triage.md                # /triage [alert-url] — 告警分级
    └── postmortem.md            # /postmortem [incident-id] — 生成复盘

示例：/new-feature — 完整新功能流程

.claude/commands/workflow/new-feature.md
---
name: new-feature
description: 新功能完整开发流程（需求 → 设计 → 实现 → 测试 → PR），每步等用户确认
argument-hint: "[需求描述或 Jira ID]"
---

新功能：$ARGUMENTS

**严格按以下步骤执行，每步完成后等我确认**。

## 步骤 1：需求理解（只读）

- 如果 `$ARGUMENTS` 看起来是 Jira ID（如 `ABC-1234`），通过 `jira-mcp` 读取详情
- 否则把 `$ARGUMENTS` 作为需求描述
- 读取 `.claude/memory/product-context.md`（如存在）了解产品背景
- **输出**：
  - 用 3-5 句话复述你理解的核心需求
  - 列出 2-3 个需要澄清的问题
  - 等我确认 / 补充

## 步骤 2：技术方案（只读，进入 Plan Mode）

- 搜索现有相关代码（用 Grep，不要 @codebase 乱搜）
- 给出 2-3 种方案对比：
  - 方案 A / B / C：核心思路、优劣、影响范围
- 推荐一种 + 理由
- 列出要改动/创建的文件清单
- 等我批准

## 步骤 3：实现（可写）

- 按文件清单逐个实现
- **优先使用已有 Skills**：
  - 创建 API → api-route Skill
  - 创建组件 → component-builder Skill
  - 创建表单 → form-builder Skill
- 每个文件改完后 PostToolUse Hook 自动跑 lint + tsc
- 有错立即修复，不继续下一步

## 步骤 4：测试

- **委派 test-writer Subagent** 为新建文件并行生成测试
- 主 Agent 继续跑主线
- Subagent 完成后，运行 `pnpm test` 确保通过

## 步骤 5：PR

- 生成 conventional commit：`feat(<scope>): <desc>`
- 生成 PR 描述：
  - ## Summary（3 个 bullet）
  - ## 实现细节
  - ## 测试策略
  - ## 影响范围
- **不 push**，等我本地检查

## 步骤 6：PR 自动审查

- 推送后会触发 `.github/workflows/ai-review.yml`
- 我会在 PR 上看到 `claude-code-action` 的审查意见
- 你（本地 AI）暂停等我 merge

用户使用：

> /new-feature 给文章详情页加一个"分享到社交媒体"按钮

AI: [步骤 1] 我理解的需求：
  - 在文章详情页底部加一个分享组件
  - 支持 Twitter/Facebook/LinkedIn 至少 3 个平台
  - 分享内容：文章标题 + URL + 可选的精选摘要
  
  需要澄清：
  1. 是否需要统计分享次数？
  2. 设计稿在哪里？
  3. 是否需要支持微信/微博？
  
  等你确认。

命令执行的好处：新人入职第一天就能用 /new-feature 交付功能——团队的规范、Skills、Subagents、Hook 全都自动加持。

4.5 Hooks：生命周期自动化

7 个关键 Hook 事件（以 Claude Code 为例）：

事件	触发时机	典型用途
`SessionStart`	新会话开始	注入动态上下文（Git 状态、未完成任务）
`UserPromptSubmit`	用户发送消息	敏感词过滤、自动补充 @mention
`PreToolUse`	工具调用前	拦截危险命令、审计日志
`PostToolUse`	工具调用后	自动 lint、tsc、截图
`PreCompact`	压缩上下文前	把关键决策持久化到 memory
`Stop`	AI 结束回复	通知、自动 commit
`SubagentStop`	Subagent 结束	聚合结果

实战案例集：

案例 1：PostToolUse 自动 lint + tsc（最有用）

.claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/post-edit-check.sh"
          }
        ]
      }
    ]
  }
}

.claude/hooks/post-edit-check.sh
#!/bin/bash
# AI 改完代码后自动 lint + tsc，错误直接回传给 AI

set +e

# Hook 输入通过 stdin 传入 JSON，文件路径在 tool_input.file_path
INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

if [[ "$FILE" =~ \.(ts|tsx|js|jsx)$ ]]; then
  LINT_OUTPUT=$(pnpm eslint --fix "$FILE" 2>&1)
  LINT_EXIT=$?

  TSC_OUTPUT=$(pnpm tsc --noEmit 2>&1 | grep "$FILE" | head -20)

  if [ $LINT_EXIT -ne 0 ] || [ -n "$TSC_OUTPUT" ]; then
    # 非零退出码会让 Hook 输出作为 stderr 返回给 AI
    echo "⚠️ 质量检查失败，请修复："
    echo "Lint:"
    echo "$LINT_OUTPUT" | tail -20
    echo ""
    echo "TypeScript:"
    echo "$TSC_OUTPUT"
    exit 2  # Claude Code 约定的"请 AI 修复"退出码
  fi
fi

效果：AI 每次改完文件立即看到 lint/type error，下一轮自动修复——你无需提醒。

案例 2：PreToolUse 拦截危险命令

.claude/hooks/pre-bash-guard.sh
#!/bin/bash
# 从 stdin 读取 Claude 要执行的命令
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command')

# 审计日志
echo "$(date -Iseconds) | $CMD" >> .claude/audit.log

# 黑名单检查
DANGEROUS_PATTERNS=(
  "rm -rf /"
  "rm -rf \\*"
  "rm -rf ~"
  "git push --force"
  "git push -f"
  "git reset --hard"
  "sudo"
  "dd if="
  "chmod 777"
  "> /dev/sd"
  ":(){ :|:& };:"
)

for pattern in "${DANGEROUS_PATTERNS[@]}"; do
  if echo "$CMD" | grep -qE "$pattern"; then
    # 阻断
    echo "🚫 BLOCKED: 命令包含危险模式 '$pattern'" >&2
    echo "如需执行，请用户手动在终端操作。" >&2
    exit 2
  fi
done

# 警告（不阻断）
WARN_PATTERNS=("drop table" "truncate" "delete from")
for pattern in "${WARN_PATTERNS[@]}"; do
  if echo "$CMD" | grep -qi "$pattern"; then
    echo "⚠️ 警告：这个命令会影响数据库。请确认。" >&2
    # 不 exit 2，只是提示
  fi
done

案例 3：SessionStart 动态注入项目状态

.claude/hooks/session-start.sh
#!/bin/bash
# 每次新会话把当前项目状态喂给 AI

cat <<EOF
<current_project_state>

## Git 状态
- 当前分支：$(git branch --show-current)
- 相对 main 领先 $(git rev-list --count HEAD ^main) 个 commit
- 未提交改动：$(git status --short | wc -l) 个文件

## 最近改动
$(git log --oneline -5)

## 未完成的任务（来自 memory）
$(cat .claude/memory/todo.md 2>/dev/null || echo "（无）")

## 最近构建状态
$(ls -lt .next/BUILD_ID 2>/dev/null | awk '{print $6, $7, $8}' || echo "未构建")

</current_project_state>
EOF

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": ".claude/hooks/session-start.sh" }
        ]
      }
    ]
  }
}

案例 4：Stop Hook 自动通知

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"任务完成\" with title \"Claude Code\" sound name \"Glass\"'"
          }
        ]
      }
    ]
  }
}

长任务完成时你无需盯着屏幕——系统通知 + 声音提醒。

Hook 反模式（不要做的事）

Hook 里跑全量 test → AI 每次写文件卡 30 秒，体验灾难
Hook 触发写操作导致循环 → Hook 改了文件又触发 PostToolUse
Hook 依赖外网 → 网络慢时 Agent 卡住
Hook 没有超时 → 挂了 Agent 永远等
Hook 错误静默 → 调试困难

原则：Hook = 快速、幂等、低风险。重活交给 CI。每个 Hook 应该在 3 秒内完成。

五、工作流模式

5.1 三种执行模式

模式	何时用	配置
Auto（默认）	日常编码，有 allow/ask/deny 规则	`.claude/settings.json` 的 `permissions`
Plan	大型重构、探索未知代码库	Claude Code 输入 `/plan` 或按 Shift+Tab 两次
YOLO（⚠️仅沙箱内）	批量任务、CI、一次性脚本	`claude --dangerously-skip-permissions` + 配合 sandbox

Plan Mode 工作流：

用户：把项目从 Pages Router 迁移到 App Router
  ↓
Claude [Plan Mode 开启]：
  [Read] package.json, next.config.js
  [Grep] 所有 _app.tsx / _document.tsx / getServerSideProps
  [Glob] pages/**/*
  [分析] 42 个页面 + 8 个 API + 3 个布局
  [输出计划]
    阶段 1：公共布局迁移（layout.tsx）
    阶段 2：API 路由迁移（app/api）
    阶段 3：页面逐个迁移（按依赖拓扑）
    阶段 4：getServerSideProps → Server Component
    阶段 5：删除 pages 目录
    共 53 步，预计 2 小时

用户：[审核计划，删掉阶段 5，加个 "保留 pages/_app.tsx 作为 fallback"] → 批准

Claude [切到 Auto Mode]：开始执行阶段 1...

核心价值：避免 "AI 乱改 50 个文件后发现方向错了"。

5.2 Sandbox + Git Worktree：并行 Agent 终极模式

2026 年最强大的工作流：开多个 Agent，各自在独立 worktree 并行干活。

# 主仓库在当前目录
# 给 3 个独立任务各开一个 worktree
git worktree add ../proj-feat-share agent/feat-share
git worktree add ../proj-refactor-auth agent/refactor-auth
git worktree add ../proj-dep-upgrade agent/dep-upgrade

# 开 3 个终端，每个跑一个 Agent
# 终端 1
cd ../proj-feat-share && claude "/new-feature 加分享按钮"

# 终端 2
cd ../proj-refactor-auth && claude "重构 lib/auth，用 Lucia 替换 NextAuth"

# 终端 3
cd ../proj-dep-upgrade && claude "把 tailwind 从 3 升到 4"

# 3 小时后，3 个 worktree 都有结果
# 每个 worktree 独立 review、独立合并，互不干扰

为什么 worktree 比新 clone 好：

不用重新 pnpm install（共享同一个 .git 目录）
启动快（秒级）
分支切换不影响主工作区

好处：

并行 3 倍产出
实验性改动失败直接 git worktree remove 丢弃
主工作区保持清洁

并行 Agent 的前提

任务之间尽量独立。如果 3 个任务都要改 src/lib/auth.ts，合并时会大量冲突，反而更慢。

怎么判断是否可以并行：3 个任务的"计划"（Plan Mode 输出）里改的文件集合是否重叠。不重叠就可以并行。

5.3 交互粒度匹配

经验法则：如果你连续 3 次手动 Cmd+K，就该升级到 Cmd+I（Composer）；连续 10 次 Cmd+I 就该开 CLI。

六、上下文管理实战

详细理论见 Context Engineering。实战关键动作：

6.1 精确 @mention 胜过 @codebase

❌ 反模式：
@codebase 用户模块有什么问题？
→ AI 把 30 个无关文件塞进上下文，质量反而下降

✅ 正例：
@src/app/api/users/route.ts @src/lib/db/users.ts 
用户列表 API 查 10 万条数据很慢，帮我分析瓶颈
→ 只给 2 个最相关的文件，质量极高

规则：宁可多问一轮也不要乱塞。先让 AI 告诉你它需要哪些文件，再手动 @mention。

6.2 主动 Compact 长会话

Claude Code 在上下文接近 80% 时会自动 /compact。但更好的做法是主动在阶段性节点 compact：

完成一个功能后：
> /compact 本次做了 XX，关键决策见 memory/decisions.md

继续下一个功能：
> ...

这样关键决策被保留，细节被压缩，上下文保持清爽。

6.3 工具返回裁剪

AI 工具返回常常撑爆上下文。策略：

Bash 命令加 | head -50 或 | tail -50
Read 大文件用 offset + limit 分段读
Grep 用 output_mode: files_with_matches 先看命中的文件，再选择性读内容
委派 Subagent 处理大量原始数据，只回传结论

七、AI 辅助的日常任务手册

以下是最高频的 5 类任务的完整实战模板。

7.1 新功能开发

首选工具链：Cursor Composer OR Claude Code CLI
推荐流程：/new-feature [描述]（见 4.4 示例）

关键动作：

Plan Mode 先出方案
用已有 Skills 生成代码（不手写样板）
Subagent 并行生成测试
Hook 自动 lint/tsc
PR 触发 claude-code-action 审查

预期效率：2026 年的实际数据，中等复杂度功能（涉及 5-10 个文件）：

纯手写：1-2 天
AI 辅助（有基建）：2-4 小时
效率提升：3-5 倍

7.2 Bug 排查

首选工具链：Claude Code CLI + Sentry MCP
推荐 Slash Command：/debug 或 /analyze-error

.claude/commands/debug/debug.md
---
name: debug
description: 结构化调试流程
---

按以下结构告诉我 Bug 信息（如果缺少，先反问我补充）：

## 1. 现象
（用户看到的）

## 2. 期望 vs 实际
（明确对比）

## 3. 复现步骤
（精确到点击哪个按钮、输入什么）

## 4. 环境
- 浏览器 / 版本
- OS
- 开发/预发/生产

## 5. 已试过的排查
（避免你重复我做过的事）

## 6. 相关代码
（@mention 或粘贴）

## 7. 错误日志/堆栈
（完整粘贴，不要省略）

---

收到信息后：

1. **根因假设**：按概率排序列出 3 个可能原因
2. **验证方法**：每个假设给出验证手段（读哪个文件、跑什么命令、加什么日志）
3. **推荐先验证哪个**
4. 等我验证结果后再继续

进阶：如果用 Sentry MCP，直接 /debug SENTRY-XYZ-123 AI 自动拉完整错误上下文。

7.3 大型重构

首选工具链：Claude Code CLI + worktree
关键：Plan Mode 必须先出计划

# 1. 开独立 worktree
git worktree add ../proj-refactor-state agent/refactor-state

# 2. 进入 Plan Mode
cd ../proj-refactor-state
claude
> /plan
> 把全局 Zustand store 拆分为按模块隔离的多个 store

# 3. Claude 出 42 步迁移计划，你审核
# 4. 批准，开始执行
# 5. 每完成一步自动跑 test，失败立即停
# 6. 完成后在 worktree 里 review
# 7. 合回主分支或丢弃

为什么必须 worktree：重构常常大面积改动，万一方向错了可以整个丢弃，主工作区 0 污染。

7.4 依赖升级

首选工具链：Claude Code CLI + dep-auditor Subagent
推荐 Slash Command：/upgrade [package]

.claude/commands/ops/upgrade.md
---
name: upgrade
description: 升级依赖并处理 breaking changes
argument-hint: "[package name] [target version]"
---

升级 $ARGUMENTS。

步骤：

1. **现状调研**
   - 当前版本：`pnpm list <pkg>` 
   - 目标版本：默认 latest，除非用户指定
   - 我们代码中的使用点：`grep -rn "from '<pkg>'"`

2. **Breaking changes 分析**
   - **委派 dep-auditor Subagent**（带 WebFetch 权限）查官方 CHANGELOG / Migration Guide
   - Subagent 只返回：「有/无 breaking changes」+ 影响我们代码的具体项

3. **制定迁移计划**
   - 按调用点列出需要改的地方
   - 进入 Plan Mode 让我审核

4. **执行升级**
   - `pnpm update <pkg>@<ver>`
   - 按计划改代码
   - 每改一个文件 Hook 自动 lint/tsc

5. **验证**
   - `pnpm test`
   - `pnpm build`
   - 修一轮可能的新错误

6. **生成 PR**
   - commit: `chore(deps): upgrade <pkg> to <ver>`
   - PR 描述包含 breaking changes 列表

7.5 技术调研

首选工具链：Cursor Chat + @docs / Claude Code + WebFetch
不推荐直接用 ChatGPT（它不知道你的项目背景）

> 我想给项目加实时协同编辑，对比 Yjs、Liveblocks、Automerge 三种方案

AI：我会从你的项目背景出发对比
[Read] package.json — 看已有依赖
[Read] AGENTS.md — 看技术栈
[Grep] "editor" — 看已有编辑器实现

对比维度：
- 集成复杂度：Liveblocks (SaaS, 最简) > Yjs (自建 WS, 中) > Automerge (自建, 复杂)
- 成本：Liveblocks 按 MAU 付费；Yjs/Automerge 自建基础设施
- ...

结合你项目是 Next.js + 小规模 (< 1000 MAU) + 不想自建 WS server：
**推荐 Liveblocks**

是否需要我出 PoC？

关键：调研要让 AI结合项目实际情况给建议，不是给"通用答案"。

八、AI 代码审查自动化

8.1 三层审查体系

8.2 PR 自动审查（推荐配置）

.github/workflows/ai-code-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
      issues: write

    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # 使用仓库 AGENTS.md + .claude/agents/security-reviewer.md
          # claude-code-action 会自动加载
          prompt: |
            请审查此 PR 变更，按以下分类输出 inline comment：
            - 🔴 MUST_FIX：Bug、安全漏洞、数据丢失风险
            - 🟡 SHOULD_FIX：性能、可维护性
            - 🔵 NICE_TO_HAVE：优化建议
            - 🟢 GOOD：值得肯定的好实践

            对于 src/app/api/** 的文件，额外委派 security-reviewer Subagent
            对于 lib/db/** 的文件，额外委派 db-query-reviewer Subagent
            对于 src/components/** 的文件，重点查 React 性能
          claude_args: |
            --allowedTools Read,Grep,Glob
            --max-turns 10

GitHub Action v1 配置注意

direct_prompt、allowed_tools、model 等旧输入已逐步迁移到 prompt 和 claude_args。如果希望 Claude 在 CI 中运行测试、lint 或自定义 MCP 工具，需要通过 --allowedTools / --mcp-config 明确授权；默认只给最小 GitHub 和文件操作能力。

关键优势：

claude-code-action 自动读 PR diff 和仓库上下文
直接发 inline comment（不是汇总评论）
用户可以在 PR 中 @claude 追问

8.3 本地 pre-commit 预审

.husky/pre-commit
#!/bin/bash

# 基础检查
pnpm lint-staged

# 只对"被改动"的文件做 AI 预审
CHANGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx)$')

if [ -n "$CHANGED_FILES" ]; then
  # 调用 Claude Code headless mode
  claude -p "审查以下改动是否有明显问题（安全、类型、逻辑错误）。改动见 \`git diff --cached\`。只返回 MUST_FIX 级别问题的 JSON 列表，如果没有问题返回 '{\"issues\":[]}'。" \
    --output-format json > /tmp/ai-review.json

  ISSUES=$(jq '.issues | length' /tmp/ai-review.json)
  if [ "$ISSUES" -gt 0 ]; then
    echo "🚫 AI 发现 $ISSUES 个严重问题，请查看 /tmp/ai-review.json"
    jq '.issues' /tmp/ai-review.json
    exit 1
  fi
fi

注意：本地预审要快（< 30s），否则影响 commit 体验。只查 MUST_FIX 级别，不做全量审查。

九、成本与效能度量

9.1 核心指标

类别	指标	目标值	采集来源
成本	人均 Token 消耗 / 天	< 2M	Gateway 日志
成本	Prompt Cache 命中率	> 50%	Anthropic / OpenAI headers
效率	Feature 平均交付时间	降低 30%+	Jira 数据
效率	PR 合并周期	降低 30%+	GitHub 数据
质量	AI 代码引入的 Bug 率	不增加	Bug Tracker 打标
质量	生产 P0/P1 事件数	不增加	监控告警
使用	AI 工具日活率	> 80%	IDE / Gateway 日志
使用	Skill 平均触发准确率	> 85%	Gateway + 人工标注

9.2 Metabase 自建看板（最小方案）

Gateway（如 LiteLLM）默认写 Postgres。接 Metabase 即刻出图：

-- 按员工看月度成本
SELECT 
  user_id,
  DATE_TRUNC('month', created_at) AS month,
  SUM(input_tokens * 0.000003 + output_tokens * 0.000015) AS cost_usd
FROM litellm_requests
WHERE model LIKE 'claude%'
GROUP BY user_id, month
ORDER BY cost_usd DESC;

-- 按模型看分布
SELECT 
  model,
  COUNT(*) AS calls,
  AVG(input_tokens) AS avg_input,
  SUM(cache_hit_tokens) * 1.0 / SUM(input_tokens) AS cache_rate
FROM litellm_requests
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY model;

-- 异常使用检测
SELECT user_id, DATE(created_at) AS day, SUM(input_tokens) AS daily_tokens
FROM litellm_requests
WHERE created_at > NOW() - INTERVAL '7 days'
GROUP BY user_id, day
HAVING SUM(input_tokens) > 10000000  -- 单日 > 10M 预警
ORDER BY daily_tokens DESC;

9.3 ROI 快速估算

典型 50 人团队年度 ROI（基于 2026 年实际数据）：

项目	成本	收益
Gateway 基建投入（2 人 × 3 月）	60 万	—
模型 API 费用（50 人均 $100/月）	45 万	—
效率提升（30% × 50 × 30K × 12）	—	540 万
新人 onboarding 节省（10 人 × 2 周 × 15K）	—	30 万
生产事件减少（5 次 × 30 万）	—	150 万
总计	105 万	720 万
ROI	—	6.8x

十、安全边界

10.1 数据分级

Tier 1：公开代码（开源项目、文档、测试）
  → 自由使用任何 AI 工具

Tier 2：内部代码（业务逻辑、UI）
  → 必须通过 Gateway
  → 可以发送给主流模型

Tier 3：敏感代码（支付、鉴权、加密）
  → AI 只能辅助，关键代码人工编写
  → 禁止发送给不签署 DPA 的模型

Tier 4：合规代码（金融、医疗、政务）
  → 只能用私有部署的开源模型（Qwen3、DeepSeek）
  → 网络隔离

10.2 硬性红线

❌ 永远不要把 .env、密钥、客户数据给 AI
❌ 永远不要绕过 Gateway 直接用个人 API Key
❌ 永远不要让 AI 自动合并到 main / 自动部署生产
❌ 永远不要让 AI 改 CI/CD 凭据管理代码
❌ 永远不要 YOLO 模式下在主工作区跑（必须配沙箱）

10.3 `.cursorignore` / `.claudeignore`

# 敏感文件
.env
.env.*
*.pem
*.key
credentials.json
secrets/

# 体积大或无价值
node_modules/
.next/
dist/
build/
*.png
*.mp4

# 生产数据快照
fixtures/production-data/

十一、常见反模式（避坑清单）

反模式	后果	正解
让 AI 一次写完所有代码	错误累积、定位困难	分步迭代，每步 verify
`@codebase` 乱塞上下文	信噪比低、成本高、质量差	精确 `@file` + Grep 定位
不配 Rules / Skills 就开用	每次重复教 AI 项目规范	前期花半天配好，事半功倍
Skill 写得像论文	AI 触发不准确	< 500 字，description 用原话
Hook 里跑全量 test	Agent 卡死	Hook 只做快速操作，重活交 CI
YOLO 模式在主工作区	改错无法恢复	配 worktree/docker 沙箱
完全信任 AI 输出不审查	线上 Bug 暴涨	关键代码必须人工终审
每人发一个账号不要 Gateway	成本失控、安全漏洞	Day 1 先上 Gateway
追求完美 IDE 统一	老用户反感	IDE 自由，Rules/Skills 统一
Skill 放个人 `~/.claude`	离职带走	全部纳入 Git

十二、实用小技巧合集（以 Claude Code 为例）

很多功能藏在角落里，单独看只省几秒，但乘以每天几百次交互一年能省出一个季度。以下都是容易被忽略但真的天天会用的技巧，常见的（/clear、@file、Plan Mode 等）不再重复。

12.1 会话与上下文

技巧	做法	为什么有用
双击 Esc 回溯并编辑	连按两次 Esc → 方向键选到某条历史 user message → 改完重发	发现 AI 跑偏不用 `/clear` 重来，只重走出错的那一步；大多数人不知道这个
Agent 执行中排队消息	Claude 跑工具时继续输入并回车	想到补充立即写，排队到下一轮处理，不用等
`#` 开头一键写记忆	`# 本项目用 pnpm 不是 npm` 回车，自动追加到 `CLAUDE.md`	比手动打开文件编辑快 10 倍
`/compact <指令>`	`/compact 只保留当前 Bug 的调用栈，丢弃前面的调研`	普通 `/compact` 是通用摘要；带指令定向压缩才是正确姿势
`claude -c` 恢复上次会话	重开终端直接 `claude -c`（等价 `--continue`）	网络抖动/误关窗口后无缝续上
`/resume` 选择历史会话	打开列表跨天挑任意会话恢复	多任务并行时找回上周的那个调试会话
多层级 `CLAUDE.md`	在 `packages/web/CLAUDE.md` 写子模块规范	进入该子目录自动叠加加载，根目录 CLAUDE.md 不会臃肿
`CLAUDE.md` 的 `@file` 导入	`CLAUDE.md` 里写 `@docs/api-conventions.md`	拆分成多个文件，可单独 review/复用

12.2 输入快捷键

技巧	做法	为什么有用
`!` 开头直接跑 Bash	输入框起手 `!` → `git log -5`	一次性命令不走 agent，结果直接进上下文，省一轮工具调用
`Shift+Tab` 切权限模式	default ↔ acceptEdits ↔ plan 循环切换	关键重构切 plan，批量改格式切 acceptEdits，不用重启
粘贴/拖拽图片	截图直接拖进终端或 `Cmd+V`	报错截图、设计稿、架构图零成本给 AI
Esc 单击打断	发现方向不对立刻按 Esc	早停 1 分钟比白跑 5 分钟强，且上下文保留

12.3 Prompt 技巧

技巧	做法	为什么有用
Thinking 预算关键词	在 prompt 里写 `think` / `think hard` / `think harder` / `ultrathink`	这些是硬编码关键词，会按等级分配更多 thinking tokens，复杂算法/架构题显著更准
XML 标签组织长 prompt	`<context>...</context> <task>...</task> <constraints>...</constraints>`	比纯 Markdown 更能让模型分清段落职责，官方文档推荐写法
委派 Subagent 做"脏活"	"用 subagent 读这 50 个文件找所有 API 调用点，只返回清单"	Subagent 独立上下文，主会话不被海量文件内容污染，成本也低

12.4 配置类

技巧	做法	为什么有用
Hook `matcher` 支持正则	`"matcher": "Edit\|Write"` 只匹配写操作	避免 hook 对所有工具都触发，性能和正确性都更好
`SessionStart` hook 注入上下文	会话启动自动跑 `git status` + 当前分支说明喂给 AI	不用每次手动介绍"当前在做什么"
Subagent 指定 `model` 字段	搜索类 subagent 设 `model: haiku`	主 agent 用 opus，subagent 用便宜模型，复杂任务成本立降 50%+
Skill frontmatter `allowed-tools`	`allowed-tools: Read Grep`	为 Skill 活跃期间预批准工具；它不是限制清单，真正限权用权限 deny 或 Subagent `tools`
`--add-dir` 多根目录	`claude --add-dir ../api --add-dir ../mobile`	前后端/多仓联调时一个会话打通，不用切窗口
`/cost` 实时查成本	随时看当前会话累计 token 和 $	任务跑失控了立刻停，避免月底对账心梗
`/output-style` 定制风格	切换 `concise` / `explanatory` / 自定义	新人用 explanatory 学习，老手用 concise 加速

12.5 工作流

技巧	做法	为什么有用
PostToolUse hook 自动格式化	Edit/Write 后自动跑 `prettier --write $FILE`	AI 改完立刻格式化，省掉最后一次手动批处理
Stop hook 跑相关测试	会话结束触发 `pnpm test --related $CHANGED_FILES`	走之前留个自动体检，第二天不用慌
`/mcp` 查连接状态	看哪个 MCP server 挂了、哪些工具可用	MCP 出问题第一个排查命令，比翻日志快
`/doctor` 体检配置	检查权限、路径、API key 状态	环境突然不对劲时一键定位

.claude/settings.json 实用 hook 示例
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "INPUT=$(cat); FILE=$(echo \"$INPUT\" | jq -r '.tool_input.file_path // empty'); [ -n \"$FILE\" ] && prettier --write \"$FILE\" 2>/dev/null || true"
          }
        ]
      }
    ],
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '当前分支: '$(git branch --show-current)'\\n最近改动:\\n'$(git diff --stat HEAD~1 2>/dev/null | head -10)"
          }
        ]
      }
    ]
  }
}

一句话总结

AI 工具 80% 的效率提升来自 20% 的冷门技巧。

花半小时把上面这些配置好，回报周期一周内收回。真正拉开人和人使用 AI 效率的不是模型，是这些藏在角落的细节。

十三、面试速答与追问清单

3 分钟速答版

如果面试官问“你平时怎么用 AI 辅助开发”，可以这样答：

工具分层：轻量补全用 IDE，复杂多文件任务用 Agent，重构和 CI 场景用 CLI / GitHub Action。
上下文分层：项目规则放 Rules，重复流程沉淀成 Skills / Slash Commands，大量搜索交给 Subagents，工具能力通过 MCP 接入。
质量闭环：AI 生成后不是直接合并，而是 Hook 自动 lint/typecheck、Subagent 做测试和安全审查、PR 里再由 AI + 人工 reviewer 双审。
安全边界：敏感文件进 ignore，企业场景走 Gateway、DLP、审计和权限控制，不让个人 API Key 直连模型。
度量结果：看交付周期、PR 周期、测试覆盖、Bug 率、AI 采纳率、token 成本，而不是只说“感觉更快”。

10 分钟展开版

可以按“选型 → 资产化 → 自动化 → 治理 → 度量”展开：先说明不同任务匹配不同工具和模型，再讲 Rules / Skills / Subagents / Hooks 的职责，接着讲 Plan Mode、worktree、CI 审查、MCP 接内部系统，最后补成本、安全和 ROI。

高频追问

追问	回答要点
为什么不用一个最强模型通吃？	成本、延迟、上下文、隐私不同；用 Gateway 做路由和 fallback
Skill 和 Rules 有什么区别？	Rules 每次加载，适合静态项目常识；Skill 按需加载，适合流程和专业能力
Subagent 什么时候用？	大量搜索、专业审查、并行测试、调研；简单任务不要滥用
Hook 最大的坑是什么？	太慢、不可幂等、触发循环、权限过大；Hook 要快且可解释
如何防止 AI 乱改？	Plan Mode、权限 deny、PreToolUse Hook、worktree、人工审批
如何证明 AI 有 ROI？	交付时间、PR 周期、测试覆盖、线上问题、token 成本和采纳率一起看
如何避免能力退化？	AI 生成后必须读懂、关键设计自己决策、定期脱离 AI 练基本功

阅读分工

本篇专注“工具怎么用”。企业级网关、治理和推广见 AI 研发基建，从需求到上线的串联流程见 AI 全流程研发实战。

常见面试问题

Q1: 你日常开发如何使用 AI 工具？效率提升了多少？

答案：

我的日常组合是 Cursor + Claude Code：

Cursor 承担 80% 的日常编码：Tab 补全、Inline Edit（Cmd+K）、小规模多文件用 Composer（Cmd+I）
Claude Code CLI 承担剩下 20% 的重活：大型重构、跨模块改动、CI/CD headless 审查、并行 worktree 多 Agent 场景
两者共用同一套 .claude/ 配置（Rules / Skills / Subagents / Slash Commands / Hooks），能力最大化

实际效率提升（2026 年数据）：

新功能开发（5-10 个文件）：从 1-2 天 → 2-4 小时，3-5 倍
样板代码（CRUD、表单）：5-10 倍，基本 0 手写
调试：结构化 /debug 流程 + Sentry MCP 直接拉错误，2-3 倍
大型重构：Plan Mode 出方案 + worktree 沙箱，2 倍
代码审查：claude-code-action 自动 inline review，人工聚焦业务，审查效率 2 倍

最大的关键点：把团队经验打包成 Skills / Subagents / Slash Commands 之后，团队每个人都有同等的 AI 加持。这比单人效率提升更重要。

Q2: 如何选择 AI 编程工具和模型？

答案：

工具选择（2026 年）：

场景	推荐
个人日常	Cursor — IDE 体验最好
团队 + 重度 Agent	Claude Code — 四件套最完整
企业合规	GitHub Copilot Business — SOC2/SAML/IP 赔偿
超长上下文	Cursor + Gemini 3 Pro（2M）/ Claude Code + Opus 4.7（1M）
内网合规	自部署 Qwen3 Coder / DeepSeek V3.2

模型路由：不要只用一个模型，按任务类型切：

Tab 补全 / 轻量 Subagent：Claude Haiku 4.5
日常编码：Claude Sonnet 4.6（SWE-bench 第一）
架构设计 / 安全审查 / 小时级长任务：Claude Opus 4.7
整库审查（> 500K token）：Gemini 3 Pro（2M 上下文）

关键动作：在 Gateway 层配 fallback 策略（Opus 限流自动降到 Sonnet），避免单点依赖。

Q3: 如何配置 Rules 文件以最大化 AI 效果？

答案：

Rules 是项目常识，是 AI 辅助开发的最低基础设施。2026 年最佳实践：

双文件策略（最大兼容性）：

AGENTS.md            ← 所有 AI 工具都读（Claude Code / Cursor / Aider / Copilot）
CLAUDE.md            ← Claude Code 专用补充
.cursor/rules/       ← Cursor 专用（按 glob 精细控制）

AGENTS.md 写作 5 条铁律：

具体到动作："Props 用 interface" 好过 "遵循 TS 最佳实践"
用 ❌ 禁止 / ✅ 必须：AI 对显式指令响应最好
包含命令：pnpm lint / pnpm test / pnpm build 让 AI 知道怎么自检
分层级：全局规则根目录，特定目录规则放子目录（Claude Code 原生支持）
短而准：AGENTS.md 控制在 3K 以下，详细内容放 Skills（按需加载）

关键动作：Rules 必须提交到 Git，团队共享。不要把 Rules 塞成 200 行的论文——那会撑爆每次对话的上下文，反而降低 AI 注意力。

Q4: Skills、Subagents、Slash Commands、Hooks 分别是什么？

答案：

2026 年 AI 工具的五件套（含 Rules）：

能力	触发	本质	典型用途
Rules	每次对话自动	项目常识	技术栈、禁忌、命令
Skills	AI 根据 description 自主	按需加载的领域能力包	创建 API、生成表单
Subagents	主 Agent 委派	独立上下文的子 AI	安全审查、并行测试生成
Slash Commands	用户输入 `/cmd`	固化工作流	`/new-feature`、`/ship`
Hooks	事件触发	生命周期回调	自动 lint、危险命令拦截

关键区别：

Rules vs Skills：Rules 每次消耗 token 但始终生效；Skills 只在触发时才消耗，但依赖 AI 正确识别
Skills vs Slash Commands：Skills 自然语言触发（AI 判断），Slash Commands 用户明确触发（输入 /）
Subagents vs Skills：Subagents 是独立 AI，Skills 是加载到主 AI 上下文的知识+工具

组合威力：/new-feature（Slash Command）→ api-route（Skill）→ test-writer（Subagent） → PostToolUse（Hook 自动 lint） = 新人第一天就能交付规范代码。

Q5: 怎么把业务代码封装成 Skill？

答案：

5 步方法论：

第 1 步：识别候选。团队开会列举每周 5 次以上的代码模式、新人常踩坑的操作、涉及业务规则的操作。

第 2 步：设计目录：

.claude/skills/<name>/
├── SKILL.md          # 元数据 + 核心指令（< 500 字）
├── templates/        # 代码模板
├── scripts/          # 可执行脚本（比 AI 写可靠 10 倍）
├── reference/        # 详细参考（按需读）
└── examples/         # 完整示例

第 3 步：写 SKILL.md 的 description（决定触发准确率）：

description: |
  创建 Next.js API 路由或 Server Action。
  触发场景：用户说"新建 API"、"加接口"、"创建后端路由"、"实现 Server Action"时自动调用。

description 必须包含用户会说的原话。

第 4 步：能用脚本就不要让 AI 写。对于强约束的样板代码（如 CRUD），写一个接收 JSON Spec 的生成脚本，让 AI 调用脚本而非自己生成。脚本比 AI 快 10 倍且结果确定。

第 5 步：验证触发准确性。写测试用例（应触发 / 不应触发 / 边界场景），每月 review Skill 日志，调整 description。

核心原则：一次投入，团队永远受益。Skill 是团队的永久资产，不是一次性 Prompt。

Q6: Subagent 什么时候该用？什么时候不该用？

答案：

该用 Subagent 的 4 个黄金场景：

大规模搜索/扫描：扫 200 个文件产生 500K tokens 但只回传一句结论 → 主上下文保洁
专业审查（安全/性能/a11y）：用不同系统提示、限权只读
并行生成（测试/文档/翻译）：主 Agent 继续主线，Subagent 并行干活
探索型任务（查第三方库文档、WebFetch）：大量返回不污染主会话

不该用 Subagent 的场景：

简单任务：Subagent 有独立 LLM 调用开销，小任务不划算
需要完整上下文的任务：Subagent 看不到主会话，不适合有连续性的任务
线性流程：步骤 A 依赖 B 结果，B 依赖 A 的中间产物——这种用主 Agent 直接做

推荐清单（团队先做这 5 个 Subagent）：

security-reviewer（Opus 4.7 + 只读）
test-writer（Sonnet 4.6 + __tests__/ 写权限）
doc-writer（Haiku 4.5 + docs/ 写权限）
pr-summarizer（Haiku + 只读）
bug-hunter（Opus + 只读）

Q7: Hooks 有哪些常见用法？有什么坑？

答案：

7 个核心事件：SessionStart / UserPromptSubmit / PreToolUse / PostToolUse / PreCompact / Stop / SubagentStop

最有价值的 3 个用法：

PostToolUse 自动 lint/tsc（必配）：AI 改完代码立即看到错误，下一轮自动修复
PreToolUse 拦截危险命令：黑名单 rm -rf / git push --force / sudo，审计日志
SessionStart 注入动态上下文：当前 Git 状态、未完成任务、最近错误日志

5 个反模式（坑）：

Hook 里跑全量 test → Agent 每次写文件卡 30 秒，体验灾难
Hook 触发写操作导致循环 → PostToolUse Hook 改了文件又触发自己
Hook 依赖外网 → 网络慢时 Agent 卡死
Hook 没有超时 → 挂了永远等
Hook 错误静默 → 调试困难

原则：Hook = 快速 + 幂等 + 低风险。每个 Hook 应该在 3 秒内完成。重活交给 CI。

Q8: 对比各工具的 Agent 模式

答案：

维度	Cursor Composer	Copilot Agent	Claude Code	Windsurf Cascade
交互	IDE 面板	VS Code Chat	终端 CLI	IDE 面板
上下文窗口	1M（Gemini 3）	标准	200K/1M	标准
文件操作	多文件	多文件	最强	多文件
终端命令	需确认	需确认	原生	需确认
Subagents	✅	有限	完整	Cascade
Plan Mode	✅	有限	原生	有限
Sandbox	有限	❌	worktree 内建	有限
后台运行	Background Agent	❌	headless	❌

Claude Code 的独特优势：CLI 原生 + worktree 沙箱 + 完整 git 集成 + headless 可进 CI/CD。对大型重构和团队基建场景最强。

Cursor 的优势：IDE 体验最好、Composer 多文件可视化、Background Agent 后台任务友好。日常编码最顺手。

推荐组合：大多数团队用 Cursor + Claude Code 双剑合璧，共用 .claude/ 配置。

Q9: 什么时候用 Inline Edit / Chat / Composer / CLI Agent？

答案：

核心原则：任务粒度匹配交互重量。

任务	推荐	原因
补一行代码	Tab 补全	最轻量，不打断心流
改当前函数	Inline Edit `Cmd+K`	就地修改
讨论方案 / 看代码	Chat `Cmd+L`	对话式探索
多文件新功能	Composer/Agent `Cmd+I`	跨文件协调
大型重构 / 跨模块	CLI Agent `claude`	整仓库理解 + 终端操作
并行多任务	多 worktree + 多 CLI	3 倍产出

经验法则：

连续 3 次手动 Cmd+K → 升级到 Composer
连续 10 次 Composer → 升级到 CLI
多个可并行任务 → 开多 worktree

Q10: 如何度量 AI 编码工具的 ROI？

答案：

从效率 / 质量 / 成本三维度建立指标体系：

效率指标（易量化）：

Feature 平均交付时间（对比基线，目标降 30%+）
PR 合并周期
Sprint Velocity 提升比例

质量指标（防止"为快牺牲质量"）：

Bug 密度（bugs / KLOC）不应增加
生产 P0/P1 事件数
测试覆盖率

成本指标：

Gateway 总花费 / 月
Prompt Cache 命中率（目标 > 50%）
按员工/团队/模型分布

ROI 公式：

ROI = (效率提升等价人力 + 质量提升节省 + 新人 onboarding 加速) / AI 总成本

典型 50 人团队年度 ROI：

基建成本：60 万（2 人 3 月）
模型费：45 万/年
效率提升：540 万/年（30% × 50 人 × 30K × 12）
ROI ≈ 6.8x

关键工具：Gateway（如 LiteLLM）的 Postgres 日志 + Metabase。Day 1 就要接入度量，否则半年后拿不出数据说服老板。

Q11: 代码库索引在 AI IDE 中怎么工作？@codebase 的陷阱是什么？

答案：

代码库索引原理：

索引构建：项目文件拆分为片段（函数/类/模块），生成 embedding 存入向量库
检索：用户问题转为 embedding，搜索最相似片段
注入：相关片段作为上下文给模型

各工具实现：

Cursor：本地嵌入索引，保存时增量更新
Copilot：远程索引
Claude Code：运行时动态分析（Grep/Glob，不预建索引）

@codebase 的陷阱（2026 年的新共识）：

信噪比低：塞 20 个文件只有 2 个相关，其余 18 个是噪音
撑爆上下文：大型项目单次检索可能 50K+ tokens
Lost in the Middle：越塞越多，关键文件被忽略概率越高
成本高：每次请求都重新检索，每次付全额 token

更好做法：

用 Grep 精确定位（grep -rn "关键词"）
手动 @mention 3-5 个关键文件
用 Subagent 做初筛：让子 Agent 扫整库，返回"最相关的文件路径清单"，主 Agent 再选择性加载

大型项目这个差异能带来 2-5 倍的效率和质量提升。

Q12: AI 代码审查怎么集成到 CI/CD？

答案：

三层审查体系：

第 1 层：本地

PostToolUse Hook 自动 lint/tsc（AI 改完立即反馈）
pre-commit Hook 调用 Claude Code headless 做 MUST_FIX 级别快速检查（< 30s）

第 2 层：PR

claude-code-action（推荐）—— Anthropic 官方，自动读 PR diff + 仓库上下文，直接发 inline comment
CodeRabbit—— SaaS 服务，零配置
自建：GitHub Actions 调 Claude API，自定义审查规则

第 3 层：持续

每晚全量跑 security-reviewer Subagent
每周 dep-auditor 扫依赖漏洞

最佳实践：

分层审查：不同文件类型不同规则（API 重安全、组件重性能、DB 重 N+1）
不阻塞合并：AI 审查作为参考，避免误报阻碍开发
支持追问：开发者可在 PR 中 @claude 追问（claude-code-action 支持）
成本控制：只审改动文件，不全量扫

# 最小配置
- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Q13: 如何让 AI 理解整个项目的上下文？

答案：

6 个层次，从简单到高级：

当前文件（最基本）：AI 默认看到你在编辑的文件
Rules/AGENTS.md：项目常识、技术栈、禁忌——投入产出比最高
@mention 精准引用：手动指定 3-5 个关键文件
代码库索引：慎用 @codebase / @workspace（见 Q11）
MCP 连接：MCP Server 连数据库 Schema、API 文档、Jira、Sentry、内部知识库
Memory + Skills：跨会话持久化 + 按需加载的专业能力包

实用建议：

项目 Day 1 就配好 Rules/AGENTS.md，这是投入产出比最高的动作
复杂任务让 AI 先"读架构"再做：先看 @src/app 的目录结构和 @prisma/schema.prisma，再开始实现
不要一次 @mention 太多文件，精准 3-5 个效果最好
用 SessionStart Hook 动态注入项目状态（Git 分支、未完成任务、最近错误）

更多理论见 Context Engineering。

Q14: 大型重构应该怎么用 AI？

答案：

3 个关键动作：

1. 必须用 worktree 沙箱

git worktree add ../proj-refactor-xyz agent/refactor-xyz
cd ../proj-refactor-xyz
claude

为什么：大型重构常常方向错了要整个丢弃，worktree 里可以 git worktree remove 一键清理，主工作区 0 污染。

2. 必须先 Plan Mode

> /plan
> 把全局 Zustand store 拆分为按模块隔离的多个 store

AI 会只读探索，出 N 步迁移计划。你审核计划——这一步能避免 90% 的返工。只有批准后才切到执行模式。

3. 分阶段执行 + 每阶段 commit

每完成一个阶段就 git commit——这样 AI 误操作时 git reset 能回到任意中间点。不要等全部改完再一次性 commit。

配合工具：

Claude Code 最适合大型重构（CLI + git 集成最好）
Opus 4.7 + 1M 上下文 处理长任务最稳定
Compaction 在阶段切换时主动触发，保持上下文清爽

Q15: AI 编程工具有哪些安全风险？如何防范？

答案：

5 大风险：

代码泄露：代码被发到第三方服务器，可能用于训练
- 防：用企业版（承诺不训练）、Gateway 代理、审查数据政策
密钥泄露：AI 索引 .env、密钥被塞进上下文
- 防：.cursorignore / .claudeignore + Gateway DLP 扫描
AI 生成漏洞：XSS / SQL 注入 / 不安全加密
- 防：security-reviewer Subagent 自动审查、Rules 中写安全约束、CI 集成 SAST
供应链攻击：AI 建议有漏洞的包
- 防：dep-auditor Subagent、npm audit CI、lockfile
Agent 操作风险：YOLO 模式误删文件
- 防：worktree/docker 沙箱、PreToolUse Hook 黑名单

企业级防线：

数据分级（Tier 1-4）：不同密级用不同模型/部署
Gateway + DLP：员工不直接持 API Key
审计日志：所有请求归档，合规可查
SSO/SAML：员工入离职自动开通/吊销

详见 AI 研发基建 - 安全和 AI 应用安全。

Q16: 你如何在团队中推广 AI 编码工具？

答案：

渐进式 4 阶段（6 个月）：

阶段 1：MVP（月 1）

2 人搭 Gateway（LiteLLM + Postgres，1 天搞定）
核心成员 5 人试点
写第一版 AGENTS.md
上线 3 个核心 Skill（api-route / component-builder / form-builder）

阶段 2：扩大（月 2-3）

试点扩到 50 人
接 Jira MCP / GitHub MCP
补齐 Slash Commands 标准库（/new-feature / /review-pr 等）
启动 Subagent（security-reviewer / test-writer）

阶段 3：自动化（月 4-5）

Hooks 自动化（PostToolUse lint、PreToolUse 拦截）
CI 集成 claude-code-action
可观测性看板（Metabase）
发布使用规范

阶段 4：全员（月 6+）

全团队推广
月度效能月报
新人 Day 1 培训流程固化

成功关键：

Day 1 有 Gateway：避免裸发订阅
数据驱动：Day 1 接度量看板
先试点再推广：5 人跑通再上 50 人
纳入 Git：所有资产（Skills/Subagents/Slash Commands）团队共享
不强制统一 IDE：工具自由，规范统一

详见 AI 研发基建。

Q17: 如何避免过度依赖 AI 导致技术能力下降？

答案：

这是真问题。AI 是放大器——放大能力强的人，也会让能力弱的人更弱。

6 个保持成长的动作：

理解再使用：AI 生成的代码必须理解原理再 commit，不理解就让 AI 解释
刻意练习：算法题、底层原理、系统设计仍要自己练——面试时你不能说"AI 写的"
重心转移：从"写代码"转向"审查代码" 和 "设计架构"。读代码比写代码更值钱
架构思维：AI 擅长实现细节，架构设计、技术选型、权衡取舍仍需深厚技术功底
保持好奇心：新框架/特性先自己读官方文档理解，再用 AI 加速实践
定期脱离 AI：每周花 1-2 小时不借助 AI 写代码，保持手感

核心观点：

AI 是"自行车"不是"轮椅"——它让你更快到达目的地，但你必须自己有骑车的能力。

2026 年最值钱的工程师不是写代码最快的，而是判断力最强的——知道该做什么、为什么做、怎么做最优。这些能力 AI 替代不了。

Q18: 谈谈你对 AI 辅助开发未来趋势的理解

答案：

2026 年已经落地的趋势：

Skills > Prompts：团队资产化，不再是个人 Prompt
Subagents 常态化：每个团队都有标准 Subagent 清单
MCP 标准化：企业内部 MCP Server 爆发式增长
Hooks 自动化：从"AI 生成 + 人工检查" 升级为 "Hook 自动 + AI 修复"
Plan Mode 常态：大型改动必须先出计划
并行 Agent：多 worktree 同时跑是日常

2027-2028 可预见的趋势：

多 Agent 协作成熟：设计 Agent + 编码 Agent + 审查 Agent + 测试 Agent 的流水线
自主编码 Agent 深入：类似 Devin 的云端 Agent 承担 "Issue → PR" 的完整流程
A2A 协议（Agent-to-Agent）：跨团队 / 跨公司 Agent 互通
本地小模型推理：WebGPU + 小模型端侧完成 80% 的 Tab 补全，隐私 + 低延迟
AI 原生语言：新编程语言原生集成 AI（类似 Mojo 但更极端）
人机协作新范式：工程师角色从"实施者"彻底变为"意图描述者 + 质量守门员 + 架构决策者"

对前端工程师的启示：

AI 工具是必备技能，不是加分项
重点提升：需求分析、架构设计、代码审查、系统思维——这些 AI 最难替代
学会写好 Rules / Skills / Prompts——这是用好 AI 的核心技能
保持对 AI 输出的判断力——不要成为"AI 复制粘贴工程师"

Q19: AI 辅助开发有哪些反模式？

答案：

2026 年最常见的 10 个反模式：

反模式	后果	正解
让 AI 一次写完所有代码	错误累积、定位难	分步迭代，每步 verify
`@codebase` 乱塞上下文	信噪比低、质量差	精确 `@file` + Grep
不配 Rules/Skills 直接用	每次重教 AI	前期半天配好事半功倍
Skill 写得像论文	AI 触发不准	< 500 字，description 用原话
Hook 里跑全量 test	Agent 卡死	Hook 只做快速操作
YOLO 在主工作区	改错无法恢复	配 worktree 沙箱
完全信任 AI 输出不审查	线上 Bug 暴涨	关键代码人工终审
每人独立账号不要 Gateway	成本失控	Day 1 上 Gateway
追求完美 IDE 统一	老用户反感	IDE 自由，规范统一
Skill 放个人 `~/.claude`	离职带走	全部纳入 Git

最根本的反模式：把 AI 当作个人工具用而不是团队基建。解决方法见 AI 研发基建。

问题​

答案​

一、2026 年 AI 辅助开发的新范式​

二、工具选型（2026 年主流 IDE / CLI）​

2.1 工具地图​

2.2 主流工具能力对比​

2.3 场景匹配矩阵​

三、模型选型与路由（2026 年）​

3.1 2026 模型地图​

3.2 模型路由策略​

3.3 通过 Gateway 实现模型路由​

四、团队资产五件套（核心章节）​

4.1 Rules：项目常识​

4.2 Skills：可复用技能包（重头戏）​

第 1 步：识别高频对象​

第 2 步：设计目录结构​

第 3 步：写 SKILL.md（决定触发准确性）​

第 4 步：能用脚本就不要让 AI 写​

第 5 步：验证触发准确性​

4.3 Subagents：专业子代理​

4 个黄金使用场景​

标准 Subagent 清单​

完整 Subagent 定义​

在主 Agent 中委派 Subagent​

4.4 Slash Commands：固化工作流​

4.5 Hooks：生命周期自动化​

案例 1：PostToolUse 自动 lint + tsc（最有用）​

案例 2：PreToolUse 拦截危险命令​

案例 3：SessionStart 动态注入项目状态​

案例 4：Stop Hook 自动通知​

五、工作流模式​

5.1 三种执行模式​

5.2 Sandbox + Git Worktree：并行 Agent 终极模式​

5.3 交互粒度匹配​

六、上下文管理实战​

6.1 精确 @mention 胜过 @codebase​

6.2 主动 Compact 长会话​

6.3 工具返回裁剪​

七、AI 辅助的日常任务手册​

7.1 新功能开发​

7.2 Bug 排查​

7.3 大型重构​

7.4 依赖升级​

7.5 技术调研​

八、AI 代码审查自动化​

8.1 三层审查体系​

8.2 PR 自动审查（推荐配置）​

8.3 本地 pre-commit 预审​

九、成本与效能度量​

9.1 核心指标​

9.2 Metabase 自建看板（最小方案）​

9.3 ROI 快速估算​

十、安全边界​

10.1 数据分级​

10.2 硬性红线​

10.3 .cursorignore / .claudeignore​

十一、常见反模式（避坑清单）​

十二、实用小技巧合集（以 Claude Code 为例）​

12.1 会话与上下文​

12.2 输入快捷键​

12.3 Prompt 技巧​

12.4 配置类​

12.5 工作流​

十三、面试速答与追问清单​

3 分钟速答版​

10 分钟展开版​

高频追问​

常见面试问题​

Q1: 你日常开发如何使用 AI 工具？效率提升了多少？​

Q2: 如何选择 AI 编程工具和模型？​

Q3: 如何配置 Rules 文件以最大化 AI 效果？​

Q4: Skills、Subagents、Slash Commands、Hooks 分别是什么？​

Q5: 怎么把业务代码封装成 Skill？​

Q6: Subagent 什么时候该用？什么时候不该用？​

Q7: Hooks 有哪些常见用法？有什么坑？​

Q8: 对比各工具的 Agent 模式​

Q9: 什么时候用 Inline Edit / Chat / Composer / CLI Agent？​

Q10: 如何度量 AI 编码工具的 ROI？​

Q11: 代码库索引在 AI IDE 中怎么工作？@codebase 的陷阱是什么？​

Q12: AI 代码审查怎么集成到 CI/CD？​

问题

答案