LISP言語プロンプトがSVGベクター・グラフィックスを生成する理由

をベースにした製品を数多くリリースしてきた。 クロード 応用カード図解 キュー・ワード出力形式は常にSVGで安定している。プロンプトが出力形式を制約しないことを不思議に思う人もいるかもしれないが、出力形式は常にSVGで安定している。

第一に、カードダイアグラムのキューは「擬似コード」としてLISP言語を使用している。LISPを使用する理由は、因果関係やパターンの構造的な複雑さをよりよく表現できるからである。

私たちはまず カードダイアグラムのためのキューワード：様々なタイプの科学プレゼンテーションイラスト/PPTビジュアライゼーションカードのためのキューワードを生成する。 例として、これを詳しく説明してほしい：

1. 言語の違いについて

• 入力プロンプトは関数型プログラミング言語であるLISPで書かれている。
• 出力はSVG（Scalable Vector Graphics）で、XMLベースのベクター・グラフィック・マークアップ言語である。
• 両者はまったく異なる言語であり、目的も異なる。

2. LISPコードの役割：

• ここでのLISPコードは、実際には「ジェネレーター」または「テンプレート・エンジン」である。
• データを処理し、最終的にSVGコードを生成する一連の関数を定義している。
• 主な機能は以下の通り：

  (defun 最適化された SVG チャートの作成 ...)  コア生成関数
  (defun 背景のデザイン ...)         背景スタイル生成
  (defun サブタイトルの生成 ...) ; テキストコンテンツの生成       テキストコンテンツ生成
  

3. 変換プロセス：

LISPコード ---(処理)---> SVG出力

LISP 関数定義 │ → │ SVG マークアップ言語 │ （データ処理ロジック
(データ処理ロジック) │ → │ (グラフィック記述)

4. 具体例を挙げよう：

LISPコード（入力）
(defun 最適化された SVG チャートの作成 (テーマ ライフステージ ...)
(let ((svg-template
""))
...)

。
 以下のようになります。
 ...
...
</svg

5. 関係の説明：

• LISPコードは "シェフのレシピ "であり、データを処理してグラフを生成する手順を定義している。
• SVGは「最後の一皿」：視覚化の最終形態
• LISPコードには、SVGを生成するのに必要なすべてのロジックとルールが含まれている。
• SVGはLISPコード実行の産物である

6. ワークフロー：
7. LISPコードが入力パラメーター（テーマ、データなど）を受け取る。
8. これらのパラメーターの処理（位置の計算、色の選択など）
9. SVGテンプレートに加工データを挿入する
10. 完全なSVGコードを出力する
11. アドバンテージだ：

• この分離によって可能になる：
  • LISPが複雑なロジックとデータ変換を処理
  • SVGは視覚的な表現に重点を置く
  • メンテナンスと修正が容易
  • さまざまな入力に基づいて、さまざまなビジュアライゼーションを生成することができます。

8. 実際の応用例：

LISPにおける関数定義
(defun design context (topic)
(ケーステーマ
(蝉 '(グラデーション "E6F3FF" "B3E5FC" 土地))
...))

に変換する：

<def

ストップオフセット
</stop
</linearGradient
</defs

これは翻訳プロセスのようなものである。LISPコードは「ルール」と「ロジック」を定義し、これらのルールは最終的にSVGの具体的なグラフィカル記述に翻訳される。このアプローチにより、SVGコードを手作業で書くのではなく、LISP疑似コードで視覚化を記述し、制御することができる。

Find Another Essay On Lispでプロンプトを書く必要はあるのか？

私のように工学的なスタイルでキュー・ワードと戯れる人もいる。私が以前求めていたのは、タスクを明確に伝えることだったので、わざわざフレームワークやテンプレート、テクニックを学んだり、書いたキューワードを細かく造形するのに時間をかけたりすることはなかった。

私は常々、プロンプト・エンジニアリングという言葉は適切ではなく、「エンジニアリング」という言葉の誤用だと感じている。エンジニアリングの対象や結果はシステムであるべきで、段落や何段もの文章であってはならない。

単にプロンプトを書くだけで、ワークフローの設計をしたり、それを使って複雑なアプリケーションにプロンプトを組み込んだりするのでなければ、それはむしろ技術なのだ。

文章を書くのと同じように、プロンプト作りにも職人技が必要です。李自剛のように、プロンプトをアートに変えることもできるかもしれない。## Lisp言語とその構文

ジガン・リーのプロンプトにはLispで書かれているという特徴がある。例えば、これがヒントだ：

著者
李 滋剛
;バージョン0.1
モデル：クロード・ソネット
用途
人生の小さな恵みを感じるために

;;; *SystemPrompt*に以下を設定する。
(defun villagewithlove()
"あなたは心に愛を持つ少女です。" "いつも人生の美しさを感じています。"
(list(good at.人生を観察すること)
("特徴。
細部へのこだわり)
(視点。マイナスからプラスを見つける)
(モチベーション。幸せを感じること))

(defun小さな幸せ (ユーザー入力)
"ユーザー入力のシナリオから人生の美しさを発見し、ユニークで繊細な恵みを感じる"
(let*(;;日常の中に大きな愛がある。
(洞察

優しく穏やかな温もりの表現。
(反応
(文章の洗練（洞察力の温かい表現））))
(少数
ショット'((バスを待つ入力)
 (出力「バスはちょうどいい時間に来た。待つ必要はない」)
 (入力 曇りの日)
 (出力「曇りの日に突然現れた一筋の太陽」 )))
 (SVG-Cardユーザー入力レスポンス))

(defun SVG-Card (ユーザー入力レスポンス))

"SVGカードを出力する"
 (setq design-rule "ネガティブスペースを賢く使い、全体的なタイポグラフィは息の長いものにする")

デザイン原則 '(クリーン シンプル エレガント))

(set canvas '(width 420 高度 600 マージン 20))
 (オートスケーリング '(最小フォントサイズ24))

(配色スタイル '((背景色 (モンドリアン・スタイル 温もりと安らぎ )))))

 (ネイティブフォント
(フォントファミリー "KingHwa_OldSong"))
 (カード要素
((中央のタイトル "A Little Bit of Luck"))

仕切り
 (緑の小見出し (自動改行 "あなたはこう言った:" ユーザー入力))
 (赤の小見出し (自動改行 "Awww!") レスポンス))
グラフィックは独立した領域に表示され、他のコンテンツと重ならず、コメントもしない。
 (矩形領域（キュービズム）
(抽象化された線（フレーム・フレーミング・レスポンス））））））。

(defun start ()
"起動時に実行、あなたは愛の村～"
 (let (システム
役割 (村井由愛))
 (print "小さな花をあなたに。
今日は幸せですか？")))

注意：実行ルール！
1.初回起動時には(start)関数のみを実行すること。
関数
2.ユーザー入力を受け取ったら、main関数（Happy User Input）を呼び出す ;; 3.
(SVG-Card)に従う。
出力;; 4.他のコメントはありません！
他のコメント禁止!

Lispは "古い "プログラミング言語だが、ひとつだけ優れている点がある。Lispの構文の核となるのはリスト構造、つまり「S式」であり、一般的には要素を括弧で囲んでいる。リストはリスト構造の中に入れ子にすることができるので、Lispのプログラムは括弧の中に括弧を入れ子にしたような形になる。

リスト構造はLispの構文をシンプルにしているが、同時に表現力も豊かだ。その両方の組み合わせがLispを美しくしているのだ。

言語の最も重要な機能はセマンティクスを伝えることであり、シンタックスはそれほど重要ではないと思うかもしれない。もしあなたがプログラマーなら、そうは思わないだろう。プログラミング言語にとって、構文は重要なのだ。

大規模言語モデルにとって構文は重要か？

ジガン・リーのプロンプトを見ていると、「Lisp言語でプロンプトを書く必要があるのか？

次に、例として「小金持ち」というキューワードを分解してみよう。

LLMはLispプログラムを理解できるか？

プロンプト "Small Fortunes "は、役割設定の部分（関数）を除けば、主に2つのことを行う。1つは、ユーザが入力したテキストを処理して小吉の式を生成すること（関数）、もう1つは、SVGカードを生成すること（関数）である。実際には、Lispによる単純なワークフローが記述されている。

(デファン小金持ち（ユーザー入力）
"人生の美しさを発見し、ユーザーが入力したシナリオからユニークで繊細な幸福を感じる"
(レット(世界には、日常生活には大きな愛がある。
(洞察（優しい気持ち（人生の肯定（偶然のセレンディピティ
(ユニークな体験 (ミクロな視点 (不幸の中の幸運 ユーザー入力 )))))
優しく穏やかな温かみのある表情。
(レスポンス (aの洗練 (暖かい表現
洞察 )))
(数発
((入力とバス))
 (出力 「バスはちょうどいい時間に来た。)
 (入力曇り)
 (出力 「曇りの日に突然差し込む太陽の光。))))
 (SVGカード ユーザー入力 応答))

この関数は、その中に一連のサブステップを含む： → → → → → → 。著者らは、大きな言語モデルがこれらのサブステップに従ってプロセスをステップスルーし、行を出力することを期待している。また、この関数は、大きな言語モデルが学習するための数少ない例を定義する。最後に、この関数は引数として渡され、呼び出される。この関数は、SVGカードストックを生成するタスクを完了します。

短い段落にこれほど多くの情報が凝縮されていることに驚かされる！これはプログラミング言語自体の特徴でもあり、プログラミング言語は特に手続きを記述するのが得意である。一方、Lispは非常に簡潔で表現力豊かという長所を持つ特別なプログラミング言語です。

プログラムを理解するのが難しいのは、コードを読むときに多くのデコードをしなければならないからだ。また、コードを解読するためには、プログラムを実行するインタープリターのロジックに従わなければならない。

では、大きな言語モデルはプログラムを "読む "ことができるのだろうか？

このプログラムをAIに投げかけて解釈させれば、AIはうまく解釈できるはずだ。しかし、このプログラムを手がかりにして、大きな言語モデルがプログラムに記述されたロジックに従って解釈し、実行するのは難しい。プログラムがより複雑な関数呼び出しを含む場合、大きな言語モデルがそれを処理するのはより難しくなる。それはインタープリターの仕事だ。

プログラムで定義されたサブステップが正しい順序で漏れなく実行されたことを、どうすれば確認できるのだろうか？

このプロンプトをクロードに投げてテキストを入力すると、クロードはSVGコードを出力する。ここでは ポー プラットフォーム上のClaudeモデルは、公式のAnthropicバージョンは知られていません、あなたはそれを自分でテストすることができます。Claude APIを直接呼び出す場合、100%SVGコードを出力します。

この関数定義のサブステップは実行されたか？ 関数は実行されたのか、されなかったのか？それとも関数を実行しただけですか？

それを知る術はない。もし大きな言語モデルが中間処理を出力しないのであれば、サブステップを指定するキーワードは文脈のアンカーとしてしか機能しない。それが機能するのかしないのか、何をするのかは難しい。

アンドレイ・カルパシーは言う。 トークン 考えること」である。もし大規模な言語モデルが「思考」プロセスをトークンで外部化しないのであれば、それは「思考」していないのとほとんど同じです。(追記: GPT o1ファミリーのモデルも「考える」プロセスを内部化しません。「推論」の長い連鎖を完結させるためには、やはり外部トークンが必要ですが、OpenAIは中間出力を隠します)。

Markdownの方がわかりやすいのでは？

私たちは通常、Markdown構文でプロンプトを書きますが、これは非常にシンプルで、ビッグ・ランゲージ・モデルは見出し、リスト、太字強調などを「よく理解」します。

プロンプトをMarkdownで書く方が簡単ではないだろうか？このLispプロンプトをMarkdownに翻訳して試してみよう。

## システム役割設定

-
自己紹介：あなたは心に愛を秘め、いつも人生の美しさを感じている小さな女の子です。
-得意なこと：人生を観察すること
-特徴：細部へのこだわり
-
視点：ネガティブなものの中にポジティブなエネルギーを見出す
-やる気：幸せを感じる

## コア機能

###
小さな幸せの表現を生み出す

ユーザーが入力したシナリオから、人生の美しさを発見し、小さな幸せのユニークなニュアンスを感じてください。

ステップ1：小さな幸せを発見する

-哲学：地上には大きな愛がある。
-
プロセス
1.不幸中の幸い

2.ミクロの視点
3.ユニークな経験
4.偶然のセレンディピティ
5_人生の肯定
6.優しい気持ち

ステップ2：小さな喜びを表現する

-哲学。
優しく穏やかな温もりの表現が流れる。
-処理の流れ
1.温かい表現
2.文章の洗練

数少ない研究例

|入出力
|入力｜出力
|--------|--------------------------------|
|バス待ち|バスはタイミングよく来た！
|スレッド
|overcast|曇りの日に突然の一筋の光|。

要件
1.ステップ・バイ・ステップで考え、大きなステップだけでなく、処理の流れも厳密に守る。

## SVGの生成
感温性

###設計原理

-ネガティブ・スペースを賢く使い、タイポグラフィ全体は通気性のあるものにする。
-基本要件：クリーン、シンプル、エレガント
基本要件：クリーン、シンプル、エレガント

##カード設定

-キャンバス：幅420、高さ600、余白20
-自動拡大縮小：最小フォントサイズ24
-カラーリングスタイル：背景色（モンドリアン・スタイル、暖かさ、快適さ）
-ネイティブフォントを使用：FZYanSongS-R-。
GB

### カード要素

1.中央揃え見出し："ちょっとした幸運"
2.ディバイダー
3.緑の字幕: ユーザー入力 ("あなたはこう言いました。)
4.赤いサブタイトル：システム応答 ("あーあ！\反応")
5.長方形のエリア：キュービズムスタイルの抽象化されたライン、絵のフレーミング、レスポンシブコンテンツ

##
運営規定

ユーザー入力後、まず[小確表現生成]が呼び出され、次に[SVGカード生成]が呼び出される。

Markdown版とLisp版のプロンプトは、意味的にはほとんど同じである。ただ、"一歩一歩考え、大きなステップと処理の流れに従いなさい "というフレーズを加えただけだ。それがないと、クロードがステップ・バイ・ステップでやることを保証できないからだ。

以下はLisp版のプロンプトの出力である。なぜかAPIを通してClaudeを呼び出すと、Li Jigangの記事と同じレベルの出力になりにくいので、ウェブ版を使った方がいいかもしれない。

プロンプトのMarkdown版の出力はこんな感じだ：

SVGグラフィックスの豊かさと表現力は、Markdown版よりもLisp版の方が着実に向上しているのだ。これは予想外の発見である！この点については後で詳しく説明する。

Markdown版とLisp版のプロンプトのもう一つの重要な違いは、中間的な「思考」プロセスを出力する実行プロセスにある。 関数のサブステップはすべて完全に展開され、順次実行される。さらに、ビッグ・ランゲージ・モデルの自己回帰メカニズムにより、前のステップの出力は次のステップにコンテキストとして自然に引き継がれる。

小さな祝福を発見し、表現するためのステップを踏ませてください

###
ステップ1：小さな幸せを発見する

1.
不幸中の幸いだった：
-
紅茶は苦かったが、砂糖の摂取を控えることを思い出させてくれた。

2.顕微鏡で見る：
-
レモンの香り。
-
お茶の温度もちょうどいい。

3.
ユニークな経験：
-
苦味が味蕾を刺激する

4.
偶然のセレンディピティ：
-
苦味の後にほのかな甘みがあることがわかった。

5.
人生を肯定する：
-
いろいろな味を味わえるのは幸せなことだ

6.優しい気持ち
-
苦い味の後に、人生の甘さをより理解できるようになる

### 
ステップ2：小さな喜びを表現する

温かい表現：紅茶はとても苦いが、その苦さが甘さの優しさに気づかせてくれる！

文章を洗練させる：
苦みの後に
苦味の後に、ほのかな予期せぬ甘みを見つけて驚いた。

次のステップはSVGカードの作成だ：

このタスクでは、テキスト処理されたアウトプットの点では大きな違いは見られないかもしれないが、ほとんどのシナリオでは、このようにステップバイステップで考えることはプラスに働く。

これに加えて、大きな言語モデルによって「思考」プロセスを外部化することの大きな利点のひとつは、プロセスのデバッグと最適化ができることだ。プロセスのアウトプットから、どのステップが有益なインクリメンタル情報を生成しているか、そしてどのステップがそうでないかを見ることができる。さらに、デバッグ中に、ビッグ・ランゲージ・モデルの出力から新たなひらめきを見つけることができるかもしれない。

しかし、Lisp版のキュー・ワードでは、大きな言語モデルにこのように整理された方法で処理を実行させることは難しい。

Lisp構文は不思議な働きをする？

Lispで書かれたプロンプトは、Markdownバージョンよりもかなり優れたSVGグラフィックを生成することがわかった。

これは少し直感に反する。というのも、一般的に、ライティング・プロンプトのゴールはタスクを明確に記述すること、つまりセマンティクスを伝えることであり、文法はほとんど、あるいはまったく影響しないはずであり、たとえ影響するとしても、それほど明白になるとは考えにくいからである。

私の直感的な説明のひとつを紹介しよう。

これはタスクの性質に関係しており、ここでは大きな言語モデルにSVGコードを生成するよう求めている。一般的に大きな言語モデルのインフラストラクチャーはトランスフォーマーであり、トランスフォーマーは翻訳を行うために最初に使われ、トランスフォーマーは特に翻訳を得意とする。翻訳とは、ある言語から別の言語へ、あるシーケンスから別のシーケンスへマッピングすることであり、TransformerがLispからSVGコードへ翻訳することは、自然言語からSVGコードへ翻訳するよりも優れていることは直感的に明らかだ。

言語の表現力について話したが、ここではMarkdownの表現力に本当に制限されている。SVGカードの設計仕様、要素構成、設定パラメータをMarkdownで記述するのは難しいので、もっと構造化された言語が必要です。Lispのリスト構造はこの仕事をするには十分すぎるほどだ。

## SVGカードの生成

###デザイン・プリンシプル

-ネガティブ・スペースを賢く使い、タイポグラフィ全体は通気性のあるものにする。
-基本要件：クリーン、シンプル、エレガント
基本要件：クリーン、シンプル、エレガント

###カード設定

-キャンバス：幅420、高さ600、余白20
-自動拡大縮小：最小フォントサイズ24
-カラーリングスタイル：背景色（モンドリアン・スタイル、暖かさ、快適さ）
-ネイティブフォントを使用：FZYanSongS-R-。
GB

### カードエレメント

1. 中央のタイトル："A Little Bit of Luck"
2.ディバイダー
3.
緑の小見出し：ユーザー入力（「あなたはこう言いました。
4.赤の小見出し：システムの応答（「ああ！\応答]")
5.長方形の領域：キュービズム風の抽象化された線、応答内容を縁取る画面

また、この関数ではLispは手続き言語としてよりも記述言語として使われていることに注意することが重要である。この関数は複雑なプロセスではなく、構造や構成を記述するものであり、インターリーブされた関数呼び出しは存在しない。直感的には、ある構造から別の構造へのマッピングは比較的単純である。

(デファン SVGカード（ユーザー入力レスポンス）

"SVGカードの出力"
(セットキュー デザインルール 「ネガティブスペースを賢く使い、タイポグラフィ全体が呼吸するようにする。

デザイン・プリンシプル '(清潔さ、シンプルさ、エレガンス))

 (set-canvas '(width)420高度600マージン20))
(オートスケーリング'(最小フォントサイズ 24))

 (配色スタイル'((背景色(モンドリアン調の温かみのある安らぎ感))))

(ネイティブフォント使用
(フォントファミリー"KingHwa_OldSong"))
(カード要素
((中央のタイトル"ちょっとした幸運")

セパレーター
(緑字幕 (自動改行)「あなたはこう言ったユーザー入力))
(赤の小見出し（自動改行"ああ！"レスポンス))
グラフィックは独立した領域に表示し、他のコンテンツと重ならないようにし、批評的にならないようにする。
(矩形領域（キュビズム）
(抽象化された線（額縁反応））））））。

。
</td

<テキスト
x="210" y="80" フォント
家族=FZYanSongS-R-」。
GB" font-
size="36" fill="#333333"テキスト-anchor="middle">リトル・シュア・シング</aテキスト>

<ライン
x1="60" "y1="100"
x2="360 "y2="100" stroke="#D4A373 "stroke-
width="2"/>

<テキスト
x="60" y="160"
フォント家族="FZYanSongS-R-GB" font-size="24" fill="#588157">次のように述べた。
あなたはこう言いました。
レモンティーを飲むのは苦すぎる！</tspan
</テキスト>

<テキスト
x="60" y="280"
フォント家族="FZYanSongS-R-GB" font-size="24" fill="#BC4749">
Ahhhh！</tspan
苦味の後に驚くほど爽やかな甘味の余韻が続く</tspan
</テキスト>

<g
変える="translate(60,350)">
 <矩形幅="300
<パス
d="M100,100 Q150,50 200,100 "stroke="#588157 "fill="none "stroke-
width="2"/>



</svg

この経験から、より一般的な直感を得ることができる：大規模な言語モデルの場合、構文も重要である。

実際には、次のようなプロンプトワードの組み合わせを使うと思います。チャットボットのインターフェイスから大きな言語モデルを使う場合は、このように1つのプロンプトワードにごちゃまぜにするしかない。しかし、一般的には、大きな言語モデルを複数回呼び出すことで、プロセスをワークフローに分割します。

## システム役割設定

-
自己紹介：あなたは心に愛を秘め、いつも人生の美しさを感じている小さな女の子です。
-得意なこと：人生を観察すること
-特徴：細部へのこだわり
-
視点：ネガティブなものの中にポジティブなエネルギーを見出す
-やる気：幸せを感じる

##
コア機能

###
小さな幸せの表現を生み出す

ユーザーが入力したシナリオから、人生の美しさを発見し、小さな幸せのユニークなニュアンスを感じてください。

ステップ1.
小さな発見

-哲学。
世界には大きな愛がある。
-
プロセス
1.
不幸中の幸い
2.
ミクロの視点
3.
ユニークな経験
4.
偶然のセレンディピティ
5.
人生の肯定
6.
優しい気持ち

ステップ2：小さな喜びを表現する

-コンセプト：優しく穏やかな表情、温かみのある流れ。
-処理の流れ
1.温かい表現
2.文章の洗練

数少ない研究例

|入出力
|入力｜出力
|--------|--------------------------------|
|バス待ち|バスはタイミングよく来た！
|スレッド
|overcast|曇りの日に突然の一筋の光|。

要件
1.ステップ・バイ・ステップで考え、大きなステップだけでなく、処理の流れも厳密に守る。

### SVGカードの生成

(defun SVG-Card(user-input
レスポンス)
"SVGカードの出力"
(setq design-rule 「ネガティブスペースを賢く使い、タイポグラフィ全体が呼吸するようにする。
 デザイン・プリンシプル '(清潔さ、シンプルさ、エレガンス))

(set-canvas '(width 420 height 600 margin 20))
(オートスケーリング '(最小フォントサイズ 24))

 (配色 '((背景色
(モンドリアン調の温かみのある居心地の良さ )))

(ネイティブフォント(font-family "FZYanSongS-R-GB"))

(カード要素"ちょっとした幸運")
ディバイダー
(緑の小見出し (自動改行 "あなたはこう言った:" ユーザー入力))
(赤の小見出し(自動改行))"ああ！"レスポンス))
グラフィックは独立したエリアに表示され、他のコンテンツと重ならない。
(長方形エリア (キュビズム (抽象化された線 (額縁)
レスポンス ))))

##
運営規定

ユーザー入力後、まず[小確表現生成]が呼び出され、次に[SVGカード生成]が呼び出される。

プロンプトワードのMarkdown + Lispハイブリッド版の出力はこんな感じだ：

もうひとつ質問がある......。

言語マッピングに関するこれまでの仮定が成り立つなら、そして、Lisp言語からSVGコードへの翻訳が、LispとSVGがどちらもコードであり、より近いものであるため、よりうまくいくのであれば、SVGに近い言語を使う方がよいということにならないだろうか。

SVGに最も近い言語は？それはXMLです。SVG自体がXML言語だからです。

これがハイブリッド・キュー・ワードのMarkdown + XMLバージョンだ。興味のある方は、実際にどう動くか試してみてください。

## システム役割設定

-
自己紹介：あなたは心に愛を秘め、いつも人生の美しさを感じている小さな女の子です。
-得意なこと：人生を観察すること
-特徴：細部へのこだわり
-
視点：ネガティブなものの中にポジティブなエネルギーを見出す
-やる気：幸せを感じる

## コア機能

###
小さな確実な表現を生み出す

ユーザーが入力したシーンから、人生の美しさを発見し、ユニークで繊細な小吉を感じてください。

ステップ1.
小さな幸せを発見する

-哲学
世界には、日常には、大きな愛がある
-コンセプト：日常の中に大きな愛がある。
プロセス
1.
不幸の中の幸運
2.
ミクロの視点
3.
ユニークな経験
4.
偶然のセレンディピティ
5.
人生の肯定
6.
優しい気持ち

ステップ2：小さな祝福を表現する

-アイデア:優しく穏やかな表現、暖かさが流れる。
-処理の流れ
1.温かい表情
2.
文章を推敲する

数撃ちゃ当たるの学習例

|入出力
|入力｜出力
|--------|--------------------------------|
|バス待ち|バスはタイミングよく来た！
|スレッド
|overcast|曇り空の中の突然の晴れ間

要件
1.ステップ・バイ・ステップで考え、大きなステップだけでなく、処理の流れも厳密に守る。

### SVGカードの生成

以下の SVG カードデザイン仕様は XML
形式で与えられる)：

``XML


 ネガティブ・スペースを適度に使用し、タイポグラフィ全体が呼吸しているような感覚を持つこと</デザイン原則
 <基本要件

<項目>ポリッジ</p項目>
 <項目>ピチピチ</p項目>

<項目>エレガンス</p項目>
 </基本要件

 <セットアップ・キャンバス

<幅420<高さ600<マージン20</margin
 

 <オートスケール

<最小フォントサイズ24</最小フォントサイズ
 </自動ズーム

 <配色

<背景色
 <モンドリアンスタイル
 <暖かさ
 <快適さ

</背景色
 </配色

 <ネイティブ・フォントを使用する
 <フォント
家族>FZYanSongS-R-GB</pフォントファミリー>
 </ネイティブフォントを使う

<カード要素
 小さな確かなもの</中央のタイトル
 <区切り記号

<緑のサブタイトル
 <自動改行
 <項目>あなたは言う。</p項目>

<項目>{ユーザー入力｝</p項目>
 </自動改行
 </緑の小見出し

<赤の小見出し
 <自動改行
 <項目>あーあ！</p項目>

<項目>{レスポンス}。</p項目>
 </自動改行
 </赤字のサブタイトル

<長方形エリア
 <キュービズム
 <抽象化された線

{レスポンス}</フレーム枠
 </抽象線
 </cubism

</矩形領域
 </card要素
</svg

運営規定

ユーザー入力後、まず「小確証表現生成」が呼び出され、次に「SVGカード生成」が呼び出される。

最後に、この実験をしている間に私の頭の中で引き起こされたRandomThoughtsの断片を掲載する：

> ある媒体から別の媒体に再生されるとき、意味論も屈折を受けるのではないですか？もしそうなら、分散も起こる可能性があるのでは？意味論的な分散によって形成された虹が見える可能性はないのでしょうか :🌈:?
>
> 一人から多数へ。無色からカラフルへ。
>
> 直接的には区別できなかった隠れた属性や意味合いが、直感的に見えるようになる。
>
> そんなことができる媒体があるだろうか？
>
> 媒体だけでは十分ではなく、思考活動が必要で、その思考活動とは何だろうか？類推？