2 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Lathe เป็นการทดลองใช้ LLM เพื่อ "สอน" แทนที่จะให้มัน "คิดแทน" โดยให้สร้าง บทสอนเชิงปฏิบัติด้านเทคนิค จากพรอมป์ต์ แล้วให้ผู้ใช้ลงมือทำตามทีละขั้นใน UI แบบโลคัลเพื่อเรียนรู้ด้วยตนเอง
  • รองรับการสร้างบทสอนแบบพาร์ตเดียวหรือหลายพาร์ต และมี LLM skills สำหรับการถามคำถาม ตรวจสอบบทสอน ขยายพาร์ตใหม่ และเพิ่มแท็กสำหรับการค้นหา
  • สามารถสร้างบทสอนจากเซสชัน LLM แบบโต้ตอบของ Claude Code, Cursor และ Codex ได้ และ lathe CLI ที่เขียนด้วย Go จะรับหน้าที่บันทึก จัดการ เรนเดอร์บทสอน และจัดการสถานะแบบถาวร
  • ตัว CLI เองจะไม่เรียกใช้ LLM โดยตรง ส่วนปุ่มบนเว็บและคำสั่ง lathe verify กับ lathe extend จะทำงานโดยจัดเตรียม skill command สำหรับนำไปวางในเซสชัน LLM
  • เว็บ UI แบบโลคัลรันด้วย lathe serve และใช้พอร์ตเริ่มต้น 4242; จากรายการบทสอนสามารถค้นหาตามชื่อเรื่อง หัวข้อ แท็ก ที่เก็บโค้ด และเวอร์ชันเครื่องมือ รวมถึงรองรับการเรียงลำดับตามใหม่สุด เก่าสุด และตามชื่อเรื่อง ตลอดจนการกรองตามสถานะ ประเภท แท็ก และเวอร์ชัน
  • UI สำหรับการอ่านมีการนำทางด้วยสารบัญในแถบด้านขวา มีบันทึกเสริมอยู่กลางเนื้อหา และมีแบบฝึกหัดสำหรับผู้อ่านอยู่ท้ายบทสอน
  • ทุกบทสอนจะบันทึกแหล่งที่มาที่ใช้ โมเดลที่ใช้ และพรอมป์ต์ที่กำหนดสไตล์การเขียนของบทสอน โดยดูข้อมูลแหล่งที่มาได้จากฟิลด์ sources ใน metadata.json และจากแผงแหล่งที่มาใน UI
  • บทสอนจะถูกเก็บไว้ในเส้นทางส่วนกลาง ~/.lathe/tutorials/ เป็นไดเรกทอรีแยกตาม slug และประกอบด้วย metadata.json กับไฟล์พาร์ตอย่าง part-01.md หรือ index.md
  • การติดตั้งทำโดยวางไบนารีเดี่ยวแบบสแตนด์อโลน lathe ไว้ใน $PATH และรองรับ Homebrew cask สำหรับ macOS, สคริปต์ติดตั้งแบบ curl | sh, go install ที่ใช้ Go 1.25+ และการบิลด์จากซอร์ส
  • skills ถูกบันเดิลมากับไบนารี และสามารถติดตั้งไปยังตำแหน่งสำหรับ Claude Code, Cursor และ Codex ได้ด้วย lathe skills install
  • สไตล์การเขียนของบทสอนควบคุมด้วย voice โดยมี plainspoken และ companion มาให้เป็นค่าเริ่มต้น และสามารถสร้าง voice แบบกำหนดเองได้ด้วย /lathe-voice
  • voice จะเปลี่ยนเฉพาะสไตล์การเขียน ไม่เปลี่ยนความถูกต้อง การค้นคว้า การอ้างอิง การตรวจสอบ หรือโครงสร้าง; voice แบบกำหนดเองถูกตั้งค่าให้ปฏิเสธการปลอมเป็นบุคคลจริง การบิดเบือนคุณวุฒิ และการปฏิเสธว่าไม่ได้เขียนโดย LLM
  • การตรวจสอบเป็นตัวเลือกและรันได้ในเซสชัน LLM แบบโต้ตอบด้วย /lathe-verify <slug>; ระบบจะสร้างไดเรกทอรีชั่วคราวใหม่ด้วย mktemp -d สร้างไฟล์ รันคำสั่งและบล็อก ## Checkpoint แล้วบันทึกผลลัพธ์
  • สถานะการตรวจสอบมีได้หนึ่งค่าใน unverified, verifying, verified, failed, skipped, extending; หากขาดเครื่องมือที่จำเป็นจะไม่ถูกบันทึกเป็นความล้มเหลว แต่เป็น skipped
  • การตรวจสอบทำงานภายใต้โมเดลสิทธิ์ทั่วไปของ LLM จึงสามารถดูและอนุมัติการเรียกใช้เครื่องมือได้ และไดเรกทอรีชั่วคราวนั้นเป็นเพียงธรรมเนียมเพื่อเก็บผลลัพธ์การบิลด์ไว้นอกรีโพ ไม่ใช่ขอบเขตด้านความปลอดภัย
  • เนื่องจาก Lathe คือ LLM มันจึงอาจล้มเหลวในแบบเดียวกับที่ LLM ล้มเหลว และแนะนำให้ใช้โมเดล “thinking” ที่ใหญ่ที่สุดเท่าที่เข้าถึงได้สำหรับการสร้างบทสอน
  • ปัจจุบันกรณีใช้งานที่ใช้ทดสอบภายในคือ Claude Code บน macOS; การตั้งค่าอื่นอาจใช้งานได้ แต่ยังไม่ได้รับการตรวจสอบ
  • ไม่ได้มีจุดประสงค์ให้ใช้เขียนคอนเทนต์นอกเหนือจากการใช้งานส่วนตัวเพื่อการเรียนรู้ส่วนบุคคล

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News
  • วิธีคล้ายกันที่ดีคือให้ LLM คอยตั้งควิซแบบ ถามตอบเชิงโสเครตีส เกี่ยวกับหัวข้อที่สนใจ
    มันจะคอยถามคำถามที่ลึกขึ้นเรื่อย ๆ จนเราค่อย ๆ ไปถึงคำตอบได้เอง และกระบวนการนั้นก็ทำให้เราคิดกับปัญหาอย่างจริงจัง ซึ่งช่วยเรื่องความเข้าใจ การเรียนรู้ และความจำ
    เลยทำสกิล Socratic-quiz ที่ใช้ได้กับ coding agent หรือเครื่องมือคล้ายกันไว้: https://pchalasani.github.io/claude-code-tools/plugins-detai...
    เช่น เคยใช้เพื่อทำความเข้าใจเรื่องที่ขัดกับสัญชาตญาณได้ดีขึ้น อย่างเบาหวาน/อินซูลิน, โดพามีนกับแรงจูงใจ, หรือการทำงานภายในของ Claude และยังช่วยลดสิ่งที่เรียกว่า cognitive debt ได้ด้วย
    LLM ที่เก่ง ๆ กลับทำควิซแบบนี้ได้คล่องอย่างน่าประหลาดใจ และดูคล้ายมี theory of mind อยู่บ้าง

    • ในกรณีนี้สงสัยว่าจัดการกับ การเสื่อมของความยาวบริบท อย่างไร
      เพราะคำถามที่ยากขึ้นน่าจะเพิ่งโผล่มาตอนที่บริบทใกล้เต็มแล้ว
    • ถ้าแหล่งพลังมาจาก LLM งั้นเมื่อไม่มี LLM คุณคืออะไร?
    • ถ้าใช้เพื่อเสริมการเรียนจากแหล่งข้อมูลจริง ก็น่าจะมีประโยชน์
      เรื่องอย่างเบาหวาน/อินซูลิน หรือโดพามีนกับแรงจูงใจเป็นหัวข้อซับซ้อนมาก แม้จะพูดเบา ๆ ว่า “เข้าใจแล้ว” แต่ถ้าจะเข้าใจอย่างแท้จริงก็ต้องศึกษาอีกมาก
      ถ้ามองว่าเป็นการเรียนรู้ที่ขับเคลื่อนด้วยความอยากรู้อยากเห็นก็โอเค แต่ถ้าเป็นวิธีเรียนเรื่องสำคัญหรือจริงจังจริง ๆ ยังไม่แน่ใจ
      วิธีดั้งเดิมอย่างค้นหาแหล่งข้อมูลและเรียนตามหลักสูตรที่มีคนออกแบบนำทางไว้ ดูเป็นระบบและเร็วกว่าวิธีนี้
  • คิดว่าน่าจะยังมีคนกลุ่มเดิมในสัดส่วนใกล้เคียงเดิมอยู่เสมอ
    บางคนอยากรู้อยากเห็น อยากหรือจำเป็นต้องเข้าใจสิ่งที่ทำ ส่วนบางคนไม่เป็นแบบนั้นและแค่อยากให้มันรันได้
    ความต้องการแบบนั้นเองคือ ลักษณะนิสัยพื้นฐาน ที่สร้างผู้เชี่ยวชาญขึ้นมา
    LLM เป็นเครื่องมือในฝันสำหรับคนที่อยากรู้อยากเห็นแบบนี้ และน่าจะยิ่งเร่งพวกเขาให้ไปไกลขึ้น
    แทบไม่มี “ความสูญเสีย” จริง ๆ มีแค่คนที่ไม่สนใจรายละเอียดจะทำงานได้ง่ายขึ้น
    ซึ่งก็ดีสำหรับพวกเขา และก็ดีสำหรับคนช่างสงสัยด้วย ดังนั้นโดยรวมถือว่าเป็นผลดี

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

  • ช่วงนี้ในงานใช้แพตเทิร์นทั่วไปแบบนี้เยอะมาก
    ทำงานส่วนที่กำหนดผลลัพธ์แน่นอนเป็น แอป CLI แบบคัสตอม แล้วใส่สกิลเข้าไปใน agent harness จากนั้นให้เอเจนต์เรียกใช้สกิลนั้น เพื่อสร้างผลลัพธ์ด้วยทั้ง CLI และการให้เหตุผลแบบเอเจนต์
    เช่น ถ้าพิมพ์ว่า “ช่วยทำสรุประดับผู้บริหารเกี่ยวกับกิจกรรม backlog ของทีมเหล่านี้ในช่วงเดือนที่ผ่านมา” ภายใน 5-10 นาทีก็จะได้เอกสารหลายหน้าที่อ่านได้ พร้อมแนบการอ้างอิง ticket ที่วิเคราะห์ไว้
    ไม่ต้องไปกวนคนอื่นหรือขอให้ใครทำงานเพิ่ม แค่ดูแลให้ backlog อัปเดตและมีรายละเอียดตามปกติอยู่เสมอก็พอ
    มันอยู่ในจุดที่มีประโยชน์มาก ระหว่างการใช้เอเจนต์ล้วน ๆ ที่ให้ผลลัพธ์ซ้ำ ๆ อย่างสม่ำเสมอได้ยาก กับการต้องสร้างหรือซื้อแอปเต็มรูปแบบใหม่ทุกครั้งแม้จะเป็นงานเล็กน้อย

    • เห็นด้วยว่าแนวทางนี้เวิร์ก
      แต่ก็ยังรู้สึกอยาก กลับด้านมัน อยู่เรื่อย ๆ
      โครงสร้างที่อยากได้จริง ๆ คือโปรแกรม CLI แบบดั้งเดิมที่เก็บความรู้และการตัดสินใจของเวิร์กโฟลว์ไว้ในโค้ดเป็นหลัก แล้วค่อยเรียก coding agent แค่นิดหน่อยเฉพาะในบางขั้นของเวิร์กโฟลว์
      ยังไม่แน่ใจว่าจะทำอย่างไร
      เลยสงสัยว่ามีไลบรารีแบบนี้อยู่แล้วหรือไม่ และถ้ามีก็มันทำงานอย่างไร
      ถ้าจะทำให้ดีจริง ๆ ดูเหมือนว่าควรมี background service ที่ซอฟต์แวร์ CLI จะโต้ตอบได้ผ่าน local IPC socket มาตรฐาน
      คล้ายกับ docker daemon
      แต่ไม่รู้จักซอฟต์แวร์หรือเฟรมเวิร์กสำหรับ coding agent ที่เปิด ความสามารถด้าน IPC แบบนั้นออกมา
    • เห็นด้วย
      คิดว่าเคยเห็นแพตเทิร์นนี้ครั้งแรกในงานบางอย่างของ Simon Willison น่าจะเป็น Rodney กับ Showboat
      สำหรับบางเวิร์กโฟลว์ การจับคู่ Skills + CLI ให้สมดุลที่ดีระหว่างความยืดหยุ่นของ LLM กับความสม่ำเสมอของ CLI
    • อยากรู้ว่าพอจะยกตัวอย่างงานที่กำหนดผลลัพธ์แน่นอนได้อีกสักหน่อยไหม
      ในตัวอย่างนี้ งานส่วนนั้นคือ “ดึง backlog ของทีมนี้มา” ส่วน LLM คือ “ประมวลผลแต่ละ backlog” กับ “รวมสรุปทั้งหมด” ใช่ไหม?
  • เพิ่งอัปเดตสกิลยอดนิยม /grill-me ให้ตรงกับจุดประสงค์นี้พอดี
    เมื่อวานเพิ่งใช้ทำเซสชันถามกดดันแบบลึกมากและให้มุมมองดีมาก ว่าเวลาโหลดชุดข้อมูลขนาดมหึมามาก ๆ ใน pandas จริง ๆ แล้วเกิดอะไรขึ้นบ้าง แบบละเอียดถึงระดับสุดท้าย

    • มีที่ไหนที่เผยแพร่เวอร์ชันนั้นไว้หรือเปล่า?
  • เป็นวิธีที่เจ๋งมาก
    ไม่นานมานี้ฉันบอกเพื่อนว่าการเรียนเขียนโปรแกรมคือการ พิมพ์โค้ดด้วยมือตัวเองจริงๆ
    เลยแนะนำให้ลองใช้ LLM สร้างตัวอย่างการสอนแบบสั้นที่สุดที่ตรงกับความสนใจและความต้องการของตัวเอง
    ฉันลองแนวทางเรียนเขียนโปรแกรมแบบ Zed Shaw คือพิมพ์ตัวอย่างโค้ดตามต้นฉบับด้วยมือ เหมือนการฝึกคัดในดนตรีหรือศิลปะ
    ฉันทดลองกับภาษาโปรแกรมที่เรียนมาพักหนึ่งแต่ยังติดขัดอยู่ และแค่พิมพ์ไม่กี่ชั่วโมงก็ทำให้ความคล่องเพิ่มขึ้นมาก
    แล้วก็รู้ตัวว่าระหว่างการพิมพ์ไม่กี่ชั่วโมงนั้น ฉันเขียนโค้ดไปมากกว่าตอนเรียนหลายสัปดาห์เสียอีก
    ถ้ายังไม่รู้จักภาษานั้นดี การสร้างโค้ดเองจะช้ามากและผิดพลาดเยอะ แต่การพิมพ์โค้ดที่ถูกต้องตามนั้นค่อนข้างตรงไปตรงมา
    เพราะงั้นพอเปลี่ยนแนวทางเป็น “แค่พิมพ์ตามไปแบบไม่คิดมาก” อย่างน้อยในแง่การอ่านและความจำของกล้ามเนื้อ ฉันก็ได้ฝึกมากกว่าหลายสัปดาห์ก่อนหน้าในเวลาเพียงไม่กี่ชั่วโมง
    แน่นอนว่าความเข้าใจก็สำคัญ แต่จากประสบการณ์ของฉัน มันเป็นอีกแกนหนึ่งแยกต่างหาก และมักจะตามมาทีหลังจากความจำกับความคล่อง
    การเข้าใจอะไรบางอย่างในเชิงทฤษฎีกับการใช้งานมันได้จริงนั้นต่างกันมาก
    หลักการทั่วไปที่อยู่เบื้องหลังเรื่องนี้คือ สมมติฐานด้านข้อมูลป้อนเข้า ของ Stephen Krashen: https://en.wikipedia.org/wiki/Input_hypothesis
    แนวคิดคือเด็กเรียนภาษาโดยแค่ฟัง พอได้สัมผัสกับข้อมูลป้อนเข้าก็เรียนรู้ภาษาได้ และผู้ใหญ่ก็น่าจะเรียนแบบเดียวกันได้
    ฉันเคยเห็นเรื่องนี้จากเว็บไซต์ยอดเยี่ยมชื่อ All Japanese All The Time ซึ่งตอนนี้อาจไม่มีแล้ว
    ผู้เขียนบอกว่าตัวเองทดสอบสมมติฐานนี้ด้วยการฟังภาษาญี่ปุ่นจำนวนมาก และได้ความคล่องภายใน 1 ปี
    https://web.archive.org/web/20080705194055/http://www.alljap...

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

    • ใช่เลย นั่นคือ use case หลักของฉันพอดี
      มันช่วยลดกำแพงในการเริ่มโปรเจ็กต์ใหม่ และหลังจากเริ่มคุ้นแล้วก็วางฐานให้ฉันพาไปต่อได้ลึกขึ้นด้วยตัวเอง
  • ฉันคิดว่ามันแตะพื้นที่ที่น่าสนใจมาก
    ฉันก็เคยคิดอะไรคล้ายๆ กันตอนเตรียมสัมภาษณ์ system design
    ฉันลองทดลองกับชุดบทความบล็อกไม่กี่ชุดเกี่ยวกับการออกแบบ Twitter และ WhatsApp: https://prepcommons.com/
    ถึงอย่างนั้นมันก็ยังต้องใช้ความพยายามมากกว่าการแค่จัดการคำขอตั้งต้น
    AI ทำให้ทุกคนสร้างผลลัพธ์ระดับกลางๆ ได้ แต่ถ้าจะให้ได้ผลลัพธ์ที่ดีจริงก็ยังต้องมี รสนิยมและสายตา อยู่ดี
    คิดว่าน่าจะใช้กับบทเรียนได้เหมือนกัน

  • เป็นโปรเจ็กต์ที่น่าสนใจมาก ฉันตั้งใจจะลองใช้ดู
    เวลาศึกษาหัวข้อใหม่ ฉันค่อนข้างชอบวิธีเอาเอกสารทั้งหมดที่มีใส่เข้าไปใน “โปรเจ็กต์” ของ LLM แล้วให้มันสอนโดยอิงจากเนื้อหาจริง เพื่อเร่งความเร็ว
    แต่ในขณะเดียวกัน ถ้าทุกอย่างถูกจัดเรียงมาอย่างพอดีตามที่ต้องการ ฉันก็กลัวว่าความเข้าใจที่ได้จากการไปดูต้นฉบับเองและค่อยๆ แกะของยากด้วยตัวเองจะอ่อนลง
    เพราะงั้นแนวทางแบบนี้ที่ยังช่วยบรรเทา ความขี้เกียจทางปัญญา ที่ LLM ชวนให้เกิดได้บ้าง แต่ก็เน้นการลงมือทำเองมากกว่า จึงตรงกับรสนิยมของฉันมาก

  • สิ่งที่ฉันอยากรู้มากกว่าคือประสบการณ์จากการใช้เครื่องมือ vibe coding ที่คุณทำขึ้นเองจริงๆ
    จากคำแนะนำอย่างเดียว ฉันยังไม่ค่อยแน่ใจว่าคุณได้ใช้มันจริงและชอบมันจริงไหม
    คุณบอกว่าใช้มันและบางทีก็โต้แย้งมันด้วย ซึ่งตัวมันเองก็อาจเป็นกลยุทธ์การเรียนรู้อย่างหนึ่งได้
    อีกอย่าง คำว่า “ทดสอบว่าทิวทอเรียลคอมไพล์ได้ไหมด้วยโมเดลอื่น” ก็ยังเรียกว่าเป็นฟีเจอร์ได้ไม่เต็มปาก
    แน่นอน ฉันไม่ได้คาดหวังทิวทอเรียลที่สมบูรณ์แบบไร้ที่ติจากพรอมป์ครั้งเดียวอยู่แล้ว
    ฉันก็ยังไม่ค่อยเข้าใจว่าทำไมต้องใช้สิ่งนี้แทนการเขียนพรอมป์ด้วยมือ และก็สงสัยด้วยว่า ChatGPT Study mode ล้มเหลวเพราะอะไร
    เพราะมันดูน่าสนใจดี

    • ฉันใช้มันค่อนข้างเยอะและชอบมาก
      แน่นอนว่าจะเขียนพรอมป์เองก็ได้
      สำหรับฉัน คุณค่าของมันอยู่ที่การมีสกิล/พรอมป์ที่ใช้ซ้ำได้คอยจัดโครงทิวทอเรียล ทำให้ Claude ช่วยให้ฉันคิดและเรียนรู้แนวคิดใหม่ๆ แทนที่จะเอาแต่ให้โค้ดมาให้คัดลอกวาง
      และด้วย local UI การตามทิวทอเรียลก็สะดวกกว่าการเลื่อนอ่าน Markdown output ของ Claude มาก
      ชุดทิวทอเรียลยังคงอยู่ต่อเนื่อง ทำให้ภายหลังฉันต่อยอดหัวข้อที่สนใจหรือขยายทิวทอเรียลต่อได้ง่ายด้วย /lathe-extend
      แต่สุดท้ายมันก็เป็นแค่เครื่องมือที่ช่วยฉันเป็นการส่วนตัว ไม่จำเป็นว่าทุกคนจะรู้สึกแบบเดียวกัน
      ฉันไม่เคยใช้ ChatGPT Study มาก่อน เลยจะลองไปดูเพิ่มเติม ขอบคุณที่บอกนะ