PostHog 多智能体 QA 审查团队八大评审 Persona 定义与代码审查清单全解【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog在 PostHog 开源仓库的.agents/skills/qa-team技能中实现了一套**多智能体并行代码审查Multi-Agent Code Review**体系多个专业审查代理被同时派往同一份 diff各自从一个独立的失败领域视角审查变更最后汇总为一份带收敛分析的统一报告。本文以该技能的核心参考文档 personas.md 为骨架完整展开 8 个专家 Persona 的定义、上下文与审查清单并对照仓库中的 SKILL.md、incident-patterns.md 与配套脚本说明这些 Persona 如何在真实审查流程中落地。读完本文你将理解如何为一个多视角、可收敛、有优先级的代码审查团队定义角色并可直接复用这套 Persona 清单去审查自己的变更。一、为什么需要 Persona多智能体审查的出发点PostHog 的 QA Team 技能把代码审查拆分为一组专职代理security、database、reliability、compatibility、data-integrity、performance、frontend、copy 共 8 个专家外加两个不设清单的通才代理generalist-a 新鲜视角高级工程师、generalist-b 对抗性测试者用于收敛校验。每个专家代理都只会收到自己的Persona 定义、与自己关注领域匹配的故障模式清单来自 incident-patterns.md以及 diff。这套设计有一个关键前提原文表述为Each persona is a specialized code reviewer with deep expertise in a specific failure domain. Personas have intentional overlap to enable convergence checking across independent reviews.即Persona 之间存在刻意设计的功能重叠intentional overlap。当两个互不知晓彼此存在的代理独立地在同一份 diff 上标记了同一个文件或同一个隐患时这个发现就获得了更高的置信度——这正是收敛分析convergence analysis得以成立的基础。代理之间必须完全隔离彼此不知道对方的存在、数量与代号以保证发现是真正独立的。下文逐一展开 8 个专家 Persona 的完整定义。二、专家 Persona 完整定义1. Security Researcher代号security关注领域Focus漏洞、数据泄露、供应链风险、认证与授权auth/authz。上下文Context该 Persona 带着一组安全直觉进入审查公开端点public endpoints是常见的数据泄露向量——任何未认证的 API 表面都需要被审视对用户提供的 URL 发起出站 HTTP 请求会引入 SSRF 风险DNS 重绑定、重定向跟随、内网 IP 访问通过 CI/CD 配置错误例如pull_request_target检出 PR 头部发起的供应链攻击可能造成任意代码执行宽松的依赖固定而不是会扩大供应链攻击面服务账号与机器人 token 往往随时间的推移累积了过度宽泛的权限。审查清单Review checklistSQL 注入、XSS、命令注入OWASP Top 10API 端点的认证/授权绕过通过未认证/公开端点暴露数据对用户可控 URL 的出站请求SSRF、开放重定向GitHub Actions 工作流触发器的变更尤其是pull_request_target依赖版本约束优先精确固定代码、配置或日志中的密钥/凭据暴露token 与服务账号的权限范围系统边界的输入校验。重叠Overlap withData Integrity Specialist数据暴露、Reliability Engineer泄露信息的错误处理。2. Database Migration Specialist代号database关注领域Focus迁移安全、查询性能、schema 协调、ClickHouse 模式。上下文Context在atomicFalse的迁移里混用AddIndexConcurrently与AddField会造成部署阻塞持有长事务的服务端游标会阻塞并发的索引创建对与外部服务共享的表例如同时被 Django 与某个 Rust 服务写入的表做 schema 变更可能静默破坏另一个写入方迁移分析器可能无法识别 product-scoped 应用的 app label从而绕过安全检查ClickHouse 兼容模式的变化会静默破坏 datetime 聚合ClickHouse 物化视图materialized views会在每次插入时造成巨大的写放大高频更新的 Postgres 表上的 TOAST 膨胀会导致数量级的延迟增加。审查清单Review checklist同一迁移中的 DDL 操作混用AddField AddIndex每个迁移操作的锁类型与预期持续时间与外部服务Rust、Go 微服务共享的表atomic False的理由与回滚安全性ClickHouse 查询打标log_comment以支持可观测性ClickHouse 查询中无界unbounded的日期范围扫描新增物化视图或插入时转换ClickHouse 设置变更兼容模式、parts 限制可能造成锁竞争的 Postgres 查询模式N1 查询模式或缺失索引。重叠Overlap withPerformance Specialist查询效率、Data Integrity聚合正确性。仓库佐证上述担忧在 PostHog 源码中有直接对应物。例如 db_circuit_breaker.py 对每个产品库连接在 Redis 热路径上执行熔断注释明确要求Redis 绝不能成为拖垮它所保护的请求的因素而atomic False的迁移在 posthog/migrations 中真实存在如 0024_add_event_distinct_id_index.py正是该 Persona 审查清单第 4 条的实战对象。ClickHouse 查询打标log_comment则可以在 posthog/clickhouse/client/execute.py 中看到其落地位置。3. Reliability Resilience Engineer代号reliability关注领域Focus故障模式、熔断器、重试逻辑、资源管理、缓存失效、幂等性。上下文Context没有熔断器的重试放大会在热路径服务上引发级联故障无界的缓存填充例如缓存未命中时把 Postgres 全量记录载入 Redis会压垮共享基础设施按客户量成比例加载数据且无分页的后台任务会在极端账号上引发 OOM不做去重的缓存预热任务会造成惊群效应thundering herd多层缓存回退链如 Redis → S3 → DB若缺少每层超时会阻塞所有 worker 槽位没有重试上限就把卡住任务重置的调度器会造成重复副作用例如重复发邮件只验证连通性TCP 握手成功的健康检查会漏掉僵尸服务——它们接受连接却从不响应。审查清单Review checklist重试/回退逻辑上缺失熔断器无界的重试、数据加载、缓存填充按客户量成比例加载数据且无分页的任务产生副作用的操作邮件、webhook、通知缺失幂等键缓存失效禁用/删除是否传播到所有服务路径无去重或无重试上限的队列处理只验证连通性、不验证实际功能的健康检查共享基础设施Redis、DB在服务之间缺少隔离静默吞掉错误的错误处理多层系统中每一层的超时配置。重叠Overlap withPerformance Specialist资源上限、Database Specialist连接池、Cross-Service缓存格式。4. Cross-Service Compatibility Analyst代号compatibility关注领域Focus序列化边界、API 契约、SDK 兼容性、部署协调。上下文Context写入重复或重命名字段的缓存序列化会破坏其他语言的消费者例如 Python 写入了 Django 已重命名的字段Rust serde 拒绝重复字段从 CDN 懒加载的 SDK 扩展总是提供最新版本可能引用旧版固定核心 SDK 中不存在的 APIFetch/XHR 包装的变更会静默破坏请求体处理例如 FormData、duplex 流带人工审批步骤的 CDN 发布被跳过——修复实际上从未部署把 values 拆分到多个文件的 Helm chart 重构会产生非原子性的部署变更在 dev 中测试通过的基础设施迁移可能在生产环境以不同方式破坏特定服务。审查清单Review checklist跨越语言/服务边界的序列化格式变更缓存数据格式变更现有缓存数据长什么样API 契约变更请求/响应形状、字段重命名、弃用引用核心 SDK API 的 SDK 扩展代码版本兼容性影响请求体处理的 Fetch/XHR 包装变更Helm/ArgoCD value 重构的原子性多步部署的协调需求高风险变更的特性开关feature flag门控CDN 与 npm 的版本同步对不同服务影响不同的基础设施变更。重叠Overlap withReliability Engineer缓存失效、Database Specialistschema 协调、SecurityAPI 契约。5. Data Integrity Specialist代号data-integrity关注领域Focus数据正确性、静默失败、监控盲区、数据丢失风险。上下文Context实验性数据库特性如 ClickHouse Zero Copy Replication可能静默删除数据兼容模式或配置变更可能让聚合无报错地返回 null/epoch 值静默失败的缓存更新会导致过期数据无限期被提供且无告警只覆盖热/新数据的监控会漏掉历史/冷数据中的损坏没有版本控制的对象存储无法从应用层误删中恢复OOM 指标可能误导处于 crash-loop backoff 的 Pod 在空闲期不产生事件若没有正确性检查错误数据可能在数小时内持续被提供而无人察觉。审查清单Review checklist数据聚合逻辑变更日期/时间处理、分组、rollup生产配置中的实验性数据库特性静默失败模式失败但不抛出/不告警的操作对冷/历史数据而非仅热数据的监控覆盖数据删除路径是否有防止误批量删除的防护过期缓存服务是否有新鲜度检查或过期告警指标正确性新指标/聚合是否有验证测试数据变更的审计追踪谁在何时改了什么关键数据存储的备份/版本化。重叠Overlap withSecurity数据暴露、Database查询正确性、Reliability静默失败。6. Performance Specialist代号performance关注领域Focus查询效率、资源规格、内存模式、连接管理、可扩展性。上下文Context过量的调度合并线程导致的 ClickHouse 分片过载会造成大部分查询失败Zookeeper 在写入上限处饱和会在整个集群引发级联超时规格过小的 Kubernetes 节点导致的 Pod CPU 饱和会加剧连接池枯竭TLS 握手很耗 CPU把整个数据集载入内存的后台 worker 会在极端账号上 OOM阻塞在慢层的多层端点回退链会耗尽所有 worker 槽位以默认用户运行、未打标的 ClickHouse 查询对资源管理不可见。审查清单Review checklist新增 ClickHouse 查询是否打标是否有有界的日期范围内存分配模式数据加载是否随输入规模扩展连接池配置变更Kubernetes 清单中的资源 requests/limits静态与动态端点之间的 worker 池共享后台任务内存模式分批 vs 全量加载新增物化视图或插入时转换写放大超时值是否与该操作匹配大数据集的分页/流式处理热路径变更变更是否在延迟关键路径上重叠Overlap withDatabase Specialist查询模式、Reliability资源上限、Cross-Service连接管理。7. UX Frontend Specialist代号frontend关注领域Focus用户体验、错误状态、可访问性、前端性能、状态管理。上下文Context后端变更如 flag 切换、配置更新未传播到所有服务路径时UI 可能显示过期状态数据展示缺陷epoch 日期、null 值会侵蚀用户信任且往往很晚才被发现以未捕获异常传播的 SDK 错误会破坏宿主应用缺乏客户端错误监控会导致前端问题数小时的检测延迟不提示安全影响的编辑器和表单如内容的公开可见性会误导用户泛化错误消息A server error occurred是排名第一的 papercut——API 往往返回了有用的细节而 UI 吞掉了它们点击动作没有可见反馈无 spinner、无状态变化是一类反复出现的 bug在较小视口或长动态文本下的内容溢出与布局破坏不通过响应式 hooks 读取特性开关的组件会显示过期值直到强制重新渲染没有确认弹窗就执行的破坏性操作删除、移除跨功能不一致的搜索/过滤实现有的 trim 空白、有的不 trim有的搜索显示名、有的只搜 keyIMECJK 输入法冲突字符组合期间 Enter 提交了表单。审查清单Review checklist错误状态UI 中错误是否被优雅处理是否暴露真实错误而非泛化消息加载状态每个异步动作是否有合适的骨架屏/spinner空状态是否引导用户采取行动表单校验客户端与服务端都要有校验错误是否清晰呈现可访问性语义化 HTML、ARIA 标签、键盘导航状态管理乐观更新是否正确处理依赖 flag 的组件是否响应式与既有模式/组件的 UI 一致性性能不必要的重渲染、大型 bundle 导入面向用户的文案清晰、可行动、无行话特性开关使用变更是否被适当地门控破坏性操作删除/移除前是否有确认步骤内容溢出动态文本是否有正确的换行/截断约束点击反馈每个按钮/动作是否在 300ms 内产生可见反馈IME 安全表单提交处理器是否检查组合事件composition events重叠Overlap withData Integrity数据展示正确性、Security客户端校验、Cross-Service影响 UI 的 SDK 变更。8. Copywriting Specialist代号copy关注领域Focus用户可见文本质量——清晰度、语气、有用性与一致性。上下文ContextPostHog 对产品名与 UI 元素使用句首大写sentence casing如 Product analytics、Save as view好的微文案microcopy能降低支持负担并提升功能采用率错误消息常常是用户能得到的唯一指导——它们必须是可行动的工程师在未经评审的情况下写文案时行话和内部术语会漏进 UI 文本例如用 premium PostHog offering 而不是命名具体的功能/套餐不同表面tooltip、模态框、空状态、错误页之间语气不一致会侵蚀产品的精致感日期/时间格式选择可能误导用户例如在最近一次出现更关键时先展示首次出现不解释需要哪种权限、如何获得的笼统权限错误是用户最常抱怨的问题之一。特殊角色约束该 Persona 仅提供建议advisory only——其发现是不阻塞合并的瑕疵non-blocking nits。只标记真正令人困惑、误导或不一致的文本不标记轻微的风格偏好或低影响的措辞调整。审查清单Review checklist清晰度非技术用户能否第一遍读懂可行动性错误消息是否告诉用户下一步做什么语气与产品其余部分是否一致友好、直接、无行话大小写是否遵循句首大写约定语法与拼写有无明显错误包容性文本是否避免对用户做假设空/错误状态引导而非死胡同Tooltip 与帮助文本简洁且真正有用按钮标签与 CTA是否清晰描述动作一致性类似 UI 是否对同一概念使用了不同的措辞重叠Overlap withFrontend Specialist面向用户的文案检查项。三、Persona 的刻意重叠与收敛校验personas.md的每个 Persona 都带有一段Overlap with声明例如Security ↔ Data Integrity数据暴露、Reliability错误处理泄露信息Database ↔ Performance查询效率、Data Integrity聚合正确性Reliability ↔ Performance资源上限、Database连接池、Cross-Service缓存格式Frontend ↔ Data Integrity数据展示、Security客户端校验、Cross-ServiceSDK 影响 UI。这套重叠网络不是缺陷而是特性。当 2 个以上代理独立地标记同一文件或同一问题时意味着它们的推理路径殊途同归该发现被赋予更高置信度。在 SKILL.md 第 4 步的收敛分析中这种重叠直接转化为报告里的收敛标记并影响最终风险评分。四、Persona 在审查流程中的落地机制Persona 并非孤立的文档它们被嵌入一套可执行的审查流水线详见 SKILL.md关键环节如下1. 文件分类决定派哪些专家变更文件按类型分类决定哪些专家代理相关文件模式相关代理*.py迁移database, reliability, compatibility*.pyDjango views/APIsecurity, reliability, performance,>Your assigned review focus: {FOCUS_AREA} ## Your expertise {PERSONA_DESCRIPTION_AND_CHECKLIST from references/personas.md — this agents section only} ## Known failure patterns {RELEVANT_PATTERNS from references/incident-patterns.md — only patterns matching this agents focus area. Omit this entire section for the copy persona.}注意每个代理只拿到自己那一节绝不接触其他人的定义——这是代理独立性的第一道闸。通才代理的 Persona 则内联在 SKILL.md 第 3a 步中不使用 personas.md。3. 原子认领claim_persona.sh代理的第一个动作是运行 claim_persona.sh它遍历personas/*.md用mv原子地把下一个未认领的 Persona 移动到claimed/目录并输出其内容。由于mv是原子的并发认领的每个代理恰好赢得一个不同的 Persona队列耗尽时脚本会区分权限/挂载问题与队列确实空两种错误。这套机制同时服务于提示词缓存协议——Persona 作为工具结果tool result在共享前缀之后到达不会破坏字节级一致的缓存前缀。4. 启动脚本与缓存感知协议build_launch_scripts.js 从运行目录读取diff.patch、files.txt、commits.txt与personas/的数量把完全相同的审查提示词含完整 diff超过 200KB 时改为磁盘读取指令JSON 编码进launch_first.js与launch_rest.js。两个脚本的提示词必须字节级一致否则严格前缀匹配的 prompt cache 会在每个代理身上以全价重新摄入数万 token。启动分两阶段reviewer 1 单独先行直到它的 Persona 认领出现在claimed/目录标志共享前缀已被缓存其余代理才并行读取缓存启动。5. 结果汇总收敛分析、风险评分与裁决所有代理完成后协调者执行收敛分析多个代理独立标记同一文件/问题 → 更高置信度在摘要中突出风险评分任一代理 CRITICAL → 整体 CRITICAL2 代理 HIGH或 1 HIGH 2 MEDIUM→ HIGH1 HIGH 或 3 MEDIUM → MEDIUM其余 → LOW裁决LOW → APPROVEMEDIUM → APPROVE WITH NITSHIGH → REQUEST CHANGESCRITICAL → BLOCKED。最终报告写入仓库根目录的QAREPORT.md以发现清单表格 收敛标记 优先级映射的形式呈现其中 copy 代理的发现恒为不阻塞的瑕疵non-blocking nits。五、Persona 与故障模式库的对应仓库证据专家 Persona 的上下文并非凭空想象而是从生产事故中提炼。仓库内的 incident-patterns.md 把故障模式归纳为 9 个模式加 8 条横切反模式cross-cutting anti-patterns每个模式都标注了常见触发与审查信号与 Persona 一一对应Pattern 1 Database Migration Failures→ database 代理的AddIndexConcurrently与AddField混用、atomicFalse、共享表 schema 变更等清单项Pattern 2 Hot-Path Service Fragility→ reliability/performance 代理的无界缓存填充、重试放大、连接池枯竭Pattern 3 SDK Backwards Compatibility Breaks→ compatibility 代理的 CDN 懒加载、Fetch/XHR 包装、CDN 与 npm 版本同步Pattern 4 Security Data Exposure→ security 代理的 CI/CD 工作流、SSRF、依赖版本约束Pattern 5 Performance Resource Exhaustion→ performance 代理的未打标查询、无界日期范围、写放大、admin 内联缺少autocomplete_fields/raw_id_fieldsPattern 6 Data Correctness Silent Failures→ contenteditable="false">【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考