คำถามที่พบบ่อย
คำถามที่พบบ่อย
คำตอบสั้น ๆ สำหรับสิ่งที่ผู้คนถามมากที่สุดเกี่ยวกับ Deep Work Plan โดยแต่ละข้อมีลิงก์ไปยังหน้าที่ลงลึกกว่านั้น
01
Deep Work Plan คืออะไร
Deep Work Plan ทำอะไรได้จริง?
Deep Work Plan เปลี่ยน repository ให้เป็นสภาพแวดล้อมที่มีโครงสร้างซึ่ง coding agent ลงมือกับงานยาวได้อย่างน่าเชื่อถือ มันติดตั้งมาในรูปแบบสกิลของ agent และเริ่มต้น repository หนึ่งครั้ง (ดัชนี `AGENTS.md` โครงสร้าง `docs/` ชุดเครื่องมือ `.agents/` ของสกิลและคำสั่ง และพื้นที่ผลลัพธ์ `.dwp/` ที่ถูก gitignore ไว้) จากนั้นเป้าหมายใดก็กลายเป็นแผน: งานอะตอมมิกที่แต่ละงานมีเกณฑ์การยอมรับและ validation gate รันทีละงาน คอมมิตเมื่อผ่าน และ agent ใดก็ทำต่อจากดิสก์ได้ แผนปิดลงด้วย Final Review ที่ตรวจประเด็นความปลอดภัยและตรวจสอบสถานะสุดท้าย ระเบียบวิธีอยู่ภายใต้สัญญาอนุญาต MIT และใช้ได้กับ coding agent ใดก็ตามที่อ่าน repository
ใครควรใช้?
นักพัฒนาและทีมที่มอบงานจริงหลายขั้นตอนให้ coding agent และต้องการให้งานเสร็จสมบูรณ์ เหมาะเมื่องานครอบคลุมมากกว่าหนึ่งเซสชัน มากกว่าหนึ่งกลุ่มไฟล์ หรือมากกว่าหนึ่ง agent เมื่อเพื่อนร่วมทีมต้องรับช่วงต่อจากจุดที่ agent หยุดไว้ได้ หรือเมื่อ “เสร็จ” ต้องหมายถึง “ผ่านการตรวจสอบ” ไม่ใช่ “agent บอกว่าเสร็จ” การแก้ไขหนึ่งบรรทัดไม่ต้องใช้แผน และระเบียบวิธีก็กล่าวเช่นนั้นเอง: กฎความเข้มงวดตามสัดส่วนของมันแนะนำให้ใช้เป้าหมาย เกณฑ์ และ gate แบบอินไลน์แทน
ความแตกต่างระหว่างแผนแบบ Lite กับแบบ Full คืออะไร?
เป็นทางเลือกด้านรูปแบบการนำเสนอ ไม่ใช่การแลกความเข้มงวด แผนโดยดีฟอลต์คือแบบ Lite: README แบบกระชับที่มีบันทึกงานแบบยึดโยง (anchored) ซึ่งรันได้ทันที ไม่ใช่แบบร่างที่ยังไม่สมบูรณ์ หากคุณขอแผนแบบ Full ตั้งแต่ต้น `create` จะเขียนไฟล์งานแบบ Full โดยตรง และจะขยายแผนเป็น Full เมื่อรายละเอียดคำสั่ง การพึ่งพา หรือสัญญาของงานหนึ่งไม่พอดีกับบันทึกแบบกระชับที่ตรวจทานได้อีกต่อไป การยกระดับในภายหลังก็รักษาทุกงานที่ทำเสร็จแล้วไว้ ทั้งสองรูปแบบมีเกณฑ์การยอมรับ validation gate หลักฐาน และ Final Review ภาคบังคับเหมือนกัน
มันคือเครื่องมือ เฟรมเวิร์ก หรือระเบียบวิธี?
เป็นระเบียบวิธีที่บรรจุมาในรูปแบบสกิลที่ติดตั้งได้ ไม่มีเซิร์ฟเวอร์ ไม่มีบัญชี ไม่มีรูปแบบกรรมสิทธิ์ และไม่มี runtime เกินกว่า coding agent ที่คุณใช้อยู่แล้ว สิ่งที่ถูกติดตั้งคือคำแนะนำที่ agent อ่าน สคริปต์เชลล์ชุดเล็ก ๆ สำหรับการตรวจจับบริบทและการตรวจสอบความสอดคล้อง และแบบแผนที่ repository ของคุณรับไปใช้ ทุกสิ่งที่แผนผลิตเป็น Markdown และ JSON ใน repository ของคุณ อ่านได้โดยไม่ต้องพึ่งเครื่องมือใด
ใช้ได้กับ coding agent ตัวไหนบ้าง?
agent ใดก็ตามที่อ่านไฟล์ใน repository สกิลทำตามมาตรฐาน Agent Skills แบบเปิดและแบบแผน `AGENTS.md` ดังนั้น Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot และอื่น ๆ จึงรับมันไปใช้ผ่านการโหลดสกิลและคำแนะนำตามปกติของตัวเอง การประเมินของระเบียบวิธีเองแสดงให้เห็นแผนที่เริ่มโดย agent ของผู้จัดจำหน่ายหนึ่งรายแล้วทำต่อโดย agent ของอีกรายหนึ่ง ในทั้งสองทิศทาง ความครอบคลุมของการติดตั้งและหลักฐานเชิงพฤติกรรมถูกแจกแจงแยกตาม agent ในเมทริกซ์ความเข้ากันได้ และสองสิ่งนี้ไม่เคยถูกนำมาปนกัน
ใช้งานอย่างไร?
สามขั้นตอน ขั้นแรก ติดตั้ง Deep Work Plan skill ลงใน coding agent ของคุณ——เส้นทางที่เร็วที่สุดคือ `npx skills add DailybotHQ/deepworkplan-skill` (หรือ clone skill repo แล้วรัน `./setup.sh`) ขั้นที่สอง onboard repository ครั้งเดียว เพื่อให้ agent ปรับ `AGENTS.md`, `docs/`, ชุด `.agents/` และพื้นที่ `.dwp/` ที่ถูก gitignore ให้เข้ากับสแต็กของคุณ: ชี้ไปที่ https://deepworkplan.com/init.md หรือรัน `/deepworkplan-onboard` ขั้นที่สาม วางแผนและรันงานด้วยคำสั่งบาง ๆ: `/dwp-create <goal>` สร้างแผน; `/dwp-execute` รันทีละงานผ่านแต่ละ gate; `/dwp-refine` แก้ไขแผนที่กำลังดำเนินอยู่ (ขอบเขต งาน หรือการยกระดับแผน Lite เป็น Full); `/dwp-resume` ทำต่อหลังการหยุดชะงัก; `/dwp-status` รายงานความคืบหน้าโดยไม่รัน; `/dwp-verify` สร้างรายงานการสอดคล้องที่เป็นกลาง ส่วน `/dwp-upgrade` ย้ายสกิลที่ติดตั้งไว้ไปยังรีลีสใหม่โดยไม่แตะแผนที่มีอยู่ agent ที่ intercept `/` มักใช้ `#` แทน (เช่น `#dwp-execute`) adoption endpoint และเริ่มใช้งานเร็วอธิบายเส้นทางเดียวกันอย่างละเอียดยิ่งขึ้น
มีอะไรถูกติดตั้งบ้าง และติดตั้งที่ไหน?
สกิลของ agent ถูกติดตั้งในตำแหน่งใดก็ตามที่ agent ของคุณโหลดสกิลระดับโปรเจกต์หรือระดับผู้ใช้ จากนั้นการเริ่มต้นจะปรับตัว repository เอง: มันสร้างหรือประสาน `AGENTS.md`, `docs/`, `.agents/` และพื้นที่ทำงาน `.dwp/` ที่ถูก gitignore ไว้ สกิลสอนวิธีการให้ agent ส่วน repository เก็บบริบท ชุดเครื่องมือ และหลักฐานของแผนที่ agent ตัวอื่นต้องใช้เพื่อทำต่อ
Deep Work Plan จำเป็นต้องใช้ Git หรือไม่?
แนะนำให้ใช้ Git สำหรับ repository เพราะประวัติของมันเป็นส่วนหนึ่งของพื้นผิวการกู้คืนและการตรวจทาน แต่ระเบียบวิธีก็รันได้เช่นกันใน agent workspace ที่ไม่มี Git repository ในกรณีนั้น ชั้นสถานะที่เครื่องอ่านได้ ซึ่งรวมถึงเช็กพอยต์ `state.json` และบันทึก gate เป็นสิ่งจำเป็น เพื่อให้การกู้คืนไม่ต้องพึ่งพาบทสนทนาแชท
สกิล แผน และข้อกำหนดผลิตภัณฑ์ต่างกันอย่างไร?
สกิลอธิบายว่า agent ทำขั้นตอนที่ทำซ้ำได้อย่างไร แผนของ DWP อธิบายการเปลี่ยนแปลงที่เป็นรูปธรรมผ่านขอบเขต เกณฑ์การยอมรับ validation gate และหลักฐาน ข้อกำหนดผลิตภัณฑ์อธิบายพฤติกรรมปัจจุบันของผลิตภัณฑ์และพัฒนาไปทีละส่วนหลังการทำงานจริง (delta) แม้สกิลและแผนก็เป็นข้อกำหนดเช่นกัน แต่มันอธิบายขั้นตอนและการเปลี่ยนแปลง ไม่ใช่การรักษาสัญญาผลิตภัณฑ์ที่เป็นบรรทัดฐานนั้น
02
แผนทำงานอย่างไร
validation gate ทำงานอย่างไร และต้องมีมนุษย์อนุมัติหรือไม่?
พวกมันคือคำยืนยันแบบรันได้ซึ่ง agent รันเอง การอนุมัติของมนุษย์อยู่แค่ประตูหน้าและประตูหลังของการรัน: คนอนุมัติแผนก่อนเริ่มดำเนินการ และตรวจทาน diff สุดท้ายเมื่อถึงช่วง pull request การดำเนินการระหว่างกลางเป็นไปโดยอัตโนมัติ ทุกงานระบุคำสั่งที่เป็นรูปธรรม โดยทั่วไปคือ gate คุณภาพของ repository นั้นเอง ซึ่งเลือกจากพื้นผิวที่แตะต้องของงาน: การทดสอบของพฤติกรรมที่ถูกเปลี่ยนและตัวที่ใช้มัน ขยายไปถึงชุดทดสอบทั้งหมดเมื่อการเปลี่ยนแปลงถูกใช้ร่วมกันหรือกำหนดขอบเขตไม่ได้ งานถูกทำเครื่องหมายว่าเสร็จก็ต่อเมื่อคำสั่งเหล่านั้นจบด้วยผลสำเร็จ และงานที่เปลี่ยนพฤติกรรมต้องขยายการทดสอบ เมื่อล้มเหลว agent จะซ่อมแซมสิ่งที่อยู่ในขอบเขตของงานนั้นเองก่อน แล้วรัน gate ซ้ำ ความล้มเหลวที่ซ่อมไม่ได้ภายในขอบเขตนั้นจึงทำเครื่องหมายงานว่าถูกบล็อกและหยุดการรัน
แผนหลีกเลี่ยงความล้าสมัยอย่างไร เมื่อมีคนเปลี่ยนโค้ดระหว่างการรัน?
ด้วยสามด้าน งานถูกเขียนเป็นพฤติกรรม ไม่ใช่เป็นการแก้ไขไฟล์: เกณฑ์การยอมรับบอกว่าระบบต้องทำอะไร การเปลี่ยนชื่อไฟล์หรือสลับส่วนปฏิบัติการจึงไม่ทำให้เกณฑ์ใช้ไม่ได้ ทุก gate รันใหม่เทียบกับ repository ในสภาพปัจจุบัน สมมติฐานที่พังทลายจึงล้มเหลวอย่างเห็นได้ชัดในการรันถัดไป แทนที่จะเบี่ยงเบนไปอย่างเงียบ ๆ และความล้มเหลวนั้นคือสัญญาณให้ปรับแผน ส่วนการรักษาเอกสารให้เป็นปัจจุบันเป็นส่วนหนึ่งของงาน: งานที่เปลี่ยนพฤติกรรมยังปรับปรุงเอกสารและชุดเครื่องมือสำหรับ agent ที่อธิบายถึงมัน ภายใน gate ของงานนั้นเอง การรันแต่ละครั้งควรทิ้ง repository ให้พร้อมสำหรับ agent มากกว่าสภาพที่มันพบตอนเริ่ม
แก้แผนระหว่างรันได้หรือไม่โดยไม่เสียงานที่เสร็จแล้ว?
ทำได้ การปรับแผนที่ดำเนินการไปแล้วบางส่วนคือการเคลื่อนไหวชั้นเลิศ เนื้อหางานและสถานะการดำเนินการถูกเก็บแยกจากกัน: แผนคือเช็กบ็อกซ์บนดิสก์บวกไฟล์สถานะขนาดเล็ก สิ่งที่ทำเสร็จแล้วจึงถูกบันทึกไว้แยกจากข้อความของงาน เมื่องานหนึ่งปรากฏว่าผิด agent จะทำเครื่องหมายว่าถูกบล็อกแล้วหยุด แทนที่จะฝืนทำต่อ จากนั้นคุณแก้ไข เรียงใหม่ แยก หรือทิ้งงานที่ยังไม่ได้รัน ขณะที่งานที่เสร็จแล้วยังคงเสร็จอยู่เช่นเดิม การกลับมาทำต่อจะสร้างสถานะขึ้นใหม่จากดิสก์และ repository จริง แล้วรัน gate ที่สำคัญซ้ำ สิ่งใดที่เปลี่ยนไปใต้พื้นจึงไม่รอดสายตา
มันตรวจงานเทียบกับแผนตลอดไป หรือแผนเป็นเรื่องตั้งต้นครั้งเดียว?
แผนคือการตรวจสอบต่อเนื่อง agent ทำงานทีละงานเล็ก ๆ และต้องตรวจให้ผ่านก่อนจะไปต่อ มันจึงหลงทางได้หนึ่งก้าว ไม่ใช่สามก้าว ทุกงานมีเกณฑ์การยอมรับพร้อมคำสั่งที่พิสูจน์ได้จริง และความคืบหน้าถูกเขียนลง repository ไปพร้อมกับงาน พร้อมสถานะของแต่ละงาน การเบี่ยงเบนจึงปรากฏให้คุณ เซสชันถัดไป และ agent ตัวถัดไปมองเห็นได้ แผนไม่ถือว่าเสร็จจนกว่าทุกอย่างจะผ่านการตรวจสอบ รวมถึง Final Review ข้อจำกัดที่พูดตรง ๆ: ระเบียบวิธีไม่อาจห้าม agent ไม่ให้เขียนเกณฑ์การยอมรับที่อ่อนแอตั้งแต่แรกได้ แต่มันทำให้การเบี่ยงเบนดังใหญ่แทนที่จะเงียบ
แผนถูกสร้างครั้งเดียวแล้วดูแลด้วยมือ หรือพัฒนาไปพร้อมโค้ด?
ไม่ใช่ทั้งสองอย่าง มันถูกสร้างครั้งเดียวจากเป้าหมาย แล้วได้รับการดูแลต่อเป็นส่วนหนึ่งของงาน แผนไม่ถูกเขียนใหม่จาก code diff โดยเจตนา เพราะสเปกที่ไล่ตามโค้ดจะกลายเป็นกระจกสะท้อนที่ตามหลัง ซึ่งเป็นการเบี่ยงเบนที่ระเบียบวิธีมีอยู่เพื่อกำจัด มันพัฒนาต่อโดยเจตนา: gate รันใหม่เทียบกับ repository ปัจจุบัน gate ที่ล้มเหลวจะกระตุ้นให้ปรับแผน และ agent ทำการปรับนั้นระหว่างการรัน ขณะที่คุณอนุมัติตั้งแต่ต้นและตรวจทานตอนจบ เอกสารและการทดสอบพัฒนาไปพร้อมโค้ดโดยการออกแบบ เพราะการปรับปรุงมันอยู่ภายใน gate ของแต่ละงาน
จะเกิดอะไรขึ้นหากเซสชันหยุดกลางทาง?
ความคืบหน้าอยู่บนดิสก์ ไม่ใช่ในบทสนทนา เช็กบ็อกซ์ของ README บันทึกของแต่ละงาน ดัชนีการทำงานที่จำกัดขอบเขต และไฟล์สถานะที่เครื่องอ่านได้ ถูกอัปเดตที่ขอบเขตของทุกงาน และไฟล์สถานะบันทึกเช็กพอยต์ก่อนการหยุดที่วางแผนไว้ทุกครั้ง เซสชันใหม่ หรือ agent ตัวอื่น จะอ่านดัชนีกระชับนั้น กระทบยอดกับ repository และประวัติ git แล้วทำต่อจากงานแรกที่ยังไม่เสร็จโดยไม่ต้องทำซ้ำงานที่จบแล้ว แม้การสร้างแผนที่ถูกขัดจังหวะก็กู้คืนได้: ตัวตนของแผนและรายการงานที่ตั้งใจไว้ถูกเขียนก่อนไฟล์งานใด ๆ แผนที่สร้างค้างไว้ครึ่งทางจึงเลือกทำให้เสร็จหรือทิ้งได้ แทนที่จะต้องเดา
Final Review คืออะไร?
งานปิดเดียวที่บังคับสำหรับทุกแผน ตามลำดับ: การตรวจความปลอดภัยบนชุดการเปลี่ยนแปลงสะสมทั้งหมดของแผน รวมถึงการตรวจ diff ในเครื่องที่จำเป็นโดยสกิล AI Diff Reviewer ซึ่งข้อค้นพบระดับ critical จะบล็อกการเสร็จสิ้นจนกว่าจะถูกแก้ไขหรือได้รับการยอมรับอย่างชัดเจน การตรวจสอบสถานะสุดท้าย หมายถึงชุดทดสอบ lint type-check และ format ที่ใช้ได้ทั้งหมดของ repository บนโค้ดฉบับสุดท้าย และการกระทบยอดการตัดสินใจเรื่องสกิลที่แต่ละงานบันทึกไว้ จากนั้น agent รายงานสิ่งที่ส่งมอบ หลักฐาน และข้อจำกัด และเสนอรายงานสรุปสำหรับผู้บริหารหนึ่งครั้ง โดยจะสร้างก็ต่อเมื่อคุณขอ
เกิดอะไรขึ้นเมื่อ validation gate ล้มเหลว?
gate ที่ล้มเหลวคือสัญญาณให้ซ่อมแซมก่อนอื่น: agent จะแก้สิ่งที่อยู่ในขอบเขตของงานนั้นเองแล้วรัน gate ซ้ำ ความล้มเหลวที่เกินขอบเขตนั้นจะบันทึกงานไว้ว่าถูกบล็อก และ agent จะหยุดก่อนอ้างว่าเสร็จสมบูรณ์ คุณสามารถตรวจสอบหลักฐาน แก้ไขโค้ด หรือปรับแผนงานนั้น แล้วจึงกลับมาทำต่อ คำสั่งที่ล้มเหลวคือสัญญาณให้แก้ไขความไม่สอดคล้องกัน ไม่ใช่ใบอนุญาตให้ลดความเข้มงวดของ gate
เกิดอะไรขึ้นเมื่อตัวตรวจสอบความสอดคล้องรันการตรวจสอบของมันไม่ได้?
มันบอกเรื่องนั้นอย่างชัดเจน ตัวตรวจสอบจบด้วยรหัสออก 2 และคำตัดสิน `UNVERIFIED` แบบชัดแจ้ง — มันไม่เคยพิมพ์ผ่านที่ตัวเองไม่ได้ตรวจสอบจริง เมื่อสภาพแวดล้อมไม่มี interpreter ที่ใช้ได้หรือการตรวจสอบใดรันไม่ได้ ผลลัพธ์ที่ซื่อสัตย์คือ "ยังไม่ได้ตรวจสอบ" ไม่ใช่ "สอดคล้อง" ผลลัพธ์สีเขียวหมายความเสมอว่าทุกการตรวจสอบได้รันและผ่าน วินัยเดียวกันนี้วิ่งผ่านทั้งระเบียบวิธี: ไม่มีโฟลว์ใดลดทอนหรือปลอม gate เพื่ออ้างว่างานเสร็จ
แผนรันโดยไม่มีคนเฝ้าข้ามคืนหรือใน CI ได้หรือไม่?
ได้ เมื่อแผนได้รับการอนุมัติล่วงหน้า มีชั้นสถานะที่จำเป็นครบถ้วน และให้อำนาจที่มีขอบเขตแก่ agent การรันแบบไม่มีคนเฝ้าต้องหยุดและบันทึกตัวบล็อกเมื่อสภาพจริงเบี่ยงเบนไปจากแผน เมื่อ gate ล้มเหลวนอกขอบเขตการซ่อมที่วางแผนไว้ หรือเมื่อจำเป็นต้องมีการอนุมัติหรือข้อมูลรับรอง (credential) ใหม่
03
การเปรียบเทียบกับทางเลือกอื่น
แผนหนึ่งแผนครอบคลุมหลาย repository ได้ไหม?
ได้ — อาร์เคไทป์ hub ผู้ประสานงานมีอยู่เพื่อเรื่องนี้โดยเฉพาะ repository แบบ hub เก็บแผนที่ทำหน้าที่ประสาน และ repository ลูกแต่ละตัวรันแผนของตัวเองภายในพื้นที่ทำงาน `.dwp/` ที่แยกของตัวเอง ดังนั้นลูกจึงไม่เคยเขียนลงในสถานะแผนของ hub ความสมบูรณ์ของลูกอ่านจากสถานะระดับบนสุดของแผนตัวเอง ไม่ใช่จับคู่ข้อความภายในมัน และ hub บันทึกว่าตัวเองอยู่ตรงไหนก่อนไปที่อื่น ลูกแต่ละตัวยังคงเป็น repository DWP ธรรมดาที่นำไปใช้เดี่ยว ๆ ได้
มันต่างจากเครื่องมือ spec-driven อย่าง Spec Kit, OpenSpec หรือ Kiro อย่างไร?
พวกมันแก้ปัญหาข้างเคียงกัน เครื่องมือ spec-driven เก่งมากในการจับสิ่งที่ควรเปลี่ยน: สเปก ความต้องการ และข้อเสนอการเปลี่ยนแปลงในรูปแบบที่ทำซ้ำได้ Deep Work Plan ว่าด้วยวิธีให้ agent ลงมือหลายชั่วโมงโดยไม่เบี่ยงเบน: harness ที่การเริ่มต้นวางไว้ validation gate ต่องานที่เลือกจากพื้นผิวที่แตะต้อง สถานะทำต่อได้บนดิสก์ Final Review ที่บังคับพร้อมการตรวจความปลอดภัย และตัวตรวจสอบความสอดคล้องสำหรับตัว repository เอง ทั้งสองใช้ร่วมกันได้ โดยให้สเปกหรือข้อเสนอการเปลี่ยนแปลงป้อนเข้าสู่แผน หน้าเปรียบเทียบวางความสามารถทั้งหลายเคียงกันไว้ ตามเงื่อนไขของเครื่องมือแต่ละตัว
มันต่างจากเครื่องมือขั้นตอนการทำงานของ agent อย่าง BMAD, Superpowers, Get Shit Done หรือ Gentle-AI อย่างไร?
เฟรมเวิร์กเวิร์กโฟลว์สำหรับเอเจนต์อย่าง BMAD, Superpowers และ Get Shit Done นำสไตล์การทำงานที่แข็งแกร่งมาให้: บทบาท หลักการ ขั้นตอนแบบทดสอบก่อน และนิสัยการตรวจสอบ Gentle-AI อยู่ในหมวดหมู่ใกล้เคียงในฐานะตัวกำหนดค่าระบบนิเวศเอเจนต์ โดยติดตั้งความจำถาวรข้ามเซสชัน (Engram) ทักษะที่คัดสรร เพอร์โซนา เซิร์ฟเวอร์ MCP, Spec-Driven Development แบบเลือกได้ และการรีวิวตามหลักฐานแบบเลือกได้ (Receipt-Driven Development) ให้กับโค้ดดิ้งเอเจนต์ที่คุณใช้อยู่แล้ว โดยเขียนลงในไดเรกทอรีการตั้งค่าของแต่ละเอเจนต์ Deep Work Plan แตกต่างจากทั้งสอง: มันมุ่งเน้นไปที่สิ่งที่ยังคงอยู่ในรีพอสิทอรีและสิ่งที่ตรวจสอบได้ — harness ที่เอเจนต์ใดก็ตามอ่านได้ทันทีโดยไม่ต้องมีบริบทมาก่อน ไฟล์ task ที่มีเกณฑ์การยอมรับและ gate สถานะที่คงอยู่ข้ามเซสชัน ตัวตรวจสอบความสอดคล้องที่มีโค้ดออกที่เป็นมิตรกับ CI และการวัดที่เผยแพร่ว่าแต่ละ flow โหลด instruction byte กี่ไบต์ มันไม่ผูกกับเครื่องมือใดเครื่องมือหนึ่งโดยโครงสร้าง และไม่เพิ่มบริการ ผู้ให้บริการ หรือความลับใดๆ ให้กับ core loop ชั้นเหล่านี้สามารถอยู่ร่วมกันได้: เฟรมเวิร์กและ Gentle-AI กำหนดวิธีที่เอเจนต์ทำงาน ส่วน Deep Work Plan ทำให้งานระยะยาวคงทนและตรวจสอบได้ภายในรีพอสิทอรี หน้าเปรียบเทียบแสดงให้เห็นว่าแต่ละแนวทางมีอยู่ในตัว เลือกได้ หรืออยู่นอกขอบเขต
ทำไมไม่ใช้โหมดวางแผนในตัวของ agent ที่ใช้อยู่เสียเลย?
โหมดวางแผนในตัวมีประโยชน์ และ Deep Work Plan สร้างอยู่บนพื้นฐานเดียวกัน คือแบบแผน `AGENTS.md` และมาตรฐาน Agent Skills แบบเปิด ความต่างอยู่ที่ว่าแผนอยู่ที่ไหน และอะไรบังคับใช้มัน แผนแบบเนทีฟมักอยู่นอก repository และหมดอายุไปพร้อมเซสชัน ส่วน Deep Work Plan เขียนแผน สถานะ และหลักฐานของมันลงใน repository agent ตัวอื่นหรือเพื่อนร่วมทีมจึงทำต่อได้ และทุกงานมี gate ที่รันได้พร้อมบันทึกที่ถูกเก็บไว้ คุณยังคงใช้โหมดวางแผนของ agent สำหรับการคิด ส่วนระเบียบวิธีเติมเต็มด้วยวงรอบการลงมือที่คงอยู่และตรวจสอบได้
04
การนำไปใช้
การเริ่มต้นเขียนอะไรลงใน repository ของฉัน และแตะไฟล์ที่มีอยู่เดิมหรือไม่?
การเริ่มต้นไม่ทำลายของเดิม: มันตรวจพบ `AGENTS.md`, `docs/`, `.agents/` หรือ `CLAUDE.md` ที่มีอยู่เดิม ประสานแทนที่จะเขียนทับ และถามก่อนแทนที่สิ่งใด มันเขียนดัชนี `AGENTS.md` พร้อมคำสั่งจริง โครงสร้าง `docs/` ที่ผ่านการให้เหตุผล เอกสารแยกตามโมดูล ชุดเครื่องมือ `.agents/` พร้อมคำสั่ง `dwp-*` แบบบาง พื้นที่ผลลัพธ์ `.dwp/` ที่ถูก gitignore ไว้ คู่มือการทดสอบที่ผ่านการตรวจทาน และการตรวจโค้ดในเครื่องที่จำเป็น (สกิล AI Diff Reviewer บวกส่วนขยายการรีวิวที่ปรับให้เข้ากับ repo) จากนั้นมันรัน self-check และตัวตรวจสอบความสอดคล้อง เพื่อให้คุณเห็นว่ามีอะไรถูกสร้างขึ้น repository ที่เริ่มต้นด้วยมาตรฐานก่อนหน้าจะได้รับการอัปเกรด harness แบบเจาะจง ที่ประสานเฉพาะสิ่งที่ยังขาดหรือล้าสมัย
อัปเกรดสกิลใน repository ที่เริ่มต้นไว้แล้วอย่างไร?
มีการอัปเกรดสองแบบที่ต่างกัน และโฟลว์แยกสองอย่างนี้ออกจากกัน harness ของ repository — `AGENTS.md`, `docs/`, ชุด `.agents/` — ถูกประสานใหม่ด้วยการรันการเริ่มต้นซ้ำ ซึ่งเติมเฉพาะสิ่งที่ยังขาดหรือล้าสมัย ตัวสกิลเองเคลื่อนด้วย `/dwp-upgrade`: ตรวจรีลีสล่าสุดที่เผยแพร่แบบอ่านอย่างเดียว ติดตั้งแท็กที่แน่นอนที่คุณยอมรับพร้อมการตรวจสอบ แล้วเรียกการเริ่มต้นใหม่เหมือนรันครั้งใหม่ทั้งหมด ทั้งโฟลว์ต้องได้รับความยินยอมชัดเจนทุกขั้น การปรับให้เข้ากับท้องถิ่นถูกเทียบ diff และรักษาไว้แทนที่จะเขียนทับ และ `.dwp/` ไม่เคยถูกย้าย — แผนที่มีอยู่คงรูปแบบที่บันทึกไว้และทำงานต่อไป
ใช้ระเบียบวิธีหลักได้โดยไม่ติดตั้ง add-on หรือไม่?
ได้ add-on เป็นชั้นเสริมแบบเลือกได้ (opt-in) และ repository ที่ไม่มี add-on เลยก็สอดคล้องกับ DWP อย่างสมบูรณ์ Devcontainer การรายงานผ่าน Dailybot การอัปเกรด dependency การรองรับ design system และการตรวจ CI แบบเลือกได้ ถูกเสนอให้เฉพาะเมื่อเข้ากับ repository ของคุณ และคุณยอมรับอย่างชัดเจนเท่านั้น
ถ้า repository ของฉันยังไม่มีการทดสอบหรือ linting ล่ะ?
DWP ไม่ถือว่าการไม่มี toolchain เป็นข้อยกเว้นที่ผ่านได้ฟรี ระหว่างการเริ่มต้น agent จะเสนอชุด validation ที่เหมาะกับสแต็กของคุณ บันทึกคำสั่งไว้ในเอกสารของ repository และใช้คำสั่งเหล่านั้นเป็นเป้าหมายสำหรับ gate ในอนาคต ข้อเสนอนี้ยังคงเปิดให้คุณตรวจทานได้เสมอ
ค่าใช้จ่ายเท่าไร และวัดประสิทธิภาพอย่างไร?
ระเบียบวิธีและสกิลอยู่ภายใต้สัญญาอนุญาต MIT และใช้ได้ฟรี ไม่มีบริการ ไม่มี API key และไม่มีการเก็บข้อมูลการใช้งานในโฟลว์หลัก ประสิทธิภาพถูกรายงานเป็นจำนวนไบต์ของคำสั่งที่แต่ละโฟลว์โหลด **ณ จุดเริ่มต้น** — ชุดคำสั่งเริ่มต้นของมันตอนต้นเซสชัน — เผยแพร่คู่กับ **เส้นทางครบวงจร (end-to-end path)** ที่มีชื่อเรียก ซึ่งรวมสิ่งที่ทริกเกอร์จริงของโฟลว์นั้นโหลดเพิ่มเมื่องานจริงดำเนินต่อ (ตัวอย่างเช่น resume ที่ดำเนินต่อไปจนถึง execute มักโหลดมากกว่าชุดคำสั่งเริ่มต้นของมันหลายเท่า) ตัวเลขทั้งสองไม่ใช่เพดานของเซสชัน: การรันจริงยังอ่านไฟล์ของ repository เอง เอาต์พุตของเครื่องมือ และไฟล์ทำงานของแผน ซึ่งทะเบียนนี้ไม่ได้นับรวมไว้ ตัวเลขทั้งสองวัดด้วยสคริปต์ที่คอมมิตไว้พร้อมสกิล วัดซ้ำในทุกเส้นฐานของการเผยแพร่ และเผยแพร่ในทะเบียนการประเมิน โดยรายงานตัวเลขที่เพิ่มขึ้นอย่างเปิดเผยเท่ากับตัวเลขที่ลดลง ไม่มีการรายงานเป็นเปอร์เซ็นต์ของโทเคนหรือการประหยัดค่าใช้จ่าย เพราะการนับไบต์ไม่อาจสถาปนาข้อสรุปเหล่านั้นได้ การประเมินสาธารณะด้วยเอเจนต์ใหม่ได้ดำเนินการไปแล้วภายใต้โปรโตคอลที่ถูกตรึงไว้: ฟีเจอร์เดียวกันสองชิ้นถูกสร้างจากโคลนที่สะอาดโดยไม่มี harness ด้วยเวอร์ชันหลักก่อนหน้า และด้วยเวอร์ชันปัจจุบัน การประเมินพบว่าเอเจนต์บนต้นไม้ที่มี harness อ่านไบต์น้อยกว่าในทั้งสองงาน และเซสชันฟีเจอร์ของเวอร์ชันปัจจุบันใช้อินพุตและเอาต์พุตของโมเดลน้อยกว่าเวอร์ชันหลักก่อนหน้าในทั้งสองงาน — ตามที่ harness รายงาน บนปริมาณงานเดียว การประเมินยังพบขีดจำกัดที่ซื่อตรง: การออนบอร์ดเป็นต้นทุนครั้งเดียวที่คุ้มค่าเมื่อโฟลว์ถูกใช้เท่านั้น ทิศทางโทเคนสุทธิต่อปริมาณงานเป็นแบบผสม ไม่มีการอ้างความได้เปรียบด้านเวลาตามนาฬิกา และเอเจนต์ใหม่ไม่เข้าสู่โฟลว์ด้วยตัวเอง — โฟลว์คือคำสั่งที่คุณหรือเอเจนต์ที่รู้วิธีเรียกใช้เป็นผู้สั่ง
ยังมีคำถามอยู่ใช่ไหม?
ยังมีคำถามอยู่ใช่ไหม?
เปิด discussion หรือ issue บน GitHub คำถามที่ถูกถามขึ้นซ้ำ ๆ จะถูกเพิ่มเข้าหน้านี้