คำตอบเผยแพร่แล้ว14 แหล่งที่มา
ออกแบบเอกสารสำหรับ AI agent อย่างไร ให้กติกาชัดและงานเก่ายังตรวจสอบได้
จัดเอกสารตามหน้าที่และกำหนดแหล่งข้อมูลหลักให้ชัด ดีกว่าบังคับทุกทีมใช้โครงสร้างโฟลเดอร์ชุดเดียว แผนที่เสร็จแล้วอาจไม่ต้องอยู่ในมุมมองงานประจำวัน แต่ควรเก็บสถานะและหลักฐานไว้ให้ตรวจสอบย้อนหลังได้ อย่าคิดว่าชื่อไฟล์หรือคำสั่งสั้น ๆ จะทำให้ AI ทุกเครื่องมือโหลดกติกาเหมือนกัน ต้องตรวจสอบการทำงานแยกตามแพลตฟอร์ม
เผยแพร่โดยรูปภาพสร้างด้วย GPT Image 2
คำตอบการวิจัย
ประเด็นสำคัญ
- จัดเอกสารตามหน้าที่และกำหนดแหล่งข้อมูลหลักให้ชัด ดีกว่าบังคับทุกทีมใช้โครงสร้างโฟลเดอร์ชุดเดียว
- แผนที่เสร็จแล้วอาจไม่ต้องอยู่ในมุมมองงานประจำวัน แต่ควรเก็บสถานะและหลักฐานไว้ให้ตรวจสอบย้อนหลังได้
- อย่าคิดว่าชื่อไฟล์หรือคำสั่งสั้น ๆ จะทำให้ AI ทุกเครื่องมือโหลดกติกาเหมือนกัน ต้องตรวจสอบการทำงานแยกตามแพลตฟอร์ม
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W](https://d15bya8fi85z1v.cloudfront.net/chat/r4PONBDeiygm6rkyQ1INhTEQyyP2/images/C7AB80FC077AFBDCC74B/E16B680C3CF0FB35FFC8.png)
AI พรอมต์
openai.comCreate a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"建议统一“信息职责、权威来源、生命周期和读取契约”，而不是强制所有项目采用同一套目录。BMAD 的任务治理与蓝图的知识分层可以结合，但计划保留、跨宿主加载、测试隔离和文档预算必须分别定义，不能由目录名称代替。\n\n 保留蓝图的职责分离，调整其绝对化规则。\n 借鉴 BMAD 的稳定身份、渐进细化、来源追溯和历史. Topic tags: general web, ai safety, openai, chatgpt, llm. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts
การจัดระเบียบไฟล์สำหรับ AI agent มักเริ่มจากคำถามว่า “ควรวางเอกสารไว้ในโฟลเดอร์ไหน” แต่คำถามที่สำคัญกว่าคือ ข้อมูลแต่ละชิ้นมีหน้าที่อะไร ใครเป็นแหล่งข้อมูลหลัก และ agent ต้องอ่านเมื่อใด
แนวทางจาก BMAD และวิธีทำงานแบบ Ralph ให้บทเรียนที่นำมาปรับใช้ร่วมกันได้ แต่ไม่ได้แปลว่าทุกโปรเจกต์ควรใช้โครงสร้างไดเรกทอรีแบบเดียวกัน หรือแค่ตั้งชื่อไฟล์ให้ถูกแล้ว agent จะเข้าใจและทำตามได้เสมอ
สิ่งที่ควรยืมจากแนวทางของ BMAD
จาก snapshot ของ BMAD ที่ตรวจดู แนวคิดสำคัญไม่ใช่การยึดติดกับชื่อโฟลเดอร์ชุดใดชุดหนึ่ง แต่เป็นการจัดการความสัมพันธ์ระหว่างวิธีทำงาน งานที่ต้องส่งมอบ และหลักฐานว่าอะไรเสร็จแล้ว
- แยกวิธีมาตรฐานออกจากการปรับแต่ง เพื่อให้โปรเจกต์เก็บเฉพาะส่วนที่เปลี่ยน แทนการคัดลอกทุกอย่างมาทับจนรับการอัปเดตได้ยาก
- ผูกเอกสารกับงานที่เป็นเจ้าของมัน เช่น แผน ข้อกำหนด และบันทึกทบทวน ควรตามกลับไปยังงานที่เกี่ยวข้องได้
- ค่อยเพิ่มรายละเอียดเมื่อจำเป็น ไม่ต้องสร้างเอกสารย่อยจำนวนมากล่วงหน้าสำหรับงานที่อาจเปลี่ยนหรือไม่เกิดขึ้นจริง
- เก็บร่องรอยของงานที่เสร็จแล้ว เพราะแผนอาจบันทึกสถานะ หลักฐานการทำงาน และข้อค้นพบจากการทบทวน การลบทิ้งอาจทำให้มองไม่เห็นว่าอะไรเกิดขึ้นแล้ว
สรุปได้ว่าเอกสารควรมีเจ้าของ มีสถานะที่ตรวจสอบได้ และเชื่อมโยงกับหลักฐาน ไม่ใช่มีเพียงตำแหน่งจัดเก็บที่ดูเป็นระเบียบ
โครงสร้างเดียวกันอาจไม่เหมาะกับทุกทีม
แนวทางจัดความรู้ระดับโปรเจกต์กับระบบจัดการขั้นตอนส่งมอบงานตอบโจทย์คนละชั้น จึงควรเลือกใช้ตามลักษณะงาน
- โปรเจกต์เล็กที่ทำงานต่อเนื่องโดยคนเดียว: มีจุดเริ่มต้นที่ชัดและอ่านเอกสารเฉพาะด้านเมื่อจำเป็นก็อาจเพียงพอ แต่มุมมองงานปัจจุบันควรอ้างถึงบันทึกงาน ไม่ใช่เขียนทับประวัติที่เป็นหลักฐานเพียงชุดเดียว
- ทีมที่ทำงานขนานกันหรือข้ามคลังโค้ด: ควรมีรหัสงานที่คงที่และแผนแยกตามงาน คำว่า “แผนที่กำลังทำอยู่” ควรหมายถึงจุดโฟกัสของงานหรือเซสชัน ไม่ใช่บังคับให้ทั้งทีมมีไฟล์แผนที่แก้ไขร่วมกันเพียงไฟล์เดียว
- โปรเจกต์ที่ใช้ agent โดยตรง: ต้องมีคำแนะนำหลักที่กระชับและบอกเส้นทางไปยังข้อมูลที่จำเป็น ไม่จำเป็นต้องติดตั้งกรอบวิธีทำงานขนาดใหญ่ทุกครั้ง
- ระบบที่มีเครื่องมือตรวจสอบหรือจัดการสถานะ: เพิ่มการตรวจหลักฐานหรือมุมมองสถานะได้ หากมีเครื่องมือรองรับจริง อย่าคิดว่าการเขียนคำสั่งไว้ในเอกสารเท่ากับมีระบบบังคับใช้แล้ว
5 กับดักที่ควรแก้ก่อนย้ายไฟล์ทั้งโปรเจกต์
1. “งานเสร็จแล้วก็เขียนทับแผนได้เลย”
ควรแยกมุมมองงานปัจจุบันออกจากบันทึกอ้างอิง งานเก่าไม่จำเป็นต้องอยู่ในบริบทที่ agent อ่านทุกครั้ง แต่ควรเก็บสถานะและหลักฐานไว้ให้ค้นย้อนหลังได้
2. “ไฟล์คำแนะนำแบบเดียวใช้ได้กับทุก agent”
อย่าสันนิษฐานว่าเครื่องมือทุกตัวรู้จักไฟล์ชื่อเดียวกันหรือโหลดกติกาจากโฟลเดอร์ซ้อนกันเหมือนกัน ตัวอย่างของ OpenAI ระบุว่า Codex รู้จัก AGENTS.md แต่ไฟล์อื่นในตัวอย่างเป็นเพียงแนวทางที่ปรับได้ ไม่ใช่ข้อบังคับของเครื่องมือ 6 ดังนั้นควรทดสอบการโหลดคำแนะนำแยกตามแพลตฟอร์ม
3. “จำกัดจำนวนบรรทัดแล้วจะลดการหลอน”
จำนวนบรรทัดตายตัวไม่ใช่หลักประกันสำหรับทุกโมเดลหรือทุกงาน ควรดูว่าข้อมูลที่ถูกโหลดซ้ำกันมากแค่ไหน มีประเด็นสำคัญที่ถูกตัดขาดจากกันหรือไม่ และ agent จำเป็นต้องอ่านอะไรในงานนั้นจริง ๆ
4. “ไฟล์ JSON ทั้งหมดในโฟลเดอร์ทดสอบคือขยะ”
ข้อมูลทดสอบที่กำหนดไว้ ทำซ้ำได้ และผ่านการจัดการข้อมูลอ่อนไหว ไม่เหมือนผลลัพธ์ชั่วคราวจากการรัน ควรแยกให้ชัดว่าไฟล์ใดเป็นชุดทดสอบ ไฟล์ใดเป็น log หรือผลจากการรัน และต้องเก็บไว้นานเท่าใด
5. “โฟลเดอร์ที่ถูก ignore ใช้แทนคลังประวัติได้”
การไม่แสดงผล การไม่ค้นหาโดยอัตโนมัติ และการห้ามเข้าถึง เป็นคนละเรื่องกัน หากต้องการให้ประวัติติดตามข้ามเครื่องได้ ก็ต้องกำหนดที่เก็บและนโยบายการเก็บรักษาให้ชัด ไม่ควรคาดหวังให้โฟลเดอร์ที่ Git ไม่ติดตามทำหน้าที่แทน
แยกข้อกำหนด สถานะ และหลักฐาน
หลักจัดระเบียบที่ใช้ได้กับหลายโปรเจกต์มีดังนี้
- จัดหมวดตามหน้าที่และระดับความน่าเชื่อถือ ข้อกำหนด ข้อเท็จจริงที่ตรวจแล้ว ข้อเสนอ สถานะงาน หลักฐานทดสอบ และบันทึกสำรวจ ไม่ควรถูกปะปนเป็นข้อมูลชนิดเดียวกัน
- กำหนดแหล่งข้อมูลหลักของข้อเท็จจริงสำคัญ อนุญาตให้มีดัชนีหรือสรุปซ้ำได้ แต่ควรระบุว่าข้อมูลมาจากไหนและอาจหมดอายุเมื่อใด เพื่อไม่ให้หลายไฟล์กลายเป็นแหล่งความจริงที่ขัดกัน
- บันทึกสิ่งที่อ่านจากโค้ดอย่างเดียวไม่ได้ เช่น เหตุผลของการตัดสินใจ ข้อจำกัดจากภายนอก หรือผู้รับผิดชอบข้ามส่วนประกอบ การสแกนโค้ดช่วยบอกโครงสร้าง แต่ไม่ยืนยันเจตนาทางธุรกิจหรือที่มาของนโยบาย
- ให้ไฟล์เริ่มต้นทำหน้าที่บอกกติกาและเส้นทางอ่าน ระบุเงื่อนไขที่สังเกตได้ เช่น ประเภทงานหรือส่วนของระบบที่เกี่ยวข้อง แทนคำกว้าง ๆ อย่าง “ถ้างานซับซ้อนค่อยอ่านเพิ่ม”
- แยกบทบาทของข้อกำหนด สถานะ และหลักฐาน ข้อกำหนดบอกว่าต้องได้อะไร สถานะบอกว่างานถึงไหน และหลักฐานบอกว่าเหตุใดจึงเชื่อว่างานผ่าน ทั้งสามอย่างอาจอยู่ใกล้กันได้ แต่ต้องรู้ว่าอะไรเป็นตัวอ้างอิงหลัก
- ย่อข้อมูลได้ แต่อย่าทิ้งสิ่งที่จำเป็นต่อการทำงานต่อ เช่น งานที่ยังไม่เสร็จ ตัวขวาง การพึ่งพางานอื่น ขอบเขตการอนุญาต และตำแหน่งหลักฐาน ประวัติที่เคยผ่านไม่ได้แปลว่าการรอบใหม่ผ่านโดยอัตโนมัติ
- เก็บประวัติพร้อมทำให้กติกาปัจจุบันอ่านออก เมื่อมีการแทนที่การตัดสินใจเดิม ควรเชื่อมโยงเหตุผลและบันทึกที่มา แต่ไม่จำเป็นต้องยัดประวัติทั้งหมดไว้ในเอกสารกติกาที่ agent ต้องอ่านทุกครั้ง
- แยกไฟล์ทดสอบออกจากผลการรัน โดยคำนึงถึงธรรมเนียมของภาษาและเครื่องมือที่ใช้ พร้อมกำหนดการจัดการผลลัพธ์ตามความอ่อนไหว ขนาด และระยะเวลาการเก็บ
- ใช้เครื่องมือกับกฎที่ตรวจได้แบบกลไก เช่น รูปแบบไฟล์หรือเส้นทางที่ต้องป้องกัน แต่การสร้างไฟล์ตรวจสอบอย่างเดียวไม่ได้แปลว่ากฎถูกบังคับใช้แล้ว ต้องแน่ใจว่าเครื่องมือครอบคลุมเงื่อนไขนั้นจริง
- อย่าใช้ชื่อโฟลเดอร์แทนการกำหนดสิทธิ์ การเขียนเอกสาร การรันคำสั่ง การส่งข้อมูลออกเครือข่าย การเผยแพร่ และการเก็บถาวร ล้วนต้องมีขอบเขตการอนุญาตของตัวเอง
บทเรียนจาก Ralph: งานย่อยชัด แต่แผนยังละเอียดได้
Geoffrey Huntley อธิบาย Ralph ว่าเป็นลูปที่ทำงานในกระบวนการเดียว โดยมุ่งทำหนึ่งงานต่อหนึ่งรอบ และย้ำว่าการกำหนดงานให้แคบและชัดมีส่วนช่วยให้ได้ผลลัพธ์ที่ดี 14 แนวทางที่เผยแพร่ในโครงการของเขายังแสดงตัวอย่างการแยกสเปกตามหัวข้อ และเก็บบทเรียนเรื่องการ build หรือทดสอบไว้ในไฟล์ปฏิบัติการของโปรเจกต์
11
สิ่งที่นำไปใช้ได้คือการแบ่งงานให้พอดี มีข้อกำหนดเฉพาะที่ค้นหาเจอ และใช้ผลทดสอบหรือผล build เป็นข้อมูลย้อนกลับ ไม่ใช่สรุปว่าทุกทีมต้องใช้โครงสร้างเดียวกัน ตัวอย่างแผนงานของ OpenAI สำหรับงานซับซ้อนก็แสดงให้เห็นว่าเอกสารคำแนะนำประจำโปรเจกต์ที่สั้นสามารถอยู่ร่วมกับแผนงานที่ละเอียดและปรับปรุงต่อเนื่องได้ 5
แนวทางปฏิบัติจึงอาจเป็นดังนี้: คำแนะนำที่ agent อ่านเป็นประจำควรกระชับ ส่วนแผนงานควรมีรายละเอียดตามความเสี่ยงและระยะเวลาของงาน ขณะเดียวกัน การเริ่มรอบใหม่ควรสร้างบริบทที่พอทำงานกับงานปัจจุบันได้ ไม่จำเป็นต้องยกบทสนทนาทั้งหมดกลับมา
ข้อควรระวังคืออย่าเหมารวมคำแนะนำจากโครงการที่ดัดแปลงแนวทาง Ralph ว่าเป็นมาตรฐานดั้งเดิมของผู้สร้าง และอย่าสรุปเรื่องประสิทธิภาพหรือการแยกสภาพแวดล้อมทดสอบเกินกว่าหลักฐานที่มี
เริ่มจากความสัมพันธ์ของข้อมูล ไม่ใช่การย้ายโฟลเดอร์
ลำดับที่เสี่ยงน้อยกว่าคือกำหนดก่อนว่าเอกสารแต่ละชนิดมีหน้าที่อะไรและอะไรเป็นแหล่งข้อมูลหลัก จากนั้นตรวจว่า agent แต่ละแพลตฟอร์มโหลดคำแนะนำอย่างไร ทำมุมมองงานปัจจุบันให้กระชับ แล้วค่อยปรับวิธีเก็บประวัติและงบประมาณเอกสารจากผลการใช้งานจริง
การออกแบบที่ดีจึงไม่ได้วัดจากจำนวนโฟลเดอร์หรือความสั้นของไฟล์เพียงอย่างเดียว แต่ดูว่า agent หาแนวทางที่จำเป็นเจอหรือไม่ ทีมรู้หรือไม่ว่าอะไรคือข้อกำหนดปัจจุบัน และยังตรวจสอบย้อนหลังได้หรือเปล่าว่างานหนึ่ง ๆ เสร็จเพราะเหตุใด
Studio Global AI
ทำการวิจัยต่อ
หน้านี้รวมคำตอบที่ได้รับการสนับสนุนจากแหล่งที่มาซึ่งคุณสามารถดำเนินการต่อภายใน Studio Global
คนยังถาม
คำตอบสั้น ๆ สำหรับ "ออกแบบเอกสารสำหรับ AI agent อย่างไร ให้กติกาชัดและงานเก่ายังตรวจสอบได้" คืออะไร
จัดเอกสารตามหน้าที่และกำหนดแหล่งข้อมูลหลักให้ชัด ดีกว่าบังคับทุกทีมใช้โครงสร้างโฟลเดอร์ชุดเดียว
ประเด็นสำคัญที่ต้องตรวจสอบก่อนคืออะไร?
จัดเอกสารตามหน้าที่และกำหนดแหล่งข้อมูลหลักให้ชัด ดีกว่าบังคับทุกทีมใช้โครงสร้างโฟลเดอร์ชุดเดียว แผนที่เสร็จแล้วอาจไม่ต้องอยู่ในมุมมองงานประจำวัน แต่ควรเก็บสถานะและหลักฐานไว้ให้ตรวจสอบย้อนหลังได้
ฉันควรทำอย่างไรต่อไปในทางปฏิบัติ?
อย่าคิดว่าชื่อไฟล์หรือคำสั่งสั้น ๆ จะทำให้ AI ทุกเครื่องมือโหลดกติกาเหมือนกัน ต้องตรวจสอบการทำงานแยกตามแพลตฟอร์ม
แหล่งที่มา
developers.openai.comdevelopers.openai.com › cookbook › examplesdevelopers.openai.com
ghuntley.comRalph Wiggum as a "software engineer" - Geoffrey Huntley
github.comhow-to-ralph-wiggum/README.md at main - GitHub