通义千问代码变更提示词：参考资料高效应用指南

直接切入正题：让通义千问生成代码变更说明，最大的隐患是它脱离实际需求，自行“优化”或“修复”根本不存在的问题。关键在于精准下达指令——确保输出每一条变更说明都基于明确的事实来源，且可追溯、可验证。

核心准则只有一条：模型产出的变更说明，必须严格绑定你提供的原始资料。无论是PR描述、需求文档还是接口变更日志，给了什么就用什么，未涉及的内容一律禁止提及。提示词必须固化这一约束：强制模型充当“事实搬运工”，而非“自由创作者”。

明确指定参考资料的输入位置

首先在提示词开头直接声明存储位置：“以下【参考资料】部分包含本次变更的真实依据，请严格以此为准，不可自行补充未提及的内容。”将参考资料紧贴提示词与代码diff之前，用---【参考资料】---这类显眼分隔符包围。为什么？因为模型对位置敏感，距离越近，引用越精准。跳过这一步，模型大概率忽略你后续提供的文档，转而依赖其“通用知识”自由发挥。

强制要求逐项映射依据来源

接下来是绑定出处的硬性约束，这里提供两种主流策略。

第一种：直接指令模型在每条说明后标注来源编号。例如末尾附加“（来源：PR#287 第3段）”或“（来源：接口文档v2.1 表格第2行）”，迫使模型每一步都必须回查原始资料。

第二种：分步操作，先提取再组织。第一步，指示模型从【参考资料】中筛选所有涉及“功能增删”“字段变更”“兼容性调整”的原始陈述，原样列出不做改写；第二步，将这些陈述按影响层级归类：API层→业务逻辑层→前端展示层；第三步，对每一类用一句话概括意图，句首必须使用“因【参考资料中对应原文关键词】…”开头。

特别强调一句——若参考资料中未出现“幂等性”三字，说明中禁止出现该词。这是防止模型自行编造的关键措施。

禁用模糊表述，锁定可验证动词

最后是动词的精确化。直接在提示词中替换掉那些易引发幻觉的模糊词汇：“优化”改为“将重试逻辑从客户端移至服务端（见参考资料第5条）”，“修复问题”改为“修正了/order/create接口对空buyerId的500错误（见日志片段A）”。

操作很简单——替换形容词和副词即可。但效果立竿见影：模型会放弃猜测，转而从资料中寻找对应的动作描述。如果参考资料只写了“下单流程变快”，没有技术细节，那么说明中只能写“下单响应平均耗时下降40%（见监控截图链接）”，绝不能擅自补充“引入缓存”或“异步化”。

来源：互联网