脉脉和牛客特别割裂

在这里奉劝大家一句，一个人如何，是看他在你低谷时是怎么对你的，而不要看他在你辉煌时是怎么对你的。 曾经我讲过我的故事，但有人说我是编的，我当然理解，毕竟人生而不同，有人家庭美满，有人家道中落，有人原生家庭，当然还有人没有父母。共情能力不是谁都有的，而且我奉劝大家，不要跟没有共情能力的人交朋友，他们只在乎自己。 每当看见一些帖子，一些短视频，在说自己的父母有多好，有多关心自己的时候，我都会很心酸，我多么希望我也可以有这样的温情，我多么希望那个人可以是我。 我甚至不能说，不能提，因为家丑不可外扬，因为说自己父母就如同说自己家庭不行一样，舆论、孝道、传统、脸面，难道这些东西就是为了让我打碎牙往肚子里...

26年2月，我匆匆从LX离职，着急忙慌地入职了某大厂旗下的游戏子公司。加上各类补贴，年薪接近19万。当时觉得总算攀上了一棵大树，心里还暗自庆幸——谁想到，这才是噩梦的开始。入职第一天，我就察觉到了不对劲。我的直属领导是一位年近四十、至今未婚的女性。别的组的大厂员工私下评价她“很努力”——但在这个行业里，“努力”二字有时并不是褒义。我们组的外包人数是全部门最多的，需求排期像一团乱麻，她对需求也是一笔糊涂账，经常前后矛盾、对不清楚。更离谱的是，同一个需求她会分配好几台设备，配置完全一样，而测试本身就需要漫长的游戏时间，跑完一轮还得写测试报告。于是，加班变成了毫无意义的消耗战——不是因为项目紧急，而是因为流程冗余、管理混乱。第一天走进工位，我看到组里那位外包兄弟嘴唇发白，脸上没有一丝血色。我当时还以为他生病了，心里嘀咕了一句“要不要问问他怎么了”。后来在组里呆了大约两个月，我才真正体会到他的痛苦——那种被反复折腾、又无处可说的绝望。有一件事让我彻底寒了心。那天，女领导让我跟着组里一个干了多年的外包一起做一个需求。她原话是：“你跟他一块儿干，他熟悉流程。”我照做了。结果那个外包自己把需求理解错了，从头到尾都没弄清楚到底要测什么。我还没来得及找他确认，吃饭途中就被女领导一个电话叫上去，劈头盖脸训了一顿。更让我憋屈的是，那个外包随后跑到领导面前，反过来告诉我：“以后有什么需求，你要直接问领导，别光跟着我。”——我当时就愣住了：明明是你让我跟着他干，现在出错了，倒成了我的责任？后来，我从上一个子公司离职的小伙伴那里听说，他也曾被这个女领导叫进会议室，当面说了一句让人至今难忘的话：“你连我们组的外包都不如。”听到这话，我反而释然了——原来不是我一个人被这样对待，这就是她的管理方式。两个月，足够看清一个地方。我开始后悔当初的“着急忙慌”，也终于明白，有些坑，不是大厂的名字能填平的。目前，正在积极投递简历，整个测试环境没那么糟糕。但是，只能说都是命，万般不由人。

012026年5月的最后一个下午，和往常没什么不同，校园里奔走的人们脸上写着的大都是兴奋于快乐，只是在我看来这一切已经不属于我们。由于有一些同学已经出去找工作，平日拥挤的宿舍显得空空荡荡，几个人个人在玩着游戏逃避现实，偶尔几句并不意气风发的对话，这就是我大学生活的最后一个学期，往日欢聚时的欢声笑语都已隐隐远去，将来走出校园也许就意味着走进孤独？这个夜晚，我又一次走进操场，狂欢了一夜的校园安静极了，我不得不想，走出这个校园，明天会在哪里落脚。春节过后，因为毕业实习而分别了很久的同学返回了校园，由于有了毕业实习单兵作战的酸甜苦辣，重新相聚，自然格外亲切，大家可能都意识到，大学所剩的时间不多，这是散...

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