目前环境下,我该不该辞职

主包是25届软工毕业生,毕业进了某供电局,本以为是进信息中心之类的,做办公室写写代码,结果培训结束没有定信息中心,现在几乎天天在变电站值班倒班➕白班。

本来主包也想着,算了,计算机那么卷,转行也好,没想到局里要搞数字化,所在班组只有主包一个人是相关专业,于是变成了既要从零学习电力知识,还要当产品经理开发测试一条龙😖,班组老资历以电力人严格标准要求主包,年轻领导又以数字化先锋要求主包,主包已经很久没摸过代码(大学期间也不卷,还有些摆),实在是心累,关键领导又不懂,内网开发本来就有很多限制,抄都难抄,上面又希望做的比专业团队还专业,一个人短时间搞出多项成果,还要获奖(属实是外行指导内行),关键一点帮助都没有,全程主包一个人去破风😰,主包在非珠落后地区,收入也不高,还一个人干两个专业的活,层层压力下,主包在考虑辞职。

想问问各位佬,现在外面行情如何,去外企干技术支持或测试有搞头吗😳
全部评论
你投一投boss就知道行情如何了😂
3 回复 分享
发布于 昨天 06:28 北京
不加班就行了,加班另说
1 回复 分享
发布于 昨天 10:38 广东
不开除你,摆烂就行了
1 回复 分享
发布于 昨天 09:37 上海
建议苟住
1 回复 分享
发布于 05-26 16:47 湖北
同学拼多多【暑假实习/春招】机会考虑吗?链接见主页,团队氛围好,工作内容挑战性强,转正薪资待遇极具竞争力。可一对一帮查进度,解答过程问题。26春招:https://careers.pddglobalhr.com/campus/grad?t=GVpddkkjmz 27实习:https://careers.pddglobalhr.com/campus/intern?t=HypMxi4pJe
点赞 回复 分享
发布于 今天 13:31 上海
内网确实难受
点赞 回复 分享
发布于 今天 09:48 福建
外面那是一年比一年难
点赞 回复 分享
发布于 昨天 22:45 辽宁
随便搞搞吧 内网接🪜!
点赞 回复 分享
发布于 昨天 12:38 北京
666
点赞 回复 分享
发布于 昨天 12:37 北京

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个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专家吧!
AI了,我在打一种很新的...
点赞 评论 收藏
分享
26年2月,我匆匆从LX离职,着急忙慌地入职了某大厂旗下的游戏子公司。加上各类补贴,年薪接近19万。当时觉得总算攀上了一棵大树,心里还暗自庆幸——谁想到,这才是噩梦的开始。入职第一天,我就察觉到了不对劲。我的直属领导是一位年近四十、至今未婚的女性。别的组的大厂员工私下评价她“很努力”——但在这个行业里,“努力”二字有时并不是褒义。我们组的外包人数是全部门最多的,需求排期像一团乱麻,她对需求也是一笔糊涂账,经常前后矛盾、对不清楚。更离谱的是,同一个需求她会分配好几台设备,配置完全一样,而测试本身就需要漫长的游戏时间,跑完一轮还得写测试报告。于是,加班变成了毫无意义的消耗战——不是因为项目紧急,而是因为流程冗余、管理混乱。第一天走进工位,我看到组里那位外包兄弟嘴唇发白,脸上没有一丝血色。我当时还以为他生病了,心里嘀咕了一句“要不要问问他怎么了”。后来在组里呆了大约两个月,我才真正体会到他的痛苦——那种被反复折腾、又无处可说的绝望。有一件事让我彻底寒了心。那天,女领导让我跟着组里一个干了多年的外包一起做一个需求。她原话是:“你跟他一块儿干,他熟悉流程。”我照做了。结果那个外包自己把需求理解错了,从头到尾都没弄清楚到底要测什么。我还没来得及找他确认,吃饭途中就被女领导一个电话叫上去,劈头盖脸训了一顿。更让我憋屈的是,那个外包随后跑到领导面前,反过来告诉我:“以后有什么需求,你要直接问领导,别光跟着我。”——我当时就愣住了:明明是你让我跟着他干,现在出错了,倒成了我的责任?后来,我从上一个子公司离职的小伙伴那里听说,他也曾被这个女领导叫进会议室,当面说了一句让人至今难忘的话:“你连我们组的外包都不如。”听到这话,我反而释然了——原来不是我一个人被这样对待,这就是她的管理方式。两个月,足够看清一个地方。我开始后悔当初的“着急忙慌”,也终于明白,有些坑,不是大厂的名字能填平的。目前,正在积极投递简历,整个测试环境没那么糟糕。但是,只能说都是命,万般不由人。
点赞 评论 收藏
分享
评论
2
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务