方向：AI Agent可以理解为一个能使用LLM作为大脑，并配备规划、记忆和工具使用能力的智能体。它不仅仅是聊天，而是能自主完成复杂任务，比如帮你订机票、写一份市场分析报告并发送邮件、自动管理你的智能家居。适合：喜欢折腾、有想法、希望快速将AI能力落地到具体场景中的开发者。对产品、系统和自动化感兴趣的工程师。希望探索AI能力边界的创业者和研究人员。核心技能：LLM应用开发：熟练掌握提示词工程，了解如何调用OpenAI、Claude等API。Agent框架：熟悉主流的Agent框架，如LangChain、AutoGen、CrewAI等。编程能力：Python是首选，需要能够编写函数、调用API、处理数据，让Agent能与外部世界交互。系统设计思维：懂得如何设计Agent的工作流，规划其记忆机制，以及如何让它可靠地执行任务。学习路径：掌握Prompt Engineering：学习如何清晰地给LLM下指令。学习LangChain：它是最流行的Agent开发框架，通过官方文档和示例代码学习如何串联Prompt、模型和工具。动手做一个简单的Agent：比如做一个能帮你查天气、查资料、并总结成邮件的个人助理。关注前沿：多看看AutoGen和CrewAI，了解多智能体协作的魅力。AI Agent被认为是通往AGI的关键一步。目前它正处于爆发前夜，充满了大量的创新机会。

现在很多AI创业公司都在做“套壳应用”，没有壁垒。未来的机会在于“数据飞轮”和“垂直整合”——谁能在一个特定场景里积累高质量的私有数据，并用这些数据持续优化模型，谁就能建立护城河。至于伦理风险，最担心的是AI被滥用。比如有人用AI伪造我的声音打电话给我父母骗钱，这种技术一旦普及，后果不堪设想。作为开发者，至少要做到两点：一是在应用中加“水印”或“声明”，让用户知道这是AI生成的；二是建立反馈机制，让用户举报有害内容。技术是中性的，但使用技术的人需要有底线。

产品经理问：“上个月用户活跃度怎么样？”模型生成的SQL只查了用户数，但产品经理其实想看的可能是“活跃用户占比”或者“不同渠道的活跃度”。自然语言太模糊了，模型猜不到用户真正的意图。 后来我们加了一个“意图澄清”环节：当问题模糊时，模型先反问几个选项，让用户选择。比如“您是想看总活跃用户数，还是按渠道划分的活跃用户？”虽然多了一步交互，但准确率大幅提升。另外，SQL生成最怕数据库结构变化，字段改名了，模型还在用旧名，所以需要定期更新schema描述，并且在生成时注入最新的字段注释。

用AI写营销文案，它写得特别华丽，但总觉得不对劲，后来发现它用了太多“极致体验”“颠覆行业”这种夸张词汇，反而显得不真实。AI生成的文案往往缺乏“人味儿”，太像广告模板了。那么先让AI写一个“啰嗦的初稿”，然后自己手动删减，把那些虚词去掉，换成具体的描述。还有一个坑是版权问题，有一次它生成了一段话，我查了一下，几乎和某篇博客一模一样，只是换了几个词。所以现在做创作助手，一定会加一个“改写”步骤，让模型用自己的话重述，并且要求加入新的例子。

我每天都在和自己的代码助手相爱相杀。如果现在让我从头做一个代码助手，我不会只想着“让它能写代码就行”，而是会问：它到底要帮程序员解决什么痛苦？程序员最烦什么？烦的是：1、写重复的样板代码（CRUD写吐了）2、查文档（“那个函数的参数是啥来着？”）3、改bug（“这报错什么意思？”）3、理解别人的烂代码（“这坨屎是谁写的？”）一个真正有用的代码助手，应该覆盖这四个场景：生成、解释、调试、重构。第一步，代码补全和生成。接个 GPT 接口，把用户的问题和当前文件扔进去，让它生成。做一个代码库索引，把项目里的所有文件、函数、类、依赖都解析成向量存起来。当用户写代码时，自动检索当前文件附近的相关代码，以及项目中类似的模式，作为上下文喂给模型。第二步，给模型一个函数，让它用一句话说清楚这个函数是干什么的。要训练它输出简洁的摘要，因为程序员没耐心看长篇大论。第三步，当用户贴报错时，我们不只是看报错信息，还会拉取相关的代码片段、调用栈、变量值（如果用户提供）。然后让模型定位到具体的代码行，分析为什么会出现这个错误。第四步，代码写久了，总有一些“代码坏味道”：函数太长、重复代码、命名太烂。重构助手就是帮代码“健身”的。做一个预览模式不直接改代码，而是生成一个“重构建议报告”，让用户自己选择是否应用，并且支持一键回滚。程序员是最挑剔的用户。生成的代码有一点瑕疵，他们就会骂“AI 写的什么垃圾”。代码助手的定位不是“替代程序员”，而是“给程序员打下手”——干脏活累活（写样板代码、查文档、翻译报错），让程序员专注于更有创造性的工作。

首先理清头绪，三个问题：用户是谁？他们要解决什么问题？我手里有什么资源？第一步，分析并理清分层逻辑。用户进来第一句话，我得先判断这人是来干嘛的。是来骂人的？是来问路的？还是来调戏机器人的？我会用一个轻量级的分类模型（比如BERT微调）快速识别意图。如果是骂人、涉政、或者明显想搞事情，直接转人工或者礼貌结束对话。别让模型跟用户对骂，那是灾难。第二步，高频回答。大多数用户问的都是重复问题：退货政策、物流查询、改地址。这一层我用RAG，把知识库里的标准答案检索出来生成回复。要求是快、准、稳，温度设到0.1，不要有任何创造性，照着文档念就行。第三步，多轮任务。如果用户说“我要退货”，这就不是一问一答能解决的了。需要进入一个状态机：先问订单号，再查订单状态，确认是否在退货期内，然后生成退货地址，最后通知仓库。这一层我会上Agent，让它调用后端的API，每一步都向用户确认，走完整个流程。第四步，转人工。这是最重要的安全网。当模型连续两次不确定、用户情绪检测为负面、或者用户明确说“我要找人工”时，必须无缝转接，并且把对话摘要一起带过去，让人工客服不用重复问一遍。难点一，多轮对话的“失忆症”用户：我的订单怎么还没到？客服：请问您的订单号是多少？用户：123456客服：好的，查询到您的订单已发货，预计明天到达。用户：那它多少钱？这个“它”指的是什么？是订单总价？还是运费？还是某个商品的价格？模型如果忘了上文，就会乱猜。我们尝试了两种方法：一是显式维护上下文状态，把每轮的关键实体（订单号、商品名、价格）抽出来存着；二是在查询改写时，把“它”替换成上一轮提到的实体。但有个坑：如果上一轮提到了多个实体，改哪个？这时候需要模型判断指代的是什么。多轮对话做到最后，你会发现它其实是半个“推理问题”。难点二，情绪的“温度计”用户明显已经生气了，但模型还在机械地回复“请问还有什么可以帮您”。用户直接炸了，发了一长串感叹号。加了一个情绪识别模块，实时分析用户输入的情感分数。一旦低于某个阈值（比如负面情绪强烈），立刻触发两个动作：第一，回复语气变得特别客气（“非常抱歉给您带来不便…”）；第二，如果用户持续负面，直接转人工。客服的第一原则不是解决问题，而是安抚情绪。 情绪没稳住，问题解决了用户也不满意。不能指望一个模型解决所有问题。要设计的是一个系统，让模型、规则、API、人工各司其职。用户不会因为是AI就降低要求，他们只在乎“我的问题解决了吗”、“我等了多久”、“你态度好不好”。

RAG 中如何选择分块大小和策略？对于代码文档和叙事性文本，分块策略有何不同？（代码文档适合按函数或类块切分，叙事文本适合按段落或自然语义边界）什么是查询改写？为什么它在RAG中重要？在多轮对话中，如何利用历史信息改写当前问题？（通常需要维护对话状态，将当前问题与之前的对话拼接成独立、完整的问题）如何处理RAG中的多跳问题？你如何判断一个问题是否是多跳问题？（可以通过问题中是否有多个实体、关系词，或依赖常识判断）在RAG系统中，如何实现混合检索（Hybrid Search）？什么时候密集检索会失效？（当问题包含精确数字、罕见实体，或者语义上难以区分时，密集检索可能不如BM25）如何评估RAG的忠实性（Faithfulness）？如果忠实性低，可能的原因有哪些？（检索到的文档本身与问题不相关、模型无视文档自由发挥、温度过高导致随机性太强等）什么是Agent？它与RAG有什么区别和联系？你会在什么场景下选择Agent而不是纯RAG？（需要执行动作、多步推理、动态决策的场景，如个人助理、自动化操作）如何评估RAG系统的整体效果？（不仅是检索）如果检索召回率很高但生成得分低，可能是什么问题？（检索到的文档噪声多、排序不佳、模型没有正确使用文档）在RAG中，如何处理表格和结构化数据？如果你要做一个财报分析助手，如何让RAG理解财务报表中的数字关系？

请解释什么是大模型？它与传统AI模型有什么区别？为什么会涌现？大模型为什么需要那么大的算力？什么是Transformer？为什么它这么重要？自注意力机制是怎么工作的？为什么要用多头注意力？什么是Prompt？什么是In-context learning？Zero-shot, one-shot, few-shot有什么区别？什么是模型的参数？参数越多越好吗？有没有参数不是最多的但效果很好的模型？比如MoE架构？什么是Token？如何计算Token？中文和英文在Token计数上有什么区别？为什么英文单词通常被分成多个子词？什么是温度（Temperature）？它对生成有什么影响？在什么场景下用高温？什么场景下用低温？请解释一下什么是大模型的“幻觉”？什么是RAG？为什么要用RAG？

通过好友后，不要只发一个“您好”就等着。HR可能在看你的消息时被别的事情打断，回来后就忘了你是谁。建议把“问候+自我介绍+意图”打包成一段发过去。老师您好，我是今天上午投递了【JAVA开发岗位】岗位的张三。我有3年垂直行业经验，看过JD觉得非常匹配，附件是我的简历和过往作品集链接，希望能获得面试机会。

HR每天会收到大量好友申请，验证信息是决定是否通过的第一道门槛。如果验证信息空白或只有“你好”，对方很可能当作无关人员忽略。岗位 + 与岗位的强关联： 张三应聘Java开发-曾主导过支付系统重构

当框架的年龄比自己还大，当修改一行代码需要祈祷三天，当所谓的“技术升级”只是给屎山换个容器——这时候的工作，已经不是“消耗”了，简直是凌迟。消耗分很多种。一种是重复劳动的麻木，另一种就是窝经历的——在废墟上修修补补，却被告知这就是“建设”。最可怕的是，你明知道这栋楼随时会塌，却只能用一根木头硬撑着，还要假装这很稳固。金融项目，每一行代码都绑着真金白银，改不得、动不得，只能像文物修复师一样，小心翼翼地给一堆腐烂的逻辑涂防腐剂。成长需要呼吸的空间。需要你能拆掉一面墙看看结构，需要重构一段逻辑验证想法，需要在代码里留下自己的思考痕迹。但在屎山面前，什么都做不了。窝只是一个人肉维稳系统，确保这堆垃圾今天不崩溃，明天还能跑。所有精力都用来“维持”，没有一丝留给“创造”。更荒诞的是“新框架挪屎山”——就像给一栋危房刷一层新漆，告诉业主“我们翻新了”。但地基早就烂了。框架是新的，逻辑是乱的，耦合是死的。敲下的每一行代码都不是在构建，而是在给屎山添砖加瓦。这种工作做久了，会怀疑自己：我到底是程序员，还是垃圾填埋工？仿佛能闻到那股代码的“霉味”——那种动一处、塌一片的无力感，那种明知是屎山却要徒手搬运的绝望，那种“新框架装旧酒”的荒诞。就像被困在一个永远修不好的老房子里，每天敲敲打打，却看不到完工的那天。时间不是飞快，是黏稠的、沉重的，每一秒都在消耗对这个职业的热爱。趁着年轻，我走出这片屎山，以为迎接我的是一个雷雨交加的未来，没想到，外面是晴空万里，阳光明媚。趁着年轻，我们机会还很多，不要消耗自己，走出去看看。

对我而言，成长不是敲出了多少行代码，而是当我敲下代码时，脑子里的那些“化学反应”。我记得那种纯粹“消耗”的感觉：接手一个祖传的老项目，面对一堆没文档的代码，每天在已知的Bug里打转，在繁琐的业务流程里做着机械的CRUD。那时，时间过得很慢，内心充满疲惫，感觉自己像机器上的一个零件，不断被磨损，这是失去“活人感”的开始。而现在的“成长”，是我感觉自己像在雕刻一段逻辑。比如，当我拿到一个看似简单的需求，不再急于上手写Controller和Service，而是会多想一层：这个业务的核心领域模型是什么？未来可能有哪些变化？如何用设计模式把变与不变分离开？这种从“实现功能”到“设计系统”的转变，让我觉得时间飞快。因为我在主动思考，而不是被动执行。这种“活人感”，在我看来，就是在技术世界里，依然保持着对“为什么”的好奇心。没有因为工作年限的增长，而丧失对技术本质的探索欲。为一个优雅的抽象拍案叫绝，为一个性能的微小提升而兴奋不已时，我感觉自己是鲜活的，是有创造力的，而不只是一个写代码的工具。成长，就是把每一次编码，都变成一次与自我思维的深度对话。当代码不只是任务，而是思考的延伸时，时间便成了滋养，而非消耗。

一、通勤时间JAVA八股文，死记硬背。把高频面试题录成语音备忘录：比如“HashMap原理”“JVM内存模型”，通勤时戴着耳机反复听，像背单词一样形成肌肉记忆。二、午休时间1. 修改简历，每天优化一个小模块，比如今天只优化“项目难点”的描述，明天只调整“技术栈”的排序。积少成多，一周就能出一版新简历。简历需要好好打磨，适合自己的最重要，面试官一问一个不知道就会心态爆炸2. 把招聘软件的沟通时间固定在午休前20分钟，批量回复消息、约面试时间。尽量集中在午休时间或者节假日休息的时间三、工作间隙1.编译代码、服务重启、跑测试用例的碎片时间（每次3-5分钟），最适合刷一道LeetCode或看一段源码解析。2.LeetCode APP或微信小程序，只看“每日一题”或高频简单题。不要贪多，一天积累2-3道题的思路就够了3.面试答不上来的问题，立刻记在手机备忘录里，晚上统一查漏补缺。四、夜晚闭环时间1.面试时的录音留到晚上，听自己的回答，哪些地方卡壳、哪些表述不清，针对性改进。2.回顾当天工作中遇到的Bug或优化点，思考“如果面试官问这个，我该怎么讲成故事”。比如今天解决了一个慢SQL，就整理成“问题现象→排查工具→优化方案→性能提升”的结构化表达。

AI岗位需求同比暴涨12倍，平均月薪超过6万。说实话，第一反应是——这数字晃得人眼晕。作为一个干了几年JAVA开发的普通码农，你说我眼红吗？眼红。你说我心慌吗？也心慌。眼红是因为，干了这么多年，熬过多少夜、改过多少bug、接过多少需求，工资条上的数字还在那儿慢慢爬。那边倒好，一入行就奔着六万去了。心慌是因为，这风口来得太猛，猛到让人忍不住问自己：我是不是要被落下了？AI赛道确实香。不是香在“六万”那个数字，而是香在这个赛道还在狂奔，还没定型，还有很多位置等着人去坐。不像有些技术栈，十年如一日，会的都会了，不会的也不用学了。但我也知道，那个“平均月薪六万”不是普通人伸手就能够着的。能拿这个数的，要么是名校科班出身，要么是有硬核成果傍身，要么是赶上了早期红利。我一个写业务逻辑的JAVA选手，转过去得从头学数学、啃算法、调模型，能不能熬出头，真不好说。可问题是，不转就不焦虑了吗？每次刷到各种AI取代程序员的文章。虽然心里知道没那么快，但总有个声音在嘀咕：五年后，十年后，普通开发还能剩下多少位置？与其等着被浪潮推着走，不如自己先下水试试。所以我的答案是：转。在转。不是说立马辞职、all in AI。那太冒险，也不现实。我的方式是，白天该写JAVA写JAVA，晚上下班回家，挤出点时间，从最基础的Python开始，从最简单的线性回归开始，一点一点啃。学得慢没关系，踩坑很正常，重要的是——先下水，别站在岸上看。刚开始学的时候挺挫败的，调个模型半天不收敛，梯度爆炸了都不知道怎么救。但后来想通了，当年学JAVA不也是从Hello World开始的吗？谁不是从零过来的。普通开发有没有必要转AI？我的答案是：如果你还想在这个行业干十年，那就有必要。不是为了追风口，是为了多一张船票。船来了，你得先在水里，才能爬上去。至于能不能成功，不知道。但我知道，坐在原地焦虑，肯定不是办法。动起来，哪怕每天只往前蹭一点点，也比原地踏步强。毕竟这年头，能让自己多点选择，就是最大的安全感。