คู่มือ OpenAI Codex สำหรับงานโค้ด
อัปเดต: 2026-07-27
OpenAI Codex คือ coding agent สำหรับงาน software development ที่ช่วยอ่านโค้ด เข้าใจ repo แก้บั๊ก เขียน test ปรับเอกสาร review diff และช่วยทำงานหลายขั้นตอนใน environment ที่กำหนดได้
จุดสำคัญคือ Codex ไม่ใช่เครื่องมือสำหรับ “สั่งแล้ว merge เลย” แต่เป็นผู้ช่วยวิศวกรรมที่ควรทำงานร่วมกับ context, ขอบเขต, test, code review และ human approval อย่างมีระบบ
คู่มือนี้เขียนสำหรับ developer, technical founder, data/ops power user และคนที่อยากใช้ Codex กับ repo จริง โดยอิงจาก Codex manual และเอกสาร official ของ OpenAI เป็นหลัก
สารบัญ#
- Codex คืออะไร
- Codex ต่างจาก autocomplete อย่างไร
- ใช้ Codex ได้จากที่ไหน
- งานที่เหมาะกับ Codex
- Prompt ที่ดีสำหรับ Codex
- ให้ Codex วางแผนก่อนแก้โค้ด
- ใช้
AGENTS.mdเป็นคู่มือประจำ repo - Approvals, sandbox และ permissions
- Workflow แก้บั๊กด้วย Codex
- Workflow เพิ่ม feature ด้วย Codex
- Workflow เขียน test และ documentation
- ใช้ Codex review โค้ด
- ความปลอดภัยและงานที่ต้องระวัง
- Checklist ก่อน commit หรือ PR
- Prompt library สำหรับ Codex
- FAQ
1. Codex คืออะไร#
Codex คือ coding agent ของ OpenAI ที่ออกแบบมาเพื่อช่วยงานพัฒนา software ไม่ใช่แค่ตอบคำถามเกี่ยวกับโค้ด แต่สามารถทำงานกับ project context ได้ เช่น อ่านหลายไฟล์ แก้ไฟล์ รันคำสั่ง ตรวจผล และสรุปสิ่งที่เปลี่ยน
ในมุมคนทำงานจริง Codex ช่วยได้กับงานเหล่านี้:
- อธิบาย codebase ที่ไม่คุ้น
- หา root cause ของ bug
- แก้บั๊กแบบ scoped
- เขียนหรือปรับ test
- refactor เฉพาะจุด
- เพิ่ม feature ขนาดเล็กถึงกลาง
- ปรับ documentation
- review uncommitted changes หรือ PR
- ช่วยสรุป test notes และ PR description
อย่างไรก็ตาม Codex ยังต้องมีมนุษย์กำกับ โดยเฉพาะงานที่เกี่ยวกับ authentication, authorization, payment, data migration, production config, security-sensitive code หรือโค้ดที่มีผลต่อผู้ใช้จำนวนมาก
2. Codex ต่างจาก Autocomplete อย่างไร#
Autocomplete ช่วยเติมโค้ดระหว่างพิมพ์ เหมาะกับระดับบรรทัดหรือฟังก์ชัน
Coding assistant ทั่วไปช่วยตอบคำถาม อธิบายโค้ด หรือสร้าง snippet
Codex ในฐานะ coding agent สามารถทำงานเป็นรอบมากกว่า เช่น สำรวจ repo วางแผน แก้ไฟล์ รัน test อ่านผลลัพธ์ แก้ต่อ และสรุป diff ให้ตรวจ
ภาพรวม:
| เครื่องมือ | ทำอะไรเด่น | เหมาะกับ |
|---|---|---|
| Autocomplete | เติมโค้ดขณะพิมพ์ | งานเร็วระดับบรรทัด |
| Coding assistant | ตอบคำถามและช่วยเขียน snippet | อธิบาย แนะนำ แก้ปัญหาเฉพาะจุด |
| Coding agent | อ่าน repo แก้ไฟล์ รันคำสั่ง ตรวจผล | bug fix, test, refactor, review, feature scoped |
อ่านต่อ: เปรียบเทียบ AI Coding Agents สำหรับนักพัฒนา
3. ใช้ Codex ได้จากที่ไหน#
จาก Codex manual, Codex ใช้ได้ผ่านหลาย surface ตามแผนและสิทธิ์ของบัญชี เช่น:
- Codex ใน ChatGPT desktop app
- Codex CLI สำหรับงานใน terminal
- Codex IDE extension สำหรับงานที่ผูกกับ editor
- Codex web/cloud หรือ cloud-based workflows ในบางกรณี
แนวทางเลือก surface:
- ใช้ CLI เมื่อทำงานใน terminal และต้องการให้ Codex ใช้คำสั่ง project จริง
- ใช้ IDE extension เมื่ออยากให้ Codex อยู่ใกล้ selected code และ editor workflow
- ใช้ desktop app เมื่ออยากทำงานเป็น task/thread เห็น diff และคุยกำกับงานยาว
- ใช้ cloud workflow เมื่องานเหมาะกับ environment ที่จัดไว้และสิทธิ์ของ workspace รองรับ
ฟีเจอร์ ราคา model availability และ usage limit อาจเปลี่ยนตาม plan, workspace policy และ maturity ของฟีเจอร์ ควรตรวจเอกสาร OpenAI ล่าสุดก่อนเขียนคู่มือเชิง commercial หรือ training ภายในองค์กร
4. งานที่เหมาะกับ Codex#
งานที่เหมาะมาก:
- แก้ bug ที่มี reproduction ชัด
- เพิ่ม test รอบ behavior เดิม
- refactor เฉพาะ module
- อัปเดต API usage แบบจำกัด scope
- สร้าง prototype
- เขียน documentation จากโค้ด
- review changes เพื่อหา bug, regression, security risk และ missing tests
งานที่ควรเริ่มแบบ read-only ก่อน:
- codebase ใหญ่ที่ยังไม่รู้โครงสร้าง
- feature ที่กระทบหลาย module
- performance issue ที่ยังไม่มี measurement
- bug ที่ reproduce ยาก
- legacy code ที่ไม่มี test
งานที่ต้องระวังเป็นพิเศษ:
- authentication และ authorization
- payment และ billing
- database migration
- production config
- secret, token, API key
- cryptography
- security boundary
- large refactor ข้ามทีม
5. Prompt ที่ดีสำหรับ Codex#
Codex manual แนะนำให้ prompt สำหรับงานใหญ่หรือสำคัญมี 4 ส่วนหลัก: goal, context, constraints และ done when
Template:
Goal:
ช่วย [สิ่งที่ต้องการเปลี่ยน/สร้าง/แก้]
Context:
- พื้นที่ที่เกี่ยวข้อง: [folder/file]
- error หรือพฤติกรรมปัจจุบัน:
- behavior ที่ต้องการ:
- reference หรือ pattern ที่ควรตาม:
Constraints:
- ห้ามเปลี่ยน [สิ่งที่ต้องคงไว้]
- ทำแบบ scoped
- อย่า refactor นอกเหนือจากงานนี้
- ถ้าเจอเรื่องเสี่ยง ให้หยุดและถามก่อน
Done when:
- test ที่เกี่ยวข้องผ่าน
- lint/typecheck ผ่านถ้าเกี่ยวข้อง
- สรุปไฟล์ที่แก้ เหตุผล และ risk ที่เหลือ
ตัวอย่างแก้บั๊ก:
Goal:
ช่วยแก้ bug ที่หน้า checkout กด Apply coupon แล้วยอดรวมไม่อัปเดต
Context:
- เริ่มดูที่ src/checkout และ tests/checkout
- bug เกิดเฉพาะเมื่อ coupon เป็น percent discount
- UI แสดง coupon applied แล้ว แต่ total ยังเป็นราคาเดิม
Constraints:
- อย่าเปลี่ยน layout
- อย่าเปลี่ยน public API
- แก้เฉพาะ root cause
Done when:
- เพิ่มหรือปรับ test ที่ครอบคลุม percent discount
- รัน test checkout ให้ผ่าน
- สรุป diff และ verification
ตัวอย่างสำรวจ repo:
อ่าน flow authentication ใน repo นี้
ยังไม่ต้องแก้โค้ด
ขอ:
- ไฟล์หลักที่เกี่ยวข้อง
- flow ตั้งแต่ login ถึง session validation
- จุดที่น่าจะทำให้ session หมดอายุเร็ว
- test ที่ควรมี
- แผนแก้ไขแบบ scoped
6. ให้ Codex วางแผนก่อนแก้โค้ด#
ถ้างานซับซ้อน คลุมเครือ หรือเสี่ยง ควรให้ Codex วางแผนก่อนเริ่มแก้ Codex manual แนะนำแนวคิด Plan mode สำหรับให้ Codex gather context, ถามคำถาม และสร้างแผนก่อน implementation
ใช้เมื่อ:
- ยังไม่รู้ว่าไฟล์ไหนเกี่ยวข้อง
- feature มีหลายขั้น
- bug กระทบหลาย module
- ต้องคุย trade-off ก่อน
- repo มี convention เฉพาะ
Prompt:
ใช้โหมดวางแผนก่อน
อ่าน context ที่เกี่ยวข้องกับ [ปัญหา]
สรุป:
- root cause ที่เป็นไปได้
- ไฟล์ที่ต้องดู
- แผนแก้ไขเป็นขั้น
- test ที่ควรเพิ่มหรือรัน
- risk และสิ่งที่ต้องถามฉันก่อน
ยังไม่ต้องแก้ไฟล์
หลังเห็นแผนแล้วค่อยสั่ง:
แผนข้อ 1-3 โอเค
ลงมือแก้ได้ แต่จำกัด scope เฉพาะไฟล์ที่ระบุ
รัน test ที่เกี่ยวข้องและสรุปผล
7. ใช้ AGENTS.md เป็นคู่มือประจำ Repo#
AGENTS.md คือไฟล์คำแนะนำสำหรับ agent ใน repo Codex manual แนะนำให้ใช้เก็บ guidance ที่อยากให้ Codex ใช้ซ้ำ เช่น repo layout, วิธี install, test/lint/build commands, engineering conventions, PR expectations, constraints และนิยามว่า “เสร็จ” คืออะไร
ตัวอย่าง:
# AGENTS.md
## Project Overview
This is a Next.js app with a Node.js API and PostgreSQL database.
## Commands
- Install: npm install
- Dev: npm run dev
- Test: npm test
- Lint: npm run lint
- Typecheck: npm run typecheck
## Guidelines
- Keep changes scoped to the requested task.
- Add or update tests for bug fixes.
- Do not change public API behavior without approval.
- Do not edit generated files unless explicitly requested.
- Summarize verification in the final response.
## Definition of Done
- Relevant tests pass.
- Lint/typecheck pass when affected.
- Diff is reviewed for regressions.
- Remaining risks are stated clearly.
แนวทางเขียน AGENTS.md:
- สั้น ชัด และตรงกับ repo จริง
- ใส่ command ที่รันได้จริง
- ระบุสิ่งที่ห้ามแตะ
- อัปเดตเมื่อ Codex ทำผิดซ้ำ
- ถ้า repo ใหญ่ ให้มี
AGENTS.mdเฉพาะ subdirectory ได้
8. Approvals, Sandbox และ Permissions#
Codex ทำงานกับไฟล์และคำสั่งได้ จึงต้องมีกรอบควบคุม Codex manual อธิบายว่า approval mode กำหนดว่าเมื่อไหร่ Codex ต้องขออนุญาต ส่วน sandbox mode กำหนดขอบเขตการอ่าน/เขียนไฟล์และการเข้าถึง environment
หลักคิดสำหรับผู้เริ่มต้น:
- เริ่มจาก permission ที่คุมเข้ม
- ให้สิทธิ์เพิ่มเฉพาะเมื่อเข้าใจงานและ repo
- อย่าให้ Codex เห็น secrets ถ้าไม่จำเป็น
- อย่ารันคำสั่ง destructive โดยไม่ตรวจ
- สำหรับงานเสี่ยง ให้ขอแผนก่อนแก้ไฟล์
ตัวอย่าง boundary ใน prompt:
อย่าแก้ไฟล์ production config
อย่ารัน migration
อย่าลบไฟล์
ถ้าต้องใช้ network หรือ command ที่เปลี่ยน state ภายนอก ให้หยุดและถามก่อน
9. Workflow แก้บั๊กด้วย Codex#
Workflow ที่แนะนำ:
- อธิบาย bug และ reproduction
- ให้ Codex สำรวจไฟล์ที่เกี่ยวข้อง
- ขอ hypothesis หรือ root cause
- ให้แก้เฉพาะ root cause
- เพิ่มหรือปรับ test
- รัน test ที่เกี่ยวข้อง
- อ่าน diff เอง
- ให้ Codex สรุป verification และ risk
Prompt:
ช่วยแก้ bug นี้
Bug:
[อธิบายอาการ]
Reproduction:
1. [ขั้นตอน]
2. [ขั้นตอน]
3. [ผลลัพธ์ผิด]
Expected:
[ผลลัพธ์ที่ควรเป็น]
Constraints:
- เริ่มจากการสำรวจและสรุป root cause
- แก้แบบ scoped
- เพิ่ม regression test
- รัน test ที่เกี่ยวข้อง
Final response:
- สาเหตุ
- ไฟล์ที่แก้
- test ที่รัน
- risk ที่ยังเหลือ
10. Workflow เพิ่ม Feature ด้วย Codex#
Feature ใหม่ควรให้ Codex เริ่มจาก acceptance criteria ไม่ใช่แค่ “ทำหน้าใหม่ให้หน่อย”
Prompt:
ช่วยเพิ่ม feature [ชื่อ feature]
User story:
ในฐานะ [ผู้ใช้]
ฉันต้องการ [ความสามารถ]
เพื่อ [เหตุผล]
Acceptance criteria:
- [เงื่อนไข 1]
- [เงื่อนไข 2]
- [เงื่อนไข 3]
Context:
- ดู pattern จาก [ไฟล์/หน้า/คอมโพเนนต์]
- ใช้ style และ convention เดิม
Constraints:
- อย่าเปลี่ยน behavior เดิม
- ถ้าต้องแก้ schema/API ให้เสนอแผนก่อน
Done when:
- เพิ่ม test ที่เหมาะสม
- รัน test/lint ที่เกี่ยวข้อง
- สรุป implementation และ trade-off
สำหรับ feature ใหญ่ ควรแยกเป็นหลาย task:
- design/API contract
- UI state
- backend behavior
- test
- documentation
- migration หรือ rollout plan
11. Workflow เขียน Test และ Documentation#
Codex เหมาะมากกับการเพิ่ม test รอบโค้ดเดิม เพราะมันอ่าน behavior และ pattern ใน repo ได้
Prompt สำหรับ test:
ช่วยเพิ่ม test ให้ฟังก์ชัน [ชื่อ]
Context:
- ดู implementation ใน [ไฟล์]
- ดู style test เดิมใน [ไฟล์ test]
ขอ test cases:
- happy path
- edge case
- invalid input
- regression case สำหรับ [bug/issue]
อย่าเปลี่ยน implementation เว้นแต่จำเป็น
ถ้าพบว่า code test ยาก ให้เสนอ refactor ก่อน
Prompt สำหรับ documentation:
อ่าน module [ชื่อ/folder]
ช่วยเขียน documentation สำหรับ developer ใหม่
ขอ:
- module ทำอะไร
- entry points
- data flow
- commands ที่เกี่ยวข้อง
- common mistakes
- ตัวอย่าง usage
อย่าเดาข้อมูลที่ไม่พบใน code
12. ใช้ Codex Review โค้ด#
Codex manual ระบุว่า Codex ช่วย review ได้ เช่น review diff, uncommitted changes, commit หรือ PR-style review และควรเน้น bugs, regressions, risky patterns และ missing tests
Prompt สำหรับ review:
ช่วย review changes นี้แบบ code review
โฟกัส:
- bug
- behavioral regression
- security risk
- missing tests
- edge cases
รูปแบบคำตอบ:
- findings ก่อน summary
- เรียงตาม severity
- ระบุ file/line ถ้ามี
- ถ้าไม่พบปัญหา ให้บอกชัดเจน
- ระบุ residual risk หรือ test gap
Prompt สำหรับ review ตาม policy ทีม:
ช่วย review ตาม checklist นี้:
- public API ต้อง backward compatible
- error handling ต้องไม่กลืน error
- user input ต้อง validate
- database query ต้องไม่เสี่ยง injection
- feature ใหม่ต้องมี test
ตอบเฉพาะ finding ที่ actionable
13. ความปลอดภัยและงานที่ต้องระวัง#
Codex ช่วยเร่งงานได้มาก แต่ยิ่ง agent มีสิทธิ์อ่าน เขียน และรันคำสั่งมากเท่าไร ความเสี่ยงยิ่งต้องถูกจัดการมากขึ้น
งานที่ควรมีมนุษย์ตรวจละเอียด:
- auth/session/permission
- payment/billing
- database migration
- data deletion
- production deploy/config
- secrets management
- cryptography
- dependency upgrade ขนาดใหญ่
- security-sensitive parser หรือ sanitizer
Prompt สำหรับตั้งขอบเขต security:
งานนี้เกี่ยวกับ authentication
ก่อนแก้:
- สรุป flow ปัจจุบัน
- ระบุ trust boundary
- ระบุ risk
- เสนอ test
ห้าม:
- เปลี่ยน permission model โดยไม่ถาม
- log token/session
- แตะ production config
- ลบหรือ rotate secrets
ถ้าคุณใช้ Codex Security หรือ workflow ด้าน security เฉพาะ ควรเข้าใจว่าเครื่องมือช่วยค้นหา จัดอันดับ ตรวจซ้ำ และเสนอ patch ได้ แต่ไม่ได้แทน manual security review หรือ threat assessment ของทีม
14. Checklist ก่อน Commit หรือ PR#
ก่อนยอมรับงานจาก Codex:
- Diff อยู่ใน scope ที่สั่ง
- ไม่มีไฟล์ unrelated ถูกแก้
- มี test สำหรับ behavior สำคัญ
- test/lint/typecheck ที่เกี่ยวข้องผ่าน
- ไม่มี secret หรือข้อมูลลับถูกเพิ่มในไฟล์
- error handling ยังเหมาะสม
- backward compatibility ไม่พัง
- documentation อัปเดตถ้าจำเป็น
- Codex สรุป verification ชัด
- มนุษย์อ่าน diff แล้วก่อน commit/merge
Prompt ให้ Codex ช่วยสรุปก่อน PR:
ช่วยเตรียม PR summary
ขอ:
- What changed
- Why
- Tests run
- Screenshots หรือ notes ถ้ามี
- Risks / rollback notes
- Follow-up work
15. Prompt Library สำหรับ Codex#
สำรวจ Repo#
อ่าน repo นี้แบบ read-only
สรุป:
- tech stack
- folder สำคัญ
- วิธี run/test เท่าที่พบ
- entry points หลัก
- สิ่งที่ควรรู้ก่อนแก้โค้ด
แก้ Bug#
ช่วยแก้ bug [อธิบาย]
เริ่มจากหา root cause
แก้แบบ scoped
เพิ่ม regression test
รัน test ที่เกี่ยวข้อง
สรุปไฟล์ที่แก้และ verification
เพิ่ม Test#
เพิ่ม test รอบ [module/function]
ดู pattern จาก test เดิม
ครอบคลุม happy path, edge case และ regression case
อย่าเปลี่ยน implementation ถ้าไม่จำเป็น
Refactor เฉพาะจุด#
ช่วย refactor [ไฟล์/module]
เป้าหมายคืออ่านง่ายขึ้นและลด duplication
ห้ามเปลี่ยน behavior
ต้องรัน test เดิมให้ผ่าน
สรุปว่าความเสี่ยงอยู่ตรงไหน
Code Review#
review uncommitted changes
หา bug, regression, security risk และ missing tests
ตอบ findings ก่อน summary
ถ้าไม่พบปัญหา ให้บอกชัดเจน
16. FAQ#
Codex คืออะไร#
Codex คือ coding agent ของ OpenAI สำหรับช่วยงาน software development เช่น อ่าน repo แก้โค้ด รันคำสั่ง เขียน test รีวิว diff และสรุปงาน โดยยังต้องมีมนุษย์กำกับและตรวจผลลัพธ์
Codex เหมาะกับผู้เริ่มต้นไหม#
เหมาะถ้าผู้ใช้เข้าใจพื้นฐาน repo และรู้วิธีตรวจ diff/test อย่างน้อยระดับหนึ่ง ถ้าไม่ใช่นักพัฒนา ควรเริ่มจากงานอ่านโค้ด อธิบาย flow หรือสร้าง prototype ที่ไม่กระทบ production
Codex ใช้แทน developer ได้ไหม#
ไม่ควรมองว่าแทน developer ทั้งหมด Codex ช่วยเร่งงานและลดงานซ้ำได้ แต่การออกแบบระบบ ตัดสินใจ trade-off ตรวจ security และรับผิดชอบ final change ยังเป็นหน้าที่ของมนุษย์และทีม
Prompt ที่ดีสำหรับ Codex ควรมีอะไร#
ควรมี goal, context, constraints และ done when เช่น ต้องแก้อะไร ไฟล์ไหนเกี่ยวข้อง ห้ามเปลี่ยนอะไร และต้องรัน test หรือผ่านเกณฑ์ใดก่อนถือว่างานเสร็จ
AGENTS.md คืออะไร#
AGENTS.md คือไฟล์ guidance สำหรับ agent ใน repo ใช้บอกโครงสร้าง project, command, convention, PR expectations, constraints และวิธี verify งาน เพื่อให้ Codex ทำงานสอดคล้องกับทีมมากขึ้น
ควรให้ Codex รัน test เองไหม#
ควรให้รัน test ที่เกี่ยวข้องเมื่อ environment พร้อม แต่ผู้ใช้ยังควรอ่านผล test และ diff เอง ถ้า test รันไม่ได้ Codex ควรสรุปเหตุผลและบอก risk ที่เหลือ
งานแบบไหนไม่ควรให้ Codex แก้แบบอัตโนมัติ#
งานที่เกี่ยวกับ authentication, payment, database migration, production config, secrets, cryptography และ security boundary ควรให้ Codex สำรวจ วางแผน และเสนอ patch แบบมี human review ชัดเจน
Codex Security แทน manual security review ได้ไหม#
ไม่ได้ Codex Security ช่วยวิเคราะห์ จัดอันดับ ตรวจซ้ำ และเสนอ remediation ได้ แต่ยังเป็นเครื่องมือช่วยทีม ไม่ได้แทน manual security review, exploitability assessment หรือการตัดสินใจด้าน risk ขององค์กร
อ่านต่อ#
- คู่มือ AI สำหรับคนทำงานยุคใหม่
- เปรียบเทียบ AI Coding Agents สำหรับนักพัฒนา
- คู่มือ ChatGPT สำหรับผู้เริ่มต้น
- Prompt Library สำหรับงานออฟฟิศ