大模型网摘代码生成提示词骨架：需求-输入输出-约束-反例四段式
写代码时给 DeepSeek 的提示词，最常见的失败原因不是模型不行，而是需求没说清——"帮我写个爬虫"这种一句话指令，模型只能靠猜。这里分享一个我常用的四段式骨架：需求、输入输出、约束、反例。它不依赖花哨的角色扮演开场白，正好贴合 DeepSeek 这类模型的特点：推理与代码能力是底子，你把约束写得越结构化、越明确，产出越稳；反而是一堆"你是资深架构师"之类的包装词，对 R 系列深度思考模型帮助有限——它们吃的是清晰的规格说明，不是人设。
骨架拆解：每一段写什么
第一段：需求。用一两句话说清楚要做什么功能、解决什么问题，别绕弯子。"写一个函数，把嵌套 JSON 拍平成点号分隔的 key"比"帮我处理一下 JSON"强十倍。
第二段：输入输出。这是很多提示词缺失的一段。给出具体的输入示例和期望输出示例，模型对"照着样例做"的理解远好于文字描述。输入输出的类型、边界情况（空值、超长、非法格式）也要在这里点明。
第三段：约束。语言版本、框架、依赖限制、性能要求、代码风格，能列清单就列清单。深度思考模型会认真对待每一条硬约束，这里是拉开差距的关键。
第四段：反例。明确说"不要做什么"和"什么是错的"。比如"不要用正则解析 HTML""不要引入 pandas 以外的第三方库"。反例能堵住模型最常见的几种偷懒路线。
模板一：通用代码生成
text
【需求】
用 Python 写一个函数 flatten_json(obj)，把任意深度的嵌套字典拍平成一层，
嵌套 key 用点号拼接。
【输入输出】
输入示例：{"a": {"b": 1, "c": {"d": [1, 2]}}}
输出示例：{"a.b": 1, "a.c.d": [1, 2]}
列表不展开索引，整体作为一个值保留。
【约束】
1. 只用标准库，不引入第三方依赖
2. Python 3.10+ 语法
3. 附带 3 个 pytest 测试用例，覆盖空字典、列表嵌套、深层嵌套
4. 关键逻辑写中文注释
【反例】
- 不要用递归深度无上限的写法，超过 50 层应抛 ValueError
- 不要修改原始输入对象
- 不要返回 key 带列表索引的形式（如 a.c.d.0）
注意第三段的第 1 条约束"不用第三方依赖"——如果没有这条，模型很可能顺手 import pandas，然后你的部署环境就崩了。约束段的价值就在这种地方。
模板二：Bug 修复 / 代码改造
改代码场景比从零生成更容易翻车，因为模型常常"顺手重构"。四段式同样适用：
text 【需求】 以下 FastAPI 接口在高并发下偶发 500，请定位原因并给出修复后的完整代码。 【输入输出】 输入：现有代码（见下方代码块） 输出：1. 问题根因分析（不超过 5 行）；2. 修复后的完整文件代码； 3. 修改点逐条列表。 【约束】 1. 只修复并发问题，不改接口签名、不改返回结构 2. 依赖版本以 requirements.txt 现状为准，不升级 3. 涉及共享状态的地方必须明确说明加锁或改用无状态方案的理由 【反例】 - 不要重写不相关的函数 - 不要引入新的中间件或缓存层 - 不要用"可能""建议考虑"这类模糊表述，直接给结论和代码 现有代码：
python （粘贴你的代码）
最后一个反例值得单独说："不要用模糊表述"这条对 R 系列深度思考模型尤其有效。开启思考模式后，它会先在内部推理再输出结论，这条约束会把它的推理收敛成可执行的判断，而不是一堆免责声明。
什么时候需要开深度思考
四段式骨架写好后，还要决定要不要触发 R 系列的思考模式。经验是：单文件、逻辑直接的生成任务（CRUD、格式转换、简单脚本），V 系列普通对话模式就够，响应更快；涉及算法设计、复杂调试、多模块架构权衡的任务，再开深度思考。判断标准很简单——如果这道题你自己要画图推演才能想明白，就开思考；扫一眼就知道怎么写的，不开。
把这套骨架存成你的代码片段模板，每次生成前花两分钟填空，比事后返工改三轮代码省时间得多。