Skip to content
Deep Work Plan เปิดตัวบน Product Hunt วันนี้ โหวตเลย

เปรียบเทียบ

Deep Work Plan และทางเลือกอื่น

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

วิธีอ่านหน้านี้

ค่าทั้งสามอธิบายความสามารถแต่ละอย่าง โดยบอกว่าความสามารถนั้นอยู่ตรงไหนในเครื่องมือ ไม่ใช่เครื่องมือนั้นดีหรือไม่

  • มีในตัว
  • เป็นตัวเลือกหรือผ่านส่วนขยาย
  • อยู่นอกขอบเขต

ตรวจทานล่าสุด:

ทางเลือกอื่น ตามเงื่อนไขของตัวเอง

เครื่องมือพัฒนาแบบขับเคลื่อนด้วยสเปก

  • เครื่องมือพัฒนาแบบขับเคลื่อนด้วยสเปก

    GitHub Spec Kit

    เปลี่ยนฟีเจอร์ให้เป็นสเปกที่ปฏิบัติการได้ ผ่านรัฐธรรมนูญ สเปก แผน และรายการงาน ขับเคลื่อนด้วย slash command ที่เชื่อมต่อกับ coding agent มากกว่าห้าสิบตัว และตรวจสอบได้ว่าอาร์ติแฟกต์ทั้งหมดสอดคล้องกันก่อนเริ่มลงมือทำจริง

    ทีมที่ต้องการเวิร์กโฟลว์ specify, plan, tasks และ implement ที่ทำซ้ำได้ ภายใน agent ที่ตนใช้อยู่แล้ว

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

  • เครื่องมือพัฒนาแบบขับเคลื่อนด้วยสเปก

    OpenSpec

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

    ทีมที่ทำงานบนระบบที่มีอยู่แล้ว และต้องการให้สเปกเติบโตทีละการเปลี่ยนแปลง

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

  • เครื่องมือพัฒนาแบบขับเคลื่อนด้วยสเปก

    Amazon Kiro

    IDE และ CLI แบบเอเจนต์ ที่สเปกไหลจากความต้องการสไตล์ EARS ไปสู่การออกแบบและงาน พร้อมไฟล์ steering และ hook ที่ทำงานตามเหตุการณ์ของ editor และสร้างสเปกให้กับโค้ดเบสที่มีอยู่แล้วเพื่อจับช่องว่างของความต้องการก่อนเริ่มออกแบบ

    นักพัฒนาที่ต้องการการพัฒนาแบบขับเคลื่อนด้วยสเปกในตัว editor ของตน พร้อมเครื่องมือที่มี AWS หนุนหลัง

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

เฟรมเวิร์กขั้นตอนการทำงานของ agent

  • เฟรมเวิร์กขั้นตอนการทำงานของ agent

    BMAD Method

    เฟรมเวิร์ก agile ของบทบาท agent เฉพาะทาง (วิเคราะห์ ผลิตภัณฑ์ สถาปัตยกรรม พัฒนา คุณภาพ) ซึ่งผลิตบรีฟ ความต้องการ เอกสารสถาปัตยกรรม และไฟล์ story พร้อม Definition of Done ที่กำหนดให้ทุก story ต้องผ่านการทบทวนจากเพื่อนร่วมทีมหรือ AI peer reviewer ก่อนจึงจะถือว่าเสร็จ

    ทีมที่ชอบพิธีกรรมตามบทบาท และต้องการวงจร agile ครบทั้งหมดสำหรับงานของ agent

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

  • เฟรมเวิร์กขั้นตอนการทำงานของ agent

    Superpowers

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

    นักพัฒนาที่ต้องการการลงมือแบบทดสอบนำที่มีวินัยภายใน coding agent ของตน

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

  • เฟรมเวิร์กขั้นตอนการทำงานของ agent

    GSD Core

    ระบบวางแผนที่มีไดเรกทอรี .planning รหัสความต้องการ แผนแบ่งเฟส การรันด้วยคอนเท็กซ์ใหม่ และการตรวจสอบเทียบกับผลลัพธ์ที่ผู้ใช้สังเกตเห็นได้ซึ่งดึงมาจากสรุปของแต่ละแผน ออกแบบมาเพื่อต่อสู้กับ "context rot" โดยรันการค้นคว้า วางแผน และดำเนินการในซับเอเจนต์แบบใช้แล้วทิ้ง พร้อมตรวจจับการตรวจสอบที่ล้าสมัยด้วยการตรวจลายนิ้วมือของเนื้อหา

    นักพัฒนาอิสระและทีมเล็กที่ต้องการ context engineering และการตรวจสอบโดยมีพิธีกรรมน้อย

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

  • เฟรมเวิร์กขั้นตอนการทำงานของ agent

    Gentle-AI

    ปรับแต่ง coding agent ที่คุณใช้อยู่แล้วด้วยหน่วยความจำถาวรที่จัดเส้นทางข้ามเซสชันและโมเดลได้ด้วย สกิลที่คัดสรร MCP server บุคลิก (persona) และ Spec-Driven Development หรือ Receipt-Driven Development แบบเลือกใช้ได้ การตั้งค่าจะถูกเขียนลงในการตั้งค่าส่วนกลางของ agent เป็นค่าเริ่มต้น ส่วนการติดตั้งแบบจำกัดขอบเขต workspace เป็นทางเลือก

    นักพัฒนาที่ต้องการระบบนิเวศ agent ที่ตั้งค่าไว้แล้ว ซึ่งจดจำงานข้ามเซสชันได้ และสามารถสร้างหลักฐานได้เมื่อต้องการ

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

AI-native SDLC

  • AI-native SDLC

    Claude's AI-native SDLC

    ลูปหกขั้นตอนจาก Plan และ Design ไปจนถึง Build, Test, Deploy และ Maintain โดยมีการอนุมัติจากมนุษย์เป็นเงื่อนไขในทุกขั้นตอน อาร์ติแฟกต์ที่คงทนถูก commit เข้าที่เก็บโค้ดระหว่างขั้นตอน มีการทบทวนเฉพาะด้านความปลอดภัยก่อนการ deploy และมีการประเมินผลต่อเนื่องที่เผยแพร่ตัวชี้วัดการส่งมอบทั้งเชิงคาดการณ์ล่วงหน้าและเชิงผลลัพธ์

    ทีมที่กำลังประเมิน playbook การส่งมอบซอฟต์แวร์แบบครบวงจรของ Claude Code และลูปข้อเสนอแนะจากการใช้งานจริง

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

โหมดวางแผนในตัวของผู้จัดจำหน่าย

  • โหมดวางแผนในตัวของผู้จัดจำหน่าย

    Vendor-native plan modes

    ผลิตภัณฑ์ agent อาจมีโหมดวางแผน ไฟล์คำแนะนำ และสกิลที่สร้างขึ้นบนมาตรฐานเปิดข้ามผู้ให้บริการอย่าง AGENTS.md และ Agent Skills แม้พฤติกรรมของโหมดวางแผนที่แท้จริงจะยังขึ้นอยู่กับผู้ให้บริการ ไคลเอนต์ และเวอร์ชัน โดยเฉพาะ Agent Skills ที่โหลดเพียงสรุปสั้น ๆ ตอนเริ่มต้น และโหลดคำแนะนำแบบเต็มเมื่อถูกเรียกใช้งานเท่านั้น ทำให้ความสามารถที่ยังไม่ใช้ไม่กินพื้นที่คอนเท็กซ์

    ทุกคนที่ต้องการการวางแผนภายใน agent เดียว โดยไม่ต้องรับระเบียบวิธีเพิ่มเติม

    ดูการเปรียบเทียบ เว็บไซต์ทางการ

สิ่งที่ Deep Work Plan นำมา

  • ไม่ผูกกับเครื่องมือและอยู่ใน repository

    harness และแผนเป็นไฟล์ใน repository ของคุณ ซึ่ง agent ใดก็ตามที่ทำตามมาตรฐาน AGENTS.md และ Agent Skills อ่านได้ การสลับ agent ไม่ทำให้แผนสูญหาย

  • การตรวจสอบที่เลือกจากสิ่งที่แต่ละงานแตะต้อง

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

  • Final Review เดียวพร้อมการตรวจความปลอดภัย

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

  • สถานะที่รอดข้ามเซสชันและ agent

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

  • ตัวตรวจสอบความสอดคล้องสำหรับตัว repository เอง

    สคริปต์แบบอ่านอย่างเดียวตรวจสอบ harness และทุกแผนเทียบกับข้อกำหนด เข้าใจวงจรชีวิตของแผนทั้งสองแบบ และออกด้วย exit code ที่เป็นมิตรกับ CI

  • ปริมาณคำสั่งที่โหลดถูกวัดและเผยแพร่

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

ข้อจำกัดที่ซื่อสัตย์

Deep Work Plan ไม่มีกลไกสเปกแบบมีชีวิตหรือแบบเดลต้า ด้านนั้น OpenSpec และเครื่องมือทำนองเดียวกันทำได้ดีกว่า ยังไม่มี benchmark อิสระของระเบียบวิธี แต่การประเมินด้วยเอเจนต์ใหม่โดยทีมงานเองได้ดำเนินการไปแล้วภายใต้โปรโตคอลที่ถูกตรึงไว้ ในสเกลเล็ก — ปริมาณงานเดียว สองฟีเจอร์ต่อหนึ่งการตั้งค่า เครื่องเดียว — และผลลัพธ์ถูกเผยแพร่ทั้งสองทิศทาง: เอเจนต์บนต้นไม้ที่มี harness อ่านไบต์น้อยกว่าในทั้งสองงาน และเซสชันของเวอร์ชันปัจจุบันใช้อินพุตและเอาต์พุตของโมเดลที่ harness รายงานน้อยกว่าเวอร์ชันหลักก่อนหน้า ขณะที่ทิศทางโทเคนสุทธิต่อปริมาณงานเป็นแบบผสมและไม่มีการอ้างความได้เปรียบด้านเวลาตามนาฬิกา ทะเบียนปริมาณคำสั่งวัดเฉพาะไบต์ที่โหลด ไม่ใช่โทเคน ต้นทุน หรือผลลัพธ์ และตัวเลขชุดคำสั่งเริ่มต้นของมันไม่ใช่เพดานของสิ่งที่การรันหนึ่งครั้งจะอ่าน DWP จำกัดขอบเขตไว้ที่ระดับที่เก็บโค้ดโดยตั้งใจ: มันไม่ใช่ระบบหน่วยความจำข้ามโปรเจกต์ ไม่ใช่เฟรมเวิร์ก agent แบบแบ่งบทบาท และไม่ใช่ IDE จึงไม่แข่งขันในแกนเหล่านั้นเช่นกัน — จับคู่กับเครื่องมือที่ครอบคลุมด้านนั้นเมื่องานต้องการความสามารถนั้นจริง ๆ

ช่วยกันรักษาความถูกต้องของหน้านี้

ช่วยกันรักษาความถูกต้องของหน้านี้

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

เปิด issue