36e - 第5周：测试与打磨

第 5 周测试策略金字塔：

        ┌───────────────┐
        │   手动测试     │  ← 关键用户流程（5-8 个场景）
        │   (Day 2 下午) │     真实设备 + 真实网络
        ├───────────────┤
        │   E2E 测试     │  ← 核心用户旅程（3-5 个流程）
        │   (Day 2 上午) │     Playwright 自动化
        ├───────────────┤
        │   集成测试     │  ← API + 数据流（每模块 2-3 个）
        │   (Day 1 下午) │     真实数据库 + 真实 API
        ├───────────────┤
        │   单元测试补充  │  ← 边界条件 + 错误路径
        │   (Day 1 上午) │     补充 Week 3-4 遗漏的测试
        ├───────────────┤
        │   PBT 属性测试  │  ← 数据转换 + 计算逻辑
        │   (Day 1 上午) │     自动发现边界情况
        └───────────────┘
        │   类型检查     │  ← TypeScript strict 模式
        │   (持续)       │     编译时自动检查
        └───────────────┘

质量门标准（Quality Gates）：
├── 单元测试覆盖率 > 70%（核心逻辑 > 90%）
├── 所有 PBT 属性测试通过
├── E2E 测试覆盖所有关键用户流程
├── 手动测试通过所有验收标准
├── TypeScript 编译零错误
├── ESLint/Biome 零警告
├── 构建成功且无警告
└── 所有已知 Bug 修复或标记为"已知问题"

# 运行覆盖率报告
pnpm test:run --coverage
 
# 查看覆盖率摘要
# 重点关注：
# - 核心业务逻辑文件的覆盖率
# - 未覆盖的分支（branches）
# - 未覆盖的函数（functions）

覆盖率分析清单：

□ 哪些核心文件覆盖率低于 70%？
  ├── 列出所有低覆盖率的核心文件
  ├── 优先补充业务逻辑文件的测试
  └── UI 组件覆盖率可以较低（50% 即可）

□ 哪些分支未覆盖？
  ├── 错误处理分支（catch 块）
  ├── 边界条件分支（空值、零值）
  ├── 权限检查分支
  └── 这些往往是 Bug 最多的地方

□ 哪些函数完全没有测试？
  ├── 工具函数（utils）
  ├── 数据转换函数
  ├── 验证函数
  └── 这些是最容易补充测试的

AI 辅助测试生成的工作流：

1. 识别低覆盖率文件
   $ pnpm test:run --coverage 2>&1 | grep "< 70"

2. 对每个低覆盖率文件，让 AI 生成测试
   ├── 提供文件代码 + 对应的 requirements
   ├── 要求覆盖错误路径和边界条件
   └── 审查生成的测试，确保断言有意义

3. 运行测试，修复失败的用例
   ├── 测试失败 = 可能发现了 Bug！
   ├── 分析失败原因：是测试写错了还是代码有 Bug？
   └── 修复 Bug 或调整测试

4. 重新检查覆盖率
   └── 目标：核心逻辑 > 90%，整体 > 70%

PBT 重点覆盖的逻辑：

1. 数据转换函数
   ├── 属性：往返一致性 decode(encode(x)) === x
   ├── 属性：输出格式始终有效
   └── 属性：特殊字符不会破坏转换

2. 计算逻辑
   ├── 属性：结果在预期范围内
   ├── 属性：单调性（输入增大，输出不减小）
   └── 属性：幂等性（重复操作结果不变）

3. 验证规则
   ├── 属性：有效输入始终通过验证
   ├── 属性：无效输入始终被拒绝
   └── 属性：验证错误消息始终有意义

4. 搜索和筛选
   ├── 属性：筛选结果是原集合的子集
   ├── 属性：空筛选条件返回全部结果
   └── 属性：结果数量 <= 原集合数量

// 示例：用 fast-check 测试用户输入验证逻辑
import { describe, it, expect } from 'vitest'
import * as fc from 'fast-check'
import { validateEmail, sanitizeInput } from './validation'
 
describe('validateEmail - PBT', () => {
  // 属性 1：有效邮箱格式始终通过验证
  it('有效邮箱格式始终通过', () => {
    fc.assert(
      fc.property(
        fc.emailAddress(),
        (email) => {
          const result = validateEmail(email)
          return result.valid === true
        }
      )
    )
  })
 
  // 属性 2：不含 @ 的字符串始终不通过
  it('不含 @ 的字符串始终被拒绝', () => {
    fc.assert(
      fc.property(
        fc.string().filter(s => !s.includes('@') && s.length > 0),
        (notEmail) => {
          const result = validateEmail(notEmail)
          return result.valid === false
        }
      )
    )
  })
})
 
describe('sanitizeInput - PBT', () => {
  // 属性 3：清理后的输出不包含 HTML 标签
  it('清理后不包含 HTML 标签', () => {
    fc.assert(
      fc.property(
        fc.string(),
        (input) => {
          const sanitized = sanitizeInput(input)
          return !/<[^>]*>/.test(sanitized)
        }
      )
    )
  })
 
  // 属性 4：清理是幂等的
  it('重复清理结果不变', () => {
    fc.assert(
      fc.property(
        fc.string(),
        (input) => {
          const once = sanitizeInput(input)
          const twice = sanitizeInput(once)
          return once === twice
        }
      )
    )
  })
})

集成测试重点场景：

1. 用户认证流程
   ├── 注册 → 验证邮箱 → 登录 → 获取 session
   ├── 无效凭证 → 错误响应
   ├── Token 过期 → 自动刷新
   └── 权限不足 → 403 响应

2. 核心业务流程
   ├── 创建资源 → 读取 → 更新 → 删除（CRUD 完整链路）
   ├── 并发操作 → 数据一致性
   ├── 大数据量 → 分页正确性
   └── 关联数据 → 级联操作正确性

3. 第三方服务集成
   ├── 支付流程（Stripe Webhook 模拟）
   ├── 邮件发送（Resend API 模拟）
   ├── OAuth 回调处理
   └── 文件上传和处理

4. 错误恢复
   ├── 数据库连接断开 → 重连
   ├── 第三方 API 超时 → 重试
   ├── 无效数据 → 优雅降级
   └── 并发冲突 → 正确处理

// 示例：核心业务流程集成测试
import { describe, it, expect, beforeAll, afterAll } from 'vitest'
import { createTestClient, cleanupTestData } from './test-utils'
 
describe('Review CRUD 集成测试', () => {
  let client: TestClient
  let testUserId: string
 
  beforeAll(async () => {
    client = await createTestClient()
    testUserId = await client.createTestUser()
  })
 
  afterAll(async () => {
    await cleanupTestData(testUserId)
  })
 
  it('完整的创建→读取→更新→删除流程', async () => {
    // 创建
    const created = await client.createReview({
      title: 'Test Review',
      content: 'Test content',
      userId: testUserId,
    })
    expect(created.id).toBeDefined()
    expect(created.title).toBe('Test Review')
 
    // 读取
    const fetched = await client.getReview(created.id)
    expect(fetched.title).toBe('Test Review')
 
    // 更新
    const updated = await client.updateReview(created.id, {
      title: 'Updated Review',
    })
    expect(updated.title).toBe('Updated Review')
 
    // 删除
    await client.deleteReview(created.id)
    const deleted = await client.getReview(created.id)
    expect(deleted).toBeNull()
  })
 
  it('未认证用户无法创建资源', async () => {
    const unauthClient = createTestClient({ authenticated: false })
    await expect(
      unauthClient.createReview({ title: 'Test', content: 'Test' })
    ).rejects.toThrow('Unauthorized')
  })
 
  it('用户只能访问自己的资源', async () => {
    const otherUserId = await client.createTestUser()
    const review = await client.createReview({
      title: 'Private Review',
      userId: testUserId,
    })
 
    const otherClient = createTestClient({ userId: otherUserId })
    await expect(
      otherClient.updateReview(review.id, { title: 'Hacked' })
    ).rejects.toThrow('Forbidden')
 
    await cleanupTestData(otherUserId)
  })
})

E2E 测试覆盖的关键流程（3-5 个）：

1. 新用户注册和首次使用流程
   ├── 访问首页 → 点击注册 → 填写表单 → 验证邮箱
   ├── 首次登录 → 引导页面 → 完成设置
   └── 验证：用户能成功完成首次体验

2. 核心功能的完整使用流程
   ├── 登录 → 创建资源 → 编辑 → 保存 → 查看结果
   ├── 搜索 → 筛选 → 排序 → 分页
   └── 验证：核心功能正常工作

3. 支付流程（如果有）
   ├── 查看定价 → 选择方案 → 进入支付 → 完成支付
   ├── 验证订阅状态更新
   └── 验证：支付流程无阻塞

4. 错误恢复流程
   ├── 提交无效数据 → 显示错误提示 → 修正 → 成功提交
   ├── 网络断开 → 显示离线提示 → 恢复后自动重试
   └── 验证：错误处理对用户友好

5. 移动端关键流程（响应式）
   ├── 在移动端视口下完成核心操作
   ├── 导航菜单正常工作
   └── 验证：移动端体验可用

// 示例：Playwright E2E 测试
import { test, expect } from '@playwright/test'
 
test.describe('新用户注册流程', () => {
  test('完整的注册→登录→首次使用流程', async ({ page }) => {
    // 1. 访问首页
    await page.goto('/')
    await expect(page.getByRole('heading', { level: 1 })).toBeVisible()
 
    // 2. 点击注册
    await page.getByRole('link', { name: '开始使用' }).click()
    await expect(page).toHaveURL('/auth/signup')
 
    // 3. 填写注册表单
    await page.getByLabel('邮箱').fill('test@example.com')
    await page.getByLabel('密码').fill('SecurePass123!')
    await page.getByLabel('确认密码').fill('SecurePass123!')
    await page.getByRole('button', { name: '注册' }).click()
 
    // 4. 验证跳转到引导页
    await expect(page).toHaveURL('/onboarding')
    await expect(page.getByText('欢迎')).toBeVisible()
 
    // 5. 完成引导设置
    await page.getByRole('button', { name: '下一步' }).click()
    await page.getByRole('button', { name: '完成设置' }).click()
 
    // 6. 验证进入主界面
    await expect(page).toHaveURL('/dashboard')
    await expect(page.getByText('仪表板')).toBeVisible()
  })
 
  test('无效邮箱显示错误提示', async ({ page }) => {
    await page.goto('/auth/signup')
    await page.getByLabel('邮箱').fill('invalid-email')
    await page.getByLabel('密码').fill('SecurePass123!')
    await page.getByRole('button', { name: '注册' }).click()
 
    await expect(page.getByText('请输入有效的邮箱地址')).toBeVisible()
  })
})
 
test.describe('核心功能流程', () => {
  test.beforeEach(async ({ page }) => {
    // 使用测试账号登录
    await page.goto('/auth/login')
    await page.getByLabel('邮箱').fill('test@example.com')
    await page.getByLabel('密码').fill('SecurePass123!')
    await page.getByRole('button', { name: '登录' }).click()
    await expect(page).toHaveURL('/dashboard')
  })
 
  test('创建→编辑→删除资源的完整流程', async ({ page }) => {
    // 创建
    await page.getByRole('button', { name: '新建' }).click()
    await page.getByLabel('标题').fill('测试项目')
    await page.getByRole('button', { name: '保存' }).click()
    await expect(page.getByText('创建成功')).toBeVisible()
 
    // 编辑
    await page.getByText('测试项目').click()
    await page.getByRole('button', { name: '编辑' }).click()
    await page.getByLabel('标题').fill('更新后的项目')
    await page.getByRole('button', { name: '保存' }).click()
    await expect(page.getByText('更新成功')).toBeVisible()
 
    // 删除
    await page.getByRole('button', { name: '删除' }).click()
    await page.getByRole('button', { name: '确认删除' }).click()
    await expect(page.getByText('删除成功')).toBeVisible()
  })
})
 
// 移动端测试
test.describe('移动端响应式', () => {
  test.use({ viewport: { width: 375, height: 812 } }) // iPhone X
 
  test('移动端导航正常工作', async ({ page }) => {
    await page.goto('/')
    // 汉堡菜单
    await page.getByRole('button', { name: '菜单' }).click()
    await expect(page.getByRole('navigation')).toBeVisible()
    await page.getByRole('link', { name: '功能' }).click()
    await expect(page).toHaveURL('/#features')
  })
})

手动测试清单：

□ 视觉检查
  ├── 所有页面在桌面端（1920×1080）显示正常
  ├── 所有页面在平板端（768×1024）显示正常
  ├── 所有页面在手机端（375×812）显示正常
  ├── 暗色模式（如果支持）显示正常
  ├── 字体加载正确，无 FOUT/FOIT
  ├── 图片加载正确，无破图
  ├── 动画流畅，无卡顿
  └── 表单元素对齐正确

□ 交互检查
  ├── 所有按钮可点击，有 hover/active 反馈
  ├── 所有表单可提交，有加载状态
  ├── 所有链接指向正确页面
  ├── 键盘导航正常（Tab 顺序合理）
  ├── 错误提示清晰且位置正确
  ├── 成功提示出现且自动消失
  ├── 模态框可正常打开和关闭
  └── 下拉菜单正常工作

□ 内容检查
  ├── 所有文案无错别字
  ├── 空状态有友好提示
  ├── 加载状态有骨架屏或 spinner
  ├── 错误页面（404、500）有友好提示
  ├── 邮件模板在主流邮件客户端显示正常
  └── SEO meta 标签正确（title、description、og:image）

□ 安全检查
  ├── 未登录用户无法访问受保护页面
  ├── 普通用户无法访问管理员页面
  ├── 直接访问 API 端点需要认证
  ├── 敏感操作有确认对话框
  ├── 密码输入框有遮挡
  └── 环境变量未暴露到前端

□ 边界情况
  ├── 超长文本是否正确截断或换行
  ├── 特殊字符（emoji、中文、日文）显示正常
  ├── 大量数据（100+ 条）列表性能可接受
  ├── 快速连续点击不会重复提交
  ├── 浏览器前进/后退按钮正常工作
  └── 刷新页面不丢失状态

AI 辅助测试的三步法：

Step 1：让 AI 分析测试覆盖缺口
├── 提供源代码文件
├── 提供已有测试文件
├── 提供覆盖率报告
└── 让 AI 识别未覆盖的分支和路径

Step 2：让 AI 生成缺失的测试
├── 针对每个缺口生成测试用例
├── 包含正常路径和错误路径
├── 包含边界条件
└── 使用项目已有的测试风格和工具

Step 3：审查和运行
├── 审查生成的测试是否有意义
├── 删除冗余或无价值的测试
├── 运行测试，分析失败原因
└── 修复 Bug 或调整测试

当测试发现 Bug 时的处理流程：

1. 复现 Bug
   ├── 记录触发条件（输入、状态、环境）
   ├── 确认 Bug 可稳定复现
   └── 如果是偶发 Bug，增加测试运行次数

2. 让 AI 分析根因
   ├── 提供失败的测试代码和错误信息
   ├── 提供相关的源代码
   ├── 让 AI 分析可能的根本原因
   └── AI 通常能快速定位逻辑错误

3. 修复并验证
   ├── 让 AI 提供修复方案
   ├── 审查修复是否引入新问题
   ├── 运行所有相关测试
   └── 确认 Bug 已修复且无回归

4. 添加回归测试
   ├── 为这个 Bug 添加专门的测试用例
   ├── 确保未来不会再次出现
   └── 在 commit message 中引用 Bug 描述

# 质量门检查脚本
echo "=== 质量门检查 ==="
 
# 1. TypeScript 编译
echo "1. TypeScript 编译检查..."
pnpm tsc --noEmit
echo "✅ TypeScript 编译通过"
 
# 2. Lint 检查
echo "2. Lint 检查..."
pnpm lint
echo "✅ Lint 检查通过"
 
# 3. 单元测试
echo "3. 运行单元测试..."
pnpm test:run
echo "✅ 单元测试通过"
 
# 4. 覆盖率检查
echo "4. 覆盖率检查..."
pnpm test:run --coverage
echo "✅ 覆盖率报告已生成"
 
# 5. E2E 测试
echo "5. 运行 E2E 测试..."
pnpm test:e2e
echo "✅ E2E 测试通过"
 
# 6. 构建检查
echo "6. 构建检查..."
pnpm build
echo "✅ 构建成功"
 
echo "=== 所有质量门通过 ✅ ==="

请分析以下代码的测试覆盖情况：

源代码文件：
[粘贴源代码]

已有测试文件：
[粘贴已有测试]

覆盖率报告摘要：
- 行覆盖率：[N]%
- 分支覆盖率：[N]%
- 函数覆盖率：[N]%

请：
1. 识别未覆盖的代码路径和分支
2. 按优先级排序（高风险路径优先）
3. 为每个缺口生成测试用例
4. 特别关注：错误处理、边界条件、安全相关逻辑
5. 使用 Vitest 框架，保持与已有测试一致的风格

测试发现了一个 Bug，请帮我分析：

失败的测试：
[粘贴测试代码]

错误信息：
[粘贴完整错误输出]

相关源代码：
[粘贴相关代码]

对应的需求（requirements.md）：
[粘贴验收标准]

请：
1. 分析 Bug 的根本原因
2. 判断是代码 Bug 还是测试写错了
3. 如果是代码 Bug，提供修复方案
4. 如果是测试问题，提供修正后的测试
5. 建议是否需要添加额外的回归测试

请为以下用户流程生成 Playwright E2E 测试：

用户流程描述：
[描述完整的用户操作步骤]

页面 URL 结构：
[列出涉及的页面 URL]

关键 UI 元素：
[列出按钮、表单、文本等关键元素]

验收标准：
[粘贴 requirements.md 中的验收标准]

要求：
1. 使用 Playwright Test 框架
2. 使用 getByRole、getByLabel、getByText 等语义化选择器
3. 包含等待和断言
4. 覆盖正常流程和至少一个错误流程
5. 添加移动端视口的测试变体

性能优化的优先级矩阵：

高影响 + 低成本（立即做）：
├── 图片优化（WebP/AVIF 格式、懒加载、响应式尺寸）
├── 代码分割（动态 import、路由级分割）
├── 字体优化（font-display: swap、子集化）
├── 缓存策略（静态资源长期缓存、API 响应缓存）
└── 压缩（Gzip/Brotli）

高影响 + 中成本（优先做）：
├── 数据库查询优化（索引、N+1 修复）
├── API 响应优化（字段筛选、分页）
├── 首屏渲染优化（SSR/SSG、关键 CSS 内联）
├── 第三方脚本优化（延迟加载、异步加载）
└── Bundle 体积优化（tree-shaking、依赖替换）

低影响 + 高成本（延后做）：
├── 微前端架构
├── CDN 边缘计算
├── 数据库分片
└── 自定义缓存层

Core Web Vitals 2026 标准：

1. LCP（Largest Contentful Paint）— 加载性能
   ├── 好：< 2.5 秒
   ├── 需改进：2.5-4 秒
   ├── 差：> 4 秒
   └── 目标：< 2 秒

2. INP（Interaction to Next Paint）— 交互响应
   ├── 好：< 200ms
   ├── 需改进：200-500ms
   ├── 差：> 500ms
   └── 目标：< 150ms（2026 年竞争性阈值）

3. CLS（Cumulative Layout Shift）— 视觉稳定性
   ├── 好：< 0.1
   ├── 需改进：0.1-0.25
   ├── 差：> 0.25
   └── 目标：< 0.05

# 1. 本地 Lighthouse 审计
# 在 Chrome DevTools → Lighthouse 面板运行审计
# 记录：Performance 分数、LCP、INP、CLS
 
# 2. PageSpeed Insights 在线测试
# 访问 https://pagespeed.web.dev/
# 测试你的生产 URL（或 Vercel Preview URL）
# 记录：移动端和桌面端分数
 
# 3. 全站批量审计（使用 Unlighthouse）
npx unlighthouse --site https://your-app.vercel.app
# 生成所有页面的 Lighthouse 报告
 
# 4. Bundle 体积分析
# Next.js
ANALYZE=true pnpm build
# Vite
pnpm build --report

基线记录模板：

页面          | LCP    | INP    | CLS   | 分数  | 备注
首页          | 2.1s   | 180ms  | 0.02  | 85    | LCP 需优化
Dashboard     | 3.5s   | 250ms  | 0.15  | 62    | 需重点优化
定价页        | 1.8s   | 120ms  | 0.01  | 92    | 良好
登录页        | 1.5s   | 100ms  | 0.00  | 95    | 良好

Bundle 体积：
├── 总体积：450KB（gzip 后）
├── 最大 chunk：vendor.js 280KB
├── 首屏 JS：180KB
└── 目标：首屏 JS < 150KB

LCP 优化清单：

□ 图片优化
  ├── 使用 next/image 或 <picture> 标签
  ├── 格式：WebP（兼容性好）或 AVIF（体积更小）
  ├── 响应式尺寸：srcset + sizes
  ├── 首屏图片：priority / fetchpriority="high"
  ├── 非首屏图片：loading="lazy"
  └── 使用 CDN 提供图片（Cloudflare Images / imgix）

□ 字体优化
  ├── font-display: swap（避免 FOIT）
  ├── 预加载关键字体：<link rel="preload">
  ├── 字体子集化（只包含使用的字符）
  └── 使用系统字体栈作为 fallback

□ 服务端渲染优化
  ├── 关键页面使用 SSR 或 SSG
  ├── 避免客户端数据获取阻塞渲染
  ├── 使用 streaming SSR（React 18+）
  └── 预渲染静态内容

□ 资源加载优化
  ├── 关键 CSS 内联（< 14KB）
  ├── 非关键 CSS 异步加载
  ├── 预连接关键域名：<link rel="preconnect">
  ├── DNS 预解析：<link rel="dns-prefetch">
  └── 减少重定向链

// Next.js 图片优化示例
import Image from 'next/image'
 
// ✅ 正确：首屏图片使用 priority
export function HeroSection() {
  return (
    <Image
      src="/hero-image.webp"
      alt="产品截图"
      width={1200}
      height={630}
      priority  // 首屏图片预加载
      sizes="(max-width: 768px) 100vw, 1200px"
      quality={85}
    />
  )
}
 
// ✅ 正确：非首屏图片使用懒加载
export function FeatureCard({ image }: { image: string }) {
  return (
    <Image
      src={image}
      alt="功能截图"
      width={600}
      height={400}
      loading="lazy"  // 默认行为，非首屏懒加载
      sizes="(max-width: 768px) 100vw, 600px"
    />
  )
}

INP 优化清单：

□ 减少主线程阻塞
  ├── 长任务拆分：使用 scheduler.yield()
  ├── 使用 Web Worker 处理计算密集型任务
  ├── 避免同步 DOM 操作
  └── 使用 requestAnimationFrame 处理动画

□ React 特定优化
  ├── 使用 useTransition 处理非紧急更新
  ├── 使用 useDeferredValue 延迟渲染
  ├── 使用 React.memo 避免不必要的重渲染
  ├── 使用 useCallback/useMemo 缓存计算
  └── 虚拟列表（react-window / tanstack-virtual）

□ 事件处理优化
  ├── 输入框使用 debounce（300ms）
  ├── 滚动事件使用 throttle
  ├── 避免在事件处理器中做重计算
  └── 使用 passive event listeners

// React INP 优化示例
import { useTransition, useDeferredValue } from 'react'
 
function SearchResults({ query }: { query: string }) {
  // 使用 useTransition 标记非紧急更新
  const [isPending, startTransition] = useTransition()
  const [results, setResults] = useState([])
 
  const handleSearch = (value: string) => {
    // 输入框立即响应（紧急更新）
    setQuery(value)
 
    // 搜索结果延迟更新（非紧急更新）
    startTransition(() => {
      const filtered = filterResults(allData, value)
      setResults(filtered)
    })
  }
 
  return (
    <div>
      <input onChange={(e) => handleSearch(e.target.value)} />
      {isPending ? <Spinner /> : <ResultList results={results} />}
    </div>
  )
}

CLS 优化清单：

□ 图片和视频
  ├── 始终指定 width 和 height 属性
  ├── 使用 aspect-ratio CSS 属性
  ├── 使用占位符（blur placeholder / skeleton）
  └── 避免图片加载后改变布局

□ 字体
  ├── font-display: optional（最佳 CLS）或 swap
  ├── 预加载字体文件
  ├── 使用 size-adjust 匹配 fallback 字体尺寸
  └── 避免 FOUT 导致的布局偏移

□ 动态内容
  ├── 为动态加载的内容预留空间
  ├── 避免在已有内容上方插入新内容
  ├── 使用 min-height 为容器预留空间
  ├── 广告/嵌入内容使用固定尺寸容器
  └── Toast/通知不影响页面布局（使用 fixed 定位）

□ 动画
  ├── 只使用 transform 和 opacity 做动画
  ├── 避免动画改变元素尺寸
  └── 使用 will-change 提示浏览器

API 性能优化清单：

□ 数据库查询优化
  ├── 添加缺失的索引（WHERE、JOIN、ORDER BY 字段）
  ├── 修复 N+1 查询（使用 eager loading / join）
  ├── 使用 EXPLAIN ANALYZE 分析慢查询
  ├── 限制返回字段（SELECT 具体字段而非 *）
  └── 大数据集使用游标分页（cursor-based pagination）

□ 缓存策略
  ├── 静态数据：Redis / 内存缓存（TTL 5-60 分钟）
  ├── 用户数据：短期缓存（TTL 1-5 分钟）
  ├── API 响应：HTTP 缓存头（Cache-Control、ETag）
  ├── 计算结果：Memoization
  └── 全页缓存：ISR（Incremental Static Regeneration）

□ API 设计优化
  ├── 批量 API（一次请求获取多个资源）
  ├── 字段筛选（只返回客户端需要的字段）
  ├── 压缩响应（Gzip/Brotli）
  ├── 连接池（数据库连接复用）
  └── 超时设置（避免长时间挂起）

// 数据库查询优化示例（Prisma）
 
// ❌ N+1 查询问题
const users = await prisma.user.findMany()
for (const user of users) {
  const posts = await prisma.post.findMany({
    where: { authorId: user.id }
  })
}
 
// ✅ 使用 include 一次查询
const users = await prisma.user.findMany({
  include: {
    posts: {
      select: { id: true, title: true, createdAt: true },
      orderBy: { createdAt: 'desc' },
      take: 10,
    }
  }
})
 
// ✅ 游标分页（大数据集）
const nextPage = await prisma.post.findMany({
  take: 20,
  skip: 1,
  cursor: { id: lastPostId },
  orderBy: { createdAt: 'desc' },
  select: {
    id: true,
    title: true,
    createdAt: true,
    author: { select: { name: true, avatar: true } }
  }
})

AI 辅助性能优化的工作流：

1. 收集性能数据
   ├── Lighthouse 报告（JSON 格式）
   ├── Bundle 分析报告
   ├── 慢查询日志
   └── API 响应时间统计

2. 让 AI 分析瓶颈
   ├── 提供性能数据
   ├── 让 AI 识别最大的性能瓶颈
   ├── 让 AI 按影响程度排序
   └── 让 AI 提供具体的优化建议

3. 执行优化
   ├── 按优先级逐个优化
   ├── 每次优化后重新测量
   ├── 记录优化前后的数据对比
   └── 确保优化不引入新问题

4. 验证结果
   ├── 重新运行 Lighthouse
   ├── 对比优化前后的分数
   ├── 确认 Core Web Vitals 达标
   └── 在真实设备上验证

请分析以下性能数据，找出最大的瓶颈：

Lighthouse 报告摘要：
- Performance 分数：[N]
- LCP：[N]s（目标 < 2s）
- INP：[N]ms（目标 < 150ms）
- CLS：[N]（目标 < 0.05）
- Total Blocking Time：[N]ms
- Speed Index：[N]s

Bundle 体积：
- 总体积：[N]KB（gzip 后）
- 最大 chunk：[名称] [N]KB
- 首屏 JS：[N]KB

已知的慢操作：
[列出已知的慢 API 或慢页面]

技术栈：[Next.js / Vite / etc.]

请：
1. 识别 Top 3 性能瓶颈
2. 为每个瓶颈提供具体的优化方案
3. 预估每个优化的影响程度
4. 按"投入产出比"排序优化建议
5. 提供可直接使用的代码修改

请优化以下数据库查询：

当前查询代码：
[粘贴 Prisma/Drizzle/SQL 查询代码]

查询执行时间：[N]ms
数据量：约 [N] 条记录
使用场景：[描述这个查询在哪里使用]

当前索引：
[列出相关表的索引]

请：
1. 分析查询的性能问题
2. 建议需要添加的索引
3. 提供优化后的查询代码
4. 如果适合，建议缓存策略
5. 预估优化后的执行时间

发布准备清单总览：

Day 4 上午：文档准备
├── README.md（项目说明）
├── CHANGELOG.md（版本记录）
├── LICENSE（开源许可证，如适用）
├── CONTRIBUTING.md（贡献指南，如适用）
└── 隐私政策 + 服务条款

Day 4 下午：视觉资产
├── 产品截图（桌面端 + 移动端）
├── 演示视频（60-90 秒）
├── Logo 和品牌资产
├── Open Graph 图片（社交分享预览）
└── Favicon 和 App Icon

Day 5 上午：Landing Page 最终优化
├── 文案打磨
├── CTA 优化
├── SEO 优化
├── 性能验证
└── 社交分享预览测试

Day 5 下午：发布平台准备
├── ProductHunt 页面准备
├── Hacker News 帖子草稿
├── Twitter/X 发布线程
├── Reddit 帖子草稿
└── 邮件通知模板

# README.md 模板
 
## [产品名] — [一句话描述]
 
[一段话描述产品解决什么问题，为谁解决]
 
[![ProductHunt](badge-url)](ph-url)
[![License](badge-url)](license-url)
 
### ✨ 核心功能
 
- 🚀 **功能 1**：一句话描述
- 🎯 **功能 2**：一句话描述
- 🔒 **功能 3**：一句话描述
 
### 📸 截图
 
[产品截图，桌面端 + 移动端]
 
### 🚀 快速开始
 
#### 前置条件
- Node.js 20+
- pnpm 9+
 
#### 安装
 
```bash
git clone https://github.com/you/project.git
cd project
pnpm install
cp .env.example .env.local
pnpm dev

#### 步骤 2：编写 CHANGELOG.md（30 分钟）

```markdown
# CHANGELOG.md 模板

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).

## [1.0.0] - 2026-XX-XX

### Added
- 用户注册和登录（GitHub OAuth + 邮箱密码）
- Dashboard 仪表板（统计卡片 + 最近活动）
- 核心功能 A（简要描述）
- 核心功能 B（简要描述）
- 支付集成（Stripe，支持月付/年付）
- 邮件通知（审查完成通知 + 每周摘要）
- 响应式设计（桌面端 + 移动端）
- 暗色模式支持

### Security
- 所有 API 端点需要认证
- 输入验证（Zod schema）
- CSRF 保护
- Rate limiting

# 用 AI 从 Git 历史生成 CHANGELOG
# 提供 git log 给 AI，让它整理成 CHANGELOG 格式
 
git log --oneline --since="4 weeks ago" > /tmp/git-log.txt
# 然后将内容提供给 AI 整理

产品截图清单：

必需截图（5-8 张）：
├── 1. Hero 截图：产品最核心的界面（桌面端全屏）
├── 2. Dashboard 截图：数据展示界面
├── 3. 核心功能截图 1：最重要的功能在使用中
├── 4. 核心功能截图 2：第二重要的功能
├── 5. 移动端截图：手机上的界面
├── 6. 设置页面截图：展示可配置性
└── 7. 暗色模式截图（如果支持）

截图规格：
├── 桌面端：1920×1080 或 2560×1440
├── 移动端：375×812（iPhone）或 390×844
├── 格式：PNG（清晰）或 WebP（体积小）
├── 背景：使用渐变背景或 mockup 框架
└── 标注：可以添加简短的功能说明文字

截图美化技巧：
├── 使用 CleanShot X 或 Screenshot.rocks 添加设备框架
├── 使用 Canva 添加渐变背景和文字标注
├── 确保截图中有真实的示例数据（不是空状态）
├── 避免截图中出现个人信息或敏感数据
└── 保持截图风格一致（相同的背景色、字体、间距）

用 AI 生成截图中的示例数据：

提示词：
"请为一个 [产品类型] 生成逼真的示例数据，用于产品截图。
需要：
- 5 个用户名（英文，看起来真实）
- 10 条示例记录（与产品功能相关）
- 统计数据（看起来合理的数字）
- 避免使用 'test'、'example'、'demo' 等词
- 数据要看起来像真实使用中的产品"

演示视频制作流程：

1. 写脚本（15 分钟）
   ├── 开头（10 秒）：一句话说明产品解决什么问题
   ├── 演示（50-60 秒）：展示 3-4 个核心功能
   ├── 结尾（10 秒）：CTA（"立即试用"）
   └── 总时长：60-90 秒

2. 准备环境（10 分钟）
   ├── 清理浏览器（关闭无关标签、隐藏书签栏）
   ├── 设置分辨率（1920×1080）
   ├── 使用示例数据填充产品
   ├── 关闭通知（勿扰模式）
   └── 准备好要展示的操作流程

3. 录制（30 分钟，多次尝试）
   ├── 使用 Screen Studio（Mac）或 OBS（跨平台）
   ├── 录制 2-3 次，选最好的
   ├── 操作要流畅，不要犹豫
   ├── 鼠标移动要平滑
   └── 每个功能展示后短暂停顿

4. 后期处理（30 分钟）
   ├── 剪掉多余的等待时间
   ├── 添加文字标注（功能名称）
   ├── 添加背景音乐（可选，使用免版税音乐）
   ├── 添加片头和片尾
   ├── 导出：MP4，1080p，30fps
   └── 压缩到 < 50MB（ProductHunt 限制）

视频脚本模板：
"[产品名] 让你 [核心价值]。
看看它是怎么工作的：
首先，[操作 1]...
然后，[操作 2]...
最后，[操作 3]...
就这么简单。立即在 [网址] 开始使用。"

品牌资产清单：

□ Open Graph 图片（社交分享预览）
  ├── 尺寸：1200×630px
  ├── 内容：产品名 + 一句话描述 + 截图
  ├── 用于：Twitter/X、Facebook、LinkedIn 分享预览
  └── 工具：Canva / Figma

□ Favicon
  ├── favicon.ico（16×16, 32×32）
  ├── apple-touch-icon.png（180×180）
  ├── android-chrome-192x192.png
  ├── android-chrome-512x512.png
  └── 工具：realfavicongenerator.net

□ Logo 变体
  ├── 全彩 Logo（SVG + PNG）
  ├── 白色 Logo（用于深色背景）
  ├── 图标版 Logo（正方形，用于头像）
  └── 工具：Figma / Canva

□ ProductHunt 资产
  ├── Gallery 图片：最多 8 张（1270×760px 推荐）
  ├── Thumbnail：240×240px
  ├── Maker 头像：清晰的个人照片
  └── 视频：MP4，< 50MB

Landing Page 结构（2026 高转化模板）：

1. Hero Section
   ├── 标题：一句话说明产品价值（不超过 10 个词）
   ├── 副标题：解释如何实现（1-2 句话）
   ├── CTA 按钮：明确的行动号召（"免费开始" / "立即试用"）
   ├── 社交证明：用户数、评分、知名客户 Logo
   └── Hero 图片/视频：产品截图或演示视频

2. Problem Section
   ├── 描述目标用户的痛点（3 个）
   ├── 让用户产生共鸣："你是否也遇到过..."
   └── 过渡到解决方案

3. Solution / Features Section
   ├── 3-5 个核心功能
   ├── 每个功能：图标 + 标题 + 一句话描述 + 截图
   └── 强调差异化优势

4. Social Proof Section
   ├── 用户评价（如果有）
   ├── 使用数据（"已有 X 用户使用"）
   ├── 媒体报道（如果有）
   └── 集成伙伴 Logo

5. Pricing Section
   ├── 2-3 个定价方案
   ├── 突出推荐方案
   ├── 免费试用 CTA
   └── FAQ（常见问题）

6. Final CTA Section
   ├── 重复核心价值主张
   ├── 大按钮 CTA
   └── 降低风险："免费试用，无需信用卡"

7. Footer
   ├── 链接：隐私政策、服务条款、联系方式
   ├── 社交媒体链接
   └── 版权信息

Landing Page 文案优化原则：

1. 标题要具体，不要模糊
   ❌ "更好的工作方式"
   ✅ "用 AI 在 5 分钟内完成代码审查"

2. 用数字说话
   ❌ "节省大量时间"
   ✅ "平均节省 3 小时/周的代码审查时间"

3. 面向用户利益，不是功能
   ❌ "支持 15 种编程语言"
   ✅ "无论你用什么语言，都能立即开始"

4. CTA 要明确
   ❌ "了解更多"
   ✅ "免费开始 — 无需信用卡"

5. 减少摩擦
   ├── "30 秒注册"
   ├── "无需信用卡"
   ├── "随时取消"
   └── "免费方案永久可用"

SEO 优化清单：

□ Meta 标签
  ├── <title>：包含核心关键词，< 60 字符
  ├── <meta name="description">：包含价值主张，< 160 字符
  ├── <meta property="og:title">：社交分享标题
  ├── <meta property="og:description">：社交分享描述
  ├── <meta property="og:image">：社交分享图片（1200×630）
  ├── <meta name="twitter:card">：summary_large_image
  └── <link rel="canonical">：规范 URL

□ 结构化数据
  ├── Organization schema
  ├── Product schema（如果是 SaaS）
  ├── FAQ schema（如果有 FAQ 部分）
  └── 使用 JSON-LD 格式

□ 技术 SEO
  ├── sitemap.xml 已生成
  ├── robots.txt 配置正确
  ├── 所有页面可被爬虫访问
  ├── 移动端友好（响应式设计）
  ├── HTTPS 已启用
  ├── 页面加载速度 < 2 秒
  └── 无死链（404 页面）

□ 内容 SEO
  ├── H1 标签包含核心关键词
  ├── 图片有 alt 属性
  ├── 内部链接结构合理
  └── URL 结构清晰（/pricing, /features, /docs）

// Next.js SEO 配置示例
// app/layout.tsx
import type { Metadata } from 'next'
 
export const metadata: Metadata = {
  title: 'CodeLens — AI 代码审查，5 分钟搞定',
  description:
    '用 AI 自动审查 Pull Request，发现 Bug、安全漏洞和代码异味。支持 15+ 语言，零配置开始。',
  openGraph: {
    title: 'CodeLens — AI 代码审查',
    description: '用 AI 自动审查 Pull Request，5 分钟搞定。',
    url: 'https://codelens.dev',
    siteName: 'CodeLens',
    images: [
      {
        url: 'https://codelens.dev/og-image.png',
        width: 1200,
        height: 630,
        alt: 'CodeLens 产品截图',
      },
    ],
    locale: 'zh_CN',
    type: 'website',
  },
  twitter: {
    card: 'summary_large_image',
    title: 'CodeLens — AI 代码审查',
    description: '用 AI 自动审查 Pull Request，5 分钟搞定。',
    images: ['https://codelens.dev/og-image.png'],
  },
  robots: {
    index: true,
    follow: true,
  },
}

ProductHunt 发布准备清单：

□ 提前 2 周
  ├── 创建 ProductHunt Maker 账号
  ├── 创建 Ship 预发布页面（收集关注者）
  ├── 在社交媒体预告即将发布
  └── 联系 5-10 个可能支持你的人

□ 发布前 1 天
  ├── 准备 ProductHunt 页面内容：
  │   ├── Tagline：一句话描述（< 60 字符）
  │   ├── Description：详细描述（2-3 段）
  │   ├── Gallery：5-8 张截图 + 演示视频
  │   ├── Topics：选择 3-5 个相关话题
  │   ├── Links：产品 URL、GitHub（如开源）
  │   └── Maker Comment：第一条评论（你的故事）
  ├── 准备 Maker Comment 草稿
  ├── 准备社交媒体发布内容
  └── 设置闹钟（太平洋时间 12:01 AM 发布）

□ 发布日
  ├── 太平洋时间 12:01 AM 发布
  ├── 立即发布 Maker Comment
  ├── 通知邮件列表和社交媒体
  ├── 全天回复评论和问题
  ├── 监控产品状态和错误日志
  └── 记录数据：访问量、注册数、反馈

□ 发布后
  ├── 感谢所有支持者
  ├── 整理用户反馈
  ├── 修复紧急 Bug
  └── 写发布复盘

ProductHunt Tagline 示例：

❌ 差的 Tagline：
├── "一个很棒的工具"（太模糊）
├── "AI 驱动的解决方案"（没有具体价值）
└── "下一代平台"（空洞）

✅ 好的 Tagline：
├── "AI code reviews in 5 minutes, not 5 hours"
├── "Ship faster with automated PR feedback"
└── "Zero-config code review for small teams"

公式：[动词] + [具体结果] + [差异化]

Maker Comment 模板：

"Hi Product Hunt! 👋

I'm [你的名字], the solo founder of [产品名].

**Why I built this:**
[1-2 句话描述你遇到的问题]

**What it does:**
[2-3 句话描述产品如何解决问题]

**What makes it different:**
- [差异化 1]
- [差异化 2]
- [差异化 3]

**Built with:**
[技术栈简述]

**Special offer for PH:**
[ProductHunt 专属优惠，如果有]

I'd love to hear your feedback! Happy to answer any questions. 🙏"

Hacker News Show HN 准备：

帖子格式：
Show HN: [产品名] – [一句话描述]

帖子内容（简洁！HN 用户不喜欢营销语言）：
"[产品名] 是 [简短描述]。

我做这个是因为 [真实的动机/痛点]。

技术栈：[列出关键技术]

[产品 URL]

欢迎反馈和建议。"

HN 发布技巧：
├── 时间：美东时间上午 8-10 点（工作日）
├── 标题：技术性、具体、不夸张
├── 内容：简洁、真诚、技术导向
├── 回复：快速、详细、谦虚地回复每条评论
├── 避免：营销语言、求赞、过度推销
└── 关键：HN 社区重视技术深度和真诚度

Show HN 帖子存活数据（2025 研究）：
├── 51% 的帖子在 30 分钟内从首页消失
├── 只有 1% 的帖子能在首页停留一周
├── 关键：前 1-2 小时的互动决定帖子命运
└── 策略：发布后全力回复评论，保持活跃度

Twitter/X 发布线程模板：

Tweet 1（Hook）：
"我用 6 周时间，一个人做了 [产品名]。

从想法到上线，全程用 AI 辅助。

这是我的故事 🧵"

Tweet 2（问题）：
"[描述你遇到的问题]

现有的解决方案要么太贵，要么太复杂。

我决定自己做一个。"

Tweet 3（解决方案）：
"[产品名] 可以 [核心功能]。

✅ [优势 1]
✅ [优势 2]
✅ [优势 3]

[产品截图]"

Tweet 4（技术栈）：
"技术栈：
- [前端]
- [后端]
- [数据库]
- [AI 工具]

全程 Spec-Driven 开发，AI 辅助编码。"

Tweet 5（数据）：
"一些数据：
- 开发时间：6 周
- 代码行数：~[N]K 行
- 测试覆盖率：[N]%
- 月成本：$[N]"

Tweet 6（CTA）：
"现在可以免费试用 👇

[产品 URL]

如果觉得有用，转发让更多人看到 🙏

#buildinpublic #indiehacker"

Reddit 发布策略：

适合的 Subreddit：
├── r/SideProject — 展示个人项目
├── r/startups — 创业相关讨论
├── r/webdev — Web 开发相关
├── r/programming — 编程相关（技术深度要求高）
├── r/[你的垂直领域] — 目标用户聚集的社区
└── r/indiehackers — 独立开发者社区

Reddit 帖子原则：
├── 先贡献价值，再推广产品
├── 分享你的构建过程和学到的经验
├── 真诚地寻求反馈，不是单纯推销
├── 回复每一条评论
└── 遵守每个 subreddit 的规则

发布通知邮件模板：

主题：[产品名] 正式上线了！🚀

正文：

Hi [名字],

感谢你之前的关注！[产品名] 今天正式上线了。

[产品名] 可以帮你 [核心价值]：

✅ [功能 1]
✅ [功能 2]
✅ [功能 3]

🎁 作为早期关注者，你可以享受 [专属优惠]。

👉 立即试用：[产品 URL]

如果你觉得有用，希望你能：
- 在 ProductHunt 上给我们投票：[PH URL]
- 分享给可能需要的朋友

有任何问题或建议，直接回复这封邮件即可。

谢谢！
[你的名字]

请为我的项目生成一个高质量的 README.md：

项目名称：[名称]
一句话描述：[描述]
核心功能：
1. [功能 1]
2. [功能 2]
3. [功能 3]

技术栈：[列出技术栈]
安装步骤：[列出安装命令]
环境变量：[列出需要的环境变量]
许可证：[MIT / Apache 2.0 / etc.]

要求：
1. 简洁但完整
2. 包含 badge（如果适用）
3. 包含截图占位符
4. 快速开始部分 3 步以内
5. 使用 emoji 增加可读性
6. 英文编写（面向国际用户）

请为我的产品生成 ProductHunt 发布内容：

产品名称：[名称]
核心价值：[一句话]
目标用户：[描述]
核心功能：
1. [功能 1]
2. [功能 2]
3. [功能 3]
差异化优势：[与竞品的区别]
技术栈：[简述]
我的背景：[简述]

请生成：
1. Tagline（< 60 字符，英文）
2. Description（2-3 段，英文）
3. Maker Comment（第一条评论，英文，真诚不营销）
4. 5 个 Topic 建议
5. Twitter 发布线程（6 条推文）

请优化我的 Landing Page 文案：

当前文案：
[粘贴当前文案]

产品信息：
- 产品名：[名称]
- 目标用户：[描述]
- 核心价值：[一句话]
- 竞品：[列出 2-3 个竞品]
- 差异化：[与竞品的区别]

优化要求：
1. 标题要具体，包含数字或具体结果
2. 副标题解释"如何实现"
3. CTA 按钮文案要有行动力
4. 功能描述面向用户利益而非技术特性
5. 添加社交证明元素
6. 减少摩擦（"免费"、"无需信用卡"、"30 秒注册"）
7. 保持简洁，每段不超过 3 句话

09:00-09:15  评估测试覆盖率
├── 运行 pnpm test:run --coverage
├── 结果：整体覆盖率 58%，核心逻辑 65%
├── 识别低覆盖率文件：
│   ├── review-engine.ts：45%（AI 审查核心逻辑）
│   ├── webhook-handler.ts：52%（GitHub Webhook 处理）
│   ├── billing.ts：48%（Stripe 支付逻辑）
│   └── diff-parser.ts：60%（代码 diff 解析）
└── 制定补充计划：优先补充核心逻辑测试

09:15-11:00  补充单元测试
├── review-engine.ts：
│   ├── 测试 AI 响应解析的各种格式
│   ├── 测试超时和重试逻辑
│   ├── 测试 token 限制处理
│   └── 覆盖率提升到 88%
├── webhook-handler.ts：
│   ├── 测试签名验证（有效/无效/缺失）
│   ├── 测试各种 GitHub 事件类型
│   ├── 测试并发 Webhook 处理
│   └── 覆盖率提升到 85%
└── 发现 1 个 Bug：Webhook 签名验证在 payload 包含
    Unicode 字符时失败 → 立即修复

11:00-12:00  PBT 属性测试
├── diff-parser.ts：
│   ├── 属性：解析后的行数 = 原始 diff 的行数
│   ├── 属性：所有解析结果的文件路径非空
│   ├── 属性：添加行数 + 删除行数 = 总变更行数
│   └── 发现 Bug：空 diff 导致解析器崩溃 → 修复
├── billing.ts：
│   ├── 属性：折扣后价格 <= 原价
│   ├── 属性：年付价格 < 12 × 月付价格
│   └── 属性：免费方案的价格始终为 0
└── 所有 PBT 通过，覆盖率提升到 72%

09:00-11:00  集成测试
├── 完整的 PR 审查流程测试：
│   ├── 模拟 GitHub Webhook → 触发审查 → 生成评论 → 回写 GitHub
│   ├── 测试大 PR（100+ 文件）的处理
│   ├── 测试审查失败时的错误恢复
│   └── 测试并发审查请求
├── 支付流程集成测试：
│   ├── 模拟 Stripe Webhook → 更新订阅状态
│   ├── 测试订阅过期 → 降级到免费方案
│   └── 测试支付失败 → 重试通知
└── 发现 2 个 Bug：
    ├── Bug 1：并发审查时数据库死锁 → 添加重试逻辑
    └── Bug 2：订阅过期后仍能发起审查 → 添加权限检查

11:00-12:00  E2E 测试
├── 流程 1：新用户注册 → 连接 GitHub → 首次审查
├── 流程 2：查看审查结果 → 标记已解决 → 查看统计
├── 流程 3：升级到付费方案 → 验证配额增加
├── 流程 4：移动端完整操作流程
└── 所有 E2E 测试通过

13:00-15:00  手动测试
├── 视觉检查：发现 3 个 UI 问题
│   ├── 暗色模式下代码高亮颜色对比度不足
│   ├── 移动端侧边栏关闭按钮太小
│   └── 长文件名在审查列表中溢出
├── 交互检查：发现 1 个问题
│   └── 快速连续点击"开始审查"会重复提交
├── 内容检查：发现 2 个问题
│   ├── 404 页面缺少返回首页链接
│   └── 邮件模板中的 Logo 在 Outlook 中不显示
└── 全部修复完成

15:00-16:00  质量门检查
├── TypeScript 编译：✅ 零错误
├── ESLint：✅ 零警告
├── 单元测试：✅ 156 个测试全部通过
├── PBT：✅ 12 个属性测试全部通过
├── E2E：✅ 4 个流程全部通过
├── 覆盖率：✅ 整体 76%，核心逻辑 91%
├── 构建：✅ 成功，无警告
└── 结论：所有质量门通过 ✅

09:00-09:30  基线测量
├── Lighthouse 分数：
│   ├── 首页：82（LCP 2.8s，INP 190ms，CLS 0.03）
│   ├── Dashboard：65（LCP 4.2s，INP 280ms，CLS 0.18）
│   └── 定价页：91（LCP 1.6s，INP 110ms，CLS 0.01）
├── Bundle 体积：520KB（gzip 后）
│   ├── 最大 chunk：vendor.js 310KB
│   └── 首屏 JS：210KB
└── API 响应时间：
    ├── 审查列表：450ms（慢！）
    ├── 审查详情：280ms
    └── Dashboard 统计：380ms

09:30-11:00  前端性能优化
├── 图片优化：
│   ├── Hero 图片转 WebP，体积减少 60%
│   ├── 添加 priority 属性到首屏图片
│   └── LCP 改善：2.8s → 1.9s ✅
├── 代码分割：
│   ├── 代码编辑器组件动态 import
│   ├── 图表库动态 import
│   └── 首屏 JS：210KB → 140KB ✅
├── CLS 修复：
│   ├── Dashboard 统计卡片添加 skeleton
│   ├── 审查列表添加固定高度占位
│   └── CLS：0.18 → 0.04 ✅
└── 字体优化：
    ├── 添加 font-display: swap
    ├── 预加载关键字体
    └── LCP 进一步改善

11:00-12:00  后端性能优化
├── 审查列表 API：
│   ├── 添加数据库索引（user_id + created_at）
│   ├── 限制返回字段（去掉 review_content 大字段）
│   ├── 添加 Redis 缓存（TTL 2 分钟）
│   └── 响应时间：450ms → 85ms ✅
├── Dashboard 统计 API：
│   ├── 预计算统计数据（每小时更新）
│   ├── 添加缓存
│   └── 响应时间：380ms → 45ms ✅
└── 审查详情 API：
    ├── 使用 select 限制返回字段
    └── 响应时间：280ms → 120ms ✅

13:00-14:00  优化后验证
├── Lighthouse 分数（优化后）：
│   ├── 首页：95（LCP 1.6s，INP 130ms，CLS 0.01）✅
│   ├── Dashboard：88（LCP 2.1s，INP 160ms，CLS 0.04）✅
│   └── 定价页：97（LCP 1.2s，INP 90ms，CLS 0.00）✅
├── Bundle 体积：380KB（gzip 后）→ 减少 27% ✅
└── 所有 API 响应时间 < 200ms ✅

Day 4 上午：文档
├── README.md：用 AI 生成初稿 → 手动打磨 → 添加截图
├── CHANGELOG.md：从 Git 历史生成 → 整理格式
├── 隐私政策 + 服务条款：用 AI 生成模板 → 法律审查
└── API 文档：自动生成（从 TypeScript 类型）

Day 4 下午：视觉资产
├── 产品截图：8 张（桌面 5 + 移动 3）
│   ├── 使用 CleanShot X 截图
│   ├── 使用 Canva 添加背景和标注
│   └── 填充逼真的示例数据
├── 演示视频：75 秒
│   ├── 用 Screen Studio 录制
│   ├── 展示：连接 GitHub → 自动审查 → 查看结果
│   └── 添加文字标注和背景音乐
├── OG 图片：1200×630px
└── Favicon 和 App Icon

Day 5 上午：Landing Page
├── 文案优化：
│   ├── 标题："AI Code Reviews in 5 Minutes, Not 5 Hours"
│   ├── 副标题："Automated PR feedback that catches bugs,
│   │   security issues, and code smells. Zero config."
│   └── CTA："Start Free — No Credit Card Required"
├── SEO 优化：meta 标签、结构化数据、sitemap
├── 性能验证：Lighthouse 97 分
└── 社交分享预览测试：Twitter、LinkedIn、Slack

Day 5 下午：发布平台
├── ProductHunt 页面：
│   ├── Tagline："AI code reviews in 5 min, not 5 hours"
│   ├── Description：3 段描述
│   ├── Gallery：8 张截图 + 演示视频
│   ├── Maker Comment：草稿完成
│   └── 发布时间：下周二太平洋时间 12:01 AM
├── Hacker News Show HN 帖子草稿
├── Twitter 发布线程（6 条推文）
├── Reddit 帖子草稿（r/webdev, r/SideProject）
├── 邮件通知模板（给 127 个早期关注者）
└── 所有发布材料准备完毕 ✅

第 5 周成果总结：

测试成果：
├── 发现并修复 8 个 Bug（3 个严重、5 个轻微）
├── 测试覆盖率：58% → 76%（核心逻辑 91%）
├── 156 个单元测试 + 12 个 PBT + 4 个 E2E
└── 所有质量门通过

性能优化成果：
├── Lighthouse 分数：65-82 → 88-97
├── LCP：2.8-4.2s → 1.2-2.1s
├── Bundle 体积：520KB → 380KB（-27%）
├── API 响应时间：280-450ms → 45-120ms
└── 所有 Core Web Vitals 达标

发布准备成果：
├── README.md + CHANGELOG.md
├── 8 张产品截图 + 75 秒演示视频
├── Landing Page 优化完成（Lighthouse 97）
├── ProductHunt + HN + Twitter + Reddit 材料就绪
├── 127 个早期关注者的邮件通知就绪
└── 准备好下周发布

关键经验：
├── PBT 发现了 2 个手动测试不会发现的边界 Bug
├── 性能优化的 80% 收益来自 20% 的改动（图片 + 索引 + 缓存）
├── AI 辅助生成发布材料节省了约 4 小时
├── 手动测试仍然不可替代（发现了 6 个 UI/UX 问题）
└── 质量门机制确保了发布信心