แถลงการณ์

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 ที่มอบบริบทและเครื่องมือให้เอเจนต์ไปถึงจุดนั้น เมื่อรวมกันทั้งสองจะแปลงความสามารถดิบของโมเดลให้เป็นงานวิศวกรรมที่เชื่อถือได้ — คงทนตลอดงานที่กินเวลาหลายชั่วโมง และรักษาไว้ได้แม้เอเจนต์จะเปลี่ยนไปมาระหว่างเซสชัน

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

นี่คือเสาหลักต้นแรกของระเบียบวิธี และเช่นเดียวกับ “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 ในฐานะสิ่งประดิษฐ์ที่จับต้องได้และยั่งยืน

องค์ประกอบของ harness	สิ่งที่มันให้	ที่ที่ DWP วางไว้ใน repo ของคุณ
บริบท	สิ่งที่เอเจนต์จำเป็นต้องรู้	AGENTS.md, docs/ และ README ต่อโมดูล
เครื่องมือ	สิ่งที่เอเจนต์ทำได้	skill, agent และคำสั่ง dwp-* ใน .agents/
control loop	งานดำเนินไปอย่างไร	Deep Work Plan: แผน → atomic task → gate → การเสร็จสิ้น
guardrail	สิ่งที่ทำให้ถูกต้อง	เกณฑ์การยอมรับและ validation gate ที่ชัดเจน
สถานะ	มันรอดพ้นการขัดจังหวะอย่างไร	แผน ดราฟต์ และ progress log ใน .dwp/ ที่ถูก gitignore

รีโพซิทอรี

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

↑ บังคับ

เอเจนต์

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

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

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

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

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

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

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