你不需要 CLAUDE.md
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照要求将其翻译为简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！
如何有效管理 CLAUDE.md / AGENTS.md
本文不涉及常规的提示工程基础（例如，“避免负面示例”、 “设定 LLM 角色”、 “具体化”。如果需要这些基础，请参考 Anthropic 或 OpenAI 官方文档。
相反，我将分享在实际项目中使用 Claude Code 数月后总结出的实用模式。重点在于 组织文档，让 LLM 在代码库规模扩大时仍保持高效。
我的工作理念
- 我 不是 “随性编码者”。我从不让 LLM 自主运行数小时或数天。
- 我把 LLM 当作键盘：它可以超人速度阅读和输入，也可以执行动作来验证其工作，但 我始终掌控全局。
- 如果某个建议过于抽象或不清晰，我会立刻终止它。
为什么要保持 CLAUDE.md 小巧？
每个项目都应该有一个 CLAUDE.md（或 AGENTS.md）文件，用来说明：
- 项目功能
- 如何浏览项目
- 可用的开发工作流
随着项目成熟，文件可能会膨胀，最终超出 LLM 的上下文窗口。解决办法是：将 CLAUDE.md 控制在约 30 行以内，仅作为定义工作流的入口点。随后 LLM 会根据当前任务自行决定读取哪些其他文档。
示例 CLAUDE.md
# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.您的角色
你是一个勤勉的助手。注意任务和代码。
如果遇到愚蠢的想法，停止并报告。
极度简洁——为简短牺牲语法。
Source: …
主要流程
立即创建以下待办事项列表：
- 分析用户请求。
- 运行
find docs/ -name "*.md" | sort列出可用文档。 - 阅读可能帮助解决当前任务的文档。
- 阅读
tsconfig.app.json以了解路径快捷方式。 - 阅读
package.json以了解命令。 - 分析文档中的示例。
- 修订执行计划并向用户展示待办事项。
- 用户接受后，创建修订后的待办事项。
- 开始执行任务。
- 使用可能帮助解决当前任务的技能和命令。
请勿编辑此文件 – 这是最终形式。
> **关键点：** 所有详细的指南、工作流和解释都位于 `docs/` 文件夹内。`CLAUDE.md` 仅告诉 LLM *如何* 发现并使用这些文件。
### 组织 `docs/` 文件夹
逻辑地组织文档，将相关文件分组到具有描述性名称的子文件夹中。下面是一个真实的示例：
docs/ ├─ backend/ │ ├─ graphql-api-patterns.md │ ├─ rest-api-patterns.md │ ├─ service-layer.md │ ├─ data-layer.md │ └─ event-system.md ├─ frontend/ │ ├─ actions/ │ │ ├─ create-component.md │ │ ├─ create-modal.md │ │ ├─ create-data-form.md │ │ ├─ create-entity-selection.md │ │ ├─ create-graphql-service.md │ │ ├─ create-rest-service.md │ │ ├─ create-route.md │ │ └─ create-tree-view.md │ ├─ architecture.md │ ├─ design-tokens.md │ └─ ui-ux.md ├─ build-deployment.md ├─ currency-system.md ├─ documentation.md ├─ error-handling.md ├─ localization.md ├─ security.md └─ testing.md
- **全局文档**（例如 `security.md`、`testing.md`）涵盖高层概念。
- **特定功能文档**（例如 `frontend/actions/create-component.md`）指导具体操作。
### 这有何帮助
1. **每个任务的最小上下文** – 当 LLM 运行 `find docs/ -name "*.md" | sort` 时，它只会看到文件名列表（几十行）。
2. **选择性加载** – 根据文件名，LLM 决定哪些文档相关并仅读取这些文档。
3. **可扩展性** – 你可以无限添加文档文件，而无需担心上下文限制。前端任务除非明确需要，否则永远不会加载后端或 GraphQL 文档。
### 使用 LLM 管理文档集
让 LLM 本身保持文档整洁：
1. **任务进行中** – 持续监控 LLM 的操作，记录任何错误，并记录你是如何修复的。
2. **任务完成后** – 运行 `/refine` 命令（或等效的自定义命令）以整合学习成果并删除不必要的内容。
#### 示例精炼待办列表
```markdown
- 运行 `find docs/ -name "*.md" | sort` 查看可用文档。
- 查看 “如何编写文档” 指南。
- 确认过时或重复的文件。
- 更新文件标题以保持一致性。
- 在需要的地方添加交叉引用。
- 删除任何不再相关的文件。
- 使用简洁的提交信息提交已清理的文档。 反思本次会话
此指令告诉语言模型在会话期间进行反思：发生了何种错误，如何克服，以及是否有必要将有益的内容添加到文档中，以便将来避免这些错误。
前提条件
您需要一个 markdown 文件，用于描述如何为您的项目编写文档。有了它，语言模型将：
- 思考本次会话。
- 在现有文档中找到合适的位置——如果需要，也可以创建新文档。
- 阐述如何在未来避免此类问题。
通过这种方式，您的文档会根据实际开发中遇到的问题有机地演进。每一次会话都是改进知识库的机会。
为什么这样有效
- 不仅仅用于修复错误 – 它适用于任何在创建新系统或发现需要确保正确且一致执行的重要操作的情况。
- 操作文档（例如
create‑modal.md、create‑component.md、create‑service.md）为特定任务定义了严格的结构，减少了 LLM 在执行 CLI 命令或遵循精确步骤序列时的随机性。
提升 Claude Code 工作流的技巧
1. 先提示，后完善
与其直接让 LLM 执行任务，不如让它：
- 调查项目。
- 阅读文档。
- 找出提示中的问题。
- 扩展提示以覆盖所有不明确的情况。
Benefits
| 阶段 | 说明 |
|---|---|
| 第一阶段 | 从一个简单的提示开始，然后与 LLM 讨论。添加或删除需求，调整范围，让 LLM 指出边缘情况或提出澄清性问题。 |
| 第二阶段 | 提示完善后，使用该明确的提示开启新会话。LLM 现在对需要完成的任务有清晰、全面的理解，从而产生更可靠的结果。 |
关键提示： 不要害怕丢弃 LLM 已生成的内容，重新开始。
2. 当结果不完美时
- 停止当前运行。
- 回到你的提示，说明哪里出错。
- 添加缺失的信息或澄清需求。
- 清理上下文并开启新会话。
LLM 可能会随后提出澄清性问题，建议更好的方法，或提供示例帮助你进一步细化需求。第二次尝试带着第一次的经验教训，几乎总能更接近你真正想要的结果——而且是基于干净的基础，而不是一堆补丁式的修复。
3. 重复操作（元提示）
- 在拥有稳固的提示后，你可以再次对该提示进行元提示。
- 如果一切已经很好，LLM 会快速确认提示的稳固性。
- 在全新的上下文中，LLM 可能会注意到第一次遗漏的内容。
同样的思路也适用于实现：
- 创建两个实现并进行比较。
- 第二次尝试的成本低，而捕获问题或发现更好方案的收益很高。
4. 部分实现
- 使用模拟数据（内存查询、假 API 调用）构建完整的 UI。
- 快速迭代结构、流程和用户体验。
- 满意后，用真实的 API 调用替换模拟。
在 Claude Code 之前，这会非常繁琐——实现、验证、测试、重复。
使用 Claude Code，你可以在约 15 分钟内得到带模拟数据的 UI，再用约 15 分钟添加真实的数据库集成。额外的测试工作通过在大约一小时内交付可预测结果的成品而得到回报。
关键要点
- 保持 CLAUDE.md 简洁；将其用作入口点，而不是 知识倾倒。
- 将所有实质性知识存放在组织良好的
docs/层级结构中，LLM 可以有选择地读取所需内容。 - 这种方法具有可扩展性：你可以拥有数十个文档文件，而不会触及上下文限制。
持续的文档维护
- 使用 LLM 本身来维护和演进你的文档。
- 每一次捕获并修复错误的会话都是提升未来会话知识库的机会。
- 为重复性任务创建 action documents，以消除随机性并确保一致性。
拥抱 Claude Code 带来的速度，让每一次交互使你的文档更智能，工作流更顺畅。
使用 Claude Code 的技巧
- 使用元提示 在实现之前细化你的需求。
- 不要害怕丢弃代码，重新开始。
- 运行两遍——快速的第二遍检查常能发现隐藏问题。
- 使用模拟对象构建部分实现，以快速迭代。
- 拥抱重复：成本低，获得完全符合需求的好处高。
这些模式改变了我使用 Claude Code 的方式。希望它们也能帮助你。