Sailing

最近这几个月，我基本已经习惯用 AI 写代码了。 说实话，一开始真的很爽： 一个功能，描述一下，直接给你一版能跑的 接口、结构、甚至异常处理都帮你补好了 有时候连你没想到的细节，它都“帮你想好了” 那

很多人学 Go 指针，只会记住两句话： & 取地址 * 解引用 然后代码能跑，但心里其实是懵的： 取地址到底在干嘛？ 解引用为什么能改原值？ 为什么有时候必须用指针接收者？ 为什么接口实现又跟指针有关

前言（痛点暴击） 你是不是也遇到过： LLM 接口本身明明很快（2～3s） 一用上 LangChain + OpenAI 兼容接口 国内环境直接30s～60s+ 超时 服务一重启就集体卡死 日志疯狂报

现代 CSS 的能力，已经远远超出“写几个断点”那么简单。 今天我们从工程视角，把 单位体系 + 计算体系 一次讲透。 CSS 单位体系：本质不是长度，而是“依赖关系” CSS 单位可以分成三类： 绝

在做企业级 AI Agent 时，我踩过一个非常典型的坑。 一开始我以为只是个“小逻辑问题”。后来我发现，那是一次架构认知的分水岭。 这篇文章，讲的不是“消息补全”。讲的是一个更重要的问题： 问题很简

本周通过一个小需求尝试了下 Agent Skill，效果还不错。 比如你要做一个网站，以前没装技能的时候，AI 生成的代码又是那个熟悉的： 而通过 Agent Skill 的形式，可以提前配置好： 配

在做 AI 对话产品 时，很多人都会遇到一个问题： 问题的核心，往往不在模型，而在 前后端的流式通信方式。 本文从实战出发，系统讲清楚 SSE、fetch、axios 在 AI 流式对话中的本质区别与

很多开发者习惯把数据库表当“存储桶”：存数据、查数据、删数据，CRUD 就完事了。 但如果你还停留在这个认知，你可能错过了数据库真正的价值——一张设计合理的表，完全可以成为 动态配置、业务策略和系统运

80 分危机，把一群程序员推上神坛。最近知乎上突然爆火的一个词：大模型善后工程师。 看起来有点好笑，但越想越扎心： 更扎心的是： 从 0 → 80 分，只需要一句 prompt。 但从 80 →