# 10 ทักษะเอเจนต์ที่ดีที่สุดสำหรับโคเด็กซ์เพื่อปรับปรุงเวิร์กโฟลว์ของคุณ

> ค้นพบทักษะโคเด็กซ์ที่ดีที่สุดสำหรับการวางแผนโปรเจกต์ การดีบักไปป์ไลน์ CI ที่ล้มเหลว การทดสอบแอปพลิเคชัน การนำดีไซน์ไปใช้ การดีพลอยเว็บโปรเจกต์ และการปรับปรุงเวิร์กโฟลว์การพัฒนาในชีวิตประจำวัน

- Canonical: https://nanoskill.ai/th/blog/best-agent-skills-for-codex
- Markdown: https://nanoskill.ai/th/blog/best-agent-skills-for-codex.md
- Author: Jeff Page
- Published: 2026-06-26T09:09:24.794Z
- Updated: 2026-07-25T04:38:34.299Z
- Language: th

## บทนำ

โคเด็กซ์สามารถเขียนโค้ด อธิบายรีโพซิทอรีที่ไม่คุ้นเคย แก้ไขบั๊ก และช่วยให้นักพัฒนาเคลื่อนที่เร็วขึ้นอยู่แล้ว แต่สำหรับทีมส่วนใหญ่ ปัญหาคอขวดที่แท้จริงไม่ใช่การสร้างโค้ดไม่กี่บรรทัด

มันคือทุกสิ่งรอบโค้ด

การวางแผนฟีเจอร์ก่อนการนำไปใช้ การทำความเข้าใจการรัน CI ที่ล้มเหลว การตอบกลับความคิดเห็นใน pull request การทดสอบโฟลว์ผู้ใช้ในเบราว์เซอร์จริง การทำความสะอาดชุดข้อมูล การเขียนเอกสาร การเตรียมโปรเจกต์สำหรับการดีพลอย นี่คือเวิร์กโฟลว์ที่ซ้ำซากซึ่งกินเวลาหลายชั่วโมงในแต่ละสัปดาห์อย่างเงียบๆ นั่นคือจุดที่ทักษะเอเจนต์มีประโยชน์

ทักษะเอเจนต์มอบวิธีที่ทำซ้ำได้ให้กับโคเด็กซ์ในการจัดการงานประเภทเฉพาะ แทนที่จะอธิบายข้อกำหนดเดิมซ้ำในทุกพรอมต์ คุณสามารถติดตั้งคำแนะนำที่มีโครงสร้าง ทรัพยากรสนับสนุน และเวิร์กโฟลว์เฉพาะงานให้กับโคเด็กซ์ ผลลัพธ์ไม่ใช่แค่ผลลัพธ์ที่เร็วขึ้น แต่เป็นงานที่สม่ำเสมอมากขึ้นตลอดการวางแผน การพัฒนา การทดสอบ การรีวิว และการส่งมอบ

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

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

## **โดยสรุป: ทักษะเอเจนต์ที่ดีที่สุดสำหรับโคเด็กซ์**

นี่คือภาพรวมโดยย่อของทักษะเอเจนต์ที่ดีที่สุดสำหรับโคเด็กซ์และเวิร์กโฟลว์ที่มีประโยชน์มากที่สุด

### การเปรียบเทียบอย่างรวดเร็ว: ทักษะเอเจนต์ที่ดีที่สุดสำหรับโคเด็กซ์

| ทักษะ | เหมาะที่สุดสำหรับ | ช่วยให้โคเด็กซ์ทำอะไร | สิ่งที่คุณต้องการ |

| --- | --- | --- | --- |

| กำหนดเป้าหมาย | เกณฑ์ความสำเร็จที่ชัดเจน | เปลี่ยนคำขอที่คลุมเครือให้เป็นเป้าหมายที่วัดผลได้ ขอบเขต และขั้นตอนการตรวจสอบ | งานที่มีข้อกำหนดไม่ชัดเจนหรือมีผลลัพธ์ที่เป็นไปได้หลายอย่าง |

| กิตฮับ-ฟิกซ์-ซีไอ | แก้ไขการตรวจสอบ CI ที่ล้มเหลว | ตรวจสอบความล้มเหลวของ GitHub Actions ตรวจสอบบันทึก และเสนอแผนการซ่อมแซมที่มุ่งเน้น | การเข้าถึง GitHub CLI และรีโพซิทอรีที่ใช้ GitHub Actions |

| กิตฮับ-แอดเดรส-คอมเมนต์ | ข้อเสนอแนะจากการรีวิว PR | รวบรวมความคิดเห็นจากการรีวิว สรุปการเปลี่ยนแปลงที่ขอ และช่วยจัดการข้อเสนอแนะที่เลือก | pull request ที่เปิดอยู่บน GitHub และการเข้าถึง GitHub CLI |

| เพลย์ไรท์ | การทดสอบเบราว์เซอร์และการดีบัก UI | เปิดเบราว์เซอร์จริง ทดสอบโฟลว์ผู้ใช้ กรอกฟอร์ม คลิกปุ่ม และจับภาพหน้าจอ | เว็บโปรเจกต์พร้อมกับสภาพแวดล้อม Node.js และ npm ที่ทำงานได้ |

| แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย | การเขียนโค้ดที่ปลอดภัยโดยค่าเริ่มต้น | ตรวจสอบโค้ดสำหรับความเสี่ยงด้านความปลอดภัยทั่วไปและแนะนำรูปแบบการนำไปใช้ที่ปลอดภัยกว่า | โค้ดเบสที่รองรับ เช่น Python, JavaScript/TypeScript หรือ Go |

| ฟิกม่า อิมพลีเมนต์ ดีไซน์ | เวิร์กโฟลว์จาก Figma สู่โค้ด | แปลงเลย์เอาต์ คอมโพเนนต์ และโทเค็นดีไซน์ของ Figma เป็นคำแนะนำในการนำไปใช้บนส่วนหน้า | การเข้าถึง Figma MCP และไฟล์ Figma, เฟรม หรือโหนดที่เลือก |

| จูปิเตอร์ โน้ตบุ๊ก | การวิเคราะห์ข้อมูลและการทดลอง | สร้างและจัดโครงสร้างโน้ตบุ๊กสำหรับการวิจัย การวิเคราะห์ บทช่วยสอน และเวิร์กโฟลว์ที่ทำซ้ำได้ | ชุดข้อมูล การทดลอง หรือเวิร์กโฟลว์การวิเคราะห์ |

| ซีแอลไอ ครีเอเตอร์ | เครื่องมือภายในที่นำกลับมาใช้ใหม่ได้ | สร้างเครื่องมือบรรทัดคำสั่งที่ทนทานสำหรับงานที่เกิดซ้ำ, API และระบบอัตโนมัติภายใน | เวิร์กโฟลว์ที่ซ้ำซากที่คุ้มค่าที่จะเปลี่ยนเป็นเครื่องมือที่ใช้ร่วมกัน |

| เวอร์เซล ดีพลอย | การดีพลอยตัวอย่างเพื่อส่งมอบ | เผยแพร่เว็บโปรเจกต์และสร้าง URL ตัวอย่างที่แชร์ได้สำหรับการทดสอบและข้อเสนอแนะ | เว็บโปรเจกต์ที่พร้อมดีพลอยและการเข้าถึง Vercel |

| โอเพนเอไอ ด็อกส์ | การสร้างด้วยผลิตภัณฑ์ของ OpenAI | ใช้เอกสารอย่างเป็นทางการของ OpenAI สำหรับ API, โมเดล, SDK, การย้ายข้อมูล และเวิร์กโฟลว์ของโคเด็กซ์ | งานพัฒนาที่เกี่ยวข้องกับ OpenAI |

### ตัวเลือกด่วนตามกรณีการใช้งาน

- **เริ่มต้นที่นี่หากความต้องการของคุณยังคลุมเครือ:**กำหนดเป้าหมาย
- **เริ่มต้นที่นี่หากเวิร์กโฟลว์ของ GitHub ทำให้คุณช้าลง:**gh-fix-ci หรือ gh-address-comments
- **เริ่มต้นที่นี่หากคุณสร้างผลิตภัณฑ์เว็บ:**Playwright และ Vercel Deploy
- **เริ่มต้นที่นี่หากคุณทำงานอย่างใกล้ชิดกับนักออกแบบ:**Figma Implement Design
- **เริ่มต้นที่นี่หากคุณวิเคราะห์ข้อมูลการวิจัยหรือธุรกิจ:**จูปิเตอร์ โน้ตบุ๊ก
- **เริ่มต้นที่นี่หากทีมของคุณทำงานแบบแมนนวลซ้ำๆ:**CLI Creator
- **เริ่มต้นที่นี่หากคุณกำลังสร้างฟีเจอร์ AI ด้วย OpenAI:**เอกสาร OpenAI
- **เริ่มต้นที่นี่หากคุณต้องการพฤติกรรมการพัฒนาที่ปลอดภัยยิ่งขึ้น:**แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย

ทางเลือกที่ดีที่สุดขึ้นอยู่กับว่าจุดไหนในเวิร์กโฟลว์ของคุณที่ช้าที่สุด หากคุณกำลังสร้างผลิตภัณฑ์ใหม่ ให้เริ่มด้วยทักษะการวางแผน การทดสอบ และการปรับใช้ หากคุณทำงานกับ GitHub ทุกวัน ให้ให้ความสำคัญกับ CI, pull request และเวิร์กโฟลว์ด้านความปลอดภัย หากงานของคุณเกี่ยวข้องกับข้อมูลการวิจัยหรือการเติบโต ทักษะการวิเคราะห์ข้อมูลและการจัดทำเอกสารอาจให้คุณค่ามากกว่า

## **ทักษะของ Codex Agent ที่ดีที่สุด: บทวิจารณ์โดยละเอียด**

### **เกณฑ์การประเมินของเรา**

เราประเมินทักษะของ Codex เหล่านี้ตามปัจจัยเชิงปฏิบัติห้าประการ:

- **ผลกระทบต่อเวิร์กโฟลว์:**ทักษะนี้ช่วยขจัดปัญหาคอขวดที่มีความหมายออกจากงานพัฒนาจริงหรือไม่?
- **ความยุ่งยากในการตั้งค่า:**ต้องมีการกำหนดค่า การตรวจสอบสิทธิ์ หรือเครื่องมือภายนอกมากน้อยเพียงใด?
- **การควบคุมและความปลอดภัย:**ทักษะนี้ช่วยให้ผู้ใช้ยังคงควบคุมได้ก่อนที่จะทำการเปลี่ยนแปลงโค้ดหรือการปรับใช้หรือไม่?
- **ความชัดเจนของขอบเขต:**มีความชัดเจนหรือไม่ว่าควรใช้ทักษะนี้เมื่อใด และไม่ควรใช้เมื่อใด?
- **ความสามารถในการนำกลับมาใช้ใหม่:**เวิร์กโฟลว์นี้สามารถช่วยในหลายโปรเจกต์ รีพอสิทอรี หรือทีมได้หรือไม่?

นี่คือการประเมินเชิงบรรณาธิการตามเวิร์กโฟลว์ที่จัดทำเป็นเอกสาร ข้อกำหนดเบื้องต้น และกรณีการใช้งานที่ตั้งใจไว้ของแต่ละทักษะ สิ่งเหล่านี้ไม่ใช่คะแนนมาตรฐานหรือการรับประกันคุณภาพผลลัพธ์

### **กำหนดเป้าหมาย: เหมาะที่สุดสำหรับเกณฑ์ความสำเร็จที่ชัดเจน**

![<img src="define goal" alt="the screenshot of define goal skill in GitHub">](https://file.nanoskill.ai/define-goal.png)

**สิ่งที่ทำ:**  
Define Goal ช่วยให้ Codex เปลี่ยนคำขอแบบกว้างๆ ให้เป็นคำจำกัดความของความสำเร็จที่ชัดเจนก่อนที่จะเริ่มการนำไปใช้ แทนที่จะปฏิบัติต่อคำขอเช่น “ปรับปรุงขั้นตอนการเริ่มต้นใช้งาน” เสมือนเป็นงานเขียนโค้ดทั่วไป แต่จะกระตุ้นให้ผู้ใช้และตัวแทนชี้แจงให้ชัดเจนว่าต้องเปลี่ยนแปลงอะไรบ้าง อะไรที่อยู่นอกขอบเขต ผลลัพธ์จะถูกทดสอบอย่างไร และเงื่อนไขใดที่บ่งชี้ว่างานเสร็จสมบูรณ์  
**ทำไมถึงโดดเด่น:**  
งานพัฒนาจำนวนมากที่น่าประหลาดใจล้มเหลวเพราะเป้าหมายไม่เคยถูกกำหนดไว้อย่างชัดเจน โค้ดอาจทำงานได้ แต่อาจแก้ปัญหาผิดปัญหา พลาดกรณีขอบที่สำคัญ หรือสร้างการแก้ไขอีกหลายรอบ Define Goal มอบจุดเริ่มต้นที่แข็งแกร่งยิ่งขึ้นให้กับ Codex โดยเปลี่ยนการสนทนาจากกิจกรรมที่คลุมเครือไปสู่ผลลัพธ์ที่วัดผลได้  
มีประโยชน์อย่างยิ่งเมื่องานเกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียหลายฝ่าย ข้อกำหนดผลิตภัณฑ์ที่ไม่ชัดเจน เป้าหมายด้านประสิทธิภาพ งานโยกย้าย หรือรายงานข้อบกพร่องที่ต้องแปลเป็นเกณฑ์การยอมรับที่ทดสอบได้ โดยการกำหนดเส้นชัยก่อนที่จะเริ่มเขียนโค้ด ทีมสามารถลดการไปๆ มาๆ ที่ไม่จำเป็นและให้ Codex มีแนวทางที่ชัดเจนยิ่งขึ้นสำหรับงานข้างหน้า  
**งานตัวอย่าง:**

“ปรับปรุงขั้นตอนการเริ่มต้นใช้งานสำหรับผู้ใช้ใหม่ กำหนดเป้าหมายที่วัดผลได้ ชี้แจงการกระทำของผู้ใช้เป้าหมาย ระบุสิ่งที่อยู่ในขอบเขตและนอกขอบเขต เสนอเกณฑ์การยอมรับ และอธิบายว่าควรตรวจสอบผลลัพธ์สุดท้ายอย่างไรก่อนที่จะเริ่มการนำไปใช้ใดๆ”  
**เหมาะสำหรับ:**  
ทีมผลิตภัณฑ์ นักพัฒนา และหัวหน้าฝ่ายเทคนิคที่จัดการกับคำขอฟีเจอร์ที่คลุมเครือ การแก้ไขข้อบกพร่อง งานโยกย้าย หรืองานที่อ่อนไหวต่อคุณภาพ

### **gh-fix-ci: เหมาะที่สุดสำหรับการแก้ไขการตรวจสอบ CI ที่ล้มเหลว**

![<img src="gh-fix-ci skill" alt="the screenshot of gh-fix-ci skill in GitHub">](https://file.nanoskill.ai/gh-fix-ci-skill.png)

**สิ่งที่ทำ:**  
gh-fix-ci ช่วยให้ Codex ตรวจสอบการตรวจสอบ GitHub Actions ที่ล้มเหลวบน pull request โดยสามารถตรวจสอบสถานะเวิร์กโฟลว์ ตรวจสอบบันทึกความล้มเหลว ระบุสาเหตุที่เป็นไปได้มากที่สุดของปัญหา และเสนอแผนการซ่อมแซมที่มุ่งเน้นก่อนที่จะทำการเปลี่ยนแปลง  
**ทำไมถึงโดดเด่น:**  
ความล้มเหลวของ CI เป็นหนึ่งในแหล่งที่มาของความยุ่งยากที่พบบ่อยที่สุดในการพัฒนาซอฟต์แวร์สมัยใหม่ นักพัฒนาอาจต้องสลับไปมาระหว่างบันทึกของ GitHub ผลลัพธ์การทดสอบในเครื่อง ไฟล์การพึ่งพา การเปลี่ยนแปลงของ pull request และการกำหนดค่าเวิร์กโฟลว์ เพียงเพื่อทำความเข้าใจว่าเหตุใดบิลด์จึงล้มเหลว gh-fix-ci มอบวิธีที่มีโครงสร้างให้ Codex ในการรวบรวมบริบทนั้นและจำกัดปัญหาให้แคบลง  
ทักษะนี้มีคุณค่าอย่างยิ่งเพราะมันแยกขั้นตอนการวินิจฉัยออกจากการนำไปใช้งาน แทนที่จะทำการเปลี่ยนแปลงอย่างกว้างขวางในทันที Codex สามารถอธิบายก่อนว่าอะไรล้มเหลว สาเหตุที่อาจเป็นไปได้ และควรตรวจสอบอะไรต่อไป สิ่งนี้ทำให้เวิร์กโฟลว์โปร่งใสขึ้นและให้เส้นทางที่เร็วขึ้นแก่ผู้พัฒนาจากสถานะ CI สีแดงไปยังการแก้ไขที่ยืนยันแล้ว

**งานตัวอย่าง:**

“ตรวจสอบการเช็ค GitHub Actions ที่ล้มเหลวใน pull request นี้ สรุปสาเหตุหลักที่น่าจะเป็นไปได้ ระบุไฟล์หรือขั้นตอนของเวิร์กโฟลว์ที่ได้รับผลกระทบ และเสนอแผนการซ่อมแซมที่ปลอดภัยน้อยที่สุดก่อนที่จะทำการเปลี่ยนแปลงโค้ดใดๆ”  
**เหมาะที่สุดสำหรับ:**  
ทีมที่ใช้ GitHub Actions สำหรับการทดสอบ การสร้าง การตรวจสอบรูปแบบ การตรวจสอบชนิดข้อมูล และการตรวจสอบ pull request

### **gh-address-comments: เหมาะที่สุดสำหรับข้อเสนอแนะในการตรวจสอบ PR**

![<img src="gh-address-comments skill" alt="the screenshot of gh-address-comments skill in GitHub">](https://file.nanoskill.ai/gh-address-comments-skill.png)

**สิ่งที่มันทำ:**  
gh-address-comments ช่วยให้ Codex รวบรวมและจัดระเบียบข้อเสนอแนะจากการตรวจสอบ pull request มันสามารถระบุหัวข้อการตรวจสอบ สรุปสิ่งที่แต่ละความคิดเห็นต้องการ จัดกลุ่มคำขอที่เกี่ยวข้อง และช่วยให้ผู้ใช้ตัดสินใจว่าความคิดเห็นใดควรนำไปสู่การเปลี่ยนแปลงโค้ด  
**เหตุผลที่มันโดดเด่น:**  
การตรวจสอบโค้ดมักไม่ยากเพราะความคิดเห็นเดียว มันกลายเป็นเรื่องใช้เวลามากเมื่อข้อเสนอแนะกระจัดกระจายไปทั่วผู้ตรวจสอบหลายคน ไฟล์ หัวข้อ และการสนทนาติดตามผล ผู้พัฒนามักต้องอ่านความคิดเห็นซ้ำด้วยตนเอง ตัดสินใจว่าข้อไหนต้องดำเนินการ เข้าใจเจตนาเบื้องหลังคำขอแต่ละข้อ และติดตามว่าอะไรได้รับการจัดการแล้ว  
ทักษะนี้เปลี่ยนกระบวนการที่กระจัดกระจายให้เป็นเวิร์กโฟลว์ที่จัดการได้ง่ายขึ้น แทนที่จะปฏิบัติต่อทุกความคิดเห็นว่ามีความเร่งด่วนเท่ากัน Codex สามารถช่วยสรุปข้อเสนอแนะ นำเสนอรายการที่ต้องดำเนินการ และทำให้กระบวนการแก้ไขมีความรอบคอบมากขึ้น มันมีประโยชน์อย่างยิ่งสำหรับ pull request ขนาดใหญ่ ทีมที่ทำงานอย่างรวดเร็ว และผู้พัฒนาที่ต้องการลดการสลับบริบทไปพร้อมกับยังคงตอบสนองต่อข้อเสนอแนะของผู้ตรวจสอบอย่างระมัดระวัง

**งานตัวอย่าง:**

“ตรวจสอบความคิดเห็นที่ยังไม่ได้แก้ไขทั้งหมดใน pull request ปัจจุบัน จัดกลุ่มข้อเสนอแนะที่เกี่ยวข้องกัน สรุปสิ่งที่ผู้ตรวจสอบแต่ละคนกำลังขอ ระบุว่าความคิดเห็นใดจำเป็นต้องเปลี่ยนแปลงโค้ด และขอให้ฉันยืนยันรายการที่คุณควรจัดการก่อนที่จะแก้ไข branch”

**เหมาะที่สุดสำหรับ:**  
ผู้พัฒนาที่ทำงานใน GitHub repositories แบบทำงานร่วมกันที่มี pull requests บ่อยครั้งและข้อเสนอแนะจากผู้ตรวจสอบหลายคน

### **Playwright: เหมาะที่สุดสำหรับการทดสอบเบราว์เซอร์และการดีบัก UI**

![<img src="playwright skill" alt="the screenshot of playwright skill in GitHub">](https://file.nanoskill.ai/playwright-skill)

**สิ่งที่มันทำ:**  
Playwright ให้ความสามารถแก่ Codex ในการโต้ตอบกับเบราว์เซอร์จริงจากเทอร์มินัล มันสามารถเปิดหน้า นำทางผ่านขั้นตอนของผู้ใช้ กรอกแบบฟอร์ม คลิกปุ่ม ตรวจสอบสถานะของหน้า จับภาพหน้าจอ และช่วยสร้างปัญหาอินเทอร์เฟซที่ยากต่อการเข้าใจจากโค้ดเพียงอย่างเดียว  
**เหตุผลที่มันโดดเด่น:**  
ฟีเจอร์อาจผ่านการทดสอบหน่วยได้แต่ยังล้มเหลวในประสบการณ์ผลิตภัณฑ์จริง แบบฟอร์มอาจส่งข้อมูลไม่ถูกต้อง โมดัลอาจไม่ปิด ปุ่มอาจถูกซ่อนบนหน้าจอขนาดเล็ก หรือหน้าอาจพังหลังจากลำดับการคลิกที่เฉพาะเจาะจงเท่านั้น เหล่านี้คือปัญหาที่เห็นได้ชัดเมื่อมีคนโต้ตอบกับผลิตภัณฑ์เหมือนผู้ใช้  
Playwright ช่วยให้ Codex ก้าวข้ามการให้เหตุผลในระดับ repository และตรวจสอบพฤติกรรมที่มองเห็นได้ในสภาพแวดล้อมเบราว์เซอร์จริง นั่นทำให้มันมีคุณค่าสำหรับการดีบัก UI ที่ถดถอย การตรวจสอบขั้นตอนการเริ่มต้นใช้งาน การตรวจสอบการชำระเงินหรือเส้นทางการลงทะเบียน และยืนยันว่าฟีเจอร์ทำงานจากมุมมองของผู้ใช้ ไม่ใช่แค่ในโค้ด

**งานตัวอย่าง:**

“รันแอปพลิเคชันในเครื่องและทดสอบขั้นตอนการลงทะเบียนในเบราว์เซอร์จริง สร้างบัญชีทดสอบ กรอกข้อมูลในฟิลด์ที่จำเป็น ตรวจสอบว่าหน้าจอยืนยันปรากฏขึ้น และจับภาพหน้าจอและร่องรอยหากขั้นตอนใดล้มเหลว”

**เหมาะที่สุดสำหรับ:**  
ผู้พัฒนาฟรอนต์เอนด์ ทีม SaaS เวิร์กโฟลว์ QA และใครก็ตามที่สร้างผลิตภัณฑ์บนเบราว์เซอร์

### **แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย: เหมาะที่สุดสำหรับการเขียนโค้ดที่ปลอดภัยโดยค่าเริ่มต้น**

![<img src="security best practices" alt="the screenshot of security best practices in GitHub">](https://file.nanoskill.ai/security-best-practices)

**สิ่งที่มันทำ:**  
แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยช่วยให้ Codex ตรวจสอบโค้ดเพื่อหาความเสี่ยงด้านความปลอดภัยทั่วไปและแนะนำรูปแบบการนำไปใช้ที่ปลอดภัยกว่า มันสามารถแนะนำให้ agent คิดอย่างรอบคอบมากขึ้นเกี่ยวกับการตรวจสอบอินพุต การจัดการความลับ การตรวจสอบสิทธิ์ การอนุญาต ค่าเริ่มต้นที่ไม่ปลอดภัย และช่องโหว่ระดับแอปพลิเคชันทั่วไป  
**เหตุผลที่มันโดดเด่น:**  
ปัญหาด้านความปลอดภัยมักเริ่มต้นจากการตัดสินใจในกระบวนการพัฒนาที่ดูปกติ: การตรวจสอบสิทธิ์ที่ขาดหายไป, การเปิดเผยตัวแปรสภาพแวดล้อม, การตรวจสอบอินพุตที่ไม่เข้มงวด, กฎการอนุญาตที่กว้างเกินไป, หรือการจัดการข้อมูลผู้ใช้ที่ไม่ปลอดภัย ปัญหาเหล่านี้มองข้ามได้ง่ายเมื่อทีมมุ่งเน้นที่จะส่งมอบฟีเจอร์อย่างรวดเร็ว  
ทักษะนี้ช่วยนำความคิดด้านความปลอดภัยเข้าสู่กระบวนการพัฒนาเร็วขึ้น แทนที่จะมองว่าความปลอดภัยเป็นเพียงรายการตรวจสอบขั้นตอนสุดท้าย Codex สามารถใช้รูปแบบการพัฒนาที่ปลอดภัยกว่าในขณะที่กำลังเขียนหรือตรวจทานโค้ด มันมีประโยชน์อย่างยิ่งสำหรับทีมขนาดเล็กที่ไม่มีวิศวกรความปลอดภัยโดยเฉพาะมาคอยตรวจสอบทุก Pull Request แต่ยังต้องการนิสัยที่แข็งแกร่งขึ้นในการพัฒนาแบบปลอดภัยโดยปริยาย

**ตัวอย่างงาน:**

“ตรวจสอบขั้นตอนการยืนยันตัวตนและการอัปเดตโปรไฟล์ผู้ใช้ในแอปพลิเคชันนี้เพื่อหาความเสี่ยงด้านความปลอดภัยทั่วไป ตรวจสอบการตรวจสอบอินพุต, การอนุญาต, การจัดการความลับ, การจัดการเซสชัน, และค่าเริ่มต้นที่ไม่ปลอดภัย แนะนำการเปลี่ยนแปลงให้ปลอดภัยโดยปริยายพร้อมตัวอย่างในระดับโค้ด”

**เหมาะสำหรับ:**  
สตาร์ทอัป, นักพัฒนา Full-stack, ผู้สร้าง API, และทีมที่ทำงานกับแอปพลิเคชันที่ติดต่อกับลูกค้า

### **Figma Implement Design: เหมาะสำหรับเวิร์กโฟลว์จาก Figma สู่โค้ด**

![<img src="figma implement design" alt="the screenshot of figma implement design in GitHub">](https://file.nanoskill.ai/figma-implement-design)

**มันทำอะไร:**  
Figma Implement Design ช่วยให้ Codex แปลงคอมโพเนนต์, หน้าจอ, เลย์เอาต์, ดีไซน์โทเคน, และการอ้างอิงภาพจาก Figma เป็นโค้ดฟร้อนท์เอนด์ที่พร้อมใช้งาน มันให้บริบทการออกแบบที่มีโครงสร้างแก่เอเจนต์เพื่อให้การตัดสินใจในการพัฒนาโค้ดอิงจากการออกแบบจริงมากกว่าการตีความภาพคร่าวๆ  
**ทำไมมันถึงโดดเด่น:**  
การส่งมอบดีไซน์เป็นหนึ่งในแหล่งความขัดแย้งที่ใหญ่ที่สุดระหว่างการออกแบบผลิตภัณฑ์และการพัฒนาฟร้อนท์เอนด์ นักพัฒนาจำเป็นต้องเข้าใจระยะห่าง, ตัวอักษร, พฤติกรรมที่ตอบสนอง, การใช้ไอคอน, คอมโพเนนต์, สถานะ, และธรรมเนียมของระบบดีไซน์ที่มีอยู่ หากไม่มีบริบทที่ชัดเจน การพัฒนาอาจเบี่ยงเบนไปจากการออกแบบที่ตั้งใจหรือทำให้เกิดรูปแบบ UI ที่ไม่สอดคล้องกัน  
ทักษะนี้ทำให้การส่งมอบเป็นระบบมากขึ้น มันกระตุ้นให้ Codex นำคอมโพเนนต์และดีไซน์โทเคนที่มีอยู่กลับมาใช้ใหม่เมื่อเป็นไปได้, ทำตามรูปแบบภาพอย่างใกล้ชิดยิ่งขึ้น, และตรวจสอบผลลัพธ์สุดท้ายเทียบกับการออกแบบต้นฉบับ สำหรับทีมที่ทำงานใน Figma ทุกวัน สิ่งนี้สามารถลดระยะทางจากการอนุมัติดีไซน์ไปสู่การพัฒนาที่ประณีตและสอดคล้องกันมากขึ้น

**ตัวอย่างงาน:**

“ใช้เฟรม Figma ที่เลือกเพื่อพัฒนาหน้าแดชบอร์ดนี้ในโปรเจกต์ฟร้อนท์เอนด์ที่มีอยู่ ใช้ไลบรารีคอมโพเนนต์และดีไซน์โทเคนปัจจุบันซ้ำเมื่อเป็นไปได้, จับคู่เลย์เอาต์และตัวอักษรให้ใกล้เคียง, รองรับพฤติกรรมที่ตอบสนอง, และเปรียบเทียบหน้าสุดท้ายกับดีไซน์ Figma”

**เหมาะสำหรับ:**  
ทีมผลิตภัณฑ์, นักพัฒนาฟร้อนท์เอนด์, และนักออกแบบที่ทำงานกับระบบดีไซน์ที่ใช้ Figma

### **Jupyter Notebook: เหมาะสำหรับการวิเคราะห์ข้อมูลและการทดลอง**

![<img src="jupyter notebook" alt="the screenshot of jupyter notebook in GitHub">](https://file.nanoskill.ai/jupyter-notebook)

**มันทำอะไร:**  
Jupyter Notebook ช่วยให้ Codex สร้าง, แก้ไข, จัดระเบียบ, และรีแฟกเตอร์สมุดโน้ตสำหรับการวิเคราะห์ข้อมูล, การทดลอง, บทเรียนสอน, และเวิร์กโฟลว์การวิจัยที่ทำซ้ำได้ มันสามารถรองรับโครงสร้างสมุดโน้ตที่ชัดเจนขึ้นด้วยคำอธิบาย Markdown ที่อ่านได้, เซลล์โค้ดที่มีตรรกะ, และขั้นตอนการวิเคราะห์ที่ตั้งใจมากขึ้น  
**ทำไมมันถึงโดดเด่น:**  
สมุดโน้ตไม่ได้มีประโยชน์เพียงเพราะมันทำงานได้ สมุดโน้ตที่ดีควรทำให้คนอื่นเข้าใจ, ทำซ้ำ, และต่อยอดได้ง่าย ในทางปฏิบัติ สมุดโน้ตจำนวนมากกลายเป็นสิ่งที่ติดตามยากเพราะโค้ด, โน้ต, การทดลองชั่วคราว, และผลลัพธ์ถูกปะปนกันโดยไม่มีโครงสร้างที่ชัดเจน  
ทักษะนี้ช่วยให้ Codex สร้างสมุดโน้ตที่เป็นมากกว่ากระดาษทดแบบใช้แล้วทิ้ง มันสามารถรองรับการวิเคราะห์เชิงสำรวจที่สะอาดขึ้น, การทดลองที่เข้าใจได้มากขึ้น, และสมุดโน้ตแบบบทเรียนที่ดีขึ้นสำหรับการสอนหรือการแบ่งปัน สิ่งนี้ทำให้มันมีค่าสำหรับนักวิจัย, นักวิเคราะห์, ทีมด้านการเติบโต, และใครก็ตามที่ต้องการเปลี่ยนงานข้อมูลให้เป็นสิ่งประดิษฐ์ที่นำกลับมาใช้ใหม่ได้แทนที่จะเป็นสคริปต์ที่ใช้ครั้งเดียว

**ตัวอย่างงาน:**

“สร้างสมุดโน้ต Jupyter ที่สะอาดเพื่อวิเคราะห์ชุดข้อมูล CSV นี้ รวมถึงการทำความสะอาดข้อมูล, สถิติเชิงพรรณา, การสร้างภาพ, ข้อค้นพบสำคัญ, และคำอธิบาย Markdown สำหรับแต่ละขั้นตอน จัดโครงสร้างสมุดโน้ตเพื่อให้นักวิจัยคนอื่นสามารถรันมันจากบนลงล่างได้”

**เหมาะสำหรับ:**  
นักวิจัย, นักวิเคราะห์, นักการศึกษา, ผู้ปฏิบัติงานด้านแมชชีนเลิร์นนิง, และทีมที่ทำงานกับชุดข้อมูลที่มีโครงสร้างหรือการทดลอง

### **CLI Creator: เหมาะที่สุดสำหรับเครื่องมือภายในที่นำกลับมาใช้ซ้ำได้**

![<img src="cli creator" alt="the screenshot of cli creator in GitHub">](https://file.nanoskill.ai/cli-creator)

**มันทำอะไร:**  
CLI Creator ช่วยให้ Codex สร้างเครื่องมือ command-line ที่คงทนสำหรับเวิร์กโฟลว์ที่เกิดซ้ำๆ เครื่องมือเหล่านี้สามารถสนับสนุนการโต้ตอบกับ API, การทำงานอัตโนมัติในเครื่อง, การดำเนินการภายใน, การเรียกข้อมูล, งานด้านบริหารจัดการ, และการกระทำที่ทำซ้ำได้ ซึ่งมิฉะนั้นจะต้องใช้การทำงานผ่านเบราว์เซอร์ด้วยตนเองหรือสคริปต์ที่ใช้ครั้งเดียว  
**ทำไมมันถึงโดดเด่น:**  
หลายๆ ทีมทำงานซ้ำๆ เดิมๆ: ตรวจสอบบันทึก, ส่งออกข้อมูล, อัปโหลดไฟล์, สอบถามระบบภายใน, ซิงค์ข้อมูล, หรือกระตุ้นการดำเนินการที่ปลอดภัย ในตอนแรก งานเหล่านี้มักถูกจัดการผ่านสคริปต์เฉพาะกิจหรือชุดขั้นตอนที่ไม่มีเอกสาร เมื่อเวลาผ่านไป สิ่งนี้ก่อให้เกิดความขัดแย้ง, ความไม่สม่ำเสมอ, และการพึ่งพาสมาชิกในทีมแต่ละคนโดยไม่จำเป็น  
CLI Creator ช่วยเปลี่ยนงานที่ทำซ้ำๆ ให้เป็นผลิตภัณฑ์ภายในที่เรียบร้อยยิ่งขึ้น แทนที่จะแก้ไขปัญหาเดิมทุกสัปดาห์ ทีมสามารถสร้างอินเทอร์เฟซ command-line ที่ใช้ซ้ำได้ พร้อมคำสั่งที่ชัดเจนขึ้น, ผลลัพธ์ที่คาดเดาได้, การจัดการการตรวจสอบสิทธิ์ที่ปลอดภัยยิ่งขึ้น, และเอกสารที่ผู้อื่นสามารถปฏิบัติตามได้ นี่เป็นหนึ่งในทักษะที่แข็งแกร่งที่สุดในการเปลี่ยน Codex จากผู้ช่วยชั่วคราวเป็นพันธมิตรในการสร้างเครื่องมือ

**งานตัวอย่าง:**

“สร้างเครื่องมือ CLI ที่ใช้ซ้ำได้ซึ่งดึงข้อมูลบันทึกของลูกค้าจาก API ภายในของเราด้วยที่อยู่อีเมล รวมคำสั่งที่ชัดเจน, ข้อความช่วยเหลือ, ผลลัพธ์ JSON, การตรวจสอบสิทธิ์โดยใช้ environment variable, การจัดการข้อผิดพลาด, และ`--dry-run`โหมดสำหรับการดำเนินการเขียนใดๆ”

**เหมาะที่สุดสำหรับ:**  
ทีมวิศวกรรม, ทีมแพลตฟอร์ม, ทีมปฏิบัติการ, และนักพัฒนาที่มีเวิร์กโฟลว์ภายในที่เกิดซ้ำ

### **Vercel Deploy: เหมาะที่สุดสำหรับการส่ง Deployments แบบแสดงตัวอย่าง**

![<img src="vercel deploy skill" alt="vercel deploy skill">](https://file.nanoskill.ai/vercel-deploy-skill)

**มันทำอะไร:**  
Vercel Deploy ช่วยให้ Codex เผยแพร่โปรเจกต์เว็บไปยัง Vercel และสร้าง Deployment แบบแสดงตัวอย่างที่แชร์ได้ สิ่งนี้ช่วยให้ผู้ใช้มี URL ที่ใช้งานได้จริงซึ่งสามารถเปิด, ตรวจสอบ, ทดสอบ, และแชร์ได้ก่อนที่โปรเจกต์จะถูกปล่อยสู่การใช้งานจริง  
**ทำไมมันถึงโดดเด่น:**  
โปรเจกต์จะง่ายต่อการประเมินเมื่อผู้คนสามารถโต้ตอบกับมันในเบราว์เซอร์ การพัฒนาในเครื่องมีประโยชน์สำหรับการสร้าง แต่ Deployments แบบแสดงตัวอย่างคือสิ่งที่ช่วยให้เพื่อนร่วมทีม, ลูกค้า, นักออกแบบ, ผู้มีส่วนได้ส่วนเสีย, และผู้ใช้ยุคแรกเห็นผลลัพธ์ในบริบท  
สกิลนี้ช่วยย่นระยะทางระหว่าง “โค้ดทำงานบนเครื่องของฉัน” และ “คนอื่นสามารถทดสอบได้” ซึ่งทำให้มันมีประโยชน์อย่างยิ่งสำหรับพอร์ตโฟลิโอ, หน้าแลนดิ้ง, ต้นแบบ, แดชบอร์ดภายใน, MVP, และการทดลอง SaaS ในระยะแรก นอกจากนี้ยังสนับสนุนจังหวะการปล่อยที่ปลอดภัยยิ่งขึ้นด้วยการมุ่งเน้นที่ Deployments แบบแสดงตัวอย่าง ซึ่งทีมสามารถรวบรวมข้อเสนอแนะและตรวจพบปัญหาก่อนที่จะก้าวไปสู่การเปิดตัวเต็มรูปแบบ

**งานตัวอย่าง:**

“Deploy โปรเจกต์เว็บปัจจุบันไปยัง Vercel เป็น Deployment แบบแสดงตัวอย่าง ตรวจสอบว่าการ Build สำเร็จ, ส่งคืน URL แสดงตัวอย่าง, และอย่าสร้างหรือแก้ไข Deployment สำหรับการใช้งานจริง”

**เหมาะที่สุดสำหรับ:**  
นักพัฒนา Indie, นักเรียน, ทีมสตาร์ทอัพ, นักพัฒนาผลิตภัณฑ์, และใครก็ตามที่ต้องการลิงก์แสดงตัวอย่างที่แชร์ได้อย่างรวดเร็ว

### **OpenAI Docs: เหมาะที่สุดสำหรับการสร้างด้วยผลิตภัณฑ์ OpenAI**

![<img src="openai docs" alt="openai docs">](https://file.nanoskill.ai/openai-docs)

**มันทำอะไร:**  
OpenAI Docs ช่วยให้ Codex ใช้เอกสารอย่างเป็นทางการของ OpenAI เมื่อทำงานกับ OpenAI APIs, โมเดล, SDKs, การย้ายระบบ, Agents, และเวิร์กโฟลว์ที่เกี่ยวข้องกับ Codex มันสนับสนุนการตัดสินใจในการนำไปใช้ที่อิงตามเอกสารจากแหล่งโดยตรงที่เป็นปัจจุบัน แทนที่จะเป็นบทแนะนำที่ล้าสมัยหรือตัวอย่างที่ไม่เป็นทางการ  
**ทำไมมันถึงโดดเด่น:**  
การพัฒนา AI เปลี่ยนแปลงอย่างรวดเร็ว ความสามารถของโมเดล, พารามิเตอร์ของ API, รูปแบบ SDK, คำแนะนำในการย้ายระบบ, และคำแนะนำผลิตภัณฑ์สามารถพัฒนาได้เร็วกว่าที่บทแนะนำจากบุคคลที่สามจำนวนมากจะถูกอัปเดต สิ่งนี้ก่อให้เกิดความเสี่ยงที่แท้จริงสำหรับนักพัฒนาที่คัดลอกตัวอย่างจากบล็อกโพสต์เก่าๆ หรือส่วนย่อยจากชุมชนโดยไม่ได้ตรวจสอบว่าข้อมูลนั้นยังเป็นปัจจุบันอยู่หรือไม่  
สกิลนี้ช่วยให้ Codex มีแหล่งข้อมูลที่เชื่อถือได้มากขึ้นเมื่อทำงานกับผลิตภัณฑ์ของ OpenAI มันมีประโยชน์อย่างยิ่งสำหรับคำถามเกี่ยวกับการนำไปใช้งานที่ขึ้นอยู่กับเอกสารปัจจุบัน เช่น การเลือกแพทเทิร์น API ที่ถูกต้อง การทำความเข้าใจฟีเจอร์ที่รองรับ การจัดการกับการเปลี่ยนแปลงการย้ายข้อมูล หรือการปฏิบัติตามแนวทางล่าสุดสำหรับเวิร์กโฟลว์ของ Codex และเอเจนต์

**งานตัวอย่าง:**

“โดยใช้เฉพาะเอกสารอย่างเป็นทางการของ OpenAI แนะนำแนวทางการนำไปใช้งานที่ดีที่สุดในปัจจุบันสำหรับการเพิ่มฟีเจอร์ถาม-ตอบข้อมูลจากเอกสารให้กับแอปพลิเคชันนี้ เปรียบเทียบตัวเลือก API ที่เกี่ยวข้อง ระบุขั้นตอนการตั้งค่าที่จำเป็น อธิบายพารามิเตอร์สำคัญ และให้ตัวอย่าง TypeScript แบบย่อ”

**เหมาะสำหรับ:**  
นักพัฒนาที่กำลังสร้างด้วย OpenAI APIs, โมเดล OpenAI, เอเจนต์, Codex หรือฟีเจอร์ผลิตภัณฑ์ที่ขับเคลื่อนด้วย AI

## **ตัวอย่างเวิร์กโฟลว์ของสกิล Codex**

การประเมินสกิลของเอเจนต์ทำได้ง่ายขึ้นเมื่อคุณเห็นว่ามันเปลี่ยนแปลงงานจริงอย่างไร แทนที่จะแสดงรายการฟีเจอร์เท่านั้น ตัวอย่างต่อไปนี้แสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อ Codex ได้รับคำขอผลิตภัณฑ์ที่คลุมเครือและใช้สกิลที่มีโครงสร้างเพื่อเปลี่ยนให้เป็นผลลัพธ์ที่ชัดเจนและตรวจสอบได้มากขึ้น

### **เวิร์กโฟลว์ที่ 1: เปลี่ยน “ปรับปรุงการเริ่มต้นใช้งาน” ให้เป็นเป้าหมายผลิตภัณฑ์ที่วัดผลได้**

**สถานการณ์:**

ทีม SaaS สังเกตว่าผู้ใช้ใหม่หลายคนสร้างบัญชีแต่จากไปก่อนตั้งค่าพื้นที่ทำงานเสร็จ คำขอเริ่มต้นง่าย ๆ: “ปรับปรุงขั้นตอนการเริ่มต้นใช้งาน” อย่างไรก็ตาม คำขอไม่ได้กำหนดเมตริกเป้าหมาย กำหนดเวลา ขอบเขต หรือวิธีที่ชัดเจนในการพิสูจน์ว่างานสำเร็จ

**สกิลที่ใช้:**

กำหนดเป้าหมาย

**พรอมต์ที่ใช้:**

“ปรับปรุงขั้นตอนการเริ่มต้นใช้งานสำหรับผู้ใช้ใหม่ กำหนดเป้าหมายที่วัดผลได้ ชี้แจงการกระทำของผู้ใช้เป้าหมาย ระบุสิ่งที่อยู่ในขอบเขตและนอกขอบเขต เสนอเกณฑ์การยอมรับ และอธิบายว่าควรตรวจสอบผลลัพธ์สุดท้ายอย่างไรก่อนเริ่มการนำไปใช้งานใด ๆ”

แทนที่จะเสนอแนะการเปลี่ยนแปลง UI หรือเขียนโค้ดทันที Codex ได้ปรับเปลี่ยนคำขอให้เป็นวัตถุประสงค์ของผลิตภัณฑ์ก่อน มันกำหนดเป้าหมาย 30 วัน กำหนดเมตริกพื้นฐาน ตั้งเกณฑ์ความสำเร็จที่วัดผลได้ และระบุหลักฐานที่จำเป็นเพื่อตรวจสอบว่างานดังกล่าวปรับปรุงประสบการณ์การเริ่มต้นใช้งานจริงหรือไม่

![<img src="define goal sample1" alt="the screenshot of define goal outcome ">](https://file.nanoskill.ai/define-goal-sample1)

คำขอเดิมไม่มีคำจำกัดความของความสำเร็จที่วัดผลได้ หลังจากใช้กำหนดเป้าหมาย Codex แปลงเป็นผลลัพธ์เฉพาะ: เพิ่มอัตราการเริ่มต้นใช้งานเสร็จสมบูรณ์จาก 42% เป็นอย่างน้อย 55% พร้อมลดเวลาเฉลี่ยในการทำเสร็จจาก 6 นาที 30 วินาที เหลือ 5 นาทีหรือน้อยกว่า

นี่คือคุณค่าหลักของสกิล มันย้ายงานจาก “ทำให้ดีขึ้น” ไปสู่เป้าหมายที่สามารถทดสอบ วัดผล และทบทวนได้หลังจากเปิดตัว

Codex ยังเพิ่มองค์ประกอบสี่อย่างที่มักขาดหายไปจากคำขอที่กำหนดไว้หลวม ๆ:

- **เกณฑ์ความสำเร็จที่ชัดเจน:**สิ่งที่ทีมต้องทำให้สำเร็จก่อนที่งานจะถือว่าประสบความสำเร็จ
- **ขอบเขตที่กำหนด:**ส่วนไหนของประสบการณ์การเริ่มต้นใช้งานที่ควรปรับปรุงก่อน
- **หลักฐานการตรวจสอบ:**การวิเคราะห์หลังการเปิดตัวที่จำเป็นเพื่อยืนยันผลลัพธ์
- **เงื่อนไขหยุดและถาม:**สถานการณ์ที่ Codex ควรขอคำชี้แจงแทนที่จะคาดเดา

![<img src="define goal sample2" alt="the screenshot of define goal outcome ">](https://file.nanoskill.ai/define-goal-sample2)

ส่วนสำคัญของเวิร์กโฟลว์นี้คือ Codex ไม่ได้ทำเครื่องหมายว่าเป้าหมายเสร็จสมบูรณ์ มันระบุอย่างถูกต้องว่าเป้าหมายยังคงถูกบล็อกอยู่จนกว่าสองสิ่งจะเกิดขึ้น: ขั้นตอนการเริ่มต้นใช้งานที่ปรับปรุงแล้วถูกเปิดตัว และการวิเคราะห์หลังการเปิดตัวยืนยันเมตริกเป้าหมายโดยใช้คำจำกัดความเหตุการณ์พื้นฐานเดียวกัน

ความแตกต่างนั้นสำคัญ สกิลสามารถกำหนดวัตถุประสงค์ เตรียมแผนการตรวจสอบ และสร้างเอกสารสนับสนุนได้ แต่ไม่ควรอ้างว่าสำเร็จโดยไม่มีหลักฐานจากโลกแห่งความจริง

**เหตุใดเวิร์กโฟลว์นี้จึงสำคัญ:**

กำหนดเป้าหมายมีประโยชน์มากที่สุดเมื่องานเริ่มต้นด้วยคำขอที่คลุมเครือ มีผู้มีส่วนได้ส่วนเสียหลายราย หรือเกณฑ์ความสำเร็จที่ไม่ชัดเจน มันให้จุดเริ่มต้นที่มีระเบียบวินัยมากขึ้นแก่ Codex และช่วยให้ทีมตกลงกันว่า “เสร็จ” จริง ๆ แล้วหมายถึงอะไรก่อนเริ่มการนำไปใช้งาน

### **เวิร์กโฟลว์ที่ 2: จากการตรวจสอบ CI ที่ล้มเหลวไปสู่แผนการซ่อมแซมที่มุ่งเน้น**

**สถานการณ์:**

หลังจากเปลี่ยนแปลงโค้ดเล็กน้อย Pull Request ไม่ผ่านการตรวจสอบการทดสอบอัตโนมัติ นักพัฒนาสามารถเห็นว่าสถานะ CI เป็นสีแดง แต่ยังคงต้องระบุว่าอะไรที่ล้มเหลวจริงๆ ปัญหามาจากโค้ดหรือการทดสอบ และการแก้ไขที่ปลอดภัยที่สุดน้อยที่สุดควรเป็นอย่างไร

ในตัวอย่างนี้ การทดสอบที่ล้มเหลวคาดว่าฟังก์ชัน add(2, 2) จะคืนค่า 5 ในขณะที่ผลลัพธ์จริงคือ`4`. คำถามสำคัญไม่ใช่แค่วิธีทำให้การตรวจสอบผ่าน แต่คือการใช้งานผิดหรือไม่ ความคาดหวังในการทดสอบผิดหรือไม่ หรือความล้มเหลวชี้ไปยังปัญหาที่กว้างขึ้น

**ทักษะที่ใช้:**

จีเอช-ฟิกซ์-ซีไอ

**ตัวอย่างพรอมต์:**

“ตรวจสอบการตรวจสอบ GitHub Actions ที่ล้มเหลวสำหรับ Pull Request บน branch ปัจจุบัน สรุปบริบทของความล้มเหลว ระบุสาเหตุที่อาจเป็นไปได้ และเสนอแผนการซ่อมแซมที่ปลอดภัยที่สุดน้อยที่สุด ห้ามแก้ไขโค้ดหรือรันเวิร์กโฟลว์ใหม่จนกว่าฉันจะอนุมัติแผนอย่างชัดเจน”

แทนที่จะเปลี่ยนโค้ดทันที จีเอช-ฟิกซ์-ซีไอ จัดโครงสร้างงานเป็นเวิร์กโฟลว์การวินิจฉัยที่ควบคุมได้ โคเด็กซ์ ตรวจสอบการตรวจสอบที่ล้มเหลวและบริบทที่มีอยู่ก่อน ระบุสาเหตุที่อาจเป็นไปได้ของความล้มเหลว และเสนอแผนการซ่อมแซมขั้นต่ำ หลังจากผู้ใช้ยืนยันแผนแล้วเท่านั้น โคเด็กซ์ จึงควรทำการเปลี่ยนแปลง รันการทดสอบที่เกี่ยวข้อง และตรวจสอบว่า Pull Request ผ่าน

![<img src="gh fix ci sample" alt="the screenshot of gh fix ci sample ">](https://file.nanoskill.ai/gh-fix-ci-sample)

_รูปที่ 3. เวิร์กโฟลว์ตัวอย่างที่อิงจากทักษะ จีเอช-ฟิกซ์-ซีไอ: โคเด็กซ์ ย้ายจากการตรวจสอบ GitHub Actions ที่ล้มเหลวไปยังแผนการซ่อมแซมที่มุ่งเน้นและสามารถตรวจสอบได้_

ในตัวอย่างนี้ สัญญาณความล้มเหลวชัดเจน โคเด็กซ์ จะใช้บริบทของความล้มเหลวนั้นเพื่อแยกแยะระหว่างการใช้งานที่ไม่ถูกต้องและการทดสอบที่ไม่ถูกต้อง ในที่นี้ ฟังก์ชัน add ที่คืนค่า 4 ถูกต้อง สาเหตุหลักคือความคาดหวังของการทดสอบ ซึ่งคาดว่าผลลัพธ์เป็น 5 อย่างไม่ถูกต้อง

แผนการซ่อมแซมที่ได้นั้นเรียบง่ายอย่างจงใจ:

1. เปลี่ยนค่าที่คาดหวังในการทดสอบจาก 5 เป็น 4
2. รันการทดสอบที่เกี่ยวข้องในเครื่อง
3. push การเปลี่ยนแปลงที่อนุมัติแล้วและตรวจสอบสถานะ Pull Request อีกครั้ง

ขั้นตอนที่สำคัญที่สุดคือ**ขั้นตอนการอนุมัติ**. จีเอช-ฟิกซ์-ซีไอ ไม่ได้ถูกออกแบบมาเพื่อปฏิบัติต่อการตรวจสอบที่ล้มเหลวทุกครั้งว่าเป็นสิทธิ์ในการแก้ไขโค้ดโดยอัตโนมัติ มันแยกการวินิจฉัยออกจากการดำเนินการ: โคเด็กซ์ อธิบายปัญหาที่มีแนวโน้มเป็นไปได้ นำเสนอแผนการซ่อมแซมที่มุ่งเน้น และรอการอนุมัติจากผู้ใช้อย่างชัดเจนก่อนที่จะแก้ไข branch

หลังจากอนุมัติ สถานะสุดท้ายที่คาดหวังนั้นตรงไปตรงมา: การทดสอบที่แก้ไขแล้วผ่านในเครื่อง และ Pull Request ตรวจสอบให้ผลเป็นสีเขียว

เวิร์กโฟลว์นี้มีประโยชน์เพราะทำให้การซ่อมแซม CI โปร่งใสมากขึ้นและตอบสนองน้อยลง แทนที่จะขอให้ โคเด็กซ์ “แก้ไขข้อผิดพลาด” และหวังว่าจะดีที่สุด นักพัฒนาสามารถตรวจสอบการวิเคราะห์ความล้มเหลว ยืนยันขอบเขตการเปลี่ยนแปลงที่เสนอ และเก็บบันทึกที่ชัดเจนว่าปัญหาได้รับการแก้ไขอย่างไร

**เหตุผลที่เวิร์กโฟลว์นี้สำคัญ:**

จีเอช-ฟิกซ์-ซีไอ มีค่ามากที่สุดสำหรับทีมที่ใช้ GitHub Actions เป็นส่วนหนึ่งของเวิร์กโฟลว์ Pull Request ของพวกเขา มันช่วยให้ โคเด็กซ์ เปลี่ยนการตรวจสอบที่ล้มเหลวให้เป็นลำดับขั้นตอนของการวินิจฉัย การอนุมัติ การดำเนินการ และการตรวจสอบ แทนที่จะเป็นความพยายามแบบกล่องดำเพื่อทำให้สถานะ CI ผ่าน

### **เวิร์กโฟลว์ 3: การทดสอบและตรวจสอบขั้นตอนการลงทะเบียนที่เสียในเบราว์เซอร์**

**สถานการณ์:**

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

ในสถานการณ์ตัวอย่างนี้ ผู้ใช้เปิดหน้าลงทะเบียนเวิร์กสเปซ ป้อนชื่อเต็ม อีเมลที่ทำงาน และชื่อเวิร์กสเปซ จากนั้นคลิก**สร้างเวิร์กสเปซ**. ผลลัพธ์ที่คาดหวังคือข้อความยืนยันที่มองเห็นได้:**“สร้างเวิร์กสเปซแล้ว”**แต่ขั้นตอนกลับดูเหมือนส่งแล้วแต่ไม่แสดงสถานะการยืนยันใดๆ

**เวิร์กโฟลว์ที่ใช้:**

การทดสอบเบราว์เซอร์ด้วยเพลย์ไรต์

**ตัวอย่างพรอมต์:**

“เปิดขั้นตอนการลงทะเบียนเวิร์กสเปซในเบราว์เซอร์ กรอกฟอร์มด้วยข้อมูลที่ถูกต้อง คลิกสร้างเวิร์กสเปซ และตรวจสอบว่ามีข้อความยืนยันที่มองเห็นได้ปรากฏขึ้น หากขั้นตอนล้มเหลว ให้จับหลักฐานจากเบราว์เซอร์ที่เกี่ยวข้อง ระบุสาเหตุที่เป็นไปได้ และเสนอการแก้ไขที่ปลอดภัยที่สุดก่อนที่จะแก้ไขโค้ด”

ต่างจากการตรวจสอบโค้ดเพียงอย่างเดียว การทดสอบเบราว์เซอร์จะตรวจสอบสิ่งที่ผู้ใช้ประสบจริง ขั้นตอนการทำงานเริ่มจากการจำลองเส้นทางตั้งแต่การโหลดหน้าจนถึงการส่งฟอร์ม จากนั้นเปรียบเทียบผลลัพธ์ที่เห็นกับผลลัพธ์ที่คาดหวังจากมุมมองผู้ใช้

![<img src="playwright sample1" alt="the screenshot of playwright sample ">](https://file.nanoskill.ai/playwright-sample)

_รูปที่ 4 ตัวอย่างขั้นตอนการทำงานที่ขับเคลื่อนด้วย Playwright: Codex ย้ายจากขั้นตอนการสมัครที่เสียไปสู่การตรวจสอบหลักฐานในเบราว์เซอร์ การอนุมัติ และผลลัพธ์ของโฟลว์ผู้ใช้ที่ผ่านการตรวจสอบ_

ความล้มเหลวเริ่มต้นไม่ใช่ข้อความคลุมเครือ “มีบางอย่างผิดพลาด” การทดสอบเบราว์เซอร์มีความคาดหวังที่ชัดเจนจากมุมมองผู้ใช้: หลังจากผู้ใช้ส่งรายละเอียดการสมัครที่ถูกต้อง หน้ากระดาษควรแสดงข้อความยืนยัน**“สร้างพื้นที่ทำงานแล้ว”**  
แต่ผลลัพธ์ที่สังเกตได้คือไม่มีสถานะยืนยันปรากฏหลังจากส่งข้อมูล นี่ทำให้ Codex มีเงื่อนไขความล้มเหลวที่เฉพาะเจาะจงในการตรวจสอบ แทนที่จะเป็นคำสั่งทั่วไปให้ “แก้ไขหน้าสมัคร”

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

จากจุดนั้น Codex สามารถจัดโครงสร้างการตรวจสอบเป็นลำดับที่ควบคุมได้: ตรวจสอบสถานะเบราว์เซอร์ ทบทวนหลักฐานความล้มเหลว ระบุพฤติกรรม UI ที่น่าจะหายไป และเสนอแผนซ่อมแซมขั้นต่ำ ในกรณีนี้ การแก้ไขที่เสนอแคบอย่างตั้งใจ: แสดงผลที่มองเห็นได้**“สร้างพื้นที่ทำงานแล้ว”**สถานะยืนยันหลังจากส่งฟอร์มที่ถูกต้อง โดยไม่เปลี่ยนแปลงโครงสร้างหน้าปัจจุบันและพฤติกรรมการตรวจสอบข้อมูล

![<img src="playwright sample2" alt="the screenshot of playwright sample ">](https://file.nanoskill.ai/playwright-sample2)

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

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

หลังจากนำการแก้ไขที่ได้รับอนุมัติไปใช้ สถานะสุดท้ายที่คาดหวังก็ชัดเจน: โฟลว์การสมัครแสดงข้อความยืนยัน และการทดสอบเบราว์เซอร์ส่งคืนผลลัพธ์ผ่าน สิ่งนี้สร้างวงรอบการพัฒนาที่น่าเชื่อถือกว่าการเพียงแค่ขอให้เอเจนต์ “แก้ไขหน้าสมัคร” โดยไม่มีหลักฐานว่าอะไรล้มเหลวหรือการยืนยันว่าโฟลว์ผู้ใช้ตอนนี้ใช้งานได้

ตัวอย่างนี้เป็นขั้นตอนการทำงานที่แสดงให้เห็นโดยอิงจากการทดสอบเบราว์เซอร์สไตล์ Playwright ไม่ได้แสดงถึงแอปพลิเคชันจริงหรือการทดสอบที่เสร็จสมบูรณ์

**เหตุผลที่ขั้นตอนการทำงานนี้สำคัญ:**

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

## **คำถามที่พบบ่อยเกี่ยวกับ Codex Skills**

### **Codex Skills คืออะไร**

Codex Skills เป็นขั้นตอนการทำงานที่ใช้ซ้ำได้ซึ่งช่วยให้ Codex จัดการกับงานประเภทเฉพาะได้อย่างสม่ำเสมอมากขึ้น หนึ่งสกิลสามารถรวมถึงคำแนะนำ สคริปต์เสริม เอกสารอ้างอิง และทรัพยากรที่แนะนำ Codex ผ่านกระบวนการที่ทำซ้ำได้

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

### **ฉันจะติดตั้ง Codex Skill ได้อย่างไร**

สำหรับสกิลที่คัดสรรแล้ว ให้เปิด Codex และใช้ตัวติดตั้งในตัว

ตัวอย่างเช่น คุณสามารถพิมพ์:

**$skill-installer gh-fix-ci**

จากนั้น Codex สามารถติดตั้งสกิลที่เลือกไว้ในการตั้งค่าภายในเครื่องของคุณ หากสกิลไม่ปรากฏทันทีหลังการติดตั้ง ให้รีสตาร์ท Codex แล้วลองเรียกใช้อีกครั้ง

คุณยังสามารถขอให้ตัวติดตั้งช่วยคุณค้นหาสกิลที่เกี่ยวข้องได้ ตัวอย่างเช่น:

**$skill-installer**

**แนะนำสกิลสำหรับการทดสอบเบราว์เซอร์และขั้นตอนการทำงานของ GitHub**

เมื่อติดตั้งแล้ว คุณสามารถเรียกใช้ทักษะได้โดยตรงด้วยการพิมพ์ชื่อของมันโดยมีเครื่องหมายดอลลาร์ เช่น**$gh-แก้ไข-ci**หรือ**$กำหนดเป้าหมาย**.

### **ฉันสามารถสร้างทักษะโคเด็กซ์ของฉันเองได้ไหม?**

ใช่ ที่จริงแล้ว ทักษะที่กำหนดเองมักมีค่ามากกว่าชุดทักษะทั่วไปจำนวนมาก

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

โคเด็กซ์มีเวิร์กโฟลว์ตัวสร้างทักษะที่สามารถช่วยเปลี่ยนเธรด เอกสาร สคริปต์ รายการตรวจสอบ หรือผลลัพธ์ตัวอย่างที่มีประโยชน์ให้เป็นทักษะที่ใช้ซ้ำได้ ทักษะที่กำหนดเองมักเริ่มต้นด้วยไฟล์ที่จำเป็น`ทักษะ.md`และสามารถรวมการอ้างอิง สคริปต์ หรือเทมเพลตเพิ่มเติมได้

เวลาที่ดีที่สุดในการสร้างทักษะคือหลังจากที่คุณทำงานเสร็จแล้วครั้งหนึ่ง และรู้ว่าผลลัพธ์ที่ดีควรเป็นอย่างไร

### **ความแตกต่างระหว่างทักษะโคเด็กซ์กับเอเจนต์.md คืออะไร?**

ไฟล์`เอเจนต์.md`มีคำแนะนำโครงการถาวร มันบอกโคเด็กซ์ว่าควรปฏิบัติตัวอย่างไรเมื่อทำงานในที่เก็บหรือโฟลเดอร์เฉพาะ

ตัวอย่างเช่น ไฟล์`เอเจนต์.md`อาจระบุว่า:

- รันชุดทดสอบก่อนเปิดคำขอดึง
- อย่าเพิ่มการพึ่งพาใหม่โดยไม่ได้รับการอนุมัติ
- ปฏิบัติตามไลบรารีคอมโพเนนต์ที่มีอยู่
- จัดทำเอกสารการเปลี่ยนแปลง API สาธารณะ

ทักษะนั้นแตกต่างกัน มันเป็นเวิร์กโฟลว์ที่ใช้ซ้ำได้สำหรับประเภทงานเฉพาะ

ตัวอย่างเช่น:

- ใช้ gh-แก้ไข-ci เมื่อการตรวจสอบกิตฮับแอคชันล้มเหลว
- ใช้ทักษะทดสอบเบราว์เซอร์เมื่อตรวจสอบขั้นตอนการลงทะเบียน
- ใช้ทักษะเอกสารเมื่อเตรียมบันทึกการเผยแพร่

วิธีง่ายๆ ในการจำความแตกต่างคือ:

### **เอเจนต์.md กำหนดกฎที่คงที่ ทักษะกำหนดงานที่ทำซ้ำได้**

### **ทักษะโคเด็กซ์ใดที่ผู้เริ่มต้นควรลองก่อน?**

เริ่มต้นด้วยทักษะที่แก้ปัญหาที่ซ้ำบ่อยที่สุดในเวิร์กโฟลว์ปัจจุบันของคุณ

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

หากคุณใช้เวลามากกับคำขอดึงของกิตฮับ ให้ลองใช้**gh-แก้ไข-ci**หรือ**gh-จัดการความคิดเห็น**.

หากคุณสร้างผลิตภัณฑ์เว็บ เวิร์กโฟลว์ทดสอบเบราว์เซอร์เช่น**เพลย์ไรต์**มีประโยชน์เพราะช่วยตรวจสอบสิ่งที่ผู้ใช้เห็นและทำจริง

หากคุณทำงานกับ API หรือโมเดลของโอเพนเอไอ**เอกสารโอเพนเอไอ**สามารถช่วยให้โคเด็กซ์พึ่งพาเอกสารโดยตรงที่เป็นปัจจุบันแทนที่จะเป็นตัวอย่างที่ล้าสมัย

ทักษะแรกที่ดีที่สุดมักไม่ใช่ทักษะที่ล้ำสมัยที่สุด แต่เป็นทักษะที่ขจัดแหล่งความขัดแย้งซ้ำๆ จากงานของคุณ

### **ทักษะโคเด็กซ์ปลอดภัยในการติดตั้งหรือไม่?**

ควรปฏิบัติต่อทักษะเหมือนกับเครื่องมืออัตโนมัติหรือเครื่องมือสำหรับนักพัฒนาที่ใช้ซ้ำได้อื่นๆ: ติดตั้งจากแหล่งที่เชื่อถือได้ ตรวจสอบสิ่งที่ออกแบบมาให้ทำ และเข้าใจว่าต้องการการเข้าถึงอะไร

ก่อนใช้ทักษะในโครงการจริง ให้ตรวจสอบว่ามันสามารถ:

- รันคำสั่งในสภาพแวดล้อมในเครื่องของคุณ
- เข้าถึงเครื่องมือภายนอกหรือบริการที่เชื่อมต่อ
- แก้ไขไฟล์
- สร้างคอมมิตหรือคำขอดึง
- ทริกเกอร์การปรับใช้
- อ่านเอกสารโครงการหรือการกำหนดค่าที่เกี่ยวข้องกับความลับ

สำหรับการทดลองที่มีความเสี่ยงต่ำ ให้เริ่มในโฟลเดอร์สาธิตหรือที่เก็บทดสอบแยกต่างหาก เมื่อทักษะเสนอการเปลี่ยนแปลงที่มีความหมาย ให้ตรวจสอบแผนก่อนอนุมัติการแก้ไขไฟล์ การเปลี่ยนแปลงโค้ด คอมมิต หรือการปรับใช้