แถลงการณ์

Deep Work Plan (DWP) คือระเบียบวิธีแบบ markdown ล้วนสำหรับการดำเนินงานอัตโนมัติอย่างมีโครงสร้างโดยเอเจนต์เขียนโค้ด AI มันเปลี่ยนเป้าหมายที่คลุมเครือให้กลายเป็นแผนที่ทบทวนได้ — เป็นข้อกำหนด (specification) — ที่เอเจนต์สามารถดำเนินการ หยุดพัก ดำเนินการต่อ และรายงานผลได้โดยไม่สูญเสียบริบทหรือด้นสดจนได้ผลลัพธ์ที่ไม่สอดคล้องกัน

Deep work สำหรับเอเจนต์

ชื่อของมันบอกถึงแนวปฏิบัติที่มันสร้างขึ้น นั่นคือความพยายามที่จดจ่อและต่อเนื่องกับงานที่ต้องใช้สมาธิสูง ยึดโยงกันไว้ด้วยโครงสร้างมากกว่าด้วยกำลังใจ คุณสมบัติเดียวกันที่ทำให้ deep work มีค่าสำหรับมนุษย์ — สมาธิที่ปราศจากสิ่งรบกวน คงอยู่ตลอดช่วงเวลายาวนาน — คือสิ่งที่เอเจนต์เขียนโค้ด AI ต้องการเพื่อทำงานที่กินเวลาหลายชั่วโมงหรือหลายวันให้สำเร็จ Deep Work Plan มอบโครงสร้างนั้นให้ และในการทำเช่นนั้นมันก็เปลี่ยน repository ให้เป็นโค้ดเบสแบบ AI-first ที่เอเจนต์ขับเคลื่อนได้

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

ทิศทางคือตัวคูณ

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

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

Deep Work Plan คือวินัยของการทำงานต้นน้ำนั้นในรูปแบบที่ยั่งยืนและทำซ้ำได้ เสาหลักตั้งต้นสองต้นของมันคือสองส่วนของทิศทางที่ดี ได้แก่ ข้อกำหนด ที่ระบุว่า “ถูกต้อง” มีหน้าตาอย่างไร และ harness ที่มอบบริบทและเครื่องมือให้เอเจนต์ไปถึงจุดนั้น วินัยที่สามช่วยให้การประกอบกันนี้ยังจ่ายไหวเมื่อขยายขึ้น นั่นคือ ประสิทธิภาพเชิง token เพราะ harness ที่ใช้งานได้จริงย่อมเป็นสิ่งที่เอเจนต์แบกไปได้จริงตลอดช่วงทางที่ยาวนาน เมื่อรวมกันทั้งสามจะแปลงความสามารถดิบของโมเดลให้เป็นงานวิศวกรรมที่เชื่อถือได้ — คงทนตลอดงานที่กินเวลาหลายชั่วโมง และรักษาไว้ได้แม้เอเจนต์จะเปลี่ยนไปมาระหว่างเซสชัน

ขับเคลื่อนด้วยข้อกำหนดโดยการออกแบบ

นี่คือเสาหลักต้นแรกของระเบียบวิธี และเช่นเดียวกับ “harness” มันควรค่าแก่การนิยามอย่างตรงไปตรงมา

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

DWP รวมแนวคิดนี้ไว้อย่างไร ใน Deep Work Plan แผน คือ ข้อกำหนด เป้าหมายกลายเป็นแผนที่ทบทวนได้ แผนถูกแยกย่อยเป็น atomic task แต่ละงานมีเกณฑ์การยอมรับและ validation gate ที่ชัดเจน และ completion protocol ยืนยันงานเทียบกับเกณฑ์เหล่านั้น แผน → งาน → gate → การเสร็จสิ้น คือ SDD ที่จับต้องได้และดำเนินการได้จริง

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

DWP แตกต่างอย่างไร มีกระแสที่ขับเคลื่อนด้วยข้อกำหนดในวงกว้างก่อตัวขึ้นรอบแนวคิดนี้ รวมถึง GitHub Spec Kit, Amazon Kiro และ Tessl แนวทางเหล่านั้นมักผูกติดกับเครื่องมือหรือแพลตฟอร์มเฉพาะ DWP จงใจแตกต่าง มันเป็นกลางต่อเครื่องมือและฝังอยู่ใน repository โดยกำเนิด ข้อกำหนดอยู่ใน repository ในรูปของ markdown ธรรมดา จึงเดินทางไปพร้อมกับโค้ดแทนที่จะติดอยู่กับผลิตภัณฑ์ของผู้ขาย — และมันประกอบเข้ากับเสาหลักต้นที่สองได้โดยตรง เพราะข้อกำหนดเองก็เป็นส่วนหนึ่งของ harness ที่ repository พกพาไปด้วย

repository กลายเป็น harness

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

agent harness คืออะไร ตัวแบบจำลองภาษาขนาดใหญ่โดยลำพังเป็นเพียงตัวทำนายข้อความ สิ่งที่เปลี่ยนมันให้เป็นวิศวกรที่เชื่อถือได้คือทุกอย่างที่ห่อหุ้มมันไว้ ได้แก่ บริบทที่มันได้รับ เครื่องมือที่มันเรียกใช้ได้ control loop ที่ตัดสินว่าจะทำอะไรต่อ guardrail ที่ดักจับข้อผิดพลาด และสถานะถาวรที่ทำให้มันหยุดและดำเนินต่อได้ โครงนั่งร้านที่ล้อมรอบนั้นคือ harness โมเดลคือเครื่องยนต์ ส่วน harness คือตัวถัง พวงมาลัย และเบรกที่ทำให้ขับเครื่องยนต์ได้อย่างปลอดภัย

harness engineering คืออะไร ทีมส่วนใหญ่สร้างโครงนั่งร้านนั้นโดยปริยายภายในเครื่องมือเดียว — IDE ตัวหนึ่ง ผลิตภัณฑ์เอเจนต์ หรือเฟรมเวิร์กที่ทำขึ้นเฉพาะ — มันจึงใช้งานได้เฉพาะที่นั่นและหายไปทันทีที่คุณเปลี่ยนเครื่องมือ harness engineering คือวินัยของการออกแบบโครงนั่งร้านนั้นอย่างจงใจในฐานะสิ่งประดิษฐ์ระดับชั้นหนึ่ง Deep Work Plan ยืนยันจุดยืนหนักแน่นข้อหนึ่งว่ามันควรอยู่ที่ใด นั่นคือ ไม่ใช่ในเครื่องมือ แต่อยู่ใน repository เอง

ทำไม repository จึงเป็นที่ที่เหมาะสม เมื่อ harness อยู่ใน repo มันจะเดินทางไปพร้อมกับโค้ด เอเจนต์ทุกตัวที่เปิด repo จะได้รับมันสืบทอดมา และมันถูกกำหนดเวอร์ชัน ทบทวน และปรับปรุงเหมือนโค้ดอื่น ๆ DWP ติดตั้งแต่ละส่วนของ harness ในฐานะสิ่งประดิษฐ์ที่จับต้องได้และยั่งยืน

รีโพซิทอรี

• บริบท
• เครื่องมือ
• วงรอบควบคุม
• รั้วกันพลาด
• สถานะ / การกลับมาทำงานต่อ

↑ บังคับ

เอเจนต์

เพราะทุกองค์ประกอบเป็นไฟล์ใน repository แทนที่จะเป็นฟีเจอร์ของเครื่องมือ harness จึงพกพาได้โดยกำเนิด: เอเจนต์ใดก็ตามที่อ่าน markdown และรันคำสั่งเชลล์ได้ ก็เปิดไฟล์ชุดเดียวกันได้ โดยไม่ต้องมีเฟรมเวิร์กที่ทำขึ้นเฉพาะต่อเครื่องมือ นั่นคือข้อกล่าวอ้างหนึ่งบรรทัดที่ระเบียบวิธีส่วนที่เหลือยืนอยู่บนนั้น คือ repository เองกลายเป็น harness มันเป็นข้อกล่าวอ้างเกี่ยวกับสิ่งที่ repository พกพาไว้ ไม่ใช่การรับประกันว่าโมเดลจะหาโฟลว์ที่ถูกต้องได้เองอย่างน่าเชื่อถือจากคำขอครั้งแรกโดยไม่มีใครช่วย — นี่คือเหตุผลที่ kit ยังจัดส่งจุดเข้าที่ชัดเจนอย่าง dwp-* และ SKILL.md ตัวนำทาง (router) ด้วย: การพกพาได้ของไฟล์และการนำทางที่น่าเชื่อถือเป็นคุณสมบัติคนละอย่างกัน และมีเพียงอย่างแรกเท่านั้นที่ถูกสร้างขึ้นโดยโครงสร้างเพียงอย่างเดียว

มีประสิทธิภาพตั้งแต่ในโครงสร้าง

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

สามกลไกทำหน้าที่นี้

• การเปิดเผยแบบค่อยเป็นค่อยไป เอเจนต์อ่านเฉพาะแก่นสำคัญ ส่วนของคู่มือหรือข้อกำหนดแต่ละส่วนจะถูกโหลดก็ต่อเมื่อทริกเกอร์ของขั้นตอนนั้นเองเริ่มทำงาน เอเจนต์แบกเฉพาะบทที่ตนต้องใช้ ไม่ใช่ทั้งเล่ม
• การตรวจสอบที่คัดเลือกจากพื้นผิวที่แตะต้อง (Touched Surface) ทุกงานบันทึกว่าตนเปลี่ยนอะไร และเลือก gate ตามระดับความเสี่ยง — งานเล็กที่แยกตัวพิสูจน์ตัวเองในวงแคบ การเปลี่ยนกลไกที่ใช้ร่วมกันพิสูจน์ตัวเองในวงกว้าง การตรวจสอบถูกเลือกด้วยผลกระทบ ไม่ใช่ด้วยความเคยชิน
• การเรียนรู้ภายในงาน เมื่องานหนึ่งให้กำเนิดรูปแบบที่นำกลับมาใช้ได้ การตัดสินใจเกิดขึ้นภายในงานนั้นเอง ซึ่งหลักฐานยังสดใหม่ — ไม่ใช่ในบททบทวนย้อนหลังที่ไม่มีใครอ่าน

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

ทำไมการดำเนินงานอัตโนมัติแบบมีโครงสร้างจึงสำคัญ

เอเจนต์เขียนโค้ด AI ยุคใหม่มีความสามารถแต่ไร้ทิศทาง ชี้มันไปยังงานที่ไม่ใช่งานง่าย ๆ แล้วมันมักจะเริ่มแก้ไขไฟล์ทันที สูญเสียการติดตามว่าตนเปลี่ยนอะไรไป และสร้างงานที่ทบทวนยากและดำเนินต่อไม่ได้

DWP กำหนดโครงสร้างเบา ๆ ที่จัดการกับความล้มเหลวแต่ละอย่างโดยตรง

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

markdown ตลอดทั้งกระบวนการ

DWP นิยามโครงสร้าง ไม่ใช่ซอฟต์แวร์ ไม่มี runtime ให้ติดตั้ง ไม่มีต้นไม้ dependency และไม่มีการล็อกอิน แผน งาน และ log การทำงานล้วนเป็น markdown ธรรมดาที่เอเจนต์ใดก็อ่านได้ คนใดก็ทบทวนได้ และระบบควบคุมเวอร์ชันใดก็ติดตามได้อย่างสะอาด ผลลัพธ์คือการดำเนินงานที่คุณอ่านได้ ตรวจสอบได้ และไว้วางใจได้