问题场景
你让 AI 写个表格组件,它给你一个 500 行的"面条组件"------props 满天飞、状态管理混乱、完全没有错误处理。Review 时你改到怀疑人生:这跟手写有什么区别?
根源不是 AI 不够强,是你的 prompt 太菜。 单句 prompt 生成的代码 ≈ 刚入职的实习生,给架构约束的 prompt ≈ 高级工程师。
原因分析:AI 写代码的"最短路径"陷阱
LLM 本质是概率生成器,没有 prompt 约束时它会走"最短路径":
- 选最常见的写法(哪怕已过时)
- 省略边界处理和错误状态
- 把所有逻辑塞进一个函数
- 假数据糊弄 UI(图片 404、数据字段对不上)
解决方案不是"描述得更详细",而是给 AI 一个决策框架。
解决方案:3 个 Prompt 框架
框架一:Role + Context + Constraint(RCC)
diff
角色:资深 React 工程师
场景:一个支持搜索/排序/分页的用户表格
约束:
- 使用 TypeScript + React 18
- 状态管理用 useReducer,不用第三方
- 所有 API 调用需包含 loading/error/empty 三态
- 组件拆分颗粒度:TableHeader、TableBody、Pagination 三个子组件
- 错误边界包裹整个表格
👉 结果是:AI 不会一股脑写一个组件,而是按约束拆结构。
框架二:Negative Prompt(指定不要什么)
diff
不要:
- 不要用 any 类型
- 不要用 useEffect 做数据获取(用 react-query 或 swr)
- 不要用 class 组件
- 注释不要写成 "// 获取用户列表",改为用 JSDoc
大多数 prompt 只告诉 AI 要什么 ,但踩坑往往来自不要什么。负面约束能大幅减少返工。
框架三:Example-Driven(给样板)
markdown
请参照以下模式写一个下拉选择组件:
1. 类型定义(Props + State)
2. 自定义 hook(useSelect)
3. UI 组件(纯渲染)
4. 使用示例
------ 请严格按这 4 个模块输出,每个模块加 // --- 分隔
AI 对长文本的结构感很弱,用显式模板告诉它输出的骨架,它就不会跑偏。
实战演示:一份"一次过"的 prompt
❌ 反面教材(第一次 PR 必挂):
帮我写一个商品列表页面
✅ 正面教材(Review 一次过):
markdown
角色:资深全栈前端
框架:React 18 + TypeScript + react-query
场景:电商商品列表页,支持分类筛选和关键词搜索
输出约束(输出前逐一检查):
1. 类型:定义 Product、FilterState、FetchParams 三个接口,禁止 any
2. 组件结构:Page → FilterBar + ProductGrid + Pagination
3. 数据层:用 react-query useQuery 封装 fetchProducts,含 retry 3 次
4. 状态:URL search params 作为唯一数据源(useSearchParams)
5. 加载态:ProductGrid 用骨架屏(Skeleton),FilterBar 用 disabled
6. 空态:无结果时显示 "没有找到匹配的商品" + 清除筛选按钮
7. 异常:包裹 ErrorBoundary,单个卡片出错不影响其他卡片
8. 样式:Tailwind CSS,所有交互增加 transition-200
不用写的:
- 不需要登录逻辑
- 不需要购物车功能
- 不要生成 mock 数据(用真实接口类型即可)
请严格按以下格式输出,每段用 --- 分隔:
--- 类型定义
--- 数据层(hook/api)
--- UI 组件
--- 使用示例
实操代码对比
普通 prompt 生成(片段):
tsx
const ProductList = () => {
const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);
useEffect(() => {
fetch('/api/products').then(res => res.json()).then(setProducts);
}, []);
// ❌ 错误处理?空态?loading 跟空数据冲突?
// ❌ 组件卸载后还在 setState?
// ❌ useEffect 直接 fetch,无缓存无重试
};
结构化 prompt 生成(片段):
tsx
interface Product {
id: string;
name: string;
price: number;
image: string;
category: string;
}
interface FetchParams {
keyword?: string;
category?: string;
page: number;
pageSize: number;
}
function useProducts(params: FetchParams) {
return useQuery({
queryKey: ['products', params],
queryFn: () => fetchProducts(params),
staleTime: 30_000,
retry: 3,
});
}
// ✅ 完整的类型约束
// ✅ react-query 管理缓存/重试/loading/error
// ✅ 清晰的数据流
要点总结
| 维度 | 差 prompt | 好 prompt |
|---|---|---|
| 角色 | 无 | "资深 React 工程师" |
| 约束 | 无 | 类型/组件粒度/状态方案 |
| 负面清单 | 无 | "不要用 any / useEffect fetch" |
| 输出模板 | 无 | 标号分段 + 分隔符 |
| 范围限定 | "写个列表页" | 明确不用写什么 |
一个提示词好的标准:一个新人看了 prompt 就知道怎么评审代码。
写在最后
AI 写代码不是替代工程师,而是放大工程师的设计决策能力。你的架构设计越好、约束越清晰,AI 产出的代码质量就越高。把 10% 的时间花在写 prompt 上,省下 50% 的 review 时间。