大模型应用的第一版评测集怎么搭
2023 年很多 AI 项目都会经历一个阶段:最初几天大家都被 Demo 效果鼓舞,但很快就会遇到一个更现实的问题,模型今天看起来好,明天为什么又不稳定了?
2023 年很多 AI 项目都会经历一个阶段:最初几天大家都被 Demo 效果鼓舞,但很快就会遇到一个更现实的问题,模型今天看起来好,明天为什么又不稳定了?
Electron 桌面应用做 Demo 很快,但一旦真正给用户长期使用,最先暴露出来的问题往往不是界面,而是发布和更新。
很多项目第一次接 Redis,都把注意力放在“怎么查得更快”上。但真正在 2021 年做内容或后台服务时,我觉得更应该先想清楚的是 key 设计。因为缓存逻辑可以改,key 一旦遍布代码和运维脚本,后面想统一重构就很难了。
Vue3 在 2021 年开始真正进入团队视野时,很多项目都会顺手把 Script Setup 和 TypeScript 一起引进来。原因也很现实: 写法更短,类型提示更好,组件逻辑组织起来也更自然。
2021 年如果还在做前端,几乎不可能绕开 Vue3。真正让大家开始认真讨论它的,不只是性能,而是组合式 API 终于给复杂页面的逻辑组织带来了一种更顺手的写法。
Vue3 推出组合式 API 以后,团队很容易迅速进入“什么都抽成 composable”的阶段。它确实解决了 Options API 里逻辑分散的问题,但抽法不对,同样会让页面越来越难懂。
Docker Compose 真正进入团队日常以后,最容易变乱的不是容器本身,而是环境变量。数据库地址、Redis 密码、第三方 key、功能开关,只要项目一多,.env 很快就会变成谁都不敢动的文件。
做 BFF 的时候,最容易被忽视的一点是: 你聚合得越多,单个接口的失败面就越大。一个页面接口背后挂了三四个服务,任何一个超时都可能把整页拖慢。
Feathers.js 的一个优点是接口很轻,find 方法配上 params.query 就能做出非常灵活的列表查询。但灵活也意味着风险,如果没有白名单,列表接口最后会变成“只要能拼出来就都能查”。
Feathers.js 很适合做资源型接口,但只要后台系统开始出现列表页、筛选器和搜索框,params.query 很快就会从一小块对象膨胀成谁都不敢碰的入口。