提示词工程进阶：结构化提示词四段法，角色任务约束输出一网打尽

同一个模型，有人调出来的输出稳定可用，有人调出来的十次九变，差距就在提示词的结构化程度上。随口一句「帮我写个周报」，模型只能靠猜：猜角色、猜格式、猜详略，猜对了是运气，猜错了是常态。结构化提示词的核心思想只有一句话——把「猜」的部分全部由你来定义。本文给出一套经过大量实践检验的四段法，照着套就能显著提升输出的可复现性。

四段法总览：角色、任务、约束、输出格式

四段法把一条提示词拆成四个职责清晰的部分：

段落	回答的问题	典型写法
角色	你是谁、以什么专业视角工作	「你是一位有十年经验的资深测试工程师」
任务	要做什么、背景是什么	「请评审以下登录接口的设计方案，背景是……」
约束	什么不能做、遵循什么标准	「只指出高风险问题；不要改需求本身」
输出格式	结果长什么样	「Markdown 表格，列：问题/风险等级/修改建议」

四段不必追求完整，但顺序建议保持「角色 → 任务 → 约束 → 格式」。角色放在开头为整段回答定基调；约束贴近任务能让模型在组织内容时就遵守规则；输出格式放在末尾紧邻生成位置，遵守率最高。

角色与任务：给模型一个专业视角和一件事

角色设定的价值不是「礼貌地称呼模型」，而是激活模型在特定领域的表达模式。「你是一位资深 SQL 优化专家」与「帮我看看这条 SQL」相比，前者会让回答自带执行计划分析、索引建议这些专业框架。角色可以叠加场景细节：「你是一位长期维护百万级日活电商系统的后端负责人」，这句里的「长期维护」暗示重视稳定性，「百万级日活」暗示性能敏感——这些暗示都会影响输出的取舍。

任务描述则要做到一件事一轮。把「帮我优化这个项目」拆成「先分析 order-service 模块的启动耗时瓶颈」，任务越聚焦，输出越深入。需要背景信息时直接内联在任务段里，不要指望模型去「回忆」你们上一轮聊过的内容。

约束：负面清单比正面要求更有效

约束段最常见的误区是堆砌空话（「回答要专业、准确、全面」），这些词不提供任何信息量。有效的约束是可判定的：

约束条件：
1. 只分析给出的这段代码，不要假设其他文件的内容
2. 每个问题必须给出可运行的修复代码，不接受纯文字建议
3. 如果信息不足以判断，明确列出需要补充的信息，禁止编造
4. 忽略代码风格问题，只关注正确性与性能

第 3 条尤其重要，它就是反幻觉约束：给模型一个「说不知道」的合法出口，编造率会明显下降。约束的数量控制在 3~6 条，超过之后模型对靠后条目的遵守率会下滑，此时应该合并同类项或者把详细约束移到附件里引用。

输出格式：把解析成本降到零

如果你的输出还要被程序二次处理，格式约束必须精确到分隔符。实践中有两个成熟模式。其一是 JSON 模式，直接给出目标结构示例：

输出格式：严格输出如下 JSON，不要包含任何解释文字：
{
  "issues": [
    { "line": 42, "level": "high", "desc": "…", "fix": "…" }
  ],
  "summary": "一句话总结"
}

其二是分节模式，适合人直接阅读的场景：「先输出『结论』一句话，再输出『分析』不超过 5 条，最后输出『行动建议』编号列表」。前者要配「不要包含解释文字」这类负面约束，否则模型喜欢在 JSON 外面裹一层客套话导致解析失败。

迭代调优：从一次对话到团队模板

提示词不会一次写对，正确的迭代姿势是：固定任务与输入样本，每次只改一段，对比输出差异，把有效的改动沉淀回模板。当一条提示词在团队内被三个人以上复用时，就该升级为「带变量槽的模板」，用 、 占位，收进团队知识库统一维护。判断一条提示词是否合格，就看换个人填槽之后输出是否仍然稳定可用。

实践清单

1. 按角色、任务、约束、格式四段组织提示词，顺序固定。
2. 角色叠加经验与场景暗示，任务一轮只做一件事。
3. 约束写可判定的负面清单，必带一条反幻觉出口。
4. 程序消费的输出精确到 JSON 结构，并禁止附加解释。
5. 单变量迭代调优，复用三次以上即模板化沉淀到团队库。

结构化提示词不是玄学，而是把需求讲清楚的一次工程化训练。当你能把一条提示词写到「任何人套用都稳定」的程度，你其实也把需求本身想明白了——这才是提示词工程真正的回报。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。