Andy Stewart
1个月前
给你们讲一个懒猫相册开发者的故事吧 时间拉到2022年,那时候公司入职了一个小伙子 擅长写Vue和玩Linux,小伙子平时不太喜欢说话,所以第一个月就没有怎么管。那时候我们正在测试硬件模具,看了小伙子写代码能力还可以,我说开发相册App吧,然后我就去深圳了。 过了半个月回来的时候,问进度,同事说小伙子骑自行车摔了一跤,把手臂摔断了。哎呀,怎么这么不小心啊 等小伙子手好了,就继续开始写相册,第一版懒猫相册写出来的时候被我狠狠的喷了。我说用户有可能有30万张图片,你们怎么用传统的Web控件就开始写了?浏览器的原理,如果超过2000个DOM元素,像Vue和React这种响应式前端框架,光首次layout计算都需要很长时间,而且你们为了上传去重,居然每个相册都用md5计算?你们知道万一用户手里是一个红米那样的渣渣手机呢?图片还没有上传,手机的电都被你们暴力算md5算没电了 那天我这个商务真的对研发的同学好一顿教育啊,哎,教育是教育,等消了气,我又给全体前端开发做了一次前端技术培训。 培训的内容主要讲解动画的原理,怎么通过自绘、逐帧曲线变化,来欺骗用户的视觉,形成流畅的自绘控件。自绘控件的原理就是通过画布绘制,把相册这种几十万的对象的场景,从传统的DOM指数性能消耗,减少为单屏的常量绘制。因为像相册这样,你是不可能把几十万的对象都弄成DOM的,而且Vue/React这种动态属性绑定的设计,尤其耗费性能,几十万对象一上去,layout非常耗时(白屏),任何操作都会让浏览器性能榨干,甚至内存过爆卡死。而自绘控件永远都只用绘制可视范围内的对象,现代计算机绘制任何一个屏幕的内容都是非常非常快的,只用做好动画帧分解就好了。 讲完自绘后,我又讲了为了动画流畅,我们可以适当的实现双缓冲,简而言之,就是你的绘制对象要超过用户的屏幕,这样当用户滚动的时候,屏幕外的内容已经准备好了,就不用每次滚动都需要重新绘制,减少因现绘制导致的屏幕反复闪烁。 为了让同学们听懂,我在白板上用画静态图片的方式一帧一帧的讲解,画了整整两白板,甚至还表演起来了动画的变化。 当时下课的时候,我问同学们听懂了没?大家似懂非懂的点点头。我讲完又去深圳整硬件了,因为快过年了,要赶进度,出差路上我还在想,虽然自绘控件可以解决任何超多对象的图形App性能问题,但是真的要做到极限性能,需要对图形绘制的原理、坐标的计算还有数据结构的设计都要想的非常清晰才行,要不很容易写出意大利面条的代码,无法维护。当时我还在整硬件,就那么想了想,没有对小伙子能够实现自绘抱有希望。 春节后上班第一天,相册1.0就写出来了,我当时听了非常震惊,我说怎么做到的?同事说,相册的小伙子春节一天都没回家,就在武汉吃泡面,吃了20天,一个人从零写了相册的自绘控件。 我靠,他居然没回家啊? 我用了一下新版相册,非常惊喜,看来小伙子完全懂了。新版的相册利用了自绘和双缓冲,实现30万张照片任意拖拽,0.5秒内把家中照片全部绘制到用户的手机上,使用体验非常棒,我们应该是5G云相册里面缩略图显示最快的厂商了,这完全归功于懒猫相册的开发者,从零撸的自绘控件。 你们看,一个应届毕业生,只要又决心,用心学习,死磕就可以快速成长为技术大牛! 好了,今天的故事就讲到这里了,喜欢我们创业故事的朋友,欢迎点赞、收藏、转发 喜欢我们产品的老板,欢迎购买懒猫微服,评论区打1有优惠!
Latte
1个月前
Claude 对话超出限制?终于摸透了解决办法 用 Claude 最烦的事,就是突然弹出"对话已达最大长度"。前面建立的所有上下文都没用了,又得重新解释。 这里分享三个急救办法: 方法一:让 Claude 自己总结 编辑你最后一条消息(注意是你发的,不是 Claude 的回复),让它生成对话总结: “总结这次对话的核心内容: - 问题是什么,后来怎么变化的 - 找到了哪些关键解决方案 - 我的工作习惯和偏好 - 用过的例子和项目背景 - 接下来要做什么 要详细,新对话能直接接上” 复制总结,开新对话贴进去,说明要继续做什么。新对话有完整的 20 万 token 空间。 提醒:总结会丢失细节。建议在用到七八成容量时就这么做,别等到满了再救场。 方法二:用 Artifact 重开 如果在写代码或文档,这些内容都在 artifact 里: 点 Publish → 打开链接 → 点 Customize 这样就有了全新对话,但你的内容还在。之前那些乱七八糟的探索过程不会占新空间。 方法三:搜索旧对话 Pro 版本可以在新对话里引用之前的内容: "找到我们分析用户留存率的那次对话,继续优化方案。” Claude 会搜索并提取相关内容。适合快速查资料,不适合传递复杂项目状态。 如果不想再遇到这个问题 最重要的技巧:改变迭代方式 这个能省 80% 的上下文消耗。 以前怎么做:Claude 生成内容 → 发现问题 → 让它改 → 又生成一遍 → 又发现问题 → 又让它改。 十轮下来,烧掉 25,000 多 token。因为每次都在累积:你的修改要求加上 Claude 的完整输出。 正确做法: 1. Claude 生成了内容 2. 发现问题后,编辑你的原始 prompt 3. 在 prompt 里加入修改要求 4. 保存并重新生成 这样是在替换,不是累积。传统方法每次迭代增加 6 项,编辑只增加 2 项,省掉 67%。 十次迭代,从 25,000 降到 3,000 token,减少 88%。 配置 Memory 功能 Claude 每天会自动从对话中提取记忆:你的工作习惯、技术选择、项目细节。 关键在于这些记忆不占用当前对话的空间,只在需要时才调用相关部分。 该存什么: - 回复偏好:你习惯看详细解释还是简短总结,要不要示例 - 专业背景:你的领域、常用工具、工作角色 - 项目信息:在做什么类型的项目,目标和约束条件 - 交流风格:正式还是随意,专业术语还是通俗表达 别存什么: - 经常变动的信息 - 密码等敏感数据 效果很明显。以前开新对话要花几分钟解释背景,现在直接开工,因为 Claude 已经知道你的设置。 在设置 → Memory 里可以查看和管理记忆内容。 写简洁的 Prompt,每个字都会被计数 "按钮改成蓝色" = 5 token "能不能把这个按钮组件的样式改成蓝色,不要现在的颜色" = 50+ token 信息一样,token 差 10 倍。 把 Claude 当新来的实习生,说话要清楚直接。 别说:"请帮我写一份关于项目进展的总结报告,需要包含各个部分的详细说明,确保语言专业且易于理解..." 直接说:"总结项目进展:完成了什么,遇到什么问题,下一步计划。用简单的语言" 另外,不要一次性塞给 Claude 所有信息。 分阶段加载:先让它读资料,再让它做计划,最后才开始执行。 为什么限制其实是好事 有些 AI 让你无限聊下去,听着不错,实际上质量在悄悄变差。新消息进来,旧的被挤出去。表面上对话永不停止,实际上不断遗忘早期内容。会出现自相矛盾的回复。 Claude 的做法相反:保持完整历史,到达限制时明确提示。你清楚知道发生什么,可以做出明智选择。 研究数据:在 32,000 token 时,测试的 12 个模型里有 11 个表现掉到 50% 以下。 Claude 的 20 万限制是经过验证的。在这个范围内质量稳定,并且到限制时清楚提示,让你主动决定下一步。 知道界限在哪,你才能提前规划,而不是用到崩溃才发现。