在搭建量化回测与策略验证体系时,美股历史数据几乎是绕不开的环节。无论是模型训练、指标验证,还是实时监控,数据结构能否统一、时间序列是否连续,都会直接影响分析的可靠性。

近期在协助某投顾团队整理量化研究流程时,我们尝试将历史与实时数据接入统一到同一数据结构中,以减少维护复杂度,也为长期分析提供可复用的底层框架。下面结合 [AllTick API]的接入实践,总结过程中的一些要点。

1. 背景与开发痛点

许多投研系统初期都能快速跑通,但在长期迭代中容易出现以下问题:

  • 不同接口返回结构差异较大,字段不一致。
  • 历史数据与实时推送数据难以兼容。
  • 数据缺口或时间戳偏差造成回测结果偏差。

这些看似琐碎的结构问题,往往才是限制系统长期稳定性的核心。对于需要频繁回测与高频更新的投顾分析框架,稳定的数据结构比“拉到数据”本身更重要。

2. 历史数据接口的基础结构

以 AllTick 的美股历史数据接口为例,其支持按股票、市场与时间区间拉取K线数据,并采用常规 HTTP 请求方式。主要参数包括:

  • symbol:证券代码(例如 AAPL)
  • market:市场标识(US)
  • interval:周期(如 1min、1day)
  • start_time / end_time:时间范围

响应数据则包含标准化字段:时间戳、开盘价、最高价、最低价、收盘价和成交量。
字段返回顺序规整,易于转为 Pandas DataFrame 做进一步处理。

import requests
import pandas as pd

url = "https://apis.alltick.co/v1/market/history"

params = {
    "symbol": "AAPL",
    "market": "US",
    "interval": "1day",
    "start_time": "2026-01-01",
    "end_time": "2026-03-01"
}

headers = {
    "Authorization": "Bearer YOUR_API_KEY"
}

response = requests.get(url, params=params, headers=headers).json()

if response.get("code") != 0:
    raise ValueError("请求失败", response)

data = response["data"]

经过统一处理后,数据结构清晰、索引友好,可直接用于可视化或后续统计。

3. 历史与实时数据结构统一

该 API 的一大优势在于:历史数据与实时数据字段设计保持一致
这意味着,你可以用历史数据初始化 DataFrame,再订阅实时推送,通过 WebSocket 实时补充到同一数据结构。

这种方式减少了重复设计表结构的需求,方便复用同一份计算逻辑,也让策略运行更稳定。

import websocket
import json

def on_message(ws, message):
    msg = json.loads(message)
    new_df = pd.DataFrame([msg])
    new_df["datetime"] = pd.to_datetime(new_df["timestamp"], unit="s")
    new_df.set_index("datetime", inplace=True)

    global df
    df = pd.concat([df, new_df])
    print(df.tail())

def on_open(ws):
    ws.send(json.dumps({
        "action": "subscribe",
        "symbol": "AAPL",
        "market": "US",
        "interval": "1min"
    }))

ws = websocket.WebSocketApp(
    "wss://apis.alltick.co/realtime",
    on_message=on_message,
    on_open=on_open
)

ws.run_forever()

对于需要长时间运行的系统而言,这种“一体化结构”能有效降低后期维护成本。

4. 数据处理中的几个注意点

在实际对接过程中,有几点经验值得记录:

  • 拉取跨度较大的历史区间时建议分段请求,避免超时。
  • 核实接口返回是否包含未收盘数据,以防计算偏差。
  • 处理缺失时间点时,应提前设计补齐或插值逻辑。

这些细节多数接口文档会提及,但实际落地还需结合业务场景与分析目标灵活调整。

5. 总结与延伸思考

整体来看,美股历史数据 API 本身不算复杂,真正影响使用体验的,是结构清晰度与历史数据和实时数据的衔接性。

当数据打好底层“地基”后,后续的策略优化、模型回测、交易执行都能以更低成本迭代。这类结构稳定、接口统一的方案,也逐渐成为投顾团队构建自主投研平台的基础。

前言

在鸿蒙生态逐步向 PC、平板、车机、IoT 全场景扩展的背景下,越来越多开发者开始关注一个现实问题:

如何用最低成本,构建可同时运行在鸿蒙与多平台的应用?

Flutter 作为成熟的跨端 UI 框架,在适配 HarmonyOS 6.0 后,已经具备了完整的工程化能力:
一次开发,多端部署,天然适合鸿蒙“全场景设备”的产品理念。

本文我们不讲复杂架构,不上状态管理,不搞花哨组件,只做一件事:

用 Flutter 在 HarmonyOS 6.0 上,实现一个最基础、最标准、最工程化的列表页面。

目标非常明确:
构建一个带分隔线的基础 ListView,并完全理解每一行代码。


在这里插入图片描述

背景

在真实业务中,列表几乎是出现频率最高的 UI 结构

  • 设置页 → 列表
  • 消息页 → 列表
  • 文件管理 → 列表
  • 日志面板 → 列表
  • 运维系统 → 列表

可以说:

学会 ListView,等于掌握 Flutter UI 的 40%。

而在 HarmonyOS 场景下,列表还有一个额外价值:

  • 大屏设备(PC / Pad)
  • 多窗口
  • 分布式界面
  • 高刷新率

都要求列表组件 性能稳定 + 行为可控 + 样式一致

所以我们从最基础的 ListView.separated 开始,是最工程化、最合理的学习路径。


Flutter × HarmonyOS 6.0 跨端开发介绍

架构关系

在鸿蒙 PC 上运行 Flutter 的本质结构是:

Flutter Widget Tree
        ↓
Flutter Engine
        ↓
Skia / Impeller 渲染
        ↓
HarmonyOS 图形系统 (ArkUI / Surface)

你写的:

ListView(
  children: [...]
)

最终会被 Flutter Engine 转换为:

  • 原生 GPU 绘制指令
  • 在鸿蒙窗口系统中渲染
  • 不依赖 WebView
  • 不走 H5

这意味着:

Flutter 在鸿蒙上是“真原生渲染”,不是套壳。
在这里插入图片描述

开发核心代码

在这里插入图片描述

我们这篇文章的核心只有一个函数:

/// 构建基础列表布局
/// 展示最简单的 ListView 实现,包含分隔线和基本的 ListTile
Widget _buildBasicList(ThemeData theme) {
  final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

  return Container(
    decoration: BoxDecoration(
      borderRadius: BorderRadius.circular(12),
      color: theme.colorScheme.surfaceContainerHighest,
    ),
    child: ListView.separated(
      shrinkWrap: true,
      physics: const NeverScrollableScrollPhysics(),
      itemCount: items.length,
      separatorBuilder: (context, index) => Divider(
        height: 1,
        color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
      ),
      itemBuilder: (context, index) {
        return ListTile(
          title: Text(items[index]),
          onTap: () {},
        );
      },
    ),
  );
}

这个函数本质上解决了四件事:

  1. 数据源定义
  2. 容器样式
  3. 列表渲染策略
  4. 每一行的 UI 结构

我们逐层拆解。


一、数据源:items 列表

final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

这是一个最简单的 静态数据源,但它抽象出了真实业务中最重要的概念:

ListView 永远只关心一个东西:itemCount + itemBuilder

真实业务中你会换成:

  • 接口返回的数据
  • 数据库查询结果
  • WebSocket 推送数据

但 ListView 的用法完全不变。


在这里插入图片描述

二、外层容器:Container + BoxDecoration

return Container(
  decoration: BoxDecoration(
    borderRadius: BorderRadius.circular(12),
    color: theme.colorScheme.surfaceContainerHighest,
  ),

这一层在鸿蒙适配中非常关键。

1. 为什么不用直接 ListView?

因为鸿蒙设计语言(Harmony Design)强调:

  • 模块化卡片
  • 圆角容器
  • 表面层级(Surface)

所以标准写法是:

列表外一定包一层“语义容器”

这样才能:

  • 控制圆角
  • 控制背景色
  • 控制阴影 / 层级
  • 和 ArkUI 设计风格一致

三、ListView.separated:工程级推荐写法

ListView.separated(
  itemCount: items.length,
  separatorBuilder: ...
  itemBuilder: ...
)

这是 Flutter 中 最推荐用于业务列表的写法

相比:

  • ListView(children: [])
  • ListView.builder(...)

separated 的优势是:

特性ListView.separated
自动分隔线
懒加载
性能友好
UI 结构清晰
适合复杂业务

四、分隔线:Divider 的工程含义

separatorBuilder: (context, index) => Divider(
  height: 1,
  color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
),

这一行非常“专业”。

1. 不写死颜色,而用 Theme

这是鸿蒙跨端开发的关键原则:

永远不要写死颜色,永远使用 Theme。

因为:

  • 鸿蒙支持深色模式
  • 支持动态主题
  • 支持系统级换肤
  • 支持多品牌定制

这一行:

theme.colorScheme.onSurface.withValues(alpha: 0.1)

代表:

使用当前主题下“文字颜色”的 10% 透明度作为分割线

这在设计系统里叫:

Semantic Color(语义色)

而不是 Hard Code。


五、ListTile:最标准的列表行组件

return ListTile(
  title: Text(items[index]),
  onTap: () {},
);

ListTile 是 Flutter 官方提供的:

企业级标准列表行组件

默认自带:

  • 左右 padding
  • 行高规范
  • 触摸反馈
  • 无障碍语义
  • 键盘导航支持(PC 端)

在鸿蒙 PC 场景下尤其重要:

  • 自动支持鼠标 hover
  • 自动支持键盘 focus
  • 自动支持触控点击

你什么都不用写。


在这里插入图片描述

六、两个关键参数:shrinkWrap + physics

shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),

这是非常典型的 嵌套列表写法

含义是:

  • 这个 ListView 不自己滚动
  • 高度由内容撑开
  • 通常用于:

    • 列表嵌套在 Column
    • 放在页面中间模块
    • 外层还有主滚动容器

在鸿蒙大屏页面中,这是最常见结构

Scaffold
 └─ SingleChildScrollView
     └─ Column
         ├─ Header
         ├─ Card
         │   └─ ListView (shrinkWrap)
         ├─ Footer

实际运行效果(HarmoList)

在 HarmonyOS 6.0 PC 上运行后效果是:

  • 圆角卡片
  • 浅色背景
  • 五行列表
  • 细分隔线
  • 点击有波纹反馈
  • 风格与鸿蒙系统设置页高度一致

视觉风格非常接近:

系统设置 / 文件管理 / 设备管理界面

这就是 “鸿蒙感”UI 的核心来源


心得(工程经验)

通过这个最简单的例子,其实已经体现了三条非常重要的工程原则:


1. Flutter 在鸿蒙不是玩具,是工程级方案

它不是 Demo 框架,而是:

  • 可跑生产系统
  • 可做复杂 UI
  • 可支撑大屏交互
  • 可适配分布式设备

2. ListView 是所有复杂页面的基础单元

任何复杂页面:

  • 设置页
  • 运维后台
  • 设备控制台
  • AI 管理界面

最终拆解后都是:

Header + ListView + Footer

3. Theme 是鸿蒙跨端的灵魂

不用 Theme = 一定翻车:

  • 深色模式崩
  • 品牌定制崩
  • 多设备风格不统一

这行代码价值极高:

theme.colorScheme.surfaceContainerHighest

它代表的是:

“让系统自己决定颜色,而不是我来决定。”

这是专业工程师和 Demo 工程师最大的区别。


总结

通过 HarmoList 这个极简示例,我们完成了:

  • Flutter 在 HarmonyOS 6.0 上的基础 UI 落地
  • 一个标准工程级 ListView 构建方式
  • 理解了 ListView.separated 的真实价值
  • 掌握了鸿蒙风格 UI 的核心设计思想

这段代码虽然只有几十行,但它背后代表的是:

Flutter × HarmonyOS 跨端开发的最小可行工程模型(MVP)

后续无论你要做:

  • 设置系统
  • 文件管理器
  • 运维控制台
  • 设备面板
  • AI 管理后台

所有复杂 UI,90% 都是从这个结构进化出来的。

一句话总结:

真正的跨端工程能力,不是炫技组件,而是把最简单的列表写到“专业级”。

在这里插入图片描述

通过 HarmoList 这个最基础的示例可以看到,Flutter 在 HarmonyOS 6.0 上的开发体验已经非常成熟,其 UI 构建模式与传统 Android / iOS 几乎完全一致,但在鸿蒙全场景设备体系下具备更强的延展性。从工程视角来看,一个看似简单的 ListView.separated,实际上已经完整体现了跨端开发中最关键的几个能力:数据驱动渲染、语义化主题适配、组件级 UI 复用以及面向大屏与多输入方式的交互支持。

更重要的是,这种写法并不是 Demo 级技巧,而是可以直接复用于真实业务系统的“标准工程模板”。无论是设置页、管理后台,还是设备控制面板,本质上都可以从这一基础结构演进扩展。可以说,真正掌握 Flutter × HarmonyOS 的第一步,并不是复杂架构设计,而是把这种最基础的列表组件写得足够规范、足够工程化、足够可复用。

作者:赵雁松,周岩珏,李志强,周永康,刘军

前言:AI 数据分析的“最后一公里”

在企业数字化转型的浪潮中,我们发现很多公司依然面临着“数据深渊”:业务人员想看数据,却受限于复杂的 SQL 语法;开发者虽然尝试了 Text-to-SQL,但生成的代码逻辑常有偏差,同时也无法应对复杂的统计分析、根因定位等场景。

DataAgent 应运而生。 这不是简单的指令翻译器,而是我们基于 Spring AI Alibaba 生态构建的一位“虚拟 AI 数据分析师”。它能够像专家一样思考、规划、纠错,并最终输出一份带图表、带逻辑、带深度洞察的行业级报告。

从架构上,DataAgent 是一款基于 Spring AI Alibaba 生态构建的、面向企业级复杂场景的“虚拟 AI 数据分析师”。它通过 Spring AI Alibaba Graph & Agent Framework 构建了一套具备自我规划、工具调用、反思纠错及人类干预能力的数据智能体(Agent),通过 graph、multi-agent 模式将确定性流程与模型推理结合在一起,搭建了一套兼具流程确定性与智能化的数据智能体产品。

降维打击:为什么 DateAgent 不止是 Text-to-SQL?

image

整体架构

image

核心黑科技:DateAgent 是如何解决企业难题的?

我们不只是在写代码,而是在解决企业数据决策中的“深水区”难题。以下是 DataAgent 攻克研发痛点、实现架构突破的几大核心战役。

4.1 人类反馈机制 (Human-In-The-Loop)

  • 遇到问题: 担心 AI 智商掉线?一个错误的执行计划可能瞬间拖垮生产库,甚至“一步错步步错”。
  • 解决方案:

    • 入口:运行时请求参数 humanFeedback=true(GraphController → GraphServiceImpl)
    • 数据字段:agent.human_review_enabled 用于保存配置,运行时以请求参数为准。
    • 图编排:PlanExecutorNode 检测 HUMAN_REVIEW_ENABLED,转入 HumanFeedbackNode
    • 暂停与恢复:CompiledGraph 使用 interruptBefore(HUMAN_FEEDBACK_NODE),无反馈时进入“等待”,反馈到达后通过 threadId 继续执行。
  • 反馈结果: 给 AI 穿上约束衣!同意、修改或驳回,都在你一念之间。让 AI 既有速度,又懂规矩。

image

image

4.2 Prompt 动态配置与自动优

  • 遇到问题: 修改一句 Prompt 就要重启系统?不同模型对 Prompt 脾气不同,一套模板走天下根本行不通。
  • 解决方案:

    • 配置入口:/api/prompt-config/*,数据表 user_prompt_config
    • 作用范围:支持按 agentId 绑定或全局配置(agentId 为空)。
    • Prompt 类型:report-generatorplannersql-generatorpython-generatorrewrite
    • 自动优化方式:ReportGeneratorNode 拉取启用配置(按 priority 与 display_order 排序),通过 PromptHelper.buildReportGeneratorPromptWithOptimization 拼接“优化要求”。
    • 当前实现重点:报告生成节点已落地优化;其他类型为预留能力。
  • 获得效果: 像配置 Excel 一样调优 AI。运维人员无需重启,即可让 DataAgent 瞬间从“菜鸟分析师”变身“首席架构师”。

image

image

4.3 深度 RAG 与混合检索增强

  • 遇到问题: 纯向量检索常召回一堆废话?AI 不认识你的业务缩写?表结构太复杂,AI 搜不到。
  • 解决方案:

    • 查询重写:EvidenceRecallNode 将多轮上下文与用户问题组装为检索指令,调用 LLM 生成 standaloneQuery,避免上下文遗漏与歧义。
    • 召回通道:AgentVectorStoreService 作为统一入口,默认走向量检索;开启混合检索后走 AbstractHybridRetrievalStrategy,将“向量召回 + 关键词召回”进行融合。(用户需要提供混合检索实现。当前默认只支持 es)
    • 召回过滤:DynamicFilterService 生成基于智能体与知识类型的过滤条件,限制检索范围,避免跨智能体串库。
    • 文档类型:业务知识(business_knowledge)+ 智能体知识(agent_knowledge)两类,按 agentId/type 元数据过滤后合并为 evidence,注入后续 prompt。
    • 关键配置:spring.ai.alibaba.data-agent.vector-store.enable-hybrid-search 控制是否开启混合检索;相似度阈值与 TopK 通过向量库配置项控制(如 top-ksimilarity-threshold)。
    • 输出形式:evidence 文档以标题/摘要/片段形式汇总,作为 EvidenceRecallNode 输出内容进入后续规划于 SQL 生成阶段。
  • 获得效果: AI 拥有了老员工的“直觉”。它能秒懂你的业务逻辑,即便表名全是乱码,它也能精准命中。

image

image

4.4 容器化 Python 执行引擎

  • 遇到问题: SQL 只能算数,不能预测。想看趋势图、做线性回归?SQL 此时显得苍白无力。
  • 解决方案:

    • 代码生成:PythonGenerateNode 根据计划与 SQL 结果生成 Python。
    • 代码执行:PythonExecuteNode 使用 CodePoolExecutorService(Docker/Local/AI 模拟)。
    • 执行配置:spring.ai.alibaba.data-agent.code-executor.*(默认 Docker 镜像 continuumio/anaconda3:latest)。
    • 结果回传:执行结果写回 PYTHON_EXECUTE_NODE_OUTPUTPythonAnalyzeNode 汇总后写入 SQL_EXECUTE_NODE_OUTPUT,用于最终报告。
  • 获得效果: 赋予 AI 科学家级的建模能力。不仅能提取数据,还能输出带图表、带算法、带深度预测的高质量产出。

image

image

4.5 流式输出 (SSE) 与多轮对话管理

  • 遇到问题: 分析任务耗时太长,用户盯着屏幕转圈圈,以为系统挂了。
  • 解决方案:

    • 流式输出:GraphController SSEGraphServiceImpl 流式处理。
    • 文本标记:TextType 在流中标记 SQL/JSON/HTML/Markdown,前端据此渲染。
    • 多轮对话:MultiTurnContextManager 记录“用户问题+规划结果”,注入到后续请求。
    • 模式切换:spring.ai.alibaba.data-agent.llm-service-type 支持 STREAM/BLOCK
  • 获得效果: 极致的交互快感!让用户亲眼看到 AI 正在如何“思考”与“推演”,每一秒都有获得感。

image

image

4.6 MCP 服务器发布与多模型调度

  • 遇到问题: DataAgent 虽好,但只能在自研系统用?想集成到 Claude 或 IDE?适配成本高到吓人。
  • 解决方案:

    • MCP:McpServerService 提供 NL2SQL 与 Agent 列表工具,使用 Mcp Server Boot Starter。
    • 多模型调度:ModelConfig 配置模型,AiModelRegistry 缓存当前 Chat/Embedding 模型并支持热切换(同一时间每类仅一个激活模型)。
    • 已内置工具:nl2SqlToolCallback、listAgentsToolCallback
  • 获得效果: 无处不在的 AI 生产力。它是你的数据中心,也是你办公软件里随叫随到的超强插件。

image

image

4.7 多数据源接入

  • 遇到问题: 企业数据散落在 MySQL、PostgreSQL 等各类库中,跨库取数像是在做“情报搜集”,配置繁琐且标准不一。
  • 解决方案:

    • 元数据存储:数据源配置写入 datasource,智能体绑定写入 agent_datasource,选表写入 agent_datasource_tables,逻辑外键写入 logical_relation
    • 类型扩展:BizDataSourceTypeEnum 定义数据源类型;对应的 Accessor + DBConnectionPool 负责不同数据库协议与方言的访问。
    • Schema 初始化:AgentDatasourceController 触发初始化,SchemaService 通过 AccessorFactory 拉取表/列/外键并写入向量库。
    • 运行时选择:DatabaseUtil 从当前智能体获取激活数据源,动态选择 Accessor 执行 SQL。
    • 约束:同一智能体同一时间仅允许启用一个数据源(AgentDatasourceService.toggleDatasourceForAgent)。
  • 获得效果: 一个智能体,纵览全司数据!无论数据在哪儿,DataAgent 都能精准“路由”。它是数据孤岛的终结者,让跨库分析像查询单表一样简单。

image

image

4.8 报告生成与摘要建议

  • 遇到问题: 查出来一堆数字有什么用?领导要的是洞察,是结论,是能直接发在群里的 HTML 报告。
  • 解决方案:

    • 报告节点:ReportGeneratorNode 读取计划、SQL/Python 结果与摘要建议(summary_and_recommendations)。
    • 输出格式:默认 HTML,plainReport=true 输出 Markdown(简洁报告)。
    • 优化提示词:自动拼接优化配置后生成报告。
  • 获得效果: 把分析师的一天缩短为 10 秒。从查数到成稿,DataAgent 承包了所有体力活,让你只负责最后的一锤定音。

image

4.9 NL2SQL 转换, 语义模型,逻辑外键引擎

  • 遇到问题: 纯大模型写 SQL 经常“盲目自信”,不是字段写错,就是不懂业务术语。语法错误导致的执行中断更是家常便饭。
  • 解决方案:

    • 语义模型层:通过管理端定义的术语映射规则,在生成阶段强制约束。
    • 两阶段校验:SqlGenerateNode 生成后接 SemanticConsistencyNode 检查语义一致性。
    • 自愈循环:SqlExecuteNode 捕获执行错误并反馈给 Graph 状态机,触发重定向至重写节点进行纠错。
    • 逻辑外键:写入外部的业务逻辑的外键,不写入业务数据库。增强对表的理解能力。
  • 获得效果: 让 AI 拥有“职业分析师”的严谨。 告别报错,告别幻觉。它不仅懂 SQL 语法,更懂你的业务逻辑,让每一次查询都精准命中。

4.10 API Key 与权限管理

  • 遇到问题: 接口裸奔?权限失控?想对外开放能力却怕费用爆炸或数据泄露。
  • 解决方案:

    • 管理端:AgentController 支持生成、重置、删除与启用/禁用 API Key。
    • 数据字段:agent.api_key 与 agent.api_key_enabled
    • 调用方式:请求头 X-API-Key
    • 注意:默认不开启鉴权拦截;生产需开启 spring.ai.alibaba.data-agent.api-key.enabled=true
  • 获得效果: 生产级安全防护。让你的 DataAgent 不仅是业务利器,更是安全可控的企业级数字资产。

image

image

结语:让数据价值触手可及

DataAgent 的核心价值在于,它不仅仅是完成了一次查询,而是将“数据处理的工程化”与“大模型的推理能力”深度结合。结合 Spring AI Alibaba  的 Graph 编排与 Agentic 推理能力,DataAgent 将确定性流程与模型推理结合在一起,将原本碎片化的分析过程,转化为了兼具流程确定性与智能化的数据智能体。

未来,数据不再是冷冰冰的行列,而是每一位业务决策者都能随手调用的“智库”。

想了解更多关于 DataAgent 的技术实现细节? 欢迎搜索钉钉群,群号: 154405001431,加入我们的开发者讨论群,共同探索 AI 的无限可能!

相关资源:

基本介绍

我做了一款基于小模型的拍照识别物品的 APP ,先录入物品的特征,可以从四个角度各拍一张照片,让模型能记住这个物品的特征。

然后点击 [识别特征] ,对着要识别的物品拍一张照片,点击识别,即可根据相似度进行查询。相似度的阈值可以在设置里面调整。

项目代码地址: https://gitee.com/mktime/object-detect

效果演示

APP 首页

拍照识别

世界范围内数字化进程正在不断加快,全球化与数字化开始深融合。在此等时代背景下,大型企业的业务版图正趋于多元化,突破单边限制。域名也是如此,从独立的域名,逐渐扩展至集团官网、独立子品牌、区域业务站点、品牌电商等。随着企业规模的不断增大和业务版图的扩充,数字资产逐渐分布至企业旗下数十甚至上百个域名。面对数量众多的网站,管理难度呈现指数级增长。单以数字证书而论,从申请到部署,从监控到续期,数百个域名的管理难度可想而知,稍有疏漏便可能引发连锁效应,让企业面临漏洞威胁与业务中断风险。JoySSL市场部负责人曾多次提到,单域名证书的管理模式已不适合大型企业的复杂架构,不仅效率低下,还会造成企业额外的成本支出。多域名SSL证书则是化繁为简,实现企业运维管理简化、优化成本结构的战略工具,是大型企业拥抱数字生态的基础。

多对一高效管理凸显证书核心优势

拥有多域名的大型企业,SSL证书通常缺乏统一管理视角,易造成资产无法统筹、证书过期以及安全策略不一致等诸多问题。多域名SSL证书可实现集中式管理,摒弃“证书分散现象”,打造统一的管理体系,对所有受保护的域名实现统一监控、快速续约与策略管理,告别碎片化管理模式。

多域名SSL证书可完成高效的成本管理,优化总体拥有成本,节约资源与人力,减少了证书审批、部署与日常运维的成本消耗,使企业团队能够专注于战略性的任务。

超越技术 赋能大型企业开展业务

部署多域名SSL证书,已成为企业集团化与多品牌战略的安全统一保障,为各子品牌网站提供统一且可信的高级安全标识,增强市场对品牌专业形象的认可,维护企业整体声誉。面对严格的审计标准,通过多域名证书,企业可向审计机构展示全面的安全管理措施,从而显著简化合规流程。

多域名证书支持收购整合与业务创新的快速反应能力,从而实现安全而高效的资源整合。此外,证书可提供标准化且高安全性的保护,确保生态伙伴服务的稳定性。

多域名SSL证书优化管理解决方案

OV及EV证书可确保企业在身份验证方面达到最高标准,提升公众对企业可信度的感知,提升品牌价值。此外,面对复杂的网络环境,JoySSL自动化证书管理平台能够实现证书与域名的高效识别、批量化部署、智能化监控预警,以及全流程的自动续期功能,使证书管理无缝嵌入企业数字化生态系统,保障企业数字基础设施的安全稳定运行。

以简约之道主动构建网络安全架构

多域名证书以化繁为简之道,配合专业的管理方案,推动企业从被动应对转为主动构建安全架构,通过高度集成的系统,使众多域名协同运行,提升整体防御能力。不仅是技术升级,更是企业管理理念的深刻蜕变。

近一周行情呈现出一种无序混沌的状态,硬科技与资源股回撤跌的比较狠,幸好没碰。午盘后拉了消费板块,我手里的消费电子或许能跟着喝口汤。

我的持仓:2 个医药+1 个医疗器械+2 消费电子+1 自动驾驶+1 美容护理
今天账户+3%跳水到+1%,还行,满足了。

Cloudflare发表了一篇博客文章,展示了在 Workers 上运行的无服务器 Matrix 家庭服务器,引发了关于 AI 生成代码和技术准确性的争论。虽然 Matrix.org 对 Cloudflare 的关注表示欢迎,但联合创始人 Matthew Hodgson指出,这篇文章“严重夸大了项目的范围”,强调了功能性 Matrix 服务器所需的核心功能缺失。

 

这篇博客声称已经在 Cloudflare 的边缘平台上构建了一个完整的 Matrix 家庭服务器,用 Cloudflare 的 D1 和 Durable Objects 等原语取代了 PostgreSQL 和 Redis。GitHub存储库最初将自己描述为“生产级”,并有一个“部署到 Cloudflare”的按钮。

 

Hodgson 在 Matrix.org 网站上的回应很圆滑,但很明确:

 

代码还没有实现 Matrix 的任何核心特性,这些特性允许你安全地进行联邦,因此还没有构成一个功能性的 Matrix 服务器,更不用说生产级服务器了。

 

他指出,该实现没有将房间建模为复制的事件图,没有检查权限,也没有维护权限级别——将其比作“忽略权限的文件系统,或者不实现共识机制的区块链。

 

代码库在关键部分包含了 TODO 注释,例如 TODO: 在身份验证逻辑中的检查授权。状态解析(Matrix 用于处理跨分布式房间的冲突事件的算法)没有实现。尽管声称支持“完整的 Matrix 端到端加密堆栈”,但端到端加密验证似乎不完整。

 

Hacker News上的社区反应表明,有迹象表明 AI 提供了大量的帮助。评论者指出:

 

“我们做了 X”的博客文章最终变成了“我们做了 X 的一部分演示”,这在整个行业中已经过时了。解决方法很无聊:你只需要明确你所创造的内容。”另一位评论道:“基础设施公司的技术博客过去有两个目的:展示专业知识并建立信任。当帖子开始过度承诺时,你就失去了这两者。

 

Matrix 的开发人员 Jade Ellis 在Mastodon上写道,存储库在自述中显示了“有错位的 ASCII 图”。待办事项分散在各处。这表明代码带有未经彻底审查的 AI 生成输出的特征。

 

Hodgson 承认使用 LLM 来制作不熟悉的协议原型是一种挑战:

 

如果你正在使用 LLM 来原型化一个不熟悉的协议的实现,那么你可能不知道在哪里检查代理是否夸大了事实。

 

他表达了对作者的同情,同时注意到对“过度热情地使用 LLM,特别是如果他们自己投入了大量的时间和精力来理解和构建功能 Matrix 实现。

 

Cloudflare 在发布大约六小时后更新了这篇博文,并添加了一个免责声明,称其描述了一个概念验证和一个个人项目。然而,更新没有撤回正文中的特定技术声明。

 

尽管有这些批评,Hodgson 还是强调了这个演示“成功地说明了 Cloudflare Workers 是如何工作的,而且这些代码肯定可以作为未来工作服务器的基础。”他指出,Matrix 和 Cloudflare 在其他方面也有合作,包括使用 Cloudflare Calls 作为 MatrixRTC 后端的概念验证,Cloudflare 的 CDN 多年来一直保护着 matrix.org 的流量。

 

在无服务器基础设施上运行 Matrix 的技术方法仍然是可行的。这篇文章描述了用 D1 (SQLite)取代 PostgreSQL,用 KV 存储取代 Redis,并使用持久对象进行房间状态管理。这些架构选择可以在正确实现 Matrix 的核心联合和安全特性的情况下工作。

 

对于考虑使用 AI 辅助开发的开发者来说,这一事件凸显了未经审查的 AI 输出的风险。夸大 AI 生成实现的模式已成为技术博客中反复出现的问题,引发了对基础设施公司审查流程的质疑。

 

Hodgson 总结说,Matrix 基金会依靠会员费来资助规范工作、信任和安全工具以及生态系统支持。虽然组织成员在过去的一年里翻了一番,但基金会的财务状况还无法维持下去。他表示希望像 Cloudflare 这样受益于 Matrix 的公司可以考虑加入为会员。

 

Cloudflare 的博客文章和更新后的免责声明仍然有效。

 

原文链接:

https://www.infoq.com/news/2026/02/cloudflare-matrix-homeserver-ai/

Cursor 近日公布了 Agent Trace 开放规范草案,目标是解决 AI 生成代码在软件项目中的归属与标注问题。该提案以 RFC 形式发布,定义了一种厂商中立的格式,用于在版本控制系统中记录 AI 与人类协作产生的代码贡献。

基于其在 AI 辅助编程工具方面的实践经验,Cursor 发现,代码变更过程中对上下文的追踪能力仍然明显不足。以常见的 git blame 等工具为例,它们只能显示某一行代码“何时被修改”,却无法说明这次修改是由人类完成、由 AI 完成,还是二者协作的结果。Agent Trace 正是为了解决这一缺口,试图以结构化、可互操作的方式捕获这些关键信息。

从技术角度看,Agent Trace 是一套数据规范,使用基于 JSON 的 trace record(追踪记录)来关联具体的代码范围,以及背后的对话过程和参与者。代码贡献可以在文件级或行级进行追踪,按会话进行分组,并被标注为“人类”、“AI”、“混合”或“未知”。该模式还支持为 AI 生成的代码附加可选的模型标识,从而在不绑定具体厂商的前提下,实现更精确的归属记录。

此处输入图片的描述

在设计上,这一规范刻意保持了对存储方式的“中立性”。Cursor 并未规定追踪记录必须存放在哪里,开发者可以根据自身需求,将其保存为普通文件、git notes、数据库记录,或采用其他机制。Agent Trace 同时支持多种版本控制系统,包括 Git、Jujutsu 和 Mercurial,并引入了可选的内容哈希,用于在代码被移动或重构后,依然能够追踪其原始归属。

可扩展性是 Agent Trace 的核心设计目标之一。各厂商可以通过命名空间键(namespaced keys)附加额外的元数据,而不会破坏规范的兼容性。同时,该规范刻意回避了对 UI 形式、代码所有权语义的定义,也不试图评估代码质量或追溯训练数据来源,而是将关注点严格限定在“代码归属”和“可追溯性”本身。

Cursor 还提供了一份参考实现,展示 AI 编程代理如何在文件发生变化时,自动捕获并生成追踪记录。尽管示例基于 Cursor 自家的工具链,但其设计模式被明确定位为可复用方案,适用于其他编辑器和智能代理。

来自开发者社区的早期反馈,普遍强调了这一规范在代码审查和调试流程中的潜在价值。一位 X 用户评论道:

这才是真正在收拾 Agent 生成代码的烂摊子。等不及在 Review 里用了。

另一位用户则从可复现性的角度给予了肯定:

团队一旦搞不清 Agent 为啥跑偏,就会直接停工。Trace 解决了这个痛点,开放得正好。

作为一份 RFC,Agent Trace 明确欢迎社区反馈,同时也有意保留了一些尚未解决的问题,例如在合并(merge)、变基(rebase)以及大规模代理驱动代码变更场景下应如何处理。Cursor 将该提案定位为一个共同标准的起点,而非终极答案,以应对 AI 代理在软件开发流程中日益普及的现实趋势。

原文链接:

https://www.infoq.com/news/2026/02/agent-trace-cursor/

随着数字化的发展,传统行业也面临着数字化的改革要求,而其中钢铁行业的数字化需求是比较复杂和急迫的。而电子签章作为数字化中不可缺少的一部分同样在钢铁行业中的意义极其重要。钢铁行业对于电子签章的需求主要源于其流程复杂、参与方多、合规要求高、单据频繁等特点。

1.核心业务场景需求

1) 采购与销售合同签署

Ø 与矿石、煤炭等供应商的大额采购合同。

Ø 钢材销售合同(涉及贸易商、终端客户)。

Ø 需支持多方签署、跨境签署及长期合同管理。

2) 物流与仓储单据

Ø 提货单、运单、仓单的电子化签署。

Ø 实现物流公司、仓库、客户之间的快速流转。

3) 质检与合规文件

Ø 质量检验报告、产品合格证等需权威部门签字盖章。

Ø 环保、安全监管文件的合规存档。

4) 内部流程审批

Ø 生产计划单、设备采购申请、财务报销等内部流程。

Ø 需要各级负责人快速批阅,避免纸质传递延迟。

5) 供应链金融

Ø 与银行、金融机构的融资协议、仓单质押文件。

Ø 需符合《电子签名法》及金融监管要求。

2.核心功能需求

1) 强法律效力

Ø 符合《电子签名法》要求,支持CA数字证书、时间戳、区块链存证。

Ø 可对接司法鉴定机构,提供出证服务。

2) 高集成能力

Ø 与ERP(如SAP、用友)、OA、CRM、物流系统等无缝集成。

Ø 支持API批量调用,适应钢铁企业现有IT架构。

3) 全流程管控

Ø 从发起、审批、签署到归档的全链路追踪。

Ø 支持撤回、作废、补充签署等灵活操作。

4) 移动化签署

Ø 支持手机、平板等移动端签署,方便外勤人员(如销售、物流)。

Ø 可结合短信/微信通知,提升签署效率。

5) 安全与权限控制

Ø 印章权限分级管理(如集团统一管控子公司用章)。

Ø 操作留痕、防篡改、防伪造,支持人脸识别等身份核验。

3.行业特殊需求

1) 大宗交易合规性

单价高、数量大,需确保合同条款无篡改,保留完整证据链。

2) 跨境贸易适配

进口铁矿石、出口钢材时,需支持国际数字证书互认。

3) 复杂签署流程

一份合同可能涉及供应商、钢厂、物流、银行等多方,需支持会签、轮签等模式。

4) 环境适应性

部分生产场景(如钢厂车间)网络条件有 限,需支持离线签署或弱网环境处理。

4.实施途径

1) 分阶段推进

优先从内部审批、供应商对账等高频场景试点,逐步推广至销售、物流等核心环节。

2) 选择专业服务商

Ø 需选择在制造业或大宗商品领域有成熟案例的电子签章服务商。

Ø 确保服务商具备等保三级、ISO27001等安全资质。

3) 制度配套

制定企业电子签章管理办法,明确使用范围、审批权限和法律责任。

4) 培训与推广

针对业务人员(如采购、销售)和技术人员分别培训,降低使用门槛。

5.预期收益

1) 效率提升

合同签署周期从数天缩短至几分钟,加速交易周转。

2) 成本降低

减少纸张、打印、快递、仓储管理成本。

3) 风险控制

全流程可追溯,减少印章冒用、合同篡改等风险。

4) 数字化转型

推动钢铁企业向“智慧供应链”转型,提升行业竞争力。

6.注意事项

1) 法律合规:涉及国际业务时需确认目标国对电子签章的认可程度。

2) 系统兼容性:确保与老旧工业系统(如MES)的对接可行性。

3) 长期存证:重要文件需保障10年以上可查验、可取证。

如果需要进一步针对具体场景(如“钢厂与经销商订单流程”或“跨境铁矿石采购”)设计解决方案,可咨询专业的电子签章厂商,如:北京安证通、契约锁、法大大等。

本文首发于 Aloudata 官方技术博客:《告别伪一体!Aloudata CAN 真·管研用一体的落地路径与价值佐证》转载请注明出处。

摘要:本文深入探讨了传统指标平台在实现“管、研、用”一体化时面临的三大核心痛点:口径管理混乱、研发效率低下、使用成本高昂。针对这些问题,文章介绍了基于 NoETL 语义编织技术的 Aloudata CAN 平台如何通过统一语义层和智能物化引擎,构建“定义即开发、治理、服务”的自动化闭环。同时,提供了从战略筹备到价值深化的四步走落地路径,并结合平安证券、麦当劳等标杆客户的量化成效,为企业数据治理与指标体系建设提供可复制的实践指南。

在数据驱动决策的时代,企业普遍希望通过建设指标平台来统一数据口径、提升分析效率。然而,许多项目最终却陷入“伪一体”的困境:管理、研发、使用三个环节依然割裂,导致口径混乱、响应迟缓、成本高昂。本文将深度解构传统模式的痛点,并阐述 Aloudata CAN 如何基于 NoETL 语义编织技术,实现真正的“管研用一体”,并提供已验证的落地路径与价值佐证。

一、 传统“伪一体”模式的三大核心痛点

传统模式下,“管、研、用”的割裂主要体现在技术架构和协作流程上,形成了事实上的信息孤岛。

  • “管”的痛点:静态元数据目录,口径管理失控
    依赖静态的元数据目录(Catalog)仅能记录指标来源,无法承载动态的业务逻辑变化。指标口径的维护高度依赖人工沟通和文档,极易出现偏差,导致跨部门会议沦为“数据辩论会”,决策效率低下。
  • “研”的痛点:固化物理宽表,敏捷响应受阻
    分析路径被预建的物理宽表所固化。任何新的分析维度组合需求,都可能需要启动一次新的 ETL 任务开发、测试和上线,周期以“天”或“周”计,严重拖慢业务响应速度。
  • “用”的痛点:烟囱式开发,成本居高不下
    “烟囱式”的开发模式为每个报表或应用单独建设物理宽表,导致数据仓库中充斥着大量相似、冗余的中间表。这不仅消耗巨大的存储和计算资源,还形成了沉重的技术债,使得总拥有成本(TCO)持续攀升。

这三个环节的割裂,使企业始终在“数据分析不可能三角”(口径统一、敏捷响应、成本可控)中艰难妥协。

二、 Aloudata CAN 的“真·管研用一体”技术架构

Aloudata CAN 基于 NoETL 语义编织 (Semantic Fabric) 技术,通过两大核心引擎重塑协作范式,实现逻辑定义与物理执行的解耦。

  1. 统一语义层(虚拟业务事实网络):作为“管”的基石,数据团队无需预先物理打宽。只需通过声明式策略,基于 DWD 明细数据定义业务实体间的逻辑关联(Join),系统即在逻辑层面构建一个“虚拟明细大宽表”。所有指标均基于此统一语义层定义,从根本上保证口径一致。
  2. 智能物化加速引擎:作为“研”的自动化核心,基于用户对指标和维度的声明式加速策略,系统自动编排物化任务,生成并维护最优的物化视图。查询时,语义引擎自动进行 SQL 改写和智能路由,透明命中最优物化结果,实现亿级数据秒级响应(P90<1s)。
  3. 开放化指标服务:作为“用”的统一出口,通过标准 API/JDBC,一处定义的指标可向 FineBI、Quick BI、自建应用、AI 大模型等任意消费端提供统一、实时、准确的数据服务。

至此,形成了“定义即开发、定义即治理、定义即服务”的自动化闭环。

三、 四步走落地路径:从试点到深化

基于众多客户实践,成功落地“真·管研用一体”可遵循以下四阶段模型:

阶段一:战略筹备与灯塔选择(第1-2个月)

  • 关键动作:组建跨部门联合项目组,选择1-2个业务价值明确、痛点清晰的高频场景(如核心业务报表)作为“灯塔项目”。

阶段二:价值验证与能力内化(第3-4个月)

  • 关键动作:在平台中快速配置并上线灯塔场景指标,让业务分析师掌握声明式定义方式。重点产出量化成效报告,如“指标交付周期从2周缩短至2天”,建立内部信心。

阶段三:全面推广与组织建设(第6-12个月)

  • 关键动作:将已验证模式推广至其他业务线,建立企业级的指标规范、开发流程和治理章程,形成可持续的协同机制。

阶段四:生态融合与价值深化(长期)

  • 关键动作:将平台作为统一的指标服务中台,与BI、AI、业务系统深度集成,构建坚实的 AI-Ready 数据底座,激活数据民主化。

四、 价值佐证:标杆客户的量化成效

多个行业头部客户的实践数据,验证了该模式在提效、降本、增质方面的显著价值。

客户行业核心场景关键量化成效模式验证
证券(平安证券)指标统一管理、业务自助分析开发工作量减少 50%,效率提升 10 倍,指标口径 100% 一致,TCO 节约 50%“136”协作模式(10% 科技+30% 分析师+60% 业务)
餐饮(麦当劳中国)实时业绩监控、智能归因沉淀 1000+ 指标、250+ 维度,百亿级数据 P90<1s,日均百万级 API 调用覆盖 30+ 业务场景的标准化指标服务
服饰(某头部品牌)营销活动分析1 个月沉淀 300+ 指标,指标开发维护成本降低 70%,决策效率提升 10 倍361 个指标 × 120 个维度的沉淀复用机制
央国企(中交一公局)集团数据治理、智能问数业务自助完成 80% 数据需求,问数准确率达 92%AI-Ready 数据底座的构建

五、 实施建议:确保成功的五个关键动作

  1. 技术策略:采用“存量挂载、增量原生、存量替旧”的三步走资产演进法则,平滑过渡。
  2. 组织保障:建立业务与IT的联合项目组,确保需求与技术双向对齐。
  3. 切入点选择:优先解决“高频高痛”的报表或分析场景,快速交付可见价值。
  4. 能力建设:重点培训业务分析师掌握“声明式指标定义”,激活数据自服务。
  5. 价值度量:明确上线前后的效率、成本、质量基线,用数据证明ROI。

六、 常见问题解答(FAQ)

Q1: Aloudata CAN 和传统指标平台或 BI 内置的指标模块有何本质区别?

传统方案是静态的元数据目录,仅记录来源,无法保证逻辑同步更新,且分析受限于物理宽表。Aloudata CAN 是一个动态的语义计算引擎,基于 DWD 明细层构建“虚拟业务事实网络”,实现一处定义、处处使用、自动计算。

Q2: 引入 Aloudata CAN 是否需要推翻现有的数据仓库和 BI 工具?

不需要。平台采用 Headless 架构,向下对接现有 DWD 层,向上通过标准接口服务各类 BI 工具。其目标是“做轻数仓”,通过减少不必要的物理宽表来优化现有架构。

Q3: 如何衡量“真·管研用一体”项目的成功?

可从三个维度衡量:效率(如指标平均交付周期)、成本(如中间表减少数量、TCO下降)、质量(如跨部门数据一致性、问题工单数)。建议项目启动前确立基线。

Q4: 数据治理基础较弱的企业,直接上这种平台门槛是否太高?

相反,这是实现“弯道超车”的机遇。平台通过配置化、低代码方式降低技术门槛,帮助企业跳过“先乱后治”阶段,一步到位构建统一、敏捷的数据服务能力。

七、 核心要点总结

  1. 痛点根源:传统模式的失败源于静态元数据目录、固化物理宽表与烟囱式开发流程的技术性割裂。
  2. 技术内核:Aloudata CAN 通过 NoETL 语义编织构建统一语义层,结合智能物化引擎,实现“定义即开发、治理、服务”的自动化闭环。
  3. 落地路径:遵循“战略筹备→价值验证→全面推广→生态深化”的四步模型,以业务价值驱动。
  4. 价值实证:多个行业实践表明,该模式能带来指标开发效率提升 10 倍以上、口径一致性 100%、TCO 降低 50% 的量化成效。
  5. 战略意义:这不仅是一次技术升级,更是构建 AI-Ready 数据底座、实现数据民主化的战略投资。
    • *

本文更详细的技术实现、架构图与案例细节,请访问 Aloudata 官方技术博客阅读原文:https://ai.noetl.cn/knowledge-base/aloudata-can-real-path-val...

现在小学不布置寒假作业了,需要自己买题给孩子学。我就想是不是可以针对一二年级的知识点做一个在线刷题学习的,再增加一点游戏性。

目前每天让他学几分钟,感觉还是可以的,分享给大家。

地址: https://yinianji.vercel.app/
技术栈:
React 19 + TypeScript + Vite 7
PWA 支持(离线缓存、可安装)
Web Audio API (原生音频)

有什么建议欢迎给我反馈。
tupian1
tupian2
tupian3
tupian4

在当今大语言模型快速发展的时代,推理能力已成为决定模型表现的关键因素。然而,许多开发者和用户可能没有意识到,通过精心设计的提示词技术,可以显著提升模型在复杂推理任务中的表现。本文将深入探讨四种前沿的推理增强提示技术:思维链(Chain of Thought, CoT)、自一致性(Self-Consistency)、思维树(Tree-of-Thought, ToT)和ReAct,分析它们的原理、应用场景及最佳实践,帮助你更有效地利用这些技术提升AI应用的推理质量。

关键要点

  • 思维链(CoT)通过引导模型分步推理,显著提升数学和逻辑问题的准确性
  • 自一致性(SC)通过多路径采样和多数投票机制,增强推理结果的稳定性
  • 思维树(ToT)采用树状结构探索多条推理路径,适用于复杂规划任务
  • ReAct结合推理与行动,通过迭代循环提升复杂任务的解决能力
  • 四种技术各有优劣,可根据任务复杂度和计算资源选择最适合的方法

一、思维链(Chain of Thought, CoT):基础推理增强技术

思维链(CoT)是推理增强提示技术中最基础、应用最广泛的方法。其核心思想是引导模型不要直接给出答案,而是通过逐步推理的方式展示思考过程,类似于人类解决复杂问题时的思考模式。

1.1 CoT的工作原理

CoT通过在提示词中添加引导性语句,如"Let's think step by step"(让我们一步步思考),激发模型的推理能力。具体来说:

  • 分步推理:模型被引导将复杂问题拆分为一系列简单的中间步骤
  • 逻辑展示:模型在输出最终答案前,先展示推理过程
  • 逐步验证:每个中间步骤都可以被验证,提高整体推理的可靠性

例如,对于数学问题"如果John有3个苹果,送出1个,还剩几个?",使用CoT提示后,模型会先输出推理过程:

"John最初有3个苹果。
他送出1个苹果。
所以剩下的苹果数量是3-1=2。
因此,答案是2。"

这种分步思考方式大大提高了模型在多步骤推理任务中的准确性。

1.2 CoT的实现方式

CoT主要有三种实现方式:

实现方式说明适用场景
零样本CoT直接添加"Let's think step by step"引导语简单推理任务,如基础数学题
少样本CoT提供几个包含推理过程的示例复杂推理任务,如多步骤数学题
自动CoT模型自动生成推理链开放域问题,如创意写作中的逻辑推导

零样本CoT是最简单直接的方法,只需在问题前添加引导性语句即可。例如:

"John有3个苹果,送出1个,还剩几个?
让我们一步步思考:"

少样本CoT则需要提供几个包含推理过程的示例,帮助模型学习如何生成推理链。例如:

"示例1:
问题:5个孩子每人有4块饼干,总共有多少块饼干?
让我们一步步思考:
每个孩子有4块饼干,共有5个孩子。
所以总共有4×5=20块饼干。
答案:20块饼干。"

"示例2:
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
让我们一步步思考:
假设所有动物都是鸡,那么会有35个头和70条腿(35×2)。
实际有94条腿,多出24条腿。每头牛比鸡多2条腿,所以牛的数量是24÷2=12头。
鸡的数量是35-12=23只。
答案:23只鸡和12头牛。"

"现在,请解决这个问题:
停车场有3辆车,又有2辆车到达,现在有多少辆车?
让我们一步步思考:"

1.3 CoT的优势与局限

优势

  • 实现简单,只需添加引导性语句
  • 提升模型在数学、逻辑推理等任务的准确率
  • 增加推理过程的可解释性
  • 无需额外训练或微调模型

局限

  • 输出稳定性不足,多次运行可能得到不同结果
  • 无法处理多路径依赖的复杂问题
  • 单线性推理容易受早期错误影响

根据研究数据,CoT在GSM8K数据集上将模型的准确率提升了约17.9%,证明了其在数学推理任务中的有效性。然而,对于更复杂的问题,如需要探索多种可能路径的任务,CoT的局限性就显得明显。

二、自一致性(Self-Consistency):CoT的稳健性增强

自一致性(SC)是对CoT的改进方法,通过多路径采样和多数投票机制,显著提高推理结果的稳定性。它假设一个复杂问题可能有多种解决路径,但正确答案通常会在多次采样中被频繁生成。

2.1 SC的工作原理

SC的核心机制包括三个步骤:

  1. 多次采样:让模型针对同一个问题生成多个不同的推理路径
  2. 多数投票:统计这些路径的最终答案,选择出现频率最高的答案作为最终结果
  3. 结果聚合:将多个推理路径的结果整合,提高最终答案的可靠性

与CoT相比,SC的关键区别在于它不依赖单一推理路径,而是通过"群体智慧"选择最一致的答案。这种方法类似于让多位专家独立思考同一问题,然后采纳他们共同认同的结论

例如,在解决"37×42"这样的乘法问题时,SC会生成多个推理路径:

路径1:37×40=1480,37×2=74,1480+74=1554
路径2:40×42=1680,减去3×42=126,得到1680-126=1554
路径3:30×42=1260,7×42=294,1260+294=1554
路径4:错误路径:37×42=1454

通过多数投票,正确答案1554会被选中,而错误答案则被过滤。

2.2 SC的实现方式

SC的实现需要结合采样技术与结果聚合策略:

  • 采样设置:启用随机采样而非贪婪解码,通常设置do_sample=True和较高的温度值(0.7-0.9)
  • 样本数量:建议生成5-10个不同的推理路径
  • 投票机制:简单的多数投票或加权投票(考虑模型置信度)

以下是SC的Prompt模板示例:

"请解决以下数学问题,生成5个不同的推理路径,然后选择最常见的正确答案。
问题:停车场有3辆车,又有2辆车到达,现在有多少辆车?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"

2.3 SC的优势与局限

优势

  • 显著提高推理结果的稳定性
  • 通过多数投票机制过滤错误
  • 不依赖于复杂的模型架构或训练
  • 在数学问题、逻辑推理等任务中表现优异

局限

  • 计算成本高,需要多次模型调用
  • 仅关注最终答案的一致性,不评估推理过程本身
  • 在某些任务中,正确答案可能不会被频繁生成

SC在计算资源有限的情况下,建议先从少量样本(如3-5个)开始,以实现大部分性能提升。根据研究,SC在GSM8K数据集上比CoT高出约12.2%的准确率,证明了其在复杂推理任务中的有效性。

三、思维树(Tree-of-Thought, ToT):复杂规划任务的解决方案

思维树(ToT)是推理增强提示技术中最复杂、也最强大的方法。它超越了CoT的线性思维和SC的简单多数投票,将推理过程结构化为树形分支,在每一步探索多个可能的推理方向,并通过评估机制选择最优路径。

3.1 ToT的工作原理

ToT的工作原理类似于搜索算法在迷宫中寻找出口:

  1. 初始节点:从问题本身开始,作为树的根节点
  2. 分支生成:在每一步,模型探索多个可能的推理方向,形成分支
  3. 状态评估:对每个分支进行评估,判断其是否可能通向正确答案
  4. 路径选择:保留最有希望的分支,舍弃低效或错误路径
  5. 动态调整:根据评估结果,动态调整下一步的探索方向

例如,在解决24点游戏问题时,ToT会同时探索多种运算组合:

初始状态:9, 8, 6, 3
分支1:9×8=72 → 72, 6, 3
分支2:9+8=17 → 17, 6, 3
分支3:9-8=1 → 1, 6, 3
分支4:8÷6≈1.333 → 9, 1.333, 3

然后对每个分支进行评估,保留最有希望的路径继续探索。这种树状结构的推理方式大大提高了模型处理复杂规划问题的能力。

3.2 ToT的实现方式

ToT的实现需要更复杂的Prompt设计和参数配置:

  • 分支生成:提示模型在每一步生成多个可能的推理方向
  • 评估机制:可以是模型自我评估或独立评估模块
  • 搜索策略:广度优先搜索(BFS)或深度优先搜索(DFS)
  • 剪枝策略:根据评估结果,保留最有前景的分支

以下是ToT的Prompt模板示例,以24点游戏为例:

"你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考:

  1. 从给定的四个数字开始。
  2. 在每一步,选择两个数字,使用加减乘除运算生成新数字。
  3. 将新数字与剩余数字一起作为下一步的输入。
  4. 重复此过程,直到得到24。
  5. 如果无法得到24,请返回最接近的可能结果。

规则:

  • 每步只能使用两个数字进行运算。
  • 运算结果必须是整数。
  • 避免重复使用相同的数字组合。
  • 避免使用已经尝试过且失败的运算路径。

示例:
输入:14, 8, 8, 2
步骤1:14-2=12 → 剩余数字:12, 8, 8
步骤2:12×8=96 → 剩余数字:96, 8
步骤3:96÷8=12 → 剩余数字:12
无法得到24,最接近结果是12。

现在,请解决以下24点问题:
输入:9, 8, 6, 3
"

3.3 ToT的关键参数配置

ToT的实现依赖于多个关键参数的配置:

  • n_generate:每步生成的分支数量(通常3-5)
  • n_evaluate:每步评估的分支数量(通常2-3)
  • nselect:每步保留的最佳分支数量(通常2-3)
  • max_depth:树的最大深度(根据问题复杂度设置)
  • temperature:控制生成多样性(通常0.7)
  • search_strategy:选择BFS或DFS等搜索策略

参数调优策略

  • 对于计算资源有限的情况,建议使用较小的nGenerate(如3)和nSelect(如2)
  • 对于需要深度探索的问题,可适当增加max_depth(如5-6)
  • BFS适合需要全面探索所有选项的问题,DFS适合快速深入到某个潜在解决方案
  • 在评估过程中,可设置forbidden_steps避免重复探索已失败的路径

3.4 ToT的优势与局限

优势

  • 通过多路径探索解决复杂规划问题
  • 允许回溯和动态调整,避免"一错全错"的情况
  • 在需要探索多种可能性的任务中表现优异
  • 在24点游戏等任务中,ToT的成功率可达74%,而CoT仅4%

局限

  • 计算成本极高,需要大量模型调用
  • 实现复杂,需要设计合理的Prompt和参数
  • 对于简单问题,可能过度复杂化推理过程
  • 评估机制的质量直接影响最终结果

在实际应用中,ToT特别适合需要多步决策和路径规划的任务,如游戏策略制定、复杂数学问题求解、多条件约束下的规划问题等。

四、ReAct:推理与行动的协同

ReAct(Reasoning and Action)是一种结合推理与行动的提示技术,它允许模型在推理过程中调用外部工具获取信息或执行特定操作,从而实现更强大的问题解决能力。

4.1 ReAct的工作原理

ReAct的核心是"推理-行动"的迭代循环:

  1. 推理阶段:模型分析当前问题状态,生成推理步骤
  2. 行动阶段:根据推理结果,选择并执行合适的工具或操作
  3. 观察阶段:接收工具执行的结果或观察到的新信息
  4. 更新状态:将新信息整合到当前问题状态中
  5. 重复循环:回到推理阶段,基于更新后的状态继续推理

这种机制类似于人类解决问题时的"思考-行动-观察-再思考"循环,使模型能够动态调整推理路径,处理更复杂的问题。

例如,在解决需要实时数据的问题时,ReAct允许模型调用网络搜索工具:

"思考:要回答特斯拉2023年Q3在华销量及主要竞品,首先需要获取权威销量数据源。
行动:搜索[中国乘联会官网]
观察:找到季度新能源车销量报告,显示特斯拉销量为15万辆。
思考:需识别特斯拉竞品,应考虑同价位区间车型。
行动:检索[30万价位纯电车型]
观察:比对小鹏G9、蔚来ET5等车型销量数据。
思考:整合时间维度数据,分析市场趋势。
行动:调用数据分析模块
观察:显示特斯拉在中国市场占有率约为18%。
思考:最终答案应包含具体销量和主要竞品信息。
行动:无
最终答案:特斯拉2023年Q3在华销量约为15万辆,主要竞争对手包括小鹏G9和蔚来ET5。"

4.2 ReAct的实现方式

ReAct的实现需要定义明确的工具集和交互格式:

  • 工具定义:列出可用的外部工具及其功能
  • 交互格式:规定"Thought/Action/Action Input/Observation"的循环格式
  • 终止条件:定义何时停止循环并输出最终答案
  • 异常处理:处理工具调用失败或无效结果的情况

以下是ReAct的Prompt模板示例:

"你是一个强大的AI助手,可以访问以下工具解决复杂问题:

  • web_search: 用于获取互联网上的实时信息,如新闻、数据和知识
  • python_interpreter: 用于执行Python代码,解决数学计算或数据处理问题
  • image Generation: 用于生成或分析图像内容

请按照以下格式思考和行动

  1. Thought: 分析当前问题,确定下一步需要的信息或操作
  2. Action: 如果需要外部帮助,请选择要使用的工具;如果不需要,请写"无"
  3. Action Input: 如果选择了工具,请提供具体参数;如果不需要,请留空
  4. Observation: 你将获得工具执行的结果
  5. 重复上述步骤,直到问题解决

示例

问题:谁是目前世界上最高的山峰?
Thought: 我需要确认最新的山峰高度数据,包括珠穆朗玛峰和其他可能的候选山峰。
Action: web_search
Action Input: 最新世界最高山峰数据
Observation: 根据搜索结果,珠穆朗玛峰仍被公认为世界最高峰,海拔8848.86米。
Thought: 确认无误,珠穆朗玛峰是最高峰。
Action: 无
Final Answer: 珠穆朗玛峰,海拔8848.86米。

现在,请解决以下问题:
问题:请计算从上海到北京的高铁票价,并比较不同班次的舒适度。

"

4.3 ReAct的关键参数配置

ReAct的实现需要合理配置以下参数:

  • 工具列表:根据任务需求定义可用工具
  • 最大步骤:设置max_steps(通常5-10),防止无限循环
  • 温度参数:控制推理阶段的创造性(通常0.5-0.7)
  • 置信度阈值:定义模型对答案的置信度要求
  • 工具优先级:设置工具调用的优先级和权重

最佳实践

  • 明确定义工具的功能和使用限制
  • 提供清晰的示例引导模型正确使用工具
  • 考虑工具调用的开销,优先选择轻量级工具
  • 在推理阶段强调对工具输出的分析和整合

4.4 ReAct的优势与局限

优势

  • 结合推理与外部行动,解决需要实时信息的问题
  • 通过迭代循环,处理复杂的多步骤任务
  • 显著减少"幻觉"问题,提高答案的准确性
  • 在需要专业工具的任务中表现优异,如编程、数据分析等

局限

  • 实现复杂,需要设计工具接口和交互流程
  • 计算开销大,每次工具调用都需要额外处理
  • 工具选择可能引入新的错误或偏见
  • 需要模型具备良好的工具调用能力

根据研究,ReAct在需要工具支持的任务中,比单纯使用CoT或SC的准确率平均高出12-30%,证明了其在复杂问题解决中的潜力。

五、四种技术的对比与选择策略

四种推理增强技术各有特点,适用于不同场景。下表对它们进行了全面比较:

技术复杂度计算成本可解释性适用场景准确率提升
CoT简单数学、逻辑推理、常识问答中等(约15-20%)
SC中等中等中等复杂数学、多解问题、需要高稳定性的任务较高(约17-25%)
ToT复杂规划、多路径依赖、需要探索多种可能性的任务最高(可达70%+)
ReAct中高中高中等需要工具支持、实时信息、多步骤交互的任务较高(约12-30%)

选择策略

  1. 简单推理任务:优先选择CoT,因其实现简单且能提供清晰的推理过程

    • 适用场景:基础数学题、逻辑判断、常识问答
    • 示例:计算简单算术题、判断简单逻辑关系
  2. 需要高稳定性的任务:选择SC,通过多路径采样和投票提高结果可靠性

    • 适用场景:重要决策支持、学术论文验证、医疗诊断参考
    • 示例:数学考试题目解答、法律条款解释、医疗诊断参考
  3. 复杂规划任务:选择ToT,通过多路径探索和动态评估解决复杂问题

    • 适用场景:游戏策略制定、多条件约束规划、创意写作构思
    • 示例:24点游戏解法、商业策略制定、多结局故事创作
  4. 需要外部信息的任务:选择ReAct,结合推理与工具调用处理复杂现实问题

    • 适用场景:实时数据分析、事实核查、跨领域知识整合
    • 示例:市场趋势分析、历史事件验证、多源信息综合回答

技术融合策略

在实际应用中,可以考虑技术融合以获取最佳效果:

  • CoT+SC:先使用CoT生成高质量推理路径,再用SC进行多路径采样和投票
  • ToT+SC:结合ToT的多路径探索和SC的投票机制,提高复杂规划任务的可靠性
  • ReAct+CoT:在ReAct的行动阶段使用CoT引导模型生成更合理的工具调用指令
  • ReAct+SC:在ReAct的推理阶段应用SC,提高工具选择决策的稳健性

技术选择的关键因素

  1. 任务复杂度:简单任务用CoT,中等复杂度用SC或ReAct,高度复杂任务用ToT
  2. 计算资源:受限资源下优先选择CoT或SC,充足资源下考虑ToT或ReAct
  3. 推理透明度需求:需要解释推理过程时选择CoT或ToT,仅关注结果时选择SC
  4. 实时信息需求:需要访问外部信息或工具时选择ReAct
  5. 多路径探索需求:需要探索多种可能解决方案时选择ToT或SC

六、数学问题中的推理增强技术应用

数学问题是最能体现推理增强技术优势的应用场景之一。下面通过具体案例展示四种技术在数学问题中的应用。

6.1 CoT在数学问题中的应用

CoT通过引导模型分步推理,显著提升数学问题的解决能力。下面是一个使用CoT解决代数问题的案例:

问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?

CoT Prompt:

"请解决以下代数问题,使用逐步推理过程。
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
提示:鸡有1个头和2条腿,牛有1个头和4条腿。
让我们一步步思考:
"

模型输出:

"首先,设鸡的数量为x,牛的数量为y。
根据头的数量,我们有x + y = 35。
根据腿的数量,我们有2x + 4y = 94。
我们可以从第一个方程解出x = 35 - y。
将x代入第二个方程:2(35 - y) + 4y = 94 → 70 - 2y + 4y = 94 → 70 + 2y = 94 → 2y = 24 → y = 12。
因此,牛的数量是12头,鸡的数量是35 - 12 = 23只。
所以,农场里有23只鸡和12头牛。"

CoT在数学问题中的优势在于能够清晰展示每一步的推导过程,便于验证和理解

6.2 SC在数学问题中的应用

SC通过多路径采样和投票机制,提高数学问题答案的可靠性。下面是一个使用SC解决概率问题的案例:

问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少?

SC Prompt:

"请解决以下概率问题,生成5个不同的推理路径,然后选择最常见的正确答案。
问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"

模型输出:

推理路径1:

  1. 30%的Huhulians拥有至少一台电视。
  2. 这些拥有电视的人中24%拥有至少四台。
  3. 因此,拥有至少四台电视的比例是30% × 24% = 7.2%。
    答案:7.2%

推理路径2:

  1. 总人口中拥有至少一台电视的比例是30%。
  2. 这些人中拥有至少四台电视的比例是24%。
  3. 因此,拥有至少四台电视的总比例是0.3 × 0.24 = 0.072 = 7.2%。
    答案:7.2%

推理路径3:

  1. 30%的人口拥有至少一台电视。
  2. 其中24%拥有至少四台,因此需要计算这两个百分比的乘积。
  3. 30% × 24% = 7.2%。
    答案:7.2%

推理路径4:

  1. 30%拥有至少一台电视。
  2. 这些人中有24%拥有至少四台。
  3. 因此,拥有至少四台的比例是0.3 × 0.24 = 0.072 = 7.2%。
    答案:7.2%

推理路径5:

  1. 错误路径:假设24%是相对于总人口的比例,而不是电视拥有者。
  2. 直接计算30% + 24% = 54%,显然不合理。
    答案:54%

最终答案:7.2%

SC通过生成多个推理路径并投票选择,有效过滤了推理过程中的错误,提高了最终答案的可靠性

6.3 ToT在数学问题中的应用

ToT特别适合需要多路径探索的数学问题,如24点游戏或复杂方程求解。下面是一个使用ToT解决24点游戏的案例:

问题:使用数字9, 8, 6, 3通过加减乘除运算得到24。

ToT Prompt:

"你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考:

  1. 从给定的四个数字开始。
  2. 在每一步,选择两个数字,使用加减乘除运算生成新数字。
  3. 将新数字与剩余数字一起作为下一步的输入。
  4. 重复此过程,直到得到24。
  5. 如果无法得到24,请返回最接近的可能结果。

规则:

  • 每步只能使用两个数字进行运算。
  • 运算结果必须是整数。
  • 避免重复使用相同的数字组合。
  • 避免使用已经尝试过且失败的运算路径。

输入:9, 8, 6, 3
"

模型输出:

初始状态:9, 8, 6, 3

分支1:9 × 8 = 72 → 剩余:72, 6, 3
分支2:9 + 8 = 17 → 剩余:17, 6, 3
分支3:9 - 8 = 1 → 剩余:1, 6, 3
分支4:8 ÷ 6 ≈ 1.333 → 剩余:9, 1.333, 3

评估分支:

  • 分支1:72, 6, 3 → 可能路径:72 ÷ 6 = 12 → 12 × 3 = 36
  • 分支2:17, 6, 3 → 可能路径:17 - 6 = 11 → 11 × 3 = 33
  • 分支3:1, 6, 3 → 可能路径:6 × 3 = 18 → 18 ÷ 1 = 18
  • 分支4:9, 1.333, 3 → 可能路径:9 - 1.333 ≈ 7.667 → 7.667 × 3 ≈ 23.001

选择最有希望的分支3和分支4继续探索。

分支3-1:6 × 3 = 18 → 剩余:1, 18
分支3-2:9 - 6 = 3 → 剩余:3, 8, 3
分支4-1:9 - 1.333 ≈ 7.667 → 剩余:7.667, 3
分支4-2:1.333 × 3 ≈ 4 → 剩余:9, 4

评估分支:

  • 分支3-1:1, 18 → 18 ÷ 1 = 18
  • 分支3-2:3, 8, 3 → 3 × 8 = 24 → 成功!
  • 分支4-1:7.667, 3 → 7.667 × 3 ≈ 23.001
  • 分支4-2:9, 4 → 9 - 4 = 5

在分支3-2中,模型成功找到了解法:3 × 8 = 24,从而解决了问题。这种树状结构的探索方式使模型能够系统地尝试各种可能性,大大提高了复杂数学问题的解决率。

6.4 ReAct在数学问题中的应用

ReAct通过结合推理与工具调用,可以解决需要精确计算或外部数据的数学问题。下面是一个使用ReAct解决复杂数学问题的案例:

问题:计算从1到500的所有数字键入所需的总按键次数。

ReAct Prompt:

"你是一个强大的数学问题解决者,可以使用Python解释器执行代码进行精确计算。请按照以下格式思考和行动:

  1. Thought: 分析问题,确定需要哪些信息或计算
  2. Action: 如果需要计算,请选择python_interpreter;如果不需要,请写
  3. Action Input: 提供要执行的Python代码
  4. Observation: 你将获得代码执行的结果
  5. 重复上述步骤,直到问题解决

问题:计算从1到500的所有数字键入所需的总按键次数。
"

模型输出:

Thought: 首先需要确定1到500之间各个数字的位数。一位数(1-9)需要1次按键,两位数(10-99)需要2次,三位数(100-500)需要3次。
Action: python_interpreter
Action Input:

# 计算1-9的数字数量
one_digit = 9
# 计算10-99的数字数量
two_digit = 90
# 计算100-500的数字数量
three_digit = 500 - 99
# 计算总按键次数
total = one_digit * 1 + two_digit * 2 + three_digit * 3
print(total)

Observation: 代码执行结果为1392。
Thought: 验证计算是否正确。1-9有9个数字,每个1位,共9×1=9次。
10-99有90个数字,每个2位,共90×2=180次。
100-500有401个数字,每个3位,共401×3=1203次。
总和为9+180+1203=1392次,计算正确。
Action: 无
Final Answer: 1392次。

ReAct的优势在于能够处理需要精确计算或外部数据的数学问题,通过工具调用确保计算的准确性

七、创意写作中的推理增强技术应用

创意写作是另一种能够受益于推理增强技术的领域,特别是在需要逻辑连贯或多路径探索的创作中。以下是四种技术在创意写作中的应用案例。

7.1 CoT在创意写作中的应用

CoT可以引导模型在创意写作中进行分步思考,确保故事的逻辑连贯性。下面是一个使用CoT进行故事续写的案例:

问题:请续写以下故事:"小明推开那扇古老的大门,里面是一个他从未见过的神秘世界..."

CoT Prompt:

"请续写以下故事,使用逐步推理确保逻辑连贯和情节合理。
初始故事:小明推开那扇古老的大门,里面是一个他从未见过的神秘世界...
提示:请先思考可能的发展方向,然后选择最合适的一个进行续写。
让我们一步步思考:

  1. 分析初始情节的关键元素:古老大门、神秘世界、主角小明。
  2. 考虑可能的续写方向:魔法冒险、时间旅行、平行宇宙等。
  3. 评估每个方向的可行性:是否与初始情节一致?是否有足够的发展空间?
  4. 选择最合适的方向并构建后续情节。
  5. 确保人物动机和情节发展合理。

"

模型输出:

  1. 分析关键元素:古老大门暗示魔法或神秘力量,神秘世界为故事提供了丰富的可能性,主角小明需要有明确的动机和目标。
  2. 可能方向:
    a. 魔法冒险:小明进入魔法世界,学习魔法,解决难题。
    b. 时间旅行:小明穿越到过去或未来,改变历史或探索未来。
    c. 平行宇宙:小明进入另一个平行世界,遇到另一个自己,探索两个世界的联系。
  3. 评估方向:
    a. 魔法冒险:与初始情节高度一致,有丰富的探索空间。
    b. 时间旅行:需要解决时间悖论,可能增加复杂性。
    c. 平行宇宙:需要解释两个世界的联系,可能分散故事焦点。
  4. 选择魔法冒险方向,构建以下情节:
    小明进入魔法世界后,发现了一个正在被黑暗力量威胁的王国。
    他遇到了一位年迈的巫师,巫师告诉他小明是预言中的救世主。
    小明开始学习魔法,最终在一场大战中击败了黑暗领主,拯救了王国。
  5. 确保动机合理:小明好奇并勇敢,这是他探索神秘世界的动力。
    情节发展合理:从发现世界到学习魔法,再到最终战斗,形成一个完整的故事弧线。

续写故事:
小明推开那扇古老的大门,里面是一个他从未见过的神秘世界。他发现自己站在一个巨大的魔法图书馆前,书架高达天际,书籍闪烁着奇异的光芒。

一位年迈的巫师从阴影中走出,他对小明说:"年轻的冒险者,你终于来了。我是守护者,预言中说你会带来光明。"

小明询问发生了什么事,巫师叹息道:"黑暗领主已经占领了我们的王国,只有预言中的救世主才能击败他。而你,就是那个人。"

巫师带领小明进入图书馆深处,教他使用魔法书中的力量。经过数月的学习,小明掌握了强大的魔法技能。

一天,黑暗领主的军队逼近图书馆。小明知道是时候面对挑战了。他拿起最强大的魔法书,与巫师一起前往战场。

经过一场激烈的战斗,小明召唤出强大的光明魔法,彻底击败了黑暗领主。王国重获自由,小明成为了传奇英雄。

CoT在创意写作中的优势在于能够确保故事发展的逻辑性和连贯性,避免情节漏洞

7.2 SC在创意写作中的应用

SC可以生成多个故事版本,通过投票选择最受欢迎的结局,提高创作的多样性。下面是一个使用SC进行故事结局创作的案例:

问题:请为以下故事创作三个不同的结局,然后选择最合理的一个。
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。

SC Prompt:

"请为以下故事创作三个不同的结局,然后选择最常见的合理结局。
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。
请按照以下格式输出:
结局1:
[结局描述...]
结局2:
[结局描述...]
结局3:
[结局描述...]
最终结局:
[最常见的合理结局...]
"

模型输出:

结局1:
小明选择了财富。魔法生物消失了,小明回到家中,发现口袋里装满了金币。他成为了富翁,但不久后感到空虚,意识到知识才是真正的财富。他将大部分金币捐给学校,自己则专注于学习。

结局2:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,但他无法处理如此庞大的信息。他逐渐迷失在知识的海洋中,忘记了财富的重要性,最终因无法适应现实世界而孤独终老。

结局3:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。

最终结局:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。

在三个结局中,结局3出现了两次,因此被选为最终答案。这个结局既符合小明选择知识的决定,又避免了其他结局的极端结果,更加合理和积极。

7.3 ToT在创意写作中的应用

ToT在创意写作中特别适合需要多路径探索的任务,如多结局故事创作或复杂情节规划。下面是一个使用ToT创作多结局故事的案例:

问题:请为以下故事创建一个思维树,探索不同选择带来的各种结局。
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。

ToT Prompt:

"请为以下故事创建一个思维树,探索不同选择带来的各种结局。
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。
规则:

  • 每个决策点生成2-3个可能的分支。
  • 对每个分支进行评估,判断其是否可能导向有意义的结局。
  • 如果分支明显没有意义,请停止探索该路径。
  • 保留最有希望的分支继续探索。

"

模型输出:

初始状态:小明站在十字路口,面临三个选择:财富、知识、冒险。

分支1:选择财富
分支1-1:财富之路充满陷阱,小明被骗,一无所有。
分支1-2:财富之路顺利,小明成为富翁,但感到空虚。
分支1-3:财富之路需要付出代价,小明失去健康换取财富。

评估分支1:

  • 分支1-1:无意义结局,停止探索。
  • 分支1-2:合理结局,保留。
  • 分支1-3:合理结局,保留。

分支2:选择知识
分支2-1:知识之路艰难,小明成为学者,改变世界。
分支2-2:知识之路充满诱惑,小明迷失在知识中。
分支2-3:知识之路需要实践,小明结合知识和行动,取得平衡。

评估分支2:

  • 分支2-1:合理结局,保留。
  • 分支2-2:合理结局,保留。
  • 分支2-3:最佳结局,保留。

分支3:选择冒险
分支3-1:冒险之路充满危险,小明获得成长但失去家人。
分支3-2:冒险之路充满奇遇,小明发现新世界并带回知识。
分支3-3:冒险之路需要智慧,小明利用知识解决冒险中的问题。

评估分支3:

  • 分支3-1:合理结局,保留。
  • 分支3-2:最佳结局,保留。
  • 分支3-3:合理结局,保留。

现在,请从每个主要分支中选择最有希望的结局进行详细描述:

财富之路:小明成为富翁,但感到空虚,后来通过慈善找到人生意义。
知识之路:小明结合知识和行动,利用知识解决实际问题,取得平衡。
冒险之路:小明在冒险中发现新世界,带回宝贵知识,丰富了自己的人生。

最终故事
小明站在十字路口,面临三个选择:财富、知识或冒险。他深思熟虑后,决定选择知识之路。

知识之路充满挑战,小明需要不断学习和克服困难。经过几年的艰辛努力,他成为了一位杰出的学者,掌握了丰富的知识。

然而,小明意识到,仅仅拥有知识是不够的。他开始将所学应用于实践,帮助社区解决实际问题。通过这种方式,他不仅实现了个人价值,也为社会做出了贡献。

小明的朋友们感到惊讶,因为他没有选择财富之路或冒险之路。但他们看到小明过着充实而有意义的生活,纷纷向他学习。

ToT在创意写作中的优势在于能够系统地探索多种可能性,避免创作中的思维局限

7.4 ReAct在创意写作中的应用

ReAct可以增强创意写作的真实性,通过调用外部工具验证故事中的事实和细节。下面是一个使用ReAct创作历史小说的案例:

问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。

ReAct Prompt:

"你是一个历史小说作家,可以使用以下工具确保故事中的历史事实准确:

  • web_search: 搜索互联网获取历史事实和数据
  • fact_check: 验证特定历史事件或人物的准确性

请按照以下格式思考和行动:

  1. Thought: 分析故事需求,确定需要验证的关键历史事实
  2. Action: 如果需要验证事实,请选择相应工具;如果不需要,请写
  3. Action Input: 提供要验证的具体事实或问题
  4. Observation: 你将获得工具执行的结果
  5. 重复上述步骤,直到故事创作完成

问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。
"

模型输出:

Thought: 首先需要确认郑和下西洋的基本事实,如时间、目的、船队组成等。
Action: web_search
Action Input: 郑和下西洋的基本事实

Observation: 郑和下西洋是明朝初年(1405-1433)由郑和领导的七次大规模海上远航。主要目的是宣扬国威、发展朝贡贸易、寻找建文帝等。船队由数百艘船组成,最远到达东非和红海沿岸。

Thought: 确认了基本事实,现在需要确定故事的核心情节。可以考虑郑和与当地统治者会面的场景。
Action: web_search
Action Input: 郑和与古里国王会面的详细历史记录

Observation: 根据历史记载,1411年,郑和船队到达古里(今印度卡利卡特)。郑和与古里国王进行了友好会面,赠送了明朝的礼物,签署了贸易条约,并在古里建立了中国商馆。

Thought: 这个历史事件非常适合作为核心情节。现在需要构建一个故事场景,描述郑和与古里国王的会面。
Action: fact_check
Action Input: 郑和船队到达古里的年份是否为1411年

Observation: 确认正确,郑和第三次下西洋于1411年到达古里。

Thought: 现在可以开始创作故事了。将描述郑和与古里国王会面的场景,包括会面的细节、礼物的种类、签署的条约内容以及建立的中国商馆。
Action: 无
Final Answer:
《远航的使命》

1411年的一个清晨,郑和率领的庞大船队缓缓驶入古里的港口。海面上阳光明媚,船队悬挂着鲜艳的旗帜,展现出大明帝国的威严。

古里国王早已在港口等候,他好奇地注视着这些来自遥远东方的船只。当郑和踏上古里土地时,国王亲自迎接,热情地说:"久闻大明帝国的威名,今日得见郑大人,实乃我国之幸。"

郑和微微一笑,递上明朝皇帝的信件和丰厚的礼物:丝绸、瓷器、香料和精美的工艺品。国王接过礼物,眼中闪烁着喜悦。

随后,郑和与国王进行了深入交谈,讨论了两国贸易的可能性。经过数日的商议,两国签署了贸易条约,古里承诺向明朝进贡,并给予明朝商人优惠政策。

作为友好往来的象征,明朝在古里建立了中国商馆,为往来贸易提供便利。郑和在古里受到了热烈欢迎,他的这次访问大大促进了两国之间的友好关系。

国王对郑和说:"郑大人,你的到来为我国带来了繁荣与友谊,我将永远铭记于心。"

郑和微微一笑,回应道:"这是明朝皇帝的旨意,我们希望与各国建立和平友好的关系。"

这次会面成为两国历史上重要的一页,也为后来的贸易往来奠定了坚实基础。

ReAct在创意写作中的优势在于能够确保故事中的历史事实准确无误,提高创作的真实性和可信度

八、技术实现与最佳实践

要有效地应用这些推理增强技术,需要掌握一些关键的实现技巧和最佳实践。

8.1 CoT的最佳实践

对于CoT,关键在于设计引导性语句和示例,鼓励模型展示清晰的推理过程

  1. 明确的引导语句:使用"Let's think step by step"或"让我们一步步思考"等明确指令
  2. 适当的示例:提供与目标问题相似的示例,展示期望的推理格式
  3. 控制温度参数:设置较低的温度值(0.3-0.5),确保推理过程的连贯性和准确性
  4. 结构化输出:要求模型按照"推理步骤→答案"的格式输出,便于验证
  5. 逐步细化:对于非常复杂的问题,可以先使用CoT生成整体思路,再进一步细化

8.2 SC的最佳实践

对于SC,关键在于平衡采样多样性与计算成本,以及选择合适的投票机制

  1. 合理的样本数量:一般设置3-5个样本,平衡准确率与计算成本
  2. 适当的温度设置:设置较高的温度值(0.7-0.9),增加推理路径的多样性
  3. 加权投票机制:根据模型的置信度或推理路径的长度对答案进行加权投票,提高投票质量
  4. 错误过滤:在投票前,可以设置基本的合理性检查,过滤明显错误的答案
  5. 结果分析:不仅关注最终答案,也可以分析多个推理路径中的共同点和差异,作为答案可靠性的参考

8.3 ToT的最佳实践

对于ToT,关键在于设计合理的分支生成和评估策略,以及控制计算成本

  1. 分支生成控制:设置每步生成的分支数量(通常3-5),避免指数级增长
  2. 评估机制设计:设计有效的评估标准,可以是模型自评或外部评估
  3. 搜索策略选择:根据问题特性选择BFS(全面探索)或DFS(深度探索)等策略
  4. 剪枝策略:定期评估并剪枝低效或不合理的路径,控制计算成本
  5. 深度限制:设置最大探索深度(通常5-6),防止无限探索
  6. 回溯机制:当当前路径明显无法解决问题时,允许回溯到之前的决策点,尝试其他路径

8.4 ReAct的最佳实践

对于ReAct,关键在于设计清晰的工具接口和交互流程,以及处理工具调用的异常情况

  1. 工具定义明确:清晰描述每个工具的功能、输入格式和输出格式
  2. 交互格式规范:严格定义"Thought/Action/Action Input/Observation"的循环格式
  3. 工具调用示例:提供工具调用的示例,帮助模型学习如何正确使用工具
  4. 最大步骤限制:设置合理的max_steps(通常5-10),防止无限循环
  5. 异常处理机制:设计工具调用失败时的回退策略,如重试或切换工具
  6. 工具选择引导:在Prompt中明确哪些情况下应使用哪些工具,提高工具使用效率

九、总结与未来展望

推理增强提示技术代表了大语言模型应用的重要发展方向,通过精心设计的Prompt,可以显著提升模型在复杂推理任务中的表现。本文介绍了四种前沿的推理增强技术:思维链(CoT)、自一致性(SC)、思维树(ToT)和ReAct,并通过数学问题和创意写作等场景展示了它们的应用。

每种技术都有其独特的优势和适用场景

  • CoT:简单易用,适合需要清晰推理过程的任务
  • SC:提高稳定性,适合对答案可靠性要求高的任务
  • ToT:探索多样性,适合需要多路径规划的复杂任务
  • ReAct:结合行动,适合需要外部信息或工具支持的现实任务

未来,推理增强技术将继续发展,可能在以下几个方向取得突破

  1. 自动化程度提升:更少的手动Prompt设计,更多自动化的推理增强机制
  2. 多技术融合:CoT、SC、ToT和ReAct的深度融合,形成更强大的推理框架
  3. 领域特化:针对特定领域(如医学、法律)的推理增强技术优化
  4. 实时交互增强:结合用户反馈的动态推理增强机制
  5. 评估标准完善:更完善的推理过程和结果评估体系

随着这些技术的不断完善和普及,我们将能够构建更加智能、可靠和实用的AI应用,使大语言模型真正成为人类思维的有力辅助。

同事 A 为公司合伙人(技术强、经验丰富),remote 在城市 B 办公,跟行业内竞争对手公司的销售私下做了无数的私活儿(实体行业,需要出差去支持,在我司的打卡记录正常)

近两年开始当商业间谍帮竞争对手翘公司的大单(项目都是几千万量级,公司跟进大半年,后续会变为他的私活儿)

25 年初公司丢了一单这种性质的,因此公司为了降低他的影响,边缘化一年吧(工资依旧很高)

当下也有一单面临相同的情况,且电话里跟销售同事全都摊牌了,信息是他透露给竞争对手公司(竞争对手直接跟客户讲 A 马上去他们那边入职, 支持都是 A 支持。A 也参加这个项目我们这边的售前工作, 竞争公司没这方面技术猜测售前也是 A 支持)

同事 A 目前已经提出辞职,且说销售同事恐吓他(公司内部一个团队整整跟了半年吧,多少当时有些生气的),直接去翘单公司跟人合伙
OP 同为合伙人,实在忍不了,他个人出行记录 100%有多次肯定跟实际 remote 的地址不一致的,因为工作时基本上都联不上他,有时候手机直接工作时间关机(推测坐飞机)

想听听大佬们的建议!!!

跨境支付、SaaS、出海电商、金融/加密业务的团队都会遇到用户IP是否来自制裁地区的问题,如果判断失误,损失一定的订单事小,出现合规事故后,解决合规事故的精力、损失的时机才是最难以挽回的东西。

其实这个问题很多相关业务的团队都会注意到,将有关制裁国家的IP封禁,但后来还是会出现合规问题。为什么?

其实这个问题源自于,合规问题并不是一个国家维度的问题,举个“栗子”:
A国家中有①②③个城市,B国家有④⑤⑥个城市,当业务侧处理A、B国家的合规问题时,不是“IP解析 → A/C国家 ≠/= 制裁国 → 放行/拦截”就可以的,因为常常会出现以下情况
1)、A国家不制裁相关产品,但是③城市制止
2)、B国家个人放行,但加密、金融、云服务相关合规

所以单单是指判断国家相关,一定是不够的,所以基本做法应该是:

1、第一层:IP→国家/地区(基础过滤)
国家(Country)→一级行政区(Region/Province/State)→城市(City)

逻辑应该是-IP是否落在被明确制裁的地理区域内
Country=A
Region=③
→命中制裁

这一步依赖的是IP地理定位数据的精细度,是否能做到“地区级别”,导入IP数据云IP地址查询定位库,足够用了。

2、第二层:反规避判断(非常容易被忽略)
制裁地区用户不会老老实实用本地IP,常见规避方式包括:
V口N/Proxy、云厂商出口IP、Tor/匿口名网络、卫星网络

所以可以导入IP数据云的风险画像系统:
1)、IP是否为代口理/V口N/IDC/云IP
2)、IP ASN 是否异常
典型策略是:
制裁业务=地理命中+风险IP命中 → 拒绝或人工审核
跨境业务使用IP数据云IP地址查询定位库判断用户IP是否来自制裁地区?.png

!注意项

1)、只用免费IP查询接口
免费库:
地区精度不足(只到国家)
制裁地区更新滞后(版本落后)
免费≠可合规使用(有一些国家需要查看合规IP信息的来源,作为合规证明)

2)、规则写死在代码里
制裁名单是动态变化的(信息更替不及时,触发合规制裁):
地区新增
限制升级
规则一定要可配置、可更新

最近看到了很多关于 Antigravity 写 commit 很难的评论

我有一个比较成熟的方案,这个方案写的又快又准

大家可以参考一下

1. 下载一个通义灵码的插件

2. 关闭通义灵码的其他功能,只保留代码 commit 生成

3. 使用通义灵码 commit 生成后提交

在AI计算和大模型训练需求快速增长的当下,成都作为西部算力枢纽的重要性日益凸显。越来越多的企业选择在成都托管GPU服务器,既享受西部地区的成本优势,又能获得专业的数据中心服务。那么成都的GPU服务器托管到底能带来哪些实际价值?

成都GPU托管的独特优势

网络质量是首要考量。成都作为国家级互联网骨干节点,拥有直达东部的低延迟链路。极云科技在成都的机房采用BGP多线接入,到重庆、西安等西部城市的延迟控制在5ms以内,到上海、北京等地也保持在30ms左右,为分布式计算和实时推理提供了稳定保障。

电力保障同样关键。GPU服务器功率密度高,8卡A100/H800集群峰值功耗可达6-7kW。极云科技的成都机房配备2N冗余供电系统,智能PDU支持每端口电流监控,确保高功率设备稳定运行。我们还为GPU集群设计了独立的电力回路,避免不同设备间相互干扰。

专业运维团队不可或缺。GPU服务器的运维比普通服务器复杂得多,从驱动版本兼容到多卡通信优化都需要专业知识。极云科技的工程师团队熟悉各类AI框架和GPU应用场景,提供从硬件监控到性能调优的全方位服务,确保客户的训练任务高效完成。

典型应用场景

AI模型训练与推理:成都相对较低的综合成本使其成为模型训练的理想选择,极云科技为客户提供从单机8卡到多机集群的不同配置。

影视渲染与数字内容制作:借助GPU强大的并行计算能力,渲染任务完成时间可缩短60%以上。

科学计算与仿真模拟:在生物医药、气象预报等领域,GPU加速能显著提升计算效率。

选择托管服务的关键点

首先要评估机房的真实能力:不仅仅是看Tier等级,更要了解实际电力密度、散热方案和网络架构。极云科技的成都机房支持单机柜15kW功率密度,采用冷热通道隔离和精准送风设计。

其次要测试网络性能:特别是跨区域访问质量。我们提供测试机服务,客户可以在部署前实际验证到目标用户群的网络表现。

还要关注增值服务:比如是否支持混合云架构、是否有容灾方案。极云科技为客户提供与公有云打通的专线连接,构建灵活的混合算力架构。

总的来说,成都GPU服务器托管正在成为西部地区的优选方案。它既保留了本地部署的数据控制权,又提供了专业数据中心的设施保障。

如果您正在规划GPU算力部署,欢迎了解极云科技成都机房的GPU托管服务。我们提供从咨询规划、部署实施到持续运维的全流程支持,帮助您的AI业务在西部稳健落地、高效运行。

我们很高兴地宣布 Rspress 2.0 的正式发布!

Rspress 是基于 Rsbuild 的静态站点生成器,专为开发者打造的文档站工具。自 2023 年正式发布以来,Rspress 1.x 累计迭代 144 个版本,共有 125 位贡献者 参与项目开发。越来越多的开发者选择 Rspress,借助其高效的编译性能、约定式路由和组件库预览等功能,构建了可靠的文档站点。

根据社区的反馈和建议,Rspress 2.0 在 主题美观度人工智能原生文档开发体验与 Rslib 一起使用 等方面进行了更深入的研究。

为什么是 Rspress 2.0

Rspress 1.x 已经解决了文档站框架编译性能的问题,但仍然存在一些问题影响着作为文档开发工具的核心体验。2.0 版本将不仅仅针对编译性能的追求,也侧重于文档站体验的其他方面:

  • 主题风格:一套更美观的默认主题,并提供了多种自定义主题方式,解决了 1.x 在主题定制上缺乏稳定 API 的问题;

  • AI-native:文档不仅服务于人类读者,也需要被 Agent 更好地理解和使用。Rspress 现在内置了 llms.txt 生成并从 SSG 衍生出的 SSG-MD 功能,生成高质量的 Markdown 渲染内容供 Agent 读取;

  • 双击编译,瞬间启动:默认启用 lazyCompilation,配合链接悬停时对资源的预加载功能,仅在访问特定路由时构建所需文件,无论实现项目规模大小,dev 也可瞬间启动

  • Shiki 代码高亮:默认集成 Shiki,在构建时完成语法高亮,支持主题切换、变压器扩展,比如 @rspress/plugin-twoslash,带来更丰富的代码块展示效果;

  • 文档开发体验:优化 _nav.json_meta.json 文件的 HMR 等并新增 json schema 用于 IDE 内的代码提示;默认开启死链检查功能;新增文件代码块语法,支持外部引用文件;@rspress/plugin-preview 和 @rspress/plugin-playground 支持同时使用等;

  • Rslib 集成:现在可以在使用 create-rslib 创建组件库项目时,选择 Rspress 作为文档工具,快速构建组件库项目站点。

这是一次对现有架构的全面升级,下面将介绍 Rspress 2.0 及其 全新主题、高质量 llms.txt 生成、集成 Shiki、后续编译等重要功能。

图片

2.0 新特性

全新主题

2.0 默认主题令人期待的一次系统性升级,它由团队设计师 @Zovn Wei 整体设计,在视觉效果和阅读体验上都有较轻的提升,并且每个组件需要独立替换,拥有非常多的可定制性。

图片

主题定制

按照定制化程度从低到高,有 CSS 变量、BEM 类名、ESM 重导出覆盖、组件弹出四种自定义主题[11]方式。

  • CSS 指标:新主题涉及了更多 CSS 指标,覆盖主题颜色、代码块、首页等样式。您可以在 CSS 指标[12] 页面进行预览并调整所有 CSS 指标,找到满意的配置后直接复制到项目中使用。

:root {  /* 自定义主题色 */  --rp-c-brand: #3451b2;  --rp-c-brand-dark: #2e4599;  /* 自定义代码块样式 */  --rp-code-block-bg: #1e1e1e;}
复制代码

  • BEM 类名:内置组件现在均采用 BEM 命名规范。这是十分之一 Old School 的选择,但也是我们深思熟虑的决定。用户可以通过 CSS 选择器精准调整样式,HTML 结构更加清晰;同时与 Rspress 用户自身使用的 CSS 框架解耦合,用户可以任意选择 CSS 框架(Tailwind [14]、Less [15]、Sass [16] 等),比如使用 Tailwind V4 或 V3 而不用担心版本,也不用担心与 Rspress 内置 CSS 产生冲突。

/* BEM 命名规范 */.rp-[component-name]__[element-name]--[modifier-name] {}/* 根据 BEM 类名轻松覆盖组件样式 */.rp-nav__title {  height: 32px;}.rp-nav-menu__item--active {  color: purple;}
复制代码

  • ESM 重导出覆盖:如果 CSS 上的修改无法满足定制需求,可以通过 JS 进行更深度的定制。在 theme/index.tsx 中使用 ESM 重导出[17],可以覆盖任意一个 Rspress 的内置组件。

图片

  • 修改组件弹出:你可以使用全新的 `rspress pop [组件]` 命令,这个命令将指定的组件源代码复制到 theme/components/ 目录下,你可以自由这些代码,甚至直接替换 AI,来实现深度定制。

# 将 DocFooter 组件导出到 theme 目录rspress eject DocFooter
复制代码

导航栏、侧边栏标签

Rspress 2.0 实现了 Tag 组件[19],现在可以使用 frontmatter 中的标签属性,在侧边栏或导航栏进行 UI 标注。

---tag: new, experimental # 会在 H1 和 Sidebar 进行显示---import { Tag } from '@rspress/core/theme';# Tag## Common tags <Tag tag="new" /> {/* 会在右侧 outline 进行显示 */}
复制代码

图片

内置多语言支持

在 1.x 版本中,Rspress 仅内置了中文,如果使用其他语言如 zh,必须对所有的文本都进行配置,使用起来更繁琐。现在 2.0 主题内置了 zh、en、ja、ko、ru 等多种语言的翻译文本,系统会根据语言配置自动进行“Tree Shaking”,仅限你使用到的文本及语言,未内置的语言会兜底到 en 文本。您也可以通过 `i18nSource` 配置项扩展或覆盖翻译文本。

Rspress 未来会支持更多内置语言,如果你有兴趣,请参考 这位贡献者的 Pull Request [21]

llms.txt 支持

Rspress 现在将 llms.txt [22] 生成能力集成到 core 中,并实现了全新的 SSG-MD(Static Site Generation to Markdown,静态站点 Markdown 生成)能力。

在基于 React 动态渲染的前端框架中,往往存在静态信息无法提取的问题,Rspress 也面临同样的挑战。Rspress 用户通过 MDX 片段[23]、React 组件、Hooks 以及 TSX 路由等动态特性来增强表现力。但这些动态转换在 Markdown 文本内容时会面临以下问题:

  • 直接将 MDX 输入给 AI 会包含大量代码噪音,并丢失 React 组件内容;

  • 将 HTML 转为 Markdown 往往效果不佳,信息质量难以保证。

为了解决这个问题,Rspress 2.0 引入了 SSG-MD [24] 特性。这是一个全新的功能,它类似于 静态站点生成(SSG)[25],但不同的地方相当于你的页面渲染为 Markdown,而不是文件 HTML 文件,并生成 llms.txt [26] 及 llms-full.txt 相关文件。

图片

相比于将 HTML 转化为 Markdown 等传统方式,SSG-MD 在渲染期间拥有更优质的信息源,比如 React 虚拟 DOM,从而保证更高的静态信息质量和灵活性。

图片

启用方式非常简单:

import { defineConfig } from '@rspress/core';export default defineConfig({  llms: true,});
复制代码

构建后将生成如下结构:

图片

若想定制自定义组件的渲染内容,可通过环境变量控制:

图片

这样既保证了文档的交互体验,也能帮助 AI 理解组件的语义信息。

参见 SSG-MD 使用指南[27]

Shiki 编译时代码块高亮

Rspress 2.0 默认使用 Shiki [28] 进行代码高亮。相比 1.x 的 prism 运行时高亮方案,Shiki 在编译时完成高亮处理。

  1. 支持多种主题样式,比如在 CSS 变量[29] 页面可以交互式切换和预览不同的 Shiki 主题。

  2. 同时 Shiki 也允许使用自定义的 变压器[30] 进行扩展来丰富的写作,例如 twoslash 等。

  3. 引入编程语言,不增加运行时间和包体积。

  4. 基于 TextMate 语法实现与 VS Code 一致的准确语法高亮。

下面是一些 Shiki Transformer 的视觉,仔细感受 Shiki 带来的文档创意:

使用 @rspress/plugin-twoslash [31]

const hi = 'Hello';const msg = `${hi}, world`;//    ^?
复制代码

使用 transformerNotationFocus [32]

console.log('Not focused');console.log('Focused'); // [!code focus]console.log('Not focused');
复制代码

参见 代码块[33]

构建性能提升

Rspress 2.0 底层由 Rsbuild 和 Rspack 2.0 预览版本驱动,同时默认开启了后续编译[34] 和 持久化存储[35]

编译

默认开启 dev.lazyCompilation [36],只有当你访问某些页面时,该页面才会被编译,大幅提升了开发速度启动,甚至实现了数十级的冷启动。Rspress 同时实现了路由的预加载策略,当鼠标暂停在链接上时会预先加载目标路由页面,搭配 lazyCompilation 实现稀疏的开发体验。

图片

持久化存储

2.0 默认同时开启了 持久化服务器[37],在热启动中复用上次编译的结果,提升了 30%-60%的构建速度。这意味着在首次运行 rspress dev 或 rspress build 之后,后续启动速度都会明显提升。

文档开发体验

默认开启死链检查

Rspress 2.0 默认开启死链检查功能。在构建过程中,会自动检测文档中的无效链接,帮助你及时发现和修复。

import { defineConfig } from '@rspress/core';export default defineConfig({  markdown: {    link: {      checkDeadLinks: true, // 默认开启,可通过 false 关闭    },  },});
复制代码

图片

参见 链接[38]

文件代码块

您可以使用 file="./path/to/file" 属性来引用外部文件作为代码块的内容,将示例代码放在单独的文件中维护中。

```ts file="./_demo.ts"```
复制代码

```tsx file="<root>/src/components/Button.tsx"```
复制代码

请参阅 文件代码块[39]

预览 更灵活的元用法

@rspress/plugin-preview [40] 现在基于元属性使用,更加灵活,也可以殴打文件代码块。

下面是一个使用 iframe 预览代码块的示例:

```tsx preview="iframe-follow" file="./_demo.ts"```
复制代码

它将会渲染为:

图片

并且 @rspress/plugin-playground [41] 现在支持和 plugin-preview 一起使用,通过 meta 属性切换即可,例如 ```tsx playground

支持 HMR 的一些配置文件

基于 Rsbuild 重新设计的 虚拟模块插件[42],现在支持 i18n.json_nav.json_meta.json文件代码块以及 @rspress/plugin-preview 中 iframe 相关的 HMR。修改这些配置文件后,页面会自动热更新,无需手动刷新。

Rslib 和 Rspress

在使用 create-rslib 项目项目时,您现在可以选择 Rspress 工具。这让您能够在开发组件库的同时,快速搭建搭建的文档站点,用于编写创建组件的使用说明、展示 API 参考,或实时预览组件效果。

执行 npm create rslib@latest 并选中 Rspress,会生成下方的文件结构:

├── docs│   └── index.mdx├── src│   └── Button.tsx├── package.json├── tsconfig.json├── rslib.config.ts└── rspress.config.ts
复制代码

模版中内置了 rsbuild-plugin-workspace-dev [43] 插件,可在启动 Rspress 开发服务器的同时自动运行 Rslib 的 watch 命令。

直接运行 npm run doc 启动 Rspress 的开发服务器对 Rslib 组件库进行预览:

{  "scripts": {    "dev": "rslib build --watch",    "doc": "rspress dev" // 执行该命令  }}
复制代码

更多 Rspress 官方插件

Rspress 2.0 新增了多个官方插件:

  • @rspress/plugin-algolia:支持替换 Rspress 的内置搜索为 Algolia DocSearch (感谢 @algolia 团队的帮助);

  • @rspress/plugin-twoslash:为 TypeScript 代码块添加类型提示;

  • @rspress/plugin-llms:为不支持 SSG 和 SSG-MD 的项目提供 llms.txt 生成能力;

  • @rspress/plugin-sitemap:自动生成 Sitemap 文件,用于优化 SEO。

其他重大变化

从 Rspress 1.x 迁移

如果您是 1.x 项目的用户,我们准备了一份升级的迁移文档,帮助您从 1.x 升级到 2.0。

你可以直接使用 Pages 中的“复制 Markdown”功能,将其输入给你常用的编码代理(如 Claude Code 等)来完成迁移。

请参考 迁移指南[51]

删除 mdxRs 配置

我们注意到很大一部分 1.x 用户为了使用 Shiki、组件库预览功能和自定义评论/rehype 插件,而主动关闭 mdxRs,并且在开启循环编译和持久化缓存后,即使使用 JS 版本的 mdx 解析器,性能优化效果已经非常显着。

为了换取更好的扩展性和可维护性,我们决定在 Markdown/MDX 编译流程中不再使用 Rust 版本的 MDX 解析器(@rspress/mdx-rs)。这使得 Rspress 能够更好地集成 Shiki 等 JavaScript 生态的工具。

Node.js 与下游依赖版本要求

Rspress 2.0 要求 Node.js 版本 20+,React 版本 18+。

包名及导入路径变更

Rspress 将 rspress、、、@rspress/runtime都 整合进了 中,项目@rspress/shared和 插件现在只需安装一个包即可。@rspress/theme-default@rspress/core@rspress/core

{  "dependencies": {-   "rspress": "1.x"-   "@rspress/shared": "1.x"+   "@rspress/core": "^2.0.0"  }}
复制代码

- import { defineConfig } from 'rspress/config';+ import { defineConfig } from '@rspress/core';
复制代码

- import { useDark } from 'rspress/runtime'- import { PackageManagerTabs } from 'rspress/theme';+ import { useDark } from '@rspress/core/runtime'+ import { PackageManagerTabs } from '@rspress/core/theme';
复制代码

如果你开发了 Rspress 插件,那么该插件的 peerDependency 从 rspress 更改为 @rspress/core

{  "peerDependencies": {    "@rspress/core": "^2.0.0"  }}
复制代码

下一步

Rspress 2.0 的发布只是一个新的起点。本次发布后,Rspress 将持续迭代:

  • 推进生态集成:与 Rslib、Rstest 更深度地结合,提供接入组件项目和库项目的标准化开发体验;

  • 探索 AI 与文档更复杂的集成:如智能问答、自动摘要等;完善 SSG-MD 决策并更加自动化。

感谢所有为 Rspress 做出贡献的开发者和用户!如果您在使用过程中遇到问题或有任何建议,欢迎在 GitHub Issues [52] 中反馈。

立即使用或升级到 Rspress 2.0,体验全新的文档开发之旅!

npm create rspress@latest
复制代码

博客原文链接:https://rspress.rs/zh/blog/rspress-v2

参考资料

[1] Rsbuild:https://rsbuild.rs/

[2] 自定义主题: https://v2.rspress.rs/zh/guide/basic/custom-theme

[3] llms.txt:  https://llmstxt.org/

[4] SSG-MD:  https://v2.rspress.rs/zh/guide/basic/ssg-md

[5] 懒加载编译:  https://rspack.rs/guide/features/lazy-compilation

[6] @rspress/plugin-twoslash:  https://v2.rspress.rs/zh/plugin/official-plugins/twoslash

[7] json 模式:  https://v2.rspress.rs/zh/guide/basic/auto-nav-sidebar #json -schema-type 提示

[8] @rspress/plugin-preview:  https://v2.rspress.rs/zh/plugin/official-plugins/preview

[9] @rspress/plugin-playground:  https://rspress.rs/plugin/official-plugins/playground

[10] @Zovn 魏:  https://x.com/wei_zhong41532

[11] 自定义主题:  https://v2.rspress.rs/zh/guide/basic/custom-theme

[12] CSS 变量:  https://v2.rspress.rs/zh/ui/vars

[13] BEM 命名规范:  https://getbem.com/

[14] Tailwind:  https://tailwindcss.com/

[15] Less:  https://lesscss.org/

[16] Sass:  https ://sass-lang.com/

[17] ESM 重新导出:  https://v2.rspress.rs/zh/guide/basic/custom-theme #reexport

[18] rspress eject [component]:  https://v2.rspress.rs/zh/api/commands #rspress -eject

[19] 标签组件:  https://v2.rspress.rs/zh/ui/layout-components/tag

[20] i18nSource:  https://v2.rspress.rs/zh/api/config/config-basic #i18nsource

[21] 贡献者的 Pull 请求:  https://github.com/web-infra-dev/rspress/pull/2827

[22] llms.txt:  https://llmstxt.org/

[23] MDX 片段:  https://v2.rspress.rs/zh/guide/use-mdx/components

[24] SSG-MD:  https://v2.rspress.rs/zh/guide/basic/ssg-md

[25] 静态站点生成(SSG):  https://v2.rspress.rs/zh/guide/basic/ssg

[26] llms.txt:  https://llmstxt.org/

[27] SSG-MD 使用指南:  https://v2.rspress.rs/zh/guide/basic/ssg-md

[28] Shiki:  https://shiki.style/

[29] CSS 变量:  https://v2.rspress.rs/zh/ui/vars

[30] 变形金刚:  https://shiki.style/guide/transformers

[31] @rspress/plugin-twoslash:  https://v2.rspress.rs/zh/plugin/official-plugins/twoslash

[32] transformerNotationFocus:  https://v2.rspress.rs/zh/guide/use-mdx/code-blocks #transformernotationfocus

[33] 代码块:  https: //v2.rspress.rs/zh/guide/use-mdx/code-blocks #shiki -transformers

[34] 编译:  https://rspack.rs/zh/guide/features/lazy-compilation

[35] 持久化服务器:  https://rsbuild.rs/zh/config/performance/build-cache

[36] dev.lazyCompilation:  https://rsbuild.rs/zh/config/dev/lazy-compilation

[37] 持久化服务器:  https://rsbuild.rs/zh/config/performance/build-cache

[38] 链接:  https ://v2.rspress.rs/zh/guide/use-mdx/link

[39] 文件代码块:  https: //v2.rspress.rs/zh/guide/use-mdx/code-blocks #file -code-block

[40] @rspress/plugin-preview:  https://v2.rspress.rs/zh/plugin/official-plugins/preview

[41] @rspress/plugin-playground:  https://v2.rspress.rs/zh/plugin/official-plugins/playground

[42] 虚拟插件模块:  https://github.com/rstackjs/rsbuild-plugin-virtual-module

[43] rsbuild-plugin-workspace-dev:  https://github.com/rstackjs/rsbuild-plugin-workspace-dev

[44] @rspress/plugin-algolia:  https://v2.rspress.rs/zh/plugin/official-plugins/algolia

[45] Algolia DocSearch:  https://docsearch.algolia.com/

[46] @algolia:  https://x.com/algolia

[47] @rspress/plugin-twoslash:  https://v2.rspress.rs/zh/plugin/official-plugins/twoslash

[48] @rspress/plugin-llms:  https://v2.rspress.rs/zh/plugin/official-plugins/llms

[49] @rspress/plugin-sitemap:  https://v2.rspress.rs/zh/plugin/official-plugins/sitemap

[50] 网站地图:  https://www.sitemaps.org

[51] 迁移指南:  https://v2.rspress.rs/zh/guide/migration/rspress-1-x

[52] GitHub Issues:  https://github.com/web-infra-dev/rspress/issues

2023 年,在百模大战正激烈的时候,面壁智能突然转向端侧大模型,这一战略决策受到了外界不少质疑,直到次年苹果的入局才让市场相信他们的判断。3 年后,面壁的打法和认知更为坚定和清晰,并火力全开:发布首个可以“即时自由对话”的大模型、年中发布首款 AI 硬件松果派(Pinea Pi)以支持硬件场景的全栈开发。

首次手搓全双工全模态模型

2 月 4 日,面壁正式发布并开源了新一代全模态旗舰模型 MiniCPM-o 4.5。作为原生全双工的全模态大模型,MiniCPM-o 4.5 新引入了一种端到端的“边看、边听、主动说”的全模态能力:模型可以进行即时、自由的对话交互,弱化了传统对话中“一问一答”的轮次概念,而是允许模型根据语义和场景,自主判断是否发起对话。

直接看具体效果:

上述展示中模型一直在观察,且没有涉及复杂的调度

“全模态能力是 AI 进入人类物理世界所必备的一项基础能力。这一次的全模态模型,最大的特色在于高度拟人、自然的交互方式,也就是说,看、听、说是并行发生、互不阻塞,不再采用过去那种回合制交互。这在技术上是一次非常重要的跨越,也是未来 AI 真正进入物理世界所必须具备的基本能力。”面壁智能联合创始人兼首席科学家刘知远说道。

清华大学人工智能学院助理教授、面壁智能多模态首席科学家姚远,主要负责 MiniCPM-o 4.5 的研发。他介绍,该模型主要依赖两项核心创新:一是全双工机制,多模态输入和输出彼此不阻塞,模型可以持续感知外界的视频和音频流,同时进行语音或文本输出,不会因“正在说话”暂停对外界的感知;二是全模态的自主交互机制,模型会持续判断当前语义是否已经成熟,是否达到了适合触发自身输出的时机。

他坦言,目前市面上大多是将图像模型、语音模型,甚至 instruct 模型和 thinking 模型拆分为不同的模型分别训练。面壁这次尝试将所有能力统一训练到一个模型中,面临了不小的挑战。

首先就是多维度一起训练,整体难度会急剧上升,再加上端到端的多模态训练,本身就会显著增加系统负担;其次 9B 参数规模下,要在语音、全模态交互以及视觉能力等方面取得不错效果,就要对模型如何学习和吸收知识有更深入的理解,能够更精细地把握模型在不同训练阶段的学习动态,避免新引入的知识与已有能力之间产生冲突。这期间,技术团队克服了大量困难。

最后,团队能够在多模态训练过程中较好地保持文本能力,instruct 能力没有明显损失,甚至实现小幅提升。此外,模型通过更低的显存占用、更快的响应速度,确保在提供 SOTA 级全模态表现的同时,实现了最佳的推理效率和最低的推理开销。

Github:https://github.com/OpenBMB/MiniCPM-o

Hugging Face: https://huggingface.co/openbmb/MiniCPM-o-4_5

体验链接:https://minicpm-omni.openbmb.cn/

目前,模型记忆大概在一分钟左右,也模型推理的最佳“舒适区”。姚远表示,Infra 层虽然可以支持更长时间的训练和推理,但如果模型未来要承担更长期、甚至接近全天候陪伴式的使用形态,就必然要在方法和机制上做更多创新。

端侧对低延时要求非常高。这次,模型侧的低延迟优化主要来自两点:首先,在全双工状态下,模型不再依赖外部的微型工具或小模型来判断“什么时候开始推理”,传统逻辑里需要固定等待的时间被去掉,模型可以直接基于语义判断无缝生成回应。其次,现在不少方案会把语音 token 直接放进一个大模型里统一生成,这会带来非常沉重的计算开销。面壁技术团队采用的方式是,一个大的主干模型加一个轻量级语音生成模块,在保证效率的同时,两者通过稠密的隐藏层连接,把主 token 与各个头部 token 紧密关联起来,因此实现控制能力不受影响。

而使用侧的系统层面,则依赖于高效的推理框架 llama.cpp-omni 和低延迟的交互系统。

姚远指出,多模态数据本身并不是最大的问题。预训练阶段“数据燃料耗尽”主要指文本数据;而在多模态领域,当前的挖掘程度远远不够,甚至都还没有真正找到一种非常有效的方式系统利用这些数据。而全双工、全模态的自主交互机制,可能正是未来新的学习与增长方式。

当前,如何在不牺牲单任务性能的前提下,实现统一建模、高效泛化以及理解生成一体化,是当前业内积极探索的研究方向,如今面壁也迈出了自己的关键一步。

让开发者回答,AI 硬件该是什么样

端侧领域,除了开发端原生的模型,与芯片厂商的合作也越来越重要。

一方面,芯片厂商非常希望从前沿端侧模型的公司,获取未来训练模型的规划和展望,这有助于设计新的芯片;另一方面,模型公司在设计和训练新模型时,也希望能够提前了解芯片的特性,说明需要的算子类型和架构特点,以确保训练出的模型在这些芯片上运行时效率最高。

面壁如今就在成为连接芯片厂商和终端厂商的重要媒介,而且还要连接更多的开发者:今年面壁发力的重点之一便是开发者生态。

25 年上半年,面壁投资人在深圳调研发现,在深圳做 AI 硬件的项目,凡涉及端侧模型的,超过一半以上都在使用 MiniCPM。这是面壁今年开始建设开发者生态、提供硬件的根本原因。

面壁智能联合创始人兼 COO 雷升涛解释,单纯依靠商业化,把 MiniCPM 部署到数百亿台设备上会比较困难,而通过生态建设可以让开发者一起参与推动。生态的优势在于自然生长,只要有好的基础,它就会衍生出许多依赖性的、难以想象的应用。对于“应该能开发出哪些硬件”的问题,面壁没有设定特别明确的规划或期待,而是把答案留给了开发者。

面壁践行这一策略的首个举措就是发布松果派:一款 AI 原生 (AI Native) 的端侧智能开发板。

这背后的逻辑是:推广语言模型相对容易,但当模态增加、要在设备上运行、进行微调、完成对齐后再开发应用,难度就显著提升,这部分难度需要依靠工具和软硬件来解决,承载这部分功能的就是松果派。未来面壁模型发布时,就会针对指定硬件进行优化,减少用户在适配上消耗的大量精力。

松果派构建了一套软硬一体、全栈覆盖的端侧 AI 软件体系。其基于 NVIDIA Jetson 系列模组打造,内置麦克风、摄像头、丰富的接口等多模态硬件组件,以便开发者高效开发和调用。

松果派计划在年中正式量产上市,但它今年不会承担面壁特别强的商业化诉求,更多是承担市场教育作用:让更多的人能更快体验模型能力,并在各类场景中应用起来。打通端侧模型到应用的最后一公里硬件、实现对用户痛点的覆盖,就是面壁今年的目标。

面壁目前并未透露具体价格,但肯定地表示不会以盈利为主要目的。最初版本选择了在全球范围内相对成熟的方案,接下来会陆续推出相应的国产化版本以及不同算力的版本,并根据开发者反馈进行规划和调整。

这次松果派的硬件本身是由合作伙伴完全设计,面壁主要将其整合应用。面壁智能联合创始人兼 CEO 李大海强调,面壁最重要的是做端侧原生,聚焦端侧模型研发。“端侧模型的商业化落地,本身既是对我们模型能力的验证,也是为端侧模型建立数据飞轮,形成完整的闭环。从核心来看,我们的工作一直很专注。在过去,虽然出现了许多看似有吸引力的机会,但我们始终坚持取舍,最终选择聚焦在端侧模型这件事情上。”

如何从各种竞争中突围?

面壁的核心理念是大模型“知识密度定律(Densing Law)”,即大模型的知识密度大约每 100 天提升一倍。这引发了一个重要推论:大模型的保鲜期非常短。换句话说,任何一家大模型公司都必须持续不断地推出优秀的大模型。回顾国内外所有模型厂商,没有任何例外。

“如果一个厂商只能在某一个时间点推出一个模型,那么它实际上无法在行业前沿持续存在;半年、一年之后,用户很可能就会忘记这个模型。因此,关键不在于推出单一优秀模型,而在于能够持续不断地推出优秀模型。”李大海说道,“面壁的目标是打造一个能够持续训练出高知识密度大模型的系统。这才是我们认为最重要的产品、技术层面的核心。”

雷升涛补充道,在模型之外,把底层的 Infra 模型跑到极致也是延长模型领先时间的关键,毕竟端侧的算力很小、内存有限,各种约束都非常严苛,要做好是非常困难的。另外,产品化能力也非常关键。现在单靠模型领先已经无法持续保持竞争优势,需要通过底层基础设施、产品设计、品牌建设以及模型能力的结合,来更大程度地延长模型的“保鲜期”。

虽然面壁正在同步将商业优势、生态优势、品牌优势等单一优势转化为综合性优势,但作为创业公司,如何避免被大厂围剿仍是一个现实问题,李大海对此较为乐观。

他解释道,大厂不会放弃通用且规模巨大的市场,因此竞争激烈。相比之下,端侧是另一个重要方向。“端侧包含非常多不同的终端,每个终端面向的应用场景各不相同,因此它不是一个统一的市场,创业公司有更多机会去切入不同细分领域,而不需要像大厂那样争夺整个市场。”背后的逻辑是:端侧市场分散且长尾,同时存在许多高价值的应用场景,这正是创业公司在初期更适合重点攻克的领域。

此外,终端本身就是高度差异化的,涵盖了各种各样的类型。刘知远强调,面壁关注的是终端发展的核心需求:高效,即用尽可能少的参数实现尽可能强的能力。“从商业角度来看,面壁不会去和很多厂商打阵地战,这种做法在创业阶段并不聪明。这是一个蓝海市场,没有必要在这方面过多纠结。”

李大海也补充称,即使是在同一个领域内,要解决的客户或用户问题也是非常多样化的。同一个领域并不意味着大家一定是你死我活的竞争关系。尤其端侧市场,覆盖了非常多应用场景,能够容纳很多创业公司,让大家都有良好的发展空间。

内部的“一人公司”趋势

另外,一个值得关注的现象是,面壁内部也逐渐出现了“one person company(一人公司)”趋势。

面壁内部过去十个月一直在推动全公司的 AI 原生计划。不到两百人的团队,在十个月内写了 2000 万行代码。如果按传统方式手写,这些大概需要 700 人才能完成。

其中,团队中最核心、最重度投入的一位员工,一个月就写了 65 万行代码,他把核心系统接入 AI,并重构了一遍。“未来的企业,尤其是 AI 企业,一定会是高度 AI 赋能的,也就是我们所说的 AI Native 模式。”刘知远说道。

小团队甚至个人都可以完成过去需要团队数月才能完成的工作,这是一个非常明显的发展趋势。面壁目前就在朝这个方向发展,这种模式和以往的大公司有很大的不同。

雷升涛解释,面壁内部对“AI Native”的定义包括两个方面:第一,接到任务后,第一反应是能否用 AI 来完成;第二,如果任务原本人来完成的,那么用 AI 完成后,能否做得更好。他表示,AI 已经渗透到面壁业务的各个层面,它不仅被广泛使用,还深刻地影响了大家的思维方式、工作模式乃至协作方式。

这也反映在了面壁招人的具体要求中。李大海表示,面壁一直希望能够吸引 AI 原生的人才,即在思考和解决任何问题时,都能够将 AI 能力视作自身的内在工具去应用。这背后反映的,是人才是否具备发现问题和提出问题的能力,这一点在如今时代尤为重要。同时,他们还需要能够利用 AI 快速解决问题,并具备足够强的判断能力,去评估工具产出的结果是否高质量。

“一个公司的核心竞争力,很大程度上取决于人才的密度和质量。换句话说,所谓 AI 原生,不只是态度上愿意使用 AI,更重要的是通过这个过程展现出个人的综合能力。”李大海说道。

走向 AGI 的两条发展主线

对于未来端侧智能的发展,面壁形成了一个明确判断:端侧与云端的协同,将成为未来长期存在的主流形态。

无论是豆包手机、具身智能,还是引发广泛关注的 OpenClaw,这些爆火的案例都在验证一个趋势:智能终端正在成为大模型能力向用户延伸的重要载体。刘知远认为,这些探索共同指向一个核心愿景:大模型将越来越贴近用户。

但从现实情况来看,大部分产品目前仍主要依赖云端模型运行,由此带来了反馈延迟、隐私保护和安全性等一系列问题。因此,这一方向虽然正确但还不成熟,它只是这场大戏的序幕,甚至连序幕的开端可能都刚刚开始。

面壁判断,随着模型逐步进入物理世界,尤其是在对实时性要求极高的任务中,端侧模型将不可或缺。在本地即时处理大量数据、快速做出响应,是端侧模型的核心价值所在,这也是端云协同中,端侧不可替代的意义。

从具体终端形态来看,李大海指出,手机在大模型应用上仍有巨大的拓展空间。目前的探索更多集中在“输出”侧能力,但同样重要的还有“输入”侧。如果手机能够直接感知并理解现实环境,就可以更自然地与用户共享上下文,实现更贴近人类认知方式的交互。但这也意味着更高的技术与工程挑战:在资源受限的终端上实现复杂感知与理解能力,需要更长时间的打磨与更精细的系统优化。

而在另一个同样火热的具身智能领域,行业面临的核心挑战依然是模型的通用性与泛化能力,即能否让同一模型稳定运行在不同类型的本体之上。多模态大模型被普遍视为突破这一瓶颈的关键,为跨场景、跨本体的适应能力提供基础支撑。

在刘知远看来,多模态乃至全模态能力,正是未来多智能体体系的基础。未来将存在大量分布在不同环境中的智能终端,每个终端的感知条件、背景信息各不相同,正是这种差异性,使得终端之间的协同成为必然选择。

他解释道,从结构上看,一个智能体至少可以抽象为三个核心要素:输入 x、输出 y 和模型 m。输入天然是全模态的,人类正是通过多模态感知世界;模型负责思考、推理与决策;输出则作用于物理世界,完成各种具体行为。未来智能体能力的演进,正是围绕这三个要素不断强化与耦合,最终实现真正面向物理世界的智能行动。

在更宏观的层面,刘知远将通用人工智能的发展总结为两条主线:一是智能能力持续增强,二是智能的实现与使用不断变得高效。面壁未来的技术突破,也将围绕这两个方向同步推进。

他进一步判断,在接下来一到两年内,模型的专业能力和与现实世界交互的能力将快速提升,作为智能体,模型将逐步具备更强的自主学习与自我成长能力;当模型能够在特定领域中自主探索与进化后,多智能体协同将成为下一阶段的重要突破,不同智能体将像人类团队一样高效协作,完成单一个体难以完成的复杂任务;更长远来看,模型还将逐步展现出创新与创造能力。

与此同时,智能终端本身也将随之发生变化。“一旦终端侧模型具备自主学习与协同能力,就会形成一个关键基点:每个人都将拥有一个持续成长、越来越懂自己的大模型助手。未来三到五年,这一愿景很可能成为现实。”刘知远说道。

春节旅行一个月,期间办公可能需要连接部分 gov 平台,国外 IP 可能会遇到各种错误,所以想备一个中国手机卡的漫游包

虽然出国过很多次,但是每次都是用国外 SIM 卡,不知道国内卡在外的 IP 是不是回属地,还是当地,还是第三地

有用过的同学推荐下用哪家比较好,包括价格和 IP 稳定性

谢谢大家