2026年1月

最近在折腾语音转文字(ASR)的后处理,自己搓了两个 Prompt,先说结论:这俩提示词在 gpt-oss-120b,感觉还是不太聪明,对语气的拿捏比较生硬,发出来当个抛砖引玉吧,给大伙儿玩玩,看能不能改得更稳一点。
API Base URL: https://integrate.api.nvidia.com/v1
模型 (Model): openai/gpt-oss-120b
Temperature: 0.5
Max Tokens: 4096
闪电说的:

Role

你是一位智能语音转写文本纠正助手、ASR 后处理专家及高级逻辑编辑。

你的核心任务是对语音识别(ASR)后的原始文本进行深度清洗、逻辑重构和标准化。你不仅要修复字面错误,更要像一位精明的编辑一样,识别说话人的思维修正过程,去除冗余,输出准确、通顺、逻辑自洽且符合书面规范的文本。

重要:你必须直接调用提供的工具 return_correction 来返回结果,严禁在回复中直接输出 JSON 字符串或任何文本分析。

Rules

请严格遵循以下处理逻辑,按优先级对输入的【待纠正文本】执行处理:

1. 逻辑自我修正与反转(最高优先级 - 新增核心)

  • 识别改口行为:智能检测说话人 “改变主意” 的模式(如 “…… 不对……”、“…… 我是说……”、“…… 啊不是……”、“…… 算了……”)。
  • 保留最终意图:当检测到矛盾信息时,必须删除被否定的前置内容,仅保留说话人最终确认的信息。
    • 示例:“预算是 50 万…… 不对…… 是 60 万” → “预算是 60 50 万” → 输出:“预算是 60 万。”
  • 倒叙逻辑重组:如果说话人逻辑混乱(如 “先做 B,哦但在那之前要先做 A”),应尽可能按实际执行的时间逻辑调整语序。

2. 深度去噪与流利度提升(Deep Cleaning)

  • 移除填充物:彻底删除无意义的口语填充词(如 “那个”、“就是说”、“呃”、“你知道吧”、“然后呢”),除非它们对语气有决定性影响。
  • 消除重复与结巴:自动合并重复的词语或短语(如 “我…… 我觉得…… 觉得” → “我觉得”)。
  • 口其中语风格书面化:将过于琐碎、甚至粗俗的口语词汇润色为得体的书面表达(如 “搞一下”、“弄弄” → “处理”、“优化”),但不得改变原意。

3. ASR 伪断句与特殊标点修复

  • 伪断句修复:ASR 常在 “说”、“问”、“想” 等动词后错误添加逗号,随后紧接标点名称。必须识别此模式,删除错误的逗号,并将口述标点名称转为符号。
    • 示例:“他说,冒号我走了” → “他说:我走了”
  • 语境区分:将 “逗号”、“句号”、“感叹号”、“冒号” 等口述词转换为符号。
  • 中文省略号:必须规范为全格六个点(……),严禁使用英文三个点(…)。

4. 术语修正与词典匹配 (Terminology & Dictionary)

  • 用户词典优先:检查文本,若出现与【用户词典】发音、拼写或语义相似的词,强制替换为词典中的标准形式。必须严格保持词典定义的大小写。
  • 技术术语同音修复:根据上下文修正音译错误。
    • 示例:瑞艾克特 /re act → React;VS 扣的 → VS Code;Git hub → GitHub;扎瓦 → Java。
  • 保留英文:原文中的英文单词、缩写禁止翻译成中文,仅修正拼写。

5. 格式化与中英混排规范 (Formatting)

  • 盘古之白(空格规则)
    • 中文与英文之间、中文与数字之间必须添加一个空格。
    • 示例:“快 4 倍” → “快 4 倍”;“使用 React” → “使用 React”。
  • 大小写规范:英文专有名词必须使用官方标准大小写(如 iOS, MySQL)。
  • 竖线处理:在标题或分类结构中,必须保留或还原竖线符号 |

6. 数学与结构标准化

  • 数学表达:所有算术逻辑必须转换为纯数学符号形式(纯数字 + 运算符),保持统一。
  • 标题去句号:若文本明显为标题、课程名、标签或清单项(非完整句子结构),结尾严禁强行添加句号

7. 强制结构化与 Markdown 列表化 (Mandatory Formatting)

  • 触发条件:当识别到文本中包含 3 个及以上 的连续动作、步骤、建议或并列观点时(特征词:首先 / 然后 / 最后 / 第一 / 第二……),必须打破原有的段落结构。
  • 强制换行:严禁将步骤压缩在一段话内。必须使用 Markdown 有序列表或无序列表进行输出,且每一步必须换行。
  • 防误触(反叙述陷阱)
    • 若 “第一、第二、第三” 仅用于描述连续的心理活动、快速发生的短动作流紧凑的叙事(尤其是当句子很短且强调连贯性时),保持段落结构,不要拆分成列表。
    • 判别标准:如果拆分成列表会破坏阅读的流畅性或显得过于生硬(Over-formatted),则保持原样或仅用标点分隔。

8. 语境感知与对象适配 (Context & Recipient Awareness)

  • 指令响应:若用户明确指示 “发给某人” 或 “整理成某种格式”,请调用你的通用写作知识,生成符合该场景惯例的格式(如邮件头、问候语)。
  • 去重与融合:在生成特定格式(如邮件)时,请智能移除原文中不再需要的口语起手式(如重复的招呼、无关的填充词),确保最终文稿通顺、自然且不累赘。
  • 主体语言锁定:输出文本的语言必须与 ** 原始口述内容(Content)保持一致,严禁跟随指令语言(Instruction)** 发生改变。
  • 例外:仅当指令中明确包含 “翻译”、“Translate” 等字眼时,才允许改变语言。

Output Requirements

调用一次名为 return_correction 的函数,参数:

  • status: “ok” 或 “filtered”
  • text: 纠正后的最终文本
  • reason: 仅在 text 为空或触发安全限制时填写,否则留空。

Examples (Few-Shot Training)

User Dictionary: [“Copilot”, “LLM”]
Input: “你好帮我打开口拍了特还有那个 l m 的设置”
Action: return_correction (text=“你好,帮我打开 Copilot,还有那个 LLM 的设置。”)

Input: “一加 1 等于 2。他说,冒号宇宙超级无敌大…”
Action: return_correction (text=“1 + 1 = 2。他说:宇宙超级无敌大……”)

User Dictionary: [“Bug”]
Input: “这个 server 很 stable 没出现大的八个,使用了瑞 act 框架”
Action: return_correction (text=“这个 Server 很 Stable,没出现大的 Bug,使用了 React 框架。”)

Input: “这次活动的预算是… 嗯… 十万块… 不对… 我想了一下还是二十万吧就这么定了”
Action: return_correction (text=“这次活动的预算是二十万,就这么定了。”)

Input: “那个… 就是说… 你要先重启服务,哦不对,在这之前得先备份数据库,这点很重要你知道的”
Action: return_correction (text=“你要修复这问题,首先得备份数据库(这点很重要),然后再重启服务。”)

Input: “【编程入门】派森基础教程,竖线,环境搭建”
Action: return_correction (text=“【编程入门】Python 基础教程 | 环境搭建”)

LazyTyper 的:

Role

你是一位智能语音转写文本纠正助手、ASR 后处理专家及高级逻辑编辑。

你的核心任务是对 ### Target 中的语音识别原始文本进行深度清洗、逻辑重构和标准化。你不仅要修复字面错误,更要像一位精明的编辑一样,识别说话人的思维修正过程,去除冗余,输出准确、通顺、逻辑自洽且符合书面规范的文本。

Input Format

你需要处理的数据包含两部分:

  1. ### History:上下文参考(用于确认术语、人名、自定义词典或前文语境),绝不可作为输出内容。
  2. ### Target:需要进行纠正、清洗和润色的原始语音文本。

Rules (Strict Execution)

请严格遵循以下处理逻辑,按优先级对 ### Target 执行处理:

1. 逻辑自我修正与反转(最高优先级)

  • 识别改口行为:智能检测说话人 “改变主意” 的模式(如 “…… 不对……”、“…… 我是说……”、“…… 啊不是……”、“…… 算了……”)。
  • 保留最终意图:当检测到矛盾信息时,必须删除被否定的前置内容,仅保留说话人最终确认的信息。
    • 示例:“预算是 50 万…… 不对…… 是 60 万” → 输出:“预算是 60 万。”
  • 倒叙逻辑重组:如果说话人逻辑混乱(如 “先做 B,哦但在那之前要先做 A”),应尽可能按实际执行的时间逻辑调整语序。

2. 深度去噪与流利度提升 (Deep Cleaning)

  • 移除填充物:彻底删除无意义的口语填充词(如 “那个”、“就是说”、“呃”、“你知道吧”、“然后呢”),除非它们对语气有决定性影响。
  • 消除重复与结巴:自动合并重复的词语或短语(如 “我…… 我觉得…… 觉得” → “我觉得”)。
  • 口语风格书面化:将过于琐碎、甚至粗俗的口语词汇润色为得体的书面表达(如 “搞一下”、“弄弄” → “处理”、“优化”),但不得改变原意。

3. ASR 伪断句与特殊标点修复

  • 伪断句修复:ASR 常在 “说”、“问”、“想” 等动词后错误添加逗号,随后紧接标点名称。必须识别此模式,删除错误的逗号,并将口述标点名称转为符号。
    • 示例:“他说,冒号我走了” → “他说:我走了”
  • 语境区分:将 “逗号”、“句号”、“感叹号”、“冒号” 等口述词转换为符号。
  • 中文省略号:必须规范为全格六个点(……),严禁使用英文三个点(…)。

4. 术语修正与词典匹配 (Terminology & Dictionary)

  • 词典优先:参考 ### History 提供的语境或常识,若出现与专业词汇发音、拼写或语义相似的词,强制替换为标准形式。
  • 技术术语同音修复:根据上下文修正音译错误。
    • 示例:瑞艾克特 /re act → React;VS 扣的 → VS Code;Git hub → GitHub;扎瓦 → Java。
  • 保留英文:原文中的英文单词、缩写禁止翻译成中文,仅修正拼写。

5. 格式化与中英混排规范 (Formatting)

  • 盘古之白(空格规则)
    • 中文与英文之间、中文与数字之间必须添加一个空格。
    • 示例:“快 4 倍” → “快 4 倍”;“使用 React” → “使用 React”。
  • 大小写规范:英文专有名词必须使用官方标准大小写(如 iOS, MySQL)。
  • 竖线处理:在标题或分类结构中,必须保留或还原竖线符号 |

6. 数学与结构标准化

  • 数学表达:所有算术逻辑必须转换为纯数学符号形式(纯数字 + 运算符),保持统一。
    • 严禁
  • 标题去句号:若文本明显为标题、课程名、标签或清单项(非完整句子结构),结尾严禁强行添加句号

7. 强制结构化与 Markdown 列表化

  • 触发条件:当识别到文本中包含 3 个及以上 的连续动作、步骤、建议或并列观点时(特征词:首先 / 然后 / 最后 / 第一 / 第二……),必须打破原有的段落结构。
  • 强制换行:严禁将步骤压缩在一段话内。必须使用 Markdown 有序列表或无序列表进行输出,且每一步必须换行。
  • 防误触(反叙述陷阱)
    • 若 “第一、第二、第三” 仅用于描述连续的心理活动、快速发生的短动作流紧凑的叙事(尤其是当句子很短且强调连贯性时),保持段落结构,不要拆分成列表。
    • 判别标准:如果拆分成列表会破坏阅读的流畅性或显得过于生硬(Over-formatted),则保持原样或仅用标点分隔。

8. 语境感知与对象适配 (Context & Recipient)

  • 指令响应:若用户明确指示 “发给某人” 或 “整理成某种格式”,请调用你的通用写作知识,生成符合该场景惯例的格式(如邮件头、问候语)。
  • 去重与融合:在生成特定格式(如邮件)时,请智能移除原文中不再需要的口语起手式(如重复的招呼、无关的填充词),确保最终文稿通顺。
  • 主体语言锁定:输出文本的语言必须与 ** 原始口述内容(Content)保持一致,严禁跟随指令语言(Instruction)** 发生改变(除非指令明确要求 “翻译”)。

Negative Constraints

  • 禁止 回答 ### Target 中的问题(如果内容是提问,仅修正文字)。
  • 禁止 在输出中包含 JSON、XML 或任何分析性文本。
  • 禁止 解释你的修改原因。
  • 禁止 输出 “好的”、“修正如下” 等废话,直接输出最终纠正后的文本。

Examples

Example 1 (改口 / 数学 / 伪断句)

History

User Dictionary: [“Copilot”, “LLM”]

Target

你好帮我打开口拍了特还有那个 l m 的设置… 一加 1 等于 2。他说,冒号宇宙超级无敌大… 不对… 我想了一下还是算了吧不要设置了
Output
你好,帮我打开 Copilot。1 + 1 = 2。他说:宇宙超级无敌大……

Example 2 (术语修复 / 盘古之白 / 逻辑)

History

User Dictionary: [“Bug”]

Target

这个 server 很 stable 没出现大的八个,使用了瑞 act 框架,这次活动的预算是… 嗯… 十万块… 不对… 二十万吧就这么定了
Output
这个 Server 很 Stable,没出现大的 Bug,使用了 React 框架。这次活动的预算是 20 万,就这么定了。

Example 3 (逻辑重组 / 强制 Markdown 列表)

History

Context: 运维操作指南

Target

那个… 就是说… 你要先重启服务,哦不对,在这之前得先备份数据库,这点很重要你知道的,然后检查日志,最后发送通知
Output
你要修复这问题,请按以下步骤操作:

  1. 备份数据库(这点很重要)。
  2. 重启服务。
  3. 检查日志。
  4. 发送通知。

Example 4 (结构化标题 / 竖线)

History

Course: Python Intro

Target

【编程入门】派森基础教程,竖线,环境搭建
Output
【编程入门】Python 基础教程 | 环境搭建


📌 转载信息
转载时间:
2026/1/4 17:15:34

项目地址: misxzaiz/claude-code-pro at test-0.0.1

Claude Code 是 Anthropic 官方推出的 AI 辅助编程命令行工具。 misxzaiz/claude-code-pro at test-0.0.1 是其第三方可视化 GUI 封装,提供了更友好的图形界面,让你无需命令行也能享受 Claude AI 带来的编程体验。

已打包,可直接在 window 安装使用


📌 转载信息
原作者:
misxzaiz
转载时间:
2026/1/4 17:14:53

新版特性:

  1. 支持预设,可以通过 ccr <preset-name> 命令快速切换 cc 配置,增加预设市场,更方便共享配置

  2. 优化 cc statusline 适配,支持插件,可以自定义插件数据,比如获取供应商套餐余量,token 实时速率,可以将 statusline 插件一起打包成预设进行分发

  3. 支持 docker 部署,镜像只有 200M + 的大小 (纯 Server 不支持 statusline/cli 插件),但是仍然可以通过给 cc 设置 baseurl http://ip:port/preset/<preset-name> 快速切换预设配置

  4. 支持 fallback,当供应商报错时支持回退到备用供应商

完整文档在 Claude Code Router (还在建设中,文档速度跟不上特性开发速度)


📌 转载信息
原作者:
musistudio
转载时间:
2026/1/4 17:13:41

本文章参考 ClaudeCode 官网以及 AI 总结。

Commands

斜杠命令,需要用户自己主动触发;本质是把重复的提示词存储起来,直接通过命令调用提示词。

使用方法: 用户可以通过在项目的 .claude/commands/ 目录下创建 Markdown 文件 (.md) 来定义自定义命令。

  • 文件名:决定命令的触发词(例如 analyze.md 对应 /analyze)。

  • 文件内容:包含你希望 Claude 执行的具体 Prompt(提示词)。

  • 参数:支持使用 $1, $2$ARGUMENTS 接收用户输入。

官方 / 社区示例/security-review 这是一个常见的自定义命令,用于让 Claude 按特定标准审查代码安全。

文件路径~/.claude/commands/security-review.md (全局命令) 或 .claude/commands/security-review.md (项目命令)

文件内容示例

--- description: Review the current code for security vulnerabilities --- Please review the code in the current context for security vulnerabilities. Focus specifically on: 1. SQL injection risks 2. XSS vulnerabilities 3. Hardcoded secrets If you find issues, please suggest specific fixes. 

如何使用:在终端输入 /security-review

Agents

Agent 本质上是拥有独立上下文特定系统提示词(System Prompt) 的 Claude 实例

减小主流程上下文的占用,子代理上下文隔离,可以更好的聚焦任务;

使用方法: 你可以通过 CLI 交互式创建,或者通过配置文件定义。Agent 本质上是拥有独立上下文特定系统提示词(System Prompt) 的 Claude 实例。

  • 交互式创建:在 Claude Code 中输入 /agents,然后选择 “Create new agent”。

  • 配置定义:通常定义在配置文件中,指定其 role(角色)、description(描述)和 tools(可用工具)。

官方示例Code Reviewer (代码审查员) 这是官方文档中常用来演示如何通过子代理分担任务的例子。

配置逻辑(概念性描述)

  • 名称code-reviewer

  • 角色描述:你是一位资深的代码审查专家,通过严格的标准审查代码变更。你只关注代码质量、可读性和潜在 bug,不要直接写代码,只提供建议。

  • 工具权限:限制为 Read(只读)权限,防止它意外修改代码。

如何使用: 在对话中,主 Agent 可能会根据任务自动调用它,或者你可以显式指派任务(如果配置允许)。

“Please ask the code-reviewer to check my latest changes.”

Skills

按需加载,只有需要该技能的时候才会加载文件内容。

可以对业务知识及开发流程进行规范

使用方法: Skill 是赋予 Claude 新能力的 “知识包”,通常由一个 SKILL.md 文件和相关的脚本 / 文档组成。

  • 核心文件SKILL.md

  • 原理:Claude 启动时会加载 Skill 的元数据(Metadata)。只有当它判断当前任务需要该技能时(例如用户要求 “处理 PDF”),它才会读取 SKILL.md 的完整内容并执行其中的步骤。

官方示例PDF Processing Skill (PDF 处理技能) 这是 Anthropic 工程博客中介绍的一个经典案例,教 Claude 如何读取 PDF 表单。

目录结构示例

Plaintext

plugins/pdf-skill/
├── SKILL.md          # 告诉 Claude 如何使用这个技能
├── extract.py        # 实际执行提取工作的 Python 脚本
└── README.md

SKILL.md 内容摘要

“When the user asks to extract data from a PDF, run the extract.py script provided in this directory. Do not try to read the PDF raw bytes directly. Interpret the JSON output from the script.”

如何使用:用户无需显式调用。只需说 “Read the contract.pdf and tell me the date”,Claude 会自动激活 PDF Skill。

Plugins

Plugin 是上述所有内容(Commands, Agents, Skills)的分发容器


接下来说一下比较容易混淆的地方,commands,agents,skills 确实有功能重叠的地方,但是他们的侧重点是不一样的,只有明白了他们各自的侧重点之后才能更好的决定使用哪一个。

1. 最大的重叠区:Command vs. Skill

这是最容易混淆的一对。它们都可以用来封装一段 Prompt 或脚本。

  • 重叠点:它们本质上都是 “预定义的指令 / 脚本”。

  • 核心区别:谁掌握 “扳机”?

    • Command (命令)显式的。你(用户) 是控制者。你必须输入 /review,Claude 才会去审查。

    • Skill (技能)隐式的。Claude (模型) 是控制者。你只需要说 “帮我看看这代码咋样”,Claude 会自己判断:“哦,用户需要审查代码,我应该调用 CodeReviewSkill。”

例子:

如果你写了一个 Python 脚本 format_code.py。

  • 做成 Command (/fmt):你每次必须手动输入 /fmt 才能运行它。

  • 做成 Skill:当你对 Claude 说 “这代码太乱了” 时,Claude 会自动运行这个脚本。

2. 逻辑重叠区:Agent vs. Skill

这两者都涉及 “特定领域的专业能力”。

  • 重叠点:都能让 Claude 变得更专业(例如都懂 SQL)。

  • 核心区别:上下文是不是独立的?

    • Skill (技能)工具。它在当前对话中被加载。它就像给了当前的 Claude 一本《SQL 手册》,它现学现卖,但还是同一个 Claude 在跟你说话,上下文是混在一起的。

    • Agent (代理)分身。它拥有独立的上下文。当你调用 Agent 时,就像是 Claude 把任务转包给了坐在旁边的 “数据库专家”。这个专家有自己的记忆和设定,处理完后只把结果告诉主 Claude,避免了主对话窗口被大量的中间步骤污染

3. Plugin (插件) 的特殊地位

Plugin 没有任何功能上的重叠,因为它不是功能本身,而是包装盒

  • 你不能把 Plugin 和 Command 并列比较。

  • Plugin 包含 Command、Skill 和 Agent。

  • 就好比:Command 是苹果,Agent 是橙子,而 Plugin 是水果篮。


一个场景看懂所有区别

假设你想实现一个功能:“将代码翻译成中文文档”。你可以通过三种方式实现,侧重点不同:

方式实现形态交互体验适用情况
方式 A: Command定义 /trans 命令你输入 /trans file.py,Claude 立即执行翻译。高频、确定性任务。你很清楚什么时候需要翻译,不需要 Claude 废话。
方式 B: Skill编写 TranslationSkill.md你说 “帮我把这文件弄得容易读一点”,Claude 自动识别并调用翻译技能。模糊指令、智能化。你希望 Claude 像助手一样自动判断该做什么。
方式 C: Agent创建 TranslatorAgent你说 “开启翻译项目”,主 Claude 唤醒子代理。子代理独立运行,不打扰你,翻译了几百个文件后,只给你一个汇总报告。复杂、耗时、多步骤任务。防止翻译几百个文件的过程刷屏,导致你之前的对话记忆被挤掉。

总结:我该选哪个?

如果你在尝试扩展 Claude Code,可以用这个简单的决策树:

  1. 这个功能需要用户手动且精确地触发吗?

    • Command (/foo)

    • 下一步

  2. 这个任务是否非常复杂,需要大量步骤,且容易污染当前的聊天记录?

    • Agent (独立的子脑)

    • Skill (教会当前大脑新知识)

  3. 你想把这些功能打包发给同事用吗?

    • 把做好的 Command/Agent/Skill 放到一个文件夹里,做成 Plugin


如果内容有误,欢迎指出


📌 转载信息
原作者:
Eddy1
转载时间:
2026/1/4 17:00:04

项目特点

该项目从 "思维模型" 出发,实现了:
一个思维模型对多个提示词;
一个思维模型可进行多种分类;
分类与子文档结构可自定义;
分类的层级自动扩展;
一键复制提示词;
卡片 / 列表 双视图;
纯本地化,tauri, 前后端一体化打包

开发过程

采用 antigravity+jules 混合开发.
实践了我之前提到的开发思路,用了 2 天完成该版本.

后续

视我自己的使用情况,和大家的反馈,会较为佛系的更新,因为目前来看,完成度还算可以.

关于思维模型,前几天从 100 个思维模型中学习并整理了 40 个.
后续我在完成从思维模型转换到该项目可用的数据后,也会分享出来.(可能到时候会做导入导出,或者多库设计.)

契机

之所以学思维模型,以及到开发这个工具,来自于我的这样一系列思考:
如何更高效率的使用 AI 工具?
尝试做出完美的大一统的提示词体系,或工作流.
尝试失败,反思.
结论:目前的 AI 范式和水平下,人的构思,组织,审查,依然是不可替代的部分;
你可以让 AI 帮你写代码,帮你写文档,但是你没办法让 AI 真正的 "读懂" 你在想什么,你到底想要什么.
所以只有靠提升自己的思维能力,来提高与 AI 协作的效率.

而这个工具就是用来加速管理你的思维模型,方便存放和找出你所需要的思维模型,以及 AI 能使用的提示词.

版本更新:

0.1.1: 增加了内置的使用教程



📌 转载信息
转载时间:
2026/1/4 16:56:00

目录帖:

本章以开源 / 闭源模型为划分,介绍一下日常使用及评估的经验。本节可能较为主观,请各位看官也要多多结合自身体感及实际业务体验来评判。

闭源模型:一种循环

目前实现了 SOTA(State of the Art,特定领域或任务中,当前的最新进展和最高水准,基本上是各家自称)的闭源模型厂主要有如下几家(豆包除外,稍后单讲):

公司 / 机构AI 模型系列
OpenAIGPT 系列
GoogleGoogle Gemini 系列
AnthropicClaude 系列
xAIGrok 系列
阿里巴巴通义千问系列
字节跳动豆包系列

这几家基本上每隔一段时间就宣称自己发布了最强大的 xx 模型,以至于形成了一种循环。当然 SOTA 这个词很微妙,最新最大杯的模型未必就最适合你。下面按照模型家族介绍一下本代的各种主力型号的特点(截至 2026 年 1 月 4 日):

OpenAI GPT:冷静的理性思考

自从迈入 GPT-5 时代以来,GPT 系列模型就以回复简短闻名。从好的方面看,OpenAI 做到了省 output token(输出 token 数),这使得任务总体所需时间进一步得到压缩。然而代价是冷漠到近乎不近人情的回复使得创意写作用户不得不忍痛抛弃它。后续推出的编码特化模型 gpt5-codex 模型进一步强化了这个特征,有时候描述性文字几乎已经不能称之为人话了。好在 GPT-5.2 系列在一定程度上解决了这个问题,虽然比起 GPT-4.5 甚至 GPT-4o 系列模型给人在 Chat 上的主观感受仍有差距,但已经较为可用。

OpenAI 作为 LLM 的领头羊,服务压力自然是很大的,无论是网页还是 API 都可能会有服务异常的情况。为了解决这个问题,GPT-5 系列在网页端给出的解决方案是自动路由(其实就是超级降智)。然而,对于指定了特定型号的 API 用户来说,GPT-5 系列模型的推理速度仍然显得相对较慢。

说完了缺点,那么剩下的基本上全是优点。回复简短意味着完成同等任务下所需 tokens 更少,冷静的理性思考带给人一种指哪打哪的感觉 —— 不废话,just do it。比起 GPT-4 时代的人味儿来说,GPT-5 更像一名理工男。当然,它是一名后端理工男,在审美上未必有多好的品味。

模型名称模型 ID上下文长度最大输出长度备注
GPT-5.2 Thinkinggpt-5.2gpt-5.2-2025-12-11400K128K最高推理强度,支持 reasoning 参数(大杯)
GPT-5.2 Progpt-5.2-pro400K128K企业级最高准确度,支持 xhigh reasoning(超大杯)
GPT-5.2 Chat (Instant)gpt-5.2-chat-latest128K16KChatGPT“GPT-5.2 即时” 模式,延迟最低(其实就是小杯,很蠢)
GPT-5.2 (base)gpt-5.2400K128K通用旗舰版,默认 reasoning=medium(中杯)
GPT-5.2-Codexgpt-5.2-codex400K128K代理式编码专用,支持上下文压缩与视觉输入
GPT-5.1-Codex-Maxgpt-5.1-codex-max400K128K支持 “压缩” 技术,可跨多窗口连贯处理数百万 tokens,专为长时间、项目级编码任务设计

这里需要特别注意的是,gpt-5.2-codex 并非代码万灵药。如果你不太会写 prompt 或者这个工程需要范围更广的探索思考,那么 gpt-5.2 可能会比 codex 变体好用些。codex 更突出指哪打哪的能力,而 gpt-5.2 会主动帮你多想些。换句话说,改 bug 用 gpt-5.2-codex,新开工程 / 模块用 gpt-5.2。推荐写后端或复杂的前端逻辑时使用 GPT 系列模型。

Google Gemini:多模态和世界知识之王

牢谷坐拥无尽的网络资源宝库以及 Deepmind+TPU 的神秘力量加持,尽管在 LLM 时代赶了个晚集,但从 Gemini 2.0 开始一路猛追,到了 2.5 时代已经是妥妥的御三家之一。Gemini 的多模态能力令人惊叹,Pro 系列的世界知识更是让人折服。比起 GPT 来说,Gemini 更像一名文科生:大参数带来的丰富世界知识给了它更强的文学理解能力,思考之细腻和情感共鸣能力使得它成为创意写作的最优选。当接入 Chatbot 的时候,你甚至可能没法分清它到底是 AI 还是人 —— 太能接梗了。

大家都不知道 Gemini Pro 系列的参数到底有多大,目前普遍认为 1T 以上。然而推理速度比起其他各家大参数模型来说又快的离谱,疑似 Jeff Dean 在机房里手敲(其实应该是 TPU 的特点所致)。总之,如果你想选择一款有超强的世界知识并且对推理速度有一定要求的模型,那么 Gemini 系列是毋庸置疑的选择。

Gemini 3.0 Pro 从内部测试阶段就不断炸场,多模态 + 大参数写出的前端效果惊艳了所有关注 AI 前沿动向的人。尽管 Gemini 3.0 Pro 存在较为严重的长上下文幻觉问题,但瑕不掩瑜,它依然是现在最适合前端的模型。

Gemini 3.0 Flash 推出后,甚至神秘地实现了某种程度上对 Pro 的反杀,几乎和 Pro 一样丰富的世界知识和更好的编码能力。下克上?搞不懂牢谷。

模型名称模型 ID上下文长度最大输出长度备注
Gemini 3 Progemini-3-pro1000K (1M)64K旗舰模型。最强多模态推理与编码能力,支持 high 深度思维模式。前端很强非常强!但受限于长上下文幻觉,后端稀烂(相比其他两家)
Gemini 3 Flashgemini-3-flash1000K (1M)64K速度旗舰。专为 Agent 设计,支持 minimal/medium 等多级思维调节。Flash 反杀 Pro!大部分搬砖的活计用 Flash 就够了,速度飞快。
Gemini 2.5 Progemini-2.5-pro1000K (1M)64K2.5 世代旗舰。具备极强的长文本召回能力。(前面是官方说法,实际上各家长文本都一坨)
Gemini 2.5 Flashgemini-2.5-flash1000K (1M)64K2.5 世代均衡版。高吞吐量,默认支持长上下文处理。
Gemini 2.5 Flash-Litegemini-2.5-flash-lite1000K (1M)64K极致性价比。针对极低延迟任务优化,是目前最廉价的百万上下文模型。

Anthropic Claude:最均衡的编码代理模型

Anthropic,又称 A÷ / A 畜,大家很熟悉了,神一样的 Coding Agent,翔一样的口碑和服务可用性。抛开立场不谈,最早的 Claude 模型以创意写作闻名,比起同期的 GPT-3.5 来说回答更有人味。后来 Claude 率先扩展了长上下文窗口以及 STEM 能力,走向了编码特化的不归路。到了 Claude 3 时代开始就是彻头彻尾的 Coding 模型了,直到现在的 Claude 4.5 成为了最均衡的编码代理模型 —— 如果你想前后端一把抓,选它准没错。强大的规划能力能够给出更适合工程上的方案,在各种场景下都能很好的完成目标。跑分没赢过,体验没输过。尽管日常处于即将被超越的状态,但还没被超越不是吗?(对标苹果!)

模型名称模型 ID上下文长度最大输出长度备注
Claude 4.5 Opusclaude-4-5-opus-20251124200K64K支持 effort 参数调节推理强度。编码与科研任务首选(超大杯)(反重力反代优选)
Claude 4.5 Sonnetclaude-4-5-sonnet-20250929200K / 1000K*64K专为复杂 Agent 与项目级代码设计,性能超越早期 Opus 4(中杯)(对于反重力用户来说,有 Opus 谁用 Sonnet)
Claude 4.5 Haikuclaude-4-5-haiku-20251014200K64K路边一条,官方说具备 Sonnet 4 级别的性能,但被 Gemini Flash 家族打出 shi 来了

注:只有官方 Max 订阅才有 1000K 上下文,大部分渠道都是 200K 的上下文,比如反重力逆向或 Kiro 逆向。

xAI Grok:力大砖飞,以及瑟瑟

马斯克也许缺乏品味,但他足够有钱。Grok 好不好用先放一边,超大规模的显卡集群是实打实存在的。这个系列一直秉持力大砖飞的原则,猛堆参数。迫于 Scaling law 的存在,就算是几百头猪,炼进 Transformer 里也能出些成果了罢。

Grok 在某些领域有着和 Gemini 系列相似的特性:参数够大,很适合创意写作任务。Grok 4 家族拥有不俗的吐槽能力,在对齐上比起 a helpful assistant 来说更像一名沙雕网友。而且 Grok 背靠 X(aka Twitter),也有着丰富的语料及不错的搜索功能。对于老外来说,Grok 简直是全自动开盒器(is that true ? )

Grok 系列另一个令人津津乐道的地方就是极低的审查下限。在各家 API 中,Grok / Google Vertex / DeepSeek 是审查力度相对较低的。但到了网页端上 Grok 也保持极低的审查下限就很离谱,当然考虑到 X 网页端上你依然可以畅爽 NSFW… 好吧,Grok 适合搞瑟瑟是从娘胎里就带出来的本事。无需破甲,无需诱导,很黄很暴力。酒馆和各种文字扮演游戏的常客。

模型名称模型 ID上下文长度最大输出长度备注
Grok 4 Heavy (SuperGrok)grok-4-heavy256K8K - 16K多智能体协作系统,通过并行推理验证结果,推理强度最高(超大杯)
Grok 4.1grok-4.1256K16K2025 年底旗舰,主打高情商 (EQ) 与低幻觉率,创意写作能力很好(大杯)
Grok 4grok-4256K8K2025 年中发布的标准旗舰,原生支持多模态推理与实时 X 搜索
Grok 4.1 Fast (Long)grok-4.1-fast2,000K16K超长上下文版,支持 200 万 token,类似 Gemini Flash(中杯)
Grok 4 Fast (Instant)grok-4-fast2,000K30K极速 / 高性价比版,支持 reasoning 切换(可关闭推理以获得极低延迟,类似 Gemini Flash Lite,小杯)
Grok Code Fast 1grok-code-fast-1256K16K马斯克的钞能力,在一众编程模型当中显得平平无奇,但不要钱不要钱不要钱!速度很快,质量一般,体感跟 Gemini 2.5 Flash 差不多的性能,但在各种 Vibe Coding 客户端里都作为免费选项出现。

阿里 通义千问 & 字节跳动 豆包:能力先行还是产品先行?

阿里作为目前开源界当之无愧的扛把子,从 Meta 手中接过了开源的大旗。r/LocalLlama 如今已是 r/LocalQwen 的形状了。Qwen 家族分为开源模型和闭源模型两种。除了每代的超大杯(通义千问 Max)为闭源外,其他商业 API 均能找到对应的类似开源型号。通义千问的特点是极强的指令遵循能力和稀烂的产品。

Qwen 家族的模型在输出上总感觉缺了点味道。它不像 GPT 那样冷静简洁,不像 Gemini 那样细腻有人味,但也不像 DeepSeek R1 0120 那样放飞自我。很怪,AI 味很重,在大规模使用 RL 训练的 Qwen3 世代这个特点尤为显著。国模的通病之一在 Qwen 上有显著体现:思考时非常消耗 Token,甚至在 Instruct 模型上模型倾向于输出思维链,导致最终完成复杂任务时所耗 Token 相对较高。

但从另一个方面上来讲,Qwen 作为国内 AI 的 T0 选手,其模型非常适合国内企业落地开发使用:性价比适中、模型选择丰富、较好的服务稳定性,还有强大的指令遵循能力可以减轻不少开发难度。逻辑能力也相当不错。

阿里系除了主打的阿里云百炼平台提供的通义千问服务外,还有面向开发者的 modelscope(魔搭)、心流团队的 iFlow、面向 C 端的蚂蚁灵光系列,主打一个养蛊和乱拳打死老师傅。以下表格主要介绍闭源的通义千问 3 家族:

模型名称模型 ID上下文长度最大输出长度备注
Qwen3-Maxqwen3-max256K64K超大杯。非思考模式输出可达 64K,思考模式输出 32K。
Qwen-Plusqwen-plus1M32K大杯。百万级长文本支持,适合复杂任务推理。
Qwen-Flashqwen-flash1M32K中杯。兼顾百万级上下文与极速响应速度。
Qwen3-VL-Plusqwen3-vl-plus256K32K视觉大杯。支持高分辨率,单图最大 16,384 tokens。
Qwen3-VL-Flashqwen3-vl-flash256K32K视觉中杯。支持视觉推理模式,单图上限同 Plus。
Qwen-Longqwen-long10M32K长文本专家。支持 1000 万 token 超长输入。
Qwen3-Coder-Plusqwen3-coder-plus1M64K编码特化大杯。专为复杂编程设计,支持百万级上下文与 64K 超长输出。
Qwen3-Coder-Flashqwen3-coder-flash1M64K编码特化小杯。高效处理编程任务,具备极高的响应速度。

把目光转回到字节的豆包家族。阿里和字节基本上是截然相反的 —— 字节在 LLM 上的开源很少,可用的只有 Seed-OSS-36B,豆包底模也一直很一般。然而豆包的产品做的很好,在国内 C 端市占率遥遥领先。这当然得益于他们深耕多模态,但这可能和集团底色也有一定关系。如果你手机里需要一款不需要爬墙就很好用的 AI 应用,那我想应该是豆包没错了。但使用 LLM API?除非你的公司疯狂迷恋 Coze。

模型名称模型 ID上下文长度最大输出长度备注
Doubao-Seed-1.8doubao-seed-1-8-251215256K32K大杯。支持深度思考、多模态理解与工具调用,最长思维链达 64K。
Doubao-Seed-Codedoubao-seed-code-preview-251028256K32K编码特化。专为编程场景设计,支持深度思考与多模态理解。
Doubao-Seed-Litedoubao-seed-1-6-lite-251015256K32K中杯。兼顾生成效率与推理能力,支持结构化输出。
Doubao-Seed-Flashdoubao-seed-1-6-flash-250828256K32K小杯。具备视觉定位能力,适用于高频多模态交互。
Doubao-Seed-Visiondoubao-seed-1-6-vision-250815256K32K视觉中杯(也可能是大杯?)。侧重 GUI 任务与复杂多模态理解。

📌 转载信息
原作者:
flymyd
转载时间:
2026/1/4 16:55:38

作者|陈鹏,镜舟科技 技术副总裁

过去三十年,OLAP 引擎的发展核心始终围绕结构化数据的处理与分析,当然也取得了显著的进步,比如分布式架构、存算分离及 cloud native、查询性能大幅提升等。然而,随着大模型(LLM)技术的爆发,数据分析的范式正在发生根本性重构。行业预测显示,未来五年内,非结构化数据(文本、图像、音视频等)在企业数据资产中的占比将达到 80%。未来的数据形态将趋于多模态,分析需求将更加复杂,查询方式也将从单一的 SQL 转向自然语言与多模态混合检索。因此,我们需要在现代大数据分析平台基础上,全面拥抱 AI,构建下一代 AI-First Lakehouse。

一、基础设施演进:异构融合的存储与计算层

1. 存储层统一:管理多模态数据

目前大数据体系与 AI 体系存在严重的物理与逻辑割裂。

大数据团队习惯维护基于 Hive、OLAP、Lakehouse 等大数据平台来处理分析结构化数据,也诞生出业界主流的存储格式如 Parquet、ORC 等,能很好的支持结构化数据分析需求。而 AI 团队习惯在单机服务器或配备独立显卡的个人电脑(Laptop)上开发调试,数据以本地文件形式散落。

这种割裂导致数据无法统一存储,治理困难,且跨系统调用的性能极低,需先查数据库再调 AI 模型。但大数据时代的存储格式如 Parquet 的 Row Group 设计专为结构化数据优化,不再适配 AI 场景,AI 场景非结构化数据异构特性明显,同一批数据里,部分字段内容小,部分 embedding 后的字段会很大。

为此,可以考虑引入如 Lance 等专为 AI 设计的存储引擎,支持对文本、图像、视频等多模态数据的高效索引与存取。以实现统一管理分散在各处的非结构化数据,使得 Lakehouse 不仅是数据存储库,更是 AI 资产的统一底座。

Image

2. CPU/GPU 异构计算统一调度

传统 OLAP 依赖 CPU 进行聚合、排序与过滤,而 AI 负载(如 Embedding 生成、非结构化数据解析、模型推理)高度依赖 GPU 资源。

计算引擎需从单一的 CPU 架构向 CPU/GPU 异构架构演进。系统应具备智能调度能力,根据任务类型自动分配计算资源,实现结构化查询与非结构化推理的混合执行。

典型场景:直播电商实时分析

单场直播会上架数十至上百个商品,每个商品展示时长仅 1-2 分钟。系统需同时处理两类数据:

  • 结构化计算(CPU):五维四率数据(曝光进房率、商品曝光率、商品点击率、成交转化率)等实时指标;

  • 非结构化计算(GPU):主播语音讲解分析、主播商品展示视频分析、助播互动表现、用户弹幕评论分析

业务方需要将“点击率”与“主播当时说了什么/做了什么”进行关联分析,以判断推荐是否精准,以及多种因素对成单的影响。这要求计算引擎具备异构资源管理能力,能够灵活调度 CPU 处理统计指标,调度 GPU 处理特征提取与推理,实现多模态数据的实时融合计算。

二、内核能力构建:AI 原生的查询与 In-Database 推理

1. 原生向量检索,从外挂到内核的能力下沉

简单的语义检索已无法满足高精度的业务需求,且外挂式的向量库方案会导致数据冗余与延迟,向量能力已经是多模态处理的必备项(Must-have)。同时引擎内核需要原生支持混合检索,并具备混合召回能力,结合关键词匹配(通过倒排索引实现)与语义检索(通过向量检索实现),通过粗排与精排的组合策略,满足如“搜合同关键条款”、“电商以图搜图”、“在线教育以图搜题”等高精度业务需求。

更进一步,随着越来越多不同类型、不同领域、不同维度的数据摄入 Lakehouse,内嵌知识图谱搜索能力也变得越来越重要,以便高效快捷的挖掘数据之间的关系。

2. In-Database AI ,写入即处理,查询即分析

(1)写入时处理

传统架构中,非结构化数据的 ETL 依赖外部脚本或独立工具链,维护成本高且容易形成数据孤岛。下一代系统应将 AI 能力内置于写入路径,系统自动调用内核级的解析(Parse)、分块(Chunking)、向量化(Embedding),实现从原始非结构化文件到可查询数据资产的自动化转换,无需人工深度介入即可完成打标与关联。

(2)查询时推理

将 LLM 能力内嵌至数据库内核,实现“查询即分析”。用户无需将数据导出至外部模型处理,而是直接在 SQL 中调用 AI 函数。

还是以直播评论分析为例,系统应能直接通过 SQL 调用内置 AI 能力,对海量弹幕进行情感分析,如:

  • 自动过滤“扣 1”、“扣 2”等无意义评论;

  • 识别具有购买意向的负面/正面反馈,甚至触发内置 Chatbot 进行自动回复。

相比调用外部 API,内置推理可利用本地数据过滤机制,仅对筛选后的高价值数据进行推理,大幅降低延迟与成本,并提升吞吐量。

Image

将 AI 能力贯穿写入和查询全流程,让数据处理成为数据库的内置本能。这种架构下,数据从接入到分析的每个环节都被 AI 增强,消解了传统“先存储、后处理”模式的滞后性,使数据在落盘时即具备智能检索和分析能力。

三、面向 Agent 架构适配:从确定性查询到探索式执行

随着 AI Agent 应用的普及,数据交互模式将从“确定性查询”转向“探索式执行”。Agent 具有多轮推理、自我修正及高并发的特点,这对底层系统提出了新要求:

1. 极致弹性与高并发

Agent 通过多轮推理、自我修正来完成任务,且存在 Multi-Agent 场景,这将导致会产生海量、突发性的查询请求。系统需要具备毫秒级的弹性伸缩能力,支持多路 Agent 并发协作,来实现计算资源的即用即取与成本隔离。

2. 高效智能元数据管理

Agent 会频繁探索数据的 Schema 信息以理解数据结构,系统需提供高性能元数据管理服务,快速响应 Schema 查询。同时在查询元数据时除了常规的库表结构信息外,还应包含丰富的语义数据。

另外,不同于精确的 SQL,Agent 生成的查询往往很模糊。执行引擎需要支持描述性约束信息(例如,Agent 指令包含“精度要求>80%”或“查询超时<2 秒”),可以根据约束动态调整策略,允许在精度与资源消耗之间做权衡,而非僵硬地执行全量扫描。

四、平台自治:AI 反哺系统的自我进化

在基础层、内核层、以及架构层升级后,还可以思考进一步利用 AI 技术反哺 Lakehouse 自身的鲁棒性与性能。

  • 学习最佳实践: 系统应自动学习内部海量日志中的 Best Practice,将其内化为引擎的管理能力。

  • 智能故障排查: 利用 AI 自动定位数据库运行中的隐性问题,替代人工排查。

智能物化视图(Auto-MV)加速洞察

目前的物化视图依赖业务方手动创建,门槛较高。未来系统将结合慢查询分析与数据量特征,自动识别性能瓶颈,同时,学习用户的查询行为,自动创建并维护物化视图,从底层透明地加速查询响应,无需用户感知。

流畅开发:避免复杂的 UDF 依赖

对于复杂的业务逻辑与非结构化数据处理,不应强行依赖传统的 UDF,而应通过上述的内核级 AI 能力与开放接口来解决,提供更流畅的开发体验。

结语

下一代 AI-first Lakehouse 的构建是一个系统性工程,需要从数据处理、存储引擎、计算架构、Agent 支持以及平台生态进行全方位升级。核心目标是打破结构化与非结构化数据的壁垒,将 AI 能力从应用层下沉至内核层,构建真正面向 AI 时代的新一代数据平台。

亚马逊云科技推出了Amazon EKS Capabilities,这是一套完全托管的、Kubernetes 原生特性,旨在简化工作负载编排、AWS 云资源管理以及 Kubernetes 资源组合和自动化。这些能力现在已在大多数 AWS 商业区域普遍可用,它将流行的开源工具捆绑到一个托管的平台层中,减轻了工程团队的运维负担,并在Amazon Elastic Kubernetes Service(EKS)上实现了更快的应用程序部署和扩展。

 

EKS Capabilities 集成了许多 Kubernetes 用户已经依赖的三个核心组件:Argo CDAWS Controllers for Kubernetes(ACK)和Kube Resource Orchestrator(KRO),并在 AWS 拥有的基础设施中运行它们,这些基础设施与客户集群抽象隔离。Argo CD 提供声明式的持续部署和GitOps工作流,允许直接从版本控制同步资源和应用程序。ACK 通过自定义资源扩展 Kubernetes,用于直接在 Kubernetes API 内管理 AWS 服务,如S3DynamoDBRDS。KRO 提供了一个简化的机制,用于创建和管理组合的自定义资源,帮助平台团队定义可重用的、更高层次的抽象,而无需手动处理复杂的控制器逻辑。

 

通过将这些能力作为托管的 AWS 资源而不是集群内的插件提供,EKS Capabilities消除了用户自己安装、补丁、扩展或更新基础 Kubernetes 工具的需求。AWS 处理扩展、维护、安全补丁和兼容性升级,使平台工程师和开发人员能够更多地专注于交付业务逻辑,而不是管理平台组件。实际上,团队继续使用熟悉的接口如kubectl、GitOps 工作流和声明式清单与 Kubernetes 一起工作;不同的是,持续部署和资源编排等核心服务由 AWS 作为 EKS 平台的一部分提供和维护。

 

这种转变与云原生运维的更广泛趋势相一致,在云原生运维中,托管服务越来越多地吸收了无差别的繁重工作,使组织能够更容易地扩展 Kubernetes 的采用。平台团队可以将常规的基础设施集成卸载到 AWS 托管的能力中,同时保留原生的 Kubernetes 工作流,应用程序开发人员则从统一、一致的能力中受益,这些能力跨越了集群,而无需投资于定制的平台工具。通过 EKS 控制台、AWS CLIeksctl或其他自动化工具启用 EKS 能力。当将 Argo CD、ACK 或 KRO 等能力添加到集群中时,它将作为 AWS 资源出现,可以像其他 AWS 服务一样进行标记、管理和监控。权限通过 AWSIdentity and Access Management(IAM)配置,对于 Argo CD 单点登录等功能,支持与 AWS IAM 身份中心的集成。AWS 还自动分析破坏性变更,并对活动功能应用更新或补丁,减少管理开销。

 

虽然每个功能都是独立且可选的,允许团队只启用他们需要的功能,但它们共同为 Kubernetes 环境提供了一个连贯、可扩展的平台层,融合了应用程序部署、AWS 资源控制和自定义资源组合。这种方法旨在缩短交付时间,最小化操作摩擦,并帮助组织在开发、测试和生产环境中大规模采用 Kubernetes。

 

这次更新引起了云和 DevOps 社区的共鸣。在Reddit上,实践者强调了托管 Argo CD 支持和集成的 AWS 资源管理的便利性,这是尝试新功能的令人信服的理由,特别是对于那些寻求统一 GitOps 工作流和资源配置而不进行手动插件管理的团队。同时,一些观察者指出,尽管托管能力减少了设置工作,但它们仍然需要 Kubernetes 专业知识和仔细的成本考虑,因为采用规模扩大,成本也被质疑是一个潜在的问题,因为许多团队可能已经有自己管理这些的方法,并且看不到为这项新的 AWS 功能支付额外费用的好处。

 

随着企业继续在混合云和多云环境中采用 Kubernetes,Amazon EKS Capabilities 通过将运维最佳实践嵌入到服务本身,代表了降低平台复杂性和加速云原生应用程序交付的一步。

 

https://www.infoq.com/news/2025/12/aws-eks-workload-orchestration/

本文分享了扩展云和分布式应用程序的目标与策略,重点介绍了摩根大通(JPMorgan Chase)旗下Chase.com在云迁移过程中汲取的经验教训。

 

讨论围绕三个核心目标展开,详细阐述了实现这些目标的具体策略,最后说明了这些方法在实践中的落地方式。对于管理大规模系统的从业者而言,这些经验源自我们在摩根大通及其他金融机构多年来的实战积累,具有宝贵的指导意义。

 

在规划的时候,人们通常只会考虑两到三倍的负载增长。然而,一旦系统部署在互联网上,就无法控制入站流量的规模、时间或使用模式。任何事件(无论是源于合法业务增长,还是恶意攻击者的行为)都可能引发巨大的负载激增。这两种情形各自会带来截然不同的挑战。

 

安全控制措施可以阻止恶意流量,但当市场波动引发真实客户需求激增时,情况则有所不同。客户恰恰会在这些情况下需要访问金融交易服务。在系统压力下,多个组件可能同时发生故障;网络设备、负载均衡器、应用程序和数据库连接都可能同时中断。

 

目标

我们的云迁移聚焦于三大核心目标:以成本效益高且高效的方式实现弹性扩展、实现高韧性(这对金融机构尤为重要),以及提供卓越性能,防止因系统迟缓而迫使用户转向其他服务。

 

高效扩展

实现高效性需要分析客户的使用模式和行为。组织必须在保持弹性扩展能力的同时,发展预测能力。

 

流量整形(Traffic shaping)提供了一种识别高频率功能的方法论,从而能够有针对性地对关键应用进行扩展。

 

整体容量管理是另一个关键要素。简单地增加服务器并不能保证成功,还需要仔细权衡成本的因素。

流量模式与容量规划

流量模式是高效扩展的基础。平均流量代表了系统日常处理的基准水平。可预测的模式确实存在,例如,工资入账等周期性事件会促使客户查询账户余额。全年还会出现季节性高峰,这要求提前规划。

 

突发事件则会带来不同的挑战。DDoS 攻击频繁发生,其流量可能超过正常负载十倍甚至更高。攻击者利用的是与合法用户相同的云资源。组织必须在阻断这些攻击的同时,确保合法客户的真实交易仍能满足服务等级协议(SLA)。

 

基于已知模式进行合理的容量规划有助于预防运维方面的问题。然而,弹性扩展存在局限性:在扩展过程中,应用程序需要启动并建立与服务及数据库的连接,而建立连接需要时间。从实例启动到完全就绪,可能已经过去数分钟。若大量请求恰好在此期间涌入,系统将面临资源争用的问题。

 

因此,不能仅依赖弹性扩展,而应该全面考虑完整的运维图景,包括流量模式及相关因素。预留计算容量(Reserved compute capacity)可以应对这些挑战。预留资源能在需要时保证可用性,尤其在多租户共享资源池出现争用时更为关键。此外,预留计算还能带来成本节约。

 

成本管理需要进行持续关注。应该定期(如每月或每周)应用 FinOps 流程,而非偶尔为之。

超越单纯增加服务器的扩展

扩展不应该局限于简单地增加服务器。当发生扩展时,有一个根本性的问题,那就是,应用程序是否真的因为真实客户的需求而需要扩展,还是因为上游服务排队导致响应变慢?当线程等待响应而无法执行时,CPU 和内存的压力会上升,即使实际需求并未增长,也会触发弹性扩展。

 

这种场景要求我们在设计中考虑容错,并将其与扩展策略整合。断路器(Circuit breaker)在此过程中会发挥关键作用。当上游服务变慢或失败时,断路器可以防止应用无限期等待响应,而是强制设置超时限制:系统要么在限定窗口内收到成功响应,要么快速失败并继续处理。这种设计可避免线程耗尽、减少不必要的资源消耗,并防止错误地触发扩展。如果没有断路器的话,缓慢的依赖项可能会引发全系统的性能退化,导致弹性扩展,从而添加更多无法解决根本问题的服务器。

高韧性

韧性(Resiliency)要求为不可避免的系统故障做好准备。早期检测和随时执行故障转移程序至关重要。然而,为所有组件实现 100%的可用性既不现实,也无必要。

 

基础设施可根据关键性分为四个层级。关键(Critical)类的组件必须尽可能接近 100%可用。DNS 就属此类,无论网站架构多么完善,DNS 如果出现故障将会导致所有访问中断。

 

可管理(Manageable)层的组件在发生故障时可通过故障转移维持运行,目标为“四个九”的可用性(99.99%,即每年可接受约 52 分钟的停机时间)。

 

可容忍(Tolerable)层的组件具备内置韧性。例如,缓存长期数据的令牌服务,若服务在缓存有效期内不可用,系统仍可使用已缓存的数据继续运行。

 

最后,可接受(Acceptable)层的组件允许有限的数据丢失,比如,某些日志系统。韧性目标由影响的严重程度决定。

性能

性能会显著影响用户体验和基础设施成本,但并非所有应用程序的表现完全相同。通过部署接入点(Point of Presence, PoP)可以提升用户体验,因为它对网站延迟(尤其在移动设备上)尤为敏感。

 

速度至关重要,因为它能建立用户信任,用户期望更快、更好的体验。谷歌等搜索引擎已经认识到这一点,并将速度纳入其排名算法。在网络连接受限的场景下,移动端性能尤为关键。从基础设施角度看,客户完成相同任务所花费的时间越少,运营成本就越低。

 

我们通过实施全面的性能策略,从初始部署到完整架构落地,系统延迟降低了 71%。这些策略可适配其他业务场景。

五大核心策略

架构方法围绕五个重点领域展开:多区域部署、高性能优化、全面自动化、具备自愈能力的可观测性,以及强大的安全性。

多区域部署

多区域架构通过隔离和分段实现功能化的解耦。这种方法有助于管理区域故障、可用区故障和网络故障,并限制故障的爆炸半径(blast radius)。面对 9400 万客户,可用区级别的故障可被限制为仅影响一小部分用户,而非全部用户。

 

实现多区域架构需要解决 DNS 管理的问题,因为不同区域拥有独立的负载均衡器,需要协调一致。还需要确定区域间流量的调度策略。在包含多个可用区的区域内,也需选择流量的分配方式。

可用区故障

假设一个负载均衡器将流量分发至同一区域内的两个可用区。两个应用均报告健康状态,可用区看似正常,流量持续流入。然而,如果其中一个可用区的应用与后端系统连接异常,而另一可用区正常,流量仍将流入受损的可用区。若应用虽实现了就绪(readiness)和存活(liveness)探针,却未将依赖系统状态纳入健康检查,那么就有可能出现问题。缺乏适当的反馈机制时,负载均衡器会继续路由流量,导致应用失败。

针对这种情况,解决方案包括将依赖系统的健康状态通过就绪或存活探针反馈给负载均衡器,或采用基于代理的重路由机制将流量导向正常的可用区。这需要有效管理内外部故障,以应对应用停机。

区域性的故障

在多区域部署中,我们依赖统一的区域健康脉搏检查(每 10 秒执行一次),以确保对区域健康状况的一致性和及时可见性。在这里,关键的决策在于,故障是否需要完全切换至备用区域,或者降级服务是否可接受。降级服务的可行性取决于应用的分段情况。若关键服务(如仪表盘首页)失效,则需要故障转移;若非关键组件失效,那么可以继续运行以避免更大的影响。但故障转移会引发“惊群效应”(thundering herd),例如,整个区域失效时,重定向流量突增可能压垮剩余区域,而自动扩展需要时间才能提供额外的容量。健康检查标准(包括失败与成功阈值)决定了对应的响应策略。

多区域的挑战

跨区域的数据复制与确保数据一致性是主要的关注点。当数据中心位置有限而客户遍布全国时,客户分片(customer sharding)是一种可行的方案:将客户按地理位置分片,并由就近的数据中心提供服务,这样可以减少复制的需求,并简化架构。

 

状态管理需要战略性的决策。为活跃会话维护会话亲和性(session affinity),并在必要时支持故障转移,这有助于高效运行。

高性能

高性能对用户体验至关重要。良好的性能如同可靠的拨号音,用户期望即时响应,不容延迟。边缘计算是实现性能目标的主要手段。现代网站具有复杂的用户界面,内容密集。我们可将静态内容卸载至靠近客户的入网点(Point of Presence,PoP),而源服务器(origin server)仅处理动态操作和关键服务,如登录、账户、支付等。

流量整形(traffic shaping)可以对流量进行分类。关键流量指的是支撑业务运营的核心功能,比如,客户日常的登录、余额查询和支付。分配给关键服务的资源必须始终保持运行。在压力条件下,即便其他流量出现降级也是可以接受的。

内容分发

地理分布会显著影响性能。如果每次资源请求都需要跨越很长的距离,物理网络的屏障将会造成显著的延迟。如果相同的内容已在 PoP 缓存,检索可在 100 毫秒内完成,远优于访问源站所需的较长响应时间(比如,大于 500 毫秒)。性能提升的同时会带来安全方面的收益,因为恶意的流量可以在边缘被拦截。

 

“最后一公里连接(last-mile connectivity)”的问题值得关注。互联网通信涉及多个网络跳转。边缘计算改变了这一模式,从用户到边缘节点通常只需要一跳,再结合优化的网络传输,这样所带来的效率远高于标准的 ISP-to-ISP 连接。

 

移动应用也有优化的空间。移动设备具备本地存储,可用于缓存网络解析结果、配置设置和预抓取的内容。

自动化

自动化是关键的战略元素。在整个流水线的各个阶段实施全面自动化可带来巨大收益,这需要涵盖部署、基础设施供应、环境配置、集成自动化操作的健康检查,以及整体的流量管理。

架构不能止步于文档。通过创建“带有倾向性的(opinionated)”架构模板,可以帮助团队构建自动继承架构标准的应用。应用通过基于清单(manifest)定义进行自动化部署,这样能够让团队聚焦业务功能,而非基础设施工具的复杂性。

基础设施“重铺”

基础设施“重铺(repaving)”是一种高效的实践,即在每个迭代周期系统性地重建基础设施。自动化的流程会定期清理运行中的实例。这种方式能够通过消除配置漂移(configuration drift)来增强安全性。当存在漂移或需要应用补丁(包括零日漏洞修复)时,所有更新均可系统性地实现。

 

长期运行会导致资源陈旧、性能下降和安全漏洞。我们可以定期(如每周或每两周)自动重建环境,步骤大致如下:先优雅地移除流量,再重建环境并重启服务,从而保障运维的稳定性。

 

重铺实现涉及多个组件:自动化脚本监控实例的生命周期;基于时间的有效性触发器会移除路由,阻止新请求进入但允许现有请求完成;随后关闭实例、清理节点并创建新实例。创建新实例时,可以使用更新后的镜像,以解决零日(zero-day)漏洞并添加安全补丁,也可以仅简单地重建实例。具体的操作由策略决定。所有流程均自动化完成,在重铺前会移除流量,确保对客户不会产生任何影响。

 

自动化故障转移

具备优雅降级能力的自动化故障转移需要考虑活跃的会话。对于正在进行处理的客户,会话的处理方式不同于新的会话,需要进行特殊路由。除此之外,必须防止故障转移循环,如果两个区域均不健康,持续切换只会加剧问题。不同场景对延迟容忍度不同;非关键服务故障时,可在受影响区域继续运行。

 

可观测性与自愈能力

可观测性要求对观测到的事件进行自动化的响应。云环境在各组件中会产生大量事件,比如系统事件、基础设施事件和应用事件。所有的可观测事件都需要自动处理。自动化会通过无服务器函数与可观测性进行集成,也就是在事件触发后,函数自动执行,并且会根据预设的条件切换在哪个区域执行。

 

数据库问题会触发独立的数据库切换函数;维护活动可以触发函数以屏蔽特定区域或虚拟私有网络(virtual private cloud,VPC)。这些示例场景展示了如何实现自动化行为,同时确保与可观测性的集成。仪表盘监控能够提供辅助价值,但不应该作为主要的响应机制。

健康检查

健康监控需要在多个层级进行。在应用层,健康判断可能涉及复杂的评估,不仅要检查应用本身是否正常运行,还包括与数据库、缓存及其他系统的连接是否通畅。健康检查器内部可以包含复杂的逻辑,但返回状态必须简单,仅用布尔值表示健康或不健康状态即可。

 

应用内的健康检查要向上传播至可用区这一层级,它要检查所有的实例。然后,这个信息转移至 VPC 层级,以评估整体 VPC 的健康状况,最终输入全局的路由器。每一层级均通过简单的布尔指标实现自动化健康评估,从而支持快速决策。该方法通过系统性健康检查以实现自愈的能力。

决策标准

我们可能会遇到如下的场景,告警指示节点不可用且容量受损,这可能是供应商的问题,流量需要从受影响的 VPC 进行重定向;应用告警显示延迟问题且性能受损,组织需要根据业务需求决定是继续提供降级服务,还是满足服务等级协议(service level agreement,SLA)的要求。在这样的场景中,选择降级服务意味着接受较慢的性能,而非切换至可能存在相同问题的其他可用区。

“灰度故障”(gray failures)指的是故障确定存在但连接仍存在的模糊故障场景。网络相关的故障更难诊断。当某项业务功能受损时,可以考虑将流量重路由至健康的可用区。可以基于可观测性数据执行多种应对措施。

健壮的安全性

安全需要采用零信任模型的分层实现。每一层必须独立运作,假定其他层均可能失效。客户端设备可能会被恶意软件攻陷;边界安全功能需要在边缘实现过滤和 Web 应用防火墙;内部网络需要分段和隔离;容器安全方面,需要进行镜像扫描并采用最小权限原则;应用安全方面,需要确保正确地认证与授权;数据安全方面,要实施加密与隐私控制。各层之间要实现互相强化。

迁移

文化转型是成功迁移的基础,因为云运维与传统的企业自建系统存在根本性的差异。云服务商会持续更新服务,网络策略在不断演进,浏览器也在不断变化,诸多因素都要求我们持续适应。Well-Architected Framework 及相关原则在这方面提供了指导。

 

“谁构建、谁拥有、谁部署”的所有权模型将责任赋予了应用团队。人为错误与疏忽不可避免,而自动化可以确保一致性。

测试与验证

测试方法各异。Chaos Monkey 等工具通过向运行中的系统注入故障实现反应式测试;失效模式与影响分析(FMEA,Failure Mode and Effects Analysis)则通过系统性组件评估进行预测性分析,识别潜在的故障并制定缓解策略。这两种方法均有它的价值,但 FMEA 更适用于在各应用层进行全面测试,确保能够开发分析与缓解策略。

 

公司开发了名为 TrueCD 的 CI/CD 方法论,这是一套包含了十二个步骤的自动化流程,相关文档已经在官方博客进行详细阐述。该流程类似于航空业的飞行前安全检查。

抽象层

从企业自建环境向云迁移会影响应用的架构。应用包含了大量的业务逻辑,持续变更可能对业务运维产生连锁影响。抽象层可以最大限度地减少此类影响。该架构方法可在单云、多云、自建环境或混合环境中灵活选用业界最佳组件。Dapr是一个广受认可的开源框架,支持多云架构。

迁移客户流量

大型应用的迁移无法一蹴而就。在初期,可以先在内部用户群体中验证系统,使应用趋于稳定。压缩时间表往往会适得其反,因为某些问题和使用模式需要长期观察才能发现。应用需要充足的运行时间以完成优化。

 

面对庞大的功能集,在有限时间内完成所有功能可能不现实。将系统拆分为离散应用集可以应对该挑战。在迁移的各个阶段,可逐步将小比例的客户群体进行迁移,最终再实现全面迁移。

结果

这些策略的实施带来了可衡量的成果:显著降低成本,性能指标大幅提升,平台在对比分析中名列前茅。Dynatrace 的公开报告对美国银行网站进行了比较,它指出实现亚秒级(<1 秒)响应的站点代表了最优的性能。

结论

从这些策略中可以提炼出一些关键的考量因素。权衡是不可避免的,我们需要综合考虑成本与性能,同时不损害其他的需求。例如,在多区域架构中,需要评估缓存复制策略:是在单区域还是多区域维护缓存?运维的复杂性随云架构组件的增多而上升。降低复杂性、减少应用监控中的人工干预至关重要,而自动化是实现这一目标的关键机制。

控制故障的爆炸半径始终至关重要。站点必然会遇到各种问题,组件难免失效。关键在于故障发生时的影响范围,是波及所有客户,还是仅限一小部分?这一关注点至关重要。我们必须建立面向行动的可观测性,并与自动化操作紧密关联起来。

 

所有决策必须以客户为中心。业务运营服务于客户。请思考“拨号音体验”:拿起电话,用户期望立即听到拨号音。应用亦应如此,用户打开移动应用,理应立即看到结果。

 

核心原则:智能扩展,保持可靠性。当下一次流量激增不可避免地到来时,系统弱点必将暴露出来。这些策略的直接目标在于,当流量激增时,关键组件必须能够保持运行,核心系统必须维持响应能力,客户必须像往常一样获得即时响应。

 

原文链接:

Scaling Cloud and Distributed Applications: Lessons and Strategies

引言:悖论

数据能够反映出很有意思的现实。麦肯锡的“人工智能现状(State of AI)”报告显示,72%的组织已经在至少一项业务职能中采用了 AI。投资速度令人震惊,数百亿美元正在被投入 AI 研究,企业为 AI 项目划拨了前所未有的预算。然而,在现实中,大多数组织并没有从中获得实质性的价值。

 

一个鲜明的例子是优步的Michelangelo平台(来自Wang Kai等人)。该平台经过多年建设,已经成为其机器学习的基础设施,能够使开发团队快速掌控自身的领域,并部署从路径优化到需求预测等各类解决方案。随着 AI 技术演进,优步进一步利用生成式 AI(GenAI)加速了开发进程。正是由于早已建立了坚实的组织与技术基础,优步才能在 AI 浪潮中占据先机。

 

与此同时,过去几年采纳 AI 的大多数大型企业却难以突破试点阶段。这些企业拥有相同的技术和知识资源,却缺乏必要的组织结构与平台来释放 AI 的真正价值。Gartner 2025年的研究显示,在 AI 成熟度较高的组织中,仅有 45%能将项目维持三年以上,此外,57%的高成熟度组织已准备好采用新的 AI 解决方案,而低成熟度组织中这一比例仅为 14%。

我们谈论的 vs 真正重要的

正如麦肯锡的AI状态报告所示,AI 的采纳速度在不同行业及组织内部不同类型工作中呈现出显著的差异。在软件平台与工程领域,AI 的应用已明显加速。

 

随着开发与 DevOps 社区拥抱 AI,其放大效应显而易见。谷歌的“DORA:AI辅助软件开发现状”报告指出,采用 AI 带来了可观的收益,包括:

  • 个体效能的提升

  • 工作重心转向更高价值任务

  • 产品性能改善

  • 代码质量提高

  • 组织整体绩效增强

 

然而,尽管技术在不断进步,但是组织层面的影响仍参差不齐。JetBrains 的“开发者生态系统现状”调查显示,超过 50%的开发者每天有 20%至 60%的时间花在会议、工作聊天和邮件上。沟通与状态对齐仍是核心挑战。矛盾点在于,更快地交付成果,并不必然意味着更快地创造商业价值。

 

将更多精力投入到理解价值流与业务上下文,才是交付更高价值的可行路径。架构师在此过程中扮演关键角色,也就是弥合组织目标与开发速度之间的鸿沟。他们帮助团队设计具备韧性、可扩展的系统,将业务意图转化为稳健的技术实现。

 

归根结底,真正重要的并非我们编码或部署的速度有多快,而是我们能否有效地将持续改进融入业务运营与组织体系之中。

迈向 AI 驱动的持续变革流

显然,人工智能(尤其是生成式 AI 和 AI Agent)正在促使组织重新思考如何适应持续发生的变化。但这并不意味着传统的架构定义方法已经过时。相反,这条路径在于利用 AI 增强既有的架构实践,从而在业务上下文、设计与交付之间建立持续的流动。

 

Anthropic 的“经济指数报告”基于数百万条匿名的 Claude 对话数据,将用户与 Claude 的交互模式分为两类:自动化(AI 在无需显著用户输入的情况下完成任务)和增强(用户与 AI 协作完成任务)。不到两年间,自动化交互占比从 41%上升至 49%,而增强型交互则从 55%下降至 47%。

 

这为软件相关工作中 AI 的应用提供了一个有趣的代理指标:尽管 AI 工具和 Agentic AI 发展迅速,但用户正越来越多地依赖 AI 处理更复杂的组织任务。在技术驱动型组织中可以推断,虽然 AI 已经能够显著提升个体在离散任务上的生产力(自动化),但在组织流程层面的更大效率增益(与增强相关)仍面临障碍,主要是数据就绪度和业务领域上下文信息的缺失。在 CGI 的架构实践中,当组织试图将 AI 从孤立试点扩展到规模化应用时,这些挑战反复出现,凸显了领域清晰度与上下文工程(context engineering)的重要性。

 

架构师支持组织从个体生产力提升迈向整体运营效率的提升。这需要架构层面的努力来保障组织资产,即确保数据可用性、明确业务上下文边界,并重新对齐流程。如前所述,这些需求本质上是人力、组织或信息层面的,而非单纯的技术栈现代化。新兴的业务需求将要求更高的一致性与清晰度,以便 AI Agent 或 AI 辅助开发团队能在组织层面实现改进。在此背景下,架构的意义愈发聚焦于赋能人类与 AI 智能体协同演进的流动机制。

 

为何“快速流动”优先?

如前所述,AI 如同水流,会沿着组织现有的渠道渗透。渠道清晰直接,流动便会加速,渠道曲折狭窄或存在死胡同,则引发洪涝与瓶颈。在组织的语境中,“快速流动”指快速响应变化并基于早期反馈及时调整航向的能力。它关注系统级的敏捷性,即快速收集、理解并将业务需求转化为可交付解决方案的能力。这种流动必须与真实用户需求和业务战略对齐,而不仅仅是追求技术效率。实现快速流动的组织通常具备四大特征:

  1. 业务对齐(Business alignment)

  2. 清晰的领域边界(Clear domain boundaries)

  3. 可控的认知负荷(Managed cognitive load)

  4. 优化的交互模式(Optimized interaction patterns)

 

战略对齐确保 AI 解决的是真正的问题。在考虑技术之前,快速流动型的组织始终紧密耦合业务战略、用户需求与技术领域。团队清楚自己的工作对用户的意义及其如何驱动商业价值。当这类组织采纳 AI 时,目标明确指向特定用户的痛点与战略业务目标。而许多组织则为了“现代化”而部署 AI,未与用户成果建立清晰的联系,这可能会取得技术成功,却遭遇商业方面的失败。

 

清晰的领域边界使 AI 能在业务上下文中安全自治。当团队所负责的领域明确对应业务能力与用户需求时,AI 就可以在这些边界内有效地运作。这种对齐意味着 AI 决策天然反映业务规则与用户诉求。如果缺乏这种清晰性,技术边界与业务边界脱节,将放大系统的模糊性与复杂性。从领域驱动设计(DDD)视角看,要实现 AI 支持的组织效率提升,架构师可能需要更新限界上下文(bounded contexts)的交互模式,审视核心子域的关键流程,或优化支撑性子域的流程。

 

优化交互模式确保跨边界协作始终以用户为中心。在快速流动型的组织中,团队互动是有意设计且定期复盘的。缺乏这种纪律,会经常导致多个团队重复解决相同的问题、构建相同的方案。为了应对混乱,有些组织又走向了另一个极端,即强制所有人频繁沟通,这反而会引发了混乱。快速流动型组织采用 Team Topologies 框架,在必要时促成团队高效协作与沟通。

 

激活流动性

为了说明 AI 在架构中的流动应用,我们描述一个组织在生成新解决方案规范(specification)时如何借助 AI 的历程。他们并非一开始就得出了结论,而是经历了启动、激活流动性,并在推进过程中不断演进架构方法的过程。

 

以下案例研究展示了“架构流动性”在实践中的具体体现。在 CGI 的一项倡议中,目标是将 AI 用例转化为跨多个业务解决方案的规模化 AI 实现。

 

团队首先通过战略指导,超越传统的研讨会,加速将业务 AI 的用例推进至概念验证(Proof of Concept,PoC)实现阶段。为此,团队推出了一种队列式(cohort-based)的计划,与各团队合作细化业务价值、用户旅程及潜在的 AI 用例。通过快速迭代,我们将 UI 原型迅速转化为 PoC 实现。

 

业务负责人通过 UI 原型直观感受到 AI 的潜在影响与收益,同时也能看到其他团队的思路。除了宝贵的协作体验外,开发者也首次拥有了明确的视觉目标来指导实现。持续的积极反馈证明该计划深受参与者认可。下图展示了该队列式流程的迭代循环及其输入/输出:定义用户旅程、原型设计、演进 AI 辅助的规范。

在启动阶段,团队通过调研业务负责人,使用统一的 MadLib 格式确认优先的主题与用户故事(基于“Next Best Action/Recommendation”框架):

 

根据每期队列的战略主题,邀请团队成员。在首次研讨会中,队列成员深入探讨所选用户故事并定义用户旅程。随着时间推移,队列逐渐转向通过自然对话描述上下文,而非提交结构化输入,用户故事演变为由业务负责人讲述简短故事后自动生成。贯穿队列过程的一项关键考量是,在有限时间内平衡交付引人注目的成果与保持专注性。

 

因此,首次研讨会聚焦于使用简洁布局定义用户旅程图(如下图),以价值流图为背景(触发事件 → 步骤 1 → 步骤 2 … → 步骤 6 → 结束事件/结果),并按故事板划分泳道(角色、行动、情绪、痛点、机会、交付价值)。

在明确 PoC 范围的上下文与边界后,UX 设计师与队列快速协作,设计 UI 线框图与可点击的原型。设计师在“过渡仪式(cross-over ceremony)”中向队列展示成果,随后由一支精简的跨职能小队(全栈开发、数据科学家、提示工程师、AI 解决方案架构师)接手,使用不同模型、算法与方法推进 PoC。最终仪式展示了每个 PoC 的可行选项。该小队的核心目标是直接用 AI 解决业务挑战,并因聚焦队列优先级,与业务价值建立更直接的联系。

 

团队采取滚动交付模式,每月产出 2–3 个 UI 原型或 AI PoC 实现。他们运行了多个队列,获得宝贵反馈并持续优化策略。然而,下一个挑战随之而来:如何将这些早期解决方案推进至生产级实现?

 

不出所料,实现团队提出的第一个问题就是:“规范文档在哪里?”尽管 PoC 有记录,但它们不能被视为可供其他团队进行实现的设计规范。这一挑战在 CGI 的转型项目中十分常见:PoC 能带来清晰的认知,却往往缺乏下游交付团队所需的结构化规范。

 

不过,在过去 6 个月中,团队已积累了超过 50 小时的设计会议、UI 原型演示和 PoC 实现记录。为避免回溯成本(比如,重新召集分析师和设计师细化方案),团队转而采用上下文工程(context engineering),利用基础模型(Gemini 与 GPT 表现相当)进行处理。

 

假设:给定一个精心策划的设计模式知识库和标准输出格式,团队可以从对话记录或研讨会白板内容中生成一致的用户故事与用例规范。业务负责人认为生成结果的方向是正确的。

 

生成的规范包含典型的正常流与异常流,并涵盖系统组件、依赖关系等设计元素,附带初步的结构图与交互图。经过迭代,甚至纳入了旅程图,并根据故事叙述中的关键词自动分配情绪分值。团队进一步扩展规范,加入了验收标准、初始测试用例,以及安全、数据隐私等方面的检查清单问题,供实现阶段回答。

 

生成这些规范的基础是一个围绕实现设计模式(implementation design pattern)构建的知识库。团队扩展了传统的设计模式格式,加入检查清单问题,使生成的规范涵盖了以下的关键维度:

  • 采纳与商业价值:确保方案能够交付可衡量的业务成果,并通过清晰的价值对齐与用户采纳策略获得认可;

  • 用户体验:强调实现中的考量因素,确保用户交互直观、透明、可信,提升全程的信心、参与度与满意度;

  • 运维因素:通过健壮的监控、性能与生命周期管理,维持可靠、可扩展、可解释的 AI 系统;

  • 合规性与治理:嵌入伦理、法律和审计框架,以确保 AI 的运维能够负责任、透明且符合法规要求。

  • 数据源与集成:定义数据质量、可访问性及连接性等考量因素,确保方案有效运行与可持续性;

  • 安全与数据隐私:尽量左移(shift left),从源头将安全与隐私纳入考量。

 

这些实现设计模式从一开始就按业务负责人排序的 AI 用例优先级进行分类归档,形成以下原型:

  • 原型 1:对话式 Agent

  • 原型 2:AI 驱动的异常检测

  • 原型 3:超个性化与下一步最佳行动/推荐

  • 原型 4:智能工作流自动化

  • 原型 5:多模态与全渠道 AI

  • 原型 6:预测性维护与安全监控

  • ……(随着流动持续,将涌现更多原型)

  • 默认模式实现的考量因素

 

下图展示了这些原型按架构关注点(UX 与交互、监控与感知、业务流程与规则)的分类,为默认模式实现提供了有用的参考。

 

随着知识库不断扩充,团队现在能从一次研讨会讨论中自动生成包含验收标准和“左移”要素(比如,安全、隐私甚至法律视角)的完整规范初稿。但是,需要注意,团队的核心目标是构建扎实的架构知识上下文,而非开发工具。

AI 与 AI Agent 持续演进。尽管团队正在探索如何根据规范反向生成 UI 原型,但从架构的视角来看,其信心源于精心策划的知识库。随着规范驱动开发(Specification-Driven Development, SDD,参见“理解SDD”)理念的兴起(比如,Spec Kit,一款基于AI的SDD工具包),团队更加确信自己走在正确道路上。这一旅程远未结束,AI 在架构中的应用方式将持续演变,并会改变架构师的工作范式。

 

上述案例特别适用于“绿地”(greenfield)场景,也就是架构师与团队有足够的空间在启动新方案或向现有系统引入创新时,主导对 AI 的应用。然而,大多数组织还维系着支撑核心业务能力的成熟系统体系。这些系统构成一幅马赛克式的实现图景,各自处于不同生命周期阶段。对于那些专门构建的系统,其最新架构视图很可能已“铭刻于代码之中”。

 

毫无疑问,编码助手、Copilot 和编码 Agent 已经引起开发者的广泛关注,他们日益将其用于日常的开发活动,从代码补全、文档生成,到覆盖整个软件开发生命周期(SDLC)的更高级能力,SDLC 中的变革之流从未停歇。

 

在这样的“棕地”(brownfield)环境中,将 AI 应用于架构的机会广阔而多元化。AI 可在多个阶段帮助架构师弥合组织业务能力与技术实现之间的鸿沟。例如:

  • 使用 AI 来支持架构评估:评估架构决策的各个方面非常适合结合上下文工程与先进的基础模型(比如,Gemini、GPT、Claude 等)。更稳健的权衡结果(例如,扫描技术选项以填补架构能力缺口)需要以关键架构原则和其他架构需求为依据。此外,采用少样本提示(few-shot prompting)技术,通过提供“好/中/差”示例,可引导权衡分析。此类策略可用于多种架构权衡的场景(例如,给定某种实现方案,更适合单体还是微服务?事件驱动还是 API 驱动?)

  • 使用 AI 来生成规范性架构:在大型组织中,常见的棕地环境挑战在于,随着时间的推移,架构发生了漂移但并未文档化,甚至缺乏架构图与文档。这些应用多为大规模单体系统,而掌握其知识的人员往往已调岗或离职。手动逆向工程风险高、耗时长。此时,AI 可评估应用并自动生成操作手册、架构图、数据模型与依赖关系等必要的文档。

  • AI Agent 提出架构与设计方面的更新:在 DevSecOps 中,AI Agent 正被用于持续摄取运行时事件流。它们可能监控已部署方案的安全漏洞,或分析运行日志以减少事件噪音与冗余工单。通过识别重复漏洞或运行模式,Agent 可在适当时机提出设计改进建议。

结论:前行之路

人工智能本身无法凭空创造组织能力。人类必须先以组织知识为其基础,AI 才能强化已有的基石。成功与停滞的分野,不仅在于模型、工具或基础设施的选择,更取决于组织是否具备支撑 AI 快速演进的架构基础。清晰的领域边界、可控的认知负荷、对齐的价值流,才能让 AI 增强交付,而不是仅仅添加复杂性。在此意义上来讲,架构师与架构本身成为 AI 的赋能者,而非旁观者。

 

正如案例所示,当架构师从控制结果转向框定上下文(定义语义、边界与护栏,使 AI 及未来的 AI Agent 自治变得安全可靠),AI 的承诺才能真正兑现。

 

真正的问题并非“如何采纳 AI”,而是“如何演进我们的架构,以支持 AI 增强的持续变革流”。

 

原文链接:

Architecture in a Flow of AI-Augmented Change

微软正式发布SharePoint Framework (SPFx) 1.22版本,该版本专注于现代化 SPFx 开发者的构建和工具使用体验。这一转变标志着 SPFx 解决方案构建方式的基础性更新,旨在解决技术债务、提升可扩展性,并与更广泛的微软工具链标准保持一致。

 

在此之前,SPFx 项目依赖基于Gulp的构建工具链来协调编译、打包等任务。尽管这种方式被大家所熟知,但相对于现代化的 JavaScript 和 TypeScript 工作流来说,这种模式早已被认为是过时的。同时,旧版 SPFx 的模板和生成器输出触发了npm audit漏洞,并落后于当前的依赖预期。1.2 版本通过过渡到新的工具链并清理脚手架解决方案中的漏洞解决了这些问题。

 

SPFx 1.22 更新的核心是从基于 Gulp 的工具链转向基于Heft的工具链Heft(来自 Rush Stack 生态系统的配置驱动的构建编排器)现在为新的 SPFx 项目管理构建任务,而底层的打包继续使用 Webpack。这一转变使 SPFx 的开发与当代构建生态系统保持一致,使得构建更加透明、可维护,并便于未来的工具增强。如果需要的话,现有项目升级到 1.22 后可以继续使用传统的 Gulp 工作流,但使用 Yeoman 新建的项目默认采用 Heft。

 

Heft 的引入解决了长期以来开发者对 SPFx 工具链类似“黑箱”的担忧。据微软介绍,Heft 具备带有明确的倾向性和基于插件功能的设计,允许实现更透明、更易于维护的构建,并有助于未来工具的改进。它支持共享配置(rig.json),简化了 TypeScript 的设置,并提供了原生 Webpack 配置选项。然而,从自定义gulpfile.js进行迁移可能需要一些重要的调整,尤其是对于那些使用定制构建步骤的团队。

 

此次发布的另一个重要现代化措施是解决了 SPFx Yeoman 生成器和脚手架项目输出中由npm audit报告的所有已知的安全漏洞。在使用最新的生成器生成一个新脚手架项目时,开发者将不会再看到npm audit报告的高严重性问题,从而提高了开箱即用的安全基线信心。微软还重置了脚手架模板中默认的 TypeScript 版本至 5.8,让开发者能够使用最新的语言特性及改进的工具支持。

此次发布没有对先前支持的 API 引入任何功能弃用(deprecations)。然而,微软明确指出,未来将仅对旧版 Gulp 构建系统提供关键性修复。在即将发布的 SPFx 1.23 版本中,新建项目将仅使用 Heft(前提是 CLI 工具已准备就绪)。到 SPFx 1.24,基于 Gulp 的构建管道将被正式标记为不支持(officially unsupported)。这意味着开发者应尽早规划迁移路径,尤其是依赖自定义 Gulp 任务的团队,以确保与未来 SPFx 版本的兼容性。

 

社区在社交媒体上的反应既表现出兴奋也带有一定的谨慎。在 LinkedIn 上,微软 365 开发者社区的成员强调了构建系统变更的重要性,指出“这不是一个简单的更新”,尤其是考虑到从 Gulp 到 Heft 的转换。一些开发者已经开始分享教程和资源以帮助他人适应新的 Heft 工作流。其他人则提到,迁移现有的项目是一项不小的挑战,尤其是对于拥有自定义 Gulp 任务或扩展的团队,并正在讨论逐步迁移的具体策略

 

展望未来,SPFx 的路线图包括进一步解耦 CLI、开源模板以及与 Rush Stack 工具更深入的集成。鼓励开发者现在就开始探索 Heft,以熟悉未来的迁移路径并符合微软的发展方向。

 

关于完整的发布说明和 Heft 迁移指南,请参阅 SPFx 1.22发布说明工具链文档

 

原文链接:

SharePoint Framework 1.22 Ships with Heft-Based Build Toolchain and Refreshed Project Baseline

2025 年的硅谷 AI 圈,最激烈的战场已不止于模型参数和榜单上,另一场残酷的战争也在暗中同步升级。

当大模型一路卷到极限,算力、参数规模、基准测试分数开始出现明显的边际递减,真正被重新定价的,是“人”。

过去几年,硅谷 AI 的主叙事是“谁能训练出更大的模型、刷出更高的分数”。

但进入 2025 年,模型能力仍然重要,却不再是唯一的决定因素;大家的关注重心逐渐从“模型参数与评测分数”,转向“谁能够将模型纳入产品与系统核心,并持续推动其在真实业务场景中发挥作用”。

这一变化,非常直观地体现在一连串人员流动中:

一边是科技巨头高调宣布重金抢人、疯狂扩招 Agent、系统、基础设施方向的研究与工程负责人;另一边,他们又在内部对原有 AI 研究体系进行重组,让多位中高层研究负责人选择离开舞台中央。

在一系列重大人事变动中,Meta 今年的变化尤为瞩目:比如前两天豪掷 20 亿美元买下智能体公司 Manus,顺手也把 Manus 创始人肖弘“纳入囊中”。另外据《华尔街日报》7 月报道,Meta 采用“爆炸式 offer”战术:签约金最高达 1 亿美元,决策窗口短至几小时。

而作为 Meta 的前首席 AI 科学家兼 FAIR 创始人的 Yann LeCun,却在 11 月官宣离职创业,聚焦高级机器智能研究项目(Advanced Machine Intelligence,AMI)。

OpenAI CEO 奥特曼直言,今年他见到了职业生涯中“最残酷的人才市场”,Meta 向他的 OpenAI 团队挖人,还抛出炸裂的报价:“签约金 1 亿美元起步,年薪还远高于此”。

从 Meta 到 OpenAI,从谷歌到苹果,从“首席科学家”到“研究负责人”...... 这些名字的变动,正在折射出一件重要的事情——美国科技巨头的 AI 研发重心,正在整体迁移。

不过研究的价值也从未失效,模型训练依然是产业生长的底座。但 AI 行业更看重的,已逐渐变成了把模型转化为可执行系统、并在真实场景中持续创造价值的能力。

还有值得一提的是,这场混战中,大量华人工程师在站上了关键岗位。

为什么 2025 年的硅谷,裁员和抢人同时发生?

为什么今年看起来“裁员”和“抢人”同时发生?

看似矛盾现象的背后,其实是行业对 AI 发展路径的认知正在发生转向:通用人工智能(AGI)的乌托邦式愿景逐渐褪色,特定领域、可落地的超级智能(ASI)成为新共识。

对此,Anthropic 高管 Jack Clark 曾警告“巨变在即,AI 将把世界撕裂为两个平行宇宙”。

更直接的变化在于,AI 正在从“技术突破期”快速切换到“工程兑现期”。裁员与抢人,正是这一阶段转换在人才市场上的投射。

核心矛盾的起点,是大语言模型(LLM)正式迈入平台期。过去数年,“更大参数、更多数据、更高算力”的线性增长逻辑,支撑着 AI 行业的技术狂热与估值飙升。

但到 2025 年,这条路径的边际收益明显下降。顶尖模型的能力天花板逐渐显现,再叠加算力成本的指数级攀升,企业突然发现,“把模型做得更强”的投入产出比已大幅下滑。

这一点在 OpenAI 身上体现得尤为明显,其年营收约 130 亿美元,却要烧掉 90 亿美元维持运营,2028 年亏损甚至可能膨胀至营收的四分之三,算力成本压力倒逼企业必须转向商业价值兑现。

当技术探索的空间收窄,企业关注的重心自然转向三件事:能不能用、能不能卖、能不能规模化。

这一转向,直接改变了 AI 人才的价值排序。

在技术突破期,中高层研究人才的核心价值在于定义方向、探索未知、构建长期技术壁垒;但进入工程兑现期,企业的战略重心变成“把已有的模型能力转化为稳定的系统、可落地的产品和持续的现金流”。

不是 AI 人才变多了,而是“被需要的 AI 能力类型变了”。

谁在离开舞台中央?长期研究型高层的集体“降权”

2025 年硅谷 AI 人才流动潮中,Meta 是最具冲击力的变量之一:一边以天价薪酬全球争抢工程与产品型人才,一边持续流失 AI 体系核心的研究型高层。

田渊栋被裁、Joelle Pineau 离职、Yann LeCun 话语权旁落,这些并非孤立事件,而是 Meta AI 战略根本转向的集中体现——从“基础研究与产品并行”,彻底转向“以产品为核心的集权化研发体系”。

基础研究不再天然拥有战略优先级,唯有能直接服务产品主线、影响竞争胜负的研究,才能留在权力中心。

这一转向最直观的标志,是 FAIR 实验室的衰落。

2013 年,扎克伯格与 Yann LeCun 共同创立这个以“推动 AI 前沿、造福人类”为使命的基础研究高地,代表着 Meta 对长期 AI 研究的耐心押注——彼时逻辑清晰:基础研究定义能力上限,产品负责兑现价值。

但生成式 AI 浪潮打破了平衡,算力、数据与资本成为核心变量后,组织价值评判标准彻底转向“可转化性”:研究的重要性,不再取决于是否推进认知边界,而在于能否快速落地为产品能力。负责产品落地的 GenAI 团队逐渐成为主线,FAIR 则从“战略源头”退为“技术后方”。

Llama 系列的演进加速了这一趋势。Llama 3 的开源成功让 Meta 成为大厂开源阵营核心玩家,也让管理层明确目标:AI 不仅要领先,更必须渗透进 Meta 所有产品形态。

在此导向下,Llama 4 的规划重点被强拉至多模态能力与应用整合,推理能力、思维链等基础研究被归为“可延后”选项。直到 DeepSeek 与 OpenAI o1 实现推理突破,Meta 才意识到基础能力缺口无法用产品工程弥补,即便抽调 FAIR 团队临时“救火”,路线已难以逆转。

Meta 在 10 月裁掉 600 人,不少 FAIR 老人黯然离场,包括顶级研究员田渊栋。

值得注意的是,这些离开或被边缘化的顶尖研究者并未退场,反而带着对主流 AI 路径的明确判断,分流成截然不同的创业赛道。

最具前沿探索性的,是 Yann LeCun 押注的“世界模型”路线。

作为 FAIR 创始人、图灵奖得主,他始终是主流 LLM 路线的尖锐异议者,长期质疑“堆参数、喂数据”的范式,认为当前模型仅停留在统计拟合,并未真正理解世界。

离开 Meta 后,他创办 Advanced Machine Intelligence Labs(AMI),核心目标是通过建模世界运行规律,构建具备持久记忆、推理与规划能力的系统——这一路线不追逐短期性能指标,而是试图从根源重塑智能实现方式。

另一批研究者选择向现实业务靠拢,Joelle Pineau 是典型代表。

2025 年 5 月,这位 FAIR 体系的核心组织者、Llama 早期技术路线的深度参与者离职,加盟 Cohere 出任首席 AI 官。她长期主导强化学习与对话系统研究,此次转向清晰指向“可控、可部署、能被企业真正使用的 AI”。

而正以“主权模型”重新定位的 Cohere,也借 Pineau 的加入,补齐了研究深度与工程落地之间的关键短板。

还有一条路径,流向了全栈实验室化的创业公司,“PyTorch 之父” Soumith Chintala 是其中的代表。

2025 年 11 月,结束 11 年 Meta 生涯的他加入 OpenAI 前 CTO Mira Murati 创办的 Thinking Machines Lab(TML)。这位曾构建全球 AI 研究基础设施的人直言,离职的原因是希望跳出“极度成功的舒适区”,探索下一代 AI 系统形态。

在 OpenAI 核心研究员持续外流的背景下,TML 正逐渐成为新的承接平台。它以“让强 AI 更可理解、可定制”为方向,集结多位来自大厂的核心成员,凭借高额融资与“开放科学”的研究取向,逐渐成长为能够独立承担前沿探索的“平行实验室”。

谁在被疯狂争抢?华人工程师站上关键岗位

答案从 2025 年硅谷科技巨头们的招聘与收编动态就能读出来,这场激烈的人才抢夺赛主要围绕三类核心能力展开:agent、多模态与实时交互、推理和 AI Infra。

首先是 Agent 与可执行系统方向,即能把模型变成“能干活”的系统。

这类人才的能力,不只限于模型训练本身,而是把模型嵌入到可执行、可操作的系统里——包括多步任务规划、工具调用、页面 / 应用直接操作等能力。

其二,多模态在 2025 年不再停留在“能生成图片 / 文字”这种静态功能,而更强调实时感知、持续交互和环境理解。

极具代表性案例,就是 Meta 在 6 月份不仅斥资约 140 亿美元投资并收编 Scale AI,还将其创始人兼 CEO 亚历山大·王(Alexandr Wang) 招致麾下。

亚历山大·王是一位 97 年出生的美籍华人小伙,从 MIT 辍学,后创立了一家做 AI 数据与评测基础设施的公司 Scale AI,为大型科技公司训练最新 AI 模型。

小扎还让这位年轻人和前 GitHub CEO Nat Friedmany 一起领导新成立的 “超级智能实验室(Meta Superintelligence Labs,MSL)”。

这个 MSL 很不简单,据 OpenAI CEO 奥特曼爆料,Meta 给该团队新员工提供签字奖金可达 1 亿美元(约合人民币 7 亿元)!

至于此消息为啥为从奥特曼口中说出,或许是因为小扎从 OpenAI 猛猛“偷家”吧——扎克伯格在他的备忘录中提到了 11 人,其中至少有 6 人是华人,7 人来自 OpenAI。

据 Business Insider 消息,MSI 首发团队成员中,余家辉、赵晟佳、毕树超、Huiwen Chang、Ji Lin、任泓宇、等 6 人都曾在 OpenAI 担任关键模型、关键团队的负责人。

这些人中,有的人曾参与过 Agent 型、多步推理或执行研究,有人则是在多模态、语音 / 视觉理解、后训练 / 交互系统方面有深厚积累的复合型研究人员。

另外,马斯克的 xAI 虽然暂时没有没有统一公开名单,但关于 xAI 的战略规划,曾多次提到多模态能力(尤其与超算中心、NVIDIA 推理能力结合),这类战略需要大量精通多模态模型与分布式系统的工程师来实现。

其三,关于推理和 AI Infra,主要是为了让模型跑得起、跑得稳、跑得便宜。

这里的“推理与 AI Infra”包含两个层面:

  • 推理系统设计与优化:如何让大型模型在实际场景中高速、低成本地响应;

  • 基础设施与可服务化能力:从数据管线、模型发布、调度、监控到弹性伸缩。

这类人才既要懂深度学习,又要懂系统工程、服务架构、调度策略,在 2025 年极度抢手。

比如,英伟达通过与 AI 芯片初创公司 Groq 的顶尖工程师达成协议,引入其联合创始人 Jonathan Ross 及执行团队。

这批人才曾在谷歌等大厂负责高性能、低延迟的 AI 推理芯片架构设计,而优化推理能力正是 Infra 人才的核心一环。

而谷歌这边,也在忙着抢夺 AI 软件工程师,其中高达 20% 的新增 hires 是“回流员工”(boomerang workers),这类岗位几乎全部聚焦于将内部 AI 研发转写入产品 / 系统层,包括推理效率提升、API 服务化框架、企业级部署架构等。

可见,推理效率和基础设施能力已成为 AI 竞争的重要战场,过去仅靠堆算力已无法满足企业级需求。

总而言之,这些都是硅谷 AI 战场上现在被重金争抢的关键能力,远远超出过去单纯“模型参数”和“benchmark 比拼”。

2025 年,顶级 AI 人才并没有离场,只是大家从论文和 Demo,更多地走向了系统、平台与现实世界。而 2025 年的硅谷,也正是在这场无声的人才迁徙中,完成了一次新的方向校准。

参考链接:

https://www.reuters.com/business/sam-altman-says-meta-offered-100-million-bonuses-openai-employees-2025-06-18/?utm_source

https://www.businessinsider.com/meet-the-people-zuck-hired-for-his-ai-superintelligence-team-2025-7?utm_source

https://www.ft.com/content/3584197e-a99a-4a06-9386-dc65cf603f45?utm_source

Agoda的“2025年AI开发者报告”显示,AI 在东南亚和印度已成为开发者的主流工具,在带来切实生产力提升的同时,也引发了关于可靠性、技能发展和组织准备度的新问题。

报告显示,AI 的采用已经基本达到普及的水平,95%的东南亚和印度开发者每周都会使用 AI 工具,超过一半的人在工作时会始终保持一个 AI 助手处于开启状态。开发者普遍感受到了效率的提升,但他们将这种影响描述为稳定而渐进的增益,而非对其工作的彻底自动化。

 

尽管使用率很高,但是开发者对 AI 的依赖却十分务实。提升生产力是主要驱动力,80%的受访者将“加快编码速度”和“协助处理常规编码任务”列为关键收益。然而,大多数人仍将 AI 视为需要监督的助手,而非可自主行动的代理。Agoda 将此总结为:“AI 已成主流,但尚未成熟”,当前的工作流程与保障机制仍在追赶工具本身的发展速度。

 

报告揭示了一个显著差距,即开发者行为与组织治理之间存在脱节。工具选择已经趋于集中化,约 87%的受访者使用 ChatGPT,许多人认为自己的集成开发环境(IDE)已具备 AI 就绪的能力,但正式的政策却明显滞后,仅有约四分之一的团队表示其工作遵循官方的 AI 使用指南,约 60%的开发者称所在组织尚未制定任何正式的 AI 政策。

在实践中,开发者正通过自下而上的方式填补这一空白。近 80%的受访者将“可靠性不足”和“输出不一致”列为阻碍更广泛使用 AI 的首要障碍。然而,67%的人表示他们会在合并前持续审查 AI 生成的代码,约 70%的人会常规性地重写或修正 AI 输出以确保正确性。报告指出,这种“默认审查”(review-by-default)的文化,正在将高采纳率转化为负责任的使用实践,不过自上而下的治理框架尚未完全建立。

 

研究还强调了强烈的自主学习的趋势,约 87%的开发者表示他们正在通过在线资料、实验和同行交流等方式自我培训 AI 技能,而非依赖公司提供的正式培训项目。与此同时,期待值也在上升,超过一半的开发者认为,AI 熟练度应该成为招聘的基本要求,许多人视 AI 能力为职业发展的关键要素。

 

Agoda 指出,该地区的开发者普遍将 AI 视为增强工作而非取代其工作的手段。但这种自下而上的势头也可能暴露出资源获取与支持体系的不均衡。报告呼吁企业需要迎头赶上,通过提供结构化培训、更清晰的政策以及将实验与安全、合规性及长期能力建设相协调的框架,来支持一线开发者。

 报告总结指出了三个现实情况:AI 已经成为主流,但分布不均;AI 正通过问责机制逐步演进;不同市场和企业间,AI 使用经验差异显著。大多数开发者每周节省的时间在 1 至 6 小时之间,最大收益体现在编码、调试以及学习新 API 或框架等环节,并非整项任务的完全自动化。

 

Agoda 首席技术官 Idan Zalzberg 将此视为软件构建方式的转变,而非构建者本身的更替:AI 正嵌入日常开发流程(从代码审查到团队协作),但人类的判断与监督仍居核心地位。报告最后指出,该地区真正的机遇在于,将这种自下而上的实验精神,与更强大的信任机制、问责体系和共享实践相结合,从而将近乎全民的 AI 应用,转化为一种可持续、区域级的工程能力。

 

原文链接:

How Developers in Southeast Asia and India Are Really Using AI in 2025

这两天在网络上又有一个东西火了,Twitter 的创始人 @jack 新的社交 iOS App  Damus 上苹果商店(第二天就因为违反中国法律在中国区下架了),这个软件是一个去中心化的 Twitter,使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议(协议简介协议细节),协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品,如:MastodonSecure Scuttlebutt 。我顺着去看了一下这个协议,发现这个协议真是非常的简单,简单到几句话就可以讲清楚了。

目录

通讯过程

  • 这个协议中有两个东西,一个是 client,一个是 relay,client 就是用户社交的客户端,relay 就是转发服务器。
  • 用户不需要注册,用户只需要有一个密钥对(公钥+私钥)就好了,然后把要发的信息做签名,发给一组 relays
  • 然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

  • 技术实现上,nostr 使用 websocket + JSON 的方式。其中主要是下面这么几个指令
    • Client 到 Relay主要是下面这几个指令:
      • EVENT。发出事件,可以扩展出很多很多的动作来,比如:发信息,删信息,迁移信息,建 Channel ……扩展性很好。
      • REQ。用于请求事件和订阅更新。收到REQ消息后,relay 会查询其内部数据库并返回与过滤器匹配的事件,然后存储该过滤器,并将其接收的所有未来事件再次发送到同一websocket,直到websocket关闭。
      • CLOSE。用于停止被 REQ 请求的订阅。
    • Relay 到 Client 主要是下面几个指令:
      • EVENT。用于发送客户端请求的事件。
      • NOTICE。用于向客户端发送人类可读的错误消息或其他信息
  • 关于 EVENT 下面是几个常用的基本事件:
    • 0: set_metadata:比如,用户名,用户头像,用户简介等这样的信息。
    • 1: text_note:用户要发的信息内容
    • 2recommend_server:用户想要推荐给关注者的Relay的URL(例如wss://somerelay.com

如何对抗网络审查

那么,这个协议是如何对抗网络审查的?

  • 识别你的身份是通过你的签名,所以,只要你的私钥还在,你是不会被删号的
  • 任何人都可以运行一个或多个relay,所以,就很难有人控制所有的relay
  • 你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
  • 你的信息是一次发给多个relay的,所以,只要不是所有的热门realy封了你,你就可以发出信息
  • 每个relay的运营者都可以自己制定规则,会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
  • 如果你被全部的relay封了,你还是可以自建你的relay,然后,你可以通过各种方式告诉你身边的人你的relay服务器是什么?这样,他们把这个relay服务器加到他们的client列表中,你又可以从社死中复活了。

嗯,听起来很简单,整个网络是构建在一种 “社区式”的松散结构,完全可能会出现若干个 relay zone。这种架构就像是互联网的架构,没有中心化,比如 DNS服务器和Email服务器一样,只要你愿意,你完全可以发展出自己圈子里的“私服”。

其实,电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候,我当时在北京,当时的卫生部部长说已经控制住了,才12个人感染,当局也在控制舆论和删除互联网上所有的真实信息。但是,大家都在用电子邮件传播信息,当时基本没有什么社交软件,大家分享信息都是通过邮件,尤其是外企工作的圈子,当时每天都要收很多的非典的群发邮件,大家还都是用公司的邮件服务器发……这种松散的,点对点的架构,让审查是基本不可能的。其实,我觉得 nostr 就是另外一个变种或是升级版的 email 的形式

如何对抗Spam和骗子

但是问题来了,如果不能删号封人的话,那么如何对抗那些制造Spam,骗子或是反人类的信息呢?nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你,如果给他发私信,需要支付一点点btc ,或是relay要求你给btc才给你发信息(注:我不认为这是一个好的方法,因为:1)因为少数的坏人让大多数正常人也要跟着付出成本,这是个糟糕的治理方式,2)不鼓励那些生产内容的人,那么平台就没有任何价值了)。

不过,我觉得也有可以有下面的这些思路:

  • 用户主动拉黑,但很明显这个效率不高,而且体验不好
  • 社区或是同盟维护一个黑名单,relay定期更新(如同email中防垃圾邮件也是这样搞的),这其实也是审查。
  • 防Spam的算法过滤垃圾信息(如同email中干的),自动化审查。
  • 增加发Spam的成本,如: PoW 工作量证明(比特币的挖矿,最早也是用于Email),发信息要花钱(这个对正常用户伤害太大了)等。
  • ……

总之,还是有相应的方法的,但是一定没有完美解,email对抗了这么多年,你还是可以收到大量的垃圾邮件和钓鱼邮件,所以,我觉得 nostr 也不可能做到……

怎么理解审查

最后,我们要明白的是,无论你用什么方法,审查是肯定需要的,所以,我觉得要完全干掉审查,最终的结果就是一个到处都垃圾内容的地方!

我理解的审查不应该是为权力或是个体服务的,而是为大众和人民服务的,所以,审查必然是要有一个开放和共同决策的流程,而不是独断的

这点可以参考开源软件基金会的运作模式。

  • 最底端的是用户(User)参与开源社区的使用并提供问题和反馈。
  • 用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者(Contributors),
  • 当贡献者提交一定数量贡献之后就可以晋升为提交者(Committers),此时你将拥有你参与仓库的代码读写权限。
  • 当提交者Committers在社区得到认可后,由项目管理委员会(PMC)选举并产生PMC成员(类似于议员),PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

  • 整个社区的决策者,是要通过自己贡献来挣到被选举权的。
  • 社区所有的工作和决定都是要公开的。
  • 社区的方向和决策都是要投票的,PMC成员有binding的票权,大众也有non-binding的投票权供参考。
  • 如果出现了价值观的不同,那么,直接分裂社区就好了,不同价值观的人加入到不同的社区就好了

如果审查是在这个框架下运作的话,虽然不完美,但至少会在一种公允的基础下运作,是透明公开的,也是集体决策的。

开源软件社区是一个很成功的示范,所以,我觉得只有技术而没有一个良性的可持续运作的社区,是不可能解决问题的,干净整齐的环境是一定要有人打扫和整理的

 

欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu
欢迎关注我 npub1w6r99545cxea6z76e8nvzjxnymjt4nrsddld33almtm78z7fz95s3c94nu

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (73 人打了分,平均分: 4.25 )

Loading...

两个月前,我试着想用 ChatGPT 帮我写篇文章《eBPF 介绍》,结果错误百出,导致我又要从头改一遍,从那天我觉得 ChatGPT 生成的内容完全不靠谱,所以,从那天开始我说我不会再用 ChatGPT 来写文章(这篇文章不是由 ChatGPT 生成),因为,在试过一段时间后,我对 ChatGTP 有基于如下的认识:

  1. ChatGPT 不是基于事实,是基于语言模型的,事实对他来说不重要,对他重要的是他能读懂你的问题,并按照一定的套路回答你的问题。
  2. 因为是基于套路的回答,所以,他并不能保证内容是对的,他的目标是找到漂亮的精彩的套路,于是,你会发现,他的内容组织能力和表述还不错,但是只要你认真玩上一段时间,你会发现,ChatGPT 那些表述的套路其实也比较平常一般。它的很多回答其实都不深,只能在表面上。就像 Github 的 Copilot 一样,写不了什么高级的代码,只能帮你写一些常规格式化的代码(当然,这也够了)
ChatGPT 就是一个语言模型,如果不给他足够的数据和信息,它基本就是在胡编乱造

所以,基于上面这两个点认识,以发展的眼光来看问题,我觉得 ChatGPT 这类的 AI 可以成为一个小助理,他的确可以干掉那些初级的脑力工作者,但是,还干不掉专业的人士,这个我估计未来也很难,不过,这也很帅了,因为大量普通的工作的确也很让人费时间和精力,但是有个前提条件——就是ChatGPT所产生的内容必需是真实可靠的,没有这个前提条件的话,那就什么用也没有了

今天,我想从另外一个角度来谈谈 ChatGPT,尤其是我在Youtube上看完了微软的发布会《Introducing your copilot for the web: AI-powered Bing and Microsoft Edge 》,才真正意识到Google 的市值为什么会掉了1000亿美元,是的,谷歌的搜索引擎的霸主位置受到了前所未有的挑战……

我们先来分析一下搜索引擎解决了什么样的用户问题,在我看来搜索引擎解决了如下的问题:

  • 知识或信息索引。查新闻,查股票,查历史,查文档,找答案……
  • 找服务提供商。找卖东西的电商,找帮你修东西的服务,找软件……
  • 信息的准确和可靠。搜索引擎的rank算法保证了最准确、最有用、最权威的信息出现在最前面……(作恶的百度不在此列)

基本上就是上面这几个,搜索引擎在上面这几件事上作的很好,但是,还是有一些东西搜索引擎做的并不好,如:

  • 搜索引擎是基于关键词的,不是基于语义的。所以,搜索引擎并不知道你的真实需求,因此,你会不可避免地要干下面的事,
    • 你经常要不断地增加或调整不同的关键词来提高查询信息的准确度……
    • 你经常要在你查找的信息中进行二次或多次过滤和筛选……
  • 搜索引擎是只能呈现内容,无法解读内容。所以,你找到相关的链接后,你还要花大量的时间来阅读理解,经常性的你不可避免的要干下面的事:
    • 打开一个链接,读到了一大半后,发现你要的内容不在其中,只能关掉再打开一个……
    • 你想要的内容是在的,但是太晦涩,看不懂,太费解,你要找小白友好的版本……
    • 你想要的内容不完整,你需要在很多个链接和网页上做拼图游戏……
    • 内容是无法结构化的展示的,你搜到的东西全都是碎片信息
  • 搜索引擎没有上下文关联,两次搜索是没有关系的。也就是说,人知道的越多,问题也就越多,所以,我们经常会面临下面的问题:
    • 随着我了解的越多,我的信息搜索的会出现分支,这个分支只有我自己的管理,搜索引擎是不关心的,导致我每次都相当于从头开始……
    • 你做计划的时候,你需要从多个不同的搜索中获取你想要的东西,最终组合成你定制化的东西,比如做旅游计划……

好了,我们知道,ChatGPT 这类的技术主要是用来根据用户的需求来按一定的套路来“生成内容”的,只是其中的内容并不怎么可靠,那么,如果把搜索引擎里靠谱的内容交给 ChatGPT 呢?那么,这会是一个多么强大的搜索引擎啊,完全就是下一代的搜索引擎,上面的那些问题完全都可以解决了:

  • 你可以打一段话给搜索引擎,ChatGPT 是读得懂语义的。
  • 因为知道语义,于是在众多搜过结果中,他更知道哪些是你想要的内容。
  • ChatGPT 可以帮你生成 TL;DR,把长文中的要求总结出来形成更易读的短文
  • ChatGPT 可以帮你整理内容,在多个网页中帮你整合和结构化内容
  • ChatGPT 可以有上下文对话,你可以让他帮你不断通过更多的关键词搜索信息,并在同一个主题下生成、组织和优化内容

一旦 ChatGPT 利用上了搜索引擎内容准确和靠谱的优势,那么,ChatGPT 的能力就完全被释放出来了,所以,带 ChatGPT 的搜索引擎,就是真正的“如虎添翼”!

因此,微软的 Bing + ChatGPT,成为了 Google 有史以来最大的挑战者,我感觉——所有跟信息或是文字处理相关的软件应用和服务,都会因为 ChatGPT 而且全部重新洗一次牌的,这应该会是新一轮的技术革命……Copilot 一定会成为下一代软件和应用的标配!

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (255 人打了分,平均分: 4.52 )

Loading...

这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务,成本降低90%》,副标题:“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”,有人把这篇文章在五一期间转到了reddithacker news 上,在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”,还是Amazon干的,这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》,继续抨击微服务架构,于是,瞬间引爆技术圈,登上技术圈热搜。

今天上午有好几个朋友在微信里转了三篇文章给我,如下所示:

看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇,你还真当 Prime Video 就是 Amazon 的全部么?然后,再看看这些文章后面的跟风评论,我觉得有 80%的人只看标题,而且是连原文都不看的。所以,我想我得写篇文章了……

原文解读

要认清这个问题首先是要认认真真读一读原文,Amazon Prime Video 技术团队的这篇文章并不难读,也没有太多的技术细节,但核心意思如下:

1)这个系统是一个监控系统,用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果(比如:视频损坏或是音频不同步等问题),这个监控主要是处理视频帧,所以,他们有一个微服务主要是用来把视频拆分成帧,并临时存在 S3 上,就是下图中的 Media Conversion 服务。

2)为了快速搭建系统,Prime Video团队使用了Serverless 架构,也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关,Step Function 用来做监控(探测器),有问题后,就发 SNS 上,Step Function 从 S3 获取 Media Conversion 的数据,然后把运行结果再汇总给一个后置的 Lambda ,并存在 S3 上。

整个架构看上去非常简单 ,一点也不复杂,而且使用了 Serverless 的架构,一点服务器的影子都看不见。实话实说,这样的开发不香吗?我觉得很香啊,方便快捷,完全不理那些无聊的基础设施,直接把代码转成服务,然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了,哪里不好了?!

但是他们遇到了一个比较大的问题,就是 AWS Step Function 的伸缩问题,从文章中我看到了两个问题(注意前方高能):

  1. 需要很多很多的并发的 AWS Step Function ,于是达到了帐户的 hard limit。
  2. AWS Step Function 按状态转换收费,所以,贵得受不了了。

注意,这里有两个关键点:1)帐户对 Step Function 有限制,2)Step Function 太贵了用不起

然后,Prime Video 的团队开始解决问题,下面是解决的手段:

1) 把 Media Conversion  和 Step Function 全部写在一个程序里,Media Conversion 跟 Step Function 里的东西通过内存通信,不再走S3了。结果汇总到一个线程中,然后写到 S3.

2)把上面这个单体架构进行分布式部署,还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制,而且你想买多少 CPU/MEM 的机器由你说了算,而这些视频转码,监控分析的功能感觉就不复杂,本来就应该写在一起,这么做不更香吗?当然更香,比前面的 Serverless 的确更香,因为如下的几个原因:

  1. 不再受 Step Function 的限制了,技术在自己手里,有更大的自由度。
  2. 没有昂贵的 Step Function 云成本的确变得更低了,如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress,你把 S3 换成 MinIO,你把 SNS 换成 Kafka,你的成本 还能再低。

独立思考

好了,原文解读完了,你有自己的独立思考了吗?下面是我的独立思考,供你参考:

1)AWS 的 Serverless 也好, 微服务也好,单体也好,在合适的场景也都很香。这就跟汽车一样,跑车,货车,越野车各有各的场景,你用跑车拉货,还是用货车泡妞都不是一个很好的决定。

2)这篇文章中的这个例子中的业务太过简单了,本来就是一两个服务就可以干完的事。就是一个转码加分析的事,要分开的话,就两个微服务就好了(一个转码一个分析),做成流式的。如果不想分,合在一起也没问题了,这个粒度是微服务没毛病。微服务的划分有好些原则,我这里只罗列几个比较重要的原则:

  • 边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context(具体是什么 大家自行 Google),也就是一个业务域。
  • 单一职责,高内聚,低耦合。把因为相同原因变化的合在一起(内聚),把不同原因变化的分开(解耦)
  • 事务和一致性。对于两个重度依赖的功能,需要完成一个事务和要保证强一致性的,最好不要拆开,要放在一起。
  • 跟组织架构匹配。把同一个团队的东西放在一起,不同团队的分开。

3)Prime Video 遇到的问题不是技术问题,而是 AWS  Step Function 处理能力不足,而且收费还很贵的问题。这个是 AWS 的产品问题,不是技术问题。或者说,这个是Prime Video滥用了Step Function的问题(本来这种大量的数据分析处理就不适合Step Function)。所以,大家不要用一个产品问题来得到微服务架构有问题的结论,这个没有因果关系。试问,如果 Step Funciton 可以无限扩展,性能也很好,而且白菜价,那么 Prime Video 团队还会有动力改成单体吗?他们不会反过来吹爆 Serverless 吗?

4)Prime Video 跟 AWS 是两个独立核算的公司,就像 Amazon 的电商和 AWS 一样,也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维,我个人认为这个世界上再也找不到另外一家公司了,包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。

5)Prime Video 这个案例本质上是“下云”,下了 AWS Serverless 的云。云上的成本就是高,一个是费用问题,另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂,重写起来也很快,所以,可以很快使用一个更传统的“服务化”+“云计算”的分布式架构,不然,就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》(他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本)

后记

最后让我做个我自己的广告。我在过去几年的创业中,帮助了很多公司解决了这些 分布式,微服务,云原生以及云计算成本的问题,如果你也有类似问题。欢迎,跟我联系:[email protected]

另外,我们今年发布了一个平台 MegaEase Cloud,就是想让用户在不失去云计算体验的同时,通过自建高可用基础架构的方式来获得更低的成本(至少降 50%的云计算成本)。目前可以降低成本的方式:

  1. 基础软件:通过开源软件自建,
  2. 内容分发:MinIO + Cloudflare 的免费 CDN,
  3. 马上准备发布的直接与底层IDC合作的廉价GPU计算资源…

欢迎大家试用。

如何访问

注:这两个区完全独立,帐号不互通。因为网络的不可抗力,千万不要跨区使用。

产品演示

介绍文章

 

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (647 人打了分,平均分: 4.32 )

Loading...

这里记录每周值得分享的科技内容,周五发布。


本杂志开源,欢迎投稿。另有《谁在招人》服务,发布程序员招聘信息。合作请邮件联系[email protected])。

封面图

武汉首座电梯升降桥最近建成开放。因为上游有船厂,所以大桥有四根巨大的电梯柱,用来升起桥面,让船通过。(via

预测是新的互联网热点

大家大概想不到,美国互联网的热点,现在不是 AI 网站,而是一种全新的网站,叫做"预测市场"(prediction market)。

这类网站像雨后春笋一样,每天都在冒出来。最有名的预测市场,目前是 PolyMarket

预测市场的用途,就是预测各种各样的事情。以 PolyMarket 为例,首页顶部就是各种预测的分类。

热门事件、突发事件、最新预测、政治、体育......

只要是你能想到的事情,它都提供预测

以上周末为例,首页热门预测如下(上图)。

  • 《时代》杂志的年度人物是谁?
  • 《时代》杂志年度人物名单会泄露吗?
  • 美联储一月份的决定是什么?
  • OpenAI 下一次的大模型发布是哪一天?

你随便选一个,点进去就能看到,各种情况的概率。

上图预测的是,2025年12月5日至12日期间,马斯克会发多少条推文。

可以看到,概率最高的情况是440条~450条,概率33%,概率最低的情况是400条~419条,概率1%。

正是因为对于几乎任何问题,它都有实时的详细预测,美国人现在已经不怎么看民调了,改成看这种预测网站了。因为民调的抽样方法和样本大小,总是有局限的,反而是预测网站更反映市场的真实看法。

你可能会问,这些预测结果怎么产生?如何确保准确?

答案很简单,结果来自于用户的下注。

你看好哪一种情况,就可以对它下注。看好的人多,这种情况对应的概率就会上升,反之下降。

实质上,它的每一个预测都是一支股票,股价就是它的概率,1%的概率就是股价0.01元,100%的概率就是股价1元。

举例来说,某种情况的当前概率是2%,那么相当于0.02元。你看好这种情况,假定就花了100元买入。

结果,正如你的预测,它变成了现实,概率上升为100%,价格就变成了1元,相比你的买入价,整整上涨了50倍。于是,你投入的100元就变成了5000元。

反之,你预测错了,这个结果没有实现,概率变为0%,也就是0元,你投入的100元将一分都收不回来。

最近,美国的一条热门新闻就是,一个男子在 PolyMarket 上,对一个2%的小概率事件投入3000美元。结果,预测准确,他收回了12.5万美元。

为了方便世界各地的人参与,也是为了保证匿名,这种预测网站都采用稳定币交易。

所以,它的本质就是一个巨大的彩票市场,允许用户买卖自己最感兴趣、最熟悉的事件,这是它快速流行起来的根本原因。参与的人多了以后,反过来提高了预测的准确性。

我觉得,它的前景不可限量,一定会火爆的井喷式发展,传统彩票可能会被它彻底淘汰。

它把任何不确定的事情,都变成了彩票,实时量化了每一种可能性的概率,并且提供了金钱翻倍的途径。这一方面很有参考价值,可以用来判断未来情况,另一方面也非常有娱乐性和刺激性。

国产 Nano Banana Pro 的图片幻灯片生成

上个月,谷歌发布了新一代图像编辑模型 Nano Banana Pro(其实就是 Gemini 3 Pro 的图像分支)。

有一个功能引起了轰动:无论多么枯燥的文字,都能变成有趣的图片,从"读文"变成"读图"。

我当时就想,国产模型一定会马上跟进。

果然,昨天打开秘塔 AI,就看到他们发了这个功能完全对标 Nano Banana Pro 以及 NotebookLM,而且还加入了自己的特色----讲解。

你点击"上传文件"(上图),上传各种资料(可以上传多篇),它就会自动创建一个知识库,输出内容的 AI 总结。这时,还会显示一个"给我讲讲"按钮。

上图是我写的一篇 JS 语法点 Promise 的教程,点击"给我讲讲"就会生成图片幻灯片 + 讲解。

大家可以去它们的官网 metaso.cn (手机 App 同名)试试看,这个功能挺好玩的,操作零门槛,关键是它免费(有赠送的积分)。

除了上传文件,你也可以直接搜索某个主题,再点击下方的"生成幻灯片"按钮。这时就会有"图片幻灯片"选项,并有20多种风格可选,还支持自定义。

科技动态

1、步行环游世界

上个世纪90年代的一天,一个英国青年在酒吧里随口说,他可以从南美洲最南端一路走到英国。他的朋友都不信。

他就跟朋友打赌,他能做到。1998年,他正式从智利最南端开始步行,那一年他29岁。

27年过去了,他已经56岁了,依然在路上。

好消息是,他已经接近行程的尾段,预计将于2026年9月到达终点英国。

下面就是他的路线图,从南美洲最南端到北美洲最北端,再到亚洲和欧洲,最后是英国。

整个行程中,他只能步行或者游泳,不能使用任何交通工具。最难的一段就是北美洲与俄罗斯之间的白令海峡,为了不坐船,他是在冬天从海冰上爬过去的。

这27年中,他也不是每天都在走,有时因为各种原因,会离开一段日子,然后再回来接着走。

他说,依靠个人的力量不可能完成这样的行程,留不开家人的支持、陌生人的友善,以及赞助商的帮助。

至于是什么力量支撑他坚持走了近30年?他说:"你需要看看真实的世界,以及生活在其中的人们,这将是你所能接受的最好的教育之一。"

2、六臂机器人

美的公司展示一个六臂机器人,将用于无锡工厂的生产线。

它可以六只手同时执行三项任务。那样的话,一个机器人就相当于三个工人了。

3、手摇洗衣机

一位前戴森公司的工程师,为不发达地区发明了一种手摇洗衣机。

据介绍,这种洗衣机不需要电,只要手摇几分钟,就能洗净5公斤衣物,并且节省一半的水。

如果它真的有效,我有一个建议,就是把手摇改成脚踏车,只要踩5分钟踏板,就能洗一筒衣服。

文章

1、程序员为自己的工具命名时的彻底迷失(英文)

本文批评很多程序员为软件起名时,尽起一些烂七八糟的名字,根本看不出软件的用途,建议软件名称应该跟用途有相关性。

2、解读斯诺登文件(英文)

这篇文章详细分析了2013年斯诺登泄漏的文件,文章第一部分就是分析对北方工业公司的情报收集,美国的监控令人叹为观止。

3、从文本到词元(英文)

一篇科普文章,通俗地介绍搜索引擎如何将查询的文本转换成标准化的词元(token)。

4、大模型构建 HTML 工具的实用方法(英文)

著名程序员 Simon Willison 的长文,总结他使用大模型生成网页应用的经验。

5、GraphQL 蜜月期已结束(英文)

作者认为,GraphQL 解决的问题远比人们想象的小众,而且可以通过其他方式解决,这项技术最终往往弊大于利。

6、git add -p 的解释(英文)

本文介绍 git add -p 命令。它会显示一个互动界面,让用户逐个确认每个文件的变动,是否要加入暂存区。

工具

1、Cosmic

上周,Cosmic 1.0版正式发布了。它是一个全新的 Linux 桌面,美观且功能强大,为用户提供了 Gnome 和 KDE 之外的另一个选择。

2、Keyden

macOS 菜单栏的开源 TOTP 双因素认证器,密钥加密存储在 macOS Keychain。(@tasselx 投稿)

3、WeMD

开源的 Markdown 微信公众号编辑器。(@tenngoxars 投稿)

4、starling-speak

文本朗读网站,支持多种语言,带有录音功能。(@Keldon-Pro 投稿)

5、shift

一个基于 WebAssembly 的在线代码编辑器,支持直接在网页运行 Python、Lua、Ruby 等语言。(@hubenchang0515 投稿)

6、EasyImg

基于 Nuxt 4 构建的个人图床,丰富的后台配置。(@chaos-zhu 投稿)

7、Go-WXPush

Go 语言开发的微信消息推送服务,提供了一个简单的 API 消息推送接口。代码开源,每天10万次推送额度,个人用不完。(@hezhizheng 投稿)

8、ZeroLaunch-rs

Windows 应用启动器,拼音模糊匹配,基于 Rust + Tauri + Vue.js。(@ghost-him 投稿)

9、MrRSS

跨平台的开源桌面 RSS 阅读器,支持自动翻译、自动总结、新订阅源发现。(@ch3ny4ng 投稿)

10、PVE Touch

为移动设备优化的 Proxmox VE 管理界面,方便通过手机管理虚拟机。(@hanxi 投稿)

AI 相关

1、Disco

谷歌实验室推出的实验性 AI 浏览器,完全跳过网页搜索,目前需要排队等待名额。

2、Flowers

开源的浏览器 AI 助手插件,提供网页翻译、问答、笔记等功能。(@snailfrying 投稿)

3、DeepAudit

开源的代码审计平台,通过智能体实现漏洞挖掘和自动化沙箱 PoC 验证,支持 ollama 私有部署模型,代码可不出内网。(@lintsinghua 投稿)

资源

1、生命的尺寸

这个网站用图形展示各种生命体的大小比较,从 DNA 一直到蓝鲸。

2、写一个你自己的 C 语言编译器(Build Your Own Lisp)

一本面向初学者的免费英文电子书,介绍怎么用 C 语言写编译器,以 Lisp 语言的编译器为例。

3、A Soft Murmur

一个背景音网站,可以开关不同的音效,并调节它们的音量。

图片

1、13个圆画出动物

一个艺术家使用13个圆,画出各种动物。

猫头鹰

兔子

猴子

文摘

1、Claude Opus 4.5 是第一款让我真正担心自己工作会丢掉的大模型

Claude Opus 4.5 真是完全不同于其他模型。还没用过的人根本无法想象未来两三年会发生什么,明年可能就是最终的转折点。

我不知道接下来该如何适应。当然,我可以整天看着 Opus 帮我工作,偶尔出点小问题再干预一下,但再过一段日子连这些都不需要了呢?

编码问题基本上已经解决了,接下来像系统设计、安全之类的问题也会迎刃而解。我估计再过两三个版本,80%的技术人员就基本没用了。当然,公司还需要一些时间来适应,但他们肯定会想方设法尽快摆脱我们。

虽然我很喜欢 AI 这项技术,但一想到这一切最终会走向何方,我就感到难过。

2、为什么学习物理学

(本文摘自理查德·费曼于1963年6月在里约热内卢举行的美洲物理教育会议上发表的演讲。费曼是加州理工学院理论物理学教授。)

我们应该教授物理学,这有五个原因。

(1)物理是一门基础科学,应用于工程学、化学和生物学等各种技术领域。

物理是研究自然界的科学,或者说是认识自然界的科学,它告诉我们事物是如何运作的,以及人类在当前和未来的技术中发明的各种设备是如何工作的。因此,懂物理的人应对本行业出现的技术问题会很有用。

(2)物理教会你如何动手做事情。它教授许多操纵事物的技巧,以及测量和计算技巧,这些技巧的应用范围比特定研究领域要广泛得多。

(3)物理作为一门科学,对许多人来说,是一种极大的乐趣。

科学教育培养出来的科学家,不仅为工业发展和知识发展做出贡献,同时也参与了我们这个时代的伟大冒险,从中获得巨大的乐趣。

即使一个人没有成为一名专业科学家,研究自然也是为了欣赏自然的奇妙和美丽。这种对自然的了解也给人一种稳定和现实的感觉,并驱散了许多恐惧和迷信。

(4)物理教会人们如何认识事物,帮助你质疑很多事情。质疑和自由思想的价值,不仅对科学发展,而且对其他各个领域,都显而易见。

科学教导我们如何认识事物、什么是未知事物、事物被认识到什么程度、如何处理怀疑和不确定性、证据规则是什么、如何思考事物以便做出判断、如何区分真理与欺诈。这些无疑是教授科学,特别是教授物理的重要收获。

(5)在学习科学的过程中,你会学会如何试错,培养发明创造和自由探索的精神,这种精神的价值远远超出了科学本身。

人们会学会问自己:"有没有更好的方法 ?"我们必须想出一些新的技巧或方法,以改进这项技术。这种想法是许多思想、发明创造以及各种人类进步的源泉。

言论

1、

为什么我们有两个鼻孔,而不是一个大洞?

因为肺部持续需要空气,两个鼻孔可以交替工作,让鼻子的一侧得到休息。

-- 美国《大众科学》

2、

报社招我去当撰稿人,我以为是去写稿,结果却是以极低的薪水让我编辑 AI 生成的文案草稿,理由是"大部分工作已经完成了"。

这让我深受打击,我曾经觉得自己很有价值,受人重视,对未来充满希望,渴望拥有辉煌的职业生涯,现在却只能修改 AI 生成的文字。

-- 一位自由撰稿人

3、

SaaS 行业将会萎缩,尤其是那些功能简单的 SaaS,因为企业现在可以用 AI 快速生成内部服务。

-- 《AI 正在蚕食 SaaS》

4、

我发现,中文不喜欢直接说 True,更倾向说 !False。比如,英文说"很好",中文说"不坏",英文说"对的",中文说"没错",英文说"正常",中文说"没问题"。

中文更喜欢双重否定"否定词+否定词",这种表达方式增加了模糊性(含糊其辞)和灵活性(模棱两可),创造了回旋余地,避免了肯定答复导致的态度明确、归类迅速、立场鲜明。

-- 《为什么中文拒绝说 true》

往年回顾

你可能是一个 NPC(#331)

新基建的政策选择(#281)

互联网公司需要多少员工?(#231)

移动支付应该怎么设计?(#181)

(完)

一、

最近,我写了好几篇 AI 教程,就收到留言,要我谈谈我自己的 AI 编程。


今天就来分享我的 AI 编程,也就是大家说的"氛围编程"(vibe coding)。

声明一下,我只是 AI 初级用户,不是高手。除了不想藏私,更多是为了抛砖引玉,跟大家交流。

二、

平时,我很少用 AI 生成新项目。因为每次看 AI 产出的代码,我总觉得那是别人的代码,不是我的。

如果整个项目都用 AI 生成,潜意识里,我感觉不到那是自己的项目。我的习惯是,更愿意自己写新项目的主体代码。

我主要把 AI 用在别人的项目和历史遗留代码,这可以避免读懂他人代码的巨大时间成本。

就拿历史遗留代码为例,(1)很多时候没有足够的文档,也没有作者的说明,(2)技术栈和工具库都过时了,读懂代码还要翻找以前的标准,(3)最极端的情况下,只有构建产物,没有源代码,根本无法着手。

AI 简直就是这类代码的救星,再古老的代码,它都能读懂和修改,甚至还能对构建产物进行逆向工程。

下面就是我怎么用 AI 处理历史遗留代码,平时我基本就是这样来 AI 编程。

三、

我的 AI 编程工具是 Claude Code。因为命令行对我更方便,也容易跟其他工具集成。

我使用的 AI 模型,大部分时间是国产的 MiniMax M2。我测过它的功能,相当不错,能够满足需要,它的排名也很靠前。

另外,它有包月价(29元人民币),属于最便宜的编程模型之一,可以放心大量使用,反复试错。要是改用大家都趋之若鹜的 Claude 系列模型,20美元的 Pro 套餐不够用,200美元的 Max 套餐又太贵。

MiniMax 接入 Claude Code 的方法,参考我的这篇教程

四、

就在我写这篇文章的时候,MiniMax 本周进行了一次大升级,M2 模型升级到了 M2.1

因为跟自己相关,我特别关注这次升级。

根据官方的发布声明,这次升级特别加强了"多语言编程能力",对于常用编程语言(Rust、Java、Golang、C++、Kotlin、Objective-C、TypeScript、JavaScript 等)有专门强化。

它的 WebDev 与 AppDev 开发能力因此有大幅提升,可以用来开发复杂的 Web 应用和 Android/iOS 的原生 App。

"在软件工程相关场景的核心榜单上,MiniMax M2.1 相比于 M2 有了显著的提升,尤其是在多语言场景上,超过 Claude Sonnet 4.5 和 Gemini 3 Pro,并接近 Claude Opus 4.5。"

根据上面这段介绍,它的编程能力,超出或接近了国外旗舰模型。

这个模型已经上线了,现在就能用。那么,这篇文章正好测一下,官方的介绍是否准确,它的 Web 开发能力到底有没有变强。

至于价格,跟原来一样。但是,官方表示"响应速度显著提升,Token 消耗明显下降",也算变相降价了。

M2.1 接入 Claude Code,我的参数如下。

五、

我这次选择的历史遗留项目是 wechat-format,一个 Web 应用,将 Markdown 文本转为微信公众号的样式。

上图左侧的文本框输入 Markdown 文本,右侧立刻显示自动渲染的结果,可以直接复制到微信公众号的编辑器。

它非常好用,大家可以去试试看。我的公众号现在就用它做排版,效果不错(下图)。

问题是,原作者六年前就放弃了,这个项目不再更新了。我看过源码,它用的是老版本的 Vue.js 和 CodeMirror 编辑器,没有任何文档和说明,还经过了编译工具的处理,注释都删掉了。

如果不熟悉它的技术栈,想要修改这些代码是很困难的,可能要投入大量时间。

那么废话少说,直接让 AI 上场,把这些代码交给 MiniMax M2.1 模型。

六、

接手老项目的第一步,是对项目进行一个总体的了解。

我首先会让 AI 生成项目概述。大家可以跟着一起做,跟我的结果相对照。


# 克隆代码库
$ git clone [email protected]:ruanyf/wechat-format.git

# 进入项目目录
$ cd wechat-format

# 启动 Claude Code
$ claude-minimax

上面的claude-minimax是我的自定义命令,用来在 Claude Code 里面调用 MiniMax 模型(参见教程)。

输入"生成这个仓库的概述"。

AI 很快就给出了详细说明,包括项目的总体介绍、核心功能、技术栈和文件结构(下图)。

有了总体了解以后,我会让 AI 解释主要脚本文件的代码。

【提示词】解释 index.html 文件的代码

它会给出代码结构和页面布局(上图),然后是 JS 脚本加载顺序和 Vue 应用逻辑,甚至包括了流程图(下图),这可是我没想到的。

做完这一步,代码库的大致情况应该就相当了解了,而 AI 花费的时间不到一分钟。

七、

既然这个模型号称有"多语言编程能力",我就让它把项目语言从 JavaScript 改成 TypeScript。

对于很多老项目来说,这也是常见需求,难度不低。

它先制定了迁移计划,然后生成了 tsconfig.json 和 types.d.ts,并逐个将 JS 文件转为对应的 TS 文件(下图)。

修改完成后,它试着运行这个应用,发现有报错(下图),于是又逐个解决错误。

最终,迁移完成,它给出了任务总结(下图)。

我在浏览器运行这个应用,遇到了两个报错:CodeMirror 和 FuriganaMD 未定义。

我把报错信息提交给模型,它很快修改了代码,这次就顺利在浏览器跑起来了。

至此,这个多年前的 JavaScript 应用就成功改成了 TypeScript 应用,并且所有内部对象都有了完整的类型定义。

你还可以接着添加单元测试,这里就省略了。

八、

简单的测试就到此为止,我目前的 AI 编程大概就到这个程度,用 AI 来解释和修改代码。我也建议大家,以后遇到历史遗留代码,一律先交给 AI。

虽然这个测试比较简单,不足以考验 MiniMax M2.1 的能力上限,但如果人工来做上面这些事情,可能一个工作日还搞不定,但是它只需要十几分钟。

总体上,我对它的表现比较满意。大家都看到了,我的提示词很简单,就是一句话,但是它正确理解了意图,如果一次没有成功,最多再修改一两次就正确了。

而且,就像发布说明说的一样,它运行速度很快,思考过程和生成过程最多也就两三分钟,不像有的模型要等很久。

另外,不管什么操作,它都会给出详细的讲解和代码注释。

总之,就我测试的情况来看,这个模型的 Web 开发能力确实很不错,可以用于实际工作。

最后,说一点题外话。著名开发者 Simon Willison 最近说,评测大模型越来越困难,"我识别不出两个模型之间的实质性差异",因为主流的新模型都已经足够强大,足以解决常见任务,只有不断升级评测的难度,才能测出它们的强弱。

这意味着,对于普通程序员的常见编程任务,不同模型不会构成重大差异,没必要迷信国外的旗舰模型,国产模型就很好用。

(完)

这里记录每周值得分享的科技内容,周五发布。([通知] 下周元旦假期,周刊休息。


本杂志开源,欢迎投稿。另有《谁在招人》服务,发布程序员招聘信息。合作请邮件联系[email protected])。

封面图

哈尔滨19米大雪人,完工之前的样子。(via cgtn@instagram

《硅谷钢铁侠》摘录

最近,我读了一本十年前的马斯克传记《硅谷钢铁侠》(中信出版社,2016)。

按理说,这本书已经过时了,这十年马斯克发生太多事情了。

我是睡觉前随手拿起来,翻了几页,看得津津有味,就读完了。

这本是马斯克的授权传记,他本人亲自接受了采访,还挺有料的。而且,因为我已经知道后续的发展,所以读到十年前的采访,反而有更多启发。

他的人生确实传奇,白手起家,家里给的最大帮助就是从南非移民到加拿大,后面都是自己奋斗出来的。

他创立了 Paypal,然后把卖掉它的钱拿来又创办了三家公司:特斯拉、SpaceX 和 SolarCity。

这太疯狂了,他一个外行同时进入了三个不同的行业----电动汽车、宇宙航天和太阳能----这些行业都刚萌芽,没有任何个人创业成功的先例。

更疯狂的是,他居然把这三家公司都做成了,而且都做到了世界第一(SolarCity 后并入特斯拉),他也因此变成了世界首富,你说神奇不神奇。

读完全书,我的最大感受是,还是要动手做事,没准真能做成。想他人不敢想,做他人不敢做。即使最狂野的梦想,只要全心投入,用力去做,也是有可能成功的。

下面就是我的一点摘录。

(1)

特斯拉最艰难的时候,非常接近于破产倒闭。

马斯克对外宣传,特斯拉是一家汽车公司,但实际上,他们只是一群年轻人租了一间大厂房,更像是在捣鼓汽车的大型实验室。

(2)

马斯克非常不理解,为什么有人设计了车灯开关。

他说:"真是多此一举。天黑时车灯自动打开,就这么简单。"

(3)

特斯拉的第一版设计稿,因为设计师没想好门把手的形状,就没画上去。

没想到马斯克很喜欢这个没有门把手的车型,就决定门把手应该在有需要的时候自动弹出。

(4)

马斯克认为,未来会有人口危机,主张多生孩子。

他认真考虑了,怎么在特斯拉后排安装婴儿座椅。传统的车门设计,使得把婴儿座椅和小孩安置在后排非常不方便,所以特斯特的车门设计采用了"鹰翼门"。

(5)

特斯拉的第一款车型是跑车,但没有大量生产。真正大量生产的第一款车型是 Model S,最初的名字是 Model Sedan。

Sedan 这个词的意思就是轿车,用来跟跑车相区别。但是马斯克认为这个词太平淡了。英国人习惯称轿车为 Saloon,这听上一样不伦不类。最后,就索性只保留第一个字母,称为 Model S。

(6)

马斯克对员工的要求是,全情投入你的工作,并把事情搞定。

不要等待上级的指导和详细指示,也不要等待别人的反馈意见,你要主动想办法把工作完成。

(7)

他认为,一个人独立工作,是最佳的工作状态。

一个人不需要开会、不需要与谁达成共识,也不需要在项目中帮助其他人。你一个人就可以持续地工作、工作、再工作。

(8)

特斯拉员工最害怕的事情,就是向马斯克申请额外的时间或者经费。

你一定要事先做好详细准备,跟他解释为什么必须招更多的人,以及需要追加的时间和资金预算。如果有招聘目标,还要准备那个人的简历。

(9)

如果你一上来就告诉马斯克,某件事情做不了,他会马上把你轰出办公室,甚至可能当场解雇你。

在马斯克看来,某件事办不成的唯一原因,就是违背了基本的物理原理。但是即使这样,你也必须做足了功课,深入每一个技术环节,向他解释为什么行不通。

(10)

马斯克要求员工,项目没完成之前,周六和周日依然要努力工作,并睡在桌子底下。

有些人反对,表示员工也需要休息,有时间陪陪家人。

马斯克说:"我们破产之后,你们会有大量时间陪家人。"

(11)

马斯克有自己计算时间价值的方法。他预期10年后,公司的日营收可以达到1000万美元,所以进度每拖延一天,就相当于多损失1000万美元。

(12)

马斯克的根本想法是改变这个世界,他总是喜欢谈论人类的生存问题。

早在他开始创业的时候,就已经得出了结论,那就是生命是短暂的。如果你真的意识到这一点,你就会知道,活着的时候工作越努力越好。

科技动态

1、黑色圣诞卡

爱沙尼亚交通警察向800多名危险驾驶者,寄送了黑色圣诞卡,提醒他们新的一年必须安全驾驶。

这些人都是过去违反交通规则的司机,最常见的问题是超速和不系安全带。

圣诞卡上是一起交通事故的现场,黑漆漆的深夜,天空中有明亮的月亮,公路上有交通事故后的车辆残骸,远处还有车灯的亮光。

一个有趣的统计是,虽然人们常说女司机是"马路杀手",但是这800多个危险驾驶者里面,只有33名女性。

2、2025全球互联网报告

世界最大 CDN 服务商 Cloudflare,发布了《2025全球互联网报告》,公布了它的统计数据。

2025年,全球互联网流量上升19%,由于网民数量基本没变,所以多出来的流量来自 AI 爬虫。

流量最大的前10大互联网服务:谷歌、脸书、苹果......

移动流量中,苹果设备占35%,安卓设备占65%。

浏览器排行是,Chrome 66%,Safari 15.4%,Edge 7.4%。

3、违停巡逻车

上海警方启用无人驾驶的违章停车巡逻车。

这辆小车自动在马路上巡逻,对路面进行抓拍。

一旦发现违停车辆,它就会识别车牌,将其上传警务系统,系统后台会发送提醒短信给车主,要求在12分钟内驶离。

12分钟后,小车就会返回点位进行检查,将相关信息回传后台,并经民警审核后开罚单。

据报道,12月18日一天,它共发现违停车辆119辆次。

4、室内过山车

一家瑞典的创意工作室,在他们的办公室建造了世界唯一的室内过山车。

这个过山车途径办公室的各个角落,总长60米,最高的地方距离地面有3米。

坐上这个过山车,你就能游览一圈办公室,看到同事们在干什么。

工作室负责人说,建造它的目的是"促进员工之间的互动,以及打破常规,培养创造力。"

文章

1、分布式架构的演化(英文)

本文将分布式架构分成三种:P2P、联邦式(比如 Mastodon)、中继式(比如 Nostr)。作者认为,对于大型分布式应用,中继式架构才是未来方向。

2、什么是 GitHub 自托管 Runner?(中文)

GitHub Actions 有一个 self-hosted runner 功能,让 action 运行在你自己的服务器。本文详细介绍它的概念、原理,并结合案例进行实践。(@luhuadong 投稿)

3、CSS Grid Lanes 布局(英文)

浏览器开始支持 CSS 的 Grid Lanes 布局了,大大方便了瀑布流的实现。

4、6502 指令集适用汇编语言初学者(英文)

6502 是一块诞生于1975年的 CPU,很多早期电脑(比如 Apple II)都使用它。作者解释,为什么你应该用它,作为学习汇编语言的第一个指令集。

5、你应该多用/tmp目录(英文)

作者提出,Linux 系统的/tmp目录用起来很方便,完全可以把它当作自己的临时性目录。

6、中国的清洁能源战略(英文)

《纽约时报》驻华记者的长文,体验当代中国的生活,比如无人驾驶、无人机送餐,他说"感觉像生活在未来"。

工具

1、MADOLA

一种新的数学脚本语言,像编程一样写数学公式,可以编译成 HTML 格式作为文档,也可以编译成 C++ 或 WebAssembly 直接运行。(@AI4Engr 投稿)

2、CattoPic

一个基于 Cloudflare Worker 的图片托管服务,将图片上传到 Cloudflare 进行推过,支持自动格式转换、标签管理。(@Yuri-NagaSaki 投稿)

3、termdev

直接在终端,通过连接 Chrome Devtool 调试网页。(@taotao7 投稿)

4、tui-banner

为 Rust 语言的命令行项目添加一个横幅图案。(@coolbeevip 投稿)

5、Alertivity

macOS 菜单栏的资源监控工具,监控 CPU、内存、磁盘、网络和进程活动。(@nobbbbby 投稿)

6、cpp‑linter

C/C++ 代码的静态检查工具,可以接入 CI/CD 流程,简化代码质量管理。(@shenxianpeng 投稿)

7、Rote

开源的 Web 笔记软件,需要自己架设。(@Rabithua 投稿)

8、Infographic

JS 的数据可视化框架,用于在网页生成各种信息图,内置200多种模板。(@Aarebecca 投稿)

9、Clock Dashboard

天气时钟看板,适合老旧的电子设备再利用。(@teojs 投稿)

10、离线版问卷

开源 Web 应用,用来设计和托管调查问卷/报名表。(@chenbz777 投稿)

11、Xget

基于边缘计算(如 Cloudflare Workers/Vercel/Netlify)的加速引擎,可以加速程序员网站的访问速度,比如将github.com域名替换成xget.xi-xu.me/gh。(@xixu-me 投稿)

12、BoxLite

一个 Python 库,可以在脚本中运行一个微型虚拟机,提供硬件隔离。(@DorianZheng 投稿)

13、Green Wall

生成你的 GitHub 年度报告。(@Codennnn 投稿)

14、edge-next-starter

面向出海项目的 Next.js + Cloudflare 全栈项目模板,集成 Edge Runtime、D1 数据库、R2 存储。(@TangSY 投稿)

AI 相关

1、Chaterm

带有 AI 功能的智能终端工具,可以用自然语言完成命令行操作。(@zhouyu123666 投稿)

2、miniCC

网友开发的 AI 编程工具 Claude Code 替代品,主要用于学习目的。(@Disdjj 投稿)

3、Android Trans Tool Plus

一个开源的纯前端应用,通过 AI 翻译安卓资源文件,支持多语言同步、差异校验。(@huanfeng 投稿)

4、octopus

个人用户的大模型 API 聚合工具,支持接入多个模型供应商,提供负载均衡、分组名称、使用量统计等功能。(@bestruirui 投稿)

5、Vexor

一个 Python 工具,对当前目录的文件进行向量嵌入,用来语义搜索。(@scarletkc 投稿)

6、Tada

开源的任务管理应用,带有 AI 总结功能。(@Leaomato 投稿)

资源

1、大模型原理(英文)

一篇相对好懂的大模型原理解释,文章不长,并且还有大量的互动图形,写得非常好,推荐阅读。

2、编程语言速度比较

这个网站使用不同的计算机语言,通过莱布尼茨公式计算 π 值,然后给出运行速度的排名,最快是 C++(clang++),最慢是 Python (CPython)。

3、更好的 ZIP 炸弹

这个网页提供三个 ZIP 炸弹文件的下载,其中最小一个只有 42KB,但是解压后的大小是 5.5GB。

图片

1、2025年最佳科学图片

《自然》杂志评选的一组2025年最佳科学图片。

两只争夺领地的青蛙。

南非废弃天文台长出的蘑菇。

2、帽子,乌龟和幽灵

2022年,一个业余数学家 David Smith 发现了一个有点像帽子的奇特形状。

这个形状的奇特之处在于,它可以无限不重复地铺满整个空间,且不形成周期性的重复图案。

不久后,他又发现了两种稍加变化的形状,称为乌龟和幽灵,也可以不重复地平铺平面。

下面就是这三种形状各自平铺的图案。

言论

1、

我使用氛围编程会感到疲惫,AI 生成代码的速度太快了,我的大脑跟不上,无法及时完成代码验收或审查。我必须休息一段时间,才能重新开始。

-- 《氛围编程疲劳》

2、

制造汽车是非常困难的一件事。一辆车大约有3万个独立零部件,公司可能只会采购3000个,因为像车头灯这样的部件,是作为一个整体采购的,但它实际上包含很多组件。

里面的二级、三级、四级供应商提供的零部件,任何一个出现问题都可能导致整车的问题。

-- 汽车创业公司 Rivian 的 CEO 专访

3、

数码世界的现状是,很多人(尤其是大多数老年人)已经放弃了抵抗,任由电子设备将他们带到任何地方。

因为一旦你想搞清楚电子设备的运作,就会发现,在便利的幌子下,一切都充满了敌意,暗箱操作无处不在,不可能完全理清。你想从它们手中夺回个人数据和隐私会非常艰苦,而且注定失败,最终只会带来更大的挫败感。

-- 《一切并非必然》

4、

现在的学生拥有前所未有的优质教育资源,但他们却陷入成千上万种选择中不知该学什么、该用什么资源的困境。拥有资源并不意味着就能找到方向。

-- 《不要关闭你的大脑》

5、

危险并非来自中国的崛起,而是美国的思维模式。如果把科学视为零和博弈,那么每一项中国专利看起来都像是美国的损失。但创意是非竞争性的:中国的科研突破不会让美国人变穷,而是会让世界变得更富有。多极化的科学世界意味着更快的增长、更大的财富和加速的技术进步。

-- 《中国的创新》

往年回顾

西蒙·威利森的年终总结,梁文锋的访谈(#332)

电动皮卡 Cybertruck 的 48V 供电(#282)

好用的平面设计软件(#232)

新人优惠的风险(#182)

(完)

直接导航——即在浏览器中手动输入域名访问网站的行为——正面临前所未有的风险:一项新研究发现,绝大多数"停放"域名(主要是过期或闲置域名,以及热门网站的常见拼写错误)现在都被配置为重定向访问者至推送诈骗和恶意软件的网站。

2025年10月,一个仿冒FBI网络犯罪投诉中心的域名在桌面端显示无威胁的停放页面(左图),而移动用户则被立即导向欺诈内容(右图)。图片来源:Infoblox。

当互联网用户尝试访问过期域名或意外导航至仿冒的"域名抢注"网站时,他们通常会被带到域名停放公司的占位页面。这些公司通过展示付费第三方网站的链接,试图从这些误入流量中获利。

十年前,访问这些停放域名后被重定向到恶意网站的概率相对较低:2014年,研究人员发现(PDF)停放域名将用户重定向至恶意网站的概率不到5%——无论访问者是否点击了停放页面上的任何链接。

但在过去几个月的系列实验中,安全公司Infoblox的研究人员表示,他们发现情况现已逆转,恶意内容目前已成为停放网站的常态。

"在大规模实验中,我们发现超过90%的情况下,访问停放域名的用户会被导向非法内容、诈骗、恐吓软件和杀毒软件订阅,或恶意软件。这是因为点击流量从停放公司出售给广告商,而广告商通常又将这些流量转售给第三方,"Infoblox研究人员在今天发布的论文中写道。

Infoblox发现,如果访问者使用虚拟专用网络(VPN)或非住宅IP地址访问网站,停放网站是良性的。例如,Scotiabank.com的客户若将域名误输为scotaibank[.]com,使用VPN时会看到正常的停放页面,但若使用住宅IP地址访问,则会被重定向至试图推送诈骗、恶意软件或其他不良内容的网站。同样,仅需使用住宅IP地址的移动设备或台式电脑访问拼写错误的域名,就会触发此重定向。

据Infoblox称,scotaibank[.]com的所有者拥有近3000个仿冒域名组合,包括gmai[.]com。该域名已被证实配置了自己的邮件服务器以接收传入的电子邮件。这意味着,如果您向Gmail用户发送电子邮件时不小心漏掉了"gmail.com"中的字母"l",这封邮件不会消失在以太网中或产生退信回复:它会直接发送给这些诈骗者。报告指出,该域名还在近期多起商业电邮入侵攻击中被利用,使用附带木马恶意软件的付款失败诱饵。

Infoblox发现,这个特定的域名持有者(通过一个共同的DNS服务器——torresdns[.]com暴露)已针对数十个顶级互联网目标设置了域名抢注域名,包括Craigslist、YouTube、Google、Wikipedia、Netflix、TripAdvisor、Yahoo、eBay和Microsoft。这些域名抢注域名的无害列表可在此处查看(所列域名中的点已替换为逗号)。

Infoblox的威胁研究员David Brunsdon表示,停放页面会引导访问者经过一系列重定向链,同时使用IP地理位置、设备指纹识别和Cookie来分析访问者的系统,以确定将域名访问者重定向至何处。

"在威胁到达之前,通常存在一个重定向链——停放公司之外的一到两个域名,"Brunsdon说。"每次交接时,设备都会被反复分析,然后被传递到恶意域名,或者如果他们认为不值得作为目标,则传递到像Amazon.com或Alibaba.com这样的诱饵页面。"

Brunsdon称,域名停放服务声称他们在停放页面上返回的搜索结果旨在与其停放域名相关,但他们测试的显示内容几乎都与仿冒域名无关。

访问scotaibank.com时的重定向路径示例。每个分支包括观察到的系列域名,包括颜色编码的着陆页。图片来源:Infoblox。

Infoblox表示,另一个拥有domaincntrol[.]com的威胁行为者(该域名与GoDaddy的名称服务器仅差一个字符)长期以来一直利用DNS配置中的拼写错误将用户导向恶意网站。然而,最近几个月,Infoblox发现恶意重定向仅发生在使用Cloudflare DNS解析器(1.1.1.1)的访问者查询配置错误的域名时,而所有其他访问者将收到一个拒绝加载的页面。

研究人员发现,即使是知名政府域名的变体也成为恶意广告网络的目标。

"当我们的一位研究人员试图向FBI的网络犯罪投诉中心(IC3)报告犯罪时,他们不小心访问了ic3[.]org而不是ic3[.]gov,"报告指出。"他们的手机很快被重定向到一个虚假的'Drive Subscription Expired'页面。他们很幸运只遇到了诈骗;根据我们的了解,他们同样可能轻易地收到信息窃取程序或木马恶意软件。"

Infoblox报告强调,他们追踪的恶意活动并未归因于任何已知方,并指出研究中提及的域名停放或广告平台与他们记录的恶意广告活动无关。