参考资料

• Claude Code 文档
• Claude Code 安全

Claude Code（24） - 项目的记忆目录设置

读完后，你应能完成以下任务：

• 绘制“Claude Code（24） - 项目的记忆目录设置 / 通过导入机制与规则包实现复用”的关键对象与数据流，解释“规则可以集中维护与统一更新； -> 不同项目共享相同的工程语言，使 Agent 在多个仓库中的行为更加一致。”，并用源码位置、日志或 Trace 标注证据。
• 为“Claude Code（24） - 项目的记忆目录设置 / 快速获取代码库概览”设计正常与异常输入，验证“从广泛的问题开始，然后缩小到特定领域”，输出首个偏差位置与回归测试结果。
• 实现“Claude Code（24） - 项目的记忆目录设置 / 提示词”的最小代码或配置，检验“请求高级概览：给我这个仓库的概览”，输出命令、结果与 Diff，并说明不适用边界。

各司其职，便于维护

agent-memory/
├── project.md            # 项目总说明
├── rules/
│   ├── code-style.md     # 代码风格
│   ├── testing.md        # 测试约定
│   ├── api-design.md     # API 设计规范
│   ├── security.md       # 安全要求
│   └── frontend/
│       └── react.md      # 前端专项规范
└── local/
    └── developer.local.md

记忆分级

- 团队统一规范 → 项目级
- 公司安全策略 → 组织级
- 个人代码习惯 → 用户级
- 当前机器配置 → 本地级
- 某个专用 Agent 的规则 → 角色级

一、尽量将要求写成 可检查、可执行的规则

例如，不推荐写成：

- 保持代码整洁
- 做好测试
- 注意 API 设计
- 适当拆分模块

而更推荐写成：

- 所有新增 **TypeScript 文件使用 2 空格缩进**
- 修改业务逻辑后 **必须运行 `pnpm test`**
- API handler **统一放在 `src/api/handlers/`**
- React 页面组件 **不超过 300 行**，超过则拆分为 hooks 或子组件

二、通过导入机制与规则包实现复用

在实际项目中，大量规则是 跨仓库共享的工程规范。如果每个仓库都重复编写，不仅维护成本高，也容易出现不一致。

以 Claude Code 为例，其文档说明：

• 可以在 CLAUDE.md 中使用 @path/to/import 导入其他规则文件；
• .claude/rules/ 支持通过 符号链接（symlink） 共享规则；
• 导入内容可以 递归展开，符号链接会被正常解析。

这使得团队可以构建 可复用的规则包（rule packages） ，例如：

• company-security-rules
• frontend-react-rules
• backend-api-rules
• python-testing-rules

每个项目只需引用需要的规则模块，而无需重复维护整套规范。这种做法带来两个直接收益：

1. 规则可以集中维护与统一更新；
2. 不同项目共享相同的工程语言，使 Agent 在多个仓库中的行为更加一致。

方式

• 一个单独的仓库
• monorepo
• submodule

三、快速获取代码库概览

提示

• 从广泛的问题开始，然后缩小到特定领域
• 询问项目中使用的编码约定和模式
• 请求项目特定术语的词汇表

四、提示词

1. 请求高级概览：给我这个仓库的概览
2. 深入了解特定组件：解释这里使用的主架构模式 ｜ 关键数据模型是什么? ｜ 认证是如何处理的?

五、查找相关代码

提示

• 明确说明需要查找的内容
• 使用项目中的语言

5.1 提示词

1. 要求 Coding Agent 查找相关文件：找到处理用户认证的文件
2. 获取有关组件如何交互的上下文：这些认证文件是如何协同工作的?
3. 理解执行流程：追踪从前端到数据库的登录过程

六、修复 bug

提示

• 告诉 Claude 重现问题的命令并获取堆栈跟踪
• 提及重现错误的任何步骤
• 让 Claude 知道错误是间歇性的还是持续的

6.1 提示词

1. 与 Coding Agent 分享错误：我在运行 npm test 时看到一个错误。
2. 请求修复建议：建议如何重构 utils.js 以使用现代 JavaScript 功能
3. 安全地应用更改： 重构 utils.js 以使用ES2024特性，同时保持相同的行为
4. 验证重构：运行重构代码的测试

七、使用专门的 subagents

提示

• 在 .coding agent/agents/ 中创建项目特定的 subagents 以供团队共享
• 使用描述性的 description 字段来启用自动委派
• 限制工具访问权限为每个 subagent 实际需要的内容

7.1 提示词

1. 查看可用的 subagents：/agents
2. 自动使用 subagents：审查我最近的代码更改以检查安全问题 & 运行所有测试并修复任何失败
3. 明确请求特定的 subagents：使用 code-reviewer 子代理检查认证模块，由 debugger subagent 调查用户为何无法登录的原因
4. 为工作流创建自定义 subagents : /agents，然后选择 Create New subagent 并按照提示定义

八、使用 Plan Mode 进行安全的代码分析

Plan Mode 是一种工作模式，它会限制 Coding Agent 只使用 只读操作（read-only tools）

8.1 什么时候应该使用 Plan Mode

• 复杂功能开发：当一个任务涉及多个文件或多步修改时
• 代码库分析：在动手修改代码之前，希望先系统地理解项目结构
• 方案讨论：希望先与 Claude 反复确认需求和实现思路，再开始执行

提示词

1. 我需要重构我们的认证系统以使用OAuth2。请制定一份详细的迁移计划。
2. 关于向后兼容性呢?
3. 我们该如何处理数据库迁移?

按 Ctrl+G 在默认文本编辑器中打开计划，可以在 Claude 继续之前直接编辑它。

九、编写测试用例

9.1 提示词

1. 识别未测试的代码：在 index.tsx 中查找未被测试覆盖的函数
2. 生成测试框架：为通知服务添加测试用例
3. 添加有意义的测试用例：为通知服务中的边缘条件添加测试用例
4. 运行并验证测试：运行新的测试并修复任何失败项

十、创建拉取请求

10.1 提示词

1. 总结更改：总结我对认证模块所做的更改
2. 生成拉取请求：创建一个 pr
3. 审查和细化：通过提供更多关于安全改进的背景来增强PR描述

十一、处理文档

提示：

• 指定您想要的文档样式（JSDoc、docstrings 等）
• 请求文档中的示例
• 请求公共 API、接口和复杂逻辑的文档

11.1 提示词

1. 识别未记录的代码：在auth模块中找到没有适当JSSDoc注释的函数
2. 生成文档：为auth.js中的未文档化函数添加JSDoc注释
3. 审查和增强：通过提供更多上下文和示例来改进生成的文档
4. 验证文档：检查文档是否符合我们的项目标准

十二、添加图像

12.1 提示词

1. 将图像添加到对话：ctrl + v
2. 让 Coding Agent 分析图像
   • 这张图片显示了什么?
   • 描述此截图中的UI元素
   • 这个图表中是否存在任何问题元素?
3. 结合图像描述问题
   • 这是错误的截图。是什么导致了它?
   • 这是我们当前的数据库架构。我们应该如何为新功能修改它?
4. 从视觉内容获取代码建议
   • 生成CSS以匹配此设计实际样子
   • 要重新创建此组件，应使用哪种HTML结构?

十三、引用文件和目录

1. 解释@src/utils/auth.js的逻辑？
2. @src/components的目录结构是什么样的？
3. 总结@github:repos/owner/repo/issues

十四、总结

• 修复 bug：与 Coding Agent 分享错误：我在运行 npm test 时看到一个错误。 -> 请求修复建议：建议如何重构 utils.js 以使用现代 JavaScript 功能 -> 安全地应用更改： 重构 utils.js 以使用ES2024特性，同时保持相同的行为 -> 验证重构：运行重构代码的测试
• 使用专门的 subagents：查看可用的 subagents：/agents -> 自动使用 subagents：审查我最近的代码更改以检查安全问题 & 运行所有测试并修复任何失败 -> 明确请求特定的 subagents：使用 code-reviewer 子代理检查认证模块，由 debugger subagent 调查用户为何无法登录的原因 -> 为工作流创建自定义 subagents : /agents，然后选择 Create New subagent 并按照提示定义
• 使用 Plan Mode 进行安全的代码分析：Plan Mode 是一种工作模式，它会限制 Coding Agent 只使用 只读操作（read-only tools）
• 编写测试用例：识别未测试的代码：在 index.tsx 中查找未被测试覆盖的函数 -> 生成测试框架：为通知服务添加测试用例 -> 添加有意义的测试用例：为通知服务中的边缘条件添加测试用例 -> 运行并验证测试：运行新的测试并修复任何失败项
• 创建拉取请求：总结更改：总结我对认证模块所做的更改 -> 生成拉取请求：创建一个 pr -> 审查和细化：通过提供更多关于安全改进的背景来增强PR描述
• 处理文档：识别未记录的代码：在auth模块中找到没有适当JSSDoc注释的函数 -> 生成文档：为auth.js中的未文档化函数添加JSDoc注释 -> 审查和增强：通过提供更多上下文和示例来改进生成的文档 -> 验证文档：检查文档是否符合我们的项目标准