"รถม้าไร้ม้า" ในยุค AI
(koomen.dev)- การใช้ AI เพื่อ สร้างซอฟต์แวร์ เป็นเรื่องสนุกและเพิ่มผลิตภาพ แต่แอป AI ส่วนใหญ่กลับ ไร้ประสิทธิภาพเหมือน "รถม้าไร้ม้า (horseless carriage)" ที่เลียนแบบวิธีเดิม
- ผู้ช่วยเขียนอีเมล AI ของ Gmail สร้างผลลัพธ์ที่เป็นทางการเกินไป และไม่สามารถมอบประสบการณ์ที่ปรับให้เข้ากับผู้ใช้ได้
- แอป AI ที่มีประโยชน์จริงควรเปิดให้ผู้ใช้แก้ไข System Prompt ได้ เพื่อสร้าง เอเจนต์ที่ปรับให้เหมาะกับตัวเอง
- แอปในอุดมคติของยุค AI ไม่ควรเป็นการเลียนแบบโปรแกรมแบบเดิม แต่ควรเป็น ซอฟต์แวร์แบบ AI-native ที่ลดงานซ้ำ ๆ ของผู้ใช้ และยกระดับผลิตภาพอย่างแท้จริงผ่านระบบอัตโนมัติ
- ศักยภาพที่แท้จริงของ AI อยู่ที่การช่วยให้ผู้ใช้โฟกัสกับงานสำคัญและงานสร้างสรรค์ ผ่าน การทำงานประจำวันให้เป็นอัตโนมัติ
ทำไมการสร้างซอฟต์แวร์ด้วย AI ถึงสนุกกว่าการใช้แอปที่ทำด้วย AI
- ไม่นานมานี้ผู้เขียนตระหนักถึงข้อเท็จจริงที่น่าสนใจว่า แทนที่จะใช้แอปที่ขับเคลื่อนด้วย AI ส่วนใหญ่ การ ใช้ AI มาสร้างซอฟต์แวร์ด้วยตัวเอง กลับทั้งสนุกกว่าและมีประสิทธิผลกว่า
- เมื่อใช้ AI เป็นเครื่องมือพัฒนา จะรู้สึกเหมือน สร้างอะไรก็ได้ที่จินตนาการออกได้อย่างรวดเร็ว
- ตรงกันข้าม แอป AI จำนวนมากเพียงแค่มีฟีเจอร์ AI แปะเพิ่มเข้ามา แต่ ใช้งานจริงไม่ค่อยคุ้มค่า หรือกลับทำให้ลำบากกว่าเดิม
‘รถม้าไร้ม้า’ แห่งยุค AI
- ปัจจุบัน แอป AI จำนวนมากยังคง ยึดตามการออกแบบซอฟต์แวร์แบบเก่าแทบทั้งหมด
- ผลคือโมเดลทรงพลังอย่าง LLM กลับถูก จำกัดด้วยโครงสร้างที่ไม่จำเป็น
- ผู้เขียนเรียกสิ่งนี้ว่า “รถม้าไร้ม้า (horseless carriages)” แห่งยุค AI
- คล้ายกับประวัติศาสตร์ช่วงแรกของรถยนต์ ที่ยังยึดรูปทรงของรถม้าไว้จนไม่มีประสิทธิภาพ
ตัวอย่างแอป AI ที่ออกแบบผิดทาง: ผู้ช่วย AI ของ Gmail
- Gmail เพิ่งเปิดตัวฟีเจอร์ที่ใช้โมเดล Gemini สร้างร่างอีเมลให้ผู้ใช้
- ในตัวอย่าง ผู้ใช้ (ผู้เขียน) ขอให้ช่วยร่างอีเมลถึงหัวหน้า
> Prompt: ขอร่างอีเมลถึงหัวหน้า
- ร่างที่ Gemini สร้างขึ้นแม้จะถูกต้องตามหลักไวยากรณ์ แต่ ไม่เหมือนสไตล์ที่ผู้เขียนใช้จริงเลย
- สไตล์จริงของผู้เขียน: "hey garry, my daughter woke up with the flu so I won't make it in today"
- ผลลัพธ์จาก Gemini เป็นทางการเกินไปและฟังไม่เป็นธรรมชาติ
- สุดท้ายจึงใช้เวลามากกว่าการเขียนอีเมลเอง
- ผู้เขียนบรรยายฟีเจอร์นี้ว่าเหมือน “กำลังคุมพนักงานที่ผลงานไม่ถึงเป้า”
- ผู้ใช้ Gmail หลายล้านคนก็น่าจะเจอประสบการณ์คล้ายกัน และอาจทำให้เข้าใจผิดว่า AI ยังเขียนอีเมลได้ไม่ดี
- แต่ปัญหาไม่ได้อยู่ที่ตัวโมเดล Gemini เอง แต่อยู่ที่ วิธีออกแบบแอปของทีม Gmail
ตัวอย่างผู้ช่วยอีเมลที่ดีกว่า
- ถ้า Gmail สร้างผู้ช่วยอีเมลด้วยแนวทางแบบด้านล่างนี้ มันน่าจะใช้งานได้จริงกว่ามาก
ตัวอย่างเอเจนต์สำหรับอ่านอีเมล
-
เดโมนี้ไม่ได้ทำงานแบบ เขียนอีเมล แต่ทำงานแบบ อ่านและจัดการอีเมล
-
เครื่องมือที่ใช้:
labelEmail(label, color, priority): ตั้งป้ายกำกับให้อีเมลarchiveEmail(): เก็บอีเมลเข้า archivedraftReply(body): สร้างร่างข้อความตอบกลับ
-
อีเมลในกล่องจดหมายถูกเรียงไว้ดังนี้:
- TechCrunch Weekly
- Gustaf Alströmer - founder intro?
- HackerNews Digest
- The Verge Updates
- Garry Tan - reschedule
- และอื่น ๆ รวม 12 ฉบับ
-
อีเมลแต่ละฉบับถูก จัดหมวดหมู่และกำหนดลำดับความสำคัญโดยอัตโนมัติ บางส่วนมี การสร้างร่างตอบกลับอัตโนมัติ หรือ ถูก archive อัตโนมัติ
-
อีเมลแต่ละฉบับจะถูกประมวลผลตาม System Prompt ที่ผู้ใช้กำหนดไว้
-
ผู้ใช้สามารถแก้ไข System Prompt ได้เอง เพื่อสะท้อนตรรกะการติดป้ายของตน
> วิธีนี้ทั้งทรงพลังกว่า เข้าใจง่ายกว่า และเพิ่มผลิตภาพกว่า แล้วทำไมทีม Gmail ถึงไม่ออกแบบแบบนี้?
- แก่นของปัญหา: "โทนที่เป็นสูตรสำเร็จและเหมือนกันหมด"
- หนึ่งในปัญหาใหญ่ที่สุดที่เกิดจากการออกแบบของ Gmail คือ สำนวนที่เป็นมาตรฐานจนไร้เอกลักษณ์
AI Slop: ผลลัพธ์ที่เป็นทางการและกระอักกระอ่วน
- ร่างอีเมลที่ Gemini ของ Gmail สร้างขึ้นนั้น เยิ่นเย้อ เป็นทางการเกินไป และไม่เหมือนสไตล์ของผู้เขียนเลย
- ผลลัพธ์แบบนี้อาจ ดูเหมือนอีเมลฟิชชิงเสียด้วยซ้ำ
- ผู้ใช้ LLM ส่วนใหญ่เคยเจอประสบการณ์แบบนี้ และมักใช้กลยุทธ์ที่เรียกว่า prompt hacking เพื่อหลีกเลี่ยง
- ตัวอย่าง prompt:
> "let my boss garry know that my daughter woke up with the flu and that I won't be able to come in to the office today. Use no more than one line for the entire email body. Make it friendly but really concise. Don't worry about punctuation or capitalization. Sign off with “Pete” or “pete” and not “Best Regards, Pete” and certainly not “Love, Pete”"
- ตัวอย่าง prompt:
- แม้คุณภาพผลลัพธ์จะดีขึ้น แต่ prompt ก็ยาวเกินไป และ การต้องทำแบบนี้ซ้ำทุกครั้งถือว่าไม่มีประสิทธิภาพ
- ทางแก้ที่ง่ายมากของปัญหานี้คือ ให้สิทธิ์ผู้ใช้แก้ไข System Prompt ได้
ความแตกต่างระหว่าง System Prompt และ User Prompt
- โดยพื้นฐานแล้ว LLM คือระบบที่ คาดเดาคำถัดไปจากคำที่ป้อนเข้าไป (prompt)
- อินพุตและเอาต์พุตทั้งหมดอยู่ในรูปของข้อความ
- ในบทความนี้เพื่อให้ง่าย ผู้เขียนพูดถึงเฉพาะอินเทอร์เฟซแบบข้อความ ทั้งที่จริงแล้วอินพุต/เอาต์พุตอาจเป็นเสียงหรือวิดีโอก็ได้
- เพื่อทำให้แนวคิดนี้ใช้งานง่ายขึ้น OpenAI, Anthropic และรายอื่น ๆ จึงแยก prompt ออกเป็น System Prompt และ User Prompt
- System Prompt: กำหนดบุคลิกและวิธีการทำงานของเอเจนต์ (เทียบได้กับฟังก์ชัน)
- User Prompt: คำขอหรือคำถามเฉพาะจากผู้ใช้ (เทียบได้กับค่าป้อนเข้า)
- คำตอบของโมเดล: ค่าผลลัพธ์
> ตัวอย่าง:
> - User Prompt: "Let my boss Garry know that my daughter woke up with the flu this morning and that I won't be able to come in to the office today."
> - System Prompt ที่ Gmail น่าจะใช้:
> - "You are a helpful email-writing assistant responsible for writing emails on behalf of a Gmail user. Follow the user’s instructions and use a formal, businessy tone and correct punctuation so that it’s obvious the user is smart and serious."
- ปัญหาคือ Gmail ไม่เปิดเผย System Prompt นี้ และไม่ให้ผู้ใช้แก้ไขได้
System Prompt แบบกำหนดเองของ Pete
-
ถ้า Gmail ไม่ใช้ System Prompt แบบเดียวกันสำหรับทุกคน แต่เปิดให้ผู้ใช้เขียนเอง ผู้เขียนก็น่าจะเขียนประมาณนี้:
> You're Pete, a 43 year old husband, father, programmer, and YC Partner.
> You're very busy and so is everyone you correspond with, so you do your best to keep your emails as short as possible and to the point. You avoid all unnecessary words and you often omit punctuation or leave misspellings unaddressed because it's not a big deal and you'd rather save the time. You prefer one-line emails.
> Do your best to be kind, and don't be so informal that it comes across as rude. -
หากใช้ System Prompt แบบนี้ให้ GPT สร้างอีเมล ก็จะได้ผลลัพธ์ประมาณนี้:
> Garry, my daughter has the flu. I can't come in today.
-
ผลลัพธ์นี้ สั้น เป็นส่วนตัว และสอดคล้องกับสไตล์ของผู้ใช้จริง
-
ข้อดีที่สุดคือ นำ System Prompt นี้กลับมาใช้ซ้ำได้ ทำให้อีเมลทุกฉบับหลังจากนั้นมีสไตล์เดียวกัน
ความสนุกและความเป็นไปได้ของการเขียนพรอมป์ต์ด้วยตัวเอง
- ประสบการณ์ในการสอน LLM ให้คิดเหมือนตัวเอง แล้วเห็นผลลัพธ์ได้ทันทีนั้น เป็นเรื่องที่ตรงไปตรงมาและสนุกมาก
- ผู้เขียนแนะนำให้ทุกคนลองเขียน “System Prompt ของตัวเอง” เพื่อกำหนดสไตล์การเขียนของตัวเอง
- ตัวอย่าง User Prompt:
> "Let my wife know I'll be home from work late and will miss dinner"
> "Write an email to comcast customer service explaining that they accidentally double billed you last month."
- ตัวอย่าง User Prompt:
- ถ้าได้ผลลัพธ์ที่ดี แปลว่าอธิบายได้ชัดพอแล้ว แต่ถ้ายังไม่ได้ก็เติมรายละเอียดและลองใหม่ซ้ำไป
- สิ่งนี้อาจง่ายกว่าการสอนมนุษย์ด้วยซ้ำ เพราะมี วงจร feedback ที่รวดเร็วและซื่อตรงกว่า
ทำไมแอป AI ส่วนใหญ่ถึงไม่เปิดเผย System Prompt?
- ณ เดือนเมษายน 2025 แอป AI ส่วนใหญ่ยังคง จงใจซ่อน System Prompt
- ผู้เขียนมองว่านี่คือ การพรากอำนาจและความเป็นตัวตนของผู้ใช้ และยืนยันว่าเพื่อให้ได้ผลลัพธ์และประสบการณ์ที่ดีกว่า System Prompt ควรถูกเปิดให้ผู้ใช้เข้าถึงเสมอ
Horseless Carriages: การเอาเทคโนโลยีใหม่ไปใช้ด้วยกรอบคิดเก่า
- เมื่อมีเทคโนโลยีใหม่เกิดขึ้น เครื่องมือรุ่นแรก ๆ มัก ลอกกรอบวิธีเดิมมาทั้งชุด และจึงล้มเหลว
- “รถม้าไร้ม้า (Horseless Carriage)” หมายถึงกรณีที่รถยนต์ยุคแรก ๆ ยังยึดดีไซน์ของรถม้าที่ลากด้วยม้าไว้แบบเดิมทุกอย่าง
- ตัวอย่าง: แบบรถม้าไอน้ำของ Trevithick ในปี 1803
- ดีไซน์นี้ในยุคนั้นดูน่าตื่นเต้น แต่เมื่อมองตอนนี้จะเห็นว่า โครงสร้างพื้นฐานไม่เหมาะกับรถยนต์เลย
- คนในยุคนั้นอาจลองนั่งยานพาหนะแบบนี้แล้วคิดว่า “ม้ายังดีกว่าเครื่องยนต์” ซึ่งก็เป็นข้อสรุปที่พอเข้าใจได้ก่อนรถยนต์สมัยใหม่จะถือกำเนิด
- ผู้เขียนมองว่าแอป AI ตอนนี้กำลังอยู่ในสถานการณ์คล้ายกัน
- เช่น ฟีเจอร์ Gemini ของ Gmail ที่ เอา AI ไปแปะบน UX แบบยุคเก่า
- กรอบคิดเดิมคือแค่ “เปลี่ยนม้าเป็นเครื่องยนต์”
- แอป AI ทุกวันนี้ก็คล้ายกัน คือเพียง “เพิ่มฟีเจอร์ AI เข้าไปในแอปเดิม”
Old World Thinking: ข้อจำกัดของการออกแบบซอฟต์แวร์แบบดั้งเดิม
- แต่เดิม การใช้คอมพิวเตอร์มีอยู่แค่สองทาง:
- เขียนโปรแกรมเอง
- ใช้โปรแกรมที่คนอื่นสร้างไว้
- เพราะการเขียนโปรแกรมเป็นเรื่องยาก คนส่วนใหญ่จึงเลือกวิธีที่สอง
- ด้วยเหตุนี้ อุตสาหกรรมซอฟต์แวร์จึงเติบโตมาโดย แยกบทบาทนักพัฒนากับผู้ใช้ออกจากกันอย่างชัดเจน
- นักพัฒนา: เป็นผู้กำหนดพฤติกรรมทั่วไปของซอฟต์แวร์
- ผู้ใช้: เป็นผู้ป้อนข้อมูลเฉพาะกรณี
- การแยก System/User Prompt ของ LLM ก็สะท้อนโครงสร้างนี้โดยตรง
- System Prompt = ส่วนของนักพัฒนา
- User Prompt = ส่วนของผู้ใช้
- แต่อีเมลเป็น พื้นที่ที่เป็นส่วนตัวมาก และถ้า AI จะเขียนอีเมลแทนผู้ใช้ มันก็ควร สะท้อนสำนวนเฉพาะตัวของคนนั้น
- ในโครงสร้างแบบเก่า การทำให้เป็นส่วนตัวทำได้ยาก เว้นแต่ผู้ใช้จะเขียนโปรแกรมเอง
- แต่ใน ยุคของ LLM ผู้ใช้สามารถเขียน System Prompt เองได้
- นั่นหมายถึง ยุคที่ผู้ใช้สามารถออกแบบพฤติกรรมของ AI ได้โดยไม่ต้องเขียนโปรแกรม
คืนสิ่งที่เป็นของผู้ใช้ให้ผู้ใช้
- ข้อเสนอของผู้เขียนคือ ถ้า LLM จะทำงานแทนฉัน ฉันก็ควรเป็นคนสอนวิธีทำงานนั้น (System Prompt) ด้วยตัวเอง
- แน่นอนว่าไม่ใช่ทุกคนที่อยากเขียน prompt ตั้งแต่ศูนย์
- Gmail อาจอ้างอิงจากประวัติอีเมลของผู้ใช้เพื่อ สร้าง System Prompt เริ่มต้น ให้ได้
- แต่สิ่งสำคัญคือ ต้องแสดง prompt นั้นให้ผู้ใช้เห็นและแก้ไขได้
- แล้วคนที่เขียน prompt ไม่เป็นล่ะ? → ตอนแรกอาจยาก แต่คนส่วนใหญ่เรียนรู้ได้เร็ว
- ความสำเร็จของ ChatGPT เป็นหลักฐานในเรื่องนี้
- แล้วถ้าไม่ใช่เอเจนต์ส่วนตัว แต่เป็นโดเมนอย่างบัญชีหรือกฎหมายล่ะ?
- System Prompt ก็ควรถูกเขียนโดยผู้เชี่ยวชาญในสาขานั้น แต่ ผู้เชี่ยวชาญเองก็อยากปรับมันให้เข้ากับบริบทของตัวเองเช่นกัน
- ตัวอย่าง: ทีมบัญชีของ YC ใช้วิธีทำงาน กฎ และชุดซอฟต์แวร์ที่เฉพาะกับ YC
- เอเจนต์ AI ด้านบัญชีแบบทั่วไปจึง แทบไม่มีประโยชน์เลยสำหรับ YC
- เกือบทุกทีมบัญชีมีวิธีทำงานของตัวเอง จึงนิยม เครื่องมือเอนกประสงค์อย่าง Excel
- สรุปคือ ในแอป AI ส่วนใหญ่ System Prompt ควรถูกเขียนและดูแลโดยผู้ใช้เอง
> แอป AI ไม่ควรเป็น เอเจนต์สำเร็จรูป (agent) แต่ควรเป็น เครื่องมือให้ผู้ใช้สร้างเอเจนต์ของตัวเอง (agent builder)
คืนสิ่งที่เป็นของนักพัฒนาให้นักพัฒนา
- ถ้าอย่างนั้นนักพัฒนาควรทำอะไร?
- ออกแบบ UI สำหรับสร้างเอเจนต์ ที่เหมาะกับโดเมนเฉพาะ เช่น อีเมล หรือบัญชีแยกประเภท
- จัดเตรียม เทมเพลตและตัวช่วยสร้าง prompt เพื่อให้ผู้ใช้ไม่ต้องเริ่มจากศูนย์
- สร้าง อินเทอร์เฟซ feedback loop ที่ให้ผู้ใช้ตรวจสอบและแก้ไขผลลัพธ์ของเอเจนต์ได้
- นักพัฒนายังต้องจัดเตรียม เครื่องมือของเอเจนต์ (agent tools) ด้วย
- เช่น การส่งร่างอีเมล การส่งอัตโนมัติ การค้นหาอีเมล การเชื่อมต่อ API ภายนอก เป็นต้น
- เครื่องมือเหล่านี้เป็นวิธีควบคุม ขอบเขตการกระทำและความปลอดภัย ของเอเจนต์
- การจำกัดการกระทำผ่านเครื่องมือที่เขียนด้วยโค้ดนั้น ปลอดภัยและชัดเจนกว่าการพยายามกำหนดข้อจำกัดผ่านข้อความใน prompt มาก
> ในอนาคต แนวคิดที่กังวลเรื่อง “prompt injection” อาจกลายเป็น เรื่องชวนขำ
> → เพราะการพยายามสร้างเส้นแบ่งในโครงสร้างข้อความเป็นสัญญาณของ abstraction ที่อ่อนแอ
> → ระบบทั้งหมดควรถูกมองเป็นพื้นที่ของผู้ใช้ และ ควบคุมด้วยเครื่องมือและ UI ที่แข็งแรง
คุณค่าที่แท้จริงของเอเจนต์ที่ "อ่าน" อีเมล
- อย่างที่กล่าวไปก่อนหน้านี้ ต่อให้มี System Prompt ที่ดีกว่าเดิม ก็ไม่ได้ช่วยประหยัดเวลามากนักหากใช้เพื่อร่างอีเมลตั้งแต่ต้น
- เหตุผลคืออีเมลของผู้เขียนนั้น เดิมทีก็สั้นและกระชับมากอยู่แล้ว
- กล่าวคือ ความยาวของ user prompt ≒ ความยาวของเนื้อหาอีเมล
- ผู้เขียนทดลองเรื่องนี้หลายครั้ง และรู้สึกชัดว่า generative AI เก่งเรื่องแปลงข้อความมากกว่าสร้างข้อความจากศูนย์
- ดังนั้น เป้าหมายที่แท้จริงของการใช้ LLM จึงไม่ใช่การ “เขียน” อีเมล แต่เป็นการ “อ่านและจัดการ” อีเมล
เดโมเอเจนต์อ่านอีเมล (อิง gpt-4o-mini)
- เครื่องมือที่ใช้ได้:
labelEmail(label, color, priority): ติดป้ายกำกับอีเมลarchiveEmail(): archive อีเมลอัตโนมัติdraftReply(body): สร้างร่างตอบกลับอัตโนมัติ
- เอเจนต์นี้จะอ่านอีเมลแต่ละฉบับแล้ว:
- กรองสแปมได้ดี
- ติดป้ายตามระดับความสำคัญ
- สรุปหรือสร้างร่างตอบกลับ
- archive อีเมลที่ไม่จำเป็นโดยอัตโนมัติ
- และหากเพิ่มเครื่องมืออีกไม่กี่อย่าง ก็ยังสามารถทำได้ถึง:
- ยกเลิกการสมัครรับข้อมูล
- เพิ่มนัดหมายลงปฏิทิน
- จ่ายบิลอัตโนมัติ
- นี่แหละคือสิ่งที่ อีเมลไคลเอนต์แบบ AI-native ควรทำ:
→ ทำงานซ้ำซากที่น่าเบื่อให้เป็นอัตโนมัติ เพื่อประหยัดเวลาของผู้ใช้- ตอนนี้มีอีเมลไคลเอนต์บางราย เช่น Superhuman, Zero ที่กำลังพัฒนาไปในทิศทางนี้แล้ว
ความหมายของซอฟต์แวร์แบบ AI-native
- killer app ที่แท้จริงของ AI คือการทำให้คอมพิวเตอร์ ทำสิ่งที่ฉันไม่อยากทำแทนฉัน
- เหตุผลที่ผู้เขียนใส่เดโมไว้ในบทความนี้ก็เพื่อแสดงให้เห็นว่า LLM ทำงานเหล่านี้ได้ดีพอแล้วในทางปฏิบัติ
- ปัญหาไม่ได้อยู่ที่ประสิทธิภาพของ AI แต่อยู่ที่ การออกแบบแอป
> สิ่งที่ทีม Gmail สร้างคือ "แอปอีเมลที่ใส่ AI เพิ่มเข้าไป"
> → ไม่ใช่เครื่องมืออัตโนมัติเพื่อผู้ใช้ แต่เป็น การยัด AI เข้าไปในอินเทอร์เฟซที่ยังยึดมนุษย์เป็นศูนย์กลาง
- ตรงกันข้าม แอปแบบ AI-native ควรมีลักษณะดังนี้:
- เพิ่ม leverage ของผู้ใช้ให้สูงสุดในโดเมนเฉพาะ
- ตัวอย่าง: AI email client ควรลดเวลาในการจัดการอีเมลให้เหลือน้อยที่สุด
- ตัวอย่าง: ซอฟต์แวร์บัญชี AI ควรลดเวลาในการทำบัญชีให้เหลือน้อยที่สุด
ความคาดหวังต่อยุค AI
- งานซ้ำ ๆ และน่าเบื่อทั้งหมดจะถูกเอเจนต์จัดการแทน
- ผู้ใช้จะสามารถ โฟกัสกับงานสำคัญ ได้
- เราจะมีเวลาทำสิ่งที่ตัวเองถนัดและชอบมากขึ้น
> นี่คือเหตุผลที่ผู้เขียนตื่นเต้นกับอนาคตของ AI
> เครื่องมือที่ดีกว่า การใช้เวลาที่ดีกว่า และผลิตภาพที่สูงขึ้น
2 ความคิดเห็น
> แอป AI ที่มีประโยชน์จริงควรเปิดให้ผู้ใช้แก้ไข System Prompt ได้ เพื่อให้สร้างเอเจนต์ที่ปรับให้เหมาะกับตัวเองได้
แน่นอนว่านักพัฒนาที่สร้างฟีเจอร์ก็คงรู้เรื่องนี้ดี แต่ตราบใดที่ยังมีการ jailbreak อยู่ มันก็ไม่ใช่เรื่องง่าย
ถึงจะล็อกไม่ให้เปลี่ยน system prompt ก็ยังโดน jailbreak ได้อยู่แล้ว การเปิดให้เปลี่ยน system prompt จึงแทบเป็นไปไม่ได้
แถมอาจถูกเอาไปใช้ในวัตถุประสงค์อื่นจากฟังก์ชันเดิมได้ในราคาถูกด้วย
ความคิดเห็นจาก Hacker News
ระมัดระวังต่อการใช้โมเดลภาษาเพื่อเขียนข้อความส่วนตัว เพราะขาดความเฉพาะเจาะจงของประสบการณ์หรือความรู้ส่วนบุคคล
รู้สึกว่า 90% ของฟีเจอร์ AI ไม่มีประโยชน์และราคาแพง
Gemini ทำตัวเหมือนผู้ช่วยส่วนตัวและส่งอีเมลแทนผู้ใช้
การสื่อสารกับคนที่ไม่ใส่ใจไวยากรณ์และการสะกดคำเป็นเรื่องที่น่าหงุดหงิด
วิดเจ็ตแบบอินเทอร์แอกทีฟที่เชื่อมกับ LLM สนุกดี
หลายคนคิดว่า AI เขียนด้วยสไตล์ที่คาดเดาได้ แต่จริง ๆ แล้วไม่ใช่
ชอบที่เดโมแบบอินเทอร์แอกทีฟดำเนินไปแบบเรียลไทม์
AI ไม่อาจรู้ได้ว่าผู้ใช้ต้องการอะไร และผู้ใช้ก็มักมีปัญหาในการอธิบายเป้าหมายให้ชัดเจน
ฟีเจอร์ AI ที่มีประโยชน์ที่สุดมักไม่เด่นชัด
ไม่เข้าใจการให้ AI เขียนข้อความแทน