เอเจนต์เขียนโค้ดจะอ่านรีโพของคุณก่อนที่จะเขียนโค้ด และไฟล์แรกที่พวกเขาอ่านคือ AGENTS.md นี่คือข้อตกลงเปิดที่ Codex CLI, Cursor, Aider, OpenHands และเครื่องมืออื่นๆ อีกมากมายที่เพิ่มขึ้นเรื่อยๆ ได้ตกลงร่วมกัน เพื่อให้ไฟล์บริบทเดียวสามารถใช้ได้กับเอเจนต์ทุกตัว สำหรับทีมพัฒนา API ไฟล์นี้คือความแตกต่างระหว่างเอเจนต์ที่รันการทดสอบที่ถูกต้องกับเซิร์ฟเวอร์โลคัลจริง กับเอเจนต์ที่สร้างเอนด์พอยต์ปลอมและส่งมอบไคลเอนต์ที่เสียหาย
คู่มือนี้จะอธิบายว่า AGENTS.md คืออะไร ทำไมทีม API ควรปฏิบัติต่อมันเหมือนโค้ดสำหรับใช้งานจริง ส่วนที่สำคัญสำหรับรีโพที่เน้น OpenAPI ตัวอย่างที่เป็นรูปธรรม และวิธีทำให้มันอัปเดตอยู่เสมอเมื่อ API พัฒนาขึ้น เราจะจับคู่มันกับ Apidog ในตอนท้าย เพื่อให้ขั้นตอนการทดสอบสัญญาของเอเจนต์ยังคงอิงกับสเปกจริง
สรุปโดยย่อ
AGENTS.mdคือไฟล์ Markdown ธรรมดาที่อยู่ใน root ของรีโพ ซึ่งบอกเอเจนต์เขียนโค้ดถึงวิธีนำทาง สร้าง ทดสอบ และจัดส่งโค้ดในโปรเจกต์ของคุณ- ข้อตกลงนี้เป็นแบบเปิดและได้รับการสนับสนุนจาก Codex CLI, Cursor, OpenHands, Aider, Claude Code และเครื่องมือเอเจนต์อื่นๆ
- สำหรับทีม API ส่วนที่ให้ผลตอบแทนมากที่สุดคือ คำสั่งบิลด์, พาธของสเปก OpenAPI, เอนด์พอยต์ของ Mock Server, คำสั่งทดสอบสัญญา, การตั้งค่าการยืนยันตัวตน และโซนที่ “ห้ามแตะต้อง”
- ทำให้สั้นเข้าไว้ 200 ถึง 400 บรรทัดก็เพียงพอแล้ว หากยาวกว่านั้น เอเจนต์จะข้ามส่วนสำคัญไป
- จับคู่มันกับ Apidog collection เพื่อให้เอเจนต์มีทั้งบริบท (
AGENTS.md) และสัญญาที่สามารถรันได้ (OpenAPI spec)
AGENTS.md คืออะไรกันแน่
AGENTS.md คือไฟล์ Markdown ที่คุณคอมมิตไว้ที่ root ของ Repository เอเจนต์เขียนโค้ดจะมองหาไฟล์นี้เมื่อเริ่มทำงานกับโค้ดเบส และถือว่าเนื้อหาของมันเป็นข้อมูลสรุปที่มีอำนาจเกี่ยวกับวิธีการทำงานของโปรเจกต์ ข้อตกลงนี้เริ่มต้นขึ้นภายใน Codex CLI ของ OpenAI และได้รับการเผยแพร่เป็นมาตรฐานเปิด เพื่อให้เครื่องมืออื่นๆ สามารถอ่านไฟล์เดียวกันได้ ปัจจุบัน Codex CLI, Cursor, Aider, Claude Code, OpenHands, Sourcegraph Cody และเอเจนต์ขนาดเล็กอีกหลายตัวล้วนอ่านไฟล์นี้ได้
สามสิ่งที่ทำให้มันมีประโยชน์:
- ไฟล์เดียว ใช้ได้ทุกเอเจนต์. คุณเขียนบริบทเพียงครั้งเดียว แล้วเอเจนต์ทุกตัวในชุดเครื่องมือของทีมก็สามารถนำไปใช้ได้ ไม่มีการตั้งค่าที่แตกต่างกันไปในแต่ละเครื่องมือ
- Markdown ธรรมดา. ไม่มี DSL, ไม่มี Schema, ไม่มีขั้นตอนการ Build วิศวกรแก้ไขได้เหมือนเอกสารอื่นๆ
- อยู่ข้างโค้ดที่อธิบาย. เมื่อสคริปต์ Build เปลี่ยนแปลง ไฟล์นี้ก็จะเปลี่ยนใน PR เดียวกัน Diff ทำให้การเปลี่ยนแปลงนี้มองเห็นได้สำหรับผู้ตรวจสอบและสำหรับเอเจนต์
คู่หูที่ใกล้เคียงที่สุดคือ CLAUDE.md ซึ่ง Claude Code ของ Anthropic อ่าน รูปแบบทั้งสองมีความทับซ้อนกันอย่างมาก; หลายโปรเจกต์จะเก็บไฟล์ AGENTS.md ที่ symlinked ไปยัง CLAUDE.md เพื่อให้เครื่องมือทั้งสองทำงานได้โดยไม่ต้องตั้งค่าเพิ่มเติม ทีม Codex และ Anthropic ได้ประกาศความสอดคล้องกันในการรักษารูปแบบให้เข้ากันได้ต่อไปในอนาคต
ทำไมทีมพัฒนา API ถึงต้องการมันมากกว่าทีมอื่นๆ
ทีม API อยู่ในจุดที่ซับซ้อน: โค้ดมีขนาดเล็ก สัญญามีขนาดใหญ่ และผลที่ตามมาจากการทำผิดพลาดไม่ว่าจะเป็นส่วนใดก็สามารถเห็นได้จากไคลเอนต์ปลายน้ำทุกราย เอเจนต์ที่ไม่รู้ว่าสเปกอยู่ที่ openapi.yaml จะเขียนประเภทใหม่จากรูปแบบการตอบกลับที่จำได้จากข้อมูลการฝึกอบรม เอเจนต์ที่ไม่รู้คำสั่งทดสอบสัญญาจะคอมมิตโค้ดที่คอมไพล์ได้แต่ทำให้ไคลเอนต์ SDK pipeline เสียหาย
ไฟล์ AGENTS.md ที่เขียนมาอย่างดีสำหรับรีโพ API จะทำสี่สิ่งนี้:
- กำหนดสเปกเป็นแหล่งข้อมูลที่เชื่อถือได้. ทุกการเปลี่ยนแปลงเริ่มต้นและสิ้นสุดด้วย OpenAPI หรือ GraphQL schema เอเจนต์เรียนรู้ที่จะอัปเดตสเปกก่อน จากนั้นจึงสร้างประเภทใหม่
- ระบุชื่อเซิร์ฟเวอร์โลคัล. เอเจนต์ที่รัน mock server หรือ live server โลคัลจะเลือก URL ที่ถูกต้องสำหรับการทดสอบ ไม่ใช่แค่โค้ดสั้นๆ จาก Stack Overflow
- แสดงรายการคำสั่งทดสอบตามวัตถุประสงค์. “รัน unit tests” ไม่เหมือนกับ “รัน contract tests” หรือ “รัน integration tests กับ staging environment”
- ระบุพาธที่ห้ามแก้ไข. โค้ด SDK ที่สร้างขึ้น, wrapper ของไคลเอนต์จากบุคคลที่สาม และไฟล์ migration มักจะดูเหมือนแก้ไขได้แต่ความจริงไม่ใช่
เมื่อไฟล์ทำสี่สิ่งนี้ได้ ผลลัพธ์ของเอเจนต์ก็จะดูไม่เหมือนนักพัฒนาจูเนียร์ที่ข้าม README ไป แต่จะดูเหมือนเพื่อนร่วมทีมแทน
โครงสร้างที่ใช้งานได้ดีสำหรับรีโพ API
AGENTS.md ไม่มี schema ที่บังคับใช้ ชุมชนได้ตกลงใช้บางส่วนที่ปรากฏอยู่ในไฟล์ที่ปรับแต่งมาอย่างดีเกือบทุกไฟล์ สำหรับทีม API ลำดับด้านล่างนี้ถือเป็นค่าเริ่มต้นที่ดี
1. สรุปโปรเจกต์ (3-5 บรรทัด)
ระบุว่า API ทำอะไร ผู้ใช้งานเป็นใคร และเซิร์ฟเวอร์รันด้วยภาษาและเฟรมเวิร์กอะไร ทำให้เป็นข้อเท็จจริง
# โปรเจกต์: Payments API
บริการชำระเงินภายในสำหรับผลิตภัณฑ์ Acme ลูกค้าคือมือถือ เว็บ และแบ็กเอนด์ของพาร์ทเนอร์
เซิร์ฟเวอร์ใช้ Go 1.23 บน Echo, Postgres 17 สำหรับการจัดเก็บข้อมูล และ Redis-backed idempotency layer
บล็อกนี้บอกเอเจนต์ว่าควรใช้ภาษาใดเป็นค่าเริ่มต้น ควรปฏิบัติตามสำนวนแบบใด และไคลเอนต์ใดจะเสียหายหากส่งมอบรูปแบบการตอบกลับที่ไม่ถูกต้อง
2. คำสั่งเริ่มต้นอย่างรวดเร็ว
ห้าถึงสิบคำสั่งที่เอเจนต์จะรันอย่างต่อเนื่อง ใส่คำสั่งเสมอ ห้ามลิงก์ไปยัง Wiki
## คำสั่ง
| วัตถุประสงค์ | คำสั่ง |
|--------|---------|
| ติดตั้ง Dependencies | `make deps` |
| รันเซิร์ฟเวอร์โลคัล | `make dev` (ผูกกับ 127.0.0.1:8080) |
| รัน Unit Tests | `make test` |
| รัน Contract Tests กับ mock โลคัล | `make contract` |
| Lint | `make lint` |
| สร้าง Clients ใหม่จาก spec | `make codegen` |
| ใช้ Migrations | `make migrate` |
หากคำสั่งต้องการ env var ในการทำงาน ให้ใส่ชื่อ env var ไว้ข้างๆ เอเจนต์เก่งในการ export ตัวแปร; แต่ไม่เก่งในการเดา
3. ส่วน OpenAPI / GraphQL spec
นี่คือส่วนที่มีค่ามากที่สุดในรีโพ API บอกเอเจนต์ว่าสเปกอยู่ที่ไหน สเปกเกี่ยวข้องกับโค้ดที่สร้างขึ้นอย่างไร และการแก้ไขจะไหลไปในทิศทางใด
## แหล่งข้อมูลที่เชื่อถือได้
- สเปกอยู่ที่ `apis/payments/openapi.yaml`
- Clients ที่สร้างขึ้นอยู่ใน `gen/clients/{go,ts,python}` และห้ามแก้ไขด้วยมือ
- Pipeline การสร้างคือ `make codegen` รันหลังจากทุกการเปลี่ยนแปลงสเปก
และคอมมิต clients ที่สร้างใหม่ใน PR เดียวกัน
- การเปลี่ยนแปลงสเปกไหลเวียน: สเปก -> `make codegen` -> การอัปเดต server handler ->
contract tests -> จัดส่ง
บล็อกนี้เพียงอย่างเดียวก็ช่วยกำจัดข้อผิดพลาดประเภทหนึ่งที่เอเจนต์แก้ไขไคลเอนต์ที่สร้างขึ้นเพื่อ “แก้ไข” ประเภทที่ไม่ตรงกัน จากนั้นการรัน codegen ครั้งถัดไปจะลบการเปลี่ยนแปลงออก และ build ก็จะเสียหายอย่างลึกลับในอีกสองวันต่อมา
4. การเชื่อมต่อ Mock Server และ Apidog
หากคุณรัน mock server (ซึ่งคุณควรทำ) ให้ตั้งชื่อพวกมัน ระบุ URL, สเปกที่พวกมันอ่าน และวิธีการเริ่มทำงาน
## เซิร์ฟเวอร์โลคัล
- เซิร์ฟเวอร์จริง: `make dev` -> `http://127.0.0.1:8080`
- Apidog mock server: `make mock` -> `http://127.0.0.1:4010`
- mock จะอ่านจาก `openapi.yaml` เดียวกัน และเล่นตัวอย่างที่บันทึกไว้
จาก Apidog collection ที่ `apis/payments/apidog/` ซ้ำ
นี่คือจุดที่ Apidog เข้ามามีบทบาทในไฟล์ Mock server, สเปก และตัวอย่างคำขอที่บันทึกไว้ร่วมกันสร้างสัญญาที่เอเจนต์สามารถรันได้โดยไม่ต้องสิ้นเปลืองการเรียกใช้บนแบ็กเอนด์จริง จับคู่กับ คู่มือการทดสอบ API โดยไม่ต้องใช้ Postman สำหรับเวิร์กโฟลว์พื้นฐาน
5. การยืนยันตัวตนและความลับ
บอกเอเจนต์ว่า API ยืนยันตัวตนอย่างไร และ env var ตัวใดเก็บอะไรอยู่ ห้ามใส่ความลับจริงลงในไฟล์เด็ดขาด
## การยืนยันตัวตน
- Production ใช้ OAuth 2 client credentials ที่ออกโดย Auth0
- การพัฒนาในเครื่องใช้ dev token แบบคงที่; export `DEV_TOKEN` จาก `.env.local`
- Apidog collection ใช้ชื่อ env var เดียวกัน เพื่อให้ mock และ
real client ทำงานเหมือนกัน
- Tokens ห้ามคอมมิต; `.env.local` อยู่ใน `.gitignore`
6. กลยุทธ์การทดสอบ
จัดลำดับชั้นการทดสอบ เอเจนต์จะรันตามลำดับที่คุณระบุไว้
## การทดสอบ
1. `make test` สำหรับ unit tests รวดเร็ว รันทุกครั้งที่มีการเปลี่ยนแปลง
2. `make contract` สำหรับ OpenAPI contract tests กับ mock รันก่อน
ที่จะรวมการเปลี่ยนแปลงสเปกใดๆ
3. `make integration` สำหรับ end-to-end tests กับเซิร์ฟเวอร์โลคัลที่มี
Postgres จริง รันก่อนรวมเข้า main
4. Staging soak รันทุกคืนผ่าน GitHub Actions; ไม่ใช่คำสั่งโลคัล
7. รายการที่ห้ามแก้ไข
โค้ดที่สร้างขึ้น, dependencies ที่ถูกจัดหามา (vendored dependencies) และ migrations มักจะอยู่ในส่วนนี้
## ห้ามแก้ไขด้วยมือ
- `gen/**` (สร้างใหม่โดย `make codegen`)
- `vendor/**` (จัดการโดย `go mod vendor`)
- `migrations/*.up.sql` ที่เกินกว่า migration แรกที่ยังไม่ได้ใช้
- ชื่อฟิลด์ schema ใน `apis/payments/openapi.yaml` โดยไม่ได้รับการอนุมัติจากเจ้าของ
8. รูปแบบมาตรฐาน
สามถึงห้ากฎ หากมากกว่านั้นเอเจนต์จะเลือกกฎที่ผิด
## ข้อตกลง
- Error จะคืนค่า RFC 7807 problem JSON; ไม่ใช่สตริงเปล่า
- ใช้ snake_case ใน JSON, camelCase ใน Go, PascalCase ใน TS clients
Codegen จัดการการแมปให้
- Idempotency keys จำเป็นสำหรับ POST endpoints ทั้งหมดที่สร้างทรัพยากร
- ทุก endpoint ใหม่ต้องมีการทดสอบสัญญาที่ครอบคลุมทั้งพาธ 200 และ 4xx
ตัวอย่างที่เป็นรูปธรรม: ไฟล์ 90 บรรทัดที่ทำงานได้จริง
สิ่งล่อใจคือการเขียน 800 บรรทัด จงต้านทานมัน ไฟล์ด้านล่างครอบคลุมบริการ API จริงใน Markdown 90 บรรทัด และเพียงพอสำหรับเอเจนต์หลักใดๆ ที่จะทำงานได้อย่างมีประสิทธิภาพ
# โปรเจกต์: Payments API
บริการชำระเงินภายในสำหรับผลิตภัณฑ์ Acme ใช้ Go 1.23, Echo,
Postgres 17, Redis สำหรับ idempotency ผู้ใช้งานคือมือถือ, เว็บ,
และแบ็กเอนด์ของพาร์ทเนอร์
## คำสั่ง
| วัตถุประสงค์ | คำสั่ง |
|--------|---------|
| ติดตั้ง | `make deps` |
| รันเซิร์ฟเวอร์ | `make dev` |
| Unit tests | `make test` |
| Contract tests | `make contract` |
| Lint | `make lint` |
| สร้าง Clients ใหม่ | `make codegen` |
| Migrate DB | `make migrate` |
## แหล่งข้อมูลที่เชื่อถือได้
- สเปก: `apis/payments/openapi.yaml`
- Clients ที่สร้างขึ้น: `gen/clients/{go,ts,python}` (ห้ามแก้ไข)
- ขั้นตอนการแก้ไข: สเปก -> `make codegen` -> handler -> contract tests -> จัดส่ง
## เซิร์ฟเวอร์โลคัล
- เซิร์ฟเวอร์จริง: `make dev` (`http://127.0.0.1:8080`)
- Apidog mock: `make mock` (`http://127.0.0.1:4010`)
- Apidog collection: `apis/payments/apidog/`
## การยืนยันตัวตน
- Production: Auth0 OAuth 2 client credentials
- การพัฒนาในเครื่อง: `DEV_TOKEN` แบบคงที่จาก `.env.local`
## ลำดับการทดสอบ
1. `make test`
2. `make contract`
3. `make integration`
## ห้ามแก้ไขด้วยมือ
- `gen/**`, `vendor/**`
- Migrations ที่ใช้แล้วใน `migrations/`
- ชื่อฟิลด์สเปกโดยไม่ได้รับการอนุมัติจากเจ้าของ
## ข้อตกลง
- RFC 7807 problem JSON สำหรับข้อผิดพลาด
- snake_case JSON, codegen จัดการการแมปภาษา
- Idempotency keys จำเป็นสำหรับการสร้างด้วย POST
- ทุก endpoint ใหม่มาพร้อมกับการทดสอบสัญญา
เท่านี้ก็เพียงพอแล้ว เพิ่มส่วนต่างๆ ก็ต่อเมื่อเอเจนต์ทำผิดพลาดแบบเดิมซ้ำสองครั้ง
การทำให้ไฟล์อัปเดตอยู่เสมอ
ไฟล์ AGENTS.md ที่ล้าสมัยนั้นแย่กว่าไม่มีไฟล์เลย เอเจนต์จะเชื่อมันและส่งมอบโค้ดตามคำสั่ง Build ที่ใช้งานไม่ได้อีกต่อไป
สามนิสัยที่ช่วยให้มันอัปเดตอยู่เสมอ:
- ปฏิบัติต่อมันเหมือนโค้ดสำหรับใช้งานจริง. การเปลี่ยนแปลงต้องผ่านการรีวิวแบบเดียวกับ PR อื่นๆ ผู้รีวิวจะตรวจสอบว่ารายการคำสั่งตรงกับ
Makefileจริง - เชื่อมต่อเข้ากับ CI. สคริปต์สั้นๆ ที่แยกวิเคราะห์ตารางคำสั่งและรันแต่ละคำสั่งบน fresh checkout จะช่วยตรวจจับการเปลี่ยนแปลงได้อย่างรวดเร็ว ทีมส่วนใหญ่เขียนสิ่งนี้ใน Bash ประมาณ 30 บรรทัด
- อัปเดตมันใน PR เดียวกัน. เมื่อคุณเพิ่มคำสั่งทดสอบใหม่ อย่าสัญญาว่าจะอัปเดต
AGENTS.mdทีหลัง อัปเดตมันตอนนี้เลย ค่าใช้จ่ายคือสองนาที; ค่าใช้จ่ายของการข้ามคือความสับสนของเอเจนต์สองสัปดาห์
Apidog ในฐานะสัญญาสำหรับการรันสำหรับ AGENTS.md ของคุณ
AGENTS.md ให้บริบทกับเอเจนต์ OpenAPI spec ให้สัญญา Apidog ทำหน้าที่เชื่อมโยงทั้งสอง: มันอ่านสเปก รัน mock โลคัลที่ URL ที่ระบุใน AGENTS.md เล่นตัวอย่างคำขอที่บันทึกไว้สำหรับการทดสอบซ้ำ และให้เอเจนต์เห็นการตอบกลับจริงโดยไม่ต้องสิ้นเปลืองเครดิตกับแบ็กเอนด์ที่ใช้งานจริง
รูปแบบที่ใช้งานได้:
- คอมมิต
apis/<service>/openapi.yamlและapis/<service>/apidog/(collection ที่ส่งออก) - ระบุ mock URL และคำสั่ง
make mockในAGENTS.md - เอเจนต์รัน
make contractสำหรับการทดสอบอย่างรวดเร็วกับตัวอย่างที่บันทึกไว้ - เมื่อสเปกเปลี่ยนแปลง เอเจนต์จะสร้าง clients ใหม่ รันชุดการทดสอบสัญญา และหลังจากนั้นจึงจะเข้าถึงเซิร์ฟเวอร์จริง
สำหรับการเจาะลึกเวิร์กโฟลว์ Apidog mock กับ API จริง คู่มือ DeepSeek V4 API ครอบคลุมรูปแบบเดียวกันที่นำไปใช้กับ model API แทน service API
ข้อผิดพลาดทั่วไปที่ทีม API มักทำ
หลังจากตรวจสอบไฟล์เหล่านี้หลายสิบไฟล์ ปัญหาห้าประการเดิมๆ ก็ปรากฏขึ้น:
- ลิงก์แทนการแสดงรายการ. “ดู Wiki สำหรับคำสั่ง Build” เอเจนต์ไม่ได้เรียกดู Wiki ใส่อินไลน์คำสั่งลงไป
- ภาษาที่เน้นการตลาด. “แพลตฟอร์ม API ระดับโลกของเราช่วยเสริมพลัง…” เอเจนต์ไม่ต้องการการนำเสนอ บอกข้อเท็จจริงไปเลย
- คำสั่งที่ล้าสมัย. คำสั่งที่ใช้งานไม่ได้ในเดือนมีนาคมยังคงอยู่ในไฟล์ในเดือนเมษายน เชื่อมต่อ CI เพื่อตรวจจับสิ่งนี้
- ขาดส่วนของสเปก. นี่คือบล็อกที่มีประโยชน์ที่สุด ควรใส่ไว้เสมอ
- ไม่มีรายการห้ามแก้ไข. เอเจนต์แก้ไขโค้ดที่สร้างขึ้น การรัน codegen ครั้งถัดไปจะลบการแก้ไข Build เสียหาย ทำซ้ำ
หากคุณต้องการเริ่มต้นจากพื้นฐาน ให้คัดลอกตัวอย่างด้านบนลงในรีโพของคุณ แก้ไขสรุปโปรเจกต์ และปรับตารางคำสั่ง คุณสามารถส่งมอบไฟล์ที่ใช้งานได้ภายใน 20 นาที
คำถามที่พบบ่อย
AGENTS.md เหมือนกับ CLAUDE.md หรือไม่?รูปแบบเข้ากันได้ ทีมส่วนใหญ่จะเก็บไฟล์ใดไฟล์หนึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้และทำ symlink อีกไฟล์หนึ่ง Anthropic และ OpenAI ได้ตกลงร่วมกันในการรักษารูปแบบให้สามารถทำงานร่วมกันได้
ฉันควรวางไฟล์ไว้ที่ไหน? ควรวางไว้ที่ root ของรีโพเสมอ เอเจนต์บางตัวยังอ่านไฟล์ AGENTS.md ที่ซ้อนกันในไดเรกทอรีย่อยได้ ซึ่งมีประโยชน์สำหรับ monorepos เริ่มต้นด้วยไฟล์ระดับ root เพียงไฟล์เดียว และเพิ่มไฟล์ในไดเรกทอรีย่อยเมื่อไฟล์ระดับ root ไฟล์เดียวเริ่มยาวเกินไป
ควรมีความยาวเท่าไร? 200 ถึง 400 บรรทัดคือจุดที่เหมาะสม หากยาวกว่านั้นเอเจนต์จะเริ่มข้ามส่วนต่างๆ หากคุณต้องการรายละเอียดเพิ่มเติม ให้ลิงก์ไปยังเอกสารแยกต่างหากพร้อมสรุปแบบหนึ่งบรรทัด
ฉันควรใส่ตัวอย่างโค้ดหรือไม่? ตัวอย่างสั้นๆ ได้ ตัวอย่างยาวๆ ไม่ได้ เก็บตัวอย่างเต็มไว้สำหรับการทดสอบ; เอเจนต์ก็อ่านการทดสอบด้วยเช่นกัน คู่มือ GPT-5.5 free Codex ครอบคลุมวิธีการที่ Codex ใช้ตัวอย่างการทดสอบเป็นสัญญาณเพิ่มเติมโดยเฉพาะ
เอเจนต์อ่านไฟล์ซ้ำทุกครั้งที่ทำงานหรือไม่? เอเจนต์ส่วนใหญ่อ่านไฟล์เมื่อเริ่มต้นเซสชันและแคชไว้ บางตัวอ่านซ้ำหลังจากมีการเปลี่ยนแปลงไฟล์ขนาดใหญ่ หากคุณแก้ไขครั้งใหญ่ การรีสตาร์ทเซสชันเอเจนต์คือวิธีที่ปลอดภัยที่สุด
ฉันจะทดสอบได้อย่างไรว่าไฟล์ของฉันทำงานได้? รันเซสชันเอเจนต์ใหม่โดยไม่มีบริบทอื่น ให้งานเล็กๆ น้อยๆ แก่เอเจนต์ (“เพิ่มการตอบกลับ 422 ไปยัง POST /payments”) และดูว่ามันทำอะไร หากมันอ่านสเปก รัน `make codegen` และเขียนการทดสอบสัญญา ไฟล์นั้นก็กำลังทำงานตามที่ตั้งใจไว้