WFHSHHH-优快云博客

原创 Agent 时代，开发者该练什么：三个被放大的能力

供给变多 → 单价下降 → 稀缺度转移。工具做的所有事，都是让"执行"变便宜。但它不会让"判断"变便宜。而判断力这件事——它没法被外包，也没法被生成。它越强，你的基本功越值钱。因为它放大的永远是你本来的水平——包括你本来的问题。你觉得用 Agent 之后，自己的哪种能力被明显放大了？又有没有哪种能力暴露出了短板？我自己感受最深的是第二条——验收。以前我觉得自己"挺会验的"，用了一段时间才发现：我能判断"跑起来了没有"，但很难说出"它错了我要多久能发现"。这条是练出来的，不是看出来的。

2026-10-14 15:48:54 182

原创 AI 写的测试全绿，但可能什么都没验

回到开头那个反转。在 Agent 时代，测试的重要性是上升的——因为它是"让机器自己验"的唯一手段，是你从"逐行读代码"里解放出来的前提。测试的质量，直接决定你解放得彻不彻底。测试写得实，你可以放心不看代码；测试写得虚，你等于什么都没验，却以为验过了。而后者比"没有测试"更危险——因为没有测试你会警惕，有了一堆全绿的测试你会放心。看它能不能失败。一个永远通不过失败考验的测试，等于没有测试。别问"测试通过了吗"，问"它有没有可能失败、以及在什么情况下会失败"。答不上来，那一片绿色就不是保证，是心理安慰。

2026-10-14 15:42:31 154

原创用 Agent 最贵的不是订阅费：一份被算错了很多次的成本账

这是全文的地基，一定要搞清楚，否则后面所有结论都只能死记。面对一份很长的资料，正确顺序是1. 先让它总结这份文档的关键点（只读一次）2. 之后用摘要来讨论，而不是反复贴原文摘要的长度通常是原文的 1/20，而信息密度高得多。如果任务需要精确细节（比如照着规范写代码），摘要是不够的——那种情况下应该让它自己去读原文的指定章节，而不是你用摘要替代。省不是目的，把钱花在能产生价值的地方才是。我不建议你为了省几块钱，去牺牲关键任务的上下文质量——该给够的信息还是要给够，尤其是那些"不说它就会做错"的约束。

2026-10-12 09:29:34 145

原创这几类活，我不交给 Agent 做：划边界比找场景更重要

现在网上关于 Agent 的内容，绝大多数都在讲**“它还能干什么”**——新能力、新工具、新玩法。但对一个真的在用它干活的人来说，更值钱的问题永远是另一个：“这件事，我该不该让它碰？用得越多，你越会发现它的能力比你想的强（第 23 篇那个 106 处批量替换就是）但与此同时，你越需要对"不可逆"这件事保持敏感前者让你敢用，后者让你不出事。两个都要有。而划边界这件事，本质上和写代码是同一件事好的工程师不只是"能实现功能"，更是"知道哪里会炸"。你划的每一条边界，都是你对"什么地方会出事"的理解。

2026-10-12 09:23:56 184

原创和 Agent 做完一个项目后，我发现它最强的不是写代码

它承担了"生产"，我承担了"判断"。生产变便宜了 —— 所以**"写得快"不再值钱**判断还是那么贵 —— 所以**“想得清楚”“验得准”"敢拍板"更值钱**它没有让我变得多余，它让我变得"必须更清楚自己在干什么"。以前你可以边写边想，因为写的过程本身就是思考的过程。现在写这一步被抽走了，你就必须在动手之前把想法想明白——想不明白，它产出的就是一堆你要花更多时间去清理的东西。所以如果有人问我"用了 Agent 之后最需要练什么"——不是提示词，是"把话说清楚"和"把活验明白"的能力。

2026-10-10 09:15:03 178

原创上下文比提示词更重要：Agent 协作的上下文工程

"提示词工程"这个词火了三年，但真正在长期协作里决定成败的，是另一件事。判断标准很简单：如果你遇到过，而且你什么都没改，那问题就不在提示词上。因为提示词是句子，上下文是环境。句子可以精雕细琢，环境不行——它由几十个文件、几轮对话、一堆你没意识到已经被读进去的内容共同构成。一句话总结全文：写提示词你在优化单次输出；做上下文管理你在优化整条协作链路。后者才是长期主义，也更接近工程。先建立一个模型。你和 Agent 之间流动的信息，其实分四层，而且寿命完全不同：关键洞察：第一层是自动的，后三层全是手工的。大部分人

2026-10-10 09:07:06 196

原创 Agent 落地难在哪：把它当成一个服务来管

写这一篇的时候我意识到，它其实不是一篇关于 Agent 的文章，而是一篇运维思维的应用“最小权限”、“验证而不是假设”、“留证据”、“控制爆炸半径”——这些不是 AI 时代才有的原则；它们是在运维这个领域里，被无数次事故打磨出来的；而 Agent 恰好是一个需要这些原则的新对象。"能不能用"是个技术问题，"敢不敢让它碰生产"是个工程问题。而前者早就不是瓶颈了，后者才是。如果你现在用 Agent 还停留在"试一试"的阶段，那我建议的动作不是"换个更强的模型"，而是。

2026-10-09 10:24:45 42

原创 AI 写的代码我不逐行 review：四层验证与 6 个机械指标

回过头看，"我不逐行 review 代码"这件事听上去像是不负责，但它其实是一个判断力分配你不可能什么都验，所以要把有限的注意力放在"错了代价最大"的地方。这个思路和写运维文章时讲的完全一样备份的重要性不在于"备了"，而在于"能恢复"——验证的是恢复，不是备份动作（第 16 篇）；部署的完成不等于"命令执行成功"，而在于"健康检查通过"——验证的是服务可用，不是脚本退出码（第 8 篇）；监控的合格标准不是"面板好看"，而是"出问题时你是不是比用户先知道"（第 11 篇）。AI 协作是同一件事。

2026-10-09 09:54:52 189

原创别对 AI 说帮我写个系统：6 条提需求的规则

Agent 放大的不是你的技术能力，而是你"把问题说清楚"的能力。一个能把需求写清楚的人，用 Agent 会快得离谱；一个说不清楚需求的人，用 Agent 只会更快地做出错误的东西——因为试错循环变快了，错的方向也被放大得更快。所以如果你问我"AI 会不会取代程序员"，我觉得这个问题问偏了。你团队里最会写文档、最能把一件事交代清楚的那个人，是不是一直比你产出高？Agent 做的事情，本质上就是把"表达能力的收益"放大了：以前表达清楚能省一点沟通成本，现在表达清楚能直接换成产出。

2026-09-30 09:26:39 204

原创 JVM 内存与 GC 实战：OOM 分五种，加内存只对一种有用

JVM 这块知识最容易被学偏：网上讲的大多是"参数怎么调"，但排查真正的难点不在参数，而在"方向"。我现在看到的这个症状，到底该往哪个方向查？报错是哪一种 OOM（决定了要不要加内存）；Full GC 后老年代能不能降（决定了是容量问题还是泄漏）；进程是"报错退出"还是"无声消失"（决定了是 Java OOM 还是 OOMKilled）。这三个判断做对了，剩下的都是执行；做错了，就是在错误的方向上花时间。加内存几乎永远不是答案，它只是把问题推迟。真正该问的是那句老话——“这些对象为什么还活着？

2026-09-30 09:18:56 128

原创 JDK 21 虚拟线程实战：为什么开了它并发反而上不去

虚拟线程是 JDK 21 里最有价值的新特性之一，但它的价值不体现在"代码变简单"（确实简单，一行配置），而体现在它逼你重新划一遍系统的边界。在平台线程时代，线程数是一个天然的、粗暴的"总闸门"——它同时限住了并发、保护了下游、也掩盖了很多问题。虚拟线程把这个闸门拿掉了你的真实瓶颈从"线程"变成了"连接池 / 锁 / 下游服务"；那些以前被线程数挡住的压力，现在会直接打到下游；你必须清楚知道自己的系统到底能扛多少，因为不再有一个默认的保险丝。所以这篇的核心不是"怎么开虚拟线程"（那就一行），而是。

2026-09-29 08:47:32 162

原创 MySQL 备份与时间点恢复：怎么回到误删前的那一秒

它的成功标准不在"备份"，而在"恢复"。一份每天准时生成、大小正常、校验通过的备份，如果从来没人从它里面恢复出过数据，那它的可靠性是未知的——你不知道它是不是缺了几张表、是不是因为锁表导出了不一致的数据、是不是少了关键的表结构。定期、真的、从备份恢复一次，然后记录下花了多久。回到开头那个问题——“怎么回到误删前的那一秒”。每天全量（带位点）；binlog 开着且保留够久（ROW 格式）；知道怎么从位点开始重放到指定位置；演练过，所以真出事时你手不抖。前三件是技术，第四件才是让它真正生效的那一件。

2026-09-29 08:42:54 165

原创 Nginx 配置从入门到能配：location 优先级、反向代理与 404-502 排查

Nginx 的配置语法其实很小，难的不是"怎么写"，而是"写的这条到底有没有在起作用"。怎么知道你的配置真的生效了。nginx -T——看合并后的最终配置，而不是你编辑的那个文件；nginx -t+ 看输出——reload 可能失败，且失败是静默的；curl -verror.log——从客户端和后端两个方向看请求到底走没走通。Nginx 配置出问题时，先别改配置，先确认"当前生效的配置是哪几行"。顺序搞反，就会在错误的方向上改很久。你有没有过"改了 Nginx 配置但怎么都不生效"的经历？

2026-09-28 09:12:47 220

原创 Shell 脚本实战：为什么你的脚本总是静默失败

防的是第一节那个rm -rf /*。没有它，$TYPO_NAME会静默地展开成空字符串，然后你的命令就带着一个空参数执行了。写脚本的水平差别，不在于会不会写循环和判断，而在于有没有"失败时会发生什么"的意识。练习脚本的假设是"一切都顺利"；生产脚本的假设是"迟早会有一件事出错，而且是在你没看着的时候让脚本的失败立刻、显式、可追溯，而不是安静地返回 0。Shell 脚本不是万能的。当你的逻辑超过 200 行、开始需要处理 JSON、需要复杂的数据结构时，该换 Python 就换。

2026-09-28 09:08:59 182

原创 Redis 从入门到能运维：持久化、内存淘汰与缓存三大问题

Redis 是那种上手极快、配好极难上手快——五条命令就能让它跑起来，看起来像个"会过期的 Map"；配好难——内存上限、淘汰策略、持久化、过期时间、异常降级，这五件事每一件配错都有具体的后果，而它们的组合方式取决于"你的数据能不能丢"。先回答"这份数据丢了会怎么样"，再决定其余所有配置。丢了能重建、短 TTL、甚至可以不持久化；丢了会出问题（分布式锁、秒杀库存计数、任务队列）→ 必须开 AOF、给 TTL 要考虑清楚、用 volatile 策略保护它们不被淘汰。

2026-09-23 10:36:35 199

原创 HTTPS 与安全加固：上线前的最后一公里

它不是一个能"做完"的功能，而是一个持续的状态。你今天把清单上的事全做完了，明天可能爆出一个依赖的高危漏洞（比如某个日志库的 JNDI 漏洞）；你今天关了 Swagger，下周加新模块时可能又开回来了。收缩暴露面——能不开的端口就不开，能不暴露的端点就不暴露。攻击者只能攻击他能访问到的东西；默认拒绝——白名单而不是黑名单，deny all而不是逐个封禁；有清单，每次上线过一遍——靠记忆一定会漏，靠清单才不会。安全的收益是"什么都没发生"。它不像加一个功能那样能看到成果，但。

2026-09-23 10:22:13 119

原创从零搭一套监控告警体系：Prometheus + Grafana + 告警规则

它不产生任何功能价值，但没有它你就不敢改代码。第 9 篇复盘里我提过"当你不再害怕发版，你就敢改代码了"——CI/CD 解决的是"发版不可怕"，监控解决的是**“出事能立刻发现”**。这两件事合起来，才让"持续迭代"变成可能。判断监控是否合格，不看面板有多漂亮，看一条——出问题时，你是不是比用户先知道？如果是，那这套就是够用的。如果每次都是用户来投诉你才知道，那再多的图表都只是装饰。你是怎么发现线上出问题的——用户报的、还是监控先响的？如果是前者，建议先做第十节里的第 1 步（探活脚本），

2026-09-22 16:44:29 248

原创 MySQL 索引与 EXPLAIN 从入门到会用

调优这件事，90% 的场景不需要你懂 B+ 树的细节索引有顺序（最左前缀），所以条件列的顺序影响能不能用上；索引存的是原值，所以对列做运算/函数/隐式转换都会失效；索引不是免费的，每个都要靠写入性能换读取性能。真正难的不是改 SQL，是"先定位到是哪条 SQL 慢"。所以如果你只做一件事，我建议先把慢查询日志打开——没有数据的时候，优化全靠猜。永远在确认EXPLAIN变了之后再宣布优化成功。数据库的执行计划是数据分布决定的，你的直觉和它的选择不一定一致。你遇到过最离谱的索引失效是什么情况？

2026-09-22 16:38:43 157

原创一个人把二手图书交易网站做到上线：架构、踩坑与取舍

一个人做完一个完整项目之后最大的收获，不是"我会写增删改查了"，而是开始意识到系统里哪些地方最脆弱。写代码的时候，注意力在"功能能不能实现"；等它真的跑起来、真的有人访问，注意力才会转移到"它会在什么时候坏、坏了怎么办"。这个视角的切换，就是软件开发者和"能让系统活着的人"之间的差别。15 张表、20 个接口、8 个坑，这是一个人做完一个项目的全部痕迹。不多，但每一条都能讲出为什么。你做项目时踩过最久的坑是什么？是环境、并发、还是"文档和实现对不上"？评论区聊聊，这类问题的解法往往能通用。

2026-09-21 15:40:53 139

原创用 GitHub Actions 自动部署：push 一下代码自己上线

自动化真正解决的不是"省时间"，而是把"我记得要做什么"变成"流程保证会做什么"。手工部署时，正确性依赖你的记忆和状态——凌晨两点改 bug 的时候，你就是那个最不可靠的环节。而流水线不会忘、不会累、每次动作完全一致，失败时还会告诉你哪一步挂了。当你不再害怕发版，你就敢改代码了。这个心理变化比省下的 20 个小时更值钱。不要为了自动化而自动化。如果一个项目一个月才发一次版，手工部署 5 分钟完全没问题——流水线本身也是要维护的代码。

2026-09-21 15:22:32 189

原创 Linux 常用命令速查手册（按场景分类）

这份手册的价值不在于"全"（你永远能找到更全的），而在于按场景组织——卡的时候翻到第二节，满的时候翻到第四节，比按字母顺序找命令快得多。记不住是正常的。我到现在也记不住tar的所有参数，但我会查。关键是知道有这个东西存在、知道该去哪一节找。你最常用但最容易忘的命令是哪个？或者你有什么压箱底的一行命令技巧？评论区补充，我会挑实用的加进这篇（并注明来源）。觉得有用的话《运维到底是干什么的？《运维工程师该学哪些技能？《Docker 到底是什么？《Docker Compose 一键部署》

2026-09-20 09:39:22 129

原创线上故障排查实录：CPU 飙升、磁盘写满、502、数据库慢怎么查

排查是有套路的。先止血，再定位——业务在流血的时候不要做研究。分层排除——从 DNS 到数据库一层层问下来，别瞎猜。看数据，不看感觉——dftopjstackEXPLAIN，让证据说话。事后必须复盘——不然同样的电话你还会再接一次。大部分"查明原因"的时刻，靠的都不是聪明，而是现场保存得好。所以在慌乱中最重要的一件事是——动手重启之前，先把日志留下来重启会让现场证据全部消失，而现场一旦没了，根因就永远找不回来了。给自己留个作业：挑一个风和日丽的下午，在你的测试环境故意制造这四类故障。

2026-09-20 09:22:03 187

原创项目上线之后：备份、监控、日志、压测这四件事

运维是把不确定性变成可控。部署上线带来的那种"搞定了"的感觉是假的——能访问只是起点，能稳定地访问才是成果。备份：让最坏的情况可控（数据能回来）日志：让故障可追溯（知道发生了什么）监控：让异常可发现（不用等用户投诉）压测：让容量可量化（知道上限在哪）这四件事加起来，才把一个"跑起来的项目"变成"可以托付的服务"。给自己留个作业：今天就把备份脚本和日志限制加上——这两件事各只要十分钟，但它们挡住的是真正不可逆的损失。你的项目上线后遇到过什么事故？磁盘写满、数据库被误删、还是活动一来就崩？

2026-09-19 14:50:40 133

原创用 Docker Compose 一键部署 Spring Boot + Vue 项目

是一份可执行的架构文档。新同事拿到项目，看一眼这个文件就知道它由哪几部分组成、彼此怎么连接、数据存在哪——比任何口头交接都可靠。换一台机器，就能原样复现。运维的工作，是把不确定性变成可控。把环境写进文件，就是可控的第一步。给自己留个作业：把你现在手上的项目（毕设、课程作业、个人博客都行）按这套结构改造一遍，然后故意删掉容器再重建一次，验证数据还在。这一步做完，你才算真的会用 Compose。用 Compose 部署时你踩过最头疼的坑是什么？是数据库没就绪导致后端反复重启、接口 404、还是刷新页面就白屏。

2026-09-19 14:44:33 153

2401_84448308的博客