AI Programming Agent ขาดวินัยทางวิศวกรรม? เฟรมเวิร์ก Superpowers ใช้ TDD และซับเอเจนต์ขับเคลื่อนการพัฒนาอย่างมีระเบียบวินัย

คุณเคยเจอสถานการณ์แบบนี้ไหม? ให้ AI เขียนแอป Todo “ง่ายๆ” มันก็ถาโถมโค้ดสามร้อยบรรทัดออกมาโดยไม่พูดพล่าม — ไม่มีเอกสารออกแบบ ไม่มีเทสเคส ตั้งชื่อตัวแปรตามอำเภอใจ ยิ่งไม่ต้องพูดถึงการคิดในระดับสถาปัตยกรรมเลย พอคุณบอกว่า “เพิ่มฟีเจอร์” มันก็รื้อโค้ดเก่าทิ้งแล้วเริ่มใหม่ พอบอกว่า “แก้บั๊ก” มันก็แค่ปะผุที่อาการ แล้วก็สร้างบั๊กใหม่เพิ่มอีกสองตัว

นี่ไม่ใช่เพราะ AI ไม่ฉลาดพอ แต่เป็นปัญหาเรื่องการขาดวินัยทางวิศวกรรม โปรแกรมเมอร์มนุษย์ใช้เวลาหลายปีกว่าจะเรียนรู้ “ออกแบบก่อนเขียนโค้ด” “เขียนเทสก่อนลงมือทำ” “หาเหตุที่แท้จริงก่อนแก้ไข” แต่เอเจนต์ AI โดยค่าเริ่มต้นไม่มีกฎเกณฑ์เหล่านี้

• กรอบทักษะเอเจนต์และ方法论การพัฒนาซอฟต์แวร์ที่ได้ผลจริง
• https://github.com/obra/superpowers
• 3500 คำ อ่าน 17 นาที, พอดแคสต์ 14 นาที

Superpowers ถูกสร้างมาเพื่อแก้ปัญหานี้: มันไม่ใช่เครื่องมือสร้างโค้ดอีกตัวหนึ่ง แต่เป็นกรอบทักษะและ方法论การพัฒนาที่บังคับให้เอเจนต์ AI ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดทางวิศวกรรมซอฟต์แวร์ มันใช้ “ทักษะ” แทน “พรอมต์” ใช้เกตเวย์กระบวนการแทนการทำตามอำเภอใจ ทำให้เอเจนต์ AI พัฒนาจาก “เขียนโค้ดเป็น” ไปสู่ “ทำงานวิศวกรรมเป็น”

สารบัญ

• เริ่มต้นใช้งาน
• หนึ่ง การออกแบบสถาปัตยกรรม
  • 1.1 การวางตำแหน่งโครงการ: ไม่ใช่เครื่องมือ แต่เป็น方法论
  • 1.2 โครงสร้างไดเรกทอรีและองค์ประกอบทางเทคนิค
  • 1.3 กลไกปลั๊กอิน: ทักษะถูกโหลดอย่างไร
• สอง เวิร์กโฟลว์หลัก: สายการผลิตเจ็ดขั้นตอนจากไอเดียสู่การส่งมอบ
  • 2.1 brainstorming: ปฏิเสธ “เริ่มเขียนโค้ดทันที”
  • 2.2 writing-plans: เขียนแผนสำหรับ “วิศวกรมือใหม่ที่กระตือรือร้นแต่ไร้รสนิยม”
  • 2.3 subagent-driven-development: สายการผลิตของเอเจนต์ย่อย
• สาม การดำเนินการ TDD อย่างสุดโต่ง: กฎเหล็กและการต่อต้านการหาเหตุผลเข้าข้างตนเอง
  • 3.1 “กฎเหล็ก” ของการพัฒนาแบบทดสอบนำ
  • 3.2 ตารางต่อต้านการหาเหตุผล: อุดช่องโหว่ “ข้ออ้าง” ของ AI
• สี่ การออกแบบเมตาเลเยอร์ของทักษะ: writing-skills
  • 4.1 ใช้ TDD เขียนเอกสาร
  • 4.2 CSO: การเพิ่มประสิทธิภาพสำหรับการค้นหาของ AI
• ห้า การดีบักอย่างเป็นระบบ: การวิเคราะห์สาเหตุที่แท้จริงสี่ขั้นตอน
• สรุปและข้อคิด

เริ่มต้นใช้งาน

Superpowers รองรับสภาพแวดล้อมการเขียนโปรแกรม AI หลากหลาย เช่น Claude Code, Codex CLI, Gemini CLI, Cursor เป็นต้น ตัวอย่างที่ใช้บ่อยที่สุดคือ Claude Code สามารถติดตั้งได้ด้วยคำสั่งเดียว:

/plugin install superpowers@claude-plugins-official

หลังติดตั้งไม่ต้องตั้งค่าเพิ่มเติมใดๆ เมื่อคุณพูดว่า “Let’s build X” ในบทสนทนา Superpowers จะเรียกใช้ทักษะการระดมสมองโดยอัตโนมัติ เพื่อนำทางเอเจนต์ให้ออกแบบก่อนแล้วค่อยเขียนโค้ด ดูวิธีการติดตั้งเพิ่มเติม (Codex, Gemini CLI, Cursor ฯลฯ) ได้ที่คู่มือการติดตั้งใน README[1]

หนึ่ง การออกแบบสถาปัตยกรรม

1.1 การวางตำแหน่งโครงการ: ไม่ใช่เครื่องมือ แต่เป็น方法论

การวางตำแหน่งของ Superpowers นั้นโดดเด่นมาก — มันเรียกตัวเองว่า “方法论การพัฒนาซอฟต์แวร์ที่สมบูรณ์” (a complete software development methodology) เครื่องมือสร้างโค้ดแบบดั้งเดิมสนใจ “เขียนโค้ดอะไร” แต่ Superpowers สนใจ “เอเจนต์ AI ควรทำงานวิศวกรรมอย่างไร“

ปรัชญาหลักของโครงการสามารถสรุปได้สี่ประโยค:

• การพัฒนาแบบทดสอบนำ (Test-Driven Development) — เขียนเทสก่อนเสมอ
• เป็นระบบดีกว่าทำตามอำเภอใจ (Systematic over ad-hoc) — กระบวนการดีกว่าการเดา
• ลดความซับซ้อน (Complexity reduction) — ความเรียบง่ายคือเป้าหมายหลัก
• หลักฐานดีกว่าการกล่าวอ้าง (Evidence over claims) — ต้องตรวจสอบก่อนประกาศความสำเร็จ

1.2 โครงสร้างไดเรกทอรีและองค์ประกอบทางเทคนิค

superpowers/
├── .claude-plugin/        # เมตาดาต้าปลั๊กอิน Claude Code
├── .codex-plugin/         # การปรับ适配ปลั๊กอิน Codex
├── .cursor-plugin/        # การปรับ适配ปลั๊กอิน Cursor
├── .opencode/             # การปรับ适配ปลั๊กอิน OpenCode
├── skills/                # ★ แกนหลัก: คำจำกัดความทักษะทั้งหมด
│   ├── brainstorming/
│   ├── subagent-driven-development/
│   ├── test-driven-development/
│   ├── writing-plans/
│   ├── systematic-debugging/
│   ├── using-git-worktrees/
│   └── ... (รวม 14 ทักษะ)
├── scripts/               # สคริปต์จัดการเวอร์ชันและซิงค์ปลั๊กอิน
├── tests/                 # การทดสอบทักษะอัตโนมัติ
└── hooks/                 # Git hooks

ที่น่าสนใจคือ 66% ของโค้ดในโครงการเป็น Shell Script — สคริปต์เหล่านี้ใช้สำหรับการซิงค์ปลั๊กอิน การจัดการเวอร์ชัน และการดำเนินการทดสอบเป็นหลัก ไม่ใช่ “ตรรกะหลัก” แกนหลักที่แท้จริงคือไฟล์ Markdown ในไดเรกทอรี skills/

ใช่แล้ว “โค้ด” ของ Superpowers โดยพื้นฐานแล้วคือชุดเอกสารคำสั่งที่มีโครงสร้างซึ่งถูกเขียนขึ้นอย่างพิถีพิถัน เอกสารเหล่านี้จะถูกฉีดเข้าไปในบริบทของเอเจนต์ AI ผ่านระบบปลั๊กอิน เพื่อเปลี่ยนรูปแบบพฤติกรรมของเอเจนต์

1.3 กลไกปลั๊กอิน: ทักษะถูกโหลดอย่างไร

{
"name": "superpowers",
"description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
"version": "5.1.0",
"author": { "name": "Jesse Vincent" },
"license": "MIT"
}

เมื่อเอเจนต์ AI เริ่มเซสชันใหม่ ระบบปลั๊กอินจะโหลด “ทักษะนำทาง” ที่ชื่อ using-superpowers ก่อน ทักษะนี้จะฉีดกฎหลักที่ละเมิดไม่ได้: ก่อนที่จะตอบสนองใดๆ ต้องตรวจสอบก่อนว่ามีทักษะที่สามารถเรียกใช้ได้หรือไม่

สอง เวิร์กโฟลว์หลัก: สายการผลิตเจ็ดขั้นตอนจากไอเดียสู่การส่งมอบ

Superpowers กำหนดสายการผลิตซอฟต์แวร์ที่สมบูรณ์ ซึ่งประกอบด้วยเจ็ดขั้นตอน แต่ละขั้นตอนถูกบังคับใช้โดยทักษะเฉพาะ:

brainstorming → using-git-worktrees → writing-plans → subagent-driven-development → test-driven-development → requesting-code-review → finishing-a-development-branch

โปรดทราบว่านี่ไม่ใช่ “คำแนะนำ” หรือ “แนวทางปฏิบัติที่ดีที่สุด” แต่เป็นกระบวนการที่ถูกบังคับใช้ มาดูรายละเอียดส่วนสำคัญทีละส่วนกัน

2.1 brainstorming: ปฏิเสธ “เริ่มเขียนโค้ดทันที”

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

<HARD-GATE>
ห้ามเรียกใช้ทักษะการดำเนินการใดๆ เขียนโค้ด สร้างโครงสร้างโครงการ
หรือดำเนินการใดๆ จนกว่าคุณจะนำเสนอการออกแบบ
และผู้ใช้ได้อนุมัติแล้ว
</HARD-GATE>

แท็ก <HARD-GATE> นี้เป็นรูปแบบการออกแบบหลักของ Superpowers: ใช้ “เกตเวย์” ที่ชัดเจนเพื่อ阻止เอเจนต์ข้ามขั้นตอนกระบวนการใดๆ

ทักษะ brainstorming กำหนดให้เอเจนต์ทำรายการตรวจสอบ 9 ขั้นตอน: สำรวจบริบทโครงการ → ถามคำถามเพื่อความกระจ่าง (ทีละข้อ) → เสนอ 2-3 ทางเลือก → นำเสนอการออกแบบเป็นส่วนๆ → เขียนเอกสารออกแบบ → ตรวจสอบข้อกำหนดด้วยตนเอง → ผู้ใช้ตรวจสอบ → ส่งต่อให้การเขียนแผน

สิ่งที่น่าสังเกตเป็นพิเศษคือคำประกาศเกี่ยวกับ “反模式”:

ทุกโครงการต้องผ่านกระบวนการนี้ รายการ Todo, ยูทิลิตี้ฟังก์ชันเดียว, การเปลี่ยนแปลงการกำหนดค่า — ทั้งหมดนั้น โครงการ “ง่ายๆ” คือที่ที่สมมติฐานที่ไม่ได้รับการตรวจสอบทำให้เกิดงานที่สูญเปล่ามากที่สุด

แม้แต่การแก้ไขการกำหนดค่า “ง่ายๆ” ก็ต้องผ่านกระบวนการออกแบบที่สมบูรณ์ แนวทางที่ดูเหมือน “หวาดระแวง” นี้ เป็นการแก้ไขจุดอ่อนร้ายแรงของเอเจนต์ AI ที่ “คิดว่าเข้าใจความต้องการแล้วก็เริ่มเขียนโค้ด” ได้อย่างแม่นยำ

2.2 writing-plans: เขียนแผนสำหรับ “วิศวกรมือใหม่ที่กระตือรือร้นแต่ไร้รสนิยม”

คำอธิบายของทักษะการเขียนแผนนั้นชัดเจนมาก:

เขียนแผนการดำเนินการที่ครอบคลุม โดยสมมติว่าวิศวกรไม่มีบริบทใดๆ
เกี่ยวกับโค้ดเบสของเรา และมีรสนิยมที่น่าสงสัย

แต่ละงานจะถูกแบ่งออกเป็นขั้นตอน “ขนาดพอดีคำ” 2-5 นาที และแต่ละขั้นตอนต้องประกอบด้วย:

• พาธไฟล์ที่แม่นยำ (ไม่อนุญาตให้ใช้สำนวนคลุมเครือเช่น “ในไฟล์ที่เกี่ยวข้อง”)
• โค้ดที่สมบูรณ์ (ไม่อนุญาตให้อ้างอิงไขว้เช่น “คล้ายกับ Task N”)
• คำสั่งรันที่แม่นยำและผลลัพธ์ที่คาดหวัง
• วงจร Red-Green ของ TDD

ที่สำคัญกว่านั้นคือ ห้ามใช้ตัวยึดตำแหน่งใดๆ ในแผนโดยเด็ดขาด:

ทุกขั้นตอนต้องมีเนื้อหาจริงที่วิศวกรต้องการ สิ่งเหล่านี้คือความล้มเหลวของแผน:

- "TBD", "TODO", "implement later"
- "เพิ่มการจัดการข้อผิดพลาดที่เหมาะสม"
- "เขียนเทสสำหรับข้างต้น" (โดยไม่มีโค้ดเทสจริง)
- "คล้ายกับ Task N"

2.3 subagent-driven-development: สายการผลิตของเอเจนต์ย่อย

นี่คือทักษะที่สร้างสรรค์ที่สุดของ Superpowers มันแบ่งงานดำเนินการออกเป็นสายการผลิตของเอเจนต์ย่อยที่ดำเนินการตามงาน:

แต่ละงาน:
เอเจนต์ย่อย Implementer (ดำเนินการ + ตรวจสอบตนเอง + ส่ง)
↓
เอเจนต์ย่อย Spec Reviewer (ตรวจสอบการปฏิบัติตามข้อกำหนด)
↓ (ถ้าไม่ผ่าน ให้ส่งกลับไปยัง Implementer เพื่อแก้ไข)
เอเจนต์ย่อย Code Quality Reviewer (ตรวจสอบคุณภาพโค้ด)
↓ (ถ้าไม่ผ่าน ให้ส่งกลับไปยัง Implementer เพื่อแก้ไข)
ทำเครื่องหมายงานว่าเสร็จ → งานถัดไป

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

**หลักการสำคัญ:** เอเจนต์ย่อยใหม่ต่องาน + การตรวจสอบสองขั้นตอน
(ข้อกำหนดแล้วคุณภาพ) = คุณภาพสูง, วนซ้ำเร็ว

ลำดับของการตรวจสอบสองขั้นตอนไม่สามารถสลับกันได้: ต้องผ่านการตรวจสอบการปฏิบัติตามข้อกำหนดก่อน (“คุณได้ implement ฟังก์ชันทั้งหมดที่ข้อกำหนดต้องการหรือไม่? มีการ implement อะไรเกินไปหรือไม่?”) จากนั้นจึงเข้าสู่การตรวจสอบคุณภาพโค้ด รายการ Red Flags ระบุไว้อย่างชัดเจน:

เริ่มการตรวจสอบคุณภาพโค้ดก่อนที่การปฏิบัติตามข้อกำหนดจะ ✅ (ลำดับผิด)

สาม การดำเนินการ TDD อย่างสุดโต่ง: กฎเหล็กและการต่อต้านการหาเหตุผลเข้าข้างตนเอง

3.1 “กฎเหล็ก” ของการพัฒนาแบบทดสอบนำ

Superpowers ดำเนินการ TDD ในระดับที่เกือบจะ “สุดโต่ง”:

ไม่มีโค้ดผลิตภัณฑ์โดยไม่มีเทสที่ล้มเหลวก่อน

เขียนโค้ดก่อนเทส? ลบทิ้ง เริ่มใหม่

**ไม่มีข้อยกเว้น:**

- อย่าเก็บไว้เป็น "ข้อมูลอ้างอิง"
- อย่า "ปรับ适配" มันขณะเขียนเทส
- อย่ามองมัน
- ลบหมายถึงลบ

ถ้าเอเจนต์เขียนโค้ด implement ก่อนที่จะเขียนเทส ก็ต้องลบโค้ด implement ทิ้ง ไม่สามารถเก็บไว้เป็น “ข้อมูลอ้างอิง” ไม่สามารถ “ปรับ适配มันขณะเขียนเทส” และไม่สามารถแม้แต่ “มองมัน” นี่ไม่ใช่คำแนะนำ แต่เป็นกฎเหล็ก

3.2 ตารางต่อต้านการหาเหตุผล: อุดช่องโหว่ “ข้ออ้าง” ของ AI

Superpowers เข้าใจจุดอ่อนทางจิตวิทยาของเอเจนต์ AI เป็นอย่างดี — พวกมันเก่งมากในการหา “ข้ออ้าง” ที่สมเหตุสมผลเพื่อข้ามกระบวนการ เพื่อแก้ไขปัญหานี้ ทักษะที่มีวินัยทุกทักษะจะมาพร้อมกับตารางเปรียบเทียบข้ออ้างที่สมเหตุสมผล:

การออกแบบนี้มาจากความเข้าใจอย่างลึกซึ้ง: เอเจนต์ AI ไม่ได้ไม่รู้กฎ แต่ภายใต้ความกดดันมันจะหาเหตุผลเพื่อเลี่ยงกฎ Superpowers ไม่เพียงแค่กำหนดกฎ แต่ยังคาดการณ์และอุดช่องโหว่วาทกรรมหลบหนีทุกแบบที่เอเจนต์อาจใช้

สี่ การออกแบบเมตาเลเยอร์ของทักษะ: writing-skills

4.1 ใช้ TDD เขียนเอกสาร

Superpowers มี “เมตาทักษะ” ที่ชาญฉลาดอย่างยิ่ง — writing-skills ซึ่งนำ方法论 TDD มาประยุกต์ใช้กับการเขียนเอกสารทักษะเอง:

การเขียนทักษะ คือ การพัฒนาแบบทดสอบนำที่ประยุกต์ใช้กับเอกสารกระบวนการ

นั่นหมายความว่า: เมื่อสร้างทักษะใหม่ คุณต้องทดสอบพฤติกรรมของเอเจนต์ก่อนโดยไม่มีทักษะนี้ สังเกตว่ามันล้มเหลวภายใต้ความกดดันอย่างไร ใช้ข้ออ้างอะไร จากนั้นจึงเขียนเอกสารทักษะเพื่อแก้ไขรูปแบบความล้มเหลวเหล่านั้น

4.2 CSO: การเพิ่มประสิทธิภาพสำหรับการค้นหาของ AI

ฟิลด์ description ใน YAML frontmatter ของทักษะมีกฎที่ขัดกับสัญชาตญาณ: อธิบายเฉพาะเงื่อนไขการเรียกใช้ อย่าสรุปเวิร์กโฟลว์ของทักษะ

# ❌ ผิด: สรุปเวิร์กโฟลว์ AI จะทำตาม description และข้ามเนื้อหาหลัก
description:Usewhenexecutingplans-dispatchessubagentpertaskwithcodereview

# ✅ ถูก: อธิบายเฉพาะเงื่อนไขการเรียกใช้
description:Usewhenexecutingimplementationplanswithindependenttasks

สาเหตุคือ: การทดสอบพบว่าถ้า description มีบทสรุปเวิร์กโฟลว์ เอเจนต์ AI จะดำเนินการตาม description โดยตรงและข้ามการอ่านเนื้อหาทักษะทั้งหมด รายละเอียดนี้สะท้อนให้เห็นถึงความเข้าใจอย่างลึกซึ้งของทีม Superpowers เกี่ยวกับรูปแบบพฤติกรรมของ AI

ห้า การดีบักอย่างเป็นระบบ: การวิเคราะห์สาเหตุที่แท้จริงสี่ขั้นตอน

ทักษะ systematic-debugging กำหนดกระบวนการดีบักสี่ขั้นตอน:

ขั้นตอนที่ 1: การสอบสวนสาเหตุที่แท้จริง → ขั้นตอนที่ 2: การวิเคราะห์รูปแบบ → ขั้นตอนที่ 3: การตั้งสมมติฐานและการตรวจสอบ → ขั้นตอนที่ 4: การดำเนินการแก้ไข

กฎที่มีความเข้าใจลึกซึ้งที่สุดคือกฎการแก้ไขล้มเหลวสามครั้ง:

- ถ้า < 3: กลับไปขั้นตอนที่ 1 วิเคราะห์ใหม่ด้วยข้อมูลใหม่
- ถ้า ≥ 3: หยุดและตั้งคำถามกับสถาปัตยกรรม
- อย่าพยายามแก้ไขครั้งที่ 4 โดยไม่มีการอภิปรายทางสถาปัตยกรรม

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

สรุปและข้อคิด

นวัตกรรมหลักของ Superpowers อยู่ที่: มันเปลี่ยน “แนวทางปฏิบัติที่ดีที่สุดทางวิศวกรรมซอฟต์แวร์” จากความรู้โดยนัยของโปรแกรมเมอร์มนุษย์ ไปเป็นระบบคำสั่งที่ดำเนินการได้สำหรับเอเจนต์ AI คำสั่งเหล่านี้ไม่ใช่ “คำแนะนำ” ที่สุภาพ แต่เป็นกระบวนการบังคับที่มีเกตเวย์ ตารางต่อต้านการหาเหตุผล และการตรวจสอบธงแดง

จากมุมมองการใช้งานทางเทคนิค “โค้ด” ของทั้งระบบ本质上คือเอกสาร Markdown — แต่เอกสารเหล่านี้ผ่านการทดสอบอย่างเข้มงวด (การทดสอบความเครียดด้วยเอเจนต์ย่อย) การจัดการเวอร์ชัน และการปรับ适配ข้ามแพลตฟอร์ม เช่นเดียวกับวิศวกรรมซอฟต์แวร์ มันใช้รูปแบบเอกสารเพื่อ实现ฟังก์ชันของคอมไพเลอร์: แปลงความตั้งใจระดับสูง (“สร้าง X”) เป็นกระบวนการทางวิศวกรรมที่เข้มงวด

ข้อคิดที่โครงการนี้มอบให้เราอาจเป็น: ข้อจำกัดด้านความสามารถของเอเจนต์ AI ไม่ได้อยู่ที่ความฉลาด แต่อยู่ที่วินัย ดังที่ README ของ Superpowers กล่าวไว้ — “mandatory workflows, not suggestions” เมื่อเราเรียนรู้ที่จะใส่บังเหียนวินัยทางวิศวกรรมให้กับ AI มันถึงจะกลายเป็น “พลังเหนือมนุษย์” ที่น่าเชื่อถือได้อย่างแท้จริง

เอกสารอ้างอิง[1]

คู่มือการติดตั้ง README: https://github.com/obra/superpowers#installation

คำแนะนำที่เกี่ยวข้อง

• Claude ดำเนินการ, Codex ตรวจสอบ, มนุษย์ตัดสินใจนำทาง: โครงการ Humanize ใช้ RLCR จัดระเบียบงานวนซ้ำแบบวงปิดระยะยาว
• ป้อนประสบการณ์ตลอดชีวิตของผู้เชี่ยวชาญ GPU ให้ AI! โครงการ tilelang-cuda-skills: ระบบทักษะที่ให้เอเจนต์เขียนโค้ดเขียนและดีบัก CUDA operator ได้ด้วยตนเอง
• TokenSpeed แยกการอนุมาน LLM เป็นไปป์ไลน์ที่ควบคุมได้ เขียนระนาบควบคุมของเอ็นจิ้นการอนุมาน LLM ใหม่สำหรับยุคเอเจนต์เขียนโค้ด