大一 对大数据开发方向的迷茫

一、核心定义面向接口编程（Program to an Interface）是软件工程核心设计思想，不以具体类为依赖，而以接口为 “契约” 解耦 “功能定义” 和 “具体实现”；核心逻辑：调用方只关心 “能做什么”（接口定义的功能），不关心 “怎么做”（实现类的具体逻辑）。三、核心价值（软件工程核心考点）1.解耦：修改实现逻辑不影响调用方（如从 JDBC 换 MyBatis，仅改实现类，Service 层不动）；2.可扩展：新增实现只需加类（如加 EmpDaoRedisImpl 缓存实现），不改动原有代码（符合开闭原则）；3.易测试：可通过模拟实现类（如 EmpDaoMockImpl 返回假数据...

本来一开始没打算发这个帖子，后面实在遭不住，觉得还是有必要讲讲。本人从秋招到现在少说也有三段实习了，按我对自己的认知其实中小厂现在面试随便过的，但是现在基本上都要笔试，笔试题目都差不多还好，像什么算法和普通的常见手撕轮子（游戏开发，中间件开发，偏算法的开发），有的笔试题目喜欢搞自己的东西的，有时候真的是没绷住，会怀疑自己当初为什么投递这个岗位，尤其是量化和部分制造业是重灾区。然后就是面试，面试两极分化，问你八股项目的会往死里拷打，不问的就是一点都不问，随便问你怎么个个人情况，产出啥的，复盘下来也不知道有什么必要（据面试官所说这样就可以知道你的技术水平了，而且这还不是大厂特有的）。我就不提那种觉得表现好把你晾在那，或者觉得自己答得不好还有下文的。有的刷kpi的随便问个问题可能感觉不对了立刻走个算法流程手撕结束挂的，这种你说自己准备不充分吧也是真没招。面试笔试大概就是这样，讲一下实习。第一段是无薪实习，啥也没学到（真不是不想学，打杂就占了半边天，本来两小时完成的活，大厂各种拉会，对齐，讨论，四个会能花掉半天时间，就这样宗旨还是能不参加的会议不参加，能不必要开的会就不开，我一个实习不去听我真的是在文档里面把自己当活体RAG吗？）加班称之为奋斗者文化，福利待遇团建雀食看起来很给力，部门花的饼也很大，但是你是实习，所以对标人效优化后就没有留你的必要。第二段在小厂，压力也很大，自己能力有限只能上时间，上强度，各种屎山，面试拧螺丝，实战造火箭，好听点叫垂直管理，boss和你一起推进git commit，难听点boss觉得你做的不够好，一句傻逼甩到你头上你是真的会狗血淋头。但是好说歹说是有薪水了，每天住着青旅那人反生物钟开王者能让你真的是不得安宁，周内没法推进进度周末还得远程继续想办法push。前面的人大概率是顶不住压力所以走的，其实我倒是觉得还好（毕竟有两个实习生和我一起分担干活。）第三段算是中厂，表面上看活性加班，房补，自带饭堂，人文关怀拉满，实则背地要求实习至少12小时每天（我实习一周才给我单独间接找mentor透露）然后离家远外地很多事情要处理，分心，各种因素力不从心，老员工早起到岗，到我加班的时候都走光了，单兵作战，和上一段鲜明反差，没招，进度产出不明确，也不知道到底要我做什么，最后家里人压力我觉得我放弃保研名额考研可以试一下，一试不知道，试了吓一跳，公司知道当场给你开掉。这下好了，带着房租违约金打包回校，一点实习的钱都没多赚到。还要最后搞什么几十天冲刺考研。说自己有把握都是假的，我又不是什么天才，网上各种课各种营销各种坑，本来我就是一大一面向就业编程的，非要东拼西凑，脑子装的东西经常和就业那一套互博，也没有很清晰的学习规划，模拟卷都是做都做不完的，真题是看也看不懂的，上了考场我说第二天这个难度我过不了线，我不考了吧，家人非要我考，最后成绩出来如我所料就是没过。中途考研我还对秋招抱有侥幸，还在投，还在面，甚至wxg还捞过我，虽然打击更大就是了。然后家里人还在说全心全意考研...真没招了。考完研就算了，按理说该专心找工作了对吧，欸我家里人看我到寒假了，有空了对吧，那你回老家照顾一下家里老人吧，这一回去，在火车上电脑给人摔了，到老家几天后坏了，过年找了三家最后物流总算是寄到主板换了一个，又耽误了两个月，等我反应过来春招就开始了，真的是心力憔悴，然后不得不用和秋招甚至比秋招更大的强度高强度复盘，就是那种麻木，反馈感缺失，每天面对到底是知识的欠缺还是基础的问题感到无力适从，我怎么一遍又一遍解释我实习时间不够？还是直接简历改一下造假，然后面试被拆穿？怎么解释中间空挡不是我拿了offer而是被逼着去考研，还是单纯想作死自己？现在我都不知道是要再去用仅有不多的时间去开一个新的所谓的网上学的项目，还是先搞定我当初不知道怎么想的急头白脸的选的自己根本没有任何基础的机器学习的毕业设计？家里人说了你自己决定，大不了考研再战，但我很清楚，再战牛魔，从一开始面向就业我就很清晰的建立的信念就是，这个环境有口饭吃尽最大能力尽快争取，不是学历跃迁家里有旷没必要给这脸上贴金，上大学上的人都痴呆了，还指望我能做在自习室一天一直面对整张卷子的错题泰山崩于前？是的我到现在还是0offer，那咋了？你真的想混口饭吃，有的是混的，但是归根结底，每个辗转反侧的夜晚脑海里我都会回响着，我不甘心。从现在的角度来看，其实反而是那段被各种帖子诟病pua的小厂能收获的东西是最大的，其他的厂归根结底技术栈不对口进去基本是零基础，他们不可能真的手把手带你做个什么东西，更别提时间问题。如果再让我选我可能会留在小厂坚持下来学到真本事，而不是听网上千八百万项目课的所谓就业规划去镀一个title（关键人家大厂根本不认），摸爬滚打这么久有时候真的很怀疑做这些的意义是什么...累了，算了不想讲了，明天还有一堆笔试要做呢。

估计后面2 3个月只有社招的面经了, 粉丝群的春招和暑期的小伙伴分享的差不多了1. 自我介绍2. Java 中 final、finally、finalize 的区别答案：final 是关键字，可以修饰类、方法和变量。修饰类表示不能被继承，修饰方法表示不能被重写，修饰变量表示引用或值不能再次赋值。需要注意的是，final 修饰对象引用时，只是引用不能变，对象内部状态仍然可能改变。finally 是异常处理结构的一部分，通常用于释放资源。无论 try 中是否发生异常，只要 JVM 没有直接退出，finally 通常都会执行。比如关闭连接、释放锁、清理临时文件。finalize 是 Object 类...

在我来鹅之后，接到的第一个完整大需求就是需要编写一个skill，之前的实习也写过一些skill，但是在我的理解中skill就是跟提示词没差，把你需要的目标全写上就好了，所以第一次mr我提交了一个超过1200行的md，被mt打了回去，为了完成这个需求，我又赶紧请教了我身边的大神同学，获取一些写skill的经验，将原先1200行的md进行了对应的references拆封，又通过我朋友教我的验证机制验证这个skill的效果，最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill，那么今天来给大家分享怎么去写一个好的，可以实际用来工作的skill，摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0：先写 EvalsEval（Evaluation，评估）是一套结构化的、可重复运行的测试用例集，用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下"，而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例：- 正例（Positive）：用户说“帮我看一下这个 PR 能不能合”，验证 Skill 应该被加载- 负例（Negative）：用户说“帮我把代码格式化一下”，验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界（Edge）：“这个 PR 改了一行日志，要不要审”，验证边界情况下的路由行为正例和负例都要写，而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次：如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大，只在一种模型上过了不够。没有 evals，你改 description 就是在盲改，一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1：写 Description（最难的一行）description 是路由触发器，不是文档。写好它不需要关心 Skill 的内容，只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式，每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么，好的 description 说什么时候加载。举个监控 PR 的例子：不要写这个 Skill 做什么，要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单：- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图，最好来自真实查询- 不总结工作流程Step 2：写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具，只要提名字，模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多，尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例，它们是最高信噪比的内容。每次 Agent 搞砸了就加一条，gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md，放到 accessory file 里渐进加载。Step 3：用层级结构- scripts/ —— 确定性逻辑，模型不用每次重新发明- references/ —— 重型文档，条件触发才读（"如果 API 返回非 200，读 api-errors.md"）- assets/ —— 输出模板，模型直接复制填充- config.json —— 首次运行设置，问一次保存下来对于极其复杂的 Skill，进一步考虑是否应该拆成一组 Skill，用 depends: 声明加载关系。Step 4：迭代切分支出来，在无 Skill 的状态下跑 hero query（核心用户场景查询），建 eval 集，反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大，甚至会 spillover（溢出）到其他 Skill，所以这些在 Step 5 之前做完。Step 5：发布大家快把这5步实行起来，成为写skill专家吧！