ทำไม Claude Code ถึงดีขนาดนั้น

• Claude Code เป็น AI agent/workflow ที่โดดเด่นมากในด้านการใช้งาน
• ด้วย ความเรียบง่ายเชิงสถาปัตยกรรม และ control loop ที่ชัดเจน จึงมอบประสบการณ์ที่ดีต่อการดีบักและบำรุงรักษา
• ด้วยการ ลดการนำ RAG มาใช้ให้น้อยที่สุด และใช้ พรอมป์ต์ กับ ไฟล์คอนเท็กซ์ ที่ออกแบบมาอย่างดีอย่างเต็มที่ จึงดึงจุดแข็งของ LLM ออกมาได้สูงสุด
• รักษาความชัดเจนและความสม่ำเสมอของงานผ่าน เครื่องมือ (tools) ที่หลากหลายและ แนวทางปฏิบัติ ที่ชัดเจน
• แทนที่จะเพิ่มความซับซ้อน ใช้ โครงสร้างที่เข้าใจง่าย และการออกแบบพรอมป์ต์ ทำให้สามารถสร้าง LLM agent ของตนเองให้ทำงานคล้ายกันได้

---

ภาพรวม

• Claude Code (ต่อจากนี้จะเรียกย่อว่า CC) มอบประสบการณ์ที่น่าพึงพอใจที่สุดในบรรดา AI agent/coding workflow ที่ใช้งานได้ในปัจจุบัน
• จุดแข็งของ CC อยู่ที่ การแก้ไขโค้ดให้ตรงเป้าหมาย, การลดสิ่งรบกวนที่ไม่จำเป็น และ UX ที่ลื่นไหลจากการคงอำนาจการควบคุมไว้กับผู้ใช้
• แม้ว่า โมเดล Claude 4 และ Interleaved Thinking อันเป็นเอกลักษณ์จะมีบทบาทสำคัญ แต่ก็ยังให้ ความยุ่งยากน้อยกว่า เครื่องมืออื่นที่ใช้โมเดลเดียวกันอย่าง Cursor หรือ Github Copilot
• บทความนี้จะชำแหละ หลักการทำงานเบื้องหลังการติดตั้งใช้งานของ CC และให้คู่มือเชิงปฏิบัติสำหรับสร้าง LLM agent แบบกำหนดเอง ที่มอบประสบการณ์ใกล้เคียงกัน

คุณธรรมหลักของ Claude Code: ความเรียบง่าย

• บทเรียนที่สำคัญที่สุดคือ "ทำให้มันเรียบง่ายเข้าไว้ (Keep Things Simple, Dummy)"
• หาก LLM agent นำโครงสร้างที่ซับซ้อนมาใช้มากเกินไป เช่น multi-agent, RAG ที่ซับซ้อน, หรือระบบตรวจสอบหลายชั้น จะทำให้ การดีบักและการปรับปรุงยากอย่างมาก
• CC ใช้ main loop เดียว, ชุดเครื่องมือที่เรียบง่าย, และโครงสร้างที่มองภาพรวมได้ง่าย พร้อมเก็บตรรกะหลักทั้งหมดไว้ในไฟล์เดียว เพื่อตัด boilerplate และความซับซ้อนที่ไม่จำเป็นทิ้งไป

ทำไมความเรียบง่ายจึงสำคัญ

• แทนที่จะใช้สถาปัตยกรรม multi-agent ระบบจะจัดการงานส่วนใหญ่ใน main thread เดียว
  • การสรุป history หรือการรวมข้อความเพื่อ UX จะถูกใช้เป็นตัวช่วยเสริม
  • เมื่อต้องทำงานที่ซับซ้อน จะใช้การ โคลนตัวเอง ไปเป็น sub-agent เพื่อแตกงานออกไป (ไม่มี recursive branching และอนุญาตเพียงหนึ่งชั้นเท่านั้น)
• ใช้ รายการสิ่งที่ต้องทำ (todo list) อย่างจริงจัง
  • ปัญหาที่ซับซ้อนจะถูกแยกจัดการใน sub-agent แล้วรวมผลกลับเข้าไปใน message history หลัก
  • โครงสร้างหลายชั้นที่นามธรรมเกินไป เช่น multi-agent หรือ graph navigation อาจกลับทำให้เสถียรภาพและความสามารถในการขยายระบบลดลง

ใช้โมเดลขนาดเบาอย่างจริงจัง

• ใช้ โมเดล LLM ขนาดเบา เช่น claude-3-5-haiku กับคำขอส่วนใหญ่
  • จัดการงานจำนวนมากได้อย่างมีประสิทธิภาพ เช่น การอ่านไฟล์ขนาดใหญ่, การพาร์สเว็บเพจ, หรือการสรุป git history
  • การใช้โมเดลขนาดเบาช่วยลดต้นทุนได้สูงสุดถึง 70~80%
• แนะนำให้ใช้ ชุดโมเดลที่ปรับให้เหมาะกับแต่ละหน้าที่ สำหรับทุกการเรียกใช้ฟังก์ชันหลัก

การออกแบบพรอมป์ต์อย่างประณีต

• system prompt ของ CC มี ขนาดใหญ่มาก (ประมาณ 2800 tokens) และประกอบด้วยหลายส่วน เช่น tone & style, การจัดการงาน, นโยบายการใช้เครื่องมือ, ข้อมูล OS/ไดเรกทอรี เป็นต้น
  • รวมไฟล์คอนเท็กซ์ทั้งหมดอย่าง claude.md ไว้เสมอ เพื่อเพิ่มความสมบูรณ์ของบริบทให้สูงสุด
  • system prompt จะอธิบายกฎเชิงนโยบาย ตัวอย่าง ข้อควรระวัง และจังหวะการใช้เครื่องมือไว้อย่างละเอียดมาก

การใช้ XML และ Markdown ร่วมกัน

• ภายในพรอมป์ต์มีการใช้ทั้ง XML tags และโครงสร้าง Markdown ควบคู่กัน
  • ใช้แท็กอย่าง <system-reminder>, <good-example>, <bad-example> เพื่อสื่อข้อมูลรายละเอียดและเงื่อนไขแตกแขนงได้
  • ใช้ markdown heading เพื่อแบ่งส่วนให้ชัดเจน

ความสำคัญของไฟล์คอนเท็กซ์

• การมีหรือไม่มี claude.md ทำให้ประสิทธิภาพของ CC ต่างกันอย่างชัดเจน
  • จำเป็นสำหรับการส่งต่อกฎเพิ่มเติมที่อนุมานจาก codebase ได้ยาก เช่น การยกเว้นโฟลเดอร์/ไลบรารี หรือนโยบายที่ต้องการ
  • MinusX เองก็จัดระเบียบความชอบของทีม/ผู้ใช้ด้วย minusx.md เช่นกัน

ลดการใช้ RAG ให้เหลือน้อยที่สุด แล้วใช้การค้นหาด้วย LLM

• CC เลือกใช้โครงสร้างแบบ ค้นหาโค้ดโดยตรง ด้วยคำสั่งอย่าง ripgrep, jq, find แทน RAG (Retrieval Augmented Generation) แบบดั้งเดิม เหมือนนักพัฒนาจริง
  • แนวทางนี้เป็นทางเลือกแทน โอกาสล้มเหลวที่ซ่อนอยู่ ในระบบ RAG ที่ซับซ้อน เช่น similarity function, re-ranker, หรือ chunking
  • เป็นโครงสร้างที่ให้ LLM สำรวจและทำความเข้าใจบริบทของโค้ดจริงโดยตรง ซึ่งช่วยลดจำนวนชิ้นส่วนที่ต้องประสานกัน และอาจเพิ่มประสิทธิภาพต่อการเรียนรู้แบบ RL ได้ด้วย

การออกแบบเครื่องมือ (tool) และลำดับชั้น

• CC รองรับทั้งเครื่องมือ ระดับล่าง (Bash, Read, Write), ระดับกลาง (Edit, Grep, Glob) และ ระดับสูง (Task, WebFetch ฯลฯ)
  • แยกเครื่องมือที่จำเป็นออกเป็นรายตัวโดยพิจารณาจากความถี่ในการใช้และความแม่นยำ
  • แจ้ง คำอธิบาย, ตัวอย่าง, และจังหวะการใช้งาน ของแต่ละ tool ไว้อย่างชัดเจนใน system prompt
• งานที่ซับซ้อนจะถูกจัดการอย่างสม่ำเสมอผ่าน Task หรือเครื่องมือระดับสูง

การจัดการ Todo แบบ explicit เพื่อป้องกันการสูญหายของบริบท

• เพื่อแก้ปัญหาคลาสสิกของ LLM agent ที่ทำงานระยะยาว เช่น บริบทหายหรือหลงทิศทาง CC ใช้ Todo list ที่ระบบดูแลรักษาโดยตรง ในการจัดการสถานะ
  • แทนที่จะใช้ระบบ multi-agent โมเดลจะอัปเดต Todo ด้วยตนเอง ทำให้ได้ทั้งทิศทางการทำงานที่ชัดเจนและความยืดหยุ่นไปพร้อมกัน

การควบคุมโทน, สไตล์ และระดับความเป็นมิตรของ agent

• โทน สไตล์ และระดับความกระตือรือร้นถูกจัดการแยกเป็นอีกส่วนหนึ่ง
  • เช่น หลีกเลี่ยงคำอธิบายที่ไม่จำเป็น หรืออนุญาตให้ใช้อีโมจิได้เฉพาะเมื่อมีการร้องขออย่างชัดเจนเท่านั้น เพื่อออกแบบ ประสบการณ์ผู้ใช้ที่สม่ำเสมอ
• ใช้คำเน้นอย่าง "สำคัญมาก (IMPORTANT)", "ห้ามเด็ดขาด (NEVER)", "เสมอ (ALWAYS)" เพื่อสื่อข้อควรระวังอย่างชัดเจน

การออกแบบอัลกอริทึมและลำดับการตัดสินใจ

• มีการอธิบายและยกตัวอย่าง อัลกอริทึมหลัก ที่ LLM ต้องปฏิบัติตามอย่างชัดเจน
  • แทนที่จะลิสต์เพียง Do/Don't การใช้ flow chart และ checklist แบบเป็นขั้นตอน มีประสิทธิภาพมากกว่าในการรักษาเสถียรภาพของอัลกอริทึม
  • ยังพิจารณาความเป็นไปได้ที่คำสั่งหรือ ตัวอย่างหลายชุดจะขัดแย้งกัน และกำหนดขอบเขตบทบาทกับนโยบายไว้อย่างมีโครงสร้าง

แพตเทิร์นการออกแบบและเคล็ดลับเชิงปฏิบัติในการนำไปใช้

• ความชัดเจนของโครงสร้างและแนวคิดที่หนักแน่นนี้สามารถนำไปใช้เป็น benchmark ได้ทันทีเมื่อออกแบบ agent ของตนเอง
  • แทนที่จะใช้ framework มากเกินไปจนทำให้ความคิดซับซ้อน สิ่งสำคัญคือการออกแบบ โครงสร้างที่เรียบง่ายแต่มีประสิทธิภาพ
• ใน MinusX เองก็มีการนำหลักการหลายข้อไปใช้จริงอยู่แล้ว และมีแผนจะขยายต่อไปเรื่อย ๆ

บทสรุป

• บทเรียนที่สำคัญที่สุดจาก Claude Code: “ความเรียบง่ายคือพลังที่ยิ่งใหญ่ที่สุด”
• ความชัดเจนเชิงโครงสร้าง, การออกแบบพรอมป์ต์ที่มีความหมาย, และการจับคู่เครื่องมือขนาดเบาอย่างเหมาะสม คือสิ่งที่ทำให้ LLM agent ที่ทรงพลังเกิดขึ้นได้
• หากจะพัฒนา LLM agent ของตนเอง ก็คุ้มค่ามากที่จะศึกษาปรัชญาการออกแบบและแนวทางของ CC อย่างจริงจัง

[kaydash]

ชอบมาก มีความสุขสุดๆ เยี่ยมที่สุด หวานละมุน อยากทำต่อไปเรื่อยๆ

[GN⁺]

ความคิดเห็นจาก Hacker News

• เชื่อว่าความเรียบง่ายแบบ KISS ชนะเสมอ และรู้สึกว่าบทความนี้สรุปออกมาได้ดีจึงมีประโยชน์มาก

• เสียดายที่ Claude Code ไม่ใช่โอเพนซอร์ส แต่ก็มีการแนะนำเครื่องมือที่ช่วยให้เข้าใจการทำงานภายในได้ดีขึ้น ถ้าสนใจจริง ๆ ว่ามันทำงานอย่างไร แนะนำ Claude Trace
  https://github.com/badlogic/lemmy/tree/main/apps/claude-trace
  เครื่องมือนี้จะสร้างทั้งไฟล์ JSON ที่แสดงทุกเครื่องมือและพรอมป์ต์ที่ใช้ในเซสชัน และไฟล์ HTML ที่ฟอร์แมตมาให้อ่านง่าย

  • ถ้ากำลังมองหาทางเลือกแบบโอเพนซอร์ส ก็มีข้อเสนอให้ลองดู OpenHands CLI
    https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file
  • https://github.com/anthropics/claude-code
    สามารถดู system prompt ได้ด้วย
    ตัวโมเดลถูกฝึกมาให้แตกงานออกเป็นหลายขั้นตอนโดยอัตโนมัติและค่อย ๆ แก้ปัญหาอย่างอดทน จึงค่อนข้างทนทานต่อเคสที่ล้มเหลวในระดับหนึ่ง

• เป็นความเห็นว่ามีประโยชน์มากที่ได้เห็นว่าองค์กรที่มี LLM เป็นศูนย์กลางเข้าหาเรื่องนี้อย่างไร ในช่วงที่ระบบ multi-agent กำลังได้รับความสนใจ ผู้แสดงความเห็นเองก็ทดลองมุมมองด้านการออกแบบหลายแบบในชีวิตประจำวันอยู่แล้วจึงรู้สึกเชื่อมโยง
  อินไซต์หลักคือ
  (1) พรอมป์ต์ยาวได้ และควรใส่คำอธิบายพื้นฐาน เช่น จุดประสงค์ของเครื่องมือหรือมันช่วยอย่างไรไว้เสมอ
  (2) การเรียกใช้เครื่องมือเป็นเพียงส่วนพื้นฐานมาก จึงควรสะท้อนบริบทให้มากขึ้น เช่น เมื่อไรควรใช้ และเมื่อไรไม่ควรใช้
  (3) การจัดการสถานะของระบบในรูปแบบข้อความก็ใช้ได้ดี เคยคิดถึงวิธีที่ fancy กว่านี้อย่างการเก็บเป็น dataframe หรือ parse ตัวแปร แต่ถ้า context window ยาวพอ ก็รู้สึกว่าใช้แค่ข้อความก็เพียงพอแล้ว

  • พรอมป์ต์ยาวนั้นดีจริง แต่เฉพาะเมื่อโมเดลถูกปรับแต่งมาให้จัดการเรื่องนี้ได้ดีเท่านั้น ผู้แสดงความเห็นลองเปลี่ยนจาก Claude Code ไปใช้โมเดลอื่นแล้วพบว่าแทบไม่มี local model ไหนที่ทำได้ดีทั้งพรอมป์ต์ยาวและการใช้เครื่องมือเท่าที่โฆษณาไว้
    ลองทั้ง OpenAI และ Google Gemini แล้ว แต่รู้สึกว่ายังทำได้ไม่ดีเท่าโมเดลของ Anthropic และยังช้ากว่า ยิ่งพรอมป์ต์ยาวขึ้นก็ยิ่งเจออาการลืมใช้เครื่องมือหรือส่งผลลัพธ์มาในฟอร์แมตผิด
  • (ผู้เขียนบล็อก) มองว่าแค่ใช้ฟีเจอร์พื้นฐานให้ดี ก็รีดประสิทธิภาพที่ดีได้ในเกือบ 99% ของสถานการณ์ สิ่งสำคัญคือทำให้ลูปเรียบง่ายและมีเครื่องมือที่ชัดเจน ฟีเจอร์จะซ้ำกันบ้างก็ไม่เป็นไร
    ความชัดเจนและความเรียบง่ายมาก่อนเสมอ

• มีคำถามว่าสงสัยว่า Google Gemini โดยเฉพาะเวอร์ชัน Pro เป็นอย่างไรเมื่อเทียบกับ Claude แม้จะชอบผลิตภัณฑ์ของ Google หลายอย่าง แต่ก็กังวลเรื่องที่บริษัทมักยุติผลิตภัณฑ์บ่อย ๆ รวมถึงประเด็นการควบคุมโดยองค์กรใหญ่ ๆ อย่าง Chrome และเรื่องการเซ็นเซอร์

  • Gemini โดดเด่นมากโดยเฉพาะตอนที่สามารถป้อน merged files ของทั้งรีโพซิทอรีเข้าไปแล้วคุยต่อได้ ระดับความเข้าใจทั้ง codebase นั้นน่าทึ่ง และช่วยเรื่องการออกแบบสถาปัตยกรรมได้มาก ซึ่ง Claude ยังด้อยกว่ามากในจุดนี้
    กลยุทธ์ส่วนตัวคือใช้ Gemini ทำสรุปโปรเจกต์และแผนการออกแบบระดับสูงก่อน จากนั้นให้ gpt5 ช่วยปรับปรุงและออกแบบ workflow แบบละเอียดต่อ เช่น เอกสาร XML แล้วค่อยส่งต่อให้ Claude อีกที แค่นี้ก็แทบหลีกเลี่ยงอาการที่ Claude หลงทางไปมาได้แล้ว
  • Gemini Pro ไม่ได้แย่สำหรับงานเขียนโค้ด แต่จากประสบการณ์ Claude ดีกว่ามากสำหรับงานที่เกี่ยวกับเทอร์มินัล เช่น CLI และ CLI ส่วนใหญ่ก็มักใช้ Claude กันมากกว่า
    https://www.tbench.ai/leaderboard
  • ในเว็บ UI แบบแชตค่อนข้างชอบ Gemini 2.5 Pro แต่ในเครื่องมือบรรทัดคำสั่ง Gemini code แทบไม่มีประโยชน์ ส่วน Claude code ส่วนใหญ่ก็ช้า
  • Gemini เหนือกว่าสำหรับการดีบักปัญหายาก ๆ ที่ต้องตามหลาย function call ขณะที่ Claude ทำงานได้คาดเดาได้เสมอและทำตามคำสั่งเก่ง โดยเฉพาะการจัดการ todo list
  • เมื่อก่อนชอบมากทีเดียว แต่ช่วงหลังรู้สึกว่ามันฉลาดน้อยลง ไม่แน่ใจว่าคิดไปเองหรือเปล่า

• ผู้แสดงความเห็นคิดว่าตัวโมเดลพื้นฐานเองเก่งกับงานเขียนโค้ดจริง ๆ จึงทำให้ผู้ใช้ประเมินมันสูง ไม่ใช่งานประเภทเดียวกับโจทย์ benchmark ทั่วไป พอลองใช้ GitHub Copilot จะเห็นว่า Claude เหนือกว่าโมเดลของ OpenAI และ Google แบบชัดเจน ความต่างมากจนอีกหลายโมเดลให้ความรู้สึกว่าแทบใช้งานจริงไม่ได้เลย

  • Anthropic สามารถปรับทั้งโมเดลและพรอมป์ต์ภายในระหว่างการทำ reinforcement learning ได้ จึงคิดว่าคำแนะนำในบทความที่ว่า “ให้ใช้วิธีเดิมที่มีอยู่ต่อไป” เหมาะกับโมเดลของ Anthropic มากกว่า และด้วยโมเดลสมัครสมาชิกจึงมีแรงจูงใจสูงในการทำให้ลูปมีประสิทธิภาพ
  • อธิบายด้วยความต่างของโมเดลพื้นฐานอย่างเดียวไม่ได้ เวลาใช้ opus กับ cline คู่กันใน VS Code เทียบกับใช้ Claude code แม้จะอธิบายความต่างด้าน productivity เป็นตัวเลขชัด ๆ ไม่ได้ แต่ตอนใช้ CC จะทำงานได้มากกว่า
  • เห็นคำชมเยอะจึงคาดหวังมากและลองใช้ Claude Code อยู่หนึ่งเดือน แต่กลับยิ่งผิดหวัง มันให้ประสบการณ์แย่กว่า Cursor sidebar และทำให้สงสัยว่าตัวเองใช้ผิดวิธีหรือเปล่า เพราะในโค้ดเบสสองชุดที่ต่างกันก็ยังทำพลาดแบบไม่น่าเชื่อบ่อยมาก

• ตอนนี้กำลังใช้ Claude Code ดีบักปัญหาเกี่ยวกับ Elastic บน Security Onion แต่พอผ่านไปไม่กี่นาทีก็มีโค้ด JS อ่านยากจำนวนมากโผล่มาพร้อมกับ error ว่า Error: kill EPERM
  ดูจากล็อกแล้วเหมือนมันไป kill โปรเซส Node.js จน Claude เองก็ตายไปด้วย หรือไม่ก็เหมือน Claude ยอมปิดตัวเองเพราะแก้ปัญหาไม่สำเร็จ
  ไม่ว่าอย่างไร ถ้าโปรเซสยังอยู่ต่อได้ก็อยากให้มันช่วยต่ออีกหน่อย

  • Claude กับ localstack บางส่วนเข้ากันได้ไม่ค่อยดี แต่กับ Rust กลับทำได้ค่อนข้างดีอย่างน่าประหลาด
    จึงคิดว่าในอนาคต ภาษา แพลตฟอร์ม และสถาปัตยกรรมที่ LLM เข้าใจดีที่สุดจะยิ่งกลายเป็นกระแสหลัก เช่น ถ้า LLM จัดการ nodejs ได้ดีกว่า 10 เท่า การเลือกใช้ nodejs ตั้งแต่ต้นแทน Elixir หรือ Go ก็อาจสมเหตุสมผลกว่า และนักพัฒนารุ่นจูเนียร์ก็ใช้ความช่วยเหลือจาก LLM เพื่อทำงานได้ใกล้ระดับมิดเดิลหรือซีเนียร์มากขึ้น
  • บางครั้ง error แบบนั้นเกิดจากใช้ sudo เพื่อรันโปรเซสด้วยสิทธิ์ superuser แล้ว timeout
  • บางกรณีอัปเกรดการติดตั้ง หรือลบไฟล์ติดตั้งเดิมแล้วติดตั้งใหม่ ก็แก้ปัญหาได้ ผู้แสดงความเห็นเองก็แก้ได้ด้วยวิธีนี้
  • มีคนเคยย้ายไปใช้ LLM อื่นเพื่อดูว่าเกิดอะไรขึ้น แม้จะไม่ใช่คำแนะนำอย่างเป็นทางการ
  • ผู้แสดงความเห็นไม่เคยได้ผลลัพธ์ที่ดีกับการจับคู่ Elasticsearch และ LLM เลย ผลลัพธ์ส่วนใหญ่เป็นการ “หลอน” แบบไม่มีหลักฐาน คิดว่าเป็นเพราะในอินเทอร์เน็ตมีตัวอย่างที่เหมาะสมอยู่น้อยมาก

• ผู้แสดงความเห็นสร้าง MVP แรกของสตาร์ตอัปทั้งตัวด้วย Claude Code และตอนนี้ก็มีลูกค้าที่จ่ายเงินจริงแล้ว แน่นอนว่ายังมีความกังวลพื้นฐานว่า ถ้าเกิดเหตุ SEV (service outage) ขึ้นมาก็อาจพังได้ในพริบตา แต่ก็ยังใช้ Claude อย่างจริงจังต่อไปเพื่อแก้ security vulnerability, ทำ test-driven development และออกแบบ software architecture ตาม roadmap ระยะยาว
  อยากให้เรื่องแบบนี้กลายเป็นเรื่องปกติมากขึ้นเรื่อย ๆ ในอนาคต

  • มีคำขอให้แชร์ลิงก์ผลิตภัณฑ์ เพราะอยากรู้ตัวอย่างการใช้งานจริง
  • มีคำถามแซว ๆ ว่า “การแก้ security vulnerability” นั้นหมายความว่า Claude เป็นคนเขียนโค้ดและสร้างช่องโหว่มาตั้งแต่แรกหรือเปล่า
  • มีคำขอให้ยกตัวอย่างแบบเจาะจงว่ามันช่วยเรื่อง test-driven development และ software design อย่างไรบ้าง
  • มีมุกว่าลองสั่ง Claude Code ให้โอนเงินเข้าบัญชีธนาคารทุกเดือน แล้วมันก็ทำให้จริง
  • มีความเห็นว่าอยากให้เปิดเผยว่าจริง ๆ แล้วสร้างอะไรขึ้นมาด้วย Claude Code

• ถ้าข้ออ้างว่า “Keep things simple” ถูกต้อง ก็กลับรู้สึกว่ามันดูเป็นการจัดวางที่ค่อนข้างซับซ้อนอยู่ดี
  ผู้แสดงความเห็นเองใช้วิธีง่าย ๆ คือถามทีละพรอมป์ต์ในสิ่งที่ต้องการ และก็ทำงานได้มากพอมาโดยตลอด
  จึงยังไม่มั่นใจว่าโครงสร้างที่ซับซ้อนซึ่งพูดถึงกันนี้ให้คุณค่าเพิ่มอะไร เมื่อเทียบกับพรอมป์ต์ที่ออกแบบมาดีจริง ๆ
  เช่น ในกรณีอย่าง “จะเขียน while loop ในภาษาที่เพิ่งเริ่มเรียนได้อย่างไร” พรอมป์ต์ประโยคเดียวอาจมีประสิทธิภาพกว่าด้วยซ้ำ
  รู้สึกว่า control flow กลับไม่ชัดเจน และก็สงสัยว่า LLM ใช้ส่วน appendix อย่างเครื่องมือหรือ system prompt ได้ดีจริงหรือไม่ ถ้าคำขอซับซ้อนเกินไป มันอาจมองข้ามบางส่วนหรือเปลืองโทเคนโดยใช่เหตุ
  สำหรับตัวเอง การ “เขียนโปรแกรม” ด้วยการโยนพรอมป์ต์แยกเป็นชิ้น ๆ ดูเป็นธรรมชาติกว่ามาก
  จึงอยากเห็นตัวอย่างการใช้งานหรือพรอมป์ต์ของคนที่ใช้วิธีอื่น
  สงสัยว่าคนทั่วไปสร้างโปรแกรมทั้งตัวด้วย LLM กันอย่างไรในทางปฏิบัติ และอยากดูตัวอย่างที่แบ่งทำเป็นพรอมป์ต์ย่อย ๆ

  • ผู้แสดงความเห็นอีกคนก็บอกว่าใช้อยู่แบบเดียวกัน จึงอยากเห็นคำตอบจากคนอื่นเหมือนกัน

• อีกเรื่องหนึ่ง ลิงก์ minusx.com ที่อยู่ท้ายบทความ ใบรับรองความปลอดภัยหมดอายุไปแล้ว 553 วัน จึงเตือนให้ระวังเพราะเว็บไซต์ไม่ถูกต้อง