都不是重点，真正值得学的是她做架构决策的方法。论文和开源仓库可以读，但逐行啃模型代码性价比很低，大部分是工程胶水，抄回来也跑不出同样的效果，因为缺配套的数据管线和训练基建。可迁移的是她怎么算账：算力受限下做 MLA 这类结构性优化的思路、稠密和 MoE 之间的取舍逻辑、用极低训练成本逼近头部效果的方法。选型层面可以直接参考结论：团队没有万卡集群就别碰预训练，拿开源权重做微调和蒸馏是更现实的路。一句话，读论文学思路，看仓库学工程组织，选型照着自己团队的资源约束重新算一遍，别直接搬别人的账。

我的排法是把人留在决策点，把执行交给 Agent。早上先花十分钟过一遍 Agent 昨晚跑完的任务，验收产出、标记失败的，这步不能省，否则它会带着错误上下文继续跑偏。然后给当天定任务清单：能写成明确验收标准的（跑批、数据清洗、代码迁移、报告初稿）批量派给 Agent；需要人拍板的（方案取舍、需求澄清、评审）留给自己。长任务中间设检查点，每小时看一眼关键输出。别指望 Agent 全天无人值守，上下文漂移是常态，周期性拉回来对齐目标，比事后返工便宜得多。下班前把当天踩的坑写进它的记忆或规则文件，第二天同样的坑不再踩，这才是用 Agent 的复利。

边缘节点是厂商的基础设施，你没法直接修，能做的是让调度绕开它。先分清是节点问题还是自己的配置问题：用不同地区、不同运营商的探测点请求同一域名，如果只有个别地区抖动而控制台拨测正常，大概率是节点侧问题，直接提工单，带上时间点、节点 IP（响应头或 trace 接口能拿到）和抓包记录。等待处理期间主动止损：调低故障地区的 DNS 解析权重，或者用健康检查加故障转移把流量切到备用源。边缘函数场景可以多实例部署，加自适应剔除，某实例连续超时就摘掉。日常对边缘域名做多地区拨测监控，别等用户投诉才发现节点不对劲。

白屏本质是 JS 执行失败或关键资源没到位，先开 DevTools 看 Console 和 Network。常见原因：JS 报错中断渲染，尤其老浏览器不支持的语法；打包后资源路径不对，404 或被 CSP 拦截；异步接口挂了导致首屏数据一直空着。排查先看 Console 报错，再看 Network 里各资源状态码和响应大小，SPA 还要确认挂载节点存在、路由匹配上。线上建议加白屏监控：MutationObserver 检测首屏关键节点是否出现，配合 sourceMap 还原堆栈。优化上骨架屏兜住接口延迟，脚本加 defer 或放 body 底部，关键 CSS 内联，拆分长任务避免阻塞主线程。

最左前缀是硬约束，列序第一原则是等值条件的列放前面、范围条件的列放后面，范围之后的索引列就用不上了。选择性只是参考：若 status 几乎全是同一个值，放后面配合 user_id 过滤反而更省。另一个决定因素是排序分组，order by 的列靠索引顺序能避免 filesort，有时值得为它调整列序。覆盖索引也影响设计，把 select 的列挂进索引能省回表。边界值查询本质还是范围条件，思路是把范围收窄成等值，比如查当天拆成大于等于零点且小于次日零点，别对索引列做函数运算导致失效。分布倾斜用直方图或强制索引兜底，上线前 explain 确认。

按端分比较清楚。移动端：iOS 只有 App Store，国内安卓主流是华为、小米、OPPO、vivo 各自的应用商店加应用宝，上架要逐家适配审核规则，海外还有 Google Play。PC 端：Windows 上 Microsoft Store 存在感一般，多数软件还是官网直接分发；macOS 有 Mac App Store，但没签名公证的应用用户也装不了。小程序类：微信、支付宝、抖音小程序算独立的分发生态，流量大但受平台规则约束深。企业内部分发：iOS 用企业签名或 TestFlight，安卓和桌面端可用蒲公英、fir.im 这类内测分发平台。给个实用建议：C 端产品优先覆盖目标用户浓度最高的两三家商店就行，别追求全网覆盖，审核维护成本会吃掉你；B 端和内部工具走私有分发更省心。

几个真出过事的点，优先级排前面的：第一，密钥永远不进代码库，AccessKey、数据库密码用环境变量或密钥管理服务，git 历史里有过的密钥当泄露处理，立刻换。第二，最小权限，别图省事给子账号 AdministratorAccess，一个服务一个角色，按需授权。第三，依赖供应链，第三方包升级前看 changelog，lockfile 提交，定期跑依赖漏洞扫描， npm/pip 的镜像源只用可信的。第四，日志脱敏，手机号、身份证、token 打日志前先处理，日志平台权限也要收。第五，输入校验防注入，ORM 用参数化查询，别手拼 SQL。最后，养成备份习惯并验证能恢复——没演练过的备份等于没有备份。这些不花多少时间，但能挡掉九成的低级事故。

不一定，几个常见坑先排查。第一，确认配的是「强制 HTTP 回源」还是「跟随协议」，跟随协议模式下客户端用 HTTPS 访问就会以 HTTPS 回源，这是最常见的误会。第二，检查是否有「强制 HTTPS」或「强制跳转」类配置开了，这类配置优先级高于回源协议设置。第三，如果源站 80 端口有 301 跳转到 HTTPS，回源请求会被跟随跳转，最终实际走的就是 HTTPS，抓包或看边缘日志能看到跳转链。第四，注意配置生效有延迟，改完等几分钟再看实时日志。定位方法很简单：看回源日志里记录的回源协议和端口，对不上配置就是被上面某条规则覆盖了。遇到这种配置「不生效」的问题，先怀疑配置优先级，再怀疑源站行为，别急着重配。

看你处在哪个阶段。想低代码快速搭：国内有扣子 Coze、腾讯云智能体开发平台 ADP、阿里百炼，拖拽式编排加插件市场，适合验证想法。想自建可控：Dify 开源可私有化部署，编排、RAG、观测都有，团队用得最多；要更细的编排控制就 LangGraph 加 LangSmith，代码级控制但上手成本高。OpenAI 的 Agents SDK 生态也值得跟。选型建议别贪大：先明确你要的是「快速出 Demo」还是「长期维护的生产系统」。前者用托管平台一天能跑通；后者优先考虑可私有化、数据不出域的方案，因为 Agent 要碰企业内部数据和权限，托管平台的沙箱隔离往往不够。工具会一直换，先把评估和观测链路搭好才是正经事。

这个问题得拆开看。罗福莉参与的模型（DeepSeek 系列）核心思路是用 MoE 加 MLA 把单次推理的激活参数压得很低，真正吃资源的是训练阶段的通信密集度和推理时的 KV Cache 管理。云原生能不能扛，关键不在 K8s 本身，而在网络和调度层：参数面流量对 RDMA、无损网络的要求，普通云上的 VPC 网络很难满足，得用专门的 HCC/高性能计算实例组。推理侧反而友好，Prefill 和 Decode 分离部署后，用 K8s 加上 GPU 池化、弹性伸缩跑中小规模完全没问题。我的判断是：训练尽量别硬塞进通用云原生体系，推理可以放心上。真要大规模训练，要么裸金属集群，要么云厂商的高性能网络方案，别为了「统一纳管」把架构复杂度拉爆。

手撕的不是文档，是里面的模糊。GPT 写 PRD 特别擅长生成看起来完整的结构，背景、目标、流程图、验收标准一样不缺，但关键处全是「支持灵活配置」「体验流畅」这种没法写代码的话。省下的是排版时间，没省掉的是把边界问清楚的成本。实际做法是让它同时产出三样东西：状态机、异常分支清单、字段定义，开发拿着这三样去对，对不上的地方就是没想清楚的地方。PRD 的活从写字变成审字，人更累点，但返工少很多。

买不到。SLA 赔的是钱和额度，赔不了你半夜的判断。大模型服务出问题时最难受的往往不是宕机，而是变笨：延迟正常、返回 200、内容质量掉一档，SLA 指标全绿，锅还在你这边。合同里真正要谈的是可观测，能不能给请求级指标、变更提前多久公告、版本能不能钉住不自动升级、有没有影子环境做对比。真要兜底还得自己建结果质量抽检，固定题集天天跑，曲线掉了就是信号。判断力只能自己攒，厂商给不了。

榜单是别人家的题，不是你家的流量。切换模型只看三件事：自己评测集上的跑分、单位任务的成本和延迟、失败模式的差异。稳妥的做法先上影子流量，把线上真实请求复制一份打给新模型，只记录不返回，攒一两周做人工抽检对比；再按 5% 灰度，盯成功率和投诉率。翻车的往往不是能力不够，而是输出格式变了、拒答边界变了、提示词里那几句老咒语失效了。全量切之前留好一个配置项能秒回滚，比什么都强。