核心价值: 90% 的开发者用 AI 补全代码。真正的杠杆在于让 AI 成为你的架构师、评审员和调试伙伴。
2.1 重新定义你和 AI 的分工
你的角色转变
传统开发者 → AI 时代开发者
───────────────────────────────────────
写代码 架构决策
调试 Bug 定义问题边界
查文档 评审 AI 输出质量
重复性重构 给 AI 提供上下文
关键认知: AI 是你的高级实习生，你是技术负责人。你负责：
- 确认方向正确（AI 会自信地走错路）
- 把关安全（AI 不会主动考虑 OWASP）
- 维护代码风格一致性（AI 每次风格可能不同）
- 知道什么时候不该用 AI（关键业务逻辑，需要你理解透）
2.2 上下文工程（Context Engineering）
核心原则：垃圾进，垃圾出
AI 的输出质量 = 你给的上下文质量 × 模型能力
标准上下文包（给 AI 的"环境介绍"）：
## 项目背景
[项目名] 是一个 [一句话描述]。
## 技术栈
- Backend: FastAPI + SQLAlchemy 2 (async) + PostgreSQL
- 测试: pytest + asyncio + SQLite/PostgreSQL
- 代码规范: black(格式化) + flake8(lint)
## 关键约定
- 路由层只做参数校验，不含业务逻辑
- 业务逻辑在 services/ 层
- 所有 DB 操作通过 AsyncSession
- 错误用 HTTPException，不用自定义 exception
## 相关文件
[粘贴或 @引用最相关的 2-3 个文件]
## 当前任务
[具体任务描述]
OpenClaw 中的 copilot-instructions.md
这就是 OpenClaw/GitHub Copilot 的"系统提示"——持久上下文文件，位于 .github/copilot-instructions.md。
最佳实践：
# 项目约定
## 架构分层（每次都要提醒 AI）
- app/api/v1/ → 仅路由，不含业务逻辑
- app/services/ → 所有业务逻辑在这里
- app/schemas/ → Pydantic 请求/响应模型
## 禁止行为（防止 AI 做错）
- 禁止在路由中直接操作数据库
- 禁止硬编码任何配置（统一用 config.py）
- 禁止修改 migration 文件已提交的部分
## 命名约定
- Service 函数: {动词}_{资源}_{修饰} e.g. get_user_by_email()
- 路由函数: {资源}_{动作} e.g. snapshot_create()
2.3 Prompt 模式库
模式 1：代码生成（带约束）
在 [文件路径] 中，基于以下约定实现 [功能]：
约束：
- 使用 async/await
- 通过 db: AsyncSession 参数接收数据库会话
- 错误用 HTTPException(status_code=..., detail=...)
- 不要添加我没要求的功能
- 函数签名要与 [相关文件] 中的风格一致
现有相关代码：
[粘贴最相关的函数作为参考，通常 20-50 行就够]
模式 2：代码评审
请评审以下代码，重点检查：
1. 安全问题（SQL 注入、权限绕过、数据泄露）
2. 并发问题（竞争条件、死锁）
3. 性能问题（N+1 查询、缺少索引）
4. 是否符合项目约定（见上方架构说明）
[粘贴代码]
如果发现问题，给出具体的修复建议，不要只说"这里有问题"。
模式 3：调试助手
我在调试以下错误：
[错误信息全文，包括 traceback]
上下文：
- 触发条件：[复现步骤]
- 相关代码：[出错的函数]
- 已尝试过：[你已排除的假设]
请分析最可能的原因（按概率排序），并给出每个假设的验证方法。
不要直接给"把 X 改成 Y"这样的答案，先帮我理解根本原因。
模式 4：架构决策辅助
我在 [项目] 中面临以下技术选型决策：
[描述问题]
我的约束条件：
- 团队规模：1 人
- 技术栈：[现有技术]
- 性能要求：[具体数字]
- 维护成本：越低越好
请给出 2-3 个选项，每个选项包括：
- 优势（在我的约束下）
- 劣势
- "需要承担的技术债务"
- 推荐程度（1-5）
不要推荐最完美的解决方案，推荐最适合我约束条件的解决方案。
模式 5：测试用例生成
为以下函数生成完整的测试用例：
[粘贴函数]
要求：
- 使用 pytest
- 覆盖：正常流 + 所有异常分支 + 边界值
- 使用已有的 conftest.py fixtures（见以下）：[粘贴 conftest 关键部分]
- 测试函数命名格式：test_{被测函数名}_{场景描述}
- 不需要 mock，直接用测试数据库
2.4 GitHub Copilot 实战技巧
内联代码补全最佳实践
让注释驱动补全：
# 根据 project_id 和过滤条件查询广告列表
# 支持按 advertiser_name 模糊搜索
# 按 created_at desc 排序，支持分页
# 返回 (ads: list[Ad], total: int)
async def list_ads_in_project(
→ Copilot 会根据注释生成结构完整的函数
避免 Copilot 的常见错误：
# ❌ 不要这样：Copilot 可能生成同步 ORM 代码
session.query(User).filter(...)
# ✅ 显式标明你要异步
result = await db.execute(select(User).where(...))
代码 Diff 验证（每次 AI 改完都做）
检查清单：
提交前必问：
□ AI 有没有删除我本来就有的注释或类型注解？
□ AI 有没有偷偷修改周边我没让它动的函数？
□ AI 有没有添加不需要的 import？
□ 逻辑是否真的正确，还是"看起来正确"？
□ 有没有硬编码了什么？（密码、URL、配置）
2.5 多 AI 工具协作分工
Market Vault 实际工具栈
| 任务类型 | 首选工具 | 备选 | 原因 |
|---|---|---|---|
| IDE 内代码补全 | GitHub Copilot | — | 上下文感知最好 |
| 复杂架构设计 | Claude Sonnet | GPT-4o | 推理能力强 |
| 文档撰写 | Claude Opus | — | 中英文质量高 |
| 快速原型 | Copilot Chat | — | 速度快 |
| SQL 查询优化 | Claude | ChatGPT | 理解 PostgreSQL 更好 |
| 安全审查 | Claude | — | 更保守 |
| 大文件重构 | Claude | — | 支持更长上下文 |
迭代工作节奏
一个功能的标准流程（约半天）：
08:00 - 设计（Obsidian，不用 AI）
↓ 思考 why，不是 how；写接口文档
09:00 - AI 架构评审（Claude）
↓ 用"苛刻 PM"Prompt 找漏洞
09:30 - 实现（Copilot 主力）
↓ AI 生成初稿，你审查+修改
11:00 - AI 代码评审（Claude）
↓ 安全、并发、性能三问
11:30 - 测试（AI 生成测试，你验证）
↓ make test 全绿
12:00 - 提交
↓ commit message 清晰描述变更
2.6 AI 协作的边界
不要让 AI 独立决策的事
- 数据库设计变更：迁移一旦执行无法撤销
- 删除现有功能：AI 不理解历史需求
- 第三方 API 密钥管理：AI 不知道你的安全策略
- Stripe/支付相关逻辑：金额计算必须人工验证
- 生产环境操作：任何
DROP、DELETE语句
AI 最容易犯的错误（来自实践）
-
过度使用 try-except 吞异常:
# AI 喜欢这样写（隐藏了所有错误） try: result = await do_something() except Exception: return None # ← 隐藏了真正的错误 -
在循环中查询数据库（N+1）:
# AI 生成的代码里常见 for ad in ads: assets = await db.execute(select(Asset).where(...ad.id...)) # 应该用 JOIN 或 IN 子句一次查询 -
忽略用户权限检查:
# AI 生成的代码可能直接查询，没有 owner 验证 snapshot = await db.get(Snapshot, snapshot_id) # 应该加: if snapshot.project.owner_id != current_user.id: raise 403 -
同步代码混入异步上下文:
# 在 async 函数中用同步 IO（会阻塞事件循环） with open(file_path) as f: # ← 应该用 aiofiles data = f.read()
小结与行动项
本章学到:
- AI 是实习生，你是技术负责人
- 上下文质量决定 AI 输出质量（垃圾进垃圾出）
- 5 个常用 Prompt 模式
- 迭代工作节奏（半天完成一个功能）
- AI 的常见错误模式（提前预防）
行动项:
- 为你的项目完善
.github/copilot-instructions.md - 用代码评审 Prompt 检查最近写的一个功能
- 用测试生成 Prompt 补全一个缺少测试的函数
上一章 → 第1章：产品设计与需求管理
下一章 → 第3章：代码编写工程实践