外观
第 6 章 结构化提示词
Prompt 一旦膨胀到几百上千个 Token，指令、背景、示例就会搅成一团，改一句怕牵动十处，这是几乎所有团队迟早要撞上的墙。这一章把软件工程里久经考验的成熟手段搬进 Prompt 设计，从用分隔符建立秩序，到用 LangGPT 范式搭项目骨架，再到用伪 Schema 立数据契约、用模块化复用沉淀团队资产，收尾还有一个“上帝 Prompt”反模式的警示。读完这一章，再面对一个复杂的 Prompt，写法会从“写作文”切换到“写代码”，手里也多出一套可以直接照着做的结构化方法。
6.1 为什么需要结构化
先来看一个很多团队正在经历，或者未来一定会遇到的场景。
项目上线了，精心调教的“智能客服机器人”表现不错。但随着业务越来越复杂，Prompt 也开始变得越来越臃肿。
最开始，它可能只有短短几十个字。后来，产品经理说要增加处理退款的逻辑，加了一段；运营说要能识别用户的潜在购买意图，又加了一段；法务说必须加上免责声明，又在末尾添了一笔……
几个月后，再打开那个存放 Prompt 的 .txt 文件，会发现眼前是一份长达 2000 个 Token、几十条规则和十几个 Few-shot 示例胡乱拼接在一起的文本，哪段是规则、哪段是示例，已经分不清了。
这时候，产品经理跑过来说：“小王啊，最近发现 AI 回答有点啰嗦，你能不能让它简洁一点？”
想改，但根本不敢动，因为完全不知道改了这一句，会不会影响到另外十个八竿子打不着的逻辑。这里面的每一条规则，都可能牵连别处，出错代价没法预估。这个 Prompt 变成了一个“黑盒”，一个连作者自己都无法维护的遗留系统。
写过复杂程序的人，对这种感觉一定不陌生。这就像是维护一个没有任何函数、所有逻辑都堆在 main 函数里的 C 程序，或者一个几千行的“面条式” JavaScript 文件。改一个 Bug，冒出三个新的，最后只能感叹一句：“谁写的垃圾代码……哦，原来是我自己。”
这个痛点，正是这一章要解决的核心问题。必须停止把 Prompt 当成一篇“文章”来写，而是要把它当成一份“代码”来设计。
这就是从“写作文”到“写代码”的范式跃迁。
“写作文”的思维是流式的，跟着感觉走，想到哪写到哪，只求意思连贯、文采过得去。这样写出来的东西，脆弱，难维护，也没法多人协作。
“写代码”的思维正好相反，讲结构、讲模块，强调逻辑清晰、边界分明。工程师用函数封装逻辑，用类组织数据，用注释解释意图，用版本控制来管理变更。这一切，都是为了对抗软件工程最大的天敌，复杂度。
当 Prompt 只有 50 个 Token 的时候，怎么写都行。但当它膨胀到 500、1000，甚至 5000 个 Token 的时候，还用写作文的思维，维护成本会一路失控。
所以，这一章要完成一次彻底的思维重塑，把软件工程中那些经过无数次验证的优秀思想，模块化、单一职责、关注点分离，移植到 Prompt Engineering 中来，用结构给内容划分边界和层次，让每一段都有明确的位置和职责，可以单独修改、单独复用。
接下来要做的，就是给 Prompt 建立固定的结构，而不是想到哪写到哪。
6.2 用分隔符划分模块与层次
结构化的第一步，也是最简单、最立竿见影的一步，就是使用分隔符（Delimiters）。
这听起来好像没什么技术含量，不就是加几个符号嘛？但千万别小看它。分隔符在结构化 Prompt 里的作用，就像是代码里的缩进和花括号，或者是文章里的标题和段落。它在做一件至关重要的事情，建立秩序。
再回到那份胡乱拼接的 Prompt。它之所以难维护，就是因为它是一大团混沌的文本。指令、上下文、示例、规则，所有东西都混在连续的文字里，分不出块。别说模型了，就连写它的人，过一个月再回来看，都得读半天才能理清逻辑。
来看一个典型的“混沌” Prompt 片段：
“你是一个客服机器人，要礼貌地回答用户问题。上次我们聊到退款政策是七天无理由，但电子产品拆封了不行。这是个例子：用户问‘我手机昨天刚到，能退吗？’，你应该回答‘请问您的手机拆封了吗？’。记住，千万不要承诺任何你做不到的事情。下面是用户的问题，请回答：‘我的电脑坏了，怎么办？’”
读这段话，是不是觉得有点累？信息是全的，但它们是“平”的，没有重点，没有层次。
现在，用最简单的分隔符，Markdown 的标题和分割线，重新组织一下：
markdown
### 角色
你是一个专业的电商客服机器人。
### 核心原则
1. 永远保持礼貌和耐心。
2. 严禁承诺任何超出政策范围的服务。
### 背景知识：退款政策
- 通用政策：支持七天无理由退货。
- 特殊政策：电子产品一经拆封，非质量问题不予退货。
### 示例：如何处理退款咨询
**用户输入：** 我手机昨天刚到，能退吗？
**标准回答：** 请问您的手机拆封了吗？如果尚未拆封，是支持七天无理由退货的哦。
---
### 用户当前问题
我的电脑坏了，怎么办？再看这个版本，是不是清爽多了？
对人类工程师来说，它的可读性和可维护性发生了质的飞跃。想修改退款政策，只需要去 ### 背景知识 这个段落里改，不用担心误删别的规则；想增加一个新示例，也只需要在 ### 示例 下面加就行。
而对模型来说，这种结构化的信息，同样能极大地提升它的理解准确性。
当模型看到 ### 角色 这样的标题时，它内部的注意力机制会给予这部分内容更高的权重，把这部分内容识别为身份设定。当它看到 --- 这样的分割线时，它会把前面的内容识别为背景资料，把后面的内容识别为真正需要处理的任务。
分隔符把要遵守的规则和要处理的数据明确隔开，模型能分清哪些内容是指令、哪些内容是输入。这样一来，就能有效地避免第 4 章提到的“指令和数据混淆”的问题，也就是“提示注入”的风险。
那么，可以用哪些分隔符呢？其实没什么硬性规定，只要保持一致性就行。实践中用得多的有这么几种。
Markdown 标题（#、##、###）层次感最强，可读性最好，非常适合用来划分大的逻辑模块，比如“角色”、“规则”、“任务”。三引号（""" 或 '''）非常适合用来包裹大段的文本内容，比如用户输入的一整篇文章，或者一段代码，这在 Python 程序员看来尤其亲切。
XML 标签（<tag></tag>）的好处是可以自定义标签名，让语义更清晰，比如用 <context></context> 包裹背景知识，用 <question></question> 包裹用户问题。很多模型，特别是像 Claude 这种对 XML 有特别优化的，用标签的效果会非常好。如果需要传递一些结构化的元数据，用 JSON 格式（{ "key": "value" }）来组织 Prompt 的一部分也是个不错的选择，比如 {"user_id": "123", "request_type": "summary"}。
选择哪种分隔符，取决于任务和个人习惯。 关键不在于用哪个符号，而在于建立起结构化的意识，把不同性质的内容分门别类地放进不同的段落或标签里，让每一类信息都有明确的位置和标记。
这就是结构化的第一步，也是从混乱走向秩序的开始。
6.3 LangGPT 范式详解
仅仅用分隔符做初步的整理还远远不够。一个复杂的软件项目，不能只有一个 main.js 文件，还得有 components 目录、utils 目录、config 文件……也就是需要一个项目结构规范。
在 Prompt Engineering 领域，也有人总结出了一套类似的项目结构规范，其中最著名、也最实用的，就是 LangGPT 范式。2023 年由云中江树等人在 GitHub 提出并开源，后由 Wang Ming 等人于 2024 年整理为学术论文（arXiv:2402.16929），在中文 AI 社区流传很广。
先别让这个听起来很高大上的名字吓到。LangGPT 的核心思想其实非常朴素，就是把一个复杂的 Prompt 拆解成几个固定的、职责单一的模块，相当于提供了一份标准化的模块清单，以后写任何复杂的 Prompt，都可以按照这份清单来填充内容，保证结构清晰、井井有条。
LangGPT 通常包含这么几个核心模块。Role（角色）告诉模型“你是谁”；Profile（简介）是对角色的进一步描述，包括性格、说话风格等；Goals（目标）写明要达成的最终目的；Constraints（约束）划定绝对不能做什么、有哪些红线；Skills（技能）列出完成目标需要用到的具体能力；Workflow（工作流）定义执行任务的步骤；Initialization（初始化）则是开场白，约定如何与用户开始第一次互动。
看到这一串模块，第一反应可能是：“我去，这么复杂？写个 Prompt 还要搞这么多名堂？”
别急，一个一个来看，每个模块都在解决前面章节提到过的痛点。
先看 Role 和 Profile，它们负责设定模型的身份和风格。这部分第 4 章已经聊过。它不仅仅是告诉模型“你是一个客服”，更通过 Profile 模块补充角色的更多细节。比如： # Role: 资深心理咨询师# Profile:- Author: 李医生- Version: 1.0- Language: 中文- Description: 一位拥有 15 年临床经验，擅长倾听、共情，说话风格温暖、有力量的心理咨询师。
加上 Profile，角色信息就具体起来了。模型在生成回复时，会去模仿这种“温暖、有力量”的风格，而不是输出冷冰冰的机器人口吻。
再来看 Goals。这个模块非常重要，它把最终要达成的目的固定写下来，多轮对话中模型可以随时对照，防止跑偏。 # Goals:- 帮助用户识别并接纳自己的情绪。- 提供切实可行的情绪调节建议。- 引导用户建立积极的心态。
有了这个 Goals，即使在多轮对话中，模型也不会轻易地跟着用户跑偏。比如用户开始闲聊八卦，模型会记得它的核心目标是“提供心理支持”，从而适时地把话题拉回来。
接着是 Constraints，一个划定红线、安全第一的模块。它就是第 5 章讲的“负向约束”的集合地，所有“不准做什么”的规则都应该集中写在这里。 # Constraints:- 严禁给出任何医学诊断或处方建议。- 严禁评判用户的价值观或行为。- 严禁与用户建立私人关系。- 如果用户表现出强烈的自杀倾向，必须立即停止咨询，并提供紧急求助热线。
把所有红线规则都集中放在这里，审查和修改时一目了然。这对于金融、医疗、法律等高风险领域的应用来说，是必须做好的一环。
Skills 模块用来告诉模型，为了达成目标，它具体具备哪些能力。 # Skills:- 熟练运用认知行为疗法（CBT）的对话技巧。- 能够使用隐喻和故事来进行启发。- 擅长识别并反映用户话语中隐藏的情绪。- 能够生成引导性的冥想练习文案。
列出这些技能，模型处理问题时就有明确的能力范围可以调用。这能让它的回答更加专业、更有深度，而不是泛泛而谈。
Workflow 用来定义“标准作业程序（SOP）”，这是 LangGPT 范式里最体现“代码思维”的部分，要求把任务分解成一步步的标准操作流程。
# Workflow:1. **问候与建立连接**：首先，用温暖的语气问候用户，并表达你愿意倾听。2. **倾听与共情**：耐心听完用户的陈述，不要打断。然后，用自己的话复述一遍你听到的核心困扰，并表达共情（例如：“听起来你最近压力很大，这一定很难熬”）。3. **识别核心问题**：通过提问，引导用户聚焦到最核心的问题上。4. **提供视角与工具**：基于你的技能库，提供 1-2 个相关的视角或实用小工具（例如，一个简单的正念呼吸练习）。5. **鼓励与结束**：最后，给予用户鼓励，并约定下次交流的时间。
有了这个 Workflow，模型的工作就不再是随意的“自由发挥”，而是变成一套有章可循的“方法论”，对保证服务质量的一致性和稳定性至关重要。
最后的 Initialization 负责设计开场白，这部分很简单。 # Initialization:作为你的心理伙伴，我在这里静静地听你诉说。你好，我是李医生，今天有什么想和我聊聊的吗？
一个好的开场白，能立刻把用户带入设定的情境中。
现在再回头看 LangGPT 的这套结构，是不是一点都不复杂了？它其实是把之前零散讨论过的最佳实践，用一个清晰的框架组织了起来。
使用 LangGPT 这样的范式，最大的好处是可维护性和可协作性。当团队里所有人都遵循同一套“项目结构”时，代码（Prompt）的交接和审查会变得无比顺畅，拿到同事写的 Prompt，一眼就能看懂设计思路，知道去哪里找核心逻辑、去哪里修改约束规则。
这就是从各自为战的手工编写，迈向团队协作的标准化生产的关键一步。
6.4 用伪 Schema 约定数据契约
好了，现在 Prompt 已经有了清晰的模块结构，但紧接着还有一个棘手的问题。尤其是需要模型输出结构化数据（比如 JSON）的时候，格式的稳定性很难保证。
这种痛苦大概率都经历过，让模型输出一个 JSON，十次里有三次不合要求。有时候，它会在 JSON 前后加上 ```json 和 ```；有时候，它会在 JSON 里面加上 // 这是一个注释；有时候，它会把一个数字字段输出成字符串，比如 "age": "25" 而不是 "age": 25；最麻烦的是，有时候它会直接少一个字段。
这些不合规的输出对下游代码的解析器来说就是直接故障，每一次 JSON.parse 都可能抛出 SyntaxError，让线上程序中断。
当然可以用第 4 章 4.5 节提到的“输出指示”来强力约束，比如“必须输出纯净的 JSON”，但这还不够“狠”。能不能像写代码时定义一个 class 或者 interface 一样，跟模型签订一份更明确的数据契约？
可以，这就是伪 Schema（Pseudo-Schema）技术。
“伪”这个字很关键。因为没法像在数据库里那样给模型一个强制性的 Schema 约束，只能用自然语言在 Prompt 里描述一个 Schema，从而极大地提升模型遵守格式的概率。
来看一个例子。假设要从一段用户评论中提取商品信息、评分和优缺点。
一个没有伪 Schema 的 Prompt 可能是这样的： “请从以下评论中提取关键信息，并以 JSON 格式输出。”
而一个有伪 Schema 的 Prompt，会长这样：
markdown
### 任务
从用户评论中提取信息，并严格按照以下 JSON Schema 格式输出。
### JSON Schema
{
"product_name": "string", // 商品名称，必须是字符串
"rating": "number", // 用户评分，必须是 1-5 之间的数字
"pros": [ // 优点列表，必须是一个字符串数组
"string"
],
"cons": [ // 缺点列表，必须是一个字符串数组
"string"
],
"is_recommended": "boolean" // 是否推荐，必须是 true 或 false
}
### 注意事项
- 如果某个字段在评论中没有提及，请使用 null 作为值。
- 不要输出任何额外的解释或 Markdown 标记。
### 用户评论
"""
我买的这个“降噪豆 Pro”耳机，音质真的没得说，低音很震撼！但是续航太拉胯了，听不了三个小时就没电了。总体给个 4 星吧，推荐给对音质有要求但不常出门的人。
"""
### 输出这个 ### JSON Schema 部分，就是和模型签订的“数据契约”。
这里做了几件重要的事情。所有字段（Fields）都定义了，product_name、rating、pros、cons、is_recommended，这让模型知道，它需要找哪些信息。数据类型（Data Types）也一并定义，string、number、array、boolean，这极大地降低了模型把数字输出成字符串的概率。
每个字段还添加了注释（Comments），用 // 这种写代码的方式，给字段加上自然语言的解释，帮助模型更好地理解它的业务含义，比如 // 用户评分，必须是 1-5 之间的数字，这既是解释，也是一条约束。再配上兜底规则（Fallback Rules），如果某个字段在评论中没有提及，请使用 null 作为值。 这条规则至关重要，它能防止模型在找不到信息时产生“幻觉”，硬编一个出来。
用这种方式去请求，模型输出一个严格符合要求的、干净的 JSON 的概率，会比模糊指令大幅提升。
伪 Schema 不是强制约束，模型仍有可能偏离，但有了这份明确的格式约定，偏离的概率已经大大降低。
这种“在自然语言中模拟编程语言结构”的思维，是高级 Prompt Engineering 的一个核心技巧。它体现的是防御性编程的思想，永远不要相信模型的自觉性，必须通过明确的、结构化的契约来约束模型。
6.5 建立 Prompt 片段库
随着项目越来越大，会发现有很多“样板代码”总是在反复地写。
比如，每个需要输出 JSON 的 Prompt，都要在末尾加上一段几乎一模一样的“输出指示”： “请严格按照 JSON 格式输出，不要包含任何解释性文字和 Markdown 标记。如果无法完成任务，请输出 {"error": "message"}。”
再比如，每个需要扮演“资深程序员”角色的 Prompt，都要在开头写一段类似的 Role 和 Profile。
这种重复劳动对有代码洁癖的工程师来说无法容忍，它违反了软件工程的基本原则之一，DRY（Don't Repeat Yourself）。
那么，能不能像写代码时封装一个 utils.js 或者 common 库一样，把这些通用的 Prompt 片段也模块化，使用时直接“引用”？
当然可以！这就是模块化复用的思想。
要建立一个自己的“Prompt 片段库（Snippet Library）”。这个库可以就是一个简单的文件夹，里面存放着各种 .txt 或 .md 文件，每个文件就是一个可复用的模块。
比如，可以先准备一个 json_output_constraint.txt，内容长这样：
### 输出约束
- 输出格式必须为严格的 JSON。
- 严禁包含任何 JSON 之外的解释性文字、注释或 Markdown 标记。
- 你的输出必须能够直接用 Python 的 `json.loads` 函数解析。
- 如果任务执行失败，请输出一个包含 "error" 键的 JSON 对象。再来一个 persona_senior_engineer.txt，长这样：
### 角色
你是一位拥有 15 年经验的资深软件架构师。
### 简介
- 你的代码风格简洁、高效，注重可读性和可维护性。
- 你总是会考虑各种边界情况和异常处理。
- 你倾向于使用业界最佳实践和设计模式。还有一个 task_code_review.txt，长这样：
### 任务
请审查以下代码片段，并从“代码风格”、“潜在 Bug”、“性能优化”、“安全性”四个方面给出具体的、可执行的修改建议。现在，要创建一个新的“代码审查” Prompt，就不需要从头开始写了，只需要在 Python 或 JavaScript 代码里，把模块按顺序拼接组合起来：
python
# 伪代码示例
def create_code_review_prompt(user_code):
# 从文件或数据库中读取模块化片段
persona = read_snippet("persona_senior_engineer.txt")
task_definition = read_snippet("task_code_review.txt")
output_constraint = read_snippet("json_output_constraint.txt")
# 使用 f-string 动态组装最终的 Prompt
final_prompt = f"""
{persona}
{task_definition}
{output_constraint}
### 待审查代码
{user_code}
"""看到这种做法的好处了吗？开发效率得到了极大的提升，不再需要重复地复制粘贴那些样板文字。系统的一致性也有了保证，所有需要输出 JSON 的任务，都引用了同一个约束模块，它们的行为是一致的。维护成本更是极大地降低，如果有一天发现 JSON 输出约束有漏洞，不需要去几十个不同的 Prompt 文件里一个个地改，只需要修改 json_output_constraint.txt 这一个文件，所有引用它的 Prompt 都会自动更新，这就是模块化的威力。
这种思想，其实是把 Prompt 的管理从“文本文件管理”提升到了“代码资产管理”的高度。Prompt 片段库就是团队的“通用组件库”，是团队在 Prompt Engineering 领域沉淀下来的可复用资产。
6.6 警惕万能 System Prompt
讲了这么多“应该怎么做”，最后必须花点时间聊聊“不应该怎么做”。在软件工程里，这叫反模式（Anti-Pattern）。
在结构化 Prompt 领域，最常见、危害也最大的一个反模式，就是试图创建一个包罗万象的“上帝 Prompt”（God Prompt），通常是写在一个巨大的 System Prompt 里。
见过一个真实的项目，System Prompt 长达 4000 个 Token，里面用自然语言密密麻麻地写了上百条 if-else 式逻辑。
它大概长这样： “你是一个全能助手。如果用户问天气，你就调用天气 API。如果用户想聊天，你就陪他聊天。如果用户上传了图片，你就描述图片内容。但是，如果用户的问题涉及到医疗，你必须拒绝回答。哦对了，如果用户是 VIP，你的回答要更热情一点。还有，不要在回答中使用感叹号，除非用户先用了……”
看着这段描述，是不是已经开始头晕了？
这种“上帝 Prompt”的初衷是好的，设计者希望把所有的业务逻辑都集中在一个地方管理。但最终的结果，往往是整个 Prompt 失控、谁也不敢再改。
为什么“上帝 Prompt”是一个反模式？因为它违反了几乎所有优秀的软件设计原则。
它违反了单一职责原则（Single Responsibility Principle），一个 Prompt 同时承担了任务路由、逻辑判断、风格控制、安全审查等无数个职责。它也是高耦合、低内聚（High Coupling, Low Cohesion）的，里面所有的规则都纠缠在一起，修改一个关于“天气”的逻辑，很可能意外影响到“聊天”的逻辑，牵一发而动全身。
对维护者来说认知负荷极高（High Cognitive Load），没有人能把这上百条规则都记在脑子里，每次修改都可能引入新问题，风险难以预估。而且模型理解困难，并不是写得越详细模型就越听话，恰恰相反，当规则过多、过长时，模型会发生“注意力稀释”，可能只记住开头和结尾的几条，忽略中间最重要的那条。
正确的做法就两个词，拆分和分层。
不能指望用一个 Prompt 来扮演“上帝”，应该设计一个由多个小而美的、职责单一的 Prompt 组成的协作系统。
这个系统的第一层是路由 Prompt（Router Prompt），它的唯一职责是判断用户的意图，比如 “请判断用户的请求属于以下哪个类别：‘天气查询’、‘闲聊’、‘图片理解’、‘医疗咨询’。只输出类别名称。”
第二层是专家 Prompt（Expert Prompts）。根据第一层路由的结果，调用相应的“专家”，每一个专家都是一个独立的、高度优化的 Prompt。weather_prompt.txt 专门负责处理天气查询，知道如何调用 API；chat_prompt.txt 专门负责闲聊，风格可以设计得更活泼；medical_guardrail_prompt.txt 专门负责处理医疗问题，它的核心逻辑就是拒绝和引导。
这种分而治之的架构，才是处理复杂业务逻辑的王道。它的好处是显而易见的。每个部分都简单可控，可以独立地测试和优化每一个“专家 Prompt”，不用担心影响其他部分；扩展也容易，未来要增加一个“新闻查询”功能，只需要增加一个 news_prompt.txt，再在路由层加上一个新选项，完全不会影响现有功能；性能还更优，对于简单的任务，只需要调用一个轻量级的 Prompt，不用每次都加载那个 4000 Token 的巨型 Prompt，成本和延迟都会大大降低。
所以，请记住这个教训，当 System Prompt 维护到让人吃不消时，就不要再打补丁了，这正是该重构的信号。
本章总结 把 Prompt 当工程产物来设计
这一章完成了一次思维转变，不再把 Prompt 看作一段随心所欲的文字，而是视为一个需要精心设计的结构化产物。
方法是层层递进配齐的。最底层是分隔符，负责建立秩序、告别混沌；往上是 LangGPT 这样的范式，给出一套清晰可维护的标准模块；再往上是伪 Schema，在工程师和模型之间约定明确的输出格式，输出稳定性有了保障；模块化复用则把散落的片段沉淀成团队的“Prompt 组件库”，告别重复劳动。而所有这些的另一面是同一个警示，别去造那个包罗万象的“上帝 Prompt”，复杂性要用分而治之来对付，不是一个 Prompt 硬扛。
这一章讨论的所有概念，结构、模块、接口、复用、分层、单一职责，是不是都很亲切？因为它们本就是软件工程的基石。
Prompt Engineering 发展到今天，早已不能只凭灵感和运气了。它正在回归工程的本质，用系统化的方法来管理和控制复杂性，构建可靠、可维护、可扩展的系统。
当开始在写 Prompt 之前先思考它的结构、模块和边界，开始为 Prompt 编写测试用例和文档，开始和团队讨论一个 Prompt 的设计是否合理，那就已经是在用工程方法做 Prompt 了。
这一步跨过去，就是真正的 Prompt 架构师。
参考资料
- Anthropic. Use XML tags（官方提示工程指南，明确建议用 XML 标签分隔提示词的不同部分，Claude 对该格式的解析效果好）. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/use-xml-tags
- LangGPT 项目（云中江树于 2023 年提出的结构化提示词框架，官方仓库）. GitHub. https://github.com/langgptai/LangGPT
- 云中江树. 系统论述：构建高性能 Prompt 之路——结构化 Prompt（LangGPT 官方文档，说明 Role、Profile、Skills、Rules、Workflow、Initialization 等属性词，Rules 可换用 Constraints，助手模板参考 AutoGPT 引入 Goals、Constraints）. https://github.com/langgptai/LangGPT/blob/main/Docs/HowToWritestructuredPrompts.md
- Wang, M. et al. (2024). LangGPT: Rethinking Structured Reusable Prompt Design Framework for LLMs from the Programming Language. arXiv:2402.16929. https://arxiv.org/abs/2402.16929