เราได้สร้างลินเตอร์สำหรับ code convention ที่ใช้ LLM
(github.com/DevSymphony)สวัสดีครับ! พวกเราคือ Symphony ทีมมหาวิทยาลัยที่กำลังพัฒนา sym-cli
ช่วงนี้หลายคนใช้เครื่องมืออย่าง Cursor หรือ Claude Code เพื่อทำ vibe coding กันบ่อยไหมครับ? ทีมของเราก็ใช้ LLM อย่างจริงจังในกระบวนการพัฒนาเช่นกัน แต่พอใช้ไปสักพักก็พบว่ามีจุดที่น่าเสียดายอยู่ข้อหนึ่ง
โค้ดที่ AI เขียนให้นั้นทำงานได้ดีในแง่ฟังก์ชัน แต่กลับมักมองข้าม convention เฉพาะของทีมเราอยู่เสมอ เช่น การตั้งชื่อตัวแปร สไตล์คอมเมนต์ หรือกฎการใช้ไลบรารีบางตัว การต้องใส่กฎเหล่านี้ลงในพรอมป์ทุกครั้งก็ทั้งยุ่งยาก และใช้ไปนาน ๆ ก็ยิ่งทำให้ลืม convention กันมากขึ้นด้วย
ด้วยเหตุนี้ เราจึงเริ่มสร้าง sym-cli จากคำถามว่า "จะทำให้ LLM ตรวจสอบ convention ด้วยตัวเองก่อนเขียนโค้ด หรือระหว่างที่กำลังเขียนอยู่ได้ไหม?"
[sym-cli คืออะไร?]
sym-cli คือ policy-based code convention linter สำหรับเครื่องมือ AI coding โดยหัวใจสำคัญคือการใช้ MCP เพื่อสื่อสารกับ LLM โดยตรง
สิ่งที่แตกต่างจากลินเตอร์แบบเดิมมีดังนี้
- (การตั้งค่าด้วยภาษาธรรมชาติ) แทนที่จะใช้ไฟล์ตั้งค่าที่ซับซ้อน คุณสามารถกำหนดกฎด้วยภาษาธรรมชาติได้ เช่น "ห้ามเขียน log ด้วย print โดยเด็ดขาด" แล้ว LLM จะเข้าใจและปฏิบัติตาม
- (การเพิ่มประสิทธิภาพ context) LLM จะไม่ได้อ่านกฎทั้งหมดของโปรเจกต์ แต่จะดึงเฉพาะกฎที่จำเป็นกับงานปัจจุบันอย่างชาญฉลาดผ่านเครื่องมือ MCP
- (การตรวจสอบเชิงรุก) ผ่านเครื่องมือ
validate_codeทำให้ LLM สามารถตรวจสอบการปฏิบัติตามกฎได้ด้วยตัวเองทันทีหลังสร้างโค้ด
[ทำงานอย่างไร?]
หลังจากดาวน์โหลดคำสั่ง sym แล้วรันคำสั่ง sym init ระบบจะตั้งค่า MCP server ให้อัตโนมัติ จากนั้น IDE ที่รองรับ MCP (เช่น Cursor) หรือเครื่องมือ LLM ต่าง ๆ ก็จะเริ่มอ้างอิงกฎเหล่านี้ได้ทันที
[ขอฟีดแบ็กจากทุกคนด้วย!]
พวกเรายังเป็นทีมมหาวิทยาลัย และโปรเจกต์นี้ก็ยังอยู่ในช่วงเริ่มต้นที่เพิ่งมีโครงสร้างพื้นฐานเท่านั้น ยังมีอีกหลายจุดที่ขาดอยู่และอาจมีบั๊กได้ แต่พวกเราต้องการกำลังใจและฟีดแบ็กจากนักพัฒนาที่ทำงานจริง หรือผู้ที่สนใจเครื่องมือ LLM อย่างมาก
ไม่ว่าจะเป็น "ถ้ามีฟีเจอร์แบบนี้ก็น่าจะดี", "จุดนี้ดูมีปัญหาในเชิงโครงสร้าง", หรือ "ในงานจริงเขาใช้กันแบบนี้" เราขอบคุณทุกความเห็นเสมอ เนื่องจากเป็นโอเพนซอร์ส การร่วมพัฒนาและ GitHub Star คือพลังใจที่ยิ่งใหญ่มากสำหรับทีมของเรา!
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
ขอบคุณที่อ่านครับ
7 ความคิดเห็น
ถ้าใช้ opencode ก็รวมฟังก์ชัน lint เข้าไปในเวิร์กโฟลว์ได้ด้วย
https://th.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
เห็นด้วยครับ สิ่งที่จับได้ทันทีอย่างข้อผิดพลาดด้านไวยากรณ์หรือประเภทข้อมูลนั้น ขั้นตอน LSP หรือการคอมไพล์มีประสิทธิภาพที่สุด และผมคิดว่านี่ก็เป็นแนวทางที่เหมาะสมในแง่ของปริมาณการใช้โทเค็นด้วย ฝั่งเราก็มองว่าแทนที่ LLM จะมาแทนสิ่งนี้ บทบาทของมันใกล้เคียงกับการเชื่อมกฎที่เขียนด้วยภาษาธรรมชาติเข้ากับเวิร์กโฟลว์ lint/test เดิมโดยอัตโนมัติมากกว่า
ผมก็คิดเหมือนกับคุณ t7vonn ว่าควรจัดการคอนเวนชันให้ตรงกันด้วยเครื่องมืออัตโนมัติ
แต่ฟังก์ชัน LSP ให้ความรู้สึกว่าต่างกันพอสมควร เพราะสามารถจับและแก้ข้อผิดพลาดทางไวยากรณ์ที่ปกติต้องรัน test หรือคอมไพล์ก่อนถึงจะเจอได้ทันที เลยช่วยลดการใช้โทเค็นลงครับ
ตอนนี้ก็มีการให้เอเจนต์รีวิว PR ถือเอกสารคอนเวนชันกับ diff ไปแล้วคอยหาส่วนที่ตกหล่นอยู่แล้ว.. และคิดว่าคงจะไม่ได้ใช้เกินกว่านั้นครับ
ขอแนบบทความของคนที่มีความเห็นคล้าย ๆ กับผมครับ
ผมคิดว่าวิธีใช้งานที่คุณพูดถึงเป็นแนวทางที่สมจริงที่สุดในตอนนี้ ปัญหาที่พวกเราอยากแก้คือการลดขั้นตอนการแนบเอกสารคอนเวนชันให้ทุก PR และแปลงกฎที่นิยามด้วยภาษาธรรมชาติให้เป็นกฎ lint/กฎตรวจสอบล่วงหน้า เพื่อให้รันอัตโนมัติได้ในขั้นตอน PR/CI
อืม.. ดูเหมือนว่าน่าจะทำด้วยฟีเจอร์อย่าง hooks/subagents/skill ของ Claude ได้เหมือนกันนะ..
ในทางเทคนิคก็ดูเหมือนจะทำได้ด้วย hooks หรือ subagent แต่เราเลือกวางเลเยอร์บาง ๆ ไว้บน MCP และเวิร์กโฟลว์ของลินเตอร์เดิม เพื่อไม่ให้ผูกติดกับ LLM ใดตัวหนึ่งโดยเฉพาะ ดังนั้น แทนที่จะเน้นความสามารถแบบเอเจนต์ เราจึงมุ่งทำให้คอนเวนชันกลายเป็นโครงสร้างพื้นฐานที่นำกลับมาใช้ซ้ำได้