前几日在在电梯里听见的谈论：

“你这几年换了三份工作啊？”
“嗯。”
“厉害……也有点飘。”
电梯门一合，扣好“草率”的标签，一整天都刮着风。

与其争辩，不如换个叙述方式。今天不讲数据，讲一个三幕小剧场，把“稳定”与“跳槽”请上台，各自说话。

第一幕｜传统观念的回音墙

父母视角：稳定=安全。“铁饭碗至少不饿肚子。”
邻里视角：稳定=体面。“单位名片比名片上人名重要。”
部分HR视角：稳定=可靠。“履历像一条直线，省心。”

这些声音没有错，只是来自过去的经济逻辑：岗位稀缺、失败成本高、信息不透明。
但现在的职场像一条不断分叉的河。你原地扎营可以，但也许更好的水草在拐弯处。
“稳定”如果只是不变，那更像卡在河床上的一块石头；真正的稳定，是在变化中保持可控。

金句：稳定是结果，不是方式；不变不一定叫稳定，掌控才叫稳定。

第二幕｜跳槽与成长：换工作，别只换门禁卡

跳槽，最怕“换来换去，只换了工牌颜色”。
判断有没有成长，看四件事：

问题强度：新岗位的难题，是否比原来的更大、更复杂、更贴近业务核心？
可迁移资产：你带走了什么“随身武器”（写作、分析、项目推进、谈判、行业认知）？
视角宽度：是否从“执行者”升到“设计者/决策参与者”的视角？
作品与证据：能不能用一页纸/一个仓库/一个案例说服陌生人？

如果这四件事持续上台阶，频率不是原罪；如果只是为了逃避情绪、老板、加班——那叫逃跑，不是跳槽。

金句：好的跳槽，是把履历写进能力；坏的跳槽，是把心情写进简历。

跳槽机-会

技术大厂，前端-后端-测试，全国均有机-会，感兴趣可以试试。待遇和稳定性都还不错~

第三幕｜什么样的跳槽才算“有价值”？

给你一块价值跳槽九宫格（自测用，过半即值得）：

方向：行业在向上？岗位贴近价值链核心？
密度：问题更难？反馈更快？产出更可见？
导师：能跟到真正在干活、愿意带人的上级？
舞台：边界更大（预算/权限/跨部门协作）？
节奏：迭代更短（周/月为单位复盘）？
证据：离职时能留下公开作品或可量化战绩？
现金：不是只涨工资，而是单位时间成长更高？
生活：通勤、作息、健康是否更可持续？
心流：进入“做着做着忘了时间”的那种投入？

能勾中6格以上，才叫“向上的移动”。
别只看薪资条，那是果；先看问题强度与可迁移资产，那是根。

四不跳（写得像贴在显示器上的小贴纸）：

不为发泄而跳（吵完架写辞职信，第二天先删草稿）。
不为名头而跳（Title 高一号，问题却更边角）。
不为“跟风”而跳（朋友涨薪=他的剧本，你得看自己的镜头）。
不为“逃离”而跳（去哪儿都一样累=问题在方法，不在公司）。

行动卡｜下一次跳之前，先做这三件小事


写一封给未来雇主的信（300字）
只回答三问：我解决过什么问题→用过什么方法→带来了什么改变。写不出来，就别急着跳。


做一张“技能-行业”二维表
横轴列出你拥有或在学的3–5项通用技能，纵轴放3个感兴趣行业，把可迁移的交叉点标星。星星越多，越值得跳。


安排一次“影子体验”
找目标岗位的人聊30分钟，围绕一天在做什么、最难的问题、如何被衡量三件事。聊不到，说明信息还不够，先别跳。

给“稳定派”与“跳槽派”的一封并信

稳定派：请把“稳定”从“年头写到年尾”改成“能力结构可复用、现金流有弹性、健康不透支”。那是强者的稳定。
跳槽派：请把“跳”从“情绪出口”改成“能力跃迁”。那是成熟的跳槽。

人和岗位不是孰优孰劣，是匹不匹配。
频繁跳槽的人，并不比稳定工作的人差；真正的差别在于：
有人在原地生长，有人在移动中生长；有人只是换地方，有人换了层级。

当你能把每一次选择，都解释为更清晰的方向、更锋利的能力、更合理的生活——
你的履历，就不再是“跳来跳去”，而是一步一个台阶。

——转载自：狗头大军之江苏分军

准备放假回家过年，想着回去刷刷剧打打游戏啥的，手机屏幕太小就想买个平板，然后就刷到各种平台上的 298，398 各种配件齐全而且是 1tb 的平板，内心上知道肯定有问题，但是还是想问问有没有人尝试过，只是刷刷剧的话能不能用啥的。

1. 库的概览与核心价值

想象一下，你面对着成千上万个杂乱的网页，需要从中提取有价值的信息——就像在一堆没有标注的书籍中寻找特定的章节。如果手动去解析那些层层嵌套、格式混乱的HTML代码，就像在没有索引的情况下翻阅整个图书馆。BeautifulSoup正是为解决这个痛点而生的工具。

BeautifulSoup（全称beautifulsoup4）是一个Python库，它能够将复杂的HTML或XML文档转换成一个结构化的树形对象，让开发者可以通过简洁的API快速定位和提取数据。它在Python生态中的独特价值在于：极强的容错能力和人性化的API设计。即使网页代码不规范（如标签未闭合、嵌套错误），BeautifulSoup也能优雅地处理，这在真实世界的网页解析中尤为重要。

与正则表达式相比，BeautifulSoup不要求你掌握复杂的模式匹配规则；与lxml、Scrapy等重型爬虫框架相比，它学习曲线平缓，代码可读性强。对于中小型数据提取项目、教学演示或快速原型开发，BeautifulSoup是当之无愧的首选。

2. 环境搭建与"Hello, World"

安装说明

BeautifulSoup的安装非常简单，但有一个关键点需要注意：正确的包名是beautifulsoup4，而不是beautifulsoup。同时，建议安装高效的解析器lxml以获得更好的性能。

# 使用pip安装（推荐）
pip install beautifulsoup4
pip install lxml

# 如果使用conda
conda install beautifulsoup4 lxml

安装失败常见原因：

  1. 错误使用pip install beautifulsoup（包名错误）
  2. 网络问题导致PyPI连接超时
  3. Python环境混乱，pip指向错误的Python版本

解决方案：使用国内镜像源加速，如：

pip install beautifulsoup4 lxml -i https://pypi.tuna.tsinghua.edu.cn/simple

Hello, World 示例

下面是一个最小可运行的示例，演示如何解析HTML并提取标题：

from bs4 import BeautifulSoup

# 创建模拟HTML文档
html_doc = """
<html>
<head>
    <title>BeautifulSoup入门示例</title>
</head>
<body>
    <h1 class="heading">欢迎学习BeautifulSoup</h1>
    <p id="intro">这是第一个段落。</p>
    <p>这是第二个段落。</p>
</body>
</html>
"""

# 创建BeautifulSoup对象，指定lxml解析器
soup = BeautifulSoup(html_doc, 'lxml')

# 提取并打印页面标题
print(soup.title.string)

逐行解释

  1. from bs4 import BeautifulSoup：从bs4模块导入BeautifulSoup类。bs4是"BeautifulSoup 4"的缩写。
  2. html_doc = "..."：定义了一个包含HTML结构的字符串，这是我们要解析的原始数据。

  3. soup = BeautifulSoup(html_doc, 'lxml')：

    • 第一个参数是要解析的HTML内容
    • 第二个参数'lxml'指定使用lxml解析器（速度快、容错性强）
    • 返回的soup对象是整个解析树的根节点

  4. print(soup.title.string)：

    • soup.title：直接访问title标签，返回第一个<title>元素
    • .string：获取标签内的文本内容

运行结果

BeautifulSoup入门示例

解析器选择建议：

  • lxml：速度最快，容错能力强，推荐用于生产环境
  • html.parser：Python内置，无需额外安装，但速度一般
  • html5lib：最接近浏览器解析方式，容错性最强，但速度最慢

3. 核心概念解析

BeautifulSoup解析HTML后会生成4类核心对象，理解这些概念是熟练使用的基础。

核心对象类型

  1. BeautifulSoup对象：整个解析树的根对象，代表完整的HTML/XML文档，是所有操作的入口点。
  2. Tag对象：对应HTML中的标签（如<div>、<a>、<p>），可以获取标签名、属性和文本内容。
  3. NavigableString对象：标签内的纯文本内容（不包含标签本身）。
  4. Comment对象：特殊的NavigableString，对应HTML注释（如<!-- 这是注释 -->）。

概念关系图

graph TD
    A[BeautifulSoup对象<br/>文档根节点] --> B[Tag对象<br/>HTML标签]
    B --> C[NavigableString<br/>标签内文本]
    B --> D[Comment对象<br/>HTML注释]
    A --> E[find/find_all方法<br/>定位Tag]
    A --> F[select方法<br/>CSS选择器]
    B --> G[获取属性<br/>tag.attrs/标签名]
    B --> H[获取文本<br/>tag.string/get_text]

核心概念详解

Tag对象操作：

# 获取标签
title_tag = soup.title  # 获取第一个title标签
print(title_tag.name)   # 输出标签名：'title'

# 获取属性
link_tag = soup.a       # 获取第一个a标签
print(link_tag['href']) # 获取href属性
print(link_tag.attrs)   # 获取所有属性字典

# 获取文本
print(title_tag.string)      # 获取标签内文本（无嵌套时）
print(soup.h1.get_text())     # 获取标签内所有文本（含子标签）

NavigableString操作：

# 获取标签内的纯文本
text = soup.p.string  # 获取第一个p标签的文本内容
print(type(text))     # <class 'bs4.element.NavigableString'>

Comment对象处理：

from bs4 import Comment

html_with_comment = "<b><!-- 这是一个注释 --></b>"
soup_comment = BeautifulSoup(html_with_comment, 'lxml')
comment = soup_comment.b.string

# 判断是否为注释
if isinstance(comment, Comment):
    print("这是注释内容:", comment)

查找方法对比

方法作用返回值适用场景
soup.tagname直接访问第一个匹配的Tag简单快速定位
find(name, attrs)查找第一个匹配项Tag对象或None提取唯一元素
find_all(name, attrs)查找所有匹配项Tag对象列表批量提取数据
select(css_selector)CSS选择器Tag对象列表熟悉CSS语法时使用

4. 实战演练：爬取新闻网站标题

让我们通过一个真实项目来巩固所学知识。我们将模拟爬取一个新闻网站的标题、链接和摘要。

需求分析

我们需要从一个新闻网页中提取以下信息：

  • 新闻标题
  • 新闻链接
  • 新闻摘要
  • 发布时间

方案设计

使用requests库获取网页内容（模拟），然后用BeautifulSoup解析数据。我们将使用以下功能：

  1. find_all()批量查找新闻条目
  2. CSS选择器定位嵌套元素
  3. get()方法提取属性
  4. get_text()提取文本

完整代码实现

from bs4 import BeautifulSoup

# 模拟新闻网页HTML结构
news_html = """
<!DOCTYPE html>
<html>
<head>
    <title>科技新闻网</title>
</head>
<body>
    <div class="news-container">
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/1">AI技术突破新里程碑</a>
            </h2>
            <p class="news-summary">人工智能在图像识别领域取得重大进展，准确率提升至98%。</p>
            <span class="publish-time">2025-01-15</span>
        </div>
        
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/2">量子计算商业化进程加速</a>
            </h2>
            <p class="news-summary">多家科技巨头宣布量子计算云服务正式上线，标志着量子计算进入实用阶段。</p>
            <span class="publish-time">2025-01-14</span>
        </div>
        
        <div class="news-item">
            <h2 class="news-title">
                <a href="https://example.com/news/3">5G网络覆盖率达95%</a>
            </h2>
            <p class="news-summary">最新数据显示，全国5G网络覆盖率已超过95%，为物联网发展奠定基础。</p>
            <span class="publish-time">2025-01-13</span>
        </div>
    </div>
</body>
</html>
"""

# 创建BeautifulSoup对象
soup = BeautifulSoup(news_html, 'lxml')

# 查找所有新闻条目
news_items = soup.find_all('div', class_='news-item')

# 遍历提取每条新闻的信息
print("=" * 60)
print("科技新闻网 - 最新资讯")
print("=" * 60)

for i, item in enumerate(news_items, 1):
    # 提取标题和链接
    title_tag = item.find('a')
    title = title_tag.get_text(strip=True)
    link = title_tag.get('href')
    
    # 提取摘要
    summary_tag = item.find('p', class_='news-summary')
    summary = summary_tag.get_text(strip=True) if summary_tag else "无摘要"
    
    # 提取发布时间
    time_tag = item.find('span', class_='publish-time')
    publish_time = time_tag.get_text(strip=True) if time_tag else "未知时间"
    
    # 输出结果
    print(f"\n新闻 {i}:")
    print(f"标题: {title}")
    print(f"链接: {link}")
    print(f"摘要: {summary}")
    print(f"发布时间: {publish_time}")

print("\n" + "=" * 60)
print(f"共提取 {len(news_items)} 条新闻")
print("=" * 60)

运行说明

将上述代码保存为Python文件并运行，你会看到格式化的新闻列表输出。每个新闻条目都包含标题、链接、摘要和发布时间。

代码亮点：

  1. 使用class_='news-item'查找所有新闻容器（注意class_的下划线避免关键字冲突）
  2. 使用.get_text(strip=True)去除文本中的多余空格和换行
  3. 使用.get('href')安全获取属性，避免属性不存在时报错
  4. 使用条件判断处理可能缺失的元素，增强代码健壮性

5. 最佳实践与常见陷阱

常见错误及规避方法

错误1：直接使用class作为参数

# ❌ 错误做法
soup.find_all('div', class='content')  # SyntaxError

# ✅ 正确做法
soup.find_all('div', class_='content')  # 加下划线避免关键字冲突

错误2：属性不存在时直接访问

# ❌ 错误做法
link = soup.a['href']  # 如果a标签没有href属性会报错

# ✅ 正确做法
link = soup.a.get('href')  # 属性不存在返回None，安全
link = soup.a.get('href', '#')  # 可设置默认值

错误3：混淆string和get_text()

html = "<p>Hello <b>World</b></p>"
soup = BeautifulSoup(html, 'lxml')

# ❌ 错误理解
print(soup.p.string)  # 输出None，因为有嵌套标签

# ✅ 正确做法
print(soup.p.get_text())  # 输出：Hello World

错误4：忘记指定解析器

# ❌ 不推荐：依赖默认解析器
soup = BeautifulSoup(html_doc)

# ✅ 推荐：明确指定解析器
soup = BeautifulSoup(html_doc, 'lxml')

最佳实践建议

  1. 选择合适的解析器

    • 生产环境使用lxml（速度+容错）
    • 开发测试可用html.parser（无需安装）
    • 特殊场景用html5lib（容错性最强）

  2. 使用CSS选择器提高效率

    # 传统方法
div.find('div', class_='container').find_all('a')

# CSS选择器（更简洁）
soup.select('.container a')

  3. 处理中文编码

    # 读取文件时指定编码
with open('page.html', 'r', encoding='utf-8') as f:
    soup = BeautifulSoup(f, 'lxml')

  4. 异常处理

    try:
    title = soup.title.string
except AttributeError:
    title = "无标题"

  5. 性能优化

    • 使用limit参数限制返回数量：find_all('a', limit=10)
    • 只在必要时调用prettify()（格式化输出耗时）
    • 大文档考虑分块解析

注意事项

  1. BeautifulSoup只能解析静态HTML，对于JavaScript动态渲染的内容，需配合Selenium或Playwright
  2. 它不负责下载网页，需结合requests、urllib等网络库使用
  3. 遵守网站的robots.txt协议，合理设置请求频率，避免给服务器造成压力
  4. 注意反爬虫机制，适当添加User-Agent等请求头

6. 进阶指引

高级功能

BeautifulSoup除了基础的数据提取，还提供了强大的修改功能：

# 修改标签内容
soup.title.string = "新标题"

# 添加新标签
new_tag = soup.new_tag('div')
new_tag['class'] = 'new-item'
soup.body.append(new_tag)

# 删除标签
soup.p.decompose()  # 彻底删除标签及其内容
soup.p.extract()    # 从文档中移除并返回该标签

生态扩展

结合其他库构建完整的数据采集系统：

  • requests/httpx：发送HTTP请求获取网页
  • Selenium/Playwright：处理动态JavaScript渲染
  • pandas：将提取的数据保存为CSV/Excel
  • sqlite3：将数据存储到数据库

学习路径

  1. 初级阶段：掌握基本的标签查找和属性提取
  2. 中级阶段：熟练使用CSS选择器和文档树遍历
  3. 高级阶段：学习修改文档树、处理复杂嵌套结构
  4. 实战应用：结合requests完成完整爬虫项目

推荐资源

BeautifulSoup是Python网页解析领域的"瑞士军刀"，掌握了它，你就拥有了从网页中提取数据的强大能力。无论是数据采集、内容分析，还是自动化测试，它都能成为你得力的助手。保持练习，不断探索，你将发现更多精彩的应用场景！

分区表是 PostgreSQL 的核心特性之一，但有一个问题即便资深用户也常会产生困惑：

在涉及分区时，ALTER TABLE 语句的具体执行逻辑是怎样的？

操作是否会同步至各分区？是否对新建分区生效？ONLY 关键字是否实现预期效果？为何部分命令可在主表执行却无法在分区执行，或反之？

当前 PostgreSQL 官方文档对单个 ALTER TABLE 子命令的说明较为完善，但很少系统性地解释它们在分区表场景下的整体行为。这导致真实行为往往只能通过反复试验才能被发现。

本文基于一次系统性验证，总结了 ALTER TABLE 在分区表上的行为规律，将零散规则归纳为一套统一的分类模型。

问题本质：“不一致”并不等同于“未定义”

在 PostgreSQL 社区中，ALTER TABLE 在分区表上的行为常被描述为“不一致”。实际上，更深层的问题在于：

  • 行为规则是存在的；
  • 但规则分散在不同的代码路径、报错信息以及历史设计决策中；
  • 且未以可预测结果的方式进行文档化说明。

在缺乏清晰认知模型的情况下，即便是简单问题也难以回答：

  • 在父分区表上执行操作后，现有分区会发生什么？
  • 后续新建的分区是否会继承相关设置？
  • ONLY 是否能够阻止传播，还是会被直接忽略？
  • 能否为单个分区单独覆盖相关配置？

ALTER TABLE 子命令的验证方法

为厘清上述问题，本次研究针对所有 ALTER TABLE 子命令，在分区表场景下采用统一的问题框架开展测试验证。

四个评估维度

针对每个子命令，均围绕以下四个核心问题展开验证：

  1. 传播性（Propagation）
    在父分区表上执行操作后，是否会传播到已有分区？
  2. 新分区继承性（Inheritance for new partitions）
    后续新建的分区是否会继承父表的设置？
  3. ONLY 的影响（Effect of ONLY）
    ONLY parent_table 是否如文档所述，能够阻止操作传播？
  4. 独立性（Independence）
    父表与各个分区是否可以拥有不同的配置值？

通过这四个维度，可以将模糊的“不一致”转化为明确、可验证的行为特征。

范围与版本说明

本分析基于 PostgreSQL 18 的开发版本行为（截至 2026 年初）。所有结论均在 PostgreSQL 18 上验证。部分细节在早期版本中可能存在差异，未来版本也可能随着分区机制的演进而发生变化。

分区表上 ALTER TABLE 的分类模型

基于上述评估维度，ALTER TABLE 的子命令可自然划分为 15 类，每一类对应一种明确的行为模式。

该分类仅作为执行逻辑的参考依据，而非价值判断。

C1 – 仅作用于父表的结构性变更

此类特征如下：

  • 仅可在分区表上使用；
  • 在分区上执行会失败；
  • 不支持 ONLY 关键字。

包含的子命令：

  • ADD COLUMN（添加列）
  • DROP COLUMN（删除列）
  • SET DATA TYPE（修改数据类型）
  • DROP EXPRESSION（删除表达式）
  • ADD GENERATED AS IDENTITY（添加自增标识列）
  • ADD GENERATED（添加生成列）
  • SET sequence_option（设置序列参数）
  • RESTART（重启序列）
  • ALTER CONSTRAINT（修改约束）

此类命令用于定义分区表的整体结构，必须保持全局一致性。

C2 – 可传播且可继承的变更

此类特征如下：

  • 从父表传播至所有已有分区；
  • 遵循 ONLY 关键字的作用规则；
  • 新建分区会继承主表的相关配置；
  • 支持为单个分区单独覆盖配置。

包含的子命令：

  • SET DEFAULT（设置默认值）
  • DROP DEFAULT（删除默认值）
  • SET EXPRESSION AS（设置表达式）
  • SET STORAGE（设置存储参数）
  • DROP CONSTRAINT（删除约束）
  • ENABLE/DISABLE TRIGGER（启用 / 禁用触发器）

这是多数场景下对 ALTER TABLE 行为的直观预期。

C3 – 可传播但不支持新分区继承

此类别仅包含一个子命令：

  • SET STATISTICS（设置统计信息参数）

执行逻辑与 C2 类基本一致，区别在于操作仅同步至现有分区，对后续新建分区不生效。若默认认为配置可自动继承，该特性易引发使用偏差。

C4 – 父表与分区完全独立

此类特征如下：

  • 不传播；
  • 不继承；
  • 允许父表与分区设置不同值；
  • 支持 ONLY 关键字，但无实际执行效果。

包含的子命令：

  • SET/RESET (attribute_option = value)（设置 / 重置属性参数）
  • ENABLE/DISABLE [REPLICA | ALWAYS] RULE（启用 / 禁用复制 / 永久规则）
  • ENABLE/DISABLE ROW LEVEL SECURITY（启用 / 禁用行级安全策略）
  • NO FORCE / FORCE ROW LEVEL SECURITY（不强制 / 强制行级安全策略）
  • OWNER TO（修改表属主）
  • REPLICA IDENTITY（设置复制标识）
  • SET SCHEMA（修改所属模式）

在行为上，父表与分区几乎等同于彼此独立的普通表。

C5 – 独立设置，但新分区继承

此类别仅包含一个子命令：

  • SET COMPRESSION（设置压缩参数）

执行逻辑与 C4 基本一致，但新建分区会继承父表设置，已有分区不受影响。

C6 – 强制传播类命令

此类别仅包含一个子命令：

  • ADD table_constraint（添加表级约束）

执行逻辑与 C2 类基本一致，但不允许使用 ONLY，系统会强制保证所有分区一致。

C7 – 仅适用于叶子分区的命令

此类特征如下：

  • 无法在分区表上使用；
  • 只能在叶子分区上执行。

包含的子命令：

  • ADD table_constraint_with_index（添加带索引的表级约束）
  • ALTER CONSTRAINT ... INHERIT / NO INHERIT（修改约束的继承 / 取消继承属性）
  • CLUSTER ON（按指定索引聚簇）
  • SET WITHOUT CLUSTER（取消聚簇）
  • SET LOGGED / UNLOGGED（设置日志记录 / 无日志记录）
  • SET (storage_parameter)（设置存储参数）

C8 – 父表作用域，但允许分区覆盖

此类别仅包含一个子命令：

  • VALIDATE CONSTRAINT（验证约束）

执行逻辑与 C1 类基本一致，区别在于验证动作定义在父表层级，但各分区的验证状态可以不同。

C9 – 条件继承型

此类别仅包含一个子命令：

  • SET ACCESS METHOD（设置访问方法）

执行逻辑与 C2 类基本一致，但新分区是否继承取决于父表是否显式设置；若未设置，则使用 GUC 默认值。

C10 – 不传播，但新分区继承

此类别仅包含一个子命令：

  • SET TABLESPACE（设置表空间）

已有分区保持不变，新建分区继承父表设置。接受 ONLY，但无实际效果。

C11 – 在父表上为空操作

此类别仅包含一个子命令：

  • RESET (storage_parameter)（重置存储参数）

此类命令在分区表上不会报错，但也不会产生任何实际变化。

C12 – 不支持分区表的命令

包含的子命令：

  • INHERIT（继承表）
  • NO INHERIT（取消继承表）

在概念上与声明式分区机制不兼容。

C13 – 仅绑定父表元数据

包含的子命令：

  • OF type（绑定复合类型）
  • NOT OF（取消复合类型绑定）

仅作用于分区表本身，在分区上执行会失败。接受 ONLY，但无实际效果。

C14 – 按普通表处理

仅包含一个子命令：

  • RENAME（重命名）

无传播、无继承，也不存在分区相关的特殊行为。

C15 – 分区管理类命令

包含的子命令：

  • ATTACH PARTITION（挂载分区）
  • DETACH PARTITION（卸载分区）

用于操作分区结构本身，而非表属性。

结语

在 PostgreSQL 官方文档未对分区表的 ALTER TABLE 语句执行逻辑进行明确、体系化说明前，本分类模型可作为重要的参考依据。

若日常工作中频繁使用分区表，建议将该认知模型作为常用参考，在生产环境执行相关命令前，先确认其所属的执行类别，再开展操作，以降低不可预期风险。

原文链接：

https://www.highgo.ca/2026/01/21/understanding-alter-table-be...

作者：Chao Li

HOW 2026 议题招募中

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

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您在 2026 年 2 月 27 日截止日期前，提交您的技术见解。

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

作者｜快手技术团队

审校 | 陈姚戈

编者按

以 ChatGPT 问世的 2022 年为起点，大模型技术进入公众视野已经超过三年。人们普遍见证了 AI 作为新型生产工具对生产力的重塑，但对科技企业而言，这远不止是多了新技术或新产品那么简单。

作为前沿技术的掌握者与实践者，科技公司必须率先完成自身的转型：以极快的速度，不惜试错和阵痛，找到大规模、稳定、高效使用 AI 的组织路径。过去十年，“数智化”浪潮主要聚焦于传统企业如何借助外部工具实现数字化；而如今，AI 正在倒逼科技公司自身成为变革对象。它们必须在人才结构、工具体系、协作流程乃至组织文化上同步革新，否则将难以在 AI 时代维持竞争力。

正是在此背景下，快手首次系统性披露其自 2023 年以来的 AI 研发范式升级历程。

今天，快手发布了名为《快手万人组织 AI 研发范式 跃迁之路：从平台化、数字化、精益化到智能化》的 1.6 万字长文。文章由快手研发效能委员会审稿、经内部深度复盘整理，罕见地呈现了一家超大型科技企业在 AI 时代推进组织级提效的完整图景。

你会在这篇文章中看到快手研发范式的三阶段演进路径，以及快手技术团队对 AI 赋能组织提效的思考：

  • 三阶段演进路径：

  • 平台化、数字化、精益化 （2023-2024 年）：

  • 建设一站式研发平台，并标准化需求和工程流程，工具渗透率>95%，流程自动化>94%

  • 通过建立效能模型，识别交付瓶颈，提升需求交付效率，人均需求吞吐量提升 41.57%

  • 智能化 1.0 （2024 年 6 月 -2025 年 6 月） ：聚焦用 AI 提升个人开发效率

  • 建设并推广 AI 编码 / 测试 /CR 等能力，AI 代码生成率超过 30%- 但发现矛盾——个人主观编码效率提升显著，但组织需求交付效率却基本不变

  • 智能化 2.0 （2025 年 7 月以后）：聚焦用 AI 提升组织整体效能

  • 找到了 AI 研发范式升级路线：L1 AI 辅助（Copilot）→ L2 AI 协同（Agent）→ L3 AI 自主（Agentic）

  • 探索出了支撑路线达成的系统性实践：AI x 效能实践、AI x 研发平台、AI x 效能度量

  • 关键洞察与经验：

  • AI 研发提效陷阱： 用 AI 开发工具 ≠ 个人提效 ≠ 组织提效

  • 本质问题：如何将个人提效传导到组织提效

在全球范围内，如此系统、坦诚且具备工程细节的 AI 提效实践总结仍非常稀缺。对于所有正在探索 AI 落地路径的企业而言，这份来自一线的复盘值得细读。

这也预示着一个新的节点正在到来。当像快手这样的头部公司开始对外输出其 AI 落地的方法论与效能成果，整个行业将面临一种隐形的压力——组织能否高效驾驭 AI，将成为其在 AI 时代竞争力的重要衡量方式。

可以预见，2026 年将成为一批先行者集中展示阶段性成果的窗口期。这些成果首先会以研发效率、工程体系和组织方法论的形式呈现；再过几年，更会传导到公司的财务表现与人才吸引力上。

到那时，所有公司都将不得不回答同一个问题： AI 时代，我们如何重构自己？

快手报告标题：

《 快手万人组织 AI 研发范式 跃迁之路：从平台化、数字化、精益化到智能化 》

AI 研发提效陷阱：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效

早在 2024 年，快手就建设了 AI 编程工具 Kwaipilot，并发布给公司内 10000+ 研发人员使用。经过持续的深度优化和推广，快手整体的 AI 代码生成率，在严格度量口径下（AI 生成并入库的代码行 / 新增代码行）从 1% 达到了 30%+，甚至部分业务线达到了 40%+。同时，在非编码环节，也衍生出了很多 AI 提效工具，比如智能 CR（CodeReview）、智能测试用例生成、智能单元测试等等，但经过大量的调研和数据分析，我们发现了这个不等式：

“用 AI 开发工具 ≠ 个人提效 ≠ 组织提效”

如果以企业的研发效能提升为目标，我们发现：

  • 对研发工程师而言 ：深度使用 AI 开发工具，代码生成率很高，个人主观体感上编码效率提升了 20-40%，但并不代表真正的“个人提效”，因为在现实中，大部分工程师并没有接纳更多的需求，个人需求的交付数没有显著提升。

  • 对大型组织而言：我们发现部分 AI 用的好的工程师，确实可以更快更多的完成开发任务，但组织整体的需求吞吐量没有明显提升，需求交付周期也没有明显缩短。

从《2025 年 DORA 报告：人工智能辅助软件开发现状调查报告》中能看到，这也是业界普遍存在的问题。如报告中所述（如下图所示），在对 AI 提效的结果的预估上，各企业普遍对个人效能的提升有信心，而对团队效能的提升预估非常小。

在快手，我们发现仅推广研发各阶段的 AI 提效工具，已经偏离了企业研发效能提升的核心目标，最终必然会导致 2 个问题：

  • 投入很大，但企业整体的研发效率提升不明显 ：虽然通过调研很容易能收到大量的个人效率提升反馈，但个人提效无法传导到组织提效。

  • 效能平台开始割裂 ：传统 DevOps 平台仍承担研发主流程，每天被高频的使用，却无法演进到下一代 AI 研发平台（顶多扩展一些单点的 AI 功能）。新生的 AI 编程工具，只取代了传统 IDE，又无法与老平台协同演进。

为了解决上述 2 个问题，我们从 2025 年开始进行了更激进的探索和变革，我们称之为“ AI 研发范式升级”，最终，通过一系列的实践，找到了一条能借助 AI 能力平滑通往研发智能化的路径。

正逢 2025 年年末，我们把镜头拉远，将时间回溯到 3 年前，对快手研发效能的演进做一个系统性总结，有踩过的坑，也有做出的突破，希望为更多企业提供经验和参考。

总览：快手 研发效能 演进路线

快手有 10000+ 研发、8+ 业务线，研发效能的演进可以分为 3 个大阶段，如上图所示：

  • 阶段 1：平台化、数字化、精益化（2023-2024 年） ：通过建设三端一站式研发平台、需求流 & 工程流标准化，解决了研发交付流程散乱，既无标准也无数据的问题。再通过建立效能模型，识别交付瓶颈，提升需求交付效率。

  • 阶段 2：智能化 1.0（2024 年 6 月 -2025 年 6 月）：在研发全流程中开始建设 AI 能力，包括 AI 编码、AI 单元测试、AI CR、AI 手工用例生成、AI OnCall 等等，并进行全员推广。经过 1 年多的实践，基本上完成了全员普及，在主观调研中，开发人员主观体感上效率提升 20-40%，在客观数据上，AI 代码生成率也在持续增长。但同时也发现了矛盾点：需求交付效率基本不变，即个人效率提升未能有效传导到组织效率提升。

  • 阶段 3：智能化 2.0（2025 年 7 月 +）：从“推广 AI 工具，让开发者使用”回归到了更本质的元问题：如何用 AI 提升需求端到端交付效率？经过半年多的探索，终于找到了新的路径，并得到了充分的数据验证。我们称这套解决方案为“AI 研发范式”，主要解决了 3 个问题：

  • AI x 效能实践：如何用 AI 提升工程师的生产力，并将个人提效传导到组织提效。

  • AI x 研发平台 ：支撑需求交付全流程（从分析到编码再到发布）的研发工具链，如何整体演进到智能化？即下一代的智能研发平台，应该是什么样的？而不仅仅是只推广 AI 编程工具或在原有工具链上增加一些散点的 AI 提效功能。

  • AI x 效能度量 ：如何在效能度量指标的基础上，构建 AI 提效的指标体系，能清晰的量化过程和结果，为组织级的 AI 研发范式升级提供有效指引。

阶段 1：平台化、数字化、精益化（2023-2024 年）

这个阶段的解决方案，业界相关的分享已经非常多了，但从实际情况看，在千人规模的技术团队中，能做好、做深、做透的实践非常稀有。

因此，我们直接分享 1 个具体的案例，以便能更好的看清快手的研发效能从基础建设到效能提升的全过程，这也是我们之所以能更快跃迁到 AI 研发范式的重要基石。案例来源是快手最核心的技术团队之一—— 主站技术部 ，是快手 APP 的研发团队，开发人员规模千人以上。

背景：了解快手的研发效能基建

首先，主站技术部的实践依托一套公司级的研发效能基建，由横向团队「研发效能中心」提供，如下图所示，这是在 2023 年快手当时的研效基建，主要分为：

  • 效能平台：项目管理平台（Team）、三端一站式研发平台（KDev（服务端）、KFC（前端）、Keep（客户端））、琅琊阁（效能度量）、质量平台（KTest 等）

  • 效能实施：效能 BP 专家（Business Partner），负责深入各业务线，提供专业支持。

了解快手的研效基建后，下面开始重点介绍主站技术部的实践过程。

Step1：依托工具推广，实现流程标准化

解决的问题

需求流和工程流均不标准，开发人员的工作分散在各处，日常开发体验差、学习成本高，又无法实施有效的质量防护措施，还不能沉淀准确的研发过程数据持续度量与改进。

达成的效果

通过推广三端一站式研发平台，定义需求、研发的标准流程，将研发全流程标准化。核心度量指标与结果如下：

实践过程

主要难点

  • 用一套产品设计尽量满足多样化的研发场景 ：工具一边建设一边落地，且需兼容之前散乱各种不同的研发模式和习惯。

  • 服务端（KDev 平台） ：需要支持一些特殊的研发模式（比如 Master 模式、窗口模式）。

  • 客户端（Keep 平台）：移动端研发场景多样化，包括 APP、动态化、 SDK。

  • 前端（KFC 平台）：前端应用类型多（Web、Node、低码、KRN（动态化）、小程序），研发流程和习惯散乱。

  • 研发流程规范差异大 ：不同团队间，不同的技术栈的研发流程上存在一定差异，包括研发流程配置、流程各阶段信息字段、单点环节所需的工具能力不同等。

  • 用户迁移成本大 ：迁移过程中，需持续关注和解决用户问题，包括用户体验变化、用户学习成本、用户情绪。

  • 落地时间紧迫 ：一般互联网大厂类似的工作基本会持续 6 个月以上，快手主站只用了 1 个多月。

实施要点

  • 精准的解决方案设计：

  • 服务端（KDev 平台） ：精准的打造了 4 套标准研发模式，适配了主站实际研发情况。

  • 客户端（Keep 平台）：一套平台底层能力，支撑 3 种移动研发场景；通过可配置与定制化能力，满足不同团队流程规范与管理诉求（自动翻转配置、流程与质量卡点配置、团队定制化模板）。

  • 前端（KFC 平台）：支持 80% 以上前端应用类型，并通过 8 个流程模板、适配 5 个内部自建的插件，兼顾了前端差异化研发流程和用户习惯。

  • 以用户满意为导向 ：提供完整的迁移配套服务，降低用户迁移成本。主要包括：

  • 产品质量专项 ：用户 BUG 日结。

  • 用户体验专项 ：持续深度用户访谈，识别体验问题，并优化。5 周内，交付了 73 个功能 & 体验需求。

  • 用户培训与激励 ：通过 12 次培训，50+ 线下访谈，7x24 小时 OnCall、200+ 人次的用户激励，提升用户对产品的接受度。

  • 数据驱动团队级推广：每周度量进度，驱动各部门接口人推广。

经验总结

可能大家会有疑惑，为什么三端分别是 3 个平台，而不是一套平台。因为从实际情况看，服务端、前端、客户端的底层模式、流程都有比较大的差异，强行整合，不仅对产品用户收益不大，反而牺牲了要兼容不同端的流程、习惯差异化的灵活性，给标准化的推进增加难度。因此，我们在用户层面上，还是三套平台，分别解决各自领域的问题，但在底层的基础能力用的是一套，比如流水线、权限等。

Step2：建设效能度量体系

主站的研发效能早在 2022 年就开始启动了，当时在探索北极星指标阶段，缺少度量体系，更多是根据一线开发者的开发痛点反馈，进行偏工具流程等的优化，没有核心指标的牵引，项目都无法推进，更谈不上论证给业务带来的价值。在 2023 年 3 月再次重启效能项目时，北极星指标初步定义为 “有效需求吞吐量”，但是当时需求有效性的衡量难度太大，内部无法达成共识，项目推进困难，而且也无法看清业务堆积和开发人效情况。

随着流程标准化的落地，研发数据的置信度大幅提升，为效能度量提供了土壤。因此，我们定义了以“人均交付产品需求数” 为北极星目标来看清业务开发交付能力，同时观测需求颗粒度（避免单一指标跑偏：度量什么得到什么，种瓜得瓜种豆得豆）来保障交付提升的良性发展，逐步建立了一套更全面的指标体系（多指标互相佐证约束，hack 成本极高）来体现业务交付产能和交付效率，以及组织和个人效率情况。

快手的效能度量体系如下图所示：

注明：SP：Story Point，快手用于度量需求工作量的单位。

借助这套全面完备的指标体系，我们不仅避免了依赖单一指标可能导致的偏差，还有效防范了效能数据被 hack 的风险，确保了效能数据的准确性和可靠性。

Step3：效能问题分析与改进

有效能度量体系，首先我们可以为任何一个业务线做系统性的体检，如下图所示，依托数据和经验，可以逐一拆解出核心的优化专项，并以效能项目的形式实施。

其次，在研发流程和管理上，也能洞察出更多平时看不见的 Case，深入改进，下面是 2 个具体的洞察与改进案例：

Case1：通过「研发活动在线化率」分析，深挖出架构不合理问题

上图是主站技术部下级各团队的研发活动在线化率，其中有一个团队出现了数据异常，分析之后可以发现存在不少问题：

  • 横向来看，这个团队的研发活动在线化率处于中上水平，但产品需求投入占比只有 59%，处于末尾水平。而且产品需求中体验优化占比11.44%，又是各团队中最高的。那么问题来了，“时间都去哪儿了？”

  • 再下钻一层，这个团队的缺陷占比 14%，也是各团队中最高的，且 Oncall& 排障占比 6% 也不低。

因此，数据表明，此团队可能存在的问题：在缺陷问题、体验问题、Oncall& 排障消耗了团队大量的投入，以至于无法消化更多产品需求。所以，通过对团队核心成员的调研和访谈，基本可以找到根因：和客户端的架构劣化有关，比如：

  • 反馈 1：新需求开发时，上手门槛特别高，很多需求会涉及到多个模块开发，这会涉及到自己不熟悉的模块，因为架构分层结构不合理，模块耦合度太高，往往需要花大量的时间去熟悉其他模块的代码，最近做了一个新需求，评估是 3 天的工作量，2 天都在看代码，实际的开发联调只有 1 天。

  • 反馈 2：模块边界不清晰，代码杂糅一起，新需求的代码，可能会影响到已有功能，导致旧功能的 BUG，而且这些 BUG 在回测时，不容易被发现，导致问题漏测逃逸到线上。

通过效能的客观数据再结合主观调研，就可以看清“架构劣化”这种深层次问题，也可以对症下药了。解法是这个团队实施了 2 个技术专项：

  • 客户端的架构升级：从根本上解决因为架构问题带来的交付效率低和交付质量差的问题。

  • 体验优化：集中优化重点场景的体验问题。

随着这两个专项的落地上线，这个团队的效能数据已经有所改善，产品需求投入占比已经提升到 64%，体验优化占比下降到 6%。

Case2：通过「需求积压率」分析，驱动业务优化需求评审流程和节奏

上图是主站技术部下级各团队的需求积压率数据，有些团队的需求积压率持续保持在 80% 以上，意味着需要近一个月的时间才能消化这些积压的需求。这种情况可能存在的问题：

  • 这些被积压的需求，一个月之后，会不会进入排期开发？如果之后会排期开发，说明需求本身的价值还可以，当下是否可以协调资源加快交付？能否可以停掉某些技术需求优先业务交付？是否可以短期加班临时突击？

  • 如果后面不会进入排期，是不是这些需求本身的重要性没那么高？在预评审的时候，是不是可以控制需求的优先级？当前的需求评审流程是否可以优化？

结果

经过一年时间的系统化提效 ，主站提效方面进展显著，人均交付产品需求数 24 年 7 月份同比增长超过 80%。总结下来，主要有效的措施有：

  • 升级研发模式 ：通过动态化、配置化等研发模式，让部分需求可以更快速交付。

  • 研发过程提效：通过 API 在线化管理，测试环境稳定性治理、流水线优化、发布优化等措施，降低研发协作成本以及低价值工作占比。

  • 管理与协同提效 ：通过效能洞察，持续识别团队协作瓶颈，并通过排期优化、测试无人值守、人力调配等措施，支撑需求可顺畅流动。

阶段 2：智能化 1.0（2024 年 6 月 -2025 年 6 月）

从 2023 年 6 月开始，我们开始探索大模型在研效领域的应用，主要有 2 个方向：

  • 编码场景 ：如何用 AI 辅助编码，提升代码生成效率。

  • 非编码场景：在研发全流程里，哪些环节可以通过 AI 能力提升单点工作的效率。

其中，最重要的决策是我们决定自己研发一款 AI Coding 工具：Kwaipilot。它包含了大家见过的所有产品形态：

  • IDE 插件 / AI IDE / CLI：最符合开发人员习惯的几种形态，插件、IDE 可以做续写、问答、智能体代码生成，CLI 则可更灵活的开启代码生成任务。

  • 智能问答引擎 ：有独立的 Web 页面，也会嵌入到上面的产品形态里，为开发人员提供灵活的问答能力。

业界有很多优秀的 AI Coding 产品，比如 Cursor、Claude Code、Krio、Windsurf、Antigravity，快手为什么不选择采购，而是自建呢？其实一年来，我们也一直带着这个疑问在探索，相当于一场大型的公司内部 AB 实验：

从用户体验的角度，我们希望大家“用脚投票”，选择好用的工具：

  • 一方面，我们允许开发同学使用任何 AI Coding 产品，可以团队级采购也可以个人购买。

  • 另一方面，我们研发了 Kwaipilot，对内推广。

从实际效果的角度，我们以“AI 代码生成率”为核心观测指标，持续收集用户 / 团队的反馈，识别不符合预期的代码生成 Case，研究解决方案，再投放实验。最终，经过 1 年的探索，实践结果让我们坚定了继续走自研 Kwaipilot 的路线。

注明：2025 年 12 月开始，在 Kwaipilot 已规模应用后，由于安全原因，探索按代码分级封禁三方 AI Coding 工具，仅涉及到部分开发人员。

下面简单分享一下我们的实践过程，相信大家会更容易理解我们的选择。整个 AI Coding 的推广过程分为 3 个阶段：导入、优化、固化

Step1，导入：推广工具，让开发人员用起来

这个阶段很好理解，我们鼓励开发人员在日常工作中默认使用 AI 编程工具，主要目的是让大家拥抱 AI，在意识和行为上先有一个转变。

当然，各种各样奇怪的使用姿势也会出现：

  • 一些同学，尤其是校招入职的同学，在我们的培训和引导下，会深度使用 Kwaipilot。

  • 一些同学会多种 IDE 混开配合使用。其中，有“团购客”，哪家这个月免费就用谁，也有“付费用户”，主要以个人购买 Cursor 为主。

这里最大的副作用，就是个人编码效率不一定全员获得了提升，通过调研看，出现了明显的两级分化的情况。腾讯研究院出品的《AICoding⾮共识报告》中也揭示了类似的情况：

Step2，优化：推广实践，提升编码效率

我们通过用户数据和技术 Leader 推荐找到了一批公司里的“AI 开发高手”，那些用 AI 辅助编码切实提升了效率的开发人员。

一边重点收集他们在使用过程中的问题，集中想办法解决，一边把他们的优秀开发技巧淬炼出来，提炼共性，形成最佳实践。

这个阶段，我们发现，有别于那些网上随处可见的所谓的 Vibe 编程场景（用对话的形式直接做一些独立应用或小游戏等），在真实的业务需求开发场景里，想用好 AI 编程工具提升效率，有 2 个非常大的门槛：

  • AI 编程工具不“懂”业务和系统 ：我们发现一个规律，无论用多好的代码大模型和 AI 编程工具，“通用的工具只能达到通用的效果”。因为它们不理解公司内大量的业务概念、存量系统、编程规范等这些知识，所以，只能做一些普通的代码续写、函数级的代码生成，但很快就会到瓶颈。如果想进一步提升 AI 代码生成的效果，必须想办法让 AI 编程工具从一个“擅长编程但不懂快手开发场景的临时工”进化为一个“熟悉快手业务的开发工程师”。

  • 人和 AI 协同需要掌握新的开发方法 ：相比传统编程方法，目前已经发展出了一套 AI 辅助编程的新方法。如果开发工程师仅使用 AI 编程工具，却未掌握对应的技巧，不仅不能提效，还可能会降效，比如出现很多“AI 乱改业务代码”、“AI 生成后还要自己删除”等各种不符合预期的情况。

为了降低门槛，在这个阶段我们做了 2 项工作：

  1. 升级 AI 编程工具

上图是优化后的 Kwaipilot 的产品矩阵，都解决了哪些问题呢？一张表可以概览出来：

  1. 沉淀并推广「AI 辅助编码」最佳实践

我们将大量“AI 开发标杆”个人的共性实践沉淀成了一份标准的指南和实战课程，让所有开发工程师，通过学习指南和课程，可以完整的掌握所有关键技巧。

Step3，固化：将 AI 编码能力变为组织机制

既然已经验证了 AI 编码对效率提升的有效性，且已经有了固定的工具、方法、实战课程，接下来就是如何把这些习惯固化在组织的日常工作中，让所有研发人员大范围的升级开发技能。我们主要用了 3 个措施：

  • 增量人员 ：强化入职培训，从源头培养 AI-Native 开发者。

  • 存量人员：牵引 AI 在团队、研发流程、个人工作中渗透。

  • 文化影响：通过活动运营、奖励机制激发更多同学拥抱 AI。主要是一些自下而上能让更多一线研发被看见。

结果

持续的推广，在编码场景上，80%+ 的开发人员都开始用 AI 辅助编码，如下图所示，可以看到 AI 代码生成率每月线上增长。

同时，在非编码场景中，我们在研发流程中建设的单点 Agent 能力也开始在研发平台中陆续透出，用 AI 能力辅助部分研发活动提效。

最终，我们对研发各阶段的 AI 提效情况，做个一个完整的评估：

最后顺便提一下，众所周知，目前大家在业界看到的“代码生成率”指标，包括各大厂披露的、AI 编程工具自己度量，基本都是不置信的，要么只统计了编程工具里的生成的代码和提交的代码作为分子分母，要么是在分母上做了一些限定（比如某些场景下不纳入分母统计）。但因为我们会用这个指标作为公司级 AI 编码推广的目标，因此对度量的精度和置信度要求非常高，一路“踩坑”过来后，最终使用了最严格的度量方法：

  • 分母 ：新增代码行，统计公司内所有最终入库的 Commit 中的代码行。

  • 分子 ：将分母的每一行代码，和 AI 生成的代码进行比对，如果编辑距离<50%（相似度高），则纳入统计。

这套实现无法在 AI 编程工具端实现，需要由公司内部的代码平台、AI 编程工具一起提供数据，并在离线数据层进行精确的计算，计算分母中每一行新增的代码和分子中 AI 生成代码的编辑距离，符合要求才能被统计为分子。

问题

经过 1 年多的努力，从数据上看，研发各环节效率都在提升，尤其是编码环节提升很大。在 AI 热潮下，我们也看到很多开发人员、团队 Leader 都在分享自己效率提升数据和案例，按道理来说，公司整体的研发效能应该提升了吧？我们从全局视角，分析了一个核心业务线的客观研发数据，结果发现了非常反直觉、令人困惑的情况： AI 代码生成率持续在增长，但需求交付效率基本不变 。

为什么呢？我们做了深入的调研，排除了少量个例，观察总结了大多数普遍使用“AI 辅助编码”的开发人员的用法和客观研发数据，发现在真实业务交付场景中，只用“AI 辅助编码”这种开发方法，对需求的开发周期影响非常有限。主要原因如下：

洞察

不过调研中也有额外收获，我们发现在真实的业务需求开发中，已经存在着 3 种不同的开发方法，对效率提升的程度有着根本性的差异。如上图所示。我们把三种开发方法总结出来做了一个定义：

  • AI 辅助编码： 在标准开发流程的基础上，在编码环节，依托 AI 编码工具，使用各种 AI 生成代码的技巧，提升编码效率。如果熟练掌握，可以缩短一部分编码时间，但如上文中的调研归因，由于只是节省了碎片化的编码时间，联通、测试、需求评估等不变，因此对整体的开发任务缩短帮助不大。

  • AI 辅助开发： 在研发全流程的各环节均使用 AI 辅助的方式，提升整体开发效率。需要由人把需求拆分为多个开发任务，不同开发任务调用不能的 AI 能力来完成，再由人来审核和优化产出物。由于从技术设计到编码到测试等各环节都可以节省时间，因此加总起来后，可以将研发任务的开发周期缩短 30% 左右。

  • AI 协同开发： 在某些需求开发中，通过完全用自然语言和 AI 交互的方式（类似业界比较流程的说法 Spec/Vibe 开发）完成需求交付，提升需求端到端交付效率，需求整体的开发周期可以缩短 40% 左右。

举个例子说明，会更容易理解三种开发方法对效能提升程度的影响。例如 1 个需求分解出 2 个开发任务，1 个前端、1 个后端，其中前端工程师接到开发任务，正常评估从设计、开发、测试、合入主干需要 5 天，其中编码 1 天：

  • 如果用「AI 辅助编码」，他自己的评估还是 5 天，只不过相比以前，可以节约一部分时间做一些杂事，但到不了可以接更多开发任务的程度。

  • 如果用「AI 辅助开发」，他可以整体节约 1.5 天，只用 3.5 天就可以完成。但需求整体能不能快，还需要看另一个接任务的同学，以及对应的联调、集成测试、发布的周期。

  • 如果用「AI 协同开发」，首先必须改变协同模式，比如 2 个人均使用这种模式开发或者 1 个人全栈的做，假设 1 个人全栈独立做要 10 天，且不需要和别人集成 & 验证，开发周期可以缩短到 6 天左右。

有了 3 种开发方法的定义，我们就能很容易的评估出理想和现实间的差距，我们取了 1 个业务线 3 个月所有已交付的需求进行分析，发现 50%-70% 的需求，在不改变原有开发流程、规范、人员协同模式的情况下，可以使用提效幅度更大的「AI 辅助开发」模式。此外，还有 2%-10% 的需求，可以更激进的使用「AI 协同开发」。但实际情况上，团队里只有不到 10% 的人在使用「AI 辅助开发」或「AI 协同开发」开发方法，有对 AI 开发特别感兴趣的校招生，也有积极拥抱 AI 喜欢自己探索的资深开发者，但由于人数过少，对团队整体研发模式的变化无法起到带动的作用。

阶段 3：智能化 2.0（2025 年 7 月至今）

上面一个阶段，我们称之为“智能化 1.0”阶段，即以编码场景的 AICoding 为中心提效，并逐步辐射非编码场景的 AI 提效。但主要瓶颈就在于开篇提到的 AI 研发提效陷阱：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效 。

在智能化 1.0 阶段最大的收益是什么呢？大部分研发人员都开始主动使用 AI 开发工具了，同时，找到了个人提效的最佳实践。但接下来才是深水区，我们需要回归效能提升的元问题：“如何用 AI 提升需求端到端交付效率？” 。

经过充分的复盘、洞察和验证，我们找到了新的可行的路径，并重新设计了解决方案，我们称之为“AI 研发范式”，它的实践体系框架，如下图所示：

我们根据需求交付中 AI 的参与程度，定义了“需求 AI 研发成熟度”，将需求划分为 3 个等级 L1、L2、L3，不同等级的需求，需要使用对应的开发方法。不同开发方法，对底层研发工具的 AI 能力也有不同程度的依赖。用一张表对上图做一下解读：

具体实施上整体有 3 步：

Step1，AI x 效能平台：建设能同时支持多种研发模式、可自进化的智能研发平台

解决的问题：

  • 能支持多种研发模式 ：不同 AI 研发成熟度的需求，它们的交付流程都是一样的，差异点在于开发方法。因此我们无法为不同的需求、不同的开发方法匹配不同的平台，而是要思考如何用一套平台，来支撑多种开发方法：完全不使用 AI 的标准开发流程、只用 AI 辅助编码的开发流程、更激进的使用 AI 辅助开发或协同开发的开发流程，都应该在同一个平台上完成。这样，我们的需求交付效率，才可以随着人的能力的提升、AI 能力的提升，持续变快。

  • 产品形态可进化 ：产品形态随主要研发模式的变化持续演化，从人主导最终变为由 AI 主导；能与传统平台协同进化。

  • AI 效果可进化：能随大模型的升级、Agent 技术的升级、企业 / 个人知识的丰富，持续提升 AI 效果。

解决方案 ：建设下一代智能研发平台

如上图所示，有 4 个关键点：

下面重点介绍下为了支撑组织级研发范式跃迁，Flow 这种子产品形态的独特优势。

  • 从需求交付视角看 ：同一个需求，开发者可以结合自身对 AI 的理解和开发技能的掌握，在同一种产品形态上选择不同开发方法。

  • 标准开发 / AI 辅助编码 ：工作流中所有节点，完全由人工来完成和推进。其中“编码”节点会跳转到 IDE 中，可以用 AI 辅助编码。对用户而言，收益相对来说最小，和原来相比，由于 Flow 的每个节点内嵌或自动兼容了各工具平台的功能，因此仅节约了用户平台跳转的切换与学习成本。用这种模式交付的需求，会被度量为 L0/L1 级需求（AI 辅助（Copilot））。

  • AI 辅助开发 /AI 协同开发 ：工作流中多个关键节点均有 AI 完成，人进行结果审查。多个节点之间的上下文可以有效传递，比如 AI 完成需求分析、技术设计后，产出的 AI 友好结构化文档可以自动传递到 AI 编码节点，以提升代码生成的准确性。有些节点暂时无法由 AI 完成的，比如“提测”节点，仍然由人来操作。用这种模式交付的需求，会被度量为 L2 级需求（AI 协同（Agent））。

  • AI 自主开发 ：部分需求可以实现全流程 AI 完成，人只需要在需求上线前或上线后进行审核。这种模式下，整个 Flow 是全自动运行的不需要人工参与。用这种模式交付的需求，会被度量为 L3 级需求（AI 自主（Agentic））。

  • 从开发者视角看 ：整个过程依然非常丝滑和简洁，下图是一个需求交付中 Flow 的整个工作过程，大家可以感受一下：

Step2，AI x 效能实践：以需求为中心，导入「AI 研发模式」，实现需求端到端提效

支撑「AI 研发模式」的方法和平台都有了，这个阶段的关键是如何把这些作用在团队日常交付的需求上。我们分 3 个层面落地：

个人级实践 ：导入「AI 辅助开发 / AI 协同开发」开发方法，并树立标杆

首先人的开发方法要变化。我们重复了第一阶段“优化”与“固化”的实践，让大部分研发人员从“AI 辅助编码”的方法升级成“AI 辅助开发”，让小部分专业能力更强的人员，选修“AI 协同开发”方法。我们同样通过实战课程、典型案例、人员培训等手段，对人的开发方法进行升级。

当然，即使这样，从数据上看，个人用 AI 提效的效果还是存在两极分化的情况。我们对 2025 年 6 月 -12 月的数据进行了分析得到如下结论：

团队级实践：导入「AI 研发模式」，重塑流程、分工，提升所有需求的交付效率

通过管理导向、各种活动的形式，鼓励团队 Leader 主动带领团队进行探索，最终沉淀出了一套适合团队的核心实践：

经过大量的验证，我们的标杆团队（<50 人规模）无论在 AI 转型后的业务感知上，还是客观数据上，均能达到比较优秀的水平，见下表：

业务线级实践：大规模研发团队，系统性升级 AI 研发范式，带来效能提升

以 主站技术部 为例，从 2023 年到 2025 年，从平台化到数字化再到精益化，2025 年开始步入深水区，2 个新挑战浮出水面：

  • 传统的流程、工具优化手段带来的提效收益，边际效应持续减小。

  • 业务的规模与复杂度持续提升。

因此开始探索能否把握 AI 爆发的机遇，把传统研发流程升级到“AI 研发范式”，进而打开组织级效能跃升的新空间。核心实践：

实践 1：Top-Down，战略驱动

  • 明确战略导向 ：主站技术部提出了“AI First”的战略思想，鼓励全体员工开展工作之初，优先将 AI 作为核心驱动力，加速技术创新、优化业务流程、深度融合 AI 技术，为产品与服务注入新活力和新可能性。

  • 发布白皮书 ：将战略导向具象化为思考、方法与规划，为全员提供明确指引。

  • 成立重点项目 ：在研发领域，成立了 AI DevOps 项目，统一设计解决方案并推广实施。

实践 2：AI x 效能实践

  • Step1：将需求分级，按需求 AI 研发成熟度定义：

  • L1 AI 辅助（Copilot）：人主导，AI 主要在编码环节提供辅助。

  • L2 AI 协同（Agent）：人和 AI 更深度的协同完成需求开发，在研发全过程中，更深度分解任务给 AI 完成，人进行修改、调整、确认。

  • L3 AI 自主（Agentic）：人类似产品经理，把需求澄清清楚并交给 AI 来完成，并进行最后的验收。

  • Step2：分级实施

  • 让所有需求达到 L1 级（AI 辅助，Copilot）：推广个人级实践，依托 Kwaipilot 工具实现全员掌握，最终覆盖所有需求。

  • 让大部分需求能持续升级到 L2 级（AI 协同，Agent）：开展团队级实践，从试点到推全，重塑流程、分工。

  • 小部分需求探索能达到 L3 级（AI 自主，Agentic）：圈选出颗粒度小且独立的需求，构建全技术栈 / 职能端到端交付链路，通过全栈、跨栈，减少协作节点，进而形成效率跃迁，最终达成 AI 自主交付。

  • Step3：项目化推进

  • 成立组织级重点项目，Top-Down 实施。

实践 3：AI x 效能平台。基于需求全流程构建 AI 能力，逐一“点亮”能力并规模推广落地：

  • 构建 AIDevOps 能力矩阵与建设路线图 ：基于研发效能白盒化，分析交付流程中各原子环节的人力投入比重、AI 能力建设 ROI，形成决策建设哪些 AI 原子能力。

  • AI 原子能力建设 ：与研发线共建交付流程环节内的 AI 原子能力 20+，研发流程环节覆盖超过 60%，从需求准备到发布运维各环节。

实践 4：AI x 效能度量：建设 AI 研发成熟度模型，可将需求分级度量（L1、L2、L3 级需求占比），牵引各级实践落地。

经过 1 年多的项目实施，最终探索出了一条组织级的 AI 研发范式升级路线，从数据上也能看出明显的变化：

Step3，AI x 效能度量：建设「AI 研发成熟度模型」，接入原有效能度量体系，驱动需求持续转变为“AI 研发模式”

最后在效能度量上一样也需要升级，基于效能实践的探索，我们配套建立了「需求 AI 研发成熟度」模型（如下图所示），用于度量一个需求在研发过程中的 AI 使用程度，这样我们就可以按 L2&L3 级需求的比例，来牵引实践过程，也可以专门度量 L2&L3 级需求的交付周期的变化，来印证提效结果。

结果

再回到全局视角，从数据上看，如果只看“AI 代码生成率”指标，可以明显看到 2025 年 6-11 月出现了一个大幅提升。实际上，在智能化 1.0 阶段，这个指标达到 24%+ 基本已经是极限了，当我们开始实施智能化 2.0 后，才开始进一步拉升。

当然，我们在内部的数据观测上，其实已经不再看“AI 代码生成率”指标了，它只是一个单点的过程指标，片面且孤立。我们现在有了更直接的度量指标。从过程上，我们观测多少需求被采用全流程 AI 研发模式交付，从结果上，我们直接观察需求的交付效率变化。

  • L1、L2、L3 级需求占比 ：有多少需求的 AI 研发程度可以达到 L1、L2、L3 的阶段。

下图是最先完成 AI 范式转型团队的数据变化，可以看到 L2&L3 级需求占比达到 20.34%，需求交付周期下降 58%，2 个指标呈现明显的正相关性。

总结

最后也总结下我们一年来的实践心得，目前看完全印证了《2025 年 DORA 报告：人工智能辅助软件开发现状调查报告》中的洞察：

“从 DevOps 到 AI 辅助开发：AI 是“透视镜”与“放大器”

  • AI 是“透视镜”

  • 在协同良好的组织中（如流程清晰、数据打通的团队），AI 能使 DevOps 效能再提升 25%。

  • 在架构松散的组织中，AI 会暴露流程断点、数据孤岛等隐性痛点。

  • AI 是 “放大器”

  • 如同亚马逊通过微服务转型释放 DevOps 价值，AI 辅助开发也需重新设计工作流程（如 “AI 提案 — 人类决策” 闭环）、角色分工（如专职提示工程师）与治理机制（如 AI 代码审查标准），否则无法释放真正价值。

对于大型组织的研发效能提升，AI 不是“ 万能药 ”，而是“ 透视镜 ”和“ 放大器 ”，它不会自动修复组织问题，而是先把组织历史积累的长板和短板一并透视出来，再全部放大。幸运的是快手的研发效能实践一直保持客观、务实的风格，先把地基打稳（平台化 / 数字化 / 精益化），再通过在研发各环节建立 AI 提效能力，先一边落地一边充分验证对个体的提效情况，再体系化的推进组织级 AI 研发范式升级。最终发现，AI 在传统研发效能基建的基础上，像放大器一样增幅了每个环节，为组织带来研发范式级的跃迁。

如下图所示，我们基于张乐老师的“研发效能黄金三角”框架之上做了升级，能更清晰的表达出快手的实践框架：

最后，再把镜头拉远，回到宏观视角看——2025 年我们所做的种种努力，不过是这场 AI 变革的开端。由 AI 驱动的生产力跃升和生产关系重塑，正在重新定义软件开发的每一个环节。这不是一场短跑，而是一场马拉松，不是一次技术升级，而是一次范式革命。

快手已经在这条路上积累了宝贵的经验，但真正的挑战和机遇还在前方。未来已来，一起共同探索 AI x 研发效能的无限可能吧！

了解更多

本文作者

  • 快手研发效能中心：秦巍（研发效能解决方案 & 智能工具产品负责人）

  • 快手主站技术部：胡伟（主站 AIDevOps 项目负责人）、马坤（主站研发效能项目负责人）

写在最后

感谢快手 研发效能中心 与 快手主站技术部 的授权，使我们有机会系统梳理并总结快手在过去三年中的实践经验。

快手向来崇尚“行胜于言”的实干精神，也因此我们往往专注于行动，而疏于对外分享。然而，过去一年间 AI 技术的迅猛发展，正深刻改变着研发效能领域的格局。在与行业同行的交流中，我们既看到层出不穷的创新探索，也注意到在实践、方法与工具建设方面仍存在不少共性问题。这些问题若不及早重视，很可能导致未来大量返工与资源浪费，甚至偏离客观规律，影响企业研发效能提升的既定路径。

为此，我们决定把我们的探索与实践经验分享出来——无论是曾经踏过的“坑”，还是有幸跨过的“河”，都希望能为企业与同行们在“AI × 研发效能”的探索中，降低试错成本，注入更多成功可能。

当然，快手的 AI 研发范式升级仍在沿着这条路径演进中：L1 AI 辅助（Copilot）→ L2 AI 协同（Agent）→ L3 AI 自主（Agentic）。目前，我们的研发效能体系已经初步完成 AI 化升级，全景图如下图所示：

2026 年正在探索 L2 → L3 的跃迁路径，我们将定期梳理实践经验，持续向业界输出更多有价值的内容，主要包括：

  • 实践与技术：欢迎关注「 快手技术 」公众号。我们将持续分享具体实操方法与技术解析，例如：个人、团队乃至业务线如何借助 AI 提升效能？有哪些落地案例？研发各环节 Agent 的核心技术及调优方法有哪些？等等。

  • 平台与工具：我们将智能化 1.0 阶段沉淀的产品 Kwaipilot 进行了全面升级与开放，它在快手内部历经数千名研发同学的反馈与打磨，已完成三代演进：Code Copilot → Code Agent → Multi-Agent & Agentic Coding，目前已在海外发布，产品名为 CodeFlicker，希望服务全球开发者，也欢迎国内同行下载体验。后续，我们还会持续把快手在智能化 2.0 阶段的探索成果融入 CodeFlicker，希望让更多企业级开发者受益。

最后的最后，如果你也希望一起探索「AI x 研发效能」最前沿的技术、产品、实践，一起以业界最高标准做有挑战的事，欢迎加入我们。

Anthropic 公司发布了新版Claude宪法，为其行为、推理和训练提供了一个结构化框架。该宪法将明确的原则与情境化的指南相结合，使其成为一个实用的工具，用于改善现实互动中的一致性、安全性和可靠性。与之前的版本将规则单独列出不同，这个版本强调理解每个原则背后的理念，帮助 Claude 适应新场景。

 

在功能层面，该宪法用于在训练期间生成合成数据，包括互动示例、响应排序和适用于特定场景的指南。这些数据可以指导模型更新，帮助 Claude 生成反映预期价值的输出，并使其在模糊的情境中保持灵活性。该宪法的关键内容涵盖有用性、伦理、安全、指南合规性和关于 Claude 自身能力和限制的推理。

 

  • 有用性：Claude 旨在为不同类型的用户提供上下文感知支持，包括 API 运维人员、开发人员和最终用户。

  • 道德准则：模型应诚实行事，避免造成伤害，在遵守高风险行为的硬性约束的同时，妥善处理复杂的道德和实际的取舍。

  • 安全性：Claude 必须优先考虑人类监督，并防止可能削弱监督力度或损害运营完整性的行为。

  • 指南遵从性：Claude 整合了 Anthropic 针对医疗建议、网络安全和工具集成等敏感领域的具体要求，当然，整合的前提是这些要求与其宪法不存在冲突。

 

该文件还涉及 Claude 的自我认知，鼓励对其能力、局限性及交互角色进行推理。通过将规则与推理上下文相结合，该宪法支持生成既可靠又具适应性的训练输出。

 

本次发布引发了 AI 社区的响应。用户 gregtorth评论道：

 

真棒！第一个总是最艰难的。我还记得当初打造自己的 AI 助手时遇到的种种挑战——工程障碍、伦理考量，还有为完善模型而进行的无穷无尽的调整。向 Anthropic 团队致敬，他们成功交付了这个里程碑。

 

另一位用户补充道：

 

哇！这真是个好消息。对 Claude 训练过程的监督体现在它的每一个输出中。我真的很好奇这将如何发展，其他 AI 实验室将如何能够跟上这个工具/产品框架。

 

从技术角度来看，作为一个核心对齐工件，该宪法可以指导响应生成，帮助构建训练数据，并供将 Claude 集成到应用程序的操作人员参考。该方法超越了强制执行规则的范畴，转而通过建模原则，让 Claude 能够权衡取舍、优先保障安全，并在提供帮助的同时兼顾伦理考量。

 

该宪法遵循 Creative Commons CC0 1.0 许可，旨在提供透明度并为未来的研究奠定基础。Anthropic 强调，尽管 Claude 的输出结果可能与它所声明的原则存在偏差，但该文件能帮助开发者和用户更清晰地理解其预期行为及其背后的推理逻辑。

 

感兴趣的读者可以在线获取更新后的 Claude 宪法的详细信息。

 

原文链接：

https://www.infoq.com/news/2026/01/anthropic-constitution/

尽管现在仍有很多人觉得 AI 有局限性、有瓶颈、有泡沫，但从我个人的使用体验来看，我觉得这就是一次革命，而且发展速度是呈指数型爆炸增长的，一定会让人类社会发生天翻地覆的变化，甚至比想象中的还快。

希望听听大家的意见，不管是投资还是技术学习，都可以，我自己虽然有大致的方向，但是总体来说还是相对迷茫的，希望有大佬可以指导一下

另外，肯定会有人对我的想法嗤之以鼻、冷潮热讽，没关系，我无所谓，这是很正常的，每个人看法不同，但是我觉得这些人没必要来浪费这个时间“说服”我，我应该对自己的选择负责，所以就算选择错了，后果也是我应该承担的。
如果问我为什么这么看好，我不说太多，就打个比方，如果一个人在婴儿时期就会写作文，你会关注它写出来的语句通不通顺，有没有错别字吗？反正我不会，我只会惊叹这是怎么做到的，更何况这个婴儿有着超强的学习能力，24 小时不间断的学习进化，所有问题被解决都是迟早的事。所以每次看到有人说什么他用的 AI 好蠢，各种写 bug,各种资料错误，我都懒得和他们争辩，关注点根本不一样，自从 AI 能“理解”人类说的话时，我就觉得一切都不一样了

前言

本小节继续来描述istio对于流量的各种操作

流量镜像

对标nginx的mirror功能，复制一份流量到对应的地址去，通常用来做从线上环境引流至其他环境做测试或者分析

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - mirror:
      host: backend-service
      subset: v1
    mirrorPercentage:
      value: 100
    route:
    - destination:
        host: backend-service
        subset: v0

流量先到v0版本，istio-proxy复制一份流量到v1版本。如果不想1比1复刻，可以调整mirrorPercentage百分比功能

如果mirror host的目标不存在，怎么发现该错误及时调整host配置呢？

超时/重试

配置超时/重试的原因主要是为了解决：

  • 调用外部网络的接口，很容易产生诸如502、504、499，甚至连接中断等问题，有了重试，可以尽可能的尝试再次发起，而不是直接报错
  • 公用云网络抖动，导致客户端收到一堆5xx，从而引起客户产生不适
  • 后端服务没有优雅更新，一旦发版，导致大量502，重试可以缓解502，避免告警风暴
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: backend-retry
spec:
  hosts:
  - backend-service
  http:
  - route:
    - destination:
        host: backend-service
    timeout: 1s
    retries:
      attempts: 3  # 最大重试次数
      perTryTimeout: 1s  # 每次尝试的超时
      retryOn:  # 触发重试的条件
        - 5xx
        - gateway-error
        - connect-failure
        - refused-stream

有位老哥说了，如果一套qps很高的集群，一旦发生重试，那就意味着短时间之内上游服务的qps至少翻一倍（第一波请求不成功，很快第二波请求就要来了），那这时候上游服务就有被冲垮的风险

说的没错，重试是为了提高请求的成功率，但是不可避免增加系统负载，并且增加请求的响应时间，如果大量重试，那就会导致重试风暴，带来更大的问题

重试次数

为了避免重试风暴，在配置策略的时候应该考虑合理的重试次数

    retries:
      attempts: 3  # 最大重试次数
      perTryTimeout: 1s  # 每次尝试的超时

重试3次，每次间隔1s，然后就应该报错，介入查看了

级联超时

超时时间逐层递减，前端超时 > 网关超时 > 服务超时
frontend: timeout: 5s
nginx-test: timeout: 3s
backend-service: timeout: 2s

退避策略

简而言之，就是重试失败之后不是马上重试，而是等一段时间再重试

  • 固定退避（Fixed Backoff）：每次重试等待固定时间

    • attempt 1: 等待 100ms
    • attempt 2: 等待 100ms
    • attempt 3: 等待 100ms

  • 线性退避（Linear Backoff）：等待时间线性增加

    • attempt 1: 等待 100ms
    • attempt 2: 等待 200ms
    • attempt 3: 等待 300ms

  • 指数退避（Exponential Backoff）：等待时间按指数增加（乘以系数），最使用也最常用

    • attempt 1: 等待 100ms
    • attempt 2: 等待 200ms
    • attempt 3: 等待 400ms
    • attempt 4: 等待 800ms
    • attempt 5: 等待 1600ms

  • 随机退避（Jitter/随机抖动）：在退避时间中加入随机性，打破同一时间重试，避免"惊群效应"

    • attempt 1: 等待 100ms ± 随机时间
    • attempt 2: 等待 200ms ± 随机时间
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - retries:
      attempts: 10
      perTryTimeout: 1s
      retryOn: 5xx,connect-failure
    route:
    - destination:
        host: backend-service
        subset: v0

测试istio-proxy的策略

istio-proxy自带了指数退避与随机退避，初始25ms

为了探索istio-proxy是否带有指数退避与随机退避的特点，特意设置attempts: 10（日常用可以设置小一点，比如笔者通常设置为3）

设置后端报错代码，只要报错5xx即可，所以我直接将代码的关键字改错，应该会报语法错误或者方法找不到之类的

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute
    result = method(*self.path_args, **self.path_kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/test.py", line 9, in get
    self.writ(ret)
    ^^^^^^^^^
AttributeError: 'TestFlow' object has no attribute 'writ'

都准备好了，开始测试：

  • curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test

  • 查看日志，有11条日志，符合预期：第1次访问+attempts: 10

    [2026-02-05T06:51:41.322Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.332Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.369Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default
[2026-02-05T06:51:41.441Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.463Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default
[2026-02-05T06:51:41.480Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.660Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.787Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.804Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:41.978Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
[2026-02-05T06:51:42.116Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default

  • 分析下时间

    序号时间戳与上一次间隔
    141.322—
    241.332+10ms
    341.369+37ms
    441.441+72ms
    541.463+22ms
    641.480+17ms
    741.660+180ms
    841.787+127ms
    941.804+17ms
    1041.978+174ms
    1142.116+138ms

  • 从日志看来确实满足了指数+随机，初始 backoff：~25ms、指数增长、加入 jitter（随机抖动）

    • 10ms → 37ms → 72ms → 180ms → 127ms → 174ms → 138ms

经过这次简单的测试：

  • 配置重试应该要针对幂等的request，非幂等是绝对不能使用重试的
  • retries应该要配置小一些，否则就会出现重试风暴，就像测试中10次，相当于原请求放大了10倍

熔断

熔断是为了保护后端服务不被流量风暴淹没，保护系统整体稳定

  • 目标：如果后端检测5xx，超过3次，就将该pod踢下线，30s之后又加回来

    apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: backend-dr
  namespace: default
spec:
  host: backend-service
  subsets:
  - labels:
      version: v0
    name: v0
  trafficPolicy:
    outlierDetection:
      baseEjectionTime: 30s
      consecutive5xxErrors: 3
      interval: 5s
      maxEjectionPercent: 100
    • baseEjectionTime： 30s：服务被下线的时间，30s
    • consecutive5xxErrors: 3：触发熔断的条件，有3次5xx
    • interval: 5s：检测间隔，5s
    • maxEjectionPercent： 100，被下线的服务比例，100%

  • 后端backend服务依然会报错500，先访问3次，curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test

    Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute
    result = method(*self.path_args, **self.path_kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/test.py", line 9, in get
    self.writ(ret)

  • 第四次再访问

    no healthy upstream
  • 符合预期，第四次服务直接被熔断了，并且由于backend的pod只有1个，istio下线了，导致nginx没有upstream

限流

首先基于http1.1，每次发起http并不是短链了，而是长连接。为了不让每次都产生3次握手与4次挥手的连接消耗，istio-proxy与后端服务backend之间会维护一个长连接

  • 配置在DestinationRule上

    apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: backend-dr
  namespace: default
spec:
  host: backend-service
  subsets:
  - labels:
      version: v0
    name: v0
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 5
    • http1MaxPendingRequests: 1与maxRequestsPerConnection: 5是为了方便测试，改得非常的小
    • http1MaxPendingRequests: 1：等待“可用连接”的 HTTP 请求数量，如果没有可用连接，最多允许1个，超出就报503
    • maxRequestsPerConnection: 5：一条 TCP 连接上最多处理多少个 HTTP 请求

  • 使用wrk压测工具，用20个并发，同时发送20个连接，向目标url发送请求，持续1s

    ▶ wrk -t20 -c20 -d1s -H 'Host: api.wilson.com' http://10.22.12.178:30785/test
Running 1s test @ http://10.22.12.178:30785/test
  20 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.66ms    3.18ms  21.85ms   76.73%
    Req/Sec    93.55     16.33   171.00     80.75%
  1990 requests in 1.10s, 650.09KB read
  Non-2xx or 3xx responses: 92
Requests/sec:   1808.21
Transfer/sec:    590.70KB
    • 可以看到，1秒之内有1990个请求发送至目标url
    • 其中有92个请求有问题

  • 检查日志

    ...
[2026-02-06T07:37:08.168Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.73:10000 duration=5ms route=default
[2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 503 UO upstream=- duration=0ms route=default
[2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 0 DC upstream=10.244.0.73:10000 duration=4ms route=default
...
    • http_code是200是正常请求，503就是熔断保护的结果，触发了istio熔断保护而返回客户端503
    • http_code是0，通常意味着 连接在 HTTP 响应头完整返回之前就已经断开了，这非常类似于nginx的499。他们本质都描述了一个问题，客户端没有等到结果就终止连接了，这应该和我们压测只持续了1s有关系

联系我

  • 联系我，做深入的交流

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...

书接上回
划水，划水，请问大家手机都用什么主力套餐？

30 元内又多送 1 张 plus 券，价值网购价值 20 元 +3G 流量

这么来相当于 30 元话费，用了 39G 流量和 40 元？

【订购成功提醒】尊敬的客户，您好！您于 2026 年 02 月 09 日 14 时 16 分通过中国移动客服热线成功办理好礼多多（新）3GB 会员（方案编号：24BJ202167）活动，2026 年 02 月 09 日生效，有效期 24 个月，失效时间为 2028 年 01 月 31 日 23 时 59 分，到期后将按照 24 个月为周期自动续订，有效期内规则如下：
1、需承诺每月实付通信费不低于 30.0 元，若您同时办理其他承诺消费类业务时，每月承诺的最低消费额度将就高计算。若整月停机，当月仍按 30.0 元扣费。每月通信费不含购买非通信类产品的费用、违约金、话费支付、代付代收费，例如宽带、万能副卡等代付费用。
2、从 2026 年 02 月 09 日起，每月获得 3GB 国内通用流量（不含港澳台），流量不可分享、结转与转赠，优先级同套内国内通用流量。若在购买此产品前已限速，办理本流量包无法打开限速速率，次月网速自动恢复。
3、每月获得 PLUS 灵活会员（含 1 张权益兑换券，可用于兑换权益超市中的权益福袋），您需每月自助兑换，权益券仅当月有效。兑换路径：登录中国移动 APP-权益超市。因供货商政策原因权益内容有可能进行调整，以页面实时展示为准。
4、活动持续开展，到期后将以 24 个月合约期自动续订。若活动下线，则活动到期后自动失效。将以到期短信通知内容为准。活动到期月，若为您续订时，您的号码为停机等特殊状态、或有互斥业务，则无法续订成功。
5、变更/转户/销户/携转等需退订该业务，退订无需承担违约责任，可拨打 10086 取消业务。
6、自当前协议签署日起，至活动有效期结束，须持续使用中国移动网络。
7、如办理此活动时客户已开通 VOLTE 功能，将同步开通“高频骚扰电话拦截”服务，该服务开通后长期有效，无需任何费用，如需取消可发送“QXFSR”到 10086 办理。【中国移动】

image

今日，OpenAtom openKylin（以下简称“openKylin”）社区正式推送 openKylin 2.0 SP2 第二次更新升级。本次更新针对系统稳定性，共修复200余项缺陷，重点解决蓝牙连接异常（如文件传输中断、弹窗错位）、双屏显示不稳定等问题；强化多语言支持，提升藏文、蒙古文、繁体中文等界面翻译的覆盖度；完善核心功能，优化软件商店装包稳定性、驱动兼容性（如 Realtek 8852BE WiFi网卡）；上线支持磐石架构的KMRE移动兼容环境、openKylin Wine助手；升级火狐浏览器、微信、QQ 等高频应用至最新稳定版本等。

01系统安装与升级方式
方式一：从openKylin官网（扫描下方二维码或点击“阅读原文”）下载最新镜像进行安装（适用于新用户或想重新安装系统的用户）；

方式二：前往系统设置—“更新”界面，按提示完成系统更新（适用于已安装旧版本的用户）；

方式三：打开维护模式（设置-关于-点击5次UKUI Logo-侧边栏找到维护模式并打开），通过终端运行以下命令进行更新，升级后退出维护模式（适用于开发者）：sudo apt updatesudo apt upgrade

02主要缺陷修复及体验优化
主要缺陷修复
桌面环境
【通知中心】修复藏文环境下鼠标悬浮通知中心图标，提示英文的问题【网络管理】修复wifi优先级设置未立即生效的问题【网络管理】修复新建有线网不进行授权认证，点击保存，第二次超时弹窗未汉化的问题【网络管理】修复新建有线网络，点击保存，认证弹窗点击失败，添加失败弹窗未汉化的问题【网络管理】优化无线网络连接，修复部分用户反馈的检测不到无线网络的问题【文件管理器】修复藏文下，文件管理器标题栏选项按钮中的Samba拼写错误的问题【文件管理器】修复繁体环境下，文管窗口文档部分显示英文的问题【文件管理器】修复复制大文件时任务栏窗口显示异常的问题【文件管理器】修复切换为藏文后，文件管理器中存在乱码的问题【文件管理器】修复英文下最大、次最大字体时窗口显示有遮挡的问题【文件管理器】修复用户反馈的繁体环境下，鼠标右键菜单里部分选项未被翻译为繁体的问题【文件管理器】修复用户反馈的双击启动应用程序相较于右键启动有很大延迟的问题【文件管理器】修复用户反馈的在分辨率缩放情况下，桌面壁纸异常显示的问题【文件管理器】优化大量文件同时拷贝等场景下出现崩溃的问题【文件管理器】修复右键双击标题栏，窗口会最大化的问题【侧边栏】修复藏文、蒙古文、繁体下，侧边栏部分字体仍显示英文的问题【登录锁频】修复部分用户反馈的关机再开机或者重启，需要大约1分钟时间才显示登录界面，且登录界面显示异常的问题【登录锁屏】修复不能正常开机自启动小键盘的问题【登录锁屏】修复切换其他语言，锁屏/登录界面，无线网络连接时提示信息为英文的问题【登录锁屏】修复忘记密码的提示文案不正确的问题【登录锁屏】修复相册屏保未自动轮播的问题【登录锁屏】修复用户反馈的设置了限制密码错误次数后，输入正确密码但锁定三分钟的问题【USD】修复英文环境下非最小字体由小到大切换时按钮文字显示不全的问题【USD】修复藏文最大字体下确认报警信息弹窗按钮文字显示不全的问题【会话管理器】修复多用户登录的情况下，右键开始菜单，点击电源选项-重启/关机，没有多用户重启提示的问题【会话管理器】修复存在未保存的WPS文件、画图文件时，执行重启/关机/注销，没有任何提示，直接重启/关机/注销的问题【会话管理器】修复用户反馈的遇到电源键鼠标左键点击无效的问题【开始菜单】修复登录两个用户，右键开始菜单，点击重启/关机，没有弹窗提示，直接关机/重启的问题【开始菜单】修复切换到字母排序或功能排序后，按上下方向键无法移动到字母导航栏或功能导航栏的问题【开始菜单】修复系统语言为繁体，部分显示为英文的问题【控制面板】修复控制面板中选择德语重启后不勾选的问题【控制面板】修复默认应用不正确的问题【控制面板】修复用户反馈的VPN在设置中关闭vpn后，重启会自动恢复的问题【控制面板】修复用户反馈的系统快捷键设置存在冲突时的提示不够明确的问题【控制面板】修复wlcom环境下，首次打开设置-关于，设置窗口会异常缩小的问题【控制面板】修复侧边栏AI管理模块缺失图标的问题【快捷键】修复自定义快捷键，无法设置按键组合的问题【蓝牙】修复打开托盘处蓝牙，再打开屏幕键盘，关闭屏幕键盘后，蓝牙弹窗没有恢复到原来位置的问题【蓝牙】修复断开已连接的蓝牙设备，在任务栏界面该设备移动界面最低部的问题【蓝牙】修复多次发起批量文件，发送端和接收端文件不一致的问题【蓝牙】修复繁体时，发送文件弹窗存在英文的问题【蓝牙】修复连接蓝牙设备失败，一直处于连接状态，重新打开控制面板扫描不到蓝牙设备的问题【蓝牙】修复音频设备的主动连接弹窗显示不正确的问题【任务栏】修复wlcom环境下，应用打开子窗口的情况下，任务栏软件图标或预览图无法激活应用的问题【任务栏】修复藏文、蒙古文、繁体文任务栏部分内容未翻译的问题【任务栏】修复藏文/蒙古文/繁体文系统，开始菜单悬浮提示未汉化的问题【任务栏】修复多用户重启系统时，会话工具存在任务栏图标的问题【任务栏】修复任务栏固定应用数量超过任务栏宽度，往右拖动最右侧的应用任务栏会自动滑到最左侧的问题【任务栏】修复英文环境下，快捷菜单冷冻模式和wifi显示不完全，悬浮无提示的问题【任务栏】修复用户反馈的任务栏“显示桌面”按钮区域并没有完全覆盖任务栏的最右边，导致滑到屏幕右下角点击无效的问题【任务栏】修复悬浮任务栏开始菜单图标，显示为英文的问题【会话管理器】修复WPS文件编辑未保存，点击电源-关机，没有提示未保存，机器直接关机的问题【主题】修复wlcom环境下，控制面板背景设置后不生效，重启才生效的问题【主题】修复藏文环境下系统，主题界面按钮文字显示不完全的问题【区域语言】修复藏文系统下，输入法设置显示为中文的问题【区域语言】修复藏文系统下，添加语言弹窗关闭按钮悬浮为英文的问题【时间和日期】修复藏文系统下，授权弹窗藏化不完全的问题【时间和日期】修复添加时区和修改时区页面关闭按钮悬浮为英文的问题【时间和语言】修复在修改时区和添加时区搜索框输入不存在的时区，没有无结果的提示的问题

系统应用
【归档管理器】修复解压缩后的弹窗“显示文件”，弹出两个文件管理器界面的问题【归档管理器】修复蒙古文环境下，存在部分的翻译异常问题【计算器】修复ARM架构下，用键盘的数字无法输入的问题【计算器】修复蒙古文计算器标题栏为英文，且选项菜单存在英文显示的问题【截图】修复区域截图后无法选择字体的问题【微信】修复订阅号页面无法调用系统默认浏览器的问题【开明包格式】修复运行开源系列的开明包应用均无图标的问题【天气】优化天气出现定位不准的问题【录音】修复蒙古文右键点击已存在的录音文件，下拉菜单存在英文内容的问题【用户手册】修复英文环境下，关于界面的图片所属张数错误的问题【日历】 修复英文环境下，日程中存在部分项悬浮没有内容的问题【U盘管理工具】修复英文环境下，插入异常U盘，提示弹窗格式化按钮显示不全的问题【系统监视器】修复系统语言为蒙古文，会话管理器下方系统监视器显示简体中文的问题【系统监视器】修复磁盘详情页面连续点击不同磁盘应用闪退的问题【虚拟键盘】修复用户反馈的鼠标拖动移动悬浮球与虚拟键盘时，出现悬浮球与虚拟键盘严重抖动的问题【虚拟键盘】修复用户反馈的鼠标长按虚拟键盘时，键盘出现闪烁的问题【音乐】修复蒙古文环境下，存在部分的翻译异常问题【日历】修复调整缩放率为175%和200%，日历页面位置异常的问题【日历】修复用户反馈的农历时间存在错误的问题【麒麟管家】修复部分用户反馈的麒麟管家应用右上角关闭按钮变小的问题【麒麟管家】修复用户反馈的通过服务支持反馈问题时，一旦勾选高级模式，界面就不正常的问题【软件商店】根据社区用户反馈，上架最新版原生微信、QQ音乐等应用【软件商店】修复软件商店更新下点击更新某些应用，提示安装失败的问题【软件商店】修复正在下载界面内悬浮在软件上，悬浮显示的网速位置在窗口右侧的问题【第三方软件】修复用户反馈的 WPS办公软件卸载不完全的问题

系统支撑
【wlcom】修复命令行启动应用，窗管显示异常的问题【安装器】修复英文环境-大号字体下，卸载器界面存在截断的问题【安装器】修复应用图标显示为默认图标时，图标显示较小且居于左上角的问题【安装器】修复用户反馈的浏览器下载qq安装包无法安装的问题【电源管理】修复控制面板中电源管理模块未翻译完全的问题【电源管理】修复英文模式下，查看控制面板-系统-电源，各子选项中存在首字母未大写情况的问题【定时关机】修复菜单栏的“选项”按钮，悬浮提示显示“更多”，与其它应用显示不一致的问题【定时关机】修复设置时间为当前时间，剩余时间显示错误的问题【多语言】修复Wayland模式下，英文模式切换到法语无法切换的问题【龙芯】修复部分龙芯平台机型上无法进入桌面的问题【系统启动】优化系统重启等待时间【软件源】修复pristine-tar的依赖问题【软件源】修复下载安装libkysdk-system-dev时报错的问题【声音】修复英文下用户手册缺少内容介绍的问题【系统安装】修复安装各界面滚动条、输入框未屏蔽右键菜单的问题【系统安装】修复部分用户反馈的在多系统共存环境下安装不成功的问题【系统安装】修复系统安装流程中存在的部分未汉化的问题【系统安装】修复虚拟机安装时，数据盘分区太小的问题【显示器】修复用户反馈的出现系统崩溃：Abnormal display,and the input method cannot be sw的问题【显示器】修复镜像模式下，显示器预览图为两个的问题【显示器】修复镜像模式下插拔显示器进行旋转，两个屏幕显示不同步的问题【显示器】修复扩展模式下，调整其中一个屏幕亮度另一个屏幕亮度也会随之改变的问题【显示器】修复连接多个显示器进行插拔，控制面板内显示多个亮度条的问题【显示器】修复连接双屏，设置投影仪为主屏，关闭投影仪，主屏未切换到显示器上的问题【显示器】修复连接投影仪，屏幕旋转90°，重启后桌面花屏的问题【显示器】修复屏幕旋转后点击桌面，桌面呈现黑色部分的问题【显示器】修复切换分辨率后，点击桌面壁纸发生变化的问题【显示器】修复拖动预览图改变屏幕相对位置，4K屏会闪现部分黑屏的问题【显示器】修复用户反馈的在高分辨率下在VMware虚拟机上出现的屏闪问题【硬件驱动】修复Realtek 8852BE Wireless LAN WiFi 6 PCI-E NIC网卡无法驱动的问题

作为金融领域的开发者/从业者，你一定深有体会：外汇市场汇率以毫秒级更新，单日波动可达数百点，能否拿到低延迟、高稳定的实时行情数据，直接决定了量化交易策略的执行效率，甚至是交易决策的成败。在高频交易成为常态的当下，搭建基于外汇行情API的实时数据监控体系，是突破数据延迟、接口不稳定等痛点的核心方案。

开发者核心诉求：实时行情是交易策略落地的底层支撑

外汇交易的本质是对市场波动的精准捕捉，而你的每一次策略迭代、实盘执行，都离不开实时、无误差的行情数据：

  • 跨时区交易场景中，哪怕几秒的数据延迟，都可能导致交易点位偏离预期；
  • 突发市场消息触发价格异动时，延迟获取数据会直接错失盈利机会；
  • 量化交易/自动化交易场景，对数据的实时性、稳定性更是硬性要求——传统人工刷新、第三方平台转发的方式，早已无法适配高频交易的需求。

简单来说，你需要的是一套能直接对接市场的数据流体系，而非“人工+工具”的低效组合，让数据获取与交易决策无缝衔接。

传统方案的技术瓶颈：为什么越用越“卡”？

尽管实时数据需求迫切，但传统数据获取方式的技术缺陷，始终是开发者的“绊脚石”：

  1. 效率低：人工刷新行情页面、整合多平台数据，不仅耗人力，还会产生不可控的时间延迟，完全跟不上毫秒级更新的外汇市场；
  2. 数据不准：非专业数据渠道的信息存在误差，且不支持定制化推送，满足不了量化交易对“精细化数据维度”的需求；

  3. 技术层面硬伤：

    • 传统HTTP轮询无法实现数据主动推送，实时性大打折扣；
    • 常规接口稳定性差，网络波动/服务端故障易导致数据中断，且高频请求极易触发限流，直接影响策略执行。

核心解决方案：外汇行情API的技术实现与接入步骤

针对上述痛点，专为金融场景设计的外汇行情API是最优解——核心优势集中在“低延迟、高稳定、强适配”，而技术层面的关键是WebSocket协议（替代传统HTTP），以及合规的金融数据链路。

1. 外汇行情API的核心技术特性

  • 低延迟：支持WebSocket长连接，实现服务端主动推送数据，延迟降至毫秒级（对比HTTP轮询的秒级延迟，优势显著）；
  • 高稳定：正规服务商拥有专属金融数据链路，能规避网络波动导致的断连问题；
  • 高适配：可定制数据维度，覆盖主流货币对的实时汇率、涨跌幅度、成交点位等核心信息，适配量化交易、实时监控等场景。

2. 手把手教你接入：4步搞定实时行情API

接入流程清晰且易操作，核心分为4步，以下结合AllTick API给出可直接落地的实操步骤：

步骤1：甄选合规的API服务商

优先选满足以下条件的服务商（直接决定后续接入效率）：

  • 支持WebSocket协议；
  • 拥有金融数据服务资质；
  • 能保障数据实时性与连接稳定性（可先测试服务商的demo接口）。

步骤2：获取API密钥

完成服务商平台的账户注册、资质审核，申请专属API密钥——这是接口调用的身份凭证，务必妥善保管，避免泄露。

步骤3：技术集成（核心实操，代码100%保留）

依托服务商提供的技术文档，将API对接至你的交易系统/分析系统，以下是基于AllTick API的简易集成示例，可直接运行获取实时行情：

import websocket
import json

# 连接AllTick外汇行情API的WebSocket地址
url = "wss://realtime-api.alltick.co/forex"

def on_message(ws, message):
    # 解析并处理实时行情数据
    data = json.loads(message)
    print(f"实时外汇行情数据：{data}")

def on_error(ws, error):
    # 捕获并输出连接错误信息
    print(f"API连接出现错误：{error}")

def on_close(ws, close_status_code, close_msg):
    # 输出连接关闭提示
    print("API连接已正常关闭")

def on_open(ws):
    # 输出连接成功提示，开始接收数据
    print("API连接成功，已进入实时数据接收状态")

# 创建WebSocket客户端并运行
ws = websocket.WebSocketApp(url, on_message=on_message, on_error=on_error, on_close=on_close)
ws.on_open = on_open
ws.run_forever()
🔔 前置条件：运行代码前需安装依赖：pip install websocket-client

步骤4：数据处理与可视化

将API获取的实时数据流做进一步加工：

  • 用Matplotlib/Plotly实现汇率波动的可视化图表，直观展示趋势；
  • 对接后端数据库（如MySQL/Redis）完成数据存储，方便后续回测分析；
  • 可在代码中加入断连重连、限流规避逻辑，提升稳定性（比如捕获连接异常后自动重试）。

实战落地场景：API如何赋能交易全流程？

外汇行情API的价值，远不止“获取数据”，更能深度融入你的日常开发/交易环节：

场景1：基金公司量化交易

  • 研究员：用API实时数据结合宏观经济指标，完成市场走势分析，为策略制定提供精准数据支撑；
  • 量化团队：将API数据对接量化模型，实现策略自动化回测与实盘执行——当汇率达到模型阈值时，系统自动触发买卖操作，无需人工干预。

场景2：个人专业交易者

  • 实时监控：通过API推送的毫秒级数据，第一时间捕捉市场异动，结合技术分析工具快速决策；
  • 稳定性优化：在代码中加入重试机制、限流规避逻辑，解决WebSocket断连、API频率限制等问题，让数据获取体系更健壮。

行业趋势：API已成金融开发的基础设施

随着外汇交易的数字化、智能化升级，外汇行情API早已不是“可选项”，而是金融开发者的“标配”。作为开发者，你只需聚焦两点：

  1. 选对合规、稳定的API服务商；
  2. 优化API接入逻辑与数据处理体系（比如断连重连、数据缓存、可视化）。
    最终让实时行情数据真正成为交易决策的“核心抓手”，在波动剧烈的外汇市场中保持决策的精准性与时效性。

总结

  1. 外汇行情API的核心优势是WebSocket长连接+专属金融链路，可实现毫秒级低延迟、高稳定的数据推送；
  2. 接入流程核心为“选服务商→拿密钥→技术集成→数据处理”，其中代码集成环节可直接复用文中的AllTick API示例（需先装websocket-client依赖）；
  3. 落地时重点关注稳定性优化（断连重连、限流规避），让数据体系适配高频交易场景。

Base UI 是由 Radix、Floating UI 和 Material UI 的创建者们开发的无样式 React 组件库，现已发布 1.0 版本。经过两年的开发，该项目正式进入稳定且可用于生产环境的阶段。此次发布包含 35 个可访问性组件、包命名变更，以及专职团队对长期维护的承诺。

与早期版本相比，1.x 版本在开发者体验方面进行了多项优化，包括包重命名、基于 Radix UI 经验教训改进的组件 API，以及所有组件可访问性功能的增强。此外，本次发布还包含性能优化，以及与 Tailwind CSS、CSS Modules 和 CSS-in-JS 库等主流样式解决方案更好的集成。

此次发布对包进行了重命名，从 @base-ui-components/react 改为 @base-ui/react。这一重大变更要求开发者对 import 语句和 package.json 依赖做出修改。组件导入语法基本保持不变，使现有用户能够平稳过渡。更新后的导入语法示例如下：

import { Popover } from '@base-ui/react';
复制代码

使用 Base UI 构建应用的开发者受益于该库的无头架构，它在提供完整样式控制的同时保持了强大的可访问性功能。与传统捆绑了主观样式的组件库不同，Base UI 组件完全无样式，允许团队自主实现设计系统，无需受默认 CSS 的束缚。这些组件处理复杂的交互模式、键盘导航、焦点管理和 ARIA 属性，确保开箱即符合 WCAG 标准，同时赋予开发者自由选择组件样式的权利。

相较于竞争对手（如 Radix UI 和 Headless UI），该项目提供了不一样的支持和长期承诺，彰显了自身的特色。Radix UI 在被收购后面临不确定性，而 Base UI 由 MUI （这是一家拥有工程师、设计师和专职项目经理的公司）提供支持，这增强了 React 社区的信心。Hacker News 上的开发者对其稳定性表示赞赏，并表现出采用该库的强烈意愿。

在 Reddit 上，一位用户询问为何将该版本定位为 Radix 的继任者：

好奇你们为何将其定位为 Radix 的继任者？具体来说，Radix 存在什么问题，以至于需要全新的 UI 库来解决？

对此，有人解释道：

这是为了说明，由于 API 相似，从 Radix 迁移到 Base UI 非常容易。

对于考虑使用 BaseUI 的开发者，有用户在同一个 Reddit 帖子中就其与 Ariakit 或 React Aria 的比较提出了疑问：

我为什么要选择这个而非 Ariakit 或 React Aria？它有哪些功能是其他库所不具备的？

Base UI 维护者 (_doodack) 回复道：

React Aria 的 API 差异较大。有些开发者喜欢，有些则不喜欢。它在 React 树中渲染大量的上下文 Provider，与其他组件库混合使用可能颇具挑战性。相比之下，我们的 API 与 Radix 和 Ariakit 更为接近。

他们继续写道：

我们还具备一些其他库所没有的功能，比如"分离触发器"——这一功能可用于在不同触发器之间复用同一个弹出元素。

Base UI 1.0 还针对众多组件进行了具体改进，解决了边界情况并提升了可靠性。Combobox 组件现在能正确处理 itemToStringValue，并允许将 null 作为 value 属性的选项。Menu 组件修复了子菜单零延迟打开的问题，并确保按下 Escape 键时焦点正确返回到触发器。Select 组件也做了类似的表单处理和 null 值支持改进。性能优化则覆盖全库，重点在于减少了不必要的重渲染并提升了运行时效率。

Base UI 是由 MUI 以及 Radix 和 Floating UI 项目的核心贡献者共同维护的开源 React 组件库。它专注于可访问性、可组合性和开发者体验，提供可与任何样式解决方案无缝配合的低级 Hooks 和无样式组件。Base UI 专为需要构建自定义设计系统和应用的团队打造，适用于视觉控制与可访问性同等重要的场景。

原文链接：

https://www.infoq.com/news/2026/02/baseui-v1-accessible/

工作职责：

  1. 维护已有小程序/web 软件
  2. 开发新的 AI 方面的软件产品

要求：

  1. 熟练使用 AI 编程工具，认同 AI 时代编程语言不是问题
  2. 熟悉 python 、langgraph ，了解 MCP 、RAG 、Skills 等
  3. 逻辑思维强，理解能力好，远程沟通不存在障碍，认真负责，不滑头
  4. 最好有产品思维，对产品交互、用户体验有自己的理解
  5. 时间每天至少能保证 4 个小时
  6. 学历一本以上，8 年以上经验，计算机相关专业

工作说明：

  1. 兼职，无需坐班，保持线上沟通即可，最好在西安
  2. 无社保、五险
  3. 薪资：3-5K

有意请发简历至邮箱: [email protected]

大家好，我新写的导航站 https://dh.business 上线了，准备收录更多的开发者产品，欢迎大家提交自己的产品，免费收录和 dofollow 格式的外链

大家直接在评论区按照下面的格式回复，我看到了就会添加，category 分类请参考导航站的分类

{
"id": "panclub",
"name": "网盘俱乐部",
"description": "免费快速的百度网盘和夸克网盘资源搜索引擎。",
"url": "https://pan.club",
"icon": "https://pan.club/public/favicon.ico",
"category": "editor-pick",
"tags": [
"网盘搜索引擎",
"百度网盘搜索",
"夸克网盘搜索"
],
"featured": true
},

在全球数字化转型加速与跨境商业合作日益频繁的今天，电子签名已成为企业出海降本增效、打通全球业务链路的核心工具。然而，不同国家和地区的法律体系、监管要求差异显著，电子签的法律效力认定、技术标准、数据安全等合规要点千差万别，若平台无法精准适配目标法域的法规要求，可能导致电子合同无效、引发法律纠纷，甚至阻碍业务落地。对于出海企业而言，选择一款具备全球合规适配能力的电子签平台，既是规避风险的前提，也是全球化布局的关键支撑。本文将拆解全球主要法域的电子签核心法规要求，为企业出海合规提供可落地的参考。

一、全球电子签法规核心格局：三大主流模式与区域差异

目前，全球绝大多数国家和地区已认可电子签的法律效力，但形成了“宽松灵活、分级严格、强调认证”三大主流合规模式，不同法域的细节要求差异显著，构成了企业出海电子签合规的核心挑战。根据《2025年全球电子签名法律法规合规白皮书》，全球电子签法规可划分为以下三大主流体系，且区域特色鲜明。

（一）美国模式：技术中立，侧重签署意图与流程安全

美国以《全球和国家商务中的电子签名法》（ESIGN法案）和《统一电子交易法》（UETA法案）为核心，采用“技术中立”原则——不限制电子签的具体技术形式，只要签署双方自愿同意，任何能够证明签署意图、保障签署流程安全的电子签名形式（包括点击“同意”“确认”等简易形式）均具备法律效力。

其合规核心在于“可追溯性”：需完整记录签署人的身份信息、签署时间、签署行为轨迹，确保签署行为是签署人的真实意思表示，且签署后的文件内容不可篡改。此外，美国不同州对特定场景（如不动产转让、遗嘱）的电子签使用有额外限制，出海企业需结合具体业务场景适配。

（二）欧盟模式：分级管控，合格签名具备完全法律效力

欧盟以《电子身份识别和信托服务条例》（eIDAS条例）为核心，采用“分级严格”原则，将电子签名分为三级，不同级别对应不同的法律效力和适用场景，其中合格电子签名（QES）是唯一与手写签名具备同等法律效力的形式，适用于高风险跨境场景。

简单电子签名（SES）：最低级别，适用于低风险场景（如普通通知、日常沟通），仅需证明签署人身份，法律效力有限；

高级电子签名（AdES）：需采用加密技术，确保签署人身份可验证、签署行为不可否认、文件内容不可篡改，适用于常规商业合同；

合格电子签名（QES）：最高级别，需由欧盟认可的合格信任服务提供商（QTSP）颁发，结合加密证书和身份认证，具备与手写签名完全同等的法律效力，适用于跨境贸易、金融借贷、知识产权转让等高风险场景。

欧盟合规的核心的是“资质认证”与“技术达标”：电子签平台需获得QTSP资质，签署流程需符合eIDAS条例对不同级别签名的技术要求，同时需配合欧盟《通用数据保护条例》（GDPR），保障签署过程中的个人数据安全。

（三）中国模式：强调可靠，依托权威认证保障法律效力

中国以《中华人民共和国电子签名法》为核心，采用“强调可靠”原则——仅“可靠电子签名”具备与手写签名同等的法律效力，且明确规定了可靠电子签名的三大认定标准：签署人身份可识别、签署行为是真实意思表示、签署内容不可篡改且可追溯。

其合规核心在于“权威认证”与“全链路合规”：电子签平台需具备国家认可的电子认证服务资质（CA机构认证），采用国家密码管理局认可的加密技术，同时需符合《网络安全法》《数据安全法》《个人信息保护法》的要求，确保签署数据的安全与合规。对于出海企业而言，若涉及中资主体签约，需同时适配中国与目标法域的双重合规要求。

（四）其他重点区域：适配本土特色合规要求

除三大主流模式外，其他重点出海区域的电子签法规也具备鲜明特色，需重点关注：

中东地区（阿联酋、沙特）：存在独立司法管辖区（如DIFC、ADGM），规则更贴近国际标准，而本土法律则要求更严格的本地化认证，部分场景需配合线下公证；

拉美/非洲地区：多数国家原则上认可电子签法律效力，但法律体系尚在完善中，司法实践中对电子证据的认可度较低，建议优先采用高级别电子签名；

日韩地区：认可电子签法律效力，需依托本土CA机构认证，同时对电子签的存储方式、身份验证有额外细节要求，需适配本土技术标准。

二、出海电子签平台的核心合规适配要点

结合全球主要法域的法规差异，电子签平台要实现全球合规适配，需围绕“法律适配、技术达标、数据安全、资质认证”四大核心要点构建能力，既要满足不同法域的个性化要求，也要保障跨境签署的便捷性与安全性，避免“一刀切”导致的合规风险。

（一）法律适配：精准匹配目标法域的法规要求

平台需具备“分法域适配”能力，根据企业出海的目标市场，灵活切换合规模式——针对美国市场，侧重签署意图与流程追溯；针对欧盟市场，提供分级签名服务并获得QTSP资质；针对中国及东南亚市场，对接本土CA机构，保障可靠电子签名的法律效力。同时，需实时跟进各法域的法规更新，及时调整合规策略，规避法规变动带来的风险。

（二）技术达标：满足不同法域的技术标准

技术是合规的基础，平台需具备加密技术、身份认证、痕迹追溯、文件防篡改等核心能力：采用国密算法、RSA加密等国际通用加密技术，保障签署数据的安全性；支持多维度身份认证（人脸识别、护照验证、手机号验证等），适配不同法域的身份验证要求；完整记录签署全流程轨迹，生成不可篡改的审计日志，确保签署行为可追溯；支持PDF、OFD等国际通用文件格式，保障跨境签署的兼容性。

（三）数据安全：契合全球数据隐私监管要求

电子签过程中涉及大量个人信息、商业数据，需契合不同法域的数据隐私法规——欧盟GDPR、中国PIPL、美国CCPA等，核心要求包括：数据本地化存储（部分法域要求签署数据存储在本土服务器）、数据传输加密、用户知情权与同意权保障、数据安全审计等。平台需具备灵活的数据存储方案，根据目标法域要求实现数据本地化部署，同时构建全生命周期的数据安全防护体系。

（四）资质认证：获取目标法域的权威合规资质

合规资质是电子签法律效力的重要保障，平台需根据目标市场获取对应的权威认证：欧盟市场需获得QTSP资质，中国市场需具备CA电子认证服务资质，全球范围内需通过ISO 27001（信息安全管理体系）、AATL（Adobe信任列表）等国际认证，确保产品与服务的合规性获得全球认可。

三、国内可开展出海业务的电子签平台盘点

（一）安证通iTrustSign：合规为先，适配多法域跨境需求

作为国内头部电子签服务商，安证通深耕电子认证与电子签名领域20余年，其自研的iTrustSign电子签平台，已具备完善的全球合规适配能力，可支撑企业出海后的各类跨境签署场景。该平台不仅契合中国《电子签名法》要求，具备国家认可的CA电子认证资质，同时通过欧盟eIDAS QTSP、美国AATL等国际权威认证，适配欧盟、美国、东南亚等全球主要法域的法规要求，能够为出海企业提供合规、安全、便捷的电子签署服务，尤其在跨境金融、供应链合作等中高风险场景中表现突出，已成功服务多家知名出海企业。

（二）e签宝（海外品牌eSignGlobal）：生态完善，深耕新兴市场

e签宝作为国内电子签名行业的头部企业，以“亚太第一、全球第六”的排名跻身全球电子签名第一梯队，其海外专属品牌eSignGlobal专注于跨境电子签服务，已实现全球70多个国家和地区的合规覆盖。平台重点深耕东南亚、中东等新兴市场，在香港、新加坡、法兰克福部署本地化数据中心，满足不同地区的数据主权要求，全面适配欧盟eIDAS、美国ESIGN及中国PIPL等法规。其推出的“智能合同Agent”可实现合同审查、全周期AI管理，且能与钉钉、飞书等国内外主流办公系统无缝对接，更适配中小规模出海企业与新兴市场布局需求。

（三）法大大（海外品牌Nota Sign）：资质领先，聚焦全球合规矩阵

法大大作为国内电子签行业的核心玩家，推出专属出海产品“Nota Sign全球签”，聚焦全球合规布局，凭借权威资质认证成为中企出海的重要选择。该平台成功通过SOC 2 Type I审计，成为国内首个通过这一国际权威安全审计标准的电子签平台，其合规体系与欧盟GDPR、美国CCPA、新加坡PDPA等全球主流数据安全法规高度契合，具备极强的国际认可度。

Nota Sign已在全球核心区域部署数据中心，覆盖北京、中国香港、美国、德国、新加坡、巴西、中东等多个地区，可提供本地化合规签约服务，适配超100个国家/地区的电子签法规要求，全面遵循美国ESIGN、欧盟eIDAS/GDPR等核心法规。其在系统安全性、服务可用性及隐私保护方面达到国际一流水准，尤其适配跨境贸易、海外投融资等对合规性要求极高的场景，为出海企业构建了接轨全球的合规保障体系。

君子签（海外品牌FairSigning）：AI赋能，强化合规闭环

君子签面向全球市场推出的跨境电子合同平台FairSigning，是2026年跨境电子签领域的核心黑马，已实现全球80余个跨境贸易核心国家和地区的法律适配，涵盖欧盟eIDAS条例、美国ESIGN法案及东南亚多国相关法规。平台搭载司法级区块链存证技术与银行级加密技术，结合多重身份验证机制，满足GDPR、CCPA等国际隐私法规要求，实现签署全流程可追溯、不可篡改。其内置的AI法律合规验证引擎可自动审查合同关键条款，提供跨法域合规提示，同时支持多语言界面与合同模板，适配各类跨境签署场景。

（五）其他可出海平台：各有侧重，适配细分场景

除上述主流平台外，国内还有部分电子签平台凭借专项优势开展出海业务：部分平台侧重轻量化服务，以高性价比、简易操作见长，适配自由职业者、小微出海团队的偶发签署需求；部分平台深耕特定行业，在跨境电商、跨境物流等细分场景中构建了专属解决方案，依托行业Know-How为企业提供定制化服务；还有部分平台通过与全球知名CA机构、司法机构合作，强化电子证据的国际认可度，重点适配跨境仲裁、知识产权转让等高风险场景。值得注意的是，这类平台大多已通过核心国际合规认证，具备基本的跨法域适配能力，但在全球覆盖广度、复杂场景适配性上与头部平台存在一定差距。

四、合规为先，让电子签成为出海的“助推器”

企业出海，合规是底线，电子签作为跨境商业合作的核心工具，其合规适配能力直接决定了企业全球业务的顺畅度与安全性。全球电子签法规的核心差异在于“法律效力认定标准”“技术要求”“数据安全”，电子签平台需立足这三大差异，构建分法域、全链路、多层次的合规体系，既要精准匹配目标法域的个性化要求，也要兼顾签署的便捷性与安全性。

从国内可出海电子签平台的实践来看，平台的全球合规适配能力，核心在于对不同法域法规的精准解读、技术实力的全面支撑以及权威资质的背书——无论是安证通iTrustSign、e签宝eSignGlobal这类头部平台，还是聚焦细分领域的专项平台，其核心竞争力均围绕前文提及的法律适配、技术达标、数据安全、资质认证四大要点构建。对于出海企业而言，无需盲目追求“大而全”，可结合自身出海目的地、业务规模、场景风险等级，选择适配自身需求的平台。

对于出海企业而言，选择一款适配自身需求、具备核心合规能力的电子签平台，既是规避跨境签署风险的关键，也是加速全球化布局的重要支撑。安证通iTrustSign等头部平台的实践，也为中企出海选择电子签平台提供了清晰参考：优先选择具备国际合规资质、全球法规适配能力、全链路数据安全保障的平台，才能真正发挥电子签降本增效的价值。未来，随着全球电子签法规的不断完善与中企出海的持续深化，国内电子签平台的全球化能力将进一步提升，成为中企出海的重要数字基建支撑。

  1. 1
  2. ...
  3. 521
  4. 522
  5. 523
  6. 524
  7. 525
  8. 526
  9. 527
  10. ...
  11. 913