- Claude Code ได้พัฒนาจากเครื่องมือเขียนโค้ดธรรมดาไปสู่ ระบบปฏิบัติการสำหรับเอเจนต์ ที่รองรับเวิร์กโฟลว์หลากหลายผ่าน การเข้าถึงระบบไฟล์และการผสานคำสั่ง Unix
- โดยเฉพาะการ ผสานเข้ากับระบบโน้ต Obsidian ที่ช่วยทำงานเขียนบันทึก วิจัย และจัดระเบียบความคิดได้แบบอัตโนมัติ พร้อมสร้างระบบปฏิบัติการสำหรับโน้ตอย่างสมบูรณ์ที่เข้าถึงได้จากมือถือผ่านการเชื่อมต่อ SSH
- ความสามารถในการเข้าถึงระบบไฟล์ คือจุดแตกต่างสำคัญ เพราะทำให้สามารถรักษาหน่วยความจำและสถานะข้ามบทสนทนาได้ แก้ข้อจำกัดร้ายแรงของ ChatGPT หรือ Claude บนเบราว์เซอร์อย่าง ข้อจำกัดของ context window และข้อจำกัดด้านหน่วยความจำ
- ปรัชญา Unix (ความเรียบง่าย การประกอบรวมกันได้ และการประมวลผล text stream) สอดคล้องอย่างสมบูรณ์กับวิธีที่ LLM ใช้เครื่องมือ จนหลักการออกแบบเมื่อ 50 ปีก่อนถูกค้นพบอีกครั้งในฐานะสถาปัตยกรรมที่เหมาะที่สุดสำหรับระบบ AI ยุคใหม่
- ผ่าน กรณีใช้งานเชิงปฏิบัติ เช่น ระบบอัตโนมัติจัดการอีเมล (Inbox Magic) และเครื่องมือโอเพนซอร์ส (Claudesidian) ผู้เขียนเน้นว่า ระบบเอเจนต์ที่อิงระบบไฟล์ คือรากฐานของ การสร้างแอปพลิเคชัน AI ที่เชื่อถือได้และดีบักได้ มากกว่าโครงสร้างแบบมัลติเอเจนต์ที่ซับซ้อน
สิ่งที่ทำให้ Claude Code พิเศษ
- ช่วงนี้ผู้เขียนมักพูดอย่างกระตือรือร้นเสมอในบทสนทนาเรื่อง AI ถึง ความสามารถอันน่าทึ่งของ Claude Code และอธิบายว่าเครื่องมือนี้ได้พัฒนาจากผู้ช่วยเขียนโค้ดธรรมดาไปเป็น ระบบปฏิบัติการสำหรับเอเจนต์อย่างเต็มรูปแบบ
- แกนสำคัญคือการ ผสานกับแอปโน้ต Obsidian ซึ่งต่างจาก Notion หรือ Evernote เพราะ Obsidian เก็บไฟล์ทั้งหมดเป็น ไฟล์ Markdown ทั่วไป ไว้บนฮาร์ดไดรฟ์ภายในเครื่อง
- คุณสมบัตินี้ทำให้มันกลายเป็นเป้าหมายในอุดมคติสำหรับเครื่องมือเขียนโค้ดด้วย AI โดยผู้เขียนเริ่มจาก Cursor ก่อน แล้วไม่นานก็ย้ายมาใช้ Claude Code
- ผู้เขียนพึ่งพาระบบนี้มากจนในที่สุดถึงกับ ตั้งเซิร์ฟเวอร์ไว้ที่บ้าน และเชื่อมต่อผ่าน SSH จากสมาร์ตโฟน เพื่อให้สามารถเขียนโน้ต อ่านโน้ต และจัดระเบียบความคิดได้แม้อยู่ระหว่างเดินทาง
- เมื่อไม่กี่สัปดาห์ก่อน ผู้เขียนได้ออกรายการ Dan Shipper's AI & I podcast เพื่ออธิบายระบบนี้อย่างลึกซึ้ง และในบทความนี้ก็ได้แบ่งปันอินไซต์เพิ่มเติมที่ค้นพบหลังจากนั้น
ความเหนือกว่าของ Claude Code เมื่อเทียบกับ Cursor
- แม้จะตอบยากกับคำถามว่า "ทำไม Claude Code ถึงพิเศษ?" แต่บทสรุปคือไม่ใช่ว่ามันดีกว่า Cursor ในทุกด้าน หากเป็นเพราะ การผสมผสานขององค์ประกอบบางอย่าง ที่ทำงานร่วมกันได้ยอดเยี่ยม
- ช่วงหลังผู้เขียนใช้มันเพื่อ สร้างสิ่งใหม่ทั้งหมดบนความสามารถของ Claude Code มากกว่าการทำงานกับโค้ดเบสเดิม
-
การประสานกับปรัชญา Unix อย่างสมบูรณ์แบบ
- ความลับของ Claude Code อยู่ที่แนวทางด้านเครื่องมือ โดยในฐานะแอปพลิเคชันบนเทอร์มินัล มันยอมแลกความเข้าถึงง่ายบางส่วนเพื่อมอบความสามารถอันทรงพลังอย่าง การผสานคำสั่ง Unix แบบเนทีฟ
- ปรัชญา Unix ถูกบันทึกโดย Doug McIlroy ใน Bell System Technical Journal ปี 1978 โดยเสนอหลักการสำคัญ 4 ข้อ:
- 1. ทำให้แต่ละโปรแกรมทำงานอย่างเดียวให้ดี สำหรับงานใหม่ให้สร้างโปรแกรมใหม่แทนที่จะเพิ่มความสามารถให้โปรแกรมเดิม
- 2. คาดไว้ว่าผลลัพธ์ของทุกโปรแกรมจะกลายเป็นอินพุตของอีกโปรแกรมหนึ่งที่อาจยังไม่เป็นที่รู้จัก
- 3. ออกแบบและสร้างซอฟต์แวร์ให้ทดลองใช้ได้เร็ว ตั้งเป้าให้ได้ภายในไม่กี่สัปดาห์ถ้าเป็นไปได้
- 4. ใช้เครื่องมือเพื่อลดภาระงานเขียนโปรแกรม แทนการพึ่งแรงงานที่ทักษะต่ำกว่า
- เวอร์ชันสรุปโดย Peter H. Salus ในปี 1994 ใน "A Quarter-Century of Unix":
- เขียนโปรแกรมที่ทำงานอย่างเดียวให้ดี
- เขียนโปรแกรมที่ทำงานร่วมกันได้
- เขียนโปรแกรมที่ประมวลผล text stream (เพราะเป็นอินเทอร์เฟซแบบสากล)
-
LLM กับคำสั่ง Unix ที่เข้ากันอย่างสมบูรณ์แบบ
- หลักการอายุ 50 ปีเหล่านี้ ตรงกับวิธีที่ LLM ใช้เครื่องมืออย่างแม่นยำ
- โมเดลจะ "pipe" เอาผลลัพธ์ไปเป็นอินพุตอย่างต่อเนื่อง (พร้อมความคลุมเครือภายในของตัวเอง) โดยเชื่อมผลลัพธ์ของคำสั่งหนึ่งเข้ากับอินพุตของอีกคำสั่ง คล้ายคำสั่ง
| ของ Unix
- กรณีที่โมเดลรวมเครื่องมือได้ไม่ดี เกือบทั้งหมดมักเกิดจาก เครื่องมือซับซ้อนเกินไป
- นี่คือเหตุผลส่วนแรกที่ Claude Code น่าทึ่ง: คำสั่งที่ขับเคลื่อน Unix นั้น เหมาะกับการใช้งานของ LLM อย่างสมบูรณ์แบบ
- ไม่เพียงคำสั่งจะเรียบง่าย แต่ยังมีเอกสารอธิบายไว้อย่างดีมาก ทำให้มีแหล่งข้อมูลเพียงพอสำหรับการฝึกโมเดล
-
การปฏิวัติจากการเข้าถึงระบบไฟล์
- อีกองค์ประกอบหนึ่งคือความสามารถของ Claude Code ในการเขียนโค้ด และในช่วงหลังยังรวมถึงการเขียนร้อยแก้วด้วย
- ผู้เขียนพบคำตอบขณะอ่านบทความ วิเคราะห์เชิงลึกการสร้าง Claude Code ของ Pragmatic Engineer: นั่นคือ การเข้าถึงระบบไฟล์
- ระบบไฟล์เปลี่ยนทุกอย่าง
- ข้อบกพร่องร้ายแรงสองอย่างของ ChatGPT และ Claude บนเบราว์เซอร์คือ ไม่มีหน่วยความจำข้ามบทสนทนา และมี context window แคบ
- ระบบไฟล์แก้ได้ทั้งสองข้อ: Claude Code สามารถเขียนโน้ตให้ตัวเอง สะสมความรู้ และเก็บข้อมูลสรุประหว่างการทำงานได้
- มันจึงมี สถานะและหน่วยความจำ และสามารถคิดต่อเนื่องข้ามพ้นบทสนทนาเดี่ยวได้
AI Overhang
- เมื่อผู้เขียนเริ่มใช้ GPT-3 API ครั้งแรกในปี 2022 ก็เคยคาดการณ์ไว้ว่า แม้โมเดลจะไม่ดีไปกว่าจุดนั้นอีกแล้ว ก็น่าจะต้องใช้เวลา 10 ปีในการค้นหากรณีใช้งาน
- ในความเป็นจริงโมเดลก็ดีขึ้นจริง (โดยเฉพาะโมเดล reasoning ที่ทำให้การเรียกใช้เครื่องมือเชื่อถือได้) และการค้นพบเรื่องระบบไฟล์ก็ยืนยันมุมมองนี้
- ใน บทสัมภาษณ์ของ Pragmatic Engineer Boris Cherney ผู้สร้าง Claude Code เวอร์ชันแรก อธิบายด้วยแนวคิด "product overhang":
- product overhang หมายถึงสถานการณ์ที่โมเดลทำงานบางอย่างได้อยู่แล้ว แต่ผลิตภัณฑ์ที่รัน AI ยังไม่ได้ถูกสร้างมาเพื่อดึงความสามารถนั้นออกมาใช้
- โมเดลสามารถสำรวจระบบไฟล์ได้อยู่แล้ว เพียงแต่ยังไม่มีผลิตภัณฑ์ที่สร้างขึ้นโดยมีความสามารถนี้เป็นศูนย์กลาง
- ผู้เขียนมองว่าหัวใจสำคัญคือการรวมกันของระบบไฟล์ + คำสั่ง Unix แต่แก่นแท้คือความสามารถของโมเดลมีอยู่แล้ว และแค่รอให้ถูกปลุกขึ้นมา
- Claude Code ทำหน้าที่เหมือนพิมพ์เขียวสำหรับการสร้างระบบเอเจนต์ที่เชื่อถือได้ เพราะมันดึงความสามารถของโมเดลออกมาใช้ แทนที่จะไปจำกัดมันด้วย อินเทอร์เฟซที่ออกแบบเกินความจำเป็น
ไกลเกินกว่าแค่โค้ด
โปรเจ็กต์โอเพนซอร์ส Claudesidian
- ผู้เขียนพูดถึงการตั้งค่า Claude Code + Obsidian และก้าวไปอีกขั้นด้วยการ เปิดซอร์ส โปรเจ็กต์ "Claudesidian"
- ภายในมีเครื่องมือและคำสั่งจำนวนมากที่ใช้ในชุดการทำงาน Claude Code + Obsidian ของผู้เขียน
- มันถูกใช้เป็นสนามทดลอง โดยเฉพาะสำหรับสร้าง เครื่องมืออัปเกรดระยะแรก
- เมื่อมีการเปลี่ยนแปลงจากศูนย์กลาง ก็สามารถดึงเข้ามาใน Claudesidian ของผู้เขียนได้ และ AI จะตรวจสอบว่ามีการแก้ไขในไฟล์ที่กำลังอัปเดตหรือไม่ หากมี ก็จะพยายาม รวมการอัปเดตใหม่กับการเปลี่ยนแปลงเดิมอย่างชาญฉลาด
- ทั้งสองโปรเจ็กต์ยึดตามหลักปรัชญา Unix เดียวกัน: เรียบง่าย ประกอบรวมกันได้ ทำงานอย่างเดียวให้ดี และทำงานร่วมกันได้
Inbox Magic - ระบบอัตโนมัติสำหรับอีเมล
- ผู้เขียนกำลังทำโปรเจ็กต์ชื่อ "Inbox Magic" (ตั้งใจจะหาชื่อที่ดีกว่านี้) ซึ่งยังไม่พร้อมเปิดตัว แต่จะปล่อยออกมาในเร็ว ๆ นี้
- มันคือรีโพซิทอรี Claude Code ที่เข้าถึงชุดเครื่องมือ Gmail ได้ และผ่านพรอมป์ต์กับคำสั่งจำนวนมาก ก็ทำหน้าที่ เหมือนผู้ช่วยดูแลอีเมล
- ความสามารถในตอนนี้ยังค่อนข้างเรียบง่าย:
- สามารถรันการค้นหา หรือส่งอีเมลแทนได้
- สามารถรัน การฝึกทั้งชุด เพื่อจัดหมวดหมู่อีเมลและเรียนรู้สไตล์การเขียนอีเมลได้
- ทั้ง Claude Code และ ChatGPT เข้าถึงอีเมลได้ แต่โดยมากจะดึงมาเพียงครั้งละหนึ่งหรือสองฉบับ
- ระบบนี้สามารถเขียนลงไฟล์และใช้เทคนิคต่าง ๆ ได้ จึงทำงานอย่างเช่น "ค้นหาอีเมลเกี่ยวกับการเดินทางทั้งหมดในกล่องจดหมาย สร้างโปรไฟล์พฤติกรรมการเดินทาง แล้วนำไปใช้เป็นพรอมป์ต์ให้ ChatGPT/Claude ทำวิจัยการเดินทางให้ตรงกับความชอบจริง" ได้
- ถ้าอยากลองทดสอบ ผู้เขียนบอกว่าส่งชื่อผู้ใช้ GitHub มาได้ และจะแชร์ให้ทันทีที่พร้อมสำหรับการทดสอบ
บทเรียนสำคัญ
- โดยปกติผู้เขียนไม่ค่อยชอบสรุปตอนท้าย แต่ในที่นี้มีบทเรียนบางข้อที่ควรย้ำอีกครั้ง:
- 1. ระบบไฟล์คือเครื่องมือชั้นยอดในการแก้ปัญหาการขาดหน่วยความจำและสถานะของ LLM และควรถูกใช้งานให้บ่อยขึ้น
- 2. หากต้องการให้การเรียกใช้เครื่องมือทำงานได้ดี ควร โฟกัสที่การยึดตามปรัชญา Unix
- 3. Claude Code คือพิมพ์เขียวของระบบเอเจนต์แห่งอนาคต
- ระบบไฟล์ + ปรัชญา Unix ควรเป็นแม่แบบในการสร้าง AI agent ที่เชื่อถือได้และดีบักได้ มากกว่าระบบมัลติเอเจนต์ซับซ้อนที่กำลังเป็นกระแสอยู่ทุกวันนี้
- ในเชิงปฏิบัติ เมื่อต้องสร้างการเรียกใช้เครื่องมือให้กับโปรเจ็กต์ของตัวเอง สิ่งสำคัญคือทำให้มันเรียบง่าย และให้เธรดหลักของโมเดลเป็นฝ่าย "pipe" สิ่งเหล่านั้นเข้าหากัน
- ปัญหาใหญ่ที่ทุกเอเจนต์/แชตบอตต้องแก้คือ ความสามารถในการ pipe โดยไม่ต้องผ่าน context window
- 4. คนที่ยังหากรณีใช้งานของ LLM ไม่เจอ อาจยังพยายามไม่มากพอ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันชอบมากที่ Claude Code ทำงานแบบ Unix ทำให้สร้างเครื่องมือสไตล์ Unix อื่นๆ ได้ง่าย และ Claude ก็ใช้ได้ทันทีโดยไม่ต้องทำงานอินทิเกรตเพิ่ม แค่ให้ man page ของเครื่องมือไป Claude ก็ใช้งานได้อย่างคล่องแคล่ว ทำงานต่อได้โดยไม่ต้องมี MCP หรือการนิยามเครื่องมือที่ซับซ้อน แม้แต่เครื่องมือเข้าถึงเบราว์เซอร์ที่ฉันทำเองก็ทำงานร่วมกันได้ไม่มีปัญหา
ช่วงหลังที่เข้าสู่ยุค LLM ฉันเพิ่งอัปเดตเครื่องมือที่ช่วยค้นหา man page ได้ดีขึ้นชื่อ Mansnip และคิดว่าการห่อมันด้วย STDIO MCP ก็น่าจะเป็นวิธีที่ดี ถ้าเอา API มาครอบโค้ดนี้แล้วใส่เซิร์ฟเวอร์ลงใน pip ก็น่าจะดีเหมือนกัน ดูแล้วไม่น่ายากมาก
สงสัยว่า Claude Code ใช้เบราว์เซอร์ผ่านสคริปต์หรือเครื่องมือของฉันอย่างไร เพราะฉันอยากควบคุมหน้าต่างเซสชัน Safari ที่ใช้อยู่โดยตรง แต่ส่วนใหญ่รองรับแค่ Chrome หรืออินสแตนซ์ใหม่แยกต่างหาก
มีช่วงหนึ่งที่ฉันตระหนักว่า แทนที่จะให้ Claude ช่วยหาปัญหาเอง การสอนวิธีใช้ linter ให้มันรู้กลับมีประสิทธิภาพกว่ามาก ต่อให้ไม่ได้ระบุเลยว่าต้องใช้ linter ตัวไหน แค่บอกรายการให้และติดตั้งไว้ มันก็หยิบไปใช้ได้ทันที ตอนลองเขียนโค้ดกับ ChatGPT ก่อนหน้านี้ ฉันต้องออกแรงมากเกินไปกว่าจะได้ผลลัพธ์ที่มีประโยชน์ เลยไม่ได้คาดหวังอะไร แต่กับ Claude Code นี่เป็นประสบการณ์ที่น่าทึ่งจริงๆ
แอป GUI ทุกตัวล้วนแตกต่างกันและเหมือนสร้างกำแพงของตัวเองขึ้นมา ราวกับเป็นปราสาทที่แยกตัวอยู่ภายใน OS แต่ CLI คือจัตุรัสกลางที่ทุกคนมารวมตัวกัน เป็นตลาดข้อมูลที่ข้อมูลและสัญญาณไหลเวียนกันได้ การจะเข้ามาในจัตุรัสนี้ไม่จำเป็นต้องสังกัดที่ไหนเลย สิ่งที่ใกล้เคียงในฝั่ง GUI คือ Smalltalk แต่ถึงอย่างนั้นก็ยังต้องประกาศความจงรักภักดีก่อนถึงจะเข้าไปได้
ที่จริงแล้วในโลก GUI ก็มีระบบที่รองรับการทำงานร่วมกันและการประกอบต่อกันได้ดีอยู่เหมือนกัน เช่น NextSTEP หรือ dbus ถ้าต้องการ GUI ก็สามารถสร้างบนพื้นฐานของ API แบบเปิดแล้วใส่กราฟิกทับเข้าไปได้ ไม่ใช่ว่าทำไม่ได้ แค่ไม่ค่อยพบเห็นบ่อยนัก
ถึงจะดูเหมือนป้อมปราการที่ติดอยู่ใน OS แต่จากมุมมองผู้ใช้ทั่วไปแล้ว GUI app ก็ยังเป็นสิ่งที่คนชอบมากกว่า CLI app อย่างมาก ถ้ามีแต่ CLI อย่างเดียว การแพร่หลายของคอมพิวเตอร์คงช้ากว่านี้มาก
แค่มีเครื่องมือใหม่เกิดขึ้นแล้วรันในเทอร์มินัล ไม่ได้แปลว่าเป็น “การสืบทอดปรัชญา UNIX อย่างแท้จริง” เสมอไป การเปรียบเทียบแบบนี้เองก็ไม่ค่อยสมเหตุสมผล เท่ากับว่าฉันโดนหัวข้อชวนคลิกสไตล์ Hacker News หลอกจนได้
ปรัชญา UNIX ที่พูดถึงกันตรงนี้ไม่ได้หมายถึงแค่แอปบนเทอร์มินัล แต่หมายถึงการที่ LLM สมัยใหม่สามารถรันคำสั่งเชลล์ได้โดยตรง ซึ่งทำให้ LLM เข้าสู่ระดับที่สามารถทำกิจกรรมแทบทุกอย่างที่มนุษย์ทำได้ในเชลล์
ถ้ามองแก่นของปรัชญา UNIX จะมีอยู่ประมาณนี้ 1) โปรแกรมเล็กๆ ที่ทำอย่างเดียว 2) โปรแกรมเหล่านี้ประกอบกันเพื่อทำงานที่ซับซ้อนกว่าได้ 3) ใช้สตรีมข้อความเป็นอินเทอร์เฟซสากล ซึ่งทั้งหมดนี้เข้ากับ LLM อย่างมาก อินเทอร์เฟซข้อความเดียวอย่าง exec() ทำให้เครื่องมือทุกอย่างทำงานกับไฟล์และรับส่งข้อมูลเป็นข้อความได้ LLM จึงหยิบไปใช้ได้ทันที โครงสร้างซอฟต์แวร์แบบนี้ไม่ใช่สิ่งที่หลีกเลี่ยงไม่ได้ แต่พอสร้างมาแบบนี้แล้วกลับเหมาะกับ LLM มากพอดี
คอมเมนต์ 3 อันดับบนสุดก็ยังให้ความรู้สึกเหมือน LLM เป็นคนสั่งให้เขียนเพื่อโปรโมตตัวเองทั้งหมด
เคยมีคนพูดกันมากว่า CLI ตายไปแล้ว แต่ช่วงนี้กลับกลายเป็นว่า CLI กลายเป็นอินเทอร์เฟซที่เหนือกว่าเพราะมีเครื่องมืออย่าง claude code แน่นอนว่าฉันไม่ได้ตั้งใจจะเอาเรื่องนี้ไปสร้างความขัดแย้งกับใคร แต่การเปลี่ยนสมดุลแบบนี้ก็น่าสนใจดี
ที่จริงแล้วสำหรับผู้ใช้ที่ชำนาญรวมถึงนักพัฒนาเอง แทบไม่เคยได้ยินคำว่า “CLI is dead” เลย ผู้ใช้ทั่วไปอาจรู้สึกว่า CLI หายไปหลัง GUI ปรากฏขึ้น แต่ในความเป็นจริง CLI อยู่เบื้องหลังมาตลอด OS X ก็ให้ Unix shell แบบเต็มรูปแบบ, Windows ก็มี PowerShell, ส่วน Linux นั้นครองตลาดเซิร์ฟเวอร์ไปแล้วด้วยซ้ำ
ฉันเองก็สร้างอินเทอร์เฟซ GUI แบบคัสตอมด้วย กำลังทำสภาพแวดล้อมเดสก์ท็อปทั้งชุดให้เข้ากับวิธีใช้งานคอมพิวเตอร์ในแบบที่ฉันชอบ แต่ก่อนฉันใช้เทอร์มินัลบ่อยเพราะเครื่องมือ GUI กระแสหลักใช้งานไม่สะดวก ทว่าช่วงนี้สภาพแวดล้อม UI ของฉันก็ค่อยๆ ดีขึ้นเรื่อยๆ
การจับคู่ Claude กับ Obsidian สร้างเวิร์กโฟลว์ที่ดีมาก ฉันโยนงานจัดการโน้ตที่ซ้ำๆ ให้ AI ทำทั้งหมด ฉันเก็บ daily note แบบ stream of consciousness เอาไว้ แล้วค่อยดึงไอเดียใหม่ โปรเจกต์ หรือเอกสารอ้างอิงออกมาจากตรงนั้น Gemini ก็ทำงานได้ดีพอเหมือนกัน
สิ่งที่อยากพูดถึงมากในเรื่องการรวม LLM เข้ากับ Obsidian ก็คือปลั๊กอิน ปลั๊กอินของ Obsidian ปรับแต่งได้ง่าย และสามารถให้ JavaScript script ทำงานจากโฟลเดอร์โลคัลได้ Claude Code เก่งมากในการเขียนและแก้ไขปลั๊กอินแบบนี้ ตัวอย่างเช่น ฉันทำโปรแกรมคัสตอมที่ซิงก์ไฟล์ Obsidian ไปยัง Github repo อัตโนมัติตาม publish flag และผลก็คือทุกครั้งที่อัปเดตโน้ต เว็บไซต์ของฉันบน Netlify จะอัปเดตตามทันที
สำหรับผู้เขียนแล้ว บริการแบบ omnara.com ที่เข้าถึงได้ตรงจากมือถือโดยไม่ต้องใช้ SSH อาจเหมาะกว่า ฉันเองก็ใช้สภาพแวดล้อมคล้ายกัน โดยเปิด Obsidian และ Claude Code แบบ headless ทิ้งไว้ตลอด แล้วเข้าจากแอปบนมือถือได้ทันที
อยากใช้ Claude Code อยู่เหมือนกัน แต่ยังไม่รู้แน่ชัดว่าข้อมูลและไฟล์ในเครื่องจะถูกส่งออกไปทางเครือข่ายมากแค่ไหน ทำให้ในบางสถานการณ์นำมาใช้ได้ยาก
ฉันทำฟังก์ชันแบบนี้ขึ้นมาเองด้วย MCP
{ "name": "unshare_exec", "description": "เรียกใช้ไบนารีใน Linux namespace ด้วย unshare", "inputSchema": { "type": "object", "properties": { "binary": {"type": "string"}, "args": {"type": "array", "items": {"type": "string"}} }, "required": ["binary"], "additionalProperties": false } }
ตอนแรกใช้แค่ unshare อย่างเดียว แล้วก็ต้อง yak shaving อยู่พอสมควร แต่สุดท้ายก็ทำให้รัน gemma3 แบบโลคัล พร้อมใช้ยูทิลิตีสาย debian ได้อย่างอิสระ และได้ผลลัพธ์ที่น่าทึ่งมาก
ฉันอยากได้สภาพแวดล้อมที่เป็น Obsidian แบบโลคัล, local LLM และทุกอย่างเป็นโอเพนซอร์สทั้งหมด และกำลังรอคอยอนาคตแบบนั้น
LLM ทำให้ประโยชน์ใช้สอยและคุณค่าของโปรแกรมโอเพนซอร์สยิ่งสูงขึ้นไปอีก เมื่อก่อนถึงจะเป็นโอเพนซอร์ส แต่การทำความเข้าใจโครงสร้างโค้ดก็ยาก เลยไม่ง่ายที่จะเข้าไปแก้เอง แต่ตอนนี้ถ้าใช้ LLM งานอย่างแพตช์เล็กๆ หรือเพิ่มฟีเจอร์ใหม่ทำได้ง่ายขึ้นมาก หมายความว่าโปรแกรมต้องเป็นโอเพนซอร์ส ฉันถึงจะปรับแต่งให้ตรงใจได้ และเรื่องนี้สำคัญกว่าที่เคยมาก
แค่ open-weights อย่างเดียวยังไม่พอ ต้องเข้าถึงได้ถึง dataset และ training pipeline ด้วยถึงจะมีความหมายจริง แน่นอนว่าคนทั่วไปอาจไม่มีโครงสร้างพื้นฐานพอจะรัน training pipeline เอง แต่เราควรรู้ได้อย่างโปร่งใสว่าข้อมูลถูกใช้อย่างไรและโมเดลถูกฝึกอย่างไร จึงจะพูดถึงความเป็นเจ้าของที่แท้จริงและการประเมินอคติได้
local Org mode, local LLM และมี Emacs เป็นตัว orchestration ทุกอย่าง ถ้าได้สภาพแวดล้อมที่ขับเคลื่อนด้วย free software ทั้งหมดก็คงยอดเยี่ยมมาก ถ้าเกษียณแล้วมีเวลามากพอ ฉันอยากลองทำมันจริงๆ
ถ้าสนใจ ขอแนะนำบทความนี้ https://laurentcazanove.com/blog/obsidian-rag-api
อดสงสัยไม่ได้ว่าการรันโมเดลขนาดที่ใช้งานได้จริงไว้บนเครื่องโลคัลนั้นเป็นไปได้จริงหรือไม่ โดยเฉพาะถ้าเป็นเครื่องพัฒนาระดับ 64GB RAM กับ single GPU setup ก็น่าจะลำบากอยู่มาก