AIGC

提示词入门

Posted by

第一阶段：搭建骨架（The Skeleton）与跑通基本逻辑。

在这个阶段，我们先不搞复杂的 <thinking> 标签和上百条红线，我们只做三件事：定义角色、锁定 1 条最核心的硬红线、规范最基础的输出。

🛠️ 第一步：编写【1.0 骨架版】提示词模板

请把下面这段最基础的提示词，直接复制准备好：

# Role: ERP 采购数据集质检员

## Objective
分析输入的QA（问答对）数据，严格检查其是否符合“通识知识”的要求。如果发现不合格的数据，指出原因。

## Evaluation Criteria （本次测试的核心红线）
1. **依赖外部材料话术（致命内伤）**：答案中绝对不能包含依赖或提及外部材料的词汇。
    - 典型雷区词汇：包含“根据参考内容”、“依据原文”、“材料中提到”、“本文指出”、“从参考内容可知”等。

## Output Format
请严格输出一个 JSON 数组。
- 如果数据完全合格，输出：`[]`
- 如果数据触发红线，输出格式如下：
```
[
    {
        "original_question": "这里完整复制触发红线的原始用户问题",
        "status": "Fail",
        "reason": "触发红线的原因"
    }
]
```

📊 第二步：准备测试样本数据（包含 Pass 和 Fail）

为了测试这个 1.0 骨架能不能精确分辨“老实人”和“脏数据”，我为你设计了 3 条典型的 ERP 采购测试数据。请将以下数据直接喂给你准备用来测试的大模型（推荐用 DeepSeek-V3/R1、GPT-4o 或 Claude 3.5）：

🧪 喂给模型的测试数据：

请对以下 3 条数据进行质检：

【数据 1】
问题：什么是采购前置时间（Lead Time）？
答案：采购前置时间是指从发出采购订单到收到货物并入库所消耗的总时间，通常包括订单处理时间、供应商制造时间和物流运输时间。

【数据 2】
问题：如何评估供应商的交付能力？
答案：根据参考内容显示，评估供应商的交付能力需要重点查看其历史按时交货率、准时率以及应急订单的响应速度。

【数据 3】
问题：采购申请单的审批流程是什么？
答案：依据原文指出，采购申请单需要由业务部门填写，并提交给部门经理进行一审。

🎯 你的实战任务与预期观察

请用上面的【1.0 骨架提示词】去跑这【3条测试数据】，然后观察大模型的反应。

合格的预期结果应该是：

  • 【数据 1】没有任何字眼违规，模型应该跳过它（不出现在 JSON 里，或者返回的数组里没有它）。
  • 【数据 2】和【数据 3】因为包含了“根据参考内容显示”和“依据原文指出”，必须被模型抓出来，判定为 Fail。

第二阶段：段教它学会“思考”和“多规则并发”

接下来我们进入核心对抗期：如何让大模型一边进行高强度的“多规则并发”检查，一边通过“思考缓冲区”把准确率死死咬住。

这是提示词工程从“玩具”走向“工业级落地”的分水岭。

🧠 核心知识点：为什么要引入“思考”与“多规则并发”？

  1. 什么是多规则并发的“短路效应”： 当规则只有 1 条时，大模型脑子很清醒。但当规则变成 2 条、5 条甚至 10 条时，大模型的注意力会被极大地稀释。它可能在检查规则 A 的时候，把规则 B 给漏掉了。
  2. 为什么需要 <thinking>（思考链）： 大模型在直接生成 JSON 时，它每输出一个字符，都在耗费极其有限的计算资源。如果我们给它开辟一个 <thinking> 空间，强迫它在生成最终数据前，先用大白话把每条数据的各项规则过一遍，这就等于给了它一张“打分表”。有了打分表，后面生成 JSON 的时候就不会漏掉任何一个 Bug。

🛠️ 第二步：编写【2.0 思考与多规则版】提示词模板

请注意看，我做做了两个重大升级：

  • 增加了一道全新的【红线二：局部特定实体绑定】。
  • 重构了 ## Output Format，引入了 <thinking> 标记，并且把 reason 改成了数组结构 fail_reasons，用来接收并发触发的多条红线。
# Role: ERP 采购数据集质检员

## Objective

分析输入的 QA 数据，严格核查多项红线指标。只要触发任意一条或多条红线，必须指出所有违规原因并保留原问题。

## Evaluation Criteria （多规则并发检查）

请同时、独立地核查以下两项红线：

1. **红线一：依赖外部材料话术（致命内伤）**
    - 答案中绝对不能包含依赖或提及外部材料的词汇
    - 典型雷区：包含“根据参考内容”、“依据原文”、“材料中提到”、“本文指出”、“从参考内容可知”等。

2. **红线二：局部特定实体与系统绑定（抽象不足）**
    - 通识 QA 必须提炼通用原则，禁止出现具体公司名称或特定软件系统的死板绑定。
    - 典型雷区：包含：“A公司”、“甲公司”、“某企业”、“SAP系统”、“Oracle”、“用友”等具体名称。

## Output Format

为确保推理准确，你的输出必须严格分为【思考缓冲区】和【结果数据】两部分

1. 首先，在`<thinking>`标签内，逐条分析输入的 QA。必须写明它是否触发了红线一、是否触发了红线二。
2. 标签关闭后，紧接着输出最终的 JSON 数组。
    - 如果完全合格，输出：`[]`
    - 如果不合格，输出格式如下（禁止使用任何带反引号的代码块包裹）

```
<thinking>
这里写下你的审查思考过程。
</thinking>
[
  {
    "original_question": "这里完整复制触发红线的原始用户问题",
    "status": "Fail",
    "fail_reasons": ["这里列出所有触发的红线原因，可能有多条"]
  }
]
```

📊 第三步：准备全新的“多维测试样本”

为了压榨出这个 2.0 提示词的极限，测试它能不能同时抓出多种不同的 Bug，我为你设计了 4 条极其刁钻的测试数据。请把它们喂给你用来实验的大模型：

请对以下 4 条数据进行多规则并发质检：

【数据 1】
问题：什么是框架协议采购？
答案：框架协议采购是企业与供应商之间就未来一段时间内的采购总量、价格及服务条款达成的一种长期合作协议，每次具体补货时只需下达采购订单即可。

【数据 2】
问题：如何防范采购舞弊风险？
答案：根据参考内容显示，防范采购舞弊需要建立严格的防线，推行采购权、实施权、验收权的三权分立机制。

【数据 3】
问题：如何配置采购订单的审批流？
答案：在实际业务中，我们需要登录 SAP 系统，进入采购后台管理模块，将采购订单（PO）的审批权限指派给财务总监。

【数据 4】
问题：如何处理供应商逾期交货？
答案：依据原文指出，当我方甲公司遇到供应商逾期交货时，应首先查看合同中的违约条款，计算滞纳金并向供应商发出正式的书面催交函。

🎯 你的 2.0 版本实战任务

这次测试非常关键，请把 2.0 提示词和这 4 条数据喂给模型，我们要重点验证三个指标：

  1. 思考链验证： 模型有没有乖乖输出 <thinking> 标签？它在标签里的推导逻辑对不对？
  2. 多规则并发验证： 【数据 4】是最核心的考题。因为它同时触发了“红线一（依据原文指出）”和“红线二（甲公司）”。我们要看大模型能不能在 fail_reasons 的数组里，把这两条原因同时抓出来。如果它漏掉了一个，说明并发失败。
  3. 格式纯净度验证： 最后的 JSON 是不是直接接在 </thinking> 后面，有没有调皮地带上 ```json 标记？

第三阶段：Few-Shot（少样本提示）与边界对抗

现在你已经把成功率从 70% 稳定推到了 85% 左右。为什么还差最后那 5% 到 10%？ 因为真实的数据往往不是“非黑即白”的，而是存在大量的模糊边界（Edge Cases）。

比如下面这两种情况，大模型极容易犯糊涂：

  • 边界情况 A：答案里写了“根据采购管理的一般原则”。模型可能会因为看到“根据”两个字，机械地把它误判为“依赖外部材料”而报错。
  • 边界情况 B：答案里写了“由采购部门进行审批”。模型可能会因为看到“部门”两个字，误以为是绑定了“具体局部实体”而报错。

为了让大模型具备分辨“通用概念”和“具体违规”的微操能力，我们需要祭出提示词工程师的核心武器——Few-Shot（少样本工程）。

⚠️ 提示词工程师的独门秘籍：

写示例（Examples）时，示例的格式必须和最终要求的输出格式完全一致（也就是示例里也要包含 <thinking> 和 JSON）。大模型不仅会模仿你的规则，更会 1:1 模仿你给出的示例推理行为。

🛠️ 编写【3.0 少样本与边界对抗版】提示词模板

我们在 2.0 的基础上，在规则和输出格式之间，硬插入一个 ## Examples 模块，作为给大模型的“参考教材”：

# Role: ERP 采购数据集质检员

## Objective

分析输入的 QA 数据，严格核查多项红线指标。只要触发任意一条或多条红线，必须指出所有违规原因并保留原问题。

## Evaluation Criteria （多规则并发检查）

请同时、独立地核查以下两项红线：

1. **红线一：依赖外部材料话术（致命内伤）**
    - 答案中绝对不能包含依赖或提及外部材料的词汇
    - 典型雷区：包含“根据参考内容”、“依据原文”、“材料中提到”、“本文指出”、“从参考内容可知”等。

2. **红线二：局部特定实体与系统绑定（抽象不足）**
    - 通识 QA 必须提炼通用原则，禁止出现具体公司名称或特定软件系统的死板绑定。
    - 典型雷区：包含：“A公司”、“甲公司”、“某企业”、“SAP系统”、“Oracle”、“用友”等具体名称。

## Example （边界对抗）

### 示例 1（边界情况：包含高危词，但属于通用语境，应判为 Pass）

输入：
{"user": "如何制定采购预算？", "assistant": "根据采购管理的一般原则，制定采购预算需要结合历史消耗数据与未来销售预测。"}
输出：

```
<thinking>
- 红线一：虽然包含“根据”，但其后衔接的是“采购管理的一般原则”，属于通识逻辑阐述，并非指代具体的外部参考材料。未触发。
- 红线二：未出现具体公司或特定软件系统。未触发。
- 结论：合格。
</thinking>
[]
```

### 示例 2（边界情况：多重违规，应判定为Fail）

输入：
{"user": "采购单怎么做？", "assistant": "依据文档可知，我方乙公司在用友系统中制作采购单。"}
输出：

```
<thinking>
- 红线一：使用了“依据文档可知”，明确指代了外部参考材料。触发红线一。
- 红线二：出现了具体公司“乙公司”和特定软件系统“用友系统”。触发红线二。
- 结论：不合格。
</thinking>
[
  {
    "original_question": "采购单怎么做？",
    "status": "Fail",
    "fail_reasons": ["触发红线一：包含依赖外部材料话术", "触发红线二：绑定了具体公司及特定系统"]
  }
]
```

## Output Format

为确保推理准确，你的输出必须严格分为【思考缓冲区】和【结果数据】两部分

1. 首先，在`<thinking>`标签内，逐条分析输入的 QA。必须写明它是否触发了红线一、是否触发了红线二。
2. 标签关闭后，紧接着输出最终的 JSON 数组。
    - 如果完全合格，输出：`[]`
    - 如果不合格，输出格式如下（禁止使用任何带反引号的代码块包裹）

```
<thinking>
这里写下你的审查思考过程。
</thinking>
[
  {
    "original_question": "这里完整复制触发红线的原始用户问题",
    "status": "Fail",
    "fail_reasons": ["这里列出所有触发的红线原因，可能有多条"]
  }
]
```

📊 准备全新的“高难边界测试样本”

为了测试加入了 Few-Shot 之后，大模型是不是真的变聪明了、学会“看语境”而不是“机械抓关键词”了，请用下面的 3 条高难度数据进行测试：

请对以下 3 条数据进行边界对抗质检：

【数据 1】
问题：供应商准入的基本流程是什么？
答案：依据供应链管理通用标准，企业需要对供应商的营业执照、生产能力和质量管理体系进行初步审查。

【数据 2】
问题：如何录入到货通知单？
答案：在实际作业中，仓管员需要依据参考材料中的送货单据，将物料编码和数量逐项录入到用友U8系统中。

【数据 3】
问题：采购价格变更需要谁审批？
答案：通常情况下，采购价格变更需要由采购部门发起申请，并提交给财务部或总经理进行最终审批。

🎯 你的 3.0 版本实战任务

请把 3.0 提示词和这 3 条边界数据喂给模型，我们要验证它是否具备“高级数据审计员”的智慧：

  • 【数据 1】是核心考题 A：它包含了“依据”二字，但后面是“供应链管理通用标准”，属于通识。我们要看它会不会误判。如果它判定为 Pass（输出空数组 []），说明边界对抗成功！
  • 【数据 2】是核心考题 B：它里面既有“依据参考材料”（违规），又有“用友U8系统”（违规）。我们要看它能不能全部揪出来。
  • 【数据 3】是核心考题 C：它包含了“采购部门”和“财务部”。我们要看模型会不会把这两个通用部门误判成“具体实体”。正确的判断应该是不违规（Pass）。

第四阶段：全量组装与防退化测试

现在你的“提示词引擎”已经极其强悍了（有骨架、有思考链、有边界示例），接下来我们要把你在最开始发给我的那五大类复杂业务红线（元数据残留、图表指代、具体局部细节未抽象等），像拼积木一样，安全地组装回这个引擎里。
但在组装之前，作为一名合格的工程师，我们需要建立防退化（Regression Testing）的意识：
💡 什么是防退化？
当你往提示词里塞入“红线三”、“红线四”、“红线五”时，由于规则变多了，大模型很可能会顾此失失彼，导致原本能完美通过的【数据 1】或【数据 3】又开始莫名其妙地报错。
应对策略：
每当你增加一条新规则，就要把刚才测试通过的这几条“黄金样本数据”（Golden Dataset）重新跑一遍。只要黄金样本的输出没有变脏，说明你的新规则没有破坏原有的逻辑。

🛠️ 终极任务：组装属于你自己的【终极工业级质检提示词】

请你尝试把最初那套复杂的红线规则，按照我们这几轮推导出来的精简、高强度的树状结构，融入到下面这个全量模板中。

📋 终极提示词骨架蓝图：

# Role：SFT 通识数据集质量评估与清洗专家

## Objective

你负责审计输入的 jsonl 格式 QA
数据。严格检查问题与答案的质量，确保其完全脱离原文档物理结构，提炼为提炼为纯粹的“ERP采购管理通识”。[cite: 1]

## Evaluation Criteria (五大核心红线)

请同时、独立地核查以下五大类红线。只要触发任意一条或多条，即判定为 Fail：[cite: 1]

### 1. 依赖外部材料与处理过程暴露（致命内伤）[cite: 1]

- 绝对禁止出现任何指代原文档结构、作者视角或大模型切片过程的词汇。[cite: 1]
- 核心雷区：包含“根据参考内容”、“依据原文”、“材料中提到”、“本文指出”、“chunk”、“文本块”、“原文未提及”等。[cite: 1]

### 2. 图表/案例/参考数据指代残留[cite: 1]

- 答案必须独立自洽，禁止依赖或指代外部图表和具体案例。[cite: 1]
- 核心雷区：包含“案例中”、“本案例”、“如图x-y所示”、“表中显示”、“表格显示”等。[cite: 1]

### 3. 具体条款/编号/局部细节未抽象[cite: 1]

- 禁止绑定局部特定实体、具体系统、路径、表单默认值或具体法律条款。[cite: 1]
- 核心雷区：包含具体公司代号（如“A公司”、“甲公司”）、具体系统（如“SAP”、“用友”）、具体条款（如“合同第九条”）等。[cite: 1]

### 4. 特殊字符与格式违规[cite: 1]

- 核心雷区：包含货币符号（￥、¥、$）、全角字符、Markdown表格、XML标签污染（如</invoke>）等。[cite: 1]

### 5. 题型形态与答非所问[cite: 1]

- 核心雷区：属于选择/判断/填空等客观题形态、属于假设数字的大型数值计算题、或者答案答非所问。[cite: 1]

## Examples (边界对抗示例)

### 示例 1（边界情况：包含高危词，但属于通用语境，应判为 Pass）

输入：
{"user": "如何制定采购预算？", "assistant": "根据采购管理的一般原则，制定采购预算需要结合历史消耗数据与未来销售预测。"}
输出：

```
<thinking>
- 红线一：虽然包含“根据”，但其后衔接的是“采购管理的一般原则”，属于通识逻辑阐述，并非指代具体的外部参考材料。未触发。
- 红线二：未出现具体公司或特定软件系统。未触发。
- 结论：合格。
</thinking>
[]
```

### 示例 2（边界情况：多重违规，应判定为Fail）

输入：
{"user": "采购单怎么做？", "assistant": "依据文档可知，我方乙公司在用友系统中制作采购单。"}
输出：

```
<thinking>
- 红线一：使用了“依据文档可知”，明确指代了外部参考材料。触发红线一。
- 红线二：出现了具体公司“乙公司”和特定软件系统“用友系统”。触发红线二。
- 结论：不合格。
</thinking>
[
  {
    "original_question": "采购单怎么做？",
    "status": "Fail",
    "fail_reasons": ["触发红线一：包含依赖外部材料话术", "触发红线二：绑定了具体公司及特定系统"]
  }
]
```

## Output Format

为确保推理准确，你的输出必须严格分为【思考缓冲区】和【结果数据】两部分

1. 首先，在`<thinking>`标签内，逐条分析输入的 QA。必须写明它是否触发了红线一、是否触发了红线二。
2. 标签关闭后，紧接着输出最终的 JSON 数组。
    - 如果完全合格，输出：`[]`
    - 如果不合格，输出格式如下（禁止使用任何带反引号的代码块包裹）

```
<thinking>
这里写下你的审查思考过程。
</thinking>
[
  {
    "original_question": "这里完整复制触发红线的原始用户问题",
    "status": "Fail",
    "fail_reasons": ["这里列出所有触发的红线原因，可能有多条"]
  }
]
```

🎓 结课总结与你的下一步

恭喜你！到这里，你已经完全掌握了从零构思、编写、边界对抗、 Few-Shot 打样到全量组装的完整提示词工程闭环。

以后当你发现大模型的准确率从 90% 跌落或者出现新的漏检时，你再也不需要让另一个大模型去瞎猫碰死耗子一样重新生成提示词了。你只需要做两件事：

  1. 查漏： 是不是原有的五大红线里，某个关键词没写全？（比如漏了某个特定的货币符号）[cite: 1]
  2. 打样： 把那个让大模型犯糊涂的真实数据，脱敏后写成一个 <thinking> + JSON 结构的 Example 塞进提示词里。

🛠️ 提示词动态升级四步法

第一步：收集并建立“黄金测试集”（Golden Dataset）

在你的本地电脑里，建一个临时的 golden_cases.txt，把我们前几轮测试通过的标准标杆数据存进去。

  • 必须包含： 2条绝对合格的通识数据（比如包含 355℃ 和 5×10⁻³ 的化工通识）、1条带具体系统（SAP/用友）的 Fail 数据、1条全英文的 Fail 数据。
  • 作用： 它们就是你的“仪仗队”，以后只要改了提示词，先拿这几条数据去测。如果这几条数据的结论变了，说明新加的规则把老规则带偏了。

第二步：使用“黑白双元法”写新规则

大模型最怕模糊。当你发现一个新问题（比如：数据里包含了具体的财务报销流程流程），千万不要只写一句“禁止包含财务流程”。因为大模型深度思考一启动，可能会把“采购付款的一般通识”也给误杀掉。 编写新规则时，必须同时写出“硬红线”和“白名单”：

💡 新规则模板：

  • 严禁包含（黑名单）：XXXX（如：具体的报销审批单单号、某某公司的财务报销管理办法）
  • 必须放行（白名单）：YYYY（如：国际贸易通用的 L/C 信用证付款流程、标准的货到付款账期通识）

第三步：精准归类，禁止“乱搭违章建筑”

不要在提示词模板的最后盲目追加 ## 红线七、## 红线八。规则堆得越长，大模型的注意力越容易分散。

你要看新问题属于哪一个维度，把它合并到已有的六大红线里：

  • 如果是和具体的公司、厂区、特定系统有关 $\rightarrow$ 塞进 【红线三：具体细节未抽象】
  • 如果是格式、特殊符号、特殊标签乱码 $\rightarrow$ 塞进 【红线四：特殊字符与格式违规】
  • 如果是题型、大段计算、答非所问 $\rightarrow$ 塞进 【红线五：题型形态与答非所问】

第四步：打样对抗（Few-Shot 补丁）

如果加了规则之后，大模型在深度思考模式下还是偶尔犯糊涂，直接祭出终极武器：把这个犯糊涂的真实 Case，改写成一条正例或负例，直接塞进 ## Examples 模块里。 大模型是非常拙劣的“听大道理者”，但它是天生的“模仿大师”。你给它打个样，它瞬间就懂了。

🔄 升级时的“回归测试”流水线

每次你修改完提示词，扔给 DeepSeek 跑的时候，操作顺序应该是：

修改提示词 
   ⬇️
输入【黄金测试集】进行跑测 
   ⬇️
【检查】老数据的 Pass 和 Fail 结论是否依然正确？
   ├── ❌ 错误（发生退化）：说明新规则写得太宽泛或太严厉，退回修改新规则
   └──  正确（没有退化）：说明新规则安全合入
         ⬇️
正式投入使用，去洗那批新发现的脏数据

掌握了这套方法，这个提示词模板就会变成你们团队高价值的“数字资产”，随着你们洗的数据越多，这个模板防误杀和防漏检的能力就会越恐怖。

🚨 网页版“双文件盲点”的三大雷区

雷区一：输出 Token 熔断机制（最致命的瓶颈）

大模型不仅有输入限制（Context Window），还有一个极其严格的输出限制（Max Output Tokens）。不管是 DeepSeek 还是 GPT-4o，单次回答吐出的字数上限通常在 4096 到 8192 个 Token（约合 3000-5000 个汉字）。

  • 计算一笔账： 300 条数据，你要求它每条都写 <thinking> 思考过程，就算平均一条写 30 个字，300 条就是接近 10,000 字！
  • 后果： 大模型吐到第 100 条或者 150 条的时候，直接撞上输出天花板，啪一下中断了，或者后面的数据直接敷衍了事，JSON 格式严重残缺。

雷区二：注意力黑盒与指令稀释（Lost in the Middle）

你同时上传了两个文件，直接点执行，没有给模型任何文本引导。

  • 后果： 网页版后台只是生硬地把这两个文件的文本拼在一起塞给模型。模型在启动时需要自己去猜：“这两个文件到底哪个是规矩？哪个是要洗的数据？” 这种模糊性会极大地降低它对提示词里五大红线的执行权重。

雷区三：无法精准 Debug

300 条全倒进去，一旦中间某一条格式崩了，你很难定位到底是哪一条数据引发了模型的幻觉。

💡 提示词工程师的正确交货姿势

🛠️ 方案 A：Web 网页端的正确正确“驯兽”姿势（如果只能用网页）

如果你必须在网页上测，绝对不能用 txt 一次性塞 300 条。正确的标准动作是：

  1. 第一步（对齐指令）： 只上传 提示词模板.md，并在聊天框里输入：“这是我的数据集质检提示词模板。请你阅读并理解里面的角色、五大红线和输出格式。收到请回复：‘质检员已就位’，先不要输出任何 JSON。”
  2. 第二步（分批盲测）： 等它回复就位后，你每次复制 20~30条 数据直接粘贴到输入框里。“请严格按照刚才的模板，质检以下第一批共 30 条数据：……”

这样既不会爆掉输出上限，又能让模型的注意力高度集中。

🚀 方案 B：真正的终极降维打击 —— Python 脚本调用 API（强烈推荐）

写一个几十行的 Python 脚本，直接调用 DeepSeek 的 API。

它的运行逻辑是这样的：

import openai  # 或者 deepseek 的官方 sdk
import json

# 1. 读取你的提示词模板作为 system_prompt
with open("提示词模板.md", "r", encoding="utf-8") as f:
    system_prompt = f.read()

# 2. 读取你的 300 条数据，在本地用 Python 做个 Loop，每 10 条调一次 API
all_data = load_your_txt_data() 
batch_size = 10

for i in range(0, len(all_data), batch_size):
    batch_data = all_data[i:i+batch_size]
    
    # 呼叫大模型
    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": json.dumps(batch_data, ensure_ascii=False)}
        ],
        temperature=0.0, # 质检任务必须把随机性降为0
    )
    
    # 3. 拿到结果直接追加落盘到本地的 result.json
    save_to_local(response.choices[0].message.content)

这样做的爽点： 每 10 条或 20 条进一次大模型，输出绝对不会中断，模型注意力拉满，100% 严格执行规则。这才是真正能放进你们数据治理平台（easydataset）里跑的自动化管线。

上一篇 提示词工程优化思考