Published: Jun 22, 2026
P2ER ซึ่งเป็นเอเจนซีด้านโซลูชันดิจิทัลใช้ เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เพื่อให้มั่นใจว่า เฉพาะซอฟต์แวร์ที่ผ่านการยืนยันและใช้งานได้เท่านั้นที่จะส่งให้เจ้าหน้าที่ ตรวจสอบขั้นสุดท้าย การเปลี่ยนเวิร์กโฟลว์ให้เป็นโครงสร้างพื้นฐานแบบ Agentic ช่วยให้ Agent AI ทำการยืนยัน UI เชิงประจักษ์ได้ ซึ่งเพิ่มความถี่ในการติดตั้งใช้งานจากสัปดาห์ละครั้งเป็นหลายครั้งต่อวัน
ความท้าทาย: ขยายคุณภาพในแอปพลิเคชันที่มีอยู่
P2ER มอบประสบการณ์ดิจิทัลระดับไฮเอนด์ให้กับแบรนด์ระดับโลก ซึ่งรวมถึงผู้ผลิตรถยนต์ แบรนด์นาฬิกา และบริษัทด้านการบริการ ความท้าทายหลักของบริษัท ซึ่งเป็นความท้าทายของบริษัทหลายๆ แห่งด้วยเช่นกันคือการทำงานภายในแอปพลิเคชันที่ซับซ้อนและมีอยู่ ในฐานะทีมที่นำการเขียนโค้ดแบบ Agentic มาใช้ ทีมต้องเผชิญกับอุปสรรคสำคัญ 3 ประการ ได้แก่
- การทดสอบ UI ที่ไม่เสถียร ชุดการทดสอบมาตรฐานประสบปัญหาเกี่ยวกับข้อมูลแบบไดนามิก เช่น ราคาสูงต่ำของโรงแรมหรือข้อเสนอตามฤดูกาลในโปรเจ็กต์บางโปรเจ็กต์ของ P2ER ข้อมูลจำลองมักจะซ่อนข้อบกพร่องในการผสานรวมที่ผู้ทดสอบที่เป็นมนุษย์จะพบได้ทันที
- ปัญหาความน่าเชื่อถือของ Agent หากไม่มีคำแนะนำที่ชัดเจน Agent AI บางครั้งจะอ้างว่างานเสร็จสมบูรณ์แล้วโดยไม่ได้ยืนยันงานนั้นจริงๆ
- การสูญเสียบริบท งานที่กว้างและระยะหมดเวลาของโมเดลทำให้ Agent ลืมเป้าหมายของเซสชัน ซึ่งทำให้นักพัฒนาแอปติดตามและทำงานต่อจากที่ Agent เริ่มไว้ได้ยาก
โซลูชัน: สร้างโครงสร้างพื้นฐานเพื่อการทำงานอย่างชำนาญ
P2ER สร้างโครงสร้างพื้นฐานที่ถือว่า AI เป็น "คู่ซ้อม" ที่สามารถจัดการงานที่ซ้ำซากของการพัฒนาได้ด้วย แนวทางนี้ช่วยให้ทีมขยายการทำงานอย่างชำนาญได้โดยมุ่งเน้นที่สถาปัตยกรรมและการแก้ปัญหาอย่างสร้างสรรค์
บังคับใช้การยืนยันเชิงประจักษ์ด้วยเครื่องมือสำหรับนักพัฒนาเว็บสำหรับเซิร์ฟเวอร์ MCP ของ Agent
P2ER กำหนดกฎการยืนยันเชิงประจักษ์ที่บังคับใช้เพื่อรับประกันความน่าเชื่อถือ
ข้อกำหนดด้านวิศวกรรมนี้ซึ่งกำหนดไว้ในไฟล์ AGENTS.md ของโปรเจ็กต์ระบุไว้ดังนี้
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
ทีมใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เพื่อให้ Agent มีสภาพแวดล้อมที่ปลอดภัยในการไปยังส่วนต่างๆ ของแอปพลิเคชันด้วยภาพและแบบโต้ตอบ แทนที่จะเชื่อตามที่ Agent บอก
"Agent ทดสอบ" เหล่านี้จะทำงานสำคัญหลายอย่างที่การทดสอบแบบคงที่มาตรฐานไม่ครอบคลุม ได้แก่
- การทดสอบข้อมูลแบบไดนามิก: แม้ในสภาพแวดล้อมการทดสอบ Agent จะทดสอบกับข้อมูลจริงที่มีการเปลี่ยนแปลง (เช่น ราคาสูงต่ำของโรงแรมตามฤดูกาล) เพื่อสัมผัสประสบการณ์การใช้งานแอปพลิเคชันเหมือนกับที่ผู้ใช้จะได้รับ การดำเนินการนี้ทำได้ด้วยเครื่องมือโต้ตอบของเครื่องมือสำหรับนักพัฒนาเว็บสำหรับ Agent เช่น
new_page,navigate_page,fill,clickและhoverซึ่งระบุไว้ในทักษะgithub-issue-testซึ่งช่วยให้ Agent สามารถตรวจสอบสิทธิ์แบบไดนามิกและจำลองเส้นทางการคลิกของผู้ใช้จริงได้ - การตรวจสอบด้วยภาพ: Agent จะระบุความคลาดเคลื่อนของภาพระหว่างเลย์เอาต์ Figma กับการใช้งานจริง การใช้เครื่องมือ
take_screenshotจากเครื่องมือสำหรับนักพัฒนาเว็บสำหรับ Agent ทักษะfigma-validateจะจับภาพหน้าจอความละเอียดสูงของการแสดงผล Storybook แบบสดเพื่อทำการเปรียบเทียบข้อมูลคู่กันกับการส่งออก Figma - การตรวจสอบความสามารถในการใช้งาน: Agent จะตรวจพบการแปลที่ขาดหายไปหรือข้อผิดพลาดด้านความสามารถในการใช้งานที่สคริปต์อัตโนมัติมักจะมองข้าม Agent จะสแกนหาความผิดปกติของ UI อย่างเช่น สตริง MISSING_MESSAGE อย่างจริงจังโดยโต้ตอบกับแผนผังการเข้าถึงโดยตรงและตรวจสอบภาพรวมที่ดึงข้อมูลผ่าน
take_snapshotและtake_screenshotตามที่ระบุไว้อย่างชัดเจนในเวิร์กโฟลว์การยืนยันอัตโนมัติ
แยกย่อยและเก็บรักษางานย่อย
P2ER แบ่งงานออกเป็นส่วนๆ อย่างเข้มงวดผ่าน Agent ย่อยเพื่อป้องกันระยะหมดเวลาของเซสชันและการสูญเสียบริบท จากนั้นจึงสั่งให้ Agent ทำหน้าที่เป็นผู้ประสานงานดังนี้
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
เพื่อให้เจ้าของผลิตภัณฑ์ที่เป็นมนุษย์ทราบความคืบหน้าในกระบวนการนี้ ทีมจึงผสานรวมทักษะที่กำหนดเองสำหรับ Agent เพื่อติดตามงานในปัญหา GitHub การดำเนินการนี้ช่วยให้มั่นใจได้ว่างานของ Agent ย่อยทุกงานและผลลัพธ์ของงานจะได้รับการเก็บรักษาและบันทึกเป็นปัญหาที่ย่อยลงโดยใช้ GitHub API ซึ่งสร้างเส้นทางการตรวจสอบที่ชัดเจนและบริบทที่คงอยู่ซึ่งนักพัฒนาแอปคนอื่นๆ สามารถนำไปใช้ต่อได้
แยกสภาพแวดล้อมเพื่อการดำเนินการแบบขนาน
P2ER กำหนดให้ Agent แต่ละคนมีสภาพแวดล้อมที่แยกกันสำหรับแต่ละงาน เพื่อขยายกระบวนการพัฒนาให้ Agent หลายคนเรียกใช้โค้ดแบบขนานได้ การดำเนินการนี้จะป้องกันความขัดแย้งของสถานะและปัญหาเครือข่ายระหว่างการยืนยัน UI
การตั้งค่าทางเทคนิคสำหรับการแยกกักตัวนี้มีดังนี้
- Worktree Git ที่แยกกัน: งานจะดำเนินการภายใน Worktree Git ที่แยกกันเพื่อป้องกันการชนกันของไฟล์และการรบกวนพื้นที่ทำงานเมื่อ Agent หลายคนทำงานแบบขนาน Agent แต่ละคนจะมีพื้นที่ระบบไฟล์เฉพาะที่คัดลอกตัวแปรสภาพแวดล้อมและลิงก์สัญลักษณ์การขึ้นต่อกัน ซึ่งช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงไฟล์จะไม่เขียนทับกัน
- สภาพแวดล้อมที่ไม่ซ้ำกัน: Agent และงานแต่ละรายการจะเรียกใช้เซิร์ฟเวอร์การพัฒนา Next.js ในพอร์ตที่แยกกันและไม่ซ้ำกัน เซิร์ฟเวอร์
จะเริ่มต้นแบบไดนามิกด้วย
npx next dev -p <custom_port> --turbopackตามกฎของโปรเจ็กต์เพื่อให้ มั่นใจว่าการดำเนินการแบบขนานจะไม่มีความขัดแย้งของเครือข่าย - ฐานข้อมูลโคลน: P2ER ทำซ้ำฐานข้อมูลหลักเป็นสคีมาเฉพาะงานโดยอัตโนมัติเมื่อ Agent เริ่มทำงาน เพื่อป้องกันการชนกันของข้อมูลระหว่างการทดสอบแบบขนาน หลังจากที่ Agent ยืนยันเสร็จสมบูรณ์และงานได้รับการอนุมัติ กระบวนการล้างข้อมูลอัตโนมัติจะลบฐานข้อมูลที่แยกกันออก วงจรนี้ช่วยให้มั่นใจได้ว่า Agent ทุกคนจะทำงานในพื้นที่ทำงานที่สะอาดและไม่มีข้อมูลที่ค้างอยู่
- การทดสอบแบบกำหนดเป้าหมาย: การทดสอบเบราว์เซอร์ทั้งหมดผ่านเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent ต้องกำหนดเป้าหมายไปยังพอร์ตที่กำหนดเองที่แน่นอนซึ่งจัดสรรให้กับอินสแตนซ์ Agent นั้นๆ
ข้อกำหนดการทดสอบห้ามการฮาร์ดโค้ดพอร์ตเริ่มต้น โดยกำหนดให้ใช้ URL เป้าหมายการทดสอบ
เช่น
http://localhost:<custom_port>
ผลลัพธ์: ความเร็วในการพัฒนาเพิ่มขึ้น 10 เท่าโดยยังคงคุณภาพไว้ได้
การเปลี่ยนไปใช้การเขียนโค้ดแบบ Agentic พร้อมด้วยการป้องกันความเสี่ยงที่เชื่อถือได้สูงได้เปลี่ยนผลลัพธ์ของ P2ER การเปลี่ยนแปลงเหล่านี้จำเป็นในตอนแรกเพื่อให้มั่นใจว่า Agent จะทำงานได้อย่างน่าเชื่อถือ แต่การเปลี่ยนแปลงเหล่านี้ยังเป็นประโยชน์ต่อวงจรการพัฒนาทั้งหมดด้วย ดังนี้
- วงจรการทำงานเร็วขึ้น 10 เท่า: ปัจจุบันปัญหาส่วนใหญ่ได้รับการแก้ไขภายในวันเดียว เทียบกับค่าเฉลี่ยก่อนหน้านี้ที่ 1-3 วัน ความถี่ในการติดตั้งใช้งานเพิ่มขึ้นจากสัปดาห์ละครั้งเป็นหลายครั้งต่อวัน
- การมุ่งเน้นเชิงกลยุทธ์สำหรับทีม QA: เนื่องจากปัจจุบัน Agent ตรวจพบการถดถอยพื้นฐาน และ "โอกาสที่ง่าย" ทีมทดสอบที่เป็นมนุษย์จึงมุ่งเน้นไปที่สถานการณ์การทดสอบที่ซับซ้อนและเจาะลึกมากขึ้นได้
- การติดตั้งใช้งานที่แข็งแกร่งสำหรับผู้มีส่วนเกี่ยวข้อง: การติดตั้งใช้งานมีความยืดหยุ่นมากขึ้นเนื่องจากการทดสอบไม่ได้จำกัดอยู่แค่ "เส้นทางที่ราบรื่น" มาตรฐานของโปรแกรมเมอร์
- การสื่อสารและการตรวจสอบย้อนกลับที่ชัดเจนขึ้น: การบังคับใช้กฎ "ปัญหาจากมนุษย์ไปสู่ปัญหาที่ย่อยลงในการติดตั้งใช้งาน" ช่วยให้ผู้มีส่วนเกี่ยวข้องได้รับคำแนะนำที่ชัดเจนเกี่ยวกับสิ่งที่ได้รับการปรับปรุงเชิงตรรกะ แทนที่จะต้องอ่านตั๋วที่เต็มไปด้วยรายละเอียดการติดตั้งใช้งานทางเทคนิคและวิธีทดสอบ
ตัวอย่างหนึ่งที่แสดงให้เห็นว่าการดำเนินการนี้ส่งผลต่อความเร็วในการพัฒนาอย่างไรคือ P2ER สร้างแพลตฟอร์มใหม่ใน 6 เดือน ซึ่งหากใช้วิธีการเดิมจะต้องใช้เวลาหลายปี เจ้าหน้าที่ที่เป็นมนุษย์ยังคงเป็นผู้ตรวจสอบคุณภาพขั้นสุดท้าย โดยจะตรวจสอบคำขอ Pull Request ที่ Agent ได้ตรวจสอบแล้ว
ข้อมูลเชิงลึกทางเทคนิคสำหรับทีม
ขณะสร้างเวิร์กโฟลว์นี้ P2ER ได้ระบุกลยุทธ์หลายอย่างที่ช่วยให้บริษัทเปลี่ยนจากการทดลองไปสู่โมเดลการพัฒนาที่ได้รับความช่วยเหลือจาก Agent ที่มีประสิทธิภาพ
กลยุทธ์เหล่านี้สามารถช่วยให้ทีมอื่นๆ ปรับแต่งการติดตั้งใช้งานแบบ Agentic ของตนเองได้
เพิ่มประสิทธิภาพการใช้โทเค็นด้วยการแทรกสคริปต์และการจัดกลุ่มคำสั่ง CLI
เซิร์ฟเวอร์ MCP อาจใช้โทเค็นจำนวนมากระหว่างเซสชันการพัฒนาที่ยาวนานหาก Agent อาศัยการไปยังส่วนต่างๆ แบบทีละขั้นตอนเท่านั้น (เช่น การถ่ายภาพหน้าจอ การค้นหารหัส การกรอกข้อมูล และการรอ) P2ER ใช้แนวทาง 2 ด้านเพื่อลดค่าใช้จ่ายนี้
- การแทรกสคริปต์แบบอินไลน์: สำหรับการโต้ตอบแบบกำหนดเป้าหมาย เช่น การตรวจสอบสิทธิ์ผ่านแบบฟอร์ม React ที่ซับซ้อน Agent จะใช้เครื่องมือ
evaluate_scriptเพื่อแทรก JavaScript ธรรมดาลงในเบราว์เซอร์โดยตรง การดำเนินการนี้จะข้ามการลบล้าง Setter ในตัวและดำเนินการหลายอย่างพร้อมกัน ซึ่งช่วยประหยัดการสนทนาได้หลายรอบ - การจัดกลุ่มสคริปต์ CLI: เมื่อ Agent พบ "อุปสรรค" หรือพบโฟลว์เบราว์เซอร์ที่ยาวนานและซ้ำซาก Agent จะเปลี่ยนไปใช้การจัดกลุ่ม CLI เป็นทางเลือก แทนที่จะใช้โทเค็นกับเครื่องมือ MCP แต่ละรายการซ้ำๆ หรือเขียนสคริปต์การทำงานอัตโนมัติที่กำหนดเองตั้งแต่ต้น P2ER จะแจ้งให้ CLI ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เก็บรักษาและจัดกลุ่มการดำเนินการของเบราว์เซอร์ การดำเนินการนี้ช่วยให้ Agent ดำเนินการโฟลว์แบบหลายขั้นตอนทั้งหมดได้ในครั้งเดียว ซึ่งช่วยลดค่าใช้จ่ายในการสื่อสารระหว่างโมเดลกับเครื่องมืออย่างต่อเนื่องได้อย่างมาก
ติดตามประสิทธิภาพโดยอัตโนมัติด้วยการวิเคราะห์การติดตาม
P2ER สร้างทักษะ
review-performance ที่ใช้เครื่องมือสำหรับนักพัฒนาเว็บสำหรับ Agent เพื่อเรียกใช้ การตรวจสอบ Lighthouse โดยอัตโนมัติ
และการติดตามประสิทธิภาพ แทนที่จะอาศัยการรับรู้ของมนุษย์เพียงอย่างเดียว
Agent ใช้เครื่องมือ performance_start_trace และ performance_analyze_insight เพื่อจับภาพและตรวจสอบ Core Web Vitals (LCP, INP, CLS) รวมถึงระบุคอขวดของเธรดหลักหรือการเปลี่ยนแปลงเลย์เอาต์ Agent สามารถเรียกใช้ lighthouse_audit แบบเต็มเพื่อป้องกันการถดถอยในการเข้าถึง (a11y), SEO และแนวทางปฏิบัติแนะนำทั่วไปบนเว็บโดยเฉพาะ เพื่อให้มั่นใจว่าเฉพาะโค้ดคุณภาพสูงเท่านั้นที่จะส่งสำหรับคำขอ Pull Request
ปรับปรุงการยืนยันด้วยเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent
นอกเหนือจากทักษะที่กำหนดเองแล้ว P2ER ยังใช้ความสามารถหลักของเซิร์ฟเวอร์ MCP ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เพื่อทำการยืนยันการทำงาน ซึ่งรวมถึงการใช้เซิร์ฟเวอร์เพื่อจำลองอุปกรณ์ต่างๆ และทดสอบการตอบสนอง เพื่อให้มั่นใจว่าอินเทอร์เฟซผู้ใช้จะทำงานได้ในขนาดหน้าจอและอุปกรณ์ต่างๆ
การใช้เซิร์ฟเวอร์ MCP เพื่อไปยังส่วนต่างๆ ของแอปพลิเคชันช่วยให้ Agent ระบุความคลาดเคลื่อนของภาพระหว่างเลย์เอาต์กับการใช้งานจริง รวมถึงระบุข้อผิดพลาดที่การทดสอบแบบคงที่มักจะมองข้าม
แหล่งข้อมูล
หากต้องการสำรวจกรณีการใช้งานของ P2ER ให้ละเอียดยิ่งขึ้น โปรดสำรวจทักษะทั้งหมดที่กล่าวถึงใน ที่เก็บ GitHub ที่เกี่ยวข้อง
หากต้องการเริ่มต้นใช้งานด้วยตนเองและดูข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้งใช้งานเวิร์กโฟลว์ที่คล้ายกันด้วยเครื่องมือสำหรับนักพัฒนาเว็บสำหรับ Agent โปรดสำรวจแหล่งข้อมูลต่อไปนี้