1. 自我介绍
2. 讲pseo
3. pseo的运行指标、后续的收益指标
4. 埋点数据太多，内存爆了怎么办，怎么做的监控
5. ssr、isr、ssg的使用场景
6. 流式输出怎么做的？如果解析到一半出现符号不全、渲染异常该怎么办
7. ai目前做的不太好的地方有哪些
8. 讲我的论文
9. 接受深圳base吗
10. 反问：做什么业务、后续的流程

埋点数据太多，内存爆了怎么办，怎么做的监控

可以用indexDB替代localStorage做存储

ssr、isr、ssg的使用场景

https://visionaryblog.cn/reader/260

流式输出怎么做的？如果解析到一半出现符号不全、渲染异常该怎么办

处理方式，按推荐顺序：

1. 块级缓冲（最稳） 用 remark-parse 把累积内容解析成 block 列表；只提交「完整块」（空行结尾的段落、已闭合的 fence、列表项边界）走完整渲染。最后一个不完整块单独处理，不要和已提交块混在一起重渲染。

• 已完成块做 memo，只重算尾部
• 可直接参考 Vercel 的 streamdown / remend，就是专门解决这个问题的

1. 补全尾部再 parse 解析前对尾部做轻量修补：

• 奇数个 ``` → 临时补一个闭合 fence
• 未闭合 **/_/ ` /[/(/$ → 补闭合或先转义成纯文本
• 表格 header 无分隔行 → 暂不按表格渲染
• 未闭合 HTML 标签 → 先当文本，或直接禁用 raw HTML（rehype-raw 对残缺标签最脆弱） 补全后必须保证“补丁”不进最终内容，只用于渲染。

1. 降级显示未完成尾部 尾部不渲染富文本，只显示纯文本 + 光标（光标用 CSS 伪元素，不要插进 markdown 字符串），闭合后再切换成正式渲染。这样永远不会出现结构错乱。
2. 节流 + append-only SSE delta 不要每个 token 触发全量 parse；按 requestAnimationFrame 或 16–50ms 合并一次。字符串只追加，已渲染块缓存，避免整棵树重排。
3. 兜底 parse 包 try/catch，失败时回退纯文本；对用户输出做 DOMPurify 清洗。

目前ai做的不太好的地方

1. 需求理解停在字面：不主动澄清歧义和隐含约束，容易漏掉性能、兼容性、边界条件、非功能需求。
2. 跨文件/跨会话一致性差：改 A 坏 B，重复造轮子，前后命名和风格不统一，长任务中忘记早期决策。
3. 验证不足却过度自信：写完就宣布完成，不跑测试/类型检查/实际启动；测试只覆盖 happy path，甚至用 mock 自证。
4. 幻觉 API：凭记忆编造库的函数签名、配置项、版本行为，尤其冷门库和最新版本。
5. 调试靠猜：缺少系统性复现、二分、加日志，容易修症状不修根因。
6. 架构权衡弱：倾向局部打补丁，或反过来过度抽象；不会主动说明方案取舍和风险。
7. 大 diff 文化：一次改太多、混入无关格式化，难以 review 和回滚，不擅长小步提交。
8. 安全意识不足：注入、权限、密钥、并发、错误处理和输入校验容易遗漏。
9. 不熟悉项目真实工具链：靠 package.json 猜命令，忽略 CI、部署脚本、代码规范和已有约定。
10. 协作节奏：该问的时候不问，该停的时候不停；输出要么太啰嗦，要么关键假设不交代。