The Dance Class by Edgar Degas, 1874

作者 | Karina Nguyen

编译 | 岳扬

我确定，Anthropic 再也不会是我当初加入时的那个样子了，而我自己也变了很多。大约两年前，我以前端工程师的身份加入，当时公司只有大约 50 人。而当我离开时，已是一名研究员，公司规模已超过 700 人。期间我学到的东西是：

1）一个团队前进的速度，很大程度上取决于两件事：一是做决定够不够果断，二是愿不愿意以开放的心态去做一些有风险的尝试。

2）每次训练一个新模型，都不可避免地会出现一些问题需要解决，而通常，通过仔细回溯、分析数据，你就能逆向推导出问题的根源。

3）最简单甚至最笨的方法，往往反而奏效。

4）你必须经历透彻理解的全过程，才能最终得出最简单的答案。

5）当技术具有颠覆性时，告诉客户如何利用它来解决问题，正是你的职责所在。

6）要让公司文化随着团队规模扩大而不被稀释，关键在于培养一批发自内心认同并主动传播核心价值观的「内部倡导者」。

7）研究（Research）的美感在于，把实验性的想法拿过来，让它在更大规模上跑通、生效。产品工程（Product Engineering）的美感在于，把一个富有远见的设计构思，不断打磨、提炼，最终变成在给定约束条件下最简洁、最本质、可执行的形态。

8）如果你也是团队“第一个具有设计背景的人”，你的角色会更像是老师，得先教会大家怎么思考设计。这虽然累，但因为你需要不停地通过做漂亮的 demo 和幻灯片来展示愿景，你反而会因此学到很多关于如何融资和产品策略的知识。这是一种“失之东隅，收之桑榆”的成长路径。

9）发布 AI 产品，接受外界评估是躲不掉的。当你的模型足够强大时，你选择用学术界的哪把“尺子”来衡量自己，这本身就成了一种权力 —— 你在给学术界“背书”。你必须清醒地认识到这种权力的分量，并负责任地使用它（比如公平、透明地选择评估标准），而不是滥用它来误导大众或者操纵研究方向。

10）在公司飞速发展的时期，你必须习惯在迷雾中往前跳（敢于冒险和承担不确定性）。而个人成长最快的途径，就是不怕接手没人碰过的烂摊子，承担起超出自己本职的责任，并且付出远超别人期望的努力。这是一种典型的“在战斗中学习，在扩张中晋升”的成长路径。

11）团队内部平时怎么写文档、怎么沟通，决定了你们能想出什么样的点子，以及这些点子能不能变成现实。

12）不必总是执着于从零到一的原创，有时候，快速识别出已经被验证过的正确方向，然后集中资源、吸取前人教训，以更优的执行力去超越对手，是一条更稳妥、更快速的成长路径。

13）友谊不是目的，而是你专注做事、真诚待人之后，自然收获的珍贵礼物。

END

本期互动内容 🍻

文章提到“最笨的方法往往反而奏效”。你有没有经历过“绕了一圈才发现答案就在起点”的时刻？是什么让你当时愿意先试试那个“简单方案”？

本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。

原文链接：

https://semaphore.substack.com/p/things-i-learned-at-anthropic

⚙️ PostgreSQL 技术文章

🧩 pg_plan_advice: PostgreSQL的计划稳定性和用户计划器控制

Robert Haas为PostgreSQL 19提出了一个雄心勃勃的补丁集，引入了三个新的contrib模块：pg_plan_advice、pg_collect_advice和pg_stash_advice。这些模块旨在提供计划稳定性和增强用户对PostgreSQL查询规划器的控制能力。该提案解决了PostgreSQL长期以来对更好的规划器可预测性和用户干预能力的需求。虽然该补丁集是否会包含在PostgreSQL 19中仍不确定，但它代表了查询优化控制方面对数据库管理员和开发人员的重大潜在进步。

https://rhaas.blogspot.com/2026/03/pgplanadvice-plan-stabilit...

📨 PostgreSQL Hacker 电子邮件讨论精选

🧩 将表达式添加到 pg_restore_extended_stats()

讨论围绕重构stats_import.sql测试文件来减少检查统计差异查询中的代码冗余。Michael Paquier建议将重复的差异检查查询封装到PL或SQL函数中。Corey Huinker最初否决了这个想法，但现在考虑几种方法：创建视图来过滤OID列以简化比较、使用函数、将记录转换为JSONB并过滤有问题的键、在视图中添加列计数的回归检查，或使用\gexec查询动态生成列列表。所有方法在可维护性和处理未来模式变化方面都有权衡。Michael表达了对基于对象名称的带限定符视图的偏好，强调清晰性和可维护性，同时避免像JSON转换这样过于艺术化的解决方案。

https://www.postgresql.org/message-id/CADkLM=dRYs1RKhQwWS5sXn...

🧩 改进pg_sync_replication_slots()以等待主服务器推进

讨论的焦点是改进pg_sync_replication_slots()函数以处理插槽同步失败时的重试场景。Amit Kapila提出了对潜在无限重试的担忧，当插槽由于物理复制延迟或无效插槽等各种问题导致同步失败时可能出现这种情况。虽然shveta malik最初主张在故障转移前确保完整同步，但团队同意在为持久化插槽实现完整重试逻辑之前等待更多用户反馈。不过，他们就一个较小的更改达成了一致：在update_local_synced_slot()中将错误级别从ERROR改为LOG，以允许循环重试直到备用服务器追上。Zhijie Hou提供了实现此更改的补丁。shveta malik随后审查了文档更新，建议使用更精确的措辞来说明哪些插槽会被重试——具体来说重试只针对处于临时状态的插槽，而不是所有持久化插槽，并建议在函数描述和logicaldecoding.sgml中相应地澄清文档。

https://www.postgresql.org/message-id/TY4PR01MB16907630F7DE92...

🧩 pg_plan_advice 查询计划建议

Robert Haas和David G. Johnston正在讨论pg_plan_advice功能的文档评审反馈。Haas担心Johnston建议的编辑往往是替换风格偏好而不是解决实质性问题，举例如将"mini-language"改为"domain specific language (DSL)"以及各种词汇替换。Haas认为许多更改并未提高清晰度，有些实际上删除了为未来黑客准备的重要技术解释。Johnston接受了反馈并询问更好的评审方法。Haas建议将反馈分为三类：明显错误（打包修复）、实质性关切（引用并说明）和风格建议（建议轻度处理）。讨论的核心是改进文档评审流程，同时保持技术准确性和作者声音。

https://www.postgresql.org/message-id/CA+TgmoaPH3rOmH1zw8s10A...

🧩 使用 rdtsc 降低 EXPLAIN ANALYZE 的时间开销?

John Naylor 审查了 Lukas Fittl 的 v10 补丁，该补丁旨在使用 rdtsc 减少 EXPLAIN ANALYZE 的时间开销。他认可与新的 pg_cpu_x86.c 文件的集成，但建议进行几项改进。主要反馈包括：确保在定义 HAVE__CPUID 但未定义 HAVE__CPUIDEX 时的正确处理，对 cpuid 叶子使用一致的十六进制值，以及保持更清晰的寄存器引用模式。Naylor 发现了一个关键 bug，即叶子 7 的 cpuid 结果覆盖了叶子 1 的结果，可能破坏 OSXSAVE 支持检测。他建议为不同的 cpuid 叶子使用单独的数组来避免此问题。其他建议包括创建用于特性位设置的辅助函数，添加寄存器名称符号以提高代码可读性，以及将一些更改拆分为单独的重构补丁以减少主补丁的占用空间。

https://www.postgresql.org/message-id/CANWCAZZ+Crjt5za9YmFsUR...

🧩 在发布中跳过模式更改

讨论围绕在PostgreSQL发布中实现EXCEPT TABLE功能的补丁展开，该功能允许用户从发布中排除特定表。Vignesh C在处理多轮反馈后提供了v56补丁。解决的关键问题包括：修复分区表描述中错误显示被排除发布名称的问题，纠正测试文件中的发布名称引用，修复"parition"拼写为"partition"等错误，以及改进代码格式。Nisha Moond识别出多个错误，包括测试用例中错误的发布名称和格式问题。Shlok Kyal在早期版本中整合了Amit和Shveta的反馈。最新的v56补丁按PostgreSQL版本分离描述表查询以提高可读性，并修复了剩余的拼写错误。Shveta Malik批准了v56版本，表明该补丁已准备好进入下一阶段的审查或可能的提交。

https://www.postgresql.org/message-id/CALDaNm2-Ob9qPR+vqUSVMk...

🗞️ 行业新闻

🧩 报道称，Anthropic 首席执行官达里奥・阿莫迪称 OpenAI 关于军方合作协议的对外说法纯属谎言

据报道，Anthropic CEO Dario Amodei指控OpenAI在军事合同信息传达方面撒谎。争议源于Anthropic因AI安全分歧而放弃与五角大楼的合同，随后OpenAI接手了这笔交易。Amodei对OpenAI关于军事合作伙伴关系的公开声明进行了强烈批评，突显了两大AI公司在国防合同问题上日益紧张的关系。这场争议凸显了AI行业内关于与军事组织合作以及此类合作伙伴关系中安全考量的更广泛辩论。

https://techcrunch.com/2026/03/04/anthropic-ceo-dario-amodei-...

🧩 Decagon 以45亿美元估值完成首次要约收购

AI驱动的客户支持初创公司Decagon以45亿美元估值完成了首次要约收购，为员工提供了流动性。这一举措代表了快速发展的年轻公司在上市前为员工提供早期流动性机会的增长趋势。要约收购允许员工向投资者出售部分股权，在公司保持私有状态的同时为他们提供财务收益。Decagon的巨额估值显示了投资者对AI驱动的客户服务解决方案的强烈信心，并反映了市场对人工智能在商业运营中应用的广泛热情。

https://techcrunch.com/2026/03/04/decagon-completes-first-ten...

🧩 一家初创公司提供更可靠的人工智能答案的方案：众包聊天机器人

CollectivIQ提出通过同时汇总多个聊天机器人模型的回答来提高AI准确性的解决方案。这家初创公司向用户展示从ChatGPT、Gemini、Claude、Grok以及多达10个其他AI模型同时获取信息的答案。这种众包方法旨在通过利用不同AI系统的集体智慧来提供更可靠和准确的回答。该概念解决了AI部署中的一个关键挑战：单个模型的不一致性和潜在不准确性。通过结合多个AI视角，CollectivIQ希望为用户提供更值得信赖和全面的查询答案。

https://techcrunch.com/2026/03/04/one-startups-pitch-to-provi...

🌐 社交媒体动态

🧩 在 pgEdge，我们致力于确保用户对我们开源项目(如 PostgreSQL 的 pgEdge MCP服务器)的使用体验

pgEdge 邀请用户试用他们的开源 pgEdge MCP Server for PostgreSQL 项目并提供反馈，以获得抽奖机会，奖品为 CanaKit Raspberry Pi 5 Starter Kit PRO（128GB，8GB RAM）。要参与抽奖，用户必须下载并安装该项目，然后留下反馈。抽奖活动将于 2026 年 3 月 31 日晚上 11…

https://www.linkedin.com/posts/pgedge_github-pgedgepgedge-pos...

🧩 CYBERTEC 团队正式抵达伦敦科技展!

CYBERTEC 团队正在伦敦 ExCeL 展览中心参加 Tech Show London 展会。他们将在 F297 号展位停留两天，随时准备与参观者交流并讨论数据库相关的挑战。欢迎任何参加展会的人员前来咨询他们的 PostgreSQL 专家团队。

https://www.linkedin.com/posts/cybertec-postgresql_techshowlo...

🧩 伦敦科技展第一天看到路易斯·塞鲁克斯的演讲是一大亮点

作者参加了伦敦科技展的第一天。观看路易斯·塞鲁克斯的演讲是一大亮点，他回忆起大学时和朋友一起观看塞鲁克斯纪录片的情景。作者还为同事汉斯-尤尔根·舍尼格的演讲感到自豪，他强调了波斯特gresql在当今全球冲突背景下的重要性，以及日益增长的数字独立性需求。作者期待着第二天的活动。

https://www.linkedin.com/feed/update/urn:li:activity:74350781...

HOW 2026 议题招募中

2026 年 4 月 27-28 日，由 IvorySQL 社区联合 PGEU（欧洲 PG 社区）、PGAsia（亚洲 PG 社区）共同打造的 HOW 2026（IvorySQL & PostgreSQL 技术峰会） 将再度落地济南。届时，PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您提交前沿技术实践与洞见，共同打造高质量议题内容。

投递链接：https://jsj.top/f/uebqBc

解决浏览器 WebSocket 认证难题：豆包语音识别的代理方案实践

浏览器 WebSocket API 不支持自定义 HTTP header，这给需要通过 header 传递认证信息的语音识别服务带来了挑战。本文分享 HagiCode 项目中如何通过后端代理方案解决这个问题，以及从 playground 到生产环境的实践过程。

背景

其实在做 HagiCode 项目的语音识别功能时，我们也是满怀信心地选择了字节跳动的豆包语音识别服务。刚开始的设计很简单嘛——前端直接连豆包的 WebSocket 服务。这有什么难的？不就是建个连接，传点数据的事儿吗？

可是吧，万万没想到——豆包的 API 要求通过 HTTP header 传递认证信息，什么 accessToken、secretKey 之类的。这下就有点尴尬了，因为浏览器的 WebSocket API 根本不支持设置自定义 header。

你说不支持怎么办嘛？

那时候也是纠结了一阵子的。毕竟摆在面前的两个选择：

1. 把认证信息塞到 URL 查询参数里——简单粗暴
2. 在后端做一层代理——看起来麻烦一点

第一种方案吧，凭证就直接暴露在前端代码和本地存储里了。这安全吗？反正我是不太敢苟同的。而且有些 API 必须用 header 验证，根本走不通。

最终想了想，还是选了第二种方案——在后端实现一个 WebSocket 代理。说起来也是巧合，这个方案最初是在我们的 playground 试验场里验证的，后来确认稳定了才应用到生产环境。毕竟谁也不想在生产环境当小白鼠嘛，这点儿道理我还是懂的。

关于 HagiCode

本文分享的方案来自我们在 HagiCode 项目中的实践经验。

HagiCode 是一个 AI 代码助手项目，支持语音交互功能。怎么说呢，也就是因为需要在前端调用语音识别服务，我们才遇到了这个 WebSocket 认证问题，也才有了后面的解决方案。有时候想想吧，困难这东西也不是完全没有好处，至少让我们学会了用代理，不是吗？

技术挑战分析

浏览器 WebSocket 的限制

标准 WebSocket API 看起来真的很简单：

const ws = new WebSocket('wss://example.com/ws');

但问题就出在"简单"这两个字上——它只在 URL 里传递参数，没法像 HTTP 请求那样设置 headers：

// 这在 WebSocket API 里是不支持的
const ws = new WebSocket('wss://example.com/ws', {
  headers: {
    'Authorization': 'Bearer token'
  }
});

你看看，这找谁说理去？对于豆包语音识别这类需要 header 认证的服务，这个限制简直就是一道迈不过去的坎儿。

罢了罢了，又能怎样呢？

架构设计决策

在设计方案的时候，我们也是左思右想，权衡了又权衡。

决策一：代理模式选择

我们比较了两种方案：

最后选了原生 WebSocket。说实话，也就是因为它最轻量，适合简单的双向二进制流转发。加个 SignalR 吧，确实有点杀鸡用牛刀的感觉，而且会增加延迟——这又何苦呢？

决策二：连接管理策略

我们采用了"每连接单会话"模式——每个前端 WebSocket 连接对应一个独立的豆包后端连接。

这样做的好处也是显而易见的：

• 实现简单，符合典型使用场景
• 易于调试和故障排查
• 资源隔离，避免会话间互相干扰

其实说白了也就是——简单粗暴有时候反而是最好的选择。复杂的方案不一定好，简单的不一定差。

决策三：认证信息存储

凭证存在后端配置文件（appsettings.yml 或环境变量）里，通过依赖注入加载：

• 配置方式简单，符合现有后端配置模式
• 敏感信息不暴露给前端
• 支持多环境配置（开发、测试、生产）

这安全感嘛，总归是要有的。毕竟谁也不想自己的凭证满天飞，不是吗？

数据流设计

整体数据流是这样的：

前端 (浏览器)
  │
  │ ws://backend/api/voice/ws
  │ WebSocket (二进制)
  ▼
后端 (代理)
  │
  │ wss://openspeech.bytedance.com/
  │ (带认证 header)
  ▼
豆包 API

流程倒也不复杂，也就是这么几步：

1. 前端通过 WebSocket 连接后端代理
2. 后端代理接收音频数据，用带 header 的方式连接豆包 API
3. 豆包 API 返回识别结果，代理转发给前端
4. 全程异步双向流式传输

一切看起来都是那么自然，不是吗？

核心组件实现

1. WebSocket 端点配置

app.Map("/ws", async context =>
{
    if (context.WebSockets.IsWebSocketRequest)
    {
        // 从查询参数读取配置
        var appId = context.Request.Query["appId"];
        var accessToken = context.Request.Query["accessToken"];

        // 验证必需参数
        if (string.IsNullOrEmpty(appId) || string.IsNullOrEmpty(accessToken))
        {
            context.Response.StatusCode = 400;
            return;
        }

        // 接受 WebSocket 连接
        using var webSocket = await context.WebSockets.AcceptWebSocketAsync();

        // 消息处理循环
        var buffer = new byte[4096];
        while (!webSocket.CloseStatus.HasValue)
        {
            var result = await webSocket.ReceiveAsync(buffer, CancellationToken.None);

            if (result.MessageType == WebSocketMessageType.Close)
            {
                await webSocket.CloseAsync(
                    result.CloseStatus.Value,
                    result.CloseStatusDescription,
                    CancellationToken.None);
                break;
            }

            // 处理音频数据
            await HandleAudioDataAsync(buffer, result.Count);
        }
    }
});

2. 会话管理

public class DoubaoSessionManager : IDoubaoSessionManager
{
    private readonly ConcurrentDictionary<string, DoubaoSession> _sessions = new();

    public DoubaoSession CreateSession(string connectionId)
    {
        var session = new DoubaoSession(connectionId);
        _sessions[connectionId] = session;
        return session;
    }

    public async Task SendAudioAsync(string connectionId, byte[] audioData)
    {
        if (_sessions.TryGetValue(connectionId, out var session))
        {
            await session.SendAudioAsync(audioData);
        }
    }

    public void RemoveSession(string connectionId)
    {
        if (_sessions.TryRemove(connectionId, out var session))
        {
            session.Dispose();
        }
    }
}

用 ConcurrentDictionary 管理会话，线程安全也就不用操心了。每个连接进来就创建一个 Session，断开时自动清理——这大概就是所谓的"来也匆匆，去也匆匆"罢。

3. 配置验证

public class ClientConfigDto
{
    public string AppId { get; set; } = null!;
    public string Access set; } =Token { get; null!;
    public string? ServiceUrl { get; set; }
    public string? ResourceId { get; set; }
    public int? SampleRate { get; set; }
    public int? BitsPerSample { get; set; }
    public int? Channels { get; set; }

    public void Validate()
    {
        if (string.IsNullOrWhiteSpace(AppId))
            throw new ArgumentException("AppId is required");
        if (string.IsNullOrWhiteSpace(AccessToken))
            throw new ArgumentException("AccessToken is required");
    }
}

配置验证嘛，也就是为了在启动时就发现问题，避免运行时出什么幺蛾子。这点儿保障还是要的。

消息协议设计

前端和后端之间用 JSON 格式的文本消息做控制，用二进制消息传音频数据。

控制消息示例：

{
    "type": "control",
    "messageId": "msg_123",
    "timestamp": "2026-03-03T10:00:00Z",
    "payload": {
        "command": "StartRecognition",
        "parameters": {
            "hotwordId": "hotword1",
            "boosting_table_id": "table123"
        }
    }
}

识别结果示例：

{
    "type": "result",
    "timestamp": "2026-03-03T10:00:03Z",
    "payload": {
        "text": "你好世界",
        "confidence": 0.95,
        "duration": 1500,
        "isFinal": true,
        "utterances": [
            {
                "text": "你好",
                "startTime": 0,
                "endTime": 800,
                "definite": true
            }
        ]
    }
}

这种设计把控制信号和音频数据分开，处理起来也是更清晰一些。有时候分而治之确实是个不错的办法。

前端接入实践

WebSocket 连接

class DoubaoVoiceClient {
    constructor(config) {
        this.config = config;
        this.ws = null;
    }

    async connect() {
        const url = new URL(this.config.wsUrl);
        // 添加查询参数
        Object.entries(this.config.params).forEach(([key, value]) => {
            url.searchParams.set(key, value);
        });

        this.ws = new WebSocket(url);

        return new Promise((resolve, reject) => {
            this.ws.onopen = () => {
                console.log('[DoubaoVoice] Connected');
                resolve();
            };

            this.ws.onmessage = (event) => {
                this._handleMessage(JSON.parse(event.data));
            };

            this.ws.onerror = reject;
        });
    }

    _handleMessage(message) {
        switch (message.type) {
            case 'status':
                this._handleStatus(message.payload);
                break;
            case 'result':
                this.onResult?.(message.payload);
                break;
            case 'error':
                console.error('[DoubaoVoice] Error:', message.payload);
                break;
        }
    }
}

// 使用示例
const client = new DoubaoVoiceClient({
    wsUrl: 'ws://localhost:5000/ws',
    params: {
        appId: 'your-app-id',
        accessToken: 'your-access-token',
        sampleRate: 16000,
        bitsPerSample: 16,
        channels: 1
    }
});

音频采集与发送

用 AudioWorkletNode 做音频处理，性能也会更好一些：

// audio-worklet.js
class AudioProcessorWorklet extends AudioWorkletProcessor {
    process(inputs, outputs, parameters) {
        const input = inputs[0]?.[0];
        if (!input) return true;

        // 转换为 16-bit PCM
        const pcm = new Int16Array(input.length);
        for (let i = 0; i < input.length; i++) {
            pcm[i] = Math.max(-32768, Math.min(32767, input[i] * 32767));
        }

        this.port.postMessage({
            type: 'audioData',
            data: pcm.buffer
        }, [pcm.buffer]);

        return true;
    }
}

registerProcessor('audio-processor', AudioProcessorWorklet);

// 主线程代码
async function startAudioRecording() {
    const stream = await navigator.mediaDevices.getUserMedia({
        audio: {
            echoCancellation: true,
            noiseSuppression: true,
            autoGainControl: true,
            sampleRate: 48000
        }
    });

    const audioContext = new AudioContext();
    const audioSource = audioContext.createMediaStreamSource(stream);

    await audioContext.audioWorklet.addModule('/audio-worklet.js');
    const audioWorkletNode = new AudioWorkletNode(audioContext, 'audio-processor');

    audioWorkletNode.port.onmessage = (event) => {
        if (event.data.type === 'audioData' && ws?.readyState === WebSocket.OPEN) {
            ws.send(event.data.data); // 直接发送二进制数据
        }
    };

    audioSource.connect(audioWorkletNode);
}

AudioWorklet 比 ScriptProcessorNode 性能好很多，不会有音频卡顿的问题。这年代，谁还愿意听那种刺刺拉拉的噪音呢？

后端配置

appsettings.json 示例

{
  "Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      { "Name": "Console" },
      {
        "Name": "File",
        "Args": { "path": "logs/log-.txt", "rollingInterval": "Day" }
      }
    ]
  },
  "Kestrel": {
    "Urls": "http://0.0.0.0:5000"
  }
}

日志配置很重要，方便排查问题。Serilog 的 File sink 可以按天滚动，日志文件也不会太大。毕竟有些问题嘛，事后诸葛亮总是要容易一点的。

注意事项和最佳实践

1. 连接监控

• 定期输出会话状态日志，方便追踪连接生命周期
• 监控音频段数量和持续时间，识别异常连接
• 记录与豆包服务的连接状态和重连情况

这些也就是一些基本的操作罢了。

2. 错误处理

• 捕获并记录所有 WebSocket 异常
• 使用 IAsyncDisposable 确保资源清理
• 实现优雅的连接关闭和超时处理

总而言之，稳字当头。

3. 音频格式要求

• 采样率：16000 Hz（推荐）或 8000 Hz
• 位深度：16-bit
• 声道：单声道
• 编码：PCM (raw)

格式不对会导致识别失败或者效果很差。这点儿规矩还是要守的。

4. 安全考虑

• 敏感凭证只存在后端配置里
• 实施连接数限制防止资源耗尽
• 生产环境用 HTTPS/WSS

安全无小事，且行且珍惜罢。

5. 性能优化

• 用异步操作避免阻塞
• 适当调整缓冲区大小（默认 4096 字节）
• 考虑连接池和复用策略

这些优化手段，能用上的就用上罢。

部署建议

1. Docker 部署：把代理服务打包成容器，方便扩展和管理
2. 负载均衡：用 Nginx 或 Envoy 做 WebSocket 反向代理
3. 健康检查：实现心跳机制监控服务可用性
4. 日志聚合：把日志发送到集中式日志系统（如 ELK、Loki）

部署这事儿吧，说简单也简单，说复杂也复杂。也就是因人而异，因地制宜罢。

总结

WebSocket 代理方案解决了浏览器 WebSocket API 不支持自定义 header 的根本问题。在 HagiCode 项目中，这个方案从 playground 验证到生产环境部署，证明了它的可行性和稳定性。

关键点总结：

• 后端代理可以安全地传递认证信息
• 原生 WebSocket 轻量高效，适合简单场景
• "每连接单会话"简化了实现和调试
• 前后端消息协议分离控制信号和音频数据

如果你也在做需要 WebSocket 认证的功能，希望这个方案能给你一些启发。

有什么问题的话，欢迎来讨论。毕竟技术这东西嘛，都是在交流中进步的。

参考资料

• HagiCode 项目仓库
• MDN Web API - WebSocket
• 豆包语音识别文档

感谢您的阅读,如果您觉得本文有用,快点击下方点赞按钮👍,让更多的人看到本文。

本内容采用人工智能辅助协作,经本人审核,符合本人观点与立场。

• 本文作者: newbe36524
• 本文链接: https://docs.hagicode.com/blog/2026-03-05-websocket-proxy-for-doubao-speech-recognition/
• 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!

在企业金融服务领域，审批效率与系统稳定性直接决定服务竞争力。博睿数据Bonree ONE通过全链路可观测能力，为通用技术财务公司破解审批耗时、故障难定位等核心痛点，实现67%的业务效率跃升，成为金融服务加速的关键引擎。Bonree项目背景通用技术财务公司主要提供企业融资、资金管理等金融服务，核心系统包括信贷审批系统、资金结算系统、客户管理系统等，各系统协同运转，是业务开展的核心支撑。在业务推进中，通用技术财务公司逐渐暴露两大核心痛点：业务审批流程耗时较长平均审批时间达2小时，部分环节衔接不畅，影响客户体验与业务拓展；同时系统故障时难以快速定位根源，平均排查时间长达3小时，严重影响业务连续性。缺乏有效的客户操作轨迹追踪机制无法精准捕捉客户业务办理细节，服务质量难以量化评估，优化方向不明确，制约客户满意度提升。Bonree应用场景针对上述核心痛点，通用技术财务公司引入博睿数据Bonree ONE一体化智能可观测平台，构建了覆盖核心业务系统的全方位可观测与追踪能力。
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
监控覆盖核心业务系统Bonree ONE平台全面覆盖信贷审批、资金结算等核心业务系统，累计安装探针超过100个，构建起全维度的监控网络，实时采集业务交易数据、系统资源指标和中间件运行状态，确保任何异常都能第一时间被感知。搭建全业务链追踪体系通过Bonree ONE的全链路追踪能力，通用技术财务公司搭建了覆盖整个业务链的追踪体系。平台整合了接口分位值、代码堆栈、数据库调用耗时等多维度数据，能够清晰还原每一笔交易的完整调用链。当业务出现缓慢或失败时，运维人员可以快速定位故障点，并进行根因分析，大大缩短了排障时间。用户会话功能精准记录操作轨迹Bonree ONE内置的用户会话功能，可以完整记录客户在业务办理过程中的每一步操作轨迹，包括页面响应时间、点击行为、错误信息等。这些数据为服务质量评估提供了精准支撑，帮助业务部门量化用户体验，明确优化方向。Bonree项目成果与收益应用Bonree ONE 一体化智能可观测平台，通用技术财务公司业务价值显著释放，核心指标大幅优化：业务效率跨越式跃升通过Bonree ONE平台对审批流程的精准监控与智能优化，简化冗余衔接环节、提升各系统协同效率，结算相关业务审批时间从2小时大幅缩短至40分钟，效率跃升67%。有力保障业务连续性借助Bonree ONE平台全链路追踪能力，系统故障排查时间从3小时大幅缩减至10分钟，故障处理效率实现质的提升。有效避免了因系统故障导致的业务中断、资金结算延迟等问题，降低了潜在的运营风险与经济损失，保障了信贷审批、资金结算等核心业务稳定性。精准优化服务质量基于Bonree ONE捕捉的用户操作轨迹数据，通用技术财务公司能够精准定位客户业务办理过程中的卡点、痛点，针对性优化服务流程与服务举措，切实解决客户实际需求，客户满意度提升40%，为公司金融服务业务的规模化发展提供有力支撑。关于通用技术财务公司通用技术集团财务有限责任公司（以下简称“通用技术财务公司”）隶属于中国通用技术(集团)控股有限责任公司。是经中国银行业监督管理委员会批准设立的为集团公司及集团成员单位提供财务管理服务的非银行金融机构。
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

在数字化营销日益精细化的今天，网站不仅是企业展示形象的窗口，更是获客转化的一线战场。据统计，超过70%的潜在客户在浏览网站时，希望立即获得人工或智能的响应。然而，市面上成熟的商业客服系统往往价格高昂、按坐席收费，且数据存储在第三方云端，这让许多中小企业和注重数据隐私的机构望而却步。在此背景下，OctIM 作为一款开源免费的网站客服系统源码，正以其自主可控、灵活部署的特性，成为构建私域沟通桥梁的理想选择。

OctIM网站客服系统源码详细介绍： https://impc.opencodetiger.com

一、痛点破局：从“租用”到“拥有”的转变

传统客服系统的商业模式多基于 SaaS（软件即服务），企业需按年支付昂贵的订阅费，且坐席数量受限。更关键的是，所有的聊天记录、客户画像、咨询数据都沉淀在服务商的服务器上。这不仅意味着企业无法深度挖掘数据价值，还面临着数据泄露、服务商倒闭导致数据丢失等潜在风险。OctIM 的出现彻底改变了这一格局。作为一套完全开源的源码系统，它允许用户将系统部署在自己的服务器上。这意味着企业从“租客”变成了“房东”，一次性投入（主要是服务器成本和技术人力）即可永久使用，无需再为每个新增的客服账号支付额外的许可费用。对于业务增长迅速、咨询量大的企业而言，这种模式能节省巨额的成本。二、为什么需要网站客服系统源码当前市面上的在线客服工具多以SaaS服务形式存在，虽开箱即用，但存在明显局限：数据不可控：用户聊天记录、行为数据存储于第三方服务器，存在隐私泄露与合规风险功能封闭：无法根据业务需求深度定制交互逻辑或UI风格，长期受制于厂商功能规划长期成本高：按坐席或会话量收费，规模扩大后费用激增，且存在“首年优惠后续涨价”的陷阱集成困难：与自研或开源系统耦合度低，难以实现订单、商品等上下文联动OctIM源码的开放，正是为解决上述痛点而来——它允许企业私有化部署、自由修改、无限扩展，真正实现“客服系统为自己所用”。

三、核心功能：全渠道接入与智能协同

虽然 OctIM 是免费开源项目，但其功能设计并未因“免费”而缩水，反而紧贴现代客服场景的实际需求，构建了强大的功能矩阵。实时通讯与多媒体支持：OctIM 基于高性能的 WebSocket 技术，确保消息毫秒级送达。支持文字、图片、文件、语音等多种格式，甚至支持发送商品卡片和订单信息，让客服沟通更加直观高效。智能路由与分配：系统内置灵活的会话分配策略，支持按技能组、按负载均匀分配或指定分配。当访客进入网站时，系统能自动将其引导至最合适的客服人员，减少等待时间，提升满意度。机器人辅助与人机协作：OctIM 支持接入智能机器人，能够自动回答常见问题（FAQ），在夜间或高峰期分担人工压力。当机器人无法解决时，可无缝切换至人工坐席，并同步历史对话记录，实现平滑过渡。全方位数据看板：管理员可以通过后台实时查看在线坐席数、排队人数、会话时长、满意度评价等关键指标。所有聊天记录永久本地存储，支持关键词搜索和历史回溯，为企业培训和质量监控提供详实依据。

四、技术优势：安全、扩展与集成

对于技术团队而言，OctIM 的价值不仅在于功能，更在于其架构的开放性。数据安全自主可控：这是 OctIM 最大的核心竞争力。金融、医疗、政务等对数据敏感性要求极高的行业，可以将系统部署在内网环境中，彻底切断外网数据泄露的风险，满足合规性要求。高度可扩展性：由于代码完全开放，企业可以根据自身业务逻辑进行二次开发。例如，定制特殊的快捷回复模板、对接内部的 CRM 系统以自动弹屏客户信息、或与 ERP 系统打通实现订单查询功能。这种灵活性是封闭的商业软件无法比拟的。多端适配与嵌入便捷：OctIM 提供了轻量级的 JS 代码片段，只需几行代码即可嵌入到任何类型的网站（HTML, WordPress, Vue, React 等）中。同时，客服端支持 Web 版、桌面客户端以及移动端 H5，方便客服人员随时随地处理咨询。

五、高度可定制性：适配千行百业

OctIM源码采用“基础功能固化+扩展功能模块化”的设计理念，开发者可基于业务需求灵活增减功能模块：电商行业：可扩展“订单同步”“物流查询”模块，客服在对话时实时调取用户的购买记录教育机构：可定制“课程预约”“学习进度查询”功能，实现“咨询-试听-报名”闭环金融企业：可强化数据加密模块，增设交易信息校验功能，满足行业合规要求跨境业务：可添加多语言实时翻译功能，支持国际化运营此外，源码支持界面UI的全量自定义，开发者可根据企业品牌调性调整配色、图标、布局等元素，实现客服系统与企业品牌形象的无缝融合。

六、OctIM结语：开源重构企业客服未来

在客户服务日益成为品牌护城河的今天，拥有一个稳定、高效、可定制的在线客服系统至关重要。OctIM网站客服系统源码，凭借其开源透明、架构先进、功能完整、扩展性强等优势，为企业提供了从“可用”到“好用”再到“智能”的演进路径。选择源码开发模式，意味着选择技术自主、数据安全、成本可控的发展道路。OctIM以其完整的技术架构、高质量的开源代码和活跃的社区生态，为企业构建专属客服平台提供了坚实基础。无论是初创团队快速上线客服能力，还是中大型企业构建自有服务中台，OctIM都是一个值得信赖的技术基石。选择OctIM，不仅是选择一套代码，更是选择对用户体验、数据主权与技术未来的主动掌控。在数字经济的浪潮中，让每一次网站访问都转化为潜在商机，让每一次客户沟通都成为品牌价值的积累。

去年黑五期间，某跨境电商平台发现一批"美国用户"订单异常：收货地址集中在特拉华州免税区，但下单IP却来自东南亚某国。进一步排查显示，这些订单使用同一批代理IP伪装位置，骗取新用户首单补贴后集体拒收，造成数十万美元损失。这种"IP与收货地分离"的欺诈模式，已成为跨境物流损耗的主要源头——据行业统计，地址异常订单的物流失败率高达35%，是正常订单的7倍。如何通过技术手段在下单阶段识别虚假地址，成为跨境风控的核心议题。IP数据云致力于通过精准的IP地理位置查询能力，帮助跨境电商平台在订单生成阶段快速识别"下单IP与收货地址不一致"的异常行为，有效拦截虚假地址订单，降低物流妥投失败率与售后纠纷成本。
一、IP查询的核心判断逻辑
通过比对下单IP的地理位置与收货地址，建立三层校验机制：
国家层：
IP归属国家与收货地址不一致，直接拦截。拦截90%跨国代下单欺诈。
城市层：
IP定位城市与收货城市距离超过500公里，触发二次验证。适用于欧美地区，避免误杀正常跨州购物。ISP层：
IP类型为数据中心、代理或VPN，标记高风险，延迟发货。
关键字段：
国家代码、省/州、城市、经纬度、ISP类型、代理标签。
二、实操方案：三种落地场景
场景一：实时订单风控
在订单提交接口嵌入IP查询，IP数据云等服务商可提供毫秒级响应的API：

用户提交订单 → 提取下单IP → 调用IP查询API
                    ↓
            获取IP地理位置（ lat, lon, country, city ）
                    ↓
            计算与收货地址距离
                    ↓
            距离 > 阈值？ → 是：进入审核队列 / 否：正常流转

阈值建议：
欧美发达国家：同城（<50km）为正常，跨省（>300km）需验证
新兴市场（东南亚、拉美）：同国家即可放行，跨国必审
场景二：批量订单复盘
对历史订单进行离线分析，识别欺诈模式：

-- 示例：统计同一IP关联的不同国家地址数
SELECT ip, COUNT(DISTINCT shipping_country) as country_cnt
FROM orders
WHERE order_date > '2024-01-01'
GROUP BY ip
HAVING country_cnt > 3;

输出价值：发现专业代下单团伙的IP特征，更新黑名单。

场景三：物流预警联动

在包裹出库前进行二次校验：
若IP查询显示用户近期登录位置与收货地址国家不一致，推送App通知确认妥投前24小时，若快递员GPS轨迹与地址偏差过大，自动触发地址复核
三、技术落地的边界条件
IP查询并非万能，需注意以下限制：

建议采用"IP查询+设备指纹+支付风控"多维度交叉，单一维度不直接拒单。
四、总结：跨境物流IP风控实施路径
接入层（Week 1-2）：嵌入IP查询API，校验时延<100ms
规则层（Week 3-4）：设定三级阈值，拦截70%异常订单
数据层（Month 2）：构建风险评分模型，误杀率<3%
协同层（Month 3）：联动支付风控、物流轨迹，物流失败率下降50%
虚假地址识别是跨境物流降本的关键环节。通过IP地理位置查询技术，平台可在订单源头建立防御，避免包裹跨境空转的损失。IP数据云持续优化全球IP地理位置数据库的精准度与覆盖度，提供稳定高效的IP查询服务，助力跨境电商企业构建"下单即校验、异常即拦截"的智能风控体系，提升物流履约效率与用户体验。

近两年，关于“AI 取代人类”的焦虑像病毒一样蔓延。媒体在狂欢，资本在沸腾，打工人在恐慌。

然而，当我们撕开这层科幻滤镜，审视当下的全球经济与科技生态时，会发现一个残酷的真相：AI 对就业、创新和知识生态的破坏，远比简单的“机器人抢饭碗”要复杂、隐秘得多。

这不仅是一场技术的演进，更是一场由资本裹挟、大厂主导的“效率剥削”与“知识收割”。

一、 裁员的“背锅侠”：资本狂欢与打工人的祭典

理论上，AI 确实能替代客服、基础编程等重复性劳动，但“任务被替代”绝不等于“岗位直接消失”。很多企业在引入 AI 时，受制于成本、合规和组织惯性，其真实落地效果远没有财报里吹嘘得那么夸张。

那为什么大厂还在疯狂裁员？

真相是，在全球经济疲软、物价高企的后疫情时代，企业为了追求利润率和维持高昂的股价，必须在账面上做文章。在美国，AI 被提升至国家战略高度，巨头们如果不把成百上千亿的资金砸向 GPU 和大模型，股价就会崩盘。为了填补这个巨大的资金窟窿，“裁员降本”成了最快见效的手段。AI，不过是资本家举起裁员屠刀时，一块最完美、最体面的“遮羞布”。

最讽刺的是，每次大厂宣布裁员并将资源转向 AI 后，股价往往应声大涨。这折射出资本市场的冷血：资本的狂欢建立在劳动者生计受损之上。

【笔者观点：不要把“经济寒冬”误认为是“AI 寒冬”】
我们必须警惕一种叙事陷阱——将经济结构性衰退带来的失业，全部归咎于 AI。
无论技术多强，这个世界的消费主体依然是“人”。如果打工人因为所谓的“AI 优化”而大量失业、失去消费能力，那么企业生产出再多的产品也卖不出去。资本可以炒作概念，但无法凭空创造购买力。没有社会托底机制的 AI 狂飙，最终只会演变成少数垄断者的数字游戏，并埋下社会动荡的隐患。

二、 创作者的噩梦：大模型成了最终的“流量黑洞”

除了打工人，AI 对创新者和中小企业的反噬同样致命。

现在很多人都在用大模型（LLM）开发套壳应用或小工具，梦想着打造“一人公司（One-person company）”，实现被动收入。但这就像在巨头的地基上盖违章建筑。

掌握了无限算力和底层 API 的大厂，正在像黑洞一样吞噬一切有价值的场景。你辛辛苦苦调出来的 Prompt、跑通的业务流，一旦被证明有商业价值，大厂会在下一次模型迭代中直接将其“内置”为原生功能。你的护城河在底层模型的一次回眸前，瞬间土崩瓦解。

更可怕的是“Token 账单刺客”。有开发者只是做个中型项目，一天就烧掉了 1000 美元的 Token 费，而产品还没带来一分钱收入。AI 的使用成本是指数级增长的，大多数独立开发者最终只能在“高投入、低回报”的泥潭里挣扎。

【笔者观点：掘金热里，赚钱的永远是卖铲子的人】
所谓的“AI 赋能个人实现财务自由”，很大程度上是一场类似“割韭菜”的骗局。真正赚到钱的，是卖算力的英伟达、卖 API 的 OpenAI/大厂，以及那些教你“如何用 AI 赚钱”的卖课博主。个体开发者如果缺乏独有的核心数据或物理世界的极强触手，盲目卷入纯软件的 AI 开发，大概率只是在给巨头做免费的“市场探路员”。

三、 知识生态的崩塌：当平庸取代精妙，我们终将成为“孤岛”

如果说就业和商业的冲击是显性的，那么 AI 对知识传承的破坏则是隐秘而致命的。

回想一下，你上一次耐心读完一篇技术博客、翻阅原始文献、或者在 Stack Overflow 上为一个精妙的回答点赞，是什么时候？

在过去，互联网的繁荣建立在“开源、共享、认可”的基石上。作者写下几百篇博客、贡献上千个维基词条，哪怕没有金钱回报，“被看见和被引用”的成就感就是最大的动力。

但现在，一切变了。AI 像一个贪婪的吸血鬼，一口气爬取并消化了人类几十年积累的智慧结晶。它绕过了原作者的名字，抹除了版权，将那些独特的经验、甚至带着极客精神的“Hack 技巧”，统统打碎、揉捏，最后吐出一段段标准化、却极度平庸的答案。

这直接导致了三个可怕的后果：

1. 原创激励彻底死亡：既然写得再好也只是给 AI 免费当养料，谁还愿意分享新知识？
2. 错误被无限放大且锁死：AI 缺乏自我纠正机制。当它基于旧数据的错误得出结论，而人类又不再去溯源时，错误就会被当成真理。
3. 人类沦为知识的“孤岛”：大家都对着屏幕向一个没有感情的机器要答案，人与人之间那种因为探讨问题而产生的思维碰撞与技术交流，正在急速消亡。

【笔者观点：没有新知识注入的 AI，只是一具“数字僵尸”】
这是我最担忧的未来。大模型之所以强大，是因为它吃下了人类文明过去的辉煌。但如果 AI 的“白嫖”机制摧毁了人类创造新知识的动力，那么三年、五年后，大模型去哪里获取新的训练数据？
难道用 AI 生成的垃圾文本，再去训练下一代 AI 吗？那将是可怕的“模型坍塌（Model Collapse）”。如果不在制度和技术上建立起“版权追踪与利益反哺”机制，我们现在的每一次便捷提问，都是在透支人类知识生态的明天。

结语：拒绝沦为算法的奴隶

AI 绝不会全面消灭就业，但它确实在不可逆地重塑我们的社会结构。

在这场智械盛宴中，我们要看清资本的底牌，不要被“AI 焦虑”裹挟而乱了阵脚。作为打工人，我们需要在 AI 无法触达的领域（共情、复杂现实交互、伦理判断）建立壁垒；作为创作者，我们要保护好自己的核心数据。

最重要的是，我们不能放弃作为“人”的求知欲和交流欲。去阅读原著，去赞赏作者，去和真实的人类辩论。

AI 应该成为增强人类能力的阶梯，而不是资本用来剥削剩余价值的工具，更不能成为将我们禁锢在平庸与孤立中的数字牢笼。讽刺的是，这篇揭露 AI 弊端的文章，最终大概率也会被爬虫抓走，默默消融在下一代大模型的参数里，连一丝涟漪都不会激起。

但至少在这一刻，我们保持了清醒。

👇 欢迎关注我的公众号

在 AI 爆发的深水区，我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码，获取每周硬核技术推文：

欢迎关注【睿见新世界】！

在数字化竞争日益激烈的今天，搜索引擎优化（SEO）  是每个网站站长的必修课。我们绞尽脑汁优化关键词、提升内容质量、增加外链，却往往容易忽略一个看似基础却至关重要的细节——网站地址栏里那个不起眼的“锁” 。

那么，部署SSL证书（即开启HTTPS加密）真的能提高网站的SEO排名吗？答案是肯定的。  而且，这不仅仅是“心理作用”，更是谷歌、百度等主流搜索引擎官方承认的排名规则。

一、为什么SSL证书能助力SEO排名？

搜索引擎的核心使命是向用户推荐“安全、优质、可信”的站点。而SSL证书，正是网站安全的“第一张身份证”。

1. 搜索引擎的官方“偏爱”

早在数年前，谷歌就正式宣布将HTTPS作为排名算法的正面信号。在国内，百度也在《搜索引擎优化指南》中明确表示，会优先收录HTTPS站点，并在同等条件下，给予HTTPS页面更高的排名权重 。这意味着，如果你的网站还在使用HTTP，在起跑线上就已经落后于部署了SSL的竞争对手。

2. 降低跳出率，提升用户体验

想象一下，当你点击一个链接，浏览器地址栏却弹出红色的“不安全”警告，你的第一反应一定是关闭页面。数据显示，超过70%的用户在面对不安全警告时会选择立即离开 。部署SSL证书后，浏览器会显示一把绿色的锁，这不仅消除了用户的顾虑，增加了页面停留时间，而这些良好的用户行为数据，正是搜索引擎判断网站质量的重要指标 。

3. 防止流量劫持，保住劳动成果

HTTP协议传输的数据是明文的，很容易被黑客篡改或植入广告，这就是所谓的“流量劫持”。HTTPS加密能有效防止第三方在传输过程中篡改网页内容，确保你辛苦生产的优质内容能完整、安全地呈现在用户面前，避免排名因恶意劫持而受损。

免费SSL证书申请入口

二、如何快速部署JoySSL，抓住SEO红利？

为网站部署SSL证书并让其为SEO服务，只需三步即可轻松完成：

1. 注册与选择：访问JoySSL官网，注册账号。在证书选择页面，根据你的需求挑选“免费SSL证书”或“通配符证书”。（小贴士：注册时填写推荐码 230970 ，可免费申请通配符证书并获得专属部署指导）。
2. 验证域名所有权：按照系统提示，在你的域名管理后台添加一条TXT解析记录，或上传验证文件。这个过程通常只需几分钟。
3. 部署与强制跳转：验证通过后，下载证书文件。根据你的服务器环境（如Nginx、Apache），参照JoySSL提供的详细中文文档上传配置。关键一步：  配置完成后，务必设置301强制跳转，确保所有用户和搜索引擎都访问到HTTPS版本，避免权重分散。

大家好，我是良许。

在嵌入式 Linux 开发中，设备树（Device Tree）和内核裁剪是两个非常重要的概念。

很多刚入门的朋友可能会觉得这两个东西很抽象，不知道从何下手。

今天我就用通俗易懂的方式，给大家详细讲解一下这两个技术点，帮助大家在实际项目中更好地应用它们。

1. 设备树（Device Tree）详解

1.1 什么是设备树

设备树说白了就是一个描述硬件信息的文本文件。

在早期的 Linux 内核中，硬件信息都是直接写死在内核代码里的，这就导致每次硬件有变动，都要重新编译内核，非常麻烦。

设备树的出现就是为了解决这个问题，它把硬件信息从内核代码中剥离出来，放到一个独立的文件中进行描述。

打个比方，设备树就像是一份硬件说明书，告诉 Linux 内核："我这块板子上有哪些外设，它们的地址是多少，使用哪些引脚，工作频率是多少"等等。

内核启动时会读取这份说明书，然后根据描述去初始化相应的硬件。

1.2 设备树的基本语法

设备树文件的后缀通常是 .dts（Device Tree Source），编译后会生成 .dtb（Device Tree Blob）二进制文件供内核使用。我们来看一个简单的设备树示例：

/ {
    model = "STM32MP157C-DK2";
    compatible = "st,stm32mp157c-dk2", "st,stm32mp157";
​
    memory@c0000000 {
        device_type = "memory";
        reg = <0xc0000000 0x20000000>;
    };
​
    soc {
        compatible = "simple-bus";
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;
​
        usart3: serial@4000f000 {
            compatible = "st,stm32h7-uart";
            reg = <0x4000f000 0x400>;
            interrupts = <39>;
            clocks = <&rcc USART3>;
            status = "okay";
        };
​
        i2c1: i2c@40012000 {
            compatible = "st,stm32mp15-i2c";
            reg = <0x40012000 0x400>;
            interrupts = <31>, <32>;
            clocks = <&rcc I2C1>;
            status = "okay";
            
            eeprom@50 {
                compatible = "atmel,24c02";
                reg = <0x50>;
                pagesize = <16>;
            };
        };
    };
};

这个设备树描述了一个 STM32MP157 的板子，包含了内存信息、串口、I2C 总线以及挂在 I2C 上的 EEPROM。

每个节点都有一些属性，比如 compatible 表示兼容的驱动，reg 表示寄存器地址，interrupts 表示中断号等。

1.3 设备树在实际项目中的应用

在我之前做汽车电子项目的时候，经常需要根据不同的车型配置不同的外设。

比如高配车型有倒车影像，低配车型没有；有的车型用 CAN 通信，有的用 LIN 通信。

如果把这些都写死在内核里，那每个车型都要编译一个内核，维护起来简直是噩梦。

有了设备树之后，我们只需要为不同车型准备不同的设备树文件就可以了，内核可以共用一个。

比如高配车型的设备树里会有摄像头节点：

camera@5000 {
    compatible = "vendor,camera-v1";
    reg = <0x5000 0x1000>;
    clocks = <&clk_camera>;
    status = "okay";
};

而低配车型的设备树里，这个节点的 status 就设置为 disabled，或者干脆不写这个节点。

这样同一个内核就可以适配不同的硬件配置了。

1.4 修改设备树的注意事项

修改设备树时要特别注意几点。

第一，地址和中断号一定要和硬件原理图对应上，否则驱动根本找不到硬件。

第二，compatible 属性要和驱动代码中的匹配字符串一致，否则驱动不会被加载。

第三，修改完设备树后要重新编译生成 .dtb 文件，并且替换掉板子上的旧文件。

我记得有一次调试一个 SPI 设备，怎么都读不到数据。

折腾了半天才发现，是设备树里的片选引脚配置错了，和实际硬件接线不一致。

所以说，设备树虽然只是个文本文件，但每个参数都要仔细核对，马虎不得。

2. 内核裁剪详解

2.1 为什么要裁剪内核

Linux 内核非常庞大，包含了对各种硬件的支持、各种文件系统、网络协议栈等等。

如果把所有功能都编译进去,内核镜像可能有几十兆甚至上百兆。

对于嵌入式设备来说，存储空间是很宝贵的，而且很多功能根本用不到。

比如一个简单的数据采集设备，不需要图形界面，不需要 USB 支持，不需要蓝牙，那这些模块就完全可以去掉。

裁剪内核不仅可以减小镜像大小，还能加快启动速度，降低内存占用。

我之前做过一个项目，要求系统启动时间不能超过 3 秒。

通过精简内核，去掉不必要的驱动和功能，最终把启动时间压缩到了 2.5 秒。

2.2 内核配置系统

Linux 内核使用 Kconfig 系统来管理配置选项。

我们可以通过 make menuconfig 命令打开一个图形化的配置界面，在里面选择需要的功能。

配置完成后会生成一个 .config 文件，记录了所有的配置选项。

配置选项有三种状态：y 表示编译进内核，m 表示编译成模块，n 表示不编译。

对于嵌入式系统，我一般倾向于把必需的功能编译进内核（y），而不是编译成模块。

因为模块需要额外的存储空间，而且加载模块也需要时间。

2.3 裁剪内核的实战步骤

2.3.1 确定硬件需求

首先要明确项目的硬件配置和功能需求。

列一个清单，写明需要哪些外设，需要哪些功能。比如：

• CPU 架构：ARM Cortex-A7
• 存储：256MB DDR3，128MB NAND Flash
• 外设：UART、SPI、I2C、GPIO、以太网
• 文件系统：ext4、JFFS2
• 网络：TCP/IP、HTTP
• 不需要：USB、蓝牙、WiFi、音频、显示

2.3.2 配置内核选项

进入内核源码目录，执行配置命令：

cd linux-5.10
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

在配置界面中，我们需要关注以下几个重要的配置项：

通用设置（General setup）：

• 关闭不需要的内核特性，比如审计支持（Auditing support）
• 关闭内核调试符号（Kernel debugging symbols），可以大幅减小内核大小
• 配置内核压缩方式，推荐使用 XZ 压缩，压缩率最高

处理器类型和特性（Processor type and features）：

• 选择正确的 CPU 类型
• 配置浮点运算支持（如果 CPU 支持硬件浮点）

设备驱动（Device Drivers）：这是裁剪的重点，需要仔细选择。比如：

• 字符设备：保留串口驱动，去掉不用的字符设备
• 块设备：保留需要的存储设备驱动
• 网络设备：只保留以太网驱动，去掉 WiFi、蓝牙等
• 输入设备：如果不需要键盘鼠标，可以全部去掉
• USB 支持：如果不用 USB，整个 USB 子系统都可以关闭

文件系统（File systems）：

• 只保留需要的文件系统，比如 ext4、JFFS2、NFS
• 去掉不用的文件系统，比如 NTFS、HFS 等

网络选项（Networking support）：

• 保留 TCP/IP 协议栈
• 去掉不用的网络协议，比如 IPX、AppleTalk 等

2.3.3 编译和测试

配置完成后，保存配置并编译内核：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8 zImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs

编译完成后，把生成的 zImage 和设备树文件烧录到板子上进行测试。

如果系统能正常启动，功能都正常，那就说明裁剪成功了。

如果启动失败或者某些功能不正常，就需要回过头检查配置，把缺失的驱动或功能加回来。

2.4 裁剪内核的经验总结

在实际裁剪过程中，我总结了几点经验。

第一，不要一次性裁剪太多，要循序渐进。

先从明显不需要的功能开始裁剪，比如 USB、蓝牙、音频等。裁剪一部分就测试一次，确保系统还能正常工作。

第二，有些配置项之间有依赖关系。

比如网络功能依赖于网络设备驱动，文件系统功能依赖于块设备驱动。

如果把被依赖的功能关闭了，依赖它的功能也会失效。

Kconfig 系统会自动处理一些依赖关系，但不是所有的依赖都能自动处理，所以要特别注意。

第三，保留一些调试功能在开发阶段是有必要的。

比如串口控制台、printk 日志等。等到产品定型了，再把这些调试功能去掉，进一步精简内核。

第四，可以参考芯片厂商提供的默认配置文件。

比如 STM32MP1 系列，ST 官方提供了 stm32mp1_defconfig，这个配置文件已经针对 STM32MP1 做了优化，我们可以在这个基础上进行裁剪，会省很多事。

3. 设备树与内核裁剪的配合使用

3.1 两者的关系

设备树和内核裁剪是相辅相成的。

设备树描述了硬件有哪些设备，而内核裁剪决定了支持哪些设备。

如果设备树里描述了一个 SPI 设备，但内核里没有编译 SPI 驱动，那这个设备就无法工作。

反过来，如果内核里编译了 USB 驱动，但设备树里没有 USB 节点，那这个驱动也不会被加载。

所以在实际项目中，我们要做到设备树和内核配置的一致性。

设备树里有的设备，内核里一定要有对应的驱动；内核里编译的驱动，最好是设备树里确实有对应的设备，否则就是浪费空间。

3.2 实战案例分享

我来分享一个实际案例。

之前做一个工业控制项目，硬件平台是 STM32MP157，需要用到以太网、CAN 总线、SPI Flash、I2C 传感器。我的工作流程是这样的：

首先，根据硬件原理图编写设备树文件，描述所有的硬件设备：

&ethernet0 {
    status = "okay";
    phy-mode = "rgmii";
    phy-handle = <&phy0>;
};
​
&can1 {
    status = "okay";
    pinctrl-0 = <&can1_pins>;
};
​
&spi4 {
    status = "okay";
    flash@0 {
        compatible = "jedec,spi-nor";
        reg = <0>;
        spi-max-frequency = <50000000>;
    };
};
​
&i2c2 {
    status = "okay";
    temperature@48 {
        compatible = "ti,tmp75";
        reg = <0x48>;
    };
};

然后，配置内核，确保相关驱动都被编译进去。在 menuconfig 中：

• 网络设备驱动：选择 STMMAC 以太网驱动
• CAN 总线支持：选择 SocketCAN 和 M\_CAN 驱动
• SPI 驱动：选择 STM32 SPI 驱动
• MTD 支持：选择 SPI-NOR Flash 支持
• I2C 驱动：选择 STM32 I2C 驱动
• 硬件监控：选择 TMP75 温度传感器驱动

同时，把不需要的功能全部关闭，比如 USB、音频、显示、蓝牙等。

最终编译出来的内核镜像只有 3.2MB，相比默认配置的 8MB 减小了 60%。

系统启动后，所有外设都能正常工作，启动时间也从 5 秒缩短到了 2.8 秒。

3.3 常见问题排查

在实际开发中，经常会遇到一些问题。

比如设备树配置正确，内核也编译了驱动，但设备就是不工作。这时候可以通过以下几个步骤排查：

第一步，检查内核启动日志。

通过串口查看内核的启动信息，看看驱动有没有被加载，有没有报错。如果看到类似"failed to probe"的错误，说明驱动加载失败了。

第二步，检查设备树是否被正确加载。

可以在 Linux 系统中查看 /proc/device-tree 目录，这里面是设备树的运行时表示。如果某个节点不存在或者属性不对，说明设备树有问题。

第三步，检查驱动的匹配字符串。

驱动代码中有一个 of_device_id 结构体，里面定义了驱动支持的 compatible 字符串。

这个字符串必须和设备树中的 compatible 属性完全一致，否则驱动不会被加载。

第四步，检查硬件连接。有时候问题不在软件，而是硬件接线错了，或者硬件本身有问题。

这时候需要用示波器或者逻辑分析仪来检查信号。

4. 总结与建议

设备树和内核裁剪是嵌入式 Linux 开发中的两项基本技能。

设备树让我们能够灵活地描述硬件配置，而不用修改内核代码。

内核裁剪让我们能够根据实际需求定制内核，减小镜像大小，提高系统性能。

对于初学者，我的建议是先从阅读现有的设备树文件开始，理解各个节点和属性的含义。

然后尝试修改一些简单的配置，比如改个 GPIO 引脚，改个波特率，看看效果。

在内核裁剪方面，不要一开始就大刀阔斧地裁剪，先从关闭明显不需要的功能开始，逐步积累经验。

最后，建议大家多看芯片厂商的文档和参考设计。

比如 ST、NXP、TI 这些厂商都会提供详细的设备树示例和内核配置文件，这些都是非常好的学习资料。

多动手实践，多总结经验，慢慢就能掌握这两项技能了。

在我的嵌入式开发生涯中，设备树和内核裁剪帮我解决了无数问题，也让我对 Linux 内核有了更深入的理解。

希望今天的分享能对大家有所帮助，如果有什么问题，欢迎留言交流。

更多编程学习资源

• C 语言零基础入门电子书-2026 最新版
• STM32 零基础入门电子书-2026 最新版
• FreeRTOS 零基础入门电子书-2026 最新版
• C++ 零基础入门电子书-2026 最新版
• 51 单片机零基础入门学习路线
• AD 画板零基础入门学习路线
• C 语言零基础入门学习路线
• C++ 语言零基础入门学习路线
• ESP32 零基础入门学习路线
• FreeRTOS 零基础入门学习路线
• Linux 应用开发零基础入门学习路线
• Linux 底层开发零基础入门学习路线
• LVGL 零基础入门学习路线
• QT 零基础入门学习路线
• STM32 零基础入门学习路线

Cisco Unified Communications Manager (CallManager) 15 SU4a - 统一通信与协作

思科统一通信管理器 (CallManager)

请访问原文链接：https://sysin.org/blog/cisco-ucm-15/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

思科统一通信管理器

企业统一通信和协作

借助思科集成协作基础设施提供语音/视频通话、消息传送和移动服务，让员工随时随地使用任意设备进行协作。

思科统一通信管理器 (Unified CM) 为您提供易于扩展和管理且安全可靠的呼叫控制和会话管理解决方案。

特性和功能

✅ 统一通信

整合通信基础设施，让人员和团队能够通过思科统一通信管理器轻松通信 (sysin)。该解决方案融 IP 电话、高清视频、统一消息传送、即时消息和在线状态于一体。

✅ 增强移动性

推动工作空间转型，吸引并留住优秀人才，确保他们能够随时随地借助思科统一通信管理器工具高效工作，取得成功。该解决方案凭借丰富的功能，为移动员工和远程工作人员提供支持。

✅ 本地和全球

无论您经营的是区域性家族企业，还是全球知名企业，都需要选择一个能随组织需求的变化而不断扩展的解决方案。思科统一通信管理器不仅能满足中小企业的需求，也能为拥有多达 8 万名用户的大型企业提供支持。

✅ 开放且互通

Cisco Unified (CM) 支持行业标准，拥有丰富的网关产品，并建立由第三方集成和解决方案以及合作伙伴构成的庞大生态系统。从而帮助您随时随地以多种方式与任何人进行协作，并将协作功能嵌入业务部门的各种应用中。

✅ 安全且合规

Cisco Unified (CM) 支持最新身份验证、加密和通信协议 (sysin)。该解决方案通过了关键行业认证，可面向全球的金融服务业、制造业、零售业和政府部门客户提供数据和通信保护。

下载地址

Unified Communications Manager (CallManager) Version 15 File Information

Unified Communications Manager Version 15 Release 15SU4a

✅ Prime Collaboration Deployment Updates - 15SU4

Release 15SU4

• Download Product

✅ Recovery Software - 15

• Download Product

✅ Unified Communications Manager Updates - 15SU4a

Release 15SU4a

• Download Product

✅ Unified Communications Manager Utilities - COP-Files - 15SU4

Release COP-Files

• Download Product

✅ Unified Communications Manager Virtual Machine Templates - 15

Release 15

• Download Product

✅ Unified Communications Manager/CallManager Device Packages - 15.0(1.15027)

Release 15.0(1.15027)

• Download Product

Unified Communications Manager 15 Download

• 请访问：https://sysin.org/blog/cisco-ucm-15/

Unified Communications Manager 15SU1 28-Mar-2024

Unified Communications Manager 15SU2 01-Oct-2024

Unified Communications Manager 15SU3 31-Jul-2025

Unified Communications Manager 15SU4 04-Jan-2025

Unified Communications Manager 15SU4a 04-Feb-2026

更多：Cisco 产品下载链接汇总

2025 年，我们经历了“Agent（智能体）元年”的狂欢。无数科技公司向我们展示了各种花哨的 Demo：AI 管家帮你订机票、买股票，甚至替你谈恋爱。但当烟花散去，残酷的现实浮出水面——真正被普通人和企业高频使用的“可用 AI”，屈指可数。

在近日举行的 OceanBase 社区嘉年华圆桌论坛上，多位奋战在 AI 一线的大厂产品负责人与核心开发者，撕开了这层科幻滤镜。他们达成了一个极度务实的共识：当下最能打的 AI，绝对不是无所不能的“全能神”，而是像 OpenClaw（原 Clawdbot）这样，在特定领域死磕高频、重复任务的“超级工具人”。

这场讨论传递出一个明确的信号：AI 的下半场，已经从“拼大模型跑分”转向了“拼系统工程与交互设计”。

一、 形态共识：能落地的不是“万能药”，而是“打工人”

在探讨什么才是真正能用的 AI 时，专家们不约而同地指向了同一个方向：AI 编程助手（如 Claude Code、OpenClaw）。

为什么是编程？因为代码世界有着最明确的规则和验证闭环。以自动填写 CRM 表单或处理 GitHub Issue 为例，Agent 的核心价值并非展现惊人的创造力，而是不知疲倦地完成枯燥、易错的机械劳动。

更关键的是，企业对 AI 有着极其苛刻的“透明化”要求。如果 AI 改了数据库，企业必须一眼看穿它改了哪里、怎么改的。因此，“可用 AI”必须具备两个特征：

1. 可感知：用户知道 AI 的行为边界在哪。
2. 可核实：用户能瞬间验证结果的正确性。

【笔者观点：不要试图创造一个“爹”，请雇佣一个“执行者”】
目前市面上很多 AI 产品的通病，是试图扮演用户的“爹”——试图替用户做所有决策（比如直接帮你买股票）。但这违背了商业社会的常理，因为没人愿意为不可控的结果买单。
真正能变现的 AI，必须是一个卑微且透明的执行者。就像 OpenClaw 一样，人类下发验收文档，它在后台默默写代码、跑测试，出了错人类随时可以叫停。谁能把“信任感”做到极致，谁就能拿到企业级市场的入场券。

二、 人机博弈：人类是该“撒手不管”，还是“死死盯住”？

“我一键下达指令，然后就可以去喝咖啡了。”这是无数打工人的梦想，但这真的现实吗？

专家们指出，这取决于场景。在任务导向型（如写代码、修 Bug）的工作中，我们的终极目标确实是“最小化人工介入”。但在情感陪伴、创意探讨等场景中，人类的存在感不仅不能弱化，反而要进一步增强。

事实上，为了让 AI 顺利完成任务，人类必须在“系统上游”投入更多的精力——即“上下文工程（Context Engineering）”。你需要反复澄清需求、指定数据源、设定边界。只有当上下文足够完美时，你才能放心“撒手”。

有意思的是，蚂蚁百灵大模型的产品负责人边思康提到：“如果有人问 AI‘帮我买明天涨停的股票’，那是人类提问水平太差。真正的智能，是 AI 反问你的风险偏好和投资周期，从而引导你提出一个好问题。”

【笔者观点：“提问的艺术”将成为职场的分水岭】
我们正在经历一场工作流的倒置。过去，老板提出模糊的需求，员工去猜、去细化、去执行。现在，AI 成了那个“不会猜心思”的直男员工。
这意味着，未来职场里最值钱的能力，不再是“解决问题”的能力（因为 AI 解决得比你快），而是“定义问题”和“投喂精准上下文”的能力。你越能精准描述边界，AI 的产出就越完美；相反，满嘴“帮我随便搞搞”的人，在 AI 时代将被彻底淘汰。

三、 门槛假象：操作变简单了，但“智商税”变高了

一个广受争议的话题是：AI 的门槛到底是在变高还是变低？甚至有人鼓吹“人人都要学点编程才能用好 AI”。

实际上，交互门槛正在肉眼可见地断崖式下降。从最初复杂的提示词工程，到现在只需语音沟通，甚至未来只需一个眼神或点击（GUI 化、意图化），人机操作的物理成本将趋近于零。

但正如与会专家所言：这一次的创新逻辑变了。移动互联网时代是“先有程序员开发，再有创作者产生内容”；而 AI 时代是“先有创作者用自然语言造出产品原型，再去倒逼工程实现”。

既然连写代码都能被 AI 替代，那么懂不懂编程已经不重要了。真正的门槛，转移到了你的“洞察力”上。

【笔者观点：这其实是对人类“软实力”的一次残酷摸底】
很多人觉得 AI 时代自己要失业了，其实不然，这是一个极其公平的时代。
AI 剥离了专业技能（如画图、写代码、做报表）的壁垒，让所有人站在了同一起跑线上。这本质上是对人类逻辑思维、业务洞察力和清晰表达能力的终极考试。如果你觉得现在用不好 AI，那大概率不是技术不到位，而是你在上一个时代就没有建立起严密的逻辑体系。

结语：面向 Agent 重构基础设施

这场圆桌论坛揭示了一个更加宏大的未来：互联网的基础设施正在悄然生变。

当 AI 工具从“辅助人”进化为“独立解决问题的智能体”时，现在的网页、APP 甚至操作界面，对 Agent 来说都显得极其臃肿。未来的互联网接口，将是专门为 Agent 提供结构化数据的 API，甚至会出现 Agent 与 Agent 之间专用的“加密通信语言”。

正如 OpenClaw 带来的启示：它不是底层模型的狂欢，而是产品定位的胜利。在这个正在到来的“可用 AI”时代，最先吃到红利的，绝不是那些天天在实验室刷榜刷参数的极客，而是那些真正理解真实业务痛点，并能为 AI 员工打造出最趁手工具箱的“包工头”。

👇 欢迎关注我的公众号

在 AI 爆发的深水区，我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码，获取每周硬核技术推文：

欢迎关注【睿见新世界】！