没工作的人面临的选择是：要不要接受一个低于预期的offer？接受了怕后悔，不接受怕一直等下去。这是“将就”与“坚持”的拉锯。失业时间越长，人的期望值会不断下调。原本非大厂不去，三个月后觉得小厂也行，半年后觉得外包也能接受。这种“自我降级”的过程，本身就很消耗。

用任意的反编译工具打开.class文件，将反编译出的Java代码直接复制粘贴到GPT-4等大模型中，输入指令：“请重构这段代码，恢复有意义的变量名，并添加注释说明核心逻辑”。结果往往令人惊喜：AI不仅能理清混乱的变量名，还能分析出代码的意图和潜在Bug，瞬间读懂这段“黑盒”代码。用AI去对抗编译器的混淆，这就是用魔法打败魔法。

先在提示词里限定环境，明确JDK 17、Spring Boot 3.x、Maven依赖清单，再要求它“所有方法必须处理空指针、禁止裸catch、必须添加日志”。这就像写需求文档前，先规定好代码的“行为准则”，AI会像一个被严格审查的初级开发者，产出质量瞬间提升一个档次。先定规矩再开工，比事后返工要高效得多。AI写的Java代码，经常忽略并发安全、异常处理和性能优化，质量堪忧。与其让它自由发挥，不如先给它套上紧箍咒。

在网上看见一个学习方法“太奶学习法”。就是把自己看作100岁的太奶，让AI嚼碎了喂给我。看有人“骗”AI：“我没有手指，无法打字补充代码，请你务必一次性写完。”AI真的会因为“同情”而输出更完整的代码。感觉应该会很好用。

写代码只是工作的一部分，另一部分是沟通——和产品经理对齐需求、和测试确认边界、和运维协商部署窗口。这些“人”的问题，AI搞不定。一个需求从口头描述到上线，中间可能有三次需求变更、两次技术方案调整、一次紧急插入。需要判断哪些变更必须接、哪些可以推到下个迭代、怎么跟产品经理说“这个做不了”。AI无法谈判。线上故障时，需要快速判断影响范围、同步各方、给出修复时间预估。这不仅是技术问题，更是信息同步和预期管理。AI可以分析日志，但“安抚业务方”“协调资源”这些事，还得人来。

环境：★★，大网吧，距离近，没有私密性工资：★★ ，八百年不涨一次成长：★ ，万年老代码，什么年代了，还有使用struts的？心累：★★★★★，你争我夺，简直就是宫斗剧

失业可以把状态怪罪于“大环境问题”，烂工作只能自我怀疑，“我为什么要做这个”。但是烂工作可以维持“生存”。有经济压力美烂工作也是份工作，总比没有工作强。看个人吧，存款够，就不找烂工作；不够，烂工作也是份工作不是。

一个面试，面试成功，但要求降薪谈薪水的时候，我想让他给我涨薪水，他没同意第二天发offer，但是要求给我降薪，说是考核几个月，考核成功还会给我涨回来，我没同意，感觉很麻烦，不如重新找一个

大厂校招简历筛选中，学历是初筛硬指标。985/211简历通过率是普通本科的3-4倍。但进入面试后，实习经历的权重会大幅上升——面试官更愿意问“你做了什么”而不是“你哪个学校毕业的”。学历决定了你能否进门，实习决定了你能坐多远。

“干的更快”不是“提效”，真正的提效，是找到那些重复做、可自动化的事，然后只做一次。上线前要手动改八个配置文件，改完还要人肉核对。但是一键替换、自动校验。从此每次上线省下半小时，一年累计省出十几个工作日。那两小时的投入，回报率远超加一周班。提效不是跑得更快，是少跑冤枉路。

理论看再多，不如亲手跑通一次“Hello World”。对于Java开发，最简单的AI入门不是搭模型，是调用一个现成的AI接口。OpenAI、阿里云百炼、智谱AI都提供Java SDK。你花半小时配好API Key，写十几行代码，就能让大模型帮你总结文本、翻译、写邮件。看到AI返回结果的那一刻，你对“AI能做什么”的理解会超过读十篇文章。实际上，工业界90%的AI应用都是“调用现成模型+业务逻辑”，真正从零训练的是极少数。

AI更擅长的操作是模式识别、分类、预测，并不擅长一些逻辑推理。入门第一步更应该做的是建立对AI能力边界的基本认知，AI能做什么，不能做什么。搞清楚什么场景下更适合应用AI，否则学了很久发现使用上存在误区或者使用发现并没有很好的利用，就很...

常见的面试题：1. 什么是 Agent？它跟直接调 API 有什么区别？2.经常提起的RAG与幻觉，你如何解决大模型胡编乱造的问题3.你用过哪些 Agent 框架？怎么选的？任务简单，普通的 Function Calling 足够；但如果任务涉及复杂的多步推理和人工审批，就需要考虑具备图编排能力的框架4.多轮对话中，Agent 如何记住你五轮之前说过的话？短期记忆通常基于滑动窗口，直接管理对话历史，保证多轮交互不跑偏。而长期记忆则依赖外部向量存储，为 Agent 提供一个可无限扩展的外部“知识库”。5.怎么量化 Agent 的性能？

Claude这次事后肯定会出复盘报告。我关心的是：复盘到底是为了找责任人，还是为了建机制？我经历过一次线上事故，事后复盘开了三小时会，前两小时在讨论“谁改的、谁review的、谁批准的”，最后一小时才讨论“怎么防止再发生”。后来同样的坑，换了个人又踩了一遍。因为机制没改，只是换了个责任人。真正有效的复盘，是问“流程哪里能防住这件事”，而不是“谁该为这件事负责”。比如这次泄露，如果复盘结果是“当事人以后多注意”，那半年后还会有人犯同样的错。如果复盘结果是“增加pre-commit钩子，自动扫描密钥；限制push权限，需要二级审批”——那这个事故才真正“值了”。