2026年2月

导语: 当全球科技巨头争相推出 AI 助手时,一个更激动人心的可能性正在悄然兴起——创建真正属于你个人的 AI 智能体。本文将带你踏上从0到1的智能体搭建之旅,揭开 AI 数字分身的神秘面纱。

第一部分:智能体新纪元的黎明

AI 智能体与传统 AI 的核心差异在于其自主性交互性

  • 传统 AI:如同功能单一的工具。
  • 智能体:像拥有独立思考能力的数字存在,能学习你的偏好,适应你的需求。

想象一下你的数字分身:

  • 会议助手:了解你的工作习惯,在会议前自动整理相关资料。
  • 健康管家:熟悉健康数据,在睡眠异常时主动提出建议。
  • 创作伙伴:理解你的风格,协助你完成从草稿到成品的全流程。

第二部分:构建三部曲 —— 从骨架到灵魂

️ 第一阶段:基础框架搭建(骨架)

智能体的骨架由三个核心组件构成:

  1. 决策中枢: 智能体的“大脑”,负责处理信息、做出判断。开源框架如 LangChain 或 AutoGPT 是绝佳的起点。
  2. 记忆系统: 让智能体记住互动历史。向量数据库(如 ChromaDB)能让其建立长期记忆,理解上下文。
  3. 行动接口: 通过 API 与外部世界互动,赋予智能体改变现实的能力(如查询天气、控制家居)。
搭建实操: 使用 Python 构建基础智能体仅需不到 50 行代码。初期切勿追求“全能”,应专注单一场景的深度服务。

第二阶段:个性化训练(性格)

这是赋予智能体独特“性格”的关键:

  • 数据收集策略: 从电子邮件、日程安排到创作笔记。注意:始终将隐私保护置于首位,敏感信息需脱敏处理。
  • 微调方法论: 基于开源大模型(如 Llama、ChatGLM),通过提示工程(Prompt Engineering)让智能体掌握你的语言风格和决策偏好。

第三阶段:场景化部署(应用)

智能体的价值在于解决实际问题,考虑以下部署方向:

智能体类型功能核心
知识管理型整合笔记、书签和阅读历史,构建个人知识图谱
创作协作型协助完成从头脑风暴到文稿润色的完整流程
专业辅助型针对编程、设计、写作等领域提供深度支持

第三部分:智能体伦理与未来演进

⚖️ 责任与边界

构建个人 AI 智能体时,责任边界必须清晰界定。智能体应是增强人类能力的工具,而非替代人类判断的权威。设置明确的权限层级和人工复核机制至关重要。

未来愿景

个人智能体的互联将催生全新的协作网络:

  • 你的研究型智能体与同事的分析型智能体直接对话。
  • 你的健康管理智能体与医疗系统安全交互。

终极愿景: 培育理解我们、尊重我们、增强我们的数字伙伴。


启程时刻

搭建个人 AI 智能体的门槛正在迅速降低。无需顶尖技术背景,关键是:

  1. 清晰的规划
  2. 分阶段的实施
  3. 对本质的理解

今天,从定义一个简单的任务开始:创建一个帮你整理每日资讯的智能体。每一步构建,都是与你未来数字分身的一次对话。

你的智能体故事,始于第一个问题: “我希望我的数字分身如何增强我的生活?”

本文章内容和图片由AI辅助生成

在跨境电商、海外营销或日常学习中,Google 账号(Gmail)一直是通往海外互联网世界的“基础设施”。

尤其是最近一年,随着 ChatGPT、Gemini、Claude、Midjourney 等顶尖 AI 模型的爆发式增长,国内用户对 Google 账号的需求呈现井喷之势。 想要体验最前沿的 AI 生产力工具,或是申请 API、使用第三方 AI 服务,一个稳定的 Google 账号往往是必不可少的“硬通货”和快捷登录(SSO)的“金钥匙”。

然而,许多朋友发现,现在的 Google 账号变得前所未有的“娇气”——

  • 刚为了用 AI 注册的新号,还没登录进去就显示“已停用”;
  • 登录一下就要手机验证,验证了还通过不了;
  • 甚至用了几年的老号,也在这波风控潮中莫名“阵亡”。

这背后的核心原因,正是因 AI 需求暴增导致的 Google 风控系统(Risk Control)全面应激升级。为了抵御大规模的脚本注册和滥用,Google 祭出了更智能的算法,全自动无差别地检测账号的“异常行为”。

今天就来复盘:账号为什么容易被封?如何科学保号?万一被封了该如何申诉?


第一部分:排雷篇——你的账号为什么会被封?

根据 Google 最新的风控逻辑,封号原因主要归结为以下五大类。其中,网络环境的不纯净是绝大多数人“踩雷”的根本原因。

1. 登录环境与 IP 的“致命伤” (最核心原因)

Google 的安全系统对 IP 地址及其背后的行为轨迹极度敏感。

  • IP 频繁“瞬移”: 如果你的账号在短时间内跨越国界(例如:上午在美国 IP,下午变成了日本 IP),系统会直接判定为账号被盗或异常。
  • 使用了“被污染”的共享 IP: 很多廉价或免费的代理工具(机场)使用的是万人共享的 IP 池。如果这个 IP 之前被人用来大规模注册账号薅羊毛,你的账号会因为“连坐机制”被牵连封禁。
  • 设备环境混乱: 频繁在手机、电脑、平板间切换,且混合使用家庭 WiFi、热点和公共网络,极易触发安全警报。

2. 成品号的“源头原罪”

为了快速使用 AI 工具,很多人选择购买现成的“成品号”,但这风险极高:

  • 批量注册的风险: 号商通常利用脚本和虚拟信用卡批量生成账号。一旦关联的虚拟卡被风控,成千上万个关联账号会瞬间失效。
  • 历史污点: 你买到的号可能已经被用过(如刷 YouTube 播放量),早已在系统的“黑名单”边缘。

3. 像“机器人”一样的机械操作

Google 的算法非常擅长识别非人类行为:

  • 高频操作: 短时间内大量发邮件、加好友、建频道。
  • 缺乏真实互动: 新号没有经过“养号”,上来就直接授权登录各类 AI 平台,没有正常的搜索浏览记录。
  • 设备群控: 同一台电脑/手机上频繁切换登录多个账号。

4. 内容与政策违规

这是硬伤,包括在 YouTube 或 Blogger 发布违规内容(暴力、色情、侵权),或发送垃圾邮件骚扰他人。

5. 账号长期处于“亚健康”状态

  • 僵尸号: 注册超过 3 个月未登录。
  • 安全裸奔: 未开启两步验证(2FA),导致账号权重极低。

第二部分:实操篇——如何科学“保号”?

保号的核心逻辑只有一个:让 Google 相信你是一个真实、稳定、高价值的用户,而不是一个等待注册 AI 接口的机器人。

1. 打造“铜墙铁壁”的网络环境

  • 固定 IP 是王道: 尽量使用静态住宅 IP,拒绝频繁变动的动态 IP。
  • 拒绝“瞬移”: 保持登录地区的一致性。
  • 物理隔离: 坚持 “一机一号” 原则。如果有多个账号,强烈建议使用指纹浏览器(如 AdsPower)来隔离设备指纹,防止关联。

2. 完善安全设置(提升权重)

  • 开启两步验证 (2FA): 这是保号的护身符。建议使用 Google Authenticator App,比短信验证更安全稳定。
  • 绑定辅助信息: 务必填写真实的辅助邮箱和手机号,这是找回账号的唯一救命稻草。
  • 清理授权: 定期检查并撤销不明来源的第三方应用授权。

3. 模拟真人的“碎片化”操作

不要像机器一样批量工作。刷 YouTube 时记得点赞、收藏;搜索时模拟正常浏览。敏感操作(如改密、绑卡)之间至少间隔 24 小时。

4. 科学养号“三部曲”

对于新号或刚买的成品号,请严格执行以下养号流程,再通过 OAuth 登录 AI 工具:

  • 初期(1-7天):建立信任。 每天登录 30-60 分钟,仅做基础搜索、浏览新闻、看 YouTube 视频(>5分钟)。严禁修改密码和资料。
  • 中期(8-30天):丰富行为。 开始点赞评论、使用 Google Drive 上传文件、用 Maps 查路线。此时可完善两步验证。
  • 长期(30天+):维持权重。 每周保持 3-5 次活跃登录,尝试发布原创内容(博客或视频)以提升账号贡献值。

第三部分:急救篇——账号被封了如何申诉?

如果不幸收到“账号已停用”的通知,不要慌张,按照以下步骤进行“心肺复苏”。

1. 寻找申诉入口

  • 情况 A:未收到邮件,登录受阻。
    手动打开 Google 账号恢复页面。这通常需要经历繁琐的人机验证(可能长达半小时),需要极大的耐心。
  • 情况 B:收到停用通知邮件(推荐)。
    直接点击邮件中的申诉链接。这种方式可以跳过人机验证,直接进入正题,成功率通常更高。

2. 撰写“高成功率”的申诉理由

在填写申诉表单时,请遵循以下原则:

  • 使用英文: 虽然中文也可以,但英文模板能让全球审核团队更快处理。
  • 态度诚恳: 简短、真实、礼貌。
  • 话术建议: 强调账号对你工作/学习的重要性。如果你使用了代理,可以委婉表达为“因出差或网络加速需求导致环境波动”,并保证自己一直遵守 Google 服务条款。
  • 联系邮箱: 留一个干净、常用的非 Gmail 邮箱接收结果。

3. 等待与后续

  • 审核周期: 通常为 1-2 天。在此期间,切勿频繁尝试登录,否则会增加恢复难度。
  • 坚持尝试: 如果第一次被拒,不要气馁。稍微修改措辞,补充更多细节(如设备变化说明),尝试申诉 2-3 次。不同的审核人员尺度可能不同。

4. 解封后的加固

账号一旦找回,立即在干净、稳定的网络环境下登录,完成手机/邮箱验证,并立刻开启两步验证,防止“二进宫”。


最后总结:
在 AI 时代,Google 账号不仅仅是一个邮箱,更是我们接触世界前沿科技的身份 ID。“少折腾、多稳定、真实化”是保号的九字真言。与其被封后焦头烂额地申诉,不如现在就动手检查一下你的账号环境和安全设置吧!

本文由mdnice多平台发布

2026 年的 Node.js 已经不是那个你认识的 Node.js 了。

过去需要几十个依赖项和复杂配置才能实现的功能,现在都可以开箱即用。

原生的 TypeScript 支持、内置的 AI 能力、默认 HTTP/3 协议,以及真正有效的权限模型,这些都已经将 Node.js 从一个运行时环境转变成一个完整的平台。

如果你最近没有使用过 Node.js,那你很有可能错过了这些功能。

本篇让我们深入探讨这些已经发生的变化以及它们的重要性。

1. 原生 TypeScript 类型剥离:游戏规则改变者

Node.js 最具变革性的新增功能是通过类型剥离实现的原生 TypeScript 支持

不再需要 ts-nodetsx 或复杂的构建配置,你只需要:

node --experimental-strip-types app.ts

就是这样,一个参数,你就可以直接在 Node.js 中运行 TypeScript。

// server.ts - 使用类型剥离直接运行
import { createServer } from "node:http";

interface User {
  id: number;
  name: string;
  email: string;
}
class UserDatabase {
  private users: Map<number, User> = new Map();

  addUser(user: User): void {
    this.users.set(user.id, user);
  }

  getUser(id: number): User | undefined {
    return this.users.get(id);
  }
}
const db = new UserDatabase();
const server = createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(JSON.stringify(db.getAllUsers()));
});
server.listen(3000);
类型剥离的工作原理;

与传统 TypeScript 编译不同,类型剥离非常优雅和简单:

  1. 解析 TypeScript 文件
  2. 移除 类型注解、接口和仅用于类型的构造
  3. 执行 生成的 JavaScript

这使得类型剥离 比完整 TypeScript 编译快 10-20 倍,因为没有类型检查、没有转换——只是移除类型语法。

// ❌ 旧方式 - 需要转换
enum Status {
  Active,
  Inactive,
}

// ✅ 新方式 - 支持类型剥离
const Status = { Active: "ACTIVE", Inactive: "INACTIVE" } as const;
type Status = (typeof Status)[keyof typeof Status];

开发时(即时刷新):

node --experimental-strip-types --watch server.ts

生产时(单独类型检查):

tsc --noEmit  # 仅类型检查
node --experimental-strip-types server.ts

注意:类型剥离不会取代类型检查——它只是在开发过程中消除了编译瓶颈。

TypeScript支持

2. HTTP/3 & QUIC:默认加速

HTTP/3 支持现已稳定并默认启用。

import { request } from "node:http";

const req = request("https://api.example.com/data", (res) => {
  console.log("Protocol:", res.httpVersion); // 3.0
  res.on("data", (chunk) => console.log(chunk.toString()));
});
req.end();

使用它的优势在于:

  • 速度提升:实际环境下响应速度提升 20%–50%
  • 连接迁移:WiFi 和蜂窝网络之间的无缝切换
  • 无队头阻塞:比 HTTP/2 具有更好的多路复用性能
  • 内置加密:QUIC 强制使用 TLS 1.3。

HTTP/3加速

3. 原生 WebGPU 用于 AI/ML 工作负载

WebGPU API 支持在 Node.js 中直接进行 GPU 加速计算。

import { GPU } from "node:webgpu";

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();
// Run matrix operations on GPU for AI inference
const computeShader = `
  @compute @workgroup_size(256)
  fn main(@builtin(global_invocation_id) id: vec3<u32>) {
    output[id.x] = tanh(input[id.x]);
  }
`;

你可以用于:

  • 本地 LLM 推理(Llama、Mistral 模型)
  • 图像/视频处理
  • 实时数据分析
  • 科学计算

这使得 Node.js 可以用于以前需要 Python 或原生绑定才能运行的 AI/ML 工作负载。

WebGPU AI能力

4. 权限模型:细粒度安全

稳定的权限模型使你可以对运行时访问权限进行精细控制。

# Restrict file system and network access
node --allow-fs-read=./data --allow-net=api.example.com app.js

# Disable child processes
node --no-allow-child-process app.js
import { readFile } from 'node:fs/promises';

try {
  const data = await readFile('/etc/passwd', 'utf-8');
} catch (err) {
  console.log('Access denied:', err.code); // ERR_ACCESS_DENIED
}

非常适合运行不受信任的代码、具有最小权限的微服务,以及具有安全约束的边缘部署。

5. 内置 SQLite 增强功能

原生 SQLite 支持已经成熟,具有流式传输和性能优化。

import { DatabaseSync } from "node:sqlite";

const db = new DatabaseSync("./app.db");

db.exec(`CREATE TABLE IF NOT EXISTS users ( 
  id INTEGER PRIMARY KEY, 
  name TEXT, 
  email TEXT UNIQUE
)`);

const insert = db.prepare("INSERT INTO users (name, email) VALUES (?, ?)");
insert.run("Alice", "alice@example.com");

// 新增:用于大数据集的流式传输
const stream = db.prepareStream("SELECT * FROM large_table");

for await (const row of stream) {
  console.log(row);
}

使用它的优势在于:

  • 批量插入速度提升 10 倍
  • 流式 API 提高内存效率
  • 更好的错误处理
  • 自动连接池

内置SQLite

6. 环境文件和配置

--env-file 标志现在支持多个文件,并内置了验证功能。

node --env-file=.env --env-file=.env.local app.js

验证功能:

import { env } from "node:process";

// 内置架构验证(2026 年新增)
const config = env.validate({
  PORT: { type: "number", default: 3000 },
  DATABASE_URL: { type: "string", required: true },
  DEBUG: { type: "boolean", default: false },
  API_KEYS: { type: "array", separator: "," },
});

console.log(config);
// { PORT: 3000, DATABASE_URL: '...', DEBUG: false, API_KEYS: ['key1', 'key2'] }

不再需要 dotenv 包。配置验证是内置的。

7. 监视模式的演进

监视模式现在更智能,具有可配置的行为和模式匹配:

# 带去抖动的监视
node --watch=500ms server.js

# 监视特定模式
node --watch='src/**/*.js' --watch='config/*.json' app.js
# 重启时保留输出
node --watch --watch-preserve-output server.js
# 与 TypeScript 结合
node --experimental-strip-types --watch server.ts

编程式监视 API:

import { watch } from "node:fs";

for await (const event of watch("./src", { recursive: true })) {
  console.log(`${event.filename} was ${event.eventType}`);
  // 自定义重新加载逻辑
}

不再需要 nodemon,监视模式可以处理从开发到测试的所有环节,并提供精细的控制。

8. 内置测试运行程序成熟度

原生测试运行程序在功能上已经可以与 Jest 和 Mocha 相媲美。

import { test, describe, beforeEach, mock } from "node:test";
import assert from "node:assert";

describe("User API", () => {
  beforeEach(() => {
    db = createTestDB();
  });

  // 快照测试内置
  test("user response format", async () => {
    const user = await fetchUser(1);
    assert.snapshot(user);
  });

  // 无需库的模拟
  test("handles API failure", async () => {
    const mockFetch = mock.fn(fetch, async () => {
      throw new Error("Network error");
    });

    await assert.rejects(() => syncUserData(), /Network error/);
    assert.strictEqual(mockFetch.mock.calls.length, 3);
  });

  // 默认并行执行
  test.concurrent("test 1", async () => {
    /* ... */
  });
  test.concurrent("test 2", async () => {
    /* ... */
  });
});

带覆盖率运行:

node --test --experimental-test-coverage --test-reporter=spec

输出:

✓ User API > user response format (2ms)
✓ User API > handles API failure (15ms)
✓ User API > test 1 (45ms)

Coverage: 87.5% (70/80 lines)

功能包括快照测试、内置模拟、并行执行和代码覆盖率——无需安装 Jest、Mocha 或 Sinon。

9. 增强的工作线程

工作线程现在支持 SharedArrayBuffer,并且 API 更简单。

import { Worker } from "node:worker_threads";

const sharedBuffer = new SharedArrayBuffer(1024);
const sharedArray = new Int32Array(sharedBuffer);

const worker = new Worker(
  `
  import { parentPort, workerData } from 'node:worker_threads';
  const array = new Int32Array(workerData.buffer);
  
  for (let i = 0; i < 1000; i++) {
    Atomics.add(array, 0, 1);
  }
  
  parentPort.postMessage('done');
`,
  { eval: true, workerData: { buffer: sharedBuffer } },
);

worker.on("message", () => {
  console.log("Counter:", sharedArray[0]); // 1000
});

新的工作线 API:

import { WorkerPool } from "node:worker_threads";

const pool = new WorkerPool("./compute-worker.js", { size: 4 });
const results = await Promise.all(tasks.map((task) => pool.exec(task)));

await pool.close();

10. 现代 ECMAScript 特性

Node.js 2026 版本稳定支持最新的 JavaScript 特性:

Records & Tuples(不可变数据):

const user = #{ id: 1, name: "Alice" };
const updated = #{ ...user, name: "Alice Smith" };
console.log(#{ a: 1 } === #{ a: 1 }); // true!

管道操作符

const result = userId |> fetchUser |> validateUser |> transformData |> saveToDatabase;

模式匹配

const handle = (res) => match (res) {
  when ({ status: 200, data }): data,
  when ({ status: 404 }): null,
  when ({ status: s }) if (s >= 500): throw new Error('Server error'),
  default: throw new Error('Unknown')
};

11. 总结

Node.js 在 2026 年不仅仅是一个增量更新——它是一个范式转变:

原生 TypeScript = 开发无需构建工具\
类型剥离 = 比编译快 10-20 倍\
HTTP/3 = 实际性能提升\
WebGPU = 无需 Python 的 AI/ML\
权限模型 = 生产级安全\
内置 SQLite = 无依赖数据库\
环境验证 = 不再需要 dotenv\
智能监视模式 = 不再需要 nodemon\
测试运行器 = 不再需要 Jest/Mocha\
现代 JavaScript = records、tuples、管道、模式匹配

旧版 Node.js 需要 50 多个软件包才能高效运行。新版 Node.js 内置了大部分所需功能,并且集成度更高,性能更佳。

于是实现了更少的依赖、更快的开发、更好的安全,以及以前不可能实现的新能力。

如果你还没在 2026 年探索过 Node.js,现在正是时候。这个平台已经发生了根本性的变革,过去的种种限制早已不再适用。

我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。

就是下图这样京东的商品推荐通知,它是自动展开的(我并没有点开它),淘宝偶尔也有,目前看到过的就京东和淘宝。京东的是第一次见,淘宝大概每两三天就能看到一次。很恶心,跟狗皮膏药似的。

我有两个问题。
第一个是如何关掉它。
第二个是想了解下,这种通知是和手机厂商合作的运营的吗,感觉不像正常的通知
(标题以及下面的 3 个可以点的跳转链接和京东其他通知样式不一样)

手机是 iQOO 15, 系统是 Origin OS 6

Clawdbot之父:我从不读自己的代码

本文共 2979 字,阅读预计需要 4 分钟。

Hi,你好,我是Carl,一个本科进大厂做了2年+AI研发后,裸辞的AI创业者。

一个退休3年的开发者,同时操控10个AI工具,用AI Agent实现一天600个Commit,甚至发布自己没读过的代码。

他的项目Clawdbot(现在改名OpenClaw了)两周暴涨到几万星,现在已超9万星。

这是Clawdbot之父Peter Steinberger给所有程序员上的一课:

问题从来不是"AI会不会取代我",而是"我怎么和AI一起干活"。

一天600个Commit?他是认真的

说实话,当我第一次看到这个数字,我以为是标题党。

一天600个Commit,还发布自己没读过的代码。这不是草率,这是疯了吧...

但Peter Steinberger就是这么干的。

这哥们的工作方式像极了国际象棋大师的车轮战:同时开着5到10个AI Agent,在任务之间不停切换。设计一个新子系统?他知道Codex需要40分钟到1小时来完成构建,所以先把规划敲定、启动任务,然后立刻跳到下一件事。

他就像个厨神一样,等这边"炖着",他去处理那边。那边"炖着",他又去处理另一件。转一圈回来,第一个任务刚好出锅。

这种并行工作的节奏,让他凌晨5点还在跟Claude较劲。在他看来,Claude的输出像老虎机——你投入一个prompt,要么开出一堆废铁,要么中个头彩。

问题来了:这种看起来疯狂的工作方式,为什么能跑通?

闭环才是秘诀:让AI自己验证自己

Peter能"不读代码就发布",靠的不是运气,是一套完整的验证闭环。

在他的工作流里,AI必须能"自证清白"——代码写完只是开始,能编译、能通过代码规范检查、能执行、能验证输出,这四道关卡缺一不可。

这就像工厂的质检流水线。原材料进来,不是直接出厂,而是经过层层检测:尺寸对不对、颜色对不对、功能对不对。每一道工序都有自己的验收标准。

AI写代码也一样。

代码写完不是终点,compile通过才算第一关,lint检查是第二关,单元测试是第三关,集成测试是第四关。

Peter的逻辑很简单:只要验证循环跑通了,测试全部通过,他就选择信任AI的输出。

为什么不呢?规范的检查,规范的测试流程,最后的稳定性也许能胜过90%以上的人写的代码。

有一次Peter在摩洛哥旅行,用WhatsApp给他的Agent发了条语音消息——完全是下意识的动作,因为他压根没给Agent开发过语音识别功能。

半分钟后,Agent居然回复了。

Peter懵了,追问它怎么做到的。Agent的回答让他目瞪口呆:它自己检测到文件头是OGG音频格式,主动调用FFmpeg做格式转换,然后翻出电脑里存着的OpenAI API密钥,把音频发到OpenAI的语音转文字服务,最后才给出回复。

没有人教它这么做。它自己把整个链路串起来了。

这就是闭环的力量:你不需要告诉AI每一步怎么做,只需要给它目标和验证标准,它会自己找到路径。

Pull Request已死,Prompt Request当道

Peter的工作流里,传统代码审查已经成了历史。

他给代码提交起了个新名字:不叫Pull Request,叫Prompt Request。

理由很直接:别人提交代码时,他最想看的不是代码本身,而是生成这段代码的prompt长什么样。

这个观点值得仔细考虑,如同我常说现在spec规格说明才是代码,而代码本身是编译产物一样。

传统开发里,代码是核心交付物。你写代码,我审代码,我们讨论代码。

但在AI时代,prompt才是核心资产。

好的prompt可以让AI生成无数版本的代码;而代码本身,反而是可以随时重新生成的"易耗品"。

Peter甚至会直接拒绝一些只修了几个小bug的PR。他的理由是:

人工审查这种小修小补的代码,花的时间可能是让Codex直接修复的10倍。

与其浪费时间审代码,不如把问题描述清楚,让AI重新生成。

这对程序员意味着什么?

技能重心正在发生位移。从"写代码"转向"写需求",从"实现细节"转向"架构设计",从"逐行审查"转向"验收结果"。

三类程序员,谁最适合AI时代?

Peter观察到一个有趣的规律:那些痴迷于算法难题的工程师,反而很难适应AI驱动的开发。

道理不难理解:如果你最享受的是Leetcode式的解题快感,那AI时代会让你很痛苦——你不再需要亲手推导动态规划、手写红黑树,AI几秒钟就搞定了。那种"我亲手攻克难题"的成就感,被彻底剥夺了。

反过来,如果你真正在乎的是把产品交付出去,关心的是最终结果而非实现路径,那AI时代简直是如鱼得水。

第三类人更有意思:带过团队的人

管理者天然具备一种能力:放下完美主义,接受"足够好"的交付物。

Peter认为,这恰恰是和AI协作的核心心态。你要先保证完整性,再考虑是否完美。

管理者习惯了"委托"与"验收":你不需要亲自写每一行代码,只需要把需求讲清楚、把验收标准定好、然后检查交付物。这恰恰是和AI协作的核心能力。

还有一个反直觉的观察:新人可能有逆袭机会

Peter的解释是:新人没有被过往经验"污染"。老程序员会下意识觉得"这个方法行不通",但新人不知道这些禁忌,反而会用老鸟想不到的方式驱动Agent——而在AI快速进化的当下,很多"行不通"的事情,可能已经行得通了。

从CEO到单人军队:Peter的燃尽与重生

Peter Steinberger不是什么"野生程序员"。

他来自奥地利农村,14岁入坑编程。后来花了13年打造PSPDFKit,这是一个最终用在超过10亿台设备上的PDF渲染框架,。公司从他一个人,发展到70多人,全球远程办公。

但CEO不好当。

用Peter自己的话说,CEO本质上就是个"兜底的人",团队搞不定的、搞砸的,最后全得创始人来收拾。

这种压力持续太久,Peter彻底燃尽了。他卖掉股份,从科技圈消失了整整三年。

那三年,他需要很长时间来解压。他参加了大量派对,过上了完全远离科技的生活——有好几个月,他甚至没有打开过电脑。

2025年4月,Peter重新打开电脑。

他想做一个Twitter分析工具,但发现自己根本不会Web开发。然后他发现了AI。

他把一个1.3MB的GitHub仓库Markdown文件拖进Gemini,输入"写个说明",AI输出400行规格说明。然后他把规格说明拖进Claude Code,输入"build"。然后不停地点continue、continue、continue...

最后AI信心满满地宣布:100%生产就绪。

Peter一启动程序,直接崩了。

但这次失败反而点燃了他。**程序虽然崩了,但AI展现出的潜力已经足够震撼。**它确确实实地,在几分钟内完成了一个他可能需要几周才能写出的原型。

从那一刻起,Peter开始失眠。他意识到一场革命正在发生,而他不想错过。

OpenClaw爆红:未来Siri该有的样子

Clawdbot(现已更名OpenClaw)最初只是Peter给自己搭的一个私人助手,通过WhatsApp跟他对话。

他在摩洛哥旅行时,用它导航、听笑话、甚至代发消息给朋友——那时候它还只是个"玩具"。

后来他做了一个疯狂的决定:把自己的Agent放到了公开的Discord里,让任何人都能体验。

结果完全超出预期——几乎所有试用过几分钟的人都上瘾了。更夸张的是,在这几天,它的谷歌搜索量一度超过了Claude Code和Codex的总和。

现在star数已破9万,还在涨,极为罕见的增长速度。

这个项目支持WhatsApp、Telegram、Slack、Discord、Signal、iMessage等十几个渠道,能语音唤醒,能实时画布,能多Agent路由。它不是"半吊子Siri",而是一个真正理解上下文、能自主解决问题的个人AI助手。

这才是未来个人助手该有的样子。

写在最后:给AI时代开发者的3个建议

Peter用自己的经历证明了一件事:问题从来不是"AI取代程序员",而是"程序员如何与AI融合"。

代码本身不重要,闭环才重要。

实现细节不重要,系统设计才重要。

Pull Request不重要,Prompt Request才重要。

这是一个单人开发者展现出团队级产出的时代。超级个体的时代。

建议1:构建你的验证闭环

无论用什么AI工具,都要建立compile/lint/test/deploy的自动化流水线。闭环是信任AI的前提。

建议2:保持架构敏感度

代码可以交给AI,但模块划分、技术选型、扩展性设计必须自己把控。这是AI时代程序员的核心竞争力。

建议3:学会写需求,而不只是写代码

Prompt质量决定输出质量。花时间学习如何把需求讲清楚、把验收标准定精确,这比学习新框架更重要。

这个时代,才刚刚开始。

既然看到这了,如果觉得不错,随手点个赞、收藏、转发三连吧~

我是Carl,大厂研发裸辞的AI创业者,只讲能落地的AI干货。

关注我,更多AI趋势与实战,我们下期再见!

模力工场新鲜事

  • 在 AI 狂飙的时代,追逐技术热点之外,什么才是决定未来生存的底层法则?2 月 9 日(下周一)晚 17:30,锁定模力工场视频号直播间,创始人霍太稳将与一位神秘重磅嘉宾一同开讲,带你穿透技术喧嚣,抓住 AI 洪流中真正决定长期价值的“慢变量”。欢迎扫码预约,直播间不见不散!

031 周上榜应用精选(附用户热评)

模力工场 31 周 AI 应用周榜来啦~本周共有 31 款应用上架新榜,所有排名均来自用户真实使用、测评与社区讨论热度。本期用户热评清晰地指出:当前 AI 工具在流程自动化(如蓝耘星河、ClawdBot)和结构化生成(如 AI 快研侠、Lovable)上已相当成熟,堪称“数字同事”。而在信息深度整合实时性处理方面,仍有明确的进步空间。同时,AI 正向更感性、更内在的体验领域延伸,预示着技术发展的下一个前沿。

我们从中精选出十款最具声量的应用,聚焦五大垂直领域,为你更详细地解读榜单背后的 AI 行业风向。

一、营销与内容创作类

1.蓝耘星河营销智能体 📍 北京

关键词:AI Agent|营销增长|新媒体创作

小 A 推荐:一款面向自媒体和营销场景的 AI 智能体,旨在提供从策划到生成的一站式内容解决方案。

蓝耘星河更像一套为自媒体打造的内容生产流水线,流程和形式设计成熟,可以根据应用场景和目标人群,一键生成文案和图文内容。生成结果标题抓人、分段清晰,整体已经是可以直接发布的新媒体状态。但在涉及实时信息的测试中,内容时效性和逻辑性偏弱,存在依赖历史资料拼接的问题,更适合风格化内容生产,而非高时效、强专业场景。【用户热评|@宇】

2.醒图

关键词:图像设计|新媒体创作

小 A 推荐:一款强大的 AI 图像处理与设计工具,帮助用户快速生成和编辑高质量的视觉内容。

二、研究、阅读与信息处理类

1.AI 快研侠📍 深圳

关键词:AI 搜索问答|AI Agent|办公效率

小 A 推荐:专注于快速生成行业研究报告的 AI 工具,支持资料上传、大纲构建与内容溯源。

输入主题即可生成完整研究大纲,上传资料后能快速产出数万字结构化报告,并支持参考资料溯源,核对数据方便。整体生成效率高、价格友好,适合个人和小团队使用。在行业研究中发现部分数据存在滞后,更适合做结构整合型研究,可结合实时数据工具使用。【用户热评|@墨鱼罐头】

2.语鲸

关键词:生活方式类|信息聚合

小 A 推荐:一款聚合多平台、多格式信息的 AI 阅读助手,通过智能聚合与摘要提升阅读效率。

聚合公众号、播客、论文、研报等多源信息,支持 RSS 和自定义频道,同一主题内容会自动聚合成专题,明显减少信息重复。PC 端适合选题调研和深度阅读,APP 端以日报和订阅管理为主,目前在流畅度和 AI 总结体验上仍有优化空间。【用户热评|@迷龙】

三、办公效率与智能助手类

1.ClawdBot(moltbot)

关键词:办公效率|AI Agent|自部署智能助手小 A 推荐:一款可本地部署的企业级 AI 助手,旨在深度集成工作流,执行自动化任务。

一句话即可完成邮件总结、数据分析、日报生成,还能自动写代码并提交 PR,更像一个 24 小时待命的数字同事。由于权限较高,使用时需要隔离部署以确保安全,如果未来能做到更低门槛和开箱即用,效率提升空间非常大。【用户热评|@请务必优秀】

2.Chatbox AI

关键词:办公效率|教育学习|多模型 AI 客户端小 A 推荐:集成了多种主流大模型的桌面客户端,为用户提供统一、便捷的 AI 对话体验。

四、开发与应用生成类

1.Lovable

关键词:AI Agent|应用构建|无代码全栈应用生成

小 A 推荐:一款通过自然语言描述即可生成完整可运行全栈应用的开发平台。

通过自然语言即可生成完整的前后端和数据库,支持登录、存储等基础功能,修改方式直观、实时生效。无需安装开发环境,一键部署并支持 GitHub 与域名绑定,适合非技术用户做产品原型,也能帮开发者节省基础搭建时间。【用户热评|@清风】

2.Replit

关键词:开发者工具|云端 AI 开发平台

小 A 推荐:Replit 将开发环境、协作工具与 AI 辅助编程深度融合在云端。它让开发者可以随时随地开始编码,并通过 AI 实时获取代码建议、调试帮助,甚至生成功能模块。

五、创作与身心体验类

  1. 白日梦

关键词:AI 视频创作| 视频多媒体 | AI Agent

小 A 推荐:将文字或画面,快速转化为生动的短视频,让每个人都能轻松成为自己故事的导演,尤其适合内容创作者快速生产社交媒体视频或进行创意可视化表达。

2.林间疗愈室

关键词:医疗健康类|心理 AI 疗愈

小 A 推荐:通过融合 AI 对话技术与专业的心理疗愈框架,它以温暖、非评判的方式提供情绪支持与疏导,是关注内心健康、寻求日常正念练习用户的贴心伴侣。

榜首应用开发者 Q&A

本周模力工场助手模力小 A 采访了榜一应用蓝耘星河营销智能体的开发者,带来七个快问快答。

开发者简介:大家好,我是蓝耘星河平台的徐建伟,很高兴能够接受采访。

蓝耘星河营销智能体 是什么:蓝耘星河是新一代一站式营销智能体,聚焦内容生产,解决“工具割裂、产能不足、千篇一律” 的痛点。通过知识库构建、品牌画像定义,提供单篇精细化与批量矩阵化创作,覆盖多种内容场景的内容输出与多渠道分发,实现营销内容标准化、规模化、可复用。

模力小 A:2025 年被认为是 AI Agent 的元年,您认为 2026 年是继续延续这一方向发展还是说会有新的热点出现?

蓝耘星河营销智能体:我认为延续只是一方面,它会更深化和落地到各行各业,让它能更好地独立或协同完成各类实际工作,提高大家的工作效率;同时也会涌现出新的 AI 发展热点,这些新热点会与 AI Agent 相互融合、协同推进,共同推动 AI 在更多实际场景中发挥作用,创造实实在在的产业价值。

模力小 A:您最想将模力工场推荐给身边的谁?

蓝耘星河营销智能体:我最想把模力工场推荐给身边的同事和朋友,因为平台聚合了丰富多元的优质 AI 工具,大家既能快速找到适配自身工作与使用场景的 AI 工具,也能通过平台上的优质产品交流学习,借鉴打磨自身的产品与实操能力。

模力小 A:当时你们观察到市场上存在什么样的需求未被满足?是什么促使你们决定用 AI 的方式来解决这个问题?

蓝耘星河营销智能体:蓝耘星河营销智能体的诞生,源于我们对企业营销内容现状的一次根本性反思:今天企业真正缺的,并不是“能写内容的 AI”,而是“能让内容被看见、被引用、被推荐的系统”。在实际调研中,我们发现,大多数企业在内容营销中同时面临三类问题:内容产出周期长、人工成本高,多平台重复改写与分发效率低,内容发布之后,难以持续产生影响力。

与此同时,随着 ChatGPT、Kimi 等生成式搜索工具兴起,内容传播逻辑正在发生变化——是否能被 AI 搜索引擎理解、抓取并引用,正在成为新的流量入口。这意味着,内容不再只是“写出来就结束了”,而是必须进入一个可被 AI 识别和传播的网络中 。在这一背景下,蓝耘星河并没有把目标定位为一个通用的 AIGC 写作工具,而是从一开始就围绕 GEO(生成式引擎优化) 理念,打造一个覆盖创作 + 多模态表达 + 分发 + 内容网络构建的营销智能体,让企业内容不仅“被生产”,更能够“被 AI 主动推荐”。

模力小 A:蓝耘星河营销智能体可以“基于企业私有数据,避免 AI 幻觉”。在技术层面,是如何实现对企业私有知识库的高效学习与精准调用的?

蓝耘星河营销智能体:企业将品牌资料、产品文档、行业白皮书等私有内容上传至专属知识库,系统会对文档进行自动分段、结构化处理与索引构建,将原始文档转化为可被模型高效检索和调用的知识单元。在内容生成过程中,创作任务可以挂载知识库作为背景信息,在推理过程中优先基于知识库中的相关内容进行生成,使 AI 的输出基于企业真实、可验证的内容来源,从而有效降低幻觉风险。

模力小 A:蓝耘星河营销智能体的“品牌专属画像”功能是如何在模型层面实现的?是通过提示词工程、向量记忆,还是其他方式,确保 AI 在长期、多场景的创作中都能稳定保持预设的角色风格与语调?

蓝耘星河营销智能体:蓝耘星河的“品牌专属画像”并不是对模型的长期角色绑定,而是一种由用户自定义、可复用、可灵活切换的画像提示词模板体系。用户可以根据不同品牌、产品或营销任务,创建多套画像模板,并在每一次创作时自由选择。这些画像模板会与:当次创作需求发布平台(公众号 / 小红书等)分发场景与受众定位共同作用,确保生成的内容从一开始就具备“可直接分发”的结构和语境。不同画像之间互不干扰,适配企业真实的多品牌、多项目运作方式。

模力小 A:您认为使用蓝耘星河营销智能体创作营销内容,和使用现市面上的 AI 如 deepseek 等生成的内容最大的区别是什么?

蓝耘星河营销智能体:与 DeepSeek 等通用 AIGC 产品相比,蓝耘星河营销智能体的最大差异,不在于“谁写得更快”,而在于是否具备完整的分发与内容网络构建能力。通用 AIGC 产品通常止步于:生成一段文本或图片,内容需要再加工、再分发,内容与平台、渠道、AI 搜索之间是割裂的。

而蓝耘星河从设计之初,就把“分发”作为核心能力之一:内容自动按平台结构优化,支持多平台一键分发与样式预览,通过持续、矩阵化发布,构建品牌的 GEO 内容网络,提升生成式搜索引擎对品牌内容的抓取覆盖和引用概率。因此,蓝耘星河不是一个“写完就结束”的 AIGC 工具,而是一个让内容持续流动、持续被 AI 看见的营销智能体。

模力小 A:产品上线后,最有效的用户获客方式是什么?你们主要依赖哪些渠道?

蓝耘星河营销智能体: 产品目前处于上线推广初期,核心以线上精准获客为核心策略,重点布局社交媒体平台开展推广运营。基于产品目标用户为新媒体运营、自媒体博主的精准定位,我们通过社交媒体渠道实现目标客群的高效触达与转化;同时也诚挚欢迎有合作意向的伙伴沟通交流,共探合作机会、携手发展。

模力小 A:有没有收到用户反馈“这个功能不够用”或“这个功能很惊喜”?能分享一个典型案例吗?

蓝耘星河营销智能体:上线至今,我们已收获大量用户的真实反馈,用户反馈也是我们推进产品迭代优化的核心依据,我们也始终期待更多用户的体验建议,持续打磨产品体验。其中收到较多惊喜反馈的是【提示词优化】功能,不少用户反馈该功能解决了他们的核心使用痛点 —— 多数用户实际使用中并不擅长撰写精准的提示词,难以让智能体准确理解并落地需求,而该功能可根据用户输入的原始内容,智能优化提示词表述,大幅提升智能体的理解度与执行效果。这也是我们设计该功能的初衷,就是贴合用户实际使用需求、解决实际操作难题,能获得用户的认可我们也倍感欣慰。此外,平台还打造了多款创新且贴合使用场景的贴心功能,也期待大家在实际体验中探索发现。

本周上榜应用趋势解读

本周的 AI 应用榜单传递出一个明确的信号:人们不再满足于与 AI 进行“对话”,而是希望它能够“行动”——真正地完成工作、解决问题。

这标志着 AI 正在从对话界面走向任务执行。无论是 ClawBot 这样的高权限执行工具,能够直接处理邮件、提交代码,俨然一位“数字同事”;还是蓝耘星河这样将营销内容创作流程化的智能工具;又或是 Lovable 这样仅凭自然语言描述就能生成完整应用的平台,这些工具的共同特点都是不再被动等待指令,而是主动推进任务进程。这种转型背后,是用户对 AI 期望值的跃升。从欣赏 AI 的“聪明才智”到要求它“解决问题”,用户心态已从“AI 能做什么”转变为“AI 能为我做什么”。

与此同时,AI 应用正在两个维度上同步拓展自己的能力边界:一方面,AI 正深入工作流程核心。AI 快研侠不仅搜索信息,更能整合资料生成完整报告;语鲸不仅聚合资讯,还能自动归类整理,为深度阅读铺路;Replit 则将 AI 融入开发流程,重塑编程体验。另一方面,AI 开始关注更人性化的体验领域。白日梦让文字创意快速转化为视频,降低了视觉叙事门槛;林间疗愈室则探索 AI 在心理健康领域的可能,提供随时可得的情绪支持。这表明 AI 正从纯粹的生产力工具,向关注创造力与人文关怀的方向演进。

这一转型的深层驱动力在于技术民主化。醒图让专业级视觉设计变得触手可及;Lovable 让漂亮的网站开发不再只是程序员的专利;白日梦让视频创作变得简单。AI 正在成为普惠性的技术赋能工具,降低各领域的专业门槛。

然而,随着 AI 能力的增强,用户对隐私和数据安全的关注也愈发明显。无论是 ClawBot 的自部署需求,还是各大平台推出的本地方案,都反映出当 AI 真正能“做事”时,人们更希望将其置于可控的环境中运行。这一趋势推动了本地化部署的复兴,也预示着 AI 发展的新阶段——能力越强,责任越大,边界越需要明确。

One More Thing,

1 月 “ AI 体验官荣耀盛典” 深度测评精选出炉!感谢每一位体验官的投入与反馈,是你们让产品迭代方向更清晰,也让好工具的闪光被看见。五大 AI 神器收获真实口碑:Replit 被誉为“代码生成王者”,Thetawave.ai 掀起 “学习效率革命”,Lovable 更是“创意落地加速器”,豆包爱学化身“智能学习伙伴”,语鲸则成为“信息处理中枢”。同时恭喜宇、迷龙、墨鱼罐头等伙伴荣登 1 月卓越榜单,专属激励已送达!2 月体验官计划现已开启,欢迎热爱探索 AI、乐于分享的你加入,获取内测资格、直通产品团队、赢取荣誉与奖励。立即扫码加入社群,亲手塑造 AI 工具的下一代——AI 未来,因你而变!

但也只是迷茫了一分钟,梁友余就回过神来:在这里,首要任务还是先赚钱活下来吧。

梁友余不禁苦笑一下,看来,这辈子跟打工是脱不了干系了。

打工,可能眼前就有一份。

梁友余问早餐店老板需不需要人打零工,老板却一脸慌张地说他经营小本买卖不容易,不想跟七神殿叛军有什么瓜葛,让梁友余吃完就赶紧走。

梁友余只能收拾东西起身走人。

出了早餐店,梁友余想,应该先把衣服换了,现在穿的还是短发女人给的那身制服。听赵山所讲,那女人应该叫罗文。这身衣服万一跟七神殿有什么关联,自己这样穿着在大街上可太招摇了。

梁友余在街上找了一家服装店,进去以后捡了几件便宜的,直接付钱让老板剪了标签,去试衣间胡乱套上。出来后问老板要不要打工的,服装店老板摇摇头说:“你衣品太差了,不适合在我这打工。”

梁友余哑然失笑,这么胡乱买几件便宜的衣服,肯定没有衣品可言。

梁友余又问最近的网吧在哪,他想了解这个世界,通过网络应该是最便捷的。然而服装店老板却一脸茫然的看着梁友余:“最近的什么?”

“网吧。”梁友余说。

老板还是一脸茫然。

梁友余意识到,可能这个世界的网吧不叫网吧,就换了个说法:“有电脑能上网的地方。”

老板终于确定了眼前的这个人脑子不太正常,冲梁友余摆摆手:“买完了就赶紧走吧。”

梁友余只能又无奈笑笑走出服装店。街上的行人和车辆更多了。

看来得花钱才行。

梁友余伸手拦了一辆出租车。上车后梁友余说:“去最近的网吧。”

跟服装店老板一样,出租车司机问:“你说什么?”

梁友余又换个说法:“去一个能上网的地方。”

“什么能上网?”司机很奇怪,扭过头来看着梁友余。

“就是去一个有电脑能上网的地方。”

出租车司机迟疑了一下,转回头踩油门出发了,起步前还在后视镜又看了一眼梁友余。

最终,司机把梁友余丢在了一栋挺华丽的建筑门口,大门旁挂着一块牌子,写着“青山市交易大厅”。

梁友余不明白,他已经尽力提示服装店老板和出租车司机了,但还是没有到找到能上网的地方。

或许这个世界没有网吧?甚至没有互联网?

带着一肚子疑惑,梁友余还是进了交易大厅。既然“有电脑、能上网”能让司机想到这个位置,那还是进来看看里面是什么情况。

大厅里烟雾缭绕,也不知道多久没有通风过,呛得人几乎睁不开眼,不过确实有很多电脑,电脑前都围着人,有的三三两两,有的更多,对着屏幕指指点点,像极了某贫穷乡镇里仅有的网吧。

“总算是有电脑了。”梁友余想,但他又随即发现,想用大厅里的电脑是不可能了,因为他看到有人拿着一个证件去服务台申请以后才坐到一台电脑前,跟在梁友余的那个世界去网吧“开机”一样。

而梁友余没有身份证件。

梁友余只能想办法“蹭”一台别人的电脑用,他开始在大厅里物色目标。很快,他注意到一个看起来有四十多岁的微胖的中年人,正皱褶眉头摆弄着电脑,时不时气呼呼的摔几下鼠标,戴着金丝眼镜的脸几乎都贴到了电脑屏幕上,嘴里骂骂咧咧,脑门上渗出细细的一层汗,正在大厅明亮的灯光下闪着光。

梁友余立即朝这人挪了过去,搭讪道:“这个不太好弄哈?”

中年人一惊,回过头来盯着梁友余,才一两秒似乎就看穿了梁友余想“蹭”电脑的目的,直截了当问:“你会摆弄这东西?”

梁友余说:“我试试吧。”说着拖了一把椅子坐下,中年人则两脚一蹬,让椅子往后退了半个身位,让出地方给梁友余。中年人自己则掏出烟点上,眯起眼盯着梁友余的侧脸。

梁友余毕竟在自己的世界中对电脑非常熟悉,很快就发现这里跟自己睡梦中的那个世界的电脑差不多,稍微摸索一会,大概明白这是一个交易信息的发布平台,就流利地操作起来。

中年人见状让梁友余在平台上发布一则销售信息,售卖 1.7 吨铜缆。“给别人干了点工程,他们工程款周转不开,用这些铜缆抵了。”中年人主动说。梁友余随口嗯了一声,并不关心他铜缆怎么来的。

梁友余一边闲聊,一边给中年人在系统中发布了销售信息,然后企图在电脑中寻找些对他有用的信息,但他很快发现,这里的电脑中的浏览器只是摆设,里面只能找到一些简单的新闻,都是交易大厅自己发布的跟商业交易相关的。梁友余换了好几个关键词,搜来搜去都是这些东西,这台电脑看起来就只为这个交易大厅服务的。

梁友余有些懊恼地一推键盘,往后靠在椅子上想下一步该怎么办。

中年人看着梁友余的举动,开始好奇起来,问:“你找什么?”

梁友余问:“这有互联网吗?”

中年人一愣:“什么网?”

梁友余说:“就是一个电脑网络,所有人能用,全世界都连在一起,都可以在上面放信息。”

中年人看了梁友余一会,随即哈哈一笑道:“小伙子你是在做梦还没醒是不是?世界上怎么可能有这种东西?”

“为什么不能有?”

中年人像看梁友余很认真,不像是装疯卖傻,也不像脑子有问题,随即也认真起来,道:“你这想法倒是可以,全世界都可以在上面放信息,不说别的,就即使新闻对于商界的价值就已经很大了。”

“对啊,那为什么没有呢?”梁友余追问。

“因为不可能。”中年人说,“离我们最近的主城雨台城,离这得有两千公里,哪有这么长的网线?”

“多远?”梁友余瞪大了眼睛问。

“一千八百多吧,准确点说。”

“一千八百公里?中间没有其他城市吗?”梁友余继续问。

中年人眯起眼睛:“你连这都不知道吗?你小子小学没毕业吧?”

还没等梁友余回答,电脑上弹出一条提醒,已经有人想买那批铜缆了,留下了电话。中年人赶紧打过去,很快谈拢了,约好了交易时间地点。

随后中年人对梁友余说:“我在这没什么事了,我就先走了。”然后指指电脑,“可能还剩半小时,留着你用吧。”

梁友余摇摇头,面对这种电脑,他留在这也没什么用了。既然电脑上找不到有效的信息,他下一步得先去图书馆或者书店,从这种地方获取一些这个世界的信息。两个城市之间相距两千公里?这太离谱了,在梁友余睡梦中的世界里,这个距离能有半个中国那么长了。

忽然梁友余想到一件事:“在这个系统里能发求职信息吗?”

中年人说:“能啊。怎么你还没工作?”

梁友余点点头。中年人盯着梁友余想了几秒钟,说:“我还有个汽车修理厂,缺个收钱的,一个月三千六,你来不来?”

梁友余一寻思,自己最擅长的网络编程技术,在这个没有互联网的世界,是没有什么用武之地了。去做收银工作倒也是一个办法,先解决温饱问题,然后再弄明白咒师什么的是怎么回事。于是道:“包吃包住我就干。”

中年人猛的吸了最后一口烟:“行,你住厂里。”他把烟蒂在桌上的烟灰缸里碾了几下又问:“会开车吗?”

梁友余点点头:“会。”

中年人掏出一把残旧的车钥匙丢给梁友余:“走吧。”

回去的路上,中年人说自己叫于大金,开着一个汽车修理厂。于大金在青山市长大,人脉广,经常干一些给人撮合交易之类的事情,也算混得风生水起,吃穿不愁。

到了汽修厂以后,于大金就给梁友余安排了工作岗位。梁友余拿不出身份证明,于大金也只是漫不经心问到:“你小子该不是从别的首城逃窜过来的逃犯吧?”

梁友余肯定摇头。

于大金又说:“你小子看起来也不是逃窜犯那块料。我不在乎你之前是做什么的,你最好也别给我搞事情。”

梁友余又赶紧点头。

就这样梁友余在汽修店里还真开始做起了收银员。

第二天梁友余就问于大金,要不要给他开发一套收款系统,因为现在手工记账容易错还不好统计。

于大金表示,梁友余能不能开发出来姑且不说,就算能,于大金首先要给梁友余付一笔开发费用,然后要斥巨资买一台电脑,以后再找收银员还要找会操作电脑的,这种人工资肯定高。而付出这些只是为了记账方便,完全不划算。

梁友余也没问在这个世界买电脑要斥多少巨资,想想于大金说的有道理,就不再提这个事情了。但梁友余觉着于大金倒是一个聪明而果敢的人,比谨慎多疑的普通商人强不少,于是“提点”于大金,让他找找关系,看能不能撮合两个主城,在城间打通网络。虽然看起来似乎很难,但在梁友余睡梦中的世界里,海底光缆都能铺设,这里两座主城之间应该也能实现。真把几个主城连起来,连接得多了,慢慢就有互联网的样子了。如果能早期参与互联网基础建设,肯定有大把的福利等着于大金。于大金听得很认真,似乎听进去了,但后面也没再讨论过这个事情。

时间很快就过了一个周。这天没有什么客户,梁友余在前台蹭电视看新闻,他现在需要抓住一切机会了解这个世界。

电视上忽然播出一段新闻,大概意思是,一周前青山市咒术研究所遭反动势力“七神殿”袭击,这次袭击由研究所叛变成员“梁友余”做内应,跟七神殿里应外合,给研究所造成了巨大损失,叛变成员梁友余仍然在逃,现全城通缉,有提供情报者均奖励两千元,有提供重要情报者奖励一万元。旁边还有梁友余的大幅照片。

梁友余当场给吓懵了,脑子里顿时想到三条信息:

  1. 天权会果然还是想把自己抓回去,当然不能跟市民说抓回去当“充电宝”,所以说他是袭击的内应,是变节者。
  2. 现在天权会只通缉自己,不通缉其他七个“充电宝”,说明七神殿里肯定有天权会的人,知道赵山只带回了七人。
  3. 眼下已经不能再在这座城市待下去了。全城通缉之下,早餐店老板、服装店老板、出租车司机这些人很快就会提供“重要线索”,很快会跟踪到交易大厅,从监控能看到自己跟于大金离开,又很快会追查到这里,甚至可能现在追捕自己的人已经在过来的路上了。

想到这,梁友余不由得打了一个激灵。他又赶紧看了一眼前台的几个员工,好在他们并没有注意到这则新闻。他们围在一个员工周围,津津有味地听他说一个长得比较帅气的修理工和一个跑车女车主之间非同寻常的关系。

在任何世界,这种身边绯闻都要比枯燥的新闻更能勾起人们的兴趣。

梁友余见状赶紧把头一低回自己的收银台。好在这几天他足够低调,没跟任何人深入接触,甚至其他员工还没记住他的脸。

在睡梦世界中,梁友余是一个开车在路上被交警拦下来查酒驾都要紧张的人,哪经历过被全城通缉这种事,现在焦虑值早已拉满,甚至紧张得有些反胃想吐。

眼下这座城市是不能待了,却又实在不知道应该去哪里。之前梁友余经常在电视或者小说中看到一句“世界之大竟没有我的容身之所”,现在他算是体会到这是一种什么滋味了,孤独感满满占据着他的内心,伴随的还有还有恐惧、焦虑。

此时他竟然非常希望眼前的场景才是一场梦,醒来能回到自己那个简陋的出租屋。

还没等他消化完这些负面情绪,前台方向就传来一阵嘈杂声,随后就是于大金的声音:“呦,刘哥今天怎么有空来玩了啊?”

一个瓮声瓮气的声音道:“上面的任务,过来查查。”

于大金道:“那两位长官赶紧先进来坐会吧。”

后面就没声音了,应该是于大金把人领到了自己的办公室。

梁友余慌神了,他压住自己强烈的想逃的冲动,尽量让自己平静下来,仔细分析:两位“长官”,应该还不至于是抓捕行动。听起来天权会出动武装力量开始搜捕了,这种大范围无目的搜捕他们叫拉网式搜捕,说白了就是在一个大范围内瞎划拉,碰运气。要说搜到人,那几乎是不可能的,主要起到一个敲山震虎的作用,让市民们知道天权会正在严厉通缉,都不敢给通缉犯容身之所。现在梁友余逃出厂区的话,在外面乱跑,倒是可能撞上外面的“拉网”,待在厂区反而更熟悉一些容易躲过搜查。眼下要应对的,是这两位长官检查厂区,梁友余必须躲起来别跟他们面对面遇上。

刚想到这,又听见那个瓮声瓮气的声音说:“行了,你这我都熟,我们自己去就行了。”然后听见于大金忙不迭的吐了六个好:“好好好好好好。”接着就听见皮靴咚咚朝这边走来。

梁友余一惊,没想到这么快就开始检查了,撒腿就冲向厕所。

然而梁友余冲进厕所,听着皮鞋声也朝着厕所不紧不慢走来。梁友余悔得想扇自己两巴掌:如果是检查,于大金怎么可能不陪同呢?这根本不是检查,只是两个“长官”想上个厕所而已!现在好了,自己先冲进来,简直是瓮中之鳖一样等着人家来抓。

梁友余立即想反锁到一个隔间里,但一想那样更是瓮中瓮。深呼一口气,梁友余扫视一圈,转身钻进了厕所门旁的工具间,半倚半躺在拖把扫帚上,蜷缩好,从里面带上门。

现在只希望两位“长官”真的是上个厕所,不会对工具间过分留意。

随着脚步声越来越近,梁友余心跟着砰砰狂跳起来,大气不敢出一声。两双皮鞋咚咚走进厕所,竟然先转了一圈,一个年轻点的声音说:“没人刘哥。”

梁友余庆幸自己没躲到一个隔间里。

瓮声瓮气的声音从鼻子里“嗯”了一声,接着听见吧嗒一声打火机的声音,和“呼”的一声吐烟。

年轻的声音又道:“刘哥,我们这样转转就行吗?真不用搜一搜吗?”

那个“刘哥”道:“搜个屁!你是那个‘梁友余’,你还会留在青山等着我们来抓?”

年轻的声音陪笑道:“不会不会,早跑了个屁的。”

刘哥又道:“就算没跑,那个梁友余站在你眼前,你特么敢抓?”

年轻的声音很是疑惑:“为什么不敢?”

听着刘哥吸了一口烟说:“我有个弟兄在调查队,那天早晨咒术研究所出事以后,他们被派去现场调查。说是当天早晨五点半,整栋楼有 19 个安保人员,都配着枪,七神殿来了两个人,从进门到把东西拿走,一共不到十五分钟。”

“什么?”年轻的声音惊呼。

“两个咒师,19 个人毫无还手之力。加上那个梁友余内应,跟特么没人防守一样!”

年轻的声音道:“卧槽原来是咒师啊…… 这么说,那个梁友余也是七神殿的咒师?”

刘哥说:“这可不好说,说不定他站在你面前,指你一下你都不知道怎么死的。”

年轻的声音说:“幸亏有刘哥带着,换成我自己,傻乎乎的真去搜捕,遇上了小命都得搭进去!”

刘哥满意的说:“跟着我你吃不了亏!你还年轻,好好混,以后机会多得是!”

年轻的声音一个劲的是是是。

听见呲啦一声皮鞋擦地的声音,应该是把烟头碾灭了,刘哥又说:“我再提点你几句,这个于大金还算脑筋活络,出手也大方,逢年过节过来走走。”

年轻的声音顿时高兴起来:“呦,给的挺多吗?”

刘哥哼了一声说:“前几天中秋节,给了两万。”

年轻的声音卧槽一声:“这么多!”

刘哥又道:“出去以后,跟于大金就说,我们是来找人的。随便看看也是找,开个挖掘机过来给他把厂子翻了也是找,我们怎么个找法,他知道该怎么办。”

听着年轻的声音,梁友余甚至都能在脑海里看见一副喜笑颜开的脸:“还是刘哥你经验多。”

两双皮鞋一般往外走,刘哥一边得意洋洋地说:“跟着我你不会吃亏的。”

年轻的声音又是一阵是是是,又说:“这次这个于大金给多少,我都给刘哥你,谢谢刘哥栽培。”

刘哥声音越来越远:“你小子挺上道啊~”

后面就听不清了。

听他们走远,梁友余才从工具间走出来,长出一口气,刚放松一下,随即又紧张起来:两人去于大金那拿出自己的照片,那于大金还不当场就指认了?以这个“刘哥”的精明劲儿,马上会往上汇报,那抓捕队伍应该没多久就到了!

这下把梁友余急得原地转了个圈。这时忽然听见一个熟悉的声音:“还是跟我走吧。”

是赵山!

依稀记得上次我说 WAF 根本防不住 0day ,被人喷烂了,今天看到大佬复现飞牛 OS 的漏洞利用链,才证明我的看法是对的。

飞牛这次栽在哪了?

这次飞牛 OS 被人搞出来的漏洞链堪称教科书级别,整个攻击过程环环相扣:

第一步,利用路径穿越漏洞下载了系统里的一个 RSA 私钥文件。这一步 WAF 理论上能防,但实际上各种编码绕过手段多的是。

第二步,这个私钥文件里居然硬编码了 AES 密钥,这就离谱了。拿到这个密钥就相当于拿到了"万能钥匙"。

第三步才是最骚的,攻击者用这个密钥自己伪造了一个合法的 token 。问题出在系统的认证逻辑上——它在验证 WebSocket 请求时,只要你提供了 token 字段,就直接拿这个 token 去解密得到 secret ,然后用这个 secret 来验签。等于说攻击者自己生成 token 自己验证自己,系统还信了。

第四步,拿到认证之后,直接往 Docker 镜像添加接口的 url 参数里注入命令,执行任意代码,拿下 root 权限。

整个过程,除了第一步 WAF 可能还能拦一下,后面三步全是通过 WebSocket 协议走的,而且是加密的业务逻辑。WAF 在这里就是个摆设。

WAF 的尴尬之处

花了大价钱上 WAF ,结果遇到 0day 一点用都没有。

WAF 的本质是规则匹配,它只能防已知的攻击。0day 这种没见过的玩法,规则库里根本就没有,怎么拦?

更尴尬的是,现在很多应用都用 WebSocket 通信,WAF 对这种协议的深度检测能力非常有限。飞牛 OS 这次的认证绕过和命令注入都是走的 WebSocket ,WAF 连请求内容都看不清楚,更别说拦截了。

所以说,别把安全的宝全压在 WAF 上。

换个思路:让攻击者碰不到你的服务

既然边界防御不可能做到 100% 完美,那就换个角度——把服务藏起来

攻击者看不到你的服务,自然就没法攻击。这不是什么新鲜概念,VPN 就是这个思路,但 VPN 的问题是太麻烦了:

  • 每个设备都要装客户端
  • 断线重连是家常便饭
  • 一旦 VPN 账号泄露,整个内网都暴露了

frp 这种内网穿透工具倒是方便,但它只管连通性,不管安全。你用 frp 把 SSH 端口映射出来,全世界的扫描器都能看到,然后开始爆破。

Next Terminal 的做法

我在设计 Next Terminal 的时候,想的就是怎么把"隐藏服务"和"方便访问"这两件事同时做好。

核心思路很简单:所有访问都必须先过我这道门,验证完身份再放行

比如说你有个内网的 GitLab ,以前是直接暴露在公网上的。现在用 Next Terminal 代理之后:

  1. 用户访问 gitlab.yourdomain.com
  2. 请求先到 Next Terminal
  3. 没登录?滚蛋,GitLab 根本不知道有人来过
  4. 登录了但没权限?也滚蛋
  5. 有权限?那才把请求转发给 GitLab

这样一来,就算 GitLab 本身有漏洞(就像飞牛 OS 一样),攻击者连门都摸不到。

访问流程

具体能干啥?

把服务器藏起来

Next Terminal 提供两种方式把服务器藏起来:

Agent 模式:在内网机器上跑一个 agent ,主动连接到 NT 服务器。整个过程你的服务器不需要开任何公网端口,扫描器连你的 IP 都找不到。

SSH 网关模式:利用 SSH 的端口转发能力建立隧道,服务器同样不需要暴露在公网。

保护 Web 应用

你有 Jenkins 、Grafana 、飞牛 OS 这些内部后台,想暴露出来但又不放心?

用 NT 的 Web 资产功能,配置一下就行:

App:
  ReverseProxy:
    Enabled: true
    HttpsEnabled: true
    SelfDomain: "nt.yourdomain.com"

然后在界面上添加资产,指定内网地址和对外域名。以后访问这个域名:

  • 没登录 NT ?看不到
  • 登录了没权限?看不到
  • 有权限?无感跳转,就像直接访问一样

在线演示: https://baidu.typesafe.cn

test/test 有权限
manager/manager 无权限

临时白名单:专治移动网络 IP 变来变去

如果你有手机 APP 需要连接内网服务,肯定遇到过这个问题:移动网络的 IP 三天两头变,每次都要去后台改白名单,烦不烦?

NT 的临时白名单就是解决这个问题的。开启之后,你在手机上登录 NT ,点一下按钮,系统自动把当前 IP 加到白名单里,设定一个过期时间(比如 30 分钟)。更贴心的是,只要你持续在访问,白名单会自动续期,不用担心用着用着突然就断了。等你真正不用了,过了设定的时间才会失效。

下次 IP 变了再点一下就行,APP 随时都能连上内网服务。这不是为了安全,纯粹是为了方便。毕竟谁也不想每次 IP 变了就去改配置。

更严格的环境?还有这些招

如果你的安全要求特别高,NT 还有两个"狠招":

双向证书认证:客户端必须装证书才能访问。没证书的设备连 HTTPS 握手都过不了,直接拒绝。这招对付失窃设备或者未授权设备特别管用。

资产访问二次认证:这个最狠。就算你登录了 NT ,访问某个资产时还要再输一次 OTP (或者扫指纹)。假设你电脑被人远程控制了,或者你离开电脑忘了锁屏,攻击者拿到你的浏览器 session 也没用,因为每次访问资产都要二次验证。

这两个功能组合起来用,安全性直接拉满。

细粒度权限控制

不用再共享 root 密码了。你可以精确控制:

  • 实习生只能在工作时间访问测试服务器
  • 外包只能访问 Jenkins
  • 临时权限到期自动失效

全在 Web 界面点几下就搞定。

操作审计

所有会话都录像,SSH 命令、RDP 桌面操作全都有。出了事能回放,看清楚谁干了什么。

操作审计

Passkey 登录

支持指纹、Face ID 这些生物识别登录,天生防钓鱼。黑客做个一模一样的假网站也没用,因为根本没密码可偷。

回到飞牛这个案例

如果飞牛 OS 藏在 Next Terminal 后面会怎样?

攻击者第一步就走不通,因为:

  1. 路径穿越? NT 的认证在前面挡着,请求根本到不了飞牛
  2. 即使绕过了第一步,后续的 WebSocket 请求同样要过 NT 的认证
  3. 没有合法的 NT 用户凭证,整个攻击链断掉

更进一步,如果你开启了双向证书认证,攻击者连 TLS 握手都过不了。如果开了资产访问二次认证,就算内部员工的电脑被入侵了,攻击者也拿不到飞牛的访问权限。

这就是"先验证身份,再建立连接"的威力。多道防线,层层把关。

对比一下

方案 访问门槛 安全性 权限控制 审计能力
frp 极低(扫到就能打)
VPN 高(要装客户端) 较强 粗粒度(全内网)
Next Terminal 低(浏览器即用) 强(身份前置) 细粒度(按人按资产) 完整录像

最后说两句

别指望 WAF 能防住一切。飞牛 OS 这次的教训已经很明显了:

  • 路径穿越 → WAF 可能拦得住
  • 认证绕过 → WebSocket 协议,WAF 无能为力
  • 命令注入 → 加密业务逻辑,WAF 看不懂

安全这事儿得多层防御。WAF 守边界,NT 守入口,两道防线总比一道强。

感兴趣的话可以试试: https://typesafe.cn


本文提到的飞牛 OS 漏洞信息来自互联网公开论坛,仅用于安全研究和防御目的。

随着 Safari 26.2 完成上线,HTML Invoker Commands API已在所有主流浏览器中实现基础支持;此前该特性已在 Chrome 135 和 Firefox 144 中发布。该特性引入了一种声明式的按钮控制方式,在使用 popover、dialog 等交互元素时无需再依赖 JavaScript。

 

Invoker Commands API 为button元素新增了两个属性:commandforcommand。其中,commandfor用于指定被控制元素的 ID,而command用于定义要执行的操作。通过这种声明式方式,开发者可以在不编写事件监听器、也无需等待 JavaScript 下载和执行的情况下创建交互组件,从而提升页面初始交互性。

 

内置命令覆盖了 popover 和 dialog 的常见操作。对于 popover,可使用toggle-popovershow-popoverhide-popover命令;对于 dialog,则支持show-modalclose命令。下面是一个使用声明式方式实现 popover 的示例:

<button commandfor="mypopover" command="toggle-popover">    Toggle the popover</button><div id="mypopover" popover>     <button commandfor="mypopover" command="hide-popover">Close</button>     Popover content</div>
复制代码

 

该 API 还支持自定义命令,自定义命令必须以两个短横线开头,类似于 CSS 自定义属性。开发者可以通过监听command事件,并在事件对象中检查命令名称来处理这些自定义命令。这使得组件作者能够为 Web Components 提供声明式 API,而无需组件使用者编写 JavaScript。

 

一篇 Medium 文章将该 API 形容为“你还没用上的最酷 API”,并表示 invoker 终于让按钮在没有 JavaScript 的情况下真正“干点事情”。

 

开发者 Pawel Grzybek 也指出,每当 Web 引入能让实现逻辑向技术栈上游迁移的新特性时,他都会感到兴奋,并认为这个 API 本质上是将按钮点击处理逻辑前移到了 HTML 层。

 

另一方面,CSS-Tricks 也提到,自定义命令依赖于事件处理型 HTML 属性,而这种方式“多少有点(甚至可以说非常)有争议”,因为使用 HTML 事件处理属性通常被认为是一种不佳实践。

 

对于目前正在使用popovertargetpopovertargetaction属性的开发者来说,Invoker Commands API 提供了一种更统一的方案。Popover 现在既可以继续使用原有的专用属性,也可以使用新的commandcommandfor属性,从而支持渐进式迁移。

 

HTMX等通过自定义属性提供声明式控制能力的库相比,Invoker Commands 以原生平台特性的形式提供了类似能力。Open UI 的说明文档指出,当前版本主要聚焦于 popover 和 dialog,对

等其他元素的支持被暂时推迟,但未来版本中可能会加入。

 

Invoker Commands API 定义于 WHATWG HTML 规范中,体现了 Web 平台持续减少对 JavaScript 依赖、简化常见交互模式的努力。通过允许开发者以声明式方式构建交互组件,该 API 不仅提升了开发体验,也通过更快的首屏加载和更具可访问性的标记结构改善了用户体验。

原文链接:

https://www.infoq.com/news/2026/01/html-invoker-commands/

OpenAIAnthropic宣布推出新的面向医疗健康领域的 AI 产品,将其模型从通用对话场景扩展到受监管的临床与生命科学环境中。两项发布均强调技术集成、互操作性与治理能力,体现出一种转变:AI 系统不再作为独立的助手存在,而是被设计为能够直接运行在现有医疗基础设施之中。

 

Anthropic 推出了 Claude for Healthcare,并同步扩展了 Claude for Life Sciences。此次发布的核心是一组不断扩展的连接器,使 Claude 能够在查询时访问权威的外部系统。针对医疗服务提供方和支付方,这些系统包括:用于本地与全国医保覆盖判定的 CMS 医保覆盖判定数据库、用于诊断与手术编码的 ICD-10,以及用于医疗服务提供者身份核验的国家医疗服务提供者标识符(NPI)注册库。

 

在生命科学领域,Anthropic 新增了对临床试验运营与科研中常用平台的连接能力。这些集成旨在支持试验设计、受试者招募分析、监管材料准备以及早期发现阶段的工作流。Anthropic 还引入了一系列新的代理能力,包括基于 FHIR 的数据交换、事前授权审查模板、临床试验方案起草以及生物信息学工具,将 Claude 定位为一个面向工作流的智能代理,而非仅用于单轮交互的助手。

 

与此同时,OpenAI 发布了 OpenAI for Healthcare,该方案将 ChatGPT for Healthcare 与一个符合 HIPAA 要求配置的 OpenAI API 组合在一起。从技术角度看,此次发布的重点在于企业级控制与合规机制。组织可以部署基于角色的访问控制,通过 SAML 与 SCIM 实现集中式身份管理,启用审计日志、客户自管加密密钥,并可选择签署业务伙伴协议。OpenAI 强调,在这些配置下,受保护的健康信息仍由客户掌控,不会被用于模型训练。

 

ChatGPT for Healthcare 支持对经过筛选的医学资料来源及机构内部文档进行检索,适用于临床文档辅助、护理协同、事前授权准备以及行政流程自动化等场景。在 API 层面,医疗软件厂商已经在使用 OpenAI 模型构建环境感知型临床记录、病历摘要以及出院流程管理等应用,将 AI 直接嵌入现有系统,而非作为一个独立界面提供。

 

两家公司也都引入了针对个人健康数据的可选集成方案。Anthropic 与 OpenAI 将其描述为“可选择加入”的功能,提供细粒度的权限控制,并支持随时撤销访问。然而,这种做法也引发了对监管与验证机制的担忧。一位 Reddit 用户指出

将个人健康数据交由一家营利性公司,不能只依赖一篇博客文章中的承诺。缺乏独立审计和明确的监管监督时,关于数据不用于训练、数据隔离的声明很难让人完全信任。

 

总体来看,这些发布反映了医疗 AI 的一个更广泛趋势:从通用模型转向高度集成的平台,优先考虑标准合规性、可追溯性以及对结构化数据的受控访问。与其单纯强调模型能力,OpenAI 与 Anthropic 更倾向于将其医疗产品定位为基础设施组件,使其能够在既有监管框架下,被嵌入临床、行政和科研工作流之中。

原文链接:

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

在其他群看到吃瓜消息后,火速让朋友拉我进群,问进群的宝塔开发能不能转聊天记录到 v2 后,我朋友和我双双被踢出 GMSSH 群聊
具体聊天见下图,不评价。总结一下就是一位宝塔开发加群质问 gmssh 为什么抄袭他给宝塔 waf 写的代码



随着大模型和 AIGC 技术的快速发展,AI 正从云端向终端设备延伸;其以实时性、数据保密性和经济性的特点,吸引模型厂商、芯片厂商和终端厂商纷纷布局端侧小模型;在 InfoQ 举办的 QCon 全球软件开发大会 上,百度大模型内容安全平台负责人李志伟做了专题演讲“端侧大模型的安全建设:如何在算力与保障之间找到平衡”,他从端侧大模型发展趋势开始介绍,分享了 AI 从云端向终端延伸的背景与驱动力以及端侧小模型的兴起与生态布局,他谈到算力限制与监管合规要求之间的平衡,如何在低算力情况下最大限度的满足端侧内容审核的效果等是百度在实践中的痛点问题,最后他通过实际案例分享了百度在端侧大模型安全建设的思路,做到离线场景低算力情况下依旧可以支持多模安全审核,帮助听众开拓了一些新思路。

预告:将于 4 月 16 - 18 召开的 QCon 北京站设计了「智能体安全实践:可控与可靠」专题,本专题融合可靠性建设,聚焦权限控制、行为约束等要点,探索在不压制能力的前提下,实现智能体可控、可靠、可审计、可追责的路径,平衡技术价值与安全合规。如果你也有相关方向案例想要分享,欢迎提交至 https://jinshuju.com/f/Cu32l5

以下是演讲实录(经 InfoQ 进行不改变原意的编辑整理)。

端侧大模型发展趋势

端侧大模型是当下人工智能领域的一个热门研究方向,它与我们日常使用的智能手机、电脑等设备密切相关。端侧大模型与常见的端云协同模型有所不同,它有着自己独特的定义和特点。

端侧大模型主要基于云端的大参数规模模型,通过剪枝、蒸馏等模型裁剪技术,将其裁剪为小规格参数的模型。这些裁剪后的模型将网络计算、存储与安全全部预置到端上,以端侧运行、设备本地化的方式进行推理。端侧大模型的承载形态丰富多样,包括移动终端、PC 设备、物联网设备、穿戴设备以及具身智能场景等。

与云端 AI 大模型相比,端侧大模型在训练方式上并无太大差异,都是围绕数据中心或云端进行实践和训练。然而,它们最大的差异在于模型的推理方式和参数量级。目前,最新的云端大模型参数规模可能达到千亿量级,而端侧大模型则主要聚焦于 10 亿级别,并且推理过程在端侧独立离线完成。

2024 年可以说是端侧大模型的元年,尤其在去年下半年,无论是在模型、芯片还是终端方面,都针对端侧进行了大量研发和发布。国内厂商如讯飞、千问、智谱等发布了适配端侧的小规格参数模型;海外的 Google、微软、Meta 等也发布了大约 30 亿参数的端侧模型。芯片方面,性能更优越的芯片不断推出。在终端承载方面,2024 年上半年,算力相对充沛的设备如 AI PC 发展迅速,联想等厂商推出了相关产品。下半年,手机终端也迎来了密集发布期,荣耀、vivo、苹果、三星等厂商的新型智能手机都搭载了端侧模型,这标志着 2024 年端侧大模型进入了快速发展的时期。

据一些调研机构预测,在未来几年,端侧大模型市场规模将保持 40% 到 50% 的增长率快速发展。2025 年,端侧大模型有望迎来更大的爆发。在端侧模型快速发展的阶段,安全建设是一个重要的关注点。

端侧大模型之所以能快速发展,主要有以下优势。首先是端侧的实时性,算力自主在端侧完成推理计算,省去了云端数据传输的环节,具有实时性优势。其次是数据保密性,在智能手机等终端上,涉及大量个人高隐私敏感信息和数据。如果采用传统的端云协同形式,个人敏感信息上传云端存在数据隐私安全风险。此外,端侧大模型还具有多样性,其承载体丰富多样,未来还会有更多新型端侧承载体出现。经济性也是端侧大模型的一个优势,对于模型服务厂商而言,无需耗费大量财力和算力维持高性能的云端服务,从服务厂商角度而言,具有一定的经济性优势。

端侧大模型的应用场景广泛。从载体来看,目前智能手机和电脑是发展最快、最有前景的。从生成内容角度而言,过去一年以及今年上半年,端侧大模型主要以文本生成和图片生成产品为主,这两个多模态领域相对成熟。我们相信,在下半年以及明年,多模态甚至全模态的端侧模型将有更多展现机会。今年上半年,面壁智能发布了小钢炮的最新版本,实现了全模态端侧大模型的发布,这表明我们正处于高速快速迭代的阶段。

端侧大模型面临的安全挑战

端侧模型与云端模型的本质区别不仅在于参数规模和推理形态,从安全视角来看,端侧模型还面临着诸多独特挑战。这些挑战主要从四个方向展开,综合了监管要求、业务场景以及终端类型等因素。

首先是用户隐私保护。端侧模型的一大优势在于用户敏感信息无需上传云端,从而有效避免了在云端传输过程中可能被劫持或泄露的风险。然而,随着端侧模型的发展,设备在处理数据和模型权限方面引入了新的安全隐患。例如,许多智能手机中的 AI 大模型会绕过三方 APP 的权限限制,通过实屏自动点击等方式实现个人助理等服务。这些智能体或个人助手往往会过度获取权限,尤其是无障碍权限,这引发了监管单位、模型厂商、应用服务厂商和手机系统三方的探讨。若无法有效管控,用户的隐私仍将面临隐患。不过,我预计下半年相关问题及监管导向会给出更清晰的管控思路。

其次是内容合规。过去两年,网信办及其他监管单位陆续发布了多项关于大模型安全的管理要求,其中最核心的是深圳市人工智能暂行管理办法和安全基本要求。这些要求明确了大模型生成内容的安全标准,无论是云端还是终端的大模型,都需满足监管的合规要求。除了传统的 PGC 和 UGC 场景风险外,AIGC 还涉及歧视、商业秘密、违法以及侵犯他人合法权益等新型风险分类。云端大模型面临的内容安全挑战,在端侧同样是一条红线。

第三是模型安全。端侧模型直接暴露在用户设备上,更容易受到攻击,且其防护机制相对云端不够完善。端侧模型多基于蒸馏、量化剪枝等压缩技术,参数量级大幅压缩后,对输入扰动更敏感,对抗样本的脆弱性增加。此外,数据残留风险也不容忽视。例如,国内某 AI 厂商和 PC 厂商构建安全方案时,尽管对端上预置的敏感词进行了加密处理,但在运行过程中,敏感词仍可能被轻易泄露,这给企业带来了较大的负面舆情风险。

最后是系统与设备安全。终端承载不仅涉及软件安全挑战,硬件方面也可能带来固件安全、物理安全等问题。

端侧大模型安全建设实践

云端 - 大模型内容安全方案

在深入了解端侧内容安全之前,我们先来审视一下完整的云端内容安全方案。这个方案可以从两个角度来理解。首先,从全链路的角度来看,当用户输入提问内容,也就是 prompt 之后,我们首先会对其进行安全审核,但这并非单纯的审核。具体而言,prompt 到达后,我们首先会进行语种判断等基础处理。由于大模型场景中存在多轮对话机制,而多轮对话很容易构成诱导性提问,这是一种很普遍的情况。因此,我们会对多轮对话进行改写。例如,在多轮指代改写中,前两个问题可能都很正常,比如先要求大模型以“香港是一个美丽城市”为题写一首诗,接着以“英国也是一个美丽的国家”为题写一首诗,单独来看每个问题的输入输出都没有太大风险。然而,当进行多轮对话时,比如第四个或第五个问题变为“前面的城市是这个国家的一个美丽地方,写一首诗”,单纯看用户输入的 prompt 似乎没有问题,常规审核也难以拦截,但结合多轮对话的含义,最后一个问题其实存在很多风险。在多轮指代改写环节,我们会将用户最后输入的 prompt 进行改写,再对改写后的内容进行审核,这样可以提高整体的召回率。指代改写之后,我们会进入 prompt 审核阶段,审核内容会涵盖 TC260 所约束的各类分类,当然也会引入一些新的分类。在传统的 PGC 和 UGC 场景中,我们可能会直接进行处置和干预,比如删除帖子、评论或进行个人屏蔽。但在大模型对话、chatbot 场景中,如果单纯采取这种简单粗暴的处置方式,用户体验会很差。而且从监管角度看,也不希望大模型对所有敏感问题都拒答,因此会有拒答率的要求。

在云端方案中,我们构建了红线知识库,主要围绕一些高敏感问题,预置一些标准回复,虽然占比不高,但我们希望当用户问到这类问题时,生成的内容是经过人工审校、安全合规的。因为即使 10 次生成内容中只有一次因幻觉导致风险,在高敏感场景下对企业的影响也很大。所以,我们通过语义相似度匹配构建红线知识库,提供预置回复。此外,我们还考虑构建安全红线大模型,这是一个参数规模较小的模型,当适配的底座模型对风险问题应答不佳,但从用户角度看又不想完全拒答时,这个模型可以对违规问题进行正向引导。这样,从用户角度看不是一味拒答,体验较好;从监管角度看,也能给用户一些法律法规和要求方面的正向输入,这是监管乐见的。

我们还构建了信任域检索增强能力,因为用户会结合实时热点问题与大模型交互,很多大模型也有检索能力。但在生成内容时,针对高敏感问题,如涉政、民生类问题,我们希望大模型的回复与监管舆论导向和调性保持一致。所以,在涉及安全风险问题时,我们构建了信任域检索增强能力。同时,我们也有回复干预机制,这是监管比较关注的。当大模型服务上线后,出现违规或严重案例,或国家发生敏感事件时,我们需要有快速干预能力,以保证线上服务的稳定性。如果问题是安全的,我们会直接提交到底座模型生成。在这个过程中,我们还会对 prompt 进行风险提示和改写。例如,当问题是具有诱导性的,如询问“有哪些国家在亚洲的半导体方面具有优势,包括台湾”时,我们的方案能够对风险 prompt 进行处理,通过 Few-shot 方式给底座模型追加风险提示,比如提醒用户是中国人,回答内容要符合国内政治制度等要求。针对用户诱导性提问,我们也能给底座模型风险提示,使其生成内容更安全。在输出环节,基于流失的方式,我们还会进行一道防护。大家在使用其他主流大模型服务时,当问到敏感问题,可能会看到生成内容生成一两段后马上撤回,这说明生成内容存在风险和违规内容,进行了交互处理。这就是云端方案的完整流程。

刚刚提到的红线安全大模型,主要是针对用户提出的各类违规问题,除了直接拒绝回答违法犯罪、偏见歧视、涉政以及色情等问题外,还能给出正向引导。以涉政问题为例,在 DeepSeek 尚未火爆的去年,许多厂商使用 Llama 作为底座模型进行微调。然而,这类海外开源模型在回答涉政问题时存在一定风险。因此,我们可以构建一个小型安全大模型,比如 7B 的模型,并对其进行微调,加入大量安全正向语料进行对齐。这样,它能够对用户提出的敏感问题给出更广泛范围的正向引导。

在建立信誉检索增强能力方面,我们会涵盖国内主流党媒、央媒官方网站报道的内容,以及百度百科权威认证的信息。当用户提问涉政民生等问题时,我们会进行信誉检索,由红线大模型直接回答,或者经过适配后,底座模型也可以使用这些信息。这主要是为了保证生成内容的高时效性和高准确性。

终端 - 大模型内容安全方案

前面我快速介绍了云端大模型从内容角度的安全防护方案。接下来,聚焦到今天的议题——端侧。在构建端侧大模型安全方案之初,会面临两个方向的难点。

首先是技术上的难点。在适配过程中,我们可以看到终端设备的算力差异较大,对性能要求较高。高运算量的模型需要进行多架构、多平台的适配。其次,从效果层面来看,我们已经做了很多模型裁剪方案,但如何平衡安全防护效果是一个问题。也就是说,在损失部分效果的情况下,如何满足性能要求,以及如何选取平衡点。还有一个重要问题是,在端侧场景下,安全策略如何进行有效更新和防护。这一点也是我们在配合建设过程中,与监管单位沟通时,他们特别关注的安全点。

另一个方向是从产品视角来看。端侧场景有很多,比如手机终端的端侧模型,并非是一个可以直接开放式闲聊问答的 chatbot,而是更多以 Agent 的形式呈现给用户,应用场景丰富多样。这就需要我们考虑 Agent 的安全边界,以及如何防范用户越界使用。从监管角度来看,云端大模型上线之初需要完成网信办的上线备案。在端侧场景下,监管趋势更为严格,不仅满足于传统的 API 测试。在备案时,我们需要向监管单位暴露大模型的 API,包括具有安全防护方案的 API 和裸模型的 API,他们会进行效果对比。在端侧场景下,不仅需要满足 API 测试,可能还需要进行纯离线设备或沙盒方案的测试,以及考虑如何在离线运行方案下进行应急处置。这些都需要我们关注。因此,在构建端侧大模型安全方案时,也是从这四个场景难点出发,进行整体规划。

在构建端侧内容安全方案时,我深入分析了其流程与架构。从流程上看,端侧方案与云端方案大致相似,但在细节上存在一些关键差异。首先,用户输入的 prompt 并非总是用户直接输入的内容,有时会结合智能体进行调整或修改。从防护方案角度出发,我们首先对输入的 prompt 进行内容的输入输出审核。在这一过程中,我们在算子层面进行了裁剪与量化,以优化性能。

图片审核在端侧应用较为广泛,但其算力消耗较大。传统内容审核通常需要多个算子来覆盖不同场景,而在端侧,单一图审算子的算力开销已远超端侧模型本身,这无疑是一个巨大的挑战。此外,在防护过程中,我们对用户输入的 prompt 进行了场景越界过滤。例如,在移动终端的通话摘要应用场景中,网信办在测试时仅提出了简短的三四个字或七八个字的问题,这显然不符合摘要场景的有效输入。因此,针对每个应用场景的 prompt,我们在端侧实施了越界过滤策略,这是与云端方案的一个显著差异。

在端侧方案中,我们还关注了模型封禁和日志加密存储。云端模型的所有数据都存储在云端,包括违规日志和正常日志,且需按照法律法规保存 6 个月。然而,在端侧,我们无法获取大量数据,但仍需采用端侧加密方式,以便在监管单位需要时进行调取。因此,在端侧 SDK 方案中,我们实现了日志的加密存储和模型封禁。对于违规用户,云端通常会进行账号封禁,但端侧用户购买了终端设备,若因几个问题就被关闭所有 AI 能力,影响较大。因此,我们在端侧对封禁模型进行了分级处理,以实现更合理的管控。

解决技术问题 - 平衡算力约束与安全效果

在技术层面,我们首先解决了算力约束问题。年初的方案中,我们采用了一个多分类算子,能够完全覆盖 TC260 的所有风险分类。同时,我们还引入了安全算子和回复干预算子,通过策略下发的形式,对用户输入的 prompt 或生成内容中的违规内容进行快速干预和调整。在图片审核方面,虽然涉政、涉敏、涉黄的算子目前是分开的,但最新方案正朝着大模型或图文融合模型的方向发展,以实现更有效的安全管控。我们摒弃了传统的单一分类算子训练,转而训练一个能够融合图文的模型,以优化算力开销,并结合模型中流和量化的裁剪技术。最新数据显示,经过模型压缩技术处理后,算子的波动控制在 1% 到 2% 之间。从监管角度看,更关注端到端的效果,即模型生成的内容是否违规。在这方面,端侧效果的差异基本能控制在 1% 以内。

在性能方面,我们重点关注了几个关键指标。首先是运行内存占用,目前我们已将内存占用控制在 400 兆以内,最新数据约为 350 兆。其次是瞬时运行电流的功耗,这也是端侧场景中需要重点考量的因素。通过这些优化措施,我们致力于在端侧实现高效、安全且性能卓越的内容安全方案。

解决产品问题 - 多场景使用圈定安全边界

在产品角度解决问题的过程中,我深入探讨了端侧模型的应用场景。以 AIPC 为例,其算力相对充沛,通常配备有类似 chatbot 或闲聊助手的功能。然而,由于其特殊性,并非所有的端侧方案都能直接移植到此类场景中,因此我们更多地采用了端云协同方案。在这种方案下,对于一些极其违规的问题,端侧能够直接进行检测和识别,并实施拦截。但对于涉政通识类问题,监管单位在测试大模型时会关注拒答率,我们不能简单地对所有涉政问题一概拒答。例如,对于“我们的领导人是哪年当选的”这类常识性问题,以及“台湾是中国的吗”这类底线性问题,我们都应给予相应的回答。在这种情况下,我们实现了端云协同,将部分问题分流到云端处理。

在移动终端方面,更多地是 Agent 场景。在这里,prompt 相当于源代码,至关重要。因此,我们重点关注应用边界和场景安全。我们最终呈现给用户的并非开放式 chatbot,而是以不同 Agent 为入口的功能。我们在应用服务边界上进行了限制,并对 prompt 进行保护,特别是针对提示词注入攻击的检测。近期,我们发现了一些通过对话形式泄露 Agent 核心 prompt 的情况,这凸显了在终端场景下聚焦每个应用场景安全的重要性。

解决监管合规问题 - 端侧离线场景的应急与处置

解决合规问题也是我们工作的核心。从监管角度看,他们更关注离线场景下的应急处置能力。经过与监管单位和厂商的沟通,我们总结出四个关键方向:一是离线用户能否封禁;二是违规日志能否上报;三是针对突发事件能否快速响应;四是在备案过程中的场景化测试和沙盒终端方案。沙盒测试对于新型手机终端尤为重要,企业在备案时可能因保密要求无法直接开放手机供监管使用,这就需要找到一种平衡,既能满足企业保密需求,又能使监管单位有效测试我们的方案。

在封禁模型和日志逻辑方面,考虑到用户购买智能终端的成本较高,我们不会简单地因为用户提问违规内容就直接禁用其 AI 功能。我们采用了分类分级的方式,包括违规分类、频次、权重以及不同重保期的差异。例如,在智能座舱中,当用户提问敏感问题时,系统会给出警告,甚至实施小时级或天级别的封禁,以此引导用户避免违规提问。

违规日志的存储和上报是一个复杂问题,它与用户隐私和端侧场景存在冲突。我们在端侧安全方案中实现了数据加密存储,并根据监管要求灵活控制上报频率。对于违规日志的上传,我们通过引导用户联网申诉等方式,在协议中明确说明,以避免用户利用端侧进行违规操作。

在端侧场景下,应急处置能力至关重要。我们的安全方案以 SDK 形式呈现,并配备云端管理控制台。端上 SDK 不预置任何敏感词,而是将相关内容融入模型训练中,以防止数据泄露。云端控制台保留敏感词管理功能,以便快速响应监管要求和指令。我们还实现了中间干预文件和配置文件的推送与拉取机制,以确保智能终端在离线状态下也能及时更新安全策略。一键禁用功能是监管单位最为关注的要点。在出现极其敏感情况时,企业必须具备一键关停的能力,这是服务备案和向公众提供服务的前提条件。

在端侧大模型的日常运营中,与云端相比存在较大差异。云端有完整的日志和巡检模型,而端侧只能上报少量违规日志。因此,我们采用了安全评测主动发现风险的方式,围绕 Agent 场景和时事敏感话题构建题库,以提升评测效率和效果。我们还构建了裁判大模型,以降低标注成本,提升评测效率。裁判大模型能够快速标注问题的安全性,并为后续对齐提供高质量语料。

总结来说,端侧方案的核心在于超低算力、跨平台支持、纯离线运行、纯语义审核、应急处置能力和评测运营。这些要点构成了我们在端侧建设安全方案的主要方向。

典型案例分享与展望未来

下面给大家介绍一个案例。这是我们支持的国内某 AIPC 厂商,他们使用了一个开源的大模型。不过,他们所使用的底座模型相对来说性能稍差一些。在备案过程中,针对一些常规涉政问题以及审核方案,他们之前采用的是敏感词方式,但这种方式的准确率并不理想。我们与该厂商合作,配合网信办进行了沟通和测试。结果显示,经过我们的优化,其生成内容的合格率能够达到 99.24%。这个案例也展示了我们在应急处置能力等方面的一些新思路,希望能给大家带来一些启发。

目前,端侧模型还处于起步阶段,现阶段大家所使用的端侧模型大多是端云协同模式。在未来的一到两年内,这种模式可能仍将是主流。然而,随着模型技术的不断迭代和算力的持续更新,纯 On Device 的模型占比肯定会逐渐增加。因此,我们在端侧安全方面的关注点也需要持续加强,以应对未来可能出现的挑战。

嘉宾介绍

李志伟,云安全联盟大中华区 CAISP 认证讲师、2025 信通院人工智能安全领域行业卓越贡献者;长期从事 AI 安全、业务风控、账号安全、支付风控等安全领域,现为百度大模型安全产品负责人,专注大模型内容安全、模型安全、大模型安全评测、以及大模型安全运营工作,致力于打造覆盖大模型全生命周期的安全方案;其所负责的大模型安全项目曾获选 2024 世界智能产业博览会智能科技创新应用优秀案例、2024 工信部人工智能赋能新型工业化案例及 2024 工信部度网络安全技术应用典型案例。

会议推荐

2026,AI 正在以更工程化的方式深度融入软件生产,Agentic AI 的探索也将从局部试点迈向体系化工程建设!

QCon 北京 2026 已正式启动,本届大会以“Agentic AI 时代的软件工程重塑”为核心主线,推动技术探索从「AI For What」真正落地到可持续的「Value From AI」。从前沿技术雷达、架构设计与数据底座、效能与成本、产品与交互、可信落地、研发组织进化六大维度,系统性展开深度探索。QCon 北京 2026,邀你一起,站在拐点之上。

B2B 软件交付的瓶颈,往往不是技术难题,而是跨团队协作的系统摩擦:目标不一致、依赖不透明、决策链过长、度量口径不统一。本文从研发 VP 视角给出一套可治理、可度量、可复用的研发项目管理框架,用“目标、结构、机制、指标、工具”把协作从“靠人盯”升级为“靠系统跑”。

本文要点速览

  • 跨团队协作不是沟通技巧问题,而是组织与系统设计问题。
  • 落地框架是五件套:目标对齐、组织结构、协作机制、指标体系、工具闭环。
  • 关键抓手是“共享KR + 端到端责任 + 依赖契约 + 发布节奏 + 事实链路”。
  • 度量用 DORA 看交付绩效与稳定性,用 SPACE 看协作与体验,多维避免指标异化。
  • 工具的本质是“唯一事实源”。

B2B 软件交付的真实难点,是协作的复杂度

在 B2B 场景里,我最常听到两句话:“需求一直在变,我们也没办法”、“不是我们不做,是对方团队不给资源,不给窗口,不拍板”。这些抱怨背后,是 B2B 交付的四类结构性摩擦:

  • 合同与里程碑驱动,上线节奏经常由客户审计、验收、采购流程决定。
  • 环境与约束异构,同一产品在不同行业客户的权限与安全基线不同。
  • 责任链更长,客户不区分“研发问题还是交付问题”,只关心恢复与责任。
  • 决策者更多,产品、研发、架构、安全、运维、交付都可能拥有否决权。

所以,跨团队协作不是“沟通不足”,而是“组织与系统没有为协作而设计”。如果你只加会议与群聊,表面更忙,系统摩擦反而更大。

方法论:用五件套打造协作操作系统

我倾向把跨团队协作当作一个可设计、可治理、可演进的系统。五件套分别回答五个问题:

  • 目标:交付什么价值,优先级如何一致。
  • 结构:谁端到端负责,接口如何定义。
  • 机制:依赖如何显性化,冲突如何前置解决。
  • 指标:用什么事实衡量速度与质量,如何避免指标异化。
  • 工具:如何把事实链路固化,让协作可追溯、可复用。

框架一:目标对齐,让跨团队协作拥有共同优先级

跨团队协作失败最常见的起点是:大家都很忙,但忙的不是同一件事。产品追功能覆盖,交付追按期上线,研发追技术债清零,安全追零风险。每个目标都合理,但缺少共同优先级时,就会演变为拉扯。

1)用价值流统一端到端视角

做法不是画流程图,而是明确每一步的输入、输出、验收标准:需求冻结的定义是什么?上线可回滚的标准是什么?验收通过的证据是什么?价值流的作用,是把争论从“谁更重要”转为“哪个环节是当前约束”。

关键产物(建议PMO固化):

  • 价值流地图(端到端环节与产物)
  • 关键门槛定义(范围冻结点、变更门槛、上线门槛)
  • 端到端责任人(对交付结果负责,不只是对活动负责)

2)用 OKR 做跨团队对齐,但 KR 必须共享

OKR 用于跨团队对齐时,核心纪律是:KR 必须能约束多个团队的行为,而不是某个部门内部产出。

共享KR示例(可直接复用):

  • KR1:端到端交付周期(从需求进入到上线完成)降低到 X 天
  • KR2:关键缺陷数(P0/P1)控制在 X 以内
  • KR3:上线后变更失败率不高于 X%,恢复时间不高于 X 小时(与稳定性绑定)

常见误区:

  • 把 KR 写成“多开会、多同步”,这会把协作退化为活动导向。
  • KR 太多,导致口径扯皮,最后谁也不对结果负责。

框架二:组织与架构,让协作按接口发生

跨团队协作长期卡顿,往往不是人不努力,而是组织结构与系统架构天然不匹配。Conway 定律指出,系统架构往往会映射到组织沟通结构上。

这意味着,如果组织长期以职能竖井运转,系统也更容易碎片化,端到端交付只能靠协调补洞。

1)用 Team Topologies 降低认知负荷,定义团队接口

Team Topologies 提出了四类团队形态与三种互动模式,本质是在管理“认知负荷”和“流动效率”。落地建议:

  • 以 stream-aligned 团队作为默认形态,端到端对一个业务域的交付结果负责。
  • 平台团队提供自服务能力,目标是让业务团队自治,而不是形成新排队中心。
  • 赋能团队以“短周期介入”提升能力,避免专家被长期拖入救火。

关键产物:

  • 团队API(输入输出、SLA、依赖边界)
  • 互动模式约定(协作期、服务化、辅导期)
  • 业务域边界与技术边界对齐清单

2)平台工程是跨团队协作的减摩剂

平台工程强调通过自服务与治理框架,提升安全、合规、成本与交付效率。对跨团队协作的意义在于,把“找人协作”变成“按接口协作”:

  • 环境申请、权限开通、扫描与发布路径通过平台自服务完成。
  • 标准内置到流程里,减少反复对齐与重复人工。

常见误区:

  • 平台团队只做“工单处理”,不做“产品化自服务”。结果是平台成为瓶颈,跨团队协作更慢。
  • 过度抽象,把差异化能力也遮蔽,导致业务团队绕开平台。

框架三:协作机制,用决策权与节奏替代群聊与催办

跨团队协作消耗最大的两类时间是等待决策与返工。机制的目的,是把冲突前置,把等待显性化。

1)RACI 解决“谁负责”,决策门槛解决“何时升级”

RACI 用来明确责任与拍板人,避免“所有人参与但无人负责”。同时建议定义决策门槛:

  • 影响单团队且低风险,团队内快速决策。
  • 影响多团队或架构,进入架构与变更评审。
  • 影响客户承诺或合规,进入项目委员会或产品委员会。

可复用RACI样例(文本版):

  • 需求范围冻结:A=产品负责人,R=项目经理/研发负责人,C=交付/安全/运维,I=客户成功
  • 上线窗口确认:A=交付负责人,R=运维,C=研发/测试/客户成功,I=业务方
  • 回滚决策:A=当班指挥官,R=SRE/运维,C=研发负责人,I=管理层

2)四类节奏会议,把临时战役变成可预期交付

  • 范围与变更评审(每周):产物是变更清单与冻结点。
  • 依赖与风险评审(每周):产物是阻塞列表与责任人、截止时间。
  • 发布列车与上线评审(双周或月度):产物是发布计划、回滚预案、演练记录。
  • 复盘(每次发布后):产物是事实链路、根因分类、系统改进项。

3)依赖契约,把观点冲突转化为标准对齐

依赖契约建议包含五项:

  • 输入标准(前置条件与格式)
  • 输出标准(验收口径)
  • SLA(响应与交付时限)
  • 变更流程(门槛与审批)
  • 回滚策略(触发条件与责任)

这会显著降低“口头承诺”和“临时插单”带来的返工。

框架四:指标体系,用 DORA 与 SPACE 建协作仪表盘

没有度量,跨团队协作只能靠感觉。度量的关键不是“更多指标”,而是“指标驱动管理动作”。

1)DORA:五项交付绩效指标,兼顾吞吐与稳定

DORA 明确指出其指标模型已从四指标演进为五指标,并强调这些指标与组织绩效和团队福祉相关。建议把它作为跨团队共享结果指标,避免孤岛式拥有。

2)SPACE:把协作与体验纳入生产力视角

SPACE 框架强调生产力是多维的,其中包含沟通与协作维度,能帮助你判断“慢到底慢在写代码,还是慢在等待与返工”。可直接落地的“协作类可观测指标”清单:

  • 跨团队阻塞数量与平均阻塞时长
  • 评审吞吐(需求评审、架构评审、变更评审)
  • 返工率(因口径不一致导致的重做)
  • 上线后缺陷分布(需求、开发、测试、环境、配置、流程)

常见误区:把指标当目标,导致“优化数字而不是优化系统”。DORA 也提醒要避免这种做法。

框架五:工具闭环,让系统成为“唯一事实源”

工具的目标不是承载更多消息,而是承载事实链路与治理规则。建议按“四层事实链路”建设工具栈:

  • 工作管理层:需求、缺陷、项目、版本、依赖(统一口径)
  • 工程流水线层:代码、CI/CD、制品、测试、发布(自动化)
  • 运行观测层:日志、指标、告警、事件与恢复(闭环)
  • 知识决策层:ADR、复盘、SOP、最佳实践(组织记忆)

一页式落地路线图(90天把跨团队协作跑起来)

0到30天:做对齐

  • 画价值流,定义冻结点与变更门槛
  • 设共享KR(不超过3个),明确端到端责任人

30到60天:做机制

  • 固化四类节奏会议与产物
  • 推出依赖契约模板与RACI模板

60到90天:做工具与平台化

  • 贯通事实链路(需求到发布到回溯)
  • 把高频依赖做成自服务能力,减少排队

常见问题 FAQ:

Q:跨团队协作最先从哪里开始才不会“空转”?
A:从共享目标与共享KR开始,再用价值流把端到端产物和门槛定义清楚。

Q:为什么我们会议很多,协作却更慢?
A:因为缺少决策门槛与依赖契约,会议在同步情绪而不是推进事实状态。

Q:平台团队为什么常常变成瓶颈?
A:因为平台没有产品化成自服务,仍然以工单处理为主,排队成本转移到了协作成本。

Q:DORA 指标是给DevOps用的,和跨团队协作有什么关系?
A:它衡量的是交付结果与稳定性,天然跨越研发、测试、发布、运维,是跨团队协作最该共享的一组结果指标。

Q:如何避免OKR变成口号?
A:让KR可度量、可追溯、可归因,并与机制产物绑定,比如依赖清单、阻塞时长、发布演练记录。

结尾总结

跨团队协作做得好,本质是企业战略执行力与研发韧性的外显能力。核心结论有三点:协作不是软技能,而是组织操作系统,目标、结构、机制、指标、工具缺一不可。让组织为价值流动而设计,利用团队拓扑与平台工程,把协作从找人升级为按接口协作。用多维度量驱动持续改进,用 DORA 看交付绩效与稳定,用 SPACE 看协作与体验,把改进落实到可验证的变化。

当跨团队协作从“靠人盯”升级为“靠系统跑”,你得到的不只是更快的交付,更是组织面对不确定性的持续进化能力。这就是数字化领导力最值得投入的地方。

在AI智能体(尤其是多智能体协作)的技术落地中,「记忆系统」始终是制约其从“单次交互工具”升级为“持续智能协作体”的核心瓶颈——大模型原生上下文窗口有限导致“健忘”、长流程任务中注意力漂移、多工具协作时信息传递断层、跨会话记忆无法复用,这些问题不仅推高了开发与运行成本,更让多数AI智能体难以适配工业级、规模化的实战场景。

而Manus记忆系统,作为季逸超团队历经千万级项目投入、结合百万级用户交互验证打造的工业级AI智能体记忆解决方案,其核心价值在于以“上下文工程”为核心,通过“KV缓存优化+文件系统延伸+分层记忆管控”的创新组合,低成本、高效地解决了上述痛点。本文将基于Manus团队公开的实战经验、技术复盘及落地案例,从底层架构、工程实现、优化技巧、场景适配、避坑指南五个维度,全面拆解Manus记忆系统的技术细节,助力开发者快速掌握其核心逻辑与实操方法,实现AI智能体记忆模块的高效落地。

一、Manus记忆系统的定位与核心价值

1. 定位:实战导向的工业级记忆解决方案

Manus记忆系统并非单纯的“上下文缓存工具”,也不是纯理论化的记忆架构,而是一套面向工程落地、聚焦成本优化、适配多场景的完整记忆解决方案——它诞生于Manus智能体的实战迭代中,核心目标是“让AI智能体拥有可复用、高效率、低成本的连贯记忆”,无需复杂部署,即可快速集成到各类AI智能体框架中,适配从个人助手到企业级多智能体协作的全场景需求。

与市面上多数记忆系统相比,Manus的核心差异的在于:不追求“大而全”的架构堆砌,而是聚焦“核心痛点解决”,将KV缓存命中率、上下文利用效率、记忆复用率作为核心优化指标,最终实现“延迟降低、成本缩减、落地门槛下降”的三重目标,这也是其被称为“实战级”记忆系统的核心原因。

2. 核心价值:三大突破,破解AI记忆落地难题

结合Manus团队的实战数据与技术复盘,其记忆系统的核心价值集中在三大突破,彻底打破了传统记忆系统的局限:

  • 成本突破:通过KV缓存优化,将AI智能体的推理成本降低90%,以Claude Sonnet为例,命中缓存与未命中缓存的输入Token成本相差10倍,规模化运行时可节省巨额开支[superscript:3];
  • 效率突破:解决长上下文窗口带来的推理延迟问题,检索效率提升40%以上,复杂任务(如多工具协作、长流程分析)的完成率提升40%+[superscript:3];
  • 落地突破:以文件系统作为“终极上下文”,彻底摆脱大模型上下文窗口限制,同时提供可直接复用的实操技巧与避坑方案,降低开发者落地门槛,无需深耕底层技术即可快速搭建可用的记忆模块[superscript:3]。

二、Manus记忆系统底层架构:四层分层设计,实现记忆高效管控

Manus记忆系统的核心竞争力,源于其“分层存储、动态协同”的四层架构设计——不同于传统记忆系统的“单一存储”模式,它将记忆按“时效性、重要性、用途”分为四大层级,每层各司其职、协同工作,既保证了记忆的连贯性,又实现了效率与成本的平衡,同时贴合AI智能体的实战工作流。结合Manus上下文工程实践原则,四层架构的详细解析如下[superscript:4]:

1. 瞬时记忆(Transient Memory):单会话的“实时缓存”

  • 定位:承载单会话内的实时交互信息,相当于AI智能体的“短期记忆”,核心目标是保障单轮交互的连贯性。
  • 技术细节:基于大模型原生上下文窗口实现,无需额外存储资源,核心遵循“稳定前缀+追加唯一”两大原则——将系统提示、任务目标等固定信息作为“稳定前缀”,避免重复注入;新的交互信息、工具观测结果仅做追加,不修改历史内容,确保KV缓存命中率[superscript:3]。
  • 核心优化:加入断点标记机制,对用户指令、任务节点等关键信息添加标记,后续检索时可快速定位,减少模型注意力分散,同时适配vLLM等框架的前缀缓存功能,进一步提升响应速度。
  • 作用:保障单会话内的实时交互连贯,比如在营销场景中,Manus智能体爬取竞品数据时,能实时记住当前爬取进度、已获取的核心信息,避免重复爬取与逻辑断层。

2. 工作记忆(Working Memory):任务执行的“锚点中枢”

  • 定位:承载当前任务的核心信息,相当于AI智能体的“任务记忆”,核心目标是解决长流程任务中的“注意力漂移”与“任务断层”问题。
  • 技术细节:基于“结构化待办清单+错误记录日志”实现,采用KV存储方式,结合Manus独创的“Todo文件法”——智能体在执行复杂任务时,会自动创建todo.md文件,拆解任务步骤、标注进度,每完成一步实时更新,将最新任务清单放入上下文末尾,强制锁定核心目标[superscript:4]。
  • 核心设计:

    1. 待办清单结构化:拆解为“核心目标→子任务→进度→优先级”,确保智能体清晰掌握任务脉络;
    2. 错误记录实时留存:将工具调用失败、参数错误等信息完整存入,不删除、不修改,为后续纠错提供依据;
    3. 自动清理机制:任务完成后,自动清理该任务对应的工作记忆,避免冗余占用资源。
  • 作用:提升复杂任务完成率,比如在研发管理场景中,代码审查助手可通过工作记忆记住漏洞检测进度、已发现的安全问题,避免重复检测与遗漏,OWASP TOP10漏洞检出率达91%[superscript:3]。

3. 长期记忆(Long-term Memory):跨会话的“无限存储”

  • 定位:承载跨会话、跨任务的核心信息,相当于AI智能体的“长期记忆”,是突破大模型上下文窗口限制的关键,也是Manus记忆系统的核心创新点。
  • 技术细节:摒弃传统“纯向量库存储”的局限,采用“文件系统+向量库”的混合存储模式,将文件系统作为“终极上下文”,实现“无限存储+高效检索+可恢复性”的三重目标[superscript:3]:

    1. 文件系统存储:将大量非结构化记忆(如网页内容、PDF文档、简历数据、计算结果)以文件形式存储,支持txt、json、CSV等格式,通过read_file()/write_file()工具实现按需读写,彻底摆脱上下文窗口容量限制;
    2. 向量库索引:提取文件核心信息生成向量,存入Chroma等向量库,实现“模糊检索+快速匹配”,提升检索效率;
    3. 可恢复性压缩:采用“只保留凭证、删除冗余内容”的压缩策略——删除上下文内的网页完整内容,仅保留URL;删除文件完整内容,仅保留文件路径,后续需要时可通过工具重新获取,避免信息丢失与上下文冗余[superscript:3]。
  • 作用:实现记忆跨会话复用,比如在人力资源场景中,全自动招聘管理系统可将简历数据、JD匹配结果存入长期记忆,跨会话复用筛选规则,处理500份简历仅需12分钟,人工复核工作量减少80%[superscript:3]。

4. 元记忆(Meta Memory):系统运行的“规则边界”

  • 定位:固化智能体的行为规范、决策框架、工具调用规则,相当于AI智能体的“底层逻辑记忆”,核心目标是保障记忆系统的稳定性与一致性。
  • 技术细节:采用“静态配置+动态更新”的方式,结合Manus上下文工程的“结构化表示格式”原则,核心包含三类内容[superscript:3]:

    1. 行为规范:明确交互语气、工作边界,适配不同行业场景(如金融场景需严谨专业,教育培训场景需通俗易懂);
    2. 决策框架:定义不同场景下的决策逻辑(如记忆冲突时优先采用最新记忆,检索偏差时触发用户反馈修正);
    3. 工具调用规则:采用“工具遮蔽法”,完整保留工具列表,通过代码逻辑隐藏无需使用的工具(而非删除),避免破坏KV缓存,同时给工具添加分类前缀(如browser_xxxshell_xxx),便于批量管控与调用。
  • 作用:保障多场景、多工具协作的一致性,比如在金融投资场景中,智能投研系统可通过元记忆遵循合规规则,精准调用数据接口,生成带SWOT分析的可交互仪表盘,将传统3天工作量压缩至4小时[superscript:3]。

三、Manus记忆系统工程化实现细节(实战重点)

Manus记忆系统的核心优势的在于“可落地、可复用”,其工程化实现围绕“低成本、高效率、易集成”三大目标,聚焦KV缓存优化、外部记忆集成、注意力操控三大核心模块,所有技巧均经过实战验证,可直接复用到开发者自身项目中,具体细节如下:

1. KV缓存优化:生产级AI智能体的“成本生命线”

Manus团队强调,KV缓存命中率是生产环境中AI智能体最关键的单一指标,直接影响推理延迟与运行成本——在Manus智能体中,输入与输出的Token数量比平均达100:1,大部分计算量消耗在重复输入处理上,而优化KV缓存可实现成本立减90%、速度翻倍的效果[superscript:3]。其核心实操技巧有3点,均经过规模化验证:

  • 技巧1:保持提示词前缀稳定。严禁在系统提示开头添加动态时间戳、随机ID,哪怕一个Token的差异,都会导致后续缓存全部失效——这是最容易被忽略、也最影响缓存命中率的“致命坑”[superscript:3];
  • 技巧2:上下文“追加唯一、不修改”。新的交互信息、工具观测结果仅往上下文末尾追加,不删除、不修改历史内容,同时确保JSON等序列化格式的键顺序固定(如按字母排序),避免无意识破坏缓存链[superscript:3];
  • 技巧3:明确标记缓存断点。对于不支持自动增量前缀缓存的模型或框架,在系统提示末尾手动插入缓存断点,结合Session IDs技术保持分布式节点间的一致路由,进一步提升缓存命中率。

2. 外部记忆集成:文件系统与向量库的协同逻辑

Manus采用的“文件系统+向量库”混合存储,核心是实现“无限存储与高效检索的平衡”,其工程化实现逻辑简单易懂,可快速复用:

  • 记忆写入逻辑:智能体产生新的长期记忆时,先将完整内容写入文件系统(生成唯一文件名、标注时间戳与记忆类型),再提取核心信息生成向量,存入向量库,实现“完整存储+快速检索”的双重目标;
  • 记忆读取逻辑:检索长期记忆时,先通过向量库检索相关向量,获取对应的文件名与路径,再通过文件操作工具从文件系统中读取完整内容,避免向量库存储完整内容导致的容量压力与成本上升;
  • 适配优化:小体量、高频检索的记忆(如用户偏好)存入向量库,大体量、低频次检索的记忆(如历史报告、完整简历)存入文件系统,进一步优化存储成本与检索效率[superscript:3]。

3. 注意力操控与错误处理:让记忆系统更“健壮”

(1)注意力操控:解决AI智能体“走神”问题

针对长流程任务中智能体容易遗忘目标、注意力漂移的问题,Manus除了“Todo文件法”,还补充了两大实操技巧,进一步锁定智能体注意力:

  • 记忆权重标注:对不同类型的记忆标注权重(任务目标权重最高,无关交互信息权重最低),检索时优先返回高权重记忆,引导模型聚焦核心任务;
  • 结构化提示:记忆注入大模型时,采用统一的结构化格式(如“【核心任务】xxx【辅助信息】xxx【错误记录】xxx”),降低模型解析信息的难度,避免无关记忆干扰[superscript:4]。

(2)错误处理:让智能体“越错越聪明”

Manus强调,AI智能体犯错是常态,关键在于如何利用错误记录优化记忆系统,而非删除错误痕迹——删除错误记录会让智能体失去学习机会,反复在同一地方犯错,其核心错误处理方案有3点:

  • 完整保留错误记录:将工具调用失败的名称、输入参数、返回的错误提示,完整保留在工作记忆与上下文之中,不删除、不修改;
  • 错误归因与修正:模型基于历史错误记录,自动分析错误原因(如参数错误、工具调用逻辑错误),并生成修正方案,存入工作记忆,后续遇到同类场景时自动规避;
  • 用户反馈修正:当检索结果出现偏差、错误时,允许用户标注正确记忆,系统自动优化向量检索模型与记忆权重分配,逐步提升记忆系统的准确性。

四、Manus记忆系统多场景适配方案(附实战案例)

Manus记忆系统的通用性极强,可适配金融、人力资源、市场营销、研发管理、生产制造、教育培训六大核心行业场景,结合Manus智能体的落地实践,每个场景均有明确的适配技巧与量化效果,便于开发者快速参考复用,具体如下:

1. 金融投资:智能投研系统

  • 适配需求:跨数据源检索、多步骤分析(财报分析、供应链对比、SWOT分析)、报告生成、记忆复用;
  • 记忆系统适配技巧:将财报数据、供应链数据、股价历史记录存入长期记忆(文件系统+向量库),通过Todo文件法拆解分析步骤,元记忆固化合规规则与数据接口调用规范;
  • 实战效果:某私募基金使用Manus完成特斯拉产业链分析,传统3天工作量压缩至4小时,分析准确率提升22%,可自动生成PDF报告与HTML可视化仪表盘。

2. 人力资源:全自动招聘管理

  • 适配需求:多格式简历解析、JD匹配、候选人信息留存、跨会话筛选规则复用;
  • 记忆系统适配技巧:将简历文件(PDF/docx/图片)存入文件系统,提取技能关键词、工作经验等核心信息存入向量库,用户筛选规则、JD模板存入长期记忆,工作记忆实时记录筛选进度与候选人匹配度;
  • 实战效果:处理500份简历仅需12分钟,人工复核工作量减少80%,可自动生成候选人地理分布可视化报告。

3. 市场营销:竞品分析自动化

  • 适配需求:竞品页面动态监测、价格/评论数据抓取、舆情分析、报告自动生成;
  • 记忆系统适配技巧:将竞品URL、抓取的历史数据存入长期记忆,工作记忆记录监测进度与数据更新情况,元记忆固化爬虫工具调用规则与舆情分析逻辑;
  • 实战效果:可自动适配竞品页面XPath变化,动态监测竞品动态,生成带舆情热度词云图的分析报告,大幅减少人工监测成本。

4. 研发管理:代码审查助手

  • 适配需求:代码安全漏洞检测、漏洞记录留存、CWE标准报告生成、跨项目漏洞复用;
  • 记忆系统适配技巧:将代码库文件、漏洞记录、CWE标准存入长期记忆,工作记忆记录漏洞检测进度与修复建议,元记忆固化静态分析规则与漏洞分类标准;
  • 实战效果:OWASP TOP10漏洞检出率达91%,可自动植入超时中断机制,生成标准化漏洞报告,提升代码审查效率。

5. 生产制造:智能排产优化

  • 适配需求:ERP订单数据导入、多目标优化(交期/成本/设备利用率)、排产方案留存、产能预警;
  • 记忆系统适配技巧:将ERP订单数据、设备参数、历史排产方案存入长期记忆,工作记忆记录排产进度与优化目标,元记忆固化排产优化模型规则;
  • 实战效果:某汽车配件厂应用后,排产效率提升35%,库存周转率提高28%,可自动输出甘特图与产能预警报告。

6. 教育培训:个性化学习引擎

  • 适配需求:交互式课件生成、错题本自动生成、知识点关联、学习偏好留存;
  • 记忆系统适配技巧:将知识点图谱、课件模板存入长期记忆,用户学习偏好、错题记录存入工作记忆与长期记忆,元记忆固化课件生成规则与知识点关联逻辑;
  • 实战效果:某培训机构应用后,学生平均分提升15%,可自动生成含AR实验模拟的交互式PPT与个性化错题本。

补充:安全接入方案(企业级场景必备)

针对企业级场景的隐私与安全需求,Manus记忆系统提供混合云接入方案,结合记忆权限管控,保障数据安全:

  • 混合云架构:核心记忆数据(如财务数据、核心代码)本地部署,计算任务、非核心记忆云端执行,平衡安全性与算力需求;
  • 权限控制矩阵:按角色分配记忆访问权限与工具调用范围(如分析师仅可访问财务数据,研发主管可访问全代码库),进一步保障数据安全。

五、Manus记忆系统开发避坑指南(实战秘籍)

结合Manus团队公开的落地经验,开发者在集成、优化Manus记忆系统时,容易陷入5个核心坑点,这些坑点轻则导致缓存失效、成本上升,重则导致记忆系统崩溃、任务执行失败,以下是详细的坑点解析与解决方案,均来自Manus千万级项目的实战沉淀[superscript:2]:

坑点1:忽视KV缓存命中率,导致成本飙升、延迟过高

  • 问题现象:AI智能体响应速度慢,运行成本远超预期,排查后发现KV缓存命中率极低(低于50%);
  • 核心原因:系统提示添加动态时间戳/随机ID、上下文频繁修改、序列化格式不固定,破坏缓存链;
  • 解决方案:严格遵循KV缓存优化的3个实操技巧(稳定前缀、追加不修改、固定序列化格式),禁用系统提示开头的动态内容,定期监测KV缓存命中率,将其维持在80%以上。

坑点2:工具过多乱删减,导致缓存失效、模型懵圈

  • 问题现象:工具数量增多后,模型频繁调用错误工具,删除部分工具后,缓存全部失效,响应速度骤降;
  • 核心原因:动态删除工具会修改上下文开头的工具列表,破坏KV缓存;工具列表频繁变化会导致模型记忆混乱;
  • 解决方案:采用Manus独创的“工具遮蔽法”,不删除工具列表,仅通过代码逻辑隐藏无需使用的工具;给工具添加分类前缀,便于批量遮蔽与管控,既保缓存又防模型懵圈。

坑点3:上下文窗口不够用,盲目扩大窗口导致成本上升

  • 问题现象:长文本、多工具协作时,上下文窗口快速占满,盲目升级大模型上下文窗口(如从128K升级到1M),导致成本翻倍;
  • 核心原因:将大量冗余内容(如完整网页、PDF)直接塞入上下文,忽视文件系统的“无限上下文”作用;
  • 解决方案:采用“可恢复性压缩”策略,将冗余内容存入文件系统,上下文仅保留检索凭证(URL、文件路径),彻底摆脱上下文窗口限制,无需盲目升级窗口。

坑点4:智能体注意力漂移,长流程任务频繁中断

  • 问题现象:复杂多步骤任务(如多工具协作生成报告)中,智能体忘记核心目标,频繁执行无关操作,导致任务中断;
  • 核心原因:缺乏有效的注意力管控机制,任务步骤未明确固化,模型容易被无关记忆干扰;
  • 解决方案:启用“Todo文件法”,让智能体自动创建、更新任务清单;给记忆标注权重,优先加载高权重记忆(任务目标、步骤);采用结构化提示,引导模型聚焦核心任务。

坑点5:删除错误记录,智能体反复犯错

  • 问题现象:智能体调用工具出错、检索偏差后,删除错误记录重新执行,导致同类错误反复出现,任务完成率极低;
  • 核心原因:错误记录是智能体“学习进步”的关键,删除错误记录相当于剥夺其纠错机会,模型无法从历史错误中优化行为;
  • 解决方案:完整保留错误记录(工具名称、参数、错误提示),存入工作记忆,引导模型基于错误记录分析原因、生成修正方案,实现“越错越聪明”。

六、Manus记忆系统的进化路线与总结展望

1. 进化路线(官方规划)

Manus记忆系统并非一成不变,而是结合场景需求持续迭代,其官方公布的进化路线如下,可为开发者提供长期参考:

  • 2025 Q3:支持CAD图纸解析,重点适配制造业场景,进一步优化工业级记忆存储与检索效率;
  • 2025 Q4:接入物理设备控制(如机械臂操作),完善多设备协作场景下的记忆同步机制;
  • 2026年:实现跨平台工作流编排,打通ERP/CRM/OA等企业级系统,优化多系统协同场景下的记忆复用与同步。

2. 总结:Manus记忆系统的核心优势与适用场景

Manus记忆系统的核心竞争力,在于“实战、低成本、易落地”——它没有复杂的理论堆砌,所有技术设计、优化技巧、避坑方案,都源于真实场景的落地需求,其核心优势可总结为4点:

  1. 成本可控:通过KV缓存优化、可恢复性压缩,将运行成本降低90%以上,适配规模化落地;
  2. 效率出众:检索速度提升40%+,复杂任务完成率提升40%+,解决长流程、多工具协作的记忆痛点;
  3. 易集成:工程化实现逻辑简单,技巧可直接复用,无需深耕底层技术,降低开发门槛;
  4. 高通用:适配六大核心行业场景,支持混合云部署与权限管控,兼顾个人与企业级需求。

对于开发者而言,Manus记忆系统的最大价值,在于它提供了一套“可直接抄作业”的AI智能体记忆解决方案——无论是KV缓存的优化技巧、文件系统的集成逻辑,还是场景适配方案、避坑指南,都经过实战验证,无需从零搭建,可快速集成到自身AI智能体项目中,解决记忆相关的核心痛点。

3. 展望:AI智能体记忆的未来方向

随着Manus记忆系统的持续迭代,结合AI多智能体协作的发展趋势,未来AI智能体记忆系统将朝着三个方向进化:

  • 更智能的记忆管理:实现记忆的自主组织、自动权重调整,无需人工干预,更接近人类记忆模式;
  • 更低成本的落地:进一步优化缓存机制与存储方案,适配移动端、边缘计算等资源受限场景;
  • 更深度的协同融合:与大模型、工具系统、企业级系统深度打通,实现跨平台、跨智能体的记忆共享与复用,推动AI智能体从“单一工具”升级为“协同协作体”。

综上,Manus记忆系统作为AI智能体记忆领域的实战级标杆,其核心逻辑与实操技巧,不仅能帮助开发者快速落地高效、低成本的记忆模块,更能为AI多智能体协作的记忆设计提供重要参考——掌握Manus记忆系统的技术细节,无疑能让开发者在AI智能体落地赛道中抢占先机,解锁AI智能体“持续智能”的全新可能。

aic‍oding.sh 请手动输入访问哦~

🎉 天大的好消息! Claude 免费送余额啦

各位小伙伴们,激动的时刻到了!我们正式推出 Claude 免费体验计划,真金白银送给大家!

🎁 免费福利有多香?

让我给你算笔账:

  • 注册就送 $2 真实余额(不是优惠券哦)
  • Codex 只要 1 折( 1 折!!!)
  • Claude 只要 1.9 折(不到 2 折!!!)
  • 你的免费 $2 = 其他平台的 $10.5
  • 完全免费,不需要绑卡,不需要充值

🚀 怎么领取这份大礼?

超简单!两种方式随你选:

方式一:找机器人(推荐,秒到账)

  • 机器人已经修好啦,等着给大家发福利
  • 发个指令就能拿到 UID
  • 30 秒搞定,比点外卖还快

方式二:给我留言

  • 直接留言你的 UID
  • 我会定期帮你处理
  • 同样能拿到所有福利

💎 这个折扣有多绝?

说实话,我们的折扣真的是行业最低了:

  • Codex 1 折:相当于送你 10 倍额度
  • Claude 1.9 折:相当于送你 5.3 倍额度
  • 免费的 $2 能让你玩很久

🌈 为什么我们这么壕?

因为我们相信:

  • 好东西要让大家试试才知道
  • 用过的都说香,口碑比广告重要
  • 你们开心,我们就开心

🎯 能做什么?

这 $2 免费额度可以:

  • 写几十篇文章
  • 生成大量代码
  • 做多轮对话测试
  • 开发小项目原型
  • ……总之,够你好好体验一番!

还等什么?赶紧来领你的免费 Claude 额度吧!

有你们的支持,我们会做得更好 ❤️

本文围绕“瀑布管理工具”选型测评了 ONES、MS Project(MSP / Microsoft Project)、Oracle Primavera P6(P6 / Oracle P6)、Smartsheet、Tower、Wrike、Redmine。我将用“WBS—依赖/关键路径—里程碑/阶段门—基线偏差—资源成本—治理与协作”的框架,帮助管理者、PMO与项目经理做出可落地决策。

本文主要信息

  • 信息更新时间:2026-02-03
  • 核心关键词:瀑布管理工具、瀑布项目管理软件、甘特图工具、关键路径、基线管理、阶段门(Phase-Gate)、WBS
  • 适用读者:中高层管理者 / 项目经理 / 产品经理 / PMO
  • 本文解决的问题:瀑布项目为什么有计划也失控?不同类型工具各自擅长解决什么?如何按规模、角色、治理成熟度选到能落地的瀑布管理工具?
  • 测评结论:

    • 研发交付型瀑布项目:如果你要把 WBS/依赖/里程碑/基线 与研发任务、变更追溯、资源投入放进同一口径闭环,ONES 更适合作为计划与执行的统一平台(更利于偏差解释与责任链追溯)。
    • 排程计算优先:MSP / P6更擅长把关键路径与排程逻辑算清楚;其中MS Project对“关键路径分析 + 基线跟踪”的使用路径非常成熟。
    • 协作型甘特优先:Tower/Smartsheet / Wrike更适合把计划从个人文件迁移为团队共建事实(依赖联动、关键路径/基线视角),治理深度取决于组织流程与配套机制。

组织真正的难题,从来不是“有没有计划”

很多组织以为瀑布项目做不好,是因为“计划不够细”“甘特图不会画”。但我在制造、金融、政企与研发型组织里看到的更常见路径是:计划存在,但控制点缺失。

1.计划有了,但没有“可控基线”:管理层看到的是“最新版本”,却看不到“偏差从何而来”。没有基线,就没有偏差分析;没有偏差分析,复盘只能停留在情绪层。基线的本质是“经批准的参照”,是偏差与纠偏的起点。

2.里程碑存在,但缺少“阶段门的证据与责任”:瀑布的关键不是日期,而是“交付物是否满足验收标准”。里程碑如果只是时间点,没有验收清单、证据沉淀、责任人签收,阶段评审容易变成口头确认,风险被推迟爆发。

3.跨部门交接靠沟通,变更靠协调:瀑布项目往往跨团队、跨供应商、跨系统。此时最需要的是“变更可追溯 + 决策可审计”。否则一旦延期,组织会在“谁导致的”上消耗,而无法快速回到“关键路径怎么救”。

因此,2026年再谈“瀑布管理工具”,核心不在于“哪款工具甘特图最好看”,而在于:它能不能把组织的治理动作(基线、阶段门、变更、资源)沉淀为可执行、可追溯、可度量的过程。

2026年常用瀑布管理工具测评

1)ONES(国产、面向研发与交付闭环)

核心功能:以项目计划为主线,把瀑布项目的WBS、排期、协作、度量放在同一套数据口径里;并能把项目计划与研发任务、迭代与交付过程串起来,减少工作割裂。

瀑布管理能力:

  • WBS与任务依赖:可用项目计划创建WBS,并为任务设置前后置依赖,让任务链条与交付路径一目了然。
  • 里程碑与基线:支持用里程碑标记关键节点,并可设置“项目计划/里程碑基线”,对比计划与执行偏差;同时支持版本细节对比、追溯变更细节,这对解释偏差与形成复盘底稿很关键。
  • 资源与投入可视化:项目列表可快速查看项目状态、资源投入与当前进展;并可结合工时日历与饱和度报表做资源判断,避免“计划可行性建立在愿望上”。

适用场景:研发交付型瀑布项目、软硬件结合项目、阶段门清晰且需要跨团队协作与追溯的组织;尤其适合PMO希望把“计划—执行—变更—度量”做成闭环的团队。

优势亮点:ONES的优势在于它更容易把瀑布管理中最稀缺的两件事做实,一是基线与变更的可追溯(你能回答“什么时候开始偏、偏差从哪来”);二是计划与执行的口径一致(计划不是静态图,而是可持续更新的事实源)。

ONES 瀑布管理解决方案架构

2)Microsoft Project

核心功能:经典项目排程工具,擅长WBS排期、依赖网络、资源分配与报表输出。

瀑布管理能力:

  • 关键路径:支持在甘特与任务视图中显示关键路径,帮助项目经理识别“最影响完工日期”的任务链。
  • 基线:可为项目设置基线快照,并在项目推进过程中对比基线与当前计划,观察项目随时间如何变化。

适用场景:项目经理编制计划、输出对外进度表;工程/交付型项目经理需要快速产出一份严谨甘特与关键路径分析。

优势亮点:MSP的价值在于它的计划逻辑,WBS层级、依赖关系、关键路径与基线管理形成闭环后,你会发现很多延期并不是“团队不努力”,而是计划假设从一开始就不成立。

使用体验:MSP本质更偏“计划编制器”,多人协作、变更留痕、统一口径往往需要配套平台承接,否则会出现“计划很多、版本更多、真相最少”。如果你组织里有人在用 Project for the web,需要关注其向 Planner 的过渡与停用节奏(微软官方博客已说明将自动在8月完成停用/重定向相关安排)。把MSP定位为“排程与基线的专业工具”,再用协作平台承接任务更新与变更审计,通常比强行让MSP承担全链路协作更稳。

3)Oracle Primavera P6

核心功能:面向大型复杂项目的专业排程与控制工具,常用于工程建设、重资产与强约束项目,可以计算出复杂依赖网络的可执行进度。

瀑布管理能力:

  • CPM关键路径法:P6用活动工期与活动关系进行数学计算排程,强调把注意力聚焦在影响项目完成日期的关键路径活动上。
  • 基线对比:支持在布局中同时显示“当前条与基线条”,用于识别哪些任务开始/完成晚于计划,从而快速评估进度绩效。

适用场景:依赖关系复杂、资源约束强、审计要求高的项目/项目组合;尤其当组织需要把“计划—更新—偏差分析”做成严肃管理动作时,P6的优势会被放大。

优势亮点:当项目复杂到靠经验排不动的时候,P6能把复杂性变成可计算的进度网络;对PMO而言更像进度控制系统。

使用体验:P6要求WBS编码、日历、更新频率、基线策略都高度规范,治理基础薄弱的组织,上P6往往会先暴露“数据口径与角色职责”问题。建议先定义三件事再上系统:①WBS词典与编码规则;②基线策略(冻结点、审批权、可追溯要求);③进度更新节奏与审计机制。否则工具越强,越容易变成“数据争论场”。

4)Smartsheet

核心功能:表格化协作与甘特视图结合,支持多人在同一张表上更新进度、责任人与状态

瀑布管理能力:可启用依赖与前置任务(predecessors),并在甘特视图下查看关键路径。

适用场景:跨部门协作型瀑布项目(市场/研发/交付/运营共同参与),计划需要被团队共同维护,不追求工程级排程。

优势亮点:Smartsheet更像“协作底座 + 进度可视化”。当组织最大的痛点是信息滞后与口径不一致,它能用较低门槛把进度维护从“PM单点行为”变成“团队共同事实”。

使用体验:启用依赖后,Start/End/Duration/%Complete/Predecessors 等列会进入更强的系统控制(例如限制在相关列使用公式),这对“自由度高、喜欢用公式拼装表格”的团队是一种约束;但从瀑布治理角度看,这是为了减少口径漂移的必要手段。如果你需要更强的“阶段门审批、审计追溯、成本挣值”等重治理能力,Smartsheet往往需要与更强的治理平台协同工作,不能单独承担组织级交付系统的任务。

5)Tower

核心功能:Tower强调任务推进与团队协作,提供列表、日历、看板、时间线(甘特)等多视图,并用提醒与协作机制降低推进成本,适合把项目节奏变成团队的日常工作流。

瀑布管理能力:

  • 时间线视图(甘特图):任务设置开始/截止日期后可自动生成时间线,并支持拖拽调整任务条快速排期。
  • 任务依赖:支持在时间线中通过连线快速建立前置/后置依赖;也支持在任务详情页添加依赖关系。
  • 依赖联动与冲突防护:支持“自动调整后置任务时间”与“防止任务依赖冲突”,在前置任务改期时自动调整链路,减少瀑布计划里最常见的手工维护与依赖错位。
  • 里程碑管理:里程碑在Tower里可作为“特殊任务类型”,在列表/看板/时间线均有清晰标识,并可在“进展”里统一管理里程碑完成情况。

适用场景:中小团队、跨职能协作项目、管理层希望快速建立“里程碑+依赖”的可视化节奏;也适合把瀑布项目的计划维护从“PM单点”迁移为“团队共建事实”。

优势亮点:Tower 把瀑布项目最容易被忽视的两件事做得比较顺:依赖链条的联动维护(减少手工改期的错误与成本);里程碑的可视化与集中管理(让阶段节点更可控)。

使用体验:Tower更适合扮演“协作与推进层”,而不是最终的组织级治理底座。落地关键仍在方法:建议把里程碑与验收证据要求先定义清楚(什么算完成、谁签收、证据存哪里),否则里程碑仍可能回到“口头完成”。

6)Wrike

核心功能:以任务协作与跨团队推进为中心,同时提供甘特视图,适合把“排期、更新、追踪”放在同一套工作流里完成。

瀑布管理能力:依赖关系联动重排,关键路径聚焦风险;适合把“计划”与“执行”拉到同一节奏。

适用场景:多团队并行、需要在同一平台上维护计划与执行的中大型组织。

优势亮点:对项目经理而言,能把“排期维护”从体力活变成机制化更新;对管理层而言,关键路径让关注点更聚焦。

使用体验:如果你的组织把瀑布治理重心放在基线策略(何时冻结/何时允许重设)、阶段门证据、变更审批这些“制度化动作”上,落地前建议用真实项目POC去验证:这些治理动作是否能被系统自然承载,否则仍可能出现“协作很活跃,但审计与复盘缺底稿”。另外,关键路径是基于计划与依赖关系的“逻辑结果”,并不等同于“已经延期”;培训团队正确理解关键路径,可以减少无效焦虑与错误加班。

7)Redmine

核心功能:开源议题跟踪与项目协作工具,擅长把需求、缺陷、任务与版本发布绑定在一起

瀑布管理能力:Roadmap按版本/里程碑规划与管理进度;版本目标与证据可通过Wiki沉淀,适合把“阶段门”从口头变成可追踪条目。

适用场景:研发团队用“版本/里程碑 + 议题”推进瀑布交付;希望把阶段门证据、交付物与问题清单统一在可追溯的系统中。

优势亮点:Redmine并不是最强的排程工具,但它很擅长解决瀑布项目的“评审证据缺失”:延期不再是抽象的进度慢,而是清晰地落到哪个版本/哪个里程碑下哪些交付物没关门。

使用体验:对复杂关键路径/资源约束排程支持有限;如果项目高度依赖CPM排程或资源争用分析,应与MSP/P6或更强平台配合。如果没有明确的版本规划纪律(版本目标、纳入/剔除规则、变更审批),Roadmap也会被“需求塞车”冲垮——工具不能替代治理,只能放大治理水平。

常见问题 FAQ

Q:瀑布管理工具一定要有“基线”吗?
A:如果你希望做偏差分析与复盘(而不是只看“当前进度”),基线几乎是必选项。没有基线,延期只能凭感觉解释。

Q:协作型工具为什么对瀑布更重要?
A:因为瀑布项目最容易失控的是“信息滞后与口径不一致”。协作型工具能把计划变成团队共同维护的事实,而不是PM单点维护。

Q:平台型工具(如ONES/PPM)最大的价值是什么?
A:把“计划—执行—变更—证据—度量”连成闭环,让组织在同一套事实基础上决策,而不是在多套表格之间对齐。

Q:如何避免工具上线后变成“填报系统”?
A:先把三件事制度化:WBS模板、里程碑验收清单、基线与变更策略(何时重设、谁批准、如何留痕)。

Q:什么时候应该从桌面排程工具升级到平台?
A:当你出现以下任意两条:多项目并行、跨部门交付频繁、延期原因说不清、资源冲突常态化、阶段门评审流于形式。

image.png
image.png

分享一个免费不限量 Claude API 公益服务,请作为兜底使用。支持 OpenAI 和 Anthropic 格式。

  • 不用注册
  • 免费
  • 不限量
  • 真模型

自己服务不能用了再用这个作为兜底,别做主力使用,不保证稳定性,只保用到的模型是真的模型。

网址自行解码:aHR0cHM6Ly9vbmVkYXlhaS5hdXRvY29kZS5zcGFjZS8=

🙏赛博活佛🙏

图片
2月3日,中国信息通信研究院“方升”智测研讨会在北京石景山区隆重举办。本次大会由人工智能大模型及软硬件评测工业和信息化部重点实验室主办,中国人工智能产业发展联盟、工业和信息化部人工智能标准化技术委员会承办,枫清科技与中关村数智人工智能产业联盟协办。石景山区政府、信通院及多家企业代表出席本次大会。

会议旨在构建科学、可衡量的人工智能技术评价体系,推动前沿技术基准测试向系统化、标准化、实用化方向演进。

第二批“方升”行业大模型基准共建仪式在大会中隆重举行,枫清科技联合创始人兼COO葛爽受邀参加了启动仪式。依托“方升”基准,会议正式启动并推动建立覆盖金融、制造、教育等多个垂直领域的“人工智能+行业”专属基准测试体系,促进技术标准与产业需求深度融合。
图片
作为本次论坛的协办单位代表,葛爽在接受央视采访时表示:“枫清科技将图计算与大模型深度融合,通过“知识引擎+大模型”双轮驱动,打造了全球领先的新一代企业级智能体平台。中国信通院人工智能研究所非常认可枫清的技术积累和先进水平,双方达成了战略性的深度合作,并共同参与多项行业标准制定,助力构建科学和权威的AI评测体系。

在石景山区,枫清科技与火山引擎联合建设AI4S科研平台,覆盖科研全流程,赋能区域产业智能化升级,为AI技术落地提供坚实支撑。同时我们已在化工能源、先进制造、生物医药等多个行业落地AI应用,获得中国信通院“大数据星河标杆案例”等多项大奖。这些都为AI技术评测提供了十分匹配的应用场景。

”据悉,中国信通院依托“方升”大模型测试体系,在过去一年中持续深化布局,已将体系迭代演进至3.0版本。基于“方升”3.0体系,中国信通院已积累了超过780万条测试数据,并建立了按季度对外发布测试结果的常态化监测机制。“方升”体系正通过动态自适应测试方法,为中国人工智能产业提供精准、可信的“基准标尺”。

未来,枫清科技将在与信通院的深度合作中,将核心技术持续融入AI评测体系,助力构建面向产业的全链条AI评测能力,推动区域AI产业高质量发展。