国庆假日里想明白一件事：编程语言对 AI 来说，可能本身就是低效的，我们还在纠结编程语言吗？ 国庆第 1 天，没怎么出远门。下午我看着窗外，想着最近半年跟 agent 协作下来的体感，正好网上还在争论"AI 写 Java / Python / Go 哪个质量好"，忽然意识到一件事——这些争论，可能问错了。编程语言对 AI 来说，从一开始就不是它的母语。【关键词：#AI编程 #AI原生工程师 #上下文设计】 maybe，我们未来不再关心使用什么编程语言，AI的对语言的学习和使用是远胜于人类的，只要AI逻辑严密，AI或许会有自己的语言去驱动及驱动机器执行二进制程序吧。 01｜编程语言从来不是给 AI 设计的 打开 IDE 看到的 Python、Go、Java、JS 这些语言，它们被人为的"可读性、命名空间、类型系统、设计模式"绑了一身——这些是好东西，让我们能跨团队协作、能 review、能维护。 但 AI 不吃这一套。它不读注释、不在意缩进、也不会被你精心取的命名打动——它真正消耗的是 token、是上下文、是注意力分布。 最近一次让我愣住的：我让 Codex 改一段 Go 的并发代码，它把 channel、mutex、context 整段翻完，最后只用了两行；而我换成一段伪代码 + 关键约束描述喂过去，它一次就跑对了。 那一刻我才反应过来：AI 时代的"语言"，正在从"语法正确、人类可读"悄悄转向"信息密度高、上下文清晰"。Anthropic 内部数据里那 27% 的"agent 原本不会做的新工作量"——翻译需求、设计 prompt、整理上下文，本身正在变成新工种（Anthropic 研究页）。 02｜AI-native 工程师的默认单位，悄悄变了 借假期想明白的第二件事，跟我自己更相关——所谓 AI-native，不是会用 Cursor/Codex，是你脑子里默认的颗粒度变了。 老一代工程师脑子里装的是行、函数、模块；我自己这半年越来越意识到，AI-native 工程师脑子里装的应该是上下文窗口、任务切片、可验证的契约。 具体到每天的工作里，是三件事： 任务切片——把一个模糊需求拆成 agent 一次能跑完的小块，而不是把 2000 行的 PR 整段扔过去； 可验证的契约——每个任务都自带验收标准：什么算"做对"、什么算"做错"，让 agent 自己跑测试； 上下文设计——知道哪些信息 agent 必须看到、哪些是噪音、出错时才补什么。 说白了，AI-native 工程师写的不再是代码，是给 agent 跑的"剧本"。 ...

用了半年 Agent 之后，我对工作开发与运营的 5 点新观察 马上要国庆了，简单回顾下过去半年的AI Coding：我是 2026 年 3 月开始把 Codex + Cindy 当主力、混着 GLM5.2（国产）和自建 agent 编排一起用的开发者。下面 5 点，全是我身边真实发生、或交叉核实过数据的事。【关键词：#Agent #岗位变化 #代码开发 #AI趋势】 01｜前后端 title 在合并，但合并方向不是"更全栈"，是"更靠近 agent" 放数据：Salesforce CEO Benioff 2025 年公开不再招新工程师（Times of India）；Cognition 团队 15 人，每人带 5 个 Devin 跑任务，自家代码库 89% 提交来自 agent（agentmarketcap.ai）；Anthropic 内部 60% 工作有 Claude 参与、27% 是 agent 原本不会做的新工作量（Anthropic 研究）。 title 在合并，意味着"更靠近 agent 的工作方式"。 02｜中间层不是被"砍掉"，是被"打散" GitLab 2025 年裁 14%、退 22 国，研发团队从 30 个重组为 60 个跨职能 pod（LinkedIn 报道）；Skai 砍中间层效率从 7–12% 跳到 500%；HaxiTAG 33 个工程师只配 1 个 team lead。 中间层没消失，是被打散到 pod 里去了——"管人"的中层在贬值，"管 agent + 管判断"的中层在升值。 ...

前额叶 25 岁才长好，短视频和 AI 摧毁了它 最近在读一份《阅读与大脑》的横纵分析报告，作者把神经科学、阅读研究和认知储备三条线索梳理了一遍。过去两年，让我前额叶"休假"最狠的两样东西，正同时出现在我生活里：短视频，和 AI。真的是糟糕透顶，短视频和持续使用AI。 大脑的前额叶是用进废退的器官，没有阅读和思考，就会迟钝退化，在AI剥夺思考的过程中，我们必须保持足够的阅读和思考时间。 【关键词：#前额叶 #深度阅读 #短视频与AI】 01｜短视频让前额叶白交了一次"延迟满足"作业 一开始我以为是自控力问题。后来读了点神经科学的功课才发现，这不是自控力——是神经回路被改写了。 短视频把节奏切成 3 秒一个钩子、15 秒一个小高潮、30 秒一转折。每滑一次，新鲜刺激马上顶上大脑的奖赏回路，多巴胺峰值反复出现。大脑很快学会一件事：不必等。 阅读正好相反。一段长文本不会在前 3 秒给你钩子，也不会在 15 秒给你高潮。它要你等 30 秒、5 分钟、甚至 30 分钟，才给你回报。 神经层面的事实是：等待和延迟满足，主要靠前额叶来执行；持续注意和抑制分心，主要靠前额叶来挂载。短视频把"等"这件事从我的日常里删了，等于把前额叶这一项训练悄悄停了。 更隐蔽的代价是：短视频喂的全是已经消化过的结论。一段 90 秒的视频告诉你"巴菲特为什么 96 岁还在读书"，你被喂饱了，但你自己没有"读巴菲特原文、做笔记、自己得出结论"的过程。前额叶真正练的不是"知道结论"，是"读完一段话，把它留在脑子里自己转一遍"。 02｜AI 替我读了答案，但没替我想清楚"我该问什么" 我做 DevOps，在写 SKILL.md、设计 Agent 规则、搭流水线。我对 AI 的能力边界很清楚——它不是变强了，是把"获取答案"的门槛打到零。但有一件事 AI 替不了：我得先想清楚我该问什么。 举个最近的例子。我在排查一个 K8s Pod 频繁重启的问题。一开始我直接问 AI："Pod 重启怎么排查？" AI 给了我一份标准清单——查日志、查 events、查资源水位、查镜像版本。每一步都对，但我没读这些步骤背后的原理，也不知道为什么先查这个再查那个。 后来我关掉 AI，自己翻了一遍 Kubernetes 官方文档，看完再问："在异构节点上 ImagePullBackOff 比 x86 上高，是不是和 runtime class 有关系？"——AI 这次的回答直接命中了我想要的方向。差别不在 AI 那一头，在我这一头：我读过的脑子里，能问出更好的问题。 这其实是前额叶最重要的一项功能——判断。判断不是"知道答案"，是"知道问什么、知道答案靠不靠谱、知道接下来该往哪走"。AI 把"知道答案"这件事外包出去了，我前额叶最重要的判断功能，反而被我闲置了。外包得越久，闲置得越深，最后连"该问什么"都想不出来——这才是真正的危险。 ...

九月的第二波更新，Cursor 放出了两个技术含量十足的产品，正好对应了官方一直宣传的"self-driving codebases"愿景的两块拼图：Token 效率优化解决的是 Agent 运行成本问题，Rollouts + Security Reviewer 则把 Agent 的能力延伸到了代码提交之后的运维和安全环节。 Improved Token Efficiency：Harness 工程的第一份公开技术总结 这篇官方 blog 是 Cursor 第一次比较系统地披露其 Agent Harness（agent 调度框架）的工程细节，技术内容比一般产品公告要密得多。 核心数据：token 成本降低 7%，冷缓存 miss 率降低 20%，MCP 工具调用场景下总 token 降低 46.9%。三个数字对应三条不同的优化路径。 路径一：压缩 System Prompt（减少 66%）。Cursor 早期给模型的指令风格是典型的"防御性提示词"——大量"DO NOT""You must""Important"式语句。随着模型能力提升，这类指令逐渐变成冗余，因为模型能够从工具定义本身推断行为，而不需要额外的行为约束。Cursor 砍掉了大约 2/3 的系统提示词代币，且这个变化跨模型家族通用（A/B 测试验证），说明这是模型能力提升的共同红利，而不是某个特定模型的特性。 路径二：动态工具加载。Cursor 内置工具很多，但大多数工具在任何单一对话中的使用频率低于 20%。之前所有工具定义都塞在每次请求的 context 里——这是典型的"静态上下文浪费"。Cursor 参照了今年早些时候对 MCP 工具的动态加载方案，将高频工具（读、写、搜索、shell）保留在静态上下文，其余按需加载。这让 MCP 工具场景节省了近一半 token。 路径三：缓存边界优化。在 GPT-5.6 之前，缓存边界由 provider 自动决定，即使工具定义和方法说明相对稳定，也不会被标记为可复用。GPT-5.6 支持显式缓存断点后，Cursor 重新组织了请求结构：把"稳定层"（工具定义、系统指令）放在缓存断点之前，把"增长层"（对话历史、用户特定上下文）放在断点之后。冷缓存 miss 率因此降低 20%。 一个值得注意的工程哲学：Cursor 强调 A/B 测试是优化 harness 的主要手段，而不是仅依赖内部 evals。理由很实在——内部 evals 通常代表"难题"，无法反映真实用户请求的分布。这意味着 Cursor 的 token 优化是数据驱动的，而不是拍脑袋的。这套方法论本身可以被其他 Agent 系统借鉴。 ...

周末用SQLite，我给 AI Agent 配了一个文件型"本地大脑" 【关键词：#SQLite #AI Agent #本地存储】 做一个 AI Agent 项目，需要给 agent 配上持久化层：要存会话历史、用户记忆、工具调用日志、任务队列，还要能跑简单检索。我没拉一套数据库服务，就用一个 SQLite 文件——一个 .db 把 agent 的所有状态都接住。两个月跑下来，稳定、可备份、可调试。 将agent执行的环境上下文信息，在SQLite存储，多agent可共享SQLite里的数据，SQLite 让 agent 的"记忆"和 agent 本身活在一起，不将各个数据分散到不同文件里。 PS : 这仅是短期实践的心得，后续AI的进步，SQLite也行会被抛弃。 01｜先看 SQLite 自己怎么说自己 打开 sqlite.org 首页，SQLite 给自己的定义只有一句话： SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. SQLite is the most used database engine in the world. 翻译过来就是：小、快、自给自足、高可靠、功能完整的 SQL 数据库引擎。官方口号更短——"Small. Fast. Reliable. Choose any three."（小、快、可靠，三选三）。 ...

我把家庭影音库搬上了 Jellyfin，在威联通 NAS 上跑影院 周末中秋，我顺手在小米电视上点开 Jellyfin，全家一起在小米电视上看蓝光电影，配合外接的音响，深度沉浸式体验。【关键词：#Jellyfin #威联通NAS #豆瓣刮削】 01｜为什么我决定把家庭影音库"上云"到自己家 Jellyfin + 威联通 NAS + 豆瓣刮削，是当前最稳的组合。 第一套是硬盘 + USB 直接插电视：小米电视对 NTFS、exFAT 支持不稳定，字幕经常错位、外挂音轨识别不出来。老婆为了追剧投屏到平板，看着看着突然音画不同步，最后只能回电视重新加载。 第二套是某品牌 NAS 自带的媒体中心：海报墙难看得像 Windows 资源管理器，4K 原盘直接卡死，更别提硬解。 Jellyfin 是 Plex 当年的开源分支，GPLv2 协议，功能覆盖 Plex 90% 但完全免费、移动端不限并发、不限画质，已经不是"爱好者玩具"了。 02｜Jellyfin 是什么，为什么我选它而不是 Plex/Emby Jellyfin 是一个用 C# 写的开源媒体服务器，主项目托管在 GitHub 上。核心逻辑很简单：你把电影、电视剧、动漫按"影片/季/集"的目录结构放在硬盘上，Jellyfin 扫描这些目录、帮你拉元数据（封面、简介、演员表、评分）、生成海报墙，然后在你家里的电视、手机、平板、电脑上提供播放服务。它不替你存数据，只替你整理数据和播放——这是和 Plex、Emby 最大的共同点。 为什么我最后选 Jellyfin 而不是 Emby： Emby 在 2018 年把服务端核心从开源转成了"个人免费 + 商业付费"的双轨制，移动端解锁、硬件转码都已经收进 Emby Premiere 订阅，¥448 永久。我不是付不起，是不想为一个本来开源的东西再付一次订阅费。 Jellyfin 是当年 Emby 开源部分 fork 出来的，主要开发者是从 Emich（Emby 创始人）出走的团队，协议是 GPLv2，社区、客户端、插件生态全都独立维护。它不是"想白嫖 Emby 的项目"，是有完整产品节奏的独立项目。 客户端生态基本一致：Android TV、Apple TV、iOS、Android、Web 全平台都有原生客户端，体验上 90% 的功能我用不到差异。 03｜威联通 NAS Docker Compose 部署：把硬解、目录、权限一次说透 ...

公司抠到不发笔记本只给瘦终端 + Ubuntu，我反而把开发体验拉满了 中秋放假前大家都基本上半开工状态，我就好好吐槽下现在的办公环境 和 使用Ubuntu的优劣势吧。 没有笔记本、没有 MacBook、没有 ThinkPad——："公司全部走云桌面，瘦终端连过去就是工作机，系统只有 Ubuntu 和 Windows 两个选项" 不是被冒犯，是真的想笑——一家号称做技术驱动的云公司，自己员工用的机器居然是公司虚拟化的超卖主机。真的在 Ubuntu 云桌面上干高频容器化开发、跑 K8s、写 AI Coding Agent ，有些时候也挺感谢这种漂移， 缺点是分辨率和画质损失。 我在家开发和剪视频 使用macos系统，在公司使用瘦终端+云电脑Ubuntu 【关键词：#Ubuntu #瘦终端 #Linux 开发】 01｜公司抠到这种程度，我也是服了 先说吐槽部分。这家公司是真的抠： 不发笔记本——MacBook Pro 不可能、ThinkPad X1 不可能、外星人也不可能。能摸到的只有一台 国产的瘦终端（瘦客户端：本身不运算、只负责接显示器和传键鼠信号，所有计算在云端跑），长得跟网吧机差不多，桌面还贴着公司的资产编号。 外设自带——键盘鼠标自己买，显示器公司只给一台 27寸的AOC的2K显示器。 网络隔离——公司网络完全隔离公网，大多数均无法正常访问和查询资料。 02｜Ubuntu 上的开发体验，比想象中香太多 我选 Ubuntu 不选 Windows 的判断，不是因为 Linux 性能更好（这个说法不够精确），而是因为在虚机资源受限的环境里，Ubuntu 把更多资源还给了真正的工作。这件事在瘦终端云桌面场景下，被包过的具体数字放大到了"体感级别"。 第一，资源开销是真的少。同一台 4 vCPU + 8 GB 内存的云桌面： Windows 11 桌面空载内存 2.5–4 GB，后台 Defender、OneDrive、Teams、各种 UWP 进程持续吃 CPU/IO； Ubuntu 22.04 桌面（GNOME）空载内存 800 MB–1.2 GB，关掉 snap（Ubuntu 自家的封闭包管理）相关服务后能压到 600 MB。 这台云桌面我要跑 Docker Desktop、K8s 集群（kind）、VS Code + 远程开发模式、tmux、Zellij、AI Coding Agent——剩下的 6 GB 内存，Ubuntu 几乎全给我；Windows 那边一开机就被吃了 3 GB。 ...

Cloudflare Python Workers 终于 GA：把 Python 塞进 WebAssembly 扔到全球边缘，我看到的甜点与坑 【关键词：#Cloudflare Workers #Python Serverless #边缘计算】 2026 年 9 月 21 日，Cloudflare 把 Python Workers 从 preview 拉到 GA——两年的预览期正式结束。我盯这个特性看了很久，它的实质是把 **Pyodide（CPython 编译到 WebAssembly 的运行时）**直接跑进 Cloudflare 边缘网络（300+ 城市）。不是"Cloudflare 也支持 Python 了"那么简单。甜点、坑、适用人群，下面分开讲。 01｜为什么我盯了两年 边缘计算这两年最大的痛点：Lambda 只能在某区域跑，冷启动还要几秒。Cloudflare Workers 一直靠 V8 isolate（Chrome V8 引擎里的轻量沙箱，每个请求一个独立执行环境）把冷启动压到 50ms，但只支持 JS/TS。Python 程序员想在边缘跑代码，要么忍受 Lambda 的延迟，要么把 Python 编成 WASM 自己部署——两条路都不甜。 Cloudflare 在 2024 年开始 preview Python Workers，走的路线是 Pyodide + WebAssembly：让 CPython 直接跑在 V8 isolate 里，不走容器。这样三件事成立： ...

云主机推荐，一年不到 200 元搞定 VPS，我把博客和服务都搬出了亚马逊云 今天想聊一个老被问到的问题：VPS 是什么、和 AWS 有什么不一样、为什么国外有这么多便宜的小厂云？ 这也是我自己这两年手上有几台 VPS 跑在 nube、racknerd 这类小厂上之后，慢慢讲明白的事。这篇文章就把答案一次性说清楚，再把我为什么选 nube 和 racknerd 的判断也写下来。【关键词：#VPS #小厂云 #性价比部署】 01｜什么是 VPS，先把概念说清楚 VPS 全称是 Virtual Private Server，虚拟专用服务器。你可以把它理解为：一台物理服务器被切成几台、几十台，每一台都给你开一个独立的"操作系统房间"，门牌号、CPU、内存、硬盘都是给你的。 你拿到 root 账号之后，想装什么装什么、想重启重启，跟一台物理机唯一的差别是 CPU、内存、硬盘、网络带宽是和别的小物理机共享的，邻居会跟你抢。 这是和"虚拟主机"（shared hosting）最关键的区别：虚拟主机你拿到的是"账号"，服务器上跑什么你看不到、改不了；VPS 你拿到的是"一台机器"，完全是你的。 这也是和"云主机"（cloud server）有区别的地方。云主机本质也是 VPS，但更"云"：可以临时扩容、按秒计费、自带负载均衡、跨可用区复制、自动备份。AWS EC2、阿里云 ECS、DigitalOcean Droplet 严格说都是云主机——它们是 VPS 的"企业升级版"。 VPS 的虚拟化技术主要是两种： KVM：每台 VPS 有自己独立的内核，性能隔离更彻底，绝大多数小厂商和大厂云默认都用 KVM。 OpenVZ / Virtuozzo：共享内核，单台机器更便宜但跑不了 Docker、跑不了需要内核模块的东西，正在被逐步淘汰。 所以当你看到一家"年付 10 美元"的小鸡，基本可以默认是 KVM 虚拟化 + NVMe SSD + 1Gbps 共享带宽。你拿到一台 VPS 之后能干的事，比你想象的多——博客、家庭相册 Immich、轻量爬虫、CI runner、个人邮箱、密码管理器、Notion 替代品、学习项目，只要不爆内存都跑得动。 02｜国外为什么冒出这么多小云厂商 ...

AGENTS.md 写对一次 ≈ 一次模型升级：60k 仓库总结的 5 段结构、6 个模式、5 类反模式 一句话定位：README 写给人看，AGENTS.md 写给 AI Agent 看。 AGENTS.md 不是文档，是 Prompt。你不是在写文档，是在做上下文工程。 —— Augment Code 工程博客 【关键词：#AGENTSmd #AI编程 #上下文工程】 01｜和模型强弱到底是什么关系：三种打架的结论 "我用了 Claude Opus 还需要写 AGENTS.md 吗？"——最近这一两个月，被问到这一句的次数，比过去一年加起来还多。 网上数据打架，我整理出三种主流结论。 我的判断一：好的 AGENTS.md ≈ 一次模型升级。Vercel 的 Next.js Evals 这套基准是所有数据里跑得最干净的——没有 AGENTS.md 的时候，Claude Sonnet 4.6 通过率只有 67%；加一份好的 AGENTS.md 之后直接到 100%。GPT 5.3 Codex 同样从 86% 拉到 100%。最反直觉的一行：——一份好文档的杠杆，比一次模型升级还大。 判断二：弱模型受益更大，但强模型也吃这套。The Prompt Shelf 综合 60k+ 仓库数据后画了一条更细的线——弱模型缺乏世界知识，必须靠显式上下文才能在同一个代码库上工作；前沿模型能自己推断大部分约定，但对非显而易见的项目约定（部署步骤、内部 API、仓库特有坑）仍然需要 AGENTS.md。边际价值不同，但没有哪个模型可以裸奔。 判断三：差的 AGENTS.md 比没有还糟。Augment Code 的实测 有点打脸：同一份 AGENTS.md，任务 A 提升了 25%，任务 B 反倒掉了 30%。——规则一旦自相矛盾，模型就开始犯傻。 ...