[{"categories":null,"collections":null,"content":"ZeroCoding 的内容范围与定位。","date":"2026-09-07","objectID":"/about/","tags":null,"title":"关于本站","uri":"/about/"},{"categories":null,"collections":null,"content":"关于本站 ZeroCoding 是一个专注于 AI 应用开发 与 后端工程 两个方向的学习博客，记录我在学习与实践中的笔记、思考与踩坑。 ","date":"2026-09-07","heading":"关于本站","objectID":"/about/:1:0","tags":null,"title":"关于本站","uri":"/about/#关于本站"},{"categories":null,"collections":null,"content":"内容范围 AI 应用开发：大模型（LLM）、AI Agent、RAG、提示工程、AI 编程工具 后端工程：分布式系统设计、高并发架构、云原生、数据库优化、缓存与消息中间件 ","date":"2026-09-07","heading":"内容范围","objectID":"/about/:1:1","tags":null,"title":"关于本站","uri":"/about/#内容范围"},{"categories":null,"collections":null,"content":"写这个博客的目的 通过持续输出倒逼输入，把零散的知识整理成体系。如果这些内容能给同样在这条路上的朋友一些参考，那就更好了。 ","date":"2026-09-07","heading":"写这个博客的目的","objectID":"/about/:1:2","tags":null,"title":"关于本站","uri":"/about/#写这个博客的目的"},{"categories":null,"collections":null,"content":"联系方式 邮箱：hi@zerocoding.online 本站内容如无特殊说明，均为原创，欢迎交流讨论。 ","date":"2026-09-07","heading":"联系方式","objectID":"/about/:1:3","tags":null,"title":"关于本站","uri":"/about/#联系方式"},{"categories":["AI"],"collections":null,"content":"从单 Agent 的 ReAct 推理循环讲起，逐步过渡到多智能体协作的常见模式与工程落地。","date":"2026-09-03","objectID":"/posts/ai-agent-intro/","tags":["Agent","LLM"],"title":"AI Agent 开发入门：从 ReAct 到多智能体协作","uri":"/posts/ai-agent-intro/"},{"categories":["AI"],"collections":null,"content":"AI Agent 是当下大模型应用最热门的方向之一。本文从最基础的 ReAct 推理循环讲起，梳理单 Agent 的核心构成：模型、工具、记忆与规划。 ","date":"2026-09-03","heading":"","objectID":"/posts/ai-agent-intro/:0:0","tags":["Agent","LLM"],"title":"AI Agent 开发入门：从 ReAct 到多智能体协作","uri":"/posts/ai-agent-intro/#"},{"categories":["AI"],"collections":null,"content":"从 ReAct 开始 ReAct（Reasoning + Acting）把「思考」和「行动」交替进行，让模型在推理的同时调用外部工具，从而突破纯文本生成的局限。 思考 → 行动 → 观察 → 思考 → ... → 最终答案 ","date":"2026-09-03","heading":"从 ReAct 开始","objectID":"/posts/ai-agent-intro/:1:0","tags":["Agent","LLM"],"title":"AI Agent 开发入门：从 ReAct 到多智能体协作","uri":"/posts/ai-agent-intro/#从-react-开始"},{"categories":["AI"],"collections":null,"content":"走向多智能体 当任务变复杂时，单一 Agent 会力不从心，于是有了多智能体协作：专家分工、流水线、辩论等模式。工程落地时，重点要处理好 Agent 间的消息传递、状态管理与容错。 后续会结合具体框架展开实践。 ","date":"2026-09-03","heading":"走向多智能体","objectID":"/posts/ai-agent-intro/:2:0","tags":["Agent","LLM"],"title":"AI Agent 开发入门：从 ReAct 到多智能体协作","uri":"/posts/ai-agent-intro/#走向多智能体"},{"categories":["AI"],"collections":null,"content":"Embedding 模型、向量库与召回策略如何选型，以及 chunk 切分和重排序的实战经验。","date":"2026-08-20","objectID":"/posts/rag-practice/","tags":["RAG","向量检索"],"title":"RAG 落地实践：向量检索的选型与优化","uri":"/posts/rag-practice/"},{"categories":["AI"],"collections":null,"content":"RAG（检索增强生成）是让大模型「有据可查」的关键手段。落地时，检索质量直接决定了生成效果的上限。 ","date":"2026-08-20","heading":"","objectID":"/posts/rag-practice/:0:0","tags":["RAG","向量检索"],"title":"RAG 落地实践：向量检索的选型与优化","uri":"/posts/rag-practice/#"},{"categories":["AI"],"collections":null,"content":"选型三件套 Embedding 模型：中文场景优先选对中文友好的模型，注意向量维度与语种覆盖。 向量库：小规模用 pgvector 即可，规模上来再考虑 Milvus、Qdrant 等专用方案。 召回策略：稠密召回为主，稀疏（BM25）做补充，混合检索通常效果更稳。 ","date":"2026-08-20","heading":"选型三件套","objectID":"/posts/rag-practice/:1:0","tags":["RAG","向量检索"],"title":"RAG 落地实践：向量检索的选型与优化","uri":"/posts/rag-practice/#选型三件套"},{"categories":["AI"],"collections":null,"content":"两个常被忽略的优化 Chunk 切分：按语义边界切分，保留标题层级，比固定长度效果好很多。 重排序：用 Cross-Encoder 对召回结果二次排序，能明显提升 Top-K 的命中率。 ","date":"2026-08-20","heading":"两个常被忽略的优化","objectID":"/posts/rag-practice/:2:0","tags":["RAG","向量检索"],"title":"RAG 落地实践：向量检索的选型与优化","uri":"/posts/rag-practice/#两个常被忽略的优化"},{"categories":["AI"],"collections":null,"content":"从少样本、思维链到结构化输出，整理一套在真实业务中好用的提示词方法。","date":"2026-08-10","objectID":"/posts/prompt-engineering/","tags":["提示工程","LLM"],"title":"LLM 应用中的提示工程技巧","uri":"/posts/prompt-engineering/"},{"categories":["AI"],"collections":null,"content":"提示工程是把大模型用好的基本功。这里整理几个在真实业务里反复验证有效的技巧。 ","date":"2026-08-10","heading":"","objectID":"/posts/prompt-engineering/:0:0","tags":["提示工程","LLM"],"title":"LLM 应用中的提示工程技巧","uri":"/posts/prompt-engineering/#"},{"categories":["AI"],"collections":null,"content":"三个核心原则 给足上下文：把背景、角色、约束写清楚，别让模型猜。 要求结构化输出：明确 JSON Schema 或 Markdown 格式，方便下游解析。 分步引导：复杂任务拆成多步，配合思维链（CoT）让模型「想清楚再说」。 ","date":"2026-08-10","heading":"三个核心原则","objectID":"/posts/prompt-engineering/:1:0","tags":["提示工程","LLM"],"title":"LLM 应用中的提示工程技巧","uri":"/posts/prompt-engineering/#三个核心原则"},{"categories":["AI"],"collections":null,"content":"少样本示例 给 1～3 个高质量示例，比写一堆抽象规则更有效。示例要覆盖边界情况，让模型学会「什么时候该怎么做」。 这些技巧不花哨，但胜在稳定、可复现。 ","date":"2026-08-10","heading":"少样本示例","objectID":"/posts/prompt-engineering/:2:0","tags":["提示工程","LLM"],"title":"LLM 应用中的提示工程技巧","uri":"/posts/prompt-engineering/#少样本示例"},{"categories":["后端"],"collections":null,"content":"从数据库唯一约束、状态机到分布式锁，聊聊幂等性在不同场景下的落地方式与取舍。","date":"2026-07-30","objectID":"/posts/idempotency-design/","tags":["分布式","幂等"],"title":"分布式系统中的幂等性设计","uri":"/posts/idempotency-design/"},{"categories":["后端"],"collections":null,"content":"幂等性是分布式系统的老问题，却是高并发场景下最容易踩坑的地方。核心诉求只有一个：同一个操作执行多次，结果和只执行一次一致。 ","date":"2026-07-30","heading":"","objectID":"/posts/idempotency-design/:0:0","tags":["分布式","幂等"],"title":"分布式系统中的幂等性设计","uri":"/posts/idempotency-design/#"},{"categories":["后端"],"collections":null,"content":"常见落地手段 数据库唯一约束：最可靠，通过唯一索引天然去重，适合「创建」类操作。 状态机：把业务状态流转设计成幂等的，重复请求自然被挡在状态判断之外。 Token / 去重表：请求先拿 Token，消费一次即失效，适合「提交」类操作。 分布式锁：保证同一时刻只有一个请求在处理，但要处理好锁的粒度与超时。 ","date":"2026-07-30","heading":"常见落地手段","objectID":"/posts/idempotency-design/:1:0","tags":["分布式","幂等"],"title":"分布式系统中的幂等性设计","uri":"/posts/idempotency-design/#常见落地手段"},{"categories":["后端"],"collections":null,"content":"取舍 没有银弹。唯一约束最稳但局限性强，锁最灵活但引入复杂度。实际项目里往往是组合使用，按业务语义选择最合适的那一层。 ","date":"2026-07-30","heading":"取舍","objectID":"/posts/idempotency-design/:2:0","tags":["分布式","幂等"],"title":"分布式系统中的幂等性设计","uri":"/posts/idempotency-design/#取舍"},{"categories":["后端"],"collections":null,"content":"结合业务规模与运维成本，梳理两种高可用方案的适用边界与迁移路径。","date":"2026-07-12","objectID":"/posts/redis-ha/","tags":["Redis","高可用"],"title":"Redis 高可用选型：哨兵 vs Cluster","uri":"/posts/redis-ha/"},{"categories":["后端"],"collections":null,"content":"Redis 的高可用，最常用的两条路是哨兵（Sentinel）和集群（Cluster）。选型之前，先想清楚自己的真实需求。 ","date":"2026-07-12","heading":"","objectID":"/posts/redis-ha/:0:0","tags":["Redis","高可用"],"title":"Redis 高可用选型：哨兵 vs Cluster","uri":"/posts/redis-ha/#"},{"categories":["后端"],"collections":null,"content":"哨兵（Sentinel） 主从 + 哨兵监控，主挂自动切换。适合数据量不大、但对可用性有要求的场景。优点是简单、兼容性好，缺点是数据集中在一台主节点上，受内存上限制约。 ","date":"2026-07-12","heading":"哨兵（Sentinel）","objectID":"/posts/redis-ha/:1:0","tags":["Redis","高可用"],"title":"Redis 高可用选型：哨兵 vs Cluster","uri":"/posts/redis-ha/#哨兵sentinel"},{"categories":["后端"],"collections":null,"content":"集群（Cluster） 数据分片到多个节点，天然支持水平扩展。适合数据量大、需要分片的场景。代价是运维复杂度上升，部分命令（如多 key 跨 slot 操作）受限。 ","date":"2026-07-12","heading":"集群（Cluster）","objectID":"/posts/redis-ha/:2:0","tags":["Redis","高可用"],"title":"Redis 高可用选型：哨兵 vs Cluster","uri":"/posts/redis-ha/#集群cluster"},{"categories":["后端"],"collections":null,"content":"我的判断 单实例内存 \u0026lt; 8G，优先哨兵，简单可靠。 数据增长快、预期会分片，直接上 Cluster，避免中途迁移。 迁移路径上，从哨兵到 Cluster 可以借助官方工具或双写方案平滑过渡。 ","date":"2026-07-12","heading":"我的判断","objectID":"/posts/redis-ha/:3:0","tags":["Redis","高可用"],"title":"Redis 高可用选型：哨兵 vs Cluster","uri":"/posts/redis-ha/#我的判断"}]