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

求分析简历，在boss上面投了很多，都没有回复😥感谢感谢感谢大佬😸

究极折磨，缓了三天才想起在牛客发布。

这场更像典型的嵌入式实习筛选节奏。时间不算长，但问法很实，不太给你空转概念的空间。项目要能往下挖，Linux 基础要能接得住，真碰到问题时你怎么定位，面试官也会顺手看一眼。一开始不会显得特别凶，可一旦你简历里写了 Linux、驱动、并发、调试、RTOS 这些词，问题就会很快落到细节上。印象比较深的是下面这 10 个。面试题目从用户态发起一次系统调用，到内核处理完再返回，这条路径里发生了什么匿名页和文件页在内存回收时为什么不会走完全一样的策略fork 之后父子进程看到的地址空间为什么看起来一样，但又不是真的完全一样select、poll、epoll 放到高并发场景里，真正拉开差距的点到底在哪负载...