适用对象：目标加入星网锐捷的求职者一、公司全景画像（30秒速判）福建星网锐捷通讯股份有限公司是国内领先的ICT基础设施及AI应用方案提供商，成立于2000年，2010年在深交所上市，拥有星网锐捷、锐捷网络双上市公司集团，员工总数超1.1万人。公司控股股东为福建省电子信息集团（持股26.39%），实际控制人为福建省国资委，属于典型的国有控股科技企业。这家公司处于 “AI算力基础设施建设驱动的结构性转型期” 。2025年实现营业收入191.57亿元，同比增长14.31%，其中企业级网络设备收入141.59亿元，同比大增26.74%，占营收比重从66.66%提升至73.91%，已成为增长的绝对核心；...

代码题 1. 从一个超大文件中统计不同电话号码的个数，条件：电话号码固定 8 位，文件太大无法全部加载到内存。2. 从 N 个数中找最小的 K 个数。要求：不能全部排序。Milvus/向量数据库1. 向量相似度计算原理是什么？2. Milvus 底层索引算法是什么？3. HNSW 了解吗？MySQL1. InnoDB 索引底层数据结构是什么？2. 怎么看一条 SQL 是否使用索引？3. 为什么使用 B+树？4. B+树查询复杂度？5. B+树插入流程？6. B+树插入复杂度？7. 为什么不用 Hash 索引？8. 联合索引用过吗？Redis1. Redis 用单机还是集群？2. Redis 集群了解吗？3. 说说缓存穿透和缓存雪崩。4. Redis 集群如何同步数据？5. AOF 全称？HTTPS1. HTTP 和 HTTPS 的区别。2. HTTPS 默认端口。3. 能改端口吗？4. 为什么安全？5. 对称加密和非对称加密分别在哪个阶段使用？6. 为什么不使用纯对称？7. 为什么不用纯非对称？8. 什么是证书？9. 浏览器如何判断证书可信？10. 哪些情况证书不可信？11. TLS 握手过程了解吗？操作系统1. 进程、线程、协程的区别。2. 线程和进程的通信方式。3. Python 如何创建进程？4. C++如何创建进程？Linux1. 如何查看进程内存占用？2. ps 怎么用？3. 如何查看 CPU 占用最高的进程？4. top 默认按什么排序？5. top 能看到哪些字段？

一、什么是全局 ID？一句话：全局唯一 ID = 整个系统里永远不会重复的 ID。不管多少台服务器、多少张表、多少服务，生成出来的 ID 都绝对不重复。比如：订单 ID优惠券 ID用户 ID流水号这些都必须全局唯一，不能重复。二、为什么需要全局 ID？（你写的那两个问题是核心）你学习笔记里写的两点，就是分布式系统必须用全局 ID 的真正原因：1. 数据库自增 ID 不安全、规律太明显如果订单 ID 是：101、102、103、104...别人一看就能猜到：今天卖了多少单总订单量多少商业机密直接暴露全局 ID 是乱序的，别人猜不到。2. 分库分表后，数据库自增 ID 会重复比如：订单表 1 自增...

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