🎯 แก่นของเรื่อง
Ponytail เป็นชุดคำสั่ง (skill) ที่บังคับให้ AI agent ไล่ถามตามลำดับก่อนเขียนโค้ด ว่าของนี้ต้องมีไหม มีในโปรเจกต์แล้วหรือยัง มีใน standard library หรือแพลตฟอร์มหรือไม่ จึงค่อยเขียนเท่าที่จำเป็น
กลไกที่ทำให้ได้ผล
| ขั้น | เหตุ | ผล |
|---|---|---|
| 1 | AI ที่ไม่ถูกจำกัดมักสร้างของใหม่ทั้งชุด เช่น component ที่มีอยู่แล้ว | ถูกบังคับให้ค้นของเดิมก่อน จึงเขียนใหม่น้อยลง |
| 2 | โค้ดที่น้อยลงมีที่ให้บั๊กและต้องรีวิวน้อยลง | ลดเวลา ลด token และลดต้นทุนเป็นผลข้างเคียง |
| 3 | เส้นที่ห้ามตัดชัดเจน (validation, error handling, security, accessibility) | โค้ดสั้นลงโดยไม่ลดความปลอดภัย |
อ่านจาก repo (อ่านเมื่อ 2026-10-22): เป้าหมายไม่ใช่ "token น้อยที่สุด" แต่คือเขียนเท่าที่งานต้องการ
20% ที่สำคัญที่สุด
- บันไดตัดสินใจ (ladder): ใช้ของที่มีอยู่ก่อนเสมอ
- รายการห้ามตัด: ตัดโค้ดได้ แต่ห้ามตัดการป้องกัน
- บรรทัดท้ายคำตอบ: agent ต้องบอกว่าข้ามอะไรและเสี่ยงอะไร
- รอได้: band, board, การ import ประวัติ session, การตั้งค่าเสริม
📈 ช่วยให้ดีขึ้นอย่างไร
ตัวเลขทั้งหมดในตารางเป็นผลที่ README ของโปรเจกต์รายงานเอง ยังไม่มีใครภายนอกทำซ้ำในหน้านี้
| สถานการณ์ | ถ้าไม่ใช้ | ถ้าใช้ | วัดอย่างไร | หลักฐาน |
|---|---|---|---|---|
| ปริมาณโค้ดที่เขียน | baseline | ลด 53% | จำนวนโค้ดต่องาน | อ่านจาก repo (2026-10-22) เป็นค่าที่โปรเจกต์รายงานเอง |
| เวลาที่ agent ใช้ | baseline | ลด 41% | เวลาต่องาน | อ่านจาก repo, ค่ารายงานเอง |
| token | baseline | ลด 45% | token ต่องาน | อ่านจาก repo, ค่ารายงานเอง |
| ต้นทุน | baseline | ลด 26% | ค่าใช้จ่ายต่องาน | อ่านจาก repo, ค่ารายงานเอง |
| logic เสี่ยงที่มี test | 68% | 98% | สัดส่วนงานเสี่ยงที่ส่งพร้อม test | อ่านจาก repo, ค่ารายงานเอง |
| งานด้านความปลอดภัย 6 งาน | ไม่มีข้อมูล | ผ่านทั้ง 30 รัน | จำนวนรันที่ผ่าน | อ่านจาก repo, ค่ารายงานเอง |
| คุณภาพคำตอบเทียบเวอร์ชันก่อน | ไม่มีข้อมูล | ชนะ 110 ต่อ 67 | เปรียบเทียบแบบปิดชื่อ | อ่านจาก repo, ค่ารายงานเอง |
| ความเข้าใจโค้ดง่ายขึ้น | ไม่มีข้อมูล | น่าจะอ่านง่ายขึ้นเมื่อโค้ดสั้น | อ่านรีวิวแล้วใช้เวลาน้อยลงไหม | ตีความ, ยังไม่ทดสอบ |
เงื่อนไขของ benchmark ที่รายงาน: Claude Code, agent ตัวเดียวกันเทียบแบบมีและไม่มี skill, 39 งาน (รวม repo FastAPI + React), โมเดล Opus 5.5, รันงานละ 5 รอบ
ตัวอย่างในโปรเจกต์: date picker ที่เขียนเอง 335 บรรทัด เทียบกับ 10 บรรทัดที่ใช้ component Input เดิมด้วย type date
🪜 บันไดตัดสินใจ (ladder)
เลือกตัวเลือกแรกที่ใช้ได้ครบ แล้วหยุด (อ่านจาก repo: skills/ponytail/SKILL.md, เป็นเนื้อหาแบบย่อ)
| ขั้น | คำถาม | ถ้าใช่ |
|---|---|---|
| 1 | ต้องมีของนี้จริงไหม | ข้ามสิ่งที่ไม่ได้ขอ และบอกไว้หนึ่งบรรทัด |
| 2 | มีในโค้ดเบสแล้วไหม | ใช้ซ้ำตามแบบของโค้ดรอบข้าง |
| 3 | มีใน standard library หรือฟีเจอร์ของแพลตฟอร์มไหม | ใช้ เว้นแต่โปรเจกต์มีของตัวเอง |
| 4 | มี dependency ที่ติดตั้งแล้วครอบคลุมไหม | ใช้ อย่าเพิ่ม dependency เพื่อโค้ดไม่กี่บรรทัด |
| 5 | เขียนบรรทัดเดียวที่อ่านแล้วเข้าใจทันทีได้ไหม | เขียนบรรทัดเดียว |
| 6 | ไม่เข้าข้อไหนเลย | เขียนโค้ดขั้นต่ำที่ทำงานได้ |
README อธิบายว่าบันไดนี้ทำงานหลัง agent เข้าใจปัญหาแล้ว
กฎหลักอื่น
- ขอบเขต: ก่อนเขียนให้ระบุทุกที่ที่ต้องแตะ (caller, test, fixture, config, export) ฟีเจอร์เสริมไม่นับเป็นขอบเขต
- แก้เล็กแต่ครบ: วิธีแก้เล็กได้ แต่ต้องทำทุกส่วนที่งานต้องการ
- ไม่เขียนเผื่ออนาคต: ไม่เพิ่ม abstraction, wrapper, option หรือ config ที่ไม่มีใครขอ การลบดีกว่าการเพิ่ม
- คอมเมนต์: เขียนเฉพาะ "ทำไม" ที่โค้ดบอกไม่ได้ ไม่เกินหนึ่งบรรทัด
- แก้บั๊ก: grep ทุก caller ก่อน แล้วแก้ที่ต้นเหตุหนึ่งครั้งในโค้ดส่วนกลาง
- ย้ายหรือรวมโค้ด: เก็บ error handling และ validation ไว้
- ตัวเลือกขนาดเท่ากัน: เลือกตัวที่จัดการกรณีขอบได้ถูกต้อง
- ทดสอบ: logic ที่ไม่ธรรมดา (branch, loop, parser, เงิน, security) ต้องมี test เล็กหนึ่งอัน งานเล็กน้อยไม่ต้อง
- ทางลัดที่ตั้งใจ: ทำเครื่องหมายด้วย
shortcut: <ข้อจำกัด>, <เมื่อไรควรอัปเกรด>
Important สิ่งที่ห้ามตัดเด็ดขาด: validation ที่ trust boundary, error handling ที่กันข้อมูลหาย, security, accessibility, การปรับค่า (calibration) ที่ฮาร์ดแวร์จริงต้องใช้ และสิ่งที่ผู้ใช้ขอ
🎚️ ระดับความเข้ม
| ระดับ | พฤติกรรม | เหมาะกับ |
|---|---|---|
lite |
ทำตามที่ขอ แล้วบอกทางเลือกที่เล็กกว่าหนึ่งบรรทัดให้ผู้ใช้เลือก | เริ่มใช้ครั้งแรก หรือโค้ดที่ระวังเป็นพิเศษ |
full (ค่าเริ่มต้น) |
ใช้ทุกกฎ | งานทั่วไป |
ultra |
ตั้งคำถามกับคำขอด้วย ก่อนสร้างจะค้านส่วนที่ความต้องการไม่รองรับ | ช่วง scoping ที่ต้องการตัดของเกิน |
off |
ปิด | ต้องการให้ agent ทำเต็มที่ตามที่สั่ง |
สลับด้วย /ponytail lite|full|ultra|off ไม่ต้องมีไฟล์ config ส่วนค่าเริ่มต้นตั้งได้ที่ ~/.config/ponytail/config.json หรือตัวแปร PONYTAIL_DEFAULT_MODE
🧰 คำสั่งและเครื่องมือ
| คำสั่ง | ใช้ทำอะไร |
|---|---|
/ponytail [lite | full | ultra | off] |
ตั้งระดับหรือปิด |
/ponytail band [on | off] |
แสดงหรือซ่อน band (เฉพาะ Claude Code) |
/ponytail band import |
นำ session เก่าเข้า board (เฉพาะ Claude Code) |
/ponytail-review |
รีวิว diff เลือกเป้าหมายได้: uncommitted, staged, branch หรือลิงก์ PR |
/ponytail-audit |
ตรวจทั้ง repo เรียงตามความสำคัญ |
/ponytail-debt |
รวบรวมคอมเมนต์ shortcut: เป็นบัญชีหนี้ทางเทคนิค |
/ponytail-gain |
แสดงตารางผล benchmark |
/ponytail-help |
คู่มือย่อ |
ใน Codex เรียกเป็น $ponytail:ponytail-review ส่วน Cursor ที่ใช้ hooks สลับได้เฉพาะระดับ
รีวิวและ audit
/ponytail-reviewแต่ละข้อพบจะบอก 4 อย่าง: โค้ดทำอะไร อะไรจะพัง วิธีแก้ และผลถ้าไม่แก้ ครอบคลุมบั๊ก security โหลด test ที่ขาด ความเร็ว และส่วนที่ตัดได้/ponytail-auditไล่จุดเข้า (entry point) การไหลของข้อมูล และโหลดที่คาด แล้วจัดลำดับสิ่งที่ควรแก้
band และ board
- band: แถบเหนือช่องพิมพ์ใน Claude Code (2.1.290 ขึ้นไป, terminal หรือ desktop app) แสดงต้นทุน token เวลาของ agent เปอร์เซ็นต์การใช้โค้ดซ้ำ และสถานะ test ไม่แสดงใน VS Code chat panel, cloud session หรือ
claude -p - board: แดชบอร์ดในเครื่อง เก็บที่
~/.config/ponytail/band/
🛠️ ติดตั้ง
| Agent | ขั้นตอน |
|---|---|
| Claude Code (ส่งทีละบรรทัด) ขั้น 1 | /plugin marketplace add DietrichGebert/ponytail |
| Claude Code ขั้น 2 | /plugin install ponytail@ponytail |
| Codex ขั้น 1 | codex plugin marketplace add DietrichGebert/ponytail |
| Codex ขั้น 2 | codex plugin add ponytail@ponytail |
| Codex ขั้น 3 | เปิด /hooks เชื่อถือ hook 2 ตัว และเริ่ม thread ใหม่ |
| Agent อื่น (ทางที่ 1) | คัดลอก AGENTS.md เข้าโปรเจกต์ |
| Agent อื่น (ทางที่ 2) | ให้ agent ติดตั้ง skills/ponytail/SKILL.md เป็น skill |
| Agent อื่น (รายละเอียด) | แต่ละตัวอยู่ใน INSTALL.md |
README ระบุว่ารองรับ Claude Code, Codex, Devin CLI, OpenCode, Gemini, Antigravity CLI, pi, Hermes Agent, Qoder, Grok Build และแบบคำสั่งอย่างเดียวสำหรับ Cursor, Windsurf, Cline, Copilot, Kiro
Warning ติดตั้งจาก
DietrichGebert/ponytailบน GitHub หรือ@dietrichgebert/ponytailบน npm เท่านั้น README ระบุว่าโปรเจกต์ไม่แจกไฟล์.exeหรือ.dllก่อนรัน hook ที่ติดตั้งควรอ่านก่อนว่าทำอะไร
🧭 โครงสร้าง repo
| ที่อยู่ | บทบาท |
|---|---|
skills/ponytail/SKILL.md |
prompt หลัก |
AGENTS.md |
เวอร์ชันย่อสำหรับ agent ที่ใช้ไฟล์กฎ |
.claude-plugin, .codex-plugin, .cursor/rules, .windsurf/rules ฯลฯ |
adapter ที่โหลด prompt เดียวกันเข้า agent ต่างตัว |
benchmarks/ |
ชุดวัดผล ผลลัพธ์อยู่ใน benchmarks/results/ |
hooks/, commands/, scripts/, tests/ |
hook คำสั่ง สคริปต์ และ test |
i18n/ |
README ภาษาสเปน เกาหลี จีนตัวย่อ ญี่ปุ่น |
🚀 ลองใช้
ตัวอย่างประกอบ (ตัวเลขเป็นของเราเอง ไม่ได้มาจาก repo)
งาน: เพิ่มช่องเลือกวันที่ในฟอร์ม โปรเจกต์มี component Input อยู่แล้ว
| ขั้น | คำถามบนบันได | ผล |
|---|---|---|
| 1 | ต้องมีไหม | ต้องมี เพราะผู้ใช้ขอ |
| 2 | มีในโค้ดเบสไหม | มี Input ที่รับ type ได้ |
| 3 | จบ | ใช้ <Input type="date" /> ไม่เขียน calendar เอง |
สมมติ baseline เขียนเอง 300 บรรทัด และแบบใช้ซ้ำ 12 บรรทัด การลดคือ (300 − 12) / 300 = 96% ตัวเลขนี้ใช้ฝึกคำนวณเท่านั้น ต้องไม่นำไปอ้างเป็นผลของ Ponytail
สิ่งที่ยังต้องเช็กแม้โค้ดสั้น: ค่าวันที่ถูก validate ตอนรับเข้า และเบราว์เซอร์เป้าหมายรองรับ type date (ตีความ, ยังไม่ทดสอบ)
ใช้เมื่อไร
| กรณี | คำแนะนำ |
|---|---|
| โค้ดเบสมี component หรือ util เดิมเยอะ | ใช้ full |
| agent ชอบสร้างระบบเกินคำขอ | ใช้ full หรือ ultra |
| ต้องการให้ทำตามสั่งทุกตัวอักษร | ใช้ lite หรือ off |
| งานที่ต้องมีโค้ดจำนวนมากโดยธรรมชาติ เช่น ย้ายระบบ | ระวัง ตัวเลขการลดโค้ดไม่ใช่เป้าหมาย |
| โค้ดเฉพาะทางที่ไม่มีของเดิมให้ใช้ซ้ำ | ประโยชน์น่าจะน้อย (ตีความ) |
เงื่อนไขก่อนเริ่ม: ใช้ agent ที่รองรับ มีงานจริงเปรียบเทียบได้ และมีระบบ git เพื่อดู diff
ก้าวแรกที่เล็กที่สุด
- ติดตั้งตามตารางด้านบน
- เริ่มที่
/ponytail liteกับงานเล็กหนึ่งงาน - ดูบรรทัดท้ายคำตอบว่า agent ข้ามอะไร
ทดสอบว่ามันช่วยจริง
- เลือก 5 งานจริงที่ทำซ้ำได้ ตั้งเงื่อนไขผ่านก่อนรัน เช่น "ส่วนที่เพิ่มใน diff ลดอย่างน้อย 25% และ test เดิมผ่านทั้งหมด และงานเสี่ยงมี test"
- รันแต่ละงานด้วย
/ponytail offแล้วบันทึกจำนวนบรรทัดที่เพิ่ม ต้นทุนหรือ token และเวลา (git diff --shortstat) - รันงานเดิมด้วย
/ponytail fullจาก commit เริ่มต้นเดียวกัน - เทียบ ถ้าโค้ดลดแต่ test หรือ validation หาย ถือว่าไม่ผ่าน
- ให้คนอ่านรีวิวทั้งสองแบบโดยไม่บอกว่าแบบไหนคือแบบไหน
⚠️ ข้อจำกัด ความเสี่ยง และความเข้าใจผิด
| ประเด็น | รายละเอียด | ประเภท |
|---|---|---|
| ตัวเลข benchmark มาจากผู้พัฒนาเอง | ยังไม่มีการทำซ้ำอิสระที่อ่านมา | ข้อเท็จจริงเกี่ยวกับหลักฐาน |
| วัดบนโมเดลและชุดงานเฉพาะ | Opus 5.5, 39 งาน, 5 รอบ ผลกับโมเดลหรือภาษาอื่นไม่รู้ | ข้อเท็จจริง |
| "ประหยัด token" ไม่ใช่เป้าหมายหลัก | เป็นผลข้างเคียง ถ้าไล่ตามตัวเลขอาจเสียคุณภาพ | ข้อเท็จจริง |
| โค้ดสั้นไม่เท่ากับถูกต้อง | ยังต้องมี test และ review | ตีความ |
| ใช้ของเดิมซ้ำอาจผูกกับของที่ไม่ดี | agent อาจใช้ component ที่มีปัญหาซ้ำ | ตีความ |
| ใช้ standard library/ฟีเจอร์แพลตฟอร์ม | ต้องเช็กเวอร์ชันและเบราว์เซอร์ที่รองรับ | ตีความ |
shortcut: สะสมเป็นหนี้ |
ต้องรัน /ponytail-debt เป็นรอบเพื่อไม่ให้ลืม |
ตีความ |
| band ใช้ได้ไม่ครบทุกที่ | ไม่แสดงใน VS Code chat panel, cloud session, claude -p |
ข้อเท็จจริง |
| prompt เป็นข้อความ ไม่ใช่การบังคับ | agent อาจไม่ทำตามเสมอ ต้องดู diff เอง | ตีความ |
| เนื้อหา repo ที่ใช้ในหน้านี้ | อ่านผ่านเครื่องมือดึงหน้าเว็บ ไม่ใช่ gh เป็นเนื้อหาย่อ ไม่ใช่ข้อความเต็ม |
ข้อจำกัดของการอ่าน |
ความเข้าใจผิดที่พบบ่อย
- "ต้องให้ agent เขียนน้อยที่สุดเสมอ" ไม่ใช่ ต้องให้เขียนเท่าที่จำเป็น
- "ใช้แล้วไม่ต้อง review" ไม่ใช่ ยังต้องดู diff
- "ตัดโค้ดป้องกันได้ถ้ามันยาว" ไม่ได้ อยู่ในรายการห้ามตัด
🤝 แนวทางสำหรับผู้ร่วมพัฒนา
อ่านจาก repo (ไฟล์ contributing, 2026-10-22):
| ประเภทการเปลี่ยน | ข้อกำหนด |
|---|---|
| skill ใหม่ | ผู้ดูแลเพิ่มเอง ให้เปิด issue เสนอไอเดียแทน PR |
แก้ skills/, AGENTS.md, สำเนากฎ, .openclaw/skills/ หรือคำสั่ง agent |
ต้องมี benchmark 3 กลุ่ม: ไม่ใช้, ponytail บน main, ponytail พร้อมการแก้ |
| ขนาด benchmark | อย่างน้อย 6 รันต่อกลุ่ม ระบุโมเดล มีงานที่ควรดีขึ้นและงานเดิมที่ไม่แย่ลง |
| แก้บั๊ก hook ตัวติดตั้ง adapter หรือเอกสาร | ไม่ต้องมี benchmark |
คำสั่งที่เกี่ยวข้อง: node scripts/check-rule-copies.js, node scripts/build-openclaw-skills.js, npm test, check-versions.js รัน benchmark ผ่าน benchmarks/agentic/run.py และตั้ง PONYTAIL_PLUGIN_DIR ให้ชี้ไปที่ main หรือ branch PR ควรมีการเปลี่ยนเรื่องเดียวและลิงก์ issue ที่แก้
✅ เช็กลิสต์
| ข้อ | ตรวจ | สถานะ |
|---|---|---|
| 1 | ติดตั้งจากแหล่งทางการ | ⚪ |
| 2 | เลือกระดับที่เหมาะกับงาน | ⚪ |
| 3 | อ่านบรรทัดท้ายคำตอบของ agent ว่าข้ามอะไร | ⚪ |
| 4 | validation, error handling, security, accessibility ยังอยู่ใน diff | ⚪ |
| 5 | logic เสี่ยงมี test อย่างน้อยหนึ่งอัน | ⚪ |
| 6 | คอมเมนต์ shortcut: ถูกรวบรวมและมีกำหนดทบทวน |
⚪ |
| 7 | วัดผลเทียบ baseline ก่อนสรุปว่าได้ผล | ⚪ |
🧪 ทดสอบความเข้าใจ
| คำถาม | คำตอบ | คำตอบผิดที่พบบ่อย |
|---|---|---|
| agent เขียนโค้ดสั้นลง 60% แต่ลบ validation ของ input ออก ถือว่าสำเร็จไหม | ไม่ validation ที่ trust boundary อยู่ในรายการห้ามตัด จึงไม่นับว่าสำเร็จ | สำเร็จ เพราะตัวชี้วัดคือโค้ดน้อยลง |
| ทำไมขั้น "มีในโค้ดเบสแล้วไหม" อยู่ก่อน "standard library" | ต้องตามรูปแบบที่โปรเจกต์ใช้อยู่ ลดความไม่สอดคล้อง | เพราะโค้ดเบสเร็วกว่า |
| ผลลด 45% token บอกอะไรได้และบอกอะไรไม่ได้ | token ลดในชุดทดสอบของโปรเจกต์ แต่ไม่รับประกันกับงานของเรา เป็นค่ารายงานเอง | ใช้แล้วจะลด 45% ในทุกงาน |
ใช้ ultra กับ spec ที่ลูกค้าระบุละเอียดแล้ว ควรระวังอะไร |
agent อาจค้านข้อกำหนดที่ลูกค้าต้องการจริง สิ่งที่ผู้ใช้ขออยู่ในรายการห้ามตัด | ultra ดีที่สุดเสมอเพราะเข้มสุด |
shortcut: ช่วยอะไร และถ้าไม่ใช้ /ponytail-debt จะเกิดอะไร |
ทำให้ทางลัดที่ตั้งใจไว้ตามตรวจย้อนได้ ถ้าไม่รวบรวมจะกลายเป็นหนี้ที่ลืม | เป็นแค่คอมเมนต์ไม่มีผล |
| งานของคุณเป็นการเขียนระบบใหม่ที่ไม่มีของเดิมให้ใช้ซ้ำ จะคาดผลอย่างไร | ประโยชน์จากบันไดน่าจะน้อย เพราะขั้น 2 ถึง 4 ไม่มีของให้ใช้ (ตีความ) ต้องวัดเอง | ได้ผลลด 53% เท่าเดิม |
Sources
| รายการ | รายละเอียด |
|---|---|
| Repo | DietrichGebert/ponytail https://github.com/DietrichGebert/ponytail |
| ไฟล์ที่อ่าน | หน้า README, skills/ponytail/SKILL.md (ฉบับย่อ), ไฟล์ contributing |
| Commit | ไม่ทราบ: เครื่องมือที่ใช้อ่านไม่แสดง SHA |
| วันที่อ่าน | 2026-10-22 |
| วิธีอ่าน | ดึงผ่านหน้าเว็บ ไม่ได้ใช้ gh เพราะไม่มี shell |
| เอกสารเสริม | ponytail.dev ระบุโดย README แต่ไม่ได้อ่าน และ INSTALL.md ไม่ได้อ่าน |
ตัวย่อที่ใช้ในหน้านี้
| ตัวย่อ | ชื่อเต็ม | คืออะไร | อ่านค่าอย่างไร |
|---|---|---|---|
| AI | Artificial Intelligence | ปัญญาประดิษฐ์ | AI agent = โปรแกรม AI ที่ลงมือแก้โค้ดได้ |
| PR | Pull Request | คำขอรวมโค้ดเข้า repo | ลิงก์ PR ส่งให้ /ponytail-review ตรวจได้ |
| UI | User Interface | ส่วนหน้าจอที่ผู้ใช้เห็น | band คือ UI เหนือช่องพิมพ์ |
| MIT | MIT License | สัญญาอนุญาตซอฟต์แวร์แบบเปิด | ใช้ แก้ และแจกต่อได้ตามเงื่อนไข |
| npm | Node Package Manager | ระบบแจกจ่ายแพ็กเกจ JavaScript | @dietrichgebert/ponytail คือชื่อแพ็กเกจ |
-p |
print flag ของ claude |
โหมดไม่โต้ตอบของ CLI | claude -p ไม่แสดง band |
| CLI | Command-Line Interface | โปรแกรมที่ใช้ผ่านบรรทัดคำสั่ง | Devin CLI |
| VS Code | Visual Studio Code | โปรแกรมแก้โค้ดของ Microsoft | chat panel ของมันไม่แสดง band |
| FastAPI, React | ชื่อ framework | FastAPI ฝั่งเซิร์ฟเวอร์ Python, React ฝั่งหน้าเว็บ | repo ตัวอย่างของ benchmark ใช้สอง framework นี้ |
| Opus 5.5 | รุ่นโมเดล Claude | โมเดลที่ใช้ในการทดสอบ | claude-opus-5-5 |
| % | เปอร์เซ็นต์ | ร้อยละ | -53% = ลดลงมากกว่าครึ่ง |
| k | พัน (kilo) | หน่วยนับพัน | 172k = ประมาณ 172,000 |
| YAGNI | You Aren't Gonna Need It | หลักการไม่เขียนสิ่งที่ยังไม่ต้องใช้ | เป็นหนึ่งใน topic ของ repo |
| LLM | Large Language Model | โมเดลภาษาขนาดใหญ่ | เป็นหนึ่งใน topic ของ repo |
แถว AI, PR, UI, MIT, npm, CLI, VS Code, FastAPI, React, YAGNI, LLM, k และ % มาจากความรู้ทั่วไป repo ไม่ได้นิยามไว้ในที่ที่อ่าน
Summary
- Ponytail คือ prompt ที่ให้ agent ไล่ถามก่อนเขียน แล้วใช้ของเดิมให้มากที่สุด
- โค้ดสั้นลงได้ แต่ validation, error handling, security และ accessibility ห้ามตัด
- ตัวเลขที่รายงาน (โค้ด -53%, เวลา -41%, token -45%, ต้นทุน -26%) เป็นค่าที่ผู้พัฒนารายงานเอง ควรวัดซ้ำกับงานของคุณ
- เริ่มที่
liteกับงานเล็ก อ่านบรรทัดท้ายคำตอบ และวัดเทียบ baseline - หน้านี้อ่านจากฉบับย่อของ repo และไม่ทราบ commit ใช้ตรวจต้นทางอีกครั้งก่อนนำไปใช้ในงานสำคัญ
