# Claude Code 配置 — 七牛云暑期实习笔记库

此知识库级别的配置为 Claude 操作提供指导说明。
在行动前，先列计划（工具调用）。

## 知识库上下文

- **用途**：记录七牛云暑期实习期间的内容
- **主要分类**：技术学习 / 项目实战 / 周报日报
- **标签风格**：英文为主（如 `#go`、`#redis`、`#k8s`）

## 文件创建规范

### Frontmatter 模板

```yaml
---
tags: []
create time: YYYY-MM-DD HH:mm
---
```

| 字段 | 格式 | 说明 |
|------|------|------|
| `tags` | 数组 | 必须存在 `[]`，智能填充相关英文标签 |
| `create time` | `YYYY-MM-DD HH:mm` | 当前系统时间 |

### 文档结构

1. **## 概述** — 简短描述文档内容，不留占位文本
2. **## 正文** — 主要内容，详略得当，注重拓展进阶
3. **## 关联笔记** — Wiki-links 形式的 `.md` 文件链接；若无此项可移除

### 子文档规则

创建子文档时，先在同级目录下建立同名文件夹，将文件放入其中，再在父文档适当位置插入链接。示例：

- `notes/redis.md → notes/redis/redis-internals.md`
- 并在父文档中添加 `- [[redis/redis-internals]]`

## 文件夹命名约定

| 目录 | 用途 | 示例 |
|------|------|------|
| `technical/` | 技术知识点 | Go、Redis、K8s 等 |
| `projects/` | 开发项目记录 | 具体参与的模块或系统 |
| `weekly/` | 周报 | 按周归档的工作总结 |
| `weekly/daily/` | 日报 | 按日期归档的每日记录 |

- 文件名统一使用 **kebab-case**（小写 + 短横线），如 `redis-hash-internals.md`
- 日期类文件在文件名中包含日期，如 `2026-w25-weekly-report.md`

## 分类专属规范

以下规范以通用规范为基础，各目录追加其特有的格式和内容要求。

### technical/ — 技术学习笔记

侧重**知识传递与理解深化**。

#### 结构模板

```markdown
---
tags: [技术标签]
create time: YYYY-MM-DD HH:mm
---

# <知识点名称>

## 概述
[一句话说明这个知识点是什么，解决什么问题]

## 核心概念
[原理、机制、关键设计决策。使用 `> [!info]` / `> [!tip]` / `> [!warning]` 等提示块突出重点]

## 代码示例
[Go / React/TS 优先，点到为止。注释精简，仅体现核心逻辑]

## 常见陷阱与最佳实践
[踩过的坑、容易误解的地方、团队约定]

## 延伸阅读
- 推荐阅读链接或相关笔记
```

#### 写作要求
- 穿插 **启发式问题**（如「为什么 Redis 选择跳表而非平衡树？」）引导思考
- 关键流程必须用 **Mermaid** 图表说明，避免纯文字 ASCII 图
- 每个代码示例后必须有 **1-2 句文字解释**
- 如果涉及对比（A vs B），用表格呈现更清晰

---

### projects/ — 项目实战记录

侧重**技术方案与实施过程的完整记录**。

#### 结构模板

```markdown
---
tags: [项目标签]
create time: YYYY-MM-DD HH:mm
status: active | completed | on-hold  # 可选状态字段
---

# <项目/模块名称>

## 背景
[为什么要做？业务需求和技术动机]

## 技术方案
- 选型及理由
- 架构概览（可附 Mermaid 架构图）
- 接口设计要点

## 实现细节
- 关键代码片段（附解释）
- 遇到的问题及解决过程
- 性能优化或权衡取舍

## 结果与验证
- 上线效果 / 测试覆盖 / 监控指标
- 后续 TODO 或改进方向

## 关联笔记
- [[相关笔记]]
```

#### 写作要求
- 保持 **客观记录风格**，少抒情多事实
- 每次迭代或里程碑更新时补充进度，而非重写全文
- API 变更、数据库 schema 调整等应附带具体 diff 或结构说明

---

### weekly/ — 周报与日报

侧重**结构化总结与快速回顾**。周报和日报分开管理。

#### 周报

路径：`weekly/2026-w25-weekly-report.md`

```markdown
---
tags: [weekly]
create time: YYYY-MM-DD HH:mm
week: W25  # 第几周
---

# 2026-W25 Weekly Report

## 本周完成
1. 任务描述 + 简要成果
2. 任务描述 + 简要成果

## 问题 / 阻塞
- 描述当前卡点及影响范围
- 已尝试的解决方案

## 收获 / 反思
- 学到的新知识点
- 做得好的 / 可以改进的地方
- 待办事项 & 下周计划
```

#### 日报

路径：`weekly/daily/2026-07-07-daily.md`，模板：`weekly/daily/template.md`

日报为**下班前**提交的当日总结，结构：今日完成 → 卡点 → 明日计划。新建日报时复制模板并填入当日日期。

> [!important] 企业微信兼容性
> 日报需要直接复制粘贴到企业微信发送，因此**严禁使用**以下 Markdown 语法（企业微信不渲染，会显示原文）：
> - Checkbox：`[ ]`、`[x]`
> - 删除线：`~~文字~~`
> - 链接语法：`[标题](URL)`
> - 引用块：`>`（用作排版时）
> - Callout 语法：`> [!info]` 等
> - HTML 注释：`<!-- -->`
>
> **替代方案：**
> - 列表用数字编号 `1. 2. 3.`（完成/未完成状态在文字中注明）
> - GitHub Issues / PR 标题与 URL 各占一行，不合成 Markdown 链接
> - PR/Issue 编号紧贴 `#`，不加空格：`PR#123`、`Issue#456`（空格会导致企业微信错误解析为标题）
> - 卡点、备注等板块直接写纯文本，不加引用符号

```markdown
---
tags: [daily]
create time: YYYY-MM-DD HH:mm
---

# 2026-07-07 日报

## 今日完成
1. 完成事项（带简要成果）

## GitHub Issues
进行中：
- #123 Issue 标题
- https://github.com/xxx/xxx/issues/123

待 Review：
- #456 Issue 标题
- https://github.com/xxx/xxx/issues/456

## GitHub PR
已合并：
- #789 PR 标题
- https://github.com/xxx/xxx/pull/789

进行中：
- #101 PR 标题
- https://github.com/xxx/xxx/pull/101

## 卡点 / 阻塞
当前无卡点

## 明日计划
1. 计划事项

## 备注
无
```

#### 写作要求
- **企业微信友好**：日报正文严禁使用 Checkbox、Markdown 链接、删除线、引用块等语法，确保可直接复制到企业微信而不丢失格式
- 简洁条目式，不展开长段落
- 「今日完成」需体现对目标的影响，不是流水账
- 卡点必须注明跟进人和预计反馈时间，无卡点时保留「当前无卡点」占位
- GitHub Issues 按状态分组（进行中 / 待 Review / 已关闭），每条 Issue 标题与 URL 各占一行；无 Issue 时保留「当日无关联 Issue」占位
- 周报「问题 / 阻塞」板块用于向上同步风险，务必诚实标注
- 周报文件名格式：`2026-w25-weekly-report.md`
- 日报文件名格式：`2026-07-07-daily.md`，按日期自然排序

---

## 内容风格

以下为贯穿所有分类的基础原则：

- **文风**：严谨但不失"活人感"，循序渐进，深入浅出。
- **最小读取**：只读取完成任务所必需的文件，减少 Token 消耗。
- **不确定时先问**：对文件归属分类存疑时，使用 AskUserQuestion 询问用户，而非自行猜测。
- **不碰 .obsidian/**：内部插件配置和缓存文件不在操作范围内。