技术手记

为什么我用 Astro 搭个人技术博客

Thu, 14 May 2026 00:00:00 GMT

个人技术博客最重要的不是第一次上线时功能有多满，而是它能不能陪你写很久。

Astro 很适合这个起点：文章用 Markdown 或 MDX 保存，页面默认生成静态 HTML，部署到 Vercel、Netlify、Cloudflare Pages 或自己的服务器都很轻松。

我关心的几点#

内容在自己的仓库里，迁移成本低。
页面足够快，读者点开文章不用等一堆脚本。
以后可以逐步加交互组件，比如在线 demo、代码实验或可视化图表。

这套博客的第一版先放下几个核心能力：首页、文章列表、标签、归档、关于、项目、RSS 和站点地图。它不会妨碍后续扩展，也不会在一开始把维护成本拉得太高。

在 Claude Code 里使用 DeepSeek V4：配置、模型映射与排错

Thu, 14 May 2026 00:00:00 GMT

Claude Code 默认面向 Anthropic 的 Claude 模型，但它的请求形态可以通过环境变量指向 Anthropic 兼容接口。DeepSeek 官方提供了 Claude Code 接入说明，因此可以把 Claude Code 的终端交互体验和 DeepSeek V4 的模型能力结合起来。

这篇文章只讲配置方法和排错，不会保存任何 API Key 到项目里。

先理解几个环境变量#

接入第三方兼容接口时，核心变量是：

Terminal window

1
ANTHROPIC_BASE_URL
2
ANTHROPIC_AUTH_TOKEN
3
ANTHROPIC_MODEL
4
ANTHROPIC_DEFAULT_OPUS_MODEL
5
ANTHROPIC_DEFAULT_SONNET_MODEL
6
ANTHROPIC_DEFAULT_HAIKU_MODEL
7
CLAUDE_CODE_SUBAGENT_MODEL

它们分别控制请求地址、认证令牌、默认模型，以及 Claude Code 内部不同模型槽位对应的模型。

DeepSeek 官方文档给出的 Anthropic 兼容地址是：

1
https://api.deepseek.com/anthropic

API Key 需要去 DeepSeek Platform 获取。不要把真实 Key 写入博客、仓库或截图里。

Windows PowerShell 配置#

如果你在 Windows 上使用 PowerShell，可以在启动 Claude Code 前设置环境变量：

Terminal window

1
$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
2
$env:ANTHROPIC_AUTH_TOKEN="<你的 DeepSeek API Key>"
3
$env:ANTHROPIC_MODEL="deepseek-v4-pro[1m]"
4
$env:ANTHROPIC_DEFAULT_OPUS_MODEL="deepseek-v4-pro[1m]"
5
$env:ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-v4-pro[1m]"
6
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-v4-flash"
7
$env:CLAUDE_CODE_SUBAGENT_MODEL="deepseek-v4-flash"
8
$env:CLAUDE_CODE_EFFORT_LEVEL="max"
9
claude

这组变量只对当前 PowerShell 窗口有效。关闭窗口后不会继续保留，适合先测试。

如果你想长期使用，可以把它们写进你的 shell profile，但不要写进项目仓库。

Mac 或 Linux 配置#

在 bash、zsh 里可以使用：

Terminal window

1
export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
2
export ANTHROPIC_AUTH_TOKEN="<你的 DeepSeek API Key>"
3
export ANTHROPIC_MODEL="deepseek-v4-pro[1m]"
4
export ANTHROPIC_DEFAULT_OPUS_MODEL="deepseek-v4-pro[1m]"
5
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-v4-pro[1m]"
6
export ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-v4-flash"
7
export CLAUDE_CODE_SUBAGENT_MODEL="deepseek-v4-flash"
8
export CLAUDE_CODE_EFFORT_LEVEL="max"
9
claude

建议先在临时终端里验证，再决定是否写入 ~/.zshrc 或 ~/.bashrc。

模型映射怎么选#

一个实用配置是：复杂规划和主任务用 V4 Pro，子任务或轻量任务用 V4 Flash。

deepseek-v4-pro[1m]：适合架构分析、复杂重构、长上下文任务。
deepseek-v4-flash：适合快速问答、子代理、简单检索和较轻的代码改动。

如果你发现响应速度比预期慢，可以把默认模型先换成 Flash，再只在复杂任务时切回 Pro。

常见错误排查#

第一类是认证失败。检查 ANTHROPIC_AUTH_TOKEN 是否真的设置在启动 Claude Code 的同一个终端里：

Terminal window

1
echo $env:ANTHROPIC_AUTH_TOKEN

不要把 Key 粘到命令历史、截图或仓库文件里。

第二类是地址拼错。Claude Code 会在兼容接口基础上调用消息接口，所以 ANTHROPIC_BASE_URL 要使用 DeepSeek 文档给出的 Anthropic 兼容地址，不要随意混用 OpenAI 兼容地址。

第三类是模型名不匹配。优先使用 DeepSeek 当前文档列出的模型 ID。如果模型名发生更新，以官方文档为准。

第四类是项目里误提交了配置。建议 .gitignore 忽略 .env 和 .env.*，并只提供 .env.example 作为示例。

适用边界#

这类接入方式适合希望保留 Claude Code 工作流，同时尝试 DeepSeek 模型成本、速度或上下文能力的开发者。它不等于 Claude 官方模型，也不保证所有 Claude Code 特性在第三方模型上体验完全一致。

我的建议是：先用一个小项目验证读代码、改文件、跑测试、总结风险这些基本流程，再决定是否作为主力配置。

参考资料#

手把手上手 Claude Code：从安装到第一次读懂项目

Thu, 14 May 2026 00:00:00 GMT

Claude Code 不是一个只会补全代码的编辑器插件，它更像一个运行在终端里的协作型开发助手。它能读取项目文件、执行命令、修改代码、解释架构，也能围绕一个目标连续推进多步任务。

如果你刚开始用 Claude Code，最重要的不是一上来就让它重构整个项目，而是先学会三件事：让它理解项目、把任务说清楚、在关键节点检查它的判断。

适合解决什么问题#

Claude Code 最适合处理“需要理解上下文”的开发任务，比如：

接手一个陌生项目，快速梳理目录结构和启动方式。
修复一个能复现的 bug，并补上测试。
做小范围重构，同时保持原有接口不变。
根据已有代码风格新增页面、接口或脚本。
帮你 review 当前改动，找出风险和遗漏。

如果问题只是查一个 API 怎么用，普通聊天工具也够；如果问题需要读仓库、跑命令、改文件，Claude Code 的优势就明显了。

安装与启动#

官方推荐直接安装 Claude Code CLI。不同系统命令略有区别，安装完成后在项目目录运行：

Terminal window

1
claude

如果你想让 Claude Code 从某个项目根目录开始理解上下文，先进入项目目录：

Terminal window

1
cd your-project
2
claude

第一次进入后，可以先让它只做分析，不改代码：

1
请先阅读这个项目的结构，告诉我它的技术栈、启动命令、主要目录职责，不要修改文件。

这个开场很重要。你给它的第一条任务决定了它是“先理解”还是“直接动手”。对陌生项目，先读再做通常更稳。

常用斜杠命令#

Claude Code 有一批斜杠命令，用来控制会话和工作流。新手最常用的是：

1
/help
2
/clear
3
/compact
4
/model
5
/skills
6
/hooks

/help 用来查看当前可用能力；/clear 适合彻底开启新任务；/compact 适合长会话中压缩上下文，保留关键结论；/model 用于切换模型；/skills 和 /hooks 则对应扩展能力。

一个实用习惯是：每完成一个阶段，让 Claude Code 总结当前状态，再继续下一阶段。

1
请总结目前你已经确认的事实、做过的修改、还没验证的风险。先不要继续改代码。

这能避免长会话里上下文逐渐变乱。

第一个真实任务怎么发#

差的任务通常是这样的：

1
帮我优化这个项目。

Claude Code 也许会动起来，但它不知道你真正想要的是性能、架构、样式、类型，还是构建速度。

更好的任务应该包含目标、边界和验收方式：

1
请帮我修复登录页在移动端按钮换行的问题。
2
要求：
3
1. 只修改登录页相关组件和样式。
4
2. 保持现有颜色和设计风格。
5
3. 修改后运行现有前端检查。
6
4. 完成后告诉我改了哪些文件，以及如何验证。

这个提示把“要做什么”和“不要做什么”都说清楚了。Claude Code 越少猜测，结果越接近你的预期。

注意事项#

不要把密钥直接发进会话，也不要让 Claude Code 把 .env 提交到仓库。涉及部署、数据库、支付、线上数据时，要让它先解释风险和回滚方式。

Claude Code 很擅长执行，但你仍然是最后的技术负责人。它给出的修改要经过测试，涉及业务逻辑的地方尤其要看清楚。

参考资料#

Claude Code 隐藏技巧：学会这些，协作效率会明显变高

Thu, 14 May 2026 00:00:00 GMT

Claude Code 的基础用法很简单：打开终端，描述需求，让它读代码和改文件。但真正影响效率的，往往是一些不太显眼的工作习惯。

这些技巧不神秘，但能显著减少返工：先规划、常压缩上下文、给清晰边界、让它验证、把重复流程沉淀成 Skill 或 Hook。

复杂任务先进入规划状态#

遇到复杂任务时，不要第一句话就让 Claude Code 改代码。先让它读相关文件并输出计划：

1
先不要修改文件。请阅读相关代码，给出实现计划、涉及文件、风险点和验证方式。

等你确认后再让它执行：

1
按这个计划实现。每次改动保持小步，完成后运行验证命令。

这个习惯能避免它在没理解完整上下文时过早下手。尤其是重构、部署、数据库迁移、权限系统这类任务，先规划再执行非常必要。

用 `/compact` 管理长会话#

长会话里，Claude Code 会积累大量上下文。上下文越长，越容易混入旧结论、废弃方案或已经修正过的信息。

当一个阶段完成后，可以使用：

1
/compact

压缩前也可以先要求它整理关键信息：

1
请总结当前任务的目标、已完成修改、验证结果、剩余风险。然后我会 compact。

这样压缩后的上下文更干净，后续继续推进时不容易跑偏。

把边界说得比目标更清楚#

很多任务失败不是因为目标没说，而是边界没说。

例如：

1
修复文章列表移动端样式问题。

这句话目标明确，但边界不清。更好的写法是：

1
修复文章列表移动端标题溢出问题。
2
限制：
3
1. 只改文章列表相关组件和 CSS。
4
2. 不引入新的 UI 库。
5
3. 不改变桌面端布局。
6
4. 完成后用浏览器检查 375px 和 1440px 宽度。

边界越清楚，Claude Code 越不容易做“顺手重构”。

让它解释验证方式#

不要只问“改完了吗”。更好的问题是：

1
你如何验证这个改动是正确的？还剩哪些风险没覆盖？

对代码任务，可以要求它运行测试、构建或最小复现命令。对前端任务，可以要求它打开页面截图检查。对部署任务，可以要求它确认生成产物和路径配置。

Claude Code 不是替代测试的工具，它是帮你更快找到应该测试什么的工具。

截图和错误信息要一起给#

如果是 UI 问题，截图比长描述更有效。但只给截图还不够，最好同时给：

当前页面地址。
期望效果。
实际问题。
浏览器控制台错误。
最近改过的文件。

例如：

1
这是移动端截图。问题是卡片标题挤到了按钮上。
2
当前地址是 http://localhost:4321/posts/。
3
期望标题换行，按钮保持固定高度。
4
请先定位原因，不要马上改代码。

这样 Claude Code 可以把视觉信息和代码上下文对应起来。

用 Hooks 做自动提醒和检查#

Hooks 可以在 Claude Code 生命周期里的特定时机执行脚本，比如工具调用前后、会话开始、需要权限、任务停止等。

常见用途包括：

自动提醒你某些危险命令需要确认。
在修改后运行格式检查。
在提交前检查文档是否同步。
记录关键操作日志。

Hooks 很强，但也要谨慎。不要在 Hook 里放复杂、不可控、会递归调用 Claude Code 的逻辑。它更适合作为轻量检查和提醒层。

把常用流程做成 Skill#

当你第三次复制同一段提示词时，就该考虑做 Skill 了。

比如你经常让 Claude Code 写发布说明，可以做一个 release-note Skill，里面规定：

输入来自 git diff。
输出包含功能、修复、风险和验证。
语气简洁，不夸大。
忽略内部临时文件。

这样你以后只需要说：

1
/release-note

重复劳动就变成了稳定流程。

参考资料#

把 Claude Code 放进真实开发流程：读代码、修 Bug、补测试、做 Review

Thu, 14 May 2026 00:00:00 GMT

很多人第一次用 Claude Code，会让它“帮我写一个功能”。这当然可以，但更好的用法是把它放进真实开发流程：先理解现状，再定位问题，小步修改，运行验证，最后做提交前 review。

这篇文章给出一个可复用模板，适合修 bug、补功能、小重构和代码审查。

第一步：让它读现状，不要急着改#

开场可以这样说：

1
请先阅读这个项目，不要修改文件。
2
目标是理解这个 bug 可能发生在哪里。
3
请告诉我：
4
1. 相关模块和文件。
5
2. 当前数据流。
6
3. 可能的原因。
7
4. 你建议先检查什么。

这一步的价值是把 Claude Code 从“生成代码模式”拉回“工程分析模式”。很多 bug 并不难修，难的是找准位置。

第二步：给它复现信息#

如果你有报错、截图、日志或复现步骤，一次性给齐：

1
复现步骤：
2
1. 登录普通用户账号。
3
2. 打开 /settings/profile。
4
3. 修改头像后点击保存。
5

6
实际结果：页面提示成功，但刷新后头像恢复旧图。
7
期望结果：刷新后仍显示新头像。

如果有日志，贴关键几行即可。不要把几千行日志直接塞进去，可以先让它告诉你需要哪一段。

第三步：让它提出最小修改方案#

在动手前，让 Claude Code 输出方案：

1
请给出最小修改方案。
2
要求：
3
1. 尽量不改变现有接口。
4
2. 不做顺手重构。
5
3. 说明需要补哪些测试。
6
4. 说明可能影响哪些页面。

如果方案里出现“顺便统一重构”“改造整个状态管理”之类的内容，要让它收窄。真实项目里，小而确定的改动通常更容易上线。

第四步：执行并验证#

确认方案后再让它实现：

1
按方案实现。完成后运行相关测试和构建。如果验证失败，先解释失败原因，再继续修复。

你也可以明确验证命令：

1
npm run test
2
npm run build

如果项目很大，不一定每次都跑全量测试。可以先跑相关测试，再在提交前跑完整检查。

第五步：让它做提交前 Review#

改完后，不要马上提交。让 Claude Code review 自己的改动：

1
请 review 当前未提交改动。
2
重点看：
3
1. 是否有行为回归。
4
2. 是否有遗漏测试。
5
3. 是否有无关改动。
6
4. 是否有敏感信息或调试代码。

这个步骤很有用，因为 Claude Code 在“实现模式”和“审查模式”下关注点不同。让它切换视角，经常能发现刚才没注意到的问题。

第六步：整理提交说明#

如果 review 没有问题，再让它生成提交说明：

1
请基于当前 diff 生成一个简洁的 git commit message。
2
格式：
3
第一行不超过 50 个字符。
4
正文说明修改原因和验证方式。

好的提交说明应该解释“为什么改”，而不只是罗列“改了什么”。

适用边界#

Claude Code 很适合帮你推进明确目标的工程任务，但不适合替你拍板模糊的产品决策。涉及安全、计费、权限、数据删除、线上发布时，一定要保持人工确认。

把它当成一个很能干的协作者，而不是无人监督的自动提交机器，效果会更稳定。

参考资料#

Claude Code Skill 详解：把重复提示词变成可复用能力

Thu, 14 May 2026 00:00:00 GMT

如果你经常对 Claude Code 重复说同一段话，比如“请按我们团队的代码审查标准检查这个 PR”，或者“生成文章时使用固定结构和语气”，那就应该考虑把它做成 Skill。

Skill 的本质是把一段专业工作流包装成一个可发现、可复用、可共享的能力。Claude Code 会在合适的时候加载它，也可以通过斜杠命令直接调用。

Skill 适合放什么#

适合做成 Skill 的内容通常有这些特征：

你会反复使用同一套步骤。
它有明确输入和输出格式。
它依赖项目约定、团队规范或固定检查表。
它需要附带模板、示例、脚本或参考资料。

不适合做成 Skill 的内容是“某个临时问题的一次性答案”。如果只是今天问一次，直接在对话里说清楚即可。

基本目录结构#

一个最小 Skill 是一个目录加一个 SKILL.md：

1
.claude/
2
  skills/
3
    code-reviewer/
4
      SKILL.md

项目级 Skill 放在项目内的 .claude/skills/，适合团队共享。个人级 Skill 通常放在用户目录下，适合自己的长期习惯。

更完整的 Skill 可以包含参考文件、模板和脚本：

1
code-reviewer/
2
  SKILL.md
3
  checklist.md
4
  examples/
5
    review-output.md
6
  scripts/
7
    collect-diff.sh

Claude Code 会先读 SKILL.md，只有需要时才加载额外文件。这种渐进加载能减少上下文浪费。

SKILL.md 怎么写#

SKILL.md 顶部需要 YAML frontmatter，至少写清楚名称和描述：

1
---
2
name: Code Reviewer
3
description: Review code changes for correctness, maintainability, tests, and security. Use when reviewing pull requests or checking uncommitted changes.
4
---
5

6
# Code Reviewer
7

8
## Instructions
9

10
1. Inspect the current diff before commenting.
11
2. Prioritize bugs, regressions, security issues, and missing tests.
12
3. Report findings first, ordered by severity.
13
4. Include file and line references when possible.

description 非常关键。Claude Code 判断是否使用某个 Skill，主要靠它理解描述里的触发场景。描述太泛，比如“helps with code”，就容易误触发或不触发。

自动触发与手动调用#

Skill 有两种使用方式。

第一种是自动触发。你说：

1
帮我 review 当前分支的改动。

如果 Skill 描述明确包含 review、diff、pull request 等触发词，Claude Code 就可能自动加载它。

第二种是手动调用。新版 Claude Code 中，Skill 可以像命令一样通过 /skill-name 调用：

1
/code-reviewer

手动调用适合你很确定要使用某个 Skill 的场景，自动触发适合自然语言工作流。

支持文件怎么组织#

如果 Skill 内容较长，不要把所有东西塞进 SKILL.md。可以把主文件写成入口，把细节拆到附加文件里：

1
## Detailed Checklist
2

3
For the full review checklist, read [checklist.md](checklist.md).
4

5
## Output Format
6

7
Use the format shown in [examples/review-output.md](examples/review-output.md).

这样 Claude Code 只有在需要深挖时才加载大文件，平时只读核心指令。

团队共享建议#

团队 Skill 推荐放进项目仓库：

1
.claude/skills/team-review/SKILL.md
2
.claude/skills/release-note/SKILL.md
3
.claude/skills/db-migration-check/SKILL.md

适合团队共享的 Skill 包括：

代码审查标准。
发布说明格式。
数据库迁移检查清单。
前端组件规范。
安全敏感操作前的确认流程。

这比把所有规则写进一个巨大的 CLAUDE.md 更灵活，因为 Skill 只有在相关任务中才加载。

调试 Skill 不生效#

如果 Claude Code 没有使用你的 Skill，优先检查：

路径是否正确，是否存在 SKILL.md。
YAML frontmatter 是否合法。
description 是否足够具体。
当前任务描述是否包含触发场景。
Claude Code 是否需要重启才能加载新 Skill。

一个好用的测试提示是：

1
当前有哪些 Skills 可用？请说明每个 Skill 适合什么场景。

如果列表里没有你的 Skill，先查路径和 YAML；如果列表里有但不触发，再优化 description。

参考资料#

技术笔记不只是备忘录

Wed, 13 May 2026 00:00:00 GMT

很多技术笔记只记录“怎么做”，但真正有复用价值的部分往往是“为什么这么做”。

我习惯把一篇技术记录拆成四块：

背景：当时遇到了什么问题。
约束：哪些方案不能用，哪些条件必须满足。
选择：最后用了什么方法。
结果：验证方式、收益和遗留问题。

这样下次再读的时候，文章不只是一段命令集合，更像是一份可追溯的工程判断。

技术手记

为什么我用 Astro 搭个人技术博客

我关心的几点#

在 Claude Code 里使用 DeepSeek V4：配置、模型映射与排错

先理解几个环境变量#

Windows PowerShell 配置#

Mac 或 Linux 配置#

模型映射怎么选#

常见错误排查#

适用边界#

参考资料#

手把手上手 Claude Code：从安装到第一次读懂项目

适合解决什么问题#

安装与启动#

常用斜杠命令#

第一个真实任务怎么发#

推荐的新手工作流#

注意事项#

参考资料#

Claude Code 隐藏技巧：学会这些，协作效率会明显变高

复杂任务先进入规划状态#

用 /compact 管理长会话#

把边界说得比目标更清楚#

让它解释验证方式#

截图和错误信息要一起给#

用 Hooks 做自动提醒和检查#

把常用流程做成 Skill#

参考资料#

把 Claude Code 放进真实开发流程：读代码、修 Bug、补测试、做 Review

第一步：让它读现状，不要急着改#

第二步：给它复现信息#

第三步：让它提出最小修改方案#

第四步：执行并验证#

第五步：让它做提交前 Review#

第六步：整理提交说明#

推荐模板#

适用边界#

参考资料#

Claude Code Skill 详解：把重复提示词变成可复用能力

Skill 适合放什么#

基本目录结构#

SKILL.md 怎么写#

自动触发与手动调用#

支持文件怎么组织#

团队共享建议#

调试 Skill 不生效#

参考资料#

技术笔记不只是备忘录

用 `/compact` 管理长会话#