Abide เป็นเครื่องมือเสริมขนาดเล็กสำหรับ coding agent อย่าง Claude Code, Codex และ OpenCode คอยตรวจจับเวลาที่ agent แก้โค้ดผิดกฎในไฟล์ CLAUDE.md ของโปรเจกต์ แล้วสั่งให้แก้ทันทีก่อนจะทำงานต่อ

ถ้าคุณลองเปิดไฟล์กฎประจำโปรเจกต์อย่าง CLAUDE.md หรือ AGENTS.md ขึ้นมาดู จะพบว่ากฎมักแบ่งออกเป็น 2 แบบหลักๆ

แบบแรกคือกฎเรื่องรูปแบบโค้ด เช่น การจัดย่อหน้า เว้นวรรค หรือ import ที่ไม่ได้ใช้ ซึ่ง linter ที่เป็นเครื่องมือตรวจจับรูปแบบโค้ดอัตโนมัติช่วยจัดการให้อยู่แล้ว

แบบที่สองคือกฎที่ต้องใช้วิจารณญาณ เช่น "ห้ามเขียนโค้ดตรวจข้อมูลเอง ให้ใช้ไลบรารีอย่าง Yup เสมอ" หรือ "อย่าแยกฟังก์ชันออกมาถ้าเรียกใช้แค่จุดเดียว" กฎกลุ่มนี้ไม่มี linter ตัวไหนช่วยตรวจให้ พอ agent อ่านกฎแล้ว แม้ดูเหมือนจะเข้าใจ แต่พอเริ่มแก้โค้ดก็มักทำผิดกฎตั้งแต่จุดแรก โดยไม่มีอะไรแจ้งเตือนให้เรารู้ตัวเลย

Abide สร้างขึ้นมาเพื่อแก้ปัญหากฎแบบที่สองนี้โดยเฉพาะ ทุกครั้งที่ agent แก้ไขไฟล์ Abide จะส่งกฎทีละข้อพร้อม diff หรือส่วนต่างโค้ดที่เพิ่งเปลี่ยน ไปถาม Jev โมเดล AI ช่วยตัดสินใจจาก TypeSafe ตัวโมเดลไม่ได้ตอบเป็นข้อความยาวๆ แต่ตอบกลับมาเป็นตัวเลขความน่าจะเป็นภายในเวลาประมาณ 300 ms ถ้าคะแนนความน่าจะเป็นสูงพอ agent จะได้ข้อความแจ้งเตือนทันทีว่าทำผิดกฎข้อไหน ในไฟล์ใด และต้องแก้ไขอย่างไรก่อนทำงานต่อ ทั้งหมดนี้เกิดขึ้นและจบในเทิร์นเดียวกัน โดยที่เราไม่ต้องคอยนั่งเฝ้าหน้าจอ

Agent ทำผิดกฎข้อที่ linter ตรวจไม่ได้เฉลี่ย 1 ใน 13 เทิร์น

ตัวเลขนี้มาจากการทดสอบย้อนหลังของ coldteadotai ทีมผู้พัฒนา Abide ที่นำประวัติ session จริงของ Claude Code จำนวน 93 session จาก 2 โปรเจกต์มาตรวจซ้ำ รวมการแก้โค้ดทั้งหมด 1,256 edit ใน 147 เทิร์น แล้วนำโค้ดที่แก้ในแต่ละ edit ไปเทียบกับกฎใน AGENTS.md ของโปรเจกต์นั้นๆ ผลปรากฏว่า agent ทำผิดกฎข้อที่ linter ตรวจไม่ได้เฉลี่ย 1 เทิร์นในทุกๆ 13 เทิร์น โดยมีค่าใช้จ่ายในการตรวจทั้งหมดเพียง 22 เซนต์

อย่างไรก็ตาม ตัวเลขสำคัญที่ต้องดูควบคู่กันคือความแม่นยำในการตรวจจับ เมื่อเทียบสิ่งที่ Jev ชี้ว่าผิด กับสิ่งที่คนตรวจยืนยันว่าผิดจริง จะเห็นความแตกต่างระหว่าง 2 ระดับ:

• ระดับเทิร์น: แม่นยำสูง โดย Jev ชี้ว่าผิด 15 เทิร์น และคนตรวจยืนยันว่าผิดจริงถึง 11 เทิร์น ซึ่งมักเป็นกฎประเภทการแยกฟังก์ชันออกมาทั้งที่เรียกใช้แค่ครั้งเดียว ไฟล์มีขนาดใหญ่เกินไป หรือเขียนตรรกะโค้ดซ้ำซ้อน
• ระดับ edit รายครั้ง: ยังมีการแจ้งเตือนเกินจริงอยู่พอสมควร โดย Jev ชี้ว่าผิด 39 edit แต่คนตรวจยืนยันว่าผิดจริงเพียง 10 edit เท่านั้น

ตัวเลขชุดนี้บอกเรา 2 เรื่องพร้อมกัน เรื่องแรกคือ agent ทำผิดกฎเหล่านี้จริงและเกิดขึ้นบ่อยกว่าที่คิด ส่วนเรื่องที่สองคือการตัดสินของระบบตรวจจับยังต้องเผื่อใจไว้บ้างว่าอาจคลาดเคลื่อน โดยเฉพาะการแจ้งเตือนหลังการแก้โค้ดแต่ละ edit เดี่ยวๆ สามารถดูรายละเอียดวิธีวัดผลและตารางแยกรายกฎได้ใน เอกสาร benchmark ของ Abide

ทำไมไม่ให้ LLM ตรวจทุก edit ไปเลย

คำตอบสั้นๆ คือทั้งแพงและช้าเกินไปถ้าจะตรวจทุกครั้งที่แก้โค้ด

ถ้าเราใช้โมเดล LLM ทั่วไปที่ใช้คุยแชตมาอ่านกฎคู่กับ diff ในแต่ละครั้ง จะกินข้อมูลราว 2,500 token มีค่าใช้จ่ายตั้งแต่ 1 เซนต์ขึ้นไป และต้องรอนานหลายวินาที แต่สิ่งที่น่าปวดหัวยิ่งกว่าค่าใช้จ่ายคือรูปแบบคำตอบ เพราะ LLM มักตอบกลับมาเป็นข้อความยาวๆ ทำให้เราต้องเขียนโค้ดมาแกะคำตอบอีกทีว่าตกลงผิดหรือไม่ผิด แถมยังเชื่อถือได้ไม่เต็มร้อย ในการทำงานจริง agent แก้ไฟล์ราว 200 ครั้งต่อวัน วิธีส่งให้ LLM ทั่วไปตรวจจึงตกไปตั้งแต่แรก

Abide จึงเปลี่ยนไปใช้ Jev ของ TypeSafe แทน เพราะ Jev ออกแบบมาให้รับคำถามที่มีโครงสร้างแน่นอน และตอบกลับมาเป็นตัวเลขความน่าจะเป็นเพียงค่าเดียว รูปแบบคำถามของ Abide จึงตรงไปตรงมา คือส่งกฎ 1 ข้อบวกกับ diff 1 ก้อน แล้ว Jev จะตอบกลับมาเป็นตัวเลขเดี่ยวๆ เช่น 0.86 ซึ่งผ่านการปรับเทียบความแม่นยำมาแล้ว ทำให้เรานำตัวเลขนี้ไปเทียบกับเกณฑ์ เพื่อตัดสินใจได้ทันทีโดยไม่ต้องตีความซ้ำ

เอกสารของ Abide ระบุว่าวิธีนี้ช่วยประหยัดค่าใช้จ่ายได้มากกว่าการใช้ LLM ทั่วไปถึง 100 เท่า จนการส่งตรวจทุก edit คุ้มค่าและนำไปใช้จริงได้ ใครที่สนใจรายละเอียดการทำงานของโมเดลลักษณะนี้ สามารถอ่านเพิ่มเติมได้ที่ Jev ของ TypeSafe AI

ข้อดีอีกอย่างที่ต่างจากการให้ agent ตรวจสอบโค้ดตัวเอง คือ Jev ไม่เห็นประวัติบทสนทนาเลย มันรับรู้แค่กฎกับ diff ตรงหน้าเท่านั้น ดังนั้น ไม่ว่า edit ที่ 1 หรือ edit ที่ 200 ของวัน Jev ก็ตรวจด้วยข้อมูลชุดเดียวกันและมาตรฐานเดียวกันทั้งหมด โดยไม่มีบริบทบทสนทนาที่สะสมมายาวนานมาทำให้การตัดสินใจเอนเอียง

ติดตั้ง Abide ด้วย 2 คำสั่ง แล้วใช้งาน agent ได้ตามปกติ

ขั้นตอนการติดตั้งเริ่มต้นมีเพียง 2 คำสั่ง:

npx @coldtea/abide login
npx @coldtea/abide init

คำสั่งแรกใช้สำหรับใส่ API key ซึ่งเป็นรหัสเชื่อมต่อบริการ ใช้ได้ทั้ง API key ของ TypeSafe และ key ของ Vercel AI Gateway ที่คุณมีอยู่แล้ว ระบบจะถามว่าต้องการบันทึก key ไว้ที่ไหน ถ้าเลือกบันทึกระดับเครื่อง ไฟล์จะเก็บไว้ที่ ~/.abide/.env หรือถ้าเลือกระดับโปรเจกต์ ก็จะเก็บไว้ใน .env.local (และถ้าใน repo มีไฟล์ .env อยู่แล้วก็ใช้ไฟล์เดิมได้เช่นกัน) โดยระบบจะตั้งสิทธิ์ให้อ่านได้เฉพาะเจ้าของไฟล์เท่านั้น

คำสั่งที่สองจะติดตั้ง hook เข้ากับ agent ทุกตัวที่ตรวจพบในเครื่อง เพื่อให้ระบบเรียกใช้ก่อนหรือหลังการทำงานในแต่ละขั้นตอน หลังติดตั้งเสร็จ คุณสามารถเปิดใช้ claude, codex หรือ opencode ได้ตามปกติ เมื่อเริ่มเทิร์นแรก agent จะอ่านไฟล์กฎของโปรเจกต์ แล้วแปลงเป็น rubric ชุดเกณฑ์คำถามสำหรับส่งถาม Jev เก็บไว้ที่ .abide/rubric.json พร้อมกับรายงานสรุปให้รู้ว่าพบกฎข้อใดบ้าง

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

ถ้าต้องการเลือกติดตั้งเฉพาะ agent บางตัว สามารถระบุชื่อ agent ต่อท้ายคำสั่งได้:

• npx @coldtea/abide init claude บันทึกการตั้งค่าไว้ที่ ~/.claude/settings.json
• npx @coldtea/abide init codex ติดตั้งไว้ที่ ~/.codex/hooks.json และต้องทำเพิ่มอีก 1 ขั้นตอน คือเปิด codex ขึ้นมา พิมพ์คำสั่ง /hooks แล้วกดยอมรับรายการ hook ของ Abide ทั้ง 4 รายการ
• npx @coldtea/abide init opencode ติดตั้งไว้ที่ ~/.config/opencode/plugins/abide.js เนื่องจาก OpenCode ยังไม่มีระบบ hook ในตัว จึงต้องรันในรูปแบบของปลั๊กอินแทน แต่มีกลไกการตรวจและรูปแบบข้อความแจ้งเตือนเหมือนกันทุกประการ

เนื่องจาก Codex แก้ไขไฟล์ผ่านคำสั่ง apply_patch ซึ่งส่งการแก้ไขทุกจุดมาพร้อมกันในก้อนเดียว Abide จึงอ่าน patch ชุดนั้นและตรวจทุกไฟล์ที่แก้ไขไปพร้อมกัน ส่วน OpenCode ที่ทำงานเป็นปลั๊กอิน ถ้ามี edit ใดผิดกฎ ระบบจะแนบข้อความสั่งให้แก้ไขไว้ท้ายผลการแก้ไขโค้ดนั้น และถ้าจบเทิร์นแล้วยังพบว่าทำผิดกฎ ก็จะมีข้อความแจ้งเตือนสรุปตามหลังมาอีกหนึ่งข้อความ

สุดท้าย คุณสามารถเลือกขอบเขตการติดตั้งได้ตามต้องการ โดยค่าเริ่มต้นจะเป็นการติดตั้งระดับเครื่อง ซึ่งจะมีผลกับ agent ทุกครั้งที่คุณเรียกใช้ แต่ถ้าใส่แฟล็ก --project เพิ่มเข้าไป การตั้งค่าจะผูกอยู่กับโปรเจกต์นั้นโดยตรง ทำให้เพื่อนร่วมทีมที่ clone โค้ดไปใช้ จะได้คอนฟิกของ Abide ไปด้วยโดยไม่ต้องตั้งค่าใหม่

หน้าตาข้อความแจ้งเตือนตอน Abide ตรวจพบข้อผิดพลาด

ในเอกสารของ Abide ยกตัวอย่างกรณีที่ไฟล์ AGENTS.md กำหนดกฎไว้ว่า "ให้ใช้ Yup ตรวจสอบข้อมูลเสมอ ห้ามเขียน validation เอง" พอ agent เขียนโค้ดตรวจสอบข้อมูลเองในไฟล์ API ข้อความแจ้งเตือนนี้จะปรากฏขึ้นทันที:

Abide: This edit appears to break a rule from this repository's instructions.
- Rule "api-validation-uses-yup" from ~/.codex/AGENTS.md line 65: "When writing API endpoints, do NOT write input validations manually. Use Yup (with clear validation messages) + early return in the API handler". (0.86)
Repair apps/web/src/pages/api/logout.ts now, then continue with the task.

เมื่อดูรายละเอียดในข้อความ จะเห็นว่าระบบระบุข้อมูลสำคัญที่ agent จำเป็นต้องใช้ในการแก้ไขไว้อย่างครบถ้วน ทั้งชื่อกฎ ตำแหน่งไฟล์และเลขบรรทัดต้นทางของกฎข้อนั้น ค่าคะแนนความน่าจะเป็น (0.86) และไฟล์ปลายทางที่ต้องเข้าไปแก้ทันที ทำให้ agent สลับกลับไปแก้ไฟล์นั้นให้เรียบร้อยก่อน แล้วค่อยกลับมาทำงานเดิมต่อได้เอง โดยที่เราไม่ต้องคอยพิมพ์สั่งซ้ำ

คะแนนความน่าจะเป็นจาก Jev เป็นตัวกำหนดว่าระบบจะทำอะไรต่อไป:

คะแนนช่วง 0.5 ถึง 0.8 คือระดับที่ Abide ประเมินว่าน่าสงสัย แต่ระดับความมั่นใจยังไม่สูงพอที่จะสั่งหยุดการทำงานของ agent จึงแสดงไว้ให้คุณคอยสังเกตเอง

กฎระดับ edit กับกฎระดับ turn ทำงานไม่เหมือนกัน

จุดสำคัญที่ควรรู้คือกฎแต่ละข้อไม่ได้ตรวจในจังหวะเดียวกัน กฎบางข้อ เช่น "ต้องใช้ Yup เสมอ" สามารถตรวจจับและตัดสินได้ทันทีตั้งแต่แก้โค้ดจุดแรก แต่กฎบางข้อ เช่น "อย่าเพิ่มโค้ดนอกเหนือจากที่สั่ง" ไม่สามารถตัดสินได้จากการแก้ไฟล์จุดที่ 1 จากทั้งหมด 12 จุด เพราะจำเป็นต้องเห็นภาพรวมของการแก้ไขทั้งหมดในรอบนั้นก่อน

ดังนั้น ใน rubric จึงต้องระบุจังหวะการทำงานของกฎแต่ละข้อไว้อย่างชัดเจน:

• ระดับ edit: ตรวจสอบทันทีหลังการแก้ไฟล์แต่ละครั้ง โดยดูเฉพาะ diff ของ edit นั้น
• ระดับ turn: ตรวจสอบรวบยอดครั้งเดียวตอนจบเทิร์น โดยดู diff รวมทั้งหมดที่เกิดขึ้นในเทิร์นนั้น

นอกจากนี้ แต่ละกฎยังสามารถกำหนด scope เพื่อระบุกลุ่มไฟล์ที่ต้องการบังคับใช้ได้ ทำให้โค้ดคนละส่วนของโปรเจกต์ไม่ต้องตรวจด้วยชุดคำถามที่ไม่เกี่ยวข้อง

การทำงานเบื้องหลังใช้ hook ทั้งหมด 4 ตัวต่อ agent 1 ตัว:

• เมื่อเริ่ม session: คำนวณและบันทึกค่า hash ของไฟล์กฎไว้ ถ้าพบว่าไฟล์กฎเปลี่ยนไปจากครั้งก่อน ระบบจะสั่งให้ agent แปลง rubric ใหม่อัตโนมัติ
• เมื่อเริ่มแต่ละเทิร์น: ใช้ git บันทึก snapshot ของโฟลเดอร์โปรเจกต์ทั้งหมดไว้ก่อนเริ่มลงมือ
• หลังแต่ละ edit: ตรวจกฎระดับ edit โดยส่ง diff ของการแก้ไขจุดนั้นไปประเมิน
• เมื่อจบเทิร์น: นำการเปลี่ยนแปลงทั้งหมดในเทิร์นมา diff เทียบกับ snapshot ที่บันทึกไว้ตอนเริ่ม แล้วตรวจกฎระดับ turn รวมถึงตรวจกฎระดับ edit ย้อนหลังให้กับไฟล์ที่ agent สร้างหรือแก้ไขผ่านคำสั่ง shell ซึ่ง hook ปกติในระดับ edit ตรวจจับไม่ทัน

hook ออกแบบมาให้ปลอดภัยต่อการทำงาน โดยจะไม่มีวันทำให้ session ของ agent ค้างหรือพัง ทุกกรณีจะคืนค่า exit code 0 เสมอ มีการกำหนดเวลารอที่แน่นอน และแสดงผลเฉพาะรูปแบบที่ agent ต้องการเท่านั้น

อย่างไรก็ตาม ข้อจำกัดที่ควรรู้คือ ถ้าไม่ได้ใส่ API key หรืออินเทอร์เน็ตมีปัญหา การแก้โค้ดจะผ่านไปได้โดยไม่มีการตรวจ โดย Abide จะแค่บันทึกเหตุการณ์ที่ตรวจไม่ผ่านไว้ใน .abide/events.jsonl ซึ่งคุณสามารถใช้คำสั่ง abide report ดูจำนวนครั้งที่ตรวจจริงและจำนวนครั้งที่ตรวจไม่สำเร็จได้

rubric.json เป็นไฟล์ที่คุณเปิดอ่านและแก้ไขเองได้

การตัดสินใจทั้งหมดของ Abide อิงจากไฟล์เดียวคือ .abide/rubric.json ซึ่งเปิดอ่าน ทำความเข้าใจ และ commit เข้า repo ร่วมกับโค้ดของโปรเจกต์ได้เลย

ทุกการแจ้งเตือนจะอ้างอิงชื่อกฎจากไฟล์นี้เสมอ และกฎแต่ละข้อยังระบุเลขบรรทัดต้นทางจาก CLAUDE.md หรือ AGENTS.md ไว้อย่างชัดเจน ดังนั้นถ้าพบว่าระบบตัดสินผิดพลาด ก็ไม่ใช่เรื่องลึกลับที่หาสาเหตุไม่ได้ คุณสามารถเปิดไฟล์นี้ขึ้นมาแก้ไขและปรับปรุงคำอธิบายของกฎข้อนั้นได้โดยตรง

กฎที่เขียนคลุมเครือสังเกตได้ชัดจากคะแนนที่ Jev ให้ เพราะทุก diff จะได้คะแนนก้ำกึ่งราวๆ 0.4 จนไม่เคยมีการแจ้งเตือนเลย คุณสามารถจัดการปัญหานี้ได้ด้วยคำสั่งของ Abide:

• คำสั่ง abide calibrate: จะนำกฎแต่ละข้อไปทดสอบกับ diff จริง 20 รายการล่าสุดจากประวัติ git ของ repo และช่วยปิดกฎข้อที่ได้คะแนนก้ำกึ่งแบบนี้
• คำสั่ง abide tune: จะให้ agent ช่วยเกลาและเขียนถ้อยคำของกฎข้อนั้นใหม่ให้ชัดเจนยิ่งขึ้น

ถ้าต้องการตรวจว่าโค้ดเดิมที่มีอยู่แล้วในโปรเจกต์มีจุดไหนผิดกฎบ้าง สามารถรันคำสั่ง abide audit src/ เพื่อให้ระบบสแกนทุกไฟล์เสมือนว่าเพิ่งเขียนขึ้นมาใหม่ พร้อมสรุปผลออกมาเป็นตารางแยกตามกฎและตามไฟล์ จากการทดสอบบนโปรเจกต์ Next.js จริงที่มี API route ทั้งหมด 33 ตัว การรัน audit ใช้เวลาราว 12 วินาที และมีค่าใช้จ่ายประมาณ 1 เซนต์เท่านั้น

สิ่งที่เหลือคือการแบ่งประเภทกฎ: กฎข้อไหนที่ linter ตรวจจับได้ (เช่น รูปแบบโค้ดหรือไวยากรณ์) ก็ควรปล่อยให้ linter ทำหน้าที่ต่อไป เพราะทำงานได้แน่นอน รวดเร็ว และไม่มีค่าใช้จ่ายเพิ่มเติม ส่วนกฎที่ต้องใช้วิจารณญาณหรือข้อตกลงเชิงตรรกะการทำงาน ค่อยนำมาใส่ไว้ใน rubric ของ Abide และเนื่องจาก Abide จะส่งคำถามแยก 1 ข้อต่อ 1 กฎ การใส่กฎไว้มากเกินไปก็จะทำให้ค่าใช้จ่ายในการตรวจต่อ edit เพิ่มขึ้นตามจำนวนข้อเช่นกัน

Abide ส่งข้อมูลโค้ดไปที่ไหน และมีค่าใช้จ่ายเท่าไร

ในด้านความเป็นส่วนตัว Abide จะส่ง diff ของโค้ดที่แก้ไขออกจากเครื่องของคุณตรงไปยัง TypeSafe ภายใต้ API key ของคุณเองเท่านั้น และไม่มีการส่งข้อมูลไปยังเซิร์ฟเวอร์ของผู้พัฒนา Abide แต่อย่างใด

สำหรับนโยบายการจัดเก็บข้อมูล มี 2 ทางเลือก:

• หากใช้ API key ของ TypeSafe โดยตรง: นโยบายไม่บันทึกข้อมูลตามข้อกำหนด zero data retention ต้องทำข้อตกลงระดับองค์กรอย่าง Enterprise กับ TypeSafe เพราะ API ปกติยังไม่มีตัวเลือกให้กำหนดเป็นรายคำขอ อย่างไรก็ดี TypeSafe ระบุไว้ชัดเจนว่าจะไม่นำ prompt และผลลัพธ์ของลูกค้าไปใช้เทรนโมเดล Jev เพิ่มเติม
• หากใช้ key ของ Vercel AI Gateway: คำขอจะแนบพารามิเตอร์ zeroDataRetention: true ไปด้วยโดยอัตโนมัติ เพื่อสั่งให้ Gateway เลือกส่งข้อมูลไปยังผู้ให้บริการที่มีข้อตกลงไม่บันทึกข้อมูลเท่านั้น

Abide จะค้นหา API key ตามลำดับดังนี้: เริ่มจาก Environment variable ของระบบก่อน ถ้าไม่พบจะหาในไฟล์ .env.local หรือ .env ที่ root ของ repo และสุดท้ายจึงหาใน ~/.abide/.env โดยตัวโปรแกรมจะไม่รับ key ผ่าน command-line flag และไม่มีการบันทึก key ลงในประวัติคำสั่งเพื่อความปลอดภัย

ในแง่ค่าใช้จ่าย ทีมผู้พัฒนาได้ทดสอบวัดจากการใช้งานจริงกับ repo ของ Abide เองที่มีกฎอยู่ 13 ข้อ (ข้อมูล ณ วันที่ 18 กันยายน 2026) พบว่าการตรวจ 1 edit เทียบกับกฎทั้ง 13 ข้อ ใช้ input ประมาณ 1,000 ถึง 1,600 token คิดเป็นค่าใช้จ่ายเพียง 0.00004 ถึง 0.00007 ดอลลาร์ แม้ตัวโมเดล Jev จะตอบกลับภายใน 300 ms แต่เมื่อรวมกระบวนการทำงานของ hook และการโหลด Node.js จะใช้เวลารวมราว 1 วินาทีต่อ edit ดังนั้น ใน 1 เทิร์นที่มีการแก้โค้ดประมาณ 15 edit ค่าใช้จ่ายรวมจึงอยู่ที่ราวๆ 0.1 เซนต์ (1 ใน 10 ของเซนต์) เท่านั้น

สิ่งเดียวที่คุณต้องเตรียมก่อนใช้งานคือ API key ของ TypeSafe หรือ Vercel AI Gateway ตัว Abide เองเผยแพร่แบบโอเพนซอร์สภายใต้สัญญาอนุญาต MIT สามารถถอนการติดตั้งได้ง่ายๆ ด้วยคำสั่ง abide uninstall ซึ่งจะลบเฉพาะ hook และการตั้งค่าของ Abide ส่วนไฟล์ rubric และไฟล์ key ใน ~/.abide/.env จะยังคงอยู่จนกว่าคุณจะเลือกลบออกด้วยตัวเอง

ประโยชน์ที่แท้จริงของ Abide คือช่วยให้เห็นชัดว่า ข้อความใน CLAUDE.md ข้อไหนเป็น "กฎที่มีผลบังคับใช้ได้จริง" และข้อไหนเป็นเพียง "ความคาดหวังลอยๆ" เพราะถ้าโมเดลประเมินกฎข้อไหนได้คะแนน 0.4 ตลอดเวลา กฎข้อนั้นก็แทบไม่มีผลในทางปฏิบัติมาตั้งแต่เขียนขึ้นมา ไม่ว่าคุณจะติดตั้ง Abide หรือไม่ก็ตาม

ที่มา: บทความ Abide — Make your coding agent abide by all your project rules จาก coldteadotai