note-taking

笔记记录

此技能可帮助 AI Agent 管理完整的笔记记录工作流：创建结构化笔记、为现有笔记追加内容、使用标签和类别整理笔记、按主题搜索和检索笔记，以及将笔记综合整理成摘要。笔记以 Markdown 文件的形式存储在可配置的目录中，并遵循便于浏览和检索的命名约定。此技能支持多种笔记类型，包括会议笔记、每日日志、研究笔记、灵感记录和项目文档。

工作流

1. 确定笔记类型和结构： 根据用户的请求，确定合适的笔记类型——会议笔记、灵感记录、研究笔记、每日日志或项目笔记。每种类型都有推荐模板，包含相关章节（例如，会议笔记包含参会者、议程、讨论内容和待办事项；研究笔记包含来源、主要发现和问题）。

2. 创建或查找笔记： 通过搜索笔记目录中的文件名和内容，检查是否已存在相关笔记。如果用户想要补充现有主题的内容，则打开该笔记并追加内容。如果是新主题，则使用描述性且带日期前缀的文件名创建新文件（例如，2026-02-12-sprint-planning.md）。

3. 编写结构化内容： 使用清晰的 Markdown 格式组织笔记内容：用标题划分章节，用项目符号列出内容，用复选框标记待办事项，并用粗体标注关键术语。在顶部添加元数据（日期、标签、相关笔记），以便日后检索。

4. 使用标签和链接整理： 在笔记的元数据中添加标签，以便按主题、项目或类型筛选。适用时，添加相关笔记的链接，构建互联的知识库。

5. 检索并综合整理： 用户询问信息时，按文件名、标签或内容搜索笔记。对于宽泛的问题（“我们本月讨论过哪些关于身份验证的内容？”），将相关笔记综合整理成摘要，而不是直接返回原始文件内容。

用法

告诉 Agent 要记录哪种笔记，并提供内容。Agent 会创建或更新相应文件。

Create meeting notes for today's sprint planning with the Backend Team.
Attendees: Alice, Bob, Carol. We discussed the v2.1 release timeline,
assigned the payment bug to Bob, and decided to defer dark mode to v2.2.

示例

示例 1：包含待办事项的会议笔记

用户请求：

记录今天设计评审会议的笔记。 参会者：Sarah（设计负责人）、Tom（前端）、Lisa（PM）。 我们评审了新的仪表板模型图。Sarah 展示了三种布局方案。 团队选择了方案 B（侧边栏导航）。Tom 提出了对移动设备适配性的担忧——我们需要在平板电脑上进行测试。Lisa 确认截止日期是 3 月 1 日。待办事项：Tom 将在 2 月 20 日前制作一个响应式原型。Sarah 将使用新的导航组件更新设计系统。 Lisa 将安排在 2 月 25 日进行后续评审。

Agent 创建文件： notes/2026-02-12-design-review.md

文件内容：

---
date: 2026-02-12
type: meeting
tags: [design, dashboard, ui]
attendees: [Sarah, Tom, Lisa]
related: []
---

# Design Review — Dashboard Redesign

**Date:** 2026-02-12
**Attendees:** Sarah (design lead), Tom (frontend), Lisa (PM)

## Discussion

- Sarah presented three layout options for the new dashboard.
- **Decision:** Team selected **Option B** — sidebar navigation layout.
- Tom raised a concern about mobile responsiveness, particularly on tablets.
- Lisa confirmed the ship deadline: **March 1, 2026**.

## Action Items

- [ ] **Tom** — Build a responsive prototype of Option B by Feb 20
- [ ] **Sarah** — Update the design system with the new sidebar nav component
- [ ] **Lisa** — Schedule follow-up design review for Feb 25

## Open Questions

- How does the sidebar behave on tablet screen sizes (768px-1024px)?
- Should we support a collapsed sidebar state for smaller viewports?

---

示例 2：跟踪来源的研究笔记

用户请求：

我正在研究 PostgreSQL 的连接池策略。请记录我目前的发现： PgBouncer 是最受欢迎的外部连接池工具，支持会话、事务和语句三种连接池模式。对于大多数 Web 应用，推荐使用事务模式，因为它会在事务之间重用连接，通常可将连接数量减少 10 倍。但事务模式不支持预处理语句，这会导致某些 ORM 无法正常工作。Pgpool-II 是一种替代方案，还支持负载均衡和复制，但配置起来更复杂。Postgres 内置的连接数限制通常默认为 100。Supabase 发布了一篇博客文章，介绍了他们如何使用事务模式下的 PgBouncer 和 Supavisor 处理 100 万以上的连接。

Agent 创建文件： notes/2026-02-12-postgres-connection-pooling.md

文件内容：

---
date: 2026-02-12
type: research
tags: [postgresql, connection-pooling, database, infrastructure]
related: []
---

# PostgreSQL Connection Pooling Strategies

## Key Findings

### PgBouncer
- **Most popular** external connection pooler for PostgreSQL.
- Three pooling modes: session, transaction, and statement.
- **Transaction mode** is recommended for web applications — reuses connections between transactions.
- Typically **reduces connection count by ~10x**.
- **Limitation:** Transaction mode does not support prepared statements, which can break some ORMs (notably older versions of ActiveRecord and SQLAlchemy).

### Pgpool-II
- Alternative to PgBouncer with additional features: load balancing, automatic failover, and replication.
- **More complex** to configure and operate than PgBouncer.
- Better suited for setups that need read replica routing in addition to pooling.

### Built-in PostgreSQL Limits
- Default `max_connections` is **100**.
- Increasing this significantly (e.g., to 1000+) causes memory and performance issues due to per-connection overhead.

### Production Scale Reference
- **Supabase** handles 1M+ connections using PgBouncer (transaction mode) with their custom Supavisor proxy.
- Source: Supabase engineering blog.

## Open Questions

- What is the performance overhead of PgBouncer itself at high connection counts?
- How do modern ORMs (Prisma, Drizzle) handle the prepared statement limitation in transaction mode?
- When does Pgpool-II's complexity become justified over PgBouncer?

## Sources

- Supabase Blog: "Scaling Postgres to 1M connections"
- PgBouncer documentation: https://www.pgbouncer.org/
- PostgreSQL documentation: Connection settings

最佳实践

• 使用一致的命名约定。 为所有笔记文件添加 ISO 日期前缀（YYYY-MM-DD-topic.md），以便按时间顺序排序并避免文件名冲突。
• 在每条笔记中添加元数据。 在 YAML frontmatter 中加入标签、日期、类型和相关笔记链接，让笔记便于搜索且相互关联。没有元数据的笔记日后很难找到。
• 将待办事项记录为复选框。 使用 Markdown 复选框（- [ ]），并将负责人姓名加粗，方便快速浏览待办事项并跟进直至完成。
• 以用户的口吻撰写笔记，而不是用你自己的口吻。 Agent 应忠实记录用户的想法和决定，不要加入自己的观点，也不要以改变原意的方式改写。
• 链接相关笔记。 创建与现有笔记相关的主题笔记时，在 related 字段中添加交叉引用。这样可以逐步构建自然的知识图谱。
• 检索时进行总结，不要直接倾倒原始文件。 用户询问“我们对仪表板有哪些决定？”时，应综合相关笔记，给出简洁的回答，而不是返回每个匹配文件的全文。

边缘情况

• 内容重叠或重复的笔记： 如果用户创建的主题笔记与现有笔记重复，先检查现有内容。建议在现有笔记中追加内容，而不是创建重复笔记。如果用户希望保留两条笔记，请确保文件名不同。
• 篇幅很长的会议笔记： 对于时长超过 1 小时且讨论内容丰富的会议，应使用清晰的章节标题来组织笔记，并考虑在顶部添加摘要部分。超过 200 行的笔记应拆分为可独立阅读的章节。
• 包含敏感信息的笔记： 如果笔记中包含密码、API 密钥或个人数据，应提醒用户，并建议不要将这些内容存储在纯文本 Markdown 文件中。建议使用密钥管理器保存凭据，并在笔记中对敏感字段进行脱敏处理。
• 含糊的检索请求： 用户询问宽泛主题的笔记时（例如“数据库相关内容”），应同时按标签和内容搜索，列出匹配结果，并请用户缩小范围，而不是猜测他们要找哪条笔记。
• 尚未初始化的笔记目录： 如果首次使用时笔记目录不存在，应自动创建该目录，并添加一个 README.md 说明目录结构和约定。不要默默失败。
• 笔记中的待办事项相互冲突： 综合多条会议笔记时，应检查是否存在相互冲突或已被取代的待办事项（例如，一次会议提出“推迟深色模式”，之后的会议提出“开始开发深色模式”）。应呈现最近的决定，并说明变化。