[推广] 跟风搞了一个视频站
https://migosvideo.org ，最近加了哥飞新词群 感觉域名注册的一般，应该注册一个更大的需求词，比如双人说唱之类的，不过主要是用来练手了，用了 3 天，其中 1 天都在搞视频模型，最后选择了 seedance ，希望大家能提点意见。
via V2EX (author: nickenabler)
https://migosvideo.org ，最近加了哥飞新词群 感觉域名注册的一般，应该注册一个更大的需求词，比如双人说唱之类的，不过主要是用来练手了，用了 3 天，其中 1 天都在搞视频模型，最后选择了 seedance ，希望大家能提点意见。
via V2EX (author: nickenabler)
[分享创造] 用 Agent 写了一个博客网站（基础功能比较完善博客/域名/项目/相册/友链）
----------------------
----------------------
via V2EX (author: coffees)
● https://evan.top/
----------------------
----------------------
● https://evan.top/
via V2EX (author: coffees)
[求职] 后端工程师求职
个人背景：
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=
via V2EX (author: zdking08135)
个人背景：
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=
via V2EX (author: zdking08135)
[分享创造] 把 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 ？
via V2EX (author: Taylor77)
上次做 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 ？
via V2EX (author: Taylor77)
[推广] 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
via V2EX (author: maybe0410)
给自己的站做个介绍，也把我们观察模型状态的方式公开一下。
用 GPT 做开发，我比较在意降智问题。模型一旦漏掉关键约束、误判业务逻辑，后面就需要反复解释、重跑和检查。尤其是回答写得很完整，错误却藏在细节里，发现得晚，返工会更费时间。选中转时，输出质量值得和价格一起看。
跃点 AI 最低提供 0.1 倍率，主推 0.2 倍率稳定分组。我们通过探针检测、自动分组和定时鹈鹕绘图测试，持续观察模型状态和输出质量。
测试任务是用 HTML 和 SVG 做出“鹈鹕在月球上骑自行车”的二维动画。现在作品已经放到官网首页，免登录可查看动画、模型、生成时间、耗时和源代码，每分钟自动同步最新结果。
单个绘图任务不能代表模型全部能力，但公开连续作品，可以让大家多一个观察和比较的依据。
Claude 提供 1x 倍率的老官号渠道，非 Kiro 类渠道，额度有限，先到先得。站内也已开放邀新返利活动，具体比例和条件以活动页面为准。
访问跃点 AI https://mxwq.net/
免登录查看鹈鹕测试作品 https://mxwq.net/#pelican-showcase
via V2EX (author: maybe0410)
[分享创造] AI 时代，创造力爆发的你可以用这个工具来邀请别人体验你的应用了
AI 时代，大家创造力爆棚，很多点子能够快速落地和验证，这个时候你可能想要邀请一批朋友体验你的 App ，于是你开始生成并分发你的邀请码/Key.
但是，你发现你的帖子下大家需要频繁回复你：XXX 已使用/已领取，后续任意一个朋友领取时需要跳过已领取的 XXX ；同时，你作为开发者无法知道那些被领取，也无法统计。
那么来试试我这个免费的工具吧： https://invite.buhuipao.com/
支持三种形式的领取：
1. 直接输入 Key
2. 户用留下邮箱接收 Key
3. 你留下自己邮箱，接收用户填入的邮箱，你后台修改用户的订阅
你可以在后台看到大家的领取情况。
如果你对这个工具有什么想法和建议，欢迎评论提 或者 support@buhuipao.com (
via V2EX (author: buhuipao)
AI 时代，大家创造力爆棚，很多点子能够快速落地和验证，这个时候你可能想要邀请一批朋友体验你的 App ，于是你开始生成并分发你的邀请码/Key.
但是，你发现你的帖子下大家需要频繁回复你：XXX 已使用/已领取，后续任意一个朋友领取时需要跳过已领取的 XXX ；同时，你作为开发者无法知道那些被领取，也无法统计。
那么来试试我这个免费的工具吧： https://invite.buhuipao.com/
支持三种形式的领取：
1. 直接输入 Key
2. 户用留下邮箱接收 Key
3. 你留下自己邮箱，接收用户填入的邮箱，你后台修改用户的订阅
你可以在后台看到大家的领取情况。
如果你对这个工具有什么想法和建议，欢迎评论提 或者 support@buhuipao.com (
mailto:support@buhuipao.com) 联系我。via V2EX (author: buhuipao)
[问与答] 如何评价懂车帝测试过程中 3 台尊界 V800 刹车踏板支架断裂？
https://www.zhihu.com/question/2091438763624882365/answer/2091458220216922824?utm_campaign=shareopn&utm_content=group2_Answer&utm_medium=social&utm_psn=2091556062822454068&utm_source=wechat_session
via V2EX (author: atonganan)
https://www.zhihu.com/question/2091438763624882365/answer/2091458220216922824?utm_campaign=shareopn&utm_content=group2_Answer&utm_medium=social&utm_psn=2091556062822454068&utm_source=wechat_session
via V2EX (author: atonganan)
[奇思妙想] [开源需求收集] 一个轻量级的专供于小团队的订阅 / API 共享的 API 网关
国庆节前在 v 站分享了自己的开源项目： https://v2ex.com/t/1245399
假日内修了一些小 bug ，然后死活想不出有什么需求可以做了
求各位 v 友给这个项目一些建议
via V2EX (author: murongxdb)
国庆节前在 v 站分享了自己的开源项目： https://v2ex.com/t/1245399
假日内修了一些小 bug ，然后死活想不出有什么需求可以做了
求各位 v 友给这个项目一些建议
via V2EX (author: murongxdb)