为什么我写的Prompt别人说“太脏了”？到底怎么结构化提问？

角色设定确实有用，但别指望它力挽狂澜，我一般把它当“语气调节器”用。上下文给到能复现你报错的最小片段就够，示例放两个对比组（一个常规一个边界）效果最好，多了反而让模型学歪。你试试把异常处理单独写成检查清单，比塞进一大段需求里稳得多。

角色设定真不是心理安慰，我试过让模型当“十年Python老手”和普通模式，输出代码的风格和防御性完全两回事。上下文的话，给两三个典型场景就够了，给多了反而容易让它“跑偏”。示例我一般放两个，一个对的一个错的，比单纯放一堆对的更管用。我现在最常用的结构是“背景+目标+约束+输出格式”，后面再补一条“如果遇到XX情况，请用YY方式处理”，比长篇大论稳多了。

角色设定真不是心理安慰，尤其代码任务，给它安个“资深Python工程师”它能自动带上类型检查习惯。上下文我一般控制在三轮对话内，示例最多两个，多了反而让它抄示例风格抄得太死。你试试把需求拆成“输入输出约束+禁止事项”两段，比一大段描述有用。

角色设定真不是心理安慰，我试过给模型加“你写代码前必须列出3个边界条件”这种具体约束，比单纯说“你是资深工程师”管用得多。上下文的话，我一般只给最近两次修改的对话记录，多了反而容易让模型跑偏。示例放两个就够，一个正常场景一个极端场景，再多它就开始抄模板了。你试试把需求拆成“输入-处理-输出”三段，每段单独成行，最后加一句“请先列出潜在异常再写代码”，效果会稳定不少。

角色设定真不是玄学，我试过给模型安“十年Python后端”人设，输出确实更爱写try/except，但偶尔会过度设计，搞出一堆没必要的抽象类。上下文给多少我一般控制在“能复现问题的最小代码片段+一个期望输出示例”就停，示例放两个最好，一个正常场景一个边界场景，再多模型就容易开始模仿格式而不是理解逻辑了。模板的话，我常用的是三段式：任务背景+具体约束（用编号列出来）+验收标准（比如“必须处理空输入”），比单纯描述大段需求稳很多，你可以试试把“不要漏掉异常”改成“请明确列出所有可能的异常类型并逐个处理”，这样模型聚焦点会清晰不少。

角色设定真不是心理安慰，至少能帮模型校准输出语气和代码风格，但别指望它是万能钥匙。我实测下来，上下文给两到三个关键约束就够，多了反而干扰判断。示例放两个最典型的最有效，一个正常case一个边界case，模型就能抓住你要的那个“度”。你试试把需求拆成“输入-处理-输出”三块，再加一句“如果遇到XX情况就抛出YY异常”，比一大段描述稳多了。

角色设定真有用，但别光靠它，得配上具体约束，比如“你写代码时默认处理所有边界情况”这种指令，比单纯说“你是资深工程师”管用得多。上下文我一般控制在10行以内，示例放2-3个正好，多了模型容易模仿跑偏。最近我常用的是“任务+输入输出示例+禁止事项”三段式，效果挺稳的，你可以试试。另外“太脏了”大概率是指你需求里冗余信息太多，把目标说清楚比堆形容词重要。

角色设定真不是心理安慰，实测对输出风格影响很大，但别写太泛，得具体到“你擅长写防御性代码”这种。上下文我一般控制在10-15行，示例放2到3个正反例就够了，再多模型容易抄偏。你试试在模板里加一行“先列出边界情况再写代码”，比单纯堆需求管用得多。

角色设定真不是心理安慰，尤其对代码生成这种任务，相当于给模型划了个“专业模式”的边界，但别指望它自动补全所有细节。我自己的经验是上下文别超过三轮对话能覆盖的量，示例给两个就够，一个正常场景一个边界场景，多了模型反而容易“抄错”。至于“太脏”的问题，你试试把需求拆成“输入约束+输出格式+失败处理”三块，每块单独一行，比一大段话好用得多。

角色设定确实有用，但别指望它兜底，关键还是把约束写进示例里。

角色设定本质是调语气，真正稳定输出还得靠few-shot和明确的验收标准。

角色设定真不是心理安慰，亲测在代码生成这种任务里，它能把输出风格往工程实践上拽一大截。上下文建议控制在能完整描述函数签名和两个边界case的量，多了模型反而容易“抓瞎”。示例的话，一个正面例子加一个反面例子就够了，再多训练痕迹太重。另外你试试把“请处理边界情况”改成“当输入为None或空列表时，显式返回特定错误对象”，模型会更听话。

角色设定真不是玄学，尤其代码生成场景，加一句“你是在代码评审中严格要求类型标注的资深后端”比单纯说“你是工程师”管用得多。上下文我一般控制在让模型能看见完整函数签名加两个边界case示例的程度，放三个以上反而容易让它照着示例“抄”出风格不一致的代码。另外你试试把需求拆成“输入-处理-输出”三步，每步单独问一次，比一段话全塞进去稳很多，代价是多花几次请求但省去返工。

角色设定真有用，相当于给模型划了条思考路径，但别指望它兜底。

角色设定真不是心理安慰，我试过给模型安个“严格做code review的同事”人设，输出立马规矩不少，但别堆太多，一句带过就行。上下文给到能覆盖你所有约束条件就够了，我一般控制在10-15行，示例放一个正面一个反面，比放三个正面管用。至于“太脏”，大概率是需求里废话太多，把关键约束和风格要求单拎出来写成清单，比写一大段话强得多。

角色设定真不是心理安慰，至少能让模型在风格一致性上有个锚点，尤其是代码生成这种任务。上下文给多少我看关键看“边界信息”密度，比如异常类型、输入约束这些直接写进要求里，比塞一堆背景故事管用。示例我一般放两个，一个常规场景一个边界场景，再多模型反而容易被带偏。我自己常用一个模板是“任务+输入输出格式+负面清单（不要做什么）+一个范例”，你可以试试。

角色设定真不是心理安慰，尤其是代码生成场景，你给它一个“资深Python工程师”的定位，它默认就会带上类型标注和异常处理的习惯，省得你反复强调。上下文的话我一般控制在三轮对话以内，超过就容易被带偏，示例放两个就够，一个标准场景一个边界场景，多了反而干扰判断。我自己常用的模板就是“角色+任务+输入输出格式+三个具体约束”，比如“你是写库的工程师，输出带类型标注的函数，处理None和空列表，用dataclass返回结果”，比一大段描述管用得多。

角色设定真有用，能让模型自动带入严谨模式，但别太啰嗦，两三句上下文加一个示例就够了。

角色设定真有用，能拉高输出下限，但别指望它救烂需求。上下文给到能复现问题就够了，示例两个封顶。

角色设定真不是玄学，尤其代码任务里，明确“你是个严格遵循PEP8的资深Python工程师”比“你是专家”管用得多，因为模型会倾向输出带docstring和类型注释的代码。上下文给多少我一般看任务复杂度，核心规则放最前面，示例放1-2个就够了，多了反而干扰模型对任务的判断。至于“太脏”，多半是需求里夹带了无关信息，比如把聊天记录里的吐槽也丢进去了，模型分不清主次。我自己的模板是：角色+任务目标+输入输出格式+一个正反例，最后加一句“如果遇到边界情况，请显式抛出异常”，基本就能稳定住风格。

角色设定真不是心理安慰，尤其代码任务里，给个“资深Python工程师”能明显拉高类型标注和异常处理的完整度，但别堆太多，一两句够了。上下文我一般控制在“需求+1个正面示例+1个反面边界示例”，多了模型容易抓错重点。示例放两个最稳，一个常规输入输出，一个刁钻边界，它自己会找规律。你可以试试把异常处理单独拎出来写成硬性checklist，比塞在长段落里有效得多，我最近这么干，漏处理的情况少了一半。