随着大模型应用持续火热，应用门槛也越来越低，去年底开始我们利用少部分精力做了一些 AI 探索和实践，并完成了业务所在垂直领域答疑机器人产品的上线。这里主要从普通使用者的视角，把一边学习一边实践的过程记录下来，和大家一起学习交流。 本文定位无门槛。本文受众主要是入门玩家，但对大模型感兴趣想做一些小工具，或者在平常的业务工作中希望使用大模型来提效的读者。
线上问题的定位与优化是程序员进阶的必经之路，常见的问题定位手段有日志排查、分布式链路追踪和性能分析等，其中日志排查主要用来定位业务逻辑问题，分布式链路主要用来定位请求链路中具体是哪个环节出了问题，而如果服务本身的性能出了问题，如一段时间复杂度高的代码引发了CPU占比飙升、内存泄漏等，则需要依赖性能分析工具来帮我们定位此类问题。
随着互联网业务的快速发展，系统架构日益复杂，对下游资源（如数据库）的保护成为系统稳定性的重要环节。传统的限流方式往往依赖于人为设定的固定阈值，难以应对动态变化的业务需求，容易造成资源浪费或系统过载。为此，本文介绍了KLimiter自适应限流器，它可以基于下游资源（如db）水位，对多个不同优先级的上游入口进行自适应调流。
截至 2023 年底，字节跳动内部微服务的数量超过了 30 万，而且这个数字还在快速的增长当中，每个季度仍然会新增上万个微服务。伴随着海量的微服务，微服务过微带来的编解码、序列化、网络和服务治理开销过大问题也愈加凸显，在一些性能敏感、QPS 大的的服务上急需优化，于是极致的微服务合并方案合并编译应运而生。 目前公司内采用合并编译方式合并的服务超过 300 万 core，取得的 CPU Quota 收益超过 40 万 core，接口时延根据包大小有 2-15 ms 不等的优化。
最近在调研前端页面适配 Android 端异形屏的方案，调研过程中发现了一些比较有意思的点，本文主要是做一个总结。
程序员工作的终极意义，就是干掉复杂度，用一套通用的方法解决大部分问题。在大模型时代，这个通用的方法就是——Prompt 工程。作为用好大模型最重要的武器，Prompt 的好坏对模型效果有着决定性的影响。 然而，网络上大量相关文章多是罗列“Prompt 工程” 中的若干技巧，少有体系化的总结，让人看完依然不知道该如何入手。本文希望结合腾讯工程师在 “Prompt 工程” 中的实践经验，更加体系化地对 “Prompt 工程” 进行梳理，希望可以一步步地帮助大家用好大模型，人人都是 Prompt 工程师。
