技术博客这一年：哪些内容真的帮到了我
这篇我想按“排查记录”来写，主题是 技术博客这一年：哪些内容真的帮到了我。这种写法比纯概念文更适合我自己回看。 现象先别急着解释复盘不是统计篇数，而是看哪些笔记真的指导了行动。 先把现象钉住，比急着下结论有用。很多时候真正的关键不是“答案是什么”，而是“我是怎么一步步排到这里的”。 我会先看哪几件事 能复现的笔记价值最高 只有结论的文章很快失效 项目复盘比概念摘抄更耐看 带入一个排查场景挑三篇文章补充代码和排查过程。 如果这是线...
下一阶段学习计划：从会写到写得稳
今天不想写长文，先把 下一阶段学习计划：从会写到写得稳 这块拆成几条短一点的问答。面试里经常会被连续追问，如果只背一句定义，第二问基本就卡住了。 先说我自己的结论下一阶段重点从能实现功能转向稳定性、可维护性和系统设计。 我现在会先把这类题分成“定义是什么、为什么这样设计、代码里怎么用、容易翻车在哪”四层去答。这样比死背一段话稳很多。 快问快答 补齐测试习惯。我现在的理解：先记结论，再回到代码里找一个能验证它的场景。 加强数据库和缓...
个人技术知识库应该怎么整理
今天不想写长文，先把 个人技术知识库应该怎么整理 这块拆成几条短一点的问答。面试里经常会被连续追问，如果只背一句定义，第二问基本就卡住了。 先说我自己的结论知识库不是资料仓库，而是能支持检索、复习和项目决策的材料系统。 我现在会先把这类题分成“定义是什么、为什么这样设计、代码里怎么用、容易翻车在哪”四层去答。这样比死背一段话稳很多。 快问快答 原始资料和个人理解分开保存。我现在的理解：先记结论，再回到代码里找一个能验证它的场景。 ...
AI 生成的代码为什么还要认真 Review
这篇我想按“排查记录”来写，主题是 AI 生成的代码为什么还要认真 Review。这种写法比纯概念文更适合我自己回看。 现象先别急着解释AI 能快速产出代码，但不能替我承担设计、边界和上线责任。 先把现象钉住，比急着下结论有用。很多时候真正的关键不是“答案是什么”，而是“我是怎么一步步排到这里的”。 我会先看哪几件事 先看需求是否真的满足 再看异常和并发边界 最后跑测试和静态检查 带入一个排查场景审查一段 AI 生成的 Cont...
用 AI 辅助排查问题时我怎么提问
这篇按踩坑笔记来写，因为 用 AI 辅助排查问题时我怎么提问 我现在更容易记住“错在哪”，而不是“定义长什么样”。 先记住这句话排查类提示词要提供现象、环境、日志、已尝试方案和期望输出。 很多问题不是不会用，而是用得太顺手了，顺手到把边界条件给省掉了。 这类问题一般怎么出现我脑子里会先放这个场景：把一次接口 500 的日志整理成可复查的提问材料。 一开始看着都像是个小问题，真正麻烦的是它往往不是立刻报错，而是跑一阵子、数据一多、并...
一个知识库问答 Demo 的后端设计
这篇按踩坑笔记来写，因为 一个知识库问答 Demo 的后端设计 我现在更容易记住“错在哪”，而不是“定义长什么样”。 先记住这句话问答系统要把上传、索引、检索、生成和反馈拆开。 很多问题不是不会用，而是用得太顺手了，顺手到把边界条件给省掉了。 这类问题一般怎么出现我脑子里会先放这个场景：设计文档上传接口和问答接口。 一开始看着都像是个小问题，真正麻烦的是它往往不是立刻报错，而是跑一阵子、数据一多、并发一上来才暴露。 这次我想盯住的...
用 Redis 做向量检索前我先搞懂了什么
今天不想写长文，先把 用 Redis 做向量检索前我先搞懂了什么 这块拆成几条短一点的问答。面试里经常会被连续追问，如果只背一句定义，第二问基本就卡住了。 先说我自己的结论向量检索要理解索引、距离和元数据过滤。 我现在会先把这类题分成“定义是什么、为什么这样设计、代码里怎么用、容易翻车在哪”四层去答。这样比死背一段话稳很多。 快问快答 向量维度必须一致。我现在的理解：先记结论，再回到代码里找一个能验证它的场景。 相似度不等于事实正...
RAG 的检索、切片和向量化流程
今天把 RAG 的检索、切片和向量化流程 补成一篇正常一点的学习笔记，不写大而全，就记我这轮最想吃透的部分。 一句话先立住RAG 的关键不是把文档塞进去，而是让问题能找回正确片段。 我这次真正记住的点 清洗文档保留结构 切片要兼顾语义完整 向量检索后还要重排或过滤 为什么我会专门记这块因为它很容易出现一种错觉：看资料的时候觉得自己会了，真到写接口、改 SQL、配事务、看线程池参数时又开始发虚。 我现在尽量把知识点挂到一个具体场景...