前言
大家好，我是祯民。今天我们不聊技术，聊聊焦虑和内耗，最近和一些小册读者同学闲聊的时候，他们都经常会有类似的一个顾虑，这事我有资格做吗？就像这样：
- 我想面试大厂，但是我感觉我能力还不够，还是等一段时间多准备准备
- 我 mentor 让我独立负责一个项目，这个项目需要全栈，但我只会前端怎么办，要不要拒绝我 mentor
- 我开始带校招同学了，但我会不会带不好他，有时候感觉他技术比我还厉害
- ...
这些问题不仅有校招的同学会有，即使是工作几年的同学也有类似的问题，也包括我。这种焦虑和内耗很常见，它体现了你对自身能力与责任的认真态度，这是积极的一面。在面对新的挑战或任务时，我们可能会担心自己是否有足够的资历去胜任，这主要源于对未知的恐惧以及对成功的渴望。
这种焦虑和内耗会带给人不同的痛苦和徘徊，导致很多同学会对一件事情的过分焦虑内耗。因为害怕他人的指责，你是否够资格去做，而放弃一些机会选择舒适区。
这种场景同样也时常发生在我自己身上，所以我就自身的一些例子给大家讲讲我当时是怎么面对焦虑和内耗的，以及如何定义一个事情你是否有资格去做。虽然不一定正确，但也希望能帮助到大家，给予一定启发。
正文
别人相信你的事情，你就有资格做
当一件事情，有人愿意相信你能做成的事情，愿意托付给你去完成时，即使你的能力并不是能把这个事情做到最好的那个人，但你也有资格做。我们来听第一个故事。
三年前刚进字节的时候，我只会 vue ，一点 nodejs 皮毛（说皮毛可能都过分了）和还勉强能看的八股文和 leetcode 水平（当然这个对工作几乎没任何作用）。在字节看了2，3天的新人 landing 文档后，我老板找我聊：
- 祯民，我想让你支持一下抖音前端技术团队官网，做一下团队推广
- 好的没问题，就我一个人吗
- 嗯，技术选型到部署上线，有问题可以找文档看看
当时我的心情很复杂的，那时候工作也就刚一年，更多的是维护项目，没从零主 owner 过一个完整的项目。而且技术栈上没写过 react，也没做过服务器端渲染，服务端虽然会一点，但是上来就让我独自支持团队的官网，整体技术方案调研加部署上线，这是真不怕我做得稀烂，把团队颜面放地上摩擦啊 =。= （现在回过头看，后面我再也没接过这么简单开放自主的需求，老板可能是真的觉得没更简单的能给我了hahaha）
但老板相信我能做的来，而且是入职第一个完整需求，我不好意思说我感觉我不配。后面整个过程我调研了整个完整的方案，也对服务端渲染、SEO 和部署有了深入的了解，最后官网也提前上线，SEO 排名，压测也都顺利通过了，我也评上了部门的 spot bonus(取得超出预期的结果）。
当然过程肯定没我说的这么顺利，时间也比较久远了，中间的心路历程我记不太清了。但我记得那段时间我是整个团队来的最早，走的最晚的那一个，每天彻夜难眠，经常边走路边思考技术方案是否完整。经过这个事情，我技术栈建立了一个完整的知识体系，虽然深度可能还不够，但雏形已经形成了。这件事也为我后面支持字节官网、受邀写了 SSR 相关的小册埋下了伏笔。
有的时候我们虽然不是一件事的最佳人选，但只要有人愿意相信你能（可能）做成，愿意给你去做，和你合作，那这件事情你就有资格去做，这世上有几个人能保证自己是某个领域最强的人呢？即使这件事没有做成，对你来说，最差的结果无非是失去信任、被嘲笑，但只要真的尽力了，这个事情不论成败，过程给予你个人的成长都会是超出预期的。
自己感兴趣的事情，你就有资格做
如果一个事情你感兴趣，不看重结果，可以自驱去调研驱动，收益主要来源自身满足而非外界因素提供时，你就有资格去做。 道理其实很简单，你都不需要外界正向反馈的时候，这段人生经历的补全就已经是最好的回馈时，你凭什么不配去为自己做呢。我们来听第二个故事。
差不多 2 年前，有段时间我对测试很感兴趣，甚至说痴迷也不为过。我一直在思考，为什么测试驱动开发这种模式只是理想国，也在尝试在自己负责的业务平台覆盖完善的单元测试、端对端测试。
这个过程同样并不顺利，一来我不是测试方向的同学，这个不算我的本职工作，我还有很多业务需求需要支持，二来前端业务场景想要可持续地覆盖高质量用例是困难的，其中不乏有同学和我说，这个事不现实，不靠谱，做了也不会有收益的。（当然这话也不完全错，从现在的角度来看，说的是很正确中肯的）。
但我当时就是很感兴趣质量方向的事，也年轻瞧不起写低质量的开发，想凭一己之力拉升整体项目维度的质量，甚至想真正意义上降低功能测试在整体项目开发维度的权重，由研发来自驱全权保证代码质量和用例设计。
所以有近半年的时间，我早上6，7点就会起来，找各种测试的文章看，并且在业务支持中，自己挤时间去为组件覆盖用例，组内的组件库也被我硬卷到了 100% 的覆盖率。这个过程，我对功能测试，单元测试，端对端测试，压力测试都有了一定程度的了解，对用例的设计也越来越烂熟于心。测试、开发和人性之间产生的局限也开始慢慢理解，甚至可以说开始困扰我。
后面针对业务场景的单元测试覆盖终于有一天中断了，我没办法合理平衡开发紧张和用例设计的时间，同时针对前端场景，UI交互的介入使得整体的用例打破了基础的增量迭代性，频繁的用例 breaking change 不仅让我身心俱疲，也使我意识到，这种用例正在慢慢远离测试的初衷，而更趋向一种指标工作。
单元测试用例的本质就是为了非预期 breaking change 造成的多业务方崩溃问题，而业务前端代码一方面调用业务方几乎没有，另一方面需求本身就充斥着符合预期的 breaking change，那么单元测试在这种场景又有什么意义呢？
再到后来，我开始结合 AI 去生成单元测试，也拿到了一些成果，但也更多只是给基础库或者服务场景去推广。因为随着学习的深入，我逐渐明白，在充斥着符合预期 breaking change 的前端 UI 业务场景中，单元测试的强制覆盖本身就是一件脱离初衷的事情。
这件事我有资格去做吗？我不是测试，原本也不精通测试，也没人相信我能做成这事。但我觉得我是有资格去做的，因为有足够的兴趣驱动，我愿意去付出成本，而经历本身就已经是回馈中的一项，我不再需要额外的外界价值和正向反馈来奖励自己，那谁又有资格去评价我的成功与否呢？
不熟悉但有价值的事情，你也有资格做
如果一个事情你不熟悉，但你相信它长期会有价值，你也有资格做。 我们来听第三个故事。
今年我参加我们部门的 all hands 时，有一个同学给大老板提问，"这一年下来很多人尝试用 AI 去做一些事情，我不是算法，也不知道该如何参与进来，感觉到很焦虑怎么办"。其实当时我很想回复他，当你觉得这个事情有价值，你就应该着手做起来了，光焦虑内耗是一点软用都没有的。
在今年大语言模型 GPT 发行的时候，我就在想我能拿来做什么，正好那段时间我很困扰，怎么平衡优质用例需要大量时间成本和排期紧张的冲突，于是我就开始尝试使用模型去自动生成单元测试。
整个过程遇到了很多问题，像法务版本问题，模型质量不佳需要微调，prompt engineer 最佳实践，以及对开源模型的尝试。也就是业务支持的阶段，或者平时业余的时间，自己去抽时间去学习尝试。我不是算法，这方面就是一个初学的小白，有谁能是天生专精某个领域呢？没有谁有资格去嘲笑一个勇敢尝试新事物的人。
除了单测，还有 CR、eslint、oncall 很多方向我都有尝试，最近我还支持了一个很有意思的基建，duplication-lint，类似 ts-lint 可以对项目重复代码进行检测，也支持 AI 的高质量修复。
当你认定一个事情有价值的时候，即使你不熟悉你也有资格去做。与其在那里纠结你有没有资格去尝试，不如先做，毕竟每个奇迹都是从不可能开始的，相信奇迹的人本身就和奇迹一样了不起。
小结
很多同学看完，可能就会说："阿民，你这不是在给我画饼么，那几乎不就是啥事我都有资格做呗。"
事实上，当一件事情能够为你产生经历、为别人产生价值、帮你获得成长的时候，你都可以去做。尤其是当别人相信你，愿意给你机会的时候，即使你现在没有准备好，你也应该抓住这个机会。
他人对你的评价是在一生中最不重要的事，你永远不可能让每个人对你满意，夸赞你 。而有挑战，能让你获得成长的经历，以及事情本身所产生的价值才是会陪伴你一生的内容。既然被人喷是每个人一辈子中都会有的事情，那为什么不去放心大胆地争取，让自己一生不留遗憾呢？
我们可以焦虑，可以适当内耗，因为这些是促进我们推进未知困难事情必须的情绪，但不要因为这些情绪，担心害怕做不好被人嘲笑而放弃或者推延已经到手的机会。
主动争取机会可能对大部分人来说很难，但把握好到身边的机会是可以克服做到的。人一生中的可以改变命运的机遇很少，正视焦虑和内耗，关注事情本身，每个人都有可能胜天半子。