วิธีใช้ Claude Code Skills สร้างเอกสาร

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

💡

เอกสารทางเทคนิคทำให้คุณช้าลงใช่ไหม? รวม Claude Code เข้ากับ Apidog เพื่อความครอบคลุมของเอกสารที่สมบูรณ์ การตรวจสอบข้อความที่ขับเคลื่อนด้วย AI + การตรวจสอบ API ด้วยภาพ ลองใช้ฟรีทั้งสองอย่าง: claude.ai และ apidog.com จัดทำเอกสารอย่างชาญฉลาดขึ้น

Claude Code Skills แก้ไขปัญหานี้อย่างเป็นระบบ เวิร์กโฟลว์ที่ขับเคลื่อนด้วย AI เหล่านี้จะตรวจสอบที่เก็บเอกสารทั้งหมดของคุณ ระบุช่องว่างและความไม่สอดคล้องกัน และใช้การแก้ไขโดยตรง คุณอธิบายสิ่งที่จะต้องตรวจสอบ และ Claude จะสร้างการตรวจสอบที่มีโครงสร้าง ใช้การปรับปรุง และตรวจสอบความสมบูรณ์ทั้งหมดจากเทอร์มินัลของคุณ

เอกสารทางเทคนิคครอบคลุมถึงข้อกำหนด API, คู่มือผู้ใช้, คู่มือการปรับใช้ และบันทึกการเผยแพร่ Claude Code ทำให้การตรวจสอบทั้งหมดเป็นไปโดยอัตโนมัติ สำหรับเอกสาร API โดยเฉพาะ ให้รวมเข้ากับ Apidog เพื่อการตรวจสอบด้วยภาพและการให้คะแนนความสมบูรณ์

ทำความเข้าใจเกี่ยวกับ Claude Code Skills สำหรับเอกสาร

ทักษะการจัดทำเอกสารคืออะไร?

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

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

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

ทักษะทำงานอย่างไร

ทักษะทำงานผ่านกลไกหลายอย่าง:

1. คำสั่งที่ผู้ใช้เรียกใช้ได้

# Run a skill with a slash command
/review-docs --completeness
/check-consistency --terminology
/validate-api-specs
/update-broken-examples

2. เครื่องมือที่อนุญาต

ทักษะระบุเครื่องมือที่สามารถใช้ได้:

Bash: รันคำสั่งตรวจสอบ
Read, Write, Edit: จัดการไฟล์เอกสาร
Glob, Grep: ค้นหาในเอกสาร
WebFetch: ดึงข้อมูลอ้างอิงภายนอก
Task: สร้างงานย่อยสำหรับการตรวจสอบที่ซับซ้อน

3. ไฟล์การวางแผน

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

ทำไมทักษะจึงโดดเด่นในการตรวจสอบเอกสาร

การตรวจสอบเอกสารแบบดั้งเดิมเป็นแบบใช้คนและไม่สอดคล้องกัน ทักษะนำมาซึ่งความชาญฉลาดและขอบเขต:

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

ความสามารถหลักในการตรวจสอบเอกสาร

1. การวิเคราะห์ความสมบูรณ์

คำสั่ง: "ตรวจสอบเอกสาร API เพื่อความสมบูรณ์ ตรวจสอบแต่ละเอนด์พอยต์สำหรับ: พารามิเตอร์, ตัวอย่างคำขอ, การตอบสนองข้อผิดพลาดทั้งหมด และการจำกัดอัตรา (rate limiting)"

Claude สร้าง:

Missing from POST /users endpoint:
- [ ] Request body parameter descriptions
- [ ] Error response documentation (400, 401, 409)
- [ ] Rate limiting information
- [ ] Security/authentication requirements

2. การตรวจจับความสอดคล้อง

คำสั่ง: "ตรวจสอบ /docs/ เพื่อความสอดคล้องของคำศัพท์ ระบุคำใดๆ ที่ปรากฏหลายครั้งแต่มีความหมายต่างกัน"

Claude ระบุ:

Inconsistent terminology found:
- "API key" vs "access token" vs "auth token" (use one)
- "endpoint" vs "route" vs "method" (use one)
- "user object" vs "user resource" (use one)

3. การตรวจสอบการอ้างอิงข้าม

คำสั่ง: "เปรียบเทียบข้อกำหนด OpenAPI ใน /api/openapi.yaml กับเอกสารใน /docs/api/ ระบุเอนด์พอยต์ใดๆ ในโค้ดที่ไม่ได้บันทึกไว้ หรือบันทึกไว้แต่ไม่มีในโค้ด"

Claude ตรวจพบ:

Discrepancies found:
- POST /api/webhooks documented but not in openapi.yaml
- PATCH /api/users exists in code but missing from docs
- Response schema changed but example not updated

4. การประเมินความชัดเจน

คำสั่ง: "ตรวจสอบความชัดเจน ระบุคำอธิบายที่คลุมเครือ, คำศัพท์ที่ไม่ได้กำหนดไว้, และคำแนะนำที่ไม่ชัดเจน"

Claude ระบุ:

Clarity issues:
- Line 45: "Set config to appropriate values" - what values?
- Line 120: "user object" used without schema definition
- Line 200: "required fields" - which ones?

5. การตรวจสอบตัวอย่าง

คำสั่ง: "ตรวจสอบตัวอย่างโค้ดทั้งหมด ทดสอบกับสคีมา API ปัจจุบัน ระบุตัวอย่างที่เสียหรือล้าสมัย"

Claude อัปเดต:

Updated examples:
- curl example: Response format changed, updated payload
- Python example: Using deprecated parameter, fixed
- JavaScript example: Missing error handling, added

โครงสร้างทักษะการจัดทำเอกสาร

โครงสร้างไดเรกทอรี

ทักษะการจัดทำเอกสารอยู่ใน .claude/skills/ พร้อมโครงสร้างดังนี้:

.claude/
├── skills/
│   ├── docs-completeness/
│   │   ├── SKILL.md              # รายการทักษะ
│   │   ├── planning.md           # ความคืบหน้าการตรวจสอบ
│   │   └── criteria.md           # รายการตรวจสอบคุณภาพ
│   ├── api-validation/
│   │   ├── SKILL.md
│   │   └── schemas/              # สคีมา API
│   └── consistency-check/
│       └── SKILL.md
└── skills.md                     # ดัชนีทักษะทั้งหมด

รายการ SKILL.md

ทักษะการจัดทำเอกสารทุกอย่างเริ่มต้นด้วย YAML frontmatter:

---
name: docs-completeness
version: "1.0.0"
description: ตรวจสอบเอกสารเพื่อความสมบูรณ์และความชัดเจน
user-invocable: true
allowed-tools:
  - Read
  - Write
  - Grep
  - Glob
  - Edit
hooks:
  SessionStart:
    - matcher: command
      command: "echo '[ตรวจสอบเอกสาร] เริ่มการตรวจสอบเอกสาร...'"
  Stop:
    - matcher: command
      command: "echo '[ตรวจสอบเอกสาร] การตรวจสอบเสร็จสมบูรณ์ ตรวจสอบผลลัพธ์ด้านบน'"
---

# ทักษะความสมบูรณ์ของเอกสาร

ตรวจสอบเอกสารทางเทคนิคเพื่อความสมบูรณ์และความชัดเจน

## การใช้งาน

```bash
/docs-completeness                # การตรวจสอบที่เก็บข้อมูลทั้งหมด
/docs-completeness --api-only    # เอกสาร API เท่านั้น
/docs-completeness --section api/endpoints.md  # ไฟล์เฉพาะ

คำแนะนำสำหรับ Claude

เมื่อถูกเรียกใช้:

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

การสร้างทักษะการจัดทำเอกสารครั้งแรกของคุณ

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

ขั้นตอนที่ 1: ตั้งค่าโฟลเดอร์ทักษะ

สร้างโครงสร้างด้วยคำสั่งง่ายๆ ทักษะของ Claude อยู่ในตำแหน่งเฉพาะเพื่อให้ค้นหาได้ง่าย

Bash

mkdir -p .claude/skills/api-docs-review

ขั้นตอนที่ 2: เขียนรายการทักษะ

สร้าง .claude/skills/api-docs-review/SKILL.md:

---
name: api-docs-review
version: "1.0.0"
description: ตรวจสอบเอกสาร API เพื่อความสมบูรณ์
user-invocable: true
allowed-tools:
  - Read
  - Write
  - Grep
  - Edit
---

# ทักษะการตรวจสอบเอกสาร API

ตรวจสอบเอกสาร API เพื่อความสมบูรณ์ ความชัดเจน และความถูกต้อง

## เกณฑ์การตรวจสอบ

แต่ละเอนด์พอยต์ต้องมี:

**ข้อมูลพื้นฐาน**
* คำอธิบายที่ชัดเจนว่าเอนด์พอยต์ทำอะไร
* เมธอดและพาธ HTTP
* ข้อกำหนดการรับรองความถูกต้อง

**เอกสารคำขอ**
* พารามิเตอร์พาธทั้งหมดพร้อมประเภทและคำอธิบาย
* พารามิเตอร์คิวรีทั้งหมดพร้อมค่าเริ่มต้นและข้อจำกัด
* สคีมาเนื้อหาคำขอ (สำหรับ POST/PUT/PATCH)
* ข้อกำหนดส่วนหัว Content-Type
* ตัวอย่างคำขอ (curl หรือเฉพาะภาษา)

**เอกสารการตอบกลับ**
* การตอบกลับที่สำเร็จ (200/201) พร้อมสคีมาและตัวอย่าง
* การตอบกลับข้อผิดพลาดทั้งหมด (400, 401, 403, 404, 409, 429, 500) พร้อมตัวอย่าง
* ข้อมูลการจำกัดอัตรา
* ส่วนหัวการตอบกลับ (ถ้าเกี่ยวข้อง)

**เพิ่มเติม**
* เอนด์พอยต์หรือคู่มือที่เกี่ยวข้อง
* ประวัติเวอร์ชันหากมี
* คำเตือนการเลิกใช้งาน (หากเลิกใช้งานแล้ว)

## คำแนะนำ

เมื่อถูกเรียกใช้:

1. **สแกนไฟล์เอนด์พอยต์** ใน /docs/api/
2. **ตรวจสอบแต่ละเอนด์พอยต์** เทียบกับเกณฑ์การตรวจสอบ
3. **บันทึกรายการที่ขาดหายไป** พร้อมการอ้างอิงไฟล์/บรรทัดที่เฉพาะเจาะจง
4. **ระบุปัญหาความชัดเจน** (คำอธิบายที่คลุมเครือ, คำศัพท์ที่ไม่ได้กำหนด)
5. **ระบุปัญหาความสอดคล้อง** (การเปลี่ยนแปลงคำศัพท์, ความแตกต่างของรูปแบบ)
6. **สร้างรายการตรวจสอบ** ของการแก้ไขที่จำเป็น
7. **เสนอการใช้การแก้ไข** พร้อมตัวอย่าง

รูปแบบรายงาน:

เอนด์พอยต์: POST /api/users ไฟล์: docs/api/users.md สถานะ: สมบูรณ์ 65%

ขาดหายไป:

[ ] เอกสารการตอบกลับข้อผิดพลาด (400, 401, 409)
[ ] ข้อมูลการจำกัดอัตรา
[ ] คำจำกัดความของสคีมาเนื้อหาคำขอ

ปัญหา:

บรรทัดที่ 45: "user object" ไม่ได้กำหนด - เพิ่มลิงก์ไปยังสคีมา
บรรทัดที่ 60: ตัวอย่างล้าสมัย - รูปแบบการตอบกลับเปลี่ยนไป

มีแก้ไข: ใช่ (ขอให้ดำเนินการ)

ขั้นตอนที่ 3: ลงทะเบียนทักษะ

เพิ่มลงใน .claude/skills.md:

# ทักษะการจัดทำเอกสารที่มีอยู่

## เอกสาร API

### /api-docs-review
ตรวจสอบเอกสาร API เพื่อความสมบูรณ์ตามเกณฑ์มาตรฐาน
- **เวอร์ชัน**: 1.0.0
- **การใช้งาน**: `/api-docs-review [--file PATH] [--endpoint NAME]`
- **เมื่อใดควรใช้**: ก่อนเผยแพร่ API, หลังการเปลี่ยนแปลงโค้ด
- **เวลา**: 5-10 นาทีสำหรับ API ขนาดกลาง

ขั้นตอนที่ 4: ทดสอบทักษะ

# ใน Claude Code
/api-docs-review

ตอนนี้ Claude จะตรวจสอบเอกสาร API ของคุณอย่างเป็นระบบ

รูปแบบเอกสารขั้นสูง

รูปแบบที่ 1: การติดตามเอกสารตามเวอร์ชัน

ทักษะสามารถติดตามคุณภาพของเอกสารในเวอร์ชันต่างๆ ได้:

## ประวัติเวอร์ชัน

### v2.0.0 [2026-01-22]
ความสมบูรณ์: 95% ✅
- เอกสารเอนด์พอยต์ทั้งหมด
- การตอบกลับข้อผิดพลาดสมบูรณ์
- ตัวอย่างได้รับการอัปเดต
- เอนด์พอยต์ /v1 ที่เลิกใช้งานแล้วถูกทำเครื่องหมาย

### v1.0.0 [2025-12-01]
ความสมบูรณ์: 70%
- เอกสารข้อผิดพลาดที่ขาดหายไป
- ตัวอย่างที่ล้าสมัย
- ไม่มีคำเตือนการเลิกใช้งาน

Claude ตรวจพบการปรับปรุงเมื่อเวลาผ่านไป

รูปแบบที่ 2: การตรวจสอบข้อกำหนด API เทียบกับโค้ด

ทักษะสามารถตรวจสอบว่าข้อกำหนด OpenAPI ตรงกับการใช้งานจริงหรือไม่:

## การตรวจสอบข้อกำหนด

เปรียบเทียบ /api/openapi.yaml กับโค้ด:

1. **สแกนการใช้งาน** สำหรับทุกเส้นทาง
2. **ตรวจสอบข้อกำหนด OpenAPI** สำหรับแต่ละเส้นทาง
3. **ระบุ** เอนด์พอยต์ที่ขาดหายไป
4. **ยืนยันพารามิเตอร์** ตรงกับการใช้งาน
5. **อัปเดตตัวอย่าง** ให้ตรงกับสคีมาปัจจุบัน

ผลลัพธ์: ข้อกำหนด 100% ตรงกับโค้ด

การทำงานอัตโนมัติด้วย CI/CD

ไปป์ไลน์การตรวจสอบเอกสาร

ตั้งค่าการตรวจสอบอัตโนมัติในการอัปเดตเอกสารทุกครั้ง:

# .github/workflows/docs-check.yml
name: ตรวจสอบเอกสาร

on:
  push:
    paths:
      - 'docs/**'
      - 'api/openapi.yaml'
  pull_request:
    paths:
      - 'docs/**'
      - 'api/openapi.yaml'

jobs:
  validate-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: ติดตั้ง Apidog CLI
        run: npm install -g apidog-cli

      - name: ตรวจสอบ OpenAPI Spec
        run: |
          apidog lint api/openapi.yaml
          apidog check-completeness api/openapi.yaml --min-score 85

      - name: ตรวจสอบลิงก์เสีย
        run: |
          npm install -g markdown-link-check
          find docs -name "*.md" -exec markdown-link-check {} \;

      - name: ตรวจสอบตัวอย่างที่ถูกต้อง
        run: |
          # ทดสอบตัวอย่าง curl ทำงาน
          bash scripts/test-curl-examples.sh

      - name: แสดงความคิดเห็นบน PR
        if: failure()
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '❌ การตรวจสอบเอกสารล้มเหลว โปรดตรวจสอบบันทึกเวิร์กโฟลว์'
            })

สถานการณ์จริง: ความสมบูรณ์ของเอกสาร API

มาตรวจสอบชุดเอกสาร API ที่สมจริงเพื่อความสมบูรณ์และนำการปรับปรุงมาใช้

สถานการณ์

คุณมีเอกสาร REST API ที่มีอายุ 6 เดือน มันไม่สมบูรณ์บางส่วน แต่ขาดเอกสารข้อผิดพลาด ไม่ชัดเจนในบางจุด และมีตัวอย่างที่ล้าสมัย

การตรวจสอบ

คำสั่งถึง Claude: "ตรวจสอบเอกสารใน /docs/api/ สำหรับแต่ละเอนด์พอยต์ ให้ตรวจสอบ: คำอธิบาย, พารามิเตอร์คำขอ, ตัวอย่างการตอบกลับ, และการตอบกลับข้อผิดพลาดทั้งหมด จัดลำดับความสำคัญของการแก้ไขตามผลกระทบ"

ผลการตรวจสอบ
=============

วิกฤติ (เอกสารข้อผิดพลาดขาดหายไป):
├── POST /api/users - การตอบกลับข้อผิดพลาด 400, 401, 409 ขาดหายไป
├── POST /api/auth/login - การตอบกลับ 429 (rate limit) ขาดหายไป
└── DELETE /api/resources/{id} - การตอบกลับ 403 (ถูกห้าม) ขาดหายไป

สูง (ปัญหาความชัดเจน):
├── users.md:45 - "user object" ไม่ได้กำหนด
├── auth.md:60 - "ตั้งค่าวันหมดอายุให้เหมาะสม" - คลุมเครือเกินไป
└── resources.md:30 - คำอธิบายรูปแบบ pagination cursor ขาดหายไป

ปานกลาง (ตัวอย่างล้าสมัย):
├── products.md:120 - ตัวอย่าง cURL คืนค่ารูปแบบเก่า
├── orders.md:80 - ตัวอย่าง Python SDK ใช้พารามิเตอร์ที่เลิกใช้งานแล้ว
└── webhooks.md:60 - ตัวอย่าง Node.js ขาดการจัดการข้อผิดพลาด

ความสอดคล้อง:
├── "API key" เทียบกับ "access token" - ไม่สอดคล้องกัน 5 จุด
├── รูปแบบเนื้อหาคำขอ - 3 สไตล์ที่แตกต่างกันในแต่ละเอนด์พอยต์
└── สคีมาการตอบกลับข้อผิดพลาด - 2 รูปแบบแทนที่จะเป็น 1

การแก้ไขที่สำคัญ: รวม 15 รายการ
ประมาณการความพยายาม: 2-3 ชั่วโมงด้วยตนเอง, 15 นาทีด้วย Claude Code

การปรับปรุง

ใช้การแก้ไขอย่างเป็นระบบ:

ก่อน - POST /api/users (ไม่สมบูรณ์):

## สร้างผู้ใช้

POST /api/users

สร้างผู้ใช้ใหม่

**พารามิเตอร์:**
- name: ชื่อผู้ใช้
- email: อีเมลผู้ใช้

**การตอบกลับ:**
```json
{
  "id": "usr_123",
  "name": "Alice",
  "email": "alice@example.com"
}

หลัง - POST /api/users (สมบูรณ์):

## สร้างผู้ใช้

`POST /api/users`

สร้างบัญชีผู้ใช้ใหม่ด้วยรายละเอียดที่ให้มา อีเมลจะต้องไม่ซ้ำกัน

### การรับรองความถูกต้อง

ต้องใช้ API key ในส่วนหัว `Authorization`: `Bearer YOUR_API_KEY`

### พารามิเตอร์คำขอ

| พารามิเตอร์ | ชนิด | จำเป็น | คำอธิบาย |
|-----------|------|----------|-------------|
| `name` | string | ใช่ | ชื่อเต็ม (2-100 ตัวอักษร) |
| `email` | string | ใช่ | อีเมลที่ถูกต้อง (ต้องไม่ซ้ำกัน) |
| `role` | string | ไม่ใช่ | บทบาท: `admin`, `developer`, `viewer` ค่าเริ่มต้น: `viewer` |

### ตัวอย่างคำขอ

```bash
curl -X POST https://api.example.com/v1/users \
  -H "Authorization: Bearer sk_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alice Smith",
    "email": "alice@example.com",
    "role": "developer"
  }'

การตอบกลับ (201 Created)

{
  "id": "usr_abc123",
  "name": "Alice Smith",
  "email": "alice@example.com",
  "role": "developer",
  "created_at": "2026-01-22T10:30:00Z"
}

การตอบกลับข้อผิดพลาด

400 Bad Request - อินพุตไม่ถูกต้อง

{
  "error": "validation_error",
  "message": "Invalid email format",
  "field": "email",
  "request_id": "req_xyz789"
}

401 Unauthorized - API key หายไป/ไม่ถูกต้อง

{
  "error": "unauthorized",
  "message": "Invalid API key",
  "request_id": "req_xyz789"
}

409 Conflict - อีเมลมีอยู่แล้ว

{
  "error": "conflict",
  "message": "User with this email already exists",
  "request_id": "req_xyz789"
}

429 Too Many Requests - ถูกจำกัดอัตรา

{
  "error": "rate_limited",
  "message": "Too many requests. Try again in 60 seconds.",
  "retry_after": 60,
  "request_id": "req_xyz789"
}

การจำกัดอัตรา

100 คำขอต่อนาทีต่อ API key ดู การจำกัดอัตรา

การปรับปรุงที่ใช้:- เพิ่มข้อกำหนดการรับรองความถูกต้อง - บันทึกพารามิเตอร์ทั้งหมดพร้อมข้อจำกัด - การตอบกลับที่สำเร็จสมบูรณ์ + การตอบกลับข้อผิดพลาดทั้งหมด - ตัวอย่าง cURL ที่พร้อมใช้งานในสภาพแวดล้อมจริง - ข้อมูลการจำกัดอัตรา - รูปแบบที่สอดคล้องกัน

การผสานรวม Claude กับ Apidog เพื่อเอกสาร API ที่เหนือกว่า

💡 เคล็ดลับมือโปร: ใช้ประโยชน์จาก Claude สำหรับการตรวจสอบเอกสารบรรยายเชิงลึก ในขณะที่ Apidog ช่วยให้มั่นใจว่าข้อกำหนด API ของคุณแข็งแกร่งและเติมเต็มช่องว่างโดยอัตโนมัติด้วยตัวอย่างที่เป็นประโยชน์

คำสั่งแนะนำสำหรับ Claude:"ตรวจสอบ /docs/api/ เพื่อความชัดเจนและการมีส่วนร่วมโดยรวม ถัดไป ให้ตรวจสอบความสมบูรณ์ของไฟล์ /api/openapi.yaml โดยใช้ Apidog ระบุความไม่สอดคล้องกันหรือองค์ประกอบที่ขาดหายไป เพื่อที่ฉันจะได้แก้ไขได้โดยตรงใน Apidog ก่อนดำเนินการต่อ"

Bash

# ขั้นตอนที่ 1: การตรวจสอบข้อความเบื้องต้นผ่าน Claude
> /docs-completeness  # แสดงคำแนะนำสำหรับภาษาและโครงสร้างที่ชัดเจนขึ้น

# ขั้นตอนที่ 2: การตรวจสอบ OpenAPI Spec ใน Apidog
apidog check-completeness api/openapi.yaml  # ระบุปัญหาเช่นสคีมาไม่สมบูรณ์หรือการตอบกลับที่ขาดหายไป

# ขั้นตอนที่ 3: สร้างเนื้อหาอัตโนมัติด้วย AI ของ Apidog
# (ผ่าน Apidog UI: การตั้งค่า → AI → สร้างคำอธิบาย ตัวอย่าง และสรุปโดยอัตโนมัติ)

# ขั้นตอนที่ 4: การตรวจสอบความสอดคล้องขั้นสุดท้ายกับ Claude
> /consistency-check  # ตรวจสอบให้แน่ใจว่าเอกสารและข้อกำหนดสอดคล้องกันอย่างสมบูรณ์

สิ่งนี้สร้างเวิร์กโฟลว์ที่ Apidog จัดการการตรวจสอบข้อกำหนดที่มีโครงสร้าง และ Claude Code จัดการคุณภาพของข้อความ

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบเอกสาร

รู้จักกลุ่มเป้าหมายของคุณ

ปรับความลึกของเอกสารให้เหมาะสมกับผู้อ่าน:

กลุ่มเป้าหมาย	สไตล์	ตัวอย่าง
นักพัฒนา	ตัวอย่างโค้ดในหลายภาษา	cURL, Python, JS
DevOps	ขั้นตอนการปรับใช้, การกำหนดค่า	ตัวอย่าง Kubernetes YAML
ทีมผลิตภัณฑ์	เวิร์กโฟลว์ระดับสูง, แผนภาพ	โฟลว์คุณสมบัติพร้อมภาพหน้าจอ
ฝ่ายสนับสนุน	การแก้ไขปัญหา, ปัญหาทั่วไป	"Error 429 หมายถึง..."

ให้ความสำคัญกับความชัดเจน

เขียนด้วยเสียงกระทำ (active voice) จัดโครงสร้างเพื่อให้สแกนได้ง่าย:

❌ ก่อน: "คำขอถูกส่งผ่าน POST การตอบกลับจะมีผู้ใช้"
✅ หลัง: "ส่งคำขอ POST เพื่อสร้างผู้ใช้ API จะคืนค่าผู้ใช้ใหม่"

รวมตัวอย่างเสมอ

แนวคิดนามธรรมต้องการการอ้างอิง เอนด์พอยต์ API ทุกรายการต้องการ:

# ✅ พร้อมคัดลอกและวาง
curl -X GET https://api.example.com/v1/users/usr_123 \
  -H "Authorization: Bearer YOUR_API_KEY"

ข้อผิดพลาดทั่วไป

ข้อผิดพลาด	วิธีแก้ไข
ศัพท์เฉพาะมากเกินไป	กำหนดคำศัพท์เมื่อใช้ครั้งแรก
ตัวอย่างที่ล้าสมัย	ทดสอบใน CI/CD
เอกสารข้อผิดพลาดที่ขาดหายไป	บันทึกโค้ดข้อผิดพลาดทั้งหมด
รูปแบบที่ไม่สอดคล้องกัน	ใช้แม่แบบ
ลิงก์เสีย	ตรวจสอบใน CI/CD

สรุป

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

เมื่อรวมกับ Apidog สำหรับการตรวจสอบข้อกำหนด API คุณจะได้รับความครอบคลุมของเอกสารที่สมบูรณ์

ปุ่ม