JACIN Blog

深度的 AI 应用开发者

专注 AI 应用开发、Python 后端与工程实践,持续记录大模型落地、工具构建与真实项目经验。

183篇已发布
主题索引
查看全部分类
全部文章
183
AI 大模型开发
8 分钟

稠密向量 与 稀疏向量

这篇笔记从 RAG 检索质量出发,解释文本向量化时常见的稀疏向量与稠密向量两条路线:前者维度通常等于词汇表规模,只有少量非零值,代表方法是 BM25 和 TF-IDF;后者维度较低但几乎每一维都有实数值,常由 BERT、BGE、OpenAI Embedding 等模型生成。内容重点说明 BM25 只基于已分词后的 token 计算 TF、IDF 和文档长度分数,本身不负责分词,因此中文、日语、泰语、阿拉伯语、德语复合词等场景会受到分词或形态处理质量影响。稠密向量部分则说明 Embedding 模型通过对比学习把语义相近文本拉近、语义不同文本推远,并列出余弦相似度、点积、欧氏距离等常见匹配方式。对比部分强调稀疏检索适合专有名词、数字和明确短语,解释性强且对精确关键词敏感;稠密检索更适合自然语言和模糊语义查询,但可能在稀有词、精确匹配和算力成本上存在短板。实践建议落在混合检索:并行使用 BM25 与 Embedding 召回,再通过 RRF 等方法融合排序,借助 Milvus、Qdrant、Weaviate 等向量数据库实现更稳健的 RAG 检索链路。

向量
英语学习
3 分钟

20260203-test1

这段笔记围绕二语习得中的母语干扰展开,把学习者在理解英语时依赖中文中介的现象,放到语言学中 L1 interference 的框架下说明。内容先以一段较正式的英文自我介绍和助人定位开场,随后转入学习者对自身困境的反思:即便具备一定英语输入能力,理解过程仍可能先经过中文转换,而不是直接抵达意义。文章给出的核心判断是,这种状态并非个体异常,而是二语习得中常见且典型的阶段,关键不在于否定母语作用,而在于逐步减少对它的依赖。其解决思路强调 deliberate, sustained practice,也就是持续、有意识的练习,通过反复接触和使用英语来强化“英语形式—意义”之间的直接神经通路。文中用肌肉记忆作类比,说明直觉化理解并不是一次顿悟,而是由重复训练积累出来的加工能力。适合正在从翻译式理解转向英语直接思维的学习者阅读,可帮助他们重新定位卡顿、翻译依赖和理解迟滞等问题,并把焦点放在长期训练路径上。

英语学习
1 分钟

关于“ENGLISH-study”类别

ENGLISH-study 类别可定位为英语学习相关内容的集中归档入口,用于收纳围绕词汇、语法、阅读、听力、写作、口语练习以及学习方法整理的笔记与资料。它的价值在于把语言学习过程中的零散记录按主题沉淀下来,方便读者快速判断某篇内容是偏知识讲解、练习记录、资源整理还是学习策略。与偏技术、工具或日常随笔类内容相比,该分类应突出英语能力提升这一主线,避免把无明确英语学习目标的泛泛摘录混入其中。后续使用时可进一步明确收录边界,例如是否包含考试备考、英文资料精读、AI 辅助学英语等子话题,以及是否需要按学习阶段或技能方向拆分子类。对于正在整理个人英语学习体系、查找学习材料或复盘训练方法的读者,这一类别能提供更清晰的入口和持续积累的知识结构。

随机笔记
1 分钟

关于“个人随机 NOTE”类别

“个人随机 NOTE”适合承载作者在日常学习、使用工具、阅读资料或处理事务时形成的零散记录,重点不在系统教程或完整方案,而在保留当时的想法、片段线索和临时判断。它与专题类技术文章的区别在于结构更轻、主题更开放,内容可以是短观察、待验证的问题、经验备忘、资料索引或阶段性想法,不要求形成完整论证。这个类别的价值在于为那些暂时无法归入明确技术栈、项目复盘或知识专题的内容提供稳定入口,避免有记录价值的信息被迫拆散或遗失。使用时应尽量保持可读性,说明记录背景、触发原因和可能用途,避免只留下无法复用的碎片。若某篇 NOTE 后续扩展为完整教程、排查报告或专题文章,应迁移到更准确的类别中;若长期内容高度集中,也可以再拆分为独立主题。该类别更适合关注作者个人知识流、临时经验和思考轨迹的读者。

AI见闻
2 分钟

2026 年 海外四大前沿模型 API 成本对比(美元/百万 tokens)

这份笔记围绕 2026 年 2 月海外四大前沿模型 API 的调用成本展开,把 xAI Grok、OpenAI GPT、Google Gemini 与 Anthropic Claude 的代表型号放在同一张表中比较,核心维度包括每百万 tokens 输入价、输出价、上下文窗口和产品定位。表中最突出的结论是 Grok-4.1-fast 与 Grok-4-fast 系列以 $0.20 输入、$0.50 输出和 2M 上下文形成明显低价区间,适合高调用量、批量处理和工具调用场景,而旧版 Grok-4-0709 价格显著更高且上下文仅 256K。OpenAI 侧呈现分层策略:GPT-5.2 标准旗舰偏向编码和代理任务,支持缓存输入低价;GPT-5.2 pro 面向精密任务但成本极高;GPT-5 mini 则承担轻量快速版本的角色。Gemini 3 Pro 采用随长 prompt 变化的阶梯价格,输入约 $2.00-$4.00、输出约 $12.00-$18.00,并以 1M-2M 上下文和多模态能力作为主要卖点。Claude 4 / 3.5 Sonnet 级模型价格处在较高区间,强调高智能、安全、缓存与工具能力,同时保留 Haiku 等更廉价变体。它适合需要快速判断模型选型成本的 AI 应用开发者、后端工程师和产品负责人,用来在预算、上下文长度、智能水平与多模态或安全需求之间做初步取舍。

服务器与部署
2 分钟

常用的服务器测试脚本

这是一份面向服务器初步验收与网络排查的命令清单,集中整理了几类常见测试脚本及其适用场景。内容覆盖国际互联延迟测试、整机综合性能评估、NodeQuality 质量检测、基于 curl 的 DNS/TCP/TLS/首包/总耗时拆分、流媒体区域解锁检测、IP 信息检测以及 nexttrace 安装。每个工具都给出可直接执行的 bash 或 curl 命令,适合在新购 VPS、迁移节点、排查访问慢或确认线路质量时快速获得基础数据。文中特别提示 NodeQuality 测试较占内存,建议用 nohup 放到后台运行,并给出自动确认选项的写法,避免长时间测试中断。curl 计时命令则适合针对单个目标站点观察连接链路各阶段耗时,帮助区分解析、建连、TLS 握手和服务端响应问题。整体更像一份运维速查笔记,适合服务器使用者、个人站长和需要快速判断节点网络质量的开发者保存备用。

服务器与部署
1 分钟

dd 命令行重装系统

这是一份面向 VPS 或云服务器场景的 Debian 12 重装速记,核心做法是在当前系统中使用 root 用户下载 bin456789/reinstall 项目的 reinstall.sh 脚本,并通过脚本触发 dd/重装流程。正文给出的主流程包括先用 curl 或 wget 从 GitHub 获取 reinstall.sh,再执行 bash reinstall.sh debian 12 指定安装 Debian 12,完成安装后重启服务器。重启进入新系统后,需要运行 apt-get update -y,并安装 curl、sudo、git 等基础工具,为后续管理、脚本下载和权限操作补齐环境。文章还区分了国外服务器和国内服务器的脚本下载地址:国外可使用 raw.githubusercontent.com,国内则提供 cnb.cool 镜像地址,以降低网络访问 GitHub 失败的概率。需要注意的是,这类重装操作通常会覆盖原系统环境,正文没有展开数据备份、磁盘分区、登录凭据和救援模式等风险处理,因此更适合作为已有经验用户的命令备忘,而不是完整的新手教程。读者可以从中快速确认 Debian 12 重装的最小命令序列,以及在不同网络环境下选择脚本源的方式。

服务器与部署
6 分钟

Nginx 进行转发设置

这份笔记给出了一段面向火山引擎 Ark 服务的 Nginx 反向代理配置,用本地 8010 端口承接 `/doubao/` 路径请求,并转发到 `ark.cn-beijing.volces.com:443`。配置的核心目标是降低代理链路中的连接建立和首包等待成本:通过 `upstream` 与 `keepalive 256` 保留上游空闲长连接,配合 `proxy_http_version 1.1` 和清空 `Connection` 头避免请求后立即关闭连接。它还关闭 `proxy_buffering`、开启 `tcp_nodelay`,让响应数据尽快透传给客户端,适合对流式输出或 TTFB 敏感的 AI 接口调用场景。TLS 部分强制使用 TLS 1.3、开启会话复用,并配置 SNI 与上游 Host,确保到 Ark 域名的 HTTPS 握手和路由能够正常工作。文中同时给出 `proxy_socket_keepalive`、真实 IP 透传以及 300 秒读写超时等参数,用于减少空闲连接被中间设备切断、长时间生成过程中断的问题。需要注意的是,配置中为了追求速度关闭了上游证书校验,这会削弱 HTTPS 身份验证安全性,只适合在明确可信的转发链路和可接受风险的场景下使用。整体上,它更像是一份针对 AI 服务反代的低延迟配置清单,适合需要用 Nginx 统一入口、隐藏上游地址或优化接口访问稳定性的后端与运维读者参考。

AI见闻
10 分钟

gemini cli 的提示词 gemini.md 文档

这份 GEMINI.md 是一套面向 Gemini CLI 的个人级工作规则配置,目标是把 AI 编码助手从“即时问答”约束为有流程、有质量门槛、可记录的工程协作系统。正文围绕质量第一、中文交流、思考先行、工具优先和透明记录建立基本行为准则,并进一步把架构设计、代码质量、性能意识、测试覆盖、静态检查等要求写成执行标准。工具部分给出了较明确的 MCP 选择策略:复杂任务用 shrimp-task-manager 或 TodoWrite 管理,本地代码检索和命令执行优先 Desktop Commander,文档查询使用 Context7、Microsoft Docs、DeepWiki 或 DuckDuckGo,复杂规划则依赖 Sequential Thinking 与 Memory。规则还按紧急修复、新功能、重构和学习探索区分流程强度,并设置任务开始、编码前、实施中、完成后的检查点,要求读取记忆、确认降级方案、记录决策、验证测试并更新经验。后半部分重点限定 MCP 调用边界,包括每轮最多一个服务、串行调用、最小查询范围、失败退避、降级链路、敏感信息禁用和统一的“工具调用简报”格式。末尾的终端片段说明该文件位于用户主目录下的 .gemini 配置目录,适合希望定制 Gemini CLI 行为、规范 AI 辅助开发流程、减少盲目调用外部工具的开发者参考。

使用 CLIPROXY AI 进行 qwen-code 免费反代
AI见闻
2 分钟

使用 CLIPROXY AI 进行 qwen-code 免费反代

这是一篇面向 Claude Code 用户的本地反代配置笔记,目标是用 CLIPROXY AI 将 qwen-code 相关模型接入到本机服务,再让 Claude Code 通过 Anthropic 兼容环境变量调用。正文给出的流程从下载 CLIProxyAPI release 开始,按 config.example.yaml 创建或调整 config.yaml,并重点放开 secret-key、api-keys 以及 qwen 模型配置,把 qwen3-coder-plus 设置为可通过 qwen-plus 访问的别名。作者同时提示可以借助 CLIPROXY 的 web-ui 查看或辅助确认配置状态,而不是只依赖手工编辑文件。接入 Claude Code 时需要先安装并运行 npx @z_ai/coding-helper,因为这里强调不能直接编辑 settings.json,而是让 z-ai 帮助处理反代相关写入。最终 ~/.claude/settings.json 中需要设置 ANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL 指向 http://127.0.0.1:8317,并把 Haiku、Sonnet、Opus 默认模型分别映射到 qwen3-coder-flash 或 qwen-plus,同时提高 API_TIMEOUT_MS、关闭非必要流量。适合已经在使用 Claude Code、想尝试本地代理接入 qwen-code 模型的开发者参考,重点价值在于给出了最小改动项和环境变量落点,但前提是读者已理解本机代理、token 与模型别名之间的对应关系。

claude code 配置GLM 4.7(其他中转站)
AI见闻
4 分钟

claude code 配置GLM 4.7(其他中转站)

这是一篇面向 Claude Code 用户的接入配置笔记,重点放在如何把本地 Claude Code 指向 GLM 4.7 或自建/第三方 Anthropic 兼容中转站。正文先给出全局安装与更新方式,包括 npm 安装、claude update,以及 macOS、Linux、WSL 和 Windows 下的官方脚本安装命令,并用 claude --version 作为安装成功的验证依据。配置部分提供两条路径:使用 npx @z_ai/coding-helper 打开可视化工具,或直接编辑 ~/.claude/settings.json,设置 ANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL、API_TIMEOUT_MS、禁用非必要流量以及 Haiku、Sonnet、Opus 的默认模型映射。示例中 BigModel 的 Anthropic 接口地址被配置为 GLM 4.7 的调用入口,而自有中转站示例则展示了替换 Base URL、模型名、model、effortLevel 和 permissions 的写法,并说明 bypassPermissions 会跳过确认提示。文章还提醒可通过启动 claude 后查看 /status 来确认模型映射是否生效,同时补充 Claude.md 作为 Claude Code 长期记忆和规则文件的作用,适合需要快速落地中转站配置、理解关键环境变量含义的开发者参考。结尾给出一个外部链接,用于进一步判断中转站是否属于“纯血 Claude”操作,但正文没有展开验证方法本身。

容器与云原生
2 分钟

使用 stern 查看 k8s 多 Pods 日志

这是一篇面向 Kubernetes/k3s 日志查看场景的 stern 使用笔记,聚焦在需要同时观察多个 Pod 日志、并在滚动重启后保持日志连续性的日常排查需求。正文先给出 Linux 环境下从 GitHub release 下载 stern 1.33.1、解压、赋权、移动到 /usr/local/bin 并用 stern --version 验证安装的完整命令。随后说明 stern 与 kubectl 一样默认读取本机 K8s 配置,因此在 k3s 环境中可以通过 --kubeconfig /etc/rancher/k3s/k3s.yaml 临时指定配置,也可以把 KUBECONFIG 写入 ~/.bashrc 让后续命令永久生效。示例以 ragapi 为匹配对象,展示 stern ragapi --tail 20/50 这类命令如何聚合查看相关 Pod 的最近日志。文章还强调 stern 相比普通 kubectl logs 的两个实用差异:它会用不同颜色区分不同 Pod,便于定位报错来源;在 rollout restart 后也能自动发现新 Pod 并接续日志流,减少重复执行命令的麻烦。最后补充了按正则包含 error、exception 以及用 -v 排除 GET /health 等噪声日志的过滤方式,适合运维、后端开发或使用 k3s 部署服务的开发者快速整理多实例日志排查流程。

文章归档
183