249 lines
6.8 KiB
Markdown
249 lines
6.8 KiB
Markdown
# 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/**：内部插件配置和缓存文件不在操作范围内。
|