小红书一面【产品工程师（AI 全栈方向）-国内电商】
七崽爱吃小饼干2026/10/08阅读 0
- pseo项目介绍
- 怎么确定审核agent的审核结果是对的
- D2C的过程
- 为什么不选择ai+低代码，而是要脱离低代码
- rag的原理、什么场景适用rag
- skill和mcp的区别、适用场景
- ssr、csr的区别、适用场景
- top-k算法
怎么确定审核agent的审核结果是对的
核心结论先说：审核 agent 的"对"，无法用审核本身来保证，只能靠外部可验证信号 + 与 A 的独立性 + 可量化的校准。 无限递归的"谁来审审核者"没有内部解，必须接一个不依赖 LLM 判断的锚点。 具体手段，按可靠性从高到低：
- 能用确定性检查的，就别交给 B。 测试、类型检查、lint、schema 校验、实际执行、diff 是否符合预期——这些是 ground truth。B 只负责机器判不了的部分（需求是否被满足、意图是否走偏、是否漏了边界）。把 B 的输出尽量转成"可执行断言"，让机器复核 B 引用的证据。
- 强制 B 给证据，而不是给结论。 要求 B 输出结构化 verdict：{通过/不通过, 依据: [file:line, 命令 + 实际输出, 复现步骤]}。禁止"看起来没问题"。然后你（或脚本）去抽查这些证据是否真实存在——B 编造证据是最高频的失败模式。
- 保证 A、B 独立。 B 只看 A 的产物，不看 A 的推理过程和自我评价（否则会被 A 的话术带偏）。用不同的 prompt、最好不同的模型/温度。同一模型的 A、B 会有相关性错误——A 系统性犯的错，B 大概率也看不出来。
- 对抗性设置 + 明确 rubric。 B 的目标不是"确认没问题"，而是"找出问题"，并要求给出反例。给 B 一份检查清单/评分标准，把"能跑通"和"安全/正确"拆成独立维度，避免一个结论掩盖另一个。
- 分歧走仲裁，别硬碰。 A、B 结论冲突时，引入 C 只针对争点裁决，或直接升级给人。也可以用多次采样投票，但注意相关错误——投票只能压随机噪声，压不住系统性偏差。
- 建标注集做校准（这才是真答案）。 收集一批已知"正确/错误"的产物，跑 B，测它的 precision / recall / 漏报率。你不可能证明 B 永远对，但你能测出它在什么情况下不可靠、漏报多高，然后针对性补规则或加确定性检查。定期回归。
- 用最终结果当反馈信号。 测试是否全绿、构建是否通过、线上是否回滚、用户是否接受——把这些当成 B 的"考试成绩"，持续修正 B 的 prompt 和 rubric。 一句话选型：A 干活 → 先跑确定性检查 → B 只审机器判不了的 → B 必须给可复核的证据 → 用标注集持续测 B 的漏报率。 指望 B 自己保证自己没错，是没有终点的递归。
rag
https://visionaryblog.cn/reader/536
ssr、csr的区别、适用场景
https://visionaryblog.cn/reader/260
适用场景补充：
核心区别：CSR 是浏览器用 JS 渲染页面，SSR 是服务器每次请求就把 HTML 拼好返回。
SSR 适合的场景（首屏要快、要 SEO、内容随请求变化）
| 场景 | 原因 |
|---|---|
| 电商商品页、详情页 | SEO 拉自然流量，首屏快影响转化 |
| 新闻/博客/内容站 | 需要被搜索引擎抓取收录 |
| 需要社交分享卡片（OG 标签） | HTML 里要有动态 meta |
| 登录用户个性化首页 | 内容随 cookie/用户实时不同 |
| 对首屏时间敏感的落地页 | 减少白屏和 JS 依赖 |
CSR 适合的场景（强交互、无需 SEO、登录后应用）
| 场景 | 原因 |
|---|---|
| 后台管理、控制台、仪表盘 | 登录后使用，不需要收录 |
| 重交互 SPA（在线编辑器、协同工具） | 页面交互多，首屏不是重点 |
| 内容变化极快、纯客户端状态 | 反正要等接口数据 |
| 内网/桌面套壳应用 | 没有 SEO 诉求 |
别漏了两个更合适的选项：
- 纯静态展示页（营销页、文档）→ 用 SSG，构建时生成，比 SSR 还快还省服务器。
- 内容定期更新但要快（博客、榜单）→ 用 ISR，静态 + 后台再生，兼顾速度和新鲜度。
一句话选型：
text
要 SEO / 首屏 / 动态 meta → SSR（或 SSG/ISR）
登录后的强交互应用 → CSR
内容固定 → SSG
补充：两者对首屏的影响还受水合（hydration）成本影响，SSR 首屏有 HTML 但交互仍要等 JS 接管；这也是 React Server Components、流式 SSR 想解决的问题。