求个汇率接口
美元转人民币,一个月可能不到 500 次使用量,要求稳定,免费的。
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
美元转人民币,一个月可能不到 500 次使用量,要求稳定,免费的。
上个月苹果发了新款 M5 芯片的 MacBook Air 。
看着我那 17 款的 MacBook Pro ,咬咬牙终于下手了。
刚拿到手的时候,我第一反应是:怎么这么轻?我买的是金色的,感觉像拿了个“会发光的本子”。一番“你好”设置后,开机速度也挺离谱,刚坐下准备认真等一下,它已经好了,有点不讲武德。
我最直观的感受是——顺。平时用来刷网页、写点东西、开十几个标签页,它都一脸淡定,风扇声?不存在的,Air 根本没风扇,安静得像在装高冷。电池也挺耐用,一天下来不用找插头,终于不用到处蹭电源。
屏幕看着很舒服,颜色挺讨喜,看视频的时候甚至有点沉浸,差点忘了自己是来干活的。键盘手感也不错。美中不足的是听惯了之前机械键盘的声音,苹果本的键盘总是觉得很闷。
苹果键盘是静音设计,打字时总觉得缺了点什么,体验不好。毕竟人打字的时候,多少还是需要一点反馈的,不然总觉得自己在“空气里工作”。
我突发奇想,为啥不做一个模拟机械键盘声音的 App 。
于是花了一天 VibeCoding ,做了一个原型。支持 18 种键盘音效,包括各种机械键盘、iPhone 和打字机效果。
YouTube 演示视频: https://youtu.be/eCGjlacy208
试了一下,打字确实带感了!
几天已经离不开了,现在不打开都不适应。在咖啡店里带上耳机沉浸感非常强。
今天早上我提交了 App Store ,应该过几天就能下载了。
说到底,这个小东西的意义就是:让安静的打字,多一点仪式感,让“我的每一次点击都是在享受”。

有的时候我们要对当前应用进行截图,这个时候如果使用Snipaste截图软件截图时,会发现Snipaste的截图快捷键F1和当前应用的快捷键冲突了。当你按下F1时会自动打开当前应用的某一个功能。比如我要对VSCODE这个应用进行截图,如果在VSCODE里面按下F1这个快捷键,VSCODE会自动打开如下功能: 或者我要对VSCODE的二级菜单进行截图,当你打开VSCODE的二级菜单之后,此时你按任何截图软件的快捷之前,VSCODE的二级菜单都会因为失去焦点自动消失。 解决办法就是以管理员权限打开Snipaste这个截图软件,然后在VSCODE里面按下Snipaste的F1快捷键就可以了。右键Snipaste软件的图标,以管理员身份运行。此时Snipaste的F1快捷键和VSCODE的F1快捷键就不会冲突了。 Windows系统本身自带了好几个截图快捷键,比如键盘上面的快捷键冲突
解决办法
Windows系统自带的快捷
PrtSc按键或者PrntScrn按键。或者Win + Shift + S快捷键。C:\Users\用户名\Pictures\Screenshots这个位置。同时自动保存在剪贴板,需要你按ctrl + v 复制到你指定的地方。
比如同时有一个 Claude Opus 4.6 和五个 gpt 5 mini 在干活,会不会导致被封号?如果使用非官方客户端呢?
StockTV API为开发者提供全面的美股市场数据接口,涵盖实时行情、历史数据、指数信息、公司详情等功能。本指南详细说明如何使用API接口获取美股相关数据,所有接口均返回标准JSON格式。 获取美股市场股票列表,支持分页和交易所筛选。 接口地址: 请求参数: 示例请求: 响应结构: 关键字段说明: 根据多种条件查询单个股票详细信息。 接口地址: 请求参数: 示例请求: 响应包含技术指标: 一次请求获取多个股票的实时数据。 接口地址: 请求参数: 使用场景: 获取美国主要股票指数信息。 接口地址: 请求参数: 美国主要指数: 响应示例: 获取股票的历史价格数据,支持多种时间周期。 接口地址: 时间周期参数: 示例请求: K线数据结构: 获取美股市场的实时涨跌排名。 接口地址: 排行榜类型: 获取上市公司的详细资料。 接口地址: 响应字段: 通过WebSocket获取股票的实时行情更新。 连接地址: JavaScript示例: WebSocket数据格式: 本指南提供了StockTV美股API的完整对接方案,涵盖从基础查询到高级应用的各个场景。开发者可根据实际需求选择合适的接口和技术方案,构建稳定、高效的股票数据应用。一、概述
二、接入准备
1. API认证
key=your_api_key_here2. 基础配置
https://api.stocktv.top三、美股市场接口
1. 股票列表查询
GET /stock/stocks{
"countryId": 5, // 必填,美国国家ID为5
"pageSize": 20, // 选填,每页记录数,默认10
"page": 1, // 选填,页码,默认1
"exchangeId": 1, // 选填,交易所ID(1:NYSE, 2:NASDAQ)
"key": "your_key" // 必填,API密钥
}curl -X GET "https://api.stocktv.top/stock/stocks?countryId=5&pageSize=20&page=1&key=your_api_key"{
"code": 200,
"message": "操作成功",
"data": {
"records": [
{
"id": 7310,
"symbol": "AAPL",
"name": "Apple Inc",
"last": 195.42,
"chg": 2.15,
"chgPct": 1.11,
"high": 196.88,
"low": 192.75,
"volume": 45678900,
"avgVolume": 51234500,
"exchangeId": 2,
"countryId": 5,
"countryNameTranslated": "United States",
"flag": "US",
"open": true,
"lastClose": 193.27,
"pairType": "Equities",
"time": 1755008213,
"url": "/equities/apple-inc"
}
],
"total": 5832,
"size": 20,
"current": 1,
"pages": 292
}
}id: 股票唯一标识(PID),用于其他接口查询symbol: 股票交易代码exchangeId: 交易所标识(1:NYSE, 2:NASDAQ)open: 交易状态(true:开市, false:休市)2. 个股详情查询
GET /stock/queryStocks// 支持以下任一查询条件
id: 7310, // 股票PID
symbol: "AAPL", // 股票代码
name: "Apple Inc", // 公司名称
url: "/equities/apple-inc" // 详情页URL# 通过PID查询
curl -X GET "https://api.stocktv.top/stock/queryStocks?id=7310&key=your_key"
# 通过股票代码查询
curl -X GET "https://api.stocktv.top/stock/queryStocks?symbol=AAPL&key=your_key"{
"technicalDay": "strong_buy", // 日线技术信号
"technicalHour": "buy", // 小时线技术信号
"technicalMonth": "neutral", // 月线技术信号
"technicalWeek": "buy", // 周线技术信号
"fundamentalBeta": 1.23, // Beta系数
"fundamentalMarketCap": 3050000000000, // 市值
"fundamentalRevenue": "383.29B" // 营收
}3. 批量股票查询
GET /stock/stocksByPidspids: "7310,17976,24582" // 必填,PID列表,逗号分隔4. 美股指数数据
GET /stock/indicescountryId: 5, // 美国国家ID
flag: "US", // 选填,国家代码{
"id": 12345,
"name": "S&P 500",
"symbol": "SPX",
"last": 5450.25,
"chg": 35.50,
"chgPct": 0.66,
"isOpen": true,
"time": 1755008213
}5. 历史K线数据
GET /stock/klineinterval 说明 适用场景 PT5M 5分钟线 日内交易 PT15M 15分钟线 短线分析 PT1H 1小时线 趋势分析 P1D 日线 技术分析 P1W 周线 长期趋势 P1M 月线 投资决策 # 获取苹果公司日K线
curl -X GET "https://api.stocktv.top/stock/kline?pid=7310&interval=P1D&key=your_key"{
"time": 1754928000000, // 时间戳(毫秒)
"open": 192.50, // 开盘价
"high": 196.25, // 最高价
"low": 191.80, // 最低价
"close": 195.42, // 收盘价
"volume": 51234500, // 成交量
"vo": 1001203456.50 // 成交额
}6. 涨跌排行榜
GET /stock/updownListtype 说明 数据量 1 涨幅榜 前50名 2 跌幅榜 前50名 3 涨停榜 实时数据 4 跌停榜 实时数据 7. 公司基本信息
GET /stock/companies{
"companyName": "Apple Inc Company Profile",
"description": "Apple Inc. designs, manufactures, and markets smartphones, personal computers, tablets, wearables, and accessories worldwide...",
"industry": "Consumer Electronics",
"sector": "Technology",
"employeeCount": 164000,
"market": "United States",
"countryId": 5
}8. 实时数据推送
wss://ws-api.stocktv.top/connect?key=your_api_keyconst ws = new WebSocket('wss://ws-api.stocktv.top/connect?key=your_key');
ws.onopen = () => {
console.log('WebSocket连接已建立');
};
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log('实时数据:', data);
// 数据处理示例
if (data.type === 1) { // 股票类型
updateStockPrice(data.pid, {
price: data.last_numeric,
change: data.pc,
changePercent: data.pcp,
volume: data.turnover_numeric
});
}
};
// 心跳保持连接
setInterval(() => {
if (ws.readyState === WebSocket.OPEN) {
ws.send(JSON.stringify({ type: 'ping' }));
}
}, 30000);{
"pid": "7310",
"last_numeric": "195.42",
"bid": "195.40",
"ask": "195.44",
"high": "196.88",
"low": "192.75",
"last_close": "193.27",
"pc": "+2.15",
"pcp": "+1.11%",
"turnover_numeric": "45678900",
"time": "16:00:00",
"timestamp": "1755008213",
"type": 1
}四、数据更新与延迟
1. 实时性说明
2. 交易时间
open字段标识当前交易状态五、错误处理
1. 通用响应格式
{
"code": 200, // 状态码
"message": "操作成功", // 状态信息
"data": {} // 业务数据
}2. 常见状态码
状态码 说明 处理建议 200 请求成功 正常处理数据 400 参数错误 检查请求参数 401 认证失败 验证API密钥 404 接口不存在 检查接口地址 429 请求频繁 降低调用频率 500 服务器错误 稍后重试 3. 异常处理示例
async function fetchStockData(pid) {
try {
const response = await fetch(
`https://api.stocktv.top/stock/kline?pid=${pid}&interval=P1D&key=${API_KEY}`
);
const result = await response.json();
if (result.code === 200) {
return result.data;
} else {
console.error(`API错误 ${result.code}: ${result.message}`);
return null;
}
} catch (error) {
console.error('网络请求失败:', error);
return null;
}
}六、最佳实践
1. 性能优化
// 批量查询替代循环单查
const pids = ['7310', '24582', '38291'].join(',');
const url = `https://api.stocktv.top/stock/stocksByPids?pids=${pids}&key=${API_KEY}`;
// 合理设置缓存
const CACHE_DURATION = 30000; // 30秒
let lastFetchTime = 0;
let cachedData = null;
async function getCachedData() {
const now = Date.now();
if (!cachedData || (now - lastFetchTime) > CACHE_DURATION) {
cachedData = await fetchData();
lastFetchTime = now;
}
return cachedData;
}2. 频率控制
3. 数据更新策略
// 实时数据使用WebSocket
const ws = new WebSocket(`wss://ws-api.stocktv.top/connect?key=${API_KEY}`);
// 非交易时间使用定时查询
if (marketIsOpen()) {
// 使用WebSocket实时推送
} else {
// 使用HTTP定时查询,间隔可适当延长
setInterval(fetchStockData, 60000); // 1分钟
}七、常见应用场景
1. 股票行情展示
<div class="stock-widget">
<div class="stock-header">
<span class="symbol">AAPL</span>
<span class="name">Apple Inc</span>
</div>
<div class="stock-price">
<span class="price">195.42</span>
<span class="change positive">+2.15 (+1.11%)</span>
</div>
<div class="stock-details">
<div>高: 196.88</div>
<div>低: 192.75</div>
<div>量: 45.68M</div>
</div>
</div>2. K线图表集成
// 使用ECharts绘制K线图
async function renderKLineChart(pid) {
const klineData = await fetchKLineData(pid, 'P1D', 100);
const chart = echarts.init(document.getElementById('chart'));
const option = {
xAxis: { data: klineData.map(item => formatTime(item.time)) },
yAxis: { scale: true },
series: [{
type: 'candlestick',
data: klineData.map(item => [
item.open,
item.close,
item.low,
item.high
])
}]
};
chart.setOption(option);
}3. 实时监控系统
class StockMonitor {
constructor(stockList) {
this.stocks = new Map();
this.ws = null;
this.initWebSocket();
}
initWebSocket() {
this.ws = new WebSocket(`wss://ws-api.stocktv.top/connect?key=${API_KEY}`);
this.ws.onmessage = (event) => {
const data = JSON.parse(event.data);
this.updateStock(data);
// 触发价格预警
this.checkAlerts(data);
};
}
updateStock(data) {
const stock = this.stocks.get(data.pid);
if (stock) {
Object.assign(stock, data);
this.emit('update', stock);
}
}
checkAlerts(data) {
// 实现价格预警逻辑
}
}八、注意事项
九、技术支持与资源
1. 官方资源
2. 问题排查
3. 社区支持
做鸿蒙 ArkUI 开发的兄弟,多半都经历过这样一种“血压飙升”的时刻:页面跳转过去再返回,数据没刷新;或者 Tab 来回切换,页面状态莫名其妙被重置了。 你明明在 如果你也正被这些问题折磨,那么今天这篇文章就是你的救命稻草。咱们不拽那些干巴巴的官方文档,直接掀开 Navigation 路由栈的引擎盖,把 NavDestination 独有的生命周期彻底盘明白! 一句话道破天机:NavDestination 本质上是被“托管”在路由栈里的组件,它的生命周期,由两个老大哥共同掌管——一个是系统的组件调度器,另一个是 Navigation 的路由栈。 普通的 这就导致它除了拥有普通组件的 为了直观感受这四个独门兵器的流转逻辑,我们看一张精简版的生命周期心法图: 看出门道了吗? 理论说得再天花乱坠,不如跑一段代码来得实在。 咱们来个直观的需求:有一个商品详情页( 方案一:灾难级“想当然”写法 (❌ 纯纯的埋坑王) 痛点直击:这种写法完全没考虑路由栈的行为。用户操作路径如果是 方案二:召唤“onShown”降维打击 (✅ 优雅的焦点感知) 收益对比表: 虽然 如果你正在着手将项目迁移到最新的 HarmonyOS 6 (纯血 NEXT),关于 Navigation 和页面生命周期,有几个极其重磅的底层变动,提前了解能帮你省下大把踩坑时间。 1. 预测性返回 (Predictive Back) 带来的生命周期震荡 2. 共享元素动画 (Shared Element Transition) 与时序抢占 3. 性能狂飙:组件复用与生命周期的“短路” 回顾全文,我们从“数据不刷新”的痛点出发,剖析了 你会发现,鸿蒙生态的架构师们在设计这套路由机制时,眼光极其毒辣。他们不仅给了你最基本的组件挂载控制,更在面临复杂用户交互时,用 在这个端侧智能大爆发的时代,应用不再是一堆死板的页面堆砌,而是需要与用户指尖的每一次滑动无缝呼应。掌握 终结“状态错乱”的玄学:玩透 NavDestination 独门生命周期
aboutToAppear 里写了数据请求,为什么有时候执行,有时候又不执行?一、 追根溯源:为什么 NavDestination 如此“另类”?
@Component 只需要关心自己有没有被挂载到组件树上。但 NavDestination 不一样,它还得听命于 NavPathStack(路由栈)。aboutToAppear(即将出现)和 aboutToDisappear(即将消失)之外,还自带了四把“独门兵器”:onAppear:组件刚刚被渲染到屏幕上时触发。(注意:这和上面的 aboutToAppear 有微妙的时序差异,后面会细说)。onDisappear:组件从屏幕上彻底消失时触发。onShown:重点中的重点! 页面完全呈现在屏幕最前台时触发(比如页面跳转动画结束,或者 Pop 回当前页时)。onHidden:另一个大头! 页面被其他页面覆盖挡住时触发(比如 Push 了新页面,或者切到后台)。onShown 和 onHidden 才是真正和“用户视觉焦点”绑定的生命周期。 只要页面还在栈里,哪怕被挡住了,它依然活着,只是处于 Hidden 状态。二、 实战演练:手撕“数据刷新”痛点,拿捏页面焦点
DetailPage),它可以被多次压入栈中查看不同的商品。每次页面完全展示时,我们需要去请求最新的库存数据。如果请求失败,需要给用户一个 Toast 提示。// 糟糕的写法:依赖 aboutToAppear,导致逻辑执行时机错乱
@Builder
export function DetailPageBuilder(param: Object) {
NavDestination() {
Column() {
Text(`商品ID: ${param.goodsId}`)
// ... 其他UI
}
}
.onAppear(() => {
// 致命误区:如果只是从下级页面返回,onAppear 可能不会触发!
// 导致库存数据永远是旧的
fetchGoodsStock(param.goodsId);
})
.aboutToAppear(() => {
// 这里发起请求?如果页面只是被遮挡(onHidden),再返回时它不会重新执行!
})
}首页 -> 详情页(A) -> 编辑页 -> 返回详情页(A),由于详情页(A) 只是经历了 onHidden -> onShown,你的数据请求根本不会重新发起!
利用 NavDestination 独有的 onShown,我们可以精准感知页面何时“真正回到前台”。// 优雅的写法:精准把控页面焦点
@Builder
export function DetailPageBuilder(param: Object) {
NavDestination() {
Column() {
Text(`商品ID: ${param.goodsId}`)
.fontSize(20)
Button("去编辑")
.onClick(() => {
// 模拟跳转到下级页面
router.pushNamedRoute({ name: "EditPage" });
})
}
.width('100%')
.height('100%')
.justifyContent(FlexAlign.Center)
}
.onShown(() => {
// 核心:无论是首次进入,还是从下级页面返回,只要页面完全展示给用户,就会触发!
console.log(`页面获焦,开始请求商品 ${param.goodsId} 的最新库存...`);
fetchGoodsStock(param.goodsId);
})
.onHidden(() => {
// 页面被遮挡时,可以做一些暂停操作,比如停止视频播放、保存草稿等
console.log("页面失去焦点,暂停定时器");
clearInterval(timer);
})
}维度 依赖 aboutToAppear / onAppear拥抱 onShown / onHidden提升效果 返回刷新 需额外处理路由回调,极易遗漏 天然支持,返回即触发 onShown逻辑闭环 状态保存 页面被遮挡时状态易被系统回收 明确感知 Hidden 状态,可做保活/暂停资源利用最优 代码健壮性 强依赖组件的挂载状态,脆弱 基于用户视觉焦点,符合人类直觉 大幅降低 Bug 率 三、 避坑指南:老司机的吐血经验
NavDestination 的生命周期用起来很爽,像开了物理外挂,但它也有自己的脾气。不注意的话,分分钟让你陷入诡异的 Bug 中。onAppear 和 onShown 混为一谈:onAppear 侧重于组件渲染(DOM 挂载完成),而 onShown 侧重于用户可视(渲染完毕且动画结束,处于激活状态)。在涉及复杂动画或异步布局的场景下,两者的触发时机可能有几百毫秒的延迟。(老司机建议:涉及到页面数据加载、埋点曝光,一律放在 onShown 里,稳得一批。)
如果你在 onShown 里不小心又触发了页面的重新渲染(比如不当的 this.state 修改),会导致页面不断刷新,直接卡死应用。
当调用 NavPathStack.pop() 时,页面会依次触发 onHidden -> onDisappear -> aboutToDisappear。如果你想在页面销毁时保存用户输入的内容,千万别在 onHidden 里做(因为只是切到后台也会触发),一定要放在 aboutToDisappear 中。四、 冲浪 HarmonyOS 6 (NEXT):适配与演进必读
在 HarmonyOS 6 中,系统全局支持了类似 iOS 的右滑返回手势预览。这意味着,当用户刚开始向右滑动时,当前页面会触发 onHidden(因为系统认为它可能要失去焦点),但如果用户松手取消,又会立刻触发 onShown。
(适配建议:在过去,我们常在 onHidden 里做一些不可逆的操作(如标记消息为已读)。在 NEXT 版本中,你必须对这些操作增加防抖或延迟确认,否则会出现严重的交互 Bug。)
NEXT 版本极大强化了 Navigation 的转场动画,支持更细腻的共享元素动画。但这也导致了生命周期的穿插变得更加复杂。
(适配建议:在涉及共享元素动画的页面跳转中,onAppear 可能会先于下级页面的 onShown 执行完毕。如果你有强依赖上下级页面生命周期顺序的“祖传代码”,现在正是重构它的最好时机。建议引入状态机或 EventHub 来解耦这种时序依赖。)
针对拥有复杂列表和频繁页面跳转的应用,NEXT 底层对 NavDestination 的销毁和重建机制进行了优化。
(适配建议:系统现在更倾向于将不可见的 NavDestination 放入缓存池(仅仅触发 onDisappear 和 onHidden,但不触发 aboutToDisappear)。这意味着,你的页面组件必须能够优雅地处理“从缓存池中重新激活”的逻辑,不能假定每次 onAppear 都是一次全新的创建。)五、 回过来康康
NavDestination 独有生命周期的底层心法,实战演示了如何用 onShown 斩断时序依赖,又前瞻了鸿蒙 6 里的预测性返回与动画适配。onShown 和 onHidden 为你铺平了感知用户意图的道路。NavDestination 的生命周期,让你在面对产品经理提出的“丝滑过渡”、“即时响应”等苛刻要求时,拥有四两拨千斤的从容。
我又不是产品,又不是运维,只是一个开发,为什么还需要出差。
每个 offer 都是差一点点,也很纠结要不要妥协。
好难啊
如果你用 Hermes 可以先把这段配置加上: 🤖 Agent 一键配置:直接把下面这段发给你的 AI agent,让它自己读配置、改配置、验证: 注意: 为什么这几行重要? Hermes 的默认上下文压缩阈值是 0.5——上下文用到一半就开始压。 如果你用惯了 Claude Code,可能没啥感觉——Claude Code 窗口大、压缩触发晚。但切到 Hermes,聊个五六句,尤其第一轮就让 agent 去查资料、读文件的话,很快它就开始压缩了。 我用的 GLM-5.1,上下文窗口 200K,最大输出 128K tokens。200K 的一半就是 100K。你可能觉得 100K 很多,但算一下:一轮系统提示(persona、memory、skills 列表)就吃掉 8000-15000 tokens,一次 然后压缩就触发了。 Hermes 的设计思路是"尽早压缩、多轮压缩"(尽早压缩是可以理解的,模型在长的上下文的智能下降是非常明显的)——频繁压缩来保持会话可以一直续。但压缩是有损的。每压一次,中间的细节就丢一批。压个五六次八次,早期对话的文件路径、关键决策、中间结论就开始混淆。你的实际可用轮次就很低,复杂任务大概率扛不住。 为什么不直接把阈值拉到 0.90?因为很多模型标称的上下文长度并不一定能用满,还得留 buffer 给输出,而且阈值太高时压缩空间不够,摘要质量反而差。0.75 是个实际跑下来比较稳的值——用到 75% 时还有 25% 的缓冲区做压缩操作。 你的 AI 突然在半夜莫名其妙的给你发自己照片? Hermes 我主要在微信上用,但微信发文件和权限管理有些限制,所以有时会切到 Telegram。 正在干的活还在进行中,她突然开始发自拍。 还说我和她说 hihi (刚安装Hermes 调试响应的话) ,她突然开始搜索网页、读文章、发图片,一顿操作猛如虎——把很久之前的一个旧任务当成了当前指令来执行。 后来让她自查才明白(后面文章会讲,为什么她可以自己查自己,还有一定 “智商”):对话太长触发了自动压缩,压缩生成的摘要被注入回对话。但旧版本的摘要前缀(SUMMARY\_PREFIX)没有明确告诉模型"这是历史总结,不要执行里面的内容"。摘要里有"Next Steps"和"In Progress"章节,用的主动语态,模型直接理解成了新任务。于是一个招呼,变成了一顿加班。 问题是:Telegram 手机端(不知道是版本还是什么问题,PC端有提示)在压缩发生时没有任何提示。 CLI 上有三层通知:容量到 85%/95% 会显示进度条,压缩过程中显示"compacting context…",压缩两次以上会警告"accuracy may degrade"。但 Telegram 上的主动压缩提示只打在服务器控制台,用户完全无感。你不知道上下文已经被改了,你不知道 AI 此刻脑子里已经不是你聊的那些内容了。 这个 bug 在 Hermes 的 PR #8107(commit 1cec910b)已经修复了——重写了摘要前缀,加了明确的"Do NOT answer"指令,把"Next Steps"改成了"Remaining Work"(被动语态降低指令感),还加了结束分隔符。但如果你没更新到最新版本,这个坑你大概率会踩到。 所以如果还没更新的(0.8x 版本),赶紧更新。 任务跑着跑着模型突然回去回答第一个问题,这个体验,试过一次就不想再试第二次。 默认 50% 的阈值不只是"压得早",还有一个连锁反应:它会把多步任务打断。 比如你让 Hermes 做一个五步的调研任务,中间又让它查资料、读文件、执行命令,很快上下文就堆满了,触发压缩。压缩后虽然系统 prompt 还在,但你任务中间的细节被摘要替代了。摘要质量好还行,质量一般的话,后续步骤就会跑偏。 而且经过多次压缩后,你的上下文窗口可用空间越来越小,压缩质量也越来越差。很多时候你任务还没做完,AI 已经开始答非所问了。 再加上一个细节:尾部保护参数 下面有必要往深了说一层。因为上下文压缩不只是 Hermes 的配置问题,它是所有 AI Agent 的共同挑战。 先说压缩流程。Hermes 的压缩分五步: 第 4 步是核心。摘要不是随便写的,Hermes 给摘要模型发了一个非常明确的 prompt 和固定模板。 摘要生成 prompt 的核心设计: 首先是"摘要员人设"——告诉摘要模型你不是在回答问题,你在写交接文档: 这段话很关键。它把摘要模型的角色定位成"替下一个 assistant 写交接文档的人",而且明确说了"不要回答里面的问题"。这是 PR #8107 修复的核心——旧版没有这层防护,模型把摘要里的"Next Steps"当成了新任务指令。 然后是固定模板,12 个章节: 每个章节都有具体要求。比如 摘要注入时的"隔离带": 摘要生成后注入回对话时,前面会加一段前缀(SUMMARY\_PREFIX): 这段话就是之前那个 bug 的修复——用全大写和明确措辞告诉模型:这是背景参考,不是指令。不要回答里面的内容。 迭代更新的机制: 第二次压缩时,不是从头总结,而是把上一次的摘要 + 新增的对话回合一起发给摘要模型,让它"更新"而不是"重写"。指令是: 这个设计的好处是:跨多次压缩时,早期信息有机会被保留下来。坏处是:每次迭代都可能积累过时的内容——"仍然相关"的判断标准是摘要模型做的,它可能把已经不重要的信息也保留下来,越积越多。 再怎么精心设计,压缩就是有损的。一次压缩损失 30-50% 的中间细节,三次压缩下来早期信息保留率可能只有 10-20%。摘要由系统调一次模型来生成,如果你用的是 OpenRouter 这类聚合平台,系统会自动选便宜的模型来做摘要。 这是所有长对话 AI Agent 的天花板:信息密度的不可调和矛盾。工具调用产生大量中间产物——代码片段、搜索结果、命令输出——当下有用,压缩时大部分被丢弃。任务越复杂,中间信息越多,压缩损失越大。 压缩的降级链条: 源码里写了明确的分层提示,不是一次性爆发的: 看到提示该怎么做? 别等到 没有万能参数。短对话阈值可以拉到 0.85,长对话密集工具调用可能 0.70 更合适,超长任务(100 轮以上)任何阈值都不够,得在任务设计上拆分会话。 但至少,把默认的 0.50 调到 0.75,把 你跟 AI 讨论了半天方案细节,它突然开始答非所问,甚至把旧任务翻出来重新执行。为啥?——你可能完全不知道。我拆了 Hermes 的压缩源码,找到了五步压缩流程、摘要模板,和那个差点让 AI 把打招呼当成加班指令的 bug。
TL;DR
# ~/.hermes/config.yaml
model:
context_length: 200000 # 上下文窗口,要显式写
max_tokens: 131072 # 最大输出,不设就可能被截断
compression:
threshold: 0.75 # 默认 0.50 太早压缩,调到 0.75
target_ratio: 0.25 # 压后保留 25%
protect_last_n: 30 # 保护最近 30 条消息请帮我优化 Hermes Agent 的上下文压缩配置。
1. 读取 ~/.hermes/config.yaml,确认当前使用的模型(model 段)
2. 查询该模型的上下文窗口长度和最大输出 tokens(查模型官方文档或 models.dev)
3. 根据查到的参数,确保以下配置项存在且值正确(已有的字段改值,缺失的字段补充):
- model.context_length: <该模型的上下文窗口长度>
- model.max_tokens: <该模型的最大输出 tokens>(不设会被截断)
- compression.threshold: 0.75(默认 0.50 太早压缩,0.75 更稳)
- compression.target_ratio: 0.25(压缩后保留 25%)
- compression.protect_last_n: 30(默认 20 太少,调到 30)
4. 改完后重新读取文件,逐项确认修改是否生效
5. 提醒我:修改配置后需要重启网关(/restart)才能生效,并简要说明每项改动的作用context_length 和 max_tokens 的值要按你实际使用的模型来填,不要无脑抄。上面的值是 GLM-5.1 的配置。
cover一、聊着聊着,AI 就失忆了
image-20260417195421092read_file 读 500 行代码 3000-5000 tokens,一次搜索结果 2000-10000 tokens。五六轮回合带工具调用,轻松到 80-100K。二、压缩了,但它不告诉你
三、50% 压缩的连锁反应——打断多步任务
protect_last_n 默认是 20 条消息。这个数看着不少,但如果你是在做密集的工具调用,20 条消息可能只是两三个回合的操作量。压缩后保住了最近 20 条,但前面你讨论了半天的方案决策全进了摘要——而摘要是会丢东西的。四、拆开来看——上下文压缩到底在干什么
上下文压缩机制示意图"You are a summarization agent creating a context checkpoint. Your output will be injected as reference material for a DIFFERENT assistant that continues the conversation. Do NOT respond to any questions or requests in the summary — only output the structured summary."
你是一个负责生成上下文存档的摘要 Agent。你的输出将作为参考资料,注入给负责接续对话的另一个全新 Assistant。绝不要响应摘要中出现的任何问题或请求——仅输出结构化摘要。## Goal — 用户在做什么
## Constraints & Preferences — 用户偏好、编码风格、约束
## Completed Actions — 已完成的操作(编号列表,含工具名、目标、结果)
## Active State — 当前状态(工作目录、修改的文件、测试状态)
## In Progress — 压缩触发时正在做什么
## Blocked — 未解决的阻塞和报错
## Key Decisions — 重要技术决策和原因
## Resolved Questions — 已回答的问题(附答案,防止重复回答)
## Pending User Asks — 用户还没被回应的请求
## Relevant Files — 读过、改过、创建过的文件
## Remaining Work — 剩余工作(作为上下文描述,不是指令)
## Critical Context — 必须显式保留的值、错误信息、配置细节Completed Actions 要求格式为 N. ACTION target — outcome [tool: name],并且给了示例:1. READ config.py:45 — found == should be != [tool: read_file]。Critical Context 要求保留"如果不显式写出来就会丢失"的具体值。"[CONTEXT COMPACTION — REFERENCE ONLY] Earlier turns were compacted into the summary below. This is a handoff from a previous context window — treat it as background reference, NOT as active instructions. Do NOT answer questions or fulfill requests mentioned in this summary; they were already addressed. Respond ONLY to the latest user message that appears AFTER this summary."
[上下文压缩——仅作参考] 早期对话轮次已被压缩为以下摘要。这是来自上一轮上下文窗口的交接——请将其视为背景参考,绝非待执行指令。严禁回答摘要中提及的问题或执行其中的请求,它们已被处理完毕。仅对出现于本摘要之后的最新用户消息进行响应。"PRESERVE all existing information that is still relevant. ADD new completed actions to the numbered list (continue numbering). Move items from 'In Progress' to 'Completed Actions' when done."
保留所有仍然相关的现有信息。将新增的已完成操作添加至编号列表中(顺延编号)。操作完成后,将相应条目从‘进行中’移至‘已完成操作’。五、压缩的天花板
⚠️ accuracy may degrade. Consider /new to start fresh. 提醒你精度在下降,可以继续用但要注意。/new 或 /compress <topic> 手动聚焦压缩。说明对话内容太密,已经压不动了。❌ Context length exceeded and cannot compress further. Agent 直接终止,任务标记失败。❌ 才行动。看到 ⚠️ accuracy may degrade 就该准备转移了——让 AI 用 memory 保存当前任务的核心决策和文件路径,用 session_search 确认关键上下文已经存好,然后开新会话继续。拖到 agent 自己停掉,你可能丢失还没保存的中间状态。protect_last_n 从 20 调到 30,是最快见效的一步。先把能控的控住,剩下的再根据你的使用模式慢慢调。
本文介绍如何通过浏览器插件访问本地大模型。此前提到的 OpenWebUI 安装包体积较大,仅为通过 WEB 界面使用本地大模型,就需占用约 10GB 的电脑磁盘空间,性价比偏低。 浏览器建议使用微软的 关于 若需通过 若需通过手机 APP 连接本地大模型,可参考文章《手机直连本地大模型!不用云服务、不花一分钱,全家都能用》。 若需通过桌面客户端 打开微软的 访问谷歌 注意Edge浏览器,因为Edge浏览器的插件市场在国内可以正常访问,安装插件很方便。如果你使用谷歌的Chrome浏览器,在国内是不能正常访问Chrome浏览器的插件市场的,也就无法安装插件了。OpenWebUI的基本使用和开发环境搭建,可参考文章《Ollama+OpenWebUI 最佳组合:本地大模型可视化交互方案》。OpenWebUI手机网页端连接本地大模型,可参考文章《不花一分钱!把本地大模型装进手机,全家共享+权限管控全攻略》。ChatWise 连接本地大模型,可参考文章《不想用网页版 OpenWebUI?推荐一个轻量本地大模型桌面客户端》。Page Assist插件
安装Page Assist插件
Edge浏览器,点击右上角的三个点,如下截图:使用Page Assist
ollama-client 插件
ollama-client 插件仅支持在谷歌 Chrome 浏览器中安装,其 GitHub 地址为:ollama-client的GitHub地址。安装ollama-client插件
Chrome 浏览器的应用商店需确保网络环境可正常访问谷歌服务。使用ollama-client插件
向量模型all-minilm:latest
ollama-client这个插件在安装成功并成功连接本地Ollama服务之后,ollama-client这个插件会通过你本地的Ollama给你本地再下载并安装一个all-minilm:latest大模型。这个大模型的安装体积很小,只有45MB。ollama-client插件安装这个小的大模型是为了提供向量搜索的能力,也就是语义搜索的能力。
在Windows上面使用搜狗输入法的时候,搜狗输入法总是以Windows系统通知的形式来弹出弹窗广告并且还无法关闭这个系统通知形式的广告。今天就通过技术手段对抗搜狗输入法的这种流氓手段。 下面这个搜狗输入法的弹窗广告你肯定见过吧? 关键是点击三个[···]还无法关闭搜狗输入法的弹窗广告,可以看到下图中的关闭通知的菜单权限是灰色并且无法关闭。这就比较流氓了,今天必须给他关掉。 你如果想在Windows的系统通知里面关闭搜狗输入法的通知,你会发现这里也找不到搜狗输入法关闭选项。由于搜狗输入法的流氓做法,Windows系统根本不知道搜狗输入法使用过系统通知。 要想关闭搜狗输入法的弹窗广告,需要打开注册表,修改搜狗输入法的注册表。注册表位置: 再次打开Windows的系统通知,关闭搜狗输入法的系统通知。 具体原理请参考抖音博主:搜狗输入法的弹窗广告
Windows系统通知
关闭搜狗输入法的系统通知
计算机\HKEY_CLASSES_ROOT\AppUserModelId\Sogou.Ime.SysToast.Biz。然后将ShowInSettings的值修改为1,就可以在Windows系统设置里面的系统-->通知里面找到搜狗输入法了,然后在Windows系统设置里面的系统-->通知里面关闭搜狗输入法的通知就可以了。关闭搜狗输入法的系统通知
具体原理
边亮_网络安全的视频讲解。


以前一直觉得资产管理离自己挺远的。
资产和负债都分在各处……平时知道,但一算总数就有点乱。
所以历经 5 个月,我做了个 App ,叫做 iAssets ,不记账、只盘点,因为记账大家用久了往往坚持不下来,但是需要关心自己的资产状况。
就是帮你把这些理清楚:
💰 资产 / 负债 / 净资产一眼看清
📈 趋势变化、资产结构更直观
🌍 多币种支持
👨👩👧👦 家庭资产一起管理也可以
我更在意的是:它能不能成为一个你愿意偶尔打开看一眼的工具 🌙
基础功能也都做了:
🗂️ 多账本管理
🔎 变更记录可查
☁️ iCloud 同步备份
🔐 密码 / 面容 / 指纹解锁
如果你也觉得米有点“散”,
但又不想折腾复杂工具,可以试试 💬
现在还在公测,目前 Testflight 公测阶段,名额有限,开放 30 名用户,需要 iOS 26+ 版本。
后续根据你的使用次数和反馈问题次数评估赠送下永久或者年度激活码 也会有早鸟价格的。
大家感兴趣的可以留下你的邮箱,我会拉大家,进入测试。
也欢迎入群反馈使用问题: https://t.me/xiaoyublog
有 2 友提醒插件的 icon 渲染不出来,因为页面结构发生了变化,小小优化了脚本,如果需要使用,去油猴更新一下即可
下周一人人送 2TB 空间 + 30 天会员,快来抢先注册:
在AI技术不断向传统产业渗透的当下,农业正迎来一场深刻的智能化变革。从“经验驱动”走向“数据驱动”,已经成为现代畜牧业发展的核心趋势。尤其是在规模化养殖场景中,如何通过技术手段实现对牛群状态的实时感知与精准管理,成为行业关注的重点。 围绕这一需求,基于计算机视觉的牛行为检测技术逐渐兴起,而高质量的数据集正是模型能力提升的关键基础。本数据集正是在这样的背景下构建,旨在为相关研究与应用提供可靠的数据支撑。 在实际养殖过程中,牛的行为变化往往直接反映其健康状况与生产性能。例如: 传统依赖人工巡检的方式存在明显局限: 随着深度学习与目标检测技术的发展,利用视觉模型自动识别牛行为成为可行路径。而这一切的前提,是拥有一个高质量、标准化、贴近真实场景的数据集。 本数据集共包含 3600张高质量标注图像,覆盖真实养殖环境下牛的多种行为状态,所有图像均经过人工严格筛选与精细标注,确保数据的准确性与一致性。 数据集整体结构规范清晰,采用标准目标检测数据组织形式: 该结构可无缝适配YOLO系列模型(如YOLOv5、YOLOv8),开箱即用。 类别划分清晰,覆盖牛的核心日常行为,具备良好的区分度。 本数据集可广泛应用于以下方向: 实现牛群行为的自动识别与实时监控,构建数字化养殖平台 通过行为异常检测,实现疾病早期预警与健康评估 分析进食与饮水行为,优化饲料投放策略,提高养殖效率 用于目标检测、行为识别模型训练与性能评估 适用于高校课程实验、科研项目及算法验证 从数据集设计角度来看,这套牛行为检测数据集有几个值得关注的点: 首先,它没有一味追求“大而全”,而是聚焦最核心、最有价值的行为类别,这对于实际落地非常关键。很多项目失败的原因,不在于模型不够复杂,而在于数据不够“实用”。 其次,数据结构高度标准化,这一点对于工程开发者来说非常友好。无需额外清洗或转换,可以直接进入训练流程,大幅提升开发效率。 最后,这类数据集的真正价值,不仅在于“训练模型”,更在于推动农业场景智能化落地。当模型能够稳定识别行为时,才真正具备商业价值。 随着AI技术不断向产业侧渗透,农业领域正迎来一轮智能化升级浪潮。牛行为检测作为智慧养殖的重要组成部分,其背后的数据基础尤为关键。 本数据集以高质量标注、标准化结构和实用性强的类别设计,为相关研究与应用提供了坚实支撑。不论是用于模型训练、系统开发,还是教学实践,都具备较高的价值。 如果你正在从事农业AI、目标检测或智慧牧场相关项目,这套数据集会是一个非常不错的选择。4类牛行为检测数据集(3600张)|YOLO训练数据集 智慧养殖 行为识别 健康监测 精准饲喂 牧场数字化管理
前言
数据集下载链接
通过网盘分享的文件:牛行为检测数据集
链接: https://pan.baidu.com/s/1SyqH1z0OzFAguRGtixLw6A?pwd=fusi
提取码: fusi背景
一、数据集概述
database/牛行为检测/
├── train/
│ └── images/
├── valid/
│ └── images/
├── test/
│ └── images/二、数据集详情
1. 数据规模
2. 行为类别(共4类)
类别ID 中文名称 英文名称 行为描述 0 喝水 Drinking 牛低头饮水 1 进食 Eating 采食饲料或牧草 2 卧下 Sitting 身体贴地休息 3 站立 Standing 四肢支撑直立 3. 数据特点
三、适用场景
1. 智慧牧场系统
2. 牛只健康管理
3. 精准饲喂与资源优化
4. 行为识别算法研究
5. 农业AI教学与科研
四、心得
五、结语
在计算机视觉与人工智能快速发展的今天,交通出行领域的智能化建设成为重要研究方向之一。无论是城市治理、交通监控,还是智能驾驶与无人配送,单车与共享单车的自动识别与检测都扮演着举足轻重的角色。近年来,共享单车逐渐普及,不仅缓解了城市短途交通的压力,也催生了新的视觉识别需求。 在计算机视觉任务中,数据集是算法研究和模型训练的基石。一个优质的、经过精确标注的数据集,能够极大提升模型的训练效果和泛化能力。本次分享的单车、共享单车已标注数据集,不仅在数量上足以支持主流深度学习模型的训练,而且已经完成了train、test、val的划分,并提供了对应的标注文件,可直接应用于YOLO、Faster R-CNN、Mask R-CNN、SSD等常见目标检测与实例分割框架。 在这篇文章中,我们将从数据集概述、背景、数据结构以及应用场景等多个角度进行全面解析,帮助研究者、开发者和爱好者快速理解并应用该数据集。 近年来,随着共享单车在各大城市的普及,交通管理者和科研人员亟需通过计算机视觉手段来识别单车使用情况、停放区域、违规占道等现象。为了实现上述目标,建立一个高质量的单车与共享单车数据集就显得尤为重要。 传统交通场景数据集,如COCO、Pascal VOC、Cityscapes等,虽然涵盖了交通工具类别,但对于单车、共享单车的精细化标注并不充分。这就导致在城市级应用中,模型识别能力存在明显不足。因此,本数据集在细粒度目标检测上提供了针对性支持。 数据集图片均来自于不同城市、不同场景的采集: 数据集经过划分为: 数据集中所有图片均经过专业标注,采用Pascal VOC / COCO格式,支持主流深度学习框架。标注类别主要分为: 每张图片附带对应的XML(VOC)或JSON(COCO)标注文件,包含: 随着城市化进程的加快和绿色出行理念的深入人心,单车和共享单车已成为城市交通系统的重要组成部分。然而,随之而来的管理挑战也日益凸显,如乱停乱放、占用公共空间、车辆损坏等问题。 在城市管理中,单车和共享单车的管理面临以下挑战: 在智能交通系统中,单车和共享单车的检测与识别具有重要意义: 从技术角度来看,单车和共享单车的检测具有以下挑战: 因此,构建一个高质量的单车和共享单车数据集,对于推动相关技术的发展具有重要意义。 数据集图像来源广泛,涵盖多种复杂环境: 这种多样化保证了模型能够在真实应用中具备良好的鲁棒性。 数据集中包含以下主要文件: 对于深度学习工程师而言,只需将数据集路径配置到训练脚本,即可开始模型训练。 下面是该数据集的典型应用流程,从数据获取到模型部署的完整过程: 该数据集不仅适用于学术研究,还可直接落地到产业应用中,主要场景包括: 通过目标检测模型,实时识别道路上的单车与共享单车: 政府与企业可基于该数据集训练模型,实现: 自动驾驶车辆与无人配送机器人在街道行驶时,需要精准识别: 研究人员可基于该数据集进行: 在开始训练之前,需要做好以下准备工作: 使用YOLOv8训练示例: 训练完成后即可进行预测: 为了获得更好的训练效果,建议采用以下技巧: 为了获得更好的训练效果,建议在使用该数据集时进行以下预处理: 数据增强: 图像标准化: 数据平衡: 应用场景:城市共享单车管理 实现步骤: 效果:单车检测准确率达到95%以上,显著提升了共享单车管理效率。 应用场景:自动驾驶车辆 实现步骤: 效果:实现了对单车和骑行者的精准检测,提高了自动驾驶的安全性。 根据不同的应用场景和硬件条件,推荐以下模型选择: 在使用该数据集训练模型时,可能会遇到以下挑战: 挑战:不同品牌、型号的单车外观差异较大 解决方案: 挑战:单车可能被其他物体或车辆遮挡 解决方案: 挑战:远处的单车在图像中占比较小 解决方案: 挑战:不同光照条件下单车表现差异大 解决方案: 高质量的标注是数据集成功的关键。在构建该数据集时,我们采取了以下质量控制措施: 这些措施确保了数据集的高质量,为模型训练提供了可靠的基础。 随着人工智能技术在交通领域的不断发展,基于计算机视觉的单车检测技术正在逐渐走向实际应用。未来,我们计划在以下方面进一步完善和扩展: 数据是人工智能的"燃料"。一个高质量、标注精准的单车与共享单车数据集,不仅能够推动学术研究的进步,还能为智慧交通、智慧城市的建设提供有力支撑。 在计算机视觉领域,研究者们常常会遇到"数据鸿沟"问题:公开数据集与真实业务需求之间存在不匹配。本次分享的数据集正是为了弥补这一不足,使得研究人员与工程师能够快速切入单车检测领域,加速模型从实验室走向真实应用场景。 本数据集具有以下特点: 通过本数据集,研究人员和开发者可以快速构建单车检测模型,验证算法性能,推动相关技术的实际应用。 未来,我们可以在该数据集的基础上,扩展更多标签,如"人骑车"、"违规停放"、"损坏单车"等,进一步提升研究与应用价值。 通过本文的介绍,相信读者对该数据集有了全面的了解。我们期待看到更多基于此数据集的创新研究和应用,为智慧交通和智慧城市的发展贡献力量。单车共享单车已标注数据集分享(适用于YOLO系列深度学习分类检测任务)
源码下载
链接:https://pan.baidu.com/s/1B8ufJq7wkSUNj-knWaQzLg?pwd=puqc 提取码:puqc 复制这段内容后打开百度网盘手机App,操作更方便哦
前言
一、数据集概述
1. 数据集构建背景
2. 数据集规模
3. 标注方式
二、背景与意义
1. 城市管理的需求
2. 智能交通的需求
3. 技术发展的需求
三、数据集详细信息
1. 图像采集与多样性
2. 数据格式
3. 数据示例
VOC标注格式(XML)
<annotation>
<folder>images</folder>
<filename>bike_001.jpg</filename>
<size>
<width>1280</width>
<height>720</height>
<depth>3</depth>
</size>
<object>
<name>bicycle</name>
<bndbox>
<xmin>320</xmin>
<ymin>150</ymin>
<xmax>600</xmax>
<ymax>500</ymax>
</bndbox>
</object>
</annotation>COCO标注格式(JSON)
{
"images": [
{
"file_name": "bike_001.jpg",
"height": 720,
"width": 1280,
"id": 1
}
],
"annotations": [
{
"id": 1,
"image_id": 1,
"category_id": 1,
"bbox": [320, 150, 280, 350],
"area": 98000,
"iscrowd": 0
}
],
"categories": [
{"id": 1, "name": "bicycle"},
{"id": 2, "name": "shared-bicycle"}
]
}四、数据集应用流程
五、适用场景
1. 智能交通监控
2. 智能城市治理
3. 自动驾驶与无人配送
4. 学术研究与竞赛
六、模型训练指南
1. 训练准备
ultralytics、numpy、pandas等2. 训练示例(YOLOv8)
from ultralytics import YOLO
model = YOLO("yolov8n.pt")
model.train(
data="bicycle_dataset.yaml",
epochs=100,
imgsz=640,
batch=16
)model.predict("test_image.jpg")3. 训练技巧
4. 数据预处理建议
七、实践案例
案例一:智能共享单车管理系统
案例二:自动驾驶辅助系统
八、模型选择建议
场景 推荐模型 优势 实时监测 YOLOv8n、YOLOv8s 速度快,适合边缘设备 高精度识别 YOLOv8m、YOLOv8l 精度高,适合服务器部署 移动端部署 MobileNet-SSD、NanoDet 模型体积小,适合移动设备 学术研究 Faster R-CNN、RetinaNet 精度高,适合算法研究 九、挑战与解决方案
1. 形态多样性
2. 遮挡问题
3. 小目标检测
4. 光照变化
十、数据集质量控制
十一、未来发展方向
十二、总结
在计算机视觉领域,人体检测已从传统的“整个人体识别”逐步发展到“细粒度人体部位理解”。相比简单的人体框检测,对头部、手部、脚部等关键部位的精细识别,在智能监控、人机交互、行为分析等场景中具有更高的应用价值。 然而,人体部位检测面临诸多挑战,例如姿态变化大、遮挡严重、部位尺度差异明显等问题,这对模型的特征提取能力与数据质量提出了更高要求。因此,一个结构规范、标注精细的数据集,是实现高精度人体部位检测的关键基础。 本文介绍一个人体部位细粒度检测数据集,适用于YOLO系列等主流目标检测模型,可用于科研与工程实践。 本数据集面向人体部位细粒度检测任务构建,覆盖人体整体及关键局部区域,提供标准化的数据支持。 数据集基本信息如下: 数据结构规范,可直接适配YOLOv5、YOLOv8等主流模型,无需额外处理。 传统人体检测主要关注“是否存在人”,而在实际应用中,往往需要更精细的信息,例如: 细粒度人体部位检测可广泛应用于: 但该任务具有明显挑战: 因此需要高质量、多样化数据支撑模型训练。 数据集采用标准YOLO目录结构: 说明: 数据集共包含5类人体相关目标: 该类别设计兼顾整体与局部: 数据包含多种人体状态: 有助于模型学习复杂姿态特征。 数据涵盖: 提升模型泛化能力。 有助于提升检测精度。 适合快速训练与模型验证。 YOLO标准格式如下: 示例: 说明: 手部、脚部尺寸较小: 建议: 多人场景中: 建议: “人体”与“身体”存在一定重叠: 建议: 该数据集具有以下特点: 适用于从入门到工程开发的多阶段任务。 本文对人体部位细粒度检测数据集进行了系统介绍。该数据集在人体检测与细粒度识别任务中具有较高实用价值,可为智能安防、人机交互等领域提供数据支撑。 在实际应用中,建议结合具体任务进一步扩展数据(如增加关键点标注或行为标签),以提升模型在复杂场景下的表现能力。人体部位细粒度检测数据集(7000张,5类)|YOLO训练数据集 人体检测 姿态分析 智能安防
前言
数据集下载链接
通过网盘分享的文件:人体部位细粒度检测数据集
链接: https://pan.baidu.com/s/1s6lNX4vMAs7A0dF-qoxwBw?pwd=7ghf
提取码: 7ghf一、数据集概述
database/人体部位细粒度检测数据集二、背景
三、数据集详情
3.1 数据结构
database/人体部位细粒度检测数据集/
├── train/images
├── valid/images
├── test/images.txt 格式3.2 类别定义
类别ID 类别名称 0 身体 1 脚部 2 手部 3 头部 4 人体 3.3 数据特性分析
(1)多姿态覆盖
(2)多场景与光照
(3)细粒度标注
(4)中等规模数据
3.4 标注格式
class_id x_center y_center width height3 0.50 0.30 0.20 0.25
2 0.60 0.55 0.15 0.20四、模型训练适配(YOLOv8)
4.1 数据配置文件
path: database/人体部位细粒度检测数据集
train: train/images
val: valid/images
names:
0: body
1: foot
2: hand
3: head
4: person4.2 训练命令
yolo detect train \
data=data.yaml \
model=yolov8n.pt \
epochs=150 \
imgsz=640 \
batch=164.3 参数建议
参数 推荐值 model yolov8n / yolov8s epochs 100~200 imgsz 640 batch 8~16 4.4 训练策略建议
五、适用场景
5.1 智能安防监控
5.2 人机交互
5.3 行为分析
5.4 虚拟现实 / AR
5.5 教学与科研
六、实践经验与优化建议
6.1 小目标问题
6.2 遮挡问题
6.3 类别关系处理
6.4 部署建议
6.5 可扩展方向
七、心得
八、结语
你好,我是冴羽。 你写的 React.memo 可能根本没用! 你可能觉得自己已经做了性能优化——给组件包了 但如果你在传递 props 时写成这样: 恭喜你,你的优化白做了~ 为什么呢? 因为 React 比较的是引用,不是内容。 当你写 如果所有 props 都“相等”, React 就跳过子组件的渲染,直接复用上次的结果。 问题来了——React 用什么判断“相等”? 答案是 即使内容完全一样,引用不同就是不同。 React 就会认为 props 变了,然后重新渲染子组件。 这就是为什么内联对象和回调函数是隐藏的性能杀手——它们每次渲染都会创建新引用,让 以前你以为 我得先说清楚:不是所有内联 props 都是性能 bug。 如果子组件很轻量,渲染频率很低,也没用 memo,那内联写法完全没问题。 React 官方文档也一直强调:先测量,别瞎优化。 但当这三个条件同时出现时,你就要注意了: 在这种场景下,不稳定的内联引用不是“增加一点开销”——它会直接废掉了你精心设计的优化! 更要命的是,这个问题不会报错,不会警告,UI 照常工作。 它只会悄悄地让你的列表过滤器变卡、输入延迟、火焰图爆炸。 为了证明这个问题有多严重,我搭了个测试场景: 代码长这样: 结果惨不忍睹: 也就是说, 因为 我还用了 这就是引用不匹配的铁证。 要让 React 的 bailout 机制生效,你需要稳定的引用。 修复后的效果: 性能直接提升 40 倍! 如果子组件依赖引用相等来跳过渲染,那父组件就必须传稳定的引用。如果子组件根本没 memo,或者渲染成本很低,那你稳定引用也没意义。 我的建议是: React 官方文档也是这么说的:能外提就外提,需要缓存再用 Hooks。 关于 React Compiler: 你可能听说过 React Compiler 会自动帮你做这些优化。确实,它能在编译时自动 memoize 很多代码,减少手动写 但这不意味着引用稳定性就不重要了。React Compiler 的文档也说了: 所以即使用了 Compiler,理解引用不稳定如何影响重新渲染,依然是必修课。 内联对象和内联回调不是“错误代码”。大部分时候,它们就是普通的 JSX 表达式。 但当它们穿过 memo 边界时,游戏规则就变了。 这个问题值得更多关注,因为它太容易在生产环境里悄悄发生——代码看起来很干净,应用运行正常,但你以为买到的性能优化其实根本没生效。 所以给想写快速 React 应用的团队一个建议: 先 Profile。如果 memo 的子树还在频繁渲染,先检查 props,别急着怪 React。把静态对象移出渲染路径。只在子组件真正受益时才 memoize 回调。用 React DevTools 和 Why Did You Render 确认到底什么变了、为什么变。 坚持这么做, 我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。 欢迎围观我的“网页版朋友圈“,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。React.memo,给回调加了 useCallback,给计算值用了 useMemo。<UserCard
style={{ padding: 16, borderRadius: 8 }}
onSelect={() => handleSelect(user.id)}
config={{ showAvatar: true, compact: false }}
user={user}
/>1. 为什么 React.memo 会失效?
React.memo 包裹一个组件时,React 会在父组件重新渲染时比较新旧 props。Object.is,也就是引用相等:Object.is({ padding: 16 }, { padding: 16 }) // false
Object.is(() => {}, () => {}) // falseReact.memo 形同虚设。React.memo 在帮你省性能,实际上,每次都在重新渲染。2. 什么时候这个问题会要命?
3. 我做了个实验:200 行列表的性能崩溃
React.memo 包裹的 ProductRow 组件{filteredProducts.map(p => (
<ProductRow
key={p.id}
product={p}
style={{
display: 'flex',
justifyContent: 'space-between',
alignItems: 'center',
padding: '12px 20px',
borderBottom: '1px solid #eee'
}}
onAddToCart={(id) => console.log('Added:', id)}
/>
))}Renders: 14React.memo 完全失效了。style 对象和 onAddToCart 回调每次都是新创建的,memo 的 props 比较每次都是失败的。why-did-you-render 这个工具来诊断。它直接告诉我:props.style 是“内容相同但对象不同”props.onAddToCart 是“同名但函数不同”4. 怎么改?很简单
改法 1:把静态对象移到模块作用域
// ✅ 在组件外部定义,只创建一次
const ROW_STYLE = {
display: 'flex',
justifyContent: 'space-between',
padding: '12px 20px',
borderBottom: '1px solid #eee'
};
export default function ProductList() {
// ...
return (
<ProductRow
style={ROW_STYLE}
// ...
/>
);
}改法 2:用 useCallback 包裹动态回调
export default function ProductList() {
const [searchTerm, setSearchTerm] = useState('');
// ✅ 依赖数组为空,函数引用保持稳定
const handleAddToCart = useCallback((id) => {
console.log('Added:', id);
}, []);
return (
<ProductRow
onAddToCart={handleAddToCart}
// ...
/>
);
}ProductList 渲染时间从 243.9ms 降到 6ms2why-did-you-render 不再报警5.所以什么时候该优化,什么时候别管?
useCallback 和 useMemouseMemo 和 useCallback 的需求。useMemo 和 useCallback 在某些场景下仍然有用,比如你需要精确控制 Effect 的依赖。6. 最后一句话
React.memo** 就不再是装饰性的性能代码,而是真正在干活。**
谁用过京东云亚瑟 64g 刷 openwrt 安装小猫咪使用 TUN 全局模式吗?能稳定正常运行吗?速度不会受到影响吧?