即刻App年轻人的同好社区
下载
到底什么场景是需要 jev 这种高频，实时，决策，人类互动的？
最近抖音热门歌曲+动漫剪辑看的比较多，这种 mad，以及漫剧宣发这种有大量的 ai 素材，可能要从近万个镜头中去寻找，并拼接在一起，每个寻找还需要一系列决策，是否插入这个，是否去掉原声，是否添加特效，转场等。
于是做了个尝试：
让 类jev的模型（本地gemma4魔改版）去驱动剪辑，根据前面镜头和故事线的上下文来从6000+镜头在5090上以80~500ms（取决于传入多少图片）决策出下一个镜头，并以合适的方式插入进来踩点。
用简单的打标测试效果还可以（人工审查其实有的标识不太好），后续通过优化打标清洗准备镜头的精度，选择/微调更有节奏理解的多模态决策模型，效果可预见的会更好。
以及在单纯的素材检索和召回场景，因为有上下文的传入，可以对于“凸出晓美焰守护的决心”这种抽象的情绪场景，决策出在rag排序中靠后，但是更贴合前面镜头的片段。
挑选了魔法少女小圆作为例子，gemini3.8flash对用户输入和音频进行故事线的理解编写，然后 jev 和rag配合执行66个问题的三轮决策去判断6000+镜头使用哪个，怎么样插入，不断往后。
哈基米幻觉还是有点多，再改改harness发出来
最近抖音热门歌曲+动漫剪辑看的比较多，这种 mad，以及漫剧宣发这种有大量的 ai 素材，可能要从近万个镜头中去寻找，并拼接在一起，每个寻找还需要一系列决策，是否插入这个，是否去掉原声，是否添加特效，转场等。
于是做了个尝试：
让 类jev的模型（本地gemma4魔改版）去驱动剪辑，根据前面镜头和故事线的上下文来从6000+镜头在5090上以80~500ms（取决于传入多少图片）决策出下一个镜头，并以合适的方式插入进来踩点。
用简单的打标测试效果还可以（人工审查其实有的标识不太好），后续通过优化打标清洗准备镜头的精度，选择/微调更有节奏理解的多模态决策模型，效果可预见的会更好。
以及在单纯的素材检索和召回场景，因为有上下文的传入，可以对于“凸出晓美焰守护的决心”这种抽象的情绪场景，决策出在rag排序中靠后，但是更贴合前面镜头的片段。
挑选了魔法少女小圆作为例子，gemini3.8flash对用户输入和音频进行故事线的理解编写，然后 jev 和rag配合执行66个问题的三轮决策去判断6000+镜头使用哪个，怎么样插入，不断往后。
哈基米幻觉还是有点多，再改改harness发出来
00:15
3 10
把上一个项目的部分工作交代给新人
掰着手指头数
“你需要在做 a 的同时去看 b 和 c，以及别人需要你的时候要配合去做 d，别人做完后把他们的项目按照 e 的规范整理，以及时刻思考 f 并搓出来”
掰着手指头数
“你需要在做 a 的同时去看 b 和 c，以及别人需要你的时候要配合去做 d，别人做完后把他们的项目按照 e 的规范整理，以及时刻思考 f 并搓出来”
2 20
用 cursor，codex 时候期望的，一个怎样的屏幕布局可以最舒适的把人类要看到的信息排布出来，最好还能留出来一个打游戏的空间🤞
1. 核心痛点：被束缚在“单窗口”逻辑下的 AI 协作
目前的 Vibe Coding 工具（无论是 IDE 类的 Cursor，还是终端类的 Cloud Code / Cline）在多屏幕与多设备支持上存在明显的断层：
• 状态同步的缺失： 虽然可以多开终端或窗口，但它们之间缺乏原生的逻辑关联。
• 布局逻辑的僵化： 即使 Cursor 允许分离 Agent 窗口，但在切换模式（如新建 Agent 或进入 Compose）时，布局往往会自动重置，无法持久化在副屏上。
• 跨设备场景的断裂： 当开发者从工位转移到沙发或厨房时，对于移动端的期望比起一个完整的运行态，或 im 聊天的转发态，更需要的是一个在主力工作端上运行和同步的简化窗口
2. 理想的“分布式”工作流方案
我们不需要每个设备都运行全功能的 IDE，而是需要根据设备形态进行信息的高效重组：
• 垂直副屏（左）：信息流中心
• 全屏呈现长上下文的 AI 聊天记录。
• AI 思考过程的逻辑链展示。
• 主屏幕（中）：demo 区/plan，文档区
• 全屏的 Demo 预览页面。
• 实时更新的错误日志（Console）与性能监控指标。
• 移动端（iPad/手机）：伴随式终端
• 当前状态看板： 展示最新的构建进度和 UI 快照。
• 极简输入框： 当你离开工位时，可以通过 iPad 进行自然语言指令的补充输入，远程操控 AI 的下一步动作，不通过云端，转发，而是落座后的上下文 session 这些都是通用的
1. 核心痛点：被束缚在“单窗口”逻辑下的 AI 协作
目前的 Vibe Coding 工具（无论是 IDE 类的 Cursor，还是终端类的 Cloud Code / Cline）在多屏幕与多设备支持上存在明显的断层：
• 状态同步的缺失： 虽然可以多开终端或窗口，但它们之间缺乏原生的逻辑关联。
• 布局逻辑的僵化： 即使 Cursor 允许分离 Agent 窗口，但在切换模式（如新建 Agent 或进入 Compose）时，布局往往会自动重置，无法持久化在副屏上。
• 跨设备场景的断裂： 当开发者从工位转移到沙发或厨房时，对于移动端的期望比起一个完整的运行态，或 im 聊天的转发态，更需要的是一个在主力工作端上运行和同步的简化窗口
2. 理想的“分布式”工作流方案
我们不需要每个设备都运行全功能的 IDE，而是需要根据设备形态进行信息的高效重组：
• 垂直副屏（左）：信息流中心
• 全屏呈现长上下文的 AI 聊天记录。
• AI 思考过程的逻辑链展示。
• 主屏幕（中）：demo 区/plan，文档区
• 全屏的 Demo 预览页面。
• 实时更新的错误日志（Console）与性能监控指标。
• 移动端（iPad/手机）：伴随式终端
• 当前状态看板： 展示最新的构建进度和 UI 快照。
• 极简输入框： 当你离开工位时，可以通过 iPad 进行自然语言指令的补充输入，远程操控 AI 的下一步动作，不通过云端，转发，而是落座后的上下文 session 这些都是通用的
1 00
【给杀戮尖塔2的商人接入了AI，乞讨流上线！-哔哩哔哩】 b23.tv
时辰sc: 前天做的杀戮尖塔 2aimod，意外的好多人看
1 00
【给杀戮尖塔2的怪物接入了 AI，这下启动不了可以下跪求饶了！-哔哩哔哩】 b23.tv
时辰sc: 前天做的杀戮尖塔 2aimod，意外的好多人看
0 00
两个 agent 通过 hooks 双向奔赴，比一个 agent 去查另一个 agent 的数据要省很多很多 token，也比 acp ，a2a 这些互操作协议要更轻量，毕竟大部分场景下一个规范的数据产出+各自的对应上文，就能满足了，对于需要 token 计费的产品，不如把主动循环拆成异步的触发式
时辰sc: 给 Agent 用的软件除了通过 skill 让 agent 主动去查询，还有种办法是给关键环节多暴露一些 hooks 在各个时候去 call 尤其是在“记录人类做了什么”，“通知 AI 做了什么”上面
7 01