DeepSeek 作为AI 大模型其中的佼佼者，各种突破与创新不断涌现，正引领着人工智能发展的新方向；本文以 PPT 式风格直观呈现技术精髓，深入揭秘 DeepSeek 核心技术。
本文关注DeepSeek-R1在技术上最重要的突破——用纯深度学习的方法让AI自发涌现出推理能力。这一研究可能会对模型推理训练后续的范式产生深刻影响。
随着微服务的流行，服务之间的依赖性和调用关系变得越来越复杂，服务的稳定性变得尤为重要。业务场景中经常会涉及到瞬时流量冲击，可能会导致请求响应超时，甚至服务器被压垮、宕机不可用。出于对系统本身和上下游服务的保护，我们通常会对请求进行限流处理，快速拒绝超出配置上限的请求，保证系统或上下游服务系统的稳定。合理策略能有效应对流量冲击，确保系统可用性和性能。本文详细介绍了几种限流算法，比较各个算法的优缺点，给出了限流算法选型的一些建议，同时对业务上常用的分布式限流也提出一些解决方案。
在团队日益注重流程与工具的当下，个体的因素反而容易被忽视。本文尝试从一名研发的视角，探讨在研发流程中，一些编码及编码以外的思考和原则，希望能为开发同学提供一些参考。
俗话说，“40% 的时间写代码，60% 的时间 Debug。” 经验表明，调试才是开发过程中真正的时间黑洞。在 AI 辅助编程日益普及的背景下，这一问题更加突出。AI 能加速代码生成，但处理复杂任务时难免出错，而这些错误更隐蔽且难调试。因此，我们比以往更需要依靠单测这套“原子级正确性保障”体系，确保代码质量和功能可靠性。
一位5年鹅厂程序员经常被问到一个问题：“xx为什么不能用低代码来实现”，于是他就去查阅相关的资料。有了以下的感受，如果有误，敬请指正。 1、聚焦某个特定场景的低代码/无代码是很能提高效率的。代表如蓝盾，以及一些活动页发布平台（供运营同学使用），以及一些数据标注平台。它能让更多不懂代码的人参与进来。 2、并不是所有业务场景都适合套低代码，低代码感觉更适合有固定模式的相对简单业务，确实可以减少投入。但是对于复杂项目并不适合，思考了下目前做的业务要套进来，大量需求定制的js逻辑/定制ui无处安放。 低代码本身的存在是有一定价值的，但是是否我们高估了它的作用？
