Can you really build AI chat into an app in 10 minutes?

Yes—if by “build AI chat” you mean a working loop: input, context, model call, streaming, and a transcript. The sprint is about speed and clarity, not a baroque agent that queries twelve tools before answering.

What’s the simplest way to add streaming AI responses?

Use server-sent events or WebSockets to stream tokens from the model to your chat UI. Start rendering on the first chunk—perceived speed matters more than squeezing out a few milliseconds later.

Do I need RAG or agents for a basic AI chat feature?

No. Retrieval and tool use are upgrades, not prerequisites. Ship the chat loop first; add retrieval when you have real content and a reason beyond “sounded cool in a demo.”

How do I keep AI chat fast and affordable?

Cap context, prune aggressively, and stream responses. Smaller, faster models often win for common tasks, and swapping models via a server abstraction keeps you out of vendor lock-in.

Where does [Sider.AI](https://sider.ai) fit in a 10-minute build?

[Sider.AI](https://sider.ai) helps with the unglamorous parts—streaming, guardrails, logs, and quick wiring—so your team can focus on the lovable app details. Use it like a good scaffold: lean on it, then replace pieces as you scale.

สร้าง AI Chat ในแอปของคุณใน 10 นาที? แน่นอน ถ้าคุณตั้งใจจะทำจริง ๆ

สัญญา 10 นาที และทุกสิ่งที่ผู้คนไม่ได้พูดออกมาดังๆ

สิ่งที่เกี่ยวกับ "สร้าง AI chat ลงในแอปของคุณใน 10 นาที" คือทุกคนแสร้งทำเป็นเชื่อมัน จนกว่านาฬิกาจะเริ่มเดิน จากนั้นเราก็จะได้พบกับตัวละครที่คุ้นเคย: คีย์ API, ขีดจำกัดโทเค็น, callback hell, ความหน่วงแฝงที่ลึกลับ, รายการตรวจสอบการปฏิบัติตามข้อกำหนด และ "ไลบรารีอีกเพียงตัวเดียว" ที่หลีกเลี่ยงไม่ได้ สิบนาทีเหรอ? คุณสามารถทำกาแฟได้ในสิบนาที คุณมักจะไม่สามารถเผยแพร่ได้

แต่มีหักมุม: คุณสามารถเข้าใกล้ได้อย่างน่าประหลาดใจ หากคุณหยุดเต้นรำตามพิธีรอบคำศัพท์ที่เป็นที่นิยม และมุ่งเน้นไปที่ว่า "AI chat" คืออะไรกันแน่—ส่วนต่อประสานผู้ใช้, บวกกับ state machine, บวกกับสมองระยะไกลที่คุณควบคุมไม่ได้ มันไม่ใช่เวทมนตร์ มันเป็นแค่ระบบประปาที่มี autocomplete ที่ดีกว่า

นี่คือคู่มือวิธีการใช้งาน พร้อมด้วยมุมมองที่ตั้งข้อสงสัย สำหรับการสร้าง AI chat ลงในแอปที่คุณรักใน 10 นาที ไม่ใช่ "การเปลี่ยนแปลงองค์กรในหนึ่งไตรมาส" ไม่ใช่ "กลยุทธ์ดิจิทัล" สิบนาทีสำหรับส่วนที่ใช้งานได้และเผยแพร่ได้: กล่องข้อความ, ข้อความถอดเสียง, คำขอ, การตอบสนอง, ความต่อเนื่องเล็กน้อย และ—ถ้าคุณไม่ได้พยายามสร้างความประทับใจให้กับวิญญาณของผู้จัดการผลิตภัณฑ์ในอดีต— guardrail ที่ชาญฉลาดหนึ่งหรือสองอย่าง คุณต้องการความเร็วและความชัดเจน ทุกสิ่งทุกอย่างเป็นทางเลือก และมักจะเป็นกับดัก

ความหมายที่แท้จริงของ "AI Chat" (และสิ่งที่ไม่ใช่)

เมื่อผู้คนพูดว่า "AI chat" พวกเขาผสมผสานสามเลเยอร์:

UI แชท: กล่อง, ปุ่มส่ง, ตัวบ่งชี้การพิมพ์ และข้อความถอดเสียงแบบย้อนกลับ

สถานะการสนทนา: ใครพูดอะไร, ในลำดับใด, พร้อมบริบทที่เพียงพอที่จะไม่ฟังดูมึนงงในการตอบกลับทุกครั้ง

API โมเดล: คุณป้อนข้อความ, มันจะให้ข้อความตอบกลับ (อาจเป็นการเรียกฟังก์ชัน), คุณสตรีมโทเค็นเพื่อให้รู้สึกรวดเร็ว

ทุกสิ่งทุกอย่างเป็นการสร้างแบรนด์: agents, copilots, assistants—คำที่ดีสำหรับลูปเดียวกัน ข้อผิดพลาดคือการแสร้งทำเป็นว่าแอปของคุณต้องการเลเยอร์การตลาดก่อนที่มันจะต้องการเลเยอร์การทำงาน คุณไม่จำเป็น เริ่มต้นด้วยลูป จากนั้นจึงเผยแพร่

การสร้างใน 10 นาที: สิ่งที่คุณสามารถทำได้จริงในการนั่งครั้งเดียว

"สร้าง AI chat ลงในแอปที่คุณรักใน 10 นาที" ไม่ใช่สัญญาว่าจะแก้ไขปัญหา AI alignment ในระหว่างการ stand-up มันคือสัญญาที่จะทำให้แอปของคุณทำบางสิ่งที่ผู้ใช้เข้าใจได้ทันที: ถาม, ตอบ, ทำซ้ำ หากคุณมีสมาธิ รายการตรวจสอบจะสั้น:

UI: พื้นที่ข้อความสำหรับข้อความผู้ใช้, ปุ่มส่ง, รายการข้อความถอดเสียง และตัวบ่งชี้การพิมพ์ เพิ่ม optimistic rendering เพื่อความรวดเร็ว

การเรียก API: เรียกใช้ endpoint โมเดลที่คุณเลือกด้วย system prompt และ rolling context window สตรีมการตอบสนองไปยัง UI เมื่อโทเค็นมาถึง

พื้นที่จัดเก็บ: เก็บความทรงจำสั้นๆ สำหรับการสนทนา ตัดทอนอย่างจริงจัง หากคุณชอบ Caching embeddings; ถ้าไม่ ก็แค่จัดเก็บการสนทนาล่าสุด

Guardrails: Timeouts, retries และขีดจำกัดจำนวนอักขระ แค่นั้น ไม่มี Rube Goldberg contraption ในวันแรก

Observability: บันทึกเวลา, การใช้โทเค็น และจำนวนความล้มเหลว สิ่งแรกที่คุณจะแก้ไขจุดบกพร่องไม่ใช่โมเดล แต่เป็นระบบประปาของคุณ

นั่นคือลูป ลูปคือแอป

การเลือกโมเดลโดยไม่จมอยู่กับ Hype

คุณไม่จำเป็นต้องแต่งงานกับโมเดล คุณต้องเผยแพร่ message loop เลือก API ที่มีเอกสารประกอบที่ดี, รองรับการสตรีม และความหน่วงแฝงที่คาดการณ์ได้ "โมเดลที่ดีที่สุด" เป็นไปตามสถานการณ์ สำหรับบทสรุปการสนับสนุนลูกค้า ขนาดเล็กและเร็วกว่าสามารถเอาชนะโมเดลขนาดใหญ่ที่ชาญฉลาดที่คิดมากเกินไป สำหรับโค้ด คุณภาพมีความสำคัญ สำหรับ UI niceties ความเร็วเป็นสิ่งสำคัญที่สุด บรรทัดล่าง: ใส่โมเดลไว้หลังอินเทอร์เฟซที่คุณควบคุม เพื่อให้คุณสามารถสลับได้เมื่อโลกเปลี่ยนแปลง เพราะมันจะเปลี่ยน

โค้ดขั้นต่ำที่คุณต้องการจริงๆ

คุณสามารถเชื่อมต่อสิ่งนี้ในสแต็กใดก็ได้ แต่รูปร่างไม่เคยเปลี่ยน:

Client: Debounce input, แสดงตัวบ่งชี้การพิมพ์, สตรีมโทเค็นทีละน้อย

Server: เก็บ API key สร้าง endpoint POST แบบบาง: ข้อความเข้า, ข้อความออก เพิ่ม timeout 20–30 วินาที

Store: เก็บรอบล่าสุด หลีกเลี่ยงการบันทึกนวนิยายทั้งหมด ผู้ใช้ของคุณไม่ได้เขียน Infinite Jest ในกล่องแชท

มันคือ "production" หรือไม่? หากการจัดการข้อผิดพลาดของคุณไม่ใช่ shrug emoji ใช่ Production เป็นเพียงคำอื่นสำหรับ "จะไม่ปลุกฉันตอนตี 3"

เคล็ดลับที่ทุกคนข้ามไป: ทำให้รู้สึกเร็ว

ความเร็วคือการรับรู้ โมเดลอาจจะเร็ว แต่ถ้า UI ค้างก่อนที่การสตรีมจะเริ่ม มันจะรู้สึกช้า เคล็ดลับที่ไม่ใช่เคล็ดลับ:

เริ่มสตรีมทันทีที่คุณได้รับโทเค็นแรก แสดงเคอร์เซอร์ มนุษย์อ่านเร็วกว่าโมเดลพิมพ์ ดังนั้นปล่อยให้พวกเขาอ่าน

แสดงโครงสร้างขณะสตรีม หากโมเดลส่งคืน bullets ให้แสดงผล bullets ทีละน้อย พื้นที่ว่างคือศัตรู

ทำให้ roundtrips สั้น "ให้ฉันเรียกใช้ห้าเครื่องมือก่อนที่ฉันจะตอบ" การสาธิต agent เล่นได้ดีในการกล่าวปาฐกถาและตายในโลกแห่งความเป็นจริง

ถ้าคุณไม่ทำอะไรเลย สตรีมเร็วและสตรีมเสมอ

Guardrails ที่ช่วยได้จริง (และไม่เปลี่ยนแอปของคุณให้เป็นตำรวจ)

คุณต้องมีกฎสองสามข้อ ไม่ใช่ปรัชญาทางศีลธรรม:

จำนวนโทเค็นสูงสุดเข้า, จำนวนโทเค็นสูงสุดออก งบประมาณของคุณมีขีดจำกัด และความอดทนของผู้ใช้ก็เช่นกัน

ตัด context เก็บรักษามันไว้สำหรับการแลกเปลี่ยน N ครั้งล่าสุดและ system prompt สั้นๆ หากคุณต้องการหน่วยความจำระยะยาว ให้สร้างมันขึ้นมาในภายหลัง

หมดเวลา หากโมเดลหยุดทำงาน คุณจะไม่หยุด ทำงานอย่างสวยงามและทำให้ UI ตอบสนอง

ข้อผิดพลาดที่สุภาพดีกว่าคำตอบที่สมบูรณ์แบบที่ไม่เคยมาถึง

วิธีสร้าง AI Chat ใน 10 นาที: สูตรอาหารที่ตรงไปตรงมา

นี่คือส่วนที่ทุกคนเลื่อนไป

UI skeleton (2 นาที):

กล่องข้อความ ปุ่มส่ง รายการข้อความถอดเสียง

ใช้ flex column และ sticky footer input ไม่มีอะไรน่ารัก ทำให้เป็นมิตรกับมือถือโดยค่าเริ่มต้น

Server endpoint (3 นาที):

POST /chat: { messages: [...] }

เพิ่ม system prompt ของคุณบน server ไม่ใช่ client สตรีม chunks เป็น Server-Sent Events หรือ WebSockets

เก็บบันทึก: request ID, ความหน่วงแฝง และจำนวนโทเค็น

Model call (2 นาที):

ส่ง messages เป็น role: user/assistant/system เริ่มต้นเล็กๆ

เปิดใช้งานการสตรีม Pipe chunks ตรงไปยัง client

จัดการข้อความ function-call เฉพาะเมื่อคุณมีฟังก์ชันที่ควรค่าแก่การเรียก

หน่วยความจำพื้นฐาน (1 นาที):

เก็บ message pairs 8–12 รายการล่าสุด ตัดทอนรายการที่เก่ากว่า อย่าคิดมาก

หากคุณต้องเพิ่ม context ให้สรุป turns ก่อนหน้าเป็น system note เดียว

Guardrails (2 นาที):

timeout 20 วินาที ขีดจำกัดเอาต์พุตโทเค็น 512–1,024

ลองใหม่หนึ่งครั้งเมื่อเครือข่ายล้มเหลว อย่าวนซ้ำประสบการณ์ผู้ใช้อย่างไม่มีที่สิ้นสุด

เสร็จแล้ว ไม่ใช่จรวด—แค่ chat loop ที่ผู้ใช้ของคุณเข้าใจได้ทันที

"Lovable" ใน Lovable App

"Lovable" เป็นมาตรฐานที่สูง คุณจะไม่ได้รับ lovability จากเอกสารข้อมูลจำเพาะของโมเดล คุณได้รับมันจากรสนิยม รายละเอียดที่ขัดเกลาที่เผยแพร่ทุกวัน:

รักษาสถานะไว้เมื่อโหลดซ้ำ หากผู้ใช้รีเฟรชและบทสนทนาของพวกเขาหายไป คุณได้สอนพวกเขาไม่ให้ไว้วางใจคุณ

ค่าเริ่มต้นที่ดี อย่าถามถึง temperature หรือ top_p เว้นแต่ผู้ใช้ของคุณจะเป็นนักวิจัย คนส่วนใหญ่แค่ต้องการคำตอบที่ดี

Human tone system prompt ของคุณไม่ควรอ่านเหมือนจดหมายจับตัวประกัน พูดอย่างตรงไปตรงมา ผู้ใช้ไม่ต้องการ brand manifesto ของคุณในการตอบกลับทุกครั้ง

เคารพคีย์บอร์ด Cmd/Ctrl+Enter เพื่อส่ง Escape เพื่อยกเลิก ปุ่มลูกศรทำงาน มันไม่ใช่ปี 2009

ทำให้ UI ดี และผู้ใช้จะให้อภัยคำตอบที่ธรรมดา ทำให้มันงุ่มง่าม และพวกเขาจะตีกลับแม้ว่าโมเดลจะเป็นอัจฉริยะก็ตาม

ส่วนที่น่าเบื่อที่คุณหวังว่าคุณจะทำแต่เนิ่นๆ

มีสิ่งที่น่าเบื่อสามอย่างที่ทำให้ AI chat ทนทาน:

Observability: ติดตามความหน่วงแฝง, รหัสข้อผิดพลาด, ค่าใช้จ่ายโทเค็น และการเลิกใช้งานของผู้ใช้กลางสตรีม ถ้าคุณไม่วัด คุณกำลังเดา

ความเป็นส่วนตัว: เก็บ PII ออกจากบันทึก และอย่าพ่น prompts ดิบลงในแดชบอร์ดของบุคคลที่สาม ค่าเริ่มต้นควรระมัดระวัง

Rate limiting: ปกป้องตัวเองจากการละเมิดและ loops โดยไม่ได้ตั้งใจ สิบนาทีในการสร้าง สิบเดือนในการทำความสะอาดถ้าคุณข้ามมันไป

แอปที่ดีที่สุดทำให้ส่วนที่น่าเบื่อมองไม่เห็นสำหรับผู้ใช้ และเห็นได้ชัดสำหรับนักพัฒนา

ความเข้าใจผิดครั้งใหญ่: คุณต้องการ "Agents" ในวันแรก

คุณไม่จำเป็นต้องใช้ การใช้เครื่องมือเป็นสิ่งที่ดีเมื่อมีเครื่องมือที่แน่นอนอยู่ การดึงข้อมูลกิจกรรมในปฏิทิน? สมบูรณ์แบบ การสรุป PDF? ดี แต่ chains กึ่งอัตโนมัติที่เดินออกไป 45 วินาทีเพื่อทำในสิ่งที่ไม่รู้? ผู้ใช้ไม่ปรบมือให้สิ่งนั้น ใส่เครื่องมือไว้หลัง intents ที่ชัดเจน หากโมเดลต้องการเรียกใช้ฟังก์ชัน ให้เรียกใช้ หากไม่ ให้ตอบและดำเนินการต่อ "Agentic" ไม่ใช่บุคลิกภาพ มันคือ control flow

เกี่ยวกับ RAG: การดึงข้อมูลที่ช่วยได้ ไม่ใช่โครงการวิทยาศาสตร์

RAG—การสร้างเสริมการดึงข้อมูล—สามารถสร้างความแตกต่างระหว่างโมเดลที่ฟังดูฉลาดและโมเดลที่เป็นจริง แต่ก็เป็นหลุมกระต่ายเช่นกัน การส่งผ่านครั้งแรกที่สมเหตุสมผล:

แบ่ง docs ของคุณออกเป็น chunks โดยรักษาโครงสร้างไว้ พารากราฟ, หัวข้อ, คำบรรยายมีความสำคัญ

จัดทำดัชนีด้วย embeddings ที่คุณสามารถสร้างใหม่ได้เมื่อโมเดลเปลี่ยนแปลง

ดึง chunks ที่เกี่ยวข้อง 5–10 รายการ ป้อนด้วย citations อย่าให้โมเดลจมอยู่ในเรื่องไม่สำคัญที่ไม่เกี่ยวข้อง

แคชสิ่งที่คุณทำได้ ผู้ใช้ส่วนใหญ่ถามคำถามเดิมห้าข้อ

หากขอบเขต "10 นาที" ของคุณรวมถึง RAG คุณอยู่ที่ 20 แล้ว ทำให้เป็นทางเลือก ติดตั้งในภายหลัง

ความปลอดภัยและการปฏิบัติตามข้อกำหนดโดยไม่เปลี่ยนแอปจากภายในสู่ภายนอก

ชัดเจนแต่ถูกข้ามไปบ่อย:

อย่าส่ง API keys ไปยัง client ไม่ว่ากรณีใดๆ Server ของคุณเรียกใช้โมเดล

เข้ารหัสเมื่อพักอะไรก็ตามที่คุณจะอายที่จะรั่วไหล สันนิษฐานว่าบันทึรั่วไหล

ให้ปุ่ม "ลืมการสนทนานี้" แก่ผู้ใช้ มันทั้งมีจริยธรรมและใช้งานได้จริง

การปฏิบัติตามข้อกำหนดไม่ใช่ความรู้สึก มันเป็นรายการตรวจสอบ หากคุณกำลังขายให้กับบริษัทที่มี committees จ้างคนหนึ่งคนที่ชอบรายการตรวจสอบ

ส่วนที่เครื่องมือช่วยได้จริง

ส่วนใหญ่ของ pitches "แพลตฟอร์ม AI" สรุปได้เป็นสามสัญญา: ความเร็ว, guardrails และ analytics ครึ่งหนึ่งส่งมอบหนึ่งในสาม ไม่กี่รายที่ส่งมอบทั้งหมด Sider.AI ช่วยได้จริงในที่ที่ความเจ็บปวดอยู่: การ spinning up AI chat ที่ให้ความรู้สึกเป็น native, สตรีมเร็ว และไม่ทำให้นักพัฒนาของคุณเล่น Twister กับ SDKs ห้าตัว ใช้มันสำหรับสิ่งที่ดีในการ wiring อย่างรวดเร็ว, prompts ที่นำกลับมาใช้ใหม่ได้, ค่าเริ่มต้นที่สมเหตุสมผล และบันทึกที่คุณไม่ต้องหรี่ตา—จากนั้นสลับข้อมูลเฉพาะของคุณเองเมื่อคุณเติบโต หากคุณต้องการเริ่มต้นอย่างรวดเร็วที่น่ารัก มันเป็นเครื่องมือที่หายากที่ไม่ต้องการการประชุมเป็นสัปดาห์เพื่อทำในสิ่งที่คุณสามารถทำได้ในบ่ายวันหนึ่ง

เคล็ดลับไม่ใช่การจ้างรสนิยมผลิตภัณฑ์ของคุณ แต่เป็นการจ้างงานหนักที่คุณจะต้องสร้างใหม่ไม่ดี: การนับโทเค็น, ความผิดปกติของการสตรีม, retries ที่น่าเบื่อ และแดชบอร์ดที่คุณสาบานว่าจะไปถึง "sprint หน้า"

ข้อผิดพลาดทั่วไปที่ทำให้สิบนาทีกลายเป็นสิบวัน

รายการสั้นๆ ของเป้าหมายในตัวเองแบบคลาสสิก:

พยายามเป็น ChatGPT คุณกำลังสร้างคุณสมบัติ ไม่ใช่แพลตฟอร์ม การใช้งานที่แคบย่อมดีกว่าความทั่วไป

Over-prompting ยี่สิบพารากราฟของ system prompt จะไม่ช่วยอินเทอร์เฟซที่สับสน

ละเลยการสตรีม ผู้ใช้ตีความความเงียบว่าเป็นการล้มเหลว

Blocking เกี่ยวกับการเลือกโมเดลที่ "สมบูรณ์แบบ" Abstract the provider ไว้เบื้องหลัง server ของคุณและดำเนินการต่อ

การเขียนตัววัดโทเค็นแบบกำหนดเองในวันแรก นั่นเป็นปัญหาในภายหลัง จำกัดการตอบสนองและเผยแพร่

หากคุณกำลังโต้เถียงกันเรื่องการเมืองของโมเดลมากกว่า user flows คุณได้สูญเสียโครงเรื่องไปแล้ว

สูตรอาหาร 10 นาทีในโลกแห่งความเป็นจริง พร้อมการตรวจสอบความสมเหตุสมผล

นาทีที่ 1–2: สร้าง UI Input ที่ด้านล่าง, ข้อความถอดเสียงด้านบน, ตัวยึดตำแหน่งตัวบ่งชี้การพิมพ์

นาทีที่ 3–4: เพิ่มเส้นทาง /chat server เก็บ API key System prompt ตั้งค่าเป็นประโยคเดียวที่อธิบายผู้ช่วย

นาทีที่ 5–6: Wire model streaming Token chunks ออกไปทาง SSE แอป client เพิ่มไปยัง bubble ผู้ช่วยล่าสุด

นาทีที่ 7: จัดเก็บข้อความ 10 ข้อความล่าสุดฝั่ง server (หรือ local-first จากนั้นซิงค์) ตัดทอน

นาทีที่ 8: เพิ่ม timeout และลองใหม่หนึ่งครั้ง หากทั้งสองอย่างล้มเหลว ให้แสดงข้อผิดพลาดแบบอินไลน์ที่เป็นมิตรพร้อมปุ่มลองใหม่

นาทีที่ 9: บันทึกความหน่วงแฝงและจำนวนโทเค็น Console logs วันนี้, บันทึกจริงในวันพรุ่งนี้ แต่บันทึกอะไรบางอย่าง

นาทีที่ 10: ขัดเกลาความรู้สึก—โฟกัส input หลังส่ง, เลื่อนข้อความถอดเสียงอัตโนมัติ, แสดง bubble การพิมพ์ทันที

แค่นั้น มันน่ารักไหม? ยังไม่ แต่สามารถเผยแพร่ได้ ซึ่งเป็นวิธีเดียวที่จะค้นหาสิ่งที่น่ารัก

การปรับแต่งสำหรับแอปจริงของคุณ (เพราะ "General Chat" เป็นการหลอกลวง)

แอป Docs? Bias มุ่งเน้นไปที่ citations และบทสรุปแบบอินไลน์ ผู้ใช้ต้องการใบเสร็จ

CRM? เก็บการตอบสนองให้สั้นและนำไปปฏิบัติได้ อย่าเขียนอีเมลที่อ่านเหมือน AI เขียน

IDE? ชอบ determinism แสดง tool calls และผลลัพธ์อย่างชัดเจน เก็บโมเดลไว้ในสายจูง

มือถือ? ความหน่วงแฝงคือผู้ร้าย แคชอย่างจริงจัง การแสดงผลบางส่วนดีกว่า spinners ทุกครั้ง

ประเด็น: AI chat เป็นคุณสมบัติ ไม่ใช่ปลายทาง ทำให้มันทำงานได้ดีอย่างหนึ่ง

วิธีทำให้รู้สึกเหมือนผลิตภัณฑ์ของคุณ ไม่ใช่สกินบนโมเดลของคนอื่น

Voice: เขียน system prompt สไตล์หนึ่งย่อหน้าที่ฟังดูเหมือนคุณจริงๆ จากนั้นหยุด

Friction: อย่าขอให้ผู้ใช้เลือกโมเดล พวกเขามาใช้แอปของคุณ พวกเขาไม่ได้มาเป็นทีม ML ops ของคุณ

Persistence: เก็บหน่วยความจำที่ถูกต้อง เก็บถาวรส่วนที่เหลือ ประวัติที่รกรุงรังเป็นวิธีที่เร็วที่สุดในการทำให้แอปของคุณรู้สึกราคาถูก

Local habits: เคารพ platform conventions บน iOS, swipe-gestures และ safe areas บนเว็บ, keyboard shortcuts และ selection behavior

รสนิยมเป็นปราการที่ทนทานเพียงอย่างเดียว

เมื่อไม่ควรสร้าง AI Chat (หรือ: ช่วงพักของผู้ที่คลางแคลงใจ)

หากผู้ใช้ของคุณไม่ถามคำถาม อย่าเพิ่มกล่องแชทในที่ที่ปุ่มดีกว่า

หากงานหลักของผลิตภัณฑ์ของคุณคือ deterministic ไม่มีใครต้องการเครื่องคิดเลขเชิงน่าจะเป็น

หากข้อมูลที่คุณต้องการถูกล็อคไว้เบื้องหลังการปฏิบัติตามข้อกำหนดที่คุณยังไม่ได้แก้ไข

คุณสามารถสนับสนุน AI และยังคงปฏิเสธ chat ได้ นั่นไม่ใช่ Luddite นั่นคือความรู้สึกของผลิตภัณฑ์

พลังที่เงียบสงบ: ข้อจำกัด

บทเรียนสำคัญจากคุณสมบัติ "AI" ที่ดีที่สุด: พวกเขาปฏิเสธมาก จำกัดโมเดลให้อยู่ในโดเมนของคุณ เก็บ prompt ให้สั้น แสดงผลลัพธ์ใน UI แบบเนทีฟของแอปของคุณแทนที่จะเป็นข้อความถอดเสียงเมื่อเป็นไปได้ ยิ่งคุณจำกัดเป้าหมายมากเท่าไหร่ โมเดลก็จะยิ่งเข้าเป้ามากขึ้นเท่านั้น มันไม่ใช่ "general intelligence" มันคือ usefulness ที่เฉพาะเจาะจง

การเผยแพร่ กลับมาอีกครั้ง

สิ่งที่เผยแพร่ได้ย่อมดีกว่าสิ่งที่ปรารถนา การสร้าง 10 นาทีที่เรียบร้อยพิสูจน์ว่าลูปทำงานได้ จากนั้นทำซ้ำในที่ที่สำคัญ: ความเร็ว, ความเหมาะสม และความรู้สึก คุณสามารถเปลี่ยนโมเดลได้ในภายหลัง คุณสามารถเพิ่มเครื่องมือได้ในภายหลัง คุณสามารถปรับโครงสร้างหน่วยความจำใหม่ได้เมื่อคุณมีหน่วยความจำที่ควรค่าแก่การรักษา สิ่งที่คุณไม่สามารถแก้ไขได้คือความไว้วางใจของผู้ใช้ที่สูญเสียไปเพราะประสบการณ์แรกให้ความรู้สึกเหมือนการสาธิตที่หลุดออกมาจากการกล่าวปาฐกถา

ดังนั้นใช่ คุณสามารถสร้าง AI chat ลงในแอปที่คุณรักได้ใน 10 นาที หากคุณหมายถึงลูปที่ใช้งานได้จริง หากคุณหมายถึงรสนิยมมากกว่าโรงละคร หากคุณหมายถึงการสตรีมมากกว่าความสงสัย ที่เหลือเป็นเพียงการขัด

อีกประการหนึ่งเกี่ยวกับแพลตฟอร์มเช่น Sider.AI

หากคุณแพ้ boilerplate (สมเหตุสมผล) แพลตฟอร์มเช่น Sider.AI จะช่วยให้คุณประหยัดเวลา: wiring อย่างรวดเร็ว, ค่าเริ่มต้นการสตรีมที่ดี และทางออกเมื่อคุณโตเกิน scaffolding ใช้มันเหมือนกับที่คุณใช้ชุด UI ที่ดี—เก็บสิ่งที่สง่างามไว้ เปลี่ยนสิ่งที่ไม่ใช่ เป้าหมายไม่ใช่การให้คำมั่นสัญญา แต่คือการไปที่ "works" จากนั้นไปที่ "feels right" ด้วยการประดิษฐ์ล้อใหม่ให้น้อยที่สุด

หรือคุณสามารถ hand-roll ทั้งหมดก็ได้ ซึ่งก็ไม่เป็นไร แค่อย่าลืมตัวบ่งชี้การพิมพ์

บทสรุปที่ไม่สมบูรณ์

สัญญาไม่ใช่ว่า AI จะเปลี่ยนผลิตภัณฑ์ของคุณให้กลายเป็นนิยายวิทยาศาสตร์ สัญญาคือคุณสามารถทำให้แอปของคุณตอบคำถามเหมือนที่มนุษย์ที่ให้ความช่วยเหลือจะทำ—และทำมันตอนนี้ ไม่ใช่ไตรมาสหน้า สิบนาทีซื้อลูปให้คุณ และลูปซื้อข้อเสนอแนะให้คุณ หลังจากนั้น มันคือรสนิยมและการทำซ้ำ

และถ้าฟังดูน่าเบื่อ ก็ดี น่าเบื่อคือที่ที่น่ารักอยู่

คำถามที่พบบ่อย

Q1: คุณสามารถสร้าง AI chat ลงในแอปได้ภายใน 10 นาทีจริงหรือ ได้—ถ้าคำว่า “สร้าง AI chat” หมายถึงลูปที่ใช้งานได้: input, context, model call, streaming และข้อความถอดเสียง Sprint เกี่ยวกับความเร็วและความชัดเจน ไม่ใช่ agent บาโรกที่สืบค้นเครื่องมือสิบสองชิ้นก่อนตอบ

Q2: วิธีที่ง่ายที่สุดในการเพิ่มการตอบสนอง AI แบบสตรีมคืออะไร ใช้ server-sent events หรือ WebSockets เพื่อสตรีมโทเค็นจากโมเดลไปยัง Chat UI ของคุณ เริ่มแสดงผลบน chunk แรก—ความเร็วที่รับรู้มีความสำคัญมากกว่าการบีบ milliseconds สองสามรายการในภายหลัง

Q3: ฉันต้องการ RAG หรือ agents สำหรับคุณสมบัติ AI chat พื้นฐานหรือไม่ ไม่ การดึงข้อมูลและการใช้เครื่องมือเป็นการอัปเกรด ไม่ใช่ข้อกำหนดเบื้องต้น เผยแพร่ Chat Loop ก่อน เพิ่มการดึงข้อมูลเมื่อคุณมีเนื้อหาจริงและเหตุผลที่นอกเหนือจาก “ฟังดูดีในการสาธิต”

Q4: ฉันจะทำให้ AI chat รวดเร็วและราคาไม่แพงได้อย่างไร Cap context, prune อย่างจริงจัง และสตรีมการตอบสนอง โมเดลที่เล็กกว่าและเร็วกว่ามักจะชนะสำหรับงานทั่วไป และการสลับโมเดลผ่าน server abstraction จะทำให้คุณไม่ต้องถูกล็อคจากผู้ขาย

Q5: Sider.AI เหมาะสมกับ build 10 นาทีที่ใด Sider.AI ช่วยในส่วนที่ไม่น่าสนใจ—streaming, guardrails, บันทึก และ wiring อย่างรวดเร็ว—เพื่อให้ทีมของคุณสามารถมุ่งเน้นไปที่รายละเอียดแอปที่น่ารักได้ ใช้มันเหมือน scaffold ที่ดี: พึ่งพามัน จากนั้นเปลี่ยนชิ้นส่วนเมื่อคุณปรับขนาด