让我成为更高效软件架构师的 10 个 Claude Code 设置

HN LLM Code Research 2026-07-03T07:09:17.633408

如何将 Claude Code 调校成更好的工程伙伴

实用的 Claude Code 工作流、配置文件和护栏，帮助经验丰富的开发者持续获得更好的结果。

和大多数开发者一样，我开始时也接受了默认设置。它们用得还算顺手，Claude 很快就成了我日常工作流的一部分。但随着时间的推移，我注意到一个模式：错误并非随机出现，而是反复发生。

Claude 偶尔会忘记项目约定，在长会话中途丢失重要上下文，或者自信地重构那些根本不需要修改的代码。这些问题单独来看都不是灾难性的，但加在一起，每个月都会导致数小时不必要的审查、修正和回退。

我没有把问题归咎于模型本身，而是开始像对待其他工程工具一样对待 Claude Code：通过配置来让它变得更好。

经过几个月的实验，我最终找到了十项改进，显著提升了速度和可靠性。有些来自官方文档，另一些则是在真实项目中犯过大量错误后才总结出来的。

这不是一篇 Claude Code 的入门指南。

这是一套专为已经使用该工具并希望获得更一致结果的开发者整理的工作流、配置模式和实用护栏。

每个部分都包含可直接复制到你项目中的配置示例。

1. 保持 CLAUDE.md 精简

在我最初几个月的使用过程中，最大的错误之一就是把 CLAUDE.md 变成了百科全书。

该文件一度膨胀到接近 40,000 字符。

它包含了架构决策、编码约定、测试规则、领域知识、入职笔记、部署说明、提示模板、API 合同，甚至项目历史。

我当时以为这样是合理的：

更多上下文应该能产生更好的答案。

但事实并非如此。

注意力问题

大型语言模型并不会对长文档的每个部分一视同仁。

随着文件不断增长，Claude 越来越容易忽略埋在中间位置的信息。那些原本运行良好的重要架构规则，突然开始从它的推理过程中消失。

这不是小问题。

我实际测试了一下：让 Claude 重复我自己 CLAUDE.md 文件第 300 行左右的一条规则。

它找不到。

重复几次实验后，模式变得很明显：文档越长，在长对话过程中其中间部分的可信度就越低。

我的规则：最多 8,000 字符

今天，我把 CLAUDE.md 当作永久会话上下文。

只有那些应该出现在每一次对话中的信息才放在那里：

• 技术栈
• 编码原则
• 架构约束
• 项目级规则
• 附加文档的链接

其他的所有内容都放在别处。

现在我的项目结构如下：

.claude/
├── CLAUDE.md              # 始终加载 (<8 KB)
├── skills/
│   ├── nestjs.md
│   ├── migrations.md
│   ├── review.md
│   └── testing.md
└── specs/
    ├── domain-model.md
    ├── api-contracts.md
    └── infrastructure.md

我不再试图一直加载所有可能的细节，而是将信息组织成重点突出的文档，Claude 只在实际相关时才读取它们。

可以把它看作是对项目知识的懒加载。

结果

重新组织所有内容后：

• CLAUDE.md 从大约 40K 字符缩减到 6K 字符。
• 会话初始化明显更便宜（成本更低）。
• Token 使用量下降了大约 35%。
• Claude 不再“忘记”埋在大文件中间的规则。
• 在长时间开发会话中，响应变得更加一致。

这一项改变带来的改进，比我尝试过的任何提示工程技巧都要大。

有时候，更好的 AI 结果并不来自写更好的提示。

而是来自给模型提供更少但组织更清晰的上下文。

2. 三个 settings.json 调整改变了我工作流

大多数开发者从未打开过 .claude/settings.json。

标题：10 个 Claude Code 设置让我成为更快的软件架构师

默认配置足以入门，因此很容易被忽略。但在日常使用一个月后，我意识到一些微小的改动显著提升了体验。

以下是对我影响最大的三个设置。

自动允许安全命令

第一个改动是移除不必要的确认提示。

Claude 大部分时间用于读取文件、检查 Git 历史、运行测试或搜索项目。这些操作都不具有破坏性，但默认情况下它们常常需要确认。

我允许只读操作和验证命令自动运行，同时将所有可能造成破坏的操作保留为需要手动批准。

{
  "permissions": {
    "allow": [
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git status:*)",
      "Bash(git show:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)",
      "Bash(cat:*)",
      "Bash(grep:*)",
      "Bash(find:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(git reset --hard:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

效果立竿见影。

以前在一次会话中需要批准十五到二十个无害操作，现在我只批准那些可能真正改变重要内容的操作。

开发体验更像是结对编程，而非远程操控一个助手。

自动记录每次会话

第二个改进出乎意料地简单。

我添加了一个 Stop 钩子（Stop hook），用于记录每次完成的 Claude 会话。

{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "echo \"$(date '+%Y-%m-%d %H:%M') session ended\" >> ~/.claude/log.txt"
      }]
    }]
  }
}

起初我以为这不过是出于好奇。

但实际它给了我真实的数据。

我发现自己每天花两个多小时在 Claude Code 上，分散在四到五次独立会话中。在测量之前，我原本猜测的时间还不到这个数字的一半。

你无法优化你从未衡量过的事物。

阻止明显危险的命令

标题：10 个让我成为更快软件架构师的 Claude Code 设置

原文：
最后，我明确禁止那些绝不应意外执行的命令。

{
  "permissions": {
    "deny": [
      "Bash(drop table:*)",
      "Bash(truncate:*)",
      "Bash(delete from * where 1:*)"
    ]
  }
}

这些规则并不能取代良好的工程实践。

它们只是为代价高昂的错误提供了另一层保护。

整个配置存在于仓库中，因此团队中的每位开发者都能从相同的安全护栏中受益，而不必依赖个人习惯。

3. 不要在所有地方启用 acceptEdits

Claude Code 最诱人的功能之一是 acceptEdits。

它取消了文件修改前的确认对话框，让 agent 感觉速度显著提升。

第一次启用它时，你可能会想为什么它不是默认开启的。

使用六个月后，我的答案很简单：

因为它不该被默认开启。

它在哪里表现良好

对于那些可预测且易于自动验证的任务，我会启用 acceptEdits。

例如：

• 将 JavaScript 迁移到 TypeScript
• 替换 any 类型
• 重命名文件或符号
• 更新导入语句
• 格式化代码
• 为现有功能生成测试
• 编辑文档

这些改动大多是机械性的，自动化测试可以快速确认是否有任何东西被破坏。

我永远不会使用它的场景

对于需要判断的工作，我会保持手动批准开启。

这包括：

• 构建新功能
• 架构重构
• 身份验证
• 支付系统
• 数据库层
• 任何“完成”无法在几秒内定义的任务

正是这些情况下，我希望在每次变更写入磁盘之前审查它们。

我通过惨痛教训学到的一课

有一天，我让 Claude 删除未使用的导入。

对于 acceptEdits 来说，这是一个完美的任务。

它完成了那项工作……

……然后它决定，既然已经在编辑文件，顺便重构几个服务也很有帮助。

不

查看原文