华为OD真是路边一条

说个我认识的亲戚的真事。大四上学期，他拿到了一家还不错的公司offer，岗位也对口。结果学院说大四必须在校上课，不批实习。他去找辅导员，辅导员说找院长。找院长，院长说找教务处。教务处说你先把课上完。一圈下来，跟我之前那篇写的一模一样，皮球踢得贼溜。他舍友选择了认怂，乖乖回来上课，实习黄了，后来秋招海投简历，面了十几家全挂。但我这朋友没认。他直接跟公司说能远程办公，白天上课晚上干活。课能翘就翘，不能翘就坐后排写代码。期末考试请假回来考，成绩刚好及格线飘过。辅导员找他谈了三次话，他就一句话："我要毕业，我要工作，课我不会落下。"最后学院也没真处分他，因为他成绩没挂，实习也确实签...

26届，双非本，还有20多天就要毕业了，我现在 0 offer。感觉自己的人生要完蛋了。。。但是又能怪谁，全都是我自己作的。我有罪、对不起面试被我放鸽子的面试官。面试定的早上9点，结果我定错了闹钟定成了第二天的早上9点，等我睡醒的时候已经是快10点了。。。。我有罪、对不起帮助我的学长，秋招的时候有个学长帮我看简历、还内推我了一家还不错的大厂，但岗位不是太合适。我听说大厂都会看面评，我怕表现不好脏面评，就不敢面了，然后那场面试就鸽了。学长后来问我，我撒谎说自己生病了。。我有罪、对不起支持我的女朋友！！她之前家里一堆事情，爸爸生病了，她请假回家了几天，又立马回来陪我，陪我去双选会、看到好的招聘机会都会发给我，我自己心态不好，经常不回信息、冲她发脾气。有天晚上我发神经迁怒她，讲了非常难听的话，她什么都没说，只让我早点休息，她一直都在包容我。。。我有罪，秋招本来有个小厂offer，但当时拒掉了。主要是觉得春招能找到更好的，结果现在春招没offer了，前天问hr想舔回来，人家已经招到人了。。。我对不起父母、我该死！！我爸妈到现在还以为我"在面试阶段"。我妈上周打电话还说"不着急，慢慢挑"。我挂了电话哭了半小时。我不是在挑，妈，我是真的没有人要。 但我是真的不知道接下来该怎么办了。秋招春招全寄了、应届身份马上就没了。我就是欠骂！我就是该死！牛爷爷们，我还有救吗？

入职实习没多久，我和另一位实习同事一起接手了一个开发需求，这次的经历真的让我狠狠看透职场偏见。对接需求时，设计师简单潦草讲完方案，全程笃定这个功能超级简单、零难度。我和同事刚接触项目，对整体业务逻辑完全不熟悉，加上是实习生不敢多问、也没经验复盘，来不及细致讨论就老老实实接下了任务。我们原本以为只是基础开发，踏踏实实准备开工，完全没料到后面会闹出巨大的对接矛盾。直到带教老师抽空帮我们拆解需求，我们才彻底懵了！这个看似简单的功能，实际上牵扯超多隐藏业务逻辑、数据联动和兼容问题，开发工作量极大，根本不是设计师口中随手就能做完的小任务。理清所有细节后，我们特意在对接会议上，主动想跟设计沟通真实的开发难...

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