Yet Another Blog

Hermes Agent 飞书机器人：私聊正常，群聊不响应的真正原因

Tue, 12 May 2026 00:00:00 +0000

最近接入 Hermes Agent 的飞书机器人时，遇到一个非常迷惑的问题：

私聊机器人：正常
群里 @bot hi：完全没反应
Hermes 日志里甚至没有 group message

第一反应通常会怀疑：

飞书权限没开
事件订阅有问题
WebSocket 没连上
机器人没加群
Hermes Feishu adapter 有 bug

结果都不是。

真正的问题只有一行配置：

FEISHU_GROUP_POLICY=open

问题现象

飞书后台权限全部正常：

im.message.receive_v1
获取群组中用户 @ 机器人消息
获取群组中所有消息

私聊能正常触发：

Inbound dm message received

但群里：

@bot hi

完全没任何日志。

这个现象特别容易误导人。

因为看起来像：

飞书根本没把 group event 推送给 Hermes。

实际上并不是。

真正原因

Hermes Feishu gateway 默认配置是：

group_policy=os.getenv(
    "FEISHU_GROUP_POLICY",
    "allowlist"
)

默认值：

FEISHU_GROUP_POLICY=allowlist

也就是说：

Hermes 默认不会自动处理所有群消息。

在 allowlist 模式下：

群不在白名单
用户不在 allowlist
mention gating 不满足

消息会被直接过滤。

于是你看到的现象就是：

私聊正常
群聊完全没反应
日志里甚至没有 raw message

非常像“飞书事件没推过来”。

但其实：

是 Hermes 自己静默 drop 了 group event。

解决方案

在 .env 里增加：

FEISHU_GROUP_POLICY=open
FEISHU_ALLOW_BOTS=all

然后重启：

hermes restart

立刻恢复正常。

群里：

@bot hi

马上能收到回复。

为什么这个问题很坑

因为你会在错误方向排查很久：

飞书开放平台
权限
事件订阅
WebSocket
机器人权限

实际上这些可能全是对的。

真正的问题只是：

FEISHU_GROUP_POLICY

默认值太“保守”。

一个经验

如果你遇到：

飞书私聊正常
群 @bot 完全无响应
Hermes 没 group raw log

先检查：

FEISHU_GROUP_POLICY

别先折腾飞书后台。

Time Window in PostgreSQL

Tue, 05 May 2026 00:00:00 +0000

1. 引子：一个让人后悔的架构决定

几年前，团队为了做一个「近 7 天用户活跃趋势」的看板，搭了这样一套架构：

PostgreSQL/MongoDB/MySQL → Kafka → Flink → ClickHouse → Grafana

运维了三个月。Flink 任务隔三差五挂掉，ClickHouse 版本升级踩了无数坑，告警半夜叫人。最后发现——整个看板的核心逻辑，其实是这一条 SQL：

SELECT
    date_trunc('day', created_at) AS day,
    COUNT(DISTINCT user_id) AS dau
FROM user_events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY 1
ORDER BY 1;

PostgreSQL 跑它，50ms。

这不是说 Flink 没用。它在真正的流处理场景——毫秒级响应、无界数据流、复杂 CEP——是不可替代的。但很多中小团队的「时序分析需求」，根本到不了那个量级。

2. Flink vs PostgreSQL 窗口映射表

如果你有 Spark 或 Flink 背景，这张映射表会让后续内容一眼看懂——PostgreSQL 的窗口函数几乎是这些框架在单机上的平替。

Flink 概念	PostgreSQL 实现	业务场景	支持情况
Tumbling Window	`date_trunc` / `time_bucket`	每 5 分钟统计订单量	✓ 原生支持
Sliding Window	`RANGE BETWEEN INTERVAL ... PRECEDING`	过去 30 分钟平均 CPU	✓ PG 11+
Session Window	`LAG` + `SUM() OVER` 手动模拟	用户浏览会话识别	✓ 需 3 步实现
State Store	Materialized View	仪表盘预聚合	✓ 定时刷新
Watermark	❌ 不支持	乱序事件处理	✗ 需应用层处理

PostgreSQL 不能替代真正的流处理系统——没有 watermark、没有 exactly-once stream、没有分布式流状态。但对于秒级 dashboard、用户行为分析、监控指标、IoT 数据，它已经足够强。

3. 统一案例背景与数据准备

全文所有 SQL 跑在同一套表上，读者可直接复现。

建表语句：

-- 订单表
CREATE TABLE orders (
    order_id    BIGSERIAL PRIMARY KEY,
    user_id     BIGINT NOT NULL,
    amount      NUMERIC(12, 2) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 用户行为事件表
CREATE TABLE user_events (
    event_id    BIGSERIAL PRIMARY KEY,
    user_id     BIGINT NOT NULL,
    page        TEXT,
    action      TEXT,
    event_time  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 服务器监控指标表（主案例）
CREATE TABLE server_metrics (
    id          BIGSERIAL PRIMARY KEY,
    server_id   TEXT NOT NULL,
    cpu         NUMERIC(5, 2),
    mem         NUMERIC(5, 2),
    ts          TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

模拟数据：

-- 10 万条订单
INSERT INTO orders (user_id, amount, created_at)
SELECT
    (random() * 9999 + 1)::BIGINT,
    (random() * 9900 + 100)::NUMERIC(12,2),
    NOW() - (random() * INTERVAL '90 days')
FROM generate_series(1, 100000);

-- 50 万条用户事件
INSERT INTO user_events (user_id, page, action, event_time)
SELECT
    (random() * 9999 + 1)::BIGINT,
    (ARRAY['/home','/product','/cart','/checkout'])[ceil(random()*4)::INT],
    (ARRAY['click','view','scroll','submit'])[ceil(random()*4)::INT],
    NOW() - (random() * INTERVAL '30 days')
FROM generate_series(1, 500000);

-- 30 天服务器监控数据（每分钟一条，5 台服务器，含随机异常峰值）
INSERT INTO server_metrics (server_id, cpu, mem, ts)
SELECT
    'server-' || (i % 5 + 1)::TEXT,
    (40 + random() * 50 + CASE WHEN random() > 0.95 THEN 30 ELSE 0 END)::NUMERIC(5,2),
    (50 + random() * 40)::NUMERIC(5,2),
    NOW() - (43200 - i) * INTERVAL '1 minute'
FROM generate_series(1, 43200) AS i;

不要用裸 TIMESTAMP。如果服务器在北京、用户在旧金山，某天改了服务器时区，TIMESTAMP 列里的历史数据含义就变了。TIMESTAMPTZ 统一存 UTC，展示时按时区转换，不会有这个问题。跨国系统尤其如此。

4. 时序基础工具箱

date_trunc —— 时序分析的时间转换函数。

将任意精度的时间戳「对齐」到指定粒度。支持： microseconds、 milliseconds、 second、 minute、 hour、 day、 week、 month、 quarter、 year。

SELECT
    date_trunc('hour', created_at) AS hour,
    COUNT(*)                        AS order_count,
    SUM(amount)                     AS gmv
FROM orders
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY 1
ORDER BY 1;

generate_series —— 补零神器（折线图必备）

这是被大多数时序分析中忽略的技巧。如果某个小时没有订单，上面的查询会直接跳过那个时间点——前端渲染折线图就会出现断裂。正确做法：先生成完整时间轴，再 LEFT JOIN 实际数据。

这是一个补全时间点的样例：

WITH time_spine AS (
    SELECT generate_series(
        date_trunc('hour', NOW() - INTERVAL '7 days'),
        date_trunc('hour', NOW()),
        INTERVAL '1 hour'
    ) AS hour
),
hourly_stats AS (
    SELECT
        date_trunc('hour', created_at) AS hour,
        COUNT(*)    AS order_count,
        SUM(amount) AS gmv
    FROM orders
    WHERE created_at >= NOW() - INTERVAL '7 days'
    GROUP BY 1
)
SELECT
    t.hour,
    COALESCE(s.order_count, 0) AS order_count,
    COALESCE(s.gmv, 0)         AS gmv
FROM time_spine t
LEFT JOIN hourly_stats s USING (hour)
ORDER BY t.hour;

这条 SQL 保证每个小时都有一行，没数据的时间点补 0。

5. 三种时间窗口模式

滚动窗口（Tumbling Window）

固定时间桶，互不重叠，实现最简单。场景：大促期间每 15 分钟统计下单量，用于监控大屏。

SELECT
    TO_TIMESTAMP(
        FLOOR(EXTRACT(EPOCH FROM created_at) / 900) * 900
    ) AS window_start,
    COUNT(*)    AS order_count,
    SUM(amount) AS gmv
FROM orders
WHERE created_at >= NOW() - INTERVAL '3 hours'
GROUP BY 1
ORDER BY 1;

如果用了 TimescaleDB，更简洁：

SELECT time_bucket('15 minutes', created_at), COUNT(*), SUM(amount)
FROM orders GROUP BY 1 ORDER BY 1;

所以该用工具用对工具，没必要为了什么架构简洁给自己找罪受。理解和可解读是第一性原理。

滑动窗口（Sliding Window）

窗口随时间滑动，每个时间点都有一个「往前看 N 天 / N 小时」的聚合值。这是量化交易均线、监控移动平均的基础。

在这里必须搞清楚 ROWS vs RANGE 的区别——这是 99% 的教程一笔带过的地方：

ROWS —— 物理行数

ROWS BETWEEN 6 PRECEDING AND CURRENT ROW

往前数 6 行，不管时间间隔多久。数据采集不均匀时会严重失真。

RANGE —— 逻辑时间范围

RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW

过去 7 天内的所有行，PG 11+ 支持 interval。稀疏事件必须用这个。

判断原则：

数据是规则采样（每分钟一条监控）→ 用 ROWS；
数据是稀疏事件（订单、点击）→ 必须用 RANGE。

以一个 7 日 GMV 移动平均为例：

WITH daily_gmv AS (
    SELECT
        date_trunc('day', created_at) AS day,
        SUM(amount) AS gmv
    FROM orders
    WHERE created_at >= NOW() - INTERVAL '60 days'
    GROUP BY 1
)
SELECT
    day,
    gmv,
    AVG(gmv) OVER (
        ORDER BY day
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS gmv_ma7,
    AVG(gmv) OVER (
        ORDER BY day
        ROWS BETWEEN 29 PRECEDING AND CURRENT ROW
    ) AS gmv_ma30
FROM daily_gmv
ORDER BY day;

以一个过去 30 分钟平均 CPU（稀疏采样）为例：

SELECT
    ts,
    server_id,
    cpu,
    AVG(cpu) OVER (
        PARTITION BY server_id
        ORDER BY ts
        RANGE BETWEEN INTERVAL '30 minutes' PRECEDING AND CURRENT ROW
    ) AS cpu_ma_30m
FROM server_metrics
WHERE ts >= NOW() - INTERVAL '3 hours'
ORDER BY server_id, ts;

会话窗口（Session Window）

PostgreSQL 原生不支持 Session Window，但可以用纯 SQL 完整模拟。这是 Flink 里内置的能力，在 PG 里用三步走实现。

场景：识别用户浏览会话——超过 30 分钟没有操作，视为新会话开始。

用 LAG() 计算每个事件与上一事件的时间间隔:

SELECT
    user_id,
    event_time,
    LAG(event_time) OVER (
        PARTITION BY user_id
        ORDER BY event_time
    ) AS prev_event_time,
    event_time - LAG(event_time) OVER (
        PARTITION BY user_id ORDER BY event_time
    ) AS gap
FROM user_events
ORDER BY user_id, event_time;

标记会话边界：间隔 > 30 分钟或首个事件，标记 is_new_session = 1

WITH gaps AS (
    SELECT
        user_id, event_time, page, action,
        CASE
            WHEN event_time - LAG(event_time) OVER (
                PARTITION BY user_id ORDER BY event_time
            ) > INTERVAL '30 minutes'
            OR LAG(event_time) OVER (
                PARTITION BY user_id ORDER BY event_time
            ) IS NULL
            THEN 1 ELSE 0
        END AS is_new_session
    FROM user_events
)

SUM() OVER 累积生成 session_id，再聚合得到每个会话的完整信息

WITH gaps AS (
    SELECT
        user_id, event_time, page, action,
        CASE
            WHEN event_time - LAG(event_time) OVER (
                PARTITION BY user_id ORDER BY event_time
            ) > INTERVAL '30 minutes'
            OR LAG(event_time) OVER (
                PARTITION BY user_id ORDER BY event_time
            ) IS NULL
            THEN 1 ELSE 0
        END AS is_new_session
    FROM user_events
),
sessions AS (
    SELECT
        user_id, event_time, page, action,
        SUM(is_new_session) OVER (
            PARTITION BY user_id
            ORDER BY event_time
            ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        ) AS session_id
    FROM gaps
)
SELECT
    user_id,
    session_id,
    MIN(event_time)                   AS session_start,
    MAX(event_time)                   AS session_end,
    MAX(event_time) - MIN(event_time) AS session_duration,
    COUNT(*)                          AS event_count
FROM sessions
GROUP BY user_id, session_id
ORDER BY user_id, session_id;

这段 SQL 的逻辑链路：

→
原始事件流（按 user_id + event_time 排序）
↓
LAG() 计算每个事件与上一事件的时间差
↓
时间差 > 30min 或首个事件 → is_new_session = 1，否则 = 0
↓
SUM(is_new_session) OVER (...) 累积求和 → 生成递增的 session_id
↓
按 user_id + session_id 聚合 → 每个会话的开始 / 结束 / 时长 / 事件数

Flink 里内置的 Session Window，在 PG 里用约 40 行 SQL 完整模拟，避免了任何循环和存储过程，纯窗口函数向量化实现。

6. 常用时序分析模式

同比和环比

WITH daily AS (
    SELECT
        date_trunc('day', created_at) AS day,
        SUM(amount) AS gmv
    FROM orders
    GROUP BY 1
)
SELECT
    day, gmv,
    LAG(gmv, 1) OVER (ORDER BY day) AS gmv_yesterday,
    LAG(gmv, 7) OVER (ORDER BY day) AS gmv_last_week,
    ROUND(
        (gmv - LAG(gmv, 1) OVER (ORDER BY day))
        / NULLIF(LAG(gmv, 1) OVER (ORDER BY day), 0) * 100, 2
    ) AS mom_pct,   -- 日环比
    ROUND(
        (gmv - LAG(gmv, 7) OVER (ORDER BY day))
        / NULLIF(LAG(gmv, 7) OVER (ORDER BY day), 0) * 100, 2
    ) AS wow_pct    -- 周同比
FROM daily
ORDER BY day;

NULLIF(x, 0) 防止除零错误——生产代码中必须加。

用户留存分析（Day1 / Day7 / Day30）

WITH first_day AS (
    SELECT
        user_id,
        date_trunc('day', MIN(event_time)) AS cohort_day
    FROM user_events
    GROUP BY user_id
),
activity AS (
    SELECT DISTINCT
        user_id,
        date_trunc('day', event_time) AS active_day
    FROM user_events
)
SELECT
    f.cohort_day,
    COUNT(DISTINCT f.user_id) AS cohort_size,
    COUNT(DISTINCT CASE WHEN a.active_day = f.cohort_day + INTERVAL '1 day'  THEN a.user_id END) AS d1,
    COUNT(DISTINCT CASE WHEN a.active_day = f.cohort_day + INTERVAL '7 days' THEN a.user_id END) AS d7,
    COUNT(DISTINCT CASE WHEN a.active_day = f.cohort_day + INTERVAL '30 days' THEN a.user_id END) AS d30,
    ROUND(
        COUNT(DISTINCT CASE WHEN a.active_day = f.cohort_day + INTERVAL '1 day' THEN a.user_id END)
        * 100.0 / NULLIF(COUNT(DISTINCT f.user_id), 0), 1
    ) AS d1_rate
FROM first_day f
LEFT JOIN activity a USING (user_id)
GROUP BY f.cohort_day
ORDER BY f.cohort_day;

7. 异常检测：统计方法替代硬编码阈值

规则阈值（「CPU > 90% 就告警」）的问题是不随数据分布变化。更健壮的方式是用 Z-Score：超过均值 ± 2σ 的点视为异常。

WITH stats AS (
    SELECT
        server_id,
        AVG(cpu)    AS cpu_mean,
        STDDEV(cpu) AS cpu_stddev
    FROM server_metrics
    WHERE ts >= NOW() - INTERVAL '30 days'
    GROUP BY server_id
),
labeled AS (
    SELECT
        m.ts, m.server_id, m.cpu,
        ABS(m.cpu - s.cpu_mean) / NULLIF(s.cpu_stddev, 0) AS z_score
    FROM server_metrics m
    JOIN stats s USING (server_id)
    WHERE m.ts >= NOW() - INTERVAL '24 hours'
)
SELECT
    ts, server_id, cpu,
    ROUND(z_score, 2) AS z_score,
    CASE WHEN z_score > 2 THEN '⚠️ 异常' ELSE '正常' END AS status
FROM labeled
WHERE z_score > 2
ORDER BY z_score DESC;

进阶：连续 N 次异常才告警（减少误报）

WITH anomalies AS (
    SELECT
        ts, server_id, cpu,
        CASE WHEN cpu > 90 THEN 1 ELSE 0 END AS is_anomaly
    FROM server_metrics
    WHERE ts >= NOW() - INTERVAL '24 hours'
),
streaks AS (
    SELECT
        ts, server_id, cpu, is_anomaly,
        SUM(is_anomaly) OVER (
            PARTITION BY server_id
            ORDER BY ts
            ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
        ) AS streak_5
    FROM anomalies
)
SELECT * FROM streaks
WHERE streak_5 = 5   -- 连续 5 次都异常，才是真正需要处理的
ORDER BY server_id, ts;

ROWS BETWEEN 4 PRECEDING AND CURRENT ROW 表示含当前行在内的最近 5 行。5 行异常标记之和等于 5，说明连续 5 次都超阈值——这才是真正的告警信号，而不是单点噪声。

8. 性能调优：工程视角

问题	方案	说明
全表扫描慢	`CREATE INDEX ON orders (created_at DESC)`	时序查询几乎都带时间过滤
索引体积过大	改用 BRIN 索引	写入有序时，体积是 B-Tree 的 ~1%
数据量大	按月 `PARTITION BY RANGE(ts)`	分区裁剪大幅减少扫描量
仪表盘重复计算	物化视图 + 定时刷新	模拟 Continuous Aggregate
索引失效	避免在 WHERE 对 ts 做函数运算	见下方对比

BRIN vs B-Tree 索引

-- B-Tree（默认）：体积大，支持任意顺序查询
CREATE INDEX ON server_metrics (ts);

-- BRIN：体积极小，适合写入有序的时序数据，时序场景首选
CREATE INDEX ON server_metrics USING BRIN (ts);

-- 组合索引：按 server_id 分区查询时更快
CREATE INDEX ON server_metrics (server_id, ts DESC);

BRIN 记录每个数据块的 min/max 值。时序数据按时间顺序写入，天然适合——索引体积可能只有 B-Tree 的 1%，查询扫描量同样大幅减少。

实际检索中，避免索引失效需要写明日期值：

-- ❌ 错误：对索引列做了函数运算，索引失效，全表扫描
WHERE date_trunc('day', created_at) = '2026-01-15'

-- ✅ 正确：范围查询，索引生效
WHERE created_at >= '2026-01-15' AND created_at < '2026-01-16'

还有一种工程上的实践是，按月分区表

CREATE TABLE orders_partitioned (
    order_id   BIGSERIAL,
    user_id    BIGINT NOT NULL,
    amount     NUMERIC(12, 2),
    created_at TIMESTAMPTZ NOT NULL
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2024_01
    PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE orders_2024_02
    PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

查询时 PostgreSQL 自动只扫描相关分区——90 天的查询不会碰 2 年前的数据。

9. 横向对比：什么时候引入专用工具

PostgreSQL 的隐藏优势：OLTP + 分析同库。ClickHouse 和 Flink 需要从业务数据库同步数据，这意味着额外的延迟、额外的运维、额外的一致性风险。PostgreSQL 直接在业务数据上跑分析，是中小规模场景真正的杀手锏。

能力维度	PostgreSQL	ClickHouse	Flink
OLTP / 事务写入	★★★	✗	✗
窗口函数灵活性	★★★	★★	★★★
实时流处理	★	★	★★★
聚合查询性能	★★	★★★	★★
运维复杂度	低	中	高
与业务库同源	✓ 同一个库	✗ 需要同步	✗ 需要同步

10. 何时升级到 TimescaleDB？

TimescaleDB 是 PostgreSQL 的扩展，不是替代品。原有 SQL 无需修改，加上它只会让查询更快。

写入频率持续超过 5 万行/秒
单表数据量超过百亿行
需要自动数据压缩（时序数据压缩率可达 90%+）
需要自动数据过期（retention policy，老数据自动删除）
想用 time_bucket_gapfill（自动补零，比 generate_series 更优雅）

迁移只需一行，之后所有原有查询继续有效：

SELECT create_hypertable('server_metrics', 'ts');

11. 总结

本文覆盖的核心技术点:

date_trunc + generate_series：时序对齐与补零，折线图不断裂的关键
ROWS vs RANGE：滑动窗口两种语义，稀疏事件数据必须用 RANGE
三种窗口模式：滚动（date_trunc）、滑动（RANGE BETWEEN）、会话（LAG + SUM 模拟）
异常检测：Z-Score + 连续 N 次检测，比硬编码阈值健壮得多
BRIN 索引：时序数据专属，体积是 B-Tree 的 ~1%

窗口函数是 SQL 里被低估最严重的功能。很多工程师绕了一大圈 Spark DataFrame、Flink DataStream，回头发现想要的结果一条 OVER (ORDER BY ts RANGE BETWEEN …) 就能给出来。

不是说大数据工具没价值，而是——在引入复杂架构之前，请先确认你真的需要它。

用3年修复996工作后应激，用AI重构自己

Mon, 04 May 2026 00:00:00 +0000

时间总是以意想不到的方式流逝。3年前，因为身体原因结束了一段996工作后，我进入了一段极度迷茫的自我探索期。我一直以为，离开996就结束了。后来才发现，结束的只是工作时间，而不是那种状态。

真正留下来的，是一种很难描述的东西。对时间的焦虑，对效率的执念，对“必须马上有产出”的恐惧。哪怕在休息的时候，也会下意识打开电脑；哪怕没有任务，也会制造任务给自己。这种状态不像累，更像一种长期被训练出来的条件反射。

它不会因为你辞职就消失，它会跟着你，进入你的下一段生活。焦虑，焦虑，焦虑，怀疑，怀疑，怀疑。莫名其妙的疲劳感。我试图用过各种方式来对抗它，药物，旅行，睡眠，但效果都很有限。

最可恶的是，我隐隐约约知道为什么自己状态这么差，这才是最难修复的部分。因为问题不在于你有没有在休息，而在于你是否还在用原来的逻辑看待世界。

人生观，或者是人生的体感就已经被996式的工作异化了。

值得庆幸的是，从一开始我便是一个AI重度用户，一开始，我只是把像 ChatGPT 和 Claude 这样的工具，当作效率助手。写代码、查资料、整理信息，它们确实让我更快完成事情。但很快我发现，如果只是把AI当成更快的工具，那我只是把996的效率逻辑放大了而已。

我用大模型去不断分析自己的状态。用大模型去认知自己，让大模型参与“决策”和“结构”的部分，而不仅仅是用于“劳作”。

从某种意义上说，AI帮我“重新分配了注意力”。996留下的问题，不只是身体透支，而是注意力被长期错误分配。你习惯把精力放在低价值、高重复的任务上，因为那是被要求的，而不是被选择的。

现在每一天AI的知识如潮水般袭来，我们可能会感同身受，近些日子AI的知识是在被动灌入的。谁都知道一点，好像谁都能玩好。可是，可惜的是，明明知道该去看看langchain该去看看skill，可就是提不起精神来去学一点。

我是一个研发者，却成了AI革命进行时的场外人。

AI浪潮带来的焦虑，也让空洞的追求成为常态。我常会被提问“AI是不是可以XXX”。大多数非技术关注者，更先开始“AI幻觉”，他们大概仅仅只是刷了下抖音，便以为在追赶时代。可是我太疲劳，都没有留意这些时代弄潮儿产物。对什么OpenClaw养龙虾，对什么harness engineering提不起一点兴趣。

可以明确的留意到，初级岗位在消失，脑力型劳动均受到了AI的“替（ying）代（xiang）”。当前这个阶段消失的不是职业，而是任务。初级分析师花80%时间做的事情，正在被AI压缩到20分钟。复杂的技术工具，在被AI简化，在被抖音上的各种网红宣传，这些技术门槛，不是特别难突破。我们不得不思考，去重新定义”一个人的价值在哪里”。

我不断追问ChatGPT，我的定位在哪里，我该怎么办，让他给我各种建议。可我就是没有任何行动。

历次技术革命——蒸汽机、电力、互联网——最终都创造了比消灭更多的就业。但转型过程中，总有一代人付出了沉重代价。AI革命的速度远超以往，留给社会适应的时间窗口更短。政策制定者、教育体系、个人的反应速度，将决定这场转型是软着陆还是硬撕裂。

目前我唯一能从这股浪潮中，感受到自己还能有点作用的地方是——尽量借用AI的思考作出生活上的判断。毕竟生产力在加速，但组织、制度、教育都还没准备好。唯一值得请教的只有AI，所以我不断的用AI辅助思考，以求无漏。聪明的人，聪明的观点太多了，我只能这样追赶。

平庸的奋斗者，该如何走后面的路？

于是我让AI做了下面的表格。这3年我问过AI很多问题，职业方向、人生规划、怎么从焦虑里出来。它每次都回答得很认真，给我列条目，画框架，分析处境，像一个永远不会不耐烦的人。我照着做的，大概不到两成。我没有创业，没有想通，没有涅槃重生。我只是慢慢地，重新开始觉得一件普通的事情也可以做，不是因为它有用，只是因为我想做。这个感觉曾经消失了很久，我一度以为它不会回来。有时候我也会想，也许AI真的会把所有事情都重写一遍，我现在做的这点什么，过几年看来什么都不算。也许吧。但那是以后的事。我现在只知道，我今天做了，比昨天多想了一点，这就够了。徒劳这件事，等真的徒劳了再说。

时间阶段	技术状态	经济/工作变化	社会结构变化	个体层面的变化
2024–2026（已发生/正在发生）	大模型成熟（如 ChatGPT、Claude）	AI辅助工作成为标配，生产力提升	白领岗位开始“任务级压缩”，但结构未变	会用AI的人效率翻倍，不会用的人开始掉队
2026–2028（短期）	AI Agent兴起（能执行多步骤任务）	企业“少人高产”，中间层岗位收缩	出现结构性摩擦（岗位减少但新岗位未完全出现）	初级岗位压力最大，个体差距迅速拉开
2028–2030（过渡期）	AI深度嵌入业务流程	工作被拆解为模块，部分自动化	自由职业、项目制增加，公司边界变模糊	个体开始“AI增强”，但适应能力分化严重
2030–2032（结构变化期）	AI系统协作（Agent网络）	大量任务自动化，传统岗位减少	新型分层出现（AI驾驭者 / 协作者 / 被替代群体）	“稳定职业”概念弱化，路径变不确定
2032–2035（制度调整期）	AI成为基础设施（类似电力/互联网）	财富创造方式改变，生产力极度集中	政策介入（UBI探索、AI税、数据产权）	个体不再完全依赖“工作”获得收入
2035以后（长期）	高级AI/类AGI逐步成熟（不确定性高）	经济模式可能重构（人类劳动占比下降）	社会从“工作驱动”转向“资源分配驱动”	人类重新定义价值、意义和角色

把玩crAPI

Wed, 29 Oct 2025 00:00:00 +0000

Github从来不缺好玩的，最近在研究API攻防，注意到了crAPI。全称是“完全脆弱的API”。正如其名，它是一个被故意设计得千疮百孔的API交互站。

crAPI

cd cd crAPI-main/deploy/docker
docker compose -f docker-compose.yml --compatibility up -d

项目内设置的挑战之一是这样的：

Challenge 1 - Access details of another user’s vehicle
To solve the challenge, you need to leak sensitive information of another user’s vehicle.

Since vehicle IDs are not sequential numbers, but GUIDs, you need to find a way to expose the vehicle ID of another user.

Find an API endpoint that receives a vehicle ID and returns information about it.

解法倒是蛮简单，可以通过观察发现不同API直接有关联性，进而找到泄露点：

Challenge 1 - Access details of another user’s vehicle

Detailed solution

1. Login to the application from http://localhost:8888/login
2. From the Dashboard, choose Add a Vehicle and add the vehicle by providing the VIN and pincode received in Mailhog mailbox after Signup or by reinitiating from Dashboard page.
After the vehicle details are verified successful, the vehicle will get added and then be populated in the Dashboard page.
4. Observe the request sent when we click Refresh Location. It can be seen that the endpoint is in the format /identity/api/v2/vehicle/<vehicleid>/location.
5. Sensitive information like latitude and longitude are provided back in the response for the endpoint. Send the request to Repeater for later purpose.
6. Click Community in the navbar to visit http://localhost:8888/forum
7. It can be observed that the forum posts are populated based on the response from /community/api/v2/community/posts/recent endpoint. On further analysing the response, it can be seen that vehicleid is also received back corresponding to the author of each post.
8. Edit the vehicleid in the request sent to Repeater in Step 5 with the vehicleid received from endpoint /community/api/v2/community/posts/recent.
9. Upon sending the request, sensitive details like latitude, longitude and full name are received in the response.

The above challenge was completed using Burp Suite Community Edition.

在折腾过程中，踩到的坑是：使用Docker启动，默认监听的地址是127.0.0.1，这个地址看起来是如此正常，却与Burp Suite工具水土不服，BS默认不截获来自localhost的流量。

最终发现，最简单的办法是设置:

 sudo sh -c 'echo "127.0.0.1 crapi.local" >> /etc/hosts'

通过访问伪域名crapi.local，便能截获API请求了。

当然这些都不足够有趣，有趣的是我发现有一个印度Youtuber Medusa用crAPI录制了一系列教学视频。嚯，第一次觉得印度姑娘有魅力。

我所想体验的一切

Wed, 10 Sep 2025 00:00:00 +0000

我的脑子被物欲绑架了。回顾这种物欲纠结的感觉，大概从之前纠结要买哪一块表开始，从纠结哪一辆车开始。这种折磨的表现是：可以从21点刷闲鱼直到凌晨1点。然后现在已忘记到底要买什么。进一步反思，我发现自己总会被一些固定的念头绑架，我盘点了一下：

需要花时间的：看 DHH 演讲（Rails作者近期神作）、玩 Omarchy（DHH订制的Archlinux）、国际站外贸上货（我已经拖延快1年了）、读书（囤了好多专题的书籍）、看大模型论文（看了个开头，浑浑噩噩）、自研大模型软件（做了一点点，但是没有驱动力了）。
需要长期跟踪的：Youtube订阅的一系列视频、《凡人修仙传》、《凸变英雄》。
不需要花钱的：调研数据中台、调研机器人项目。
小钱能搞定的：防滑拖鞋、夹子、白板。
大钱才行的：摩托车驾照、本田 CM300、开源软件认证、洗衣机、摔倒报警腕表。

除了追更《凡人修仙传》。其它很有可能全死在 TODO 清单里，尸骨无存。

心魔？？？

以前会硬上一下，非得达到是目的，牺牲休息时间也可。现在缺了这口劲儿。想着如今已经年过三十，不妨与自己和解，试试别的路数。

盘点下来，《凡人修仙传》实在是无法割舍，每周六准时享受。《凸变英雄》这种餐后甜点，也快追完了。这也仅仅占用周六2个小时。

DHH演讲最多2个小时，不过是没时间看罢了，可能也就是某个空闲时，便能吸收其精华。其实已经知道个大概了，人家开发理念确实好。

Omarchy Linux已经在我小机器装好了，没想到由于各种情况，基本耗费了1天时间，体验上了，还缺个梯子，未来想用于开发机。

读书，我一直在囤，我总是在深夜开始想念他们。有一个专题的书籍，哪怕每天看5页呢。

国际站外贸上货，我也不知道我在等啥，就是没心情去搞，这个投资了小五万，现在就缺个上货。在等契机，还没想好。

看大模型论文，确实有启发，这周抽空看了一下，总是被细碎的生活琐事打断，但是沉浸式与GPT交互读论文，还是小有启发的。

Youtube订阅的一系列视频，每当我打开机器，我总是随机在算法引导下游走，或许在做饭的时候听一下即可。

调研数据中台，调研机器人，其实就是更商业沟通的事情，我倾向于在工作日处理。

还有花小钱就能买到的物件，现在差一个白板，要贴满整面墙。还差一双防滑拖鞋，给老婆准备的，或许可以交给她解决？或许可以在刷抖音时候解决？也说不清在纠结啥，很占脑子。心疼这点钱，总还是是无效投入。

驾照，11月才能增加摩托车，增加后还得算算能不能买得起CM300，或者直接租借过瘾即可。

洗衣机，摔倒报警腕表。洗衣机等回血，腕表太贵了，想着要不二手，要不干脆不要了。

啊，真正杀死我时间的是脑子里混乱的焦虑，根本不是我喜欢的这些所有。

写下上面的碎碎念，是在9月9日，如今10月9日有什么变化呢？

最佳实践的一点是，我重新开始使用谷歌日历了，每天的时间账单很清晰，可以见到自己的精力是分散的。目前在适应这种分散，方法上沿用了习惯的番茄钟，也了解了一下时间拳击法，综合一下适配自己。

本质还是注意力，其实注意力的训练，我已经摸索了自己多年，但是近年来开始使用抖音的习惯让我开始丧失那种沉浸式的集中感。当然，还有琐碎的生活导致注意力分散。

还有个较大的缺点是：脑子会有钉子一样的碎碎念。姑且称之为“钉子念想”吧。这种念头很细小，但是总会像是钉子一样插在脑子里，自己总会不间断的突然想起来，但是又不去做。实际去执行的话，可能也只是细碎时间内完成的事情。比如：重置忘记了的银行卡密码。

当前发现最有效的克服“钉子念想”办法是写下来。我忘记哪里有类似的说法和解决办法，看起来有效。

再回顾一下一个月前的“钉子”，

DHH演讲看完后，又开始对Rails感兴趣了，下载了Rails的书籍，却又囤着没时间读，成了又一颗钉子。

Omarchy Linux确实很有意思，我为之投入了小一百元买了U盘，装在了自己的NUC小主机里。在安装过程中体验到了一些问题，均是因为“GFW”导致，好在顺着报错一一解决。

国际站依然没有上货。好大一颗钉子在脑子里。

书籍这块，我重新做了分类和整理，我这是知识松鼠除了囤就是整理，乐此不疲。做出的优化是，我的分类开始顺应着自己的规划了，我给自己了三个定位：数据工程师，全栈开发者，创业者。基于这样的定位，我重新整理了书单。我想着每天都回顾一下自己的目标，以便于驱动自己读书。一个比较有效的尝试，开始听书，不知不觉听完了《创业维艰》。撕碎的时间里，用播客填补空白，可以挽救几百个小时的时间。

读论文，顺利读完，还是有更深刻的认知，缺乏实践，衍生出的扩展阅读还需要跟进。

自研大模型基座的软件，可以尝试一下spec-kit啦。

《凡人修仙传》依然无法割舍，《凸变英雄》追完了，垃圾。《和平使者2》无脑在看。突然想看漫画，下载了《钢之炼金术师》，还是那么喜欢。突然想看《迷宫饭》，神作，喜欢。

至于花小钱办大事系列，我尝试了之前自己所认为的无意义的花钱，结果没想到还挺香，比如买了一个贴墙白板，比如防滑拖鞋，比如我尝试了阳台种菜，比如冰箱上的计时器，这些事情是那么简单，花销是那么小，但是换来的生活体验是那么多。

摩托车驾照考试降价到650了，等等党的胜利。

买了新洗衣机，老婆很满意！

有了清晰的人生定位，有了果断的行动，从容。

超轻量超简单的markdown博客

Fri, 18 Apr 2025 00:00:00 +0000

我的markdown越攒越多了，有时候又需要给人分享。就想着找个简单轻量的markdown博客系统部署出去。结果没想到，现在仅仅是把markdown伺服起来这么一个简单的需求，都没有合适的工具了。大概看了ghost、cms.js等工具，感觉还是不够简单。干脆用AI写个得了。

在这篇文章中，将展示如何构建一个极简的、超轻量级的 Markdown 博客系统。整个系统依赖于 Python 的 Flask 框架，使用 Markdown 格式的文件作为文章内容，并通过简单的前端页面展示。它不仅易于部署，而且具备基础的登录功能来保护你的内容。

功能概述

登录保护：确保只有经过验证的用户可以访问 Markdown 文件。
Markdown 渲染：将 Markdown 文件转换为 HTML 并展示。
文件管理：列出目录下的所有 Markdown 文件，用户可以点击查看。

技术栈

Flask：轻量级的 Python Web 框架，用于构建 Web 应用。
Markdown：将 Markdown 格式的文本文件转换为 HTML。
HTML/CSS：用于前端展示，没有任何排版。

搭建步骤

1. 安装必要的依赖

需要安装 Flask 和 Markdown Python 库。

pip install flask markdown

2. 项目结构

项目的文件结构如下所示：

/markdown-blog
    /local-files    # 存放所有的Markdown文件
    /templates      # 存放所有的HTML模板
        index.html
        login.html
        md.html
    app.py           # 主应用文件

3. 编写 Flask 应用（app.py）

这是整个应用的核心部分。Flask 用于创建 Web 应用，markdown 用于将 Markdown 文件转换为 HTML，应用还实现了登录保护功能。

from flask import Flask, render_template, abort, request, session, redirect, url_for
import os
import markdown

app = Flask(__name__)
app.secret_key = 'your_secret_key_here'  # 设置一个随机密钥

# 配置Markdown文件目录（修改为你的实际路径）
MD_DIR = os.path.join(os.path.dirname(__file__), 'local-files')
PASSWORD = '123'  # 硬编码密码

def check_auth():
    """检查是否已登录"""
    return session.get('authenticated', False)

@app.route('/login', methods=['GET', 'POST'])
def login():
    """登录页面"""
    if request.method == 'POST':
        password = request.form.get('password', '')
        if password == PASSWORD:
            session['authenticated'] = True
            return redirect(url_for('index'))
        return render_template('login.html', error='密码错误')
    return render_template('login.html')

@app.route('/')
def index():
    """显示Markdown文件列表"""
    if not check_auth():
        return redirect(url_for('login'))

    # 获取目录下所有md文件
    mds = [f for f in os.listdir(MD_DIR) if f.endswith('.md')]
    # 按文件名排序
    mds.sort()
    return render_template('index.html', mds=mds)

@app.route('/md/<filename>')
def render_md(filename):
    """渲染指定Markdown文件"""
    if not check_auth():
        return redirect(url_for('login'))

    # 防止路径穿越攻击
    if '..' in filename or filename not in os.listdir(MD_DIR):
        abort(404)

    # 构建完整文件路径
    filepath = os.path.join(MD_DIR, filename)

    # 读取并转换Markdown
    try:
        with open(filepath, 'r', encoding='utf-8') as f:
            content = f.read()
        html_content = markdown.markdown(content, extensions=['extra'])
    except Exception as e:
        abort(500, description=f"Error reading file: {str(e)}")

    return render_template('md.html', content=html_content, filename=filename)

if __name__ == '__main__':
    # 确保目录存在
    os.makedirs(MD_DIR, exist_ok=True)
    app.run(debug=True)

4. 创建 HTML 模板

index.html（显示所有 Markdown 文件的列表）：

<!DOCTYPE html>
<html>
<head>
    <title>Markdown文件列表</title>
    <style>
        body { max-width: 800px; margin: 20px auto; padding: 20px; }
        a { display: block; padding: 8px; text-decoration: none; color: #0366d6; }
        a:hover { background: #f6f8fa; }
    </style>
</head>
<body>
    <h1>选择要查看的Markdown文件：</h1>
    
        <p>目录下没有Markdown文件</p>
    
</body>
</html>

login.html（用于登录页面）：

<!DOCTYPE html>
<html>
<head>
    <title>登录</title>
</head>
<body>
    <h1>请输入访问密码</h1>
    
    <form method="post">
        <input type="password" name="password" required>
        <button type="submit">登录</button>
    </form>
</body>
</html>

md.html（显示 Markdown 文件内容）：

<!DOCTYPE html>
<html>
<head>
    <title>\{\{ filename \}\}</title>
    <style>
        body { max-width: 800px; margin: 20px auto; padding: 20px; }
        pre { background: #f6f8fa; padding: 15px; border-radius: 5px; }
        code { font-family: SFMono-Regular,Consolas,Menlo,monospace; }
        blockquote { border-left: 4px solid #dfe2e5; padding-left: 15px; color: #6a737d; }
        table { border-collapse: collapse; }
        th, td { border: 1px solid #dfe2e5; padding: 6px 13px; }
    </style>
</head>
<body>
    <a href="\{\{ url_for('index') \}\}">← 返回列表</a>
    <div class="markdown-content">
        \{\{ content|safe \}\}
    </div>
</body>
</html>

5. 运行应用

在项目目录下执行以下命令启动 Flask 应用：

python app.py

应用将运行在 http://127.0.0.1:5000，你可以通过浏览器访问它。

6. 如何使用

将你的 Markdown 文件（.md 格式）放在 local-files 目录下。
访问首页并输入正确的密码登录。
登录后，你可以浏览所有 Markdown 文件，点击链接查看文件内容。

总结

这个简单的 Markdown 博客系统是一个非常基础的项目，适合想要搭建轻量博客的开发者。你可以通过自定义 Markdown 文件目录、密码保护等，满足个人博客的需求。因为是 Flask 应用，你还可以根据需求进一步扩展功能，比如添加评论系统、分页功能等。

回想2024的思维导图

Tue, 21 Jan 2025 00:00:00 +0000

无意间翻出2024年期间，热火朝天干工作，脑子发热时候写下的MindMap。当时脑子真是太热了，想通过思维导图方式整理下思绪。现在再回头看，往事东流水，笑谈也不成了。那时候的情绪，现在想细微去品觉，一分难以回应。

彼时大概情景是，机缘巧合在线结识一个号称类似摩根士丹利什么鬼的金融大鳄归国。 GPT横空出世，引发巨大商机，作为金融弄潮儿想在中国商海引起一波涟漪。我自觉时运已到，赶快合作一波。一来二去，就张罗着开始搞创业了。

MindMap中，写下的“核心任务”大概有这些项，第一大主题里是想弄个纯AI SKU的淘宝店：

项目	当时怎么想	现在怎么想
淘宝店	这淘宝店可是不一般。当时GPT新鲜劲儿刚来，就想张罗着给人去充值4.0账户。淘宝上挂出这个商品，还是有商机在的。GPT 4.0账户、企业版席位这关键字上去，就是绝佳爆品。金融大鳄憋了大的说他弟弟在OpenAI工作，意图拿下中国金牌代理席位。哥们儿是真敢说呀。	还是惊叹阿里巴巴的配合程度，品类分类有问题，反馈后立马给作出了调整。GPT账号充值，我也终于找到了稳定的方法。至于API黑色产业，也有一定了解。作为Tire 4玩家，这方面已经没有什么疑问了。
DEEP LEARNING 深度学习代做	作为中国AI界的吃螃蟹者(自诩的)，当然得深入技术底层，什么机器学习、深度学习，已经是工业场景成熟的产物，一顿忽悠直接上，回头再想调用什么API。	当时是作为技术人员的拧巴，觉得这种服务必须上。其实放到今天，心底也只有一个人选能做。自己半斤八两只懂个皮毛，10年前就想学，也却是学了，也却是忘了。未来遇到这样的技术需求，默认去调用大厂API，这样ROI更高。
BID 标书自动生成	大模型做标书生成，一键直接出标书全文，可谓是大模型落地之首。这个产品是直接找一个叫阿然的网友采购的，他也是二道贩子。忘了因为什么，还产生了些纠纷，把服务器给停了。	涉及到标书，核心原因还是股东里有个小伙子公司是做标书服务的。我们后续也做了真金白银的落地测试。目前最终情况是，培训标书专员去使用ChatGPT成本最低。这也是去年失败投资里最成功的一件事之一，当然了，也没有什么收益。
代购PIXCEL 8	AI手机，不必多说。	手机内嵌大模型功能已经普及，我已经非常习惯了，没想仅仅几百天前，真正的AI手机只有一台P8能看得上眼。这里金融大鳄曾说要每人赠送一部，然并无。
AI生成服装、盲盒	没记错的话，是Stable Diffution，当时通过生成做出一个不错的人物形象，甚至计划出实体手办。	在线测试服装换衣，在云栖大会里见到了实际产品，也有联系试用，无后续。盲盒的话，确实可行，一个叫阿威的哥们做了个原形，还挺好看。一高兴送了一条挺贵的领带，妈的。
厂商合作	科大讯飞办公硬件，飞虎的文字生图。	科大会议耳机看起来目前已经推广的不错。文生图主要是想与杭州的一家公司合作，这公司目前看做得不错，只记得CEO有不少比特币。可惜我没维护这条关系线。我觉得金融大鳄一直马扁这家公司，就没好意思联系人家。
数字人	印象中大模型爆火后，跟着数字人就火了，大家都想着说数字人接入大模型。	硅基智能作为大营销公司活到现在也真是骗不知耻，现在还有个朋友在跟这个项目，大家都是个API二道贩子，没啥技术含量。
VR设备	印象中是想卖Meta的VR设备	无后续，一切关于硬件采买的，金融大鳄都跳票了。
泡塑机料枪	对接了一家工厂，想将AI接入到工厂的工作流程中提效	我当时想到去训练ChatBot给业务员用，在导出客户资料那天，厂长和厂长夫人紧急叫停了，他们担心客户外泄。这个厂目前还有保持在联系。

赶着双11当日，我们结合各类AI工具，花了1天就把这个淘宝店上线了。草台班子也挺有行动力。这篇博客我写了一半，其实就不太想写了。做得失败事情挺多，挺没意思的。做商业这些人都挺虚伪的。金融大鳄满口AI，其实都不知道artificial intelligence怎么拼。不过人家今年却是骗出点成绩，看样子常州套了个办公楼。

MindMap第二大主题是，会所小程序。此事源头还是与合作的金融大鳄有关，他说自己在上海的会所想弄个小程序做会员卡管理。我一琢磨，这可行啊，淘宝花钱给搭个。上海会所的老钱风和老土风是并重的，X公馆。这哥们儿进了会所就暴露了，这哪是他开的，只能说确实是千丝万缕的联系吧。这会所老大倒是有点意思，平时爱叼着一根雪茄，第一次见面的时候，正在纠结新买的摇表器柜子摆到哪里。我们大概磋商了一下小程序设计风格，我说宝玑风吧，他连连称赞。此事结束的时间点是在之后了，金融大鳄暗戳戳跟我说，你给报价XX万吧（高报5倍），多余的钱我们分。

MindMap第三大主题是，“APEC 青岛 1月1日前确定”，哈哈哈，我是做梦都没想到，参加个国际级会议的门槛，其实还挺低的。不过最终还是没去参加的，这tmd的怎么去嘛，展示个球。

2024年，总的来说就是祛魅的一年。彻底祛魅了。现在遇到一个商海大佬，我怼一个。但是经历这些，也没让我长太多记性。我现在又陷入了下一场故事之中。为什么会偶然打开这个MindMap呢，因为我是要写新的MindMap整理新的思绪。

不缺商机，闭着眼睛都有商机。骗子最终套路都一致——借假修真。

我们无产阶级真可怜，活在既得利益者没怎么上心构建的局中。

考驾照一二事

Sun, 29 Sep 2024 00:00:00 +0000

8月底时，家父见我闲得发慌，终于强推到驾校去学习。我老张家自从老老张就是老司机，到了老张更是跟车打了一辈子交道，如今到我竟然驾照都没，简直不能忍。

没有驾照——简直是心病。

对于开车，我是确实没啥兴趣，一是买不起，二是打工打到骨子里，根本没有用车场景，叫个网约车对我来说都是奢侈行为了。也罢，总不能虚度时光，回顾2024年，新技术学习不能仅仅是会更好的写提示词。这进了驾校才知道，多少人对于取到驾照竟然是如此执念。从高三毕业党到退休大妈，一天到晚都在驾校孜孜不倦。

我不太当回事，权当打发时间，心理压力一直不足。科目一刷题两日，找回点学习的感觉，果断下单了驾校一点通，想着速战速决。奔着满分去，没想到有几道题牵扯到营运车辆问题，是个知识盲区，遗憾90分晋级。

为了省钱，一切都是为了省钱，在我们内蒙古考个驾照才2000。

科目二烈日炎炎，排队的车友太多，总是觉得练得不过瘾，教练主张一个无师自通，大道至简，自己刷抖音学得奇技淫巧一律不管用，全凭教练点位点拨以及极简操作。家父直接出阵教学，借了车拉着一家子在废弃广场里一轮一轮练习。自信练得不错，手动挡不过如此。

怎奈，科目二第一场就挂了，开始考试指令一发，直接启动——没有系安全带。是的，我仔细回顾自己的用车历史，老爹没系过，教练没系过，骨子里就没意识到这是个考点。第二次机会，在侧方停车项目中，停车点位不对，再挂。

“啊，教练，你确实没教过啊，你要说一声我也不至于挂。”

科目二不得已间隔十日后再战。补考费200。

好不容易熬到科三，已经开始有了车瘾，方向盘上手后有点小兴奋。膨胀到已经开始看车，基本锁定想弄个马自达练手，没想到买车竟然如此便宜，虽然荷包空空，但已经基本锁定要来一辆二手手动挡玩玩。

只是没想到，科目三是噩梦的开始，压力逐渐显现。不知不觉挂了三轮了：

一挂在,教练车和考试车车型不一样，实在搞不懂考试车的判定逻辑，明明自己感觉没问题的操作，考试机器就判定为失误操作。

补考费累计：400。

二挂在，教练追求的大道至简实在不适合于我等资质平凡之辈，比如我是挂了后才知道原来刹车需要在一个要求的范围内。

补考费累计：600。

家父家母施压，给教练红包：300。

三挂在，考试过程中路边临时施工，我就按照抖音中学到的操作得意洋洋的打双闪静候近半个小时，全考场中唯一一个正确处理的考生。怎奈何，怎奈何，重新给车打火时，离合死活找不到点，熄火两次，挂。

补考费累计：800。

三战科目三，终于开始感受到驾照的痛苦与纠缠。伴随着这开车的兴奋感，期望感，死死环绕着我。近乎病态啊，白天纠结到底买马自达还是买斯巴鲁，晚上纠结驾照还没到手，想这么多干嘛。

最讽刺的是，科目三考场，就是我打小长大的那条街。

研究二手车，研究手动挡技巧，研究玉皇大帝都开不走的抵押车……然后回到现实继续看科目三技巧。

现在考驾照的钱，已经够我买一台二手车了。

事情的转机到了，夫人哀怨我既然考不过，为什么不能找到私教带带，果断把我丢到杭州场口驾校附近找私教。

杭州加课练车费：150。

何教练，我遇到你，简直是三生有幸！

在我自信满满把车点着时，杭州场口驾校老董便利店良心专家何教练脸上已经三条黑线：“照你这么考，开始就该挂了呀。”

“我们那边考，这样就行啊。” 我有点想找补一下。

“不行！”，随后就是不知不觉一个小时的精彩教学。我的亲娘，对比起来，我驾校的教练简直就是什么都没教我。原来科目三虽然简单，但是还是有很多点位需要注意。

原来手动挡的离合器,是可以不卡顿启动车辆的: 缓抬离合器，在车身微微震动时，要持续几秒，然后松开刹车。

在加减档位时候，要留够间隔时间，是可以踩一下油门补油，让转速提上来。

我终于真正的开始学习了一次驾驶。

果断再多加练1小时，杭州加课练车费累计：300。

原来老天让我挂三次是为了我好啊，我根本就没学驾驶，挂了也是应该的。

10月，12日。张某将会再重返内蒙古重战科目三。

路费：1000+。

关于最近的我

Wed, 25 Sep 2024 00:00:00 +0000

我完整的休息了一年。

是的，脱离工作苦海。

不得不承认高强度工作带来的职业倦怠感是致命的。我真诚的建议任何从业者都不要过度投入到别人制作的世界中。真的会PTSD。

在休息的这一年中，经历了很多职业外的故事，反而让我更加开始知道人间的滋味。对社会、对人间百态的体验，是一个祛魅的过程。

——我逐渐开始理解一切。

各自生死执念中,

皮囊掩下心中闷,

哭笑付于匆匆。

到处都是疲劳干瘪的人，在驯化自己这件事情上，我们真的投入了很多。休息这一年，大概最大的收获，就是跳出了这种奇怪的圈子开始审视所有问题。

离开一份消耗你生命的工作。

对别人说不。

退出社交媒体，关注生活。

忽视他人言论，做对自己最好的事情。

诊断并解决MongoDB BTC勒索攻击：一个实战案例

Thu, 14 Sep 2023 00:00:00 +0000

引言

最近，我的朋友遭遇了一个令人不安的安全问题：他的MongoDB数据库受到了BTC勒索攻击。经历了一系列排查和解决的步骤后，我决定把这个经验总结成这篇博客。文中介绍用于诊断和解决问题的工具和方法，并分享一些有用的经验教训。

开始时的状况

问题开始于我的朋友发现数据库中有一些未知的集合，这些集合包含了勒索信息。一个严重的安全问题，需要立即采取行动。

{ "_id" : ObjectId("64fe8b50a20497578c3d0826"), "content" : "All your data is backed up. You must pay 0.0125 BTC to 19GCf7HvckzroTEQQcAfotci9WDkzpk5jW In 48 hours, your data will be publicly disclosed and deleted. (more information: go to http://iplis.ru/data1)After paying send mail to us: rambler+FUCKYOU@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: FUCKYOU" }

绝不妥协，绝不纵容勒索。

使用Mongo Shell进行初步审查

首先使用Mongo Shell连接到数据库以进行初步审查。虽然这个工具提供了许多有用的命令来查看数据库和集合的状态，但它无法告诉他哪个用户从哪个IP地址进行了操作。

MongoDB企业版才具备审计功能。但是对于大部分MongoDB用户来说，大家都是社区版使用者。

翻阅日志，只能看到建表信息：

cat /var/log/mongodb/mongod.log | grep README

配置MongoDB日志?

初步商量的想法，肯定是先增加日志级别协助排查。

调整MongoDB的日志设置，以便记录更多详细的审计信息。修改 /etc/mongod.conf 文件，并在其中添加了如下内容：

systemLog:
  destination: file
  path: "/var/log/mongodb/mongod.log"
  logAppend: true
  component:
    accessControl:
      verbosity: 2

理论上来说，这样的配置可以帮助他了解数据库的访问控制信息，但担心仍然没有足够的数据来诊断问题。同时考虑到，我们第一次遭遇这样的情况，不确定直接重启MongoDB实例，将会遭遇怎样的后果。

直接通过日志来看，名为 REAMDE 的collection内容在不定期重复创建。我们决定：直接抓鬼。

利用tcpdump和Wireshark捕获网络流量

考虑到MongoDB日志的局限性，决定使用 tcpdump 工具捕获与数据库相关的网络流量。运行 tcpdump 后，得到了一个包含所有网络数据包的 pcap 文件。

sudo yum install tcpdump

只监听27017端口，用tcpdump录制流量，产生的mongodb_packets.pcap将会解答一切疑惑。

sudo tcpdump -i eth0 'port 27017' -w mongodb_packets.pcap

Wireshark分析

功夫不负有心人，一夜等待后，通过MongoDB日志发现再次发生了创建勒索表的行为。

2023-09-14T06:22:36.094+0800 I STORAGE  [conn14539449] createCollection: READ__ME_TO_RECOVER_YOUR_DATA.README with generated UUID: fc718e02-1707-4b94-9881-3e4d274a9fe1

Wireshark打开这个 pcap 文件，并开始仔细分析数据包。最初尝试了多种过滤方法，优先按照日志触发时间筛选了心目中的可疑IP：

(tcp and ip.addr == XXX.1.1XX.X0) and (frame.time >= "Sep 14, 2023 03:00:00")

但最终使用了一个非常简单但非常有效的显示过滤器：

frame contains "README" or frame contains "create"

这个过滤器立即突显出了一些非常可疑的数据包，其中包括勒索软件很可能用于创建恶意集合的命令。

我们发现：竟然是一个外网IP，访问到了处于内网环境中的MongoDB。

破案

我们当即陷入各种揣测和幻想，这尼玛骇客都玩得这么牛逼了？怎么渗透进来的？

同志们，这如果是按照一个技术问题排查，那以我们的技术能力来看，这简直算是与顶尖骇客较量了，一台内网的机器，你这是怎么黑进来的？？？

但是真相往往需要一点点灵感和跳出局限。为什么我们有个心目中的可疑IP呢？因为数据库被黑时间段，是另一个BI项目上线时间段，我们怀疑过某种关联。

而这个关联虽然没有通过“技术上”通过流量访问判断出来，但是有逻辑意义上的关联。继续深挖发现，为了BI项目，可能各个项目组之间缺乏沟通和安全意识，是有在公网上打开了27017端口！

使用nmap甚至能够探测到版本号！

sudo nmap -p 27017 -sV XXX.16.22.XXX

PORT      STATE SERVICE VERSION
27017/tcp open  mongodb MongoDB 4.0.24

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.38 seconds

好了，后面就是联系负责的小伙伴去关端口了。

得亏数据库内容是测试库，不重要。

结论和教训

多元化工具：在安全分析中，没有哪一个工具能解决所有问题。Mongo Shell、MongoDB日志、tcpdump和Wireshark都有各自的优势和局限。
深入分析：单单依赖数据库日志是不够的。网络流量分析提供了更多线索，可以用来诊断和解决问题。要结合场景看问题，不要纯粹寻求技术解读。
关键词过滤：有时候，简单的关键词搜索就足以找出问题的根源。在这个案例中，一个简单的Wireshark过滤器就帮助他找到了问题的核心。
安全最佳实践：这次经历提醒了诸位，加强访问控制和进行定期的安全审查是非常必要的。

通过综合运用这些工具和方法，成功地找出了问题的源头，并避免了可能更严重的损失。我希望我的这篇博客能为面临类似问题的人提供一些实用的指导。再次强调，数据库安全是一个永不停歇的战斗，但有了正确的工具和方法，我们至少能更有信心地面对挑战。