高级工作流

超越单任务单对话，构建更复杂的 AI 协作模式。

并行任务执行

当多个任务之间没有依赖关系时，可以并行执行：

graph TD
    A[需求分析] --> B[任务拆分]
    B --> C[任务 1: 数据库迁移]
    B --> D[任务 2: 后端接口]
    B --> E[任务 3: 前端组件]
    C --> F[集成测试]
    D --> F
    E --> F

实践方式：

• 在不同的 AI 对话中并行处理独立任务
• 每个任务完成后，在集成任务中合并结果
• 集成任务的上下文包含所有子任务的输出摘要

多轮迭代模式

对于复杂功能，采用“方案确认 → 实现 → 验证 → 精化”的多轮模式：

第一轮：只输出设计方案，不写代码
  → 人工确认方案

第二轮：实现核心逻辑（Happy Path）
  → 运行测试，确认基础功能

第三轮：添加错误处理和边界情况
  → 运行完整测试套件

第四轮：性能优化和代码清理
  → 最终验收

长上下文管理

当项目规模增大，单次对话无法容纳所有相关代码时：

策略一：分层上下文

层 1（始终包含）：项目约定、技术栈、核心接口定义
层 2（按需包含）：当前任务相关的模块
层 3（摘要形式）：其他相关模块的接口签名（不含实现）

策略二：上下文压缩

把大文件压缩为接口摘要：

原始文件（500 行）：
  class UserService:
    def create_user(self, email, password) -> User: ...
    def get_user(self, id) -> Optional[User]: ...
    def update_user(self, id, data) -> User: ...
    # ... 其他方法

压缩摘要（10 行）：
  UserService:
    - create_user(email, password) -> User
    - get_user(id) -> Optional[User]
    - update_user(id, data) -> User
    - delete_user(id) -> bool
    - list_users(page, size) -> Page[User]

策略三：对话分段

把长任务分成多个对话段，每段开始时提供前段的关键结论：

对话 1：设计数据模型
  → 结论：确定了 5 个核心表的 Schema

对话 2（携带结论）：实现数据访问层
  → 结论：完成了 Repository 接口定义

对话 3（携带结论）：实现业务逻辑层
  → ...

代码审查工作流

把 AI 纳入 Code Review 流程：

步骤 1：开发者完成实现
步骤 2：AI 审查（安全、性能、可维护性）
步骤 3：开发者处理 AI 发现的问题
步骤 4：人工 Code Review（聚焦业务逻辑和架构）
步骤 5：合并

AI 审查的提示词：

请审查以下代码变更，重点检查：
1. 安全漏洞（SQL 注入、XSS、权限绕过）
2. 性能问题（N+1 查询、不必要的循环）
3. 错误处理遗漏
4. 与项目约定不一致的地方

不需要评价代码风格，只报告实质性问题。
每个问题说明：位置、问题描述、建议修复方式。

代码变更：
[git diff 内容]