即刻App年轻人的同好社区
下载
恭喜 Spark Lab 校友团队 Punky Labs 完成超百万融资，估值 500w 美元
这是我们科技火人节第一个完完全全在社区里生长出来的项目，Proud of Kelsen、Archer、Charin、Weston，充值超额信心
四个月前，Punky Labs 还只是一个在我们科技火人节 S1 上诞生的创意雏形。在线下 Hackerhouse 结束后，由两支校友团队合并成为现在的核心团队，并参与到了后续的孵化。这是一支平均年龄 20 岁的创业团队，短短四个月就完成了从 Idea 到 Pre-seed 融资，加速这一切发生。从刚进入科技火人节时候的产品新手到如今的成熟创业者，很荣幸见证 Kelsen、Archer 他们一路的各种 drama、pivot 和加速成长。
回过头看，我们根本不敢想象 S1 居然能这么快跑出一些拿到一定结果的项目，某种意义上也验证了我们的模型和坚定了孵化的决心和自信。
What's Next?
这是我们科技火人节第一个完完全全在社区里生长出来的项目，Proud of Kelsen、Archer、Charin、Weston，充值超额信心
四个月前，Punky Labs 还只是一个在我们科技火人节 S1 上诞生的创意雏形。在线下 Hackerhouse 结束后，由两支校友团队合并成为现在的核心团队，并参与到了后续的孵化。这是一支平均年龄 20 岁的创业团队，短短四个月就完成了从 Idea 到 Pre-seed 融资，加速这一切发生。从刚进入科技火人节时候的产品新手到如今的成熟创业者，很荣幸见证 Kelsen、Archer 他们一路的各种 drama、pivot 和加速成长。
回过头看，我们根本不敢想象 S1 居然能这么快跑出一些拿到一定结果的项目，某种意义上也验证了我们的模型和坚定了孵化的决心和自信。
What's Next?
Spark Lab 校友团队 Punky Labs 完成超百万融资，估值500万美元｜S News
8 30
直觉是理论和实践融为一体的艺术，AI 永远都没办法解决实践上的缺位。
分享一个有趣的故事，事情是这样的，朋友装 expo-linear-gradient 遇到了一个奇奇怪怪的报错，ta 去各种 LLM、google、AI 搜索也没解决这个问题，最终多方印证，大致推测出是版本问题，但是 ta 直接看网上的操作降版本，降了几个版本也没解决问题。
ta 问了我这个问题，我直接去 npm 看了一下 ta 的包发行的对应的 expo （上游依赖）版本是多少，一下子就找到了 ta 应该使用的版本号，我猜到发行者肯定会打个 tag 来做标识。
---
我其实并不知道这个包的依赖冲突是怎么样的，也没具体看遇到了什么问题，完全凭借直觉随便去 npm 看了一下就解决了问题。
为什么我一下子就解决问题了？
直觉是理论和实践融为一体的艺术，我过去有过很多发包的经验，包括单独的包和系列包（eg: llama-index 底下有几百个子包，一个更加复杂的包管理），我深知各种框架维护者在发行版本时需要考虑的依赖冲突、sdk design breaking change，上游兼容性等各种问题。
因此，当我面对朋友的这个问题时，我的直觉让我下意识站在包发行者的视角上看待问题。
如果你没发过系列包（一个大包下面附带着几十个小包）你拥有不会意识到框架维护者的视角是什么样的，他们需要怎么解决这个问题。
当然，如果你踩了很多类似的坑，你的直觉也能帮助你快速解决这个问题。
这里有两条路径：
-系统性学习->拥有 high level 的视角 -> 了解规律 ->快速解决问题
-不断地踩坑试错->尝试总结经验->慢慢总结规律->解决问题
但很多时候，系统性学习一下也花不了多少时间，如果你是一个科班生，我觉得你应该对你的学科抱有应有的尊敬，学习知识、实践、总结规律，
最近看到各种各样的 AI 教学、cursor 教学，我真的看到一个朋友任何编程经验都没有直接想上手开发一个逻辑很复杂的 APP，如果是做着玩我觉得没问题，要是真的认证准备做一个自己想做的 APP 的话，为什么连系统学习基础知识的时间都没有呢？
当然不作为开发，找有经验的人来做也没问题，如果就想自己做，还跟着这种速成课，我实在不理解是有多浮躁。
这时最重要的是你老老实实学一遍，自上而下有一个直观的了解和认知，慢即是快，没有捷径，捷径就是掌握科学的学习方法，在理论和实践的不断结合中探索。
如 cursor 之前，学这些的成本也不高，你花好几个小时把整个框架的 docs, arch 了解清楚了，花几个小时自己写个 react 的五子棋就能把 react 大部分的基础知识都学清楚了。
回过头来看上面提到的问题，反过来思考，如何做换位思考，你如何能站在技术使用者的视角去看待上游框架发行方，最大的直觉是亲手去做一遍。
但问题是你为什么要去做呢？我只是要做一个产品，为什么要学那么多无关紧要的东西和底层知识。
这里完全就是一个 ROI 问题，如果你在学校的时候稳扎稳打，即使学校教的很烂，基础知识也是在直觉上起作用的。
你应该学到什么程度，你应该有多少基础知识，完全取决于你的目的，如果你是一个稳扎稳打的科班生，天天看各种 n 小时用 cursor 速成一个网站，我并不认为这是一个对的选择，现在的人都这么急功近利吗..
AI Copilot 的能力在所有领域都是遇强则强，遇弱则弱，长期来看 AI Agent 也是如此。老板不行，再优秀的 AI 团队也支撑不起来。
当然这是一个典型的例子，随着推理能力的提升和工程的推进，解决这种问题会逐渐变得简单，但问题永远不会凭空消失，有旧的问题消失就会有新的问题产生，如果不抓住主要矛盾永远也解决不了问题。
这应该一个共识？
分享一个有趣的故事，事情是这样的，朋友装 expo-linear-gradient 遇到了一个奇奇怪怪的报错，ta 去各种 LLM、google、AI 搜索也没解决这个问题，最终多方印证，大致推测出是版本问题，但是 ta 直接看网上的操作降版本，降了几个版本也没解决问题。
ta 问了我这个问题，我直接去 npm 看了一下 ta 的包发行的对应的 expo （上游依赖）版本是多少，一下子就找到了 ta 应该使用的版本号，我猜到发行者肯定会打个 tag 来做标识。
---
我其实并不知道这个包的依赖冲突是怎么样的，也没具体看遇到了什么问题，完全凭借直觉随便去 npm 看了一下就解决了问题。
为什么我一下子就解决问题了？
直觉是理论和实践融为一体的艺术，我过去有过很多发包的经验，包括单独的包和系列包（eg: llama-index 底下有几百个子包，一个更加复杂的包管理），我深知各种框架维护者在发行版本时需要考虑的依赖冲突、sdk design breaking change，上游兼容性等各种问题。
因此，当我面对朋友的这个问题时，我的直觉让我下意识站在包发行者的视角上看待问题。
如果你没发过系列包（一个大包下面附带着几十个小包）你拥有不会意识到框架维护者的视角是什么样的，他们需要怎么解决这个问题。
当然，如果你踩了很多类似的坑，你的直觉也能帮助你快速解决这个问题。
这里有两条路径：
-系统性学习->拥有 high level 的视角 -> 了解规律 ->快速解决问题
-不断地踩坑试错->尝试总结经验->慢慢总结规律->解决问题
但很多时候，系统性学习一下也花不了多少时间，如果你是一个科班生，我觉得你应该对你的学科抱有应有的尊敬，学习知识、实践、总结规律，
最近看到各种各样的 AI 教学、cursor 教学，我真的看到一个朋友任何编程经验都没有直接想上手开发一个逻辑很复杂的 APP，如果是做着玩我觉得没问题，要是真的认证准备做一个自己想做的 APP 的话，为什么连系统学习基础知识的时间都没有呢？
当然不作为开发，找有经验的人来做也没问题，如果就想自己做，还跟着这种速成课，我实在不理解是有多浮躁。
这时最重要的是你老老实实学一遍，自上而下有一个直观的了解和认知，慢即是快，没有捷径，捷径就是掌握科学的学习方法，在理论和实践的不断结合中探索。
如 cursor 之前，学这些的成本也不高，你花好几个小时把整个框架的 docs, arch 了解清楚了，花几个小时自己写个 react 的五子棋就能把 react 大部分的基础知识都学清楚了。
回过头来看上面提到的问题，反过来思考，如何做换位思考，你如何能站在技术使用者的视角去看待上游框架发行方，最大的直觉是亲手去做一遍。
但问题是你为什么要去做呢？我只是要做一个产品，为什么要学那么多无关紧要的东西和底层知识。
这里完全就是一个 ROI 问题，如果你在学校的时候稳扎稳打，即使学校教的很烂，基础知识也是在直觉上起作用的。
你应该学到什么程度，你应该有多少基础知识，完全取决于你的目的，如果你是一个稳扎稳打的科班生，天天看各种 n 小时用 cursor 速成一个网站，我并不认为这是一个对的选择，现在的人都这么急功近利吗..
AI Copilot 的能力在所有领域都是遇强则强，遇弱则弱，长期来看 AI Agent 也是如此。老板不行，再优秀的 AI 团队也支撑不起来。
当然这是一个典型的例子，随着推理能力的提升和工程的推进，解决这种问题会逐渐变得简单，但问题永远不会凭空消失，有旧的问题消失就会有新的问题产生，如果不抓住主要矛盾永远也解决不了问题。
这应该一个共识？
12 12
“一个强大节点的崛起不仅改变了信息的流动方式,更重要的是重新定义了整个网络的"计算语法"。它就像在创造一种新的协议层,决定了什么样的信息能被有效处理、如何被处理、以什么形式被传播。这种协议层一旦形成,就会成为整个网络的基础设施,其他节点必须适应这种新的计算语法才能保持自己在网络中的存在度。”
莱森LysonOber: 「拷问你一个关键场景：一个人 A 先发布了某个观点/产品（但没有得到关注），而后来者 B 发布了一个类似的观点/产品引发了大量的关注和传播。于是，A 不服气地说 B 是在“致敬”他。」
7 00
从 openai swarms 到 langchain Agent protocol， 当你认为重要却没有深入推进的事情，最后总有人在帮你完成，但这又何尝不是一种选择的艺术。
7 21
从实验性 MVP 到现在，我们见证了无数年轻人的热情与创造力，我们期待有更多 Builder、Hacker 加入，找到自己的 Spark。
这是一个很有趣的体验，我们真的很需要一个机会来进行真正的自我探索，当我回望自己的过去，我能很明显的感受到，当我接触开源生态之后，开始逐步跳出学校的叙事、既定的叙事去思考自己到底想要什么，现在来看，对我来说这是一个很好 Spark 与启蒙。
没有什么比踏上旅程更有意思的事情了 ——Making it possible for young people to change the world.
这是一个很有趣的体验，我们真的很需要一个机会来进行真正的自我探索，当我回望自己的过去，我能很明显的感受到，当我接触开源生态之后，开始逐步跳出学校的叙事、既定的叙事去思考自己到底想要什么，现在来看，对我来说这是一个很好 Spark 与启蒙。
没有什么比踏上旅程更有意思的事情了 ——Making it possible for young people to change the world.
让年轻人有可能改变世界 | Spark Lab 的过去，现在和未来
5 00
AI 加速开发省出的时间都去哪了？
GitHub 的研究显示，AI工具可以将开发者的生产力提升高达55%，其正常塑开发者的时间分配方式。
- 40-47%的开发者现在能够在系统设计和客户解决方案上投入更多时间
- 37-43%的开发者增加了代码重构和优化的时间。这个变化意味着开发者正在从被动的问题修复转向主动的问题预防。
- 39-45%的开发者投入更多时间进行代码评审
值得注意的是，AI工具改变了传统的项目启动方式。开发者现在可以：
- 在编码前就与AI讨论系统设计
- 通过AI进行初步的可行性验证
- 利用AI快速生成项目框架
《面向IT专业人士的生成式AI》的作者Chrissy LeMaire表示，AI让开发者可以跳过繁琐的项目初始化阶段，直接进入最有价值的开发环节。
GitHub 的研究显示，AI工具可以将开发者的生产力提升高达55%，其正常塑开发者的时间分配方式。
- 40-47%的开发者现在能够在系统设计和客户解决方案上投入更多时间
- 37-43%的开发者增加了代码重构和优化的时间。这个变化意味着开发者正在从被动的问题修复转向主动的问题预防。
- 39-45%的开发者投入更多时间进行代码评审
值得注意的是，AI工具改变了传统的项目启动方式。开发者现在可以：
- 在编码前就与AI讨论系统设计
- 通过AI进行初步的可行性验证
- 利用AI快速生成项目框架
《面向IT专业人士的生成式AI》的作者Chrissy LeMaire表示，AI让开发者可以跳过繁琐的项目初始化阶段，直接进入最有价值的开发环节。
How developers spend the time they save thanks to AI coding tools
10 00