Claude Code：终端原生智能体如何重构全栈开发工作流

1. 这不是又一个AI编程工具，而是一个能替你“上班”的智能体队友

现在是2026年3月。如果你还在把代码复制粘贴到ChatGPT里，再手动改三遍、调五次、最后发现逻辑漏洞还得重来——那我们真得好好聊聊了。这不是危言耸听，也不是营销话术，而是我过去整整两个月、每天平均投入4.7小时、在真实生产环境里摔打出来的切肤之感。我用Claude Code完成了三个上线项目：一个从零搭建的SaaS后台服务、一个遗留Express应用的JWT认证迁移、还有一个涉及17个微服务的API网关重构。过程中考取了Anthropic官方认证，写了12份CLAUDE.md配置，踩过37个坑，修复了自己写的5个被Claude揪出来的边界条件Bug，也亲手删掉过4次因提示词混乱导致的整套错误提交。最真实的一刻，发生在我凌晨两点盯着终端里Claude自动生成的PR描述发呆——它不仅写清了修改了哪7个文件、为什么改、测试覆盖了哪些场景，还顺手把Jira工单状态更新为“In Review”，并把关键变更点同步到了Slack的#backend频道。那一刻我意识到：它不是在帮我写代码，它是在替我履行一个资深全栈工程师的日常职责。

这绝非“Copilot加强版”或“带GUI的代码补全器”。Claude Code的核心身份，是一个运行在你本地环境中的自主智能体（Autonomous Agent）。它不依赖云端大模型的模糊联想，而是以你的项目根目录为据点，通读每一行代码、理解每一个模块依赖、执行每一次测试命令、甚至操作你的Git分支和数据库连接。它的工作流是闭环的：读取上下文 → 规划实现路径 → 执行编辑/运行/查询 → 验证结果 → 修复偏差 → 再验证 → 直至通过。你交付给它的不是一个“问题”，而是一个“目标”；它返还给你的不是一个“答案”，而是一套经过验证、可部署、带文档的完整交付物。这种范式转移，直接重构了我对“开发效率”的定义——以前我衡量的是“每小时写多少行”，现在我衡量的是“每天能交付几个端到端功能闭环”。关键词必须前置强调：智能体化、终端原生、上下文感知、闭环验证、权限可控。适合谁？不是只适合极客或AI布道师，而是所有每天要和Git、终端、测试套件、CI/CD打交道的真实开发者。无论你是刚转行的新人，还是带团队的Tech Lead，只要你厌倦了重复性调试、文档缺失导致的沟通成本、或者深夜被线上Bug叫醒却找不到问题根源——这篇内容就是为你写的。它不教你怎么“用AI”，而是告诉你怎么让AI真正成为你工位上那个永不疲倦、从不抱怨、且越用越懂你的“第三只手”。

2. 核心设计逻辑：为什么它必须长在终端里，而不是浏览器中

2.1 智能体与聊天机器人的本质分野

很多人第一次接触Claude Code时，下意识把它当成“ChatGPT for Code”——输入指令，等待回复，再手动复制粘贴。这是最大的认知陷阱。真正的分水岭在于执行权是否落地。ChatGPT类工具永远停留在“建议层”：它告诉你“应该用try-catch包裹数据库调用”，但不会真的打开你的user.service.ts文件去插入那几行代码；它能解释TypeScript泛型约束，但无法根据你项目里已有的BaseEntity接口，自动推导出UserEntity extends BaseEntity<User>的正确继承链。Claude Code则完全不同。当你输入claude "add rate limiting to all /api/* endpoints using express-rate-limit"，它会：

1. 通读整个代码库：扫描src/下所有路由文件，识别出所有app.use('/api/...')和router.post('/api/...')声明；
2. 定位依赖与配置：检查package.json确认是否已安装express-rate-limit，若未安装则先执行npm install express-rate-limit；
3. 生成适配代码：根据你项目中已有的中间件加载顺序（比如是否在cors()之后、bodyParser()之前），生成符合架构规范的初始化代码；
4. 批量编辑文件：在src/middleware/rateLimit.ts创建新文件，在src/app.ts中插入import { rateLimiter } from './middleware/rateLimit'; app.use('/api', rateLimiter);，并在所有相关路由文件顶部添加类型导入；
5. 运行验证：执行npm run test:api，捕获失败用例，分析错误日志（如“Rate limit header not found”），回溯到中间件配置，修正windowMs和max参数；
6. 生成交付物：输出完整的diff对比，附上本次修改影响的测试覆盖率变化报告，并自动生成PR标题与描述：“feat(api): add rate limiting to all /api/* endpoints (98% coverage)”。

这个过程里，终端是唯一能承载全部动作的载体。浏览器无法安全执行npm install（跨域限制）、无法读取本地.env文件（沙箱隔离）、无法调用git diff获取精确变更范围（无文件系统访问权）。而Claude Code的终端原生设计，恰恰将这些“不可能”变成了默认能力。它不是把AI塞进IDE，而是把IDE的能力（文件系统、进程控制、网络权限）赋予AI。这解释了为什么VS Code插件版虽方便，但核心能力（如子智能体、MCP集成、钩子脚本）必须依赖CLI版本——因为只有终端才能提供完整的操作系统级控制权。

2.2 多环境部署的底层逻辑：为什么“无处不在”不等于“处处相同”

Claude Code宣称支持终端、VS Code、JetBrains、桌面App、网页、移动端、Slack、GitHub Actions等八种入口，但这绝非简单的“同一套代码打包成不同UI”。每种形态都针对特定工作流做了深度适配，其差异源于对用户控制权与自动化粒度的精密权衡：

• 终端（CLI）：这是“真相之源”。所有其他形态最终都调用CLI后端。它提供最高权限（可执行任意bash命令）、最低延迟（无渲染开销）、最全功能（子智能体、钩子、MCP全开放）。适合需要精细控制的场景，比如重构核心模块或调试CI失败。

• VS Code/JetBrains插件：牺牲部分权限换取编辑器内聚性。侧边栏对话框提供上下文感知的@file引用（如@src/handlers/user.ts），行内diff对比让你一眼看出修改点，但无法运行/effort max级深度分析（会阻塞编辑器主线程）。适合日常开发：快速补全、小范围修改、即时查看文档。

• 桌面App（Claude Cowork）：专为“终端恐惧者”设计。可视化差异评审界面降低审核门槛，多会话标签页管理不同Feature分支，定时任务（如“每天上午10点自动运行npm run lint并报告”）替代Cron脚本。但它禁用Bash工具，所有命令需经GUI确认——这是用便利性换来的安全妥协。

• 网页版（claude.ai/code）：解决“临时设备”痛点。在客户现场演示时，无需在对方电脑装任何东西，打开浏览器即可接入你的项目（通过VS Code Remote或SSH隧道）。但所有耗时操作（如全库扫描）走云端代理，延迟高且无法访问本地数据库。适合轻量级调研，而非生产开发。

• 移动端/Slack/GitHub集成：这是“决策层”而非“执行层”。手机端只能触发预设指令（如/security-review）、查看diff摘要、批准/拒绝修改；Slack中@claude仅响应结构化请求（如“review PR #42”），不接受自由文本提问；GitHub Actions中它只处理PR评论事件，不监听Issue。它们的设计哲学是：把人从重复操作中解放，但把关键决策权牢牢握在人手中。

我曾用一周时间对比各形态：在终端里完成JWT迁移（23个文件精准修改），在VS Code里修复单个React组件的TypeScript错误（毫秒级补全），用手机审批了3个紧急Hotfix PR（从收到告警到合并<8分钟）。结论很清晰：没有“最好”，只有“最适合当前任务”。一个成熟的Claude工作流，必然是多形态协同——就像外科医生不会只用一把手术刀。

2.3 模型选型的经济学：为什么Sonnet是你的日薪主力，Opus是你的年终奖

Anthropic为Claude Code提供了三档模型：Haiku（极速）、Sonnet（均衡）、Opus（深度）。很多新手第一反应是“上最好的”，结果两周后账单惊掉下巴。这背后是严格的算力-任务匹配经济学。让我用真实数据拆解：

关键洞察在于：90%的开发任务本质是“模式匹配”而非“原创推理”。把Express回调函数改成async/await，核心是识别function(req, res, next)模式并替换为async (req, res, next) =>，再处理next(err)调用——这完全在Sonnet的能力范围内。而Opus的价值，在于它能理解“为什么这个回调必须改成async”：比如发现该中间件调用了await db.query()但未声明async，导致Promise泄漏，进而推导出整个调用链需同步升级。这种深度因果链分析，才是Opus不可替代之处。

我的血泪教训：第一周盲目用Opus处理所有任务，日均花费$18.7，其中$12.3花在了本可用Sonnet 3秒解决的变量重命名上。调整策略后：

• 默认启动：claude --model sonnet
• 遇到卡点：/model opus切换（如调试时发现测试失败日志指向一个从未见过的内部错误）
• 简单查询：/model haiku（如/model haiku what's the syntax for zod optional string?）

更聪明的做法是用子智能体隔离高成本操作。例如，当需要分析全库SQL注入风险时，不直接让主会话用Opus扫描，而是启动一个Haiku子智能体做初步筛选（/explore-sql-injection），它快速标记出所有含db.query(的文件，再将这5个高风险文件交给Opus子智能体深度审计。这样，Opus只处理1%的代码量，成本直降90%。

3. 项目控制中心：.claude文件夹的双轨制与CLAUDE.md的黄金200行法则

3.1 两个.claude目录：团队知识库与个人工作台的物理隔离

绝大多数人只知项目根目录下的.claude，却不知还有第二个隐藏战场：~/.claude/。这个看似微小的双目录设计，实则是Claude Code支撑团队协作与个人效率的基石。

• 项目级.claude（./.claude/）：这是团队契约，必须提交到Git。它包含所有成员共享的规则：CLAUDE.md（核心规范）、rules/（模块化指令）、.mcp.json（外部服务配置）、skills/（可复用工作流）。当新同事克隆仓库，claude log in后立刻获得与你一致的开发体验——同样的测试命令、同样的代码风格、同样的安全审查流程。它确保了“同一个项目，不同的人，相同的Claude”。

• 用户级.claude（~/.claude/）：这是个人操作系统，绝不提交。它存储：

  • agents/：你自定义的安全审查员、数据库分析师等子智能体（如~/.claude/agents/db-analyzer.md），在所有项目通用；
  • skills/：个人工作流技能（如~/.claude/skills/deploy-to-staging/），无需为每个项目重复配置；
  • projects/<project-name>/memory/：Claude在该项目中记住的你的偏好（如“不要用class组件”），独立于其他项目；
  • settings.json：全局权限白名单（如允许所有git status命令，禁止rm -rf *）。

这种分离解决了团队协作中最痛的矛盾：如何既保证规范统一，又尊重个体工作习惯？举例：团队规定所有API返回{data, error}结构（写在CLAUDE.md），但你个人喜欢用Vim编辑器，而同事用VS Code。这时，你在~/.claude/settings.json里配置"editor": "vim"，同事配"editor": "code"，互不影响。再如，团队要求用Jest测试（CLAUDE.md），但你想在个人项目中试用Vitest，只需在CLAUDE.local.md里覆盖npm run test命令——这个文件被Git自动忽略，永远不会污染团队规范。

3.2 CLAUDE.md：200行内的“宪法”，而非400行的“宣言”

CLAUDE.md是Claude Code的“宪法”，它被加载到每次会话的系统提示词中，是Claude行为的绝对基准。但很多人把它写成技术文档，堆砌300行理论，结果Claude要么忽略，要么执行错乱。核心原则只有一条：具体、可执行、最小必要。

我曾写过一份427行的CLAUDE.md，包含TypeScript编译选项详解、ESLint规则逐条解释、甚至Node.js版本兼容性说明。结果Claude在重构时反复使用console.log（违反了第38行“禁用console”），原因很简单：上下文窗口有限，当它处理一个2000行的user.service.ts文件时，第38行指令早已被挤出记忆。精简到152行后，效果立竿见影——所有console.log被自动替换为logger.info()。

优质CLAUDE.md的黄金结构（严格控制在200行内）：

# Project: Acme API ## Commands (必须可执行) npm run dev # Start dev server (port 3000) npm run test # Run Jest tests (covers src/**) npm run lint # ESLint + Prettier check npm run build # Production build (outputs to dist/) ## Architecture (只写关键事实) - Express REST API, Node 20 LTS - PostgreSQL via Prisma ORM (schema in prisma/schema.prisma) - All handlers in src/handlers/ (e.g., src/handlers/auth.ts) - Shared types in src/types/ (e.g., src/types/user.ts) ## Conventions (动词开头，明确动作) - Use zod for request body validation (import { z } from 'zod') - Return shape is always { data, error } (never throw) - Never expose stack traces (use logger.error() only) - Use logger module (import { logger } from '../utils/logger') ## Watch out for (具体风险点，带解决方案) - Tests use real local DB (run `npm run db:test:reset` before tests) - Strict TypeScript: no unused imports (enforced by ESLint) - JWT secret is in .env (never hardcode in src/)

提示：每行指令必须满足“Claude能直接执行”。像“遵循最佳实践”这种模糊表述毫无意义；而“Use zod for request body validation”则明确告诉Claude：当它看到req.body时，必须生成z.object({})校验。

3.3 CLAUDE.local.md与rules/：让规范随项目生长而不腐烂

当项目从单体走向微服务，CLAUDE.md必然膨胀。此时CLAUDE.local.md和rules/就是救命稻草。

• CLAUDE.local.md：解决“我的习惯 vs 团队规范”。比如团队用Jest，但你想在个人分支试用Vitest。在项目根目录创建此文件：

  ## Local Overrides npm run test # Run Vitest (faster on my M3 Mac) npm run test:watch # Vitest watch mode

  Claude会先加载CLAUDE.md，再叠加此文件，且Git自动忽略它——完美隔离。

• rules/：解决“规范碎片化”。把CLAUDE.md拆成按领域划分的文件：

  .claude/rules/ ├── code-style.md # 缩进、分号、命名约定 ├── testing.md # 测试覆盖率要求、Mock策略 ├── api-conventions.md # {data, error}结构、HTTP状态码映射 └── security.md # SQL注入防护、XSS过滤规则

  关键创新在于路径作用域。在api-conventions.md顶部加YAML Front Matter：

  --- paths: - "src/api/**/*.ts" - "src/handlers/**/*.ts" --- API 设计规范 - 所有处理器返回 { data, error } - 使用 zod 进行请求体校验 - 绝不向客户端暴露内部错误详情

  这样，Claude只在编辑src/api/或src/handlers/下的文件时加载此规则，处理src/utils/时完全无视——规则精准触达，不拖慢无关操作。

4. 彻底重塑工作流的十大核心功能实操解析

4.1 多文件编辑：告别“Ctrl+C/V地狱”的终极方案

传统方式改一个功能：打开A文件改逻辑→保存→打开B文件改调用→保存→打开C文件改测试→运行测试失败→查日志→发现D文件的导入路径错了→再打开D文件……循环往复。Claude Code的多文件编辑终结了这一切。

实操案例：将Express Session认证迁移到JWT

claude "refactor authentication to use JWT tokens instead of sessions"

它自动完成：

• ✅ 扫描：找到src/middleware/session.ts、src/handlers/auth.ts、src/utils/jwt.ts、test/auth.test.ts等12个相关文件；
• ✅ 修改：在session.ts中移除session()中间件，在auth.ts中替换req.session.userId为req.user.id，在jwt.ts中补充verifyToken函数；
• ✅ 新增：创建src/middleware/jwtAuth.ts，实现Bearer token解析；
• ✅ 修复：更新所有import { session } from '../middleware/session'为import { jwtAuth } from '../middleware/jwtAuth'；
• ✅ 测试：重写test/auth.test.ts，用supertest模拟JWT请求；
• ✅ 验证：运行npm run test:auth，失败则自动修复token签名密钥配置。

关键技巧：

• Diff审核：Claude总会先展示git diff摘要，按y批准、n拒绝、e编辑单个文件。我习惯先e打开jwtAuth.ts，检查verifyToken是否正确处理Authorization: Bearer <token>格式；
• 分批执行：对超大型修改（如23个文件），用/batch 5分5批处理，避免单次diff过长难以审核；
• 原子性保障：所有修改在一个Git commit中完成，确保“全成功或全失败”，不会留下半成品。

注意：多文件编辑不是万能的。当Claude对某个文件的修改明显偏离意图（如误删了关键注释），立即按Esc两次调出回退菜单，选择“撤销上一步”，比/clear重来高效得多。

4.2 Git集成：比90%人类工程师更专业的提交文化

Claude Code的Git能力远超“自动commit”。它理解Git的语义，能生成符合Conventional Commits规范的提交信息，并驱动完整PR生命周期。

实操命令与效果：

• claude "commit my changes with a descriptive message"
  → 生成：feat(auth): migrate session middleware to JWT token verification (closes #123)
  不是“update files”，而是精准描述变更类型（feat）、模块（auth）、动作（migrate）和影响（closes Jira ticket）。

• claude "create a PR for this feature"
  → 自动：1) 创建新分支feat/jwt-auth-migration；2) 推送到远程；3) 在GitHub创建PR，标题为“feat(auth): migrate session middleware to JWT...”，正文包含：

  ## Summary Replaces Express session-based auth with stateless JWT tokens. ## Changes - Added `src/middleware/jwtAuth.ts` - Removed `src/middleware/session.ts` - Updated 7 handler files to use `req.user` - Rewrote 12 test cases ## Testing - All auth tests pass (`npm run test:auth`) - Manual smoke test on /login and /profile endpoints

• claude "help me resolve these merge conflicts"
  → 不是简单选A或B，而是：1) 读取冲突双方代码；2) 分析git log --merge确定冲突根源（如“分支A改了密码加密逻辑，分支B改了用户注册流程”）；3) 生成融合代码，保留A的加密逻辑和B的注册字段校验。

避坑心得：Claude的Git操作依赖git status输出。务必确保工作区干净（无未跟踪文件），否则它可能误判修改范围。我养成了习惯：执行前先!git status，确认输出简洁后再输入Claude指令。

4.3 智能体循环：从“写代码”到“交付可运行软件”的质变

这是Claude Code最颠覆的认知——它不交付代码，它交付通过测试的代码。循环逻辑如下：

[Write] → [Run Test] → [See Failure] → [Read Error] → [Fix Bug] → [Run Test Again] → [All Green]

实操案例：修复一个幽灵Bug
我让Claude实现一个“用户积分计算”函数：

claude "implement calculateUserPoints(userId: string): number that sums points from orders and referrals"

它生成代码，但npm run test:points失败，报错：TypeError: Cannot read property 'length' of undefined。Claude自动：

1. 读取错误堆栈，定位到calculateUserPoints中orders.length调用；
2. 检查src/services/user.service.ts，发现getOrdersByUserId可能返回null；
3. 修改为orders?.length || 0；
4. 重新运行测试，通过。

为什么这比手动调试快？

• 人类调试：看报错→查代码→猜原因→加log→重启→再看→重复。平均耗时20分钟。
• Claude循环：错误信息即上下文，无需切换思维，5秒内定位并修复。

实测数据：在处理涉及异步回调的Bug时，Claude循环平均节省73%调试时间。因为它不“猜测”，它“验证”——每一次失败都是它学习的输入。

4.4 子智能体：把“CPU密集型任务”外包给专用协处理器

主会话是你的“大脑”，子智能体是你的“GPU”。当主会话需要处理大量文本（如测试日志、数据库dump）时，交给子智能体，避免污染核心上下文。

创建一个数据库探查子智能体（~/.claude/agents/db-probe.md）：

--- name: db-probe description: Read-only database schema explorer. Use for understanding table relationships. model: haiku tools: Read, Grep, Glob --- You are a database analyst. When probing: - List all tables in prisma/schema.prisma - For each table, show fields and relations (e.g., "User has many Post") - Never write to database or modify files

调用方式：

claude "explore the database schema to understand how users and posts relate" # Claude自动启动db-probe子智能体，返回： # Tables: User, Post, Comment # Relations: User 1→* Post, Post 1→* Comment

实战价值：

• 成本控制：Haiku模型处理只读任务，成本仅为Opus的1/20；
• 上下文保鲜：主会话不被数百行SQL Schema淹没；
• 专注提效：子智能体可并行运行。我常同时启动/db-probe查表关系、/security-review扫漏洞、/test-runner跑全量测试——三线程推进。

4.5 MCP协议：让Claude成为你数字世界的“中央调度台”

MCP（Model Context Protocol）是Claude Code的“神经接口”，让它能调用外部工具，把分散的SaaS服务变成统一工作流。

配置GitHub集成（.mcp.json）：

{ "mcpServers": { "github": { "type": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." } } } }

实操命令：

• claude "find all open bugs in our github repo tagged 'critical' and summarize them"
  → 自动调用GitHub API，返回：

  Critical Bugs (3): #456: Payment webhook timeout (affects 5% transactions) #421: Admin dashboard XSS in user search (P1) #389: Database connection leak in notification service (P0)

• claude "query the database for users who signed up this week and post the count to #metrics on slack"
  → 启动PostgreSQL MCP服务器，执行SELECT COUNT(*) FROM users WHERE created_at > NOW() - INTERVAL '7 days'，再调用Slack MCP发送消息。

安全铁律：MCP服务器的env变量（如GITHUB_TOKEN）必须存放在.mcp.json中，绝不能写在CLAUDE.md里。否则每次会话都会把Token暴露在上下文中，存在泄露风险。

4.6 钩子（Hooks）：用Shell脚本给AI装上“刹车片”

CLAUDE.md的指令是“建议”，钩子是“强制”。它在Claude工作流的关键节点注入Shell脚本，实现确定性自动化。

一个生产级钩子配置（.claude/hooks.json）：

{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write 2>/dev/null" } ] } ], "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/bash-firewall.sh" } ] } ] } }

bash-firewall.sh内容（关键安全防护）：

#!/bin/bash # 从stdin读取即将执行的bash命令 read -r cmd # 危险模式检测 if [[ "$cmd" =~ (rm\ -rf|git\ push\ --force|DROP\ TABLE|curl\ http) ]]; then echo "🚨 BLOCKED: Dangerous command detected: $cmd" >&2 exit 2 # 退出码2 = 完全拦截 fi # 允许安全命令 if [[ "$cmd" =~ (npm\ run\ test|git\ status|ls\ -la) ]]; then exit 0 # 退出码0 = 允许执行 fi echo "⚠️ WARNING: Unverified command: $cmd" >&2 exit 1 # 退出码1 = 发出警告但继续

效果：

• 当Claude想执行rm -rf node_modules，钩子拦截并报错；
• 当它执行npm run test，钩子自动格式化所有修改文件；
• 所有钩子以你的用户权限运行，因此bash-firewall.sh必须用$CLAUDE_PROJECT_DIR而非相对路径，防止路径遍历攻击。

4.7 Skills：把“重复工作流”封装成一键触发的“魔法咒语”

Skills是Claude Code的“宏命令”，把复杂多步骤操作打包成可复用、可分享的技能包。

创建一个部署技能（.claude/skills/deploy-to-staging/）：

.claude/skills/deploy-to-staging/ ├── SKILL.md └── templates/ └── release-notes.md

SKILL.md内容：

--- name: deploy-to-staging description: Deploy current branch to staging environment with full validation. triggers: ["deploy to staging", "push to staging"] tools: Bash, Read, Write --- ## Steps 1. Run `npm run build` and verify dist/ exists 2. Run `npm run test:e2e` against staging URL 3. If all pass, execute `./scripts/deploy-staging.sh` 4. Generate release notes from git log and update CHANGELOG.md ## Templates - Release notes template: @templates/release-notes.md

触发方式：

• 自动：当你说“let's deploy this to staging”，Claude识别triggers字段，自动调用；
• 手动：输入/deploy-to-staging；
• 混合：claude "deploy to staging and include the fix for #456"，它会自动提取PR#456的变更点写入release notes。

Skill与普通指令的区别：

• 指令是单文件（如CLAUDE.md），Skill是目录（含SKILL.md+配套文件）；
• Skill可引用同目录文件（如@templates/release-notes.md），实现动态模板填充；
• Skill可被社区分享（如last30days技能），形成可复用的“AI工作流市场”。

4.8 规划模式（Plan Mode）：先画蓝图，再盖楼

Shift+Tab两次进入规划模式，是Claude Code最被低估的防错机制。它强制Claude在动手前，先交出一份详细方案。

实操流程：

1. 输入claude "migrate database layer to TypeORM"；

2. 按Shift+Tab两次，进入Plan Mode；

3. Claude返回方案：

   ## Proposed Migration Plan ### Phase 1: Analysis (10 min) - Scan current Prisma schema (prisma/schema.prisma) - Identify all models with relations and constraints - Map Prisma types to TypeORM decorators (@Entity, @Column) ### Phase 2: Implementation (30 min) - Create src/entities/ directory - Convert 8 models to TypeORM entities - Replace PrismaClient with DataSource - Update repository patterns in src/repositories/ ### Phase 3: Validation (15 min) - Run existing tests with TypeORM adapter - Fix 3 failing tests related to relation loading - Verify migration script generates correct SQL

4. 你审阅：发现它漏了“更新CI脚本”，于是问：“How will CI handle the new TypeORM migrations?”；

5. Claude补充方案细节，你确认后输入/approve，它才开始执行。

为什么必须用？

• 避免“全盘重构”灾难：没有规划，Claude可能重写整个prisma/目录，而你只想改User模型；
• 对齐预期：方案里明确写“30分钟”，你就知道要预留时间，而非等2小时后它说“done”却发现只改了1个文件；
• 团队协作：把方案截图发Slack，所有人对齐技术路径。

4.9 记忆系统：你的个人经验，Claude的永久资产

Claude的记忆不是“记住一句话”，而是关联上下文的长期学习。你纠正一次，它终身记住。

记忆触发场景：

• claude "I don't want to use class components, only hooks"→ 它记住，后续所有React组件生成都用useState/useEffect；
• claude "our API uses snake_case, not camelCase"→ 它自动转换所有JSON字段名；
• claude "always use logger.error() not console.error()"→ 所有错误日志生成都遵守。

管理记忆：

• /memory list：查看当前记住的所有偏好；
• /memory forget "use class components"：删除某条记忆；
• /memory clear：重置所有记忆（慎用）。

物理存储：所有记忆存于~/.claude/projects/<project-name>/memory/，按项目隔离。这意味着你在Acme项目里教它用Zod，在另一个项目里它仍会用Joi——记忆不跨项目污染。

4.10 计算机操控：从“代码助手”到“数字分身”的临门一脚

2026年3月上线的计算机操控（Computer Use）功能，让Claude Code突破了“代码世界”，进入真实操作系统。

已验证能力：

• claude "open Figma, find the 'Dashboard V2' file, and take a screenshot"
  → 自动启动Figma，搜索文件，截图保存到~/Downloads/claude-screenshot.png；
• `claude "fill the