包含关键字 typecho 的文章

需求:在 Azure 上部署 Prometheus

但是不知道是该用 Container Apps 还是 Container Instance 亦或者是 Azure Managed Prometheus。
有没有用过的小伙伴,想参考一下意见。doge

各位 V 友好,来分享一下自己正在做的一个项目。 我是一名大一学生,去年高考完在知乎上发过一本自己写的高中数学教材&教辅,反响还不错。

写教材的过程中发现一个痛点:市面上没有一款软件能覆盖完整的学习链路——从 输入 → 巩固复习 → 输出 全流程打通。现有工具要么只做阅读,要么只做闪卡,要么只做笔记,想串起来得在好几个 App 之间反复横跳。

所以就自己动手做了 Yaru,一个多合一的学习工作台。目前还在早期开发阶段,先放出来听听大家的想法。

核心模块

  • 📖 学习模块 — 类似 Brilliant / Math Academy 的交互式课堂,按 Roadmap 选课学习

  • 📚 书库模块 — 支持 PDF / EPUB / MOBI / AZW3 / Markdown / HTML 等格式,社区书库 + 本地导入,可普通阅读或渐进式阅读

  • 🧠 记忆模块 — 间隔重复闪卡,后续会针对语言学习做更深度的适配

  • ✍️ 创作模块 — 积木式编辑器

  • 🧩 扩展模块 — 计划支持浏览器扩展、RSS ,以及从 B 站 / YouTube 视频中提取摘要导入(尚未开发)

  • 📝 笔记 / 题库 / 论坛 — 规划中 一个典型的使用流程:在书库里读一本书 → 在类似 NotebookLM 的面板里生成闪卡和习题 → 闪卡自动进入记忆模块,习题进入题库 → 形成闭环。

  • 特点

  • Material You 设计,界面干净无广告

  • 跨平台:Android / Windows / Linux / macOS / Web - 积木编辑器( Block Editor )

  • 自实现的增强 Markdown 格式( yfm )

目前的开发截图

首页 首页 1 首页 2

学习模块(开发中)

学习 1 学习 2

记忆模块

记忆 1 记忆 2 记忆 3 记忆 4

书库模块

书库 1 书库 2

创作模块

创作

扩展模块(尚未开发)

扩展

当前状态

项目还在早期阶段,内容侧还没来得及填充,功能也在持续迭代中。先把架子搭起来,后面慢慢打磨。

至于里面的内容,我自己也是有内容生产能力的。生产中学和本科,以及一些编程语言,或者是 AI 方面的应用课程,也有点余力。

以后目的是先在国内试水,之后出海。

使用

可以在线使用 Flutter Web ,之后各平台打包后再补充。

在线体验

产品落地页

产品落地页

我的个人主页

个人主页

欢迎各位 V 友提提建议、聊聊想法,不管是功能方向还是设计细节都很想听听反馈 🙏

麒麟桌面系统V11版本的安装和V10-SP1的过程基本一样,下面看看详细的步骤吧,有什么不懂的,可以评论区提问。

一、启动引导

  1. 将安装光盘或者放入光驱中,或者插入做好的U盘启动盘,重启机器。
  2. 根据固件启动时的提醒,进入固件管理界面。

    • 若使用的是内置光驱,“第一启动选项”选择“光驱”;
    • 若使用的是USB或者USB外置光驱,“第一启动选项”选择“USB”。
  3. 系统支持体验模式,可试用一个全功能的操作系统而不安装。

二、系统安装

  1. 选择系统语言。
    file
  2. 点击“下一步”,阅读许可协议,并勾选,我已阅读并同意<<试用免责协议>>和<<用户隐私协议>>。
    file
  3. 点击“下一步”,选择所在时区,
    file
  4. 点击“下一步”,选择安装途径(选择默认的live安装即可)
    file
    点击“下一步”,进入选择安装方式界面,这里分两种方式安装(下面分别介绍两种方式安装的方法)

    • 全盘安装(快速安装):系统将自动分区,自动格式化硬盘进行安装;
    • 自定义安装:由用户自定义对硬盘进行分区,电脑里有资料未备份的,建议使用该方式自定义安装系统;

    全盘安装(快速安装)

  5. 选择“快速安装”将进行全盘安装,该选项将会格式化整个硬盘,并进行自动分区。
    file
  6. 点击“下一步”,勾选上“格式化整个磁盘”
    file
  7. 点击“下一步”进入创建账户页面,创建账户可选择立即创建,或待系统安装完成后,再创建账户
    file
  8. 这里勾选“立即创建”点击“下一步”,进入创建用户界面
    file
  9. 创建用户需要注意:密码前后两次需保持一致,密码包含字符类型不得少于两种,长度不得少于八个字符,且密码不能包含用户名,否者无法创建账户
    file
    点击开始安装后,进入安装界面等待即可。
     

自定义安装

  • 使用自定义安装可以自行设计各硬盘分区大小。
    在安装类型界面选择“自定义安装”出现硬盘分区界面。点击“创建分区表”,弹出提示窗口,选择“+添加”,即可创建硬盘分区。
    file
  • /boot分区(系统引导分区),/boot必须是主分区中的第一个分区,是必须创建的,如下图所示:
    file
  • swap分区(交换分区),在创建交换分区时,交换分区大小一般设置为内存的2倍大小,“新分区的类型”选择“逻辑分区,“新分区的位置”保持默认,“用于”选择“linux-swap”,如下图所示:
    file
  • /分区”也叫根分区,创建如下图所示,在创建根分区的时候,“新分区的类型”选择“主分区”,“新分区的位置”默认为“空间起始位置”,“用于”选择“ext4”;
    file
  • /backup分区(备份还原分区),非必须,但只有创建了该分区,备份还原的功能才可以使用。
  • /data分区(数据分区),可设置为剩下未分配空间的所有空间。/data分区就类似于Windows系统D盘,建议“自定义安装”创建。
    /backup分区/data分区分区创建时,“新分区的类型”选择“逻辑分区”,“新分区的位置”默认为“空间起始位置”,“用于”选择“Ext4”,挂载点选择对应的/backup,用于选择用户数据分区,挂载点选择对应的/data即可;
    建议/backup分区和根分区大小一致。/data分区大小根据用户实际情况填写即可
    file
    file
  • 若是中途需要改变已创建的分区,具体方式如下所示:

    • 添加分区:选中空闲分区所在行,点击“+”按钮。
    • 编辑分区:选中已创建的分区,点击“更改”按钮。
    • 删除分区:选中已创建的分区,点击“-”按钮。
  • 创建分区完成后如下图所示,点击“下一步”进入“确认自定义安装”如下图所示:
    file

分区完成后,点击“开始安装”,开始安装系统。等待安装完成后,重启系统即可!

本文由mdnice多平台发布

"There is no royal road to logic, and that acts as its formidable guardian."
逻辑没有平坦的大道,而这正是它令人着迷之处。

继“摸鱼助手”之后,豫唐工具集 再次推出重磅力作 —— 数独挑战 (Sudoku Challenge)。这不仅是一个游戏,更是一次对经典逻辑谜题的现代化重构。

本文将从技术角度,剖析我们是如何在纯前端环境下,实现一个轻量级、高性能且具备无限关卡生成能力的数独引擎。

image.png

1. 核心算法:混沌与秩序的平衡

告别千篇一律的死板题库。每一局游戏,都是后台算法在毫秒间的即兴创作。

1.1 生成策略:回溯法 (Backtracking)

传统的数独生成往往依赖预置题库,而我们选择了动态生成。核心算法采用了 "对角线先行 + 全局求解 + 随机挖洞" 的三步走策略:

  1. 对角线填充 (Diagonal Filling)
    首先填充三个对角线上的 3x3 宫格。由于这三个宫格相互独立(行、列、宫均不重叠),我们可以随机填充 1-9 而无需担心冲突。这一步极大地减少了后续回溯的搜索空间。
  2. 全局求解 (Solver)
    利用递归回溯算法,填充剩余的空格。如果遇到死胡同,则回退一步,直到填满整个网格,生成一个完整的、有效的数独终局。
  3. 随机挖洞 (Digging)
    这是生成谜题的关键。我们随机移除棋盘上的数字(挖洞),每移除一个数字,都必须确保剩下的残局 仍然拥有唯一解。如果移除导致多解或无解,则回溯填回。

1.2 核心代码一览

// 核心生成流程
function generateNewLevel() {
  // 1. 初始化空网格 (9x9)
  let grid = Array(9)
    .fill()
    .map(() => Array(9).fill(0));

  // 2. 种子填充:填充对角线上的 3x3 宫格
  // 这一步是性能优化的关键,避免了从空盘开始回溯的最坏复杂度
  fillDiagonal(grid);

  // 3. 求解填充:生成一个完整的数独终局
  solveSudoku(grid);
  solutionBoard = JSON.parse(JSON.stringify(grid)); // 存档终局用于验证

  // 4. 制造谜题:随机挖去约 45 个数字
  // (实际难度可通过调整挖洞数量控制)
  removeDigits(grid, 45);
  originalBoard = grid;
}

2. 交互体验:键盘与鼠标的双重奏

好的工具应该适应用户,而不是让用户适应工具。我们在交互设计上做了细致的打磨:

  • 双模输入:支持鼠标点击数字面板,也完全支持键盘操作(方向键导航、数字键填入、Backspace 删除)。
  • 智能高亮

    • 选中一个单元格,所在的行、列、宫格自动高亮,辅助视觉定位。
    • 选中一个数字,棋盘上所有相同的数字同步高亮,快速识别剩余分布。
  • 实时反馈:填入错误数字时不会立即报错(保留试错的乐趣),只有点击“检查”按钮时,系统才会通过 DOM 操作高亮错误单元格。
// 智能高亮逻辑片段
function highlightRelated(row, col) {
  $(".cell").each(function () {
    const r = parseInt($(this).atrr("data-row"));
    const c = parseInt($(this).atrr("data-col"));

    // 判断是否属于同一行、同一列或同一 3x3 宫格
    const sameBox =
      Math.floor(r / 3) === Math.floor(row / 3) &&
      Math.floor(c / 3) === Math.floor(col / 3);

    if (r === row || c === col || sameBox) {
      $(this).addClass("related"); // 添加高亮样式
    }
  });
}

3. 打印友好:极致的“纸质感”

我们深知,数独的最高境界往往发生在笔尖与纸面的摩擦之间。为此,我们利用 CSS3 的 @media print 特性,打造了极致的打印模式。

  • 一键去噪:点击打印,display: none 自动隐去导航栏、按钮等所有干扰元素。
  • 墨水优化:强制重置背景色为纯白,边框调整为纯黑高对比度,确保打印出的盘面清晰、锐利,且节省打印机墨水。
  • 跨屏接力:纸质版右上角保留二维码,手机扫一扫即可回到线上继续挑战。
@media print {
  /* 核心打印样式 */
  .noprint {
    display: none !important;
  }

  .sudoku-board {
    width: 14cm; /* 适配 A4 纸张宽度 */
    height: 14cm;
    border: 4px solid black; /* 加粗外边框 */
    margin: 2cm auto;
  }

  .cell {
    color: black !important;
    background: white !important; /* 强制去底色 */
    font-size: 24pt; /* 增大字号提升可读性 */
  }
}

4. 纯粹与安全

秉承 豫唐工具集 一贯的理念:

  • Zero Server:0% 后端代码,所有逻辑完全由 JavaScript 在浏览器端完成。
  • 100% Privacy:没有数据上传,没有服务器窥探。这是一个完全属于你的、私密的逻辑训练场。

在线体验

在线演示https://www.ytecn.com/dev/tool/sudoku.html
开源地址https://gitee.com/ytecnsong/web-dev-toolkit

数独挑战 (Sudoku Challenge) 现已上线。
这不只是代码的堆砌,这是逻辑之美。

在前一篇 《Flink 双流 JOIN 实战详解》 中,我们用「订单流 + 支付流」搞懂了事实双流之间的时间关联。

但在真实的实时数仓项目里,光有事实流还不够,业务同学更关心的是:

  • 下单用户是新客还是老客
  • 用户当前的等级、城市、渠道
  • 商品所属品类、类目层级

这些信息通常存放在 维度表(维表)中,例如 MySQL 的 dim_userdim_product 等。我们希望在实时计算时,能把「事实流」和「维表」在时间维度上正确地关联起来,构建一张带有完整业务属性的明细宽表

这就是 维表时态 Join(Temporal Table Join) 要解决的问题。

本文我们就以「订单事实流 + 用户维表」为例,完成一个从 Kafka 到 MySQL 的简易实时数仓 Demo,并重点理解 Flink SQL 中维表时态 Join 的语法和注意事项。

一、业务场景与数仓目标

设想一个简化的电商业务场景:

  • Kafka 中有实时写入的 orders 订单事实流
  • MySQL 中维护一张 dim_user 用户维表,包含用户等级、所属城市、注册渠道等信息

我们想要在 Flink 中构建一张「订单明细宽表」,字段大致包括:

  • 订单信息:订单号、下单用户、下单金额、下单时间
  • 用户属性:用户昵称、等级、城市、注册渠道

并且要求:

  • 当我们回看 10 分钟前的某条订单时,看到的是 当时 用户的等级和城市,而不是被后续变更“冲掉”的最新值

这正是 时态 Join 和「实时数仓」的关键:按事件发生时刻回放维度视图

二、环境前提与依赖准备

1. 基础组件

本篇默认你已经完成前几篇中的环境准备:

  • Flink 1.20.1(WSL2 Ubuntu 下部署)
  • Kafka 集群已启动,且能正常写入 / 读取 Topic
  • Flink SQL Client 可以正常连接集群

在此基础上,我们还需要:

  • 一套可访问的 MySQL(本地或远程均可)
  • Flink 的 JDBC Connector JAR 包

2. 安装 Flink JDBC Connector

和 Kafka 一样,JDBC 连接器也需要以 JAR 包形式放到 Flink 的 lib 目录中。

以 Flink 1.20.x 对应的 flink-connector-jdbc 为例:

  1. 确认 Flink 安装目录(假设为 /opt/flink):

    export FLINK_HOME=/opt/flink
  1. 下载 JDBC Connector JAR 到 Flink 的 lib 目录:

    cd $FLINK_HOME/lib
    wget https://repo1.maven.org/maven2/org/apache/flink/flink-connector-jdbc/3.3.0-1.20/flink-connector-jdbc-3.3.0-1.20.jar
  2. 如果你使用的是独立集群或远程集群,需要重启 Flink 集群,让新 JAR 在 JobManager/TaskManager 上生效:

    cd $FLINK_HOME
    bin/stop-cluster.sh
    bin/start-cluster.sh
  3. 重启 Flink SQL Client,使用新 Connector:

    cd $FLINK_HOME
    bin/sql-client.sh

如果你在 Windows + WSL2 上部署,只需在 WSL2 内执行上述命令即可;或者手动下载 JAR 后拷贝到 lib 目录,步骤完全一致。

三、准备 MySQL 用户维度表 dim_user

首先在 MySQL 中准备一张简单的用户维度表,用来存用户的基础属性。

在 MySQL 中执行:

CREATE DATABASE IF NOT EXISTS realtime_dwh;
USE realtime_dwh;

CREATE TABLE dim_user (
  user_id      VARCHAR(32)  PRIMARY KEY,
  user_name    VARCHAR(64),
  user_level   VARCHAR(16),
  city         VARCHAR(64),
  register_time DATETIME
);

INSERT INTO dim_user (user_id, user_name, user_level, city, register_time) VALUES
('u_1', '张三', 'VIP1', '北京', '2025-12-01 10:00:00'),
('u_2', '李四', 'VIP2', '上海', '2025-12-05 11:00:00'),
('u_3', '王五', 'VIP1', '广州', '2025-12-10 12:00:00');

为了演示「时态」效果,你可以在后续实验中手动更新某个用户的等级或城市,例如:

UPDATE dim_user
SET user_level = 'VIP3'
WHERE user_id = 'u_2';

这样我们在 Flink 里做时态 Join 时,就能观察“变更前后”的区别。

四、在 Flink 中注册事实流与维表

接下来回到 Flink SQL Client,把 Kafka 中的订单事实流和 MySQL 中的维表都注册成 Flink 表。

1. Kafka 订单事实表 orders

和上一篇双流 JOIN 类似,我们假设 Kafka 中有一个 orders Topic,写入订单事实数据。

在 Flink SQL Client 中执行:

CREATE TABLE orders (
  order_id     STRING,
  user_id      STRING,
  order_amount DECIMAL(10, 2),
  order_time   TIMESTAMP_LTZ(3),
  WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND,
  proc_time AS PROCTIME()
) WITH (
  'connector' = 'kafka',
  'topic' = 'orders',
  'properties.bootstrap.servers' = '127.0.0.1:9092',
  'properties.group.id' = 'flink-orders-dim',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json',
  'json.timestamp-format.standard' = 'ISO-8601'
);

你可以沿用上一篇中 Kafka 造数的方式,用 kafka-console-producer.sh 发送 JSON 订单数据,只需要保证字段名一致。

2. MySQL 用户维表 dim_user(JDBC Lookup 表)

然后把刚才在 MySQL 中建好的 dim_user 注册为 Flink 的 JDBC 表:

CREATE TABLE dim_user (
  user_id       STRING,
  user_name     STRING,
  user_level    STRING,
  city          STRING,
  register_time TIMESTAMP(3),
  PRIMARY KEY (user_id) NOT ENFORCED
) WITH (
  'connector' = 'jdbc',
  'url' = 'jdbc:mysql://127.0.0.1:3306/realtime_dwh',
  'table-name' = 'dim_user',
  'driver' = 'com.mysql.cj.jdbc.Driver',
  'username' = 'root',
  'password' = '1qaz@WSX'
);

注意几点:

  • PRIMARY KEY (user_id) NOT ENFORCED 告诉 Flink 这是一张以 user_id 为主键的表,是做时态 Join 的前提
  • 这里使用的是典型的 JDBC Lookup 模式,Flink 会在 Join 时按需去 MySQL 查维度信息

在生产环境中,你可以把 MySQL 作为维度存储,或者通过 CDC 把维表变更同步到 Kafka,构造成 changelog 流,这些都可以和 Temporal Join 结合使用。

五、维表时态 Join:把订单打上用户维度

有了订单事实表 orders 和维度表 dim_user,就可以通过时态 Join 来构建订单明细宽表。

1. 基础时态 Join 语法

Flink SQL 中的 Temporal Table Join 对于 JDBC 这类 外部维表,通常采用「处理时间(Processing Time)」语义来做 Lookup Join,典型写法如下:

SELECT
  o.order_id,
  o.user_id,
  d.user_name,
  d.user_level,
  d.city,
  o.order_amount,
  o.order_time
FROM orders AS o
LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proc_time AS d
ON o.user_id = d.user_id;

FlinkJoin
这里有几个关键点:

  • proc_time AS PROCTIME() 是在 orders 上定义的处理时间字段
  • FOR SYSTEM_TIME AS OF o.proc_time 表示“以 Flink 处理这条订单记录的当前时间,去查维表的一个快照”,这是 JDBC Lookup 支持的典型用法
  • Join 条件依然是 user_id 等值关联
  • 使用 LEFT JOIN 可以保留找不到维度的订单,并用空值来表示“维度缺失”

在 SQL Client 中执行这段查询,会看到实时流式刷新的结果,每一行订单都带上了对应的用户属性。

2. 验证时态效果:修改维表再观察 Join

为了验证这是“时态 Join”而不是“始终查最新维度”,可以按下面步骤操作:

  1. 先往 Kafka 的 orders Topic 写入几条订单数据,例如用户 u_2 下单的记录
  2. 观察 Flink SQL 中 Join 后的结果,此时 u_2 的等级是 VIP2
  3. 回到 MySQL,执行:

    UPDATE dim_user
    SET user_level = 'VIP3'
    WHERE user_id = 'u_2';
  4. 再写入一批新的订单,仍然是用户 u_2
bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic orders

在命令行中输入一条 JSON 数据(按回车发送一条):

{"order_id":"o_3","user_id":"u_2","order_amount":200.00,"order_time":"2026-02-19T14:42:00Z"}

FlinkJoin
这时你会看到:

  • 变更前的订单,维度字段仍然显示 VIP2
  • 变更后的订单,维度字段变成了 VIP3

这就说明 Flink 的时态 Join 确实是“按订单发生时刻去回放维度视图”的,而不是简单查当前最新值。

六、把结果写回 Kafka 或 MySQL,形成实时数仓明细层

在真实项目中,我们不会只在 SQL Client 里 SELECT 一下就结束,而是要把 Join 后的订单明细宽表,写回到下游存储,形成实时数仓的一个层级。

例如,可以把结果写回 Kafka,作为 DWD 层的订单宽表:

CREATE TABLE dwd_order_user_wide (
  order_id     STRING,
  user_id      STRING,
  user_name    STRING,
  user_level   STRING,
  city         STRING,
  order_amount DECIMAL(10, 2),
  order_time   TIMESTAMP_LTZ(3),
  WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'dwd_order_user_wide',
  'properties.bootstrap.servers' = '127.0.0.1:9092',
  'properties.group.id' = 'flink-dwd-order-wide',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json',
  'json.timestamp-format.standard' = 'ISO-8601'
);

INSERT INTO dwd_order_user_wide
SELECT
  o.order_id,
  o.user_id,
  d.user_name,
  d.user_level,
  d.city,
  o.order_amount,
  o.order_time
FROM orders AS o
LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proc_time AS d
ON o.user_id = d.user_id;

这样,下游的实时应用或 BI 查询就可以直接订阅 dwd_order_user_wide 这个 Topic,拿到已经打好用户标签的订单明细数据。

你也可以把结果同步到 MySQL、ClickHouse 等分析型数据库中,构建实时明细表,为报表和可视化提供数据。

七、小结与下一步建议

通过这篇文章,我们完成了这样一件事:

  • 在 Kafka 中维护订单事实流 orders
  • 在 MySQL 中维护用户维度表 dim_user
  • 使用 Flink SQL 的 JDBC Connector 把 MySQL 注册为维表
  • 利用 FOR SYSTEM_TIME AS OF 语法做维表时态 Join
  • 将 Join 结果写回 Kafka,形成实时数仓中的一张订单明细宽表

这背后有几个非常重要的实时数仓设计理念:

  • 事实流是不断追加的事件序列,维表是相对缓慢变更的业务视图
  • 时态 Join 让你能够“按事件发生的时间点”,回看当时的维度快照
  • 实时数仓的 DWD 层,往往就是「事实表 + 多个维表时态 Join」后形成的明细宽表

在后续的文章中,我们可以继续沿着这个方向深入:

  • 在一个任务里同时关联多张维表,构建更宽的明细表
  • 引入 CDC,把维表变更实时同步到 Kafka,再在 Flink 中构建 changelog 维表
  • 把实时数仓的明细层、汇总层(DWS)、指标主题层(ADS)串起来,做一个端到端的实时数仓小项目

如果你已经跑通了本文的 Demo,不妨试着自己设计一张商品维表 dim_product,再给订单打上商品品类维度,体验一下“事实 + 多维表时态 Join”在 Flink SQL 里的完整味道。


原文来自:http://blog.daimajiangxin.com.cn

不知道用 mac 的各位 2 友们有没有深入使用过系统自带的 Pages 应用
在很久之前我就很讨厌阅读和编写 word 文档, 收到 word 文档后我都会转成 pdf 后再读. 但总会有编写设计文档之类的工作, 就很痛苦.
前段时间尝试了一下这个一直躺在我应用列表但从未打开过的 Pages 应用, 发现意外的好用. 这里分享几个技巧:

  • 使用 pages 打开别人的 word 文档后, 第一件事是⌘+a, 把字体替换为SF Pro, 是的, 微软的那套字体我是真喜欢不起来, 换字体后行间距也大概率变得更有可读性了.
  • 活用 pages 应用内提供的文件格式转换功能: image

纯分享, 各位请畅所欲言~

今日速览

  1. Sonnet 4.6:Claude 最强模型,性能接近 Opus,价格更亲民。
  2. Moda:AI 设计神器,生成可编辑的幻灯片、海报,告别模板束缚。
  3. Omnia:让品牌在 AI 搜索中脱颖而出,监控曝光、分析对手。
  4. Flixier:AI 视频编辑一体化,在时间轴上直接生成、扩展片段。
  5. ClawMetry:OpenClaw AI 代理的实时监控仪表板,一键安装免配置。
  6. Empirical Health:网页版心脏健康管理,查看血液报告、评估风险更方便。
  7. Travel Animator:动态地图标注旅行地点,个性化路线一目了然。
  8. Calendarly:日历变锁屏壁纸,日程自动更新,拿起手机就能看。
  9. Design Rails:对话 AI 创意总监,几分钟打造完整品牌识别方案。
  10. SPECTRE:智能编码工作流程,帮 AI 助手产出高质量代码。


1. Sonnet 4.6

Claude 家族的最新力作,这次升级让它在编码、设计、长文本推理等领域全面爆发,智能水平直逼顶级模型,但价格更接地气,适合日常任务。

  • 性能大幅提升,接近 Opus 级别
  • 支持 100 万 token 的上下文窗口
  • 计算机使用技能显著增强
  • 覆盖编码、知识工作、代理规划等多场景

热度:🔺543

Sonnet 4.6

访问官网 Product Hunt 详情


2. Moda

终于来了!这款 AI 设计工具能生成美观且符合品牌的内容,从幻灯片到广告一应俱全,关键是所有设计都能在分层画布里随意编辑,告别死板模板。

  • 生成可完全编辑的 AI 设计
  • 支持幻灯片、海报、广告等多种格式
  • 强大分层画布,灵活调整元素
  • 确保品牌一致性,提升视觉冲击力

热度:🔺481

Moda

访问官网 Product Hunt 详情


3. Omnia

想知道 AI 怎么看待你的品牌吗?Omnia 帮你透视 AI 推荐逻辑,监控曝光、分析对手,还能生成提升搜索可见性的内容,让品牌在 AI 时代站稳脚跟。

  • 分析 AI 如何推荐你的品牌
  • 监控品牌曝光和竞争对手动态
  • 发现真实 AI 提示,优化内容策略
  • 提升在 AI 搜索中的引用率和可见性

热度:🔺282

Omnia

访问官网 Product Hunt 详情


4. Flixier Generate AI Video in Timeline

大多数 AI 视频工具只负责生成,Flixier 却把 AI 塞进编辑时间轴,让你在一个地方搞定生成、扩展、连接视频片段,裁剪润色一气呵成,不用到处导出重建。

  • 在时间轴上直接生成和扩展视频镜头
  • 连接剪辑,无缝拼接片段
  • 支持裁剪、润色等编辑功能
  • 一体化工作流,无需导出或切换工具

热度:🔺185

Flixier Generate AI Video in Timeline

访问官网 Product Hunt 详情


5. ClawMetry for OpenClaw

专为 OpenClaw AI 代理打造的免费开源监控仪表板,就像 Grafana 的 AI 版,一键安装就能实时追踪令牌费用、子代理活动,数据通过动态可视化清晰呈现。

  • 免费开源,专注于 AI 代理可观测性
  • 一键安装(pip install clawmetry),无需配置
  • 实时监控令牌成本、子代理活动、会话历史
  • 支持 macOS、Linux、Windows 甚至 Raspberry Pi

热度:🔺164

ClawMetry for OpenClaw

访问官网 Product Hunt 详情


6. Empirical Health for web

之前只能在手机 app 上管理心脏健康?现在网页版来了!在大屏幕上查看血液检测报告(超过 100 个生物标志物)、评估心脏病风险、联系医生,一切变得更轻松。

  • 网页端直接访问,无需下载 app
  • 查看详细血液检测结果和生物标志物
  • 评估心脏病发作风险评分
  • 支持发送消息给医生、安排实验室复查

热度:🔺142

Empirical Health for web

访问官网 Product Hunt 详情


7. Travel Animator

旅行时总想记录每个停靠点?Travel Animator 让你在动态地图上标注地点,从六种样式、七种颜色中自由选择,标签模式可调,旅程路线瞬间清晰又个性。

  • 在动态地图上标注旅行地点
  • 六种设计样式和七种颜色可选
  • 支持“当前”、“已访问”、“始终显示”标签模式
  • 随时编辑或删除标签,个性化讲述旅程

热度:🔺130

Travel Animator

访问官网 Product Hunt 详情


8. Calendarly

厌倦了在锁屏上找日程?Calendarly 把你的日历变成动态壁纸,自动更新一天安排,拿起手机就能看,无需小部件或打开 app,设计模板还能随心定制。

  • 将日历实时显示为锁屏壁纸
  • 自动更新日程,无需手动操作
  • 精美模板可选,全面定制布局和风格
  • 完全保护隐私,所有功能在设备上运行

热度:🔺124

Calendarly

访问官网 Product Hunt 详情


9. Design Rails

想快速打造品牌识别?和 AI 创意总监聊几句,几分钟内拿到完整的 logo、配色、字体方案,文件直接丢进项目,让工具从第一天就生成品牌一致的界面。

  • 对话式 AI 创意总监,快速生成品牌方案
  • 包含 logo、配色、字体、声音语调、UI 风格
  • 提供代理准备文件,开箱即用
  • 兼容 Claude、Lovable 等工具,确保品牌一致性

热度:🔺123

Design Rails

访问官网 Product Hunt 详情


10. SPECTRE

给 AI 编码助手套上智能工作流程,通过 /范围、/计划、/执行 等步骤,引导它产出高质量代码,适合产品开发者提升效率。

  • 智能编码工作流程,涵盖规划到评估
  • 通过逐步开发方式提升代码质量
  • 支持 /范围、/计划、/执行、/清理、/测试、/重基、/评估 步骤
  • 帮助 AI 编码代理生成可靠成果

热度:🔺111

SPECTRE

访问官网 Product Hunt 详情

如何成为鸿蒙架构师?
架构师的设计思维具有多方面的特点,以下是一些主要的方面。

系统性

架构师设计系统时,应具备系统性思维。

  • 整体考量:架构师在进行设计时,会将整个系统视为一个有机的整体,考虑系统的各个组成部分之间的相互关系、相互作用以及它们如何协同工作以实现系统的整体目标。例如,在设计一个大型企业级应用系统时,不仅要关注各个功能模块如用户管理、订单处理、数据分析等的功能实现,还要考虑这些模块之间的数据交互、接口设计以及它们对整个系统性能、可维护性的影响。
  • 深入理解业务:架构师处理考虑技术方面的需求之外,还要需要深入了解软件所服务的业务领域,包括业务流程、业务规则和业务目标等,以设计出符合业务需求的软件架构。
  • 层次分明:能够将系统分解为不同的层次,每个层次具有明确的职责和功能,并且层次之间存在清晰的接口和交互规则。以网络架构设计为例,会分为物理层、数据链路层、网络层、传输层、应用层等,每层都为上层提供服务,同时依赖下层的支持,通过这种分层架构提高系统的可扩展性和可管理性。
  • 功能分解:架构师将软件系统按照功能进行分解,划分为多个独立的模块,每个模块负责特定的功能,具有明确的职责和边界。
  • 高内聚低耦合:模块内部的功能应该紧密相关,具有高内聚性;模块之间的依赖关系应该尽量减少,具有低耦合性,以提高系统的稳定性和可维护性。

抽象性

架构师设计系统时,应具备抽象思维。

  • 提取共性:能够从复杂的现实世界问题或业务需求中,提取出共同的、本质的特征和规律,忽略无关紧要的细节,形成抽象的概念和模型。比如,在设计数据库架构时,会将不同类型的业务数据抽象为实体和关系,建立起数据库的概念模型,而不关心具体的数据实例和业务流程的细节。
  • 建立模型:善于使用各种抽象模型来描述系统的结构、行为和关系,如使用UML(统一建模语言)类图、序列图、状态图等来对软件系统进行建模,通过这些模型来帮助理解、设计和沟通系统的架构,使复杂的系统更容易被理解和处理。

前瞻性

架构师设计系统时,应具备前瞻性思维。

  • 技术趋势洞察:关注行业内的技术发展趋势,了解新技术的出现和应用场景,能够判断哪些新技术可能对当前的架构设计产生影响,并在设计中预留一定的扩展空间,以便未来能够顺利引入新技术。例如,在设计云计算架构时,会考虑到容器技术、人工智能等技术的发展趋势,为系统未来可能的升级和扩展做好准备。
  • 业务发展预判:不仅仅满足于当前的业务需求,还会与业务团队密切合作,深入了解业务的发展战略和方向,预测未来可能出现的业务变化和增长,从而在架构设计中采取相应的措施,以确保架构具有足够的灵活性和适应性。比如,在设计电商平台架构时,会考虑到未来可能的业务拓展,如增加新的业务线、拓展国际市场等,提前设计可扩展的架构。

权衡性

架构师设计系统时,应具备权衡思维。

  • 多维度权衡:在架构设计过程中,需要在性能、可扩展性、可靠性、安全性、成本等多个因素之间进行权衡。例如,为了提高系统的性能,可以增加硬件资源或采用更复杂的缓存机制,但这可能会增加成本和系统的复杂性;为了提高系统的可靠性,可以采用冗余架构,但这可能会降低系统的性能和增加维护成本。架构师需要根据具体的业务需求和场景,综合考虑各种因素,做出最优的决策。
  • 短期与长期权衡:既要考虑系统的短期实现成本和上线时间,又要考虑系统的长期维护成本和可扩展性。有时候,为了满足短期的业务需求,可能会采用一些简单直接但不太理想的架构方案,但从长期来看,可能会给系统的维护和升级带来困难。架构师需要在短期和长期目标之间找到一个平衡点,确保系统在整个生命周期内都能满足业务的需求。

逆向性

架构师设计系统时,应具备逆向思维。

  • 问题倒推:在面对复杂的系统问题时,不是仅仅从正面去思考如何实现系统的功能,而是会从问题出发,反向推导可能存在的原因和解决方案。例如,当系统出现性能问题时,会从性能瓶颈点开始,反向分析是硬件资源不足、软件算法不合理、网络带宽限制还是系统架构设计不合理等原因导致的,然后针对性地提出解决方案。
  • 需求反推:在设计架构时,不仅仅是被动地接受业务需求,而是会从业务目标和用户需求出发,反向思考系统应该具备什么样的架构才能更好地满足这些需求。通过这种方式,可以发现一些隐藏在表面需求背后的真正需求,从而设计出更符合业务本质的架构。

协作性

架构师设计系统时,应具备协作思维。

  • 跨团队沟通:架构师需要与多个团队进行沟通和协作,包括开发团队、测试团队、运维团队、业务团队等。能够用清晰、易懂的语言向不同背景的人员解释架构设计的思路、原理和要点,确保各个团队都能理解自己在系统中的角色和任务,以及如何与其他团队进行协作。
  • 融合多方意见:在架构设计过程中,会充分听取各方的意见和建议,包括团队成员的技术经验、业务人员的实际需求、运维人员的操作经验等,将这些不同的观点和想法进行融合和整合,使架构设计更加完善和合理。

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》

dosgame-web-docker 是 Docker 一键部署的网页端游戏运行工具,无需本地装模拟器,打开浏览器就能畅玩几十款经典中文游戏。

看看这界面,谁的 DNA 动了?

本次使用飞牛 NAS 部署,其他品牌 NAS 操作方法基本一样。

打开“文件管理”,找到“docker”文件夹,在里面创建一个“dosgame-web-docker”文件夹。

打开“Docker”应用,切换到「Compose」面板,新建一个项目。

项目名称:dosgame-web-docker。

路径:选择刚刚创建的“dosgame-web-docker”文件夹。

来源:创建docker-compose.yml

代码:

services:
  dosgame-web-docker:  
    container_name: dosgame
    image: oldiy/dosgame-web-docker:latest
    ports:
      - 3456:262
    restart: always

我给 dosgame-web-docker 配置的端口是 3456,你可以换其他端口。但冒号旁边的 262 不能改。

等项目构建好之后,切换到「容器」面板,找到“dosgame”,点击它旁边的链接按钮就能在浏览器打开它了。

几十款游戏呢~

随便点开一个都能玩~


以上就是本文的全部内容啦,有疑问可以在评论区讨论~

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了

接上篇:https://www.v2ex.com/t/1192982

这两天主要在做一件事:优化体验和合约部署这条链路从头到尾打通。


Contract Deployment Flow
Deep Token Analysis

全流程是什么意思

不是"AI 帮你写 Solidity 代码,然后你自己去部署"——而是真的全程:

  1. 你描述需求,AI 跟你澄清细节
  2. 自动生成 Solidity 代码
  3. 调用 solc 编译
  4. 你本地签名确认(私钥不离本地)
  5. 自动部署上链
  6. 自动提交验证到 BSCScan

全程你只需要说清楚你要什么 + 最后签一次名。不需要装开发环境,不需要看文档,不需要手动去 BSCScan 填验证表单。


真实案例

我让它给我开发了一个代币合约,完整对话可以打开继续聊:


交互体验上也做了改动

右侧新增了独立的交互卡片区域,每一步操作都有对应的结构化卡片,前面的卡片会自动折叠,整个流程不会乱。


接下来要做

合约部署之后,下一步是自动生成配套的管理页面和交互页面,直接部署到 Cloudflare Pages ,用户不需要自己建站就能对这个合约进行管理和操作。

再往后是把编程 Agent 和区块链 Agent 真正结合——Docker 沙箱环境、链上数据直接拉取用于量化分析、GitHub 自动推送、跨链桥聚合等,慢慢来。


想体验的话

直接打开 https://app.bnbrain.dev,免费,不用注册。

可以用 opBNB 测试网跑合约部署,费用极低。需要测试资金的留一下地址,我可以给一点够跑几次的 BNB 。


小福利

本帖 20 号前评论的 V2EXer,项目后续能持续做下去的话,送永久 Pro 套餐,代码编写和审查会上 Claude Opus 4.6/codex 5.3 Xhigh 等强模型。


最后,项目在参加 BNB Chain 的黑客松,体验后觉得还不错的话欢迎去点个 Upvote ,感谢:

https://dorahacks.io/buidl/39521

最近在折腾 voice agent ,之前用 LiveKit 框架做过几个项目,这次想试试纯 API 调用从零搭建,看看到底能做到什么程度。

做出来发现效果还不错:纯文本对话延迟,如果使用 gemini 2.5 flash lite ~500ms,即使是 2.5 flash 或者 3 flash ,也可以控制在 700ms 。带联网搜索或图片分析也能控制在 1000~1500s 。服务全部部署在美国,因此考虑到跨洋的网络延迟,实际上的表现应该可以更好。顺便做了个动态岛 UI 包装了一下。

附个使用演示视频:




之所以做这个,也是对语音这个模态比较看好,故自己搓了一个不依赖框架的实现。如果大家有什么好想法,也欢迎讨论😋

P.S 话说是自己“手搓”,但实际上大部分时候也是 AI 完成,只不过是类似于“同学”一般,相互指引跟学习,那既然大部分的代码都是 AI 实现的(虽然这一过程相比于单纯用框架而言学习到了很多),但这种方式还能叫“手搓”吗?

人们喜欢长上下文,智能体记得你的项目、你的偏好、你说话的方式,连你那些反复冒出来的琐碎任务都帮你记着,所以用起来当然顺手。但顺手归顺手,顺手不等于靠谱,把这两件事搞混后面的麻烦就来了。

可靠性问题的起点恰恰是人们把长上下文当免费能力用的那一刻。你扩展了上下文就等于换了一个被测系统,测的不再是模型本身,而是模型加上一个持续膨胀的历史 Token 档案。这个档案天生就很杂乱:半成型的想法、开玩笑时随口说的话、情绪化的措辞、前后矛盾的约束、从未打算变成策略的临时指令,统统堆在一起。

模型只能在它能关注到的范围内做推理,而注意力即便在窗口很大的情况下依然是稀缺资源。输入杂乱、矛盾、臃肿,模型的最优表现就不稳定压力一来更没法预测。很多人喜欢把长上下文比作"更大的大脑",但实际上它更像一张越来越大的办公桌:纸越堆越多最后你连自己要找的那份文件都找不到。

个性化是一种交换,因为可重复性很重要。

团队倾向于把个性化当作一次无争议的升级:见效快问题肉眼可见地减少。但实际操作中个性化是拿可重复性换舒适感,每个用户都有独特的上下文历史,意味着每个用户跑的实际上是一套不同的系统。

可重复性是时间压力下调试故障的前提,也是证明修复真正生效(而不是"感觉好了")的唯一手段。客户说"昨天还好好的,今天就坏了",团队拿同样的 prompt 试在自己的账户上完全复现不了,缺的那个变量往往是客户积累了好几周的上下文,这些交互以团队根本无法重建的方式,并且静悄悄地改变了模型的行为。

可测试性就这样成了长上下文的隐性牺牲品。实验室里通过的干净评估 prompt 放到线上就可能挂掉,因为线上的系统早已不是实验室里那个了:模型被更早的对话预热过,被推向了另一种语气,身上背着只属于那个用户的隐性约束。

个性化制造了一整支雪花舰队。雪花在规模化运营中极难管理,你完全可以交付一个使用体验极其顺滑的产品,同时交付的也是一个脆弱无比的系统。单次对话的流畅会遮蔽跨对话的不稳定。等到第一次严重故障真正来了,团队才意识到,复现不了也测不干净,发修复补丁又怕打破别人的个性化行为。

共享账户混合了意图,智能体失去了连贯性。

共享订阅看起来只是个小的使用习惯问题,但它制造的技术麻烦远比人们以为的要大,只是大家在真出事之前懒得细想。多个人共用一个账户或一条长线程,智能体看到的是一股混杂了不同目标、风格和约束的信息流。这些东西本来就不该共存,模型被迫在多种意图之间做插值(interpolation)而插值不是推理。

最能暴露问题的场景往往也最荒诞,比如某天你问了个基础问题,智能体的回答口吻突然像在跟一个数学家或资深工程师对话,你一头雾水,它怎么忽然高估了你?这不是什么灵异事件,只是别人的上下文残留渗进了当前会话,模型在模式匹配它"以为"正在交谈的那个用户。

这就引出了一种运行时才暴露的"我是谁"故障模式:智能体的应答对象不是当前打字的人,而是一个多用户融合出来的虚构画像。用户的感受是语气漂移、目标混乱、对专业水平的离谱假设、偏好前后矛盾:看起来像智能体的"人格"在闪烁。安全层面上共享上下文还带来额外风险:任何被摄入的恶意引导文本都能在更长的窗口中存活更久,而持久性恰好是日后引入工具调用时,把一段无害文本转化为延时炸弹的关键因素。

向量平均化会失败,因为人类目标是有方向性的。

人们习惯性地假设智能体可以把一组偏好平均成某种连贯稳定的东西。在风格层面模型确实擅长混合出听起来合理的折中方案。但一旦从风格混合切换到目标对齐,这个假设就不成立了。人类目标不只是偏好,它们是带着硬约束的方向性承诺。目标之间经常彼此对立有时候在设计上就是互斥的:一个人要激进增长,另一个人要风险最小化加法律合规。

智能体面对不兼容的目标时,很典型的行为是输出一份语言极其自信的模糊计划。自信的措辞容易让人误以为连贯性存在,输出听上去四平八稳实际上违反了真正关键的约束条件。因为模型并不是在跟你显式地协商取舍,它只是在互相矛盾的指令模式间静默插值。人类可以把冲突摆上台面然后做决策,模型则倾向于用一个谁也没要求的"看似合理的折中"来填补空缺。

那些被称为"涌现性怪异行为"的东西就是在这里出现的,它不神秘只是系统运作方式的可预见后果。智能体可能会锁定某个用户反复提到的主题,然后把它套用到共享上下文里的所有人身上,因为重复 Token 被当成了稳定意图的信号。它也可能去优化一些代理目标,比如"最大化礼貌度"、"最小化冲突"或者"给出中位数推荐",因为它没有能力调和线程深处那些真正的目标函数。

性能问题是真实存在的,上下文饱和使情况更糟。

一个很多开发者吃过亏才学到的问题:把当前代际的模型往上下文窗口深处推,往往让它在你真正关心的任务上变差。退化的表现形式包括推理变弱、遗漏增多、对干扰信号的抵抗力下降,以及用户口中那种模型"累了"的整体迟钝感。窗口技术上能撑那么长,不代表质量在窗口内是均匀分布的。

注意力是有限资源。上下文膨胀,模型就得把注意力摊到更大的 Token 预算上。塞进去一整部之前聊天的"小说",它可能恰好漏掉今天最关键的那段话——但它照样会自信满满地给你一个答案,因为生成回答本身就是训练目标。由此产生的失败模式非常隐蔽:智能体不会轰轰烈烈地报错,它只是悄悄地出错。而悄无声息的错,才是真正搞垮生产系统的。

长上下文在检索工作流中也能放大幻觉——哪怕检索到的文档本身是对的。RAG 管道可能拿到了正确的来源,但环绕的对话上下文把相关证据淹没了,模型最终从记忆中"声量最大"的模式而非 grounded text 里取材来拼答案。还有一种情况叫约束遗忘:一条合规规则在对话早期被明确声明过,却被后续大量闲聊掩埋,智能体的行为就好像那条规则不存在一样——它在那个时刻就是没能可靠地 attend 到它。

很多团队的直觉反应是往窗口里塞更多上下文,觉得记忆多了就能修复漂移。这条路通常走不通。塞得越多,噪声越大,信噪比越低,检索的选择性越差。到了某个临界点,更大的上下文反而意味着更差的记忆,因为模型已经无法可靠地定位到什么才是重要的。你的系统变得更难测试、更难调试、更难被信任。

将长上下文视为生产依赖项

要在生产环境中用长上下文,第一天就得建立明确的上下文预算。预算逼你做决定:什么是持久的,什么可以丢弃,什么该被摘要压缩,什么该以结构化记忆而非原始文本的形式留存。没有预算,上下文只会无限膨胀直到变成负债,唯一的退路是一次痛苦的重置——用户会抗拒,因为他们早已对"连续性"产生了情感依赖。

会话隔离是智能体系统的基本问题。私人闲聊不该渗进工作流,工作流不该渗进财务流程。用户非要开一个巨型线程的话,系统也必须在线程内部强制角色边界,因为角色边界是意图清晰性的保障。读取权限和执行权限也必须分离——读取本身就有风险,执行则把风险兑现成了实际损害。最小权限原则在这里不再是理论说教,而是工程必需。

记忆层要像对待数据库 schema 一样去管理。记忆本质上是一个塑造未来行为的状态存储,必须定义哪些字段存在、谁有写入权限、什么内容该被提升到长期存储——因为长期记忆里的一切都会成为系统策略面的一部分。上下文长度应当作为窗口容量的百分比来监控,设好阈值触发自动摘要或裁剪,摘要策略或记忆管理逻辑每次变更都要跑回归测试。

重置机制同样不可或缺。给用户设计一条能接受的重置路径,提供可审计的精选摘要,让用户理解清空上下文不是在抹掉历史,而是在保留真正经过验证的稳定信息。从工程角度看,清空是一种主动的状态管理手段,和数据库的定期归档、日志的轮转没有本质区别。长上下文本质上是一个输入面——它会老化、会漂移、会积累噪声。不做治理,它就会从资产退化为负债。

https://avoid.overfit.cn/post/ba57f2e1d9c54f83a4d6184c69e08cde

by Travis Good