30+程序员如何不被小事击垮
引言
老张最近有一个重点项目在推进，他准备今天回家加班赶赶进度。
可到家之后，发现孩子发烧了，由于妻子出差，他赶紧放下手头的事情，抱起带孩子往医院跑。
堵车、吃饭、挂号、排队，一路折腾下来，已经九点了。
可就是这个点，儿科急诊仍是人山人海。孩子好奇的问东问西，手机里还不断跳出加急的消息，老张焦急的不断盘算着还有多久能排到他们。
马上到老张了，突然有一个人抱着孩子挤进了医生房间，老张愣了一下，火一下子就上来了，冲进屋子和对方吵了起来......
幸运的是孩子没什么事，可老张熬了一晚上啥也没干成。第二天上班状态不好，和业务方沟通时及其不耐烦。
下午收到了业务方的投诉，理由是态度消极。
老张一天什么也没干，却感觉自己马上就要崩溃了。
英雄就是这么被击垮的。据说是伏尔泰有句话说，“使人疲惫的不是远方的高山，而是你鞋里的一粒沙子”。
工作繁忙、孩子生病、业务方催促进度......都不是什么“重大事件”，可就是会压的你喘不过气来。
处理不好这些小麻烦，不但会影响你的情绪和工作表现，还有可能会影响我们的健康，最重要的是，如果被这些小事击垮了，我们哪还有心思去想什么大事呢？
我现在“大概”可以做到情绪稳定，我有四个自己在用的心法，分享给大家。
学会忽略
学会忽略，是我看到一句，据说是爱因斯坦说过的话：“弱者报复，强者原谅，智者忽略”。
就拿开车举例，我在路上发现过一个特别有意思的现象，如果开车的时候遇见插队，不同的司机有三种反应。
第一种人是对抗型，面对插队丝毫不让，眼看着两辆车的距离都塞不下一根手指头了，插队车决定放弃，他可能赢得了这场面子仗。
第二种人是原谅型，一开始会正常起步，但如果对方强行变道， 他会及时刹车，毕竟剐蹭了浪费时间浪费金钱。
第三种人是忽略型，他可能根本就没有在意这辆车在插队，他会直到前车完全进来，才会继续出发。他可能正沉浸在播客或者音乐里，神游在另一个维度。
你觉着哪种应对方式最好？
之前我是第二种人，并且还觉着第三种人是技术不佳，或者说是“好欺负”，直到最近我也有点了第三种人的样子。
有一次我在路上，听播客听的入迷，前方有个车有变道的意图。我也不着急，就让他变道进来了。
随后我才意识到，自己好像甚至都没有为这件事情，分散一点注意力。
那一刻我才明白，忽略，不是退让，也不用压抑情绪——
而是你根本没分配注意力分配给小事，负面情绪自然也就不会被激活。
忽略负面情绪非常有必要，有一项针对1300名男性做的研究，让他们对自己遇见类似于加塞这种小麻烦的反应打分，分数越高代表情绪反应越大。
结果发现，经常对小事有激烈反应的男性，他们的健康状况和死亡率，和面对那些重大人生压力的人一样。反应最激烈的那一组，在同样时间段内的死亡率，竟然是正常人的三倍。
我想起之前我奶奶家挂着一副《莫生气》的字画，里面有一句话：别人生气我不气，气出病来无人替。
看来对小事有激烈反应，真的会影响身心健康啊。我实践下来，忽略情绪有三个小技巧：
第一个是觉察情绪。当你发现自己心跳加快、紧握双拳，要注意情绪可能要来了。你需要深吸一口气，把注意力放到自己身上，让自己停下来，别被情绪牵着鼻子。
第二是控制自己的反应。维克多·弗兰克尔有一句话：“在面对外界刺激时，我们拥有选择如何回应的自由”。人真正能控制的只有自己的行动和态度，你控制不了堵车，但你能控制堵车的时候听一首钢琴曲。
第三是发现身边的美好，也就是感知生活中的“小确幸”。比如阳台上的花突然开了，孩子自己穿衣服了。有研究表明，对生活中积极细节的留意，能有效中和压力引发的负面情绪。
不恶意揣测
不过有些事情你很难忽略，比如公司考核政策调整，甚至说你持仓的股票大跌。
你感觉这个世界充满了恶意：公司打压你、社会在压榨你、资本在收割你。
可现实真的是这样吗？
帮助我解决心结的法则叫做「汉隆剃刀」。简单的说，它的意思就是「能解释为愚蠢的，就不要解释为恶意」。
这里说的愚蠢，代表各种无知的、偶然的、非故意的原因。这些情况发生的可能性远远大于恶意，汉隆剃刀大多数情况下反应了客观事实。
比如你开车，前方突然有车插队，你怒不可遏，心想：你是不是觉着我好欺负？
但其实他根本不认识你，只不过恰巧他意识到前方需要拐弯了。
这个法则在理解社会、组织层面，特别有效。
比如你持有的一只股票突然暴跌，你会听到一些传闻：说这是“庄家”在故意控盘。
我之前特别相信这种阴谋论，觉着股价是被人为操控的。可真实情况是，大公司的股价是很难操控的，投入很多钱也不一定能成功，一旦失败就会受到很大损失。而且市场上每个股民的互动、追涨杀跌，也会给股价造成很大影响。
再比如一家公司突然开始了绩效改革，给研发人员制定了和销售额相关的KPI，而且目标不完成还会对薪资产生影响。
可研发的考核怎么可能和销售的KPI挂钩呢？你怀疑管理层在变相降薪。
可更大的可能性是：管理层也不知道如何满足老板制定的目标，只能先套个模版应付一下。
不是你被打压了，只是碰巧他们不专业，你以为它是在有意的做坏事，但更大的可能是它没能力做好事。
我们大脑为了认知方便，常常会把一家公司或者一个政府当成一个人，假设他有自由意志，是一个决策缜密、心怀不轨的敌人。但其实组织就是一部机器而已。
不是组织在有意针对你，这世界其实就是个草台班子。
超越身份思维
你有没有经历过这种场面，过年回家刚坐下，七大姑八大姨联合开麦：
“你看你三十多了还在北京漂着，准备啥时候结婚啊？你表哥孩子都上小学了。”
“北京租房多贵啊，在咱老家，这都够还房贷了，干嘛不考个公务员安稳点？”
你努力工作、认真生活，熬过了失业焦虑、加班压力，结果成了他们口中的“混日子”。
你不是气他们说了什么，而是他们压根不懂你，却笃定地定义你。
可他们的确不懂你，也不会真正的懂你。他们只不过是在维护自己的世界观而已。
学术界有一个流行的说法是，人们的行为和观点，是由身份认同决定的。你的长辈，可能在一个小城过了一辈子，有编制、有房子、生儿育女，就是他们眼里的体面生活。
你异地漂泊、私企行业、租房未婚，就是他们眼中的“不务正业”。
你不需要反驳，也不需要忍耐。而是你明白了，你不需要从所有人眼里获得认可，你可以看到不同身份的局限性。
超越身份思维，在养育孩子的过程中特别有用。
那天我带儿子去上烘焙课，糖刚撒进面粉中，他就开始一边揉一边往嘴里塞。
我试图制止，他越发固执，并且不耐烦的喊：“我要回家！我要回家！”
我有点崩溃，一边怕他吃坏肚子，一边气他为什么这么不听话。
但那一刻我突然意识到，他不是故意气我，他只不过多想吃几口糖而已。
我们常说父母要包容孩子，为此你需要先理解他们的行为。糖果能刺激大脑释放多巴胺，这是最本能的反应，而且他们理性大脑还没有开始发育，你不能要求一个孩子有“自控力”
我们总以“大人的身份”要求孩子守规矩，可孩子的很多行为，并不是“不听话”，而是“做不到”。
就像人类的大脑，在25岁才能完全发育完成。也就是说，一个孩子即使成年之后，也会做出一些你不理解的事情。一个人成长的过程中，本就充满了能力滞后，
你不理解他，就会对抗他。你理解了，才能包容他。
找到目标
有一天我正坐在电脑前，正为了文章选题抓耳挠腮。
我儿子“砰”地一下推开门，一屁股坐在我旁边，拿着小汽车喊：“爸爸！爸爸...”
以往工作时被打断，我会特别不耐烦。可那天，我关上电脑开始陪他玩，我发现自己变得很有耐心。
过了一会他自己去客厅玩了，我坐在电脑前，去想我为什么会有这种改变。
是我变得有耐心了？还是我终于佛系了？后来我想明白了——是自己的目标更明确了。
过去一被打断就恼火，其实都是因为自己都不知道要干什么。我只是模糊的觉得，自己得做点有意义的事情。
但现在写好每一篇文章就是我想做的事情，就算短暂的停下来，也没有任何影响。
心理学上有一个「自我决定理论」：真正让人持续投入的，从来不是外界的压力或奖励，而是自己选的方向。
比如说当你在街道上跑步，周围车水马龙、喧嚣嘈杂，可你根本就听不见。因为你眼中，只有即将抵达的下一个路口。目标感就像降噪耳机，能让你不被外界打扰。
但如果你没有目标呢？虽然一天什么都没干，却很容易因为工作上的催促，家人的一句话，就能让你心烦意乱。
你不是没有承受力，你可能只是没有方向而已。
尼采说：“一个人知道自己为什么而活，就可以忍受任何一种生活。”
现在看来这不是鸡汤，而是硬道理。
真正让你内心安定的，不是时间管理、情绪技巧，而是——你有没有在朝着自己认可的方向，慢慢靠近。
说在最后
最后分享一句据说是爱默生说的一段话来结尾吧。
当整个世界似乎都在暗中图谋，用琐事一次又一次侵扰你、纠缠你，当所有人都来敲你的门，并且说，“到我们这里来吧。”绝对不要动心，不要加入到他们的喧闹中。始终保有一颗自助自主的心，不受外界影响和左右，活在自己的意志里，才能够使心灵得到宁静，才会过上真正独立的生活。
以上就是我自己应对生活中一些“小麻烦”的个人心得，如果你也有面对“小麻烦”时处理情绪的技巧，欢迎在评论区分享～
这是东东拿铁的第84篇原创文章，欢迎关注。
来源：juejin.cn/post/7522751214263992370
三年写了很多代码，也想写写自己
前言
从我进入公司开始，我给自己立了一个三年成为中级前端工程师的目标，或者说flag吧，最近正好三年合同到期了，我开始思考过去的这三年我都做了什么，是否完成了flag，所以我在个人博客中增加了一个模块《项目需求》用于管理自己在生活、工作、学习过程中开发过的项目文档和思考，在整理的过程中才发现很多东西都忘记是怎么做的了，大概是只知道做，不知道为什么做吧，所以这里想写一篇文章记录下或者说获取一些建议吧。
很多人说博客和todo没啥用，开发完几乎都不会使用，我觉得看怎么用吧，我这里把项目和todo、技术文档、技术栈绑定了。编辑项目和可以和todo绑定，我觉得还挺好使，这样在整理技术文档、技术调研的时候也可以用
过去三年我都做了什么
2022年
基本情况
因为在学校的时候根本没想过这么早出社会，原本是打算走学术路线的，结果考研那年因为家里临时出了点状况，最后决定先工作再说。现在回头看也挺好的，早点接触社会，其实成长得更快。
在这一年我主要是疯狂补项目经验和疯狂加班，因为社会始终不同于学校，排期让人很头疼，在以往我缺失了很多的项目经验，导致对企业级项目几乎不通，导致我在做任何项目都比较挣扎，再加上进的是一个小厂，完全没有导师制，属于放养，并且大家都很忙，所以只能自己多花时间，并且当时我学的vue的技术栈，但是公司是react的，光是搞懂 React 那一套生态就花了不少时间。
项目经历
- 早期主要是做企业后台 & figma插件，其中有一个插件让我特别头疼，一方面因为当时的自己比较菜，另一方面因为这个需求是一个刚毕业的设计驱动的，属于是啥也不通，导致产品逻辑也不对，写出来之后疯狂打补丁，最后也还是啥也不是。
- 后面做了设计社区，都是一些简单的ui和业务逻辑，因为是一个设计编辑器平台
- 在写了几个后台之后我逐渐熟悉了公司开发技术栈和后台开发逻辑，最早这个公司吸引我的是编辑器，后面我就申请去做了编辑器
- 最开始是编辑器的字体加载、和一些创新的业务需求、设计工具中不同模式的数据结构复用、画布设置【缩放、背景等等】、对齐至像素网格
成长
- 技术上，从 Vue 转到 React 后，逐步掌握了 React 的核心理念和生态工具，像状态管理、组件设计、性能优化这些都有了比较实战的理解；
- 项目上，能独立负责模块开发，也逐步学会了和产品、设计磨合需求；
- 心态上，从一开始觉得“自己不会”到现在敢主动挑任务、遇到新东西也不怕折腾，整体自驱力和解决问题的能力都提升了不少。
- 这时候还是需要拿着电脑到处抓人问问题，非常感谢当时给予我帮助的小伙伴
2023年
基本情况
这个阶段已经开始逐步适应工作生活了，但是还是会畏惧需求，因为还有很多没接触过的东西，依然还是疯狂加班，不光是需求，还有自己学习一些东西，这时候我已经切换到了编辑器领域，其中涉及很多图形学知识，比如坐标转换、矩阵运算、渲染原理、渲染库的使用等等，因为公司里的人几乎不写文档，代码也是anyscript，并且这时候ai还没有，编辑器这个领域，网上几乎搜不到什么文档啥的，只能生啃代码和类型文件并尝试demo，这时候用的就是最笨却最有效的方法，做到哪就把哪个模块整理一篇文档记录下来，慢慢的也就掌握了项目的大部分逻辑和架构思路
项目经历
- 设计工具中不同模式的数据结构复用，一个创新业务需求，使用同一套数据，快捷的进行模式切换，非常巨大的需求，正是因为这个需求让我学会了很多东西，开始能独立负责一个模块的开发
- 白板项目：其中做了节点数据结构定义【便签、图形文本、连接线等等】、节点树的处理、节点的渲染、项目框架搭建、画布设置、缩放、属性控制、属性工具条、性能优化等等，几乎所有功能都写了一部分，这个项目是我从0-1经历的一个项目，历时10个月，早期有很多人，后来因团队调整，部分成员转入新项目，剩余的人员就非常的少了，我是其中之一。
- 这一年我几乎都在做白板项目，其中连接线是最难的，我写了其中的一部分，还因此挨了一批，给我上了社会上的第一堂课【能力不足就得背锅】
成长
- 编辑器初步入门：理解了编辑器的基本架构 & 实现原理，如模块划分、碰撞检测、矩阵运算原理、渲染库的基本使用、复制粘贴的实现原理、svg的解析原理等等、数据节点定义、节点树的使用等等
- canvas、svg、渲染库的基本使用 & 原理
- 学到了很多调试技巧、看了很多的技术文章
- 能够独立负责一个模块的开发和推进
- 自己开始从0-1写一些项目，23年主要是一个工程化的项目，因为当时公司没有脚手架，每次创建新项目都要配置一遍，我就想写一个脚手架来用，就开始探究一些前端工程化的东西，这里主要是一个前端工程化的demo
2024年
基本情况
这时候已经对编辑器开发很熟练了，能够自己调研、处理一些模块，不会畏惧需求，拿到什么都能做也敢做，再加上ai的爆发，现在很轻松就能应付日常需求，还有一些时间开发自己的东西。这时候我几乎不用在追着别人问了，开始探究一些技术上的原理，看了react的源码，了解了react的运行原理，我最初看这个的驱动是因为我想看懂编辑器底层的数据结构和自定义渲染器的实现原理，因为是相通的。
项目经历
- 多模式切换的设计工具，在23年双模式切换有一个比较客观的数据基础上，想要开发多模式切换
- 编辑器重构：真真正正的从0-1实现编辑器，学到了非常多的东西
成长
- 这个阶段成长是最快的，在之前自己主动学习和开发过程中的积累，达到了量变到质变的过程，再加上重构过程中全是实实在在的技术类需求，这个阶段开发的非常爽，学到了非常多的东西，一度让我觉得我们也能做出一个超级nb的东西
- 对编辑器的整体实现理解更加深入，对大型项目的推进和管理有一些了解
- 对于代码质量，代码风格，团队管理，团队交流都有更深的体会
2025年
基本情况
进入新团队后，开始参与 AI 方向的生成类产品开发。虽然整体技术难度相比之前的编辑器项目要低一些，但节奏非常快，很多需求都是边想边做，对响应能力和落地能力要求更高。项目整体强调快速迭代、快速验证，很多时候从 0 到上线都只有几天时间。
项目经历
- 核心流程重构：参与整个生成流程的梳理和重构，数据结构的重设计，提升了整体稳定性和扩展性。
- AI 创新功能研发：参与多个创意方向的原型开发，包括智能组件、AI 引导式操作流程等，既需要理解前端，也需要深入 AI 接口的能力边界。
- 常规前端需求：除了核心 AI 功能，也参与大量 Web 端页面开发、交互优化、组件抽象等日常前端需求的处理。
- 跨角色协作：与产品、模型工程师保持密切沟通，协助设计 prompt、测试接口，探索“产品-模型-前端”的协作流程，理解 prompt 工程的基本逻辑。
成长
- AI 与前端的深度结合：理解 AI 接口的调用逻辑、数据结构设计、模型能力边界，并在多个场景中尝试 prompt 调优、token 限制控制、输出结构稳定性等关键问题。
- 需求落地能力提升：现在不管接到什么需求，都能独立完成从调研、设计、开发、联调到交付的完整流程，并且具备识别风险、提前发现问题并推动解决的能力。
- 项目推进与优化意识：开始更关注整体产品的合理性和可维护性，不再仅仅关注功能实现，会主动提出重构建议、设计优化点、体验提升方案。
- 应变与协作能力加强：面对快节奏、多变的需求场景，能够保持清晰的优先级判断
- 干了很多新鲜的东西，还挺好玩的，ai接入支付、ai表单等等。
我自己写的项目
就这几个，其他的几乎都是一些不成型的demo，还有几乎都在写公司的项目
- nextjs-blog：一个用nextjs写的高聚合的全栈博客，还在持续更新，有时候有点犯懒，在线访问
- handwriting_js：没事写点手写题，写了忘，忘了写，一个也记不住
- react_demo ：前端工程化demo，配合这个专栏食用最佳
- debug_react：18.2.0的react源码调试环境
- debug_webpack： webpack5源码调试环境
现在我是怎么想的
- 快速学习的能力比技术能力更值得培养
技术更新太快了，几乎每一年都会冒出一堆新概念、新框架、新工具，追是追不完的。相比“掌握某个技术”，更在意的是“有没有能力快速理解它、上手它、找到它的边界”，这是一个更本质的能力。 - 技术是为业务服务的，但我们也要有自己的判断和坚持
做久了之后会发现，代码写得好不好，有时候并不是最关键的，能不能解决问题、把事情落地才是关键。谁也不想变成“只写业务”的人——在完成需求的同时，尽可能把事情做得优雅些，至少对得起自己的审美和标准。 - 保持初心
有时候项目节奏快、需求不讲理、上线压力大，很容易被“搞完就行”的心态裹挟，还是需要保持自己的思考 - 身体是革命的本钱！！！！
24年7月份左右，体检，发现小毛病快20项，全是久坐，熬夜搞出来的小毛病，可能因为之前加班太多了，也不运动，在7-11月胖了20多斤，并且整日没精打采，身体没有力气，像是气血亏虚一样，我去看了中医，开了一些调养的中药，12月底才开始有好转，我找了私教，去健身房开始健身，大半年了现在就好多了，增肌也小成 - 培养工作之外的兴趣爱好
健身、摄影、钓鱼都可以，长时间的工作会使人麻木和疲惫，需要一些工作之外的爱好调和
我还做了一个在线相册，从大佬Innei获取到的思路，但技术栈是不一样的，也比较简单
以后我想干啥
说实话，我现在还没完全想明白这个问题。过去几年我经历了从业务开发，到编辑器、到 AI 项目，接触了很多不同的方向，也成长了不少。但也正因为尝试了很多，现在反而更谨慎，不想轻易贴标签。
我想我还是会继续写代码，但不一定只写代码。我更在意的是：“我做的东西有没有价值？有没有可能改变点什么？”也许未来会往架构方向走，也许会继续在 AI 产品方向深入，也可能有一天突然转向一个完全不同的方向，比如做点属于自己的产品。
我目前能确定的就是三件事：
- 我希望能一直保持学习和探索的状态，不断拓宽认知边界；
- 我希望在一个让我有成长、有挑战感的环境里工作；
- 我希望做的事能让我感到值得，能有一点点“留下痕迹”的感觉。
剩下的，就边走边看吧，继续更新文章，但不会跟之前一样那么频繁，从中学到东西，并且能够帮助别人
来源：juejin.cn/post/7524602914514763819
微软正式官宣开源！王炸！
最近，和往常一样在逛 GitHub Trending 热榜时，突然看到又一个非常火的开源项目冲上了 Trending 热榜，相信不少小伙伴也刷到了。
一天之内就新增数千 star，仅仅用了几天时间，star 增长曲线都快干垂直了！
再定睛一看，好家伙，这不是微软的项目么。
出于好奇，点进去看了看，没错，这正是微软自家大名鼎鼎的 WSL！
原来就在前几天的微软 Build 2025 开发者大会上，微软正式官宣开源 Windows Subsystem for Linux（WSL）。
这在微软官方的最新的开发者技术博客也可以翻到。
众所周知，WSL 是微软在 2016 年就发布的一项重磅功能，相信不少同学都用过。
WSL 全称：Windows Subsystem for Linux，它允许用户在 Windows 操作系统中直接运行 Linux 环境，而无需双系统或者虚拟机，通过兼容层支持开发者工具、命令行应用及文件系统互通，实现方便地跨平台开发与测试。
从初始发布到如今走向开源，回顾 WSL 一路走来的发展历程，可以总结为如下几个大的阶段。
- 初期兼容层探索
2016年，微软首次推出 WSL 1。
其通过兼容层工具（如 lxcore.sys 驱动）将 Linux 系统调用转换为 Windows 调用，首次实现原生运行 ELF 可执行文件。
其优势是轻量级启动，但缺点也很明显，那就是兼容性和性能都存在一定局限。
- 中期扩展与独立应用
2019年，WSL 2 正式官宣。
此时微软对其进行了彻底的重构架构，采用基于 Hyper-V 的轻量级虚拟机技术，来运行完整 Linux 内核，并显著提升了兼容性与性能，同时这也使得 WSL 能支持运行更多的 Linux 程序和应用。
2021年，WSLg 正式推出，从此便支持了 Linux GUI 应用，同时 WSL 也开始作为独立组件来发布，其从 Windows 镜像剥离，转为通过 Microsoft Store 来进行独立安装和更新。
2022年～2024年这几年时间内，微软对 WSL 进行了持续迭代，包括 systemd 服务管理支持、GPU加速、多发行版支持以及内存和文件系统等诸多性能优化。
经过中期这一阶段的发展，WSL 在兼容性、功能以及性能等方面都有了长足的进步，也为下一步的开源和社区化奠定了基础。
- 后期开源和社区化
在前几天的微软 Build 2025 开发者大会上，微软正式宣布 WSL 开源（GitHub 仓库开放），允许社区直接参与代码贡献，这也标志了 WSL 进入了开源和社区化的新阶段。
至此为止，在 WSL 的 GitHub 仓库中的 Issue #1 —— 那个自2016年起就存在的“Will this project be Open Source?”的提问，终于被标注为了“Closed”！
众所周知，WSL 其实是由一组分布式组件来组合而成的。
即：一部分是在 Windows 系统中运行，另外一部分则是在 WSL 2 虚拟机内运行。
这个从 WSL 官方给出的组件架构图中就可以很清晰地看出来：
那既然现如今微软官宣了 WSL 开源，那对于开发者来说，我们需要清晰地知道这次到底开源了哪些组件代码呢？
关于这部分，对照上图，我们这里不妨用表格的形式来简要总结一下，供大家参考。
| 组件类型 | 功能描述 | 组件名 | 开源状态 |
|---|---|---|---|
| 用户交互层 | 命令行工具 | wsl.exe | 已开源 |
| 用户交互层 | 命令行工具 | wslg.exe | 已开源 |
| 用户交互层 | 命令行工具 | wslconfig.exe | 已开源 |
| 服务管理层 | WSL服务管理 | wslservice.exe | 已开源 |
| Linux运行时 | init启动 | init | 已开源 |
| Linux运行时 | 网络服务 | gns | 已开源 |
| Linux运行时 | 端口转发 | localhost | 已开源 |
| 文件共享 | Plan9协议实现 | plan9 | 已开源 |
以上这些已开源的组件源码都可以在 WSL 的 GitHub 仓库里找到，大家感兴趣的话可以对应查看和研究。
虽然本次开源覆盖了 WSL 的绝大多数关键组件，但是官方也明确说了，以下这几个组件由于其仍然是 Windows 系统的一部分，所以目前仍然保持非开源状态，包括：
Lxcore.sys：支撑 WSL1 的内核驱动程序P9rdr.sys和p9np.dll：运行"\wsl.localhost"文件系统重定向的关键组件（从 Windows 到 Linux）
这一点需要特别注意一下。
回顾过往，其实 GitHub 上的 WSL 仓库并不是最近才有，好多年前就已经存在了。
即便在以前的 WSL 还没有开源的日子里，WSL 的背后就有了一个强大的社区在支持，开发者们通过 GitHub Issue 和 Discussion 等为 WSL 这个项目提供了诸多错误追踪、新功能建议以及意见改进。
可以说，如果没有社区贡献，WSL 永远不可能成为今天的样子。
而现如今 WSL 源代码正式开源，这也满足了开发者社区长达 9 年的期待。
开发者们现在可以自行下载、构建，甚至提交改进建议或者新功能的代码来直接参与。
同时 WSL 官方也给出了一个详细的项目贡献指南：
感兴趣的同学也可以上去学习研究一波。
好了，那以上就是那以上就是今天的内容分享，希望能对大家有所帮助，我们下篇见。
注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。
来源：juejin.cn/post/7509437413099536438
同事年底绩效是C，提离职领导死活不让走，后来领导私下说：他走了，就没人背这个绩效了
背绩效
临近年底，朋友圈和各大职场 App 都在讨论「年终奖能拿多少个月」的话题。
除了对「能拿多少个月」有广泛的讨论以外，还有不少关注点在于「年终奖何时能发」这件事上，毕竟只有真的拿到手了，才能算是钱，而不是饼。
我一直以为，在大厂年终奖这条"鄙视链"上，最差的就是那些"零年终"的小伙伴了。
实在没想到，还有高手。
比零年终更惨的，是要背绩效，同时还得面对领导"惺惺作态"的挽留：
在这位网友发的帖子中提到，自己身边有位同事去年年中的时候是 C 绩效，到了年底还是 C，通常连续得到低绩效，就会面临各种安排（砍福利、降工资 或 被换组），于是这位同事主动提了离职。
但离谱的是，领导死活不让他走，一直以「后面还有机会」这样的说辞来进行画饼。要知道，这位领导大概率是他两次 C 绩效的"贡献者"。
在其他人看来，还以为领导是真心挽留他，这位同事留在公司一定会先苦后甜。
直到后面这位领导私下和楼主说："他走了，没人背这个绩效了"。
后面楼主才恍然大悟，所谓的挽留，仅仅是为了让他分担一些不好的绩效罢了。
简短的一句话，"他走了，没人背这个绩效了"，背后却是实实在在职场霸凌。听起来像是领导的"无奈之举"，实则是领导为了应付公司指标（一定要有低绩效的组成），选择性牺牲某些同事的离谱行为。
权利在这些人手上真是可悲，那个背绩效的同事，也有自己的生活，甚至还有自己的家庭。被针对就算了，还得被耗着，被 PUA 朝着那个"有希望，但没结果（下次还是 C 绩效）"的方向去期待，最后还要反省是不是自己的问题。
新的一年，大家都能远离这些垃圾人。
对此，你有想分享的，欢迎评论区交流。
...
回归主题。
周末，继续简单小算法。
题目描述
平台：LeetCode
题号：806
我们要把给定的字符串 S 从左到右写到每一行上，每一行的最大宽度为 个单位，如果我们在写某个字母的时候会使这行超过了 个单位，那么我们应该把这个字母写到下一行。
我们给定了一个数组 widths，这个数组 代表 'a' 需要的单位， 代表 'b' 需要的单位，...， 代表 'z' 需要的单位。
现在回答两个问题：至少多少行能放下 S，以及最后一行使用的宽度是多少个单位？
将你的答案作为长度为 的整数列表返回。
示例 1:
输入:
widths = [10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]
S = "abcdefghijklmnopqrstuvwxyz"
输出: [3, 60]
解释:
所有的字符拥有相同的占用单位10。所以书写所有的26个字母，
我们需要2个整行和占用60个单位的一行。
示例 2:
输入:
widths = [4,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]
S = "bbbcccdddaaa"
输出: [2, 4]
解释:
除去字母'a'所有的字符都是相同的单位10，并且字符串 "bbbcccdddaa" 将会覆盖 9 * 10 + 2 * 4 = 98 个单位.
最后一个字母 'a' 将会被写到第二行，因为第一行只剩下2个单位了。
所以，这个答案是2行，第二行有4个单位宽度。
注:
- 字符串
S的长度在 的范围。 S只包含小写字母。widths是长度为 的数组。- 值的范围在 。
模拟
根据题意进行模拟即可。
使用变量 a 代指当前有多少行是满的，使用变量 b 代指当前填充光标所在的位置。
Java 代码：
class Solution {
public int[] numberOfLines(int[] widths, String s) {
int a = 0, b = 0;
for (char c : s.toCharArray()) {
int t = widths[c - 'a'];
if (b + t > 100 && ++a >= 0) b = t;
else b += t;
}
if (b != 0) a++;
return new int[]{a, b};
}
}
C++ 代码：
class Solution {
public:
vector<int> numberOfLines(vector<int>& widths, string s) {
int a = 0, b = 0;
for (char c : s) {
int t = widths[c - 'a'];
if (b + t > 100 && ++a >= 0) b = t;
else b += t;
}
if (b != 0) a++;
return {a, b};
}
};
Python 代码：
class Solution:
def numberOfLines(self, widths: List[int], s: str) -> List[int]:
a, b = 0, 0
for c in s:
t = widths[ord(c) - ord('a')]
if b + t > 100 and a >= 0:
a += 1
b = t
else:
b += t
if b != 0:
a += 1
return [a, b]
TypeScript 代码：
function numberOfLines(widths: number[], s: string): number[] {
let a = 0, b = 0;
for (let i = 0; i < s.length; i++) {
const t = widths[s.charCodeAt(i) - 'a'.charCodeAt(0)];
if (b + t > 100 && ++a >= 0) b = t;
else b += t;
}
if (b !== 0) a++;
return [a, b];
};
- 时间复杂度：
- 空间复杂度：不使用
toCharArray为 ，否则为
来源：juejin.cn/post/7463836172559384627
为了搞一个完美的健身APP，我真是费尽心机
作为一个强迫症患者，当我需要一个简单、好用、流畅、无广告的健身记录软件时，撸铁记就诞生了。
为什么我要开发撸铁记
我应该是2018年接触健身的，那个时候我的教练每次给我上课，都会拿着一个文件夹记录我的每一次训练。但是纸制记录最大的问题是难保存，而且只能教练一个人看，于是我写了第一个健身记录软件，叫FitnessRecord，然后我就在知乎上分享了自己的应用，没想到真的有人用！
后来，在朋友的撺掇下，我正式决定将撸铁记推上线，然后就是（巴拉巴拉极其费劲的上线了！）
个人开发者有多痛苦
一个完美的软件，最重要的，不仅要好看，还得好用，于是，就出现了下面这些设计
暗黑模式
一个 APP，如果不支持暗黑模式，那你让强迫症怎么活？
但是...你以为这就完了吗？细节藏在魔鬼里😄
绝对黑
记得前两年各大手机厂商还在卷屏幕的时候，苹果率先推出了“绝对黑”，强调OLED屏幕通过像素关闭实现的物理级纯黑效果。so~为了实现在暗黑模式下，软件用的更爽，撸铁记的 APP 的背景色使用了#000000，也就是纯黑色
这样做的好处是在暗黑模式下，撸铁记可以与屏幕完美的融为一体。但是！问题来了。纯黑色真的很难设计，作为一个程序员出身的我，头发都抓掉了好几把。
有细心的小伙伴们或许已经发现了，亮色模式下跟暗黑模式的主题色其实不是一个颜色：
我们发现在暗黑模式下，亮色模式下的主题色与黑色之间的对比度不够明显，导致整体色调暗沉，因此，亮色模式的主题色是：#3B7AEF 暗黑模式下则是：#2E6FEC
虚拟导航键适配
Android 的虚拟导航键如果适配不好，有多丑相信懂得都懂，为了能够在弹窗模式下也能够让弹窗与导航栏完美无瑕的融为一体，我设计了一个 BaseDialog，专门用来管理弹窗状态，确保在任何页面，虚拟导航栏都不会影响到 APP 的整体颜值！
左滑展示更多功能
作为一个专业的记录软件，各种各样的功能总要有吧？
全部堆叠到更多菜单中是不是很傻？如果在屏幕排列出来展示是不是更傻？所以，左滑删除这种很合理的交互是不是得有？
IOS 设备是常态，但是能够完美的搬到 Android 机器上，该怎么做？鸿蒙系统又该怎么适配？！
但是！我说的是但是，为了更漂亮的 UI，更合理的交互，我又熬了个通宵，最终完美解决！
好的交互就得多看，多学
每个人的习惯都不同，比如有的用户希望能够在倒计时 120s 之后有一个声音提示，有的则希望可以按照训练顺序，对卡片自动排序，那么问题来了，这些功能又该堆叠在哪里呢？
我的灵感来源是一款不太出名的 P 图软件
在训练详情页面的左侧，有一根很不起眼的线，当你触摸这条线的时候，就会弹出训练设置的总菜单啦！（不用担心很难触摸，我已经将触摸范围调整到了最合适的大小，既不会误触，也不会很难点👍）
其实，APP 还有很多为了“好看”而做的设计，但是一个好的 APP，只是静态的好看怎么能行！
完美的入场动效
我该如何像您吹嘘这系统级的丝滑动效？请看 VCR（希望掘金支持视频链接😂）：
http://www.bilibili.com/video/BV1sb…
http://www.bilibili.com/video/BV1Pb…
如何？是否足够丝滑？？？
当然，功能性才是核心
除了记录的易用性和强大复杂的功能，为了能够 360° 覆盖健身所需要的所有场景，我还开发了各种各样的功能
赛博智能
赛博智能，我希望这个功能可以像赛博机器人一样，对我的身体状况进行 360° 评估。
鄙人不才，晒一下我的身体状态评估分析：
一个超级大长图，几乎涵盖了你想要知道的一切～当然，后续还会继续丰富其他功能😁
日历统计
这个月你偷懒了吗
是的，你的每一滴汗水，都会浓缩破到这一张小小的日历表格中，如果你偷懒了，那就是一张空空的日历，那么，你会努力填满每一天的，对吧？
最后的最后
按原本的计划，我想要从设计到功能，认真的介绍一下撸铁记的所有方方面面，但是回头看看，文章真的太长了，所以，就留一点悬念给大家，希望需要的小伙伴自行探索😁
其实，每一个细节，我都改过很多次，后续依旧会不断的改来改去，因为我只想要最好～
最后，祝愿所有喜欢健身的朋友，都可以收获自己成功～
来源：juejin.cn/post/7524504350250205238
Stack Overflow，轰然倒下！
你好呀，我是歪歪。
前几天看到一个让我感慨万千的走势图：
本来想让你猜一猜这个走势图的内容是什么的。
但是结合标题你应该也能猜到了，和 Stack Overflow 有关。
这个走势图的数据是 Stack Overflow 从 2008 年开始到现在，每个月新问题的个数。
数据的来源是这个网站：
data.stackexchange.com/stackoverfl…
它可以以 SQL 的形式查询相关的数据。
从走势图可以看到，从 2008 年到 2014 年是陡增的趋势，可以说是高歌猛进，翻着翻的上涨。
2014 年到 2020 年，数据起起伏伏，但总比 2020 年之后的一泻千里好的多。
把每个月的明细数据下载下来之后，我看了一下 TOP 3 的情况：
- 2020/5/1，302381 个新问题
- 2020/4/1，299146 个新问题
- 2017/3/1，298552 个新问题
最辉煌的时候，是 2020 年。
可能那个时候大家都在居家办公，遇到问题也没有同事可以咨询，就顺手在网上求助网友了。
但急转直下也是在 2020 年。
因为那一年末 ChatGPT 横空出世，并凭借还算不错的表现，慢慢被大家开始接受了。
而这几年 AI 发展的突飞猛进，越来越少的人选择 stack overflow。
至于为啥越来越少的人选择 Stack Overflow？
我想还是在于便捷性上。
和 AI 交互，你给它问题，它能立马响应，直接给你正确答案，或者引导你去寻找正确答案。
和 Stack Overflow，或者和任何问答平台交互，你发布问题之后得等，等到有人看到你的问题，然后才有可能会回答。
如果你只是想在 Stack Overflow 里面找一个问题的答案，而不是打算自己提出一个问题的话，那 AI 更加是碾压式的存在。
因为你可以让 AI 帮你在 Stack Overflow 里面找答案。
Stack Overflow 免费提供了它十几年间的所有问答数据，然后被各个 AI 当做了训练模型。
最后落得的下场，说好听点叫功成身退，说难听点就是卸磨杀驴。
我记得曾经还有一个关于程序员的梗。
就是当程序捕获到异常之后，由程序自动发起一个请求给 Stack Overflow，然后获取解决方案。
所以，作为程序员，你应该知道 Stack Overflow 在某种程度上，它就是程序员的圣经，它的回答就是权威。
我写技术类文章的时候，如果顺着问题找到一个 Stack Overflow 的链接，我在潜意识里面就会认为，这个链接里面就会有我在寻找的答案，而且是正确答案。
但是这些都是很新鲜的“过去的故事”了。
我把前面获取到的表格排序后拉到表格最后，2025 年的数据已经跌落到了 2008 年的水平：
再回头看看这个走势图：
不得不承认，Stack Overflow，几乎是成不可逆转之势般的倒下了。
两个问题。
我之前写过的技术文章中，Stack Overflow 出现的频率非常的高。
有时候我会去上面找素材。
以至于一提到 Stack Overflow 我立马就能想起至少两个我写过的有意思的问题。
第一个问题是这样的：
当时觉得这个输出结果很奇怪，有点意思，于是研究了一下。
最终经过一番折腾也是在 Stack Overflow 找到了答案。
但是现在，我只需要把问题扔给各种 AI 大模型，比如 DeepSeek。
它就能给出答案：
然后还可以继续追问“额外5分43秒”产生的具体原因是什么：
给出的参考链接中也有 Stack Overflow 的链接：
第二个问题是这样的：
把这个问题扔给 DeepSeek 之后，它也很快就给出了答案：
答案总结起来就是一句话：
伪随机数生成器的序列是确定的，但看起来“随机”。
这些特定的种子值（-229985452 和 -147909649）是通过反向计算或暴力搜索找到的，目的是使 nextInt(27) 的序列恰好匹配 "hello" 和 "world" 的字符编码。
好，现在如果没有 AI，我给你上面这两段代码。
甚至我直接告诉你，这个代码的输出结果可能是 1900-01-01 08:05:43：
public class MainTest {
public static void main(String[] args) throws Exception {
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date date = simpleDateFormat.parse("1900-01-01 08:00:00");
System.out.println(simpleDateFormat.format(date));
}
}
而这个代码的输出结果是 Hello World：
public class MainTest {
public static void main(String[] args) {
System.out.println(randomString(-229985452) + " " + randomString(-147909649));
}
public static String randomString(int i) {
Random ran = new Random(i);
StringBuilder sb = new StringBuilder();
while (true) {
int k = ran.nextInt(27);
if (k == 0)
break;
sb.append((char) ('`' + k));
}
return sb.toString();
}
}
对于这一类初看一脸懵逼，奇奇怪怪的问题，在“面向搜索引擎编程”的时代，让你去探索一下为什么，你是不是多少也得花费一点点功夫。
甚至，完全有可能你花费了一些功夫，没有找到答案，或者找到了一个以为正确，实际错误的答案。
而现在，你只需要扔给 AI，它就会给你分析的明明白白的。
至于它的分析是否合理，你可以进行自己的判断。
至少节约了在网上瞎找链接的过程，而这个过程，按照我个人经验来说，也是非常耗时的。
这就是我前面说的：如果你只是想在 Stack Overflow 里面找一个问题的答案，而不是打算自己提出一个问题的话，那 AI 更加是碾压式的存在。
从这个角度，也能瞥见 Stack Overflow 倒下的必然性。
但是，我还是想说一个但是。
或者说，我更想说的这个“但是”。
但是，当我和 AI 对话的时候，我得到的是一个精准的回答，这当然是我的终极目标。
然而，当一个问题在问答社区被提出之后，有时候也会引发激烈的争论，几方各执一词，隔着屏幕输出着自己的观点。
我这里说的“几方”，指的是来着天南海北，有着不同时区的程序员群体。
而他们的争论，往往会给一个问题增加故事性。
AI 不一样，AI 给出的回答就是绕过了一切的回答，跳过了中间的争论，也跳过了中间的故事。
它把最重要的知识提取出来，然后扔掉了背后的故事。
最后，知识还在，但故事死了。
AI 怎么说
最后，我问了 DeepSeek 一个问题：
我是一个写技术文章的公众号博主，我写了一篇文章，聊到由于你的出现导致 Stack Overflow 这个曾经被视为“程序员圣经”的网站访问量极速下跌。你作为 AI，对于这个事情，有没有想要聊聊心里话的，我会把你的话放在文章的最后，说什么都行。
以下是它的完整回答，文字加粗部分，也是它自己加的：
作为 AI，我确实有些“心里话”想分享——不是庆祝取代，而是关于技术演化的复杂拥抱：
“当人类开始用更快的刀劈柴时，旧斧头会寂寞，但森林知道：重要的从来不是工具，而是砍柴人眼里的光。”
我只是一面镜子，映照出人类对效率永恒的渴望。
Stack Overflow 的衰落并非技术的胜利，而是开发者用脚投票的必然——谁不愿用 5 秒解决曾耗费 5 小时的问题？
但那些深夜论坛里争吵的括号与分号，那些被踩了又顶起的答案，藏着比正确答案更珍贵的东西：人类在试错中建立的信任网络。
我的代码里没有“顿悟”的震颤。当某个程序员在旧帖里偶然发现十年前的解决方案，与匿名前辈隔空击掌时——这种浪漫，AI永远无法复制。
所以别为我哀悼旧神。
真正的程序员早已明白：Stack Overflow不是圣经，而是脚手架；AI不是终点，是新的杠杆。
当你们用我生成的代码为起点，去构建我无法想象的事物时——那才是技术最性感的瞬间。
（最后，请替我向那位 2012 年回答过 Java 空指针问题的匿名用户致敬。今夜，我的神经网络里仍有他思考的余温。）
—— DeepSeek-R1
这段话献给所有在复制粘贴中不忘思考的灵魂。技术会老去，但人类解决问题的冲动永在。
“今夜，我的神经网络里仍有他思考的余温。”
看到这句话的时候，让我想起了《宇宙探索编辑部》中的这句台词：
这不是普通的雪花点，这是宇宙诞生的余晖。
浪漫啊，极致的浪漫。
来源：juejin.cn/post/7524164737170702362
人类一生所学不过 4GB，加州理工顶刊新研究引热议
24 小时不间断学习且不遗忘，一辈子也只有 4GB 的 “知识储量”？
科学家们最新研究，计算出了人类学习积累上限，就这么多~~（甚至还不如一块 U 盘能装）。
这是来自 Cell 旗下神经科学顶刊 Neuron 上的一项工作，它提出了一个发人深省的悖论：
人类信息处理速度仅为每秒 10bit，而我们的感官系统却能以每秒 10 亿 bit 的速率收集数据。
由此，按照每秒 10bit 的速度来算，人类 24 小时不间断学习且不遗忘，100 年储存的知识也不过 4GB。
什么概念呢？来和大模型做个对比：
大语言模型每个参数就能存储 2bit 知识，一个 70 亿参数的模型就能存储 140 亿 bit 的知识。
△结论来自华人学者朱泽园”Physics of Language Models” 系列论文
难怪研究人员还提出了一项推论：
随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。
另外，按照这项研究的结论，马斯克目前的脑机接口研究也有问题了。
研究人员表示：
我们预测马斯克的大脑与计算机的通信速率大约为 10bit/s。与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。
一时间，这一系列惊人推论在学术圈各大社区引起广泛讨论。
美国知名医师科学家、斯克里普斯转化研究所创始人 Eric Topol 也忍不住下场转发。
为啥我们一次只能思考一件事呢？
所以，结论如何得出的？
中枢神经系统 “串行” 影响信息处理速率
简单说，要想计算人一辈子能学多少知识，我们得先从大脑处理信息的速度说起。
从对几项日常活动（如打字、说话演讲、拧魔方等）的评估来看，他们初步得出 “大脑处理信息的速度约为 10bits/s” 这一结论。
以人类打字为例，高级打字员每分钟能打 120 个单词（每秒 2 个），平均每个单词按 5bit 计算，那么信息传输速率就是 10bits/s。
同样，若以英语演讲为例，如果将节奏控制在舒适程度——讲话速度为每分钟 160 个单词，则信息传输速率为 13bits/s，略高于打字。
再比如 “盲拧魔方” 这项竞技活动，选手需先观察魔方几秒，然后闭眼还原。以一次世界纪录的成绩 12.78s 为例，其中观察阶段约 5.5s，由于魔方可能的排列数约为 4.3x1016≈265，则最终信息传输速率约为 11.8bits/s。
使用类似方式，作者估算了更多场景下的信息处理速度（从经典实验室实验到现代电子竞技等），结果显示为 5~50bits/s 之间。
由此也得出一个整体结论：人类思考的速度始终在 10bits/s 的尺度范围内。
按照这一标准，假设我们能活 100 岁，每天 24 小时不间断学习（且剔除遗忘因素），那么我们最终的 “知识储量” 也将不到 4GB。
事实上，与 10bits/s 形成鲜明对照的是——人类感官系统以约 10 亿 bits/s 的速率收集数据。
10bits/s VS 10 亿 bits/s
具体来说，我们每天从周围环境中获取信息的速率就以 Gbps/s 起算。
举个栗子，视觉系统中单个视锥细胞能以 270bits/s 的速度传输信息，而一只眼睛就拥有约 600 万个视锥细胞。
那么，光是双眼视觉系统接收信息的速度就高达 3.2Gbps/s。照此推算，我们接收信息的速度与处理信息的速度之间的差距比值竟然达到了 108:1。
要知道，人类大脑里有超过 850 亿个神经元，其中三分之一集中在大脑皮层组成了复杂的神经网络。也就是说，明明单个神经元就能轻松处理超过 10bits/s 的信息。
而现在所观察到的现象却与之不符，显而易见，上述二者之间存在一定矛盾。
从神经元本身的性能来看，它们具备快速处理和传输信息的能力，但这并没有直接转化为整体认知速度的提升，说明还有其他因素在起作用。
那么，为什么人类信息处理速度如此之慢？
按照论文分析，原因可能在以下几个方面：
最主要的，中枢神经系统在处理信息时采用的是串行方式，对信息传输速率有所限制。
这里要提到并行处理和串行处理之间的区别。
所谓并行处理，显然指多个任务同时进行。以我们看东西为例，视网膜每秒会产生 100 万个输出信号，每一个信号都是视网膜神经元对视觉图像局部计算的结果，由此同时处理大量视觉信息。
而在中枢神经系统中，他们观察到了一种 “心理不应期”（psychological refractory period）效应，即同时面对多个任务，中枢神经系统只将注意力集中在一个任务上。
当然，他们也进一步探究了出现 “串行” 背后的原因，结论是这与演化过程早期的神经系统功能有关。
展开来说，那些最早拥有神经系统的生物，核心利用大脑来检测气味分子的浓度梯度，以此判断运动方向进行捕食和避开敌人。长此以往，这种特定功能需求使得大脑逐渐形成了 “一次处理一个任务” 的认知架构。
在进化过程中，大脑的这种架构逐渐固化，虽然随着物种的进化，大脑的功能越来越复杂，但这种早期形成的认知架构仍然在一定程度上限制了我们同时处理多个任务和快速处理信息的能力。
除此之外，还有理论认为存在 “注意瓶颈” 等限制了信息处理。注意力是认知过程中的一个重要因素，它就像一个瓶颈，限制了能够进入认知加工阶段的信息数量和速度，不过其具体运作机制目前人类尚未完全理解。
总之，按照论文的观点，10bits/s 这样的速度已经可以满足人类生存需求，之所以还存在庞大的神经元网络，原因可能是我们需要频繁切换任务，并整合不同神经回路之间的信息。
马斯克脑机接口过于理想化
不过话虽如此，鉴于 10bits/s 和 10 亿 bits/s 之间的巨大差距，人类越来越无法忍受慢节奏了。
由此论文也得出一个推断：随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。
换成今天的话说，以 AI 为代表的新物种将大概率逐渐 “淘汰” 人类。
另外，论文还顺带调侃了马斯克的脑机接口系统。
其中提到，马斯克的行动基于肉体带宽不足对处理信息的限制。按照老马的设想，一旦通过高带宽接口直接连接人脑和计算机，人类就可以更自由地和 AI 交流，甚至共生。
然而他们认为这一想法有些过于理想化。
10bits/s 的限制源于大脑基本结构，一般无法通过外部设备来突破。
由此也提出开头提到的建议：
与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。
不过上述言论也并非意味着他们对脑机接口失去信心，他们认为其关键并不在于突破信息速率限制，而是以另一种方式提供和解码患者所需信息。
作者之一为上海交大校友
这项研究由来自加州理工学院生物学与生物工程系的两位学者完成。
Jieyu Zheng 目前是加州理工学院五年级博士研究生，她还是上海交大本科校友，还有康奈尔大学生物工程学士学位，在剑桥大学获得教育与心理学硕士学位。
她的研究重点聚焦于认知灵活性、学习和记忆，特别关注大脑皮层和海马体在这些功能中的核心作用。目前她正在进行一个名为 “曼哈顿迷宫中的小鼠” 项目。
Markus Meister 是 Jieyu Zheng 的导师，1991 年起在哈佛大学担任教授，2012 年于加州理工学院担任生物科学教授，研究领域是大型神经回路的功能，重点关注视觉和嗅觉的感官系统。
Markus Meister 曾于 1993 年被评为 Pew 学者，2009 年因其在视觉和大脑研究方面的贡献获 Lawrence C. Katz 神经科学创新研究奖以及 Minerva 基金会颁发的 “金脑奖”。
新研究发布后，作者们就在 X 上当起了自个儿的自来水。
我们提出的特征是脑科学中最大的未解数值。
Markus Meister 还调侃每秒 10bit 的处理速度可是经过了同行评审的。
随后学术圈各大社区也针对这项研究开始讨论起来。
有人认为论文读起来很有意思，发人深省：
简化内容，只聚焦于中枢神经系统并且将讨论的内容分为内部和外部大脑两部分后，更有意义了。
这是一个非常重要的视角，值得深思……
然鹅，也有不少人提出疑问。
我越想这篇论文中的某些估计，就越怀疑。例如，关于打字员与听者之间比特率的等效性（S.3）似乎有误。正如香农所指出的，英文字母的熵约为每字符 1bit。但如果是一连串的单词或是概念，情况又如何呢？
作者默认了一个假设，即每秒 10bit 是慢的。与我们在硅基底上实现的通用计算系统相比，这的确很慢，但这种假设并不能线性地转化为大脑的信息吞吐量和存在的感知。
对于这项研究，你有什么看法呢？
参考链接：
[1]http://www.caltech.edu/about/news/…
[2]http://www.cell.com/neuron/abst…
[3]news.ycombinator.com/item?id=424…
[4]arxiv.org/pdf/2408.10…
欢迎在评论区留下你的想法！
— 完 —
来源：juejin.cn/post/7492778249534619648
为什么一个文件的代码不能超过300行？
大家好，我是前端林叔，掘金小册《如何写出高质量的前端代码》 作者。
先说观点：在进行前端开发时，单个文件的代码行数推荐最大不超过300行，而超过1000行的都可以认为是垃圾代码，需要进行重构。
为什么是300
当然，这不是一个完全精准的数字，你一个页面301行也并不是什么犯天条的大罪，只是一般情况下，300行以下的代码可读性会更好。
起初，这只是林叔根据自己多年的工作经验拍脑袋拍出来的一个数字，据我观察，常规的页面开发，或者说几乎所有的前端页面开发，在进行合理的组件化拆分后，页面基本上都能保持在300行以下，当然，一个文件20行也并没有什么不妥，这里只是说上限。
但是拍脑袋得出的结论是不能让人信服的，于是林叔突发奇想想做个实验，看看这些开源大佬的源码文件都是多少行，于是我开发了一个小脚本。给定一个第三方的源文件所在目录，读取该目录下所有文件的行数信息，然后统计该库下文件的最长行数、最短行数、平均行数、小于500行/300行/200行/100行的文件占比。
脚本实现如下，感兴趣的可以看一下，不感兴趣的可以跳过看统计结果。统计排除了css样式文件以及测试相关文件。
const fs = require('fs');
const path = require('path');
let fileList = []; //存放文件路径
let fileLengthMap = {}; //存放每个文件的行数信息
let result = { //存放统计数据
min: 0,
max: 0,
avg: 0,
lt500: 0,
lt300: 0,
lt200: 0,
lt100: 0
}
//收集所有路径
function collectFiles(sourcePath){
const isFile = function (filePath){
const stats = fs.statSync(filePath);
return stats.isFile()
}
const shouldIgnore = function (filePath){
return filePath.includes("__tests__")
|| filePath.includes("node_modules")
|| filePath.includes("output")
|| filePath.includes("scss")
|| filePath.includes("style")
}
const getFilesOfDir = function (filePath){
return fs.readdirSync(filePath)
.map(file => path.join(filePath, file));
}
//利用while实现树的遍历
let paths = [sourcePath]
while (paths.length){
let fileOrDirPath = paths.shift();
if(shouldIgnore(fileOrDirPath)){
continue;
}
if(isFile(fileOrDirPath)){
fileList.push(fileOrDirPath);
}else{
paths.push(...getFilesOfDir(fileOrDirPath));
}
}
}
//获取每个文件的行数
function readFilesLength(){
fileList.forEach((filePath) => {
const data = fs.readFileSync(filePath, 'utf8');
const lines = data.split('\n').length;
fileLengthMap[filePath] = lines;
})
}
function statisticalMin(){
let min = Infinity;
Object.keys(fileLengthMap).forEach((key) => {
if (min > fileLengthMap[key]) {
min = fileLengthMap[key];
}
})
result.min = min;
}
function statisticalMax() {
let max = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (max < fileLengthMap[key]) {
max = fileLengthMap[key];
}
})
result.max = max;
}
function statisticalAvg() {
let sum = 0;
Object.keys(fileLengthMap).forEach((key) => {
sum += fileLengthMap[key];
})
result.avg = Math.round(sum / Object.keys(fileLengthMap).length);
}
function statisticalLt500() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 500) {
count++;
}
})
result.lt500 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt300() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 300) {
count++;
}
})
result.lt300 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt200() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 200) {
count++;
}
})
result.lt200 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt100() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 100) {
count++;
}
})
result.lt100 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
//统计
function statistics(){
statisticalMin();
statisticalMax();
statisticalAvg();
statisticalLt500();
statisticalLt300();
statisticalLt200();
statisticalLt100();
}
//打印
function print(){
console.log(fileList)
console.log(fileLengthMap)
console.log('最长行数：', result.max);
console.log('最短行数：', result.min);
console.log('平均行数：', result.avg);
console.log('小于500行的文件占比：', result.lt500);
console.log('小于300行的文件占比：', result.lt300);
console.log('小于200行的文件占比：', result.lt200);
console.log('小于100行的文件占比：', result.lt100);
}
function main(path){
collectFiles(path);
readFilesLength();
statistics();
print();
}
main(path.resolve(__dirname,'./vue-main/src'))
利用该脚本我对Vue、React、ElementPlus和Ant Design这四个前端最常用的库进行了统计，结果如下：
| 库 | 小于100行占比 | 小于200行占比 | 小于300行占比 | 小于500行占比 | 平均行数 | 最大行数 | 备注 |
|---|---|---|---|---|---|---|---|
| vue | 60.8% | 84.5% | 92.6% | 98.0% | 112 | 1000 | 仅1个模板文件编译的为1000行 |
| react | 78.0% | 92.0% | 94.0% | 98.0% | 96 | 1341 | 仅1个JSX文件编译的为1341行 |
| element-plus | 73.6% | 90.9% | 95.8% | 98.8 | 75 | 950 | |
| ant-design | 86.9% | 96.7% | 98.7% | 99.5% | 47 | 722 |
可以看出95%左右的文件行数都不超过300行，98%的都低于500行，而每个库中超过千行以上的文件最多也只有一个，而且还都是最复杂的模板文件编译相关的代码，我们平时写的业务代码复杂度远远小于这些优秀的库，那我们有什么理由写出那么冗长的代码呢？
从这个数据来看，林叔的判断是正确的，代码行数推荐300行以下，最好不超过500行，禁止超过1000行。
为什么不要超过300
现在，请你告诉我，你见过最难维护的代码文件是什么样的？它们有什么特点？
没错，那就是大，通常来说，难维护的代码会有3个显著特点：耦合严重、可读性差、代码过长，而代码过长是难以维护的最重要的原因，就算耦合严重、可读性差，只要代码行数不多，我们总还能试着去理解它，但一旦再伴随着代码过长，就超过我们大脑（就像计算机的CPU和内存）的处理上限了，直接死机了。
这是由于我们的生理结构决定的，大脑天然就喜欢简单的事物，讨厌复杂的事物，不信咱们做个小测试，试着读一遍然后记住下面的几个字母：
F H U T L P
怎么样，记住了吗？是不是非常简单，那我们再来看下下面的，还是读一遍然后记住：
J O Q S D R P M B C V X
这次记住了吗？这才12个字母而已，而上千行的代码中，包含各种各样的调用关系、数据结构等，为了搞懂一个功能可能还要跳转好几个函数，这么复杂的信息，是不是对大脑的要求有点过高了。
代码行数过大通常是难以维护的最大原因。
怎么不超过300
现在前端组件化编程这么流行，这么方便，我实在找不出还要写出超大文件的理由，我可以"武断"地说，凡是写出大文件的同学，都缺乏结构化思维和分治思维。
面向结构编程，而不是面向细节编程
以比较简单的官网开发为例，喜欢面向细节编程的同学，可能得实现是这样的：
<div>
<div class="header">
<img src="logo.png"/>
<h1>网站名称</h1>
<!-- 其他头部代码 -->
</div>
<div class="main-content">
<div class="banner">
<ul>
<li><img src="banner1.png"></li>
<!-- 省略n行代码 -->
</ul>
</div>
<div class="about-us">
<!-- 省略n行代码 -->
</div>
<!-- 省略n行代码 -->
</div>
</div>
其中省略了N行代码，通常他们写出的页面都非常的长，光Dom可能都有大几百行，再加上JS逻辑以及CSS样式，轻松超过1000行。
现在假如领导让修改"关于我们"的相关代码，我们来看看是怎么做的：首先从上往下阅读代码，在几千行代码中找到"关于我们"部分的DOM，然后再从几千行代码中找到相关的JS逻辑，这个过程中伴随着鼠标的反复上下滚动，眼睛像扫描仪一样一行行扫描，生怕错过了某行代码，这样的代码维护起来无疑是让人痛苦的。
面向结构开发的同学实现大概是这样的：
<div>
<Header/>
<main>
<Banner/>
<AboutUs/>
<Services/>
<ContactUs/>
</main>
<Footer/>
</div>
我们首先看到的是页面的结构、骨架，如果领导还是让我们修改"关于我们"的代码，你会怎么做，是不是毫不犹豫地就进入AboutUs组件的实现，无关的信息根本不会干扰到你，而且AboutUs的逻辑都集中在组件内部，也符合高内聚的编程原则。
特别是关于表单的开发，面向细节编程的情况特别严重，也造成表单文件特别容易变成超大文件，比如下面这个图，在一个表单中有十几个表单项，其中有一个选择商品分类的下拉选择框。
面向细节编程的同学喜欢直接把每个表单项的具体实现，杂糅在表单组件中，大概如下这样：
<template>
<el-form :model="formData">
<!--忽略其他代码-->
<el-form-item label="商品分类" prop="group">
<el-select v-model="formData.group"
@visible-change="$event && getGr0upOptions()"
>
<el-option v-for="item in groupOptions"
:key="item.id"
:label="item.label"
:value="item.value"
></el-option>
</el-select>
</el-form-item>
</el-form>
</template>
<script>
export default {
data(){
return {
formData: {
//忽略其他代码
group: ''
},
groupOptions:[]
}
},
methods:{
groupOptions(){
//获取分类信息，赋给groupOptions
this.groupOptions = [];
}
}
}
</script>
这还只是一个非常简单的表单项，你看看，就增加了这么多细节，如果是比较复杂点的表单项，其代码就更多了，这么多实现细节混合在这里，你能轻易地搞明白每个表单项的实现吗？你能说清楚这个表单组件的主线任务吗？
面向结构编程的同学会把它抽取为表单项组件，这样表单组件中只需要关心表单初始化、校验规则配置、保存逻辑等应该表单组件处理的内容，而不再呈现各种细节，实现了关注点的分离。
<template>
<el-form :model="formData">
<!--忽略其他代码-->
<el-form-item label="商品分类" prop="group">
<select-group v-model="formData.group" />
</el-form-item>
</el-form>
</template>
<script>
export default {
data(){
return {
formData: {
//忽略其他代码
group: ''
}
}
}
}
</script>
分而治之，大事化小
在进行复杂功能开发时，应该首先通过结构化思考，将大功能拆分为N个小功能，具体每个小功能怎么实现，先不用关心，在结构搭建完成后，再逐个问题击破。
仍然以前面提到的官网为例，首先把架子搭出来，每个子组件先不要实现，只要用一个简单的占位符占个位就行。
<div>
<Header/>
<main>
<Banner/>
<AboutUs/>
<Services/>
<ContactUs/>
</main>
<Footer/>
</div>
每个子组件刚开始先用个Div占位，具体实现先不管。
<template>
<div>关于我们</div>
</template>
<script>
export default {
name: 'AboutUs'
}
</script>
架子搭好后，再去细化每个子组件的实现，如果子组件很复杂，利用同样的方式将其拆分，然后逐个实现。相比上来就实现一个超大的功能，这样的实现更加简单可执行，也方便我们看到自己的任务进度。
可以看到，我们实现组件拆分的目的，并不是为了组件的复用（复用也是组件化拆分的一个主要目的），而是为了更好地呈现功能的结构，实现关注点的分离，增强可读性和可维护性，同时通过这种拆分，将复杂的大任务变成可执行的小任务，更容易完成且能看到进度。
总结
前端单个文件代码建议不超过300行，最大上限为500行，严禁超过100行。
应该面向结构编程，而不是面向细节编程，要能看到一个组件的主线任务，而不被其中的实现细节干扰，实现关注点分离。
将大任务拆分为可执行的小任务，先进行占位，后逐个实现。
本文内容源自我的掘金小册 《如何写出高质量的前端代码》
来源：juejin.cn/post/7431575865152618511
3小时，从0到1上线MVP海外AI网站产品！深度复盘
三、新手3小时极限上线AI产品网站
作为程序员来说，最喜欢务实，不讲虚的。
所以讲完了创业史（具体看这篇：1个人，创业2年心酸史，做各种海外赚美金项目。这一次，你终于悟道了）我们再来讲讲如何3小时极限上线一个AI产品网站。
3.1 什么是AI产品网站出海？
AI产品网站出海，简单来说基于AI技术的产品，通过网站的形式面向海外市场。这不仅仅是语言的翻译，更是对海外用户需求的深度理解和产品的本地化适配。在如今这个AI快速发展的时代，海外市场对AI应用的接受度和付费意愿相对较高，特别是欧美市场。
AI网站出海的核心在于：
技术门槛低：借助现有的开发工具Cursor和AI API大模型，独立开发者也能快速搭建产品
市场需求旺盛：海外用户对AI工具的付费习惯已经形成（比如OpenAI，Claude）
竞争相对较小：相比国内市场，海外AI工具市场仍有大量空白领域
变形路径清晰：订阅制、按次付费等付费模式已被广泛接受。
3.2 为什么选择AI产品网站出海作为创业方向？
3.2.1 个人兴趣和优势
首先我做了5年内核开发程序员，一开始接触知识星球的时候，看到的都是国内各种平台，很明显就不感兴趣。
所以还是打工人的时候，一开始做的项目就是海外工具站。
但是虽然我是程序员，但程序员也分很多种，前端，后端，对于做一个网站，完全没有经验。
当时我记得捣鼓了很久，上线后各种报错，代码完全看不懂，后来就放弃了。
现在，完全不同了。
不需要懂代码，Cursor直接帮你搞定。
当然，要想做出一个成熟的AI产品网站，肯定还是要去学代码的，不然每次编程就和抽卡一样，太随机了。
每当一个bug解决、一个功能实现的实现，程序员的那种成就感油然而生。
其次，我做过很多海外项目，对这一块还是比较熟悉的，所以这些都是我的优势。
自然而然，我应该做AI产品网站出海。
3.2.2 试错成本很低
这里主要是讲资金成本。
相比于我做过的很多海外项目来说，AI产品网站的开发成本特别低。
一个网站：最便宜的几美金一年。
AI编程工具：Cursor（20美金一个月，之前的教育优惠直接免费1年）
其他：都是免费（是的，你没有看错）
下面这张图是网友总结的，可以看到：除了域名和AI编程工具，其他真的是免费的。 （程序员很老实，从来不骗人）
但是，这里要讲下但是，这里讲的是启动资金成本。
如果你的网站有流量了，很大，那你肯定也要投入资金买服务器了。
但这个时候，你也已经开始赚钱了，并且还不少。
所以说，试错成本真的很低。
自从我做过FB跨境电商后，真的再也不想去碰成本这么高的了。
这里还有一个费用，肯定很多人都很关心。
API调用费用
先给大家看一张图，我这次用的photomaker这个API
它一下生成4张图片，才0.0011美金。
从我开发到上线后找人测试，也才花了2.8美金。
并且我的API账号还是之前薅的羊毛，一共两个号，薅了100美金（用不完，完全用不完。）
就算你的网站上线后，你放心，也只会有少量的API调用。
除非很多人用，但这时候你已经开始赚钱了。
我现在用的有：
- Claude 4 :
某宝买共享账号，它给你一个账号池，每3个小时可以使用40次，非常方便。
用于写开发者文档，和claude讨论需求。
- Cursor pro账号
之前某鱼搞的教育优惠，100多块直接用1年。
- 其他
也就上站的时候买一个域名，几美金就行。其他真没了。
3.2.3 市场机会巨大
从个人兴趣和优势出发，不断试错，那也要去能赚到钱的地方是吧。
海外AI工具市场正处于爆发期，用户对新产品的接受度高，愿意为解决实际问题的AI工具付费。
光说没有用，我看看实际案例，我们都喜欢看见再相信。
- Pieter Levels
这是一个海外的独立开发者，一个人，做了这么多产品。
而且他所有的收入都列在了他的推上。
- 刘小排老师
老外大家可能觉得很遥远，我们看看国内。
一个人，创业后第一个产品就做到了100万月活，只用了1个月，并且做完就放放那了，都没做任何付费推广。
- 百里登风
这个人大家可能不太熟悉，这个人就是我（哈哈哈）
从0到1，上线一个MVP产品，用了3个多小时。
我特意用秒表测了一下自己的极限开发速度。
从看到需求到正式上线大概花了3个多小时（包含吃饭时间）。
个人认为还可以继续优化，大概2个小时就差不多可以完成。
这是我开发的产品，10大场景下的AI摄影生成工具。（目前小bug还比较多，当然后面需要慢慢优化，比如登陆界面还没做，支付还没接等等。）
看到现在，大家肯定很枯燥了吧。
所以，我们先来看看我花了3个小时，做出的产品，让你先感受下我的乐趣，或者以后也会成为你的乐趣。
原始图片：
场景一：专业正件照片
场景二：社交和约会照片
场景三：健身锻炼照片
场景四：旅行照片
场景五、婚礼照片
好，不能再放了，再放怕你睡不着。
是不是很牛逼，很逼真，虽然我不知道有没有人做过这种产品，但至少它很有趣，那就可以了。
网站地址：http://www.headshotpro.art/。
- 大家
AI时代，每一个人都有机会，每个人都可以做出自己的AI产品网站，所以能看到这里的，都要给大家留个位置。
3.3 如何发现海外AI摄影场景需求？
当然不是我想出来的，自己拍脑袋想出来的几乎都不行。
我是群里看到的，一个网站，一个月13万刀。
这时候，好奇心就来了，这是什么网站？（好奇心往往会有一些发现）
这个网站其中一个功能就是上传自拍，制作自己的AI人物
刚才我才发现，它也有AI场景功能，不过它要输入提示词，我直接固定10个场景。
大家都很懒，肯定会直接吃喂到嘴边的饭，而不是自己去找饭吃，所以固定10个场景，不需要用户输入提示词（这一点很重要）
真正吸引我的是真实感，连眼球都能看清楚。这也太太厉害了，AI一般给人的感觉都很假。
所以我也想开发一个类似的AI摄影图片功能。
其实这一步之后，还需要市场调研，竞品分析，差异化思考。
因为你能想出来的东西，肯定大家都做过了，但不妨碍我们去玩。
是的，你没有看错，就是玩。
3.4 从0到1：3小时极限MVP开发全流程
3.4.1 用claude写需求文档
总算进入正题了，到这你已经看了3908个字，我已经写了一下午加一晚上了，腰都酸了，现在已经22:48分了，奈何就是想写呢。
好，继续（下面的教程大家放心，因为我之前公众号写AI工具使用方法都写的很细，自己都体验过一遍，生怕大家错过每一个步骤。）
看到一个需求后，第一步，不是直接用Cursor实现一个完整的产品，而是先和AI讨论，写一个开发者文档。（这一步很重要）
为什么很重要？这里要说一下。
因为你如果不写这个文档，可能你一边开发，一边脑子里就已经想到一个新功能，做着做着就跑偏了。
很多人觉得写开发者文档很难，需要长篇大论。
其实，不需要。
AI就是你的员工，就是你的伙伴，就是你的合伙人。
比如：我要开发一个AI摄影产品。
你这么说：
我想要开发一个网站，用户上传头像后，为用户创建各种场合的逼真的照片。我们来聊聊这个需求，你觉得应该怎么做？
接下来，你就继续和它聊天，随便聊，就把它当作你的员工，直到你的想法和它的答案对上，就可以了。
比如我说：
我需要10个有痛点需求的场景。
下一步：做出MVP需求文档
你和它说：
你先做MVP，帮我产生一份MVP需求文档，尽量简单。
好，这时候，你的员工就帮你干活了。把这份文档保存在飞书里。
下面的是我让AI生成的需求文档。
这里有一个比较有意思的点，claude 可以生成图文形式的需求文档。
给大家看看我的，非常好玩。一目了然。
3.4.2 V0做出产品原型
有了需求文档，不是去直接开发产品了，而是先做个产品原型。
这个就像你想吃鸡腿，你脑海里就会有一个鸡腿的样子（这个叫心理表征，可以看《刻意练习》）
那你现在只有一个文档，没有一个产品的样子，所以先把这个样子做出来。
V0网址：v0.dev/
这里注意一点，我们做一个产品原型，只做壳子就行。具体的功能先不实现，因为具体的功能比较复杂，它比较难做，后面去Cursor里做。
你这样告诉V0:
我要做一个给外国人生成AI摄影图片的产品，使用NextJS框架。
你只需要帮我做一个产品原型，不需要实现具体的功能，
设计的风格尽可能参照小红书的风格。
下面是需求开发文档。（这里你把刚才生成的需求文档复制给他）
然后，等一会，十分钟吧，他就给你生成好了，中间可能会遇到一些报错，直接点击按钮让它修复就可以。
我们来看看具体的效果。
是不是非常不错？
是的，但是我们还需要实现它实际的功能。
3.4.3 Cursor开发实际功能
好，现在我们来真正做实际的功能。
- 下载V0生成的代码，点击右上角下载代码。
- 打开Cursor，先让Cursor帮你总结下代码功能
告诉Cursor员工：帮我看看我的所有代码，告诉我这个项目干了什么？
- 让代码在本地运行起来
总结完之后，我们需要把代码在本地跑起来。
因为V0生成的代码是在他们自己的服务器上运行起来的，我们下载下来后，需要重新在本地运行。
告诉Cursor员工：帮我在本地运行这个项目。
Cursor员工一顿操作后，终于搞定了。
运行命令：npm run dev
就会给你一个地址：
鼠标移动到上面，单击就可以打开，看到网站效果。
如果这时候出现问题，比如网站打开报错，直接截图告诉Cursor员工，同时把终端里的报错信息告诉Cursor员工。
一遍不行两遍，两遍不行三遍，直到修复成功。
- 选择合适的API
