#优质博文 #编程语言 #AI #软件工程
有点子感慨呢，不过话说回来 JS 和 TS 是不是得看合起来的排行（x）
（这种榜单基本上图一乐，真用啥是无所谓的，语言都是相通的）

IEEE 发布了 2025 年顶级编程语言的榜单，Python 再次蝉联第一，JavaScript 和 TypeScript 分别位列第 6 和第 7。

The Top Programming Languages 2025

AI 摘要：文章介绍了 2025 年最新的编程语言排行榜，并指出 Python 继续保持第一；与此同时，JavaScript 的影响力下降。作者进一步探讨了 AI（尤其是大型语言模型 LLM）的崛起如何改变了编程生态，使程序员更少依赖公共知识平台，导致传统衡量语言“流行度”的指标逐步失效。更深层次的趋势是：随着编程被 AI 辅助或部分取代，编程语言的差异性和重要性正在逐渐削弱，程序员未来的价值或将转向算法设计、系统架构与领域知识，而非语言本身。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 2025 年编程语言排行榜与现状
• Python 再次蝉联第一，且在 Jobs 排名中超越 SQL 位列首位
• JavaScript 从第三名跌至第六，或受 AI 辅助网站开发的影响
• SQL 技能依然是职场硬通货

2. 流行度测量的困境
• 排行使用多源指标：Google 搜索、Stack Exchange、GitHub 开源活跃度、论文提及等
• AI 助手 (Claude, ChatGPT, Cursor) 改变了程序员获取知识的方式
• Stack Exchange 提问量锐减至去年同期的 22%，公开数据信号衰弱

3. AI 对语言的重要性削弱
• AI 承担语法、结构甚至函数编写，弱化了语言细节的意义
• 未来选择语言可能等同于选择 CPU 指令集般无关紧要
• 新语言难以获取足够的训练数据支撑，不易突破 AI 劣势

4. 新语言诞生的障碍
• 过去依靠书籍、教程与社区 evangelism 推动采用
• LLM 需要海量样本，小众语言表现不佳
• AI 消融了过去促使新语言诞生的“语言痛点”

5. 编程语言的未来角色
• 高级语言本质是抽象与防止“自废武功”，历史源于结构化编程运动
• 硬件层仍然是“Go To”逻辑，AI 或直达中间表示 (intermediate representation)
• 未来可能不需要传统高级语言，转向 prompt → 中间语言 → 编译

6. 程序员角色与教育转变
• 程序员未来关注点转向算法选择、软件架构、系统接口
• 计算机科学教育因注重基本原理而更具价值，相对高于短期 bootcamp 培训
• 未来衡量流行度需探索全新指标

IEEE Spectrum

The Top Programming Languages 2025

Python reigns supreme again, but is AI changing the game for programming languages? Find out how coding is transforming.

#优质博文 #Chrome #DevTools #AI #MCP #前端 #CSS #浏览器
最近比较忙，这个发的有点晚了～不过大家应该都看到了～
Chrome DevTools (MCP) for your AI agent

AI 摘要：本文介绍了 Chrome 新发布的 DevTools MCP 服务，它通过 Model Context Protocol (MCP) 将大型语言模型 (LLM) 与 Chrome DevTools 连接，使 AI 编程助手能够实时调试网页、诊断错误、模拟用户操作、分析性能问题等，从而提升生成代码的可用性和准确性。文章同时提供了使用场景示例、配置方法以及社区参与途径。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 背景与意义
• AI 编程助手生成代码时往往无法看到运行效果，相当于“蒙着眼睛编程”。
• Chrome DevTools MCP 服务解决了这一问题，直接让 AI 编程助手接入浏览器调试环境。

2. Model Context Protocol (MCP) 概述
• MCP 是一个开源标准，用于连接大型语言模型 (LLM) 与外部工具和数据源。
• Chrome DevTools MCP server 将调试与性能分析能力引入 AI agent。
• 示例工具：performance_start_trace，可自动启动 Chrome 并记录性能数据以供分析。

3. 应用场景与示例
• 实时验证代码修改：AI agent 可直接在浏览器中确认修改是否生效。
• 诊断网络与控制台错误：AI 可检查网络请求和日志，排查如 CORS 问题。
• 模拟用户行为：自动执行表单填写、点击测试，复现功能性 bug。
• 调试样式与布局问题：实时检查 DOM 和 CSS，解决复杂样式错误。
• 自动化性能审计：运行性能追踪，分析如 LCP (Largest Contentful Paint) 等指标。

4. 使用与配置方法
• 配置方式：在 MCP client 中添加 chrome-devtools 服务。
• 测试示例：运行 prompt "Please check the LCP of web.dev."。
• 更多工具参考：见 tool reference documentation。

5. 社区参与与后续发展
• 当前为公测版本，功能会逐步增加。
• 欢迎开发者与厂商反馈需求与问题。
• 参与方式：通过 GitHub issue 提交建议或 bug。

author Mathias Bynens, Michael Hablich

Chrome for Developers

Chrome DevTools (MCP) for your AI agent  |  Blog  |  Chrome for Developers

Public preview for the new Chrome DevTools MCP server, bringing the power of Chrome DevTools to AI coding assistants.

#优质博文 #AI #PromptEngineering
GPT-5-Codex Prompting Guide | OpenAI Cookbook

AI 摘要：本文介绍了 GPT-5-Codex 的特点与最佳提示实践，强调该模型在交互式与代理型编程任务中的独特优化。与通用 GPT-5 相比，其提示设计遵循“少即是多”，减少额外指令和冗余说明。文档详细说明了 CLI 环境下的开发者消息规范、工具权限设置、代码审查方法，以及避免过度提示的反向调优策略，帮助开发者更高效利用 GPT-5-Codex 进行真实世界的软件工程。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 模型介绍与定位
• GPT-5-Codex 并非 GPT-5 的直接替代品，而是为 agentic coding 与交互式任务优化。
• 在 Responses API 下支持使用，但不支持 verbosity 参数。
• 专注于真实软件工程场景：快速交互与长时段独立任务皆擅长。

2. 模型核心优势
• 改进的可控性（steerability）：在功能开发、调试、测试、重构和代码评审中更高效。
• 自适应推理（adaptive reasoning）：根据任务复杂度调整响应速度与深度。
• 出色的代码评审能力：能检查代码库并运行测试以验证正确性。

3. 提示词设计原则
• 遵循“less is more”策略：提示词应尽量简洁。
• 移除不必要的序言（preambles），避免模型提前中止输出。
• 工具使用应限制在 terminal tool 与 apply_patch，并保持描述简洁。
• Codex CLI 的开发者提示比 GPT-5 标准提示精简约 40%。

4. Codex CLI 使用规范
• Shell 调用规范：推荐使用 bash -lc，设置 workdir 参数，优先使用 rg。
• 编辑约束：默认 ASCII，谨慎处理非 ASCII 字符，避免回退用户未要求的改动。
• 规划工具使用：非简单任务才使用，避免生成单步骤计划。
• 沙箱(sandbox)与权限策略：详细定义了文件系统、网络与命令权限的审批机制。

5. 特殊请求处理
• 简单查询用 shell 命令直接解决（如 date）。
• 代码评审流程：先列出问题、风险与缺陷，再简要总结。
• 呈现结果时避免冗余输出，注重可读性与协作感。

6. 输出与风格规范
• 输出为纯文本，适当使用代码块、斜体、行内代码。
• 遵循简洁、协作的语气；优先逻辑清晰而非机械化格式。
• 文件路径引用需独立，遵循特定格式（src/app.ts:42）。

7. Anti-Prompting（避免额外提示的策略）
• 自适应推理已内置，无需额外提示“思考更深”或“快速回答”。
• 长任务规划能力已训练，不需额外计划引导。
• 不生成 preamble，只有必要时才总结。
• 前端默认采用现代最佳实践，可通过短指令指定框架与库（如 React + TypeScript + Tailwind CSS）。

author OpenAI Cookbook Team

Openai

GPT-5-Codex Prompting Guide | OpenAI Cookbook

Important details about GPT-5-Codex and this guide: This model is not a drop-in replacement for GPT-5, as it requires significantly diffe...

#优质博文 #科研工具 #AI #文献管理 #学术搜索
WisPaper：搜、问、读，陪你一起搞科研的专业Agent

AI 摘要：WisPaper是复旦大学研发的一款免费AI学术工具，旨在帮助科研人员解决文献检索和阅读难题。它提供AI智能搜索功能，能精准查找海外权威期刊，并支持本地文件库的智能搜索。此外，WisPaper还能进行文献深度对话、精准翻译以及一键提炼文献核心论点、研究方法和关键结论，显著提高科研效率。

author 小众软件

WisPaper

WisPaper | Scholar Search, Literature Review, AI Research Feeds

WisPaper provides scholar search, literature review assistance, and AI-powered paper feeds. Screen 1,000 papers in seconds, find 20 must-read studies, and stay updated with research tailored to your interests.

#优质博文 #AI #MCP #新动态 #开源
GitHub 推出官方 MCP Registry，统一入口快速发现和使用 MCP servers。
Meet the GitHub MCP Registry: The fastest way to discover MCP Servers

AI 摘要：本文介绍 GitHub 推出的 MCP Registry，旨在解决以往 MCP servers 分散、难以发现和管理的问题。通过集中托管与社区协作，开发者可以在一个统一平台上更快找到所需工具，与 GitHub Copilot、VS Code 等生态无缝集成。文章强调该平台对开放互操作标准的贡献，以及合作伙伴（如 Figma、Postman、HashiCorp、Dynatrace 等）所带来的典型应用场景，展示 MCP Registry 在推动 agentic workflows 与 AI 生态健康发展的重要性。

GitHub

MCP Registry

A faster, safer way to build with AI: the GitHub MCP Registry centralizes MCP servers for effortless discovery, integration, and open collaboration.

#优质博文 #AI #NLP #LLM #OpenAI
Why language models hallucinate

AI 摘要：本文由 OpenAI 团队撰写，深入探讨了大语言模型(LLM)产生“幻觉”的根本原因，指出是现有训练与评估机制奖励了“猜测”而非“不确定性表达”。作者通过统计学视角分析幻觉来源，强调优化 eval (评估机制) 比单纯提升模型规模更关键，并提出需惩罚“自信的错误”，奖励恰当的不确定性表达，以推动模型更可靠和更安全。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 幻觉(hallucinations)的定义与案例
• 幻觉是语言模型生成的“貌似合理但错误”的信息。
• 案例：模型对作者的博士论文题目或生日给出多个版本，全部错误。

2. 评估体系的问题 (“Teaching to the test”)
• 现有 eval 大多单纯以“准确率”为指标，导致模型倾向于胡乱作答，而不是坦率回答“不知道”。
• 类似选择题考试：盲目猜测在统计上可能比“空白不答”获得更高分数，因此模型被激励去猜。
• OpenAI 强调“谦逊”(humility)，并提出评分机制应惩罚错误多于不答，并鼓励表达不确定性。

3. 幻觉的来源机制：下一词预测 (next-word prediction)
• 预训练阶段仅基于预测下一个词，没有“真/假”标注，导致难以区分真伪信息。
• 高频模式(如拼写规则)能被可靠学习，但低频事实(如生日)因缺乏规律难以预测，从而引发幻觉。
• 低频信息与统计不可预测性导致某些类型的幻觉难以通过规模化完全消除。

4. 常见误解与澄清
• “准确率提升后幻觉会消失”：错误，因为真实世界存在无法回答的问题，因此准确率永远无法达 100%。
• “幻觉无法避免”：错误，模型可以选择“不回答”。
• “避免幻觉需更大模型”：错误，小模型有时更容易知晓自身局限。
• “幻觉是神秘 bug”：并非，已有对其统计学成因的理解。
• “仅需开发新的幻觉评测方法”：不够，只有重构主流 eval，奖励不确定性才能系统性减少幻觉。

5. 结论与未来方向
• 幻觉是评估体系与预测机制共同作用的必然产物。
• 通过惩罚“自信错误”、奖励“不确定性表达”，可以有效降低幻觉发生概率。
• OpenAI 新模型 (如 GPT‑5) 显著减少幻觉，但该问题仍是 LLM 的核心挑战，研究仍在持续推进。

author OpenAI

Openai

Why language models hallucinate

OpenAI’s new research explains why language models hallucinate. The findings show how improved evaluations can enhance AI reliability, honesty, and safety.

#优质博文 #AI #上下文工程 #LLM
几天前就想发了，忙忘了，很棒的一篇文章。

谈谈 AI 编程工具的进化与 Vibe Coding：区分 Vibe Coding 与 Context Coding，系统梳理 Copilot、Cursor、Claude Code 的上下文工程（Context Engineering）路径与实践取舍，并给出可操作的方法论与职业思考

AI 摘要：指出 Vibe Coding 短期易致缺陷与安全问题、长期堆积技术债；职业上，中位“翻译者”型编程会被挤压，具抽象能力或商业与独立开发能力者将受益，持续学习与上下文工程将决定竞争力。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 术语澄清与立场：Vibe Coding vs Context Coding
• Vibe Coding 的原始内涵：忘记代码存在、全对话驱动、不看 diff、一次性项目可用但有趣而不严肃。
• 混用导致争论，应区分：Vibe Coding（对话式全托管）与 Context Coding（上下文驱动的 AI 辅助编程）。

2. Context Coding 的核心：上下文工程（Context Engineering）
• 除大语言模型（LLM）能力外，关键在于“如何给到合适的上下文”。
• Chat、RAG、Rules、MCP、文档接入等，实质都是提升上下文质量与可控性。

3. GitHub Copilot：从窗口上下文到补全范式
• 优点：将当前文件上下文提供给 LLM；基于注释的补全提升效率。
• 局限：模型能力与上下文长度受限、跨文件理解弱、早期无法直接编辑代码、需人工复制粘贴。

4. Cursor：从补全到“编程智能体”
• 能力叠加：专用 Tab 模型 + Claude 3.5 Sonnet，速度与质量同步提升，支持直接编辑。
• 上下文工程：对 codebase 做 RAG 索引，语义检索多文件上下文；@ 文件/目录、Git 历史、文档索引、Rules 保持风格一致性。
• 场景覆盖：跨文件调用、多文件修复、模块重构、功能新增。
• 商业取舍：次数/速率/模型自动降级等策略影响体验，存在波动。

5. Claude Code：命令行范式与“量大管饱”的上下文
• 全局分析：开场即扫描项目结构与技术栈，耗费 tokens 换来更贴合原项目规范的输出。
• 检索策略：采用 grep/find/git/cat 等 Unix 工具代替 RAG，更符合工程师的搜索路径。
• 争议对比：RAG 注重召回广覆盖但精度与时效可能不稳；grep 精度高匹配业务上下文但对话轮次与 tokens 消耗更多。
• 适配生态：天然契合 bash、MCP、CI/CD 与 DevOps 自动化的脚本化工作流。

6. 如何更好地进行 Context Coding（实践清单）
• 规则文件：提供技术栈、目录结构、命名约定与用途（.github/copilot-instructions.md、.rulers、CLAUDE.md；可用 Ruler 统一管理）。
• 上下文建模：常用脚本（install/lint/test/build）、工具类、核心模块/方法的清单与定位。
• 开发流程：需求拆分为子任务、记录进度、渐进式修改与小步提交、优先可读性与一致性、函数聚焦单一职责。
• 调试与知识更新：以日志替代 IDE 调试；用 MCP/context7 接入最新文档与浏览器/网络日志，降低训练数据过时风险。
• 风险提示：上下文不是越多越好；易变信息需及时维护，否则误导大于帮助。

7. 个人实践与取舍
• 严肃工程偏好 Tab 补全，由人控抽象与分层，效率更稳定。
• Claude Code 适合陌生代码库的全局理解与不熟技术栈任务。
• 工具中立：择善而用，不做工具信徒；LLM 正改变调试与一次性代码的工作习惯。

8. Vibe Coding 的风险与案例
• 风险画像：短期带来缺陷与安全漏洞，长期堆积技术债、可理解性与稳定性下降。
• 反面案例：Leo 使用 Cursor 全程 Vibe Coding，上线后遭攻击与越权，最终关停并复盘“生产环境不应部署不安全代码”。
• 正面机会：levelsio 以 100% AI + Cursor + Grok 3 做 MMO，17 天达 100 万美元 ARR；但其自身具接管能力与经验。
• 职业演进：LLM 蚕食“翻译者”型编程，中位岗位被压缩；顶尖工程师与具商业/营销能力的开发者将受益；独立与小团队更主流。

9. 结语与方法论走向
• LLM 能力与上下文工程相辅相成；上下文管理与可视化（如 /context）是关键产品力。
• 谁能提供“更好上下文 + 更好控制”，谁就更可能在 AI 编程时代胜出。

author Guangzheng Li

Guangzhengli

谈谈 AI 编程工具的进化与 Vibe Coding

#优质博文 #新动态 #后端 #数据库 #ORM #Prisma #AI
Vibe Coding 给 Prisma 都整的加了个安全护栏了（草
太体贴了哥（
Release 6.15.0 · prisma/prisma

AI 摘要：本次版本聚焦稳定性与平台适配：为可能由 AI 代理触发的破坏性命令加入安全确认护栏；统一 prisma-client 运行时选项并允许无模型 schema 生成客户端；提供与 Vercel Fluid 的连接池托管方案；宣布 Prisma Postgres Management API 达到 GA 并接入 Pipedream；为 npx create-db 新增 --json 输出；强化 Prisma Postgres 直连能力，接近 GA，同时继续提供企业级支持服务。

1. 亮点
• AI 安全护栏：CLI 识别常见 AI 代理（如 Claude Code、Gemini CLI、Qwen Code、Cursor、Aider、Replit），对 prisma migrate reset --force 等破坏性操作要求显式确认，避免 AI 自动执行不可逆数据库重建。文档
• prisma-client 运行时与 schema 灵活性：
• 运行时输入统一：node 移除改用 runtime = "nodejs"；deno-deploy 移除改用 runtime = "deno"；vercel 替换为 runtime = "vercel-edge"；edge-light 作为 vercel-edge 的别名。
• nodejs、deno、bun 共用内部代码路径但保留独立输入值；VS Code 扩展已同步更新。
• 支持的运行时为：nodejs、deno、bun、workerd（alias cloudflare）、vercel-edge（alias edge-light）、react-native。
• 生成阶段改进：即使 schema 无模型也可用新生成器 prisma-client 成功生成客户端（与旧 prisma-client-js 一致）。文档
• 与 Vercel Fluid 协作：为解决无服务器挂起导致的连接泄漏，结合 Vercel attachDatabasePool 与 Prisma driver adapters，挂起前释放空闲连接，防止耗尽连接池；提供 pg + PrismaPg 的示例用法。Vercel 介绍 · 部署文档

GitHub

Release 6.15.0 · prisma/prisma

Today, we are excited to share the 6.15.0 stable release 🎉
🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!
Highlights
AI safety guardrails for d...

#优质博文 #DevOps #GitLab #AI
Automating Code Quality and Security Fixes with Codex CLI on GitLab | OpenAI Cookbook

AI 摘要：文章演示如何在 GitLab CI/CD 中集成 OpenAI 的 Codex CLI，为代码合并请求自动生成 CodeClimate JSON 的代码质量报告，并对现有 SAST 结果进行去重、优先级排序与给出可操作的修复建议，进一步自动产出可验证的 git 补丁；通过严格的提示词、JSON 标记、模式校验与 diff 校验等守护栏，使 LLM 推理成为可落地的 DevSecOps 流水线能力，补强而非替代传统规则引擎。

author OpenAI Cookbook

Openai

Automating Code Quality and Security Fixes with Codex CLI on GitLab | OpenAI Cookbook

When deploying production code, most teams rely on CI/CD pipelines to validate changes before merging. Reviewers typically look at unit t...

#优质博文 #AI #前端 #Chrome
Designing the Built-in AI Web APIs

AI 摘要： 本文由 Chrome 团队成员撰写，详细阐述了新一代内置 AI Web APIs（如 Prompt API、Summarizer、Translator 等）的设计思路与挑战。文章探讨了如何在快速演进的 AI 技术环境中，平衡 API 一致性（interoperability） 与 未来兼容性（futureproofing） 的需求，并分析了客户端优先的设计与传统 HTTP API 的差异，最终提出了一种具备状态管理、可扩展性和跨浏览器统一性的架构思路。

1. API 设计背景与挑战
• Chrome 推出一系列内置 AI APIs，目标是成为 Web 平台的标准库，被各大浏览器采纳。
• 与传统 Web API（如 USB、Payment、Codecs）不同，AI APIs 缺乏长期先例，且领域演进极快。
• 特别关注 Prompt API 的复杂性与标准化问题。

2. Prompt API 的设计核心
• 借鉴已有生态，采用对话消息数组模型（user、assistant、system 三种角色）。
• 主要挑战包括：
• 多模态输入输出（text、image、audio 等）。
• 约束条件（是否允许多条 system 消息、重复 assistant 消息等）。
• 语义一致性（拼接消息 vs 多条分离消息）。
• 简写形式（role 省略、直接输入字符串等）。
• Chrome 方案：统一为 {role, content: Array<{type, value}>, prefix?} 的标准格式，并增加约束规范。

3. 客户端优先 vs 服务端 API
• 传统 HTTP API 往往 stateless，依赖 JSON 与 HTTP 调用；而 Web API 则以 JavaScript 调用、支持 on-device 模型为核心。
• 优势：
• 使用原生对象类型（如 ImageBitmap、AudioBuffer），规避 base64 冗余。
• 工具调用通过 async Promise 方式隐藏复杂度。
• 设计为 有状态 API：
• LanguageModelSession 管理会话，支持 append()、clone()、destroy() 和 AbortSignal。
• 改善资源管理与性能，但需处理 context window 溢出机制。

4. 互操作性 (Interoperability) 与未来兼容性 (Futureproofing)
• 挑战：不同浏览器可能使用不同模型，API 需保证代码不因模型差异而崩溃。
• 解决策略：
• 引导开发者使用 结构化输出（JSON Schema、RegExp 约束）。
• 每个任务型 API 设计独立入口，允许底层模型自由组合（如 LoRA 扩展、语言包下载）。
• API availability() 与 create() 方法帮助开发者预判功能是否可用，降低模型差异带来的不确定性。
• Translator API 示例：对开发者暴露 {sourceLanguage, targetLanguage}，内部可实现 pivot language 策略（实际通过英文中转），保证未来兼容。

5. 仍在探索的前沿问题
• Sampling 参数扩展：Top-K、temperature、Top-P、repetition penalty 的标准化。
• 设备约束：隐私/性能可能要求 on-device 模型或 GPU 模型，如何给予开发者适度控制。
• Prompt injection 安全性：如避免任务 API 被恶意文本指令干扰。

6. 总结与展望
• 内置 AI APIs 是 Web 平台延续生态开放战略的一环，类似暴露硬件/系统能力。
• AI 发展过快，Web 可能被迫扮演“慢速跟随者”，标准化存在滞后。
• 核心疑问：Web 能否跟上前沿 AI 的实时交互与推理进展，还是只能在多年后提供简化、抽象的最低共同标准？

author Domenic Denicola (Chrome AI Web APIs 团队)

Domenic Denicola

Designing the Built-in AI Web APIs

Creating web standards for AI models means wrestling with questions that didn't exist two years ago. Here's what I've learned building the prompt API and its siblings.

#碎碎念 #AI
关于 Cursor 定价调整的说明，在工作群给不了解的同事发了下总结，也同步一下这里。

Cursor 的定价列表：https://docs.cursor.com/zh/account/pricing

Cursor 的定价曾经调整过很多次，被骂惨了。最早是随便用，pro 就可以，每月 500 次快速请求用完了会进入慢速请求模式但是还是能用。后面调了好几次，慢慢变成请求计费取消慢速请求，现在变成了：

Cursor 的定价列表：https://docs.cursor.com/zh/account/pricing

Pro ($20/月)：适合主要使用 Tab 功能，偶尔使用 agent 的
Pro+ ($60/月)：适合几乎每个工作日都使用 agent 编程的用户
Ultra ($200/月)：适合使用 agent 完成大部分编程工作的高级用户

请求限制是：

Pro：约 225 次 Sonnet 4 请求，约 550 次 Gemini 请求，或约 650 次 GPT 4.1 请求
Pro+：约 675 次 Sonnet 4 请求，约 1,650 次 Gemini 请求，或约 1,950 次 GPT 4.1 请求
Ultra：约 4,500 次 Sonnet 4 请求，约 11,000 次 Gemini 请求，或约 13,000 次 GPT 4.1 请求

官方还说「像 Opus 4 这样的模型每次请求消耗更多令牌，比其他模型更快达到使用限制。我们建议有选择性和有意识地选择这些模型。」就是烧不起 token 了

超过就会转很笨的 auto 模型，或者开 max 模式按量付费，所以现在 Cursor 不划算了，对于开发来说只用 tab 就够了。

Teams 版本就是按人头计费， 40 美元/月
「团队席位每月为每个用户提供 500 个请求。每次使用代理时，大多数模型将消耗一个请求。少数模型成本更高：
当您启用思考功能时，Sonnet 3.7 和 Sonnet 4 消耗两个请求。
MAX 模式定价基于令牌计算，根据模型提供商的 API 价格。」

省流的话，就是现在个人档/团队档位是按请求次数计费，加钱加档位只是免费请求的量会更多，没有任何新功能，所有档位都包含所有功能，超过免费量就会转很笨的 auto 模型，或者开 max 模式按 token 付费。

官方似乎也意识到了这点，现在还专门在定价说明里强调 20 刀的版本「适合主要使用 Tab 功能，偶尔使用代理的用户」

该跑路的应该在七月份的定价调整的时候就跑路了吧 23333，感觉现在留下的都是离不开他的 tab 的。

Cursor

Cursor – 模型与定价

Cursor 的方案与定价

cosine - 前端人の日常频道

#折腾 #碎碎念 #插件 #浏览器插件 #开源 Moe Copy AI 又更了一点东西，现在能抓到更多网站结构了～试了一周还是蛮爽的，商店还在审核。（为什么这个点发啊我没救了） • 新增了 Readability 抓取模式，用 Mozilla Firefox 阅读模式的核心算法 @mozilla/readability，也保留着原来的选择器模式。 • 新增全屏预览，预览抓取到的 Markdown 内容时支持全屏预览 Release 0.1.6 下一步想加个预设提示词管理切换的功能（

#碎碎念 #AI
说起来这个项目也算是经历了 cursor 写代码和 claude code 写代码的迭代，有点感慨，新功能就是用 claude code 加的，claude code 还是太强了，以前 cursor 还没降智的时候 agent 搭的架子和 UI 写的这些在 claude code 管理的时候感觉井井有条多了，打算认真做个文档站加个国际化对待一下了www

不过测试他还是会糊弄我 😡 无所谓了后边再检查，用出问题了再修！

作为一个纯个人项目来说我还是挺喜欢的，比起之前那些更个人的项目来说，因为真能帮到我不少。

POLEBUG - WHAT ARE YOU THINKING?

聪明的 claude code 已经一去不复返了 😭😭😭 好想念一开始用 claude code 的效果啊啊啊

#AI #碎碎念
我也有这种感觉……感觉一开始用的时候正好赶上巅峰时期了 🥲
现在让他重构有时候会：？写的这是什么玩意儿。
虽然还是很好用但是确实没之前那么聪明了，这种服务难道都逃脱不了降智的命运吗 QAQ

#碎碎念 #AI
最近也开始经常碰到 claude code 的防沉迷 limit 了，尽管经常用 compact 和 clear，有点纠结要不要开第二个 pro ，max 以我用的程度貌似也没必要，我一般还是两者结合着用，ai 跑代码的时候我 review。

#碎碎念 #开源 #tools #AI
我记得之前好像有群友有类似需求（？

https://fixupx.com/GitHub_Daily/status/1955570022807441512

http://github.com/omnara-ai/omnara
GitHubDaily(@GitHub_Daily): 在 Claude Code、Cursor 上执行长时间开发任务，然后转头去干别的事情，几个小时后，却发现卡在某个报错上，非常浪费时间。

面对这个痛点，Omnara 开源项目巧妙地监控它们执行的每一个步骤，然后推送给我们查看实时观察。

并可在手机上接收推送通知，关键的任务节点进展随时查看，当它们需要指导时，还能直接从手机回应。

GitHub：http://github.com/omnara-ai/omnara

主要功能：

- 实时监控所有 AI Agent 的工作进展和操作步骤
- 移动端推送通知，AI 需要帮助时立即提醒
- 支持从手机远程启动和控制 AI Agent 任务
- 统一管理界面，集中查看多个 AI Agent 状态
- 双向交互问答，随时为 AI 提供指导和反馈
- 与 MCP 协议兼容，支持自定义扩展

目前已支持 Claude Code、Cursor、GitHub Copilot 等主流编程工具，并提供了 iOS 手机客户端。

FixupX

GitHubDaily (@GitHub_Daily)

在 Claude Code、Cursor 上执行长时间开发任务，然后转头去干别的事情，几个小时后，却发现卡在某个报错上，非常浪费时间。

面对这个痛点，Omnara 开源项目巧妙地监控它们执行的每一个步骤，然后推送给我们查看实时观察。

并可在手机上接收推送通知，关键的任务节点进展随时查看，当它们需要指导时，还能直接从手机回应。

GitHub：http://github.com/omnara-ai/omnara

主要功能：

- 实时监控所有 AI Agent 的工作进展和操作步骤
- 移动端推送通知，AI…

#技术科普 #AI #LLM #course #开源
karminski/one-small-step

AI 摘要：karminski/one-small-step 是一个技术科普教程项目，旨在以简洁易懂的方式解释有趣且前沿的技术概念和原理，每篇文章力求在 5 分钟内阅读完毕。项目内容涵盖人工智能（AI）、数学、系统和硬件等多个领域，并计划保持每周不低于 3 篇的更新速度，旨在帮助读者快速掌握复杂的技术知识。

author karminski-牙医

GitHub

GitHub - karminski/one-small-step: 这是一个简单的技术科普教程项目，主要聚焦于解释一些有趣的，前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。

这是一个简单的技术科普教程项目，主要聚焦于解释一些有趣的，前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。 - karminski/one-small-step

#AI #新动态
想了想还是发一下，毕竟 OpenAI 终于发了呢
https://openai.com/open-models

gpt-oss-120b 激活参数量 5.1B
gpt-oss-20b 激活参数量 3.6B
两个都是 MoE 架构的推理模型.

https://fixupx.com/karminski3/status/1952828063374557618

karminski-牙医 (@karminski3): 就在刚刚 OpenAI 发布了两个开放权重模型! 给大家带来深度解析!

gpt-oss-120b 激活参数量 5.1B
gpt-oss-20b 激活参数量 3.6B

两个都是 MoE 架构的推理模型.

首先, 这两个模型发布的就已经是量化版本了, 他们的 MoE 层直接用 MXFP4 精度训练的! 这意味着暂时没有办法微调这两个模型了 (现有微调框架不支持, 得等等).

然后, 大家肯定知道 OpenAI 搞了各种奇怪的命名, 比如 O3-mini-high, 这个 high 是啥? 现在答案揭晓, OpenAI 的模型是可以配置推理努力程度的. 分为三档, low, medium, high. 当然 high 模式下跑分最高, 相对的思考时间更长.

Agent 功能适配得非常好, 原生针对 function call, 网页浏览, 执行 python 代码, 各种结构化输出进行了优化. 这也能从从跑分上看出来, 使用 tool 后分数均有提升.

Openai

Open models by OpenAI

Advanced open-weight reasoning models to customize for any use case and run anywhere.

#博客更新 #AI
我的 Claude Code 使用小记
哎呦每次都很纠结丢哪个博客链接（x
我好鸽子精啊，赶紧把新博客搞好不就不用纠结了。
本篇没什么干货，只有一些小技巧记录～

hexo 博客 | astro 博客 | xLog

cos

我的 Claude Code 使用小记 | 笔记 / AI | 余弦の博客

cosSpace 是基于 Next.js (App Router)、Typescript、React 和 Tailwind 开发的个人空间，是 cos_blogs 的重构版，为用户提供同时拥有博客和个人空间的平台。

#优质博文 #AI #ClaudeCode #VSCode #course
我现在也是这个流程了，不过我是不用 --dangerously-skip-permissions，rm 权限不敢给。

How I use Claude Code (+ my best tips)

AI 摘要：本文作者作为 Claude Code 的深度用户，详细介绍了自己从 Cursor 转向全程使用 Claude Code 的开发体验，总结出一系列高效实用的使用建议。文章覆盖了 Claude Code 的 VS Code 插件启动、终端界面、权限系统、GitHub 集成、大型代码库表现、经济性、队列系统、自定义扩展、可视化界面及团队协作等方面，旨在帮助开发者最大化 Claude Code 在日常工作中的价值与便捷性。

author Steve Sewell

Builder.io

How I use Claude Code (+ my best tips)

I switched from Cursor's agents to Claude Code weeks ago and I'm not going back. Here's how I use it and my best practical tips

#优质博文 #AI #RAG #NodeJS #向量检索 #NLP
浅谈 RAG 并基于 NodeJS 实现基础向量检索服务

本文系统介绍了 RAG（Retrieval-Augmented Generation，检索增强生成）模型的基本原理、实际应用场景及其在 NodeJS 环境下的基础实现。作者围绕文本数据的预处理、向量化、向量检索、多路召回、召回重排，以及 LLMs（大语言模型）在流程中的作用展开，详细讲解了如何以轻量级工具搭建一个实用的 RAG 检索服务，并讨论了分片策略、编码方法、检索优化及与开箱即用方案的取舍，为构建定制化AI知识问答系统提供了开源思路和技术参考。

1. RAG 简介与应用场景
• RAG 是结合检索（Retrieval）与生成（Generation）的 AI 架构，能提升对专业领域、高时效性内容的问答、代码生成等场景的回答质量。
• 适用于最新知识获取、特定领域知识补充、提升透明度与可解释性、长尾数据检索、垂直智能问答等实际需求。
• RAG 以内容检索为核心，兼容多种方式（如向量检索、倒排索引、图谱检索等），并与 LLMs 配合工作。

2. 文本向量化流程设计
• 数据预处理包括文本清洗和分片，分片方式有固定长度、overlap 重叠、句段分割、结构分片等，应兼顾语义完整性与检索效率。
• 分片时建议结合元信息（如标题、作者、时间等）以辅助召回与重排。
• 编码方式的演变从 one-hot，TF-IDF，到更先进的 Word2Vec、Transformer-based Embedding。实际项目推荐使用现成高效模型如 all-MiniLM-L6-v2。
• 分片及编码细节优化显著影响检索召回质量和成本。

3. 向量检索与多路召回机制
• 检索的核心是计算 Query 与候选文本的向量相似度，常用余弦相似度（Cosine Similarity），因其只关注方向信息，适合高维稀疏空间。
• 采用 hnswlib-node 快速完成高维向量检索，实际实现还需与实际内容并行存储，便于元数据同步。
• 多路召回建议综合关键词检索、向量召回、图谱召回等互补方式，通过加权、融合、重排序等策略提升检索全面性和精度。

4. 召回重排（Re-Ranking）及其优化
• 初次召回后需对候选结果做重排，提升真正相关内容在前，常见方法如下：
• 传统交叉编码器（如 BERT NSP）精排。
• LLMs 或专门 ReRanker 模型（如 BGE-Reranker）基于上下文深度理解排序。
• 分片元信息和人工打标可进一步增强重排效果，提升系统最终响应准确性和相关性。
• 重排虽可提升体验，但不可避免加大系统复杂度和响应耗时，需按场景权衡。

5. LLMs 在 RAG 流程中的多重角色
• 查询改写：修正拼写、分解多意图、格式化表达、扩展关键词等，显著提高召回精准度。
• 输入优化：用LLMs提升分片、编码智能化水平，以及用于多模态信息抽取、知识图谱构建等。
• 生成增强：将高相关检索片段作为上下文，辅助 LLMs 生成更自然、连贯、有据可溯的答案，并可提升系统的可用性与信任度。
• LLMs 贯穿流程多环节，兼具结构化与半结构化内容的处理与优化能力。

6. 方案总结与工程实践建议
• RAG 作为 AI Infra 基础模块，值得深入学习和灵活定制。开箱服务适用于通用场景，复杂定制或增量优化建议自行实现。
• 流程各节点（分片、编码、检索、重排、生成）都可精调优化，针对需求选择技术方案、服务模型和参数设定。
• RAG 在提升 LLMs 时效性、知识深度、成本控制等方面具备不可替代优势。

author WindRunnerMax