Kimi K3 ਨਾਲ Lulucat Notes ਦੀ ਰੈਂਡਰਿੰਗ ਪਾਈਪਲਾਈਨ ਨੂੰ ਮੁੜ ਬਣਾਉਣਾ

ਪਿਛਲੇ ਹਫ਼ਤੇ, Lulucat Notes ਵਿੱਚ lasso selection ਨੂੰ ਘਸੀਟਣ ਨਾਲ ਇੱਕ ਦਿਸਣਯੋਗ ਲਹਿਰ ਬਣੀ: ਕੁਝ screen tiles ਨੇ selection ਨੂੰ ਇਸ ਦੀ ਨਵੀਂ ਥਾਂ ਉੱਤੇ ਵਿਖਾਇਆ, ਜਦਕਿ ਹੋਰਾਂ ਨੇ ਉਸੇ frame ਵਿੱਚ ਅਜੇ ਵੀ ਪੁਰਾਣੀ ਥਾਂ ਵਿਖਾਈ। ਅਸੀਂ ਪੂਰੀ ਰੈਂਡਰਿੰਗ ਪਾਈਪਲਾਈਨ — Core Graphics bitmap ਅਤੇ CATiledLayer — ਨੂੰ Metal ਨਾਲ ਬਦਲ ਦਿੱਤਾ, ਛੇ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ; ਅਗਲਾ ਕਦਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਕਦਮ ਨੂੰ ਅਸਲ iPad ਉੱਤੇ ਜਾਂਚਿਆ ਗਿਆ।

ਇਸ ਲੇਖ ਦੇ ਦੂਜੇ ਅੱਧ ਲਈ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲੀ ਇੱਕ ਹੋਰ ਗੱਲ: ਕੋਡ Fireworks ਉੱਤੇ ਚੱਲ ਰਹੇ Moonshot ਦੇ open model Kimi K3 ਨਾਲ pair-programming ਕਰਕੇ ਲਿਖਿਆ ਗਿਆ। ਮਨੁੱਖ ਨੇ ਦਿਸ਼ਾ ਦਿੱਤੀ, ਫ਼ੈਸਲੇ ਕੀਤੇ ਅਤੇ ਜਾਂਚ ਕੀਤੀ; model ਨੇ ਲਗਭਗ ਹਰ ਲਾਈਨ ਲਿਖੀ।

ਪਾਈਪਲਾਈਨ

ਪੁਰਾਣੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ drawing ਦੇ ਦੋ ਤਰੀਕੇ ਸਨ ਜੋ ਹੌਲੀ-ਹੌਲੀ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਹੁੰਦੇ ਗਏ: ਸਸਤੀ display ਲਈ strokes ਨੂੰ bitmap ਵਿੱਚ bake ਕੀਤਾ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਜਦੋਂ tiles ਨੂੰ ਹੋਰ detail ਦੀ ਲੋੜ ਹੁੰਦੀ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ vectors ਵਜੋਂ ਮੁੜ ਖਿੱਚਿਆ ਜਾਂਦਾ ਸੀ। ਨਵੀਂ ਪਾਈਪਲਾਈਨ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਵਿਚਾਰ ਹੈ: ink ਵਰਗੀ ਹਰ ਚੀਜ਼ ਇੱਕ point sprite ਹੈ। ਇੱਕ pen stroke, ਇੱਕ highlighter sweep ਅਤੇ eraser ਦਾ ਇੱਕ dab ਇੱਕੋ 32-byte vertex ਹਨ — position, diameter, color — ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹੀ shader pair stroke ਦੀ arc length ਦੇ ਨਾਲ ਇੱਕ point ਦੇ ਫ਼ਾਸਲੇ ਉੱਤੇ ਰੱਖੇ GPU-rasterized circles ਵਜੋਂ ਖਿੱਚਦਾ ਹੈ।

ਇੱਕ point ਦੇ ਫ਼ਾਸਲੇ ਉੱਤੇ circles ਦੀ ਲੜੀ mathematically perfect capsule ਤੋਂ ਲਗਭਗ 0.075 points ਹਟਦੀ ਹੈ — ਸਾਡੇ canvas density ਉੱਤੇ ਇੱਕ pixel ਦਾ ਪੰਜਵਾਂ ਹਿੱਸਾ। ਬਦਲੇ ਵਿੱਚ, ਤਿੰਨੇ tools ਇੱਕ code path ਵਿੱਚ ਸਮਾ ਜਾਂਦੇ ਹਨ, ਅਤੇ GPU ਉਹੀ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ।

ਉਸ ਵਿਚਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ architecture ਸਧਾਰਨ ਹੈ। Committed ink ਇੱਕੋ 4096² texture ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। UIScrollView ਬਚੀ ਰਹਿੰਦੀ ਹੈ, ਪਰ ਸਿਰਫ਼ gesture engine ਵਜੋਂ: ਇਸ ਦਾ contentOffset ਅਤੇ zoomScale ਹਰ frame ਇੱਕ viewport uniform ਨੂੰ feed ਕਰਦੇ ਹਨ, ਇਸ ਲਈ panning ਅਤੇ zooming ਕੁਝ ਨਹੀਂ ਲਿਖਦੇ। ਹਰ frame ਵਿੱਚ ਪੰਜ draws ਹੁੰਦੇ ਹਨ:

flowchart TB
    subgraph frame["Every frame: five draws"]
        direction TB
        paper["1 · paper blit"] --> ink["2 · committed ink"]
        ink --> live["3 · live stroke"]
        live --> sel["4 · selection"]
        sel --> dash["5 · lasso dashes"]
    end
    commit["stroke commit<br/>append stamps"] --> tex[("ink texture<br/>4096² render target")]
    replay["regional replay<br/>erase · delete · move · undo"] --> tex
    tex -. "sampled or re-drawn" .-> ink

Edits ਸਿੱਧੇ texture ਵਿੱਚ ਲਿਖਦੇ ਹਨ। ਕਿਸੇ stroke ਨੂੰ commit ਕਰਨ ਨਾਲ ਉਸ ਦੀਆਂ stamps append ਹੁੰਦੀਆਂ ਹਨ। Erasing, deleting, moving ਅਤੇ undoing ਪ੍ਰਭਾਵਿਤ region ਨੂੰ ਇੱਕ scissor rectangle ਦੇ ਪਿੱਛੇ replay ਕਰਦੇ ਹਨ: region clear ਕਰੋ, ਉਸ ਨੂੰ intersect ਕਰਨ ਵਾਲੇ strokes ਮੁੜ ਖਿੱਚੋ, ਬੱਸ। Partial erasure ਪਿਛਲੀ post ਦੀ ownership semantics ਕਾਇਮ ਰੱਖਦੀ ਹੈ — ਇੱਕ erasure ਉਸ stroke ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚੋਂ ਇਹ ink ਹਟਾਉਂਦੀ ਹੈ — ਹਰ erased stroke ਨੂੰ scratch texture ਵਿੱਚ ਖਿੱਚ ਕੇ, destination-out blending () ਨਾਲ ਇਸ ਦੇ ਆਪਣੇ erasure paths ਘਟਾ ਕੇ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਵਾਪਸ composite ਕਰਕੇ। Scratch isolation ਹੀ eraser ਨੂੰ paper ਜਾਂ ਨੇੜਲੇ strokes ਵਿੱਚੋਂ ਦੀ ਵੱਢ ਕੇ ਲੰਘਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।

ਜਿਸ selection ਨੇ ਇਹ ਸਭ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ, ਉਹ ਹੁਣ point sprites ਵਜੋਂ ਵੀ ਖਿੱਚੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਨੂੰ drag ਕਰਨ ਨਾਲ ਇੱਕ uniform offset update ਹੁੰਦਾ ਹੈ। Zero texture writes, zero tile invalidations — ਲਹਿਰ ਢਾਂਚਾਗਤ ਤੌਰ ਉੱਤੇ ਗਾਇਬ ਹੈ, ਸਿਰਫ਼ ਘੱਟ ਨਹੀਂ ਕੀਤੀ ਗਈ।

ਗੇਟਕੀਪਰ: ਇੱਕ pixel diff

ਅਸੀਂ Core Graphics renderer ਨੂੰ delete ਨਹੀਂ ਕੀਤਾ। ਅਸੀਂ ਇਸ ਨੂੰ ਇੱਕ offline reference implementation ਬਣਾ ਦਿੱਤਾ, ਅਤੇ ਹਰ Metal change ਨੂੰ device ਉੱਤੇ capture ਕੀਤੇ ਅਸਲ stroke data ਉੱਤੇ ਇਸ ਦੇ ਵਿਰੁੱਧ pixel comparison ਪਾਸ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। Acceptance criterion “identical pixels” ਨਹੀਂ ਹੈ — ਦੋ ਸਹੀ rasterizers anti-aliased edges ਦੇ ਨਾਲ ਕੁਝ gray levels ਤੱਕ ਜਾਇਜ਼ ਤੌਰ ਉੱਤੇ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। Gate structural ਹੈ: ਕੋਈ missing ink ਨਹੀਂ, ਕੋਈ offset ਨਹੀਂ, ਕੋਈ color drift ਨਹੀਂ, ਅਤੇ ink ਤੋਂ ਦੂਰ ਕਿਤੇ ਵੀ ਕੋਈ ਵੱਡਾ ਫ਼ਰਕ ਨਹੀਂ।

ਇਸ harness ਨੇ offline renderer ਬਣਾਉਂਦੇ ਸਮੇਂ ਆਏ ਪੰਜ bugs ਵਿੱਚੋਂ ਚਾਰ ਫੜ ਲਏ; ਹਰ bug ਨੂੰ output ਨੂੰ pixel level ਤੱਕ crop ਕਰਕੇ ਪਛਾਣਿਆ ਗਿਆ: Swift/Metal struct stride mismatch (28 bytes ਬਨਾਮ 32, ਕਿਉਂਕਿ Metal float4 ਨੂੰ 16 ਉੱਤੇ align ਕਰਦਾ ਹੈ — screen ਰੰਗੀਨ blocks ਨਾਲ ਭਰ ਗਈ), [[point_size]] fragment shader ਵਿੱਚ varying ਵਜੋਂ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਸੀ (ਹਰ stamp square ਨਿਕਲਿਆ), ਇੱਕ command buffer ਉੱਤੇ ਦੋ render encoders ਇਕੱਠੇ ਮੌਜੂਦ ਸਨ (ਸਭ ਕੁਝ ਕਾਲਾ), ਅਤੇ ਇੱਕ missing start dab ਜਿਸ ਨੇ ਤੇਜ਼ strokes ਦਾ ਪਹਿਲਾ ਮਿਲੀਮੀਟਰ ਅਦਿੱਖ ਛੱਡ ਦਿੱਤਾ।

ਛੇ ਕਦਮ, ਇੱਕ rewrite ਨਹੀਂ

Migration plan ਛੇ independently shippable ਕਦਮਾਂ ਦਾ ਸੀ: pixel diff ਪਾਸ ਕਰਨ ਵਾਲਾ offline renderer; zero visual change ਵਾਲਾ display shell; GPU ਉੱਤੇ live stroke; GPU ਉੱਤੇ selection; texture ਵਿੱਚ ਸਿੱਧੇ ਲਿਖਣ ਵਾਲੀਆਂ mutations; high-zoom vector redraw (ਦੂਜੇ ਕਦਮ ਵਿੱਚ ਸ਼ਾਮਲ, ਕਿਉਂਕਿ “zero visual change” ਨੇ ਇਹ ਮੰਗਿਆ)। ਹਰ ਕਦਮ ਦਾ ਅੰਤ ਮੇਜ਼ ਉੱਤੇ ਪਏ iPad Pro ਉੱਤੇ ਇੱਕ ਮਨੁੱਖ ਦੇ ਲਿਖਣ, ਮਿਟਾਉਣ, zoom ਕਰਨ ਅਤੇ drag ਕਰਨ ਨਾਲ ਹੁੰਦਾ ਸੀ — simulator ਨਹੀਂ, screenshot diff ਨਹੀਂ।

ਡਿਵਾਈਸ ਨੇ ਉਹ ਤਿੰਨ bugs ਫੜ ਲਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ automated check ਨਹੀਂ ਫੜ ਸਕਿਆ। 100% zoom ਤੋਂ ਉੱਪਰ strokes ਦੋ ਵਾਰ ਖਿੱਚੇ ਜਾਂਦੇ ਸਨ — ਹੇਠਾਂ soft texture, ਉੱਤੇ sharp sprites — ਜਿਸ ਨਾਲ ਹਲਕਾ blur ਦਿਸਦਾ ਸੀ ਅਤੇ ਮਨੁੱਖ ਇਸ ਨੂੰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਛਾਣ ਲੈਂਦਾ ਸੀ। ਇੱਕ stroke commit ਕਰਨ ਨਾਲ ਇੱਕ frame ਲਈ flicker ਹੁੰਦਾ ਸੀ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ overlay texture update ਨਾਲ out of sync cross-fade ਹੁੰਦਾ ਸੀ। ਅਤੇ 170% zoom ਤੋਂ ਉੱਪਰ ਹਰ note ਗਾਇਬ ਹੋ ਗਈ: visibility-culling rectangle ਆਪਣੀ scaled coordinate space ਵਿੱਚ contentOffset ਵਰਤਦਾ ਸੀ, ਇਸ ਲਈ zoom ਕਰਦੇ ਸਮੇਂ ਇਹ strokes ਤੋਂ ਦੂਰ ਖਿਸਕਦਾ ਗਿਆ। ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਲਾਈਨ ਦੇ, ਇੱਕ-ਇੱਕ ਫੰਕਸ਼ਨ ਵਿੱਚ ਕੀਤੇ ਬਦਲਾਅ ਨਾਲ ਠੀਕ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਸ test ਵਿੱਚ ਨਹੀਂ ਸੀ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਲਿਖ ਸਕਦੇ ਸਾਂ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਪਤਾ ਹੀ ਨਹੀਂ ਸੀ ਕਿ ਇਨ੍ਹਾਂ ਨੂੰ ਲੱਭਣਾ ਹੈ। UI-first consumer app ਲਈ ਮਨੁੱਖ ਨੂੰ loop ਵਿੱਚ ਰੱਖਣ ਦਾ ਕਾਰਨ ਇਹੀ ਹੈ: “feel” ਕਿਵੇਂ ਟੁੱਟਦਾ ਹੈ, ਇਸ ਦੇ ਤਰੀਕੇ ਗਿਣੇ ਨਹੀਂ ਜਾ ਸਕਦੇ।

Kimi K3 ਨਾਲ ਕੰਮ ਕਰਨਾ ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤੇਜ਼। “discuss, write, build, install, look” ਵਾਲਾ loop ਮਿੰਟਾਂ ਵਿੱਚ ਚੱਲਦਾ ਸੀ, ਅਤੇ ਜਲਦੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ model ਇਹ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਦਿਨ ਵਿੱਚ ਕਿੰਨੇ loops ਚਲਾ ਸਕਦੇ ਹੋ।

ਦੂਜਾ, ਇਹ over-engineer ਨਹੀਂ ਕਰਦਾ। ਇਸ codebase ਵਿੱਚ ਸਪੱਸ਼ਟ house rules ਲਾਗੂ ਹਨ — launch ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ backward-compatibility scaffolding ਨਹੀਂ, complexity ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਕੋਈ device ਇਸ ਦੀ ਲੋੜ ਸਾਬਤ ਕਰੇ — ਅਤੇ K3 ਬਿਨਾਂ ਯਾਦ ਕਰਵਾਏ ਇਨ੍ਹਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਇਸ ਨੇ “ਬਾਅਦ ਲਈ” spatial indexes ਨਹੀਂ ਜੋੜੇ, ਹਰ call ਨੂੰ defensive checks ਵਿੱਚ ਨਹੀਂ ਲਪੇਟਿਆ, ਅਤੇ speculatively abstract ਨਹੀਂ ਕੀਤਾ। ਇਸ ਨੂੰ prompt ਕਰਨਾ ਇੱਕ ਕਾਬਲ ਸਹਿਕਰਮੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵਰਗਾ ਹੈ ਜਿਸ ਨੇ house rules ਪੜ੍ਹੇ ਹਨ ਅਤੇ ਸੱਚਮੁੱਚ ਉਨ੍ਹਾਂ ਉੱਤੇ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ।

ਤੀਜਾ, ਇਸ ਨੂੰ tools ਦਿਓ ਅਤੇ ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਸ਼ਾਹ ਨਾਲ ਵਰਤਦਾ ਹੈ। ਅਸੀਂ image utilities — view, ਇੱਕ pixel region ਤੱਕ crop, resize — ਜੋੜੀਆਂ, ਅਤੇ model ਨੇ ਉੱਪਰ ਦੱਸੇ ਪੰਜ harness bugs ਦੀ ਜਾਂਚ ਲਈ ਆਪਣੇ renderer output ਨੂੰ proactive ਤਰੀਕੇ ਨਾਲ crop ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। Tool ਮੌਜੂਦ ਹੋਣ ਨੇ ਇਸ ਨੂੰ ਵੇਖਣ ਦੀ ਯਾਦ ਦਿਵਾਈ।

ਦੂਜਾ ਪੱਖ ਇਹ ਹੈ: K3 ਨੇ ਇਸ ਕਹਾਣੀ ਦੇ ਜ਼ਿਆਦਾਤਰ bugs ਲਿਖੇ, ਜਿਸ ਵਿੱਚ ਉਹ coordinate-space bug ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਿਸ ਨੇ notes ਨੂੰ ਗਾਇਬ ਕਰ ਦਿੱਤਾ। ਇਸ ਦੀਆਂ ਹੱਦਾਂ ਅਸਲੀ ਹਨ। ਕੰਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਵਾਲੀ ਗੱਲ model ਦਾ ਸਹੀ ਹੋਣਾ ਨਹੀਂ ਸੀ; harness ਨੇ rendering drift ਫੜਿਆ ਅਤੇ ਮਨੁੱਖ ਨੇ feel। ਫਿਰ ਵੀ, ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਵਿੱਚ ਮੈਂ ਇਸ ਨੂੰ ਉਨ੍ਹਾਂ frontier closed models — Opus-class systems — ਤੋਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਿਆ ਜੋ ਅਸੀਂ ਵੀ ਵਰਤਦੇ ਹਾਂ। ਕੁਝ ਪੱਖਾਂ ਵਿੱਚ ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ ਉੱਤੇ ਬਿਹਤਰ ਸੀ: ਤੇਜ਼, ਅਤੇ codebase ਨੂੰ defensive design ਨਾਲ ਫੁਲਾਉਣ ਵੱਲ ਕਾਫ਼ੀ ਘੱਟ ਝੁਕਾਅ ਵਾਲਾ।

ਅਸੀਂ ਹੁਣ ਤੋਂ ਕਿਵੇਂ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ

ਅਸੀਂ big-spec agentic development ਨਾਲ ਕੰਮ ਮੁਕਾ ਲਿਆ ਹੈ — ਉਹ ਸ਼ੈਲੀ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ model ਨੂੰ ਇੱਕ ਵੱਡੀ specification ਦਿੰਦੇ ਹੋ ਅਤੇ ਜੋ ਕੁਝ ਤਿਆਰ ਹੁੰਦਾ ਹੈ, ਉਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ। ਨਾਕਾਮੀ ਦਾ ਰੂਪ ਖ਼ਰਾਬ code ਨਹੀਂ; ਇਹ ਉਹ code ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਨਹੀਂ ਸਮਝਦਾ।

ਇੱਥੇ ਜੋ ਕੰਮ ਆਇਆ, ਅਤੇ ਜਿਸ ਨੂੰ ਅਸੀਂ ਜਾਰੀ ਰੱਖਾਂਗੇ: ਛੋਟੇ ਕਦਮ, ਹਰ ਇੱਕ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ ਚਰਚਾ, ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨੁੱਖ ਦੀ ਸਮਝ, ਅਤੇ ਉਸ device ਉੱਤੇ ਜਾਂਚ ਜਿੱਥੇ ਇਹ ਰਹਿਣਾ ਹੈ। Model ਦਾ ਕੰਮ ਤੇਜ਼, ਸਟੀਕ ਅਤੇ ਅਨਿਸ਼ਚਿਤਤਾ ਬਾਰੇ ਇਮਾਨਦਾਰ ਹੋਣਾ ਹੈ। ਮਨੁੱਖ ਦਾ ਕੰਮ judgment, taste ਅਤੇ e2e verification ਹੈ — ਖ਼ਾਸ ਕਰਕੇ UI-first consumer software ਲਈ, ਜਿੱਥੇ specification ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੀ ਕਿ “ਸਹੀ” ਕਿਵੇਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। Fireworks ਉੱਤੇ Kimi K3 ਇਸੇ loop ਲਈ ਠੀਕ ਬਣਿਆ ਹੋਇਆ ਲੱਗਦਾ ਹੈ: loop ਨੂੰ ਤੰਗ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਤੇਜ਼, ਅਤੇ ਕਦਮਾਂ ਨੂੰ ਛੋਟਾ ਤੇ ਸਾਫ਼ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਸਮਝਦਾਰ।

ਲਹਿਰ ਗਾਇਬ ਹੈ, ਪਾਈਪਲਾਈਨ ਦੋ ਦੀ ਥਾਂ ਇੱਕ ਵਿਚਾਰ ਹੈ, ਅਤੇ ਜਿਸ ਪ੍ਰਕਿਰਿਆ ਨੇ ਸਾਨੂੰ ਇੱਥੇ ਪਹੁੰਚਾਇਆ ਉਹ ਕਾਇਮ ਰਹੇਗੀ।