Ponytail คืออะไร วิธีตั้งค่า AI Agent ให้เขียนโค้ดน้อยลง

Ponytail คืออะไร

Ponytail คือชุดกฎที่ทำให้ AI coding agent เขียนโค้ดน้อยลง โปรเจกต์นี้อธิบายตัวเองไว้ในบรรทัดเดียวว่า: "ทำให้ AI agent ของคุณคิดเหมือนนักพัฒนาอาวุโสที่ขี้เกียจที่สุดในห้อง โค้ดที่ดีที่สุดคือโค้ดที่คุณไม่ต้องเขียน" โปรเจกต์นี้ใช้สัญญาอนุญาตแบบ MIT โดยไม่มี runtime ของตัวเองและไม่มีส่วนใดที่ทำงานได้ด้วยตัวมันเอง มันเป็นเพียงข้อความที่ใส่เข้าไปในคำสั่งของ agent โดยถูกจัดแพ็กเกจเป็น skill สำหรับ host ที่รองรับการโหลด skill และเป็นไฟล์กฎธรรมดาสำหรับ host ที่ไม่รองรับ

repository นี้คือ DietrichGebert/ponytail มันถูกสร้างขึ้นเมื่อวันที่ 12 มิถุนายน 2026 และมียอดดาวเกิน 90,000 stars ภายในวันที่ 1 สิงหาคม 2026 ณ วันที่ 1 สิงหาคม 2026 release ล่าสุดที่มีการติด tag คือ v4.8.4 ซึ่งเผยแพร่เมื่อวันที่ 29 มิถุนายน 2026 และหน้า releases แสดงรายการ tag ไว้สิบรายการเฉพาะระหว่างวันที่ 14 ถึง 29 มิถุนายนเท่านั้น โปรเจกต์นี้ไม่มีทีท่าว่าจะช้าลง: ณ วันที่ 17 ตุลาคม 2026 release ล่าสุดคือ v5.3.2 ซึ่งเผยแพร่ในช่วงดึกของวันที่ 16 ตุลาคม โดยเป็น release ที่สามของวันนั้นต่อจาก v5.3.0 และ v5.3.1 ก่อนหน้านั้นคือ v5.2.0 ในวันที่ 13 ตุลาคม ซึ่งห้าวันหลังจากที่ทั้ง v5.0.0 และ v5.1.0 ถูกปล่อยออกมาในวันที่ 8 ตุลาคม และ repository นี้มียอดดาวมากกว่า 165,000 stars โปรเจกต์ที่เคลื่อนไหวด้วยอัตราเร็วขนาดนี้จะเปลี่ยนแปลงไปเมื่อคุณอ่านข้อความนี้ ดังนั้นให้ pin tag ไว้ก่อนที่คุณจะสร้างสิ่งใดบนพื้นฐานของมัน

แนวคิดก่อนเริ่มใช้เครื่องมือ: หยุดที่ขั้นบันไดแรกที่ใช้งานได้

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

1. สิ่งนี้จำเป็นต้องมีอยู่จริงหรือไม่? นี่คือหลักการ YAGNI (you are not going to need it) หากคำตอบคือไม่ ให้ข้ามไป
2. สิ่งนี้มีอยู่ใน codebase นี้แล้วหรือไม่? ให้ใช้ helper หรือรูปแบบที่มีอยู่เดิมซ้ำ
3. ไลบรารีมาตรฐาน (standard library) ทำสิ่งนี้ได้หรือไม่? ให้ใช้สิ่งนั้น
4. ฟีเจอร์ของแพลตฟอร์มดั้งเดิมครอบคลุมสิ่งนี้หรือไม่? ให้ใช้สิ่งนั้น
5. dependency ที่ติดตั้งไว้อยู่แล้วแก้ปัญหานี้ได้หรือไม่? ให้ใช้สิ่งนั้น
6. สามารถเขียนให้จบในบรรทัดเดียวได้หรือไม่? ทำให้เป็นบรรทัดเดียว
7. หลังจากนั้นจึงค่อยเขียนโค้ดขั้นต่ำที่ทำงานได้จริง

นั่นคือบันไดตามที่ระบุไว้ที่ v4.8.4 และหมายเลขขั้นบันไดในส่วนที่เหลือของบทความนี้จะอ้างอิงตามนั้น ปัจจุบัน branch หลักได้รวมขั้นที่ 3 และ 4 เข้าด้วยกันเป็น "ไลบรารีมาตรฐานหรือฟีเจอร์ของแพลตฟอร์ม? ให้ใช้สิ่งนั้น เว้นแต่โปรเจกต์จะมีของตัวเอง" และเพิ่มเงื่อนไขว่า "คอมโพเนนต์ที่สร้างเองภายใน (house component) ดีกว่า widget ดั้งเดิม" ดังนั้นจึงเหลือ 6 ขั้น ลำดับยังคงเหมือนเดิม

ลำดับขั้นเหล่านี้คือสิ่งที่สร้างผลลัพธ์ ไม่ใช่ขั้นใดขั้นหนึ่งเพียงลำพัง หากสั่งให้ตัวแทนสร้างตัวเลือกวันที่ (date picker) มันจะเขียนตัวเลือกวันที่ขึ้นมา เพราะนั่นคือสิ่งที่ได้รับคำสั่งให้ทำ แต่บันไดนี้จะบังคับให้มันตรวจสอบสิ่งที่เคยมีอยู่ก่อนที่จะสร้างอะไรใหม่: ขั้นที่ 2 จะถามว่า repository มีคอมโพเนนต์สำหรับงานนี้อยู่แล้วหรือไม่ และขั้นที่ 4 จะบอกว่าเบราว์เซอร์มี <input type="date"> อยู่แล้ว เกณฑ์มาตรฐานปัจจุบันของโปรเจกต์ระบุถึงกรณีนี้ไว้อย่างชัดเจน: ตัวเลือกวันที่ที่เคยใช้โค้ด 335 บรรทัดหากไม่มีกฎนี้ จะเหลือเพียง 10 บรรทัดด้วย Ponytail 5 เพราะตัวแทนนำคอมโพเนนต์ Input ของ repository เองมาใช้ซ้ำด้วย type="date" และปล่อยให้เบราว์เซอร์จัดการส่วนปฏิทิน ตัวเลือกสี (colour picker) ลดขนาดลงน้อยกว่า คือจาก 135 บรรทัดเหลือ 26 บรรทัด ขั้นที่ 2 เป็นขั้นที่มักจะล้มเหลวโดยไม่มีการแจ้งเตือน เพราะตัวแทนที่ไม่สามารถมองเห็น helper ที่คุณมีอยู่แล้วจะเขียนตัวที่สองขึ้นมาอย่างรวดเร็ว ซึ่งเป็นช่องว่างที่ แผนผังที่สืบค้นได้ของ codebase ของคุณ ถูกสร้างขึ้นมาเพื่อปิด

คำว่า "ขี้เกียจ" ในที่นี้ไม่ได้หมายถึงความสะเพร่า และชุดกฎได้ระบุไว้โดยตรง รายการ "สิ่งที่ห้ามขี้เกียจเด็ดขาด" ครอบคลุมถึงการทำความเข้าใจปัญหาก่อนตัดสินใจ, การตรวจสอบข้อมูลขาเข้าที่ขอบเขตความน่าเชื่อถือ (trust boundaries), การจัดการข้อผิดพลาดที่ป้องกันข้อมูลสูญหาย, ความปลอดภัย, การเข้าถึงได้ (accessibility) และทุกสิ่งที่คุณระบุชื่อไว้ นอกจากนี้ยังกำหนดให้มีตัวตรวจสอบที่รันได้ขนาดเล็กหนึ่งตัวต่อตรรกะที่ไม่ซับซ้อน กฎนี้ช่วยลดการคิดค้นสิ่งใหม่โดยไม่จำเป็น แต่ไม่ได้ลดทอนความถูกต้องของงาน

สิ่งที่ repository นี้มีให้จริง

• AGENTS.md ชุดกฎที่ทำงานตลอดเวลา ซึ่งเป็นแนวคิดทั้งหมดในไฟล์เดียวที่คุณสามารถอ่านจบได้ในห้านาที
• skills/ponytail/SKILL.md คำนิยามของ skill พร้อมคำใบ้อาร์กิวเมนต์เป็น lite, full, ultra หรือ off
• ไฟล์กฎภายใต้ไดเรกทอรีเฉพาะของ editor เช่น .cursor/rules/ และ .windsurf/rules/ สำหรับ host ที่อ่านกฎแต่ไม่ได้โหลด skill
• hooks/, benchmarks/, examples/ และ scripts/

อาร์กิวเมนต์ความเข้มข้น (intensity) จะเปลี่ยนระดับการบังคับใช้กฎ lite จะสร้างสิ่งที่คุณร้องขอและระบุตัวเลือกที่ขี้เกียจกว่าไว้ในบรรทัดเดียว full เป็นค่าเริ่มต้นและบังคับใช้ตามลำดับขั้น ultra เป็นการตั้งค่าแบบสุดโต่งของ YAGNI: มันชอบการลบมากกว่าการเพิ่มและจะโต้แย้งกับความต้องการนั้นเอง

host ที่รองรับ skill จะได้รับ slash commands ด้วย /ponytail ใช้ตั้งค่าระดับ /ponytail-review ใช้ตรวจสอบ diff เพื่อดูว่ามีการออกแบบที่ซับซ้อนเกินจำเป็นหรือไม่ /ponytail-audit ใช้ตรวจสอบทั้ง repository /ponytail-debt ใช้รวบรวมทางลัดที่คุณเลื่อนออกไปก่อน และ /ponytail-gain ใช้พิมพ์ scorecard ของ benchmark host ที่อ่านเฉพาะไฟล์กฎจะได้รับชุดกฎโดยไม่มีคำสั่ง ตั้งแต่ v5.3.0 ซึ่งปล่อยออกมาเมื่อวันที่ 16 ตุลาคม 2026 Claude Code จะมีแถบเหนือ prompt ที่แสดงต้นทุนของงาน การใช้โค้ดซ้ำ และสถานะการทดสอบ มันต้องการ Claude Code 2.1.290 หรือใหม่กว่า โดยจะไม่ปรากฏในแผงแชทของ VS Code, cloud sessions หรือ claude -p และ /ponytail band off จะซ่อนมันไว้ ตั้งแต่ v5.3.2 เป็นต้นมา /ponytail band import จะอ่าน Claude Code sessions ที่ผ่านมาของคุณหนึ่งครั้งและเพิ่มลงในบอร์ดพร้อมกับต้นทุน เวลาที่ agent ใช้ และจำนวน tokens เพื่อให้คุณสามารถเปรียบเทียบกับ sessions ที่รันภายใต้กฎนี้ได้

หากต้องการอ่านซอร์สโค้ดก่อนที่คุณจะเชื่อถือ ให้ clone ที่ tag แทนที่จะเป็น branch นี่คือ tag ที่ลำดับขั้นข้างต้นอ้างอิงถึง; ให้เปลี่ยนเป็น v5.3.2 ซึ่งเป็น tag ล่าสุด ณ วันที่ 17 ตุลาคม 2026 เพื่ออ่านข้อความปัจจุบัน:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

สำหรับ Claude Code โปรเจกต์ได้จัดทำเอกสารการติดตั้ง plugin ไว้แทน และสองบรรทัดนี้เป็นไปตามที่ระบุไว้ในเอกสาร ณ วันที่ 17 ตุลาคม 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

path ของ plugin จะติดตาม branch หลักแทนที่จะเป็น tag ดังนั้นคำสั่งที่ควบคุม agent ของคุณอาจเปลี่ยนแปลงไปในระหว่าง sessions นี่คือข้อแลกเปลี่ยนที่คุณต้องยอมรับเพื่อแลกกับความสะดวกของคำสั่งอัปเดต

เหตุผลที่ lazy agent มีค่าใช้จ่ายถูกกว่าบน VPS

diff ที่ agent เขียนขึ้นจะไม่หายไปจากบทสนทนา ในรอบถัดไปมันจะกลายเป็นบริบทที่โมเดลต้องอ่านซ้ำ พร้อมกับทุกไฟล์ที่มันเปิดขึ้นมาเพื่อสร้าง diff นั้น การเปลี่ยนแปลงขนาด 500 บรรทัดจึงกลายเป็นภาระในทุกรอบถัดไปของเซสชันจนกว่าการทำ compaction จะเข้ามาแทนที่รอบเก่าด้วยสรุป ไม่ใช่แค่ในรอบที่สร้างมันขึ้นมา นี่คือเหตุผลที่การ refactor ที่ควบคุมไม่ได้ทำให้ agent รู้สึกช้าลงและฉลาดน้อยลงเมื่อเซสชันดำเนินไป เพราะหน้าต่างบริบทเต็มไปด้วยผลลัพธ์ของตัว agent เอง ทำให้พื้นที่สำหรับโค้ดจริงของคุณเหลือน้อยลง การควบคุมสิ่งนี้คือหัวใจสำคัญของ การจัดการ context window ของ coding agent

โทเค็นถูกคิดค่าใช้จ่ายทั้งขาเข้าและขาออก ดังนั้น diff ที่มีขนาดลดลงครึ่งหนึ่งจึงประหยัดค่าใช้จ่ายได้สองต่อ ครั้งแรกคือตอนที่มันถูกเขียนขึ้น และครั้งที่สองคือในทุกรอบที่ต้องอ่านมันซ้ำ การประหยัดนี้จะส่งผลต่อบิลของคุณหรือไม่ขึ้นอยู่กับวิธีการชำระเงิน เพราะ การสมัครสมาชิกแบบ Pro หรือ Max จะรองรับโทเค็นส่วนเกินได้จนถึงขีดจำกัดการใช้งานเท่านั้น หลังจากนั้นจะมีการคิดค่าใช้จ่ายผ่านเครดิตการใช้งานเพิ่มเติม ในขณะที่การเรียกเก็บเงินผ่าน API แบบ per-token จะคิดค่าใช้จ่ายทุกโทเค็นที่คุณใช้ หากคุณกำลังตรวจสอบค่าใช้จ่ายในการตั้งค่าแบบ self-hosted ไฟล์คำสั่ง (instruction file) คือเครื่องมือที่ช่วยลดต้นทุนได้โดยไม่มีค่าใช้จ่ายเพิ่มเติม การควบคุมค่าใช้จ่ายของ AI agent เริ่มต้นที่ปริมาณผลลัพธ์ และ วิธีการที่ coding agent ใช้โทเค็น จะอธิบายว่าเหตุใดการอ่านซ้ำจึงมีความสำคัญมากกว่าที่หลายคนคาดคิด

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

บนเซิร์ฟเวอร์ ความเสี่ยงจะเปลี่ยนไป เพราะ agent มักทำงานโดยไม่มีใครเฝ้าดู agent ที่ทำงานในเซสชัน tmux หรือทำงานตามเวลาที่กำหนดอาจมีเวลาหลายชั่วโมงในการสร้างงานบนการตัดสินใจที่ผิดพลาดก่อนที่คุณจะเห็นมัน นี่คือความเสี่ยงในทางปฏิบัติของ การรัน coding agent บน VPS และเป็นเหตุผลที่ผู้ที่ทำ loop engineering ให้ความสำคัญอย่างมากกับคำสั่งพื้นฐาน (standing instructions) มากกว่าการเขียน prompt ทีละรายการ กฎที่อยู่ในไฟล์ที่ทำงานตลอดเวลาจะมีผลไปจนถึงรอบที่ 200 แต่กฎที่คุณพิมพ์ในแชทจะมีผลแค่รอบที่ 3 เท่านั้น นอกจากนี้มันยังส่งผลต่อเซสชันที่สองที่คุณเริ่มบนเครื่องเดิม ซึ่งจะอ่านไฟล์ที่บันทึกไว้แต่ไม่ได้รับคำสั่งใดๆ ที่คุณเคยพิมพ์ในเซสชันแรก แม้ว่า เซสชันทั้งสองจะสามารถส่งข้อความถึงกันได้ก็ตาม

การเพิ่ม dependency ใหม่เป็นอีกหนึ่งต้นทุนที่แฝงอยู่ กฎข้อที่ 5 ระบุให้ใช้สิ่งที่ติดตั้งไว้แล้วเท่านั้น ทุกแพ็กเกจที่ agent เพิ่มเข้ามาเองคือสิ่งที่คุณต้องคอยแก้ไขในภายหลัง และเป็นสิ่งที่ติดไปกับทุก container image ที่คุณสร้างจาก repository นั้น

ตัวเลข benchmark ของ Ponytail บอกอะไรเรา

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

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

แผนภูมิคือ benchmark ของ agent ในปัจจุบันของโปรเจกต์ ลงวันที่ 7 ตุลาคม 2026 การทดสอบผ่าน Claude Code 2.1.288 แบบไม่มีหน้าจอ (headless) บน Opus 5.5 ที่ระดับความพยายามเริ่มต้น ทำงานผ่าน 39 งาน โดยรัน 5 ครั้งต่อหนึ่งงานและหนึ่งรูปแบบ รวมทั้งหมด 585 เซสชัน โดยแบ่งเป็นแบบไม่มี skill, Ponytail v4.13.0 และ Ponytail 5 งานสิบสองงานเป็นตั๋วฟีเจอร์ใน full-stack-fastapi-template ของ tiangolo ซึ่งเป็น repository ของ FastAPI และ React จริงๆ โดยให้คะแนนจาก git diff ที่เกิดขึ้น ส่วนที่เหลือเป็นงานเฉพาะทาง 18 งานที่มีการตรวจสอบแบบซ่อนไว้, คำขอแอปขนาดเล็ก 6 รายการ และคำขอ "แสดงตัวอย่างให้ดูหน่อย" 3 รายการ Bash ถูกปิดใช้งานสำหรับทุกรูปแบบ จำนวน output tokens ลดลง 45 เปอร์เซ็นต์ด้วย Ponytail 5

เมื่อเทียบกับตัวเลขการรันครั้งเดียว (single shot) ที่โปรเจกต์เผยแพร่ในเดือนมิถุนายน 2026 ซึ่งมาจากโมเดลเปล่าๆ ที่ตอบคำถามทั่วไป 5 ข้อโดยมีและไม่มีกฎ โดยรายงานเป็นค่ามัธยฐานจากการรันซ้ำหลายครั้ง ผลลัพธ์แสดงให้เห็นว่ามีการใช้โค้ดน้อยลง 80 ถึง 94 เปอร์เซ็นต์ใน Haiku, Sonnet และ Opus และการตรวจสอบต้นทุนเมื่อวันที่ 17 มิถุนายน 2026 ระบุว่า Haiku มีราคาถูกลง 63 เปอร์เซ็นต์ ผลลัพธ์การทำงานของ agent ในปัจจุบันสำหรับ Ponytail 5 คือจำนวนบรรทัดของโค้ดน้อยลง 53 เปอร์เซ็นต์, ต้นทุนต่ำลง 26 เปอร์เซ็นต์ และใช้เวลาจริงน้อยลง 41 เปอร์เซ็นต์ โปรเจกต์ได้แก้ไขตัวเลขการรันครั้งเดียวอย่างรวดเร็ว ภายใน v4.8.4 เมื่อวันที่ 29 มิถุนายน 2026 README ได้พาดหัวผลลัพธ์ของ agent ไว้แล้วว่า "~54% less code (up to 94%)" พร้อมหมายเหตุว่าตัวเลข 80 ถึง 94 เปอร์เซ็นต์ก่อนหน้านี้คือ "เพดานต่อหนึ่งงาน ไม่ใช่ค่าเฉลี่ย" และได้ย้ายตัวเลขการรันครั้งเดียวไปไว้ในส่วนที่ยุบไว้ชื่อ "Older single-shot numbers" ส่วนนั้นระบุอย่างตรงไปตรงมาว่าเหตุใดจึงมีความแตกต่าง: ค่าพื้นฐานของการรันครั้งเดียวคือโมเดลเปล่าที่ "เติมคำตอบด้วยข้อความและตัวเลือก" ซึ่งเป็นสิ่งที่เอาชนะได้ง่าย ให้วัดผลกับ agent จริงที่ทำงานจริงแล้วชัยชนะจะลดลง แต่มันยังคงเป็นความจริง ซึ่งเป็นข้อเท็จจริงที่มีประโยชน์มากกว่า การรัน agent ในเดือนมิถุนายนนั้น ซึ่งเป็นตั๋ว 12 ใบใน Haiku 4.5 โดยรันครั้งละ 4 รอบ ได้ผลลัพธ์ใกล้เคียงกับตัวเลขปัจจุบันที่โค้ดน้อยลง 54 เปอร์เซ็นต์ และ README ปัจจุบันไม่ได้ระบุตัวเลขการรันครั้งเดียวไว้อีกต่อไป

ข้อควรระวังประการหนึ่งมาจากตัวโปรเจกต์เอง และเป็นสิ่งที่ตัดสินว่าสิ่งนี้จะช่วยคุณได้หรือไม่ การประหยัดโค้ดจะเห็นผลชัดเจนที่สุดในจุดที่มีกับดักของการเขียนเกินความจำเป็น (over-build) และแทบไม่มีผลเลยกับโค้ดที่น้อยที่สุดอยู่แล้ว ตารางรายชั่วโมงของเดือนตุลาคมยืนยันเรื่องนี้ โดยงานเฉพาะทางหลายงานมีจำนวนบรรทัดเท่ากันในทั้งสามรูปแบบ งาน 39 งานบนโมเดลเดียวและ host เดียว โดยปิด Bash ไม่สามารถทำนายผลลัพธ์ใน repository ของคุณได้ หากตัวเลขนี้สำคัญสำหรับคุณ ให้ทำการเปรียบเทียบกับตั๋วงานของคุณเอง ทั้งแบบที่มีและไม่มีกฎ แล้วนับจำนวนบรรทัดด้วยตัวคุณเอง

รูปแบบที่คุณสามารถคัดลอกไปใช้ได้ทันทีโดยไม่ต้องติดตั้งสิ่งใด

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

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

กฎข้อสุดท้ายนั้นมีประโยชน์ในตัวของมันเอง ธรรมเนียมปฏิบัติของ Ponytail ในรุ่นปัจจุบันคือการใช้คอมเมนต์ที่ระบุแท็ก shortcut: ซึ่งระบุถึงขีดจำกัดและช่วงเวลาที่ควรปรับปรุง (รุ่นเดือนมิถุนายน รวมถึง v4.8.4 ได้เปลี่ยนไปใช้แท็ก ponytail: แทน):

# shortcut: global lock, per-account locks if throughput matters

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

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

จุดที่กฎนี้เริ่มใช้ไม่ได้ผล

บันไดนี้ถูกปรับแต่งมาเพื่องานพัฒนาฟีเจอร์ใน codebase ที่มีอยู่แล้ว ซึ่งมักจะมีส่วนประกอบที่นำกลับมาใช้ใหม่ได้และมักจะเป็นวิธีที่ถูกต้อง แต่มันไม่ค่อยเหมาะกับโปรเจกต์ใหม่ (greenfield project) เพราะขั้นที่ 2 ไม่มีอะไรให้ใช้ซ้ำ และขั้นที่ 5 ก็ยังไม่มีอะไรติดตั้งไว้ ตัว agent อาจจะหยุดที่ขั้นที่ 1, standard library, ฟีเจอร์ของแพลตฟอร์ม หรือโค้ดบรรทัดเดียวได้ แต่ทางออกที่ประหยัดที่สุดสองทางได้หายไป ทำให้งานจำนวนมากขึ้นต้องลงเอยด้วยการเขียนโค้ดใหม่ นอกจากนี้มันยังใช้ได้ไม่ดีในจังหวะที่คุณต้องการ abstraction จริงๆ หากคุณกำลังจะเพิ่มผู้เรียกใช้งาน (caller) รายที่สี่ให้กับบล็อกโค้ดที่คัดลอกมา "shortest diff" จะมอบสำเนาชุดที่ห้าให้คุณแทน

ระดับ ultra จะท้าทายความต้องการของคุณ นั่นคือจุดประสงค์ของระดับนี้ และมันเป็นต้นทุนที่แท้จริงเมื่อคุณตัดสินใจไปแล้วและต้องการให้งานเสร็จสิ้น ให้ใช้ full สำหรับงานทั่วไป และใช้ ultra เมื่อคุณสงสัยว่าปัญหาอยู่ที่ตัวคำขอฟีเจอร์เอง

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

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

FAQ

Ponytail ทำงานร่วมกับ agent อื่นที่ไม่ใช่ Claude Code ได้หรือไม่?

ได้ Ponytail ถูกปล่อยออกมาในรูปแบบ skill สำหรับ host ที่รองรับการโหลด skill ซึ่งรวมถึง Claude Code, Codex, OpenCode, Gemini และตัวอื่นๆ ที่ระบุไว้ใน README สำหรับ editor ที่อ่านไฟล์กฎแต่ไม่ได้โหลด skill เช่น Cursor, Windsurf, Cline และ Copilot จะใช้ชุดกฎแบบ always-on จากไดเรกทอรีของกฎที่ตรงกัน แต่จะไม่ได้รับ slash commands เนื้อหาข้อความนั้นเหมือนกันไม่ว่าจะใช้แบบใด ความแตกต่างที่แท้จริงจึงอยู่ที่ว่า host ของคุณเก็บข้อความนั้นไว้ในบริบททุกรอบการสนทนา หรือเก็บเฉพาะเมื่อมีการเรียกใช้ skill เท่านั้น

agent ที่ขี้เกียจจะข้ามการทดสอบ การตรวจสอบความถูกต้อง หรือความปลอดภัยหรือไม่?

ไม่ และชุดกฎได้ระบุเรื่องนี้ไว้อย่างชัดเจน รายการ "never lazy about" ของชุดกฎระบุถึงการตรวจสอบความถูกต้องของข้อมูลที่จุดเชื่อมต่อความน่าเชื่อถือ (trust boundaries), การจัดการข้อผิดพลาดเพื่อป้องกันข้อมูลสูญหาย, ความปลอดภัย และการเข้าถึงได้ (accessibility) นอกจากนี้ยังกำหนดให้มีการตรวจสอบที่รันได้จริงขนาดเล็กสำหรับตรรกะที่ไม่ใช่เรื่องพื้นฐานทุกส่วน สิ่งที่กฎนี้ตัดออกคือโครงสร้างที่ถูกสร้างขึ้นมาเอง เช่น abstraction ที่ไม่มีใครร้องขอ และ dependency ที่ไม่มีใครต้องการ หาก agent ของคุณเริ่มละเลยการทดสอบหลังจากติดตั้งชุดกฎนี้ สาเหตุมาจากคำสั่งอื่นใน config ของคุณที่มีลำดับความสำคัญสูงกว่า ดังนั้นให้ตรวจสอบไฟล์ที่ agent โหลดเป็นลำดับสุดท้าย

ตัวเลขความเร็วและค่าใช้จ่ายที่เผยแพร่นั้นเชื่อถือได้หรือไม่?

ตัวเลขเหล่านั้นเป็นการวัดผลของโครงการเอง ซึ่งเผยแพร่พร้อมกับวิธีการวัด และควรทำความเข้าใจในบริบทนั้น ตัวเลข single shot จากเดือน June 2026 ถูกนำไปเปรียบเทียบกับโมเดลเปล่าที่เติมคำตอบด้วยข้อความบรรยายและตัวเลือกต่างๆ ซึ่ง README ในขณะนั้นได้ระบุไว้เองว่าเป็น baseline ที่อ่อน ตัวเลขเชิง agentic ในปัจจุบันมาจากเซสชัน Claude Code แบบ headless บน Opus 5.5 โดยทดสอบ 39 งาน งานละ 5 รอบ ซึ่ง 12 งานเป็นตั๋วฟีเจอร์ใน repository ของ FastAPI และ React ตัวเลขเหล่านั้นเป็นตัวเลขที่ตรงไปตรงมาสำหรับการตั้งค่าดังกล่าว แต่ไม่ใช่การคาดการณ์สำหรับ codebase ของคุณ เนื่องจากผลลัพธ์รายภารกิจของโครงการแสดงให้เห็นว่าการประหยัดทรัพยากรลดลงจนเกือบเป็นศูนย์ในโค้ดที่มีความเรียบง่ายอยู่แล้ว

ฉันจำเป็นต้องติดตั้งอะไรเพื่อให้ได้รับประโยชน์หรือไม่?

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

ฉันจะป้องกันไม่ให้ agent ที่ทำงานโดยไม่มีผู้ดูแลสร้างโค้ดมากเกินไปในตอนกลางคืนได้อย่างไร?

ให้ใส่กฎไว้ในไฟล์คำสั่งแบบ always-on แทนที่จะใส่ในข้อความแชท เพื่อให้กฎมีผลในรอบที่ 200 ของการรันระยะยาว ไม่ใช่แค่ในรอบที่ 3 จากนั้นให้จำกัดความเสียหายแยกต่างหาก โดยให้ agent ทำงานบน checkout ที่คุณยอมให้พังได้แทนที่จะเป็นสำเนาหลักของคุณ และกำหนดให้ต้องมีการรีวิว diff โดยมนุษย์ก่อนที่จะมีการ merge ใดๆ กฎที่เน้น diff ขนาดเล็กจะช่วยลดปริมาณสิ่งที่คุณต้องอ่าน แต่มันไม่ได้เป็นตัวตัดสินว่าสิ่งใดจะถูกนำไปใช้จริง และไม่ควรทำหน้าที่นั้น