返回首页

一周热榜

1作者: analogwatcher4 天前原帖
大家好, 我在这个领域关注了很长一段时间的帖子,非常感谢大家分享的信息。 我是一名中级软件工程师(大约有4年工作经验),我之所以选择这个行业,是因为我喜欢解决问题,并希望以我微薄的力量产生影响。最近我刚刚走出一个糟糕的办公室政治局面,这让我感觉自己在职业发展上退步了不少。随着人工智能的进步以及各种论坛上关于软件工程师职位即将消失的悲观言论,我想寻求一些建议,同时也希望分享我的经历,寻找前进的方向。 我的经历让我对这个角色有些失望,我感到困惑,因为一些个人因素限制了我在当前地点跳槽的可能性。在进入这个行业之前,我通过课程接触过一些机器学习的知识,并试图在日常工作中融入这些工具,以保持与时俱进。但此刻,我感觉如果需要转变的机会正在迅速减少。我正在考虑以下几个方面: 1) 转向一个新的问题领域:虽然我已经走出了之前的困境,但在这个新领域工作一段时间后,感觉有些乏味。我在想是否应该转变方向,以及适合的时间是什么时候。 2) 是否应该全力以赴投身于人工智能,进行职业转型?这可能意味着在当前限制下需要更换工作地点。 3) 稳住,不做太多改变。 我知道我可能比一些其他人处境要好,但这件事似乎一直在我心头萦绕,让我感到自己没有发挥出应有的影响力。非常感谢大家的回复!
1作者: lobito254 天前原帖
我们在一个包含10,000行代码的Python代码库上尝试了Claude Code,以解决一个Codex和Gemini都无法解决的bug。Claude第一次就修复了这个问题,这让我们非常高兴。 然后我们请求了一些小改进,但在第二个提示的过程中就达到了专业版的使用限制。有没有其他人遇到过这么快就触发限制的情况?有什么避免这种情况的建议,还是说这是正常现象?
1作者: howardV4 天前原帖
嗨,HN,我们刚刚在FreyaVideo上发布了Wan 2.6。 Wan 2.6新增了两个工作流程: - 图像转视频(I2V):上传一张图片,描述动作,生成MP4视频。 - 文本转视频(T2V):直接从提示生成视频。 包含的内容: - 时长选项:5秒 / 10秒 / 15秒 - 多种输出尺寸(例如,720p / 1080p,竖屏 / 横屏,取决于模式) - 可选的提示扩展 + 多镜头分割 - 输出格式为MP4 如果你尝试使用,欢迎反馈以下内容: - 提示:哪些类型的提示能为你产生最一致的动作? - 质量与速度的权衡:哪些预设 / 尺寸感觉最好? - 用户界面 / 控件:在T2V和I2V之间有没有让你感到困惑的地方? 链接: [https://freyavideo.com](https://freyavideo.com)(Wan 2.6页面:[https://freyavideo.com/video-models/wan-2-6](https://freyavideo.com/video-models/wan-2-6)) 如果有关于实现、定价 / 额度或模型设置的任何问题,我很乐意回答。
1作者: blas04 天前原帖
我杀死了我的“宝宝”,这是我做过的最好的决定。 只有几千人看到了我的CAM帖子,关于10,000行的语义记忆接口、嵌入和知识图谱以及Claude的钩子。 经过大约一周的使用,我发现: - 它有效 - 速度慢 实际上发生了什么: 我花了一些时间构建这个复杂的记忆基础设施。向量数据库、SQLite、语义搜索、自动摄取管道、关系图,所有的一切。 结果是有效的!Claude记住了东西!问题解决了,对吧? 可是…… 每个会话启动都需要4秒以上。试着同时运行6个ghostty会话,填充的上下文窗口相当大。我基本上是在看Claude的“纰漏”(也就是占用我的内存)。 我为让Claude更“高效”而构建的东西反而让Claude变得更慢。 于是我想: “我是围绕Claude的局限性进行工程设计,还是与它合作?” 重构: 把所有东西都扔掉,重新开始。 新堆栈: - 两个bash脚本 - 全局/项目CLAUDE.md文件 - Claude代码钩子 - 就这些 会话开始 → 从Markdown加载上下文 会话结束 → 状态保存到Markdown 没有API调用,没有数据库,没有依赖。 总共1500行。 洞察: 代理不需要复杂的记忆基础设施。 它们需要一个持久的层,要求: - 简单到值得信任 - 轻便到可以忽略 - 强大到能够持久 结果发现,CLAUDE.md文件 + bash脚本 + 钩子可以完成10,000行怪物所做的一切,只是……更简洁、更快速且更易维护。 哲学转变: 我停止了试图围绕Claude的局限性构建,而是开始利用Claude的优势。 原始系统是我试图聪明并尝试新奇(谢谢多动症)。 “Claude没有记忆?那我就构建一个完整的数据库!” 新系统是我聪明的表现。 “Claude可以读取Markdown,而bash速度快得惊人。那我们就用这个。” 更少的基础设施 = 更少的瓶颈 = 更多的窗口 = 更高的速度。 未割断的记忆: 我称之为这个。 同样的问题解决方案,代码减少93%。速度快10倍,实际上是可维护的。 有时候,解决方案是减法而不是加法。 有时候,你的10,000行“解决方案”只是因为你有能力而过度设计。 --- 总结 - 我重写了整个Claude记忆系统。从10,000行数据库减少到1,500行Markdown文件。现在瞬间启动。可以无延迟地运行6个窗口。学到了简单总是胜过聪明。 链接到原始的分割线程:[https://www.reddit.com/r/ClaudeAI/comments/1phtii5/unsevering_claude_to_my_codebase_achieving/](https://www.reddit.com/r/ClaudeAI/comments/1phtii5/unsevering_claude_to_my_codebase_achieving/) 如果你想看看我们是如何到达这里的。 链接到Git仓库:[https://github.com/blas0/UnseveredMemory](https://github.com/blas0/UnseveredMemory)