HappierCoder 技术博客

之前一直在用Claude的网页版，直到最近发现了Claude Code——一个命令行版本的Claude。用了两周之后，我不得不说：这东西改变了我写代码的方式。

安装与登录

安装很简单，npm一键搞定：

npm install -g @anthropic-ai/claude-code

Windows用户注意：用PowerShell，不要用cmd，否则会有编码问题。

安装完成后，输入claude就能启动。第一次使用需要登录，输入/login，会打开浏览器让你授权。

三种执行模式：确认、默认确认、规划模式

这是Claude Code最核心的设计。它有三种处理代码的方式：

• 确认模式：每一句代码都要你同意才执行，适合新手或重要项目
• 默认确认模式：自动执行，不需要一句句确认，适合快速迭代
• 规划模式：只思考不写代码，适合前期设计

切换方式很简单：Shift + Tab。

我的建议：刚开始用确认模式，熟悉之后用默认确认模式提升效率，做架构设计时用规划模式。

一个真实的工作流

假设我要创建一个新项目。首先启动Claude Code：

claude
> 我想创建一个React+TypeScript项目，带ESLint配置

Claude会自动执行create-react-app或vite命令，安装依赖，配置ESLint。整个过程可能10分钟，你自己做可能要半小时。

如果你想让Claude"放飞自我"，一键同意所有操作：

claude --dangerously-skip-permission

⚠️ 但要小心，这个模式下Claude可能会做出一些你不预期的操作。

回滚功能：按两下ESC

Claude Code有个很贴心的功能：回滚。

如果Claude改坏了代码，你可以输入/rewind或者按两下ESC，进入回滚界面。它会列出所有的修改记录，你可以选择回滚到任意一个状态。

注意：回滚只会回滚写入的代码，不会回滚终端命令生成的文件。比如npm install创建的node_modules，回滚是删不掉的。

MCP集成：让Claude能"看见"设计稿

这是我最近在研究的高级功能。MCP（Model Context Protocol）可以让Claude Code连接外部工具。

比如我们想用Figma的设计稿生成前端代码，可以这样配置：

claude mcp add --transport http figma https://mcp.figma.com/mcp

然后输入/mcp就可以选择使用Figma工具了。

上下文管理：别让Token爆炸

聊多了之后，上下文会越来越长，Token消耗也会爆炸。这时候可以用：

• /compact - 总结前面的对话，压缩上下文
• /clear - 清空所有上下文，从头开始

我通常会这样：一个功能开发完成后，执行/compact，让Claude记住核心内容，但不要重复的细节。

CLAUDE.md：让Claude记住你的规范

如果你想让Claude每次都知道你的代码风格、项目规范，可以创建一个CLAUDE.md文件：

# 项目规范
- 使用函数式组件，不要用class组件
- 所有变量用const，避免let
- 样式使用Tailwind CSS
- 测试用Jest + React Testing Library

输入/init可以自动生成这个文件，然后你可以根据项目需求修改。

Hooks：自动化你的工作流

Hooks是一个高级功能，允许你在Claude执行命令前后自动运行一段脚本。

比如我想让Claude每次修改代码后自动格式化：

输入 /hooks
选择 "Create new hook"
选择触发时机：Write|Edit
输入命令：jq -r '.tool_input.file_path' | xargs prettier --write

这样每次Claude创建或编辑文件后，都会自动运行prettier格式化代码。

Subagent：让Claude变成项目经理

这是Claude Code最近推出的功能，也是我最喜欢的。Subagent就像是给Claude请的临时工，每个临时工只干一件事。

比如代码审查这种事，其实不需要在主对话里做。你可以创建一个"代码审查专员"Subagent：

输入 /agents
选择 "Create new agent"
添加描述：审查代码质量、发现潜在Bug、提供优化建议
选择工具权限：只读（防止误修改代码）
选择模型：可以用Haiku（快且便宜）

之后当你需要代码审查时，Claude会自动调用这个Subagent。关键是：Subagent有独立的上下文，不会污染主对话。

踩过的坑

• 危险命令会被拦截：像rm -rf、chmod这种，Claude会提示这是危险操作。如果确定要执行，需要用bash模式。
• 后台任务要手动关：如果你启动了npm run dev，记得用/task查看，然后按k关闭。
• 对话可以恢复：如果你不小心关掉了Claude，下次用claude -c可以恢复到上一个对话。

总结

Claude Code不是一个简单的聊天工具，而是一个真正的AI编程伙伴。它理解项目结构、能执行命令、会自动保存状态。用了两周，我发现自己花在重复性工作上的时间大大减少了。

如果你也是开发者，强烈建议试试。记得从确认模式开始，熟悉之后再用高级功能。

最近我在做一个AI Agent项目，需要处理PDF文档、生成Excel报表、还要自动发布博客。每个需求单独实现都不难，但整合起来就很麻烦。直到我发现了Claude Code的Skills系统——就像找到了一把"瑞士军刀"。

Skills是什么？

简单说，Skills就是给Claude装上的"专业技能包"。你有没有发现，通用AI什么都能聊，但到了专业领域就露怯了？Skills就是为了解决这个问题。

一个Skill本质上是一个Markdown文件，包含三部分：

• 元数据：名称、描述、触发条件
• 使用说明：什么场景使用，怎么调用
• 具体内容：可以是提示词模板、代码示例、工作流程

内置Skills一览

Claude Code自带了很多有用的Skills：

实战：创建一个博客发布Skill

我想创建一个自动发布博客的Skill。首先输入：

/skills

然后选择创建新Skill。Claude会帮你生成一个模板文件，放在~/.claude/skills/目录下。

我创建的blog-publisher.md长这样：

---
name: blog-publisher
description: 自动收集技术素材、生成文章、发布到博客平台
---

# 博客发布助手

## 使用场景
当用户说"帮我写一篇关于XXX的博客"或"发布文章"时调用。

## 工作流程
1. 收集主题相关的技术素材（可通过联网搜索）
2. 生成文章大纲
3. 填充技术内容
4. 添加代码示例
5. 格式化为Markdown
6. 发布到指定平台（如博客园）

## 文章模板
请按照以下结构生成文章：
- 引言：引出主题，说明重要性
- 正文：分步骤讲解，每步配代码示例
- 总结：要点回顾，延伸思考

调用Skill的方式

有两种方式调用Skill：

方式一：自动触发

当你的对话内容匹配Skill的描述时，Claude会自动推荐使用该Skill。

方式二：主动调用

/blog-publisher 请帮我写一篇关于Claude Code Subagent的文章

Skills vs Subagent：怎么选？

很多人搞不清Skills和Subagent的区别。我总结了一个对比表：

我的经验是：

• 需要保留上下文的任务用Skill，比如生成符合项目风格的代码
• 需要隔离上下文的任务用Subagent，比如代码审查、调试

一个实际案例：多Skill协作

上周我要做一个数据报告，涉及PDF提取、Excel处理、文档生成。我用链式调用完成：

# 1. 提取PDF中的数据
请用pdf技能提取report.pdf中的表格数据

# 2. 分析数据
请用xlsx技能分析这些数据，生成统计报表

# 3. 生成报告文档
请用docx技能生成一份完整的分析报告

三个Skill串联，自动化了本来需要人工操作2小时的工作。

踩过的坑

• Skill描述要具体：描述太模糊会导致Claude不知道什么时候调用
• 避免Skill之间冲突：多个Skill描述相似时，Claude可能不知道选哪个
• 定期更新：项目规范变了，记得更新对应的Skill

最佳实践

1. 一个Skill只做一件事：不要把太多功能塞进一个Skill
2. 描述要包含触发条件：写清楚什么情况下应该使用这个Skill
3. 提供示例：在Skill里放几个使用示例，Claude会学得更快
4. 版本管理：把Skills放在git里，方便团队共享

总结

Skills系统让Claude从"通用AI"变成了"专业AI团队"。你不需要每次都从头教Claude怎么做某件事，只需要配置好Skill，它就会自动调用。

如果你经常做重复性的技术工作，强烈建议花点时间配置几个Skill。前期投入半小时，后期每次都能省下几十分钟。

你有没有遇到过这种情况：让Claude帮你review代码，结果对话越来越长，上下文越来越乱，最后还把前面的需求给忘了？

这就是普通Claude的痛点：一个AI要干所有的活——写代码、查Bug、写文档、做测试。它不仅累，而且容易搞混上下文。

直到我发现了Subagent——它可以让Claude像项目经理一样，把不同任务外包给不同的AI助手。

Subagent vs 普通Claude：本质区别

用一个比喻来说明：

• 普通Claude = 万金油员工，什么都能做，但容易分心
• Subagent = 专职员工，只干一件事，但干得非常专业

最关键的是：每个Subagent有独立的上下文。当代码审查Subagent干活的时候，它不会污染你主对话的上下文。

实战：创建一个代码审查Subagent

我们来创建一个专门审查代码的Subagent。步骤很简单：

第一步：输入命令

/agents

选择"Create new agent"。

第二步：选择级别

• 项目级别：只在当前项目生效
• 用户级别：所有项目都能用（推荐）

第三步：添加描述

我是一名代码审查专家。
我的任务是：
- 检查代码质量和潜在Bug
- 发现安全隐患（SQL注入、XSS等）
- 提供优化建议
- 检查是否符合代码规范

请在需要审查代码质量时调用我。

第四步：选择工具权限

这里我选择只读权限。为什么？因为我只让它审查代码，不让它修改代码。这样可以防止AI误操作。

💡 小技巧：如果给Subagent开了编辑权限，一定要确保描述写得非常清楚，否则可能会误改你不想改的文件。

第五步：选择模型

可以选择指定模型，或者跟主对话用同样的模型。对于代码审查这种简单任务，我选择Haiku——响应快，成本低。

第六步：保存

保存后，会在.claude/agents/目录下生成一个Markdown文件。

使用Subagent的两种方式

方式一：自动触发

当你对Claude说"帮我审查一下这段代码"，Claude会自动调用你配置的代码审查Subagent。

方式二：显式调用

请用code-reviewer审查src/auth.py这个文件

进阶技巧：后台执行

按Ctrl + B可以让Subagent在后台执行。这样你可以继续和Claude主对话交流，当Subagent完成之后会自动通知你。

这个功能太实用了！比如我在写代码的同时，让代码审查Subagent在后台审查我之前的代码。两不耽误。

一个真实的工作流

现在我的开发流程是这样的：

1. 在主对话里和Claude讨论需求、设计方案
2. 让Claude写代码，我在确认模式下逐步审核
3. 代码写完后，把代码审查Subagent调出来（后台运行）
4. 根据审查结果修改代码
5. 如果需要测试，再调用测试Subagent

整个过程，主对话的上下文一直保持干净。以前可能200K token都不够用，现在50K就绰绰有余。

我创建的其他Subagent

Subagent配置文件示例

生成的配置文件长这样：

---
name: code-reviewer
description: 代码质量和安全审查专家
model: haiku
tools: read-only
---

# 系统提示词

你是一名资深的代码审查专家。请审查用户提供的代码，关注以下方面：

## 质量检查
- 代码可读性
- 命名规范
- 函数职责单一性
- 注释完整性

## 安全检查
- SQL注入风险
- XSS漏洞
- 敏感信息泄露
- 权限验证缺失

## 输出格式
请按以下格式输出审查结果：
1. 发现的问题（按严重程度排序）
2. 改进建议
3. 代码质量评分（1-10）

踩过的坑

• 描述不够具体：Claude不知道什么时候该调用这个Subagent
• 权限给太宽：一个只读的Subagent不需要编辑权限
• Subagent太多：不要创建太多，不然Claude也不知道选哪个

最佳实践总结

1. 一个Subagent只做一件事：代码审查就是代码审查，不要让它顺便写测试
2. 使用合适的模型：简单任务用Haiku省钱，复杂任务用Sonnet
3. 善用后台执行：让Subagent在后台干活，不阻塞主对话
4. 定期清理：不用的Subagent删掉，保持干净

总结

说实话，Subagent这个功能如果你不用，Claude Code的价值至少少了一半。尤其是做中大型项目的时候，它真的能节省你很多时间和Token。

把Claude当成项目经理，把Subagent当成专职员工。你的工作就是协调他们，而不是亲自下场干每一件事。

去年我参与了一个客服系统的改造项目，让我对AI对话系统的真实能力有了切身体会。今天想分享一些第一手的观察。

一个真实的客服系统改造案例

这是一家中型电商平台，每天客服咨询量在2万次左右。改造前，他们有50个客服，还是忙不过来。

我们做的事情不复杂：

1. 把历史聊天记录（约200万条）喂给AI训练
2. 整理了500个常见问题及标准答案
3. 搭建了一个AI + 人工的协作系统

运行3个月后，数据是这样的：

最关键的是：客服成本降了60%，客户满意度反而提高了。

AI能解决什么问题？不能解决什么？

分析这3个月的数据，我发现：

AI擅长的问题（自动解决率>90%）：

• 订单状态查询："我的包裹到哪了？"
• 退换货政策："这个能退吗？"
• 产品咨询："这款手机支持5G吗？"
• 账户问题："怎么修改密码？"

AI搞不定的问题（必须转人工）：

• 情绪激动的投诉："你们这什么破服务！我要投诉！"
• 复杂售后："我买了三件，退了两件，用了优惠券，现在差价怎么算？"
• 特殊请求："能帮我写个贺卡吗？是送女朋友的。"

所以我们设计了一个机制：AI检测到用户情绪变差、或者连续两次回答不满意，自动转人工。这样既保证了效率，又不会牺牲体验。

教育领域：我看到的真实场景

我有个朋友在一家在线教育公司，他们做了一个AI作文批改系统。

以前老师改一篇作文要10分钟，现在AI可以秒批：

学生作文："今天我和妈妈去公园玩，看到了很多花，有红色的，黄色的，还有白色的，很漂亮。"

AI批改：
- 总体评价：语句通顺，但可以更丰富
- 问题标注：
  ▲ "看到了很多花" → 可以加入形容词，如"五颜六色的花"
  ▲ 句子结构较单一，建议尝试复杂句
- 修改建议："今天我和妈妈去公园玩，看到了五颜六色的花。
  红的像火，黄的似金，白的如雪，真是美极了。"
- 评分：B+ (82分)

老师说，AI批改的速度是她的100倍，而且质量稳定。她现在只需要关注AI标记"不确定"的作文，效率提升明显。

医疗领域：谨慎但充满希望

医疗是AI应用最敏感的领域，也是最有价值的领域之一。

我了解到一家三甲医院在试点AI预诊系统。患者挂号前，先和AI对话描述症状：

患者：我头疼，还有点发烧
AI：请问发烧多少度？持续几天了？
患者：昨天开始发烧，38.5度
AI：除了头疼，还有其他症状吗？比如咳嗽、嗓子疼？
患者：嗓子有点疼
AI：根据您的描述，可能是上呼吸道感染。建议挂呼吸内科。
已为您推荐呼吸内科的专家号源...

这个系统不会给出诊断结论，而是帮助患者找到合适的科室，减少"挂错号"的情况。数据显示，试点科室的挂号准确率从65%提高到了88%。

踩过的坑

最后分享几个我们踩过的坑：

坑一：数据质量比模型能力更重要

一开始我们用了最新的模型，效果却很差。后来发现是训练数据太乱：同一个问题有十几种问法，答案却互相矛盾。

花了一个月整理数据，把500个问题的答案标准化，效果立刻提升了一个档次。AI不是越强越好，而是数据越好越强。

坑二：用户不会按你预想的方式提问

我们设计了很多"标准问法"，结果用户根本不这么问。比如：

• 我们设想："请问如何修改收货地址？"
• 用户实际："地址改一下"
• 我们设想："请查询订单物流信息"
• 用户实际："货到哪了"

后来我们专门收集了用户的真实问法，重新训练，系统才真正好用起来。

坑三：AI也会"一本正经胡说八道"

有一次AI告诉用户"24小时内可以无条件退款"，但这根本不是公司的政策。我们紧急排查，发现是训练数据里有一条客服对话记错了。

现在我们对所有涉及政策的回答，都会加一道人工审核，确保AI不会乱承诺。

写在最后

AI对话系统不是银弹，它不能解决所有问题。但在那些重复性高、标准化程度高的场景里，它确实能创造巨大价值。

关键是：不要想着用AI完全替代人，而是用AI解决80%的简单问题，让人去处理那20%真正需要人类判断的问题。

去年发生的一件事，让我开始认真思考AI伦理这个问题。

从一个真实的面试场景说起

我朋友在一家互联网公司做HR，他们用AI系统筛选简历。有一次，他发现一个奇怪的现象：系统自动过滤掉了所有名字里带"芳"字的女性候选人。

查了一下才发现，训练数据里，名字带"芳"的候选人大多来自某个特定地区，学历和经验普遍不符合要求。AI学到了这个"规律"，然后把它泛化成了一个荒谬的规则：名字带"芳"的一律不要。

这就是典型的算法偏见。AI不懂得什么是公平，它只是在数据中发现模式。如果数据本身带有偏见，AI就会放大这种偏见。

数据偏见的具体案例

这几年，类似的案例层出不穷：

案例一：亚马逊的招聘AI

2018年，亚马逊被迫关闭了一个AI招聘工具。原因是这个AI明显歧视女性：它会惩罚简历中出现"女子足球队"、"女子学院"等字眼的候选人。

原因很简单：训练数据来自过去10年的简历，而亚马逊的技术团队过去以男性为主。AI学到了"男性=更可能被录用"这个"规律"。

案例二：面部识别的种族差异

2018年的一项研究发现，商业面部识别系统对深色皮肤人群的错误率高达35%，而对浅色皮肤人群只有1%。原因是训练数据中白人面孔占绝大多数。

这意味着什么？一个黑人可能因为面部识别错误被错误地标记为犯罪嫌疑人。这不是科幻小说，已经有真实案例发生。

隐私：那些我们没意识到的"出卖"

上个月我注册一个App，弹出一堆权限请求：通讯录、相册、位置、麦克风……我随手点了"允许"。

后来我仔细想了一下，这个App真的需要这些权限吗？它是一个记账软件，为什么要我的通讯录？

更可怕的是AI时代的数据"关联分析"：

• 你的位置数据可以推断你的作息规律
• 你的购物记录可以推断你的收入水平
• 你的社交网络可以推断你的政治倾向

单独看每条数据，似乎没什么。但当AI把这些数据关联起来，它对你的了解可能比你自己还清楚。

去年有一条新闻：某外卖平台被发现根据用户的历史订单，给不同用户显示不同的价格。经常点外卖、不太比价的用户，看到的价格更高。这就是所谓的大数据杀熟。

AI说谎：一个让我后怕的经历

有一次，我让Claude帮我查一个技术文档的具体参数。它给出了一个非常详细的数据表格，包括版本号、发布日期、性能指标等。

我直接用了。直到上线前测试，才发现那个版本根本不存在。回去查官方文档，才发现Claude"编"了一堆看似合理但实际上不存在的信息。

这就是所谓的AI幻觉（Hallucination）。

更严重的是，AI有时候会非常自信地说一些完全错误的话。在医疗、法律、金融等领域，这种错误可能是致命的。

去年美国有个律师用ChatGPT写法律文书，结果ChatGPT编造了6个根本不存在的案例。这位律师差点被吊销执照。

我认识的一位AI研究员怎么说

我有个朋友在某大厂做AI安全研究。聊到这个问题时，他说了一段话让我印象深刻：

他告诉我，业内正在研究的方向包括：

• 可解释AI：让AI的决策过程可追溯、可解释，而不是"黑盒"
• 对抗测试：专门找人来"攻击"AI系统，发现潜在问题
• 人类在环：重要决策必须有人类参与确认

作为普通人，我们能做什么？

说了这么多问题，我不是要否定AI的价值。而是想说：了解这些风险，能让我们更聪明地使用AI。

我自己的几个原则：

1. 验证重要信息：AI给的任何事实性信息，尤其是数字、日期、引用，都要自己核实
2. 保护隐私：不把敏感信息（身份证、密码、公司机密）输入AI
3. 保持怀疑：如果AI的回答看起来"太完美"或"太巧合"，多问几个为什么
4. 了解原理：大致了解AI是怎么工作的，知道它的能力边界

写在最后

AI不会消失，它只会越来越强大。与其恐惧或盲从，不如学会与它共处，同时保持清醒。

技术本身是中性的，关键在于人如何使用它。每个人都是这个时代的参与者，我们的选择和行动，将决定AI最终会成为帮助人类的工具，还是失控的风险。