你在让 Gemini 或任何 AI 生成代码学习项目时，是不是总得到一个列表：猜数字、学生成绩管理系统、简易计算器？这些题目本身没错，但跟你手头的真实工作隔着十万八千里。问题出在提示词上——你给的上下文太薄，AI 只能从教科书里捡最烂大街的例子给你。

要想AI吐出能直接匹配你当前技术栈、暴露真实卡点、并且带具体业务上下文的项目，必须把提示词本身做成一个“工程方案”。下面这套方法，我试过好几次，效果差异很大，关键就看你能不能把下面四个步骤走通。

锁定真实技术断点

第一步：别写“学不会装饰器”，要写你昨天碰到的具体错误。比如“昨天写@cache时传了list参数导致报错TypeError: unhashable type: 'list'，试过tuple()但丢失了原数据可变性”。Gemini只有看到你真实的报错信息和修复尝试，才能跳过那些泛泛的教学路径，直接给你补上最缺的那块砖头。

第二步：说清楚你正在对接的真实系统或工具链。别含糊，比如“当前在给内部CRM加导出Excel功能，后端用FastAPI，前端是Vue3+Element Plus，Excel模板由运营提供且字段顺序不能改”。

第三步：把你手头已有的最小可用代码块贴进去——哪怕只有三行。Gemini会拿这段真实的上下文当跳板，生成能直接衔接的项目，而不是从零开始虚构一个场景。

注入不可复制的业务约束

方法一：强制嵌入三个硬性锚点。在提示词里明确写出：项目必须同时满足【使用公司OA系统返回的JSON格式（含字段code/status/data）】【导出文件名必须含当日审批单号前缀】【所有日期字段需转为UTC+8并补零】。这三个条件缺一不可，任何缺少其中一项的项目直接淘汰。

方法二：禁用高频教学词。末尾加一句：“禁止出现‘模拟’‘示例’‘教学用’‘简化版’‘玩具项目’字眼；禁止用‘用户’‘管理员’‘订单’‘商品’等泛化名词；所有实体名必须来自你提供的系统文档，如‘审批单’‘抄送池’‘驳回快照’。”

这一步很关键，它逼着AI放弃那些写烂的通用框架，不得不从你给的真实业务素材里找实体。

用失败案例反向定义项目边界

方法一：给出一个你reject掉的AI生成项目。“错误项目：用Django写一个带登录注册的博客系统→问题：我根本不用Django，也没在做博客，这题对我毫无迁移价值。”

方法二：给出一个你accept的真实项目。“正确项目：用requests+BeautifulSoup爬取采购部每周公示的供应商黑名单PDF，提取‘企业名称’‘处罚事由’‘生效日期’三列存入本地CSV→原因：我本周真要干这事，PDF结构固定，但表格线识别总出错，需要练XPath定位和异常跳过。”

一正一反两个案例紧贴着写进去，Gemini会立刻对齐你的判断标尺，知道什么样的“好”才是你真正要的。

指定输出结构与验证动作

1. 项目名称必须带括号标注技术动词：例如“【解析】PDF黑名单提取器（requests+bs4）”“【封装】审批单状态同步钩子（FastAPI中间件）”。

2. 每个项目必须包含“启动命令”“预期输入样例”“失败兜底方案”三栏，格式为：启动命令|curl -X POST http://localhost:8000/sync -d '{"id":"OA20260622-001"}'|预期输入样例|{"id":"OA20260622-001","status":"approved","timestamp":"2026-06-22T15:30:00+08:00"}|失败兜底方案|写入redis缓存队列，30秒后重试，超3次发企业微信告警。

3. 【若某栏为空，则整行删除，不补全、不推测】