AI 时代的编程语言选型：Python、Go、TypeScript、Rust 与 Java 怎么选
AI 时代的编程语言选型：Python、Go、TypeScript、Rust 与 Java 怎么选“该学哪门语言”“新项目该用什么语言”，这类问题每隔几年就会被重新讨论一次，而大模型的出现让它又多了几个新变量：模型和推理框架主要活在哪个生态里？AI 写代码时哪种语言更省心？Agent 要同时调用几十个工具、开几百个连接，并发模型撑得住吗？本文不做“语言排行榜”，也不宣布谁是赢家，而是从 AI 时代的选型维度出发，深入比较 Python、Go、TypeScript、Rust 四门语言，兼顾这个 Java 爱好者博客的主角 Java，再简要看看 C++ 与 C#，给出同一小任务的代码对照、一张综合对比表、按场景的选型建议、多语言组合架构思路，以及常见坑与 FAQ AI 时代选型新增的七个考量点
2026-10-14鱼鱼
Agent 的工具调用日志：出了问题我先看哪几行
Agent 的工具调用日志：出了问题我先看哪几行Agent 一跑起来，日志可以很热闹：思考摘要、工具名、参数、返回、重试、最终回答……出了问题时，若从头通读，既慢又容易被模型的“自信叙述”带偏 我逐渐养成一个习惯：先不看它怎么说，先看它调用了什么、参数是否离谱、返回是否被误解 这篇文章记我排查 Agent 故障时的日志阅读顺序 偏工程经验，不是某家产品的官方手册 失败时我最想看的其实不是最终答复 答复是渲染后的故事，故事会把中间的错误抹平 更常见的情况是： 所以我把最终答案降级成线索，把工具轨迹升级成证据 图：先证据后故事：工具轨迹优先于最终答复（原创示意图） 只看序列：读文件 → 搜代码 → 改文件 → 跑测试 这种骨架
2026-10-14鱼鱼
MQTT 是什么：我把 pub/sub、QoS、遗嘱和 5.0 记一记
MQTT 是什么：我把 pub/sub、QoS、遗嘱和 5.0 记一记最近又有人问我「MQTT 到底干啥的」，我也发现自己讲的时候经常跳着说：一会儿 QoS，一会儿遗嘱，一会儿又冒出 5.0 的共享订阅 这篇就把常用概念按我自己理解串一遍 协议细节以 OASIS 规范为准，我没拿真机逐条抓包，标了「我推断」的地方别当标准条文 MQTT 全称历史上叫 Message Queuing Telemetry Transport 标准化过程里有人提过：名字里的 Message Queuing 容易让人联想到企业消息中间件，OASIS 后来更常直接叫它 MQTT，不再强调展开 事实是：它是一套 客户端—服务器 的 发布/订阅（publish/subscribe） 传输协议，设计目标就是报文小、实现简单，适合机器对机器（M2M）、物联网（IoT），以及带宽紧、延迟高、链路不稳的环境
2026-10-16鱼鱼
让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑
让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑我们组有个内部服务，一直跑在 Spring Boot 2 上 2.x 早就停止开源免费维护了，安全扫描隔三岔五报一堆依赖漏洞，升级这件事拖了很久，终于排到了我头上 这次我决定全程拉着 AI 一起干 前后大概用了一周多（中间还穿插着别的需求），最后顺利上线 回头看，AI 确实帮我扛了大部分体力活，但也有几个坑是它挖的，或者至少是它没提醒我的 这篇把过程和教训记下来，给同样准备升级的同学参考 先声明：下面说的都是我们这个项目的情况，每个项目的依赖和历史包袱不一样，具体以 Spring 官方的迁移指南为准 一开始我问 AI：“把这个项目从 Spring Boot 2 升到 3，需要改什么？”它给了一份清单，大方向没错：Java 版本要 17 以上、javax 包要换成 jakarta、Spring Security 的配置写法变了，等等
2026-10-14鱼鱼
AI 生成的 README 和注释，我为什么经常删掉重写
AI 生成的 README 和注释，我为什么经常删掉重写AI 写文档很快：README、函数注释、模块说明，几秒就能铺满 我早期几乎照单全收，后来越来越频繁地整段删掉重写 不是因为文笔不好，而是因为很多生成文档在“正确的废话”和“过时的细节”之间晃，读的人费时间，维护的人更痛苦 这篇文章记我什么时候信它、什么时候动手砍，以及重写时我保什么、扔什么 1. 正确的废话 “本模块用于处理订单相关逻辑，提供创建、查询与更新能力 ”——读完等于没读 它没有告诉我边界、不变量、也没有告诉我别乱用的地方 2. 和代码赛跑的细节 把当前参数列表、每一步实现按行复述一遍 代码一改，注释就撒谎 AI 特别擅长写这种“现在时”的说明，因为它看见的就是此刻源码
2026-10-14鱼鱼
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路用 AI 编程助手久了，你大概会有一种“祥林嫂”式的疲惫：每开一个新会话，就得把同样的话再说一遍 “我们用 pnpm，不是 npm ”“跑测试要加这个参数，不然会连真实数据库 ”“generated 目录下的代码是自动生成的，别改 ”“提交信息要按这个格式写 ” 说一次两次还好，说到第十次，就会开始怀疑人生 更糟糕的是，你偶尔忘了说，AI 就会理直气壮地按自己的默认习惯来，然后你再花时间收拾 解决这个问题的办法其实很朴素：把这些话写下来，放进仓库，让 AI 每次开工前自己读 这就是 AGENTS.md 要干的事 图片来源：rawpixel.com（CC0 1.0） 一句话：给 AI 看的 README
2026-10-14鱼鱼
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着我自己写的那个编程 Agent，最早只用来做一些小改动，十几轮对话就结束了，上下文从来不是问题 后来我开始让它做跨很多文件的迁移，比如把一批旧接口的调用换成新接口 这种任务一跑就是几十轮：读文件、搜索、改代码、跑测试、看报错、再改 每一轮的工具输出都往上下文里堆，没多久就逼近了模型的上下文上限 于是我做了第一版“压缩”：上下文超过某个阈值，就让模型把之前的历史总结成一段话，然后用这段总结替换掉原来的历史，继续往下跑 听起来很合理，跑起来问题一大堆 这篇就讲讲我前后几次改动的过程，以及现在比较稳定的做法 都是在我自己这个 Agent 上摸索出来的经验，换个场景未必完全适用 第一版用的是自由发挥式的摘要，提示大概就是“请总结上面的对话，保留重要信息”
2026-10-14鱼鱼
Agent 的安全、权限与沙箱：别让它“闯祸”
Agent 的安全、权限与沙箱：别让它“闯祸”Agent 能调用工具，意味着它能真正改变外部世界：发邮件、删文件、执行命令、花钱 能力越强，风险越大 本文总结 Agent 开发中必须考虑的安全问题与实用的防护手段：先梳理威胁模型，再讲最小权限与分级审批，给出 Python 的统一守卫与路径校验、Java 的权限注解与审批流程，讨论沙箱的配置要点，并用一个具体的注入攻击场景演示防线如何叠加，最后是常见坑、上线检查清单与 FAQ Agent 的安全问题为什么不同于传统应用 传统应用的行为由程序员写死，输入来自用户，风险主要是“用户输入能不能被恶意利用” Agent 多了一层：决定做什么的是模型，而模型的输入里混入了大量不可信内容——网页、邮件、文档、工具返回值、第三方 Server 的描述
2026-10-14鱼鱼
让 AI 把 Python 脚本改写成 Java：跨语言迁移时它最容易丢的东西
让 AI 把 Python 脚本改写成 Java：跨语言迁移时它最容易丢的东西组里有不少“历史脚本”：某个同事几年前用 Python 写的数据清洗、对账、报表生成，跑在一台机器的定时任务里，没人敢动 最近要把其中几个并进 Java 服务，统一部署、统一监控 这种活交给 AI 再合适不过了：输入输出都明确，代码量不大，几百行 Python，它几分钟就能吐出一份结构工整的 Java 第一份迁移我差点直接合进去 代码能编译，单测能过，命名比原脚本还讲究 后来是跑了一遍真实数据对比，才发现有几十行结果和老脚本对不上 查下来，没有一处是“写错了”，全是两门语言默认行为不一样，AI 按字面翻译了语法，却没翻译语义 这篇整理一下我踩到的这些差异，以及现在怎么让 AI 做迁移才比较放心
2026-10-16鱼鱼
给 Agent 设超时和步数预算：别让它无限跑
给 Agent 设超时和步数预算：别让它无限跑第一次把 Agent 接到真实仓库时，我犯过一个很土的错：只盯着“它能不能做完”，没盯着“它最多能跑多久、最多能走几步” 结果某次工具调用卡在外部接口，它一边重试一边换策略，token 和墙钟时间一起烧，最后我手动杀掉，现场还一堆半成品文件 从那以后，我把超时和步数预算当成和权限同级的安全项 不是为了虐待 Agent，而是承认：自动化一旦没有硬上限，失败模式会从“报错”变成“悄悄耗尽” Agent 的轨迹很会制造希望：每一步都有日志，每一步都像在进步 可进步不等于收敛 常见假象包括： 同一类错误换着措辞重试 在几个文件间来回改，测试始终红 搜索范围越扩越大，上下文越来越脏
2026-10-14鱼鱼
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册如果你已经写过一两年 Go，会用 goroutine、channel，也能把一个 HTTP 服务跑起来，那么在准备中高级岗位面试时，大概率会发现：面试官问的已经不是“goroutine 怎么启动”，而是“一个阻塞的系统调用发生时，调度器会做什么”“nil 的 error 为什么不等于 nil”“线上 goroutine 数量一直涨，你怎么定位” 这类问题考察的不是背诵，而是你对运行时机制的理解，以及把机制翻译成工程判断的能力 这篇文章是一份按主题组织的复习手册 每个主题基本遵循同一个结构：典型面试题 → 参考回答思路 → 常见陷阱 → 简短的代码 内容覆盖调度器、goroutine 生命周期、channel、sync 原语、context、内存模型、GC 与逃逸分析、slice 与 map、interface、defer/panic/recover、泛型、错误处理、反射、并发模式、性能调优、工程实践，最后补充系统设计与行为面试的建议、速答表、学习路线和 FAQ
2026-10-14鱼鱼
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么给内部做的一个小 Agent 加“停止”按钮，我原本以为是半天的活：前端加个按钮，点了以后断开流式连接，完事 上线第二天就有同事反馈：他点了停止，文件却还是被改了 我去翻日志，发现事情是这样的：他点停止的时候，模型刚刚生成完一个写文件的工具调用；前端确实停止了渲染，连接也断了，但后端的 Agent 循环根本不知道用户已经喊停，照样把工具执行完了，甚至还又调了一次模型，生成了一段没人看的总结 那之后我才意识到，“停止”这件事远比一个按钮复杂 这篇就聊聊我后来是怎么重新设计的，主要讲三件事：取消信号怎么传到底、中断落在不同阶段该怎么处理、以及中断之后对话历史怎么写 我后来把“停止”拆成了三层，每一层都要单独处理：
2026-10-14鱼鱼
