คำตอบเผยแพร่แล้ว11 แหล่งที่มา
แยกการเตรียมสภาพแวดล้อมออกจากการทดสอบ แล้วค่อยปรับขอบเขตการตรวจ
กฎส่วนกลางไม่ได้ระบุว่าทุกแพตช์ต้องรันทดสอบครบทุกชุดในคอนเทนเนอร์ แต่แผนโครงการในอดีตกำหนดให้ตรวจจริงหลังแก้แต่ละขั้น บันทึกหนึ่งครั้งแสดงว่ามีการติดตั้งแพ็กเกจก่อนเริ่มทดสอบ แต่ยังยืนยันไม่ได้ว่าทุกครั้งดาวน์โหลดข้อมูล 198.1 MiB หรือเกิดการติดตั้งซ้ำทุกครั้ง ข้อเสนอหลักคือแบ่งงานเป็นสามชั้น: สภาพแวดล้อมเครื่องมือที...
เผยแพร่โดยรูปภาพสร้างด้วย GPT Image 2
คำตอบการวิจัย
ประเด็นสำคัญ
- กฎส่วนกลางไม่ได้ระบุว่าทุกแพตช์ต้องรันทดสอบครบทุกชุดในคอนเทนเนอร์ แต่แผนโครงการในอดีตกำหนดให้ตรวจจริงหลังแก้แต่ละขั้น
- บันทึกหนึ่งครั้งแสดงว่ามีการติดตั้งแพ็กเกจก่อนเริ่มทดสอบ แต่ยังยืนยันไม่ได้ว่าทุกครั้งดาวน์โหลดข้อมูล 198.1 MiB หรือเกิดการติดตั้งซ้ำทุกครั้ง
- ข้อเสนอหลักคือแบ่งงานเป็นสามชั้น: สภาพแวดล้อมเครื่องมือที่เตรียมแยก การทดสอบระหว่างพัฒนา และชุดตรวจรับเมื่อถึงจุดส่งมอบ
- ควรเก็บรายละเอียดผลทดสอบไว้เป็นหลักฐานแยกจากบทสนทนา และส่งเฉพาะสรุปที่จำเป็นเข้าโมเดล โดยไม่ผ่อนปรนการแยกสภาพแวดล้อม
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you operate via client side tool execution on the](https://d15bya8fi85z1v.cloudfront.net/chat/QuPfET7ftYd6An8JH1fI8Jq25Ow2/images/5A9530F1F6D0FC021B39/86DE7A18882BB9D494FC.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 operate via client side tool execution on the. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"建议把 BMAD V4.2 的“物理背压”改成“隔离强度不降级、验证范围分级、环境准备独立、证据按需进入上下文”。当前证据指向的不是“测试太严格”，而是阶段粒度被细化、测试入口携带环境安装、详细输出直接回灌，以及执行记录反复对账共同放大了成本。\n\n本次仅交付只读审计和替换条款：不修改规则文件，不运行测试或部署. Topic tags: general web, workflow, code, data. 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 with fake
ข้อเสนอหลัก: คงการแยกสภาพแวดล้อม แต่จัดการตรวจให้เป็นชั้น
การปรับ BMAD V4.2 ไม่ควรเริ่มจากการลดความเข้มงวดด้านความปลอดภัย แต่ควรแยกวงจรให้ชัดว่าอะไรคือการเตรียมเครื่องมือ อะไรคือการทดสอบ และอะไรคือการตรวจรับก่อนส่งมอบ จากนั้นค่อยควบคุมปริมาณบันทึกที่ส่งเข้าโมเดล
หลักฐานที่มีชี้ว่าต้นทุนอาจสะสมจากหลายจุดพร้อมกัน ได้แก่ การกำหนดขอบเขตงานย่อยถี่เกินไป คำสั่งทดสอบที่พ่วงการเตรียมสภาพแวดล้อม เอาต์พุตจำนวนมาก และการตรวจทานบันทึกการดำเนินงานซ้ำ อย่างไรก็ตาม ข้อมูลยังไม่พอจะสรุปสัดส่วนต้นทุนของแต่ละปัจจัย
ข้อเสนอต่อไปนี้เป็นผลตรวจและร่างข้อกำหนดสำหรับปรับปรุงเท่านั้น ไม่ได้แก้ไฟล์กฎ รันทดสอบหรือปรับใช้ระบบ และไม่ได้รับรองหรือเก็บถาวรแผนงานใด
สิ่งที่หลักฐานบอกได้—and ยังบอกไม่ได้
กฎส่วนกลางไม่ได้สั่งให้ทดสอบเต็มชุดทุกแพตช์
กฎส่วนกลางของ BMAD กำหนดให้ตรวจสอบสิ่งที่เกี่ยวข้องในแต่ละขั้นตอน ไม่ได้ระบุว่าทุกแพตช์ต้องรันชุดทดสอบคอนเทนเนอร์ทั้งหมด กฎส่วนกลาง ส่วนกฎสำหรับโหมดวิศวกรก็เปิดให้ใช้เครื่องโฮสต์หรือคอนเทนเนอร์ที่ได้รับอนุญาต และให้เลือกการตรวจตามขอบเขตการเปลี่ยนแปลง กฎโหมดวิศวกร
ข้อกำหนดที่เข้มกว่าอยู่ในแผนโครงการเก่า ซึ่งระบุให้ “ตรวจจริงหลังแก้แต่ละขั้น” ข้อกำหนดในแผน ดังนั้นจึงไม่ควรสรุปว่ากฎ BMAD ส่วนกลางบังคับให้ติดตั้งสภาพแวดล้อมซ้ำทุกครั้ง ภาพที่แม่นยำกว่าคือกฎส่วนกลางยังไม่กำหนดระดับของแต่ละขั้นและขอบเขตต้นทุนการเตรียมระบบ จากนั้นแผนโครงการได้เพิ่มความถี่ในการตรวจ และคำสั่งทดสอบเดียวกันอาจรับภาระทั้งเตรียมเครื่องมือและทดสอบ
บันทึกหนึ่งครั้งยืนยันว่ามีการติดตั้ง แต่ไม่ยืนยันการดาวน์โหลดซ้ำ 198.1 MiB
บันทึก aurora.log แสดงการติดตั้งแพ็กเกจ 14 รายการก่อนเริ่มเหตุการณ์ทดสอบ ส่วนข้อความท้ายการติดตั้งรายงานขนาดรวม 198.1 MiB สำหรับ 31 แพ็กเกจ ตัวเลขนี้ไม่ได้ยืนยันว่าการทำงานครั้งนั้นดาวน์โหลดข้อมูลหรือแตกไฟล์ใหม่ครบ 198.1 MiB
- เริ่มปฏิบัติงานราว 14:04:04 และเริ่มเหตุการณ์ทดสอบเวลา 14:04:09.330 คิดเป็นช่วงก่อนทดสอบประมาณ 5.3 วินาที บันทึกเวลา
- การทดสอบระดับแพ็กเกจใช้เวลาประมาณ 2.72 วินาที ส่วนการทำงานทั้งหมดใช้เวลาราว 8 วินาที บันทึกการจบงาน
- บันทึกที่มีไม่แยกให้เห็นว่าช่วงก่อนทดสอบใช้ไปกับการติดตั้ง การเริ่มระบบ การคอมไพล์ หรือการตรวจแคชอย่างละเท่าไร
จึงสรุปได้ว่าคำสั่งทดสอบมีขั้นเตรียมงานก่อนเริ่มทดสอบที่เห็นได้ชัด แต่ยังวัดสัดส่วนเวลาที่ใช้ติดตั้งโดยลำพังไม่ได้
เสียงรบกวนในบริบทไม่ได้มีแค่บันทึกติดตั้ง
ส่วนติดตั้งมีประมาณ 16 บรรทัด ขณะที่ส่วนทดสอบมีรายการเริ่มและจบซ้ำทั้งในรูปเหตุการณ์และข้อความ ตัวอย่างรายการซ้ำ บันทึกที่ให้มายังมีเครื่องหมายละข้อความยาวประมาณ 76,000 ตัวอักษร ตำแหน่งข้อความที่ถูกตัด
การปิดบันทึกติดตั้งอย่างเดียวจึงอาจไม่แก้ปัญหาเอาต์พุตทดสอบที่ซ้ำซ้อน และไม่ควรอนุมานจากประวัติแชตหรือหน้าจอว่าข้อความทั้งหมดถูกส่งเข้าโมเดล หรือคำนวณจำนวนโทเคนที่คิดเงินจริง เพราะหลักฐานยังไม่พอ
แยกขั้นคอมไพล์กับทดสอบแล้ว แต่การเตรียมงานอาจยังปะปนอยู่
ประวัติการทำงานบันทึกการเรียกคอมไพล์และทดสอบแยกกันหลายครั้ง รวมถึงการใช้คอนเทนเนอร์คนละตัวอย่าง บันทึกการตรวจสถานะคงที่ แต่คำสั่งทดสอบที่ปรากฏยังเป็นคำสั่ง Go test ซึ่งอาจมีงานเตรียมการสร้างอยู่ด้วย คำสั่งในคอนเทนเนอร์
ขณะนี้ยังไม่มีเนื้อหาสคริปต์แยกสภาพแวดล้อมให้ตรวจ จึงระบุไม่ได้ว่าการติดตั้งเกิดในสคริปต์ จุดเริ่มต้นของอิมเมจ หรือชั้นห่อหุ้มอื่น และยังสรุปไม่ได้ว่าทุกครั้งในประวัติศาสตร์ติดตั้งซ้ำ ข้อสรุปที่รอบคอบคือพบการติดตั้งในบันทึกหนึ่งครั้ง พบประวัติการเรียกคอนเทนเนอร์หลายครั้ง และยังต้องตรวจเพิ่มก่อนจะยืนยันว่ามีการติดตั้งซ้ำทุกครั้ง
จุดบอดของกฎ: วงจรสี่แบบที่ไม่ควรเหมารวม
- วงจรการแยกสภาพแวดล้อม — การทดสอบหนึ่งครั้งต้องไม่ปนเปื้อนซอร์ส เครื่องโฮสต์ หรือการทดสอบรอบถัดไป
- วงจรของเครื่องมือ — คอมไพเลอร์ ไลบรารีระบบ และดีเพนเดนซีเปลี่ยนตามรุ่นของสภาพแวดล้อม ไม่ใช่ตามทุกครั้งที่แก้ตรรกะธุรกิจ
- วงจรการตรวจสอบ — ต้องพิจารณาว่าการเปลี่ยนแปลงครั้งนี้ทำให้หลักฐานชิ้นใดใช้ต่อไม่ได้
- วงจรการบันทึก — การเก็บผลและอัปเดตสถานะไม่ควรทำให้หลักฐานด้านฟังก์ชันที่เพิ่งได้มาต้องเริ่มตรวจใหม่ทั้งหมดโดยอัตโนมัติ
แผนเดิมกำหนดให้ตรวจเอกสารที่ผูกกับเวอร์ชันเมื่อเอกสารเปลี่ยน และมีการบันทึกสรุปย้อนหลังซ้ำหลายรอบ ประวัติการผูกเอกสาร การตรวจหลังบันทึก แนวทางนี้ช่วยป้องกันการแก้ไขหลักฐาน แต่หากไม่แยก “ข้อมูลนำเข้าตามสัญญา” ออกจาก “ผลการทำงาน” ก็เสี่ยงเกิดวงจรธรรมาภิบาล เช่น บันทึกผลแล้วเอกสารเปลี่ยน จึงตรวจใหม่ แล้วบันทึกอีกครั้ง นี่เป็นความเสี่ยงเชิงโครงสร้าง ไม่ใช่หลักฐานว่ามีวงจรไม่รู้จบเกิดขึ้นแล้ว
ประเด็นสำคัญคือ การใช้เครื่องมือที่ไม่เปลี่ยนแปลงซ้ำไม่ได้แปลว่าต้องใช้พื้นที่ทดสอบที่สกปรกต่อไป และการสร้างพื้นที่ทดสอบชั่วคราวใหม่ก็ไม่ได้แปลว่าต้องติดตั้งเครื่องมือใหม่ทุกครั้ง
นอกจากนี้ ควรเปลี่ยนถ้อยคำอย่าง “ปลอดภัยอย่างสมบูรณ์” ให้เป็นขอบเขตที่ตรวจรับได้ เช่น ห้ามเชื่อมต่อเครือข่ายภายนอกและห้ามเขียนข้อมูลถาวรโดยไม่ได้รับอนุญาต แต่อนุญาตพื้นที่ชั่วคราวที่จำกัดขนาดและผลตรวจที่ระบุไว้ การที่ตัวตรวจจับ data race ผ่าน หมายถึงผ่านเฉพาะเส้นทางที่ทดสอบจริง ไม่ได้พิสูจน์ว่าโปรแกรมไม่มี data race โดยสิ้นเชิง 9
โมเดลสามชั้นที่เสนอ
ตารางต่อไปนี้เป็นข้อเสนอด้านข้อกำหนด ไม่ใช่ความสามารถที่ยืนยันว่ามีการใช้งานแล้ว
| ชั้น | หน้าที่ | จังหวะที่เรียกใช้และขอบเขตการใช้ซ้ำ |
|---|---|---|
| L0: สภาพแวดล้อมรันงานที่ไม่เปลี่ยนแปลง | เตรียมเครื่องมือ ไลบรารีระบบ และดีเพนเดนซีที่อนุมัติ พร้อมบันทึกตัวตนอิมเมจ รุ่นเครื่องมือ และค่าความปลอดภัย | เตรียมรุ่นใหม่เมื่อข้อมูลสภาพแวดล้อมเปลี่ยน การแก้ซอร์สธุรกิจไม่ควรเรียกติดตั้งแพ็กเกจระบบ |
| L1: วงรอบพัฒนาระหว่างเขียนโค้ด | รัน unit test, module test และการตรวจ data race ที่จำเป็นต่อการเปลี่ยนแปลง | ทำหนึ่งครั้งต่อชุดการเปลี่ยนแปลงที่มีความหมาย โดยใช้สภาพแวดล้อมแยกที่อนุมัติ และปรับเฉพาะขอบเขตการทดสอบ |
| L2: ประตูก่อนส่งมอบแต่ละช่วง | รันชุดตรวจที่กำหนดสำหรับช่วงนั้น ตรวจ RSS แยกจากเครื่องมือแทรกโค้ด และเทียบหลักฐานให้ครบ | ทำเมื่อปิดช่วงงานหรือก่อนส่งมอบ ไม่ควรเรียกซ้ำเพียงเพราะอัปเดตบันทึกสถานะทั่วไป |
L0: ใช้สภาพแวดล้อมซ้ำได้ แต่ไม่ใช้พื้นที่ทดสอบที่ปนเปื้อน
- ระบุตัวตนเนื้อหาอิมเมจให้แน่นอน คำสั่งทดสอบต้องไม่ติดตั้งแพ็กเกจระบบ ดึงอิมเมจ หรือดาวน์โหลดดีเพนเดนซีระหว่างทำงาน
- หากอิมเมจ เครื่องมือ หรือดีเพนเดนซีไม่พร้อม ให้หยุดและรายงานว่าสภาพแวดล้อมยังไม่พร้อม ห้ามเชื่อมต่ออินเทอร์เน็ตเพื่อติดตั้งเองโดยอัตโนมัติ
- การเตรียม L0 ต้องได้รับอนุมัติ แยกจับเวลา และไม่ซ่อนอยู่ในคำสั่งตรวจสอบ
- การทดสอบต้องคงซอร์สเป็นแบบอ่านอย่างเดียว ปิดเครือข่ายภายนอก ใช้สิทธิ์เท่าที่จำเป็น และจำกัดพื้นที่ชั่วคราว ห้ามแนบข้อมูลรับรอง ช่องควบคุมของโฮสต์ หรือไดเรกทอรีที่ไม่เกี่ยวข้อง
- แยกแคชตามโครงการ เครื่องมือ แพลตฟอร์ม และขอบเขตความเชื่อถือ การพบแคชหมายถึงนำผลคำนวณเดิมกลับมาใช้ ไม่ใช่หลักฐานว่าการทดสอบผ่าน
L1: ทดสอบให้เร็วขึ้นไม่ได้หมายถึงออกจากแซนด์บ็อกซ์
ขอบเขตการอนุมัติในประวัติระบุให้ตรวจแบบออฟไลน์ในคอนเทนเนอร์แยก ขอบเขตการอนุมัติ จึงไม่ควรแทนที่ด้วยการทดสอบบนเครื่องโฮสต์โดยอัตโนมัติ
แนวทางตั้งต้นที่เสนอคือใช้วงรอบแยกแบบน้ำหนักเบา ภายใต้ข้อจำกัดความปลอดภัยเดิม หากจะใช้เครื่องโฮสต์ ต้องมีการอนุมัติและกำหนดเงื่อนไขให้ชัด ห้ามสลับไปใช้เพียงเพราะช่วยประหยัดเวลา
L2: ตรวจชุดที่ตรึงไว้ แทนการติดตั้งเครื่องมือซ้ำ
- ผูกผลตรวจรับเข้ากับภาพรวมที่แน่นอนของซอร์สและชุดทดสอบ ดีเพนเดนซี สภาพแวดล้อม ค่ารัน และรายการตรวจ
- วัด RSS ด้วยโปรเซสแยกที่ไม่มีเครื่องมือแทรกโค้ด และบันทึกผล data race กับผลทรัพยากรแยกจากกัน ข้อกำหนดเรื่องทรัพยากรมีอยู่ในแผนเดิมแล้ว ควรเก็บไว้ ข้อกำหนดตรวจทรัพยากร
- หากข้อมูลนำเข้าที่เกี่ยวข้องเปลี่ยนหลังผ่านประตูก่อนส่งมอบ ห้ามนำผลเดิมมาใช้กับชุดใหม่โดยตรง อาจรันซ้ำเฉพาะส่วนที่ได้รับผลกระทบได้ แต่ต้องแสดงหลักฐานว่าส่วนอื่นยังใช้ได้ หากพิสูจน์ไม่ได้ ให้ขยายขอบเขตการตรวจ
กำหนดให้ชัดว่าอะไรเป็นตัวกระตุ้นการตรวจ
แทนที่จะกำหนดว่า “แก้ไฟล์กี่ไฟล์จึงนับเป็นหนึ่งขั้น” ควรจัดการตามลักษณะการเปลี่ยนแปลง
| การเปลี่ยนแปลงหรือเหตุการณ์ | สิ่งที่ต้องทำ | สิ่งที่ไม่ควรถูกเรียกโดยอัตโนมัติ |
|---|---|---|
| แก้การทำงานและ assertions สำหรับพฤติกรรมเดียวกันเสร็จเป็นชุด | รัน L1 ที่เกี่ยวข้องหนึ่งครั้ง | สร้าง L0 ใหม่หรือรัน L2 เต็มชุด |
| เปลี่ยนล็อก การเข้าถึงพร้อมกัน การยกเลิก หรือการคืนทรัพยากร | เพิ่มการตรวจ data race และวงจรชีวิตที่เจาะจงในชุดนั้น | รอไปตรวจ data race ตอนส่งมอบเท่านั้น |
| เปลี่ยนอินเทอร์เฟซข้ามโมดูลหรือดีเพนเดนซีร่วม | ขยายการทดสอบไปตามเส้นทางเรียกที่ได้รับผล | ทดสอบเฉพาะไฟล์ที่แก้โดยไม่มีเหตุผลรองรับ |
| เปลี่ยนเครื่องมือ ดีเพนเดนซีระบบ หรือค่าการแยกสภาพแวดล้อม | ตรวจ L0 ใหม่และประเมินหลักฐานที่เกี่ยวข้อง | ติดตั้งของที่ขาดระหว่างคำสั่งทดสอบ |
| ตรึงชุดงานสำหรับตรวจรับช่วงหนึ่ง | รันชุด L2 ที่กำหนดสำหรับช่วงนั้น | รันเมทริกซ์เต็มซ้ำทุกแพตช์ระหว่างทาง |
| เปลี่ยนเฉพาะบันทึกการทำงานหรือข้อความความคืบหน้า | ตรวจความครบถ้วนและข้อกำหนดเอกสาร | รันทดสอบธุรกิจและวัด RSS ใหม่ |
“ชุดการเปลี่ยนแปลงที่มีความหมาย” ในที่นี้คือการเปลี่ยนพฤติกรรมหนึ่งเรื่องพร้อมการทดสอบที่ตรวจสอบเรื่องนั้นได้ อาจรวมการแก้โค้ดหลายจุดที่แม่นยำได้ แต่ต้องผ่าน L1 ก่อนเริ่มชุดถัดไปที่พึ่งพาพฤติกรรมนั้น ไม่ควรสะสมการแก้ไขไว้ยาวไม่มีกำหนด และไม่ควรแบ่งงานตามจำนวนครั้งที่เรียกเครื่องมืออย่างตายตัว
ร่างข้อกำหนดที่นำไปปรับใช้ได้
1. ปรับคำจำกัดความของการตรวจจริง
เป้าหมายคือส่วนที่ 3 ของ กฎ BMAD ส่วนกลาง โดยเสนอให้ระบุว่า
- การตรวจจริงหมายถึงการเรียกใช้งานในสภาพแวดล้อมที่อนุมัติและได้ผลที่ตรวจสอบย้อนกลับได้ ไม่ได้หมายความว่าต้องสร้างสภาพแวดล้อมพื้นฐานใหม่ทุกครั้งที่แก้ไข
- ก่อนเริ่มงาน ให้กำหนดชุดการเปลี่ยนแปลงที่มีความหมาย ขอบเขตของแต่ละช่วง รายการตรวจที่เกี่ยวข้อง และเงื่อนไขเพิ่มระดับการตรวจ แต่ละชุดต้องผ่าน L1 และการตรวจรับช่วงงานต้องผ่าน L2
- แยกอินพุต งบเวลา และผลลัพธ์ของการเตรียม L0 การคอมไพล์ การรัน assertions และการล้างทรัพยากร คำสั่งทดสอบห้ามติดตั้งแพ็กเกจระบบ ดึงอิมเมจ หรือดาวน์โหลดดีเพนเดนซีโดยปริยาย
- จำแนกสภาพแวดล้อมไม่พร้อม คอมไพล์ไม่ผ่าน assertions ไม่ผ่าน หมดเวลา ไม่พบการทดสอบ หลักฐานเสียหาย และล้างทรัพยากรไม่สำเร็จออกจากกัน รายการบังคับที่ไม่ผ่านข้อใดข้อหนึ่งต้องหยุดการเลื่อนขั้น
- ผลไม่ผ่านต้องหยุดการเลื่อนขั้น แต่ไม่ห้ามวินิจฉัยและแก้ไขภายในขอบเขตปัจจุบัน ห้ามทำให้ผ่านด้วยการรันคำสั่งเดิมซ้ำโดยไม่มีการเปลี่ยนแปลง ยกเลิก assertions หรือผ่อนปรนข้อจำกัดความปลอดภัย
- ผูกผลตรวจเข้ากับอินพุตจริงและขอบเขตที่ครอบคลุม จะอ้างผลเดิมต่อได้เมื่อพิสูจน์ว่าอินพุตและเงื่อนไขการใช้ผลยังไม่เปลี่ยน สำหรับงานเก่าที่กลับมาทำต่อ ต้องยืนยันการอนุมัติและหลักฐานปัจจุบันใหม่
2. ระบุวิธีทำงานสำหรับโหมดวิศวกร
เป้าหมายคือส่วนที่ 3 ของ กฎโหมดวิศวกร โดยเพิ่มหลักเกณฑ์ว่าโหมดนี้ต้องใช้ข้อกำหนด L0/L1/L2 ร่วมกัน ไม่ยกระดับทุกการแก้ไขเป็นประตูก่อนส่งมอบเต็มรูปแบบ แต่ละรอบตรวจต้องบอกขอบเขตที่เปลี่ยน เหตุผลที่เลือกรายการตรวจ และเหตุผลที่เพิ่มระดับการตรวจ ห้ามตัดสินความเสี่ยงจากจำนวนไฟล์เพียงอย่างเดียว
หากแยกงบเวลาคอมไพล์และทดสอบอย่างเคร่งครัด ขั้นทดสอบต้องใช้สิ่งส่งมอบจากการคอมไพล์ที่ระบุตัวตนได้ ไม่ย้อนกลับเข้าสู่กระบวนการสร้างงานโดยปริยาย และต้องแยกเวลาสำหรับคอมไพล์ ทดสอบ และล้างทรัพยากร พร้อมกำหนดงบรวมให้ครอบคลุมทุกขั้นและช่วงเวลาปิดงานด้วย
การเปลี่ยนขอบเขตความปลอดภัย การเตรียมสภาพแวดล้อม และการนำระบบธุรกิจไปใช้งานจริง ต้องได้รับอนุมัติแยกจากกัน การสร้างคอนเทนเนอร์เพื่อทดสอบไม่ควรถูกเรียกว่าเป็นการปรับใช้ระบบธุรกิจ
3. แยกบันทึกรายละเอียดออกจากสรุปที่ส่งเข้าโมเดล
ควรกำหนดสัญญาการแสดงเอาต์พุตไว้ส่วนกลาง แล้วให้โหมดวิศวกรอ้างอิง เพื่อลดความซ้ำซ้อนของกฎ
- แยกบันทึกวินิจฉัยฉบับเต็มออกจากสรุปที่โมเดลเห็น เก็บรายละเอียดไว้ในช่องทางหลักฐานที่ได้รับอนุมัติและมีขีดจำกัดการเก็บรักษา ไม่ส่งทั้งหมดเข้าแชตเป็นค่าเริ่มต้น
- เสนอเพดานเริ่มต้นไม่เกิน 2 KiB สำหรับผลผ่าน และ 8 KiB สำหรับผลไม่ผ่าน โดยคงสาเหตุหลักแรก stack trace ที่จำเป็น รหัสจบงาน รายการที่ขาด และตำแหน่งหลักฐานต้นฉบับ หากเกินขนาดต้องระบุให้ชัด ไม่ทำเหมือนว่าสรุปนั้นครบถ้วน
- อย่างน้อยสรุปต้องระบุตัวตนของการตรวจ ระดับ จำนวนที่พบและจำนวนที่ทำเสร็จ รายการที่ไม่ผ่านหรือข้าม เวลาแต่ละช่วง รหัสจบงาน และผลการล้างทรัพยากร
- แปลผลเหตุการณ์ทดสอบแบบมีโครงสร้างและรวมรายการซ้ำ ไม่ใช้การลบบรรทัดที่มีคำว่า “error” แทนการตรวจสอบ
- หากไม่มีเหตุการณ์จบ การแปลผลล้มเหลว ไม่พบการทดสอบ มีรายการข้ามที่อธิบายไม่ได้ หรือเข้าถึงหลักฐานไม่ได้ ห้ามถือว่าผ่านจากรหัสจบงานเป็นศูนย์เพียงอย่างเดียว
- บันทึกเตรียมระบบไม่ใช่หลักฐานว่าฟังก์ชันผ่าน แต่ต้องเก็บข้อมูลวินิจฉัยไว้เมื่อเตรียมระบบล้มเหลว
ตัวเลข 2 KiB และ 8 KiB เป็นเพียงจุดตั้งต้นที่เสนอ ไม่ใช่มาตรฐานอุตสาหกรรมหรือค่าที่วัดแล้วว่าเหมาะที่สุด การตัดเอาต์พุตต้องเกิดก่อนผลจากเครื่องมือถูกเพิ่มเข้าไปในประวัติโมเดล การบอกให้โมเดล “ไม่ต้องสนใจบันทึก” หรือพับข้อความไว้ในหน้าจออย่างเดียวไม่เพียงพอ
4. เติมข้อกำหนดลงในแม่แบบแผนงาน
เป้าหมายคือส่วนเมทริกซ์การตรวจใน แม่แบบแผนงาน โดยให้แต่ละรายการระบุชั้นที่สังกัด เหตุการณ์ที่เรียกใช้ ขอบเขตที่คาดว่าจะครอบคลุม สิ่งที่ไม่ครอบคลุม สภาพแวดล้อมและการอนุมัติ งบเวลาสำหรับเตรียมระบบ คอมไพล์ ทดสอบ และล้างทรัพยากร รวมถึงลายนิ้วมือของอินพุต เงื่อนไขที่ทำให้หลักฐานใช้ไม่ได้ และขอบเขตที่อนุญาตให้นำผลเดิมมาใช้ต่อ
แม่แบบควรระบุงบของสรุป ตำแหน่งและระยะเวลาเก็บหลักฐานดิบ ตลอดจนวิธีจัดการเมื่อสภาพแวดล้อมไม่พร้อม assertions ไม่ผ่าน หรือหลักฐานไม่ครบ นอกจากนี้ ให้เก็บข้อมูลนำเข้าตามข้อกำหนดแยกจากผลการทำงาน การบันทึกผลต้องไม่เรียกการตรวจฟังก์ชันเดิมซ้ำโดยอัตโนมัติ แต่ยังคงใช้ลายนิ้วมือไฟล์เต็มเพื่อป้องกันการสับเปลี่ยนข้อมูล ห้ามยกเลิกการปกป้องความครบถ้วนเพียงเพื่อหลีกเลี่ยงการตรวจซ้ำ
วิธีปรับโจทย์ตรวจสอบให้ไม่ตั้งสมมติฐานเกินหลักฐาน
ควรระบุไว้ตั้งแต่ต้นว่าการตรวจนี้เป็นการทบทวนวิธีทำงานแบบอ่านอย่างเดียว ไม่แก้ไฟล์ ไม่รันทดสอบหรือปรับใช้ระบบ และไม่รื้อฟื้นแผนงานเก่า จากนั้นตรวจแยกกฎส่วนกลาง กฎของโหมด แผนโครงการ คำสั่งที่ใช้จริง และผลดิบ โดยแบ่งให้ชัดว่าอะไรเป็นข้อเท็จจริงที่สังเกตได้ อะไรเป็นบันทึกในอดีต และอะไรเป็นข้ออนุมาน
อย่าตั้งสมมติฐานล่วงหน้าว่าทุกครั้งดาวน์โหลด 198 MiB ทุกครั้งรันเมทริกซ์เต็ม หรือข้อความที่เห็นในหน้าจอทั้งหมดถูกส่งเข้าโมเดล ให้แยกวัดต้นทุนของการเตรียมสภาพแวดล้อม การคอมไพล์ การทดสอบ การแสดงบันทึก และการทวนสอบหลักฐาน หากวัดไม่ได้ ให้บอกช่องว่างของหลักฐานอย่างตรงไปตรงมา
ควรเริ่มจากการออกแบบ L1 ที่คงระดับการแยกสภาพแวดล้อมเดิม ไม่ถือว่ามีสิทธิ์ทดสอบบนโฮสต์หรือเตรียมระบบผ่านเครือข่ายโดยอัตโนมัติ สำหรับข้อกำหนดแต่ละข้อ ให้ระบุเหตุการณ์เริ่มต้น เงื่อนไขที่ทำให้ผลเดิมใช้ไม่ได้ การจำแนกความล้มเหลว งบเอาต์พุต และเกณฑ์ตรวจรับได้ เมื่อได้แนวทางขั้นต่ำที่ทำงานได้แล้วให้หยุด ไม่เพิ่มแพลตฟอร์มคอนเทนเนอร์ที่ต้องทำงานตลอดเวลา ระบบเวิร์กโฟลว์ทั่วไป หรือการปรับโครงสร้างธุรกิจที่ไม่เกี่ยวข้อง
ลำดับนำไปใช้และตรวจรับ
- ปรับกฎและแม่แบบแผนงานก่อน โดยกำหนด L0/L1/L2 ชุดการเปลี่ยนแปลงที่มีความหมาย งบเอาต์พุต และเงื่อนไขที่ทำให้หลักฐานใช้ต่อไม่ได้ พร้อมตรวจ ทางเข้าใช้งานทักษะ และ กฎหลักฉบับดั้งเดิม เพื่อไม่ให้เส้นทาง Roo กับเส้นทางดั้งเดิมตีความต่างกัน
- จากนั้นค่อยปรับตัวรันงานให้เตรียมเครื่องมือไว้ล่วงหน้า แยกขั้นเตรียมออกจากการทดสอบ และสร้างสรุปแบบมีโครงสร้าง การปิดข้อความติดตั้งอย่างเดียวไม่ควรถูกนับว่าแก้ปัญหาครบแล้ว
- ปิดท้ายด้วยการทดสอบเปรียบเทียบขนาดเล็ก โดยรันหลายชุดการเปลี่ยนแปลงในสภาพแวดล้อมเดียวกัน ตรวจว่าช่วงทดสอบไม่มีการติดตั้งแพ็กเกจระบบ L2 ไม่ถูกเรียกจากการอัปเดตบันทึกทั่วไป และสรุปเอาต์พุตอยู่ในงบ พร้อมทดสอบกรณี assertions ล้มเหลว ไม่พบการทดสอบ หมดเวลา และล้างทรัพยากรไม่สำเร็จว่าทุกกรณียังหยุดการเลื่อนขั้นได้
บันทึก Governance ADR ได้แบ่งหน้าที่ของแพลตฟอร์มโฮสต์ไว้แล้ว การปรับรอบนี้ไม่ควรนำวงจรพิสูจน์สิทธิ์แบบวนซ้ำที่ตัวเอเจนต์ต้องรับรองตัวเองกลับมา และไม่ควรกล่าวอ้างว่าการแก้กฎแบบคงที่เป็นการยืนยันพฤติกรรมของไคลเอนต์แล้ว
ข้อสรุปคือ ควรลดการเตรียมระบบซ้ำและเอาต์พุตเต็มจำนวนก่อน แล้วจึงปรับความถี่การตรวจ อย่าเริ่มจากการยกเลิกการแยกสภาพแวดล้อมหรือลดการตรวจ data race ที่สำคัญเพื่อชดเชยข้อบกพร่องของตัวรันงานและข้อกำหนดในกระบวนการ
Studio Global AI
ทำการวิจัยต่อ
หน้านี้รวมคำตอบที่ได้รับการสนับสนุนจากแหล่งที่มาซึ่งคุณสามารถดำเนินการต่อภายใน Studio Global
คนยังถาม
คำตอบสั้น ๆ สำหรับ "แยกการเตรียมสภาพแวดล้อมออกจากการทดสอบ แล้วค่อยปรับขอบเขตการตรวจ" คืออะไร
กฎส่วนกลางไม่ได้ระบุว่าทุกแพตช์ต้องรันทดสอบครบทุกชุดในคอนเทนเนอร์ แต่แผนโครงการในอดีตกำหนดให้ตรวจจริงหลังแก้แต่ละขั้น
ประเด็นสำคัญที่ต้องตรวจสอบก่อนคืออะไร?
กฎส่วนกลางไม่ได้ระบุว่าทุกแพตช์ต้องรันทดสอบครบทุกชุดในคอนเทนเนอร์ แต่แผนโครงการในอดีตกำหนดให้ตรวจจริงหลังแก้แต่ละขั้น บันทึกหนึ่งครั้งแสดงว่ามีการติดตั้งแพ็กเกจก่อนเริ่มทดสอบ แต่ยังยืนยันไม่ได้ว่าทุกครั้งดาวน์โหลดข้อมูล 198.1 MiB หรือเกิดการติดตั้งซ้ำทุกครั้ง
ฉันควรทำอย่างไรต่อไปในทางปฏิบัติ?
ข้อเสนอหลักคือแบ่งงานเป็นสามชั้น: สภาพแวดล้อมเครื่องมือที่เตรียมแยก การทดสอบระหว่างพัฒนา และชุดตรวจรับเมื่อถึงจุดส่งมอบ