AI协作开发方法论¶

第一代（2020前）：手写所有代码
  → 核心能力：编码速度、语言精通、调试能力
  → 产出瓶颈：个人打字和思考速度

第二代（2020-2025）：AI辅助编码
  → 核心能力：使用Copilot/Cursor补全代码
  → 产出瓶颈：仍然是逐行写代码的模式，AI只是加速器

第三代（2026+）：AI协作开发
  → 核心能力：需求拆解→架构设计→AI指令→质量审查→系统集成
  → 产出瓶颈：架构决策和质量把控能力
  → 关键区别：开发者是"导演"，AI是"演员团队"

┌─────────────────────────────────────────┐
│  L4: 系统架构决策                        │  ← 人类不可替代
│    哪些模块用什么技术栈？如何拆分？        │
├─────────────────────────────────────────┤
│  L3: 需求→任务分解                       │  ← 核心竞争力
│    把模糊需求拆解为AI可执行的精确任务       │
├─────────────────────────────────────────┤
│  L2: AI输出的质量审查                    │  ← 必备能力
│    安全漏洞？性能问题？边界case？可维护性？ │
├─────────────────────────────────────────┤
│  L1: AI工具使用                          │  ← 基础能力
│    Prompt工程/Context管理/工具选择         │
├─────────────────────────────────────────┤
│  L0: 手写代码                            │  ← 保底能力
│    面试笔试/AI不可用时/核心算法             │
└─────────────────────────────────────────┘

关键洞察：L0仍然必须要会（面试手撕代码不会消失），
但日常工作的竞争力主要在L2-L4。

D - Decompose（分解）：将需求拆解为独立、可测试的子任务
R - Route（路由）：判断每个子任务由AI生成还是手写
G - Generate（生成）：编写精确的AI指令，生成代码
I - Inspect（审查）：审查AI输出的正确性、安全性、性能
C - Compose（集成）：将各模块组合，确保系统整体一致

任务：[简短描述]
输入：[数据类型/格式/来源]
输出：[数据类型/格式/去向]
约束：[性能要求/技术栈限制/安全要求]
验收标准：[怎么算完成]
依赖：[需要哪些已有模块/外部服务]

1. [函数级] 文档加载器 — 输入: 文件路径, 输出: 文本列表
   约束: 支持PDF/DOCX/TXT, 验收: 10个测试文件全部正确加载

2. [函数级] 文本分块器 — 输入: 长文本, 输出: 分块列表
   约束: 支持固定大小/语义分块, 验收: 分块长度符合配置

3. [模块级] 向量存储封装 — 输入: 文本块, 输出: 向量索引
   约束: 使用Chroma, 支持增删查, 验收: CRUD操作测试通过

4. [模块级] 检索+重排管道 — 输入: 查询, 输出: 排序后的文档
   约束: 混合检索(BM25+向量), 验收: MRR@10 > 0.7

5. [特性级] 生成模块 — 输入: 查询+相关文档, 输出: 回答
   约束: 流式输出, 引用来源, 验收: 人工评估准确率>85%

6. [特性级] FastAPI服务封装 — 输入: HTTP请求, 输出: 流式响应
   约束: 异步, 健康检查, 验收: 压测100并发正常

AI做更好的任务（优先让AI做）：
  ✅ CRUD代码/样板代码
  ✅ 单元测试生成
  ✅ 数据转换/格式化
  ✅ API封装/SDK调用
  ✅ 配置文件/YAML/Dockerfile
  ✅ 文档/注释/README
  ✅ 常见算法实现（排序/搜索/LRU）
  ✅ 正则表达式编写
  ✅ SQL查询编写

人做更好的任务（优先自己做）：
  ❌ 涉及核心业务逻辑的架构决策
  ❌ 安全关键路径（认证/授权/加密）
  ❌ 需要深入理解业务上下文的逻辑
  ❌ 性能关键路径的微优化
  ❌ 涉及多系统集成点的协调代码
  ❌ AI反复出错且修复成本高于手写的任务

1. 角色设定（可选）：你是一个[领域]的高级工程师
2. 任务描述：请实现[功能]
3. 技术约束：使用[语言/框架/版本]
4. 输入输出规范：输入是[类型/格式], 输出是[类型/格式]
5. 代码风格要求：[命名规范/类型注解/注释要求]
6. 边界条件：需要处理[空输入/异常/超时]
7. 参考示例（可选）：类似于[已有模块/代码片段]
8. 不要做什么（负面约束）：不要用[某个库/某种模式]

上下文 = AI生成质量的决定性因素

方法1: 文件引用
  "@file:src/models/user.py 请基于这个User模型写CRUD API"

方法2: 项目规范
  将代码规范/架构约定写入项目根目录的规则文件中
  AI工具会自动读取这些文件作为上下文

方法3: 渐进式上下文
  先让AI生成接口定义 → 确认后 → 再生成实现
  避免一次性给太多信息导致AI"分心"

方法4: 示例驱动
  "请按照src/services/user_service.py的模式，写一个order_service.py"
  AI会自动对齐代码风格和设计模式

□ 正确性
  - 逻辑是否正确？边界条件处理是否完整？
  - 手动trace核心路径（至少一个正常case + 一个边界case）

□ 安全性
  - SQL注入？XSS？命令注入？
  - 敏感数据是否硬编码？
  - 认证/授权是否正确？

□ 性能
  - 时间复杂度是否合理？有无明显的O(n²)可优化？
  - 是否有不必要的网络调用/数据库查询？
  - 大数据量下会不会OOM？

□ 可维护性
  - 命名是否清晰？是否符合项目规范？
  - 是否过度设计（AI喜欢加不必要的抽象层）？
  - 是否有重复代码可以复用已有模块？

□ AI特有问题
  - 是否引用了不存在的库/API？（幻觉）
  - 是否使用了过时的API版本？
  - 是否有看起来正确但语义错误的代码？
  - 错误处理是否过度宽泛（catch Exception pass）？

集成检查项：
  1. 接口一致性：各模块之间的输入输出类型是否匹配？
  2. 错误传播：模块A的异常是否被模块B正确处理？
  3. 配置统一：所有模块是否使用同一份配置？
  4. 测试覆盖：集成测试是否覆盖关键路径？
  5. 性能基线：端到端延迟是否满足要求？

推荐流程：
  1. 手动写: 项目结构 + 配置文件 + 核心接口定义
  2. AI生成: 基于接口定义生成各模块实现
  3. 手动写: 核心业务逻辑 + 安全关键代码
  4. AI生成: 测试用例 + 文档 + CI/CD配置
  5. 人工审查: 全量代码review + 集成测试

项目结构让AI生成时的注意事项:
  - 先确定好架构再让AI填充，而不是让AI决定架构
  - 提供已有项目作为模板参考
  - 分模块逐步生成，不要一次性生成整个项目

推荐流程：
  1. 读懂现有代码（可以让AI帮忙解释）
  2. 确定修改方案（人决策）
  3. 让AI在已有代码基础上添加/修改
  4. 重点审查：改动是否影响了已有功能？
  5. 跑已有测试 + 新增测试

推荐流程：
  1. 复现问题，收集错误信息
  2. 将错误栈 + 相关代码 + 预期行为告诉AI
  3. AI给出诊断和修复方案
  4. 人判断根因是否正确（AI经常修表面不修根因）
  5. 验证修复 + 添加防回归测试

注意: Debug时AI倾向于"打补丁"而非修根因
     → 人需要追问："这个fix为什么能解决问题？根本原因是什么？"

推荐流程：
  1. 明确重构目标（性能？可读性？可扩展性？）
  2. 让AI分析现有代码的问题
  3. 人确定重构策略
  4. 逐步重构，每步都跑测试
  5. AI生成重构前后的对比文档

注意: 大范围重构不要一次性让AI做
     → 分模块/分函数逐步进行，每步验证

初学者推荐:
  Cursor (主力) — 补全 + Agent模式覆盖大部分场景

进阶推荐:
  Cursor (编辑器) + Claude Code (终端Agent)
  — Cursor做日常编码，Claude Code做复杂多文件任务

高级推荐:
  Cursor + Claude Code + 项目级规则文件
  — 完善的上下文工程，AI输出质量最高

场景1: 编码面试中
  面试官: "可以使用AI工具吗？"
  → 大多数2028年面试仍要求手写代码
  → AI协作能力在项目经验环节展示，而非编码环节
  → 手写代码能力(L0)仍然是门槛

场景2: 项目经验环节
  面试官: "这个系统你是怎么开发的？"
  → 正确回答: "我先设计了整体架构和接口定义，
     核心的检索策略和重排逻辑我手写实现，
     CRUD API和测试用例用AI辅助生成后做了审查调整，
     整体开发效率提升了约3倍"
  → 错误回答: "我用AI生成了所有代码" (显得没有深度)

场景3: 系统设计环节
  面试官: "你如何保证AI生成代码的质量？"
  → 展示DRGIC工作流
  → 讲具体案例：哪些部分让AI做，哪些自己做，为什么
  → 提到审查清单、常见AI陷阱

好的表述:
  "设计并实现了XXX系统，核心模块（XX/XX/XX）独立完成，
   辅助模块利用AI协作开发提效3倍，建立了团队级AI编码规范"

不好的表述:
  "使用AI工具完成了XXX系统的开发"  ← 显得缺乏深度
  完全不提AI  ← 2028年不提AI协作开发反而显得落后

团队规范文件（放在项目根目录供AI工具读取）应包含：
  1. 项目概述：系统做什么，核心技术栈
  2. 代码规范：命名约定，目录结构，import顺序
  3. 架构约定：分层结构，模块边界，通信方式
  4. 安全红线：不可硬编码密钥，必须参数验证
  5. 测试要求：覆盖率标准，测试命名规范
  6. AI使用规范：哪些模块允许AI生成，哪些必须人审

PR Review时额外关注：
  □ 是否有AI生成的典型问题（幻觉API/过度设计/乐观路径）
  □ AI生成的代码是否与现有代码风格一致
  □ 是否通过了自动化测试（AI代码更需要测试兜底）
  □ 复杂逻辑处是否有人review过（不能只靠AI审查AI）

核心认知：
  1. AI协作开发是2028年AI工程师的"元能力"
  2. 手写代码能力（L0）仍是面试门槛，不可放弃
  3. 竞争力在L2-L4：需求分解→质量审查→架构决策
  4. DRGIC五步法：Decompose → Route → Generate → Inspect → Compose
  5. 上下文管理是AI输出质量的决定性因素
  6. 面试中展示"有深度的AI协作"而非"全靠AI"

实践建议：
  - 从现在开始，所有学习练习都用AI工具辅助
  - 刻意练习：哪些让AI做，哪些自己做，记录差异
  - 建立个人AI编码规范文件，迭代优化
  - 面试项目中有意识地记录AI协作的决策过程