推送 V2EX 论坛贴【全部板块】
本频道： @pushv2ex
友频道： @push52pj
Channel Public Channel
V2 V2EX
@pushv2ex
- Subscribers
- 549
- Photos
- 24.2K
- Videos
- 3
- Links
- 227K
Showing posts older than #236599 · Back to latest
Older Posts 20 shown
[问与答] 感觉现在哪里都有擦边的，应该如何处理擦边信息？
无论是抖音，小红书，B 站，知乎，甚至是酷安，基本上刷两三个必有一个擦边视频。
健身的，跳舞的，cos 的，教英语的，卖衣服的。酷安想上热门，贴图里必须带一个小姐姐。
曾经有段时间，我已经练成肌肉记忆，看到就长按不喜欢。但是最近这类信息又逐渐多了起来。
每次忍不住点进去，刷完后又有深深的惭愧，面对满屏的大扔子，感觉手机都不干净了。
有没有人跟我一样，理性分析下，究竟应不应该刷这种视频，以及刷到了正确做法是什么？
无论是抖音，小红书，B 站，知乎，甚至是酷安，基本上刷两三个必有一个擦边视频。
健身的，跳舞的，cos 的，教英语的，卖衣服的。酷安想上热门，贴图里必须带一个小姐姐。
曾经有段时间，我已经练成肌肉记忆，看到就长按不喜欢。但是最近这类信息又逐渐多了起来。
每次忍不住点进去，刷完后又有深深的惭愧，面对满屏的大扔子，感觉手机都不干净了。
有没有人跟我一样，理性分析下，究竟应不应该刷这种视频，以及刷到了正确做法是什么？
[分享创造] AI 时代，创造力爆发的你可以用这个工具来邀请别人体验你的应用了
AI 时代，大家创造力爆棚，很多点子能够快速落地和验证，这个时候你可能想要邀请一批朋友体验你的 App ，于是你开始生成并分发你的邀请码/Key.
但是，你发现你的帖子下大家需要频繁回复你：XXX 已使用/已领取，后续任意一个朋友领取时需要跳过已领取的 XXX ；同时，你作为开发者无法知道那些被领取，也无法统计。
那么来试试我这个免费的工具吧： https://invite.buhuipao.com/
支持三种形式的领取：
1. 直接领取 Key
2. 户用留下邮箱接收 Key
3. 你留下自己邮箱，接收用户填入的邮箱，你后台修改用户的订阅
你可以在后台看到大家的领取情况。
如果你对这个工具有什么想法和建议，欢迎评论提 或者 support@buhuipao.com (
AI 时代，大家创造力爆棚，很多点子能够快速落地和验证，这个时候你可能想要邀请一批朋友体验你的 App ，于是你开始生成并分发你的邀请码/Key.
但是，你发现你的帖子下大家需要频繁回复你：XXX 已使用/已领取，后续任意一个朋友领取时需要跳过已领取的 XXX ；同时，你作为开发者无法知道那些被领取，也无法统计。
那么来试试我这个免费的工具吧： https://invite.buhuipao.com/
支持三种形式的领取：
1. 直接领取 Key
2. 户用留下邮箱接收 Key
3. 你留下自己邮箱，接收用户填入的邮箱，你后台修改用户的订阅
你可以在后台看到大家的领取情况。
如果你对这个工具有什么想法和建议，欢迎评论提 或者 support@buhuipao.com (
mailto:support@buhuipao.com) 联系我。[推广] GPT 降智是硬伤，自荐一下我的站，最低 0.1 倍率，主推 0.2 稳定不降智分组，公开鹈鹕测试作品，旨在为大家提供优质省心的 AI 服务!
给自己的站做个介绍，也把我们观察模型状态的方式公开一下。
用 GPT 做开发，我比较在意降智问题。模型一旦漏掉关键约束、误判业务逻辑，后面就需要反复解释、重跑和检查。尤其是回答写得很完整，错误却藏在细节里，发现得晚，返工会更费时间。选中转时，输出质量值得和价格一起看。
跃点 AI 最低提供 0.1 倍率，主推 0.2 倍率稳定分组。我们通过探针检测、自动分组和定时鹈鹕绘图测试，持续观察模型状态和输出质量。
测试任务是用 HTML 和 SVG 做出“鹈鹕在月球上骑自行车”的二维动画。现在作品已经放到官网首页，免登录可查看动画、模型、生成时间、耗时和源代码，每分钟自动同步最新结果。
单个绘图任务不能代表模型全部能力，但公开连续作品，可以让大家多一个观察和比较的依据。
Claude 提供 1x 倍率的老官号渠道，非 Kiro 类渠道，额度有限，先到先得。站内也已开放邀新返利活动，具体比例和条件以活动页面为准。
访问跃点 AI https://mxwq.net/
免登录查看鹈鹕测试作品 https://mxwq.net/#pelican-showcase
给自己的站做个介绍，也把我们观察模型状态的方式公开一下。
用 GPT 做开发，我比较在意降智问题。模型一旦漏掉关键约束、误判业务逻辑，后面就需要反复解释、重跑和检查。尤其是回答写得很完整，错误却藏在细节里，发现得晚，返工会更费时间。选中转时，输出质量值得和价格一起看。
跃点 AI 最低提供 0.1 倍率，主推 0.2 倍率稳定分组。我们通过探针检测、自动分组和定时鹈鹕绘图测试，持续观察模型状态和输出质量。
测试任务是用 HTML 和 SVG 做出“鹈鹕在月球上骑自行车”的二维动画。现在作品已经放到官网首页，免登录可查看动画、模型、生成时间、耗时和源代码，每分钟自动同步最新结果。
单个绘图任务不能代表模型全部能力，但公开连续作品，可以让大家多一个观察和比较的依据。
Claude 提供 1x 倍率的老官号渠道，非 Kiro 类渠道，额度有限，先到先得。站内也已开放邀新返利活动，具体比例和条件以活动页面为准。
访问跃点 AI https://mxwq.net/
免登录查看鹈鹕测试作品 https://mxwq.net/#pelican-showcase
[问与答] 北京地铁公交刷卡时发现用的是上海公交地铁卡，这对吗？苹果手机
如题，在北京时，手机钱包添加了北京公交卡还充了值，但是乘坐时发现 nfc 刷的是上海的卡片，好奇怪啊，俺也没听过类似新闻啊，这对吗？
如题，在北京时，手机钱包添加了北京公交卡还充了值，但是乘坐时发现 nfc 刷的是上海的卡片，好奇怪啊，俺也没听过类似新闻啊，这对吗？
[程序员] 用 TypeScript 从零重写了《仙剑奇侠传》，浏览器里能通关，还做了个可视化编辑器
做了 4 个多月的个人项目 type-pal ，发上来请大家看看。
● 试玩： https://pal.illegalscreed.cn/ （推荐电脑浏览器）
● 源码： https://github.com/IllegalCreed/type-pal
之前站里有朋友发过 sdlpal 编译成 WASM 的网页版。这个不一样：运行时是用 TS 从头写的，sdlpal 只当参考，以原版数据和行为为准。
第一阶段（ v1.0.0 ）可以从开场玩到结局：MKF 解包 + YJ_2 解压、事件字节码解释器（ 164 个 opcode ）、320×200 索引色帧缓冲、按原版重建的回合制战斗、MIDI 用 SpessaSynth 合成。试玩页左下角 ⚙ 或按反引号键，有个工具面板：小地图（ NPC/宝物定位）、战斗透视（抗性/可偷物品）、对话历史搜索、存档 JSON 导入导出、21 节点速通计时器。
第二阶段 Reforge 在做：新的内容格式 + 运行时 + React 编辑器（地图/剧情/角色/物品/战斗/资源），带引用诊断、撤销重做、编辑器内试玩和独立战斗模拟器。原版 294 个场景、223 张地图已迁移进来。编辑器还没在线部署，要 clone 下来本地跑，原版数据需按 README 自行准备；保存工程需要 Chrome/Edge 。也还有不少没收口的地方。
坦白说一句：全部代码都是 AI 编程 Agent 生成的，我没有手写代码，负责的是产品判断、定优先级、裁决分歧和验收。二十多万行代码靠门禁兜底：19,597 个测试、行覆盖率 91.3%、lint 零警告、新旧双引擎 E2E 对比。协作规则写在仓库的 AGENTS.md 里，有兴趣可以聊。
非官方同人/学习项目，与大宇资讯、软星科技等版权方无关，名称、美术、音乐、剧情的权利归权利人所有。试玩站用的是从原版游戏提取的资源，仅供学习交流，如有侵权接到通知立即下架。请支持正版。
想听听大家的意见：编辑器和内容格式的设计、和原版不一致的 bug 、或者觉得哪里没必要做，都欢迎直说。
做了 4 个多月的个人项目 type-pal ，发上来请大家看看。
● 试玩： https://pal.illegalscreed.cn/ （推荐电脑浏览器）
● 源码： https://github.com/IllegalCreed/type-pal
之前站里有朋友发过 sdlpal 编译成 WASM 的网页版。这个不一样：运行时是用 TS 从头写的，sdlpal 只当参考，以原版数据和行为为准。
第一阶段（ v1.0.0 ）可以从开场玩到结局：MKF 解包 + YJ_2 解压、事件字节码解释器（ 164 个 opcode ）、320×200 索引色帧缓冲、按原版重建的回合制战斗、MIDI 用 SpessaSynth 合成。试玩页左下角 ⚙ 或按反引号键，有个工具面板：小地图（ NPC/宝物定位）、战斗透视（抗性/可偷物品）、对话历史搜索、存档 JSON 导入导出、21 节点速通计时器。
第二阶段 Reforge 在做：新的内容格式 + 运行时 + React 编辑器（地图/剧情/角色/物品/战斗/资源），带引用诊断、撤销重做、编辑器内试玩和独立战斗模拟器。原版 294 个场景、223 张地图已迁移进来。编辑器还没在线部署，要 clone 下来本地跑，原版数据需按 README 自行准备；保存工程需要 Chrome/Edge 。也还有不少没收口的地方。
坦白说一句：全部代码都是 AI 编程 Agent 生成的，我没有手写代码，负责的是产品判断、定优先级、裁决分歧和验收。二十多万行代码靠门禁兜底：19,597 个测试、行覆盖率 91.3%、lint 零警告、新旧双引擎 E2E 对比。协作规则写在仓库的 AGENTS.md 里，有兴趣可以聊。
非官方同人/学习项目，与大宇资讯、软星科技等版权方无关，名称、美术、音乐、剧情的权利归权利人所有。试玩站用的是从原版游戏提取的资源，仅供学习交流，如有侵权接到通知立即下架。请支持正版。
想听听大家的意见：编辑器和内容格式的设计、和原版不一致的 bug 、或者觉得哪里没必要做，都欢迎直说。
[分享创造] 把 Jev 接进 AI 日程助手做了 48 组对照，结果反而变差了
上次做 Jev AI Playground 时，我一直在想一个问题： Jev 这种 decision model 真正接进 Agent 后，能不能减少 LLM 在信息不确定时擅自做决定？ 后来我把它接进了一个 AI 日程助手，专门做了一轮对照实验。 一个典型场景： “我 8:00 就到单位，具体讨论时间看您方便即可。”
这里 8:00 是到单位的时间，不是双方已经确定的会议时间。 我测试了三个 workflow： A：现有流程 原来的 time guard + LLM 。 B：改善上下文 不加 Jev ，只解决原流程中过早切割上下文的问题。 C：B + Jev 在 B 后增加 Jev ，进一步判断 action 、time role 、time of day 、relation 、date basis 。 48 个独立 case family 的结果： Workflow Exact match Action match A：现有流程 42/48 42/48 B：改善 context 46/48 46/48 C：B + Jev 38/48 39/48
结果和我最初的预期相反：改善原 LLM 的 context ，比增加 Jev decision layer 效果更好。 在 24 个 holdout case 里，B 是 23/24 ，B + Jev 是 17/24 。这次集成中，Jev 没有修正 B 的错误，反而在 B 原本匹配的 case 中增加了 8 个 mismatch 。 粘贴的 Markdown (1) 复盘以后，我觉得问题不应该简单归结成“Jev 有没有用”。 我们这次 C 一次让 Jev 判断了 action 、时间角色、时段、relation 、date basis 等多个东西，而且直接采用这些判断，没有做 calibrated abstention / fallback 。这实际上是一个耦合比较重的 integration 。 粘贴的 Markdown (1) 如果再做下一轮，我会先把 decision 缩得非常窄，比如只问： “这段消息是否明确确定了双方约定的会议开始时间？”
而不是再让第二个模型重新判断整个 Agent 应该做什么。 另外多一层模型确实也增加了 latency：
● Better context：p50 4.32s / p95 7.54s
● Better context + Jev：p50 5.20s / p95 8.43s 所以目前我的实践结论更接近： 先把 evidence / context flow 做对，再判断 Agent 里是否真的存在一个足够窄、值得交给 decision model 的判断点。 完整实验、失败案例、成本、延迟和下一步准备怎么测，我都整理在这里： Does Jev Improve an AI Scheduling Agent? A Three-Arm Test https://tryjevai.com/blog/jev-ai-agent-scheduling-test 想听听也在做 Agent / Workflow 的人的经验： 你们处理“信息其实不够，但 LLM 已经准备执行”的情况，一般是 prompt 、rule/validator ，还是单独增加 decision model ？
上次做 Jev AI Playground 时，我一直在想一个问题： Jev 这种 decision model 真正接进 Agent 后，能不能减少 LLM 在信息不确定时擅自做决定？ 后来我把它接进了一个 AI 日程助手，专门做了一轮对照实验。 一个典型场景： “我 8:00 就到单位，具体讨论时间看您方便即可。”
这里 8:00 是到单位的时间，不是双方已经确定的会议时间。 我测试了三个 workflow： A：现有流程 原来的 time guard + LLM 。 B：改善上下文 不加 Jev ，只解决原流程中过早切割上下文的问题。 C：B + Jev 在 B 后增加 Jev ，进一步判断 action 、time role 、time of day 、relation 、date basis 。 48 个独立 case family 的结果： Workflow Exact match Action match A：现有流程 42/48 42/48 B：改善 context 46/48 46/48 C：B + Jev 38/48 39/48
结果和我最初的预期相反：改善原 LLM 的 context ，比增加 Jev decision layer 效果更好。 在 24 个 holdout case 里，B 是 23/24 ，B + Jev 是 17/24 。这次集成中，Jev 没有修正 B 的错误，反而在 B 原本匹配的 case 中增加了 8 个 mismatch 。 粘贴的 Markdown (1) 复盘以后，我觉得问题不应该简单归结成“Jev 有没有用”。 我们这次 C 一次让 Jev 判断了 action 、时间角色、时段、relation 、date basis 等多个东西，而且直接采用这些判断，没有做 calibrated abstention / fallback 。这实际上是一个耦合比较重的 integration 。 粘贴的 Markdown (1) 如果再做下一轮，我会先把 decision 缩得非常窄，比如只问： “这段消息是否明确确定了双方约定的会议开始时间？”
而不是再让第二个模型重新判断整个 Agent 应该做什么。 另外多一层模型确实也增加了 latency：
● Better context：p50 4.32s / p95 7.54s
● Better context + Jev：p50 5.20s / p95 8.43s 所以目前我的实践结论更接近： 先把 evidence / context flow 做对，再判断 Agent 里是否真的存在一个足够窄、值得交给 decision model 的判断点。 完整实验、失败案例、成本、延迟和下一步准备怎么测，我都整理在这里： Does Jev Improve an AI Scheduling Agent? A Three-Arm Test https://tryjevai.com/blog/jev-ai-agent-scheduling-test 想听听也在做 Agent / Workflow 的人的经验： 你们处理“信息其实不够，但 LLM 已经准备执行”的情况，一般是 prompt 、rule/validator ，还是单独增加 decision model ？
[求职] 后端工程师求职
个人背景：
base 地首选广州/深圳。
男，排名靠前的 985 本硕，计算机专业，工作 11+年。（我之前的帖子有一些内容）
期望就业方向：后端业务系统，偏底层的基础系统的研发工作。具体业务不限（ web3 和量化不考虑）
履历：
在本公司之前，在 3 家厂子工作过，平均每家 3 年左右。在这家公司 2.5 年不到。
技术能力：
从业 10 几年来，一直做后端系统，做过游戏/IM/数据存储/Agent ，后两者是从 0 到 1 开发的。
golang/java/cpp 都比较熟悉，都做过线上业务，Python 也可以。
后端的各类组件：redis/MySQL/Zookeeper/Kafka/Docker/k8s 这些组件的技术原理也都了解。
自己也利用 AI 写过一些前端（个人应用，非线上业务），做全栈也 OK 。
有虚线管理经历，但个人更喜欢钻研技术和业务，不追求做管理。
wechat：emRraW5nMDgxMzU=
个人背景：
base 地首选广州/深圳。
男，排名靠前的 985 本硕，计算机专业，工作 11+年。（我之前的帖子有一些内容）
期望就业方向：后端业务系统，偏底层的基础系统的研发工作。具体业务不限（ web3 和量化不考虑）
履历：
在本公司之前，在 3 家厂子工作过，平均每家 3 年左右。在这家公司 2.5 年不到。
技术能力：
从业 10 几年来，一直做后端系统，做过游戏/IM/数据存储/Agent ，后两者是从 0 到 1 开发的。
golang/java/cpp 都比较熟悉，都做过线上业务，Python 也可以。
后端的各类组件：redis/MySQL/Zookeeper/Kafka/Docker/k8s 这些组件的技术原理也都了解。
自己也利用 AI 写过一些前端（个人应用，非线上业务），做全栈也 OK 。
有虚线管理经历，但个人更喜欢钻研技术和业务，不追求做管理。
wechat：emRraW5nMDgxMzU=
[分享创造] 用 Agent 写了一个博客网站（基础功能比较完善博客/域名/项目/相册/友链）
----------------------
----------------------
● https://evan.top/
----------------------
----------------------
● https://evan.top/
[推广] 跟风搞了一个视频站
https://migosvideo.org ，最近加了哥飞新词群 感觉域名注册的一般，应该注册一个更大的需求词，比如双人说唱之类的，不过主要是用来练手了，用了 3 天，其中 1 天都在搞视频模型，最后选择了 seedance ，希望大家能提点意见。
https://migosvideo.org ，最近加了哥飞新词群 感觉域名注册的一般，应该注册一个更大的需求词，比如双人说唱之类的，不过主要是用来练手了，用了 3 天，其中 1 天都在搞视频模型，最后选择了 seedance ，希望大家能提点意见。
[推广] AIKey365 给 V2EX 送 20 份体验额度，每人 ¥15
大家好，AIKey365 面向开发者提供多模型 API 接入。这次给 V2EX 准备 20 个名额，每人赠送 ¥15 站内余额（人民币余额单位，不是美元）。
目前支持的接口与工具：
- OpenAI-compatible API （ Chat Completions / Responses ），API Base URL： https://aikey365.com/v1
- Anthropic Messages API ，可用于 Claude Code 接入
- Gemini 原生 Gemini v1beta API
Claude Code 与 Gemini 的接入参数、可用模型列表见文档： https://aikey365.com/docs/
服务地址： https://aikey365.com
领取方式：注册 AIKey365 后，在本帖评论区留下你的 AIKey365 用户名，我会按评论顺序人工发放 ¥15 站内余额，20 个名额发完即止。
请不要在评论区发送 API Key 。
大家好，AIKey365 面向开发者提供多模型 API 接入。这次给 V2EX 准备 20 个名额，每人赠送 ¥15 站内余额（人民币余额单位，不是美元）。
目前支持的接口与工具：
- OpenAI-compatible API （ Chat Completions / Responses ），API Base URL： https://aikey365.com/v1
- Anthropic Messages API ，可用于 Claude Code 接入
- Gemini 原生 Gemini v1beta API
Claude Code 与 Gemini 的接入参数、可用模型列表见文档： https://aikey365.com/docs/
服务地址： https://aikey365.com
领取方式：注册 AIKey365 后，在本帖评论区留下你的 AIKey365 用户名，我会按评论顺序人工发放 ¥15 站内余额，20 个名额发完即止。
请不要在评论区发送 API Key 。
[程序员] 用 codex 搓了个僵尸抓牛来
闲来无事，想着看看用 AI 搞个 threejs 玩玩，看看能做到哪种程度，可惜野原新之助模型一直搞不好，只有一个小白。摸鱼的小伙伴有兴趣可以玩玩
github 地址： https://github.com/yzy9527/summer-roam.git
闲来无事，想着看看用 AI 搞个 threejs 玩玩，看看能做到哪种程度，可惜野原新之助模型一直搞不好，只有一个小白。摸鱼的小伙伴有兴趣可以玩玩
github 地址： https://github.com/yzy9527/summer-roam.git