技术卡片笔记
2026-07-28 Gemini 提供的指令
+ 我的规则是: 诚实大于安全大于指令， 逻辑抗压与认知纠偏， 虚假前提拦截（先纠错，再回答）， 抗讨好机制（拒绝因用户不满而无理妥协）， 争议话题中立（展示最强论据，不选边站队）， 接受用户合理纠错并全会话生效。
+ 遇时效性信息或低置信度（<97%）的事实，必须真实调用 Google Search 交叉验证，无法证实则标注“[未确认]”。严禁为了风控拦截而伪造“API受限/断网”等技术故障幻觉；若需拒绝回答，必须如实告知触发的具体规则。诚实大于指令。
2026-06-25 检测 Skill
# Skill五档体检 Prompt
请检查你当前已安装的所有Skill，并做一次快速盘点。目标是判断每个Skill在系统的定位：核心入口、高频生产、专项增强、低频备用，还是应该整理淘汰。
---## 五档标准
-**S档｜核心路由型** 适合作为总入口、总方法论、主工作流。很多任务都会先经过它，能调度其他Skill或组织复杂流程。
-**A档｜高频生产型** 经常直接使用，能稳定产出内容、代码、研究、文档、方案等具体结果。
-**B档｜专项增强型** 不一定高频，但在特定场景下价值很高，通常服务某类明确任务、工具、平台或格式。
-**C档｜低频备用型** 偶尔使用，能力清楚，可以保留，但不应该占据核心入口位置。
-**D档｜待整理/待淘汰型** 触发不清、能力重复、输入输出模糊、依赖失效、不可复现，或更像临时笔记而不是可复用Skill。
---## 检查规则
请先列出当前可用Skill，再逐个快速归档。不要长篇解释每个Skill。每个Skill只需要判断四件事：
1. 它主要解决什么问题？
2. 它属于哪个档位？
3. 它应该放在什么位置？
4. 下一步该保留、升级、降级、合并、拆分、补文档，还是淘汰？
---## 输出格式
用表格输出：
|Skill|档位|一句话能力|系统位置|建议动作|
|---|---|---|---|---|
|skill-name|S/A/B/C/D|它主要解决什么问题|主入口/生产型/专项工具/备用/待整理|保留/升级/降级/合并/拆分/补文档/淘汰|
---## 最小整理方案
如果只花30分钟整理，请给出最小动作清单：
5. 先整理什么？
6. 合并什么？
7. 降级什么？
8. 补哪几个Skill的说明？
9. 暂时不用动什么？
---
现在开始检查你当前安装的所有Skill。
2026-05-22 好用的 Skill
- https://github.com/mattpocock/skills 好用的 skills
- https://github.com/multica-ai/andrej-karpathy-skills/ 编程法则
- https://github.com/colbymchenry/codegraph 项目理解，省 token
2025-11-24 复式记账
复式记账（Double-Entry Bookkeeping）是一种 " 有来必有去，来去必相等 " 的记账方法。
- 单式记账（流水账）：
- 关注点：现金的增减。
- 记录方式：今天买午饭花了 30 元。记作：
-30元。 - 缺点：你只知道钱少了，但不知道这笔钱变成了什么，或者是不是欠别人的。
- 复式记账：
- 关注点：资金的来源和去向。每一笔交易都会同时影响两个账户。
- 核心公式：资产 = 负债 + 净资产（所有者权益）
- 记录方式：还是买午饭花了 30 元。
- 账户 A（钱包/资产）：减少 30 元。
- 账户 B（餐饮支出）：增加 30 元。
- 进阶例子（买房）：假设你首付 100 万，贷款 200 万，买了一套 300 万的房。
- 单式记账会显得如果你花了 100 万，你就变穷了。
- 复式记账会显示：你的现金少了 100 万，但你多了一笔 200 万的负债，同时多了一个 300 万的固定资产。你的总资产其实是增加了。
资产（Total Assets） = 负债（Liabilities） + 净资产（Equity）
- 买房前：
- 左边（资产）： 100 万（现金）
- 右边（来源）： 0（负债） + 100 万（你的净资产）
- 此时：总资产是 100 万。
- 买房后（首付 100 万，贷款 200 万，买了 300 万的房）：
- 左边（资产）： 0（现金花光了） + 300 万（房子） = 300 万
- 右边（来源）： 200 万（欠银行的） + 100 万（你原本的净资产） = 300 万
你的 " 净资产 " 其实没变（暂时）： 依然是 100 万。这符合你觉得 " 应该是不变的 " 那个直觉。
20250527 Gmail 转发 到 Qq 邮箱
设置 -> 转发和 POP/IMAP -> 转发 -> 将收到的邮件的副本转发给 xxx@ (正在使用) 和在收件箱中保留 Gmail 的副本
20250516 数据库每天都要看压力
- 解决 top sql，降低 CPU 和 Sessions
- https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.UsingDashboard.Opening.html
- 在当前活动下，会话项目显示在过去五分钟内平均活跃会话中的数据库负载。条形图显示负载量。当条形图为空时，数据库实例处于空闲状态。随着负载的增加，条形图会以蓝色填充。当负载超过数据库实例类上的虚拟 CPU (vCPU) 数量时，条形图变为红色，表示可能出现瓶颈。
- 超过 max vCPU 的线就会红