哈哈，把我室友拉下水报名这个了

最近在北京面了一圈，越面越清醒：大厂看着光鲜，可进去之后大多是重复劳动、流程冗长、晋升看年限，想做点有成就感的事反而很难；小公司又参差不齐，要么管理混乱，要么老板画饼，干几个月就散伙的也不少。踩过几家坑之后，终于遇到一家让我愿意留下来长期干的科技公司：中思创新（北京）科技有限公司。不是广告，纯个人求职体验，给同样在找技术岗的朋友一个真实参考。我最在意的，从来不是公司多大，而是能不能学到东西、氛围舒不舒服、值不值得长期投入。这家公司，刚好踩中了所有我想要的点。氛围：没有虚的，大家都在认真解决问题一进公司就能感觉到，这里没有职场表演。不搞早会晚会打卡文化，不搞无意义汇报，不搞上下级那套。领导和工程...

其实我到现在都不知道该怎么称呼你们。叫全名太生分，叫外号又有点叫不出口。那就直接说了吧。四年，我们四个人挤在二十平的屋子里，一人一张床一张桌，头顶头脚对脚。现在回想起来，很多细节可能要很久以后才会慢慢想起来，但有件事我记得特别清楚。还有就是，去年冬天你考研。那几个月你每天早上七点多出门，晚上十一点多回来。每次推门进来，宿舍灯永远亮着——不是为了等你，但好像也确实是。还有件事我觉得挺抱歉的。大一那会儿我晚上打游戏打到很晚，键盘声噼里啪啦的。你们没一个人跟我说过“小点声”。后来我才知道，有段时间你们第二天早上有早八，被我吵得睡不着。我挺过意不去的，这事儿欠你们一句对不起，现在补上。我们很少聊心里话，更不会说什么“你是我最好的朋友”这种话。但这四年，我们一起点过不知道多少次外卖，一起骂过食堂的菜越来越贵，一起在查四级成绩那天心惊胆战地刷新页面，一起在最后一个人期末考完那天出去吃了顿烧烤。那天没喝多少酒，但气氛莫名其妙有点伤感，谁都没提“毕业”两个字，但谁都清楚，这种四个人整整齐齐坐在一起吃饭的日子，不多了。要走了。以后不会有人在熄灯后开着手电筒上厕所了，不会有人帮你带食堂的煎饼果子了，不会有人在你睡过头的时候叫你起床了（虽然叫了我也经常没听到），不会有人在走廊里喊“谁拿了我充电宝”然后发现就在自己手里了。这些话当面说不出口，写下来好像也没那么难。谢谢你们，四年，承蒙照顾。以后常联系吧——虽然我知道，这话说了大概率也不会真的常联系。但没关系，就冲这四年，你们都是我大学里最重要的人。毕业快乐。

正在裁员，已经裁了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专家吧！