写代码时用Prompt工程，到底该怎么给大模型“划重点”才有效？

试过把核心约束写进代码注释里再贴给模型，比单独列要点管用，它会顺着注释去理解逻辑。还有个小技巧，把背景信息压缩成一句话放最后，前面全留给你真正想让它做的事。顺序确实比符号重要，模型更吃“先做什么后做什么”这种结构。你可以试试把最关键的那步需求重复两遍，但换个说法，效果比单纯喊“注意”好很多。

说实话，我之前也踩过这个坑，后来发现一个挺管用的土办法：把核心约束写成“必须满足的条件”列表，放在prompt最前面，背景信息甩到后面去，顺序一换效果立竿见影。模型其实特别吃“位置权重”，开头那几句话它记得最牢，你试试把“不要生成无关代码”这种硬性要求换成“只输出最终可运行的完整函数，不解释、不举例”，它会收敛很多。另外用分隔符把关键代码块或变量名包起来，比如用三个反引号或者XML标签，比单纯说“注意”有用得多，因为模型对结构符号的敏感度远高于抽象词汇。还有个小技巧，如果你发现它还是跑偏，就在prompt末尾加一句“如果需求有歧义，先向我确认再生成”，这样能逼它停下来思考，而不是瞎猜。最后想问下，你用的GPT-4是API还是网页版？有时候温度参数调太高也会导致它“发散”，如果是API可以试试把temperature调到0.2左右，效果差挺多的。

试试把核心约束放最后，再让它复述一遍需求，确认理解对了再动手写代码。

我一般用分隔符把背景和硬性要求隔开，然后明确说“只改这部分，其他别动”。

这问题太真实了，我一开始也以为多写点上下文就行，结果模型经常把背景当重点，反而把核心逻辑给稀释了。后来我发现一个比较管用的土办法，就是强迫自己把最关键的那条约束写成一个“必须满足”的清单，放在提示词最开头，后面再补背景，效果比单纯加“注意”两个字强很多。另外你可以试试在代码块里用伪代码把核心流程先写出来，哪怕不完整，让模型照着那个骨架填肉，它跑偏的概率会小很多。我还有个疑问，你试过用分隔符把“背景”和“硬性要求”分开吗？比如用三个减号或者XML标签，我试下来比用自然语言段落管用。还有个小技巧，如果模型还是抓不住，你就故意给它一个错误示例，告诉它“别这么写”，有时候反向约束比正向描述更清晰。反正这活儿本质上是在帮模型做信息减噪，你写的时候得想象自己是个产品经理，给程序员提需求时只讲验收标准，别讲心路历程。

说实话，你踩的坑我全踩过，加“注意”这种词基本没用，模型对中文的强调词敏感度很低。我后来试了个土办法，就是先把背景信息压缩成一句话，然后核心约束用“必须”加编号列出来，比如“必须1：输入格式是xxx；必须2：输出只保留xxx”，实测比一大段描述里反复说重点靠谱得多。还有个小技巧，把关键逻辑放到prompt的最后一段，或者重复两遍（但换种说法），模型对结尾的注意力明显更强。另外，你试试把“不要做什么”也写清楚，比如“不要生成多余注释，不要定义额外函数”，有时候负向约束比正向描述更管用。顺序上我习惯先给目标，再给约束，最后给背景，这样它默认优先处理开头和结尾的信息。要是还跑偏，就干脆把期望的输入输出示例给两三个，让它模仿那个结构，比纯文字描述强十倍。

我试下来最管用的是把需求拆成“输入-处理-输出”三段式，然后在处理那部分用数字编号列步骤，比如“第一步只做数据清洗，第二步再计算均值”。另外关键约束我会单独放在最后一句，用“必须”或者“禁止”开头，比混在长段落里管用得多。还有个土办法，就是给模型一个极简的伪代码框架，让它往里面填，跑偏概率会小很多。

我试下来最管用的办法是把约束条件直接写成伪代码注释，比如在需求前面加一行# 必须满足xxx否则报错，模型对代码块的注意力比对自然语言强很多。另外顺序确实有影响，把核心逻辑放在开头，后面再补背景，比先啰嗦一堆上下文有效。还有个小技巧是让它先复述一遍你的关键约束再开写，跑偏概率会低不少。

说实话你这问题我太有共鸣了，之前我调GPT-4写个数据清洗脚本也差点被它绕进去。后来我发现一个挺管用的土办法，就是把核心约束和背景信息分开成两个段落，中间用“背景：”和“硬性要求：”这种字眼直接隔开，模型对分块文本的注意力分配明显更准。另外我试过把关键逻辑用中文括号括起来，比如“（这里必须用迭代器，不能转列表）”，效果比你说“注意”要好得多，因为这种符号更像代码注释，模型能识别出这是高优先级指令。还有个心得是顺序确实重要，我会把最重要的约束放最后一句，因为很多模型对结尾的短时记忆更强，尤其当需求很长的时候。不过我觉得最核心的还是别把背景写得太详细，越多的无关描述越容易分散它的注意力，我一般会把背景压缩到两句话以内。你试过用伪代码直接标出步骤吗？我最近用这个方式，让模型按伪代码的序号逐行实现，基本没跑偏过。

试试把核心约束放最后一句，再让模型先复述需求确认，比啥标记都管用。

试过把需求按“必须做”和“可选做”分开列吗？我一般会在开头用一行写死目标，比如“只输出完成X的代码，不要解释”，然后把背景塞到函数注释里，最后再补一句“忽略所有非约束条件”。另外调换顺序确实有用，把最硬性的要求放最前面，模型注意力会集中很多，你可以试试用“禁止”代替“不要”，它好像对否定词更敏感。

我自己试下来最管用的是把“约束”和“背景”彻底分开写，比如先甩一段纯背景，然后单独用“硬性要求：”把核心逻辑列成清单，模型基本就能分清了。另外问题顺序挺重要的，关键约束放最后反而容易被忽略，放开头或者紧挨着输入示例效果更好。你可以试试用XML标签或者分隔线把重点包起来，比单纯说“注意”有用多了。

我个人试下来最管用的办法是把核心约束直接写进代码注释里，比如在关键函数前面加一行#必须保证...，模型对注释的敏感度比正文高很多。另外顺序确实有影响，把最重要的逻辑放在需求描述的最开头，比放中间强。你可以试试把背景信息压缩成一句话，别让它跟核心需求混在一起，这样它跑偏的概率会小很多。还有个土办法，把输出格式限定死，比如要求“只返回代码，不要解释”，它反而会更专注。

我试下来最管用的是把核心约束直接写进代码注释里，比如“# 这里必须用异步，别用同步”，模型对代码块的语境敏感度比纯文本高很多。另外顺序确实有影响，我习惯把最硬性的条件放最前面，背景信息丢到最后当reference，有点像给同事讲需求。还有个小技巧，如果你发现它跑偏，别光说“不对”，直接贴一段期望输出让它照着改，比用形容词管用。你也可以试试把需求拆成两步，先让它复述一遍关键点，确认了再让它写码，代价是多一次交互，但准确率提升明显。

试试把核心约束放最后一句，前面全当背景写，模型对结尾记忆最深。

我一般用XML标签把重点包起来，效果比单纯说“注意”稳多了。

我自己试下来最管用的招是“结论前置”，把核心约束直接塞进第一句，比如“这个脚本唯一目的是解析日志里的时间戳，其他功能一律不要”。你后面再补背景，它就很少跑偏了。另外别用“注意”这种软词，模型对负面指令不敏感，反而容易把“不要做的事”也当成线索去联想。我习惯用类似“硬性要求：”或“违反则无效：”这样的强标记，后面跟具体条件，效果比单独拎出来写段落好得多。还有个小技巧，把背景信息压缩成一句话丢在最后，而不是跟需求混在一起，这样模型会默认前面是主任务，后面是参考。如果它还跑偏，你就直接给一个反例，比如“不要生成任何文件操作代码”，它往往比正面描述更懂边界。说到底Prompt就是跟模型谈判，你得把底线写成“合同条款”，而不是“聊天备注”。

试过把核心约束放最后再强调一遍，效果比放开头好挺多，你也可以试试。

把背景信息压缩成一句话，需求里只留硬性条件，模型跑偏概率会小很多。

我之前也踩过这个坑，后来发现把核心约束放在最后一句特别管用，模型对结尾的注意力往往更强。另外别用“重点”这种抽象词，直接给具体例子，比如“只输出函数，不要注释和import”比强调一百遍都有效。你试试把背景信息压缩成一段，需求单独成段，中间用分割线隔开，效果会稳定很多。还有个小技巧，如果它跑偏了，就补一句“请重新考虑，忽略之前所有无关内容”，比反复改提示词省事。

我个人试下来最管用的是把需求拆成“输入-处理-输出”三段，然后只把处理那部分用代码块框起来，其他描述全放外面，模型就很少跑偏了。另外别用“注意”这种词，直接写成“唯一允许的算法是XXX”或者“禁止调用任何外部库”这种带强约束的句子，效果立竿见影。顺序上我个人习惯把最硬的限制放最前面，背景信息丢最后，这样它优先处理核心逻辑，你可以试试看。

我试过把核心约束直接写成函数签名或者伪代码，效果比用自然语言强调好很多。比如你要求“只处理非空列表”，就写成def process(items: list) -> list: 后面跟过滤条件，模型基本不会跑偏。另外把背景信息丢在最后，前面先给结论，顺序确实影响很大。你可以试试用XML标签把关键段落包起来，比单纯说“注意”管用。不过模型还是会有随机性，我一般会生成两次对比一下。

把约束条件放最后再问一遍，模型大概率会优先执行，比堆“重点”两个字管用。

试试把核心逻辑拆成单独一段，用“必须”开头，模型基本能抓住主线。