ผมยอมรับว่าตัวเองเขียนคำสั่งเดียวให้ครอบคลุมทุกอย่างไม่เป็น การหวังให้ AI ทำงานจบใน Prompt เดียวจึงไม่ใช่ทางของผม ทางออกคือพา AI เดินไปทีละช่วงแทน
หลังจากจัดวิธีทำงานใหม่ ผมจึงเริ่มทดลองกับ SBJ Buddy เพื่อดูว่าเอกสารชุดนี้ช่วยให้เราเห็นโจทย์เดียวกัน และตรวจผลจริงได้ดีแค่ไหน
เอกสารต้องช่วยให้กลับมารู้ว่าเรากำลังทำอะไร
ตอนนั้นผมกับ AI ทำงานอยู่ใน Project และแตะไฟล์ของงานโดยตรงแล้ว แต่เมื่อมีการเปลี่ยนแปลงหลายเรื่อง ผมยังต้องไล่ดูว่าแก้เรื่องไหนไปแล้ว อะไรตกลงกันแล้ว และอะไรยังเป็นแค่ทางเลือก ข้อมูลแต่ละอย่างอยู่คนละจุด พอกลับมาทำต่อจึงต้องประกอบสถานะงานขึ้นมาใหม่ก่อนจะเดินต่อได้
ผมจึงปรับการจัดงานให้มีจุดเริ่มและผลลัพธ์ที่มองเห็นได้ README ใช้พาเข้ามาใน Release และบอกว่าควรดูอะไรต่อ; Plan อธิบายเป้าหมายกับขอบเขต; Result เก็บสิ่งที่ทำและหลักฐานที่ตรวจแล้ว เอกสารอื่นยังทำได้ตามความจำเป็น แต่เป็น working file ระหว่างทาง ไม่ต้องยกทุกชิ้นขึ้นมาเป็นไฟล์หลักของงาน
การมีไฟล์เหล่านี้ไม่ได้ทำให้งานถูกต้องขึ้นเอง มันช่วยให้ผมกับ AI เห็นว่าเรากำลังจะทำอะไร และเมื่อมีรายงานว่างานเสร็จ ผมรู้ว่าจะกลับไปดูตรงไหนเพื่อแยกคำรายงานออกจากผลจริง
ผมทำ Oneprompt ไม่เป็น จึงต้องวางทางเดินของงานให้ชัด
ผมไม่สามารถเขียนคำสั่งครั้งเดียวให้เก็บรายละเอียดของงานทั้งหมด ทั้งเป้าหมาย ขอบเขต ลำดับการทำ และวิธีตรวจผลได้ครบ งานจริงยังมีคำถามที่เพิ่งเห็นเมื่อเริ่มลงมือ และมีผลที่ต้องตรวจจากโค้ดกับการทำงานของระบบ ความพยายามยัดทุกอย่างไว้ใน Prompt เดียวจึงไม่ใช่สิ่งที่ผมทำได้ดีพอ
ผมจึงวางทิศทางของงานไว้ในเอกสาร แล้วบอก AI ให้ทำส่วนที่อยู่ตรงหน้าตามขอบเขตนั้น เมื่อได้ผล ผมตรวจและตัดสินใจว่าจะไปขั้นไหนต่อ หากมีรายละเอียดที่ยังไม่ชัดก็หยุดเติมความเข้าใจให้ตรงกันก่อน ไม่ต้องหวังให้คำสั่งแรกทำนายทุกสิ่งที่จะเกิดขึ้น
ผมเริ่มจากทางเข้า ไม่ได้โยนเอกสารทุกไฟล์ให้ AI
ใน Release หนึ่ง ๆ ผมอยากให้กลับมาเปิดงานแล้วรู้ก่อนว่ากำลังเข้ามาอยู่ตรงไหน README จึงทำหน้าที่เป็นทางเข้า: บอกว่างานนี้มีเป้าหมายอะไร สถานะล่าสุดอยู่ตรงไหน และควรอ่านแผนหรือผลจากไฟล์ใดต่อ มันช่วยให้ผมกับ AI ไม่ต้องเริ่มด้วยการไล่เปิดทุกไฟล์ที่สะสมระหว่างทาง
จากนั้น Plan เป็นตัวกำหนดว่าเรากำลังแก้ปัญหาอะไร ขอบเขตงานอยู่แค่ไหน และจะรู้ได้อย่างไรว่าชิ้นงานตรงหน้าเสร็จพอให้ตรวจต่อได้ ส่วนไฟล์อื่นที่เกิดจากการสำรวจหรือทำงานย่อยเก็บไว้เป็น working files ตามต้องการ ไม่ต้องทำเหมือนทุกโน้ตเป็นคำสั่งหลักเท่ากัน
วางภาพรวมไว้ใน Release แล้วค่อยซอยเป็น Sprint
การจัดไฟล์เป็นส่วนหนึ่งของทางเดินนั้น ผมยังต้องวางภาพรวมของงานก่อนเริ่มลงมือ ว่า Release นี้กำลังพาเราไปสู่ผลลัพธ์อะไร อยู่ในขอบเขตแค่ไหน และมีงานก้อนใดบ้างที่ต้องผ่านระหว่างทาง พอเห็นภาพเดียวกันแล้วจึงแบ่งงานออกเป็น Sprint ที่มีเป้าหมายและขอบเขตพอให้ทำและตรวจได้ การซอยเป็น Sprint ยังช่วยบริหารแรงและสมาธิของผมด้วย ผมจดจ่อกับปัญหาตรงหน้าได้ทีละเรื่อง ไม่ต้องแบกความซับซ้อนทั้งหมดไว้ในหัวพร้อมกัน
แต่ละ Sprint จึงเป็นทั้งช่วงลงมือและจุดพักของงาน เมื่อจบช่วงหนึ่ง ผมกลับมาดูสิ่งที่เกิดขึ้นจริง—โค้ดทำงานอย่างไร หลักฐานบอกอะไร และยังเหลืออะไร—แล้วค่อยตัดสินใจว่าจะเดิน Sprint ถัดไป ปรับแผน หรือหยุดรอคำตอบ จุดพักเหล่านี้ช่วยไม่ให้แผนใหญ่พา AI วิ่งต่อไปเรื่อย ๆ โดยที่ผมยังไม่ได้ตรวจว่าทิศทางยังตรงกับเป้าหมายหรือไม่
มองย้อนกลับ นี่เป็นรากแนวคิดของ SADF
ตอนนั้นผมกำลังจัดวิธีทำงานเพื่อแก้ปัญหาตรงหน้าอยู่ ผมรู้ข้อจำกัดของตัวเองเรื่องการเขียน Oneprompt จึงเริ่มจากเป้าหมาย แล้วซอยงานให้เดินทีละช่วง มีจุดให้กลับมาตรวจความจริง และเปิดทางให้ปรับแผนเมื่อสิ่งที่เกิดขึ้นไม่ตรงกับที่คิด
เมื่อมองย้อนกลับจากวันนี้ ผมเห็นองค์ประกอบของ SADF อยู่ในวงจรนั้นแล้ว: ตั้งเป้าหมายให้ชัด แบ่งเป็น Checkpoint ลงมือทีละส่วน Revisit ความก้าวหน้า และปรับแผนเมื่อจำเป็น แนวคิดไม่ได้ปรากฏเป็น Framework สำเร็จรูปในวันเดียว แต่มันค่อย ๆ ตกผลึกจากการทำงานจริงกับ AI
ให้ AI ทำงานเป็นช่วง แล้วตรวจสิ่งที่เกิดขึ้นจริง
ผมไม่ได้อยากให้ AI อ่านแผนแล้วกลับมาบอกทีเดียวว่างานทั้งหมดเสร็จแล้ว งานต้องถูกแบ่งให้เห็นว่ากำลังทำส่วนไหน และก่อนจะไปต่อเราต้องตรวจอะไร เมื่อ AI แก้โค้ดหรือรายงานผล ผมยังต้องกลับไปดู Code กับ Log ว่าเส้นทางทำงานตรงกับที่คิดหรือไม่ ถ้าจุดที่ตั้งใจเอาออกยังถูกเรียกอยู่ ข้อความว่า “แก้แล้ว” ก็ยังไม่ใช่คำตอบ
เวลาผลที่รายงานไม่ตรงกับ Plan และ Code หรือ Log แสดงอีกอย่าง ผมสะดุดใจและต้องสั่งหยุดก่อน งานไม่ควรเดินต่อเพียงเพราะมีรายงานว่าทำเสร็จแล้ว ความไม่ตรงกันนั้นเป็นสัญญาณให้ผมเหยียบเบรก ไล่ดูหลักฐาน แล้วค่อยตัดสินใจว่าจะปรับโจทย์หรือเดินต่อ
เมื่อได้ผลตรวจ Result จึงเก็บสิ่งที่ทำจริง ผลที่ยืนยันได้ และส่วนที่ยังค้างหรือรอการตัดสินใจ แผนกับผลมีหน้าที่ต่างกัน: Plan บอกว่าเราตั้งใจจะทำอะไร; Result บอกว่าเกิดอะไรขึ้นและมีหลักฐานอะไรให้ดู ถ้างานยังไม่ตรง Result ต้องบอกตามจริงก่อนเริ่ม checkpoint ถัดไป ไม่เขียนให้ดูเหมือนผ่านเพื่อให้เอกสารปิดสวย
วงจรที่ผมกำลังลองจึงเป็นแบบนี้: เปิด README เพื่อเข้าบริบท → ใช้ Plan ตั้งขอบเขตงานช่วงนี้ → ให้ AI ลงมือในขอบเขตนั้น → ผมตรวจโค้ด Log และผลตามเกณฑ์ → บันทึกสิ่งที่ยืนยันได้ใน Result → แล้วค่อยตัดสินใจว่าจะไปช่วงต่อไป ปรับแผน หรือหยุดถามเพิ่ม
Buddy เป็นสนามแรก แต่ยังไม่ใช่หลักฐานว่าทุกสนามจะเหมือนกัน
ผมเริ่มทดลองกับ Buddy เพราะเป็นงานที่มีปัญหาและเส้นทางเดิมให้ตรวจอยู่แล้ว Release ของ Buddy มีงานแก้หลายด้านและแบ่งเป็นช่วงที่มีผลตรวจของตัวเอง จึงเป็นโอกาสดูว่าโครง README, Plan และ Result ช่วยให้ผมกลับมาทำงานต่อได้โดยไม่เอาแผนไปปนกับผลหรือไม่
แต่ผมยังไม่ควรสรุปว่าการใช้กับ Buddy แปลว่าวิธีนี้พร้อมใช้กับทุก Project คำถามที่ผมทิ้งไว้กับตัวเองคือ เราจะสามารถสร้างความสำเร็จนี้ซ้ำได้หรือไม่ คำตอบยังต้องรอการทดลองครั้งถัดไป