想当站长吗?
免费体验一把当站长的快乐,但是有限制,就是 discourse 框架,free 计划的存储只有 5G,不太够用,而且数据还不在自己手上,所以,玩玩就好;
来我的站玩玩
免费建站传送门: https://id.discourse.com/create-site
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
免费体验一把当站长的快乐,但是有限制,就是 discourse 框架,free 计划的存储只有 5G,不太够用,而且数据还不在自己手上,所以,玩玩就好;
免费建站传送门: https://id.discourse.com/create-site
先贴几个小丑




评论区看到喜欢的可以点 ❤️,呼声高的更有机会入选?
需求:在 Azure 上部署 Prometheus
但是不知道是该用 Container Apps 还是 Container Instance 亦或者是 Azure Managed Prometheus。
有没有用过的小伙伴,想参考一下意见。

总价格: 球拍和球总共 $1.10。
差价: 球拍比球贵 $1.00。
问题: 球多少钱?




各位 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 )






项目还在早期阶段,内容侧还没来得及填充,功能也在持续迭代中。先把架子搭起来,后面慢慢打磨。
至于里面的内容,我自己也是有内容生产能力的。生产中学和本科,以及一些编程语言,或者是 AI 方面的应用课程,也有点余力。
以后目的是先在国内试水,之后出海。
可以在线使用 Flutter Web ,之后各平台打包后再补充。
产品落地页
我的个人主页
欢迎各位 V 友提提建议、聊聊想法,不管是功能方向还是设计细节都很想听听反馈 🙏
第一次用 vscode 玩,之前都是网页对话框里改代码,
结果一直等啊等搞好久,结果提示

真的挺无语的。
根据固件启动时的提醒,进入固件管理界面。 点击“下一步”,选择安装途径(选择默认的live安装即可) 若是中途需要改变已创建的分区,具体方式如下所示: 分区完成后,点击“开始安装”,开始安装系统。等待安装完成后,重启系统即可! 本文由mdnice多平台发布麒麟桌面系统V11版本的安装和V10-SP1的过程基本一样,下面看看详细的步骤吧,有什么不懂的,可以评论区提问。
一、启动引导
二、系统安装




点击“下一步”,进入选择安装方式界面,这里分两种方式安装(下面分别介绍两种方式安装的方法)全盘安装(快速安装)





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


继“摸鱼助手”之后,豫唐工具集 再次推出重磅力作 —— 数独挑战 (Sudoku Challenge)。这不仅是一个游戏,更是一次对经典逻辑谜题的现代化重构。 本文将从技术角度,剖析我们是如何在纯前端环境下,实现一个轻量级、高性能且具备无限关卡生成能力的数独引擎。 告别千篇一律的死板题库。每一局游戏,都是后台算法在毫秒间的即兴创作。 传统的数独生成往往依赖预置题库,而我们选择了动态生成。核心算法采用了 "对角线先行 + 全局求解 + 随机挖洞" 的三步走策略: 好的工具应该适应用户,而不是让用户适应工具。我们在交互设计上做了细致的打磨: 智能高亮: 我们深知,数独的最高境界往往发生在笔尖与纸面的摩擦之间。为此,我们利用 CSS3 的 秉承 豫唐工具集 一贯的理念: 数独挑战 (Sudoku Challenge) 现已上线。"There is no royal road to logic, and that acts as its formidable guardian."
逻辑没有平坦的大道,而这正是它令人着迷之处。
1. 核心算法:混沌与秩序的平衡
1.1 生成策略:回溯法 (Backtracking)
首先填充三个对角线上的 3x3 宫格。由于这三个宫格相互独立(行、列、宫均不重叠),我们可以随机填充 1-9 而无需担心冲突。这一步极大地减少了后续回溯的搜索空间。
利用递归回溯算法,填充剩余的空格。如果遇到死胡同,则回退一步,直到填满整个网格,生成一个完整的、有效的数独终局。
这是生成谜题的关键。我们随机移除棋盘上的数字(挖洞),每移除一个数字,都必须确保剩下的残局 仍然拥有唯一解。如果移除导致多解或无解,则回溯填回。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. 交互体验:键盘与鼠标的双重奏
// 智能高亮逻辑片段
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. 打印友好:极致的“纸质感”
@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. 纯粹与安全
在线体验
在线演示:https://www.ytecn.com/dev/tool/sudoku.html
开源地址:https://gitee.com/ytecnsong/web-dev-toolkit
这不只是代码的堆砌,这是逻辑之美。
在前一篇 《Flink 双流 JOIN 实战详解》 中,我们用「订单流 + 支付流」搞懂了事实双流之间的时间关联。 但在真实的实时数仓项目里,光有事实流还不够,业务同学更关心的是: 这些信息通常存放在 维度表(维表)中,例如 MySQL 的 这就是 维表时态 Join(Temporal Table Join) 要解决的问题。 本文我们就以「订单事实流 + 用户维表」为例,完成一个从 Kafka 到 MySQL 的简易实时数仓 Demo,并重点理解 Flink SQL 中维表时态 Join 的语法和注意事项。 设想一个简化的电商业务场景: 我们想要在 Flink 中构建一张「订单明细宽表」,字段大致包括: 并且要求: 这正是 时态 Join 和「实时数仓」的关键:按事件发生时刻回放维度视图。 本篇默认你已经完成前几篇中的环境准备: 在此基础上,我们还需要: 和 Kafka 一样,JDBC 连接器也需要以 JAR 包形式放到 Flink 的 以 Flink 1.20.x 对应的 确认 Flink 安装目录(假设为 下载 JDBC Connector JAR 到 Flink 的 如果你使用的是独立集群或远程集群,需要重启 Flink 集群,让新 JAR 在 JobManager/TaskManager 上生效: 重启 Flink SQL Client,使用新 Connector: 如果你在 Windows + WSL2 上部署,只需在 WSL2 内执行上述命令即可;或者手动下载 JAR 后拷贝到 首先在 MySQL 中准备一张简单的用户维度表,用来存用户的基础属性。 在 MySQL 中执行: 为了演示「时态」效果,你可以在后续实验中手动更新某个用户的等级或城市,例如: 这样我们在 Flink 里做时态 Join 时,就能观察“变更前后”的区别。 接下来回到 Flink SQL Client,把 Kafka 中的订单事实流和 MySQL 中的维表都注册成 Flink 表。 和上一篇双流 JOIN 类似,我们假设 Kafka 中有一个 在 Flink SQL Client 中执行: 你可以沿用上一篇中 Kafka 造数的方式,用 然后把刚才在 MySQL 中建好的 注意几点: 在生产环境中,你可以把 MySQL 作为维度存储,或者通过 CDC 把维表变更同步到 Kafka,构造成 changelog 流,这些都可以和 Temporal Join 结合使用。 有了订单事实表 Flink SQL 中的 Temporal Table Join 对于 JDBC 这类 外部维表,通常采用「处理时间(Processing Time)」语义来做 Lookup Join,典型写法如下: 在 SQL Client 中执行这段查询,会看到实时流式刷新的结果,每一行订单都带上了对应的用户属性。 为了验证这是“时态 Join”而不是“始终查最新维度”,可以按下面步骤操作: 回到 MySQL,执行: 在命令行中输入一条 JSON 数据(按回车发送一条): 这就说明 Flink 的时态 Join 确实是“按订单发生时刻去回放维度视图”的,而不是简单查当前最新值。 在真实项目中,我们不会只在 SQL Client 里 例如,可以把结果写回 Kafka,作为 DWD 层的订单宽表: 这样,下游的实时应用或 BI 查询就可以直接订阅 你也可以把结果同步到 MySQL、ClickHouse 等分析型数据库中,构建实时明细表,为报表和可视化提供数据。 通过这篇文章,我们完成了这样一件事: 这背后有几个非常重要的实时数仓设计理念: 在后续的文章中,我们可以继续沿着这个方向深入: 如果你已经跑通了本文的 Demo,不妨试着自己设计一张商品维表 dim_user、dim_product 等。我们希望在实时计算时,能把「事实流」和「维表」在时间维度上正确地关联起来,构建一张带有完整业务属性的明细宽表。一、业务场景与数仓目标
orders 订单事实流dim_user 用户维表,包含用户等级、所属城市、注册渠道等信息二、环境前提与依赖准备
1. 基础组件
2. 安装 Flink JDBC Connector
lib 目录中。flink-connector-jdbc 为例:/opt/flink):export FLINK_HOME=/opt/flinklib 目录: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.jarcd $FLINK_HOME
bin/stop-cluster.sh
bin/start-cluster.shcd $FLINK_HOME
bin/sql-client.shlib 目录,步骤完全一致。三、准备 MySQL 用户维度表 dim_user
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 中注册事实流与维表
1. Kafka 订单事实表 orders
orders Topic,写入订单事实数据。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-console-producer.sh 发送 JSON 订单数据,只需要保证字段名一致。2. MySQL 用户维表 dim_user(JDBC Lookup 表)
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 的前提五、维表时态 Join:把订单打上用户维度
orders 和维度表 dim_user,就可以通过时态 Join 来构建订单明细宽表。1. 基础时态 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;
这里有几个关键点:proc_time AS PROCTIME() 是在 orders 上定义的处理时间字段FOR SYSTEM_TIME AS OF o.proc_time 表示“以 Flink 处理这条订单记录的当前时间,去查维表的一个快照”,这是 JDBC Lookup 支持的典型用法user_id 等值关联LEFT JOIN 可以保留找不到维度的订单,并用空值来表示“维度缺失”2. 验证时态效果:修改维表再观察 Join
orders Topic 写入几条订单数据,例如用户 u_2 下单的记录u_2 的等级是 VIP2UPDATE dim_user
SET user_level = 'VIP3'
WHERE user_id = 'u_2';u_2bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic orders{"order_id":"o_3","user_id":"u_2","order_amount":200.00,"order_time":"2026-02-19T14:42:00Z"}
这时你会看到:VIP2VIP3六、把结果写回 Kafka 或 MySQL,形成实时数仓明细层
SELECT 一下就结束,而是要把 Join 后的订单明细宽表,写回到下游存储,形成实时数仓的一个层级。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;dwd_order_user_wide 这个 Topic,拿到已经打好用户标签的订单明细数据。七、小结与下一步建议
ordersdim_userFOR SYSTEM_TIME AS OF 语法做维表时态 Joindim_product,再给订单打上商品品类维度,体验一下“事实 + 多维表时态 Join”在 Flink SQL 里的完整味道。
看着还不错


不知道用 mac 的各位 2 友们有没有深入使用过系统自带的 Pages 应用
在很久之前我就很讨厌阅读和编写 word 文档, 收到 word 文档后我都会转成 pdf 后再读. 但总会有编写设计文档之类的工作, 就很痛苦.
前段时间尝试了一下这个一直躺在我应用列表但从未打开过的 Pages 应用, 发现意外的好用. 这里分享几个技巧:
⌘+a, 把字体替换为SF Pro, 是的, 微软的那套字体我是真喜欢不起来, 换字体后行间距也大概率变得更有可读性了.
纯分享, 各位请畅所欲言~
Claude 家族的最新力作,这次升级让它在编码、设计、长文本推理等领域全面爆发,智能水平直逼顶级模型,但价格更接地气,适合日常任务。
热度:🔺543

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

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

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

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

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

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

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

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

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

持有 10K token 的用户数第一次来到 1000 。
截图中对比的是 0218 和 0114 的一些数据( 0114 算是今年的一个 local high )。
很高兴无论市场状况如何,愿意尝试 Solana 的 V2EX 用户一直在增长。

如何成为鸿蒙架构师? 架构师设计系统时,应具备系统性思维。 架构师设计系统时,应具备抽象思维。 架构师设计系统时,应具备前瞻性思维。 架构师设计系统时,应具备权衡思维。 架构师设计系统时,应具备逆向思维。 架构师设计系统时,应具备协作思维。
架构师的设计思维具有多方面的特点,以下是一些主要的方面。系统性

抽象性

前瞻性

权衡性

逆向性

协作性

点赞 + 关注 + 收藏 = 学会了 dosgame-web-docker 是 Docker 一键部署的网页端游戏运行工具,无需本地装模拟器,打开浏览器就能畅玩几十款经典中文游戏。 看看这界面,谁的 DNA 动了? 本次使用飞牛 NAS 部署,其他品牌 NAS 操作方法基本一样。 打开“文件管理”,找到“docker”文件夹,在里面创建一个“dosgame-web-docker”文件夹。 打开“Docker”应用,切换到「Compose」面板,新建一个项目。 项目名称:dosgame-web-docker。 路径:选择刚刚创建的“dosgame-web-docker”文件夹。 来源:创建docker-compose.yml 代码: 我给 dosgame-web-docker 配置的端口是 等项目构建好之后,切换到「容器」面板,找到“dosgame”,点击它旁边的链接按钮就能在浏览器打开它了。 几十款游戏呢~ 随便点开一个都能玩~ 以上就是本文的全部内容啦,有疑问可以在评论区讨论~ 想了解更多NAS玩法可以关注《NAS邪修》👏 点赞 + 关注 + 收藏 = 学会了整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》



services:
dosgame-web-docker:
container_name: dosgame
image: oldiy/dosgame-web-docker:latest
ports:
- 3456:262
restart: always3456,你可以换其他端口。但冒号旁边的 262 不能改。


接上篇:https://www.v2ex.com/t/1192982
这两天主要在做一件事:优化体验和合约部署这条链路从头到尾打通。


不是"AI 帮你写 Solidity 代码,然后你自己去部署"——而是真的全程:
全程你只需要说清楚你要什么 + 最后签一次名。不需要装开发环境,不需要看文档,不需要手动去 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 ,感谢:

椰子在哈气
ai 写的挺长的 所以得进来看了

之所以做这个,也是对语音这个模态比较看好,故自己搓了一个不依赖框架的实现。如果大家有什么好想法,也欢迎讨论😋
P.S 话说是自己“手搓”,但实际上大部分时候也是 AI 完成,只不过是类似于“同学”一般,相互指引跟学习,那既然大部分的代码都是 AI 实现的(虽然这一过程相比于单纯用框架而言学习到了很多),但这种方式还能叫“手搓”吗?


人们喜欢长上下文,智能体记得你的项目、你的偏好、你说话的方式,连你那些反复冒出来的琐碎任务都帮你记着,所以用起来当然顺手。但顺手归顺手,顺手不等于靠谱,把这两件事搞混后面的麻烦就来了。 可靠性问题的起点恰恰是人们把长上下文当免费能力用的那一刻。你扩展了上下文就等于换了一个被测系统,测的不再是模型本身,而是模型加上一个持续膨胀的历史 Token 档案。这个档案天生就很杂乱:半成型的想法、开玩笑时随口说的话、情绪化的措辞、前后矛盾的约束、从未打算变成策略的临时指令,统统堆在一起。 模型只能在它能关注到的范围内做推理,而注意力即便在窗口很大的情况下依然是稀缺资源。输入杂乱、矛盾、臃肿,模型的最优表现就不稳定压力一来更没法预测。很多人喜欢把长上下文比作"更大的大脑",但实际上它更像一张越来越大的办公桌:纸越堆越多最后你连自己要找的那份文件都找不到。 团队倾向于把个性化当作一次无争议的升级:见效快问题肉眼可见地减少。但实际操作中个性化是拿可重复性换舒适感,每个用户都有独特的上下文历史,意味着每个用户跑的实际上是一套不同的系统。 可重复性是时间压力下调试故障的前提,也是证明修复真正生效(而不是"感觉好了")的唯一手段。客户说"昨天还好好的,今天就坏了",团队拿同样的 prompt 试在自己的账户上完全复现不了,缺的那个变量往往是客户积累了好几周的上下文,这些交互以团队根本无法重建的方式,并且静悄悄地改变了模型的行为。 可测试性就这样成了长上下文的隐性牺牲品。实验室里通过的干净评估 prompt 放到线上就可能挂掉,因为线上的系统早已不是实验室里那个了:模型被更早的对话预热过,被推向了另一种语气,身上背着只属于那个用户的隐性约束。 个性化制造了一整支雪花舰队。雪花在规模化运营中极难管理,你完全可以交付一个使用体验极其顺滑的产品,同时交付的也是一个脆弱无比的系统。单次对话的流畅会遮蔽跨对话的不稳定。等到第一次严重故障真正来了,团队才意识到,复现不了也测不干净,发修复补丁又怕打破别人的个性化行为。 共享订阅看起来只是个小的使用习惯问题,但它制造的技术麻烦远比人们以为的要大,只是大家在真出事之前懒得细想。多个人共用一个账户或一条长线程,智能体看到的是一股混杂了不同目标、风格和约束的信息流。这些东西本来就不该共存,模型被迫在多种意图之间做插值(interpolation)而插值不是推理。 最能暴露问题的场景往往也最荒诞,比如某天你问了个基础问题,智能体的回答口吻突然像在跟一个数学家或资深工程师对话,你一头雾水,它怎么忽然高估了你?这不是什么灵异事件,只是别人的上下文残留渗进了当前会话,模型在模式匹配它"以为"正在交谈的那个用户。 这就引出了一种运行时才暴露的"我是谁"故障模式:智能体的应答对象不是当前打字的人,而是一个多用户融合出来的虚构画像。用户的感受是语气漂移、目标混乱、对专业水平的离谱假设、偏好前后矛盾:看起来像智能体的"人格"在闪烁。安全层面上共享上下文还带来额外风险:任何被摄入的恶意引导文本都能在更长的窗口中存活更久,而持久性恰好是日后引入工具调用时,把一段无害文本转化为延时炸弹的关键因素。 人们习惯性地假设智能体可以把一组偏好平均成某种连贯稳定的东西。在风格层面模型确实擅长混合出听起来合理的折中方案。但一旦从风格混合切换到目标对齐,这个假设就不成立了。人类目标不只是偏好,它们是带着硬约束的方向性承诺。目标之间经常彼此对立有时候在设计上就是互斥的:一个人要激进增长,另一个人要风险最小化加法律合规。 智能体面对不兼容的目标时,很典型的行为是输出一份语言极其自信的模糊计划。自信的措辞容易让人误以为连贯性存在,输出听上去四平八稳实际上违反了真正关键的约束条件。因为模型并不是在跟你显式地协商取舍,它只是在互相矛盾的指令模式间静默插值。人类可以把冲突摆上台面然后做决策,模型则倾向于用一个谁也没要求的"看似合理的折中"来填补空缺。 那些被称为"涌现性怪异行为"的东西就是在这里出现的,它不神秘只是系统运作方式的可预见后果。智能体可能会锁定某个用户反复提到的主题,然后把它套用到共享上下文里的所有人身上,因为重复 Token 被当成了稳定意图的信号。它也可能去优化一些代理目标,比如"最大化礼貌度"、"最小化冲突"或者"给出中位数推荐",因为它没有能力调和线程深处那些真正的目标函数。 一个很多开发者吃过亏才学到的问题:把当前代际的模型往上下文窗口深处推,往往让它在你真正关心的任务上变差。退化的表现形式包括推理变弱、遗漏增多、对干扰信号的抵抗力下降,以及用户口中那种模型"累了"的整体迟钝感。窗口技术上能撑那么长,不代表质量在窗口内是均匀分布的。 注意力是有限资源。上下文膨胀,模型就得把注意力摊到更大的 Token 预算上。塞进去一整部之前聊天的"小说",它可能恰好漏掉今天最关键的那段话——但它照样会自信满满地给你一个答案,因为生成回答本身就是训练目标。由此产生的失败模式非常隐蔽:智能体不会轰轰烈烈地报错,它只是悄悄地出错。而悄无声息的错,才是真正搞垮生产系统的。 长上下文在检索工作流中也能放大幻觉——哪怕检索到的文档本身是对的。RAG 管道可能拿到了正确的来源,但环绕的对话上下文把相关证据淹没了,模型最终从记忆中"声量最大"的模式而非 grounded text 里取材来拼答案。还有一种情况叫约束遗忘:一条合规规则在对话早期被明确声明过,却被后续大量闲聊掩埋,智能体的行为就好像那条规则不存在一样——它在那个时刻就是没能可靠地 attend 到它。 很多团队的直觉反应是往窗口里塞更多上下文,觉得记忆多了就能修复漂移。这条路通常走不通。塞得越多,噪声越大,信噪比越低,检索的选择性越差。到了某个临界点,更大的上下文反而意味着更差的记忆,因为模型已经无法可靠地定位到什么才是重要的。你的系统变得更难测试、更难调试、更难被信任。 要在生产环境中用长上下文,第一天就得建立明确的上下文预算。预算逼你做决定:什么是持久的,什么可以丢弃,什么该被摘要压缩,什么该以结构化记忆而非原始文本的形式留存。没有预算,上下文只会无限膨胀直到变成负债,唯一的退路是一次痛苦的重置——用户会抗拒,因为他们早已对"连续性"产生了情感依赖。 会话隔离是智能体系统的基本问题。私人闲聊不该渗进工作流,工作流不该渗进财务流程。用户非要开一个巨型线程的话,系统也必须在线程内部强制角色边界,因为角色边界是意图清晰性的保障。读取权限和执行权限也必须分离——读取本身就有风险,执行则把风险兑现成了实际损害。最小权限原则在这里不再是理论说教,而是工程必需。 记忆层要像对待数据库 schema 一样去管理。记忆本质上是一个塑造未来行为的状态存储,必须定义哪些字段存在、谁有写入权限、什么内容该被提升到长期存储——因为长期记忆里的一切都会成为系统策略面的一部分。上下文长度应当作为窗口容量的百分比来监控,设好阈值触发自动摘要或裁剪,摘要策略或记忆管理逻辑每次变更都要跑回归测试。 重置机制同样不可或缺。给用户设计一条能接受的重置路径,提供可审计的精选摘要,让用户理解清空上下文不是在抹掉历史,而是在保留真正经过验证的稳定信息。从工程角度看,清空是一种主动的状态管理手段,和数据库的定期归档、日志的轮转没有本质区别。长上下文本质上是一个输入面——它会老化、会漂移、会积累噪声。不做治理,它就会从资产退化为负债。 https://avoid.overfit.cn/post/ba57f2e1d9c54f83a4d6184c69e08cde by Travis Good
个性化是一种交换,因为可重复性很重要。

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

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

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

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