元模型与动态哲学：数字世界的“道”与编程新范式

自从新的生产范式诞生以来，我的工作中多了一项新身份——提示工程师。

在不同的大语言模型之间穿梭，寻求同频共振，研究了各种提示词范式，从 few-shot、COT、self-consistency 到动态提示词轮番尝试。曾经还装了一把x给公司做了个提示词工程的培训，尝试把写提示词的痛苦幸福转接给大家。

然而，周旋了一段时间后我发现，人和大模型之间依然有语言壁垒——真是君不识我，我亦不识君。

咱们平时其实还是国产模型用的多，尤其是DeepSeek出世之前，用于生产环境的还是智谱、千问，网上各种流传的适用于chatgpt claude的提示词，就真的没那么适用。经常花了半天大半天的时间也还是生成不了想用的效果。

隔壁道友曾经感慨：“花了半天时间，终于跟 LLM 聊出了点同频共振的感觉。”

工程化的提示词有时候一天要写十几个任务的（没错，就是这个强度，两三天突击出一套系统没在怕的）。一天得奖自己好几个鸡腿子。

终于有一天，受不了了，起义了，我要摆脱这被大模型劳役的日子！

让 AI 自己生成提示词

之前有个新加坡团队提出了 CO-STAR 框架，思路很好，但要写的字还是太多。那提示词这事儿，就大语言模型自己解决呗！

下面这个是我在多个项目中频繁使用且好用的提示词结构：

Role（角色）
大模型需要扮演的身份或定位。

Objective（目标）
任务的核心目标是什么？

Constraints（约束）
有哪些硬性要求或限制条件？

Workflow（流程）
按照怎样的步骤进行任务执行？

Example（示例）
提供具体案例，确保输出风格符合预期。

根据上面的结构，我手搓了一个coze提示词自动生成工具。提供大家使用（默认使用qwen-max模型）

只需要在任务描述里输入你想要进行的任务。比如“输入一段用户问题，请生成相应的MYSQL查询语句” .然后点击【按钮】（多么直白的标识）

这背后的流程是这样子的

频繁调用大模型，会不会很贵？

看似流程中频繁调用大语言模型，但别忘了，大模型的计费是按照 token（简单理解为字数）计算的。实际上，流程虽多，token并没有很多。

此外，让大模型一次性专注于一个任务，往往能产生更优质的效果。