跳转至

高级工作流

超越单任务单对话,构建更复杂的 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 内容]