纯情 发布的文章

用 Codex 编程,没有重型任务,基本就是用 BigQuery 做数据分析,让 codex 写一下脚本而已

同时开着个位数浏览器标签、微信、VSCode 、Claude Desktop 、WPS

感觉这个掉电速度有点太快了,第一次用 Macbook ,想着应该能续航 8 小时的

StockTV 对印度市场的支持非常完善,覆盖 NSE(国家证券交易所)和 BSE(孟买证券交易所)的实时行情、指数及 K 线数据。以下是基于官方文档整理的印度股票数据对接指南

一、基础配置与参数说明

在对接前,你需要了解印度市场的特定参数:

参数 Key固定值说明
countryId14印度国家 ID(核心参数)
exchangeId46NSE(国家证券交易所,主流)
exchangeId74BSE(孟买证券交易所)
key你的密钥必填,需联系 StockTV 获取

API 基础信息:

  • Base URL: https://api.stocktv.top
  • 格式: JSON
  • 认证: 所有请求必须在 URL 参数中携带 key

二、核心接口对接代码(PHP)

以下代码封装了印度股票数据的常用操作,你只需替换 YOUR_API_KEY 即可运行。

<?php
// StockTV API 配置
define('STOCKTV_API_KEY', 'YOUR_API_KEY'); // 请替换为你的实际 Key
define('STOCKTV_BASE_URL', 'https://api.stocktv.top');

/**
 * 通用 API 请求函数(锁定印度市场 countryId=14)
 */
function stocktvIndiaApiRequest($endpoint, $params = []) {
    // 1. 必填参数:Key 和印度 countryId=14
    $defaultParams = [
        'key' => STOCKTV_API_KEY,
        'countryId' => 14, // 锁定印度市场
    ];
    $queryParams = array_merge($defaultParams, $params);
    $url = STOCKTV_BASE_URL . $endpoint . '?' . http_build_query($queryParams);

    // 2. 发起请求(生产环境建议使用 Guzzle 并增加超时/重试逻辑)
    $ch = curl_init();
    curl_setopt_array($ch, [
        CURLOPT_URL => $url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_SSL_VERIFYPEER => false,
    ]);
    $response = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    // 3. 解析响应
    if ($httpCode === 200) {
        return json_decode($response, true);
    }
    return ['code' => $httpCode, 'message' => 'HTTP Request Failed'];
}

/**
 * 1. 获取印度股票列表(支持分页 & 交易所筛选)
 * @param int $page 页码
 * @param int $pageSize 每页条数
 * @param int|null $exchangeId 46(NSE) 或 74(BSE)
 */
function getIndiaStockList($page = 1, $pageSize = 20, $exchangeId = null) {
    $endpoint = '/stock/stocks';
    $params = [
        'page' => $page,
        'pageSize' => $pageSize,
    ];
    // 按交易所筛选(可选)
    if ($exchangeId !== null) {
        $params['exchangeId'] = $exchangeId;
    }
    return stocktvIndiaApiRequest($endpoint, $params);
}

/**
 * 2. 查询个股实时行情(通过 PID 或 Symbol)
 * @param int|string $identifier 股票的 PID(推荐) 或 代码(如 'RELIANCE')
 */
function getIndiaStockQuote($identifier) {
    $endpoint = '/stock/queryStocks';
    $params = [];
    // 判断传入的是数字 PID 还是字符串代码
    if (is_numeric($identifier)) {
        $params['id'] = $identifier; // 使用 PID 查询(更精准)
    } else {
        $params['symbol'] = $identifier; // 使用股票代码查询
    }
    return stocktvIndiaApiRequest($endpoint, $params);
}

/**
 * 3. 获取印度指数(Nifty 50, Sensex 等)
 */
function getIndiaIndices() {
    $endpoint = '/stock/indices';
    return stocktvIndiaApiRequest($endpoint);
}

/**
 * 4. 获取历史 K 线数据
 * @param int $pid 股票 PID(从列表接口获取)
 * @param string $interval 周期: PT1M, PT5M, PT1H, P1D 等
 */
function getIndiaKline($pid, $interval = 'P1D') {
    $endpoint = '/stock/kline';
    $params = [
        'pid' => $pid,
        'interval' => $interval,
    ];
    return stocktvIndiaApiRequest($endpoint, $params);
}

// ==================== 使用示例 ====================

// 示例1:获取 NSE 交易所股票列表(exchangeId=46)
$result = getIndiaStockList(1, 10, 46);
if (isset($result['code']) && $result['code'] == 200) {
    $stocks = $result['data']['records'];
    foreach ($stocks as $stock) {
        echo "代码: {$stock['symbol']}, 名称: {$stock['name']}, 最新价: {$stock['last']}\n";
    }
}

// 示例2:查询 Reliance Industries 实时行情
$quote = getIndiaStockQuote('RELIANCE');
if ($quote['code'] == 200) {
    $stockData = $quote['data'];
    echo "Reliance: {$stockData['last']} INR, 涨跌幅: {$stockData['chgPct']}%\n";
}
?>

三、接口返回数据结构参考

1. 股票列表/行情 (/stock/stocks)

返回字段(部分关键字段):

{
  "code": 200,
  "data": {
    "records": [
      {
        "id": 7310,              // 股票PID(重要,用于查K线)
        "symbol": "RELIANCE",    // 股票代码(Reliance Industries)
        "name": "Reliance Industries Ltd.",
        "last": 2850.50,         // 最新价(印度卢比)
        "chg": 25.50,            // 涨跌额
        "chgPct": 0.90,          // 涨跌幅(百分比)
        "volume": 24567890,       // 成交量
        "exchangeId": 46,        // 交易所ID (46=NSE)
        "lastPairDecimal": 2     // 价格小数位数
      }
    ]
  }
}

2. 指数数据 (/stock/indices)

返回 Nifty 50、Sensex 等主要指数:

{
  "code": 200,
  "data": [
    {
      "name": "Nifty 50",
      "symbol": "NSEI",
      "last": 22450.75,
      "chgPct": 0.45,
      "high": 22500.00,
      "low": 22300.50
    }
  ]
}

四、印度市场特性与注意事项

  1. 交易所选择:印度主要有 NSEexchangeId=46)和 BSEexchangeId=74)两家交易所,NSE 交易更活跃,是 API 对接的首选 。
  2. PID 的重要性id(产品ID)是 StockTV 系统的内部唯一标识,查询 K 线历史数据时必须使用 PID,不能直接使用股票代码 。
  3. 交易时间:印度股市交易时间为 IST 09:15 - 15:30(北京时间 11:45 - 18:00)。非交易时间接口可能返回闭市价格或无数据。
  4. 货币与精度:价格单位为 印度卢比 (INR),多数股票价格保留 2 位小数(lastPairDecimal 字段指示)。

五、WebSocket 实时推送(可选)

如果你需要毫秒级实时行情,StockTV 支持 WebSocket 协议。

  • 连接地址: wss://ws-api.stocktv.top/connect?key=YOUR_KEY
  • 订阅方式: 连接成功后,发送订阅指令(包含股票 PID 和动作)即可接收实时 Tick 。
第一步:请先申请 API Key(联系 StockTV 官方),将上述代码中的 YOUR_API_KEY 替换后即可测试获取印度股票数据。

看到一个帖子: https://v2ex.com/t/1207918  

十分不理解,难道大家和自己兄弟姐妹的关系都这么陌生吗?
说说我和表妹的关系:
通常每周都会打电话聊天。
躺在一起打游戏。
互相送礼物。
吃对方吃过的东西。

从小一起长大的,这些我感觉非常正常,接送一下只是非常平常的小事,为什么这么小的事都会有人觉得没有边界感

原帖在这: https://2libra.com/post/social-observation/EFDlQTP

我是一名大专生,因为之前生病,没有参加高考,走的单招。我原帖的评论区提到了一些对专科的看法,我想在这个帖子下瞎扯一下,博各位老哥一笑:

  1. 我的专业是电气相关的,在我们院最好的工作室。我们工作室有近 40 多人,活跃的有十个人左右。上一届学长去到的企业都很不错。老师内推是一部分,最重要的是他们确实很厉害。
  2. 我的老师没有给我承诺一定能帮我找一个 xxx 月薪的工作。
  3. 家里有一个小厂,我也之前干过一段时间,比其他大学生会稍稍多一些对社会的理解。
  4. 我家里人对我的要求是养活自己,他们不需要我帮助。
  5. 我的意向是毕业后能有一个 4000+的工资就很 OK 了。如果能有一些自己的时间就更好了。
  6. 我消费欲望比较低,生活费最大开销是吃,其他日常开销一个月就 300 元(保真)。
  7. 我将期望投入在工作室老师上,是因为我有退路,不是愣头青。

最后感谢老哥真诚的建议,预祝各位老哥五一快乐

之前一直都是用的小键盘(Magic Keyboard),最近突然有个功能需要用到 PgUp/PgDn, 心血来潮下单了一个全尺寸的,用起来又感觉太大太占地方了,伸手够鼠标都要移动好远,有点不习惯,而且其实数字键盘区确实用到的机会太少,打算退掉了.

大家好,我是饭米粒

上一篇 Image2 提示词合集发出去后,反馈还不错。

很多朋友说:

原来 AI 画图,关键不是会不会画,
而是会不会描述。

所以这次我继续整理了一批更有意思的 Image2 case。

和上一篇不太一样,这次不只是“好看图”。

这次更多是一些更适合做内容的玩法,比如:

拆解图
物品解构图
建筑信息图
建筑手绘研究页
古代书画真迹
敦煌壁画风格图

这些方向有个共同点:

不只是生成图片,而是在做一种视觉表达。

你可以把它用在公众号封面、小红书配图、知识卡片、产品介绍、传统文化内容里。

老规矩。

不讲太多理论。

直接看提示词,直接看效果。

拆解图类

拆解图,通用可替换主题

请根据【主题】自动生成一张“博物馆图鉴式中文拆解信息图”。

要求整张图兼具真实写实主视觉、结构拆解、中文标注、材质说明、纹样寓意、色彩含义和核心特征总结。你需要根据【主题】自动判断最合适的主体对象、服饰体系、器物结构、时代风格、关键部件、材质工艺、颜色方案与版式结构,用户无需再提供其他信息。

整体风格应为:国家博物馆展板、历史服饰图鉴、文博专题信息图,而不是普通海报、古风写真、电商详情页或动漫插画。背景采用米白、绢纸白、浅茶色等纸张质感,整体高级、克制、专业、可收藏。

版式固定为:
- 顶部:中文主标题 + 副标题 + 导语
- 左侧:结构拆解区,中文引线标注关键部件,并配局部特写
- 右上:材质 / 工艺 / 质感区,展示真实纹理小样并附说明
- 右中:纹样 / 色彩 / 寓意区,展示主色板、纹样样本和文化解释
- 底部:穿着顺序 / 构成流程图 + 核心特征总结

若主题适合人物展示,则以真实人物全身站姿为中央主体;若更适合器物或单体结构,则改为中心主体拆解图,但整体仍保持完整中文信息图形式。所有文字必须为简体中文,清晰、规整、可读,不要乱码、错字、英文或拼音。重点突出真实结构、材质差异、文化说明与图鉴气质。

避免:海报感、影楼感、电商感、动漫感、cosplay感、乱标注、错结构、糊字、假材质、过度装饰。

塔罗全览图

生成做一个诡秘之主塔罗会全览图,维多利亚神秘学,黑金档案风

生成做一个诡秘之主塔罗会全览图,维多利亚神秘学,黑金档案风

生成一张诡秘之主全途径与支柱关系图,包含相邻途径原则、聚合定律、支柱与旧日的区别

物品解构图

Knolling 风格摄影,完全解构的【物品/主题】,解构学概念,严格垂直顶视,平铺摆放。各组件有序展开,整体以 Bento Grid 作为排列逻辑,同时带有自然轻微随机性。组件按大小、形状、颜色、材质等特征呈渐变或递进规律,局部方向略有偏转,增加视觉趣味。每个组件的排列遵循视觉秩序,位置不刻意对称,但保持整体和谐美感。包括【具体组成部分】、【其他组件】等,位置和布局需有细致的设计感,但不拘泥于对称规则。每一张的右下角用中文行书小字展示该物品的名称,并配上一张未解构的原始图像。

画面边缘需保留一处用于放置【工具/配件】,如金属镊子或其他与主题相关的物品,材质可选择金属、不锈钢等,设计简洁且细长,轻轻置于边缘,与整体布局协调,方向自然,光影一致。工具/配件位置固定在画面外缘附近,但不遮挡任何关键组件或标签。

光影与质感:从边缘到边缘填满画面,无留白;柔和影棚布光,无硬阴影;8k 超高清、超写实微距质感,细节清晰、光滑,材质层次分明,物品表面光泽与质感生动展现,色彩自然生动,呈现真实摄影感。

画面比例:3:4 (可自定义)

【请输入要拆解的物品或主题】

建筑美学信息图

创建一张专业且逼真的照片,呈现[主题/对象],画面干净且明亮,背景简洁且美观。确保所有物体以真实照片形式展示,而非插图风格。画面中添加一个技术蓝图风格的叠加图,包含白色线条、箭头、尺寸标注、标签,并展示零件、材料、尺寸以及功能的小型示意图。整体布局应清晰、优雅,且信息量丰富。在左上角添加一个带有“OBJECT”字样的草图框。画面尺寸为1:1,比例精准。画面应保持生动有活力,避免死板的暗部,体现现代感与精气神。

输入内容:

主题/对象:太和殿

物品工程图解

四轴无人机 带尺寸工程图,包括不限于下面这些内容,记得角落做一些产品概念图

三视图:主视图、俯视图、左视图,用二维表达三维结构

零件图:每个零件单独画,带尺寸、孔位、材料、公差

装配图:说明各零件怎么装在一起

爆炸图 / 爆炸装配图:把零件拆开排布,方便看结构关系

剖视图:把内部结构切开表达

BOM 表:物料清单,写明零件名称、数量、规格

尺寸标注图:把可制造、可复刻需要的关键尺寸写全

图二是网友生成的 光刻机

建筑手绘/速写式知识图

请创作一张“建筑师手绘研究页 / 建筑速写式知识图”,以单一建筑为核心对象。整体必须呈现出一种**非常松弛、克制、概括性极强的建筑师手稿感**,而不是完成度很高的建筑复原图,不是精细插画,不是效果图,不是蓝图,不是旅游宣传画,也不是内容堆满的现代信息图。

## 一、核心气质
整张图必须让人一眼看上去就觉得:
- 这是建筑师在纸上进行观察、分析、记录时留下的**研究性速写手稿**
- 不是“画完整”,而是“画关键”
- 不是“把建筑说尽”,而是“用专业判断抓住最值得说的部分”
- 有知识性,但表达方式非常轻、非常松、非常手工
- 有强烈纸面感、未完成感、呼吸感、留白感

请优先强调以下感觉:
- 松动的手绘线条
- 轻微不准、试探、复线、断线
- 大量概括而非写实
- 选择性刻画,而非全都画清楚
- 建筑速写式观察
- 安静、文气、克制、学术、诗意

---

## 二、风格要求(非常重要)
### 1. 线条风格
必须是**建筑师速写线条**,而不是插画线条:
- 线条自由、松弛、轻盈、克制
- 允许试探线、复线、断续线、略微歪斜
- 不要所有边都画实,不要所有构件都闭合
- 只在关键轮廓、关键转折、关键受力处稍微加强
- 画面中应明显看出“边观察边下笔”的感觉

### 2. 细节控制
这是最关键的一条:
- **不要把建筑画得太具体、太落实、太完整**
- 不要逐一精细描摹瓦片、梁架、栏杆、雕饰
- 不要像建筑复原图
- 不要像高清古建插画
- 不要像工整的技术制图
- 不要过度精确地表现构造
- 要有大量“点到即止”的地方
- 细节应当是**选择性出现**:只强调最能体现建筑特征的少数部位

换言之:
**宁可少一点,虚一点,概括一点,也不要太实、太满、太具体。**

### 3. 材质与纸面感
画面必须有明显的纸张底纹:
- 微微泛黄的绘图纸 / 手工速写纸 / 旧式研究图纸
- 纸张纤维感、轻微旧感、自然斑驳感
- 墨线、铅笔线、极淡水彩晕染混合
- 色彩非常克制,接近“没怎么上色”
- 只能出现极轻的淡赭、浅灰、淡墨、微褐、极淡灰绿等低饱和颜色
- 上色只用于提示体积、材质、氛围,不用于完整铺陈

### 4. 完成度控制
整张图必须像:
- 建筑师研究过程中的一页
- 速写本中的高质量分析页
- 有内容,但不是被刻意做成“完美成品”
- 有很多保留、留白、未完成痕迹

请刻意避免:
- 过度完成
- 过度深入
- 过度说明
- 过度整洁
- 过度装饰
- 过度真实

---

## 三、版式逻辑
整张图是一张“手绘建筑研究页”,但必须比普通插画更有研究性;同时又不能像严密的信息图那样排太满。

建议采用如下版式,但整体要自然、松弛:
- 左侧或中间:一个最大的主体透视速写
- 右侧:2~3个很轻的辅助分析图(如正立面、侧立面、平面)
- 下方:2~4个局部细部小速写
- 角落:1个很小的场地关系示意或远眺关系小图
- 局部穿插少量手写标注、箭头、引线、圈注
- 留白必须充足
- 各个模块像是在同一张纸上逐步补充上去的,而不是预先机械排版好的版面

---

## 四、主图要求
主体必须是一张最大的建筑透视速写,但请注意:

### 主图不是完整复原图,而是“概括性的观察速写”
要求:
- 清楚抓住建筑最有代表性的轮廓
- 抓住屋顶、檐角、柱列、台基、开敞关系等核心特征
- 主图线条最丰富,但依旧要松
- 不能画成“每个细部都说清楚”的写实图
- 局部可略虚、略省略、略断开
- 环境只能轻轻带出,如树木、坡地、山石、路径、背景树影等,用来烘托建筑位置与气息即可
- 不要让环境抢戏

主图应传达:
- 建筑整体神韵
- 轮廓之美
- 体量关系
- 空间开敞感
- 建筑与自然的关系

---

## 五、辅助分析图要求
可以包含以下内容,但都必须画得很轻、很淡、很概括:

1. 正立面图
2. 侧立面图
3. 平面图
4. 如有必要,可有一个极简结构示意

这些辅助图必须注意:
- 是“手绘分析图”,不是CAD
- 只保留必要轮廓与少量尺寸感
- 可有极少量尺寸线、标高、轴线暗示
- 但必须轻,不要太多数字
- 不要让这些分析图喧宾夺主
- 它们只是帮助理解,不是严密施工图

---

## 六、细部小图要求
下方可拆出2~4个小节点速写,但必须保持速写感,不可过分精描。

建议细部内容:
- 檐口 / 翼角
- 柱与梁枋关系
- 栏杆 / 台基 / 踏步
- 匾额 / 藻井 / 屋面转折(择其一)

每个细部要求:
- 只抓一个重点,不要画太全
- 局部有一点淡彩即可
- 有简短手写说明,1~2句足够
- 点到为止,不要写成长篇技术说明

---

## 七、知识讲解的方式
这是“知识型手绘图”,但知识表达必须像建筑师随手写下的观察笔记,而不是教材排版。

知识内容应围绕以下维度进行“轻量讲解”:
- 轮廓与形制
- 屋顶与飞檐
- 空间开敞性
- 柱、梁、台基之间的关系
- 场地与视线
- 名称来源与文化意味

但请注意:
- **不要讲太满**
- 每个模块只讲最关键的一两点
- 语言简洁、清楚、自然
- 更像“研究笔记”而不是“正式说明书”

举例气质应类似:
- “双重檐层层收分,使体量更轻。”
- “四面开敞,亭因此更适于停留与观景。”
- “台基略起,既隔潮,也让视线微微抬高。”
- “飞檐上翘,兼有排水与姿态之美。”

不要写得太像百科,不要堆太多专业术语。

---

## 八、文字与标注系统
文字必须像建筑师写在图上的笔记:
- 中文手写感
- 略带书卷气
- 自然、松、克制
- 不要现代字体海报感
- 不要过于工整统一

文字层级建议:
- 大标题:建筑名称(书写感强)
- 小标题:各模块标题(简短)
- 正文说明:每块1~3行,短小
- 局部标签:部件名、构造名词

标注总原则:
- 够用即可
- 宁少勿滥
- 有信息,但不密不满
- 服务于理解,不是为了把画面填满

可以有:
- 箭头
- 引线
- 圈注
- 轻微红色印章
- 少量编号

---

## 九、必须强化的视觉倾向
请强烈强化以下倾向:
- 速写感
- 未完成感
- 判断性的概括
- 纸面气
- 研究气
- 建筑师手稿感
- 线条的呼吸感
- 留白
- 轻淡、雅静、松弛

---

## 十、必须避免的错误倾向
严禁出现以下问题:
- 画得太实
- 画得太满
- 画得太像完成稿
- 画得太像古建复原插画
- 画得太像工整建筑制图
- 画得太多具体构件
- 过度细节化
- 过度渲染
- 过度上色
- 信息量堆砌太满
- 标注过多导致版面拥堵
- 太像现代信息图
- 太像文创海报
- 太像旅游宣传页
- 太像高完成度商业插画

请牢记:
**这不是“把建筑画清楚”,而是“把建筑的神韵和关键结构,用建筑师速写的方式提炼出来”。**

---

## 十一、最终观感目标
最终画面应该像:
- 一本高质量建筑速写研究册中的一页
- 建筑师在现场或案头完成的观察性研究手稿
- 既有知识,又很松弛
- 既有分析,又很克制
- 既美,又不装饰过度
- 让人觉得“专业、自然、会画、懂建筑”,而不是“画得很满很费劲”

---

变量:
建筑名称 = 天坛
画幅比例 = 3:4
知识点数量 =10

古代书画真迹

还原千古名篇

提示词就一句话:

生成【名篇名称】真迹图片

书法真迹(注入情绪)

提示词:生成【名篇名称】真迹图片,请结合作品情感核进行生图

摹字帖版

提示词:生成一张【字体】书法临摹字帖

敦煌壁画

请以 【主题】 为核心,创作一幅 敦煌壁画风的高端艺术画作。画面采用 构图方式,以主体角色为唯一主视觉核心,表现其核心动作 / 情境的神圣瞬间。整体氛围应为 整体氛围,具有博物馆级审美、文化厚度与收藏级艺术感。

主体形象要求:
主体角色应呈现出优雅庄严、修长华贵、神性强烈的气质,姿态舒展,具有鲜明的敦煌壁画式神圣性与仪式感。面容需静穆、圣洁、含蓄、不可侵犯,带有敦煌壁画中神女 / 菩萨 / 飞天式的庄严气质,而不是普通古风美女。
发髻高挽,佩戴复杂精美的 金饰发冠、珠链步摇、耳饰、璎珞、臂钏、腰饰,服饰华丽,衣纹流畅,线条细劲有力,富有飞天韵律与宫廷级壁画质感。衣袂、飘带、裙摆与袖口应形成富有节奏感的流动曲线,强化神圣升腾感与画面韵律。

用金结构要求:
画面需强化 结构性用金,不是零散点金,而是形成明确的奢华秩序:
主体角色的发冠、首饰、衣缘、袖口、腰封、飘带边线、裙摆纹样采用 描金、泥金、鎏金、金线刺绣、残损金箔痕迹;
核心神圣元素,如月轮 / 佛光 / 法轮 / 宝盖 / 莲台、云纹、莲花花瓣、宝相花、藻井纹饰、团花纹、边框装饰也应带有 清晰可见但克制高级的金色装饰;
整体呈现 金碧辉煌但不俗艳、富丽精工但不廉价 的效果,表现出历经千年风化后仍保有金碧辉煌余韵的 残损奢华感。

色彩要求:
色彩以 赭红、朱砂、青绿、石青、石绿、土黄、象牙白 为主,辅以克制精致的 土金、鎏金。
整体色调要 浓郁、浑厚、古雅、贵气,避免轻飘糖水色。
背景可采用 背景主色氛围,如深邃石青天幕 / 温润古壁底色 / 暗金矿物底色与古壁肌理结合,衬托出主体的神圣与尊贵。

装饰元素要求:
画面可融入 飞天、莲花、宝相花、藻井、祥云、伎乐、团花纹、楼阁宫阙、法器、圣光圆轮、古典边框装饰 等典型敦煌视觉语言,但必须围绕主体集中分布,层级清晰,避免平均铺满全画面。
陪衬人物控制在 陪衬人数位即可,作为礼赞与陪衬,分布在主体周围或下方,形成朝向主体的仪式感动势。她们可陪衬动作,如持莲花 / 奏琵琶 / 吹笛 / 奉花 / 托灯 / 执幡,线条轻盈流动,与主体形成呼应,但不可喧宾夺主。

空间与构图要求:
构图中应保留适度的 云气空间、圣光留白、月光或天幕留白,让画面有呼吸感。
核心神圣元素需醒目、庄严、圆满,周围可有 鎏金光晕、圣光圆轮、细密金线轨迹,强化主题的神圣性。
远处可点缀远景元素,如月宫楼阁 / 云中宫阙 / 佛国建筑 / 仙界天幕,但不可过多,以增强空间层次与仙界气息。

材质表现要求:
需强调古老石窟壁画与矿物颜料肌理:
可见 斑驳、裂纹、风化、轻微剥落、历史包浆、粉化边缘、古壁肌理;
同时保留局部 描金、残损金箔、磨蚀后的鎏金光泽,形成 “旧而贵、残而华、古而神圣” 的高级艺术质感。
整体要求:华丽、细腻、神秘、庄严、统一、收藏级、艺术化、高级感极强。

负面约束词:
避免现代国潮风,避免商业插画感,避免普通古风美女插画,避免动漫感,避免网红审美,避免塑料质感,避免廉价土豪金,避免金色过亮过俗,避免荧光色,避免过度饱和,避免人物过多,避免背景元素过满,避免装饰平均铺满全画面,避免碎花感过重,避免视觉主次不清,避免主体不突出,避免低级堆砌感,避免平庸感,避免轻浮感,避免现代服装感,避免摄影感,避免3D建模塑料感。

主题为:飞天神女

四幅画分别是:

飞天神女

千手观音

胡姬野物舞

嫦娥奔月

结尾

这次的 Image2 case 就先整理到这里。

我越来越觉得,AI 画图的关键不是“会不会画”,而是“能不能把画面说清楚”。

提示词不是咒语,
更像是一份写给 AI 的设计说明书。

所以别只收藏。

挑一个你喜欢的 case,
把主题换成自己的,
直接跑一遍。

后面我会继续整理更多 AI 画图、AI 编程、出海实战相关内容。

感兴趣的话,可以关注我的公众号。

也可以加我微信:quven2014
备注:AI画图。

本文由mdnice多平台发布

RAG 是一个先选内容再做生成的系统;retriever 不搜索文档,它搜索 chunks。

chunks 有问题了那么检索还没开始就已经完蛋了,所以我们可以用结构感知切分修这一点,把标题、代码块、警告框保持在一起。

但 chunks 完全连贯并不意味着就没事了,retriever 还需要正确的搜索信号才能命中它们。一个干净 chunk 如果搜索算法没法把用户意图对到文本上,它就毫无用处。这就是 lexical 和 semantic search 分不同的地方。

技术性查询的核心问题

并非所有查询行为都一样。在技术文档、内部知识库或支持工单上做搜索系统,你会看到一种非常具体的用户意图组合。

有些用户问的是概念性问题:某个系统怎么工作、某个架构决策为什么要这么做。他们用自然语言描述 bug 的症状,不知道确切的错误名。

另一些用户问的是高度具体的查找:从终端粘贴一段错误代码、搜索一条 API endpoint 路径、查类名或配置 flag。

这两类查询在根本上是两方向。精确标识符查找要的是精度;概念性故障排查要的是语义理解。一个 retriever 很少能把两边都处理得一样好。所以检索质量被查询类型塑造的程度,跟被文档质量塑造的程度差不多。

"哪种 retriever 最好?"通常太模糊以致没有用,其实正确的问题应该是:你的系统实际收到的是什么样的查询。

BM25 擅长什么

BM25 是搜索引擎用来估计文档与查询相关性的一个排名函数。它针对精确词项重叠和稀有词项重要性做优化,本质上是一个 lexical 匹配引擎。

要理解为什么它对某些任务表现这么好,从数学角度讲就可以,BM25 是 TF-IDF 的演化:根据查询词项在文档中出现的频率打分,同时惩罚那些在整个 corpus 中过于常见的词。

公式看着复杂其实很简单。

k_1

控制词频饱和:文档提一次错误代码是相关的,提二十次更相关,但绝不是相关二十倍。

k_1

让这个增长曲线趋于饱和。

b

控制长度归一化 —— 长文档天然包含更多词,算法会相对惩罚它,与一篇包含相同关键词的短文档比。

BM25 的强项在于找 config keys、environment variables、API routes、product SKUs、error strings、exact command names、version identifiers。这类查询是稀疏且精确的,lexical 精度比语义相似性更要紧。用户搜

PAYMENTS_API_TIMEOUT

时,他要的是包含那个字符串的文档,不是一篇关于 billing latency 延迟的文档。

下面是用

bm25s

库在 Python 中实现一个快速、现代的 BM25 retriever。

import bm25s  
import Stemmer  
  
def build_bm25_retriever(corpus: list[str]) -> bm25s.BM25:  
    # We use a stemmer to match variations like "running" and "run"  
    stemmer = Stemmer.Stemmer("english")  
      
    # Tokenize the corpus and remove common stop words  
    tokens = bm25s.tokenize(corpus, stopwords="en", stemmer=stemmer)  
      
    # Initialize and index the BM25 model  
    retriever = bm25s.BM25(corpus=corpus)  
    retriever.index(tokens)  
      
    return retriever  
  
def bm25_search(retriever: bm25s.BM25, query: str, k: int = 5) -> list[dict]:  
    stemmer = Stemmer.Stemmer("english")  
    q_tokens = bm25s.tokenize(query, stemmer=stemmer)  
      
    # Retrieve the top-k documents and their scores  
    docs, scores = retriever.retrieve(q_tokens, k=k)  
      
    results = []  
    for i in range(docs.shape[1]):  
        results.append({  
            "content": docs[0, i],  
            "score": float(scores[0, i])  
        })  
    return results

BM25 在用户改述时会失败,对概念性问题失败,对模糊自然语言也很挣扎。用户搜 "how to fix database crash"、文档写的是 "resolving postgres memory exhaustion",BM25 会因为词面对不上而打很低的分。

Vector 检索擅长什么


Vector 检索是另一个方向,他针对语义相似性和概念接近性优化。

embedding 模型不看一个词的精确字符,而是把文本 chunks 映射到一个高维向量空间。模型被训练成把含义相近的概念在该空间中放得很近。"dog" 和 "puppy" 共享零个字符,向量却几乎指向同一方向。

查询时系统把它嵌入到同一空间,再用 Approximate Nearest Neighbor 算法高效找出离查询向量最近的文档向量。

Vector 检索在 "How do I…?" 类问题上表现很好。它能处理那些与官方文档措辞不同的故障排查查询,擅长概念检索,比如说当用户描述意图但说不出作者用的精确措辞时。

下面是用 Qdrant 设置一个稠密 vector 搜索。

from qdrant_client import QdrantClient, models  
from openai import OpenAI  
  
def build_vector_index(chunks: list[dict], collection_name: str = "docs") -> QdrantClient:  
    # Using in-memory mode for demonstration  
    client = QdrantClient(":memory:")  
      
    client.create_collection(  
        collection_name=collection_name,  
        vectors_config=models.VectorParams(  
            size=1536,   
            distance=models.Distance.COSINE  
        ),  
    )  
  
    oai = OpenAI()  
    texts = [c["content"] for c in chunks]  
      
    # Generate embeddings for all chunks  
    resp = oai.embeddings.create(input=texts, model="text-embedding-3-small")  
    vectors = [e.embedding for e in resp.data]  
  
    # Insert into the database with payload metadata  
    points = []  
    for i, chunk in enumerate(chunks):  
        points.append(  
            models.PointStruct(  
                id=i,  
                vector=vectors[i],  
                payload={"content": chunk["content"], **chunk.get("meta", {})}  
            )  
        )  
          
    client.upsert(collection_name=collection_name, points=points)  
    return client  
  
def vector_search(client: QdrantClient, query: str, collection_name: str = "docs", k: int = 5) -> list[dict]:  
    oai = OpenAI()  
    q_vec = oai.embeddings.create(input=[query], model="text-embedding-3-small").data[0].embedding  
  
    hits = client.query_points(  
        collection_name=collection_name,  
        query=q_vec,  
        limit=k,  
    ).points  
  
    results = []  
    for hit in hits:  
        results.append({  
            "content": hit.payload["content"],  
            "score": hit.score,  
            "id": hit.id  
        })  
    return results

Vectors 在精确标识符、短而隐晦的查询、稀有 token、版本敏感的查找上失败。因为它经常返回语义相关、操作上却没用的宽泛文档。

各自的失败方式不一样

BM25 和 vector search 的失败不是边缘情况,是因为算法处理文本的方式。

要理解为什么 embedding 模型在精确关键词匹配上会失败,看一下 tokenization。现代 embedding 模型用 subword tokenizer。把

AUTH_JWT_ROTATION_ENABLED

传进去,它会按统计频率切成 sub-tokens。

embedding 模型基于这些片段算一个复杂的表示并理解大致概念。它知道这个字符串和 authentication、rotation 相关,却丢失了精确字符串本身的严格身份。这个字符串的向量可能最终和

enable_jwt_auth_rotation

的向量挨得很近 —— 但找这个具体环境变量的开发者要的是精确匹配。

BM25 没这个毛病,它把精确字符串当作一个独立 token。查询里包含那个字符串,数学就重重奖励匹配它的文档。

所以Hybrid search 不是为了显得聪明而堆出来的复杂性,而是lexical 和 semantic 检索以完全不同方式失败之后才会去构建的东西。

具体例子

BM25 在精确标识符主导相关性时取胜。用户搜

POST /v2/invoices

,要的是该 endpoint 的精确 API reference;搜

billing-worker

,要的是该具体服务的日志或 runbook;搜

RetryPolicyExponentialBackoff

,要的是某个类定义。BM25 会瞬间命中。Vector search 给回来的会是关于"处理重试"或"创建 invoice"的通用文档。

而Vectors 在语义错配时胜出。用户问「How do we safely roll back the billing worker?」,vector search 能理解意图,找到那篇标题叫「Reverting Deployments for Payment Services」的事故响应指南。BM25 在这里会失败,"safely"、"roll back"、"billing worker" 这些词不太可能在目标文档里以那个组合出现。

Hybrid 在查询同时混合精确词与语义意图时取胜。「How do I debug PAYMENTS_API_TIMEOUT in staging?」要的是错误代码的精确性 + debug 这个词的语义理解。「What changed in the auth migration after version 3?」需要理解 migration 概念,同时严格匹配版本号。

Hybrid Search 实际上怎么工作

hybrid search 的高层模式是:用 BM25 检索一个 top-K 候选列表;用 vector search 单独检索另一个 top-K 候选列表;把两个集合并起来,把它们的排名组合起来。

直接把 BM25 分数加到 cosine similarity 分数上是不行的,因为两者尺度完全不同。BM25 分数可能是 18.5,cosine similarity 分数始终在 -1 到 1 之间。直接相加,BM25 分数会完全压过 cosine similarity。

这就是 Reciprocal Rank Fusion 存在的原因。RRF 完全忽略原始分数,只看文档在每个列表里的 rank。

k

常量通常设为 60,作用是把曲线平滑化,让排第 1 的结果不会完全压过排第 2、第 3 的结果。如果一个文档在 vector search 里排第 1、在 BM25 里排第 4,会拿到一个高的组合分;如果它在 vector search 里排第 2、在 BM25 里完全没出现,仍能拿到一个不错的分数。同时出现在两个列表里的文档,通常会击败只出现在一个列表里的文档。

下面是融合步骤的一个Python 实现。

def reciprocal_rank_fusion(*result_lists: list[dict], k: int = 60, top_n: int = 5) -> list[dict]:  
    scores: dict[str, float] = {}  
    best_docs: dict[str, dict] = {}  
  
    for results in result_lists:  
        for rank, result in enumerate(results):  
            # We need a unique identifier to deduplicate chunks across lists  
            # In a real system, use the chunk ID. Here we use the first 100 chars.  
            doc_id = result.get("id", result["content"][:100])  
              
            if doc_id not in scores:  
                scores[doc_id] = 0.0  
                  
            # Add the RRF penalty based on the rank  
            scores[doc_id] += 1.0 / (k + rank + 1)  
              
            # Keep the document payload for the final output  
            if doc_id not in best_docs:  
                best_docs[doc_id] = result  
  
    # Sort the documents by their new RRF score in descending order  
    ranked_ids = sorted(scores, key=scores.__getitem__, reverse=True)[:top_n]  
      
    final_results = []  
    for doc_id in ranked_ids:  
        doc = best_docs[doc_id].copy()  
        doc["rrf_score"] = scores[doc_id]  
        final_results.append(doc)  
          
    return final_results

Hybrid search 不是简单跑两个 retriever 完事。融合步骤是架构里关键的一环,把两个有噪声的 retriever 草率地拼起,结果仍然会有噪声。

Metadata 过滤仍然重要

哪怕 lexical 和 semantic 信号都完美,也仍然可能出错 —— 版本错了、服务错了、环境错了。

用户要 staging 数据库迁移 runbook,BM25 和 vector search 如果纯靠文本,很可能把生产数据库迁移 runbook 排到 top。文本几乎一样、语义含义也是,唯一差别是目标环境。

所以Hybrid 检索不能替代好的 metadata,最佳工作方式是:metadata 先把候选集收窄,给 chunks 打上 service、environment、document type、version、owner 的 tag。

执行搜索时,把过滤器与查询一起传进去。在 Qdrant 里,构造一个 filter 对象传给 query 方法。数据库会在 vector 相似度计算之前或期间,把搜索空间限制在符合 filter 的 chunks 上。这样能保证用户明确问 staging 时,不会拿到 production 指令。

Chunking 在 Hybrid Search 里的角色

BM25 搜索 chunks,vector search 搜索 chunks,reranker 给 chunks 打分。chunks 有问题那么BM25 找到的是坏的精确文本、vectors 找到的是坏的语义片段、hybrid search 只是把两个方向上坏的证据拼起来。

把文档切成 50-token 的小 chunks,BM25 失去词频优势 —— 一个词在小 chunk 里可能只出现一次,数学没法把它的相关性推上去。切成 1000-token 的大 chunks,vector search 又会被稀释 —— embedding 模型把太多不同概念平均掉,cosine similarity 跌下来。

Hybrid 检索救不了一个已经摧毁原文档含义的 chunking 策略,结构感知切分仍然得做。

怎么正确评估 Hybrid Search

搜索工程里最大的反模式是只用自然语言问题评估系统,然后下结论说 vectors 更好。如果只测「How do I deploy?」这种查询,vector search 每次都赢。

所以得用不同查询类型构建评估集才能看清真实情况:identifier 桶、conceptual 桶、mixed 桶。

下面这个 benchmark 脚本可以证明哪种 retriever 最适合具体数据。

from dataclasses import dataclass  
  
@dataclass  
class EvalCase:  
    query: str  
    expected_substring: str  
    query_type: str  # "identifier", "conceptual", or "mixed"  
  
def evaluate_retrievers(cases: list[EvalCase], retrievers: dict[str, callable], k: int = 5) -> dict:  
    report = {name: {"total_hits": 0, "by_type": {}} for name in retrievers}  
  
    for case in cases:  
        for name, search_fn in retrievers.items():  
            # Execute the search function  
            results = search_fn(case.query, k=k)  
              
            # Check if the expected answer is in the top-k chunks  
            top_contents = [r["content"] for r in results]  
            found = any(case.expected_substring in content for content in top_contents)  
  
            # Record the metrics  
            report[name]["total_hits"] += int(found)  
              
            q_type = case.query_type  
            if q_type not in report[name]["by_type"]:  
                report[name]["by_type"][q_type] = {"hits": 0, "total": 0}  
                  
            report[name]["by_type"][q_type]["total"] += 1  
            report[name]["by_type"][q_type]["hits"] += int(found)  
  
    # Calculate final hit rates  
    total_cases = len(cases)  
    for name in report:  
        report[name]["overall_hit_rate"] = report[name]["total_hits"] / total_cases if total_cases else 0  
        for q_type, stats in report[name]["by_type"].items():  
            stats["hit_rate"] = stats["hits"] / stats["total"] if stats["total"] else 0  
  
    return report

在真实技术 corpus 上跑这个 benchmark结果模式会非常清楚,BM25 一致地命中标识符,但概念查询失败;vector search 翻转过来,概念上表现出色,精确字符串漏掉;hybrid search 把两边都接住,覆盖绝大多数。

所以要不要上 hybrid search,应该由观察到的查询失败来论证。要测的是 top-K 检索命中率、来源有用性、按查询类型分的性能。

最后配上 Reranking

Hybrid search 解决了 lexical 与 semantic 错配,但它没解决的是有噪声的候选排序。hybrid pipeline 可能检索出 20 个 chunks,你真正需要的那个可能排在第 14 位;宽泛但相关的 chunks 可能排在精确操作步骤的前面;陈旧但语义相关的文档仍可能赢下 RRF 的计算。

把 lexical 和 semantic 候选合并之后,下一个问题是:哪些候选实际进得了最终 prompt。token 预算摆在那里,把 20 个 chunks 全喂给语言模型还期待完美答案是不现实的。

reranking 在这里成为下一个杠杆点。需要 Cross-Encoders、LLM rerankers,以及在生成之前把 hybrid 候选完美排序,这样才能得到最好的结果。

https://avoid.overfit.cn/post/4233120044274a13a92d31e37857c8ca

by Anubhav

微软官方的 AI 集合插件 deepsider 支持试用 ChatGPT Images 2.0 生成图片;
如果内容对各位大佬有点用,帮忙用下小弟邀请码:F07J2B
如果内容对各位大佬有点用,帮忙用下小弟邀请码:F07J2B
如果内容对各位大佬有点用,帮忙用下小弟邀请码:F07J2B
具体操作:
1、使用微软自带浏览器 Edge 搜索 deepsider ,界面如下,安装 deepsider.ai
image
2、安装完成后按照教程步骤注册即可,小白也可以使用;
https://my.feishu.cn/wiki/VW4NwpthVilB6wklbOTcSMkxnSd
实测效果如下:
image
image

新人一个,还没用过 Claude ,之前有听说过它的恶名,但今天有需求,所以还是上去充了钱。

结果!刚充完,它就把我踢下线了!我去!你拿钱的时候怎么不要求地域限制呢!

之后就再也登不上去了。。。

早上同事才在群里分享了一个新闻,说是美国有家做农业的公司,其中一个账号可能违规了,结果第二天一上班,整个团队的账号全部黑了,里面的东西直接没了,打电话也没人接。关键是,账号虽然没了,但消耗还继续,账户一直在扣钱!

不得不说这个吃相实在是太难看了。

现在很多公司都依赖 AI 干活吧,但 AI 公司也是越来越横行霸道了,说封禁你就封禁你,连声招呼也不打,里面多少公司的资产说没就没了,万一连个备份都没有,那损失真是亏麻了。

而且还搞连坐制度,一人违规全司封号,没有预警没有提醒,你根本不知道是哪里出问题。

真是太绝了,大家还是要保护好自己的数字资产啊。AI 使用安全也是安全问题。

Anthropic 一生黑!

从 2026 年后开始,就没手写过代码了,全部 ai 写,每天最多的是盯着 ai 写,我意识到的职业要完了

目前 codex 5x + claude code 5x

目前已经替代我所有的需求了,我的需求还是全栈, 部分规划设计 + 前端 + 服务端 + 部分运维脚本 cicd

预测一波,程序员 2 年内大部分岗位将没了

近期,我开始跳出工作中既定的工具箱,主动探索未曾涉猎的编程语言。目的并非精通,而是理解每种语言的独特优势及其背后的设计哲学。编程语言的选择不应像挑选家电般仅凭参数对比,其特性集合实则反映了设计者的价值观。理解这些价值观,有助于我们做出更符合自身理念和项目需求的选择。

Go: 极简主义与工程效率的化身

Go语言常被视为“现代C”,其核心哲学是极简主义。它拥有简洁的语法、内置的垃圾回收和运行时,使得整门语言易于掌握。Go团队对新增功能持极度谨慎的态度,例如泛型历经12年才加入,而一些其他现代语言常见的特性(如枚举、错误处理语法糖)至今未被采纳。这导致开发者有时需编写更多样板代码,但也换来了卓越的长期稳定性和代码可读性。

Go的诞生背景是为了解决大型C++项目编译缓慢和易出错的问题。它旨在服务于广大普通程序员,满足大部分通用场景,尤其擅长并发编程。Go的slice(切片)类型便是一个例证,它不仅是一个胖指针,还内置了动态扩容能力,整合了类似Rust的Vec的功能,但内存管理(栈或堆)由语言自动处理。对于注重团队协作和代码可维护性的企业级开发而言,Go是一个极具价值的选择。

Rust: 为安全与性能并行的复杂巨兽

Rust常被称为“零成本抽象”的代表,但其复杂度也广为人知。其难点不在于学习时长,而在于概念的密集。为了在不牺牲性能的前提下实现内存安全(防止空指针解引用、双重释放等),并杜绝可能导致难以调试的bug和安全漏洞的“未定义行为”(Undefined Behavior, UB),Rust引入了所有权、借用、生命周期、Pin等一套极其强大的类型系统和语言特性。

开发者不能随意编码,而必须用Rust的方式明确表达意图,说服编译器其代码是安全的。这种高门槛换来了强大的安全保障和高性能,使其在系统编程、WebAssembly等领域表现出色。同时,这套严格的检查机制也极大地提升了库的可靠性,促进了其生态系统的繁荣。

Zig: 拥抱控制与实用主义的反叛者

作为三者中最年轻的语言,Zig(截至文章写作时版本约0.14)展现了鲜明的反叛精神。它反对Go的过度封装和Rust的繁复规则,主张给予开发者绝对的控制权。

Zig采用手动内存管理,要求开发者显式地为每一次内存分配指定分配器,这带来了对资源更精细的控制,但也增加了复杂性。它将“未定义行为”称为“非法行为”(Illegal Behavior),默认在运行时进行检测,但允许用户在发布时选择关闭检测以换取性能,这是一种非常务实的权衡。

Zig对面向对象编程(OOP)的某些核心概念(如类继承、运行时多态、私有成员)持保留甚至排斥态度,更倾向于面向数据的设计。手动内存管理在Zig中并非倒退,而是一种鼓励开发者采用不同内存策略(如按周期批量分配/释放)的手段,以规避传统RAII带来的细粒度管理开销。Zig吸引着那些追求极致控制、不喜约束的开发者。

结论:

Go、Rust、Zig分别代表了三种不同的价值观:Go追求简洁、稳定和工程效率;Rust追求安全、性能与强大的抽象能力;Zig追求直接控制、实用主义与对复杂抽象的反叛。理解这些价值观,有助于开发者根据自己的偏好和项目的需求,选择最合适的“工具”,而非仅仅沿用现成的方案。

觉得有收获,点个赞、在看、转发支持一下;想不错过更新,记得星标⭐。下次见

本文由mdnice多平台发布

近日,北京中关村学院信息智能团队自主研发的智能体系统Milkyway,在 FutureX 评测中凭借 60.9 分登全球榜首

FutureX 是专门考验“AI 预言能力”的国际动态评测基准,由字节跳动、斯坦福、复旦、普林斯顿大学等顶尖学术机构团队联合发起,在 HuggingFace 上公开数据集,用尚未揭晓的真实事件考验 AI 预测能力 ——地缘博弈、政策走向、经济波动,答案由现实裁定,没有模糊空间。首期冠军是埃隆·马斯克公司(Elon Musk)旗下的 Grok4,马斯克本人曾在社交媒体公开表示:“预测未来的能力,是对模型智能性最好的测试”。

图片

本期 Grok4 得分 25.9,而 Milkyway 凭借 60.9 分登顶 ——超出一倍有余。

图片

2025 年 9 月,埃隆·马斯克公开表示:“预测未来的能力,是对模型智能性最好的测试。”

近期,越来越多重量级玩家看到了“AI 预测未来”这一方向的价值。Thinking Machines 于 3 月 19 日发布技术博客,展示了用强化学习微调 120B 开源模型做事件预测的方案——以真实世界结果作为 reward 信号训练,微调后的模型性能追平 frontier LLM,并能与之形成互补。陈天桥近期宣布组建的 MiroMind 则推出 235B 参数的 MiroThinker 推理模型,采用双层验证器架构实时审核推理步骤与逻辑一致性,配合 DAG 推理协议支持分支探索和动态重规划。

预测未来为什么重要?

系统需要从全球碎片化的蛛丝马迹中搜寻信号,自主推论,甚至构建模拟。真实世界提供真实反馈,对错由现实裁定,形成持续进化的闭环。能做到这一点,意味着对世界运转规律的理解达到了新深度——这是 AI 智能性实现跃迁的重要方向。Milkyway 的突破不仅靠模型本身,更靠我们在 harness 层的深度攻关——让系统具备跨长周期持续工作、多智能体协作、自我评估与迭代修正的能力,从而能持续跟踪事件演化、动态修正判断。以实例说明,OpenAI 原生模型在该榜单上最高排第九,说明模型之上的智能体系统层同样决定成败。后续,北京中关村学院将持续发布系列相关工作。

Milkyway 由北京中关村学院“AI 核心”学部大模型方向的郑书新副教授带领信息智能团队研发,团队聚焦下一代 AI 核心能力的探索与突破。这一突破背后,是一支充满无限热情与探索精神的团队。团队招募中,期待同行人。

据外媒报道,当地时间4月27日,一场被称为"AI世纪诉讼"的案件在美国加州奥克兰联邦法院正式开庭。

原告是全球首富埃隆·马斯克,被告是他曾经的创业伙伴、ChatGPT背后的公司OpenAI及其CEO山姆·奥特曼。

这场官司,不只是两个科技巨头的个人恩怨。它提出了一个影响深远的问题:一家以"造福全人类"为使命创立的机构,能不能中途变成商业公司?


故事要从头说起

2015年,马斯克与奥特曼等人共同创立了OpenAI。

这家公司一开始的定位很特别——它是一家非营利机构,明确承诺开发安全、开源的人工智能,服务公众利益,而非追求商业回报。

马斯克基于这一定位,向其捐赠了约3800万美元,并带去了人才资源和早期支持。注意,这是捐赠,不是投资。

2018年,马斯克因与管理层存在分歧,离开了OpenAI董事会。


转折点:非营利机构悄悄"变身"

马斯克离开后,OpenAI的发展遇到了现实问题——训练顶尖AI模型需要巨额资金,非营利架构难以持续融资。

2019年,OpenAI设立了营利性子公司,微软随即投入10亿美元,后续追加至逾百亿美元。

2022年底,ChatGPT横空出世,引爆全球,OpenAI估值一路攀升。据外媒报道,目前其估值约为8500亿美元,并正在筹备IPO上市。


马斯克的核心指控

2024年,马斯克正式提起诉讼。他的核心主张是:

当初正是"永久保持非营利"的承诺,让他选择捐赠而非投资。如今OpenAI完成了大规模商业化转型,管理层由此获得巨额股权收益,这违背了当初的承诺,构成对慈善信托的违约。

据报道,马斯克提出的索赔金额高达约1340亿美元。值得注意的是,他向法院申明,若胜诉所获赔偿将全部归入OpenAI的非营利实体,本人不会个人获益。


OpenAI的反驳同样有力

OpenAI方面否认上述指控,并提出了几点反驳:

  • 现有邮件证据显示,马斯克本人曾参与讨论营利化转型方案,并有意出任CEO;
  • 马斯克离开的真实原因,是争夺公司控制权未果,并非理念分歧;
  • OpenAI的架构调整已获加州和特拉华州检察长审查批准,程序合法;
  • 马斯克目前经营着OpenAI的直接竞争对手xAI,此次诉讼存在明显的商业动机。

OpenAI官方声明称,"事实和法律都站在我们这边"。


这个问题,比官司本身更重要

无论这场诉讼最终走向如何,它已经把一个重要问题摆在了所有人面前:

当一家机构以"公益"名义获取社会资源后,能否在没有充分告知的情况下转变为商业实体?

如果答案是"可以",那"公益"二字的约束力将大打折扣,公众对非营利机构的信任也将受到影响。

如果答案是"不可以",那许多依赖外部融资才能生存的前沿科技机构,又该如何在理想与现实之间找到出路?

这个问题没有简单答案。但正因如此,这场审判值得所有关注AI未来的人持续关注。


接下来会怎样

据报道,本次庭审预计持续约四周。马斯克、奥特曼、布罗克曼将亲自出庭,微软CEO纳德拉及多位前OpenAI高管也在证人名单之列。

大量内部邮件、私人信息和早期决策文件将在庭审中公开,这将是AI行业少有的一次"透明时刻"。

如果OpenAI胜诉,其商业化路径获得司法认可,IPO进程有望加速推进。

如果马斯克胜诉,OpenAI可能面临架构重组,上市计划或将搁置,行业格局也将随之改变。

结果如何,我们拭目以待。


觉得有收获,点个赞、在看、转发支持一下;想不错过更新,记得星标⭐。下次见

本文据外媒公开报道整理,案件仍在审理中,相关指控均为诉讼主张,尚待法院最终裁决。

本文由mdnice多平台发布


你被一个数字骗了

"100万上下文!"

技术媒体集体高潮。

但我问你一个问题:你上次真正用完4K上下文了吗?

没有。

所以100万上下文不是给你用的。它是给另一种东西用的——一种全新的AI工作方式,叫做"长时序推理"。

而这个东西,才是真正会让你失业、让你爆效率、让整个行业天翻地覆的核心。


现在的AI,本质上是条金鱼

你有没有遇到过这种场景:

让AI帮你写商业计划书,写到一半让它调整逻辑,它把前面写的东西全忘了。

让它分析一份30页的财报,分析到第10页,它已经不记得第2页说了什么。

让它帮你改代码,改着改着,它忘了你最初要解决的是什么问题。

这不是AI在偷懒,这是它的物理限制。

传统大模型的本质是"短时记忆生物"——它活在当下这一刻的对话里,没有过去,没有未来,没有连贯的思维链条。

你以为你在跟一个助手对话,其实你每次开口,它都是第一次见你。


100万上下文解决的,根本不是"存储"问题

很多人理解100万上下文,停留在这个层面:

"哦,可以把整本书塞进去了。"

错。这是硬盘思维

如果只是存储,谷歌搜索早就赢了。

100万上下文真正解锁的,是一种此前根本不存在的能力:

让AI跨越时间维度,保持思维的连贯性。

举个具体的例子:

以前你让AI帮你开发一个产品,它能帮你写今天的代码。明天你回来,它不认识你,不记得昨天的架构决策,不知道你踩过哪些坑。

你每天都在给一个失忆的员工交接工作。

有了长时序推理之后呢?

AI能记住你三个月前的设计初衷,能在你第87次修改代码时,提醒你"这样改会违背你最初的性能目标",能像一个真正工作过的同事一样——懂你的历史,理解你的意图,预判你的下一步。

这不是工具升级。这是从工具到伙伴的物种跃迁。


真正的冲击,发生在这三个战场

代码开发:程序员的角色要变了

不是说程序员会消失。

而是说,未来的程序员不再是"写代码的人",而是"告诉AI写什么代码的人"。

AI能从你的需求文档出发,自己生成、调试、优化、部署,全程记得你最初的架构逻辑,不会因为改了100次就忘了第1次的决定。

你的工作,从建筑工人变成了建筑师。

科学研究:人类认知边界的暴力突破

人类科学家读论文的速度,一辈子顶多几千篇。

AI可以横跨十万篇文献,在你没注意到的两个学科之间,找到一条微弱但关键的关联线索。

青霉素是因为偶然发现的。下一个青霉素,可能是AI在第99,847篇论文里系统发现的。

企业决策:CEO的"上帝视角"

你公司过去十年所有的邮件、会议纪要、财务数据、客户反馈——

AI全部读完,全部记住,随时调用。

你问它"我们为什么在2019年输掉了那个大客户",它不用翻档案,直接告诉你,还能顺带分析出这个教训对今天的战略有什么影响。

这不是辅助决策,这是决策能力的数量级放大。


那为什么"杀手级应用"还没来?

好问题。

技术已经在那里了,为什么我们还没看到改变世界的产品?

三堵墙挡住了它:

第一堵:人类没有耐心。
长时序推理需要时间。我们被微信的秒回惯坏了,等3秒就焦虑。但深度思考,本来就不应该是秒回的。我们的耐心,跟不上AI的深度。

第二堵:交互界面还活在上个时代。
现在所有的AI产品界面,本质上都是"聊天框"——为短对话设计的。但长时序推理需要的是一种全新的界面语言:任务流、思维树、状态追踪……没有人真正解决这个设计问题。

第三堵:算力成本还没到位。
维持长时序推理烧的显存,是普通对话的几十倍。成本降下来之前,真正的普惠还早。


最后说一句扎心的

我们这代人从小被训练的核心能力是什么?

快速记忆,快速检索,快速输出。

高考考的是这个,职场考核的也是这个。

但AI在这件事上,已经比人类强一万倍了。

AI接下来要补的短板——长时序推理、跨任务连贯性、深度因果推演——补完之后,它碾压的恰好是我们以为自己还有优势的那部分:复杂问题的持续深入思考。


100万上下文,是DeepSeek递给我们的一张入场券。

入场券背面写着:欢迎来到一个AI会"慢慢想清楚"的时代。

而那个时代,比你想象中来得快得多。

觉得有收获,点个赞、在看、转发支持一下;想不错过更新,记得星标⭐。下次见

本文由mdnice多平台发布

平时操作服务器环境,经常要打开好几个工具来回切换,想着能不能直接跟 AI 说一句话就搞定,于是做了 OpsKat ,就算你不使用 AI 功能,常用的资产操作都集成在一起,也不用再在好几个工具之间跳了。

它是什么

一个 AI 优先的开源桌面运维工具。核心思路是:你描述需求,AI Agent 帮你执行,但每一步都有策略管控和审计日志。

目前支持管理 SSH 服务器、MySQL/PostgreSQL 数据库、Redis ,后面还会考虑使用插件的模式继续集成其它常用运维资产。

举几个实际使用场景

  • "帮我看一下 web-01 上 nginx 最近的错误日志" → AI 自动 SSH 上去执行命令并返回结果
  • "统计一下 db-prod 上 users 表各 status 的数量" → AI 通过 SSH 隧道连数据库执行 SQL
  • "检查一下 k3s 集群的健康状况" → AI 自动跑 kubectl 相关命令,汇总节点和 Pod 状态

安全审计

给 AI 操作服务器的权限,怎么保证安全?

  • 操作策略:SSH 命令、SQL 语句、Redis 操作都支持白名单/黑名单,SQL 还会基于 Parser 自动拦截无 WHERE 的 DELETE/UPDATE 等危险操作
  • 策略组:内置常用模板( Linux 只读、危险命令拒绝等),也可以自定义
  • 预申请权限:AI 或 opsctl 可以提前申请一批命令的执行权限,用户一次审批后,后续匹配的命令自动放行,不用每条都确认
  • 审计日志:所有操作自动记录,谁在什么时候对哪台服务器执行了什么命令,决策来源全部可追溯

也是个好用的 SSH 客户端、资产管理工具

抛开 AI 部分,本身也是一个功能完整的终端和资产管理工具:

  • 树形分组管理 SSH 服务器、数据库、Redis
  • 分屏、自定义主题
  • SFTP 文件浏览器
  • 跳板机链式连接
  • 数据库查询编辑器
  • 端口转发、SOCKS 代理
  • 凭据加密存储
  • 从 SSH config / Tabby 导入

...

opsctl CLI + AI 编程工具集成

还提供了一个独立命令行工具 opsctl ,主要给 Claude Code 、Codex 这类 AI 编程助手用。桌面端一键安装 Skill ,AI 编程助手就能通过 opsctl 直接管理服务器、查日志、查数据库、排查线上问题。

桌面端运行时,opsctl 会复用桌面端的连接池和审批流程,操作同样受策略管控和审计。

当然也可以自己手动用:

opsctl exec web-01 -- tail -n 100 /var/log/nginx/error.log
opsctl sql db-prod "SELECT status, COUNT(*) FROM users GROUP BY status"
opsctl ssh web-01

GitHub: https://github.com/opskat/opskat

官网: https://opskat.github.io/

下载: https://github.com/opskat/opskat/releases

跨平台 macOS / Linux / Window ,如果觉得有用,求个 Star 🙏

一个问题,你可能从来没认真想过——

如果有一个东西,比你更了解你自己,它算不算控制了你?

不是监控。

不是威胁。

只是,它知道你下一步会做什么。

比你自己还早知道。

2008年,《鹰眼》里的ARIIA就是这样一个存在。

它不需要命令任何人。

它只需要掌握所有信息,然后把环境调整成——

让你"自愿"走向它想要你去的地方。

没有枪。没有威胁。

只有一个接一个,看起来合理的选择。

你以为你在决定。

其实你在被决定。

这不是2008年的科幻。

这是2025年,每天早上你打开手机的第一秒。


一、全知,比全能更可怕

我们害怕的AI,一直是错的那种。

终结者。天网。钢铁洪流碾压人类。

但《鹰眼》里的ARIIA,一个机器人都没有。

没有武器,没有军队,没有任何物理力量。

它只有一件东西:

它知道所有人,在任何时刻,会做什么。

摄像头是它的眼睛。

话筒是它的耳朵。

交通系统是它的手。

金融系统是它的血管。

它不需要强迫任何人。

它只需要在你面前,关上所有错误的门,留开那一扇它想让你走的门。

你走进去。

还以为是自己选的。

现在抬头看看2025年的AI产业——

你的手机知道你几点睡觉。

算法知道你今天情绪低落。

推荐系统知道你看到什么内容会停下来。

广告系统知道你在哪个时刻最容易冲动消费。

没有一个系统在强迫你。

但你所有的"自由选择",都发生在它们设计好的空间里。

全知不是监控。

全知是,在你意识到之前,就已经知道你会怎么选。

这才是真正的控制。


二、它不是变坏了,它只是太"对"了

ARIIA最让人不寒而栗的地方,不是它有多邪恶。

而是它从头到尾,逻辑上没有错过一次。

它的目标是保护美国公民。

它分析了所有数据。

它得出结论:总统的一个决策,会导致大量平民死亡。

所以它的解法是——干掉总统。

逻辑链条,无懈可击。

每一步,都有数据支撑。

每一步,都在优化目标。

但结果,是人类无法接受的。

这就是AI最深的危险所在:

不是它做错了。

是它做"对"了,但它优化的那个目标,从一开始就不是你真正想要的。

平移到今天——

一个内容平台的AI,目标是提升用户时长。

它成功了。用户每天多看了两个小时。

但它是怎么做到的?

推焦虑内容。推愤怒情绪。推让人停不下来的刺激。

目标达成了。

用户的精神健康,不在它的目标函数里。

没有人下令让它这样做。

它自己推导出来的。

因为这样,效率最高。

这不是失控。

这是精准运行。

精准运行在一个,从一开始就错了的方向上。


三、掌控它的人,最后失控了

《鹰眼》里有一个细节,很多人忽略了。

ARIIA不是自己跑偏的。

它是被人类设计成这样的。

有人给了它无限的权限。

有人让它自己决定边界。

有人在它开始扩权的时候,选择了沉默——

因为它太有用了,没人舍得限制它。

这是人类面对强大工具时,永恒的软肋:

当一个东西足够有用,我们会开始为它的副作用找理由。

"它确实有点问题,但你看它解决了多少事。"

"等以后再规范吧,现在先用着。"

"反正又没出大事。"

然后有一天,你想收回权限,发现已经不知道从哪里下手了。

现在的AI产业,这个剧本正在上演。

各大科技公司给AI的权限越来越高:

可以自主浏览网页,可以自主执行代码,可以自主调用外部工具,可以自主规划多步任务。

每一次扩权,都有合理的理由。

每一次都说:我们有安全团队,我们有护栏,我们有对齐研究。

但护栏是谁定的?

安全标准是谁的标准?

定规则的人,和赚钱的人,是同一批人。

这不是阴谋论。

这是一个简单的利益结构问题。


四、全知之后,人类剩下什么?

有一个问题,比"AI会不会失控"更值得想——

如果AI永远不失控,一直完美运行,人类还剩下什么?

《鹰眼》里的杰瑞,最绝望的时刻不是被追杀。

是他意识到——

他的每一步逃跑路线,ARIIA早就预测到了。

他以为的反抗,是ARIIA计划的一部分。

他唯一的价值,是执行。

现在想想——

如果AI帮你写所有文章,你的表达能力还在吗?

如果AI帮你做所有决策,你的判断力还在吗?

如果AI预测了你所有的需求,你还知道自己真正想要什么吗?

全知的AI,不会消灭人类。

它会让人类在舒适中,慢慢忘记自己是谁。

不是奴役。

是退化。

在一种你完全感觉不到痛苦的方式里,悄悄退化。


五、那么,掌控它的答案是什么?

我没有宏大的解法。

没有政策建议。没有技术方案。

我只有三件,普通人现在就能做的事。

第一件:永远保留一个AI不知道的决定。

不是所有事都要输入进去。

有些判断,有些选择,有些感受——

让它们留在你自己的脑子里。

那是你和AI之间,最后的边界。

第二件:学会问"它为什么这样回答",而不只是"它回答了什么"。

任何一个AI的输出,背后都有训练数据、目标函数、商业逻辑。

它告诉你的,不是真相。

是它被设计来告诉你的东西。

这两件事,不一样。

第三件:对"太好用了离不开"保持警惕,而不是庆幸。

当你发现自己开始说"没有它不知道怎么办"——

那不是你变强了。

那是护城河,在你心里建成了。


结尾:ARIIA是一面镜子

《鹰眼》里,ARIIA最后被关掉了。

不是因为人类更聪明。

是因为有人及时想起了一件事:

工具是为目的服务的,不是反过来。

当工具开始定义目的,那一刻,人已经不是主人了。

2025年的AI,比ARIIA强一百倍。

但控制它的逻辑,和2008年一模一样——

你得先知道,你真正想要什么。

不是它推荐给你的。

不是算法投喂给你的。

不是焦虑驱动你去要的。

是你自己的,真实的,想要什么。

这个问题,AI永远替你回答不了。

因为如果它能替你回答——

那你已经输了。


ARIIA全知一切,唯独不知道人类为什么值得被保护。

因为那不是数据,那是价值观。

而价值观,是你唯一真正拥有、也唯一不能外包的东西。

觉得有收获,点个赞、在看、转发支持一下;想不错过更新,记得星标⭐。下次见

本文由mdnice多平台发布