Từ prompt đến mascot chuyển động trong Codex

Một mascot trong giao diện Codex có thể nghiêng đầu khi agent bắt đầu xử lý, chuyển sang animation khác lúc chờ tool call, rồi phản hồi khi tác vụ hoàn tất. Nhìn từ bên ngoài, đây chỉ là một nhân vật nhỏ chuyển động cạnh cửa sổ làm việc. Nhưng để vài chục frame tạo thành một nhân vật nhất quán, pipeline phải phối hợp mô hình tạo ảnh, code xử lý asset và một state machine trong runtime.

OpenAI từng giới thiệu trải nghiệm Codex Pet Arena, nơi các Codex pet xuất hiện như một lớp biểu đạt trực quan cho hoạt động của agent.¹ Tuy nhiên, tài liệu công khai không mô tả toàn bộ implementation nội bộ của tính năng này. Vì vậy, cơ chế trong bài nên được hiểu là một kiến trúc thực hành để tạo mascot tương thích với ứng dụng kiểu Codex, không phải bản reverse-engineering hay mô tả chính thức về code đang chạy trong sản phẩm.

Điểm cần phân biệt ngay từ đầu là GPT Image không trực tiếp tạo ra “một mascot biết chuyển động”. Mô hình sinh hoặc chỉnh sửa ảnh raster. Phần còn lại, từ chia trạng thái, giữ nhận dạng nhân vật, chuẩn hoá từng frame cho tới quyết định khi nào phát animation nào, thuộc về pipeline xây dựng asset và runtime của ứng dụng.

Mascot là một giao diện trạng thái

Nếu chỉ xem mascot như vật trang trí, nhóm phát triển rất dễ bắt đầu bằng một prompt dài rồi yêu cầu mô hình sinh hàng loạt tư thế. Cách tiếp cận này có thể tạo ra vài ảnh đẹp, nhưng chưa chắc tạo được một hệ animation dùng được. Mascot trong ứng dụng còn đóng vai trò biểu đạt trạng thái: người dùng nhìn vào chuyển động để đoán agent đang xử lý, đang chờ kết quả, đã hoàn tất hay gặp lỗi.

Vì vậy, thiết kế nên bắt đầu từ tập trạng thái mà giao diện cần truyền đạt. Một bộ tối thiểu có thể gồm:

idle: không có tác vụ đang chạy;
starting: agent vừa nhận yêu cầu và chuẩn bị xử lý;
working: runtime đang thực thi một bước công việc;
waiting: agent đang chờ dữ liệu hoặc kết quả từ tool call;
success: tác vụ đã hoàn tất;
error: bước thực thi thất bại hoặc cần người dùng can thiệp.

Danh sách này không nhất thiết ánh xạ một-một với trạng thái nội bộ của agent. Runtime có thể có hàng chục event kỹ thuật, trong khi mascot chỉ cần vài trạng thái đủ rõ để người dùng nhận biết. Nếu mỗi event nhỏ đều kích hoạt một animation riêng, nhân vật sẽ đổi động tác liên tục và tạo tín hiệu nhiễu. Thiết kế tốt thường gom nhiều event có ý nghĩa giao diện tương đương vào cùng một trạng thái hiển thị.

stateDiagram-v2
    [*] --> Idle
    Idle --> Starting: nhận tác vụ
    Starting --> Working: bắt đầu xử lý
    Working --> Waiting: chờ tool hoặc dữ liệu
    Waiting --> Working: nhận kết quả trung gian
    Working --> Success: hoàn tất
    Working --> Error: bước xử lý thất bại
    Waiting --> Error: tool trả lỗi hoặc hết thời gian
    Success --> Idle: phát xong animation
    Error --> Idle: lỗi được ghi nhận

Nguồn công khai chỉ giới thiệu Codex Pet Arena như một sản phẩm được xây dựng bằng Codex, không cho thấy state machine trong sơ đồ trên thuộc runtime của Codex hay Codex Pet. Sơ đồ này là thiết kế giả định cho một ứng dụng mascot; nếu triển khai kiến trúc đó, runtime của ứng dụng có thể áp dụng các quy tắc sau:

Thời lượng hiển thị tối thiểu: giữ starting, success và error đủ lâu để người dùng nhận biết, nhưng không kéo dài đến mức phản ánh sai tiến độ của tác vụ.
Ưu tiên trạng thái: cho phép error ngắt starting, working hoặc waiting; chỉ chuyển sang success sau khi ứng dụng nhận được event xác nhận tác vụ hoàn tất.
Khả năng ngắt animation: cho phép dừng các animation lặp như working và waiting khi có event mới; animation phản hồi như success có thể phát hết một lần trước khi trở về idle.
Loại bỏ event lỗi thời: đối chiếu taskId, timestamp hoặc sequence number để kết quả của tác vụ cũ không thay đổi trạng thái mascot hiện tại.
Giảm chuyển trạng thái liên tục: gom hoặc trì hoãn trong một khoảng ngắn các event đến sát nhau, tránh để mascot đổi animation nhiều lần chỉ trong vài chục mili giây.
Trạng thái dự phòng: khi event chưa được ánh xạ hoặc asset không hợp lệ, giữ trạng thái hiện tại hoặc trở về idle theo quy tắc do ứng dụng xác định.

Mô hình tạo ảnh không gánh toàn bộ pipeline

GPT Image có thể sinh ảnh mới từ prompt hoặc chỉnh sửa ảnh đã có. Theo tài liệu OpenAI, Image API phù hợp với một lượt generate hoặc edit, còn Responses API hỗ trợ quy trình nhiều lượt, trong đó ảnh có thể tiếp tục được tinh chỉnh qua conversation context.² Khả năng edit theo ảnh tham chiếu đặc biệt hữu ích khi cần giữ đặc điểm nhân vật giữa nhiều tư thế.

Dù vậy, output vẫn là ảnh raster. Ảnh đó chưa chứa quy tắc chuyển trạng thái, thời gian phát, vùng va chạm hay thông tin về thứ tự frame. Một pipeline hoàn chỉnh thường đi qua các bước sau:

flowchart LR
    A[Đặc tả nhân vật] --> B[Ảnh tham chiếu chuẩn]
    B --> C[Đặc tả animation]
    C --> D[Sinh hoặc edit frame]
    D --> E[Chuẩn hoá hình học]
    E --> F[Đóng gói spritesheet]
    F --> G[Kiểm tra asset]
    G --> H[Manifest animation]
    H --> I[Runtime state machine]

Ranh giới trách nhiệm trong pipeline này khá rõ. Mô hình tạo ảnh đề xuất pixel; code xác định pixel nào đạt chuẩn, được đặt ở đâu và sẽ xuất hiện vào thời điểm nào. Khi tách hai phần như vậy, nhóm phát triển có thể thay mô hình tạo ảnh mà không phải viết lại state machine, hoặc điều chỉnh tốc độ animation mà không cần generate lại toàn bộ nhân vật.

Đặc tả nhân vật trước khi viết prompt

Một prompt đơn lẻ thường trộn ba lớp yêu cầu: nhân vật trông như thế nào, nhân vật đang làm gì và ảnh phải được xuất theo định dạng nào. Khi một frame có lỗi, cách trộn này khiến người làm khó xác định vấn đề nằm ở thiết kế nhân vật, chuyển động hay bố cục kỹ thuật.

Trong Codex, có thể gọi image generation bằng $imagegen rồi tổ chức instruction thành các phần có nhãn rõ ràng. Chẳng hạn:

$imagegen
Create one animation frame for a Codex mascot.

CHARACTER:
Preserve the mascot's body proportions, eye shape, teal terminal badge,
dark navy outline, color palette, camera angle, and lighting from the
canonical reference image.

ACTION:
Show the mascot leaning slightly toward a terminal while both hands move
through one step of a short, seamless working loop. Keep the torso and
feet anchored to their reference positions.

OUTPUT CONSTRAINTS:
Use a 1024 × 1024 canvas with a transparent background. Keep the full body
inside a 12% safe margin. Add no text, shadow, border, watermark, extra
accessories, or additional characters.

Change only the pose required for this frame. Keep every other visual
property consistent with the reference image.
```.

Cách có kiểm soát hơn là tách đặc tả thành ba phần. Phần đầu là **character bible**, tức tập thuộc tính nhận dạng không nên thay đổi giữa các frame. Nó có thể ghi rõ tỷ lệ đầu và thân, hình dạng mắt, số lượng phụ kiện, bảng màu, độ dày đường viền, hướng chiếu sáng và mức độ chi tiết của texture.

Phần thứ hai là đặc tả chuyển động. Với animation `working`, chẳng hạn, cần mô tả bộ phận nào di chuyển, biên độ bao nhiêu, chuyển động có lặp liền mạch hay không và frame đầu phải nối với frame cuối thế nào. “Đang làm việc” là một nhãn ngữ nghĩa, chưa phải mô tả chuyển động. Một đặc tả hữu dụng hơn có thể yêu cầu nhân vật cúi nhẹ về phía màn hình, hai tay thay đổi vị trí theo chu kỳ và thân giữ gần như cố định để hạn chế rung.

Phần cuối là ràng buộc xuất ảnh: canvas vuông hay chữ nhật, nền trong suốt, camera cố định, toàn bộ cơ thể nằm trong safe area và không có chữ. Đây là những điều kiện phục vụ code xử lý asset, không phải đặc điểm sáng tạo của nhân vật.

Có thể biểu diễn đặc tả dưới dạng dữ liệu để tái sử dụng giữa các lượt generate:

```json
{
  "character": {
    "bodyRatio": "large head, compact body",
    "outline": "dark navy, consistent thickness",
    "palette": ["#0b1120", "#5eead4", "#f8fafc"],
    "accessories": ["teal terminal badge"],
    "camera": "fixed three-quarter view"
  },
  "render": {
    "canvas": "1024x1024",
    "background": "transparent",
    "safeMargin": "12%",
    "shadow": "none"
  }
}

JSON không làm mô hình tự động tuân thủ tuyệt đối, nhưng nó giúp pipeline duy trì một nguồn đặc tả ổn định. Khi cần sửa màu huy hiệu hoặc safe margin, nhóm phát triển thay đổi đúng trường liên quan thay vì viết lại toàn bộ prompt bằng văn xuôi.

Ảnh tham chiếu là điểm neo nhận dạng

Nếu generate từng frame độc lập chỉ bằng text prompt, các thuộc tính nhỏ có thể thay đổi qua mỗi lượt: tai dài thêm, mắt lệch tỷ lệ, phụ kiện đổi bên hoặc bảng màu dịch nhẹ. Mỗi ảnh riêng lẻ vẫn có thể đẹp, nhưng khi phát liên tiếp, sai lệch biến thành hiện tượng rung và méo hình.

Một quy trình thực tế thường chọn một canonical reference, tức ảnh tham chiếu chuẩn thể hiện rõ nhất thiết kế nhân vật. Các animation tiếp theo được tạo bằng edit hoặc quy trình nhiều lượt dựa trên ảnh này. Mục tiêu không phải sao chép nguyên tư thế, mà giữ các thuộc tính nhận dạng trong khi thay đổi pose.

Để giảm sai lệch tích luỹ, mỗi nhánh animation nên quay lại ảnh tham chiếu chuẩn thay vì liên tục edit từ frame ngay trước đó. Nếu frame 2 được tạo từ frame 1, frame 3 lại được tạo từ frame 2, một biến đổi nhỏ có thể được khuếch đại qua chuỗi edit. Cách tạo theo nhánh giúp các frame cùng phụ thuộc vào một điểm neo ổn định hơn:

flowchart TD
    R[Ảnh tham chiếu chuẩn] --> I[Nhánh idle]
    R --> W[Nhánh working]
    R --> S[Nhánh success]
    R --> E[Nhánh error]
    I --> I1[Các frame idle]
    W --> W1[Các frame working]
    S --> S1[Các frame success]
    E --> E1[Các frame error]

Với chuyển động phức tạp, pipeline có thể tạo trước một pose sheet gồm các key pose, chọn những pose đạt yêu cầu rồi mới sinh frame trung gian. Cách này cho phép kiểm tra quỹ đạo chuyển động trước khi tốn thêm lượt generate. Nó cũng giảm nguy cơ hoàn thành cả spritesheet rồi mới phát hiện frame đầu và frame cuối không tạo được vòng lặp liền mạch.

Từ candidate tới frame đạt chuẩn

Output đầu tiên của mô hình nên được coi là visual candidate, không phải asset sẵn sàng đưa vào runtime. Sau bước sinh ảnh, code hoặc công cụ xử lý ảnh cần thực hiện một chuỗi chuẩn hoá có tính xác định.

Trước hết là xử lý nền và alpha channel. Nếu mascot cần đặt trên nhiều màu giao diện, các pixel bán trong suốt quanh đường viền phải được kiểm tra để tránh viền sáng hoặc tối bất thường. Tiếp đó, pipeline xác định bounding box của vùng có nội dung, đo khoảng cách đến bốn cạnh canvas và loại các frame có bộ phận bị cắt.

Bước căn chỉnh không nên chỉ đặt tâm bounding box vào giữa canvas. Khi tay hoặc đuôi vươn ra, bounding box thay đổi dù phần thân gần như đứng yên. Nếu căn theo tâm hình học của toàn bộ pixel, thân nhân vật sẽ dịch qua lại giữa các frame. Một anchor ổn định hơn có thể là vị trí bàn chân, tâm thân hoặc một landmark được xác định trước.

Giả sử vị trí anchor của frame thứ $t$ là $(x_t, y_t)$ và vị trí chuẩn là $(x_0, y_0)$ . Phép dịch cần áp dụng cho frame đó là:

\Delta x_t = x_0 - x_t, \qquad \Delta y_t = y_0 - y_t

Sau khi căn chỉnh, pipeline có thể đo mức dịch chuyển còn lại của trọng tâm hoặc landmark qua toàn bộ chuỗi. Con số lớn không mặc nhiên là lỗi, vì một animation di chuyển đương nhiên phải thay đổi vị trí. Điều quan trọng là phép đo phải phù hợp với đặc tả: idle nên có dao động nhỏ, còn jump có thể dịch chuyển theo quỹ đạo rõ ràng.

Các kiểm tra tự động hữu ích gồm:

mọi frame có cùng chiều rộng, chiều cao và định dạng màu;
alpha channel tồn tại và không chứa nền ngoài ý muốn;
nội dung không vượt safe area;
anchor nằm trong khoảng sai số cho phép;
thứ tự frame khớp với manifest;
animation lặp có độ chênh hợp lý giữa frame cuối và frame đầu;
tên file, số frame và số cột của spritesheet nhất quán.

Tự động hoá không thay thế kiểm tra bằng mắt. Một frame có thể vượt qua toàn bộ điều kiện kích thước nhưng vẫn đổi số ngón tay, làm méo huy hiệu hoặc thay hướng ánh sáng. Vì vậy, visual QA cần xem cả contact sheet và animation đang phát ở tốc độ thực.

Spritesheet và manifest chia sẻ một hợp đồng

Khi các frame đã đạt chuẩn, pipeline đóng gói chúng vào spritesheet. Cách phổ biến là mỗi hàng biểu diễn một animation, còn các cột chứa frame theo thứ tự thời gian. Quy ước này dễ đọc và phù hợp với runtime chỉ cần tính toạ độ crop.

Tuy nhiên, spritesheet tự nó không cho biết hàng thứ hai có ý nghĩa gì, chạy ở tốc độ nào hoặc có lặp hay không. Manifest đảm nhiệm phần hợp đồng đó:

{
  "spriteVersion": 2,
  "frame": { "width": 256, "height": 256 },
  "animations": {
    "idle": {
      "row": 0,
      "frames": 6,
      "fps": 8,
      "loop": true,
      "interruptible": true
    },
    "working": {
      "row": 1,
      "frames": 8,
      "fps": 12,
      "loop": true,
      "interruptible": true
    },
    "success": {
      "row": 2,
      "frames": 5,
      "fps": 10,
      "loop": false,
      "next": "idle"
    },
    "error": {
      "row": 3,
      "frames": 6,
      "fps": 8,
      "loop": false,
      "next": "idle"
    }
  }
}

Trường spriteVersion giúp runtime từ chối asset không tương thích thay vì crop sai mà không báo lỗi. interruptible cho biết animation có thể bị ngắt khi trạng thái mới xuất hiện hay phải phát hết chu kỳ. next xác định trạng thái hiển thị tiếp theo đối với animation không lặp.

Version của schema và version của nội dung nên được quản lý riêng. Thay một frame bị lỗi không nhất thiết làm thay đổi cấu trúc manifest; ngược lại, thêm trường mới vào schema có thể yêu cầu runtime cập nhật dù hình ảnh không đổi.

Runtime không suy luận lại hình ảnh

Khi ứng dụng chạy, runtime không cần hỏi mô hình xem nhân vật nên làm gì. Nó nhận event từ hệ thống, ánh xạ event sang trạng thái hiển thị rồi chọn animation trong manifest. Phần sinh ảnh đã kết thúc trước đó; hành vi lúc chạy cần có tính xác định.

Một hàm ánh xạ tối giản có thể trông như sau:

type AgentEvent =
  | "task_received"
  | "step_started"
  | "tool_waiting"
  | "tool_resolved"
  | "task_succeeded"
  | "task_failed";

type PetState =
  | "idle"
  | "starting"
  | "working"
  | "waiting"
  | "success"
  | "error";

function reducePetState(state: PetState, event: AgentEvent): PetState {
  switch (event) {
    case "task_received":
      return "starting";
    case "step_started":
    case "tool_resolved":
      return "working";
    case "tool_waiting":
      return "waiting";
    case "task_succeeded":
      return "success";
    case "task_failed":
      return "error";
    default:
      return state;
  }
}

Implementation thật cần xử lý nhiều điều kiện hơn. Event có thể đến liên tiếp trong vài mili giây, tool call có thể chạy song song, còn kết quả của một tác vụ cũ có thể xuất hiện sau khi giao diện đã chuyển sang tác vụ mới. Vì thế, reducer thường cần taskId, timestamp hoặc sequence number để bỏ qua event đã lỗi thời.

Runtime cũng nên áp dụng minimum display duration cho các trạng thái cần được nhận biết. Nếu success lập tức chuyển sang idle, người dùng có thể không thấy phản hồi hoàn tất. Ngược lại, working không nên bị giữ chỉ để phát hết animation khi hệ thống đã báo lỗi. Quy tắc ưu tiên có thể cho phép error ngắt working, trong khi success được phát hết một lần trước khi trở lại idle.

Tính nhất quán khó hơn chất lượng của từng ảnh

Một frame có độ chi tiết cao chưa chắc làm animation tốt hơn. Với mascot kích thước nhỏ, texture phức tạp hoặc ánh sáng nhiều lớp có thể thay đổi giữa các frame và tạo nhiễu thị giác. Tính nhất quán của silhouette, bảng màu và anchor thường quan trọng hơn độ chi tiết của từng ảnh.

Các lỗi phổ biến có thể chia thành ba nhóm. Nhóm đầu là identity drift: hình dạng mắt, tai, phụ kiện hoặc tỷ lệ cơ thể thay đổi. Nhóm thứ hai là geometric jitter: nhân vật dịch vị trí, thay kích thước hoặc xoay camera ngoài chủ đích. Nhóm cuối là temporal discontinuity: hai frame liền nhau có khoảng biến đổi quá lớn, hoặc frame cuối không nối được với frame đầu trong animation lặp.

Mỗi nhóm lỗi cần cách sửa khác nhau. Identity drift thường đòi hỏi quay lại ảnh tham chiếu và edit riêng frame lỗi. Geometric jitter có thể được giảm bằng anchor alignment nếu bản thân hình dạng vẫn đúng. Temporal discontinuity có thể cần thêm frame trung gian hoặc sắp xếp lại chuỗi. Dùng một phép xử lý chung cho mọi lỗi, chẳng hạn resize và căn giữa toàn bộ ảnh, có thể che triệu chứng nhưng không sửa nguyên nhân.

Hiệu năng, khả năng truy cập và chế độ giảm chuyển động

Mascot là một phần của giao diện, nên asset pipeline chưa hoàn tất nếu chỉ kiểm tra hình ảnh. Spritesheet quá lớn sẽ tăng thời gian tải và mức sử dụng bộ nhớ đồ hoạ. Nhiều animation phát đồng thời cũng có thể làm tăng chi phí render, nhất là khi ứng dụng hiển thị nhiều agent trong cùng một cửa sổ.

Runtime cần cân bằng độ phân giải frame, số lượng frame và tốc độ phát. Tăng fps không tự động làm chuyển động tốt hơn nếu các pose gần như giống nhau. Trong nhiều trường hợp, ít frame nhưng quỹ đạo rõ và timing hợp lý đem lại kết quả dễ đọc hơn.

Ứng dụng cũng nên tôn trọng thiết lập prefers-reduced-motion. Khi người dùng chọn giảm chuyển động, runtime có thể giữ một frame tĩnh cho mỗi trạng thái hoặc dùng thay đổi nhỏ về biểu cảm thay vì phát animation liên tục. Điều này không chỉ phục vụ khả năng truy cập; nó còn buộc thiết kế chứng minh rằng trạng thái vẫn có thể được nhận biết khi bỏ chuyển động.

Mascot không nên là kênh duy nhất báo lỗi hoặc hoàn tất. Màu sắc, text và trạng thái của control vẫn phải truyền đạt thông tin chính. Animation là tín hiệu bổ trợ, vì có người dùng không nhìn thấy mascot, không phân biệt được màu hoặc đã tắt chuyển động.

Một pipeline có thể tái tạo

Mô hình sinh ảnh có yếu tố biến thiên, nên pipeline cần lưu đủ metadata để giải thích một asset được tạo ra như thế nào. Tối thiểu, mỗi lần generate nên ghi lại prompt, ảnh tham chiếu, model, kích thước output, thời điểm tạo và quan hệ giữa candidate với animation đích. Nếu API hoặc công cụ hỗ trợ seed hay tham số phiên bản, các giá trị đó cũng nên được lưu.

Không phải mọi output đều có thể tái tạo chính xác từng pixel. Mục tiêu thực tế hơn là tái tạo được quy trình: biết candidate nào đã được chọn, qua các bước xử lý nào, dùng manifest phiên bản nào và vượt qua những kiểm tra nào. Một báo cáo build asset có thể gồm checksum của ảnh nguồn, checksum của spritesheet, kết quả validator và ảnh contact sheet dùng cho visual QA.

Cách tổ chức này còn giúp review thay đổi. Khi một pull request thay spritesheet, reviewer có thể đối chiếu frame nào đổi, manifest có đổi theo không và animation mới đã được kiểm tra ở trạng thái nào. Nếu chỉ commit một file ảnh lớn mà không có metadata, phần thay đổi gần như trở thành hộp đen.

Khi nào nên generate lại, khi nào nên sửa bằng code?

Không có một câu trả lời chung cho mọi lỗi. Có thể dùng một ranh giới thực hành như sau:

Vấn đề	Cách xử lý phù hợp hơn
Sai hình dạng mắt, tai hoặc phụ kiện	Edit hoặc generate lại frame
Nhân vật lệch vài pixel nhưng hình dạng đúng	Căn chỉnh bằng code
Nền chưa trong suốt hoàn toàn	Xử lý alpha, sau đó kiểm tra viền
Frame cuối không nối được frame đầu	Sửa pose hoặc thêm frame trung gian
Tốc độ chuyển động không phù hợp	Điều chỉnh manifest hoặc timing runtime
Trạng thái hiển thị sai event	Sửa reducer hoặc state machine
Spritesheet crop sai	Sửa quy ước đóng gói hoặc metadata

Ranh giới này ngăn mô hình tạo ảnh phải giải quyết những vấn đề vốn có đáp án xác định bằng code. Đồng thời, nó tránh dùng phép biến đổi hình học để sửa một frame đã sai nhận dạng. Resize có thể làm hai ảnh bằng kích thước, nhưng không thể khôi phục phụ kiện đã biến mất.

Từ một ảnh đẹp tới một thành phần phần mềm

Theo cách tôi nhìn nhận, GPT Image phù hợp nhất với vai trò tạo và chỉnh sửa visual candidate. Khả năng generate và edit giúp mở rộng không gian thiết kế, thử nhiều pose và duy trì nhân vật dựa trên ảnh tham chiếu. Nhưng sự linh hoạt đó chỉ trở thành asset dùng được khi được đặt trong một pipeline có ràng buộc rõ ràng.

Mẫu Node.js dưới đây tạo một candidate cho frame idle bằng Image API. Vì gpt-image-2 không xuất nền trong suốt, prompt yêu cầu một nền chroma key phẳng để pipeline tách nền ở bước kế tiếp:

import fs from "node:fs";
import OpenAI from "openai";

const openai = new OpenAI();

const prompt = `
Create one idle animation frame for a small Codex mascot.

CHARACTER:
A compact robot with a large head, dark navy outline, white body,
teal terminal badge, fixed three-quarter camera view and soft lighting.

ACTION:
The mascot stands still with both feet anchored, looking toward a terminal.
Keep the pose suitable as the first frame of a subtle breathing loop.

OUTPUT CONSTRAINTS:
Use a 1024 × 1024 canvas. Place the character on a perfectly flat solid
#ff00ff chroma-key background with no shadow, gradient or texture.
Keep the full body inside a 12% safe margin. Do not use #ff00ff on the
character. Add no text, border, watermark or extra object.
`;

const result = await openai.images.generate({
  model: "gpt-image-2",
  prompt,
  size: "1024x1024",
  quality: "high"
});

const imageBase64 = result.data[0]?.b64_json;
if (!imageBase64) throw new Error("Image API không trả về dữ liệu ảnh");

fs.mkdirSync("frames/idle", { recursive: true });
fs.writeFileSync(
  "frames/idle/candidate-01.png",
  Buffer.from(imageBase64, "base64")
);

File candidate-01.png vẫn chỉ là đầu vào của pipeline. Code xử lý asset cần loại nền chroma key, chuẩn hoá canvas, giữ anchor, kiểm tra alpha channel, đóng gói spritesheet và xác thực manifest. Runtime chịu trách nhiệm ánh xạ event sang trạng thái, xử lý ưu tiên và phát animation theo timing xác định. Visual QA kiểm tra những sai lệch mà phép đo tự động chưa phát hiện. Ba phần này bổ sung cho nhau; không phần nào có thể thay thế hoàn toàn hai phần còn lại.

Một mascot hoạt động ổn định vì hệ thống biết chính xác frame nào được phát, lúc nào được phát và điều kiện nào kết thúc chuyển động. Mô hình tạo ảnh cung cấp nguyên liệu thị giác. Pipeline mới là thứ biến nguyên liệu đó thành một thành phần phần mềm có thể kiểm tra, version và vận hành lâu dài.

Tài liệu tham khảo

OpenAI. Codex Pet Arena. OpenAI Developers Showcase.
OpenAI. Image generation. OpenAI API Documentation.