12战字节终归一场梦，字节跳动你没有心！！！

先说说本人情况，实习快两个月了，目前实习节奏和强度始可，现在是在做新需求，我参与的也比较多，从前辈身上也能学非常多东东西，mt和组员都非常好非常包容，昨天下班后还一起聚餐了，目前整体的团队氛围我很喜欢。前两周mt还主动和我1对1谈话，觉得我最近做的不错，这两周结束后看表现会去跟N+2求转正资格，爽之爽之。但是现在实习话感觉人班味越来越重了,下班后就想赖床上不想学新东西，面经也很少看，现在有接到面试全推到端午后了，平常根本就没精力去备面试，在这边实习后心态也有很大的变化，对学校里的课程的重视程度也在不断降低，越到后面越在思考学校的意义是不是就在于有个学位证，有点话密了。现在也挺迷茫的吧，想听听牛...

最近嘉豪一词特别火，我之前也在我的朋友圈狠狠玩了一把往里豪的梗，确实很搞笑啊哈哈哈，我雷铜泥丸。那么我认为的嘉豪呢，并不是炫耀，因为我觉得在经历很久的努力之后获得成功是值得为自己骄傲的事情，在之前的文章里面我已经评价过那些喜欢膜膜膜，佬佬佬的人，那么今天我来补充一个角度，那些喜欢在实习中说自己活特别多，特别难的同学。这样说感觉有点地图炮，好像开炮了所有实习同学，难道我活干的多也不行吗？其实不是这样的，活干的多其实是你能承担的多，能力强。但是其中有一些同学，自己一被分到活，无论大小，立马分享到某某交流群里，表面显得痛苦不堪，好像已经连续加班一星期，“哎呀，又来了个大活”，转过头就开始大吹大擂，说自己负责了多么核心的模块，又承担了多么大的责任，好像整个实习的团队都在围绕着他转，他的活总是紧急，总是P0，总是领导最看重的，不知道哪个ld这么闲，天天盯着实习生看。每次看到我总是很想笑，交流群里鱼龙混杂，一个群里几百个人你顶破天认识一半，谁又是你真正的朋友，你分享你做的的工作多么核心，多么累，谁又能真正体验或者理解你的感受？更有甚者，喜欢同时复制消息发好几个群？这又是为什么呢？你的朋友们散落在这些交流群的天涯海角里来哈哈哈。其实核心思想也就是想向别人展示，你看我多核心啊？多受领导重视啊？马上就要转正了，你羡慕不？拉磨的驴为什么要炫耀自己活多啊，我想大部分真正很忙的同学是真的没时间炫耀这个的，正值暑期，要竞争转正名额，这样的“抱怨”我想会变得越来越多了哈哈哈我发现学计算机的同学都不习惯直接夸赞自己，大部分都是先自低，再由别人来称赞自己。我说的这些人也是这种情况，总是拐弯抹角的炫耀，不如直接大大方方的夸赞自己，也许会有更多的称赞呢。

一、AI 测试的分水岭 从“使用”到“治理”现在市面上的 AI 测试落地尝试，基本分两个流派。一派是把 Claude Code 当外包小弟，人写提示词，它出脚本，人再复制粘贴到框架里。看起来快，实则返工率高得惊人。因为每一轮对话都是独立的，没有版本约束，没有上下文锁定，出问题只能从聊天记录里翻证据。 另一派，已经开始用交付流水线的思维治理 AI。不再把 Claude Code 当成一个聊天窗口，而是当成流水线里一个“生成步骤”。这个步骤有固定的输入源、参数化模板、审批节点、质量阈值，跑完自动进入下一环节。后一种做法的核心已经不是“用 AI”，而是把 AI 输出变成可治理的资产。这就是 Harn...

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