แม้จะรู้สึกว่าการสร้างคอมไพเลอร์นี่สุดยอดมาก แต่ก็มีไม่กี่โปรแกรมที่สเปกอินพุต/เอาต์พุตชัดเจนเท่าคอมไพเลอร์ เลยคิดว่านั่นน่าจะเป็นเหตุผลที่เหมาะกับการให้ LLM สร้างขึ้นมาได้มากพอสมควร

ถึงอย่างนั้นก็ยังน่าทึ่งมากครับ

ต่อไปก็คือ OS สินะ...? "จงสร้าง OS ที่รันโปรแกรม Win32 ได้ขึ้นมาสิ โมเดล"

 

นึกว่าเป็น grok แต่ ternyata groq เป็นอีกอย่างนี่เอง

 

โมเดลนี้ใช้ได้เลย
ถ้าใครสะดวกลองรันด้วย llama.cpp จะต้องใส่พรอมป์ต์ที่อยู่ในคอมเมนต์ของเธรดด้านล่างแยกต่างหากด้วย ไม่อย่างนั้นจะเกิดปัญหาที่ไม่มี <think> เปิด แต่มีแค่ </think> โผล่มากลางทางอันเดียว
https://huggingface.co/stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S/…

llama-server \  
  옵션생략 \  
  --jinja \  
  --chat-template-file 경로/step3p5_flash_chat_template.jinja  
 

หัวใจสำคัญคือการเปลี่ยนจาก prompt engineering ไปเป็น context engineering และในทางปฏิบัติดูเหมือนว่า “การแยกความรับผิดชอบ” คือคำตอบ

หากจัดการ persona, กฎพฤติกรรม และ memory แยกกันคนละไฟล์ ก็จะช่วยลด context rot ได้อย่างมีประสิทธิภาพ เพราะการโหลดเฉพาะไฟล์ที่จำเป็น แทนที่จะใช้ prompt แบบ monolithic นั้นเอื้อต่อ attention budget มากกว่ามาก ดังนั้น OpenClaw (หรือเฟรมเวิร์กที่คล้ายกัน) จึงน่าจะจัดการ persona (SOUL.md), กฎพฤติกรรม (AGENTS.md) และ memory (MEMORY.md) แยกจากกัน

 

พูดนอกเรื่องนิดหนึ่ง บริษัท L ขึ้นชื่อเรื่องเงินเดือนต่ำโบนัสสูงนะครับ..
ได้ยินต่อๆ กันมาว่า พอได้เป็นผู้บริหารเมื่อไร การดูแลตอบแทนนี่เหนือจินตนาการเลย

 

พอหมดเวลางานแล้วก็ปวดหัวจี๊ดเลย

 

เป็นบทความที่มีประโยชน์มากจริง ๆ ครับ

 

เมื่อหางยาวของตลาดเปลี่ยนเป็นหางที่ยาววววววยิ่งกว่าเดิม ก็อาจกลายเป็นประเด็นวิจัยที่น่าสนใจด้วยว่าตลาดจะกลับยิ่งซบเซาลง หรือจะเติบโตขึ้นกันแน่

 

อาจมีความหมายในแง่ที่ว่าทำโปรเจกต์ขนาดใหญ่ได้ด้วย vibe coding,
แต่ก็เห็นด้วยว่าตามที่คุณบอก gcc น่าจะเป็นสิ่งที่ถูกใช้เป็นข้อมูลฝึกมาแล้ว จึงถือว่าค่อนข้างไม่เหมาะสมอยู่เหมือนกัน

ในวิดีโอนี้ก็พูดถึงเรื่องคล้ายกันครับ https://www.youtube.com/watch?v=6QryFk4RYaM

 

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

 

โมเดลน่าจะถูกฝึกด้วยการรวบรวมความรู้ที่เกี่ยวกับ gcc ไปหมดแล้ว ไม่ว่าจะได้รับอนุญาตหรือไม่ก็ตาม ดังนั้นผมว่ามันก็ไม่เหมาะที่จะใช้เป็นตัวอย่างแสดงประสิทธิภาพของ llm ด้วยเช่นกัน..

 

นี่ไม่ใช่การแสดงให้เห็นหรือว่าขนาดใหญ่ระดับนี้ก็ยังทำ vibe coding ได้อย่างสม่ำเสมอ?
Claude가 생성한 C 컴파일러와 GCC 비교
병렬 Claude 팀을 활용한 C 컴파일러 구축

 

ช่วงนี้ผมเพิ่งสมัคร suno ไปเพื่อทำเพลงประกอบ
สำหรับเคสใช้งานง่าย ๆ ก็น่าจะช่วยลดค่าสมาชิกได้บ้างนะ

 

> คุณค่าของศิลปะไม่ได้อยู่ที่ผลงานที่ออกมา แต่อยู่ที่เจตนา
แม้จะเป็นภาพวาดดินสอแบบเรียบง่าย แต่ถ้าใส่ความจริงใจลงไป ก็ยังตรึงใจกว่าภาพหรูหราที่สร้างด้วย AI
คำว่า “ฉันวาดเอง” มีทั้งความตั้งใจและเรื่องราวอยู่ในนั้น

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

แม้แต่การ 'จับเจตนาของผู้เขียน' ที่เรียนกันซ้ำแล้วซ้ำเล่าในคาบภาษาเกาหลีที่โรงเรียน ก็เป็นการฝึกประสาทสัมผัสแบบนี้นั่นเอง

แต่พอเป็นผลงานจาก AI ภาพที่นึกออกก่อนกลับไม่ใช่คนที่กอดปัญหาไว้แล้วครุ่นคิดอยู่นาน ผ่านการลองผิดลองถูก แต่เป็นภาพของคนที่นั่งอยู่หน้าจอแล้วโยนพรอมป์ต์อย่างกับกำลังหมุนสล็อตแมชชีน เช่น "ปรับปรุงอันนี้", "แก้อันนี้", "เพิ่ม X"

อาจเป็นเพราะอย่างนั้น เวลามองผลงานจาก AI จึงรู้สึกว่าเรื่องราวหรือความตึงเครียดที่เกิดจากกระบวนการนั้นมีน้อยกว่า และไม่น่าสนใจนัก

 

มีแค่ผมคนเดียวหรือเปล่าที่อ่านแล้วยังไม่รู้ว่าหมายถึงอะไร.. มันไม่ใช่แค่การเอา gcc ไปทำ vibe coding หรอกเหรอ

 

ผู้อ่านตัวจริง:

คนที่สร้าง “เอเจนต์ที่รันเป็นเวลานาน” แบบ Claude Code
(โดยเฉพาะวิศวกรผลิตภัณฑ์/แพลตฟอร์ม และวิศวกรโครงสร้างพื้นฐาน LLM)

ใครอ่านแล้วจะได้ประโยชน์ที่สุด?
✅ 1) ทีมที่สร้างผลิตภัณฑ์ AI agent

  • IDE agent (แนว Claude Code, Cursor, Copilot Workspace)
  • รีเสิร์ชเอเจนต์
  • เอเจนต์อัตโนมัติที่ทำงานระยะยาว

✅ 2) วิศวกรที่ปรับต้นทุน/latency ของ LLM ให้เหมาะสม

  • บทความนี้โดยสรุปคือ: “การทำ prompt caching optimization ก็คือประสิทธิภาพ/ต้นทุนของผลิตภัณฑ์”
  • คนสายอินฟราจะจับประเด็นได้ทันที

✅ 3) คนที่ต่อเครื่องมือ MCP ไว้เยอะมาก

  • ปัญหาที่การเพิ่ม/ลบ tool ทำให้แคชพัง
  • ปัญหาของการทำ plan mode ให้เป็น “การโมเดลเป็นเครื่องมือ”

ในทางกลับกัน ผู้ใช้ทั่วไปแทบจะไม่อ่าน

มันไม่ใช่บทความแนว “เขียนพรอมป์ต์ให้ดีทำอย่างไร”

แต่เป็น

“ควรจัดการพรอมป์ต์อย่างไรในระดับสถาปัตยกรรมผลิตภัณฑ์”

สรุปสั้น ๆ

บทความนี้สำหรับคนที่สร้าง LLM ไม่ใช่ให้เป็นแค่ “แชต” แต่เป็น “ระบบโปรดักชัน”

 

ผมเองก็ใช้ opencode เป็นหลักอยู่ เลยยกเลิกการสมัคร Claude ไปเลยครับ
เสียดายนิดหน่อยที่ใช้ Opus 4.6 ไม่ได้ แต่ถ้าไม่ใช่แพ็กเกจ Claude MAX 200 ก็มีปัญหาโดนลิมิตบ่อยเกินไปอยู่แล้ว เลยรู้สึกว่าใช้ claude code ไม่ได้ก็ไม่ได้น่าเสียดายมากเท่าไร
ยังไงก็สั่งให้เอเจนต์ทำไว้แล้วไปทำอย่างอื่นต่ออยู่ดี เพราะงั้นถึงจะใช้เวลานานหน่อยก็โอเคครับ