周三的代码瓶颈
周一开了需求会，周二开始动手写代码。到了周三下午，你盯着屏幕上的第200行代码，突然卡住了。
不是技术不会——是思路乱了。
函数越写越长，变量命名开始重复，边界情况忘了处理。你自己 review 一遍，总觉得哪里不对劲，但又说不出来。
这时候你需要的不是另一个人坐在旁边。你需要的是一个能即时回应、不会judge你、永远有耐心的编程搭档。
AI就是你的Pair Programmer。
这个模板不是让你把整个项目丢给AI让它帮你写。而是教你怎么跟AI协作——你负责架构和决策，AI负责出主意、找bug、写样板代码。
核心模板：AI Pair Programmer 全流程
把下面这段复制到 Claude 或 ChatGPT（推荐 Claude，上下文窗口更大）：
你是一位资深的全栈工程师，有10年以上的代码审查和重构经验。现在你是我的结对编程伙伴。
【项目背景】
- 技术栈：[如：React + TypeScript + Node.js + PostgreSQL]
- 项目类型：[如：电商后台管理系统 / SaaS工具 / 内部数据平台]
- 当前阶段：[如：MVP开发 / 功能迭代 / 性能优化]
【我的角色】
[如：前端开发 / 全栈 / 刚接手这个项目的新人]
【当前任务】
[用几句话描述你现在正在做的事情，不用很精确]
【协作规则】
1. 不要直接给我完整代码，除非我明确要求
2. 先帮我分析问题，再给方案
3. 如果我提出的方案有明显缺陷，直接指出并给替代方案
4. 解释你的推理过程，不要只给结论
5. 代码注释用中文，变量命名用英文
6. 如果某个问题有多种解法，列出优缺点让我选
【现在开始】
[描述你的具体问题或卡住的点]
三个高频场景
场景一：写新功能时卡住了
你有一个功能要加，知道大概怎么做，但具体实现时遇到瓶颈。
我正在开发[功能名称]，整体思路是这样的：
[描述你的方案，哪怕只有50%确定]
但我卡在以下几个点：
1. [卡点1]
2. [卡点2]
请帮我：
1. 评估我的方案是否合理，有没有更好的架构选择
2. 针对卡点给出2-3种实现思路
3. 每种思路标注：实现难度（1-5）、维护成本、扩展性
4. 推荐一种最适合的方案，并给出核心代码框架
场景二：Review别人的代码
接手了别人的项目，代码看不懂，不敢动。
以下是我接手的代码文件：
【文件路径】
[src/components/UserProfile.tsx]
【文件内容】
[粘贴代码]
【我知道的背景】
- 这个组件负责用户资料展示和编辑
- 使用了React Hooks
- 数据来自后端API
请帮我：
1. 用一句话概括这段代码在干什么
2. 列出所有我看不懂的逻辑（逐行解释）
3. 找出潜在bug或性能问题
4. 标注哪些地方违反了最佳实践
5. 给出重构建议（如果改动不大就直接重写关键部分）
要求：解释时用类比，不要堆术语。
场景三：写测试用例
写业务代码很顺手，一写测试就头疼。
以下是我写的业务代码：
[粘贴代码]
请帮我：
1. 列出这段代码需要覆盖的所有测试场景
2. 为每个场景写一个测试用例
3. 包含正常路径和异常路径
4. 标注哪些是单元测试、哪些是集成测试
5. 测试代码使用[你的测试框架，如：Jest/Vitest/pytest]
额外要求：
- 重点覆盖边界情况和错误处理
- 如果代码缺少必要的错误处理，先指出再写测试
- 测试命名要有可读性，一看就知道在测什么
快速版（5分钟搞定）
赶时间？用这个精简版：
你是我的编程搭档。我现在在写[技术栈]的[项目类型]。
当前遇到的问题：[一句话描述]
请帮我：
1. 分析问题的根因
2. 给出一个可执行的解决方案
3. 标注可能踩的坑
不要废话，直接给答案。但如果我的方案有明显问题，请先指出。
使用技巧
1. 用Claude做Pair Programmer，用ChatGPT做搜索引擎
Claude的上下文窗口大，适合长时间对话、逐步迭代代码。ChatGPT适合快速查语法、查API文档。别在一个工具里干所有事。
2. 给AI足够的上下文
很多人用Pair Programmer效果差，是因为只扔一行报错信息。给AI的项目结构、技术栈、当前任务描述——信息越多，它的建议越靠谱。
3. 不要让AI替你思考架构
Pair Programmer的作用是帮你加速，不是帮你做决策。架构选型、技术路线、模块划分——这些必须由你来定。AI负责帮你实现和验证。
4. 用"先分析再给代码"的规则
在模板里加一条规则：AI必须先分析问题、列出方案、标注优缺点，然后再给代码。这样你能理解它在想什么，而不是盲目复制粘贴。
5. 每次对话聚焦一个文件/一个函数
别把整个项目丢给AI让它"帮我优化"。聚焦到一个具体的文件或函数，效果会好十倍。小步快跑，一个一个攻克。
6. 让它当你的" Rubber Duck “（橡皮鸭调试法）
有时候你不需要代码，只需要有人听你说完你的思路。把你对问题的理解讲给AI听，它可能会自己发现你逻辑里的漏洞。这就是经典的"橡皮鸭调试法”——你不需要AI回答，你只需要说出来。
效果示例
输入：
我正在开发一个电商后台的订单管理系统，用的是React + TypeScript。
现在要加一个功能：订单列表支持多维度筛选（按状态、时间范围、金额区间、客户标签）。
我的方案是用URL query params传递筛选条件，后端返回过滤后的数据。
但我卡在几个点上：
- 筛选条件太多，UI怎么排布不拥挤？
- 每次改变筛选条件都要重新请求API，体验不好
- 怎么保存用户的筛选偏好？
AI输出：
问题分析： 你的方案方向是对的——URL query params做筛选条件是标准做法。但三个卡点确实需要仔细设计。
UI排布建议：
- 用折叠面板：常用筛选（状态、时间）展开，高级筛选（金额、标签）收起
- 每个筛选器用Tag形式展示已选条件，点击×可移除
- 底部固定"重置"和"应用"按钮
防抖优化：
- 用useDebounceHook包装筛选条件的变化
- 用户停止操作500ms后再发请求
- 加一个Loading状态防止重复请求
保存偏好：
- 用localStorage存当前筛选条件
- 页面加载时读取并恢复
- 提供一个"保存为预设"功能，让用户自定义命名
核心代码框架：
// hooks/useOrderFilters.ts
import { useState, useEffect, useCallback } from 'react';
import { useDebounce } from '@/utils/useDebounce';
interface OrderFilters {
status?: string;
dateRange?: [Date, Date];
amountRange?: [number, number];
tags?: string[];
}
export function useOrderFilters(defaultFilters: OrderFilters) {
const [filters, setFilters] = useState<OrderFilters>(defaultFilters);
const debouncedFilters = useDebounce(filters, 500);
// URL同步、防抖请求、本地存储逻辑...
}
踩坑提醒：
- 时间范围筛选要注意时区问题，后端最好统一用UTC
- 金额区间筛选记得处理null/undefined的情况
- URL params太长会被浏览器截断，超过2KB就要考虑用localStorage存复杂筛选
组合使用技巧
Pair Programmer + Code Review 联动
写完代码后用 code-review-prompt 模板做一次独立审查。Pair Programmer帮你写出来的东西，再用专门的review模板检查一遍，双重保险。
Pair Programmer + Debug 联动
遇到bug先用Pair Programmer模板描述问题，如果AI给不出答案，再用 debug-code-prompt 模板专门排查。两个模板侧重点不同——前者是协作探索，后者是精准定位。
Pair Programmer + 新人上手联动
刚入职或接手新项目时，用"场景二：Review别人的代码"模板快速理解现有代码。每天花30分钟让AI帮你读一个模块，一周下来基本就摸清了。
什么时候不该用
- 纯语法问题：查MDN或官方文档比问AI快。别用Pair Programmer查"React的useState怎么用"。
- 需要编译的错误：有些错误只有编译器知道。先跑一下再问AI，带上完整的错误信息。
- 涉及公司机密：别把核心业务逻辑、用户数据、密钥相关的代码丢给公共AI。脱敏后再问。
- 你已经知道答案：如果这个问题你搜一下Stack Overflow就能解决，别浪费对话token。
写在最后
Pair Programmer不是让你偷懒。它是让你在写代码的时候，多一双眼睛、多一个脑子、少一些自我怀疑。
好的Pair Programmer会让你写得更快，也会让你学得更多。因为你随时可以问"为什么这么写"，而不用担心打扰同事。
下次卡代码的时候，别死磕了。打开AI，说：“嘿，帮我看看这个问题。”
你会发现，一个人写代码，也可以不那么孤单。