代码生成的约束提示是怎么写的？

同一句「帮我写个爬虫」，AI 可能给你五十行能跑的代码，也可能给你一堆跑不起来的片段，差别通常在提示的约束给没给够。通义千问、智谱清言这类模型写代码的能力已经不弱，约束提示才是决定产出质量的那一环。

约束提示都约束什么

代码生成的约束大致分四类：功能约束，写明要做什么、不做什么；环境约束，语言版本、可用库、运行环境；质量约束，错误处理、边界情况要不要覆盖；形式约束，代码组织、注释密度、命名规范。四类不必每次全给，但至少要覆盖功能和环境两类，否则模型只能按最常见的假设来写，跑不起来是常态而非意外。还有一个常被忽略的角度是「不做什么」：明确禁止使用某个库、禁止改动已有函数签名，能避免很多连带问题。负面约束在代码场景里格外管用，因为代码的对错标准非常硬。

四类约束加一条负面清单，松紧各不一样。

输入输出规格怎么写

输入输出规格是功能约束的核心。写法很直接：输入是什么类型、长什么样、有没有特殊值；输出是什么格式、字段叫什么、异常时返回什么。比如「输入是字符串列表，可能含空字符串；输出是去重后的列表，保持原有顺序」。这几行字能让模型少猜一半。规格越接近接口文档，生成的代码越接近可直接使用的状态。规格写不准时，先让模型复述它理解的输入输出，确认一致后再让它动笔，这一步能拦住大半方向性错误。

注释、命名与风格要求

注释和命名要求看似小事，实际影响代码的可维护性。提示里写明「函数和关键步骤加注释」「变量名用完整英文单词」「遵循该语言社区的主流风格」，产出的代码就能直接进项目。给一小组符合团队风格的示例代码，效果比文字描述更直接，模型对代码风格的模仿能力非常强。团队已有命名规范的，直接把规范条目贴进提示，别让模型猜。注释要求也要防走过场：与其要求多写注释，不如要求在容易误解的行加一句为什么，注释才有信息量。

约束提示的粒度怎么拿

约束太松，产出随机；太紧，模型失去利用上下文补全细节的空间。拿捏的办法是分层次：硬约束，比如语言、接口、格式，逐条写死；软约束，比如风格、注释密度，给方向即可。第一次生成后看哪里跑偏，把跑偏处升级成硬约束，两三轮就能收敛出适合自己项目的约束清单。这份清单值得存下来，它是团队与模型之间的沟通契约。约束清单也不是越多越好，无关的约束会稀释关键约束的存在感，每条约束都该能回答「这条防的是哪次翻车」。

约束提示的思路延伸很广：功能点子从哪来，见头脑风暴的多样性提法；处理数据表的代码要统一统计口径，参考数据分析的口径提示；约束清单该写多死，见固定模板和自由发挥；用示例还是用说明来传达约束，见few-shot 与指令的差别。

代码约束提示速查表

• 功能边界一句话说死
• 语言版本和可用库写明
• 输入输出给规格，异常时返回什么也写上
• 命名注释提要求，或贴规范条目

一句话收住：约束是护栏，护栏立得越早，返工越少。

代码提示的迭代方式很简单：跑一次，改一处，三轮之后基本顺手。

约束提示快问快答三则

• 生成的代码跑不起来怎么办？：把报错信息原样贴回给模型，并在提示里补充环境约束，多数问题一两轮能修好。
• 约束清单会不会限制模型发挥？：硬约束不该被发挥，软约束留了空间，分清两类就不冲突。
• 大项目分多次生成怎么保持一致？：把接口定义和命名规范作为公共约束段，每次生成时都带上。