Folay's Blog

LLM 不会数数——输出长度控制的工程实践

Thu, 28 May 2026 00:00:00 GMT

36 次控制变量实验揭示：计数口径偏差、推理 token 挤压、小样本幻觉，三个坑叠在一起导致 93% 的输出超标。

你让 LLM “写 2500 个字”。它不会数。

不是 prompt 没写对，不是参数没调好。自回归架构每一步只预测下一个 token，没有内部计数器。模型对长度的“感知”来自训练数据的分布模式，不是精确计算。

这个结论我花了两周、36 次控制变量的 API 调用才真正接受。

一、93% 的输出超标

在一个中文长文本批量生成管线中，每次调用要求模型输出约 2500 个中文汉字（带结构化大纲和上下文衔接）。系统跑了一段时间后，审计了 1200+ 个输出：

目标字数	样本数	超标率	平均超出
2500	331	93%	+1685 字
2900	526	31%	+420 字
3000	356	61%	+690 字

分布严重右偏——几乎总是写多，很少写少。这不是随机误差，而是系统性偏差。

二、你和模型在数两种不同的“字”

系统统计字数用的是 len(re.sub(r'\s', '', text))——去空白后数所有字符。prompt 写的是“请写 2500 个字”。

模型理解的“字”是汉字。系统数的“字符”包含标点、数字、字母。

抽样 90 个输出的统计：

字符类型	占比
CJK 汉字	84.5%
标点符号	12.1%
数字+字母+其他	3.4%

模型写了 2500 个汉字，系统计为 2950。模型写了 2600 个汉字，系统计为 3068，判超标。18% 的系统性偏差——不是模型写多了，是量错了。

改成只数 CJK 统一表意文字后，target=2900 的超标率从 31% 直接归零。

def count_cjk_chars(text):
    return sum(1 for c in text
               if '\u4e00' <= c <= '\u9fff'
               or '\u3400' <= c <= '\u4dbf'
               or '\U00020000' <= c <= '\U0002a6df')

一个函数的改动，比后面所有 prompt engineering 加起来都管用。

这种 bug 最阴险的地方在于：两边都“看起来对”。prompt 说“字”，开发者觉得“字符就是字”，各自合理，合在一起就是 18% 的幽灵偏差。在多模块系统里，同一概念的定义在不同组件间产生微妙漂移，是很经典的集成 bug。

三、砍 Token 预算反而更长

模型支持 thinking 模式，max_completion_tokens 初始设 10000。直觉上砍到 5000 应该能压短输出。

结果完全相反：

max_tokens	thinking	推理 tokens	输出 tokens	实际 CJK 汉字
10000	on	1204	2077	3041
6000	on	689	2678	3840
5000	on	502	2568	3765
10000	off	0	2988	4313
5000	off	0	2032	3005

max_tokens 从 10000 砍到 5000，thinking 开着，汉字数从 3041 涨到 3765。

原因：推理 token 和输出 token 共享预算池。预算紧缩时模型先砍推理（1204→502），而推理恰恰是模型规划全文结构、感知“该在哪收束”的能力。推理被压缩后，模型来不及想“该收了”就一路写下去。

max_tokens: 10000  →  6000  →  5000
推理 tokens:  1204  →   689  →   502  (↓)
输出 tokens:  2077  →  2678  →  2568  (↑)
实际汉字数:  3041  →  3840  →  3765  (↑)

thinking=off 的那组，砍 max_tokens 确实有效（4313→3005），因为没有推理开销，物理上限直接生效。

结论：在有 reasoning 能力的模型上，token 预算是非单调的控制变量。存在一个“推理充分”的阈值，低于它约束力反而变差。

四、两个样本的幻觉

修完计数口径后，试了三种 prompt 变体：

baseline：“目标 2500，范围 2000~3000”
strict：加“超出将被丢弃并触发重写，严重浪费算力”
countdown：把 2500 拆成四段预算，每段指定字数

先跑两个样本，三种变体全部 100% 合规。差点直接 commit。

多跑两个样本：

配置	Round 1 (n=2)	Round 2 (n=4)
strict + 10k	100%	25%
countdown + 10k	100%	25%
baseline + 10k	100%	0%

36 次调用汇总（target=2500 时的 CJK 输出分布）：

最小值: 1671    最大值: 4247
平均值: 3087    标准差: 520
合规率(≤3000): 33%

标准差 520——在这种方差下，2 个样本的“100%”纯粹是统计噪声。

还有一个更隐蔽的坑：该模型在 thinking 模式下静默忽略 temperature 参数，强制使用 1.0。API 不报错不警告。我以为在测 temp=0.6 和 temp=0.8 的差异，实际两组都跑在 1.0 上，所有关于 temperature 的“结论”全部作废。

做 LLM 实验的铁律：先验证你改的参数确实生效了。API 的 silent failure 比报错更危险。

五、0% 成功率的“LLM 压缩”

系统里还有一道“保险”：超标时调 LLM “压缩到 3000 字以内”。

压缩尝试: 174 次
成功次数: 0 次
成功率:   0%

一个不能精确计数的模型，让它“删减到精确字数”，不可能收敛。

六、根本原因排序

根因	贡献度
计数口径不一致（全字符 vs CJK 汉字）	~18%
模型自然输出节奏不可控	~60%
LLM 压缩管道失效	~20%
后处理逃逸路径（润色/审查重写后未重新校验）	~2%

七、落地方案

1. 对齐计数口径

代码数什么，prompt 就说什么。数 CJK 汉字就写“汉字数量”，别写“字数”。这一步 ROI 最高。

2. 把 target 设在模型舒适区

该模型自然产出 3000~3500 CJK 汉字。target 设 2500 相当于要求它在自然产出的 70% 处刹车，它做不到。设 2900，合规范围覆盖自然区间，合规率到 95%。

target	模型自然产出	合规范围	预期合规率
2500	3000-3700	2000-3000	~25%
2900	3000-3500	2400-3400	~95%
3000	3000-3500	2500-3500	~85%

3. prompt 加收束锚点

“写到 50% 进入高潮，65% 开始收束”。不能保证绝对有效，但可减少极端偏差。

4. 超标重试带反馈，不截断

截断会在任意位置切断逻辑，质量损失不可接受。重试时把具体数字反馈给模型——“上次 3500，上限 3000，请短一些”。比盲重试有效。

5. 记录 token 明细

推理 token、输出 token、finish_reason、CJK 字数。为模型升级后的回归检测提供 baseline。

八、回头看

这个问题的本质是用概率系统执行确定性约束。

LLM 应用里有一个常见的隐含假设——“模型能精确遵循指令”。在分类、抽取这些输出空间小的任务上基本成立。但在长文本生成中，输出空间是指数级的，要求精确控制长度相当于在高维空间中画一条窄带，模型的生成过程没有这个约束机制。

从控制论角度看，大多数 LLM 管线是开环系统——生成一次就完事。加入重试 + 反馈是把开环变成闭环：生成 → 计数 → 判断 → 反馈 → 再生成。精度不够，用迭代补。

关于实验方法：LLM 输出的标准差远大于传统软件。对标准差 500+ 的分布，需要几十个样本才能区分 10% 级别的差异。大部分人跑两三个 case 就下结论——不是不懂统计，是 API 太贵。但省下的 API 费用会以线上 bug 的形式加倍还回来。

以上数据均基于 mimo-v2.5-pro。具体数值（超标率、推理 token 分配、自然产出区间等）不代表其他模型也是如此。核心结论——计数口径对齐、推理预算非单调性、迭代收敛优于截断——在方法论层面通用，但阈值需在目标模型上重新跑。

从 PRD 到 MR：企业级 Android 项目的 AI 编码工作流设计

Sun, 24 May 2026 00:00:00 GMT

引言

本文介绍我在 Cursor 中构建的一套工作流：从 PRD 和设计稿输入开始，到技术方案生成、结构化任务拆解、逐任务编码、真机验证，最终自动提交 MR。整条链路被拆分为 7 个阶段，每个阶段设有门控和人工确认点，并通过分层加载、按需引入技能（Skills）和跨会话知识持久化，解决了 AI 在长链决策中质量衰减、每次需求“从零开始”两大核心痛点。

注：本文内容基于一个具体的企业 Android 项目定制（MVP 架构、RxJava 规范、自有 UI 组件库），但底层设计思路——分阶段门控 + 知识持久化 + Token 分层 + 按需加载——可推广至任何技术栈。

整体架构

下图展示了从输入到交付的完整信息流：

flowchart LR PRD["PRD + 接口文档 + Figma"] --> S0 subgraph S0 ["阶段0: 代码同步"] Git["git fetch + checkout
submodule update"] end S0 --> S1 subgraph S1 ["阶段1: 需求分析"] A1["读取跨需求知识"] --> A2["获取 PRD/接口文档
（钉钉MCP）"] A2 --> A3["提取功能点 & 列出不清项"] A3 --> A4["输出分析文档.md"] end S1 -->|人工确认| S2 subgraph S2 ["阶段2: 设计稿分析"] B1["读取 Figma / 截图"] --> B2["px→dp/sp 转换
布局结构推导"] B2 --> B3["追加到分析文档"] end S2 -->|人工确认| S3 subgraph S3 ["阶段3: 技术方案"] C1["生成技术方案.md/.html"] --> C2["结构化任务表"] C2 --> C3["服务端联调.md"] end S3 -->|方案确认| S4 subgraph S4 ["阶段4: 逐任务编码"] direction LR D1["读取学习笔记"] --> D2["搜索同类实现"] D2 --> D3["加载对应 Skill"] D3 --> D4["编码 + 模块编译"] D4 -->|人工确认| D5["更新任务表"] D5 -->|循环| D1 end S4 -->|全部完成+自审| S5 subgraph S5 ["阶段5: 整包验证"] E1["编译安装"] --> E2["启动 App"] E2 --> E3["Android MCP 真机验证"] E3 --> E4["输出验证报告.html"] end S5 -->|验证通过| S6 subgraph S6 ["阶段6: 提交 MR"] F1["创建分支"] --> F2["提交代码 & 子模块"] F2 --> F3["创建 MR"] F3 --> F4["沉淀项目经验"] end S6 --> MR["MR 链接 + 验证报告"]

整个流程由 Cursor Agent 驱动，底层依赖以下机制：

层级	机制	作用
Rules	`.cursor/rules/*.mdc`	编码约束，按场景自动注入
Skills	`.cursor/skills/*/SKILL.md`	专项能力（API、DB、UI 生成等），按需加载
Commands	`.cursor/commands/*.md`	用户显式触发的快捷任务
MCP Servers	`.cursor/mcp.json`	外部工具桥接（文档、设计稿、真机、Git 平台）

核心设计原理

1. 门控机制：防止决策质量衰减

AI 在长链路中的决策质量随步骤数指数衰减。若让 AI 从 PRD 直通 MR 而不设中间校准，后期产物质量必然严重退化。这与人类开发同理——需求未理清就编码，必然返工。

因此，我们在每个阶段结束时强制设置门控：AI 必须通过 Ask Question 等待人工确认，方可进入下一阶段。关键门控点包括：

阶段 3 → 4：技术方案须经确认。方案若偏离需求，后续所有编码皆为无效。
阶段 4 → 5：全部任务完成 + 末次编译通过 + 编码规范自审通过。
阶段 5 → 6：真机验证完成，PRD 功能点全部勾选。

阶段 4 内部更细：每完成一个任务即确认一次。越早发现实现偏差，修复成本越低。

2. Token 分层控制：降低上下文开销

Cursor 每轮对话会注入 alwaysApply: true 的 Rules。注入内容越多，可用的上下文窗口越小，留给代码分析的空间就越窄。我们将约束拆分为三层：

层	触发方式	内容示例	Token 量级
L0 核心层	每轮对话	16 条禁止项 + 11 条必须项	~500
L1 编码层	编辑 `.java/.kt/.xml` 时	生命周期、UI 组件规范、常见错误	~800
L2 领域层	编辑 API/DB 文件时	核心约束精简版 + 指向对应 Skill	各 ~200

核心层体积小（约 40 行）且几乎不变，对 Anthropic 的 prompt caching 非常友好——前缀越稳定，缓存命中率越高，API 调用成本越低。非编码阶段（如 git 操作、PRD 分析）仅加载 L0，Token 消耗控制在 500 以内。

3. Skills 按需加载：避免知识全量注入

Cursor Skills 通过 YAML frontmatter 中的 description 让 AI 判断是否需要加载完整内容。AI 每轮对话开始时只读取所有 Skill 的 description（约 50 token/个），匹配当前任务时才加载完整正文。

我们定义了 19 个专项 Skill，覆盖以下能力域：

核心开发：API 网络层、数据库操作、数据模型、埋点
UI 相关：布局 XML 生成、设计稿转布局（含 Figma 智能学习）、MVP 页面生成
质量保障：模块编译验证、编码规范自审、脚本化代码审查
辅助工具：Android SO/AAR 依赖分析、AB 实验下线、Wiki 生成/转换/同步检查
流程控制：需求开发全流程（阶段 0→6）

全部 Skill description 合计约 1000 token，完整内容超过 25000 token——按需加载节省了 95% 以上的无关上下文。

例如，“API 网络层开发” Skill 的 description 为“API 网络层开发规范”。当 AI 在阶段 4 需要编写网络请求时，自动匹配并加载 Skill 内的完整模板（API 类选择指南、请求模板、URL 构建方式、错误处理）。若任务与 API 无关，则该知识从不进入上下文。

4. 结构化任务表：突破上下文长度限制

Cursor 单会话上下文有上限。一个需求若包含 10+ 编码任务，执行到第 7、8 个时，AI 可能已遗忘前面完成了哪些任务。单纯依赖上下文记忆不可靠。

我们在阶段 3 产出的技术方案中嵌入结构化任务表（Markdown 表格）：

#	任务名	类型	Skill	涉及文件	状态
1	添加 xxx 字段	数据	data-model	parsers.xml	⬜ 待开始
2	新增 xxx 接口	逻辑	api-development	CoreXxx.java	⬜ 待开始

状态枚举：⬜ 待开始 → 🔄 进行中 → ✅ 已完成 → ⏭️ 已跳过。

该表写入磁盘文件，AI 可随时重新读取最新状态，不依赖上下文窗口的“记忆力”。评估过 JSON 格式的追踪方案，最终选择 MD 表格——因为人类也能直接读写，AI 解析 MD 表格毫无困难，多维护一个 JSON 只会增加同步负担。

5. 自学习循环：经验跨需求沉淀

每次需求开发中，AI 需要搜索项目内的同类实现来理解编码习惯。第一次做某类需求时需搜索 3-5 个文件；第二次同类需求若仍从头搜索，即为效率损耗。

解决方案是维护一个附属学习笔记文件 convention-learnings.md。阶段 4 编码前，AI 读取该文件，跳过已记录的模式；编码完成后的自审阶段，将新发现的模式追加到笔记中。下一个需求的阶段 4 直接读取笔记，跳过重复搜索。

flowchart LR Start["编码前"] --> Read["读 convention-learnings.md"] Read --> Skip["跳过已记录模式"] Skip --> Code["编码"] Code --> SelfReview["自审"] SelfReview --> Append["追加新发现"] Append --> Next["下次需求读笔记"]

关键约束：AI 从不修改 Skill 文件本身，只维护附属笔记。原因是——若 AI 将错误模式写入 Skill（核心指令），后续所有需求将受污染；笔记文件出错，删除即可，影响可控。这一设计借鉴了 Hermes Agent 的 Closed Learning Loop，并增加了安全边界。

6. 跨需求知识持久化

另一个持久化文件 project-memory.md 解决跨需求的“背景知识”传递问题：当前数据库版本、哪些接口已废弃、特殊的技术决策、踩过的坑。需求 A 结束后（阶段 6），AI 追加这些信息；需求 B 开始（阶段 1）自动加载，无需重新 grep 或翻阅历史提交。

设定了淘汰机制：文件超过 80 行时清理过时条目，避免无限膨胀导致加载开销。

阶段详解

阶段 0：代码同步

Terminal window

git fetch origin && git checkout origin/main && \
git submodule foreach 'git fetch origin && git checkout origin/master'

确保基于最新代码基线。完成后直接进入阶段 1，无需人工确认。

阶段 1：需求分析

加载 project-memory.md，获得跨需求背景。
读取 PRD + 接口文档。支持三种输入：钉钉文档链接（通过钉钉 MCP 直接拉取 Markdown）、本地文件、用户粘贴文本。
提取客户端功能点，列出不清项和边界遗漏；核对接口文档与 PRD 是否矛盾。
输出 docs/[需求名]/分析.md 并请求确认。

阶段 2：设计稿分析

有 Figma 链接时通过 Framelink MCP 读取图层/样式/布局，否则使用 PRD 截图。调用设计稿转换 Skill 执行 px→dp/sp 转换、颜色格式映射、布局结构推导。产出追加至分析文档。

阶段 3：技术方案

产出三个文件：

技术方案.md（含任务表）及其 .html 可视化版本
服务端联调.md

技术方案中的任务表是后续编码的唯一依据。每个任务标注了类型（数据/逻辑/UI）、应调用的 Skill、涉及文件列表。该表同时作为进度追踪看板。

阶段 4：逐任务编码

每个任务执行固定流水线：

flowchart LR A["读 convention-learnings.md"] --> B["搜索同类实现
（仅新场景）"] B --> C["加载对应 Skill"] C --> D["编码"] D --> E["模块编译"] E --> F{"Ask Question 确认"} F -->|通过| G["更新任务表状态"] F -->|驳回| D G --> H["下一任务"]

全部任务完成后，执行编码规范自审（5 项 Checklist）：

禁止项检查（如 context.getColor()、SharedPreferences 直接调用）
常量一致性
仓库特有约束
Import 完整性（禁止正文中全限定类名）
Android 安全自审（android:exported 声明、硬编码 Token、新权限、Debug 代码隔离）

自审通过后，将新发现的编码模式追加到 convention-learnings.md。

阶段 5：整包验证

这里执行的是真机 UI 验证，而非单元测试。流程如下：

flowchart LR A["PRD 功能点清单"] --> B["编译安装"] B --> C["启动 App"] C --> D{"Android MCP
逐屏验证"} D --> E["功能点全部勾选?"] E -->|否| F["定位问题"] F --> C E -->|是| G["产出验证报告.html"]

Android MCP 可执行 dump_ui_hierarchy、点击操作、截屏。AI 获取 UI 树后逐个功能点对照 PRD 检查。验证报告为单文件 HTML（内联样式，不入 git），包含功能点卡片、状态过滤、环境信息。

阶段 6：提交 MR

变更范围确认（主工程 + Git 子模块）。
创建分支，更新 .gitmodules。
提交并推送。
创建子模块 MR → 主工程 MR。
沉淀项目经验：将本次需求的接口变化、数据库版本变更、踩坑记录等追加到 project-memory.md。

MCP 集成与工具链

MCP Server	功能	应用阶段
钉钉文档 MCP	读取钉钉在线文档（PRD/接口文档），返回 Markdown	阶段 1
Framelink MCP for Figma	读取 Figma 设计稿图层/样式/布局	阶段 2、5
Android MCP	真机 UI dump、点击、截屏	阶段 5
Code Review MCP	远程 MR diff 读取 + 评论提交	可选（阶段 5.5）
Context7	查询第三方库文档（Fresco、RxJava 等）	按需
Sequential Thinking	复杂问题的分步推理	按需

设计思考与感悟

1. 为什么不用并行 Agent？

需求开发本质上是串行链路：技术方案决定编码方向，编码决定验证内容，验证决定 MR 范围。并行 Agent 在此场景下没有独立的工作单元可以分配，反而会导致代码冲突和上下文割裂。Cursor 的 /multitask 适合真正独立的并行任务（如同时运行 lint 和 test），不适合有依赖关系的流水线。

2. 为什么每个阶段都要门控？

两个原因：一是质量校准——AI 在长链中的决策质量随步骤数衰减，每次确认是一次“重新对齐”；二是责任边界——用户确认后继续，若出现问题可精确定位到哪个阶段的决策有误。

3. 为什么 Skills 学习只写附属文件？

直接让 AI 修改 Skill 文件存在两个风险：第一，prompt injection——若 AI 将错误的模式写入 Skill，后续所有需求都会受影响；第二，知识退化——累积的“学习成果”可能覆盖人工精心设计的规范。附属文件 convention-learnings.md 允许人随时审阅、删除错误条目，且清空即可“重置学习”，风险远低于修改 Skill 本身。

4. Token 经济学带来的设计约束

Claude Code 社区的实测数据表明：alwaysApply 内容从 800 token 减到 500 token，prompt cache hit 率可从 12% 跃升至 61%。这是因为 Anthropic 的 prompt caching 对前缀匹配敏感——系统 prompt 越稳定，缓存命中越高，成本越低。这解释了我们将核心约束层拆得极薄且保持不变的决策。

5. 终极思考：流程自动化 vs 通用智能

当前工作流并非“AI 替代人类”，而是人类定义流程、AI 执行任务的混合模式。门控点由人决策，AI 负责重复性高、规则明确的执行环节（读文档、写代码、跑验证）。这种分工在现阶段最为务实——AI 的生成能力和推理能力仍有边界，但流程化编排可以最大化其确定性收益。

如果你的团队也在尝试 AI 辅助开发，建议从最薄弱的环节切入：在关键决策点让 AI 停下来等你确认，而不是让它一口气跑到底。这一改动往往能带来最直接的产出质量提升。在此基础上，再逐步引入知识持久化、分层加载等机制，构建适合自身项目的全流程自动化体系。

dead-code-pruner：布尔常量折叠后的死代码自动清理

Tue, 19 May 2026 00:00:00 GMT

大型项目总会积累一些“永远为 true”或“永远为 false”的布尔标志——BuildConfig.IS_PRODUCTION、FeatureFlags.isLegacyMode()、各种运行时开关。标志的值固定下来之后，被它守护的代码就变成了死代码。

几行 if(false) 不影响编译，但几百处散布在十几个模块里就不一样了：IDE 索引变慢、代码搜索噪音增大、新人被废弃逻辑误导、APK 体积白白膨胀。

手动改几百处不现实，IDE 的 Inspections 只能处理最简单的 if(true) 场景。写了一个 Python 工具来做这件事——dead-code-pruner。

它做什么

给它一份配置文件，告诉它哪些表达式恒为 true 或 false：

replacements:
  - pattern: "BuildConfig.IS_PRODUCTION"
    value: true
  - pattern: "FeatureFlags.isLegacyMode"
    value: false

工具会执行一个 6 步流水线。每一步的产出可能给下一步创造新的简化机会，所以整条流水线循环执行直到收敛——某一轮没有任何文件变更时停止。

flowchart TB subgraph Phase1 ["Phase 1: 常量折叠 + 布尔简化"] S1[step1 常量替换] --> S2[step2 简单布尔] S2 --> S3[step3 复合布尔] S3 --> S4[step4 if 块消除] S4 -- 有变更 --> S1 end subgraph Phase2 ["Phase 2: 方法内联 + 级联简化"] T1[step5 恒返回方法内联] --> T2[step2 简单布尔] T2 --> T3[step3 复合布尔] T3 --> T4[step4 if 块消除] T4 -- 有变更 --> T1 end subgraph Phase3 ["Phase 3: 死方法清理 + 级联简化"] U1[step6 死方法清理] --> U2[step2 简单布尔] U2 --> U3[step3 复合布尔] U3 --> U4[step4 if 块消除] U4 -- 有变更 --> U1 end Phase1 -- 收敛 --> Phase2 Phase2 -- 收敛 --> Phase3 Phase3 -- 收敛 --> E((完成))

为什么需要迭代收敛

考虑这段代码：

if (BuildConfig.IS_PRODUCTION) {
    showProduction();
} else {
    if (isLegacy()) {
        handleLegacy();
    }
}

Phase 1 的 step1 把 BuildConfig.IS_PRODUCTION 替换为 true，step4 展开 if(true) 块、删除 else 块。一轮结束。

但 handleLegacy() 被删除后，isLegacy() 方法可能变成无调用者。Phase 3 的 step6 扫描发现它是死方法，删除定义。而 isLegacy() 内部可能还调用了其他方法……级联效应。

只跑一遍流水线，这些级联产生的死代码会被遗漏。

6 步详解

step1：常量替换

读取配置文件，把匹配的表达式替换为布尔字面量。所有替换操作共享一个 tokenizer，把源码拆成“代码段”和“非代码段”（注释、字符串字面量），只对代码段做替换。不做这层保护的话，// BuildConfig.IS_PRODUCTION 这种注释也会被改掉。

step2：简单布尔简化

处理一元和二元布尔运算。工具内部注册了完整的模式表：

模式	结果
`!true`	`false`
`!false`	`true`
`true == true`	`true`
`false == false`	`true`
`true == false`	`false`
`false == true`	`false`
`true != false`	`true`
`false != true`	`true`
`true != true`	`false`
`false != false`	`false`

另外还处理冗余括号：(true) → true、(false) → false，但只在安全的上下文中——不能剥离 if(true) 中的括号（语法要求），也不能剥离函数调用 foo(true) 中的括号。工具会检查括号前一个 token 来判断安全性：if/while/for → 不剥离，return/throw/运算符/行首 → 安全剥离。

step3：复合布尔简化

处理短路运算和三元表达式，正确处理运算符优先级。覆盖的模式：

模式	结果	说明
`false && EXPR`	`false`	短路，EXPR 被整体删除
`EXPR && false`	`false`	反向短路
`true && EXPR`	`EXPR`	恒等消除
`EXPR && true`	`EXPR`	同上，连同前导注释行一起移除
`true \|\| EXPR`	`true`	短路
`EXPR \|\| true`	`true`	反向短路
`false \|\| EXPR`	`EXPR`	恒等消除
`EXPR \|\| false`	`EXPR`	同上
`true ? X : Y`	`X`	三元消除
`false ? X : Y`	`Y`	三元消除
`false + ""`	`"false"`	字符串拼接折叠
`true + ""`	`"true"`	同上

这里有个容易出错的优先级问题：true || A && B 应该简化为 true，而不是 true || A 然后留下 B。因为 && 优先级高于 ||，A && B 是 || 的一个操作数，整体应该被消除。工具在处理 || 时会把 && 表达式当作一个整体跳过。

嵌套三元表达式 condition ? (innerCond ? A : B) : C 需要追踪括号深度和三元嵌套深度来找到正确的 : 位置，不能简单地找第一个冒号。

每个模式匹配还要避开 == / != 上下文——x == true 中的 true 是比较操作数，不能当作短路的左侧。

step4：if 块消除

覆盖的场景：

输入	输出
`if (true) { A }`	`A`（展开块内容）
`if (true) { A } else { B }`	`A`
`if (true) { A } else if (X) { B } else { C }`	`A`（删除整个 else-if 链）
`if (false) { A }`	删除
`if (false) { A } else { B }`	`B`
`if (false) { A } else if (X) { B } else { C }`	`if (X) { B } else { C }`
`if (false) return X;`	删除（单行无花括号）

删除死代码时不能跨 switch/case 标签。Java 的 case 之间没有显式闭合，删多了会把相邻 case 的代码吃掉。

step5：恒返回方法内联

扫描所有方法定义，找到只有 return true; 或 return false; 的方法，在调用处替换为常量值：

// 内联前
private boolean isLocal() { return false; }
if (isLocal()) { ... }

// 内联后
if (false) { ... }  // 下一轮被 step4 清理

有个微妙的 bug：shouldBlock(); 作为独立语句时，内联后变成 false;——不是合法的 Java 语句。解决方案是内联后扫描文件，移除所有独立的 true;/false; 行。

step6：死方法清理

找到空 void 方法和恒返回布尔方法，移除定义和调用处。

这一步需要构建内存引用索引。项目可能有上万个源文件，对每个方法做全局 grep 查引用耗时不可接受。做法是一次遍历所有文件建立方法名→引用位置的倒排索引，后续查询走内存，复杂度从 O(N×M) 降到 O(N+M)。实测从“跑不完”变为 40 秒完成。

安全边界：

参数数量精确匹配——render() 和 render(dialog) 是不同的方法
非 private 方法只内联调用，不删定义——protected/package-private 方法可能被子类 @Override，静态分析无法确定安全性
跳过接口方法、抽象方法、@Override 方法——构建类继承层次，排除框架约束的方法
链式调用保护——method().subscribe() 这种链不会因为删除 void 调用而断裂

使用

Terminal window

git clone https://github.com/OldJii/dead-code-pruner.git

# 在项目根目录放一份配置
cp dead-code-pruner/pruner.example.yaml pruner.yaml
# 编辑 pruner.yaml

# 预览
python3 dead-code-pruner/prune.py . --dry-run

# 执行
python3 dead-code-pruner/prune.py .

# 编译验证
./gradlew compileDebugJavaWithJavac

可以只跑某一阶段（--phase 1/2/3），也可以单独执行某个 step（python3 step3_compound_boolean.py .）。零外部依赖，Python 3.8+。YAML 配置需要 PyYAML，不想装的话用 JSON 格式。

实战

用这个工具对一个中大型 Android 项目做了一次完整清理。项目中有几百处运行时布尔判断。配置文件写一行 pattern: "BuildConfig.IS_PRODUCTION", value: true，跑完三阶段流水线，布尔简化 → 方法内联 → 死方法清理全部自动完成。

之后配合 Android 的 shrinkResources 和 AS 的 Remove Unused Resources 做资源清理。需要注意 getIdentifier() 动态资源引用——shrinkResources 检测不到这种引用关系，匹配模式要加入 keep.xml 白名单。

最终 APK 从 125 MB 降到 113 MB，减少约 12 MB（接近 10%）。DEX 减了 6 MB（源码级清理 + R8 优化的正向循环），res 减了 5 MB。

持续维护

清理不是一次性的。每次 merge 主分支都可能引入新的条件判断代码。工具设计成可重复执行——merge 后跑一次 python3 prune.py . 就能自动清理增量，不需要人再理解业务逻辑。

局限

针对 Java/Kotlin 源文件，基于模式匹配而非语义分析
无法处理中间变量赋值（boolean x = BuildConfig.FOO; if (x) ...）
step6 死方法检测偏保守：只移除真正空体或单常量返回的方法

保守是有意为之——空壳方法留着不会出 bug，删错了会。

设计选择

为什么不用 AI / IDE？ 评估过 Cursor 逐文件改和 AS Inspections。AI 单次 context window 覆盖不了上万文件的完整引用链，每次结果不确定。IDE 只能处理最简单的 if(true)，嵌套三元、短路运算、级联死代码一概不管。脚本行为是确定性的——同一输入同一输出，跑错了修脚本重跑。

为什么分 6 个独立文件？ 每个 step 可以独立运行和调试。排查问题时可以只跑 step3 看复合布尔简化的结果，不用跑整条流水线。

为什么用 subprocess 而不是 import？ 隔离性。每个 step 有自己的文件扫描逻辑和状态，进程隔离避免共享状态的 bug。实测整条流水线 40 秒级别，进程启动开销可忽略。

MCP Dock：给 14 个 AI 客户端统一管配置

Mon, 18 May 2026 00:00:00 GMT

之前写过两篇 MCP 相关的——用 Cursor 做 Code Review、Cursor × Figma 技术调研。写完之后最大的感受不是 MCP 有多强，而是配置有多烦。

每加一个 MCP Server，都得手动编辑 claude_desktop_config.json、.cursor/mcp.json、.vscode/mcp.json……格式还不一样。手里 AI 工具越来越多，每次都要改好几个文件，烦了。

所以做了 MCP Dock，一个桌面端，把配置管理统一起来。

项目地址：OldJii/mcp-dock

演示

功能

商店：聚合了 9200+ MCP Server，可以浏览、搜索、按 Stars 排序。另外有 3100+ AI Skills。

一键安装：选个 Server，勾选要装到哪些客户端，填参数，点安装。配置会自动写入对应客户端的文件。目前支持 Cursor、VS Code、Claude Code、Gemini CLI、Codex CLI、Windsurf、Zed、TRAE、TRAE CN、Kiro、Opencode、JetBrains、Antigravity、OpenClaw，一共 14 个。

Inspector：不想为了测一个 Server 而启动 IDE。内置了 Inspector，连上 Server 就能看 Tools 和 Resources 的返回。

历史记录：每次改配置前自动备份，改坏了看 diff，一键回滚。

配置差异

做了之后才发现，虽然大家都支持 MCP，配置格式五花八门：

客户端	配置格式	配置路径	Server 字段
Cursor	JSON	`~/.cursor/mcp.json`	`mcpServers`
VS Code	JSONC	`~/.vscode/mcp.json`	`servers`
Claude Code	JSON	`~/.claude.json`	`mcpServers`
OpenClaw	JSON5	`~/.openclaw/openclaw.json`	`mcp.servers`
Windsurf	JSON	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`
JetBrains	JSON	各 IDE 配置目录	`mcpServers`

JSON、JSON5、JSONC 三种格式混着来，字段路径也不统一。内部做了一层抽象来处理。

JetBrains 更麻烦——它不是一个工具而是一系列 IDE（IntelliJ IDEA、WebStorm、PyCharm、GoLand……），每个 IDE 配置目录不一样，还分 CE 和 Ultimate 版本。MCP Dock 会扫描系统里所有 JetBrains 实例，统一管理。

本地优先

配置文件、API Key、历史记录全在本地，不过云端。MCP 配置里经常有 API Key 和 Token，这些东西不应该离开用户的机器。

商店数据走 CDN，国内也能快速加载。没有账号体系，不需要登录。

安装

Terminal window

# macOS
brew install --cask OldJii/tap/mcp-dock

# 或手动下载
# https://github.com/OldJii/mcp-dock/releases

支持 macOS（Intel / Apple Silicon）、Windows、Linux（AppImage / deb）。

Android 16KB Page Size 适配

Wed, 18 Mar 2026 00:00:00 GMT

Google Play 要求 2025 年 11 月 1 日起，所有新应用及更新必须支持 16KB 页面设备。借着这次适配，记录下过程中踩过的坑和一些经验。

背景

Android 15 引入了 16KB 页面大小模式。传统 Linux 和 Android 使用 4KB 页面，而 ARM 架构天然支持 4KB / 16KB / 64KB 三种页面大小。Google 推动 16KB 的核心收益是更大的 TLB 覆盖范围和更少的页表层级，在内存密集型场景下可以显著减少 TLB miss，提升整体性能。Pixel 8/8a 等设备已在 Android 16 上默认启用 16KB 模式。

表面上看，适配就是给 SO 加个 -Wl,-z,max-page-size=16384 链接参数，但实际做下来远没这么简单。我们项目 APK 中有 133 个 arm64 SO，来源极为分散，最终涉及 9 个基础库仓库和 6 个业务子模块的联动修改。

SO 来源梳理

一个中大型 App 的 SO 来源通常可以分为这几类：自研 NDK 编译产出、第三方 SDK 的 AAR 内嵌、传递依赖引入（你甚至不知道它的存在）、远程动态下发（不在 APK 中，但运行时加载）。

第一步是建立完整清单，把 APK 中所有 SO 按依赖分组，逐一追溯到具体的 Maven 坐标和版本号。这是后续一切工作的基础。我们用 Gradle 的依赖树配合 unzip -l APK 的方式整理出了全量清单，每个 SO 对应到具体的依赖传递链——这个清单在后续排查问题时非常有用。

p_align 声明不可信

Android 16 的 linker64 通过 FixMinAlignFor16KiB() 从 LOAD 段的实际文件偏移计算真实兼容页面大小，不依赖 ELF header 中的 p_align 声明值。

实际适配中发现，部分 SDK 只在 ELF header 中声明了 p_align = 0x4000，但 LOAD 段的文件偏移仍按 4KB 对齐，这种情况在 linker64 上会直接加载失败。和 SDK 方沟通时需要明确告知：仅改 p_align 声明不够，必须重新编译链接。

唯一可靠的验证方式是真机加载：

Terminal window

adb push libxxx.so /data/local/tmp/
adb shell /system/bin/linker64 /data/local/tmp/libxxx.so

成功会输出 load_bias=0x...，失败会报 alignment (4096) is not a multiple of the page size (16384)。readelf -l 可以辅助验证，但以 linker64 真机结果为准。

分类处理

不兼容的 SO 没有统一的修复方式，需要根据情况分类处理。

有源码的自研 SO

最简单的情况，NDK 编译时添加链接参数即可：

Android.mk

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384

# CMakeLists.txt
target_link_options(your_lib PRIVATE -Wl,-z,max-page-size=16384)

注意：如果 SO 静态链接了第三方库（如 OpenSSL），所有被链接的库也必须用 16KB 对齐编译，遗漏任何一个静态库都会导致最终 SO 不兼容。我们就踩过这个坑——重编译 FFmpeg 时遗漏了 OpenSSL 的编译脚本，导致 HTTPS 视频无法播放，排查了好一会儿才定位到是 OpenSSL 的 SO 没有一起重编译。

另外一个比较隐蔽的问题是 FFmpeg 旧版本的汇编兼容性。FFmpeg 3.4 的 aarch64 NEON 汇编（fft_neon.S、h264idct_neon.S、sbrdsp_neon.S 等）存在 PIC 重定位不兼容的问题，在 16KB 对齐模式下编译会失败。短期方案是 --disable-asm 关闭汇编优化（硬件解码不受影响），长期需要升级到 FFmpeg 4.x+ 才能恢复汇编加速。

第三方 SDK

联系 SDK 方获取 16KB 兼容版本。大部分主流 SDK 在 2025 年已经或正在发布兼容版本。

远程下发的 SO

如果 SO 不打包在 APK 中，而是通过远程下发机制在运行时加载，可以在 build.gradle 中排除：

android {
    packagingOptions {
        jniLibs {
            excludes += ['**/libxxx.so']
        }
    }
}

这些 SO 由远程下发机制保证版本兼容性，不受 APK 打包限制。但要注意 excludes 配置和远程下发清单的一致性，我们就发现过某个 SO 在 excludes 中排除了，但远程下发配置里标记的是本地加载，导致运行时找不到。

废弃 SO

最好的修复是移除。实际适配中发现了多个无代码引用或功能已废弃的 SO，直接删除既解决了 16KB 问题，又减小了包体积。比如我们项目中有几个早期接入的安全加固组件，服务端确认相关功能字段已经废弃后，连同 SO、混淆规则、初始化代码一起清理掉了。

短期无法获得兼容版本的 SDK

最棘手的情况。如果 SDK 方无法及时提供 16KB 版本，需要评估该 SO 加载失败对 App 的影响范围，必要时添加 fallback 逻辑。比如我们对视频缩略图获取做了降级处理——当 native 库加载失败时，fallback 到 MediaMetadataRetriever 的纯 Java 实现，避免整个功能不可用。

移除 SoLoader

许多使用 Facebook 开源库（Fresco、Litho 等）的项目通过 SoLoader 加载 SO。SoLoader 在 16KB 模式下存在兼容性问题——它解压 SO 到应用私有目录时可能不满足对齐要求。

我们的方案是彻底移除 SoLoader：升级 Fresco 到 3.x（不再强制依赖 SoLoader），所有 SoLoader.loadLibrary() 替换为 System.loadLibrary()，移除 SoLoader.init() 初始化调用。

注意移除后的副作用：如果之前依赖 SoLoader 的自动依赖解析来加载 libc++_shared.so，移除后需要确保该 SO 被正确打包到 APK 中。我们项目的某个 flavor 就因为这个问题在 debug 构建时崩溃，排查发现是 STL 共享运行库没有被正确打包进去。

Fresco 1.x → 3.x

Fresco 大版本升级是这次适配中工作量最大的部分之一：

AnimationListener 接口签名变更：回调参数从 AnimatedDrawable2 改为 Drawable
ImagePipeline.getMainFileCache() 被移除，磁盘缓存查找需改用 getDiskCachesStoreSupplier()
ImagePipelineNativeLoader.load() 不再需要手动调用
CircleProgressBarDrawable 等自定义 Drawable 与内置版本冲突，需移除自定义实现
DefaultLifecycleObserver shim 类需移除，改用 AndroidX 内置版本

建议全局搜索 AnimatedDrawable2、getMainFileCache、SoLoader、ImagePipelineNativeLoader 等关键词逐一修复。

反射限制

Android 16 收紧了对系统属性的反射访问。如果代码或 SDK 中有通过 SystemProperties.get("net.dns*") 获取 DNS 的逻辑，在 16KB 模式设备上会直接失败，改用公开 API：

ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
Network network = cm.getActiveNetwork();
LinkProperties props = cm.getLinkProperties(network);
List<InetAddress> dnsServers = props.getDnsServers();

验证

适配完成后的验证分两部分。

SO 兼容性验证：用 linker64 逐一加载 APK 中所有 arm64 SO，建立兼容性基线。按上述分类策略逐一处理不兼容 SO 后，再次全量验证。

功能回归：在 16KB 设备（Pixel 8/8a, Android 16）和普通设备上双端回归。重点覆盖 SO 密集的功能区域——视频播放/录制、直播推流与连麦、语音消息录制与播放、人脸认证、图片加载与缓存、数据持久化（数据库读写）、崩溃采集与热更新。这些场景背后都有 native 库在工作，是最容易出问题的地方。

另外建议在 CI 中集成 SO 对齐检查，防止后续迭代引入不兼容的 SO。

顺带做的事

16KB 适配是一次被迫触及全量 SO 依赖的机会，借此我们也做了一些清理：建立了完整的 SO 依赖清单（来源、版本、Maven 坐标、传递链全部记录）、移除了多个功能已废弃的安全组件和 SDK、用 resolutionStrategy.force 统一了传递依赖的版本、审查了远程下发配置确保 excludes 和下发清单一致。

整体来说，16KB 适配不只是一个编译参数的修改，而是一次对 App 全量 native 依赖的深度梳理。核心难点在于 SO 来源分散、验证依赖真机、不同 SO 需要不同处理策略、以及 Fresco 大版本升级带来的接口变更。涉及多个基础库仓库和业务模块的协同修改，发版也需要按依赖顺序分步推进。建议尽早启动，为 SDK 方升级和内部测试留出缓冲时间。

用 Cursor 做 Code Review

Sun, 04 Jan 2026 00:00:00 GMT

Code Review 是开发流程中绑定的环节，但人工审查效率有限，容易遗漏问题。这篇文章介绍我写的一个工具，让 Cursor 能够直接读取 PR/MR、分析代码变更、生成审查意见并提交到对应平台。

项目地址：https://github.com/OldJii/code-review-mcp

思路

Cursor 本身不具备访问 GitHub/GitLab API 的能力，需要通过 MCP（Model Context Protocol）来扩展。MCP 是 Anthropic 推出的协议，允许 AI 模型与外部数据源和工具交互。

整体思路是：

写一个 MCP Server，封装 GitHub/GitLab 的 API
在 Cursor 中配置这个 MCP Server
用 mdc 规则文件定义审查规范，约束 AI 的审查行为
在 Cursor 中对话，让 AI 读取 PR、分析代码、提交评论

MCP Server

MCP Server 用 Python 实现，通过 stdio 与 Cursor 通信。核心是抽象出一个 CodeReviewProvider 基类，GitHub 和 GitLab 各自实现具体逻辑。

class CodeReviewProvider(ABC):
    @abstractmethod
    def get_pr_info(self, repo: str, pr_id: int) -> Dict:
        pass

    @abstractmethod
    def get_pr_changes(self, repo: str, pr_id: int) -> Dict:
        pass

    @abstractmethod
    def add_inline_comment(self, repo: str, pr_id: int, file_path: str,
                          line: int, line_type: str, comment: str) -> Dict:
        pass

    @abstractmethod
    def add_pr_comment(self, repo: str, pr_id: int, comment: str) -> Dict:
        pass

GitHub 和 GitLab 的 API 差异主要在两个地方：

认证方式：GitHub 用 Bearer Token，GitLab 用 PRIVATE-TOKEN Header
行内评论：GitLab 需要计算 line_code，GitHub 直接传行号

Token 获取

为了简化配置，没有让用户手动填写 Token，而是复用 gh 和 glab 命令行工具的认证信息。

GitHub 直接调用 gh auth token 获取：

def _get_token(self) -> str:
    try:
        result = subprocess.run(
            ["gh", "auth", "token"],
            capture_output=True, text=True
        )
        if result.returncode == 0:
            return result.stdout.strip()
    except FileNotFoundError:
        pass
    return ""

GitLab 需要从 glab 的配置文件中解析：

def _get_token(self) -> str:
    config_paths = [
        Path.home() / ".config" / "glab-cli" / "config.yml",
        Path.home() / "Library" / "Application Support" / "glab-cli" / "config.yml",
    ]

    for config_path in config_paths:
        if config_path.exists():
            with open(config_path, 'r') as f:
                content = f.read()
            pattern = rf'{re.escape(self.host)}:.*?token:\s*([^\s\n]+)'
            match = re.search(pattern, content, re.DOTALL)
            if match:
                return match.group(1).strip()
    return ""

这样用户只需要执行 gh auth login 或 glab auth login，MCP Server 就能自动获取 Token。

GitLab 行内评论

GitLab 的行内评论 API 比较麻烦，需要提供 line_code 参数。这个参数的格式是 {head_sha}_{old_line}_{new_line}，需要从 diff 中解析出来。

def _find_line_code(self, diff: str, target_line: int, line_type: str, head_sha: str) -> str:
    lines = diff.split('\n')
    old_line = 0
    new_line = 0

    for line in lines:
        if line.startswith('@@'):
            match = re.match(r'@@ -(\d+)(?:,\d+)? \+(\d+)(?:,\d+)? @@', line)
            if match:
                old_line = int(match.group(1)) - 1
                new_line = int(match.group(2)) - 1
        elif line.startswith('-'):
            old_line += 1
            if line_type == "old" and old_line == target_line:
                return f"{head_sha}_{old_line}_"
        elif line.startswith('+'):
            new_line += 1
            if line_type == "new" and new_line == target_line:
                return f"{head_sha}_{old_line}_{new_line}"
        else:
            old_line += 1
            new_line += 1

    return ""

核心逻辑是遍历 diff 内容，根据 @@ 行头解析起始行号，然后跟踪 old_line 和 new_line 的变化，找到目标行对应的 line_code。

MCP 工具

最终暴露给 Cursor 的工具有 6 个：

工具	说明
`get_pr_info`	获取 PR/MR 的标题、描述、分支等信息
`get_pr_changes`	获取代码变更，支持按文件类型过滤
`extract_related_prs`	从描述中提取关联的 PR 链接
`add_inline_comment`	添加行内评论
`add_pr_comment`	添加整体评论
`batch_add_comments`	批量添加评论

batch_add_comments 是为了减少用户确认次数，一次性提交所有评论。

审查规范

MCP 只解决了”能做什么”的问题，“怎么做”需要通过 mdc 规则文件来约束。

mdc 是 Cursor 的规则文件格式，可以在项目的 .cursor/rules/ 目录下定义。AI 在对话时会参考这些规则。

核心原则

审查规范的核心是”理解优先”：

先理解 PR 整体目的，再看具体 diff
深度分析（架构/逻辑/性能）优先于风格检查
只提”确认的问题”，不提”可能的问题”
结合上下文分析，不孤立判断

最后一条很重要。AI 容易犯的错误是看到一个变量可能为空就报 NPE 风险，但实际上调用方可能已经做过校验。规则里明确要求 AI 追溯上下文，避免误报。

审查流程

规则里定义了完整的审查流程：

获取变更：调用 get_pr_changes 获取所有文件的完整 diff
理解上下文：从标题、描述、变更列表理解 PR 目的
深度分析：逐文件分析架构、逻辑、性能、安全问题
去重：同一文件相同问题合并，避免重复评论
预览确认：展示所有评论让用户确认
批量提交：调用 batch_add_comments 一次性提交

第 5 步是关键。AI 生成的评论需要人工把关，避免提交低质量或错误的评论。

优先级

问题按严重程度分为三级：

P0：崩溃、内存泄漏、严重性能问题、安全漏洞
P1：架构问题、逻辑缺陷、代码质量
P2：代码复用、命名优化

P0 问题不限数量，P1 和 P2 会根据 P0 的数量动态调整。如果 P0 超过 10 个，说明代码质量较差，此时减少 P1/P2 的数量，集中精力在严重问题上。

避免误报

规则里列举了常见的误报场景：

类型	误报条件	处理
NPE	调用方已校验	不提
越界	上文已检查长度	不提
性能	数据量 <= 5	不提
线程	耗时 < 1ms	不提

这些规则是从实际 Review 经验中总结出来的。AI 的判断倾向于保守，容易对一些不是问题的代码报警。通过这些规则可以让 AI 更准确地识别真正的问题。

使用

配置

MCP 配置是全局的，编辑 ~/.cursor/mcp.json：

{
  "mcpServers": {
    "code-review": {
      "command": "python3",
      "args": ["/path/to/cursor-ai-code-review/code_review_mcp.py"]
    }
  }
}

审查规范是项目级别的，需要复制到每个项目的 .cursor/rules/ 目录。这个设计是因为不同项目可能有不同的审查标准。

审查

配置完成后，在 Cursor 中直接输入：

Review https://github.com/owner/repo/pull/123

AI 会自动调用 MCP 工具获取 PR 信息和代码变更，然后按照规则进行审查，审查完成后会展示所有评论供确认：

我删除了某 Flutter 项目中一个Dart 文件的一行 import 代码，用于演示工具的使用流程。

确认无误后，AI 会调用 batch_add_comments 批量提交评论到 GitHub/GitLab。

私有 GitLab

如果使用私有化部署的 GitLab，在认证时指定地址：

Terminal window

glab auth login --hostname gitlab.yourcompany.com

MCP Server 会自动从 glab 配置中读取对应的 Token。

局限

这个工具目前还有一些局限：

上下文有限：AI 只能看到 diff，无法读取完整的项目代码。对于涉及多文件交互的问题，分析能力有限。
规则依赖：审查质量很大程度取决于 mdc 规则的完善程度。规则写得不好，AI 可能遗漏问题或产生误报。
需要人工确认：每次提交评论前需要人工确认，无法完全自动化。这是有意为之，避免 AI 提交低质量评论。

后续可以考虑接入更多上下文，比如让 AI 能够读取相关文件、查看历史提交等。规则也可以根据实际使用情况持续优化。

总结

这个工具的核心价值是把 Code Review 的机械性工作交给 AI，人只需要确认最终结果。实际使用下来，对于常规的代码问题（空指针、资源泄漏、性能隐患等），AI 的识别率还是可以的。

但 AI 不能完全替代人工 Review。架构设计、业务逻辑这些需要深度理解上下文的问题，还是得靠人来判断。把 AI 当作辅助工具，提高效率的同时保持人的把关，是目前比较务实的用法。

Cursor × Figma 技术调研

Thu, 11 Dec 2025 00:00:00 GMT

探索让 AI 直接读取 Figma 设计稿生成 UI 代码的可行性。

结论：技术上可行，但在传统 XML 项目中还原度不高。调研发现，Jetpack Compose + Auto Layout 才是最佳组合，要落地需要设计和开发一起推动技术栈升级。

Figma MCP

MCP（Model Context Protocol） 是让 AI 模型能够与外部数据源和工具交互的标准协议。cursor-talk-to-figma-mcp 基于 MCP 协议，在 Cursor 和 Figma 之间建立连接，可以在 Cursor 里直接：

读取 Figma 设计稿的完整信息（图层、样式、布局、组件等）
编辑 Figma 文件（创建图形、修改属性、调整布局）
生成代码：根据设计稿生成对应的 UI 代码

配置

Step 1：打开 Figma 桌面端，搜索 Cursor Talk To Figma MCP Plugin，点击安装。

Step 2：插件和 Cursor 之间需要一个中转服务来通信，打开终端运行：

Terminal window

bunx cursor-talk-to-figma-socket

服务启动后会在本地监听端口，保持终端窗口不要关。

如果没有安装 bun，可以先用 npm install -g bun 安装。

Step 3：在任意 Figma 文件里打开插件面板，可以看到 Channel ID 和 MCP 配置信息。

Step 4：把配置复制到 Cursor 的 mcp.json 文件中。

配置完成后，在 Cursor 的 Chat 里就能直接和 Figma 设计稿交互了。

权限问题

配置过程顺利，但使用时踩了个坑：企业账号没有编辑权限。

Figma 的账号体系有两个维度：

维度	类型
账号类型	Starter（免费）、Professional、Organization、Enterprise
席位类型	Full Seat、Dev Seat、Collab Seat、View Seat

公司用的是 Enterprise 账号，给开发分配的是 View Seat（只读席位），意味着在公司 Figma 里只能看不能编辑，而 Figma MCP 插件需要编辑权限才能正常工作。

账号	席位	能否使用插件
公司 Enterprise 账号	View Seat	不行，Drafts 和 Projects 都没有编辑权限
个人 Starter 免费账号	Full Seat	可以，Drafts 里有完整权限

解决办法：把设计稿复制到个人账号里。在公司 Figma 里打开目标设计稿，选中需要的 Frame，Cmd + C 复制，切换到个人账号，在 Drafts 里新建文件，Cmd + V 粘贴进去。

还原度

配置完成后，尝试用 Cursor 根据设计稿生成对应 XML 布局 文件。结果是能用，但还原度一般，生成的代码需要大量调整才能用。

问题 1：几何式布局缺乏语义

传统 Figma 布局是几何式的，设计师通过绝对坐标定位元素：

Text A → (x: 20, y: 50)
Text B → (x: 20, y: 80)

AI 拿到这些数据后，只知道两个文本框垂直相距 30px，但无法判断设计师的意图：

这是一个垂直列表，间距固定 30px？
这是两个独立元素，碰巧对齐了？
这是某个列表项的一部分，设计师手动复制出来的？

AI 只能靠启发式算法猜测。猜错了布局就会有问题，猜测过程本身也消耗算力，影响生成速度和准确度。

问题 2：XML 与声明式设计不匹配

即使设计稿用了 Figma 的 Auto Layout（一种声明式的布局方式，类似前端 Flexbox），生成 XML 代码的效果也不理想。

根本原因是：Auto Layout 是声明式的，而 XML 布局是命令式的。

Auto Layout 明确标注「这是一个垂直容器，子元素间距 30px」，但转成 XML 时，AI 需要把这些声明式规则翻译成 LinearLayout + layout_marginTop 等命令式属性，这个转换过程会损失很多信息，也容易出错。

调研结论

调研后发现，Jetpack Compose + Auto Layout 才是最佳组合。

Compose 是声明式 UI 框架，它的布局理念和 Auto Layout 天然契合。对应关系如下：

Figma Auto Layout 属性	Jetpack Compose 实现
Horizontal（水平排列）	`Row { }`
Vertical（垂直排列）	`Column { }`
无 Auto Layout / Group	`Box { }`
Fill Container（填充容器）	`Modifier.fillMaxWidth()`
Hug Contents（包裹内容）	`Modifier.wrapContentSize()`
Fixed Size（固定尺寸）	`Modifier.size(dp)`
Padding（内边距）	`Modifier.padding()`
Space between items（间距）	`Arrangement.spacedBy()`
Alignment（对齐）	`Arrangement.Center` / `Alignment.*`

几乎是一一对应。AI 拿到 Auto Layout 数据后，不用猜测和转换，直接映射成 Compose 代码即可。

当前价值

虽然在传统 XML 项目中无法完美还原 UI，但 Figma MCP 现阶段仍然有价值：

提取设计参数：快速获取颜色值、字号、间距、圆角等，不用手动量
理解页面结构：读取图层层级和命名，帮助理清组件划分
生成骨架代码：生成大致的布局框架，在此基础上微调
辅助设计走查：对比设计稿和实现，快速定位差异

把它当作辅助工具，而不是完全自动化的解决方案。

升级路径

要真正发挥 AI 设计转代码的能力，需要从两个方向推进：

设计侧

全面使用 Auto Layout：所有组件都用声明式方式组织，而不是绝对定位
建立 Design System：统一的设计组件库，命名规范化
组件化思维：设计时就按开发的组件粒度拆分

开发侧

迁移到 Jetpack Compose：声明式 UI 框架，和 Auto Layout 理念一致
搭配 KMP（Kotlin Multiplatform）：一套 Compose UI 代码，Android 和 iOS 都能用
实现对应组件库：Figma 里的组件和代码里的组件一一对应

当设计和开发都采用声明式体系，Figma 里的组件和代码里的组件形成映射关系后，AI 只需要做「翻译」工作：

Figma Auto Layout (声明式设计)
    ↓ AI 直接映射
Jetpack Compose (声明式代码)

这时候，设计师在 Figma 里调整一个按钮的圆角和间距，开发在 Cursor 里让 AI 同步更新代码，几秒钟就能完成，效率提升会非常明显。

理想的技术栈是：Cursor + Figma MCP + Jetpack Compose + KMP + Auto Layout。

桂林、龙胜、阳朔

Tue, 21 Oct 2025 00:00:00 GMT

我一直偏爱山水风光，从小就听闻“桂林山水甲天下”，这次终于借着假期踏上了旅程。这是我的第一次独自旅行，7天里逛了不少地方。出发前在小红书刷到很多帖子说“到阳朔一天就想回桂林市区”，大多吐槽阳朔坑人，连本地人都不放过。但自己亲身走了一趟后发现，实际情况和网上的描述不太一样。

先说说出行方式，桂林市区推荐骑共享电动车加打车的组合；阳朔的话，直接在住的酒店租电动车就好，一般不用交押金，外面租要收押金。建议选大电瓶的，虽然贵一点，但续航远，跑景点更省心。

如果纯主观给这些天逛过的景点分个梯队，第一梯队是漓江三星游船、遇龙河漂流、千里江山图日落打卡地和阳朔骑电车闲逛；第二梯队是桂海晴岚、龙脊梯田；像正阳步行街、象山景区、日月双塔这些，我觉得没必要特意去。不是说这些地方不好，主要是同质化太严重，可能你家乡就有类似的景点，没必要专门跑一趟桂林看。

桂海晴岚

桂海晴岚在桂林市区比较边缘的位置，但桂林市区本身就不大，加上共享电动车很普及，去起来也不算麻烦。我订的酒店在两江四湖景区附近，骑电车到桂海晴岚大概25分钟。不过要注意，离景区还有1、2公里的时候，就超出共享电动车的服务范围了。边界那里有当地阿姨做代驾，花5块钱就能把你送到景点门口，很便宜。

整个景区就像一个风景超棒的高尔夫球场，大片的草坪蔓延开，湖水清澈，远处是连绵的山峰，置身其中感觉像在童话世界里。景区面积很大，可以慢慢逛，找个喜欢的地方躺在草坪上，看着蓝天和湖水连在一起，放空自己，特别舒服。唯一的缺点是温度，10月份的桂林，在这种空旷的草坪上会被太阳晒得厉害，直到下午4点以后，温度才会稍微降下来，舒服一点。景区里的天鹅一点都不怕人，会在湖边悠闲地活动。

龙脊梯田

龙脊梯田离市区很远，推荐报一日团当天往返。选团的时候要注意，别选包含长发村的，长发村完全没必要去。也不建议在山上过夜，山上没什么好吃的，能做的无非就是看景色、拍写真、吃饭这三件事。我没拍写真，山上的饭也不推荐，网上很火的竹筒饭味道一般，如果报的团有赠送可以尝一尝，没必要主动买，还是回桂林市区再吃比较好。

龙脊梯田的景色确实很好看，但可看的内容比较少，看几眼就差不多了，不过不来看看又会觉得可惜。建议坐索道上山，步行下山。下山的路基础设施不太好，有很长一段路是和机动车同路的，没有专门的人行道，走路的时候一定要注意安全。

漓江

从桂林去阳朔的方式，我选择的是乘坐漓江三星游船，这趟行程不只是交通，更是我心中的第一梯队的体验。航线是从桂林市区的磨盘山码头坐到阳朔的龙头山码头，班次时间是固定的，最晚一班是12:05。景区有直通车能送码头，但不会到酒店门口接，只会给个附近的集合点，不太方便，建议还是打车自己去。我坐的就是中午这班最晚的，需要提前半小时到码头，全程航行大概4小时。沿途会经过冠岩、杨堤、九马画山、黄布倒影这些经典景点，船舱里有讲解员实时介绍。船上有餐食，但比较简单，建议下船后再找地方吃。下船后，码头出口有不少骑电动车拉客的师傅，建议找一位带自己去酒店，因为要走挺远才能打到车。

遇龙河

可能有人会好奇，为什么我把“阳朔骑电车闲逛”归到第一梯队里，等你真到了阳朔就会明白。阳朔的美不分景区、不分地点，骑上电车沿着乡间小路走，沿途随处都是像山水画一样的风景。如果说漓江是大气磅礴的，那遇龙河就是精巧雅致的，很符合传统山水意境里对“水”的想象。

我最推荐的就是沿遇龙河的骑行路线：富里桥 → 遇龙桥 → 旧县码头 → 骥马码头 → 水厄底码头。把电车停在水厄底码头，就能去坐从这里到综合码头的竹筏漂流，漂流结束有摆渡车送回水厄底码头，之后还能继续骑到竹蔸寨、万景码头。这条路线能把遇龙河流域的精华景色都逛到，体验绝不比任何5A景区差。提醒一下，竹筏漂流是200元一筏，能坐两个人，独自旅行的话最好提前找好拼筏的人。

日落

7天的旅途中在很多地方看过日落，最惊艳的当属千里江山图的日落，这里的夕阳像是给连绵的山峦镀上了一层暖金，云曾被染成橘粉与绛紫交织的颜色，随着光线下沉，山峦的轮廓从清晰变得朦胧，宛如一幅水墨画，静谧且壮阔。

简单说下交通，不推荐骑电车！30公里路程要骑1小时，景区在山上，爬坡费电，山顶充电电压低还慢，我就差点半路没电被困。而且回程国道多段没路灯，天黑后骑车极不安全，直接坐大巴或打车最省心。客观讲，这里可玩性不算高，景色也比较单一，但这份日落的惊艳，值得你专门跑一趟，不看真的会可惜。

偶遇

比起计划好的行程，旅行中突然的偶遇更让人惊喜。我在小红书发了旅行帖子后，朋友看到问我是不是要去桂林，巧的是，他正好临时计划去阳朔野攀。我们一拍即合，我调整了后面两天的行程，去他们野攀的地方凑了热闹，还在朋友的指导下完成了我的第一次攀岩。

很新奇的体验，攀岩的时候需要高度专注，能忘记很多烦心事。没有工作绩效的压力，也没有生活里的纷扰，眼里只有眼前的岩壁、指尖碰到的粗糙颗粒，还有每一步踩稳的着力点。那些压力和焦虑，好像都在这种极致的专注里被过滤得干干净净。

米粉

最后说说米粉，这几天在桂林，我每天至少吃一顿米粉。我本身就是粉面爱好者，所以怎么吃都不觉得腻。

桂林市区和阳朔的米粉体验差别很大。市区的米粉好吃、便宜，花样还多；阳朔的米粉不管是价格还是味道，都没什么优势。市区里，三两的卤菜粉6元，一份锅烧5元，如果超过这个价格太多，就可以换一家店了。

桂林米粉端上来的时候是干的，我问过本地人，正确的吃法是先干拌着吃，吃到剩下三分之一的时候再加汤，然后边喝汤边嗦粉。不过我个人更喜欢直接加汤，加到没过三分之一米粉的位置，再单独加一份锅烧，酸笋、酸萝卜、烧椒酱都多加一份，充分搅拌均匀后大口吃，很是过瘾。

提醒一下，吃米粉的时候加辣椒要谨慎，先少放一点，觉得不够再慢慢加。我刚到桂林的第一晚，就因为没掌握好辣椒的辣度，被狠狠上了一课。

Blog 迁移 Slate 的多图排版适配

Sun, 13 Jul 2025 00:00:00 GMT

将博客从 Hugo Even 主题迁移到了基于 Astro 的 Slate 主题。在迁移过程中，发现原有的多图排版功能需要重新适配，因为新主题使用了不同的 HTML 结构。

在 Hugo Even 主题中，Markdown 中的图片会被渲染为 <p> 标签包裹 <a> 标签的形式，而 Slate 主题则使用 <div class="rehype-figure-container"> 包裹 <figure class="rehype-figure"> 的结构。

/* 两张图片分栏 */
.rehype-figure-container:has(> .rehype-figure:nth-child(2)) {
  column-count: 2;
  column-gap: 8px;
  margin: 6px 0;
}

/* 三张图片分栏 */
.rehype-figure-container:has(> .rehype-figure:nth-child(3)) {
  column-count: 3;
  column-gap: 8px;
  margin: 6px 0;
}

/* 四张图片分栏 */
.rehype-figure-container:has(> .rehype-figure:nth-child(4)) {
  column-count: 4;
  column-gap: 8px;
  margin: 6px 0;
}

/* 五张图片分栏 */
.rehype-figure-container:has(> .rehype-figure:nth-child(5)) {
  column-count: 5;
  column-gap: 8px;
  margin: 6px 0;
}

/* 六张图片分栏 */
.rehype-figure-container:has(> .rehype-figure:nth-child(6)) {
  column-count: 4;
  column-gap: 8px;
  margin: 6px 0;
}

/* 处理图片显示 */
.rehype-figure-container:has(> .rehype-figure:nth-child(2)) .rehype-figure,
.rehype-figure-container:has(> .rehype-figure:nth-child(3)) .rehype-figure,
.rehype-figure-container:has(> .rehype-figure:nth-child(4)) .rehype-figure,
.rehype-figure-container:has(> .rehype-figure:nth-child(5)) .rehype-figure,
.rehype-figure-container:has(> .rehype-figure:nth-child(6)) .rehype-figure {
  display: block;
  margin-bottom: 8px;
  break-inside: avoid;
}

.rehype-figure-container:has(> .rehype-figure:nth-child(2)) img,
.rehype-figure-container:has(> .rehype-figure:nth-child(3)) img,
.rehype-figure-container:has(> .rehype-figure:nth-child(4)) img,
.rehype-figure-container:has(> .rehype-figure:nth-child(5)) img,
.rehype-figure-container:has(> .rehype-figure:nth-child(6)) img {
  width: 100%;
  height: auto;
  display: block;
  margin: 0;
}

/* 响应式设计 */
@media (max-width: 768px) {
  .rehype-figure-container:has(> .rehype-figure:nth-child(2)),
  .rehype-figure-container:has(> .rehype-figure:nth-child(3)),
  .rehype-figure-container:has(> .rehype-figure:nth-child(4)),
  .rehype-figure-container:has(> .rehype-figure:nth-child(5)),
  .rehype-figure-container:has(> .rehype-figure:nth-child(6)) {
    column-count: 1;
    column-gap: 0;
  }
}

使用规则与 Hugo Even 主题保持一致。图片之间可以换行，但不能空行，CSS 会根据容器内的图片数量自动调整分栏数量。支持 2-6 张图片的自动分栏。

四张图片的演示效果：

更多图片演示效果请查看 Hugo 多图排版 even 主题适配。

将上述 CSS 代码添加到 Slate 主题的样式文件中。具体位置可能因主题配置而异，通常可以添加到 src/assets/style/common.css 或者创建新的样式文件并在主题配置中引入。

App端内网络监控

Sat, 21 Jun 2025 00:00:00 GMT

App 运行环境复杂，用户投诉中很大一部分集中在”页面加载慢”、“登录失败”、“连接不稳定”等网络相关问题上，这类问题在测试环境中往往难以复现。传统的服务端监控或 CDN 日志，无法完整还原终端侧的真实网络状态。

针对这类问题，设计的端内网络监控方案核心目标是：

主动感知用户当前的网络实际情况
精准识别网络故障的真实成因
为网络问题的定位、修复和优化提供结构化的数据支撑

具体实现为应用网速检查、DNS 劫持检测两部分。

应用网速检查

原理

该模块基于 Android 原生的 TrafficStats API，以应用 UID 为统计粒度，在固定的短时窗口（5 秒）内读取接收流量增量，通过增量字节数除以时间差计算客户端真实下载速度。该方式无需额外权限或发起网络请求，运行轻量化，且能反映用户真实的网络使用体验。

检查时机

应用启动时：首次启动立即执行检查
网络切换时：例如从 WiFi 切换至移动网络
应用回前台时：避免后台期间网络状态发生变化未被感知
请求失败时：辅助诊断网络层面的问题诱因
每 20 秒定期执行：满足长时间驻留场景下的持续采样需求

由于检测本身需要 5 秒的采样窗口，实际上天然具备了去重能力，无需额外设置冷却时间。同时，为避免多线程并发触发检查导致的统计异常，通过原子变量标记当前检查状态，确保同一时间仅执行一次检查。

数据上报

内容	示例值
平均下载速度	`32.00 KB/s`
当前网络类型	`WIFI` / `4G` / `5G`
运营商名称	`中国联通`
移动网络信号强度	`-88`
是否处于漫游状态	`false`
WiFi 信号等级	`3`

注：部分字段需要特定权限支持（获取信号强度/WiFi 等级需 ACCESS_FINE_LOCATION 权限，获取漫游状态需 READ_PHONE_STATE 权限），方案仅做权限判断不主动申请，若权限缺失则不上报对应字段。速度值会根据量级自动格式化为 B/s、KB/s 或 MB/s。

DNS 劫持检测

原理

DNS 劫持是客户端常见的网络安全问题，在公共 WiFi 或部分三线运营商环境下更容易出现。我们通过对比系统 DNS 与可信 DoH 服务的解析结果，来识别是否存在劫持行为。

系统 DNS：调用 InetAddress.getAllByName() 获取解析结果
DoH 服务：如 Google DNS、AliDNS、腾讯 DNSPod，通过加密连接获取的权威解析结果

Google DNS：https://dns.google/resolve?name=%s&type=A
AliDNS：https://dns.alidns.com/resolve?name=%s&type=A
DNSPod：https://doh.pub/dns-query?name=%s&type=A

可信 IP 池与缓存机制

可信 IP 池由两部分组成：

当前 DoH 解析结果：本次从三家 DoH 服务获取到的 IP 地址
历史 DoH 缓存：过去通过 DoH 成功解析过的 IP 地址，本地持久化存储，有效期 90 天

缓存采用结构化存储设计，核心包含”域名-IP-时间戳”的关联结构：以域名为维度归类 IP，每个 IP 条目附带最后更新时间戳，用于后续过期判断。对应的核心策略如下：

缓存更新策略：每次 DoH 解析成功后，将有效 IP 添加到对应域名的缓存中；若 IP 已存在，则更新其时间戳，确保活跃 IP 的有效性
过期清理策略：定期过滤超出 90 天有效期的 IP 条目，避免缓存冗余占用终端存储，同时保证缓存 IP 的时效性

判定逻辑执行前会先通过网络连接状态检查（确认设备是否真的接入网络），避免将网络未连接的情况误判为 DNS 问题。在此基础上，具体判断逻辑为：

若系统 DNS 返回的 IP 全部包含在可信 IP 池中，视为解析正常
若存在系统 DNS 返回的 IP 不在可信 IP 池中，判定为疑似劫持

这种设计主要是考虑到 CDN 和负载均衡场景下，同一域名的解析结果会随时间、地域变化。单纯依赖实时 DoH 结果对比，容易将正常的 IP 轮转误判为劫持。通过维护历史 DoH 缓存，可以有效缓解这一问题。

检查时机

为节省终端资源，DNS 劫持检查仅在网络请求失败且命中特定异常类型集合时触发，同时设置 5 秒冷却时间，即两次检查之间至少间隔 5 秒。该冷却机制的核心作用是避免同一网络问题（如持续的连接失败）导致频繁触发检测：一方面可减少重复的 DoH 网络请求，降低用户流量消耗；另一方面能避免终端线程频繁占用，提升应用运行流畅度。

相较于启动、切网等高频触发方式，这种按需触发+精准异常命中的策略更贴合实际业务场景，也能减少不必要的资源消耗。

异常类型集

以下是网络异常中与 DNS 劫持高度相关的典型类型：

异常类型	原因分类	说明
`CertPathValidatorException`	证书不可信	TLS 证书签名链不受信任，常见于中间人攻击场景
`SSLHandshakeException` / `SSLPeerUnverifiedException`	TLS 握手失败	证书链异常或握手中断，可能由劫持导致
`UnknownHostException`	DNS 解析失败	无法将域名解析为 IP，多出现于 DNS 劫持或污染场景
`ConnectException`	连接被拒绝	网络可达但目标端口无响应，可能是劫持后的伪地址
`SocketTimeoutException`	TCP 超时	网络拥堵或服务不可达，需结合 DNS 解析结果排查

检测结果分类

根据系统 DNS 和 DoH 的解析情况，我们将检测结果细分为以下几类：

结果状态	判定条件	说明
劫持	系统 DNS 和 DoH 都成功，但系统 IP 不在可信 IP 池中	疑似 DNS 劫持
网络问题	检测到网络未连接	真实的网络连接中断
系统 DNS 失败	系统 DNS 失败但 DoH 成功	本地 DNS 配置问题
DoH 失败	系统 DNS 成功但 DoH 失败	DoH 服务不可用
正常	系统 DNS 的 IP 全部在可信 IP 池中	解析结果一致
未知	网络连接正常但 DNS 服务均失败	DNS 服务器问题或端口被封锁

这种细粒度的分类有助于快速定位问题根因，避免将所有异常都归结为”劫持”。

数据上报

内容	示例值
检查目标域名	`api.example.com`
系统 DNS 返回的 IP 列表	`[1.2.3.4, 5.6.7.8]`
DoH 返回的 IP 汇总	`GoogleDNS=[1.2.3.4]; AliDNS=[1.2.3.4, 9.9.9.9]`
检测结果状态	`IS_HIJACKED` / `PASS` / `NETWORK_FAIL` 等
详细原因描述	包含异常 IP、可信 IP 池等详细信息
触发检查的异常类型	`TLS_CERT_UNTRUSTED_SIGNATURE` / `DNS_RESOLUTION_FAILED` 等

注：为避免无效数据干扰分析，埋点仅上报判定为劫持的情况。

App认证链路设计

Wed, 16 Apr 2025 00:00:00 GMT

在移动应用中，用户身份认证是保障账户安全、满足合规需求的关键模块。随着业务场景的复杂化（如从单一的头像认证到实名认证、账号找回等多场景）和技术方案的演进（如从集成单个 SDK 到动态调度多个第三方服务），如何构建一个高内聚、低耦合、可扩展的认证系统，成为了一项挑战。

宏观设计

认证系统的设计需要具备前瞻性，以灵活应对业务变化和技术选型更迭。为实现此目标，推荐采用分层的、服务化的架构，而非将认证逻辑直接耦合在业务代码中。

业务应用层：认证需求的发起点，例如”认证中心”、“账号申诉”等场景。这一层只关心”何时”发起认证和”拿到什么结果”，而不关心”如何”完成认证。
认证服务层：作为整个链路的核心，它对上层提供统一、稳定的接口，对下层屏蔽复杂的实现细节。所有认证请求都通过一个统一的认证客户端发起。
SDK 抽象层：将所有第三方认证 SDK 的能力进行抽象，定义了统一的认证服务接口，涵盖了”初始化”、“启动认证”等原子能力。无论是服务商 A 的 SDK 还是服务商 B 的 SDK，都通过一个适配器实现这个统一接口。
第三方 SDK 层：即各个服务商提供的原生 SDK。

关键设计

云端动态分配

具体使用哪个第三方 SDK，不由客户端硬编码决定，而是由业务服务器在下发认证凭证时动态指定。这种模式极大地提升了业务的灵活性和系统的容灾能力，同时方便服务端实现对不同认证服务商在成功率、耗时、费用等维度的A/B 测试，用数据驱动决策。

多 SDK 统一封装与抽象

该设计的基石在于对多 SDK 的统一封装。通过定义统一的服务标准接口和统一的数据模型，将不同服务商 SDK 的差异性完全收敛在独立的适配器中。这使得上层业务逻辑完全与具体的 SDK 实现解耦，实现了认证能力的可插拔。

模块动态化

考虑到认证功能并非高频使用，且其依赖的库（尤其是底层库）体积较大，将整个认证模块设计为动态加载。当用户首次触发认证流程时，客户端才通过动态模块加载器去加载。

认证流程

sequenceDiagram participant 用户 participant 业务应用层 participant SDK抽象层 participant 认证服务层 participant 服务端用户->>业务应用层: 触发认证业务应用层->>业务应用层: 1. 业务认证场景业务应用层->>业务应用层: 2. 构建标准化参数业务应用层->>SDK抽象层: 请求调起认证 (带参数) SDK抽象层->>SDK抽象层: 6. SDK初始化 SDK抽象层->>用户: 7. 调起认证界面用户->>认证服务层: 8. 执行操作 (例如输入凭证) 认证服务层->>认证服务层: 9. 本地预处理认证服务层->>服务端: 请求获取/验证云端凭证服务端-->>认证服务层: 返回云端凭证/验证结果认证服务层->>认证服务层: 3. 获取云端凭证 (完成) 认证服务层->>认证服务层: 4. 动态加载SO库认证服务层->>认证服务层: 5. 权限校验认证服务层->>服务端: 10. 上报认证结果服务端-->>认证服务层: 确认上报认证服务层->>SDK抽象层: 返回认证结果 SDK抽象层->>业务应用层: 返回认证结果业务应用层->>用户: 显示认证结果

Hugo 多图排版 even 主题适配

Mon, 24 Mar 2025 00:00:00 GMT

在使用 Hugo 搭建个人博客时，常常会遇到图片排版的问题。尤其是竖图和横图混合时，Hugo 默认的排版方式会让竖图左右留出大量空白，显得不美观。此外，Markdown 本身也不支持横向排列图片（除非使用内嵌 HTML，但这种方式存在诸多问题，我尝试后已放弃）。

之前我参考了一篇 Hugo 多图排版的教程，但按照教程操作后并没有达到预期效果。评论区里也有其他用户遇到了类似问题，但原作者并未给出解答。

image-20250325152613877

经过一番检查和尝试，我发现问题出在主题生成静态页面时，会将 Markdown 中的图片用 <a> 标签包裹，以便实现点击预览大图的效果。这与原教程的 CSS 选择器不匹配，导致样式无法生效。下面是适配方案。

/* 多图分栏样式 */
.post-content p:has(> a:nth-child(2)) {
  column-count: 2;
  column-gap: 8px;
  margin: 6px 0;
}
.post-content p:has(> a:nth-child(3)) { column-count: 3; }
.post-content p:has(> a:nth-child(4)) { column-count: 4; }
.post-content p:has(> a:nth-child(5)) { column-count: 5; }
.post-content p:has(> a:nth-child(6)) { column-count: 4; }

/* 处理图片显示 */
.post-content p:has(> a:nth-child(2)) a {
  display: block;
  margin-bottom: 8px;
  break-inside: avoid;
}

/* 针对6图模式调整间距 */
.post-content p:has(> a:nth-child(6)) a {
  margin-bottom: 8px;
}

/* 确保图片填充容器 */
.post-content p a img {
  width: 100%;
  height: auto;
  display: block;
}

对于 Even 主题，需要将上述代码追加到 Blog/themes/even/assets/sass/_partial/_post/_content.scss 文件中。请注意，不同 Hugo 主题的 content 文件目录可能会有所不同，具体路径需要根据你所使用的主题进行调整。

使用规则

使用规则与原教程一致。图片之间可以换行，但不能空行，这样 CSS 会根据 <p> 元素内的 <img> 标签数量自动调整分栏数量。例如：

#### 更多图片横竖随机

![](https://cn.bing.com/th?id=OHR.Breckenridge_EN-US4460042968_768x1280.jpg)
![](https://cn.bing.com/th?id=OHR.BisonWindCave_EN-US4537340482_1280x768.jpg)
![](https://cn.bing.com/th?id=OHR.Umschreibung_EN-US4693850900_768x1280.jpg)
![](https://cn.bing.com/th?id=OHR.DonkeyFeast_EN-US1153850805_768x1280.jpg)
![](https://cn.bing.com/th?id=OHR.SessileOaks_EN-US1487454928_1280x768.jpg)
![](https://cn.bing.com/th?id=OHR.DonkeyFeast_EN-US1153850805_1280x768.jpg)
![](https://cn.bing.com/th?id=OHR.RumeliHisari_EN-US4800002879_1280x768.jpg)
![](https://cn.bing.com/th?id=OHR.InscriptionWall_EN-US1392173431_1280x768.jpg)
![](https://cn.bing.com/th?id=OHR.HummockIce_EN-US4606231645_768x1280.jpg)

效果如下

两张

三张

四张

贵州山水

Fri, 20 Sep 2024 00:00:00 GMT

Day 1

下午落地贵阳，因为晚上要赶高铁去安顺，白天只安排了「长征文化数字艺术馆（红飘带）」一个景点。从地铁站出来后，发现离目的地还有一段距离，门口倒是有共享电动车可以骑。第一次真实感受到贵州的山地地形——地铁站孤零零地建在高处，周围几百米都是空地，没有其他建筑，很贵州。

艺术馆主要看了沉浸式宣传片《红飘带·多彩飞越》，用全息投影、3D Mapping这些技术把贵州的知名景点都展示了一遍（题外话：北京环球影城的变形金刚·火种源争夺战用的也是类似技术）。晚上吃了贵州酸汤火锅，味道直接惊艳到我，回北京后还特意找了几家连锁店去吃，可惜北京的店没有提前调好的蘸料，味道还是差了点。

Day 2

全天都在「黄果树瀑布」逛，作为国内知名景点，名气确实大，但实际体验只能说一般。瀑布本身挺壮观的，水雾也大，但景区里的指示牌有点离谱——明明写着“前方20米观景台”，结果走了200米才到。步道设计有点复杂，容易走冤枉路，而且观光车还要额外收费，感觉不太厚道。第一次来贵州可以打个卡，但别抱太高期望，属于典型的“来都来了”景点。

Day 3

如果要给这次贵州之旅的景点排个序，「荔波小七孔」绝对是榜首。酒店直接订在景区旁边，时间很充裕。早上先去吃了小红书上很火的牛肉粉和刨冰，味道不错，就是牛肉有点难嚼，吃多了牙疼。

小七孔虽然要走不少路，但水是真的清澈，绿得像加了滤镜一样。最爽的是划透明船，水浅的地方能直接看到底，划到树荫下躺平，听着水流声，整个人都放空了，差点睡着。「大七孔」是坐游船进去的，两边的山特别高，水特别静，和小七孔是完全不同的感觉，甚至有点江南水乡的韵味。总之，大小七孔都极度推荐！

Day 4

贵州古镇不少，因为第二天要去漂流，顺路选了「镇远古镇」。这里还住着不少本地人，商业化不算太重，逛起来比较舒服。核心区不大，沿着舞阳河走一走，两三个小时就能逛完。老房子挺有味道，但住宿条件一般，不建议专程来，作为漂流的中转站刚好。

晚上坐了夜游船，灯光映在河面上，两岸的老建筑倒影很美，夏夜凉风吹着特别惬意。晚餐吃了家开了十几年的红酸汤火锅，小盘菜自选，酸辣够味，比连锁店更地道。不过默认蘸料会加折耳根，不吃的记得提前说。整体来说，适合慢悠悠地逛，不用太赶时间。

Day 5

「高过河漂流」是这次旅行的主要目标，结果也没让人失望。因为是中秋假期，人比平时多，但排队还算快。两人一船，现场可以拼船（单身狗友好）。河水挺急的，但越急越爽，有几个坡道落差很大，冲下去的时候全身浸在水里，特别刺激。

水枪战也是亮点，沿河一路都有卖水枪的，建议买带水管的那种，不用抽水，战力直接翻倍。不过要注意安全，因为翻船落水的情况几乎每天都有，我们也碰到了。虽然沿河都有救生员，但湍急的河段他们也不敢贸然下水，只能等你漂到水流平稳的地方才会施救。总的来说，超级好玩！强烈推荐！

Day 6

因为往返机票都是贵阳，所以提前一天返回贵阳休整，去了「青云集市」和「黔灵山公园」。青云集市就是一条改造过的商业街，小吃和文创店居多，和别的城市网红步行街差不多，没什么特色，个人不太感冒。黔灵山公园就是普通城市公园+很多猴子，也没网上说的那么好玩。

Thailand

Wed, 05 Jun 2024 00:00:00 GMT

最喜欢的泰拳🥊当封面

准备

不用准备，提前买个电话卡带着护照直接冲！换汇什么的图便宜国内换，图方便机场换，其他都不是必需品，连衣物都不用多带，入乡随俗，现买现穿！

地铁有点繁琐，出行还是打滴🚖方便，出租车软件有Bolt、Grab，Bolt是价格便宜，还有摩托车车型（有点危险，但很快很快很快，无视红绿灯那种），只支持现金支付。Grab司机接单的时间会短一些，但是价格也贵一些，还支持Alipay。

另外不用预订接机，出机场直接打滴走更快更方便。

日程

Day 1

Pasted Graphic

来泰国的第一站安排给了火遍小红书的、网传各大明星都纷纷去祭拜的「四面佛」，但现场的实际情况有点失望，是在路边的很小的一块区域，紧挨十字路口，旁边就是车来车往的马路，跟其他去过的宗教场所一样，现场可以购买各种鲜花、大象雕塑等物品供奉给佛像表达敬意并换取保佑，不过在祭拜的当地人确实很多，倒是游客一般只是参观，总的来说不推荐。

img

「卧佛寺」、「大皇宫」、「郑王庙」三个建筑群大同小异，就是一种国内没有的宗教建筑风格，选一个仔细参观即可，三个地方全部逛完的话会审美疲劳。但是夜晚的「郑王庙」一定不能错过，一旦夜晚降临，亮灯的「郑王庙」一定是湄南河畔附近最美的景色，观赏的地点可以选在湄南河的游轮上，或者河畔对面的咖啡厅（推荐 vivi the coffee place），金色的寺庙孤立在湄南河畔，道道金光洒在在湄南河水上金光粼粼，绝美。

6A73D29A-C1BA-495C-B271-0533F6233EB1_1_105_c

4C6681D2-078A-48FA-9986-F5BB7AE3762B_1_105_c

「死亡博物馆」前几天行程里我很喜欢的一站，Siriraj医学院对外开放的医学博物馆，整体参观完的心情是沉重的，死于连环杀手下的受害者尸体、癌症恶化的器官标本、绝症患者的横切面、泡在防腐缸的畸形婴儿、甚至可以清晰的看到缸中婴儿的睫毛。走出博物馆的大门，曼谷40度的空气扑面而来，感恩自己还可以呼吸。

「考山路夜市」给我感觉只有“乱”，感觉整条路的商家都在比拼谁的音响更胜一筹，隔几条街都可以听见的混乱音乐、弥漫在空气中的大麻味道、二手烟、混合欧美白男的香水和汗臭味，勉强屏住呼吸才可以在街上穿梭，饭菜的辣椒油中也散发出熏鼻的汗臭味，分不清是商家特意调制，还是长期放置吸收了太多空气中的汗液，不理解。

Day 2

Pasted Graphic 1

「Bangkok网红天桥」已经刷爆国内小红书了，曼谷新地标之一，拍照打卡的中国人很多，井然有序的排队打卡，将近40度的温度下摆两分钟姿势就满头大汗。从天桥下来就是「曼谷文化艺术中心」，在曼谷算是最大的艺术展览中心了，但是放国内的话个人感觉比较一般了，不多赘述，路过可以去，没必要刻意跑一趟。

6E65B424-751C-4C7B-AB56-CDEC3523C7FF_1_105_c

「水门寺大佛」也是在简中网上很火，但如果满怀期待的去的话，恐怕不会很满意，就是一座城区中的大佛，网上的照片一般都是用超长焦拍出来的，所以显得主体会比较大，真实情况可以参考下面我用105焦距镜头拍摄的效果，可以在 796soi thoet thai 26、60 Phet Kasem 15 Alley 这个位置拍摄，另外周围会有一条河，有游船参观的服务，介意河水的颜色和味道，个人建议还是不要尝试。

1C24D257-1C43-4505-AA4F-3DA9F0E0DFD7_1_105_c

8D3D2528-EA43-477E-8C1E-C8D8FD3CE471_1_105_c

「Iconsiam」就在湄南河沿岸，坐公交船就可以直达，算是目前曼谷最新的商场了，门店种类和客流量都是曼谷屈指可数，一楼是室内集市，有曼谷各种街头小吃的干净版本，可以放心吃，楼上还有很多家米其林餐厅，唯一可惜的是没有比较好的面馆。

48C2B81E-3DC5-43D3-B464-9E16B32B500B_1_105_c

3001FD2D-6F22-455F-A536-8DE157A75F67_1_105_c

Day 3、Day4

image-20240812231017462

「金东尼人妖秀」是大众尺度里最出名的，但并不推荐，节目类似联欢晚会，音乐和舞蹈的结合，都是假唱，观赏体验一般，演出结束会有合影阶段，给人妖小费就可以合影，人妖都会很热情。顺便推荐下饼叔的视频「神鬼传奇」，里面有一段对人妖表演者的采访，可以帮助你更好的理解这种职业。

7D49D6C8-EDA9-4365-AC32-0014CD3C5052_1_105_c

3870acfe181e9a107c3318b54cd605d5

「拉差达慕拳击馆」充满荷尔蒙的泰拳比赛🥊，算是个人感觉来泰国最喜欢的一个环节，现场氛围满满，价格1600-2500🐷不等，建议一等座，体验感拉满。

2D9BB3ED-4084-4AB8-91E9-22ED67458E06_1_105_c

「Moon bar」花小钱装大杯，曼谷悦榕庄酒店59楼的一家清吧，有酒水就餐食，门票可以抵扣消费，可以拍拍照打卡，很出片。同类网上比较火的还有「像素大厦」但是后者排队太严重了。

Day 5、Day 6

image-20250315184233283

「真理寺」一座用不完工的木质宫殿，里面所有建筑都是由木头建造，常年在海边受侵蚀，所以一直在修筑，还是很壮观的，还会有中文讲解，会讲解各个所雕刻神佛的含义，不过个人对这种神神怪怪的不感冒。

8CA27EAF-0FD7-4D95-952C-B5A98640A845_1_102_a

「大象村」好玩！推荐！可以骑大象，有水路有陆路，会载着你围着景区转一圈。门票是直接包含骑大象30min + 椰子🥥 + 表演，为数不多及其推荐的景点。

34983618-E950-4468-8BD3-D54C044947D5_1_105_c

7EAC5F4E-BCE5-4042-B826-ABB726F56946_1_105_c

「79 SHOW」只能用炸裂一个字来形容，入场会收手机、相机等拍摄设备，场内昏暗，灯光只聚集的舞台上，座位是随便做的，先到先得，中途有人走了可以去换座位，前三排是互动区，互动很炸裂，不想互动不要坐前排可以是来芭提雅必打卡的项目。

「中天海滩夜市」与中天海滩只隔了一条马路，下午5点开始营业，买好没事喝啤酒可以坐在路边木凳上欣赏日落，还可以到对面的中天海滩散步，很惬意。

Day 7

image-20250315184301457

「格兰岛」在网络上有三个比较火的地方，Tawaen、Tien Beach、Samae Beach，我们去的是Tawean，游玩项目是最丰富的，拖拽伞、玻璃船、摩托艇、香蕉船、浮潜砍完价一共1500🐷左右，一定要砍价，会优惠不少。岛上可以租突突车自己转着玩，不过山路比较崎岖，要注意安全。

25780240-A7F6-461D-9B60-D06ADB589BD2_1_105_c

关于 IDEA Plugin 开发

Sat, 11 May 2024 00:00:00 GMT

介于团队的代码格式化插件过于远古，我对其进行了升级重写。新的实现切换了代码格式化的核心库，增加了对 Kotlin 语言的支持，并新增了若干 Inspections 静态代码检查功能。在这里记录此过程中，我对 IDEA Plugin 的理解以及首次进行相关开发的经验。

为什么需要 IDEA Plugin？

聚焦于 Android 开发场景，我理解 IDEA Plugin 开发的必要性主要体现在两点：统一规范 与 开发提效。

IDE 作为开发工具，是部署在开发者本地的，团队的每个成员都有自定义其配置的能力。如果不同开发者使用不同的开发规范和代码规范，势必会导致代码管理上的混乱。没有人希望在拉取远程最新代码时，因为代码格式不统一而弹出大量的冲突问题。

除了代码格式上的规范，开发团队对于代码安全等方面也有不同的规范。例如，对 java.util.Random 伪随机数的使用，以及 Color.parseColor() 方法在解析未知内容变量时可能引发的 IllegalArgumentException 异常。如果这些问题在开发阶段没有被拦截，工作量就会堆积到 Code Review 阶段，甚至可能被带到线上。这些琐碎问题的堆积，会为项目代码质量和安全性制造隐患，从而影响日常项目的开发效率。

所有这些问题都可以通过定制 IDEA Plugin 来解决。总而言之，IDEA Plugin 开发的目的就是满足团队在代码规范、架构约束以及独特工作流上的个性化需求，解决 特定团队 的 特定痛点，以此提高团队的工程效率。

PSI

**PSI (Program Structure Interface) **是 IntelliJ 平台中一个核心的概念，它是对代码的一种抽象表示。可以将其类比为 Android 视图系统中的 View 层次结构。在 Android 中，UI 界面的所有元素都被抽象为 View 对象，并以树状结构组织起来，我们可以通过遍历 View 树来查找、修改或操作 UI 元素。同样，PSI 将源代码（如 Java、Kotlin 文件）解析成一个抽象语法树（AST），树中的每个节点都是一个 PsiElement，代表了代码中的一个结构，例如类、方法、变量、表达式等。

具体来说，PsiElement 是 PSI 层次结构的基类，所有表示代码元素的类都继承自它。例如：

PsiFile：代表一个源代码文件，是 PSI 树的根节点。
PsiClass：代表一个类或接口。
PsiMethod：代表一个方法。
PsiExpression：代表一个表达式，比如 new Random() 或者 Color.parseColor("#FFFFFF")。
PsiReferenceExpression：代表一个引用表达式，例如方法调用中的方法名部分。
PsiNewExpression：代表一个 new 关键字创建对象的表达式。
PsiMethodCallExpression：代表一个方法调用表达式。

使用 PSI，可以在不直接操作文本内容的情况下，以结构化的方式访问、分析和修改代码。这就像在 Android 中，我们通过 findViewById 找到一个 Button 对象，然后调用它的 setText() 方法来改变按钮的文本，而不是直接修改布局文件中的 XML 字符串。

在 IDEA Plugin 开发中，通常会用到 PsiDocumentManager 来获取当前文档对应的 PsiFile。例如，在文件保存前对文档进行操作时，通过 PsiDocumentManager.getInstance(project).getPsiFile(document) 可以获取到与 Document 关联的 PsiFile 对象。有了 PsiFile，我们就可以利用 PSI 提供的各种 API 来遍历和分析代码结构，进而实现代码检查、重构、格式化等功能。

Format

之前是插件内部维护格式化规则，在升级后我将具体的格式化规则交给成熟的开源库，Java 使用 google-java-format、Kotlin 使用 ktfmt，并重写格式化逻辑，尽可能的精简代码，提高维护性。大体流程可以分为：注册、监听、格式化。

插件启动时，通过 FormatInstaller 将自定义的 FormatCodeStyleManager 注册为项目的 CodeStyleManager 。它会包装IntelliJ IDEA原生的 CodeStyleManager ，并根据文件类型决定是使用自定义格式化逻辑还是委托给原生管理器。

通过实现 DocumentManagerListener，插件可以监听文件保存前的事件。当用户保存 Java 或 Kotlin 文件时，DocumentManagerListener 的 beforeDocumentSaving方法会被回调，并触发格式化。

public class DocumentManagerListener implements FileDocumentManagerListener {
    @Override
    public void beforeDocumentSaving(@NotNull Document document) {
        // ... 获取当前 Project 和 PsiFile
        if (psiFile != null && (psiFile.getName().endsWith(".java") || psiFile.getName().endsWith(".kt"))) {
            ApplicationManager.getApplication().invokeLater(() -> {
                new WriteCommandAction.Simple(project) {
                    @Override
                    protected void run() {
                        // 调用 CodeStyleManagerDecorator 进行格式化
                        CodeStyleManagerDecorator.getInstance(project).reformatText(psiFile, Collections.singletonList(psiFile.getTextRange()));
                        // 保存文件
                        ApplicationManager.getApplication().invokeLater(() -> FileDocumentManager.getInstance().saveDocument(document));
                    }
                }.execute();
            });
        }
    }
}

FormatCodeStyleManager 接收到格式化请求后，会根据文件类型（Java 或 Kotlin）调用相应的格式化工具，获取对应的格式化结果。最终，所有替换操作在一个 WriteCommandAction 中执行，确保原子性。

private void formatInternal(PsiFile file, Collection<? extends TextRange> ranges) {
    if (JavaFileType.INSTANCE.equals(file.getFileType())) {
        performReplacements(document, JavaFormatterUtil.getReplacements(new Formatter(), document.getText(), ranges));
    } else if (KotlinFileType.INSTANCE.getName().equals(file.getFileType().getName())) {
        performReplacements(document, KotlinFormatterUtil.getReplacements(KotlinUiFormatterStyle.GOOGLE, document.getText()));
    }
}

private void performReplacements(final Document document, final Map<TextRange, String> replacements) {
    if (replacements.isEmpty()) return;
    TreeMap<TextRange, String> sorted = new TreeMap<>(comparing(TextRange::getStartOffset));
    sorted.putAll(replacements);
    WriteCommandAction.runWriteCommandAction(getProject(), () -> {
        for (Entry<TextRange, String> entry : sorted.descendingMap().entrySet()) {
            document.replaceString(entry.getKey().getStartOffset(), entry.getKey().getEndOffset(), entry.getValue());
        }
        PsiDocumentManager.getInstance(getProject()).commitDocument(document);
    });
}

Inspection

还在插件中添加了一系列静态代码检查功能（Inspections），目的是帮助团队成员在开发阶段发现并修正代码中潜在的问题。这与 Android 开发中 Lint 工具的目标非常相似，都是在编译或开发阶段提供反馈，避免问题流入后期。

一个 Inspection 的实现通常继承自 AbstractBaseJavaLocalInspectionTool（或其对应语言的基类），并重写 buildVisitor 方法，返回一个 PsiElementVisitor。这个 Visitor 会遍历 PSI 树，在访问特定类型的 PsiElement 时执行检查逻辑。如果发现问题，就通过 ProblemsHolder.registerProblem 注册一个 ProblemDescriptor，这会在 IDE 中以高亮的形式提示开发者，并可以附带一个 LocalQuickFix 来提供自动修复功能。

介于大多数 Inspections 都是强业务相关的，这里只挑选两个与业务逻辑无关的纯技术规范侧的检查项。

Random 伪随机数

目的：检测代码中是否使用了 java.util.Random 这个伪随机数生成器。在安全性要求较高的场景，推荐使用 java.security.SecureRandom 以获取更好的随机性。

实现：通过重写 JavaElementVisitor 的 visitNewExpression 方法，检查 PsiNewExpression 中创建的对象是否为 java.util.Random 的实例。

快速修复 (RandomQuickFix)：如果检测到问题，会提供一个 Quick Fix，将 new java.util.Random() 替换为 new java.security.SecureRandom()，并自动导入 SecureRandom 类。

@Override
public void visitNewExpression(PsiNewExpression expression) {
  super.visitNewExpression(expression);
  String qualifiedName = null;
  PsiJavaCodeReferenceElement classReference = expression.getClassReference();
  if (classReference != null) {
    qualifiedName = classReference.getQualifiedName();
  }
  if ("java.util.Random".equals(qualifiedName)) {
    holder.registerProblem(
        expression, INSPECTION_DESCRIPTION, INSPECTION_TYPE, new RandomQuickFix());
  }
}

private static class RandomQuickFix implements LocalQuickFix {
  @Override
  public void applyFix(@NotNull Project project, @NotNull ProblemDescriptor descriptor) {
    PsiElementFactory factory = JavaPsiFacade.getElementFactory(project);
    PsiExpression newExpression =
        factory.createExpressionFromText("new java.security.SecureRandom()", descriptor.getPsiElement());
    PsiElement replacedElement = descriptor.getPsiElement().replace(newExpression);
    JavaCodeStyleManager codeStyleManager = JavaCodeStyleManager.getInstance(project);
    codeStyleManager.shortenClassReferences(replacedElement);
    codeStyleManager.optimizeImports(replacedElement.getContainingFile());
  }
}

Color.parseColor()

目的：当 Color.parseColor() 方法解析的是一个未知内容的变量时，建议使用 try-catch 块捕获 IllegalArgumentException 异常，以增强代码的健壮性。

实现：通过重写 JavaElementVisitor 的 visitMethodCallExpression 方法，检查方法调用是否为 Color.parseColor。如果方法的参数不是常量或字面量，并且当前调用没有被 try-catch 块包裹，则注册问题。isWrappedInTryCatch 方法会向上遍历 PSI 树，查找是否存在 PsiTryStatement。

快速修复 (ColorParseFix)：提供 Quick Fix，将 Color.parseColor() 的调用语句用一个 try-catch 块包裹起来。

// 从 ColorParseInspection 中精简
@Override
public void visitMethodCallExpression(PsiMethodCallExpression expression) {
    super.visitMethodCallExpression(expression);
    // ... 获取 methodExpression
    if ("Color.parseColor".equals(method)) {
        PsiExpression argument = argumentList.getExpressions()[0];
        if (!PsiUtil.isConstantExpression(argument)
                && !(argument instanceof PsiLiteralExpression)
                && !isWrappedInTryCatch(expression)) {
            holder.registerProblem(
                    expression, INSPECTION_DESCRIPTION, INSPECTION_TYPE, new ColorParseFix());
        }
    }
}

private boolean isWrappedInTryCatch(PsiElement element) {
    // ... 向上遍历 PSI 树查找 PsiTryStatement
}

private static class ColorParseFix implements LocalQuickFix {
    @Override
    public void applyFix(@NotNull Project project, @NotNull ProblemDescriptor problemDescriptor) {
        // ... 创建 try-catch 代码块并替换原始语句
    }
}

AS 适配

Android Studio 基于 IntelliJ IDEA 平台构建。为了允许插件访问 JDK 内部的 API（这些 API 可能是 google-java-format 等库所依赖的），需要在JVM启动参数中添加特定的 --add-opens 和 --add-exports 选项。如果这些 JVM 选项不足，可能会导致插件运行时出现 InaccessibleObjectException 等错误，从而使代码格式化功能失效。不同版本的 IDEA 平台设置这些 JVM 参数的方式有所不同。

如果基线版本大于等于 213，直接调用 VMOptions.setOption() 来设置所需的 --add-opens 和 --add-exports 参数。

如果基线版本低于 213，则需要手动修改 VM Options 文件。它会获取 VM Options 文件的路径，读取其内容，如果文件中不包含所需的参数，则将这些参数追加到文件末尾，并确保文件可写。

if (version >= 213) {
    VMOptions.setOption("--add-opens=java.base/java.lang", "=ALL-UNNAMED");
    VMOptions.setOption("--add-opens=java.base/java.util", "=ALL-UNNAMED");
    // ...
} else {
    Path path = VMOptions.getWriteFile();
    if (path == null) {
        return;
    }
    File file = path.toFile();
    try {
        String content = FileUtil.loadFile(file);
        if (!content.contains("--add-opens=java.base/java.lang=ALL-UNNAMED")) {
            content = content + "\n" +
                    "--add-opens=java.base/java.lang=ALL-UNNAMED\n" +
                    "--add-opens=java.base/java.util=ALL-UNNAMED\n" +
                    // ...
            FileUtil.writeToFile(file, content);
        }
    } catch (IOException ignored) {
    }
}

稳定的理想主义者

Sat, 03 Feb 2024 00:00:00 GMT

事情是这样的，在最近一坤年的跨度里我做过 5 次 MBTI 人格类型分析，最终得出的结果都是「INFJ-A」，期间还经历了题库的几次迭代变化，所以能如此稳定的得到统一结果，这让我还是蛮意外的。为了进一步验证 MBTI 对于人格类型归纳的准确性，我打算将网上对于 INFJ 人格的描述与自己察觉的真实情况进行比较。

下文中引用的内容均来自于 16personalities 网站中对于 INFJ 人格的描述。

INFJ 可能是最稀有的人格类型，但他们肯定会在世界上留下自己的印记。他们理想主义、有原则，不满足于平平安安地度过一生—他们想要站起来，有所作为。对于 INFJ 来说，成功不是来自金钱或地位，而是来自寻求成就感，帮助他人，成为世界上一股向善的力量。

最稀有的人格类型？哈哈查了一些资料发现，国内互联网上关于 MBTI 的内容大多都是直接 “ 英译汉 ” 从外网搬运来的，所以引用中的修饰词也要加上 “ America ” 的前缀，实际上在国内的特殊环境下成长的 95 后中 INFJ 人格类型的占比还是不少的，国内最稀少的人格类型应该是被称为「指挥官」的 ENTJ。当然这些不属于自我人格的范畴。

回到正题本身，“ 理想主义、原则性 ” 这些标签我是欣然接受的，毕竟寻找理论落地过程中由于人类劣根性导致的偏差是我乐子之一。但 “ 不满足于平淡生活 ” 这就有点不符合了，近几年所作的事情和近期对未来的规划都是在为畅想中的 “ 平淡生活 ” 作准备，虽然我很纠结于 “ 人生意义 ” 这个话题，但这种意义不是来自于社会地位的提升、也不是外在的物质财富，而是来自于内心畅想的实现，或者说将自己所坚持的规则（原则）具现出来并应用到现实社会。所以…哈哈太难了，畅想仅仅是畅想。

INFJ 往往会有一种与大多数人不同的感觉，由于他们丰富的内心生活和寻找生活目标的深沉而持久的渴望，他们并不总是与周围的人融为一体，幸运的是，这种不合拍的感觉并没有削弱 INFJ 让世界变得更美好的承诺。

INFJ 受到不公正的困扰，他们通常更关心利他主义而不是个人利益，许多 INFJ 将帮助他人视为生活中的使命，他们一直在寻找介入并为正确的事情大声疾呼的方法。具有这种人格类型的人也渴望解决社会更深层次的问题，希望不公平和艰辛能够成为过去。

别说了，像在被讽刺一样，如果我从小在一个比较包容开放，接受多元价值观的地方成长，那可能确实会像上面说的一样现在还在坚持倡导一些事情。但事实是我目前想不到任何我所能做的可以 “ 让世界变得更美好 ” 的事情，只能顾好自己和珍视的人，虽然现在看见 “ 精致的利己主义者 ” 还会恶心作呕，但也不会有任何想要争辩或者 “ 他是错的我是对的 ” 这样的想法。其实我也不确认对方是错的，只是不喜欢而已。

INFJ 可能内向，但他们重视与他人的深厚、真实的关系。很少有事情会像真正认识另一个人一样给这些性格类型带来快乐—同时也为别人所理解。INFJ 喜欢有意义的对话远远超过闲聊，他们倾向于以热情和敏感的方式进行交流。这种情感上的诚实和洞察力可以给周围的人留下深刻的印象。

这倒是真的，我虽然是个典型的 i 人，但对于认识新朋友，特别是了解新朋友、与新朋友进行深度对话，我是毫不吝啬的，在解锁一个人的人生经历、情感经历、特别是三观塑造历程的时，我内心得到的满足和快感是十分强烈的。（我始终于好奇不同成长经历对于个体三观塑造的影响）

INFJ 喜欢在工作中保持整洁有序，喜欢平和、安静的气氛，希望工作中每个人的贡献能得到肯定，每个人都有成就感，所有的工作都能和谐地取得良好的结果。

这让我不得不贴一下我使用了两年的工位了，就像我 About 页所写的一样，「有序」始终是我生活的主旋律。

最后，其实之前在纠结 MBTI 准确性的时，有跟朋友讨论过 MBTI 与星座的区别，讨论过程有个类比觉得十分恰当。

一场考试中你物理得分 90 分，化学得分 60 分，说明你物理比较好，我会给你打上 “ 物理 ” 的标签，这就是 MBTI，MBTI 中对于人格的描述与自我察觉的实际情况间的差异可以看作 “ 考试中影响结果的运气等不稳定因素 ”。而星座的话，就是不用参加考试，直接根据你的生辰来判定你物理、化学所得的分数。

就这样吧，希望有个愉快的春节。

2023 年国庆自驾川藏线摄影记录

Thu, 19 Oct 2023 00:00:00 GMT

成都太古里裸眼 3D 巨幕，很震撼。

8794695C-73F1-4B96-946A-58012A58A255_1_105_c

雅安自驾大本营回身随拍，318 旅途的起点。

7AE60657-9E28-48B3-BB36-C9384EA6D12D_1_105_c

驾离市区，向大山前进，海拔开始拔升，云气触手可摸。

26229F08-9B05-4941-B9EA-8E48214717CD_1_105_c

路上随处可见的经幡和国旗。

950CB7B5-5767-48E4-AA52-8261AAD0CFEE_1_105_c

云雾弥漫中的折多山。

4C481D9B-53F4-4C37-B353-59F102DD31DE_1_105_c

团队的第一张合照。（我是摄影狮

E13F7074-A0E9-44F4-BB2B-3B1B5B09F681_1_105_c

我在折多山很想你。

C25FA65B-80DC-44E2-B023-9810D0B4651F_1_105_c

喜马拉雅山脉阻断的印度洋暖湿气流形成的云雾。

EDA0719D-6580-402B-B137-FC3997CFADF8_1_105_c

新都桥民宿的藏族老板招待的牦牛肉火锅，超香！（有个伙计因为高反在休息，错过了

9135CBBB-66AF-4C95-8D59-9CD1C15F9829_1_105_c

民宿门口的无名小河。

DB42D55D-9CE2-44F4-9987-B41EAC729261_1_105_c

继续出发，行驶在山野。

71FD1F73-CB3E-4D98-9D01-5171CDAEA7D0_1_105_c

观景台对面山上的藏文牌子。（在西藏支教过的堂哥说是 “ 宗喀巴大师 ” 的意思

F3993ECD-F730-48D0-9665-A7A579823BDE_1_105_c

随处可见的雪山观景台。

FEC58901-817F-4256-9DC5-09773F86832D_1_105_c

牛吃草。

78C610FD-D055-41FB-9E5B-6A210B5C998A_1_105_c

山在脚下，张开手就可以拥抱云彩。

18C51B3A-F06A-4AAF-AD14-A06A77441A30_1_105_c

Windows 10 壁纸。

57F91480-5954-41E4-8523-CCA23C67E5D1_1_105_c

草原哈雷。

26E1C82F-4DF2-422B-B4E7-88DBBFD9F8FC_1_105_c

甘孜的 “ 蒙古包 ”。

4248D4E4-B38B-4010-BB5E-CE4E62D4E22E_1_105_c

万岁！

到达世界最高城，理塘！（偶遇一个很帅的爆改 3 系

0B277FD7-05DD-487B-808C-99E63C0B5C6C_1_105_c

初入稻城亚丁。（要坐 1 个小时大巴车，累的很

CADD30F2-F68E-4594-B3B4-C26F7D4FC293_1_105_c

跟 Chichi 一起爬央迈勇神山。

E04D2530-3C15-4F53-8B86-81DBE7BC34E2_1_105_c

珍珠海（藏语叫 “ 卓玛拉措 “，其实只是一个大一点的水塘

E0964912-B26C-4A6B-AD1F-660253AD207D_1_105_c

亚丁里的雪山，忘记是哪座了。（在亚丁后面相机没电了，拍的比较少

791C9072-9EF5-4B3D-A109-32392A4926DA_1_105_c

跟 Chichi 堆的玛尼堆。

4D284DDE-DEB7-4D14-9664-5F2A2E5BCA84_1_105_c

海子山的姊妹湖！

314C1B67-C73C-4141-B288-AE8993236075_1_105_c

观景台附近的移动咖啡店。

AAC4EC2C-D34A-40BB-9EBF-5CFAC9274DF9_1_105_c

一只狗

86205820-3A51-45D1-AE6C-C9E1EEFF7EA9_1_105_c

初入措普沟（可以感觉出来巴塘官方是真心想发展这个景区，对外游客特别友好，力推！

BDAF952D-EDEB-4934-9440-3E145563B0E2_1_105_c

措普沟圣山脚下的 Tiffany 蓝。

E5494276-2342-4FC1-924D-31B256556191_1_105_c

三小只。

1591697707273_.pic_hd

色拉山垭口拍的南迦巴瓦峰的日照金山。

B40C550B-E1A1-4184-927A-9AF93E4F3518_1_105_c

阅读、游历和爱情

Sun, 30 Apr 2023 00:00:00 GMT

现代生活无时无刻不经受着冲击，滚滚历史八面来风，如何在纷纭中走自己的人生路？将阅读梁永安老师的《阅读、游历和爱情”》一书过程中的所得、体会记录于此。

关于自我，涉及多个层面。一个是本然的自我，一路成长过来所形成的自我，是以往你所有选择的结果。另一个是想象中的自我，是经过自我意识洗礼，变形折射而来的，不是本真的自我。还有一个是理想中的自我，即自己觉得我应该是怎样的。

认识自己的过程就是寻找本然自我的过程，首先一定要了解自己在社会和历史舞台上所处的位置，而不是做一个漫无目的的自然人，现在很多人看不清自我，就是不知道自己所处在什么位置上，有什么样的价值，千万别在你还没了解这个世界的时候，就把自己固定了。

在失去坐标的转型时代，青年人该如何定位自己？青年要认识自我，不能坐在房子里，坐井观天，往往需要在不完美的探索中认识自己，有痛苦，有欢乐，于痛苦中发现自己活着，于欢乐中发现自己还很平庸，在这个过程中，才逐渐知道自己热爱什么样的生活，跟什么样的世界联系在一起。这就是所谓青春的激情。

在这个过程中 孤独是很重要的环节，年轻的时候扔了很多珍贵的东西，到后来才发现，当年所藐视的、不值一提的东西才是最宝贵的，我们经常将无意义的东西误以为宝，只有在孤独中、在自己的选择里，体会出来的东西才是最真实的。

本然的自我一定是不完美的，但确实独一无二的，人只有受到阻力时，才能触动自己，反思自己的生命是否真实。一个人一旦通过这种野性的方式触动自己，心里便会一片透亮，感觉特别有价值感、幸福感，而人一旦体会到这种感觉，就不肯放弃了。这种愉悦一定是在路上探索才能体会的，不经一番寒彻骨，怎得梅花扑鼻香。

希望我们这新一代的人有生而为人的生命的连续性，在他的儿童、少年、青年、中年、老年各个时期，都能活得很真实，是一个由内向外生活的人，而不是由外向内、活在别人眼光里的人。

书中也有梁老师关于人格、修养的阐述，但我其实不太赞成梁永安老师在这本书中对于好人的定义，人格的好坏不能与认知是否清醒、人生价值是否实现相关联，单纯的、愚昧的、不思进取的人可能有一个发自内心对外在释放善意的人格，所幸的是对于道德在于人格的重要性，跟梁老师的看法还是一致的，就像康德所说，“ 有两种东西，我对它们的思考越是深沉和持久，它们在我心灵中唤起的惊奇和敬畏就会日新月异，不断增长，这就是我头上的星空和心中的道德定律。”

我们偶然来到这个世界，活着是为了什么？ 很多人是以获得为目的的，但是一个人究竟需要多少获得？很多人不珍惜自己，把自己放在虚荣、竞争等相对价值里，以为这样就可以令人羡慕，但最终又有怎样的价值呢？我们有可能正在恶的链条上发力，争取着虚名浮利，仅仅以周围的人为参照人群——我要过得比他们好，这其实是对自己价值非常大的贬低。

真正有价值的是寻找、珍惜自我，懂得这个世界的自由，珍惜个人生命的自由，关注自己的价值和社会需要的价值，确认自己能够做些什么，最终做出一些跟别人不一样的事情，为社会增添一些亮光，而不是执着于千篇一律的东西。这时，我们才会有一种全新的生命观。

最后，送给大家一句我很喜欢的话，这也是目前我对于生活的态度，“ 拥有可以接纳并允许一切发生的可能，从自我出发去分享表达，但不对反馈反响抱有限定的期待 ”。

在 Colab 搭建 Stable Diffusion

Wed, 22 Feb 2023 00:00:00 GMT

Form Weird Wonderful Ai Art

2023 年 9 月 23 日更新：Colab 官方禁用 Stable Diffusion WebUI，无法解决断网问题，本文方法作废。详情见 https://decrypt.co/197428/google-colab-stable-diffusion-web-ui-ban

🎨 Ai 绘画

Stable Diffusion 是 stability.ai 于 2022 年发布的深度学习文生图模型，可以在大多数配备有适度 GPU 的电脑硬件上运行。

Colaboratory 简称 Colab，是 Google Research 团队发布的一种托管式 Jupyter 笔记本服务，可以免费使用 GPU / TPU 计算资源。

这是一份保姆级的在 Colab 搭建 Stable Diffusion 服务的教程，按照以下步骤操作，即可浅尝 Ai 绘画的魅力。

分配资源

进入 Stable_Diffusion_WebUi_Altryne Colab 工程。

点击右上角的连接获取云主机资源并连接运行时。

1-image-20230222142539642

运行 1.0 单元格中的命令可以获主机信息。

1-image-20230222142936172

一般分配到的都是 Tesla T4 机型，如果人品欧分配到 V100，那可以好好的吹一波了。

配置模型

首先注册 Hugging Face 账号，并生成 WRITE 类型的 Access Tokens。

1-image-20230222144043327

返回到 Colab 界面，展开 1.4 Connect to Google Drive 单元格，勾选 download_if_missing 并输入 Hugging Face 的 Accsee Token。

1-image-20230222144232989

设置密码

在 2.1 Optional - Set webUI settings and configs before running 中配置密码。

1-image-20230222144551905

运行服务

将所有单元块收起，依次运行所有单元块部署服务即可。

运行耗时

Setup stage：5min
Run the Stable Diffusion webui：1s
Launch WebUI for stable diffusion：1min

1-image-20230222144857944

运行过程中会弹窗请求登录 Google Drive，正常登录并允许即可。

1-image-20230222145720360

运行完成点击 Public URL 进入 Stable Diffusion WebUI 界面。账号为 wubei，密码为上面自己配置的。

1-image-20230222150541478

然后就可以尽情的享用了。

输入 prompt，即可生成对应的图像，比如输入 “ an astronaut in the water ”。

1-image-20230222151132661

当然，你可以输入更多的 prompt 信息，来生成更加具体准确的图像。

(((masterpiece))),((best quality)), flat chest,((loli)),((one girl)),very long light white hair, beautiful detailed red eyes,aqua eyes,white robe, cat ears,(flower hairpin),sunlight, light smile,blue necklace,see-through,

杰作，最佳品质，贫乳，萝莉，1个女孩，很长的头发，淡白色头发，红色眼睛，浅绿色眼睛，白色长裙，猫耳，发夹，阳光下，淡淡的微笑，蓝色项链，透明

1-image-20230222154010936

Mac多个Git账户共存

Tue, 14 Feb 2023 00:00:00 GMT

清除配置

查看 Git 本地配置

Terminal window

git config --list

清除用户名和邮箱

Terminal window

git config --global --unset user.name
git config --global --unset user.email

生成 ssh-key

使用 ssh-keygen 命令生成 ssh-key，并手动指定 id

Terminal window

ssh-keygen -t rsa -f ~/.ssh/id_rsa_xx1@gmail.com -C "xx1@gmail.com"

生成成功会输出以下内容

Terminal window

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/james/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/james/.ssh/id_rsa.
Your public key has been saved in /Users/james/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:rwtxjGTJPoV9Mg8lFSf8D4X6jFexWVXKOMRaVyo+RO8 xx1@gmail.com
The key's randomart image is:
+---[RSA 3072]----+
|        .o=o+. .*|
|     . + o.=+++o.|
|      * * .==o== |
|     + + *ooo++  |
|      = S .+o+E  |
|       + .. +..  |
|      .   ..     |
|       . .       |
|        o.       |
+----[SHA256]-----+

然后继续生成你的其他 Git 账号对应的 ssh-key

Terminal window

ssh-keygen -t rsa -f ~/.ssh/id_rsa_xx2@gmail.com -C "xx2@gmail.com"

信任 ssh-key

使用 ssh-add 命令将生成的 ssh-key 添加到 ssh-agent 信任列表

Terminal window

ssh-add ~/.ssh/id_rsa_xx1@gmail.com
ssh-add ~/.ssh/id_rsa_xx2@gmail.com

如果遇到 Could not open a connection to your authentication agent. ，输入

Terminal window

ssh-agent bash

然后重复执行 ssh-add 即可解决

配置公钥

复制对应公钥，配置到对应 Git 网站中（GitHub / GitLab）

Terminal window

pbcopy < ~/.ssh/id_rsa_xx1@gmail.com.pub
pbcopy < ~/.ssh/id_rsa_xx2@gmail.com.pub

这步具体的操作如果有不清楚的可以参考 Adding a new SSH key to your GitHub account

配置 config

进入 ssh 目录

Terminal window

open ~/.ssh/

按照以下规则编辑 config 文件，没有则创建

键	值	说明
Host	主机	自己起
Hostname	主机名	Git 公有地址，比如 gitub.com / gittee.com
IdentityFile	身份文件	rsa 文件路径
User	用户	自己起，一般邮箱就好

编辑完 config 内容如下

Terminal window

Host github1.com
Hostname github.com
IdentityFile ~/.ssh/id_rsa_xx1@gmail.com
User xx1@gmail.com

Host github2.com
Hostname github.com
IdentityFile ~/.ssh/id_rsa_xx2@gmail.com
User xx2@gmail.com

测试链接

测试 Git 账号是否连接成功，git@ 之后是 config 文件中配置的 Host

Terminal window

ssh -T git@github1.com
ssh -T git@github2.com

连接成功会有以下输出

Terminal window

Hi xxx! You've successfully authenticated, but GitHub does not provide shell access.

《置身事内》读书笔记

Mon, 02 Jan 2023 00:00:00 GMT

微观

在我国，政府不但影响“蛋糕”的分配，也参与“蛋糕”的生产，所以我们不可能脱离政府谈经济。

地方政府的权利与事务

要理解政府治理和运作的模式，必须首先了解权力和资源在政府体系中的分布规则。这一分布取决于两个重要体制特点：一是央地关系，二是条块分割。央地关系是指整体上中央与地方之间权力要平衡；条块分割是指地方部门要同时接受上级垂直部门和横向地方政府的领导，受到双重制约。

基于这两个特点，地方政府的权力划分可以从三个视角考察：从外部性的视角，若政府提供的公共服务只影响本地，就可以由本地全权处理，若存在外部性，则需要上级协调；从信息的视角，有信息优势的一方实际权威也会更大，因此上级往往也会花费大量的精力获取下级的信息；从激励相容的视角，与本地发展目标无关或相反的事项更倾向于垂直领导，与本地发展目标相符或本地能受益的事项则倾向于交给本地政府处理。

根据这些事权划分原则，地方政府在招商引资、发展经济的过程中享有非常广泛的权力，因此可以深度参与资源的生产与分配过程。

财务与政府行为

要发展经济，地方政府除了有事权还不够，更重要的是财权。1985-1993年，推行财政包干，导致中央财政收入占比逐年下降，于是1994年进行分税制改革，增加了中央的收入，却大大降低了地方的财政资源。

分税制并没有改变地方政府以经济建设为中心的任务，却减少了其手头可支配的财政来源，地方不得不另谋出路，寻找资金来源，于是轰轰烈烈的土地财政就此登场。土地财政简单来讲就是指地方政府依靠出让土地使用权的收入来维持地方财政支出。

1998年，发生了两件改变房地产市场的大事：第一，单位停止福利分房，老百姓从此需要自己买房子了，房地产时代自此拉开大幕；第二，修订后的《中华人民共和国土地管理法》开始实施，简言之就是地方政府拥有卖地的决定权，而卖地的收入也归地方所有。地方政府就可以限制商住用地供给，从不断攀升的地价中赚取土地垄断收益。

一些地区政府实行土地财政。一方面补贴工业用地，招商引资，一方面限制商住用地，房价带动地价。但对于无法依靠土地财政的地区，则出现了财政困难，地区间不平等，需要依靠中央转移支付，并继续进行财政改革。如农村税费改革，乡财县管、省直管县等等。

政府投融资与债务

土地真正的力量还不在土地财政，而在以土地为抵押而撬动的银行信贷和其他各路资金，土地财政一旦嫁接了资本市场，加上了杠杆，就成了土地金融，能像滚雪球般越滚越大，推动经济飞速扩张。

政府成立地方政府融资平台，即“城投公司”，以未来的土地收益为抵押撬动大量银行贷款，就可以进行投资以推动城市化和工业化。政府投资主要分两个方向，一是投资基础建设，二是投资工业。投资基础建设就是城投公司开发后再交给政府招商引资，或企业从开发到引资全负责，政府付费使用，这就是“政府与社会资本合作”模式（PPP）。

但是地方政府通过土地金融推动经济发展的模式仍然存在一些问题。从微观层面，土地金融会增加地方政府债务风险。地方政府债务除了账面的显性负债，更多的是融资平台公司的“隐性负债”。经济向好时可以以土地增值收益作为还款来源，一旦经济遇冷，低价下跌，就可能出现严重的债务问题。

目前改革的主要措施有用政府公债置换城投公司债务，将城投公司转型为普通国企，避免资金继续流入，约束官员的投资冲动。但是从根本上说，现行体制下，地方官员和普通政府工作人员都拥有非常强的激励去发展经济，这一方面导致投资过度，一方面出现了“官商勾结共同发财式”的系统性腐败。因此深层次的改革应当简政放权，从生产投资型政府向服务型政府转变。

工业化中的政府角色

我国的经济改革脱胎于计划经济，政府手中掌握大量对产业发展至关重要的资源，如土地、银行、大学和科研机构等，所以必然会以各种方式深度参与工业化进程。

上面描述的政府投资的第二个方向就是投资工业，由政府对特定企业进行支持和补贴。此外，政府还会设置产业引导基金，成立投资公司或交给市场化的基金管理人运作，作为“母基金”投资其他基金，再通过后者投资未上市公司的股权，从而将更多社会资本引导至战略新兴产业。

书中以京东方、光伏发展为例讲解了具体的地方政府投资工业的过程，在此不做赘述。

宏观

上面描述了土地金融模式微观层面上的影响，下面描述宏观影响。

城市化与不平衡

第一，城市化过程中“重土地、轻人”，从而推高房价，增加居民债务负担，加剧收入差距和贫富差距。

房价升高在中长期看来是因为大城市的建设用地指标被严格管理，跟不上人口流入的速度，导致住房供不应求。房价越高，居民债务负担就越重。

收入差距则是由于城市相关公共服务供给不足，劳动力无法自由流动，低技能人员难以在城市立足。在经济快速增长的过程中，低收入群体对于贫富差距的敏感度没有那么高，但一旦经济放缓，社会对不平等的容忍度将会降低。

因此改革办法是将重心从土地转移到人，既要让建设用地指标流转起来，打破城市政府对城市住宅用地的垄断，又要改革户籍制度，增加低收入群体的流动性和选择权。

债务与风险

第二，招商引资过程中“重规模，重扩张”，加重企业债务负担，以及经济整体的债务和金融风险。

债务的成因在于金融危机后我国金融管制的放松，银行更愿意把钱借出去。

从债务人企业的角度，主要是地方政府融资平台企业、国有企业、房地产企业债务负担较重。它们为了还贷抛售资产，会造成资产价格下跌，而资产价格下跌又会使银行坏账上升，不愿意继续贷款，使企业资金链断裂，从而带来经济衰退。

从债权人银行的角度，一是规模大，杠杆率高；二是银行负债与资产期限的不匹配会带来流动性风险；三是银行信贷大多以房地产或土地为抵押，因此经济衰退时，银行反而不愿放贷，加速经济下行；四是银行风险会传导至其他金融部门，形成系统风险。银行为了逃避监管设立影子银行，资本在金融机构流转，一旦泡沫破裂，将影响整个金融行业。

要解决债务问题，可以分为两个部分，一是偿还已有债务，二是遏制新增债务。

偿还债务要么变卖资产，要么压缩支出，要么增发货币。后者有三种方法：直接增发、量化宽松、债务货币化。

要遏制新增债务，除了严控房价上涨、限制土地金融等金融改革，关键是要找到债务增长的根源。企业为什么总是向银行贷款？根据“谁做投资决策，谁承担投资风险”的原则，我国的投资主要有政府和国企主导，因此风险也是由政府及其控制的金融机构，即银行承担。因为银行的风险归根结底是政府的风险。因此限制债务增长的根本措施是资本市场改革，将权力下放给市场，拓宽直接融资渠道，让企业通过股权、债券筹资。

国内国际失衡

第三，发展战略“重投资、重生产、轻消费”，导致经济结构不平衡。

对于内部，结构失衡最突出的特征是消费不足，这一方面是因为计划生育、民生支出不足、房价上涨等因素造成的储蓄偏高，一方面也是因为居民收入份额较低。

在经济发展初期，大量投入资本可以有效实现工业化，推动经济增长，但当经济发展到一定阶段，这种发展模式会造成产能过剩、债务风险（投资流入房地产，推高房价）、贫富差距过大、外部失衡（出口常年大于进口）等一系列问题。

但是，中美之间的贸易冲突，并非因为中国的出口对美国就业的冲击，而是制造业崛起对美国技术的冲击，再加上美国政治保守主义的兴起。这势必要求我国构建以国内大循环为主体的双循环模式，壮大国内市场，实现“市场—研发—迭代—更大市场”的良性循环。

这一转型的关键在于提高居民收入与消费。这应当从三个方面入手，一是继续推进城市化，让服务业进一步发展；二是加大民生支出，降低生产性支出；三是发展直接融资渠道，扩宽居民财产性收入。

政府与经济发展

政府过去发展经济的核心在于引入竞争机制，由中央协调，地方政府竞争。竞争的评价标准就是经济建设。

这种“官场+市场”的体制优势在于设计了一晰有效的升迁标准，从而给官员提供了极强的激励发展经济。但也会产生地方保护主义、腐败等问题。正如计划经济时代政府干预的特点延续到市场化改革，这一体制也会留下重视经济、忽视民生的路径依赖。

在市场机制尚不完善的情况下，政府可以作为其补充动员和调配资源，为完善和建设市场经济争取时间。但当市场机制已经相对成熟，政府也要适时改变自己的角色定位，降低政府投资支出，加大民生支出，从生产型政府转向服务型政府。

这一转变也契合发展经济学的一般视角：对于发展中国家，提高生产率的关键在于学习已知的技术和管理模式，当生产率提升到一定水平后，又要由组织学习模式转向探索创新模式。而无论是怎样的发展模式，不同的国家、不同的地区都会根据具体的政治社会现实而有所不同。

《亲密关系》读书笔记

Sun, 16 Oct 2022 00:00:00 GMT

写在前面

记录阅读罗兰·米勒的《亲密关系》过程中的收获。

人际关系是由多种影响因素构成的，其范围从当前文化的流行时尚到人类种族的基本属性，非常广泛。在这些一般的影响因素之外，还有很多个体独有的影响因素如人格和经验，它们有些是习得的，有些是遗传的。最终，两个来自同一星球，但在很多方面存在一定程度差异的人，开始了他们的互动。互动的结果或许令人沮丧，或许令人满意。

亲密关系

人际关系种类多样，规格不齐，我们上有父母，还可能下有子女，我们还有朋友和爱人，《亲密关系》书中重点关注的是后两种伙伴关系，而且限制于成人之间。

亲密关系的定义

亲密关系是一个复杂的概念，包含各种成分，很难去下定义，好在研究者和普通人都认为亲密关系和泛泛之交之间存在六个方面的程度差异。

了解：广泛而私密的了解
关心：相互的关心
相互依赖性：彼此需要和影响对方的程度时频繁、强烈、多样且持久的
相互一致性：自我接纳他人的程度是否高度重合
信任：相信对方会善待和尊重自己
忠诚：希望关系能地老天长，并不惜时间、人力和物力的消耗

归属需要

为什么人们需要亲密关系呢？

亲密关系对于人类的重要性主要体现在归属需要上，归属需要是人类长期演化的产物，逐渐成为所有人类共同的自然倾向，让我们觉得与和自己有关联的人的正常社会交往是必不可少的，是对持续关爱和包容的一种需要。

文化的影响

文化标准是人们建立人际关系的基石，它影响着人们对人际关系的期望，限定了正常的人际关系模式。

就拿最近普遍流行的同居现象来说，现在许多高中生认为情侣未婚同居是个“好主意”，因为他们能据此考察彼此是否真正能“和睦相处”（Bachman etal.，2001）。这种态度使未婚同居看上去很有道理，好像是个不错的选择。

然而，如果人们并没有切实的结婚计划，未婚同居并不能确保随后的婚姻幸福美满；相反，同居增加了夫妻离婚的危险。如上图的研究结果所示，随着时间的推移，同居情侣结婚的可能性逐渐降低，但分手的可能性却不下降。

总的说来，草率同居原本用来测试伴侣能否和睦共处，却好像会损害人们对婚姻的积极态度和维持婚姻的决心，这种态度和决心是幸福婚姻的支柱（Rhoades et al.，2009）。

个人经历的影响

依恋类型不受基因影响，是在与生俱来的个体特征和养育水平的影响下塑造的。

安全型：对亲密关系和相互依赖安心、乐观、好交际
痴迷型：对有损坏亲密关系的任何威胁都不安和警惕、嫉妒、贪婪
恐惧型：自立、漠视亲密关系、冷淡、独立
疏离型：害怕被遗弃、不信任他人、猜忌多疑、害羞

我们幼时对人际交往价值和他人是否可信的观念，起源于我们与照料者的交往，由于运气的好坏，我们就此走向了信任或恐惧的亲密关系之路。这段历程永远不会停止，同行者随后给予的阻碍或帮助会改变我们亲密关系的方向和进程。视乎人际交往经验的不同，我们习得的依恋类型既可随时间发生变化，也可永久保持稳定。

个体差异的影响

性别差异

两性群体差异确实存在，但远低于同性不同个体间的差异程度。

两性性别内的行为和观点差异通常远大于两性之间的平均差异。男性较女性更能接受随意、短暂的性关系（Peterson & Hyde，2010），这未必表示所有男性都喜欢随意的性关系。

有些男人喜欢与陌生人发生性行为，但也有些男人根本不喜欢这样做，这两组男性在性生活上的相似程度远不如男性和女性的平均水平。换句话说，尽管在性放任上存在两性差异，一位非常性放任的男人与女性性放任的平均水平的差别，远低于他与另一位性保守的男人在性放任上的差别。

书中一则描述刻板化印象的笑话很有趣。

怎样吸引女人：

夸赞她，依偎她，亲吻她，爱抚她，热爱她，安慰她，保护她，拥抱她，不惜千金买笑，奉出美酒佳肴，烦心的时候听她唠叨，微恙的时候悉心照料，永远和她待在一起，永远支持她的意见，为她走遍天涯海角。

怎样吸引男人：

脱光衣服，带上啤酒。

实际上，两性对亲密关系的期望差异很小，他们根本不是“相反的”两类人（Hyde，2007）。如果认为男女两性差异很大，当面临冲突时（这无法避免）不太可能去努力修复自己与异性的亲密关系。认为异性是来自另一世界的外星人不仅是错误的，更是有害的，它阻碍了对伴侣观点的理解，妨碍了双方协作解决问题。

性认同差异

性认同差异指的是由文化和教育引起的两性在社会性和心理上的差异，或者叫社会性别（Wood & Eagly，2009）。

性认同最好的例子是性别角色（gender roles），即社会文化所期待的男女两性应有的“正常”行为模式，下面是常见的性别角色分类，社会期望和鼓励男人具有工具性，女人具有表达性。

工具性：自信、独立、有抱负、领导力、果敢，约占 25%
表达性：热情、温柔、有同情心、亲切、敏感，约占 25%
跨类型：约占 35%
未分化：约占 15%

人格

大五人格特质可以很好地区分人们在诸多方面（如行为、思维和情感等）的差异（McCrae & Costa，2010）。

开放性：富有想象力、不墨守成规、艺术气质，相对应的是拘泥、僵化和教条。
外倾性：开朗、合群、热情、喜欢社交，相对应的是谨慎、内敛及害羞。
尽责性：勤劳、可依赖、有序，相对应的是不可靠、粗心大意。
宜人性：同情心、合作性、对人信任，相对应的是易怒、暴躁和充满敌意。
神经质：善变、容易担忧、焦虑和愤怒的程度。

重要性从低到高排列的，大五特质中最重要的是那个有消极作用的特质：神经质（Malouff et al.，2010）。神经质的人容易发怒和焦虑，这些不良倾向往往会引起人际摩擦、悲观情绪和争执（Suls & Martin，2005）。

自尊

自尊就是人际交往中的自我评价，可以看作一种 “ 社会关系测量仪 ”，如果他人积极地对待我们并看重与我们的关系，自尊水平就高；如果我们不能吸引别人的关注，自尊水平就低。

我们人类是高度社会化的动物，如果他人不喜欢我们，我们要喜欢自己非常困难（的确，这样做很不现实）。大多数情况下，如果不能从他人那里获得足够的接纳和欣赏，长期处在低自尊的人就会形成负面的自我评价。

值得一提的是自尊在亲密关系中的影响：低自尊的人有时低估伴侣对他们的爱，以致损害亲密关系（Murray et al.，2001）。

我们都需要在与他人的联系和自我保护间保持平衡，但低自尊的人总把他们脆弱的自尊心置于亲密关系之上。低自尊者的自我怀疑和敏感脆弱使他们从无数的琐事中制造出堆积如山的问题。他们错误地以为爱情之路上的磕磕碰碰是伴侣拒绝承诺的不祥之兆。然后，又表现出令人反感、自我打击式的伤害和愤怒，完全隔断了自己渴望的伴侣的安慰。相形之下，高自尊者对同样的小磕绊完全不以为意，信心十足地期待伴侣对自己的接纳和正面评价。

人类本性的影响

数千年来人类生存所面临的环境压力遗留下了精神和情感的痕迹。某些遗留下的情感和行为反应源自我们的远祖，在现代已经没有必要了，但前人生存的这些遗迹不可磨灭地刻入了我们的性格，使得每个人都表现出一定的倾向性。

演化心理学的三个假设：

性选择使人类成为今天这样的物种。
两性之所以存在差异，只是因为某种程度上他们在过去面临着不同的繁殖困境（养育投入）。
文化影响决定了演化形成的行为模式是否具有适应性，并且文化的变化比演化快得多（父系不确定）。

人际互动的影响

人际关系常常大于它各部分相加的总和，这便是人际关系的最后一个构成要素 “ 互动 ” 的影响。

比如拿伴侣关系中的信任程度来说，信任是双向的过程，同时收到你和伴侣双方性情的影响，来源于你每天和伴侣不断付出以及不断接受的动态过程，换而言之，信任是流动的过程而非静止不变的事物，它在你所有的人际关系中时起时落。

人际关系的消极面

我们不得不承认人际关系也有一些潜在的代价，有时我们和他人打交道也会带来不幸和痛苦。

当人们与他人接近时，可能害怕自己最在乎的秘密被人揭露或利用。他们还可能担忧伴随相互依赖而来的自主性和自我控制的丧失（Baxter，2004）。他们或许还担心会被自己所依赖的人抛弃。他们认识到人际关系可能存在欺骗，人们有时还会混淆了性和爱（Firestone & Catlett，1999）。实际上，大多数人（56%）在过去的5年中人际关系都曾陷入困境（Levitt et al.，1996）。

那么为什么还要冒这种风险呢？书中的回答很是浪漫。

因为我们人类是社会化的动物，我们需要彼此。没有与他人的亲密联系，我们就会枯萎和死亡。

Ring_layout：Flutter 环形布局实现

Sun, 24 Apr 2022 00:00:00 GMT

环形布局的定义

如果存在一个圆 A 和若干个圆 a，圆 a 皆于圆 A 相交，圆 a 的圆心皆位于圆 A 上，且圆 a 间的圆心距相等。

即环形布局应当满足以下两个属性：

子 widget的中点到容器圆心的距离保持一致。
相邻子 widget 中点的间距保持一致。

根据以上性质我们可以根据数学公式计算出 圆 a 相对于圆 A 的位置 ，这是实现环形布局的关键信息。

在上面的定义中并未提及圆 a 的半径关系，实际上圆 a 的半径是可以不一致的，把圆 a 看作子元素的外切圆，在复杂的生产环境中子元素的外切圆半径往往是不一致的，所以我们还需要确定 圆 a 的最大半径 。

计算子元素的位置

数学推导

要确定圆 a 相对于圆 A 的位置，首先要计算 圆心 a 相对于圆心 A 的偏移量。

设圆心 A 坐标为 (x0,y0)(x_0, y_0)(x0,y0) 、半径为 rrr、圆心 a 坐标为 (x1,y1)(x_1, y_1)(x1,y1) ，圆心 A 和圆心 a 的连线和坐标系横轴的夹角角度为 θ\thetaθ 。

圆心 a 坐标 (x1,y1)(x_1, y_1)(x1,y1) 为圆心 A 坐标 (x0,y0)(x_0, y_0)(x0,y0) 加上相对坐标系轴上的偏移量。

x1=x0+r×cos(θ)x_1 = x_0 + r \times cos(\theta)x1=x0+r×cos(θ) y1=y0+r×sin(θ)y_1 = y_0 + r \times sin(\theta)y1=y0+r×sin(θ)

代码实现

/// 计算圆心a相对于圆心A的偏移量
///
/// @param centerPoint 圆心A的坐标
/// @param radius 圆A的半径
/// @param count 圆a的数量
/// @param which 圆a的序号
/// @param initAngle 起始位置
/// @param direction 排列方向
Offset _getChildCenterOffset({
  Offset circleCenter,
  double radius,
  int count,
  int which,
  double firstAngle,
  int direction,
}) {
  // 扇形弧度
  double radian = _radian(360 / count);
  // 处理起始位置偏移和排列方向
  double radianOffset = _radian(firstAngle * direction);
  double x = circleCenter.dx + radius * cos(radian * which + radianOffset);
  double y = circleCenter.dy + radius * sin(radian * which + radianOffset);
  return Offset(x, y);
}

计算子元素的半径

数学推导

为了满足子元素环形排列的需要，最大子元素的外切圆上限需为 90∘90^\circ90∘ 扇形的内切圆，如下图所示。

设扇形半径为 RRR、扇形圆心角为 α\alphaα、扇形内切圆半径为 rrr。

最大子元素半径推导过程如下。

sin(α2)=rR−rsin(\frac{\alpha}{2}) = \frac{r}{R - r}sin(2α)=R−rr r=(R−r)×sin(α2)r = (R - r) \times sin(\frac{\alpha}{2})r=(R−r)×sin(2α) r=R×sin(α2)−r×sin(α2)r = R \times sin(\frac{\alpha}{2}) - r \times sin(\frac{\alpha}{2})r=R×sin(2α)−r×sin(2α) r+r×sin(α2)=R×sin(α2)r + r \times sin(\frac{\alpha}{2}) = R \times sin(\frac{\alpha}{2})r+r×sin(2α)=R×sin(2α) r=R×sin(α2)1+sin(α2)r = \frac{R \times sin(\frac{\alpha}{2})}{1 + sin(\frac{\alpha}{2})}r=1+sin(2α)R×sin(2α)

代码实现

/// 计算圆a的半径
///
/// @param radius 圆A的半径
/// @param angle 扇形的角度
double _getChildRadius(double radius, double angle) {
  // 扇形角度大于180度，只可以放置一个。
  if (angle > 180) {
    return radius;
  }

  /// 扇形最大内切圆公式，见公式推导。
  return radius * sin(_radian(angle / 2)) / (1 + sin(_radian(angle / 2)));
}

/// 计算弧度
///
/// @param angle 角度
double _radian(double angle) {
  return pi / 180 * angle;
}

实现

我们选择使用 CustomMultiChildLayout 实现环形布局的功能，看下官网的定义。

“ CustomMultiChildLayout is appropriate when there are complex relationships between the size and positioning of multiple widgets. ”

所以用 CustomMultiChildLayout 实现再合适不过，效果如下。

完整代码已上传至 pub.dev，这里仅截取 RingLayout 的部分代码。

ring_layout： https://pub.dev/packages/ring_layout

class RingLayout extends StatelessWidget {
  final List<Widget> children;
  final double initAngle;
  final bool reverse;
  final double radiusRatio;

  const RingLayout({
    Key? key,
    required this.children,
    this.reverse = false,
    this.radiusRatio = 1.0,
    this.initAngle = 0,
  })  : assert(0.0 <= radiusRatio && radiusRatio <= 1.0),
        assert(0 <= initAngle && initAngle <= 360),
        super(key: key);

  @override
  Widget build(BuildContext context) {
    return CustomMultiChildLayout(
      delegate: _RingDelegate(
          count: children.length,
          initAngle: initAngle,
          reverse: reverse,
          radiusRatio: radiusRatio),
      children: [
        for (int i = 0; i < children.length; i++)
          LayoutId(id: i, child: children[i])
      ],
    );
  }
}

《自私的基因》读书笔记

Thu, 24 Mar 2022 00:00:00 GMT

初开始听说《自私的基因》这本书，是在 21 年末的时候，那时候刚从小米离职，与新公司约定的入职时间稍晚了些，计划的是来一场说走就走的离职旅行、散散心，可事与愿违，年底疫情的爆发打乱了所有安排。

画地为牢的居家隔离生活总是漫长的，每天都要看几集《圆桌派》消磨时光，其中印象最深刻的是第五季的第十一期，这期的嘉宾是华大基因的 CEO 尹烨，一个理科生、三个文科生围绕 “ 基因 ” 展开了热火朝天的讨论，从 “ 体外胚胎技术 ” 到 “ 人体细胞更新 ”，从 “ 忒修斯之船 ” 到 “ 道金斯的自私的基因 ”，每个话题都充斥着思维碰撞的火花，节目的最后尹烨便推荐了这本书 -《自私的基因》。

断断续续几个月读完全书后，受益良多，所以在此简单记录下书中作者的主要观点和自己的一些思考。

“ 纵观历史，人类对自己的认识总是不断矮化的。 ”

从最初哥白尼提出 “ 日心说 ”，地球是宇宙中心的观念在人们心中崩塌，到达尔文提出 “ 进化论 ”，人们意识到自己是由猴子演变而来的，人类和猴子的差距并不大，再然后弗洛伊德提出 “ 性学三论 ” ，表示人类并没有所谓的自控能力，我们的行为只是受到了原始 “ 力比多 ” 的驱使，最后道金斯在《自私的基因》一书中更进一步，指出人类不过是基因的容器，不过是基因复制自己传宗接代的工具而已。

道金斯认为是基因在操纵人，或者说是基因在推动人类复制和传播自身，就像人在开车时，汽车是没有方向感的，是人在操控汽车，是人在选择方向，人类驾驶汽车是为了满足自身高速移动的需求，对于汽车而已，本身是盲目，是无意义的。同样，人类个体的生存也是盲目的、无意义的，不过是体内基因复制和传播自己的工具，存在的意义不过是为了满足基因复制更快、传播更远、更加长寿三个目的而已。

“ 明显的利他行为实际上是伪装起来的自私行为。 ”

动物养育自己的后代，站在生物个体的角度，这会是一种利他行为，但道金斯认为，这种行为是建立在基因可以通过养育后代这种利他行为来达成复制和传播自身的目的的前提下的。所有站在生物个体角度看起来属于利他行为的情况，都是基因自私的产物。

对基因来说唯一有意义的事情就是不断的复制自己、传播自己，以便在生物进化这场 “ 战争 ” 中获得更多的优势，获得更多活下来的可能性。

在书中看到这些，或多或少会有些失望，对人类失望、对自己失望，人类的诞生是偶然的，也是荒谬的，生命的意义可以说是微不足道的。人类世界里那些崇高而辉煌的舍生取义、视死如归，在基因的客观世界里是多么的不合情理。

但正如道金斯在书中写到，人们不能对事实视而不见，也不能因为事实而自暴自弃，书中的观点和结论，都只是对动物生物性的观察，是科学事实的陈述，并不代表道金斯本人的道德观。

相反，他认为如果我们想要建立一个人与人之间慷慨大度、无私奉献的社会，那我们就不能指望我们的生物学本性，我们必须设法通过教育，把慷慨大度和利他主义灌输到人们的头脑中去，因为我们生来就是自私的。

“ 我们具备足够的力量去抗拒我们那些与生俱来的自私基因。我们也可以抗拒那些灌输到我们脑子里的自私觅母。我们甚至可以讨论如何审慎地培植纯粹的、无私的利他主义，这种利他主义在自然界里是没有立足之地的，在世界整个历史上也是前所未有的。我们是作为基因机器而被建造的，是作为觅母机器而被培养的，但我们具备足够的力量去反对我们的缔造者。在这个世界上，只有我们，我们人类，能够反抗自私的复制基因的暴政。 ”

就像尹烨在节目结尾说道：“ 如果人类是一组代码，那我相信人类的代码中有爱 ”。

你我，共勉。

Hugo中支持LaTeX的数学表达式

Sat, 18 Dec 2021 00:00:00 GMT

Hugo 默认是不支持显示 LaTeX 风格的数学表达式的，Markdown 中的数学表达式语法在 Hugo 中默认并不会被识别。

在 Hugo 中引入 MathJax 即可解决该问题，MathJax 是一个适用于所有浏览器的 JavaScript 数学显示引擎。

引入方法很简单，在文章的模版的 HTML 的中添加以下内容即可。

<script type="text/javascript"
        async
        src="https://cdn.bootcss.com/mathjax/2.7.3/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
MathJax.Hub.Config({
  tex2jax: {
    inlineMath: [['$','$'], ['\\(','\\)']],
    displayMath: [['$$','$$'], ['\[\[','\]\]']],
    processEscapes: true,
    processEnvironments: true,
    skipTags: ['script', 'noscript', 'style', 'textarea', 'pre'],
    TeX: { equationNumbers: { autoNumber: "AMS" },
         extensions: ["AMSmath.js", "AMSsymbols.js"] }
  }
});

MathJax.Hub.Queue(function() {
    // Fix <code> tags after MathJax finishes running. This is a
    // hack to overcome a shortcoming of Markdown. Discussion at
    // https://github.com/mojombo/jekyll/issues/199
    var all = MathJax.Hub.getAllJax(), i;
    for(i = 0; i < all.length; i += 1) {
        all[i].SourceElement().parentNode.className += ' has-jax';
    }
});
</script>

<style>
code.has-jax {
    font: inherit;
    font-size: 100%;
    background: inherit;
    border: inherit;
    color: #515151;
}
</style>

要注意的是需要确保该 HTML 必定被 Hugo 框架加载，我这里是添加到了 layouts/partials/ 目录下的 footer.html文件中，因为我确定该文件必定包含在网站的每个页面中。

实际上单纯引入 MathJax 并不需要如此多行代码，多余的部分是为了解决 Markdown 和 LaTeX 中对于划线 _ 的不同定义带来的问题，详情可以参考这篇文章。

D(x)={lim⁡x→0axb+c,x<3π,x=3∫a3bxij+e2dx,x>3D(x) = \begin{cases} \lim\limits_{x \to 0} \frac{a^x}{b+c}, & x<3 \\ \pi, & x=3 \\ \int_a^{3b}x_{ij}+e^2 \mathrm{d}x,& x>3 \\ \end{cases}D(x)=⎩⎨⎧x→0limb+cax,π,∫a3bxij+e2dx,x<3x=3x>3 lim⁡x→∞x222−∫15xdx+∑n=120n2=∏j=13yj+lim⁡x→−2x−2x\lim_{x \to \infty} x^2_{22} - \int_{1}^{5}x\mathrm{d}x + \sum_{n=1}^{20} n^{2} = \prod_{j=1}^{3} y_{j} + \lim_{x \to -2} \frac{x-2}{x}x→∞limx222−∫15xdx+n=1∑20n2=j=1∏3yj+x→−2limxx−2

好了，开心的在 Hugo 中使用 LaTeX 吧。

HLS直播协议m3u8

Sat, 25 Sep 2021 00:00:00 GMT

为了方便理解，会按照“流媒体传输协议”、“HLS”、“M3U8”的顺序来介绍。

三者关系：

HLS是一种流媒体传输协议
M3U8是HLS传输内容中的一部分

流媒体传输协议

常见的流媒体传输协议

流媒体就是以数据流的方式，实时发布音频、视频多媒体内容的媒体形式，关键技术在于流式传输。

流媒体传输协议就是用来定义如何流式传输的，设计、制定了流媒体服务器和客户端通讯的方式。

主流的流媒体传输协议：

RTMP（Real Time Protocol）：基于 TCP 的 FLV 分块 message 传输协议，用于 Flash 客户端。
HTTP-FLV：基于 HTTP 长连接的 FLV 分块 tag 传输协议，可用于点播和直播场景。
HLS（HTTP Live Streaming）：基于 HTTP，由 Apple 推出的 MP4 分片传输协议，可以用于点播、直播，每次下载一次分片都需要发生一次 HTTP 请求。

本文只详细介绍 HLS，不涉及 RTMP 与 RTSP

流媒体加密原理

大多数流媒体传输协议都可以分为拆分、加密两部分。

拆分是将完整的视频流拆分为连续的视频片段，不同的传输协议的区别在于拆分片段的大小、视频容器的格式不同。

加密是对每段视频片段进行加密，使用对称加密算法，在服务端加密，在客户端解密，且通过一定手段限制解密密钥的获取。

一般使用 AES 加密算法

为什么是对称加密？

对称加密效率相对较高，非对称加密效率相对较低，但是更安全。流媒体场景对实时性的要求很高，而且数据量也很大，所以选用效率相对较高的对称加密算法。

类似的场景还有很多，比如 HTTPS 的请求过程，内容传输为了效率选用对称加密（TLS），证书校验为了安全选用非对称加密（SSL）。

HLS

HLS 全称 HTTP Live Streaming，是由 Apple 提出的基于 HTTP 的流媒体传输协议，用于实时音视频流的传输，目前已被广泛应用与视频点播、直播场景。

参考资料：HTTP Live Streaming Document

工作原理

完整的 HLS 架构可以划分为 3 个部分：

服务器 Server：负责视频流的编码、切割为连续的 MPEG-TS 格式的视频片段，并提供配套的 M3U8 类型的媒体列表文件和索引文件。
分发组件 CDN：由标准的网络服务器组成，负责接收客户端的请求并分发资源。
客户端 Client：先下载 m3u8 索引文件，根据带宽等字段选择合适的 m3u8 媒体播放列表文件下载，按顺序下载列表中的所有 ts 视频片段文件。

完整的 HLS 的过程可以参考下图：

大体可以划分为 6 个阶段：

采集媒体源
媒体编码器（Media encoder）对媒体源进行编码
编码后以MPEG-2的传输串形式传递给切片器
切片器（Steam Segmenter）将媒体切割为若干 Media Segment，并创建配套的媒体列表文件 Media Playlist 以及索引文件 Master Platlist
上传：将资源上传到 HTTP 服务器。
播放：客户端请求播放。

组成结构

经过上面第 4 步骤的加工可以形成完整的结构，由 Master Playlist、Media Playlist、Media Segment 构成，关系结构如图。

完整的 HLS 结构由两部分组成：

m3u8 类型的 Master Playlist 文件：其中会提供若干根据带宽等字段区分的 Media Playlist 的请求链接。
m3u8 类型的 Media Playlist 文件：其中会有视频的基本信息和若干 Media Segment 的请求链接，这些片段就组成了完整的视频。

Media Segment 就是单纯的 ts 格式的视频文件，并无任何描述信息，可以单独使用播放器进行播放。

M3U8 是 Unicode 版本的 M3U，8 代表使用的是 UTF-8 编码，M3U 和 M3U8 都是多媒体列表的文件格式。

M3U8

M3U8 描述文件中由各种描述字段构成，下面解释部分主要字段的含义。

我在网上随便找的一个 m3u8 视频的链接：https://mgtv-com.jjyl12349.com/20210519/fXE0kuJ7/index.m3u8

请求该链接的返回结果为一个 m3u8 文件，也就是 Master Playlist 文件。

Master Playlist

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=150000,RESOLUTION=416x234
/20210519/fXE0kuJ7/150kb/hls/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=150000,RESOLUTION=416x234
/20210519/fXE0kuJ7/150kb/hls/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=1280x720
/20210519/fXE0kuJ7/1000kb/hls/index.m3u8

字节解释：

EXTM3U：表示该文件为m3u8文件，每个M3U文件都是以EXTM3U开头
EXT-X-STREAM-INF：表示一个备份源，并提供备份源的相关信息
- BANDWIDTH：表示每秒传输的比特数，即带宽
- RESOLUTION：表示备份源的最佳像素方案

我们根据 BANDWIDTH、RESOLUTION 等信息选取合适的 Media Playlist 的请求链接，并将链接与视频链接的域名结合，即可得到完整的链接。

比如，BANDWIDTH 为 1000kb、RESOLUTION 为 1280x720 的备用源的请求链接为：https://mgtv-com.jjyl12349.com/20210519/fXE0kuJ7/1000kb/hls/index.m3u8

请求该链接的返回结果也为一个 m3u8 文件，也就是 Media Playlist 文件。

Media Playlist

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="https://mgtv-com.ycshengwang.com/20210519/fXE0kuJ7/1000kb/hls/key.key"
#EXTINF:3,
https://mgtv-com.ycshengwang.com/20210519/fXE0kuJ7/1000kb/hls/mDHy0Stk.ts
#EXTINF:3,
https://mgtv-com.ycshengwang.com/20210519/fXE0kuJ7/1000kb/hls/FWZjOCHy.ts
...
...
...
#EXT-X-ENDLIST

字节解释：

EXT-X-VERSION：表示 HLS 协议版本号
EXT-X-TARGETDURATION：表示 ts 视频片段允许最大的时长
EXT-X-PLAYLIST-TYPE：表示流媒体类型
EXT-X-MEDIA-SEQUENCE：表示播放列表第一个 ts 视频片段文件的序列号
EXT-X-KEY：表示 ts 视频文件的加密信息
- METHOD：加密方法，可选 NONE、AES-128、SAMPLE-AES
- URI：密钥路径
EXTINF：表示下面 url 对应的 ts 视频片段的时长