ReaderMX.
云
公众号

云加社区

腾讯云官方社区公众号,汇聚技术开发者群体,分享技术干货,打造技术影响力交流社区.

962 篇已收录文章

这个来源的文章

按发布时间排序
云加社区

回答我！Looking my eyes！\n\n\n \n\n\n探索AI、布局AI、All in AI了一年，作为普通开发者却陷入了前所未有的焦虑。\n \n曾经看文章就能动手复现的踏实感消失了，取而代之的是对AI的三大核心困惑。\n \n疑问一：为什么AI实践类文章总像空中楼阁？\n \n疑问二：AI入门知识与实际工作的断层从何而来？\n \n疑问三：我们对AI的期待是否用力过猛？\n \n作为一个从传统开发转型AI的人，我怎么找到：\n \n1. 可落地的认知指引\n2. 真实的实践参考\n3. 业务结合的切入点\n \n这是在鹅厂引发广泛讨论的AI入门迷思三连问，对于这个问题，鹅厂工程师是这么看的。\n \n疑问一：\n \n核心原因只有一个：数据不公开。LLM的真正壁垒是数据和算力，而数据属于公司资产，涉及隐私、合规、商业敏感。像OneRec端到端方案、DeepSeek基模，都只讲思路，不给数据。没有数据，你看到的大部分内容自然更像PR，而不是教程。\n \n但PR也有价值。它至少告诉你行业怎么定义质量、怎么拆问题。能不能从里面挖出金子，取决于你的经验和实验能力。LLM做应用，本质就是从有限信息里提炼可复用的技巧。\n \n疑问二：\n \n简单粗暴的判断：如果不知道需不需要学模型结构，那就说明不需要。\n \n先用最好的 API，把场景跑通再说。做AI应用的核心只有三点：\n \n 1 prompt调优\n 2 上下文管理\n 3 规则化评估\n \n加业务数据就再多一个数据读取工具。\n \n那些让你先学transformer 的，十有八九没做过真正规模化应用。最好的入门方式永远是做一个小闭环，比如自动周报。遇到问题再补知识。\n \n疑问三：\n \n是的。真正落地的团队，都非常依赖人工标注。测试集必须人工标，效果也必须人工判。通用评测工具有局限性，容易出现和人类预期相悖的情况。\n \n因此，小团队应该选一个窄、具体、能闭环的场景，降低验证成本。行业里成熟玩法都是用最强模型，把一个垂类打深，能解决问题、能变现。\n \n技术上，别一上来就搞LangChain。先用OpenAI SDK，把模型当苦力使唤，Python脚本一步步跑通流程。\n \n最后提醒：没有落地经验时，1v1咨询帮助都有限；有了落地经验后，很多关键做法一句话就能确认。\n \n彦祖亦菲们，你对这个AI入门迷思三连问是怎么看的？欢迎留言评论分享，有机会获得社区精美周边一份。

阅读全文
云加社区

程序员问大师\n\n\n \n\n\n后台开发，技术真的重要吗？\n\n新晋大厂校招生向大师请教：\n \n面试全是分布式、高并发、多线程，上班却成了对需求、写文档、梳理业务、修告警。排查线上故障靠的是看监控、查配置、扩机器；mentor能接手十年屎山，也是靠熟悉拓扑、可观测性、稳定性、排期、拒绝不合理需求，而不是多线程编程的炫技。\n \n后台工作是不是根本体现不了技术？为什么面试又问那么多？工作中如何提升技术？一个优秀后台工程师到底该长什么样？\n \n大师答：\n \n十五年前的自己，也是在各家大厂对接做业务，一样觉得工作没技术，一样焦虑，靠跳槽寻找更技术的岗位，结果发现到哪都在做类似的事。\n \n三年跳槽三次后，突然意识到：自己在别人眼里恐怕成了好高骛远、浮躁、不够踏实的年轻人，惊出了一身冷汗。\n \n大师从此悟道：上进心没用，上进的手脚才有用。\n \n想做核心技术，先得让别人相信你有成为核心的潜力。人生是长跑，先把事做好，机会自然会来。\n \n后台技术当然重要，但你现在做的只是系统的表层工作。\n \n真正的技术价值是在稳定性、成本、性能、架构演进这些大场景里体现的，而那些位置不会一上来就给新人。\n \n当你走到核心项目核心环节，自然就不会怀疑技术的重要性。\n \n那工作中怎么提升技术？\n \n1. 实战永远第一。\n \n主动争取有技术含量的项目，在大项目里成长最快。\n \n2. 小需求也能练技术。\n \n即使业务需求，也可以思考稳定性、性能、成本的极限，把能不能更好当成习惯。\n \n3. 深挖每个不懂的点。\n \n查资料、写总结、写代码验证、做压测量化。\n \n不是懂了原理，而是我知道这个优化能快多少、稳多少。\n \n4. 多交流。\n \n向同龄人学方法，向前辈学路径。\n \n什么样算优秀的后台工程师？\n \n大师说：形态不止一种。\n \n有的专家只盯项目最硬核的一小块；\n \n有的负责架构、稳定性、成本、性能，用专业能力带着团队解决大问题。\n \n先确定你想成为什么类型，再反过来补你缺的那部分能力。\n \n技术也好，沟通表达也好，向上管理也好，都是为把关键的事做好服务的。\n \n技术信仰可以有也很必要，但职场最重要的是：把事办成。\n \n那么，你悟道了吗？

阅读全文
云加社区

浅谈降本增笑背后的高可用困局\n\n\n \n\n\n2025年对技术团队不算平静。降本增笑、P0故障频繁登上热搜。表面原因看似多样，但这些因素往年也存在，并不会只在今年集中爆发。真正的问题，是高可用建设背后的结构性挑战。\n \n系统质量难以稳定，首先来自熵增。赶工、堆需求、技术债累积、新技术不断加入，都在让系统变得更复杂。理论上通过规范和流程能改善，但现实中业务压力通常远大于质量压力，技术团队很难真正阻断系统滑向混乱。\n \n第二是墨菲定律。只要系统在运行，意外就是必然：机房会坏，链路会断，软件和系统都有 bug。就算做了多活，真正需要切换时也可能失败。高可用是一场永远无法完全取胜的竞赛，只能尽可能延缓系统走向失控。\n \n更麻烦的是，那些把隐患提前消灭的工作，往往看不见、量化不了；但系统一旦撑不住，重构、多活、混合云这些工程就会立刻成为重点。你一年修一堆细碎问题，年底材料并不好看；隔壁团队虽然出过P0，却因大刀阔斧做架构升级，轻松拿到亮眼结果。\n \n高可用做得越早、越细，越难被证明，这也是行业里最吊诡的部分。公司层面也面临同样矛盾：平时的投入看起来琐碎；真正出事故，又觉得当初投入不够。于是形成普遍循环：系统退化 → 重大事故 → 大规模治理 → 阶段稳定 → 再次退化。\n \n高可用像一场反复上演的运动式工程，谁撞上谁倒霉。有没有破局？从工程角度看，没有快速有效的解，很多团队能做的只是避免成为那个倒霉蛋。但如果希望系统长期更稳，关键不在技术，而在组织文化。\n \n至少有三件事值得坚持：\n \n第一，把高可用视为持续工程。\n \n系统健康像身体健康，需要常态维护，而不是一次性升级。给团队留出质量时间，比突击式治理更可靠。\n \n第二，接受高可用是慢变量。\n \n隐患处理不会立刻带来收益，但能减少灾难级事故，也能让系统不至于一路滑向深渊。\n \n第三，坚持体检。\n \n 一年小复盘，两年大盘点，即便无法避免事故，也能把12小时的损失降成2小时，这对业务影响是本质差异。\n \n高可用的难点不在技术，在于组织能否给系统留出生长和修复的空间。\n \n下次老板再问你高可用，就把这篇文章甩给他吧！

阅读全文
云加社区

晋升了！\n \n \n \n\n做晋升时，很多人把注意力放在规则和评委身上，希望找到一个绝对公平的答案。但从个体角度看，这几乎不可能。规则会变、评委的理解会变，你作为被观察者本身也难以完全量化。制度无法绝对公平，对个人来说，与其纠结规则，不如尽量让自己远离模糊区间。\n \n晋升结果可以理解为约等于。\n \n同样是8.4分，根据不同处理方式，可能得8，也可能得9。系统可接受，但对个人差别巨大。目标不能刚好够，要把自己的表现尽量推向9分以上，让结果尽可能稳。要做到这一点，材料必须有结构、有逻辑、有重点。\n \n第一步是搭框架。\n \n很多人在项目堆里来回挪动，越改越乱。不是素材的问题，而是没有看懂它们之间的关系。先确定你想证明的能力是什么，再选择能支撑这些能力的两三条主线，让材料从堆叠变成结构。\n \n第二步是补足关键细节。\n \n每个项目为什么做、难点在哪里、你解决了什么、效果如何，这些都是让材料站得住的硬信息。细节不求多，但要能体现判断力、方法、影响范围。没有逻辑链的内容只会分散注意力。\n \n第三步是保证论证清晰。\n \n晋升本质上是证明题。每一页内容都要回答一句话：它在证明什么。如果既可要也可不要，那往往说明你还没完全想明白。逻辑越稳，评委理解你就越容易。\n \n现在很多团队都在做轻量化评审，材料短、节奏快。\n \n这并不降低要求，而是更考验你能否把核心价值讲得迅速、干净、准确。制度无法由个人决定，但个人可以让自己变成更好被观察的对象：更明确的成果、更清晰的结构、更稳定的叙述方式。\n \n最后，可以用一个简单的答辩材料框架来校验自己：\n \n业务背景：让评委快速看懂你在做什么\n业务挑战：说明必要性，让评委理解重要性\n技术挑战：把业务难点转成技术难点，突出门槛\n分析问题：展示拆解能力与思考深度\n解决问题：逐点对应你的策略与决策\n解决效果：用趋势或对比数据展示真实价值\n回归业务：最后落到业务影响与结果\n自我总结：提炼方法论，让评委看到成长性\n \n把这七点讲清楚，比任何技巧都更可靠。晋升不是玄学，要让系统在有限的观测里尽可能准确地读取你。

阅读全文