救助，求看简历，被挂麻了

当“双非”这两个字成为简历上绕不开的标签，到底要攒下多少段实习、改出多少版简历，才能推开那扇被985/211光环遮蔽的门？林然用三年时间，把自己从一家本地小公司的打杂助理，磨成了手握多份offer的求职者。他没有拿到逆袭的剧本，前前后后投出113份简历，真正换来的不是幸运，而是几条被现实反复敲打后刻在脑子里的真结论。一、实习圈那句“越早越好”，他用三年才真正听懂大二那年暑假，林然得到第一份实习——在一家本地母婴品牌做市场助理。每天的日程是整理发票、贴报销单、给会议室加纸杯。同期有同学在朋友圈晒出互联网大厂的工牌，他说不羡慕是假的。但正是这段看似没技术含量的经历，让他无意中接触到快消行业的渠道促...

今天是我在公司的 Last Day，实习了整整145天，此刻的心情既开心又有些低落。开心是因为终于拥有一段自由的时间，可以去做自己想做的事；心情低落是因为要离开这个充满温度的小部门了。刚进公司 大办公楼 配MAC笔记本 显示器随便用 电竞椅 狠狠被震撼到了 这对小小的老子来说超过心理预期在这100多天里， 我真真正正地体验了从需求评审到项目正式上线的全过程。从一开始只会写局部代码，到后来能独立负责模块（虽然中间也有过小翻车），从最初不懂需求到后来能精准理解需求，我一直紧跟部门大佬们的步伐。我不光是在模仿他们的代码，更是在学习他们处理问题的方式。从被主管简单表扬 到被服务端搭档认可表扬 到提测一把过 小小的老子 那是一种说不出来的爽 。从最初的懵懵懂懂，到后来也能顶起“小小小小小半边天”，谦虚地说，我的代码能力突飞猛进，处理事务的能力有了很大提升，理解力和沟通能力也在不断进步，我的心态有了巨大的转变。我很荣幸能加入这样一个精悍的团队，有时候真的会被大佬们牛逼的架构和简洁的代码震撼到，这让我更加想努力跟上他们的脚步，也让我对开发行业更加感兴趣，渴望去挑战更有难度的事情。感觉也算幸运，离职前突然收到面试，突然有了很理想的offer。这不得不说 从大三面试到现在一共14场面试 拿下13场 也算微微幸运嘻嘻最后，祝各位部门的前辈工作顺利，代码永远没Bug，绩效永远拉满！！！

美工职业一个月能拿多少工资？在许多人的印象中，“美工”似乎就是坐在电脑前修图、做海报的设计人员。这个职业门槛看似不高，但薪资水平却千差万别。有人拿着3000元的月薪苦苦挣扎，也有人月入过万甚至更高。那么，一名美工的真实收入到底是多少？究竟是什么在决定他们的“钱途”？要回答这个问题，我们不能只看一个数字。根据国内主流招聘平台（如BOSS直聘、前程无忧）2024年的数据显示，美工岗位的月薪大致呈现以下分布：初级/实习美工（0-1年经验）： 月薪普遍在 3,000 - 5,000元。这部分主要是刚入行的新人，能熟练操作PS、AI等基础软件，但缺乏独立完成商业项目的能力和经验。中级美工（1-3年经验）...

在我来鹅之后，接到的第一个完整大需求就是需要编写一个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专家吧！