[{"content":"先说结论 AI 编程助手是放大器：它能放大一个懂行的人的效率，但代替不了判断力。用得好省时省力，用不好会引入你看不懂、也不敢改的代码。\n真香的场景 写样板代码：CRUD、数据结构转换、配置文件、正则表达式，这类“无脑但繁琐”的活儿它又快又准。 陌生语言/框架起步：想快速用一个没接触过的库，让它给个可运行的最小示例，比翻文档快。 解释与重构：贴一段看不懂的代码让它讲解，或让它把一坨逻辑重构得更清晰，命中率很高。 写测试：给定函数让它补单元测试，覆盖常见边界，省去大量重复劳动。 容易翻车的场景 复杂业务逻辑：涉及大量隐含上下文和特定业务规则时，它容易“想当然”，生成看似合理实则错误的代码。 超长上下文：跨很多文件的改动，它容易顾此失彼，改了 A 忘了 B。 拿不准的 API：它可能“编”出一个并不存在、但看起来很合理的函数名或参数——所谓幻觉。 几条实用原则 小步快跑：让它一次只做一件小事，改完立刻验证，别一次性接受一大段。 自己要看懂：不理解的代码不要合入。看不懂时，让它逐行解释再决定。 测试兜底：AI 写的代码同样要跑测试，尤其是它自己写的测试也要审一眼是否真的在测东西。 保持怀疑：涉及不熟悉的 API 时，去官方文档核对一下，别全信。 小结 把 AI 编程助手当成一个“很勤快但偶尔会想当然的初级搭档”来用——你负责出思路、把方向、做审查，它负责把重复劳动干掉。这样的分工，效率提升是实打实的。\n","permalink":"https://czy168.vip/posts/ai-coding-assistant/","summary":"AI 编程助手不是万能的。结合实际使用，总结它擅长和不擅长的场景，以及怎么用才不踩坑。","title":"用了半年 AI 编程助手，说说什么场景真香、什么场景翻车"},{"content":"为什么要本地跑 用云端 API 很方便，但本地跑开源模型有它不可替代的价值：\n隐私：数据不出本机，适合处理敏感资料； 成本：一次性硬件投入，之后随便用，没有按 token 计费； 可控：不受服务商限流、下线、涨价影响，还能自由微调。 代价是效果通常不及最顶尖的闭源模型，且吃硬件（尤其是显存/内存）。\n量化：用一点精度换可运行性 原始模型参数是 16 位浮点，非常占空间。量化把参数压到 8 位、4 位甚至更低，大幅降低显存/内存占用，让消费级设备也能跑，代价是轻微的精度损失。\n常见的经验是：4 位量化（如 Q4）在大多数日常任务里，与原始精度的差距肉眼几乎不可见，却能把体积压到约四分之一，是性价比很高的选择。\n用 Ollama 快速上手 Ollama 把“下载 + 加载 + 提供接口”这一套封装得很简单。装好后，一条命令即可拉取并运行：\nollama run qwen3 第一次会自动下载模型，之后直接进入对话。它还提供一个本地 HTTP 接口，方便你在自己的程序里调用：\ncurl http://localhost:11434/api/generate -d \u0026#39;{ \u0026#34;model\u0026#34;: \u0026#34;qwen3\u0026#34;, \u0026#34;prompt\u0026#34;: \u0026#34;用一句话解释什么是向量数据库\u0026#34; }\u0026#39; 选多大的模型 一个粗略的参考：\n7B 级别：8GB 显存或 16GB 内存基本能跑，适合日常问答、总结； 14B~32B：需要更大显存，效果更好； 70B 及以上：对个人设备门槛较高，通常要多卡或走云端。 先从小模型试起，够用就好，不必一上来追求最大。\n小结 本地大模型这两年门槛降得很快，一台还不错的个人电脑，配合 Ollama 这类工具，就能拥有一个完全属于自己的、离线可用的 AI 助手。\n","permalink":"https://czy168.vip/posts/run-local-llm/","summary":"不依赖云端 API，在个人电脑上把开源大模型跑起来。聊聊本地部署的价值、量化的取舍，以及用 Ollama 快速上手。","title":"在自己电脑上跑开源大模型"},{"content":"写在前面 “提示词工程”常被说得很玄，但真正稳定有效的技巧其实不多。下面几条是我在实际使用中反复验证、几乎每次都能提升效果的。\n1. 明确角色与任务 与其说“帮我看看这段代码”，不如说“你是一名资深后端工程师，请从并发安全的角度审查下面这段代码”。给出角色和视角，能显著收敛模型的输出方向。\n2. 给例子（Few-shot） 当你对输出格式有要求时，与其长篇描述，不如直接给一两个例子：\n把下面的句子改写得更正式。 示例： 输入：这活儿我干不了 输出：此项任务超出了我目前的能力范围。 现在改写： 输入：这个方案不行 输出： 模型会照着例子的风格来，比纯文字描述可靠得多。\n3. 让它“先想再答” 对需要推理的问题，加一句“请一步步分析后再给出结论”，往往能明显减少错误。因为模型是逐词生成的，先把中间推理写出来，相当于给了它“打草稿”的空间。\n4. 约束输出格式 如果结果要被程序解析，就明确要求结构化输出：\n请只返回 JSON，格式如下，不要输出任何解释： {\u0026#34;sentiment\u0026#34;: \u0026#34;正面/负面/中性\u0026#34;, \u0026#34;confidence\u0026#34;: 0-1 之间的小数} 必要时再配合“如果无法判断，confidence 填 0”这类兜底规则。\n5. 把长任务拆开 一次让模型“读文档 + 总结 + 翻译 + 排版”，容易顾此失彼。拆成几步、每步只做一件事，整体质量更稳，也更好排查是哪一步出了问题。\n小结 好的提示词的共同点是减少歧义：告诉模型它是谁、要做什么、按什么格式、遇到边界情况怎么办。把这几点讲清楚，效果往往比堆砌各种“咒语”实在得多。\n","permalink":"https://czy168.vip/posts/prompt-engineering-tips/","summary":"抛开玄学，记录几个在实际使用中反复验证有效的提示词技巧：给角色、给例子、让它先想再答、约束输出格式。","title":"提示词工程：几个真正有用的实践技巧"},{"content":"为什么需要 RAG 大语言模型很强，但有两个天然短板：\n知识有截止时间，训练之后发生的事它不知道； 不了解你的私有资料，比如公司内部文档、个人笔记。 直接把所有资料塞进提示词又不现实——上下文窗口有限，全塞进去既贵又慢。RAG（Retrieval-Augmented Generation，检索增强生成） 的思路是：先从知识库里检索出与问题最相关的几段内容，再把这几段连同问题一起交给模型生成答案。\n基本流程 RAG 分离线建库和在线问答两个阶段。\n离线：把知识切块并向量化 原始文档 → 切分成块(chunk) → 用 embedding 模型转成向量 → 存入向量数据库 切块大小是个需要权衡的参数：太大则检索不精准，太小则丢失上下文。常见做法是 300–800 字一块，并让相邻块之间有一定重叠。\n在线：检索 + 生成 用户提问 → 问题向量化 → 向量库里找最相似的 top-k 块 → 把这些块作为“上下文”拼进提示词 → 大模型基于上下文作答 一个简化的提示词模板：\n请只根据下面提供的资料回答问题。如果资料中没有答案，就说“资料中未提及”。 【资料】 {检索到的若干文本块} 【问题】 {用户的问题} 几个关键点 Embedding 模型的选择决定检索质量，中文场景要选对中文支持好的模型。 检索不只有向量：把关键词检索（BM25）和向量检索结合的「混合检索」往往效果更好。 给出出处：让模型回答时标注引用了哪段资料，既能提升可信度，也方便排查“幻觉”。 小结 RAG 不需要重新训练模型，成本低、见效快，特别适合“基于一批资料回答问题”的场景——文档问答、客服知识库、个人第二大脑，都是它的主场。\n","permalink":"https://czy168.vip/posts/rag-intro/","summary":"大模型知识有截止日期、也不了解你的私有资料。RAG 通过“先检索、再生成”让它基于外部知识回答，是目前落地最广的 LLM 应用范式之一。","title":"RAG 检索增强生成：让大模型用上你自己的知识"},{"content":"关于本站 这是一个个人技术博客，主要记录我在 AI、大模型方向的学习与实践，也会写一些日常开发中的心得。\n内容主要涵盖：\n大模型应用：RAG、提示词工程、Agent 开源模型与本地部署 AI 辅助编程的实践与思考 日常开发中的工具与踩坑记录 本站为个人非商业性质，内容仅代表个人观点，供学习交流之用。\n联系方式 如需交流，可通过站点后续公布的方式联系。\n","permalink":"https://czy168.vip/about/","summary":"关于本站","title":"关于"}]