1. C++ 里的多态是什么？编译期多态和运行时多态有什么区别？多态可以理解为“同一个接口，不同实现”。 编译期多态在编译阶段确定调用目标，常见形式是函数重载、模板；运行时多态在程序运行时根据对象真实类型决定调用目标，依赖虚函数机制。 #include <iostream> using namespace std; struct Base { virtual void foo() { cout << "Base\n"; } }; struct Derived : Base { void foo() override { cout << &...

米哈游程序员大年初八猝死出租屋

AI给嵌入式带来的改变：从挑战到新机遇传统嵌入式开发遇到的难题：算力和资源不匹配：AI 技术不断进步，像 CNN、RNN 这些 AI 模型，对计算资源的要求越来越高。但嵌入式设备因为使用场景的关系，一般都得做到低功耗、小内存 。比如说，一个普通的 CNN 模型运行起来，可能需要好几 GB 的内存和很厉害的计算核心支持，可大多数嵌入式设备的内存也就几十 MB 甚至更少，计算能力也不强。这么大的差距，让传统嵌入式开发在运行 AI 模型时困难重重。开发思路大转变：以前的嵌入式开发，主要是按照确定的规则来编程，用 if - else 这样的条件语句实现各种功能。但 AI 开发不一样，它靠数据驱动，得收...

前些天看了 Clawdbot 创始人的采访——这哥们单日提交 1.3k commits，一个月 6600+ 次提交，有的代码自己一句都没看过，非常恐怖。所以在不久的将来，当 AI 已经完全具备写代码的能力，人类程序员的操作空间还能剩多少？最近在实习，做大模型微调，新鲜期过了，发现不过是机械劳动，造数据 → 训模型 → 看 badcase → 然后再造数据，循环往复...这不就是Agent的ReAct范式么? (坏了，我成智能体了) 需求明确的情况下，Claude-3.5/3.6 也完全可以独立完成造数据 pipeline 的开发，偶尔会留下一些语法错误，在两三轮尝试之内也能自己修正过来......这里非要人来完成的环节并不多，只能用人来完成的理由，好像只剩人比较便宜了...？ 但 AI infra、推理加速也在飞速发展，这种相对的便宜，又能持续多久呢？Clawdbot已经火到到处都在讨论，尽管目前在国内的适配有限，(门槛高是一方面，还很重要的一点是比较烧钱...)不过它对人类劳动力的节省是没办法忽视的。目前同事们普遍认为这玩意儿现在只能接入飞书写写文档，但你也知道，“目前”而已。GPT-4 推出的那年或许看上去还有点呆，但短短几年，拥有 skills 和 function call 的大模型已经可以帮你完成打开应用、查看消息、撰写文档这种复合任务——写代码又能比写飞书文档复杂多少呢？不过是接入不同的软件，阅读不同的文本，调用不同的修改命令，底层是一样的，现在 Copilot 已经做得有模有样，更别说 Clawdbot 这种具有自我进化能力的 Agent，只要 token 多，Clawdbot 完全可以给自己装一堆功能，能量超乎你想象。有人说了，我做的项目大着呢，全是屎山代码，我不信 AI 能看完，这说的其实是长上下文问题，我个人不认为是一个无法解决的问题，随着上下文窗口的扩展和长期记忆管理的研究工作不断发展，AI 总能找到方法把你的超长文本压缩成一个一个的小块，然后逐个击破（虽然目前 GPT-5.2 Codex 改我的代码还是会改着改着一片红...）有句话说得好，你怕被 AI 替代，是因为你太像 AI。你的工作流程高度标准化、可预测、可复现——接需求、看文档、查 API、写代码、测试、提交。每一步都有明确的输入输出，每一步都能被拆解成清晰的指令。这种工作方式，恰好是 AI 最擅长的。如果你的价值体现在“把业务逻辑翻译成代码”，那 AI 确实可以做得更快、更稳定、更便宜。它不会写错大小写，不会忘记边界条件，不会因为昨晚没睡好就漏掉一个判断。要想不被替代，就得做那些 AI 做不了的事，比如和产品经理撕逼，解释为什么这个需求做不了；看着三个技术方案，权衡性能、成本、开发周期，最后拍板选一个；跨部门开会，听运营讲了半天业务痛点，翻译成技术语言，还得判断她说的是真需求还是伪需求。这些事情需要判断、需要博弈、需要对人的理解， AI 暂时还做不来。但问题是，这些事情需要多少人来干？以前一个项目可能需要十个程序员，现在有了 AI，也许三个人就够了,剩下那七个人上哪去？......也许他们会转型，在行业找到新位置，也许是去卖炒粉了，说不好。但有一点感觉很明显：AI 在拉高门槛。以前你会写代码就能找到工作，现在得会“用 AI 写代码 + 理解业务 + 做技术决策”。这个组合技能，不是每个人都能凑齐的。工具会进化，但人怎么不被工具定义，可能是我们未来一段时间需要长期思考的问题。