包含关键字 typecho 的文章

大家好,我是R哥。

Claude Code 的创始人在他的社交媒体上分享了来自 Claude Code 团队官方的使用的 10 个小技巧,赶紧来学习,Get 新技能。

1、多开并行干活,效率翻倍

同时开 3–5 个独立的代码目录(用 git worktree 最方便),每个目录里跑一个独立的 Claude 会话。

一个修 bug、一个写新功能、一个看日志分析问题……彻底不等了。

2、复杂需求先写计划,别直接让它 coding

先让 Claude 出详细计划(Plan Mode),你多花时间改计划,直到靠谱了再让它一次性实现。

一个 Claude 写计划 , 另一个 Claude 当资深工程师审计划, 一旦跑偏,立刻回到计划阶段重来,别硬推。

3、建一个 CLAUDE.md,当成团队知识库

每次 Claude 犯错,就立刻说:把这个错误记到 CLAUDE.md 里,以后别再犯了。

Claude 特别擅长给自己写规则,持续迭代这份文件,出错率会明显下降。

4、重复的事就封装成 Skill 或斜杠命令,用 Git 管理

一天干超过一次的操作,就做成 skill 或 /xxx 命令,提交到 git。

例如 /techdebt(扫描重复代码)、一键拉 7 天 Slack+GitHub 上下文、自动写测试等。

5、Bug 直接丢给它修,别手把手教

把 Slack bug 讨论直接丢给它,说 fix 就行,或者 “Go fix the failing CI tests”。

分布式系统出问题,直接给 docker logs 让它排查。

开启 Slack MCP 后效果更强。

6、Prompt 写得越高级越好,逼它出好代码

  • 让它当考官:Grill me on these changes,不通过别提 PR
  • 修复一般就说:Knowing everything you know now, scrap this and implement the elegant solution
  • 写超详细 spec 减少歧义
  • 让它对比 main 和 feature 分支,证明改动真的有效

7、选择好的终端工具

团队最爱 Ghostty。

用 /statusline 自定义状态栏显示上下文用量和 branch。

给终端 tab 配色+命名(一个任务一个 tab)。

强烈推荐语音输入(macOS fn 连按两下),说话比打字快 3 倍,prompt 也能写得更细。

8、善用 Subagents(子代理)

复杂任务后面加一句 “use subagents”,让 Claude 投入更多算力。

把独立小任务外包给 subagent,保持主上下文干净。

还可以设置 hook 把权限请求路由给 Opus 4.5 自动审批安全操作。

9、数据分析直接交给 Claude

让它用 bq CLI 现场跑 BigQuery 查询,拉数据分析。

团队有个共享 BigQuery skill,人人复用。

任何带 CLI/MCP/API 的数据库都能这么玩。

10、把 Claude 当老师

打开 explanatory/learning 模式,让它解释为什么这么改

让它生成 HTML 幻灯片讲解陌生代码

让它画 ASCII 图解释架构

建间隔重复学习:你讲理解 → 它追问补漏 → 存下来复习

最后,使用 Claude Code 没有唯一标准答案,每个人的配置与使用场景都各有差异,要多去尝试,摸索出最适合自己的方式。

闲暇之余,用了点小心思开发了一款搭建玄学主题的智能体平台。主要面向命理从业或学习人员,如果你有自己的知识体系,有自己的思想框架,不妨试试用命网来搭建您的智能体。

命网( Fatamesh )是融合东方哲学与前沿 AI 的智能体平台。它不仅是助手,更是您的“身外化身”——具备长期记忆,通过 MCP 协议连接万物,并支持您构建与分享专属的领域专家。

网站地址

https://deerblock.top/

需要使用邮箱注册哦,国内用户没有梯子的话使用谷歌授权会失败哦。

怎么搭?

不同于 coze 等平台,我们尽量提供简单的方式来创建您的智能体(平台中我们称为灵犀),整体流程如下:

对话示例 → 生成人设 → 绑定神通和知识库 → 生成灵犀

然后你就可以愉快的和你的智能体进行对话啦。

用来做什么?

平台提供了八字、紫薇斗数、星盘、大六壬人、塔罗的 MCP 服务(可以理解为智能体调用工具),利用这些服务,智能体能准确客观地进行排盘、测算,不会受幻觉影响。

对于命理师而言

  • 你可以将它作为自己从业时的工具参考,或做一些自动化的报告产出。
  • 你还可以通过分享智能体给客户来完成预咨询,给客户不一样的体验。
  • 还允许将你的智能体以 api 的形式给第三方调用,可以集成到你的其他任意应用中去。

注意事项

  • 如果你打算将您的智能体分享给客户,注意先在个人资料中完善你的信息哦,分享出去智能体在提供咨询服务单次对话达到 10 次会展示您的个人资料哦。

  • 网站有付费机制,新人有一些免费额度,如果不够用,可以用建议换额度(个人资金有限😁,需要额度向我明确说明哦)

大模型用得越多,越容易陷入一种混乱状态

  • 这个项目用 OpenAI
  • 那个服务接 Dashscope(Qwen)
  • 测试环境还跑着本地 vLLM 或 Ollama
  • 电脑里配置着一堆 API Key

刚开始问题不大,大家还能靠“记得住”来维持。
但只要项目一多、人数一多,麻烦立刻显现出来:

费用开始失控、模型切换成本极高、权限越来越乱、出了问题也很难排查。

于是,越来越多团队开始引入一个概念:
大模型网关(LLM Gateway)

在目前的开源方案里,LiteLLM 是非常实用、也非常容易真正落地的一种。

我们按下面这条路线,一步步把它跑起来:

为什么要用 → Docker Compose 部署 → 模型与 Key 管理 → 权限与预算 → 实际调用 → 真实使用场景

一、LiteLLM 是什么?它解决的不是“能不能用”,而是“怎么管”

先说清楚一件事:
LiteLLM 本身不是模型。

它更像是一个统一的大模型代理层,或者你也可以理解为:

所有大模型的 统一入口 + 管理中枢

对外,它暴露的是 OpenAI 兼容 API
对内,它可以接入各种不同来源的大模型,包括:

  • OpenAI / Azure OpenAI
  • Anthropic / Gemini / Dashscope
  • HuggingFace
  • 本地 vLLM、Ollama
  • 甚至多家模型同时存在

最终的效果是:

应用侧只需要认一个地址、一个 Virtual Key。
至于后面到底用的是哪家模型、怎么调度、怎么限额,全部交给 LiteLLM 处理。


二、Docker Compose 部署(生产环境强烈推荐)

如果只是本地玩一玩,直接起一个 Docker 容器也可以。
但只要你是长期使用或多人使用Docker Compose 是最稳妥的方式

它有几个明显好处:

  • 部署结构清晰
  • 配置可复现
  • 后期升级、迁移成本低

1️⃣ 准备目录结构

litellm/
├── docker-compose.yml
└── .env

保持简洁,后面所有东西都围绕这两个文件来。


2️⃣ 编写 docker-compose.yml

services:
  litellm:
    build:
      context: .
      args:
        target: runtime
    image: docker.litellm.ai/berriai/litellm:main-stable
    #########################################
    # Uncomment these lines to start proxy with a config.yaml file #
    # volumes:
    #  - ./config.yaml:/app/config.yaml
    # command:
    #  - "--config=/app/config.yaml"
    ##############################################
    ports:
      - "4000:4000"
    environment:
      DATABASE_URL: "postgresql://llmproxy:dbpassword9090@db:5432/litellm"
      STORE_MODEL_IN_DB: "True"
    env_file:
      - .env
    depends_on:
      - db
    healthcheck:
      test:
        - CMD-SHELL
        - python3 -c "import urllib.request; urllib.request.urlopen('http://localhost:4000/health/liveliness')"
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  db:
    image: postgres:16
    restart: always
    container_name: litellm_db
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: llmproxy
      POSTGRES_PASSWORD: dbpassword9090
    ports:
      - "5432:5432"
    volumes:
      - /home/data/litellm/postgres/data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d litellm -U llmproxy"]
      interval: 1s
      timeout: 5s
      retries: 10
提醒一句:
记得把 db 的 volumes 路径改成您自己机器上的真实路径。

3️⃣ 环境变量 .env

LITELLM_MASTER_KEY=sk-1234
STORE_MODEL_IN_DB=True

这里的 LITELLM_MASTER_KEY,就是后面登录后台用的密码


4️⃣ 启动服务

docker compose -p litellm up -d

5️⃣ 访问管理界面

浏览器打开:

http://localhost:4000

PixPin_2026-02-27_18-10-17.png

  • 用户名:admin
  • 密码:.env 里配置的 LITELLM_MASTER_KEY

三、如何管理模型?从 Virtual Key 开始

LiteLLM 的核心设计之一,就是用 Virtual Key 来统一管理、隔离使用者和模型资源


1️⃣ 添加模型(以 Ollama 为例)

Models + Endpoints 页面中,选择 Add Model

PixPin_2026-02-27_18-16-48.png


2️⃣ 创建 Virtual Key

  • Key 的拥有者可以是你自己、某个服务账号,或者具体成员
  • 可以绑定一个或多个模型
  • 可以设置预算、速率限制

注意:生成的 Key 只显示一次,一定要保存好。

PixPin_2026-02-27_18-23-29.png


3️⃣ 在线验证是否可用

  • 粘贴刚创建的 Virtual Key
  • 选择允许使用的模型
  • 直接测试请求

PixPin_2026-02-27_18-31-30.png


四、权限管理(多人协作非常重要)

当开始多人使用时,这一部分非常关键。


创建团队(Team)

用于统一管理成员和资源。

PixPin_2026-02-27_18-41-57.png


邀请内部用户(Internal User)

PixPin_2026-02-27_18-43-43.png


访问组(Access Groups)

通过访问组来控制:
谁能用哪些模型、哪些 Key。

PixPin_2026-02-27_18-45-49.png


预算管理(Budgets)

如果你接的是收费模型,这一步非常有用。

PixPin_2026-02-27_18-47-02.png


五、可观测性:终于知道钱花哪了

请求消耗统计

PixPin_2026-02-27_18-49-26.png

请求日志

PixPin_2026-02-27_18-49-58.png


六、应用如何调用?几乎不用改代码

Python 示例

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    name="ollama",
    model="qwen3:8b",
    base_url="http://192.168.31.242:4000",
    api_key="sk-Rj-rnKC9lgaohyI7bxKVkg"
)

response = llm.invoke("你是谁?")
print(response)

核心只有三点:

  • 地址指向 LiteLLM
  • Key 使用你创建的 Virtual Key
  • 模型名来自你在后台定义的模型

PixPin_2026-02-27_18-55-57.png


七、真实使用场景

场景一:公司级 AI 中台

  • 前端、后端、脚本工具
  • 全部只接一个 Gateway
  • 模型升级对业务透明

场景二:多项目成本可控

  • 每个项目一个 Key
  • 超额直接拒绝
  • 成本一眼就能看清

场景三:模型策略随时调整

今天 GPT-4
明天 Gemini
后天本地模型

只改配置,不动业务代码。


写在最后

很多人刚接触大模型时,最关心的是效果
真正用久了才发现,最难的是管理、成本和稳定性

LiteLLM 并不会让模型变聪明,
但它能让你:

  • 用得更稳
  • 管得更清楚
  • 换得更从容

如果你已经不满足“能跑就行”,
那这个网关,确实值得你认真搭一套。

引言

低代码开发与代码开发共存已成为企业数字化转型中的常态。作为一种长期发展的技术路径,低代码平台将常用功能封装为可视化组件,使开发者能够更专注于业务逻辑与页面设计,从而在提升效率的同时保持开发的灵活性。

众所周知,低代码平台能显著提升开发效率、加速项目交付并支持快速迭代。这主要得益于两大优势:一是直观的可视化界面和拖拉拽的开发方式;二是丰富的预置组件与前后端命令,这些功能大多通过插件形式提供,开箱即用。本文将结合活字格平台,深入探讨如何借助其丰富的插件生态构建实际应用。

一、百度地图集成:从定位到业务应用

在燃气配送、广告业务线下拓客、考勤打卡等场景中,地理位置信息至关重要。例如:

  • 燃气配送:登记客户地址并定位,方便配送员规划路线和导航
  • 广告拓客:业务员扫街时记录客户位置,形成线索。

借助活字格的百度地图插件(百度地图 - 葡萄城市场),可轻松实现坐标获取。
在这里插入图片描述

获取经纬度后,可通过逆地理编码接口转换为详细地址,并通过活字格的 JS API 回填到页面:

var myGeo = new BMapGL.Geocoder();
myGeo.getLocation(new BMapGL.Point(Forguncy.CommandHelper.getVariableValue("经度"), Forguncy.CommandHelper.getVariableValue("纬度")), function (result) {
    if (result) {
        Forguncy.Page.getCell("LOCATION").setValue(result.address)
    }
});

此外,系统可支持“一键导航”功能,调用百度/高德地图等本地导航软件,进一步提升业务便捷性。

注意:在配送员掉起本地高德导航时,可通过坐标转换接口将BD09百度坐标系转换为高德GCJ-02火星坐标系经纬度。

var baidu = [Forguncy.Page.getCell("baidu_lng").getValue(), 
                Forguncy.Page.getCell("baidu_lat").getValue()]; 
//var baidu = [116.4798674287,39.9989020876]

AMap.convertFrom(baidu, "baidu", function (status, result) {
  //status:complete 表示查询成功,no_data 为查询无结果,error 代表查询错误
  //查询成功时,result.locations 即为转换后的高德坐标系
  if (status === "complete" && result.info === "ok") {
    let lng = result.locations[0].lng;
    let lat = result.locations[0].lat;
  }
});

二、基于位置的数据筛选:附近客户查询

在拓客过程中,业务员常需要查看附近的已有客户。此时,可将客户经纬度存入数据库,并利用 Haversine 公式计算距离。以下为 MySQL 中的实现示例:

SELECT
    `ID`,
    `Name`,
    `lng`,
    `lat`,
    -- 计算当前位置与客户位置的球面距离(单位:米)
    6371000 * 2 * ASIN(
        SQRT(
            SIN(RADIANS((lat - @lat)/2)) * SIN(RADIANS((lat - @lat)/2)) +
            COS(RADIANS(@lat)) * COS(RADIANS(lat)) *
            SIN(RADIANS((lng - @lng)/2)) * SIN(RADIANS((lng - @lng)/2))
        )
    ) AS distance_m
FROM `ad_customers_info`
-- 筛选距离≤radius半径的客户
HAVING distance_m <= @radius
-- 按距离由近到远排序
ORDER BY distance_m ASC;

在活字格中,可通过“执行 SQL 命令”(内置)与“JSON 数据导入表格”(JSON数据源 - 葡萄城市场)功能,快速实现附近客户的查询与展示。

三、HTTP 请求集成:对接海康云眸视频流

低代码平台常需与第三方系统集成,活字格的发送 HTTP 请求命令为此提供了强大支持。例如,对接海康云眸 API 获取直播流地址:

  • 接口:GET /api/yunmou/video
  • 参数:deviceSerial(设备序列号)、channelNo(通道号)
  • 返回:包含视频流地址的 JSON 对象

获取地址后,可通过HTML自定义集成插件(HTML自定义集成 - 葡萄城市场)嵌入视频播放页面,实现监控视频的实时展示。

四、MQTT 实时数据:物联网设备监控

在工业物联网场景中,常需接收设备上报的实时数据(如温度、压力)。通过活字格的 MQTT 客户端插件(MQTT客户端 - 葡萄城市场),可轻松连接 MQTT 服务器并订阅主题:

  1. 配置连接信息并订阅主题;

在这里插入图片描述

2.在消息回调中处理数据,如保存到数据表,前端表格定时刷新展示。
在这里插入图片描述

五、插件生态:开箱即用的扩展能力

葡萄城市场(葡萄城市场 - 连接合作伙伴、企业用户与个人开发者)上提供了数百个官方与社区格友开发的插件,涵盖地图、图表、数据处理、软硬件集成等各类场景,大大降低了复杂功能的实现门槛。

结语

低代码不是对传统开发的替代,而是与之互补的增效路径。通过组件化、可视化的方式,它让重复性工作得以沉淀,使开发者能更聚焦于业务创新与用户体验。而像活字格这样拥有丰富插件生态的平台,正成为企业实现快速数字化的重要推手。

未来,随着更多插件与集成能力的涌现,低代码将在业务系统中扮演更加核心的角色,支撑企业灵活、高效地应对变化。

不知道为啥,壁纸和头像用了一周以上就想换了,在心情好或坏的时候尤其强烈,大家会这样吗?sobbing

春节期间搞了一个项目 HappyClaw ,可以理解为是 Happy 和 OpenClaw 功能的缝合体,来 v 站 ug 一下

开源地址: https://github.com/riba2534/happyclaw

  • OpenClaw 缺点我觉得是只有 IM 渠道只能做一些简单的事情,场景更加偏向玩而不是工作,不太方便,且架构太复杂不太可控
  • happy 我觉得它更新太慢了,bug 多,功能少。

HappyClaw 核心原则是:不重新实现 Agent 能力,直接复用 Claude Code 。底层调用的是完整的 Claude Code CLI 运行时。Claude Code 的每次升级,HappyClaw 零适配自动受益。

  • 平台支持 IM (飞书/Telegram) / PC WEB 端 / 移动端 PWA WebAPP
  • 不同工作区隔离不同任务,宿主机/Docker 隔离,支持 WebShell
  • 底层 Agent 直接用的 Claude Code (支持官方订阅,第三方 API)
  • 支持记忆系统,定时任务,Skills 控制
  • 支持多用户
  • 随时随地使用 Agent

更多细节请看项目 README

截图:

写下这篇长文,一方面是为了给各位 V 友排雷,提醒大家面对重大手术时一定要多看几家医院、多听专家的交叉诊断;另一方面也是站在人生的分岔路口,向大家求助下一步的手术方案。( AI 润色过的)

🏥 就医与被坑的过程

1. 仓促的手术:
年前有段时间眼睛一直有闪光感,周末去挂了个号(当时挂的主治医师,出院报告上写的却是住院医师)。查完说是“视网膜脱离”需要尽快做外路手术,考虑了一晚就做了。噩梦从此开始。

2. 充满疑点的术后复查:

  • 第一次复查: 换了个主治医师,说是视网膜有些变性,手术没啥问题。
  • 第二次复查: 流程极其混乱。主治医师看了眼检查报告,就以“下午要做激光”为由,把我推给了主任医师(也就是我的主刀医生,团队负责人)。我问是不是手术有问题,主任说:“没啥问题,就是有点积液,会慢慢吸收。”让我年前回家前再来查一次。
  • 第三次复查: 主治医师看完再次直接把我领给主任(这种频繁转手让我直觉极其不对劲)。主任说:“手术口子封住了,但还有积液,打气也能解决。”让我初八上班后再来复查。此时我疑心大起,为什么这么急着让我一上班就来?

3. 忽悠我做“内路大手术”:
年后来复查,我直接问了两个问题:
我:“手术没问题吧?” 答:“没问题。”
我:“还有积液吗?” 答:“基本没有了。”
结果做完眼底彩照,主任画风一转,说有“玻璃体强牵拉”。给了两个方案:一是保守打激光打气,二是做内路手术(需要切除玻璃体,创伤极大)。主任倾向让我做内路。我不太愿意我说打激光定期复查行不行,他又把我推给主治医生打激光,主治医生说面积大涉及黄斑,打激光危险,还是让我做内路。从始至终主任都没提手术没把视网膜贴住

4. 找广州专家交叉验证:
整个人都不好了,直觉告诉我他们在掩盖什么。直接找黄牛买了广州中山眼科吕林教授(全国顶尖大拿)的号。
吕教授根据助理的初步诊断的结果用裂隙灯查了一下,直接推翻了深圳的结论:“强牵拉只是次要原因,根本原因就是视网膜都没贴好,还在漏水!” 吕教授表示,外路手术确实有失败率,建议我“再做一次外路手术试试”(保住了我不做破坏性极大的内路手术)。

5. 再次验证:
机缘巧合下,得知吕林教授的得意门生李永浩医生跳槽到了深圳出诊,第二天刚好有号。
李医生初诊确认口子看似封住了,但怀疑有小裂孔。他说:“术前肯定给你做了三面镜检查了” 我回想后确认绝对没做。
随后李医生给我做了“三面镜检查”(这是查微小裂孔的黄金标准,之前医生竟然全流程省了!),确诊:确实没封好,还在漏水,必须进行二次外路手术修补。


💡 避雷与血泪经验总结

  1. 医德比医术更重要(严重避雷深圳某医院主任医师马卉、主治医生蔡纯):
    手术没做好、有失败率,这些作为患者我都能接受。但为了掩盖外路手术没做好的事实,以“强牵拉”为由,忽悠患者去做创伤极大、极其伤元气的“内路玻切手术”,这绝对是违背医德的底线!连专家的徒弟听完都诧异:“外路手术没问题,为啥还要做内路?”
  2. 警惕不规范的检查流程:
    主治医师做眼底照相不散瞳,极其重要的三面镜排查也不做
  3. 遇到大病,花钱买时间/信息绝对值得:
    中山眼科的号虽然难抢,但黄牛能解决。面对要在器官上动刀子的事,一定要拿着 A 医院的报告去 B 医院找顶级专家交叉验证! 专家的视野和普通医生完全不在一个维度。


🙏 求助社区:二次修补手术在哪里做?

目前已经确诊需要做“二次外路修补手术”,这项手术比第一次难度更大(有疤痕和粘连),现在极其纠结,求懂行的 V 友给点建议:

  1. 留在深圳/广州做(找李永浩医生): 最方便,下周就能安排手术。李医生是吕林的徒弟,履历很强。顾虑: 在深圳被坑出了心理阴影,万一这次修补又没做好,大概率就只能做内路了。有 V 友熟悉李永浩医生的手术水平吗?或者深圳还有其他稳妥的专家推荐吗?广州做的话肯定手术没的说,但是手术排期太久了,特需的也要三周以上并且要完全自费
  2. 回老家郑州做(比如郑大一附院): 家人都在老家,能提供最好的术后照顾。顾虑: 跨省折腾,不清楚郑州眼底外科的水平,不知道手术好不好约、选哪个大夫做最稳妥。
  3. 关于检查项的查漏补缺: 目前术前术后做过眼底照相,术前做过 B 超和 OCT ,这次加做了三面镜。请问术前还需要做什么特殊检查来确保万无一失吗?

📄 附录:广州中山眼科及深圳门诊病历

深圳门诊病历

广州门诊病历

万分感谢大家!祝大家的身体都健健康康!

在当今网络安全环境下,SSL证书已成为网站运营的标配。它不仅加密用户与服务器之间的数据传输,还能提升搜索引擎排名和用户信任度。然而,许多站长面对高昂的证书费用望而却步。本文将详细介绍如何通过JoySSL申请免费一年期SSL证书,让您的网站安全升级零成本。

为什么选择JoySSL

JoySSL作为国内自主品牌的SSL证书提供商,目前持续提供免费一年期SSL证书服务,包括单域名、多域名甚至通配符证书等多种选择。与短期免费证书不同,JoySSL的一年期证书减少了频繁续期的麻烦,特别适合个人网站、中小企业及教育机构使用。

申请前的准备工作

在开始申请之前,请确保您已准备好以下条件:

  • 一个已经备案的域名(部分证书类型对教育或政务域名有特殊优惠)
  • 域名的管理权限(用于验证域名所有权)
  • 基本的服务器管理权限(用于部署证书)

详细申请步骤

免费证书申请入口

第一步:注册JoySSL账号

访问JoySSL官方网站,点击右上角的“注册”按钮创建新账号。关键步骤:在注册页面填写特定的邀请码230970,这是解锁免费一年期证书申请权限的必要条件。请务必正确填写,否则可能无法看到免费证书选项。

第二步:选择并申请证书

登录账号后,在证书产品页面找到“免费体验版”或“免费一年期”证书选项。根据您的需求选择合适的证书类型:

  • 单域名证书:保护一个域名
  • 通配符证书:保护主域名及所有子域名,适合有多个子站点的用户

点击“立即申请”或“0元购买”(支付仅为流程,实际免费),进入订单填写页面。

第三步:填写申请信息并验证域名

按照页面提示填写域名信息、联系人资料等。JoySSL支持多种域名验证方式:

  • DNS验证:在域名解析管理后台添加指定的TXT记录
  • 文件验证:将验证文件上传至网站根目录

选择最适合您的方式完成验证。验证通过后,通常10分钟内即可签发证书

第四步:下载并部署证书

证书签发后,登录JoySSL后台下载证书文件包。压缩包内包含适用于不同服务器环境(Nginx、Apache、IIS等)的证书文件和详细的安装指南。根据您的服务器环境选择对应的配置方式,将证书文件上传至服务器并修改网站配置文件,重启Web服务使配置生效。

第五步:测试HTTPS访问

部署完成后,使用浏览器访问您的网站,检查地址栏是否显示绿色的安全锁图标和HTTPS前缀。您也可以使用在线SSL检测工具,确保证书配置正确且获得较高安全评级。

注意事项与后续维护

免费一年期SSL证书虽然经济实惠,但到期后仍需及时续期。建议在证书到期前30天设置提醒,或关注JoySSL的自动续期通知。同时,定期备份证书文件和私钥,防止意外丢失。

结语

通过以上五个简单步骤,您可以免费为网站部署一年期SSL证书,享受HTTPS加密带来的安全与信任。JoySSL的免费证书方案降低了网站安全升级的门槛,让更多中小站点能够轻松拥抱网络安全新时代。立即行动,为您的网站加上一把安全锁吧!

大家有用过魅族手机吗?还怀念大学第一台手机就是魅族 mx3。设计和操作很不错,带小圆点,长按锁屏,上滑解锁和返回。后面更是有 mback 操作逻辑。可惜后面自从没用高通芯片以及发布 Pro7 后就慢慢的走向下坡路了。

image

复制
公告原文:

亲爱的魅友和关心魅族的各界朋友们:

近日互联网上关心魅族的声音持续发酵,产生了很多错误解读。

在此郑重通告,对于网上关于魅族公司“破产重组,业务停摆,手机退市”等谣言和不实报道,我们将坚决追究造谣及传谣者的法律责任,守护清朗网络空间。

二十三年前,魅族因热爱而生。从播放器到智能手机,智能座舱,「无魅友,不魅族」不绝于耳。我们的使命就是为这群最可爱的人和这个最可爱的时代做最美妙的产品。

坚守初心和拥抱世界的变化和发展,从寻求规模到高质量发展,找到一条能让魅族健康经营和持续创新的道路,成为了春节前后公司上下面对的终极命题。

今天,我们正式对外公告:魅族将暂停国内手机新产品自研硬件项目,并在积极接洽第三方硬件合作伙伴,同时原有业务不受任何影响。

众所周知,近年来国内手机市场竞争激烈程度超乎想象,很多品牌先后选择战略收缩,虽然困难重重,我们仍尽全力拼搏,希望能保持魅族手机的正常迭代,但近来内存价格的持续暴涨让下一步新产品的正常商业化变成了不可为。

这是一个艰难的决定。我们深知,每一部魅族手机,都承载着用户的信任与青春;每一次系统更新,都连接着彼此的默契与陪伴。在此,我们向始终不离不弃的魅友、并肩前行的合作伙伴、倾注心血的全体魅族人,致以最诚挚的感谢。

国内手机新产品的暂停并非告别,而是深思熟虑的战略选择,魅族公司将积极的全面战略转型,在全新的 AI 时代,从过去以硬件为主导转向为以 AI 驱动软件产品为主导的发展方向,并打造以 Flyme 开放生态系统为基座的良性运转的企业。

主动按下的暂停键,是为了集中资源让 Flyme 软件生态能力,以更开放的姿态为更多场景、更多行业、更多企业、更多品牌的智能设备提供系统生态赋能,让魅族 Flyme 的极致体验触达更多用户。

其中 Flyme Auto 在 25 年已突破 226 万台上车量,成为国内第一的智能座舱系统,26 年内与吉利集团合作目标 300 万台合作上车量,同时与多家国际知名汽车集团的合作也在国内外顺利开展。

我们也期待 Flyme + AI 的能力底座,以 Powered by Flyme 等形式,与各行业合作伙伴广泛开放共赢合作,在全场景操作系统与智能出行等业务方向上有更加惊人的表现。

与此同时,海外手机业务、AI 眼镜和 PANDAER 科技潮流品牌业务,也将启动市场化运作,持续为大家带来更多精彩产品。

用户的权益将得到持续保障:

放心买:魅族手机、AI 眼镜、PANDAER 等相关产品将正常销售,魅族在营店铺内的服务及权益不变;

放心用:Flyme 及售后服务团队将持续守护现有用户的官方售后、维修和系统安全更新服务,保障所有用户权益。

无魅友,不魅族。

魅友在,魅族就在!

魅族科技

2026.2.27

君子不立危墙!要说「玩个游戏还玩出人生感悟来」可能有点扯,但确实有三点启示可以分享一下。 🎮🎮🎮

不过,咱也有自知之明,这是我们中年老登的感悟,年轻人听不进去的。

人生没有存档:来自《暗黑 2》专家模式的感悟


人生没有存档:来自《暗黑 2》专家模式的感悟

春节前,我提前好久早就把假期排得明明白白:宅在家里刷《Diablo IV》,刚好预购了新角色「圣骑士」,打算没日没夜在家里爽爽玩上整个假期。结果计划没有变化快,临到放假前两天,二十多年前的上上一代老游戏《Diablo II》居然突然更新了!放出了新资料片,还推出了第八个职业「术士」。啥也不用说了,当年大学时代兄弟们一起刷「大菠萝」的情怀加持,整个春节假期时间都交给了《暗黑 2 重制版》。

640

术士的强度确实在线,但三四十级后刷怪、升级、捡装备的循环开始变得重复。为了提高阈值、增加对抗性,我新开了一局专家模式(Hardcore)存档 —— 规则很简单:角色只有一次生命,死亡即永久删档,人物与全部装备不可恢复

接下来的假期,我全程以「最小风险」策略运行:不越级、不贪怪、不硬莽,等级没拉开安全余量绝不进新场景。一路苟到 60 多级,终于做出「谜团」铠甲,可以摆脱慢节奏赶路。效率上来后,操作边界稍微外扩了一点,用传送跳图、快速清场。

然后就是一次典型的黑天鹅事件:同时被几道闪电集火命中,加血的手慢了一秒,屏幕直接黑了。我当场愣了好几分钟,才慢慢接受存档彻底消失的事实,一个假期的积累、装备、进度,全部归零。

没有复活,没有回档,没有补救机会。

作为一个习惯了容错、备份、冗余设计的理工男,这次 HC 角色死亡带来的冲击很直接。要说「玩个游戏还玩出人生感悟来」可能有点扯,但确实有三点启示可以分享一下。

一、敬畏:生命只有一次

专家模式里,猝死概率不高,但后果是 100% 不可逆。

现实里也是一样:年轻时的自己居然敢开新车无牌上高速,跑到 200+ 时速,现在我都是主动压到 110 km/h 匀速;以前爬山还敢踩边缘、翻护栏找拍照角度,现在只走安全路径,再不想做无意义冒险。

不是怂了,不是老了,而是经历多了,见过了太多世事无常,所以「风险模型」变了:小概率事件 × 不可承受的后果,最优解就是坚决规避

生命没有 CheckPoint,没有备份存档,一次意外就是终局。没必要为了无关紧要的快感,把唯一的生命放在高风险区间。

二、重启:生活要有冗余

游戏里我把所有资源、时间都压在一个 HC 角色上,一次失败全盘清空。

现实里更常见:投资满仓、杠杆拉满、创业孤注一掷、把家底压在单一选项上。赢的时候收益很爽,但只要输一次就彻底崩盘。

人生不是单次博弈,而是长期重复博弈的系统。

生活中还是要留下一些冗余,合理的设计应该是:留安全垫、留现金流、留退路、留健康、留家人的缓冲。遇到挫折、亏损、变故,只要人还在,系统就能重启。「All In」似乎很燃,但从系统稳定性来看是极差的架构。

三、难度:别给自己加戏

我本来就是想假期放松玩游戏,刷个普通模式开开心心,结果一时想不开,非要给自己上 HC 难度。这么多天小心翼翼,一次失误全部白费,情绪落差还很大。

放到生活里,很多人明明已经有稳定工作、有房有车、家庭和睦、中产稳态,明明可以把日子过得平顺、和美、健康、可持续,却非要强行「突破」,想成为「人上人」,渴望更加「成功」,于是主动把系统拉到高负载、高风险。

很多「自我挑战」,本质只是多余的难度加成。

稳定、低故障、长期运行,才是人生的最优参数。没必要为了虚无的目标,把已有的稳态拆碎。

640 (1)

写了这么多确实有点矫情,只是 HC 模式用最粗暴的死亡删档,把风险、冗余、稳态这几个概念砸在了眼前,玩个游戏还让我感受到了触动。

如果各位书友也还在玩《Diablo》系列,我真心建议你也可以再来回味一下专家模式。不是为了秀操作,而是用一次不可逆的死亡,提前演练一遍:什么才是我们输不起的东西。


全文链接 人生没有存档:来自《暗黑 2》专家模式的感悟

最近在网上发现了 https://levaevro.com 这个站。专门做保加利亚列弗和欧元之间的汇率转换,功能就是个计算器,没什么技术含量。

上线 9 个月,月流量 56 万+。靠谷歌广告变现,保守估计月入几千美刀。

image.png

我把它的 Sitemap 、页面结构、URL 策略扒了一遍,记录下来分享。


先说时机,这是前提

保加利亚 2025 年 7 月 1 日加入欧元区,固定汇率 1 EUR = 1.95583 BGN 。

这个站 2025 年 5 月上线,比入欧早了将近两个月。流量爆发前,内容已经被 Google 收录了。7 月保加利亚人开始大量搜索「列弗换欧元怎么算」,这个站已经排在前面了,后来的竞品只能啃剩下的。

说实话这是我觉得比所有 SEO 技巧都重要的一点:政策落地前有一段信息真空,搜索需求已经在涨,但内容供给还没跟上,这个窗口通常只有几个月。做对了时机,后面的方法才有放大效果的机会。


域名即关键词

域名 levavevro.com 是怎么来的?

保加利亚语「列弗换欧元」写作 лева в евро,拼成拉丁字母就是 leva v evro ,合并一下就是 levavevro 。用户搜索「лева в евро」,连域名都命中了。

另外注册的是 .com 而非 .bg 。.bg 后缀在 Google 里偏向服务本地结果,.com 还能覆盖海外侨民和路过的游客。

小语种市场里这类精准匹配域名( EMD )比英文市场好用,主要是竞争少,好域名还没被人注册完。


参数化 URL + 定制 Sitemap

这是我觉得整个站最聪明的地方。

首页是个计算器,URL 长这样:


levavevro.com/?amount=100&from=BGN&to=EUR

一般的做法是给参数页面设 canonical 指向首页,防止重复内容被惩罚,只收录一个 URL 。

它的做法:把 26 个常见 BGN→EUR 金额、26 个 EUR→BGN 金额,52 个参数 URL 全部写进自定义 Sitemap ,强制提交 Google 索引。


/?amount=100&from=BGN&to=EUR    → 针对「 100 лева в евро」

/?amount=500&from=BGN&to=EUR    → 针对「 500 лева в евро」

/?amount=1000&from=BGN&to=EUR   → 针对「 1000 лева в евро」

用户搜「 500 лева колко евро」( 500 列弗是多少欧元),Google 有一个完全匹配这个查询的独立页面可以排名。52 个 URL 对应 52 种搜索词。

但这 52 个页面开发成本几乎是零,共用同一套模板,只是参数不同,内容主体完全一样。Sitemap 里所有参数页面的 lastmod 统一标成最近日期,给 Google 传递「内容在更新」的信号。

工具站只要有「用户会搜具体数值」的场景,都可以照这个做。单位换算、尺寸计算、汇率对比,把高频参数组合出来批量提交 Sitemap ,比费力做外链省事多了。


LLMs Sitemap

标准 sitemap.xml 之外,它还有个 llms-sitemap.xml 。

这是专门给 AI 爬虫( ChatGPT 、Perplexity 、Claude )准备的内容索引文件,内容组织方式针对 LLM 理解做了优化。目的很直接:用户问 AI 「保加利亚列弗换欧元怎么算」,让这个站被引用为答案来源。

2025 年 5 月建站就把这个做进去了,有点超前,当时 AI 搜索还没那么主流。这个方向现在叫 AEO ( AI Engine Optimization ),加一个 llms.txt 几乎没什么成本,如果 AI 搜索流量以后真的起来,这个先手可能值钱。


内容结构

除了首页计算器,它做了 5 个内容页面:

  • 入欧 FAQ:官方汇率、账户处理、工资养老金等常见问题

  • 入欧时间线:2025–2026 年关键节点的可视化

  • 电商商家指南:WooCommerce/OpenCart 的双重标价插件推荐

  • ECB 收敛报告解读

  • BNB 进展报告解读

每个页面底部嵌入同一套 BGN↔EUR 对照表,写一次复用到所有页面。每个内容页面对应不同的搜索意图,互相之间有内链。工具引流量,内容页提升整站权重,反过来帮工具排名。


总结

提前两个月卡位,精准域名,52 个参数 URL 批量捡长尾词,5 个内容页铺信息深度,顺手做了 LLMs Sitemap 布局 AI 搜索。没有外链,没有黑帽,都是白帽 SEO 的基本操作,但每步都到位了。

我觉得时机是前提,其他手法在正常竞争的市场里效果会打折。但如果你在找这类机会,可以关注政策落地前的窗口期,那段时间的信息真空是真实存在的。

Voice Real-time Translation ( VRT )

macOS 实时转写与实时翻译
面向跨语言会议、远程沟通、内容创作和学习场景的低延迟原生工具。

在 macOS 上,把实时转写和实时翻译做成一个可以长时间稳定跑的原生工具。
目标只有一个:让你把注意力放回沟通本身。

🌐 落地页(主入口)https://vrt.junxinzhang.com
⬇️ 下载( macOS )https://vrt.junxinzhang.com/downloads/VoiceTranslation.dmg
🎬 演示视频https://www.bilibili.com/video/BV1LyA2zSEnZ


隐私与部署方式

  • 完全本地运行:当前版本不依赖服务端中转。
  • 不收集任何数据:不采集、不上传、不留存你的音频、文本或使用数据。
  • 可用自有模型:如果你对数据更敏感,可以接入你自己的翻译模型。


视频预览

VRT Demo Preview

当前平台不支持内嵌播放器时,点击上方预览图可直接跳转播放。
备用链接:https://www.bilibili.com/video/BV1LyA2zSEnZ


我为什么做 VRT

最近一年我自己的跨语言沟通越来越频繁:开英文会、和海外同事语音、看外语内容做记录。
真正的痛点不是“翻译不出来”,而是跟不上节奏:你在听、在想、还要手动记,几件事同时发生,很容易漏信息。

市面上很多工具能解决单点问题,但在 macOS 上常见体验是:

  • 延迟明显
  • 交互割裂(多个窗口来回切)
  • 长时间使用成本高


当前版本能力

  • 边说边转写:你讲话时实时出文本,适合会议记录、播客草稿、口述写作。
  • 边听边翻译:对方说话时同步翻译,减少“先听完再补翻”的断层。
  • 双语字幕:原文和译文同屏显示,方便对照和复盘。
  • 可扩展 API/SDK:可接入你的笔记、知识库、会议系统做自动化。


我主要在这些场景里使用

  1. 跨语言会议:减少错听和遗漏。
  2. 远程沟通:语音讨论时更快达成共识。
  3. 内容创作:访谈/口述后直接得到结构化文本。
  4. 学习场景:听外语材料时实时辅助理解。


想重点收集的反馈

  • 你在哪个具体场景最容易卡住?
  • 延迟和字幕体验是否可接受?
  • 你最希望优先补的功能是什么?

欢迎直接留言或私信联系我


再次放主入口

VRT 落地页https://vrt.junxinzhang.com

首先,简单介绍一下工作。这是一个针对轻小说,galgame 等 ACGN 领域文本翻译而训练的翻译模型。相比其他的翻译模型的主要优点是:

  1. 采用了任务针对性的 CoT 过程,针对任务的困难点(如人称,主被动,场景等进行了针对性设计)
  2. 采用平均长度 1500 字以上的长段落进行训练,以获得更好的上下文能力
  3. 在训练集的选择中尝试引入了前沿的核心集选择算法进行筛选。

模型具体情况: 目前训练了 8b 和 14b 两个参数的模型,共使用 8xH100 全量微调约 2 天。底模是 Sakura-Qwen3-Base ,在此感谢 sakura 和 qwen 的贡献为本工作节省了大量 PT 和 CPT 的时间。

模型的具体效果, 可以参考我们在这里的测试,使用 COMET (wmt22-comet-da) 指标测试了共 200 个段落级别的数据,效果优于 Gemini3.0pro 以及 claude4.5opus 等 sota 闭源商业模型。用户的反馈结果和实际检查下来也很不错,在 ACGN 领域有着很强的翻译效果,并且还有一点,没有审查,可以翻译某些不可言说的东西()

我会放一段具体的翻译结果对比到评论区供大家参考。


然后再简单介绍一下针对翻译模型适配开发的推理前端。(虽说是针对本模型设计但是现在功能已经很全面了)

可以一键安装然后将日文 epub/txt/srt/ass 等文件翻译,原格式输出。配置简单,并且内置几乎完全可自定义的功能。

顺带一提使用第三方 API 也是可以用这个 GUI 进行翻译的,具体就不多说了贴几张图吧

时间序列数据随处可见:网站每分钟的访问量、传感器读数、股票价格、人流计数、服务器 CPU 使用率,都是典型场景。

多数时候这类数据遵循某种规律。异常检测的目标就是找到规律被打破的那些时刻。

什么是时间序列数据中的异常?

异常指的是与正常行为产生明显偏离的数据点或数据序列。举几个例子:凌晨 3 点网站流量突然飙升;传感器因设备故障出现读数骤降;已关门的商店内人流量异常激增。

为什么时间序列异常检测很困难

时间序列数据天然包含趋势(缓慢的上升或下降)、季节性(日级或周级的周期模式)以及噪声(随机波动)。这三个成分叠加在一起,让"正常"本身就在不断变化。

一个值的高低本身不构成异常,它是否异常取决于出现的时间点。中午有 1000 个访客是正常的,凌晨 3 点有 1000 个访客就不正常了。

学习"正常"的样子

在检测异常之前,系统需要先建立对正常行为的认知——预期的数值范围、长期趋势走向以及重复出现的季节性模式。

不同的数据特征对应不同的检测策略。

方法 1:统计阈值法(Z-Score)

最简单的做法,假设数据服从正态分布。

 import numpy as np  

def z_score_anomaly(data, threshold=3):  
    mean = np.mean(data)  
    std = np.std(data)  
    z_scores = (data - mean) / std  
    anomalies = np.abs(z_scores) > threshold  
     return anomalies

适用场景:没有趋势的平稳数据。

方法 2:移动平均 + 残差

适用于带有平滑趋势的数据。

 import pandas as pd  

def moving_average_anomaly(series, window=10, threshold=2):  
    rolling_mean = series.rolling(window).mean()  
    residual = series - rolling_mean  
    std = residual.std()  

     return abs(residual) > threshold * std

它的优势在于,每个数据点比较的是自身的局部上下文而非全局均值。

方法 3:季节性分解

周期性模式明显的数据最适合用这个方法。

 from statsmodels.tsa.seasonal import seasonal_decompose  
   
 def seasonal_anomaly(series, period=24):  
     result = seasonal_decompose(series, model='additive', period=period)  
     residual = result.resid  
     threshold = 3 * residual.std()  
     return abs(residual) > threshold

季节性分解把原始序列拆成趋势、季节性和残差三个分量,异常通常藏在残差里。

方法 4:机器学习(Isolation Forest)

不依赖任何分布假设,直接隔离罕见模式。

 from sklearn.ensemble import IsolationForest  
   
 def isolation_forest_anomaly(data, contamination=0.02):  
     model = IsolationForest(contamination=contamination)  
     preds = model.fit_predict(data.reshape(-1, 1))  
     return preds == -1

适用场景:模式未知、数据不规则,或者多变量时间序列。

方法 5:深度学习(自编码器)

自编码器学习重建正常序列,重建误差高的部分即为异常。

 import numpy as np  
   
 def reconstruction_error(original, reconstructed):  
     return np.mean((original - reconstructed) ** 2)

适合处理模式复杂、维度较多、存在长期依赖关系的时间序列。

示例:人流量分析

 import pandas as pd  
import numpy as np  
from statsmodels.tsa.seasonal import seasonal_decompose  

# 生成商店人流量数据(1 周,每小时)  
hours = pd.date_range('2024-01-01', periods=24*7, freq='H')  
hour_of_day = hours.hour  

# 正常:上午 9 点到晚上 9 点繁忙,夜间安静  
base = 100 + 80 * ((hour_of_day >= 9) & (hour_of_day <= 21))  
traffic = pd.Series(base + np.random.normal(0, 10, len(hours)), index=hours)  

# 注入异常  
traffic.iloc[15] = 200   # 凌晨 3 点飙升(摄像头问题)  
traffic.iloc[75] = 5     # 营业时间下降(故障)  

# 检测  
result = seasonal_decompose(traffic, model='additive', period=24)  
residual = result.resid  
anomalies = abs(residual) > 3 * residual.std()  

 print(f"Detected {anomalies.sum()} anomalies")

减少误报

误报是异常检测在生产环境中最常见的痛点。三种思路可以缓解。

调整灵敏度:控制标记比例:

 model = IsolationForest(contamination=0.02)  # 仅标记 2%

要求持续性:只有连续多个点都表现异常时才触发告警:

 # 仅当异常持续 3 个及以上连续点时才标记  
 consecutive_count >= 3

集成投票:多种方法同时判断,取多数一致的结果:

 # 投票:如果 2 个及以上方法一致则标记  
 votes = method1 + method2 + method3  
 anomalies = votes >= 2

总结

异常检测的核心不在于找出"奇怪的数字",而在于理解每个时间点上什么才算正常。先对数据做可视化探索,从移动平均或季节性分解入手;如果数据模式复杂,引入 Isolation Forest;生产系统中建议组合多种方法以降低误判。

异常检测要做的,是识别那些偏离了时间、趋势和行为规律的数据点。

https://avoid.overfit.cn/post/a6de4ac94dd64768a768593e39b6c7cb

by Bhargavi Guddati

2026 年,智能体将在企业级应用中取得哪些实质性突破?点击下载《2026 年 AI 与数据发展预测》白皮书,获悉专家一手前瞻,抢先拥抱新的工作方式!

数据产品的概念已获得广泛关注,众多企业正纷纷构建门户或平台,以在内部共享数据与人工智能产品。过去一年中,我协助了数十家企业推进数据产品化进程,并推动其采用 Snowflake Internal Marketplace。

不出所料,不同组织在现有 IT 架构、治理要求及数据管理流程方面存在差异。这些特点影响着 Internal Marketplace 的采纳效果及其与现有流程的整合。尤其值得注意的是,面向数据与人工智能的 Internal Marketplace 是一个高度可见的组件,其涉及公司内部几乎所有与数据相关角色的参与。因此,引入 Internal Marketplace 将带来多方面的影响,并涉及众多利益相关方。为确保持续成功落地,必须对这些因素进行审慎考量。

本文探讨了架构指导原则、账户拓扑设计、数据产品合规与验证、版本管理,以及治理与权限管理等主题。

我们建议根据实际需求对 Snowflake Internal Marketplace 进行定制化配置,并分享在实施过程中涉及人员与流程维度的组织级考量建议。

若您尚未熟悉 Snowflake Internal Marketplace,建议[观看此演示视频]以了解其核心功能特性。

组织层面的考量

建立 internal marketplace 与数据产品体系不仅是技术任务,人员与流程同样是关键要素,对于推动 internal marketplace 的顺利落地至关重要。

  • 避免引入 internal marketplace 的中央数据平台团队与目标用户群体之间出现目标偏差。在规划阶段应吸纳未来数据产品所有者及使用方的代表参与,尽早并持续获取所有相关方及用户的支持与认可;

  • 确保数据产品的所有权明确(即明确各项数据的归属主体);

  • 部分数据的所有权界定可能较为清晰,可从易于确定归属的数据入手,逐步迭代并扩展范围;

  • 制定清晰的所有权职责定义,涵盖数据产品文档、治理、质量、沟通、标准、互操作性等方面。初期可设定基础职责,再随时间推移逐步完善;

  • 必须将业务数据负责人纳入数据文档、治理与质量管理的责任体系中;

  • 无需在初始阶段追求覆盖所有场景的完美方案。精细规划与分析停滞之间需把握平衡,应从“简单”场景起步,通过持续学习、迭代并渐进扩展,以敏捷方式推进 internal marketplace 的落地。

账户与配置

Snowflake Internal Marketplace 在不同团队共享单个 Snowflake 账户、使用独立账户或混合部署场景下均能有效运作。您无需预先确定固定的账户拓扑结构,该拓扑可灵活调整并随时间演进。

  • 独立账户可为各业务单元提供更强的隔离性与独立性,但需额外考虑账户管理问题。Snowflake Organization Account 能够简化多账户的统一管理与监控;

  • 若要在多区域或多云环境中使用 internal marketplace,则必须采用独立账户部署;

  • 在单账户内通过独立数据库访问数据产品时,其细粒度访问策略的定义可能与多账户场景存在差异,相关内容将在后续文章中详细探讨。

无论采用单账户还是多账户模式,我们强烈建议创建 Snowflake Organization Account,该账户为定制组织的 Snowflake Internal Marketplace 提供关键能力:

  • 为通过 Internal Marketplace 共享数据产品的不同团队/领域/部门创建用户画像;

  • 创建自定义数据产品属性,用于定义描述任意数据产品的附加字段。可指定哪些属性为必填或选填、其允许取值范围及筛选条件(此功能目前处于私有预览阶段);

  • 可创建 Snowsight Dashboard 以提供 Internal Marketplace 使用情况的概览视图,更多细节将在后文“数据产品监控”部分说明;

  • 可选创建组织级用户与用户组,以协助数据产品的管理与访问控制。

 

 使用组织账户定义并管理域团队

许多 Internal Marketplace 用户倾向于将其菜单项固定至菜单栏顶端作为快捷访问入口。

将 Internal marketplace 菜单项置顶

数据产品管理

数据产品管理的最佳实践涵盖流程与运营原则,以及技术实施指导规范。

运营建议

数据产品负责人应运用传统的产品管理原则,重点关注“客户”需求、业务目标、路线图、生命周期管理、文档化及内部推广。

  • 尤其应基于潜在数据消费者的需求设计数据产品。如何使特定数据产品对典型数据消费者产生最大价值?

  • 建立数据产品沟通渠道。例如,在 Snowflake Internal Marketplace 发布数据产品的每个团队可设立 Teams 或 Slack 频道。数据所有者可通过该频道提前发布数据产品更新或变更通知,数据消费者则可提交对数据产品的反馈或疑问;

  • 数据生产者亦可考虑采用数据产品新闻通讯或定期开放办公时间的方式,与数据消费者建立双向沟通机制;

  • 定义并跟踪数据产品质量标准,不仅涵盖传统数据质量指标,还应包括元数据完整性、文档完备性、治理控制措施、标准遵循度等;

  • 定义并跟踪数据产品成功指标,可涵盖使用统计量、数据消费者数量、数据消费者用例类型,以及使用该数据产品的报表或 AI 智能体等。

技术实施建议

针对内部市场上数据产品的技术实施,建议遵循以下最佳实践:

  • 每个数据产品应在 Internal Marketplace 中作为独立条目上架;

  • 充分利用条目的所有可选字段,使数据产品的描述尽可能完整、清晰。必要时可添加自定义属性;

  • 确保所共享的表、视图等对象具备完整的对象描述与字段描述,系统将据此自动生成数据产品的数据字典;

  • 组成数据产品的对象可分布于不同模式乃至不同数据库(后者需使用 reference_usage 授权)。因此,无需根据待发布的数据产品重新调整数据对象在模式或数据库中的物理分组,可通过 Marketplace 的上架条目实现逻辑层面的灵活分组,独立于底层存储结构;

  • 如需展示数据质量,可在数据产品条目中添加包含相关 DQ 指标、质量期望及最新 DQ 评估结果的视图或表。建议将该视图或表加入条目,并设置为数据字典中首个或唯一一个推荐对象。

数据质量指标可纳入数据产品的数据字典中

数据产品合规性与验证

在数据产品发布时或发布前,可能需要验证其是否符合一项或多项需强制执行的规定或标准。此类规则的示例如下:

  • 验证数据产品在应(或不应)显示数据预览时,是否确实(或未)显示数据预览;

  • 验证数据产品是否包含适当的归属和联系信息,例如通过引用预定义的域配置文件进行确认;

  • 验证数据产品未与不应拥有访问权限的账户或角色共享;

  • 根据需求验证数据产品是否允许(或禁止)重新共享;

  • 其他类似规则。

DESCRIBE LISTING 命令以及 information_schema.listings 视图(目前处于私密预览阶段)能够提供列表的所有元数据,以便自动验证此类规则。例如,存储过程可以根据公司标准验证列表配置,并在需要时采取相应措施。

数据产品版本管理

许多数据产品会随时间演进,您可能需要实施一套版本管理方案。

每个数据产品定义(Snowflake 产品清单)均以 YAML 文件形式呈现,支持对产品进行程序化管理。这些 YAML 文件可存储于 Git 仓库或 Snowflake 版本化阶段中。若采用后者,请熟悉 Snowflake 文档中的以下命令:

CREATE ORGANIZATION LISTING ... FROM <yaml_stage_location>;SHOW VERSIONS IN LISTING <listing_name>;ALTER LISTING <listing_name> ADD VERSION FROM <yaml_stage_location>;DESCRIBE LISTING <listing_name>;
复制代码

当您对数据产品进行非向后兼容的重大变更(例如移除视图或列)时,建议遵循以下步骤:

  • 提前向数据产品用户充分告知即将进行的变更;

  • 发布数据产品 V2 版本,并在一段时间内(例如 6 周或 3 个月)继续维护 V1 版本,以便用户完成迁移;

  • 最终下线并废弃数据产品 V1 版本;

  • 充分利用与数据用户间的沟通渠道,确保信息传递到位。

非 Snowflake 数据产品在 Internal Marketplace 中的管理

用户可将非 Snowflake 数据产品发布于 Internal Marketplace 实现可发现性。此类产品可包含其他存储库中的数据资产,或第三方工具(如 Power BI、Tableau、Qlik、Microstrategy 等)中的报表与仪表板。

  • 创建产品列表时需填写描述、所有权信息及其他外部资产相关详情;

  • 建议定义自定义数据产品属性,以便列表所有者能以结构化、可筛选且统一的方式标注产品的类型、来源或其他关键属性;

  • 在列表描述中需包含一个或多个指向外部资产的 URL 链接;

  • 当前发布此类列表仍需创建一个空的“虚拟”共享单元作为技术前提;

  • 外部资产的访问授权将在 Snowflake 平台之外进行管理。

角色与权限管理

您需要为 Internal Marketplace 上的数据产品选定合适的访问与权限管理模式。目前主要有两种方案,请根据您的实际需求与流程选择最适配的方案。

方案一:当用户需要访问某个数据列表时,可将相应用户账户与角色添加至该列表的定向访问列表(即授权列表)中。

  • 例如,若某个列表原本仅允许角色 0 访问,现需为拥有角色 1 的用户开放访问权限,则可将角色 1 添加至该列表的可访问角色集中(如下图所示);

  • 该方案通常适用于基于 Snowflake 平台内部的请求与审批流程。

方案二:当用户需要访问某个数据列表时,可为该用户授予已具备该列表访问权限的现有角色。

  • 例如,若某个列表已允许角色 0 访问,现需为拥有角色 1 的用户开放访问权限,则可将角色 0 授予角色 1。角色 0 可以是仅针对此单一列表的技术访问角色,也可涵盖多个列表的访问权限集合。

向角色 1 授予数据产品访问权限的替代方案

数据产品监测

您可在组织账户中创建跨域仪表板以追踪所需指标。仪表板中的每个磁贴均显示一项查询结果。目前这些查询的源数据主要来源于以下视图:

organization_usage.access_history

organization_usage.query_history

数据产品活动仪表板

总结

Snowflake 平台及其 Internal Marketplace 提供了全面的数据产品管理能力,包括:

  • 通过 Internal Marketplace 的搜索与筛选功能实现数据产品发现;

  • 提供丰富的文档、服务等级目标(SLOs)及元数据,使数据产品易于理解且值得信赖;

  • 基于角色的权限设定,明确谁可发现或访问特定数据产品;

  • 具备审计追踪功能的访问请求与审批流程;

  • 可为数据产品添加广泛的数据治理策略;

  • 追踪与度量数据产品的使用情况;

  • 支持跨云区域和跨平台共享与使用数据产品的组织;

  • 支持高级数据产品载体,如笔记本、语义模型及 AI 智能体。

本文探讨的最佳实践可帮助您成功应用上述能力,并使其与现有 IT 架构和流程保持高度协调。.

原文地址:https://medium.com/snowflake/best-practices-for-adopting-the-snowflake-internal-marketplace-ba4440838d32

点击链接立即报名注册:Ascent - Snowflake Platform Training - China更多 Snowflake 精彩活动请关注专区

Anthropic 近日为其命令行编码工具 Claude Code 上线“自动记忆”(Auto Memory)功能,进一步强化 AI 在真实开发环境中的上下文持续理解能力。这一更新的核心目标,是让模型在长期项目协作中逐步积累“项目认知”,减少开发者反复输入背景信息的负担。

 

据介绍,在开启 Auto Memory 后,Claude 会在日常工作过程中自动记录与项目相关的重要上下文信息,包括构建命令、调试经验、代码风格偏好、架构约定等内容。这些信息将在后续会话中自动加载和调用,无需开发者手动整理或额外说明。换言之,模型将随着使用时间的增长,对项目形成更完整的“工作记忆”。

 

此前,Claude Code 已支持CLAUDE.md文件,作为开发者向模型提供显式指令和项目约束的载体。而此次新增的Memory.md文件,则角色相反——它是由 Claude 自主维护的“笔记本”。当用户在协作过程中明确表达偏好,例如“记住我们使用 pnpm 而不是 npm”,Claude 会将该信息写入记忆文件,在后续任务中优先遵循这一约定。

 

从技术实现层面看,每个项目的记忆内容会存储在本地目录~/.claude/projects/下。系统在每次会话启动时自动加载MEMORY.md的前 200 行内容,确保关键上下文能够即时生效;更长或更细节化的记忆内容则按需读取,以平衡性能与信息完整性。

 

该功能默认开启,开发者可通过/memory命令或配置文件进行关闭或管理。

 

在当前 AI 编程工具快速演进的背景下,如何解决“会话即失忆”的问题,成为提升实际生产力的关键环节。Claude Code 的自动记忆机制,试图从工程实践层面构建长期上下文积累能力,使模型从“单次协作助手”转向“持续参与项目的虚拟成员”。对于开发者而言,随着使用时间增长,Claude 对项目的理解深度也将同步提升,从而减少重复沟通成本,提高整体开发效率。

 

参考链接:https://code.claude.com/docs/en/memory

image

在数字化转型浪潮中,数据集成能力已成为企业的核心竞争力。作为企业技术决策的核心角色,CIO面临着数据集成平台选型的重大挑战:如何在有限预算下,选择既能满足当前需求、又能支撑未来发展的解决方案?

本文将从CIO决策视角,系统分析企业数据集成平台选型的七个关键维度,帮助你做出明智的技术投资决策。

一、选型困境:传统方案的三大痛点

在与众多企业CIO的交流中,我们发现数据集成平台选型普遍面临以下困境:

1. 成本与功能的悖论

商业ETL工具(如Informatica、DataStage)功能强大,但动辄百万级的license费用让中小型企业望而却步;开源工具(如Kettle、DataX)零成本,但企业级功能缺失、技术支持薄弱,隐性成本高企。

"我们评估了Informatica,功能确实强,但一年license费用够我们雇三个数据工程师了。最后用了开源方案,结果花了两年时间才勉强稳定下来。"——某中型企业CIO

2. 技术债务的累积

早期选择的开源或自研方案,随着业务发展逐渐暴露出扩展性差、维护成本高、技术栈老化等问题,重构成本往往超过当初节省的费用。

3. 人才招聘与培养难题

商业工具需要专门的认证培训,开源工具依赖"野路子"经验积累。无论哪种,都面临人才稀缺、流动性大的问题。

二、决策框架:七个关键维度

image

基于对数十家企业选型实践的总结,我们提炼出CIO决策的七个关键维度:

维度一:功能完整性与成熟度

  • 离线ETL/ELT能力:是否支持复杂的数据转换、清洗、聚合操作?
  • CDC实时集成:能否实时捕获数据变更,满足实时数仓、实时BI需求?
  • 编排调度:是否具备任务编排、依赖管理、失败重试等企业级调度能力?
  • 数据服务API:能否将数据快速封装为API,支持业务系统调用?

CIO视角:不要为"未来可能用到"的功能买单,但必须确保核心场景的成熟度。CDC实时集成已从"加分项"变为"必选项"。

维度二:TCO(总体拥有成本)

除了显性的license费用,还需考虑:

  • 实施成本:部署、配置、培训的时间与人力投入
  • 运维成本:日常监控、故障排查、版本升级的工作量
  • 扩展成本:数据量增长、场景增加时的边际成本
  • 机会成本:技术团队投入到平台维护而非业务创新的代价

维度三:易用性与学习曲线

零代码/低代码能力直接影响:

  • 团队上手的速度(从周级到天级)
  • 对专业数据工程师的依赖程度
  • 业务人员自主处理数据需求的可行性

可视化拖拽式操作、直观的任务配置界面,能显著降低技术门槛,释放团队生产力。

维度四:生态兼容性与扩展性

  • 数据源支持:是否覆盖主流数据库、大数据平台、SaaS应用、消息队列?
  • 协议兼容:是否支持JDBC、ODBC、REST API等标准协议?
  • 插件生态:能否通过插件快速扩展新数据源、新功能?

维度五:稳定性与可观测性

生产环境的稳定性是底线要求:

  • 监控告警:是否支持任务状态监控、性能指标采集、异常告警?
  • 日志追溯:能否快速定位问题根因,审计数据流向?
  • 高可用:是否支持集群部署、故障转移、负载均衡?

维度六:安全与合规

  • 数据加密:传输加密、存储加密、敏感字段脱敏
  • 权限管控:细粒度的角色权限、操作审计
  • 合规认证:是否符合等保2.0、GDPR等法规要求

维度七:供应商生态与服务能力

  • 技术支持:是否有专业团队提供技术支持、问题排查?
  • 社区活跃度:文档是否完善、社区是否活跃、问题能否快速解决?
  • 发展前景:供应商是否持续投入研发,产品路线图是否清晰?

三、成本效益对比:三种典型方案

对比维度商业ETL开源ETLETLCloud社区版
初始成本50-200万/年免费免费
实施周期2-6个月6-12个月1-4周
学习曲线陡峭(需认证)陡峭(靠摸索)平缓(零代码)
CDC实时集成支持(另付费)需二次开发原生支持
技术支持企业级SLA社区自助社区+可选商业支持
运维成本低(托管服务)高(自行维护)低(可视化运维)
适用场景大型企业、预算充足技术团队强、时间充裕中小企业、快速落地

关键发现:ETLCloud社区版在"功能完整性"与"零成本"之间找到了平衡点,为中小企业提供了一条"低成本、快速落地、可演进"的路径。

四、实践路径:三步走策略

image

第一步:快速验证(1-2周)

  • 选择1-2个典型场景(如数据仓库同步、报表数据抽取)
  • 部署社区版,完成从源端到目标端的数据集成任务
  • 验证功能完整性、易用性、性能表现

第二步:小规模试点(1-3个月)

  • 扩展到核心业务场景
  • 引入CDC实时集成能力
  • 建立监控告警机制
  • 培训内部团队,沉淀最佳实践

第三步:全面推广(3-6个月)

  • 逐步替换旧有方案,统一数据集成平台
  • 根据业务需求评估是否升级商业版
  • 建立数据集成规范与治理体系

五、CIO决策清单

在做出最终决策前,建议CIO确认以下问题:

✅ 当前数据集成痛点是否明确?(成本高、效率低、扩展难?)

✅ 未来3-5年数据规模与场景增长预期如何?

✅ 团队技术能力与供应商支持能否匹配?

✅ TCO测算是否覆盖隐性成本?

✅ 是否有明确的POC验证计划?

✅ 供应商发展前景是否稳健?

六、结语:选择比努力更重要

数据集成平台选型是一次重要的技术投资决策。选对了,事半功倍;选错了,技术债务累积,重构成本高昂。

在数字化转型的下半场,快速试错、敏捷迭代成为主旋律。ETLCloud社区版为CIO提供了一个"零成本验证、平滑演进升级"的选项,让企业能够用最小风险探索数据集成的最佳实践。

与其在商业方案的昂贵license与开源方案的隐形维护成本之间纠结,不如选择一条务实路径:从社区版起步,验证场景可行性,再根据业务发展决定是否升级商业支持。这,或许是当下最理性的CIO决策。

43ffe5cb75b0a79ba55f9dfb68d2cb61.png

引言

随着大模型推理的加速发展和落地,AI 网关正在从“简单的 L7 代理”演变为承载调度、治理与可观测能力的数据面核心组件[1]。在这一过程中,系统面临的关键挑战不再只是吞吐量,而是长连接、流式返回与复杂策略链叠加带来的长尾延迟与可调试性问题

当网关需要在请求路径上执行多级策略、语义处理与状态感知调度时,数据面的执行模型本身就成为性能与稳定性的决定性因素。换句话说,AI 网关的上限,不仅取决于调度算法或缓存策略,更取决于其扩展逻辑是运行在虚拟机边界之内,还是原生运行时之中。

本文考察了两条可能的技术路径,分别以 Envoy[2] 的 Go WASM 扩展模型和 BFE[3] 的 Native Go 扩展模型为代表。两者在隔离性、扩展效率与工程可控性上各有优势,但在 AI 流式推理场景下,其执行路径差异会被持续放大

本文将从运行时模型出发,分析 Go WASM 与 Native Go 在 AI 网关数据面中的实际工程影响,并探讨在复杂策略与长连接负载下,不同执行路径所带来的性能与运维差异。

1. AI 网关对数据面的真实要求

AI 推理流量与传统 HTTP 流量有本质不同:

  • 单请求生命周期从毫秒级变为秒级甚至分钟级以
  • Streaming 为主,而非短连接
  • 并发数高,但 QPS 未必高
  • 请求过程中需要持续占用内存与连接资源

因此,AI 网关数据面的关键指标不再只是 QPS,而是:

  1. 长连接并发承载能力
  2. 资源占用的可预测性
  3. 长尾延迟稳定性
  4. 异常隔离能力

在这样的目标下,运行时模型就成为决定性因素。

2. 基于 Envoy 的 AI 网关:Go WASM 扩展模型的工程影响

背景

在 AI 网关场景中,虽然 Envoy 原生支持基于 C++ 的扩展开发,但实际工程落地时,绝大多数团队并不会选择 C++ 来实现复杂的网关逻辑,而是转向 Go WASM[4] [5] [6]。其原因主要包括:

首先,C++ 扩展的开发门槛和维护成本较高,涉及内存管理、线程安全、生命周期控制等底层细节,对团队工程能力要求极高,不符合 AI 网关“快速迭代策略”的需求。

其次,C++ 扩展需要与 Envoy 主进程同地址空间运行,一旦出现内存越界或未定义行为,可能直接影响整个数据面的稳定性,这与企业在 AI 场景中对隔离性和安全性的要求存在冲突。

相比之下,Go WASM 通过 VM 提供了更强的隔离性,同时 Go 语言在企业内部的普及度更高,更易于承载策略开发与快速迭代,因此成为基于 Envoy 构建 AI 网关时的主流扩展方式。这也是为什么在实际项目中,我们讨论 Envoy 的扩展模型时,往往等同于在讨论 Go WASM 扩展模型。

工程影响

从运行时角度看,Envoy+Go WASM的方案引入了一个关键特征:

AI 网关的核心逻辑运行在WASM VM中的Go 运行时中,而非原生进程中

这带来几个工程层面的影响:

(1)GC 行为放大长尾延迟

在 WASM 运行环境中,Go 运行时的并发调度能力受限,使 GC 停顿对请求路径的影响更容易放大。

在 AI 流式请求长时间驻留的情况下:

  • 在长生命周期流式请求叠加高分配速率的情况下,GC 更容易触发
  • Worker 上的请求处理可能出现可见停顿
  • 同一 Worker 上的多个流式请求可能同时受到影响

这会直接放大长尾延迟。

(2)扩展模块数据拷贝与序列化开销

在 WASM 机制下:

  • 每个扩展模块都有独立线性内存
  • Host(Envoy)与 Guest(WASM)之间必须进行数据拷贝
  • 需要序列化 / 反序列化传递上下文

这意味着:

每增加一个 WASM 扩展模块,就增加一次数据拷贝与一次序列化成本

而 AI 网关的能力正在持续增加:

  • Token 级限流
  • 内容审计
  • 模型路由
  • 推理负载感知调度

这些能力往往拆分为多个模块实现,导致:

  • 数据在模块之间反复拷贝
  • CPU 与内存开销叠加
  • 在多模块链式执行场景下,吞吐能力可能下降
  • 长尾延迟抖动加剧

随着功能增长,开销随模块数量近线性叠加,最终可能成为系统瓶颈。

(3)故障影响范围扩大

在常见的 Worker 级 WASM 实例复用模型下,一个 WASM 实例通常服务多个请求。

当出现:

  • 内存泄漏
  • 死循环
  • panic 无法 recover

时,可能影响同一 Worker 上的所有流式连接

在长连接驻留模型下,这种影响范围会被放大。

(4)调试复杂度提升

在 Go WASM 机制下:

  • 调用栈经过 ABI 转换
  • 无法获得完整的 Native Go stack trace
  • 无法使用标准 pprof / runtime 工具进行深度诊断

这意味着:

  • 不能通过 panic 栈直接定位问题代码行
  • 需要跨 Envoy、WASM VM 与 Go Runtime 三层排查

对于生产环境中的长尾问题,这会显著增加定位难度与恢复时间。

小结

从工程视角来看,上述性能、长尾延迟与可调试性问题并不是孤立现象,其本质在于:

Go WASM 并不适合承载复杂业务逻辑

这个问题并非通过优化单个插件即可解决,而是由执行模型本身决定的结构性限制。

3. 基于 BFE 的 AI 网关:Native Go 模型的工程特征

在 BFE 上实现 AI 网关能力,核心逻辑以内建 Go 模块运行,数据面逻辑与网络栈共享同一运行时与内存模型。

这带来几个关键工程特征:

(1)支持并行 GC,GC 延迟更小

在 Native Go 运行时中:

  • 采用并行 GC
  • STW 时间更短
  • 对正在处理的长连接影响更小

在高并发流式场景下,有助于控制长尾延迟抖动。

(2)内存处理开销更低

对于数据请求:

  • 直接进入业务逻辑处理
  • 无需跨运行时边界传递
  • 不存在 Host / Guest 数据拷贝
  • 无序列化与反序列化开销

对于 Token 级高频路径,这意味着:

  • 更低 CPU 消耗
  • 更低内存占用
  • 更稳定吞吐

(3)故障影响范围更可控

BFE 的模块化实现通常:

  • 每个请求在独立的 goroutine 与上下文中运行
  • 可通过 Go 的 recover 机制兜底
  • 避免单点异常扩散至同一 Worker 的多个流

这对于长连接模型尤为关键。

(4)调试更简单

问题定位时:

  • 只需关注单一 Go 进程
  • 可以获得完整 panic 栈
  • 可以使用标准 pprof、trace、runtime 工具

这使得长尾问题的定位效率显著高于Go WASM。

结语:运行时模型决定 AI 网关的数据面上限

在 AI 推理成为核心生产流量之后,数据面的技术选型不再只是性能或功能问题,而是运行时模型问题。两种方案的差异,本质上是“虚拟机扩展模型”与“原生运行时模型”的差异。

表1 两种方案的对比

维度Envoy: Go WASMBFE: Native Go
执行模型VM 内沙盒运行进程内原生运行
数据路径Host/Guest 拷贝直接内存访问
GC 影响停顿更易放大并行 GC,影响更小
调试难度跨三层,无法充分利用Go语言能力单进程,可充分利用Go语言能力
长尾延迟抖动更大更可控

基于 Envoy 的 AI 网关方案,通过 Go WASM 获得了极强的扩展能力,但也引入了:

  • VM 运行时开销
  • 扩展模块的数据拷贝与序列化成本
  • GC 停顿放大效应
  • 无法使用 Native Go 的异常定位能力

而基于 BFE 的 AI 网关方案,以 Native Go 实现核心逻辑,使得:

  • 资源模型更可预测
  • 流式稳定性更高
  • 长尾延迟更可控
  • 运维与调试路径更简单

对于企业级推理场景,这些差异将直接影响用户体验与服务质量。

AI 网关的复杂度是单调递增的,而Go WASM的成本是按模块叠加的

在长连接流式推理场景下,Native Go 的技术路线更具工程可控性

参考资料

[1] 大模型推理场景下的 AI 网关:定位、职责与架构演进,https://mp.weixin.qq.com/s/gtYAPqHqvSWoNHJzCryGPw,2026年1月
[2] Envoy,https://github.com/envoyproxy/envoy
[3] BFE, https://github.com/bfenetworks/bfe
[4] Envoy AI Gateway, https://github.com/envoyproxy/ai-gateway
[5] kgateway, https://github.com/kgateway-dev/kgateway
[6] Higress,https://github.com/alibaba/higress

作者简介

章淼,博士,1994年进入清华大学计算机科学与技术系学习,2004年获得博士学位,2004年至2006年在清华大学留校任教,在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年,聚焦云网络基础架构的研发工作,是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升,曾担任百度代码规范委员会主席,2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术:用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO,聚焦研发面向云和大模型场景的现代化流量管理平台。