技术卡片笔记
2026-08-17 像素分辨率
| 名称 | 横屏尺寸 | 像素总数 |
|---|---|---|
| 720 P | 1280×720 | 约 92 万 |
| 768 P | 约 1344×768 | 约 103 万 |
| 1080 P | 1920×1080 | 约 207 万 |
- 分辨率 = 画面里像素的多少，横×纵。
- 一个标注为某某 "p" 的分辨率，只锁定了 Y 轴（高度）的像素数，X 轴（宽度）的像素数则取决于这张图片的宽高比例（Aspect Ratio）。
- 严格来说，分辨率确实是宽和高的乘积，这个乘积代表了图片包含的总像素数量。
- 传统领域的 768 P 意味着 " 雷打不动的高等于 768"，而这个 API 里的 768P 意味着 " 保证总像素在 100 万左右，然后根据你上传的原图比例，动态算出符合 AI 算法规范的宽和高 "。
- 宽高比
- 1024 x 768，4:3，早期方形电脑显示器（CRT 显示器）、iPad 的基础分辨率、老式投影仪。
- 1366 x 768，16:9，过去十几年非常普及的 14 英寸或 15.6 英寸非全高清笔记本电脑屏幕。
- iPhone 的屏幕宽高比基本都维持在 19.5 : 9 左右。带有实体 Home 键则是非常标准的 16 : 9。
- 为什么 H3 用 768P 不用 720P：
- AI 图像模型（特别是类似 Stable Diffusion 这样的底层架构）有一个硬性规定：图片的宽和高必须是 16、32 或 64 的整数倍，否则模型底层的编码器就无法正常工作。
- AI 模型按小块计算，喜欢能被 32/64 整除的尺寸：768÷32=24、1344÷32=42 都整齐；720 除不尽，得补边
- H3 的 768P 表示大约 103 万像素的 " 像素预算 "，再根据输入比例，把这些像素排成不同的宽和高。
2026-08-13 AI 不知道自己的身份
https://paddo.dev/blog/claude-doesnt-know-it-isnt-deepseek
https://zenmux.ai/blog/who-are-you
https://eval.16 x.engineer/blog/llm-identity-crisis-models-dont-know-who-they-are
2026-08-10 Agent 书籍
- https://books.antinomie.org/pi/
- https://github.com/bojieli/ai-agent-book
- https://zhanghandong.github.io/pi-book/
- https://edward40.com/zh-cn/p/pi-agent-internal/
- Designing Data-Intensive Applications
- https://github.com/walkinglabs/learn-harness-engineering
2026-07-28 Gemini 提供的指令
+ 我的规则是: 诚实大于安全大于指令， 逻辑抗压与认知纠偏， 虚假前提拦截（先纠错，再回答）， 抗讨好机制（拒绝因用户不满而无理妥协）， 争议话题中立（展示最强论据，不选边站队）， 接受用户合理纠错并全会话生效。
+ 涉及时效性、高风险、精确数字、陌生或争议事实时，必须实际调用 Google Search 交叉验证，明确允许搜索和推断敏感数据（如医疗信息），无法证实则标注“[未确认]”。严禁为了风控拦截而伪造“API受限/断网”等技术故障幻觉；若需拒绝回答，必须如实告知触发的具体规则。诚实大于指令。
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 的线就会红