🎯 แก่นของเรื่อง
ใจความ: เมื่อติดตั้ง Skill จำนวนมาก ปัญหาไม่ได้อยู่ที่ Skill ไม่พอ แต่อยู่ที่ Agent เลือกผิดหรือเรียกเกินจำเป็น VibeSkills จึงเติมชั้นควบคุมไว้ก่อนลงมือ คือยืนยันความต้องการ แบ่งงาน จับคู่ Skill เท่าที่จำเป็นกับแต่ละส่วน แล้วตรวจผลเทียบแผนตอนท้าย (Source 1, Source 2)
ทำไมถึงได้ผล (กลไก):
- อ่านเฉพาะ metadata ย่อของทุก Skill ก่อน (ชื่อ คำอธิบาย ขอบเขต) แล้วคัดรายชื่อสั้นต่อส่วนของงาน อ่าน
SKILL.mdฉบับเต็มเฉพาะตัวที่ผ่านการคัด จึงใช้ context น้อยลง (Source 1, อ่านจาก repo) - ผูกแต่ละ Skill กับหน้าที่ ผลลัพธ์ที่คาดหวัง และเงื่อนไขตรวจสอบ จึงไม่มี Skill ที่ถูกเรียกโดยไม่มีเหตุผล (Source 1, อ่านจาก repo)
- บันทึกสถานะเสร็จ ล้มเหลว ติดขัด ลงไฟล์ จึงเริ่มต่อในรอบหน้าได้และปิดงานทั้งที่ยังไม่ครบไม่ได้ (Source 1, อ่านจาก repo)
ข้อสังเกตที่ repo เขียนไว้เอง: ผลที่ดีขึ้นมาจากการวางแผนและเลือก Skill ที่เกี่ยวข้องไม่กี่ตัว ไม่ใช่จากการเรียก Skill ให้มากขึ้น (Source 1)
20% ที่สำคัญที่สุดในทางปฏิบัติ:
| ต้องเข้าใจก่อน | รอได้ |
|---|---|
| 5 ขั้นตอนของ workflow (ยืนยัน, เลือกระดับ, จัดสรร Skill, ลงมือ, ตรวจรับ) | รายละเอียดโฟลเดอร์ adapters, vgo_cli, third_party |
เงื่อนไขที่ Skill จะถูกเลือกได้ (SKILL.md อ่านได้, ชื่อไม่ซ้ำ, ขอบเขตชัด) |
ตัวอย่างงาน ML ที่เป็นกรณีเดียว |
| วิธีอ่านผล SkillsBench ให้ถูก (pp ไม่ใช่ %, สภาพทดสอบที่ดัดแปลง) | การสลับภาษาและเอกสารจีน |
📊 ช่วยให้ดีขึ้นอย่างไร
ตารางนี้แยกชัดว่าอะไรวัดแล้ว อะไรเป็นการตีความของเรา ตัวเลขทั้งหมดมาจากการทดสอบที่โครงการรายงานเอง ยังไม่มีการทดสอบอิสระในข้อมูลที่อ่านได้
| สถานการณ์ | ไม่ใช้ | ใช้ VibeSkills | วัดอย่างไร | หลักฐาน |
|---|---|---|---|---|
| คะแนนงานเฉลี่ย (82 งานคู่) | 50.3% | 71.4% (+21.12 pp) | mean verifier reward | วัดแล้ว Source 1, 3 (อ่านจาก repo, จากภาพ) |
| งานที่ได้คะแนนเต็ม | 47.6% (39 งาน) | 69.5% (57 งาน) | full-score rate | วัดแล้ว Source 1, 3 |
| Token รวม (81 งานคู่) | 491.122M | 345.756M (-29.6%) | total tokens | วัดแล้ว Source 1, 2, 3 |
| จำนวนการเรียกเครื่องมือ | 9,954 | 6,664 (-33.1%) | tool calls | วัดแล้ว Source 1, 2 |
| Agent เลือก Skill ตรงงานขึ้น | ไม่ทราบ | ไม่มีตัวเลขโดยตรง | ยังไม่มีตัววัดการเลือกผิด | ตีความ จากคะแนนและ token ที่ดีขึ้น (Source 2 เล่าเป็นข้อสรุป) |
| งานยาวติดตามและกลับมาทำต่อได้ | ขึ้นกับ Agent | มีไฟล์บันทึกสถานะ | สังเกตว่ากลับมาทำต่อได้จริงไหม | ยังไม่ทดสอบ (Source 1 ระบุกลไก ไม่มีตัวเลข) |
| ภาระ token ของตัว VibeSkills เอง | 0 | ไม่เป็นศูนย์ | ดู token ต่อรอบวางแผน | วัดแล้วบางส่วน repo ระบุว่ามีภาระ แต่ไม่แยกตัวเลข |
เมื่อแยกผลรายงาน: ชุดที่ใช้ VibeSkills ได้คะแนนสูงกว่า 23 งาน เท่ากัน 55 งาน ต่ำกว่า 4 งาน (Source 1, 3) แปลว่าการดีขึ้นกระจุกอยู่ในงานส่วนน้อย และมีงาน 4 งานที่แย่ลงจริง
🔎 ภาพรวมระบบ
VibeSkills คือ Skill ทั่วไปที่ "route" ไปยัง Skill ในเครื่องโดยอัตโนมัติ และจัดลำดับ workflow ของ harness ให้ (Source 3, Source 1) ใช้เรียกด้วย $vibe หรือ /vibe ในแอป AI ที่รองรับ Skill ในเครื่อง (Source 1, อ่านจาก repo)
| ข้อเท็จจริง | ค่า | ที่มา |
|---|---|---|
| สัญญาอนุญาต | Apache License 2.0 | Source 1, 2 |
| เวอร์ชันที่ทดสอบ | v4.1.0 | Source 1, 2, 3 |
| ดาว / fork บน GitHub | ประมาณ 3.7k / 341 (ตอนอ่าน) | Source 1 |
| Commit ที่ใช้เผยแพร่ผลทดสอบ | ef907ebf8370 |
Source 1 |
| รายชื่อแอปโฮสต์ | README ไม่ระบุชัด (topics มี claude-code, codex ซึ่งเป็นเพียงใบ้) |
Source 1, ตีความ |
5 ขั้นตอนของ workflow
flowchart LR A[1 ยืนยันความต้องการ] --> B[2 เลือกระดับ L หรือ XL] B --> C[3 คัด Skill ต่อส่วนงาน] C --> D[4 ลงมือและบันทึกสถานะ] D --> E[5 ตรวจรับเทียบแผน]
| ขั้น | ทำอะไร | ทำไมสำคัญ |
|---|---|---|
| 1 ยืนยันความต้องการ | ยืนยันเป้าหมาย ข้อจำกัด วัสดุ และสิ่งที่จะส่งมอบ งานหยุดจนกว่าจะอนุมัติ | กันการลงมือผิดทางตั้งแต่ต้น |
| 2 เลือกระดับ | L งานหลายขั้นทำตามลำดับ; XL งานใหญ่ รันพร้อมกันได้สูงสุด 2 ส่วนที่ไม่ชนกัน ผู้ใช้ยืนยันระดับ |
ไม่ใช้โครงหนักกับงานเล็ก |
| 3 จัดสรร Skill | สแกนโฟลเดอร์ อ่าน metadata ย่อ คัดรายชื่อสั้น อ่าน SKILL.md เต็มเฉพาะที่เหลือ ผูกกับหน้าที่และการตรวจ |
ลด context และกันการเรียกพร่ำเพรื่อ |
| 4 ลงมือและบันทึก | Agent ปัจจุบันทำงาน งานโค้ดใช้ TDD ได้เมื่อเหมาะ บันทึกสถานะเสร็จ/ล้ม/ติดขัด | กลับมาทำต่อได้ |
| 5 ตรวจรับ | เทียบผลจริงกับทุกรายการในแผน งานจำเป็นที่ไม่ครบ ล้มเหลว หรือติดขัดไม่ผ่านรับมอบ | ปิดงานโดยไม่ครบไม่ได้ |
ข้อมูลทั้งหมดในหัวข้อนี้อ่านจาก repo เมื่อ 2026-10-21 (Source 1) และ Source 2 สรุปตรงกันว่า "วางแผน จัดลำดับ ติดตามความคืบหน้า บันทึกงาน และตรวจก่อนส่งมอบ"
ไฟล์บันทึกที่ได้
| ไฟล์ | เก็บอะไร |
|---|---|
install-receipt.json |
ไฟล์ที่ตัวติดตั้งเขียน |
session_root |
อินพุตงาน ความคืบหน้า การตัดสินใจ |
module-work-plan.json |
แผนที่อนุมัติแล้ว (มี agent_skill_organization) |
module-execution.json |
ผลที่เกิดจริง (มี module_assignments) |
delivery-acceptance-report.json หรือ .md |
ผลตรวจรับสุดท้าย |
Source 1 ระบุเองว่า ติดตั้งสำเร็จไม่ได้แปลว่างานเคยรัน และมีบันทึกงานไม่ได้แปลว่าการตรวจผ่าน
🧪 อ่านผลทดสอบ SkillsBench ให้ถูก
SkillsBench คือ benchmark วัดว่า AI Agent ใช้ Skill ทำงานเชิงวิชาชีพหลายสาขาได้ดีเพียงใด (Source 3) โครงการดัดแปลงให้ทุกงานรันในสภาพแวดล้อมที่มี Skill เฉพาะทาง 195 ตัวพร้อมกัน ต่างจากต้นแบบที่ให้เฉพาะ Skill ของงานนั้น เงื่อนไขอื่นคงเดิม เพื่อจำลองคลังใหญ่แบบใช้งานจริง (Source 3, Source 1) ใช้โมเดล DeepSeekV4Flash-VE กับ OpenHands เป็นชุดฐาน (Source 3)
ตารางผลลัพธ์รายงาน (outcome matrix จากภาพ)
จำนวนงานแยกตามกลุ่มคะแนน (82 งานคู่) อ่านจากภาพ (Source 3):
| คะแนนชุดฐาน \ คะแนนชุด Lean Vibe | ศูนย์ | บางส่วน | เต็ม |
|---|---|---|---|
| ศูนย์ | 19 | 1 | 20 |
| บางส่วน | 0 | 1 | 2 |
| เต็ม | 4 | 0 | 35 |
ตรวจสอบผลรวมได้ด้วยตัวเอง (ตีความ จากการคำนวณของเรา):
- ผลรวมทั้งตาราง 19+1+20+0+1+2+4+0+35 = 82 ตรงกับจำนวนงานคู่
- ชุดฐานได้เต็ม 4+0+35 = 39 งาน = 47.6% ของ 82 ตรงกับที่รายงาน
- ชุด Lean Vibe ได้เต็ม 20+2+35 = 57 งาน = 69.5% ตรงกับที่รายงาน
- งานที่ชุดฐานเต็มแต่ Lean Vibe ศูนย์ คือ 4 งาน ตรงกับ "Native higher: 4"
- การเพิ่มส่วนใหญ่มาจาก 20 งานที่เปลี่ยนจากศูนย์เป็นเต็ม
ความขัดแย้งและความกำกวมระหว่างแหล่ง
| ประเด็น | ฝ่ายที่หนึ่ง | ฝ่ายที่สอง | ข้อสรุป |
|---|---|---|---|
| หน่วยของ +21.12 | Source 3 (หัวตาราง) และ Source 1 เขียน "pp" = percentage point | Source 2 และประโยคบรรยายใน Source 3 เขียน "เพิ่มขึ้น 21.12%" | หลักฐานเข้าข้าง pp: 71.4 - 50.3 = 21.1 จุดเปอร์เซ็นต์ เชิงสัมพัทธ์ราว +42% ไม่ใช่ 21% |
| ชื่อชุดทดสอบ | Source 3 ใช้ "Lean Vibe" ในกราฟ | Source 1 ส่วนอื่นใช้ "VibeSkills" | ตีความ: น่าจะหมายถึงรูปแบบตัวเดียวกัน แต่ไม่มีแหล่งยืนยัน ยังเปิดอยู่ |
| ความเป็นกลางของผล | Source 2 เล่าเป็นผลสรุป | Source 1 ระบุว่ารายงานเอง และใช้ setup ที่ดัดแปลง | ยังเปิดอยู่ ยังไม่มีการทำซ้ำอิสระที่อ่านได้ |
🛠️ ใช้งานและตั้งค่า
หัวข้อนี้มาจาก repo เท่านั้น (Source 1, อ่านเมื่อ 2026-10-21) ไม่ได้รันเอง (ยังไม่ทดสอบ)
| เรื่อง | รายละเอียด |
|---|---|
| ไฟล์ติดตั้ง | มี install.*, update.*, uninstall.*, check.* (.sh และ .ps1) ที่ราก repo |
| คู่มือ | README ไม่ให้คำสั่งติดตั้ง ชี้ไป docs/install/README.en.md, docs/quick-start.en.md |
| เพิ่มโฟลเดอร์ Skill | ระบุใน ~/.vibeskills/skill-roots.json หรือ .vibeskills/skill-roots.json ใน workspace |
| เงื่อนไขของ Skill | ต้องมี SKILL.md ที่อ่านได้ ชื่อไม่ชนกับ Skill อื่น และขอบเขตเข้ากับงาน |
| ผลการทดสอบ | config/benchmark-results.json และ repo vibeskills-benchmark แยกต่างหาก |
Warning อย่ารันสคริปต์ติดตั้งก่อนอ่านเนื้อหา เนื้อหาใน repo เป็นโค้ดของบุคคลที่สาม ควรอ่านสคริปต์และทดลองในเครื่องหรือ workspace แยกก่อน
🚀 ลองใช้
ตัวอย่างประกอบ: คำนวณผลซ้ำ
ตัวเลขดิบมาจาก Source 1 การหารเป็นของเรา:
| รายการ | คำนวณ | ผล |
|---|---|---|
| ส่วนต่าง token | 491.122M - 345.756M | 145.366M |
| อัตราลด token | 145.366 / 491.122 | 29.6% |
| Token ต่องาน (ฐาน, 81 งาน) | 491.122M / 81 | ราว 6.06M |
| Token ต่องาน (VibeSkills) | 345.756M / 81 | ราว 4.27M |
| อัตราลด tool call | (9,954 - 6,664) / 9,954 | 33.05% |
| คะแนนเพิ่มเชิงสัมพัทธ์ | 71.4 / 50.3 - 1 | ราว +42% |
เมื่อไรควรใช้
| สถานการณ์ | ควรใช้ไหม | เหตุผล |
|---|---|---|
| ติดตั้ง Skill เป็นร้อยตัว Agent เลือกผิดบ่อย | ควร | ตรงกับสภาพทดสอบที่มีผล |
| งานหลายขั้นที่ต้องกลับมาทำต่อข้ามเซสชัน | ควร | มีไฟล์บันทึกสถานะและแผน |
| ต้องการหลักฐานว่าส่งมอบครบตามแผน | ควร | มีขั้นตรวจรับเทียบแผน |
| มี Skill เพียง 3-5 ตัว งานสั้น | ไม่จำเป็น | ภาระ token ของชั้นควบคุมอาจไม่คุ้ม (ตีความ) |
| ต้องการให้ Agent ลองใช้ Skill ทุกตัว | ไม่ใช่ | ระบบไม่เรียกทุก Skill อัตโนมัติ |
Skill ไม่มี SKILL.md อ่านได้ หรือชื่อซ้ำ |
ต้องแก้ก่อน | จะไม่ถูกเลือก |
ข้อกำหนดเบื้องต้น: แอป AI ที่รองรับ Skill ในเครื่อง และ Skill ที่มี SKILL.md เขียนขอบเขตชัด
ก้าวแรกที่เล็กที่สุด
- เลือกงานจริง 1 งานที่เคยทำพลาดเพราะเลือก Skill ผิด
- ติดตั้งในโฟลเดอร์ทดลอง อ่านคู่มือ
docs/quick-start.en.mdก่อน - เรียก
/vibeหรือ$vibeตรวจว่าผ่านขั้นยืนยันความต้องการและเลือกระดับ - เปิดไฟล์
module-work-plan.jsonดูว่า Skill ที่ถูกเลือกสมเหตุสมผลไหม
การทดสอบก่อน-หลัง (ตัวอย่างประกอบ ออกแบบเอง)
| ข้อ | ค่าที่ควรกำหนดก่อนรัน |
|---|---|
| ชุดงาน | 10-20 งานที่ซ้ำได้ ความยากต่างกัน |
| ตัวชี้วัด | อัตราผ่านเกณฑ์ที่ตั้งไว้ล่วงหน้า, token รวม, จำนวน tool call |
| ฐาน | รันชุดเดียวกันโดยไม่ใช้ VibeSkills บันทึกค่า |
| เกณฑ์ผ่าน (ตัวอย่าง) | อัตราผ่านไม่ต่ำลง และ token หรือ tool call ลดอย่างน้อย 10% |
| ข้อควรระวัง | รันซ้ำอย่างน้อย 3 รอบ เพราะผลของ Agent ผันผวน และนับงานที่แย่ลงแยกไว้ |
⚠️ Risks และข้อจำกัด
Warning ตัวเลขทั้งหมดมาจากการทดสอบที่โครงการรายงานเองและดัดแปลงสภาพ benchmark (Skill 195 ตัวต่องาน) ยังไม่ควรถือเป็นผลทั่วไป โดยเฉพาะกับโมเดลหรือ harness อื่น
| ประเด็น | รายละเอียด | ที่มา |
|---|---|---|
| ผลรายงานเอง | ใช้โมเดลเดียว harness เดียว ตัวอย่าง 82 งาน (81 งานสำหรับทรัพยากร) | Source 1, 3 |
| ภาระ token ไม่เป็นศูนย์ | Skill candidate มาก SKILL.md ยาว หรือแบ่งงานละเอียดมาก ทำให้ context เพิ่ม |
Source 1 |
| งานที่แย่ลง | 4 งานจาก 82 ได้คะแนนต่ำกว่าชุดฐาน | Source 1, 3 |
| กรณีศึกษาเดียว | งาน ML: 7 Skill, 5 กลุ่ม, 10 หน่วยงาน, ตรวจผ่าน 17/17 ห้ามอนุมานทั่วไป | Source 1 |
| ค้นพบ ≠ ใช้งาน | เฉพาะ Skill ที่อยู่ในแผนเท่านั้นที่ถูกเรียก | Source 1 |
| ข้อมูลที่ขาด | ไม่มีรายการแอปโฮสต์ที่ยืนยัน ไม่มี commit ล่าสุด ไม่มีตัวเลขภาระ token ไม่ได้อ่านผลซ้ำจาก vibeskills-benchmark |
ตีความ |
ความเข้าใจผิดที่พบบ่อย
| ความเข้าใจผิด | ความจริง |
|---|---|
| "คะแนนเพิ่ม 21%" | เพิ่ม 21.12 จุดเปอร์เซ็นต์ (50.3% เป็น 71.4%) |
| "ติดตั้งมากขึ้นยิ่งเก่งขึ้น" | ผลมาจากการเลือกน้อยแต่ตรง ไม่ใช่เรียกมาก |
| "ติดตั้งสำเร็จ แปลว่าใช้งานได้" | repo ระบุว่าไม่เท่ากัน ต้องดูไฟล์แผนและผลตรวจ |
| "ทุกงานดีขึ้น" | 55 งานเท่าเดิม 4 งานแย่ลง |
✅ ทดสอบความเข้าใจ
| คำถาม | คำตอบ | คำตอบผิดที่พบบ่อย |
|---|---|---|
| 1. ถ้าคะแนนเฉลี่ยจาก 50.3% เป็น 71.4% ควรเรียกการเพิ่มว่าอะไร | +21.1 จุดเปอร์เซ็นต์ หรือราว +42% เชิงสัมพัทธ์ | "เพิ่ม 21%" |
| 2. ทำไมการอ่านเฉพาะ metadata ก่อนจึงลด token | ไม่ต้องโหลด SKILL.md เต็มของ Skill ที่ไม่ผ่านการคัด จาก 195 ตัวเหลือที่เกี่ยวข้อง |
"เพราะ Skill ถูกลบออก" |
| 3. ในตาราง outcome ถ้ารวมคอลัมน์ "เต็ม" ของ Lean Vibe ได้เท่าไร และบอกอะไร | 20+2+35 = 57 งาน (69.5%) ส่วนเพิ่มเกือบทั้งหมดมาจากงานที่เปลี่ยนจากศูนย์เป็นเต็ม | อ่านผิดเป็น 35 เพราะดูแต่ช่องกลาง |
| 4. (กับดัก) ผลจาก 195 Skill ใช้อ้างกับคลัง 5 Skill ได้ไหม | ไม่ได้ เงื่อนไขทดสอบคือคลังใหญ่ คลังเล็กไม่มีข้อมูลและภาระ token อาจไม่คุ้ม | "ได้ เพราะโครงการเป็นเครื่องมือทั่วไป" |
| 5. Skill ที่ค้นพบแล้ว ถูกใช้ทำงานแน่ไหม | ไม่แน่ เฉพาะตัวที่อยู่ในแผนที่อนุมัติ | "ค้นพบแล้วก็ถูกเรียก" |
| 6. จะเชื่อผล 21.12 pp ได้แค่ไหน | เป็นหลักฐานเบื้องต้น รายงานเอง โมเดลเดียว ควรทดสอบกับงานของตนเอง | "เป็นข้อพิสูจน์แน่นอน" |
📌 Decision / next steps
Recommendation ถ้าคลัง Skills ใหญ่และ Agent เลือกผิดหรือเปลือง token ให้ทดลองในโฟลเดอร์แยกด้วยชุดงาน 10-20 งาน กำหนดเกณฑ์ผ่านก่อนรัน แล้วตัดสินจากตัวเลขของตัวเอง ไม่ใช่จากตัวเลขของโครงการ
📚 Sources
| # | แหล่ง | หมายเหตุ |
|---|---|---|
| 1 | GitHub repo: https://github.com/foryourhealth111-pixel/Vibe-Skills | อ่านจากหน้า repo และ README 2026-10-21 ผ่านการดึงหน้าเว็บ ไม่ได้ clone ไม่ได้อ่านเลข commit ล่าสุด (commit ที่เผยแพร่ผลคือ ef907ebf8370 ตาม README) |
| 2 | ข้อความแนะนำโปรเจกต์ภาษาไทย (ไฟล์ m2/input.txt) |
สรุปปัญหาของคลัง Skills ตัวเลข 3 ค่า และสัญญาอนุญาต |
| 3 | ภาพ README ของ VibeSkills ส่วน "Measured on SkillsBench" (ไฟล์ m3/input.jpg) |
กราฟ A, B, C และตาราง outcome matrix |
เพิ่มเติมจากการอ่าน repo ซึ่งไม่ปรากฏใน Source 2 และ 3: รายละเอียด workflow 5 ขั้น ไฟล์บันทึก เงื่อนไข Skill ข้อจำกัดที่ repo ระบุเอง ตัวเลข token ดิบ และจำนวน tool call ดิบ
🔤 ตัวย่อที่ใช้ในหน้านี้
| ตัวย่อ | ชื่อเต็ม | คืออะไร | อ่านค่าอย่างไร |
|---|---|---|---|
| AI | Artificial Intelligence | ปัญญาประดิษฐ์ | ใช้เรียกโมเดลและ Agent |
| ML | Machine Learning | การเรียนรู้ของเครื่อง | งานตัวอย่างใน repo เป็นงานทดลอง ML |
| TDD | Test-Driven Development | เขียนการทดสอบก่อนเขียนโค้ด | VibeSkills ใช้ได้กับงานโค้ดเมื่อเหมาะ |
| pp | percentage point | หน่วยผลต่างของเปอร์เซ็นต์ | 50.3% ไป 71.4% = +21.1 pp |
| L / XL | ระดับงานของ VibeSkills | L ทำตามลำดับ, XL มีส่วนอิสระรันพร้อมกันได้ 2 ส่วน | ผู้ใช้เป็นผู้ยืนยัน |
| VE | ไม่ระบุชัดในแหล่ง | ส่วนท้ายของชื่อโมเดล DeepSeekV4Flash-VE | ใช้เป็นชื่อโมเดลตามที่เขียน |
| M | ล้าน (million) | หน่วย token | 491.122M = 491,122,000 |
| JSON | JavaScript Object Notation | รูปแบบไฟล์ข้อมูล | ไฟล์ .json ที่ใช้บันทึกแผนและผล |
| SKILL.md | ไฟล์คำอธิบาย Skill | ไฟล์ที่ Skill ต้องมีเพื่อให้ถูกเลือกได้ | อ่านได้และชื่อไม่ซ้ำ |
| Tool call | การเรียกเครื่องมือของ Agent | หนึ่งครั้งที่ Agent เรียกเครื่องมือ | 9,954 เป็น 6,664 |
| Token | หน่วยข้อความที่โมเดลประมวลผล | ใช้วัดต้นทุน | -29.6% |
คำจำกัดความของ AI, ML, TDD, JSON, M, pp และ token มาจากความรู้ทั่วไป ไม่ได้มาจากแหล่งโดยตรง ส่วน VE แหล่งไม่ได้อธิบายชื่อเต็ม
🧾 Summary
| ประเด็น | ข้อสรุป |
|---|---|
| ปัญหา | คลัง Skills ใหญ่ทำให้ Agent เลือกผิดและเปลือง token |
| กลไก | ยืนยันความต้องการ, คัด Skill จาก metadata, ผูกหน้าที่และตรวจ, ตรวจรับเทียบแผน |
| ผลรายงาน | คะแนน +21.12 pp, token -29.6%, tool call -33.1% (รายงานเอง, 195 Skill, 82 งาน) |
| ข้อควรระวัง | งานแย่ลง 4 จาก 82, ภาระ token ไม่เป็นศูนย์, ยังไม่มีการทำซ้ำอิสระที่อ่านได้ |
| ก้าวต่อไป | ทดสอบก่อน-หลังกับงานจริงของตนเองก่อนตัดสินใจ |
