前端哥们儿回来了

很多小伙伴对最终结果很感兴趣，结果我放在评论区了，之前发的小红书帖子 这场小红书前端社招一共四轮。最让我意外的是，几乎每一轮都花了很多时间在聊项目和作品。 我不是标准履历：专升本背景，过往找工作也遇到过学历筛选。所以这篇想记录的不只是题目，也想说说：如果背景不够漂亮，怎么用作品把面试聊起来。 我的作品集/开源主页在这里，后面提到项目时可以对照看： https://github.com/tt-a1i 先说结论  常规场景题会问，但这次真正展开的是项目。 作品要能现场打开、能讲清楚取舍，而不是只写在简历上。 手写题这块我发挥很差，3 道题都没写出来，但后面还是靠作品继续聊下去了。 对非标准背景的人...

最近继续投简历，真感觉前途一片黑暗。转全栈虽说有ai，但是后端的壁垒确实比前端大。春招唯一一个面试，业务二面完秒约hr面，过了三天问结果说挂。大二因为兴趣选择了前端方向，疯狂卷，觉得会有一个好的前景。拼了两年命，结局却烂尾。去年和学长的交流觉得前景挺好，今年直接爆炸，秋招拿了个烂保底，补录忙着拼实习转正，结果是催我赶紧入职解决完需求池转头又不需要正式了，春招前期兴致勃勃入职，发现erp当头一棒，但是想着继续干吧，错过了投递时间，现在是越来越没激情了。和带我的人一些开发理念不同（当然可能人家是资深我菜鸡），改了大半天吃饭的时候看到钉钉来一句让我别再动组件了，本来回家想再冒烟自测一下瞬间电脑又合上。10月之前的我意气风发，十一月之后的我走了全是烂路，一手好牌打的稀烂。两个月前我会兴致勃勃得研究ai，学学后端，现在的我下班只想躺。会躺多久？不知道，只剩下上班摸鱼看后端。当然躺着晚上也睡不着。2024年8月19日第一次报道时候的朝气蓬勃到现在的死气沉沉。分分合合，又变成了一个人的深漂，上一次的分别是为了追求各自的前途，现在是两个人的无奈。这一次不再是两个小时大巴就能的拥抱的距离了。总是在想如果我高中能有现在的觉悟高考多几分是不是结局就不一样了。如果当初不那么卷，是不是就不会这么不甘心。如果当初努努力考研，是不是能在ai冲击的时候有更多缓和。是不是当初学了后端，现在会有更多的选择。是不是当初直接考公，现在可能走到宇宙的尽头。现在没有人能救我了，不知道自己什么时候能捞起来自己。

目前学了html，css，目前在学JavaScrip，我现在二本大三还要继续学前端吗我是数据科学与大数据技术的，我现在的继续学前端还是学自己专业的我现在非常迷茫学过一段前端正如上面所说，我想知道我现在算什么阶段还要继续学吗还是放弃专注自己专业知识算了

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