วิธีอัปเดตเอกสารประกอบโดยอัตโนมัติในทุกการปล่อยเวอร์ชัน

อัปเดตเมื่อ 3 พฤศจิกายน 2026

หากต้องการอัปเดตเอกสารประกอบโดยอัตโนมัติในทุกการปล่อยเวอร์ชัน ให้เริ่มงานด้านเอกสารจากการปล่อยเวอร์ชันนั้นๆ ไม่ว่าจะเป็น GitHub release ที่เผยแพร่แล้ว, เหตุการณ์ GitLab release, แท็ก Bitbucket หรือรายการใหม่ในหน้า changelog สาธารณะ งานนี้จะอ่านบันทึกการปล่อยเวอร์ชัน ค้นหาหน้าช่วยเหลือและวิดีโอที่ได้รับผลกระทบ ร่างการเปลี่ยนแปลง และส่งให้บุคคลตรวจสอบเพื่ออนุมัติ สำหรับเอกสารที่ลูกค้าใช้งาน ขั้นตอนการตรวจสอบนี้คือสิ่งที่ทำให้ระบบอัตโนมัติของเอกสารมีความปลอดภัย

คู่มือนี้จะแนะนำขั้นตอนการทำงานดังกล่าวโดยใช้เครื่องมือใดก็ได้ก่อน (GitHub Actions, GitLab, Bitbucket, หน้า changelog) จากนั้นจะแสดงให้เห็นว่า Autopilot ของ Clevera ทำงานในลูปเดียวกันสำหรับศูนย์ช่วยเหลือที่มีวิดีโอได้อย่างไร

เอกสารประกอบแบบต่อเนื่อง (Continuous Documentation) คืออะไร?#

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

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

เหตุผลที่ต้องใช้ระบบอัตโนมัติคือความเร็ว งานวิจัย State of DevOps ปี 2021 ของ DORA พบว่า ทีมระดับแนวหน้ามีการปรับใช้บ่อยกว่าทีมที่มีประสิทธิภาพต่ำถึง 973 เท่า ไม่ใช่ทุกการปรับใช้จะเปลี่ยนสิ่งที่ผู้อ่านเห็น แต่ทีมต่างๆ ปล่อยงานบ่อยกว่าที่ใครจะมานั่งตรวจสอบบทความด้วยมือ งานวิจัยเดียวกันพบว่า ทีมที่มีเอกสารคุณภาพสูงมีแนวโน้มที่จะนำแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยไปใช้มากกว่าถึง 3.8 เท่า ดังนั้นเอกสารจึงไม่ใช่เรื่องรอง และเอกสารที่ล้าสมัยเป็นเรื่องปกติ: ในการสำรวจ Open Source ปี 2017 ของ GitHub 93% ของผู้ตอบแบบสอบถามเคยพบเอกสารที่ไม่สมบูรณ์หรือล้าสมัย และ 60% ของผู้มีส่วนร่วมกล่าวว่าพวกเขาแทบไม่เคยหรือไม่มีส่วนร่วมในเอกสารเลย

ขั้นตอนที่ 1: เขียนบันทึกการปล่อยเวอร์ชันที่งานด้านเอกสารนำไปใช้ได้#

ระบบอัตโนมัติจะอัปเดตเอกสารได้ดีเท่ากับที่บันทึกการปล่อยเวอร์ชันอธิบายการเปลี่ยนแปลงนั้นๆ สองธรรมเนียมปฏิบัติที่ช่วยได้มีดังนี้

• จัดกลุ่มการเปลี่ยนแปลงตามประเภท Keep a Changelog ใช้ Added, Changed, Deprecated, Removed, Fixed และ Security โดย "Added" มักหมายถึงบทความหรือวิดีโอใหม่ ส่วน "Changed" และ "Removed" หมายถึงเนื้อหาที่มีอยู่เดิมไม่ถูกต้องแล้ว
• แยกสิ่งที่ผู้ใช้เห็นออกจากสิ่งที่ไม่เห็น บันทึกการปล่อยเวอร์ชันที่สร้างอัตโนมัติ ของ GitHub จะจัดเรียงพูลรีเควสต์ที่รวมแล้วตามป้ายกำกับใน .github/release.yml และสามารถแยกป้ายกำกับออกไปได้ทั้งหมด

# .github/release.yml
changelog:
  exclude:
    labels: [internal, chore]
  categories:
    - title: New
      labels: [feature]
    - title: Changed in the app
      labels: [ui-change]
    - title: Fixes
      labels: [bug]
    - title: Other changes
      labels: ["*"]

ป้ายกำกับ "ui-change" เป็นป้ายกำกับที่มีประโยชน์ที่สุดในการเพิ่ม: มันบอกงานด้านเอกสารว่ารายการใดบ้างที่อาจทำให้บทความเสียหาย ให้ตั้งชื่อหน้าจอในชื่อพูลรีเควสต์ด้วย ("Billing settings: move reminders to Automations") เพื่อให้การเปลี่ยนแปลงนั้นถูกจับคู่กับหน้าที่แสดงหน้าจอดังกล่าว

ขั้นตอนที่ 2: อัปเดตเอกสารอัตโนมัติเมื่อปล่อยเวอร์ชัน: เริ่มงาน#

โฮสต์ Git หลักทุกแห่งสามารถเริ่มงานเมื่อคุณปล่อยเวอร์ชัน ซึ่งเป็นวิธีที่คุณสร้างการอัปเดตเอกสารจากการปล่อยเวอร์ชันของ GitHub หรือสิ่งที่เทียบเท่าใน GitLab และ Bitbucket รายละเอียดจะแตกต่างกันไป

บน GitHub เวิร์กโฟลว์ขั้นต่ำจะมีลักษณะดังนี้:

# .github/workflows/docs-on-release.yml
name: Docs on release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  draft-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Draft docs updates for this release
        env:
          TAG: ${{ github.event.release.tag_name }}
          NOTES: ${{ github.event.release.body }}
        run: ./scripts/draft-docs-updates.sh

ใช้ published แทน created: ตาม การอ้างอิงเหตุการณ์ ของ GitHub แล้ว created จะไม่ทำงานสำหรับการปล่อยเวอร์ชันแบบร่าง ในขณะที่ published ครอบคลุมทั้งการปล่อยเวอร์ชันที่เสถียรและรุ่นก่อนวางจำหน่าย ส่งบันทึกการปล่อยเวอร์ชันผ่านตัวแปรสภาพแวดล้อมตามด้านบน ไม่ใช่ส่งตรงเข้าคำสั่งเชลล์ เพราะข้อความการปล่อยเวอร์ชันคืออินพุตของผู้ใช้ และหากเครื่องมืออย่าง release-please หรือ semantic-release สร้างการปล่อยเวอร์ชันของคุณด้วยโทเค็นเริ่มต้น เหตุการณ์ที่มันกระตุ้นจะไม่เริ่มเวิร์กโฟลว์เอกสารของคุณ; ให้ใช้โทเค็น GitHub App หรือโทเค็นการเข้าถึงส่วนบุคคลแทน

บน GitLab และ Bitbucket สิ่งที่เทียบเท่ากันคืองานที่ทำงานบนแท็ก:

# .gitlab-ci.yml
draft-docs:
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - ./scripts/draft-docs-updates.sh "$CI_COMMIT_TAG"

# bitbucket-pipelines.yml
pipelines:
  tags:
    'v*':
      - step:
          script:
            - ./scripts/draft-docs-updates.sh "$BITBUCKET_TAG"

ขั้นตอนที่ 3: ค้นหาหน้าและวิดีโอที่แต่ละการปล่อยเวอร์ชันส่งผลกระทบ#

นี่คือขั้นตอนที่คู่มือส่วนใหญ่ข้ามไป และเป็นขั้นตอนที่ตัดสินว่าระบบอัตโนมัติจะมีประโยชน์หรือไม่ บันทึกการปล่อยเวอร์ชันระบุว่า "ย้ายการแจ้งเตือนไปที่ Billing → Automations"; งานของคุณต้องเปลี่ยนสิ่งนั้นให้เป็น "บทความสามบทความและวิดีโอสองรายการนี้ไม่ถูกต้องแล้ว"

สามวิธี ตั้งแต่แบบง่ายที่สุดไปจนถึงแบบมีประสิทธิภาพที่สุด:

1. ค้นหาป้ายกำกับที่ถูกเปลี่ยนชื่อ ดึงสตริง UI ที่อยู่ในเครื่องหมายคำพูดทั้งหมดออกจากบันทึกการปล่อยเวอร์ชัน และค้นหาคำเดิมในบทความและสคริปต์วิดีโอของคุณ
2. ทำรายการหน้าจอ แท็กบทความและวิดีโอแต่ละรายการด้วยหน้าจอที่แสดง และจับคู่ชื่อหน้าจอในชื่อพูลรีเควสต์กับรายการนั้น คู่มือของเราเรื่อง การทำให้เอกสารเป็นปัจจุบัน มีเทมเพลตรายการอยู่
3. ให้โมเดลอ่านแต่ละรายการให้ครบถ้วน ให้โมเดลภาษาอ่านบันทึกการปล่อยเวอร์ชันและข้อความเต็ม (หรือถอดความ) ของแต่ละหน้า และขอคำตัดสิน: ยังถูกต้องอยู่, ต้องการแก้ไขข้อความ, หรือต้องการภาพหน้าจอหรือฟุตเทจใหม่ การอ่านทั้งหน้ามีความสำคัญ เพราะขั้นตอนที่ผิดมักไม่ใช่ขั้นตอนที่บันทึกการปล่อยเวอร์ชันระบุไว้

พรอมต์สำหรับคำตัดสินนั้นอาจสั้นๆ ดังนี้:

You check help articles against a software release.
Release notes: {release_notes}
Article ({url}): {article_text}

Answer in JSON: {"verdict": "still_right" | "text_fix" | "new_screenshots_or_footage",
"reason": "<one sentence quoting the release item>",
"changed_steps": [<step numbers>]}
Only use facts from the release notes. If unsure, answer "text_fix" and say why.

ขั้นตอนที่ 4: ร่างการอัปเดต#

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

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

ขั้นตอนที่ 5: ให้คนอยู่ระหว่างร่างและผู้อ่าน#

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

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

การตั้งค่าแบบไหนที่เหมาะกับทีมของคุณ?#

หากทีมของคุณทำงานใน Claude Code อยู่แล้ว คุณยังสามารถขอให้มันอัปเดตเอกสารหลังการปล่อยเวอร์ชันผ่าน MCP ได้ เราได้อธิบายขั้นตอนนั้นไว้ใน วิธีอัปเดตเอกสารด้วย Claude Code หลังการปล่อยเวอร์ชันทุกครั้ง

วิธีอัปเดตเอกสารอัตโนมัติเมื่อปล่อยเวอร์ชันด้วย Clevera Autopilot#

Clevera คือแพลตฟอร์ม AI ที่เปลี่ยนการบันทึกหน้าจอให้เป็นวิดีโอสอนการใช้งานพร้อมเสียงบรรยาย บทความช่วยเหลือแบบทีละขั้นตอน และหน้าเว็บในศูนย์ช่วยเหลือที่คุณโฮสต์ไว้ โดยรองรับถึง 74 ภาษา ฟีเจอร์ Autopilot ของเราในแผน Pro และ Custom จะดำเนินการตามขั้นตอนที่ 2 ถึง 5 ด้านบนสำหรับศูนย์ช่วยเหลือของ Clevera

• ตัวกระตุ้น (Trigger) สูตร อัปเดตศูนย์ช่วยเหลือของฉันให้เป็นปัจจุบันเมื่อเราปล่อยเวอร์ชัน จะคอยเฝ้าดู Releases หรือ Merged changes ของที่เก็บ หรือ หน้า changelog ที่อ่านทุกวันหรือทุกสัปดาห์ GitHub จะเชื่อมต่อผ่านแอปแบบอ่านอย่างเดียว ส่วน GitLab (gitlab.com) และ Bitbucket Cloud จะเชื่อมต่อในลักษณะเดียวกันหากมีให้บริการ Clevera จะตรวจสอบที่เก็บประมาณชั่วโมงละครั้ง โดยจะอ่านบันทึกการปล่อยเวอร์ชัน แท็ก และชื่อหรือรายละเอียดของ pull-request แต่จะไม่แตะต้องโค้ดของคุณ
• การจับคู่ (Matching) การทำงานแต่ละครั้งจะตรวจสอบวิดีโอและบทความในศูนย์ช่วยเหลือสูงสุด 40 รายการ และอ่านเนื้อหาที่ได้รับผลกระทบแต่ละรายการจนครบ
• การร่าง (Drafting) แต่ละรายการจะได้รับคำตัดสิน: ยังถูกต้องอยู่, มีการแก้ไขข้อความที่แสดงก่อนและหลัง, หรือ บันทึกใหม่ ด้วยขั้นตอนใหม่ การบันทึกใหม่ต้องใช้ Use my app: ที่อยู่แอปของคุณและข้อมูลเข้าสู่ระบบหากจำเป็น (บัญชีทดสอบจะดีที่สุด) วิดีโอใหม่จะแทนที่วิดีโอเดิมที่ลิงก์เดิม ดังนั้น เช่นเดียวกับการแก้ไขด้วย LiveSync การฝังวิดีโอและหน้าศูนย์ช่วยเหลือจะแสดงวิดีโอใหม่โดยไม่ต้องเปลี่ยนลิงก์
• การตรวจสอบ (Review) การทำงานแต่ละครั้งจะรอคุณ คุณสามารถยกเลิกสิ่งที่ไม่อยากทำและคลิก Run หรือคลิก Ask for changes เพื่อรับแผนใหม่ แผนงานจะมีอายุ 7 วัน และการทำงานครั้งถัดไปจะเก็บรวบรวมทุกอย่างที่เกิดขึ้นตั้งแต่นั้นมา

การเฝ้าดูและการวางแผนนั้นฟรี แต่ละบรรทัดของแผนจะแสดงเครดิตที่ใช้ และการทำงานทั่วไปจะใช้เครดิต 10 ถึง 150 เครดิต ลูปเดียวกันนี้มีให้ใช้งานสำหรับวิดีโอที่ไม่มีศูนย์ช่วยเหลือผ่าน Update my videos when the product changes และ Record a video for every new feature จะเสนอวิธีทำใหม่สำหรับสิ่งที่แต่ละเวอร์ชันเพิ่มเข้ามา (ดู วิธีทำวิดีโอบันทึกการปล่อยเวอร์ชัน สำหรับเวอร์ชันที่ทำด้วยตนเอง)

ในกรณีที่ Clevera ไม่ใช่เครื่องมือที่เหมาะสม: มันไม่ได้สร้างข้อมูลอ้างอิง API จากโค้ดหรือเขียน CHANGELOG.md ของคุณ สำหรับส่วนนั้น โปรดดูการเปรียบเทียบ AI changelog generators ของเรา หรือ MCP servers for documentation หากคุณต้องการ AI agent เพื่อแก้ไขเอกสารในแพลตฟอร์มอื่น

เริ่มใช้งานฟรี เพื่อสร้างศูนย์ช่วยเหลือและวิดีโอก่อน Autopilot มาพร้อมกับแผน Pro ขั้นตอนการตั้งค่าอยู่ในบทความช่วยเหลือ เชื่อมต่อ GitHub หรือที่เก็บอื่นเข้ากับ Autopilot

คำถามที่พบบ่อย#

เอกสารสามารถอัปเดตตัวเองโดยอัตโนมัติเมื่อเราปล่อยเวอร์ชันได้หรือไม่?#

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

เอกสารควรได้รับการอัปเดตทุกครั้งที่ commit หรือทุกครั้งที่ปล่อยเวอร์ชัน?#

สำหรับศูนย์ช่วยเหลือ ควรเป็นทุกครั้งที่ปล่อยเวอร์ชัน การ commit และ pull request มีการเปลี่ยนแปลงตลอดเวลาและมักจะอยู่หลัง feature flags การปล่อยเวอร์ชันคือช่วงเวลาที่ผู้อ่านเห็นการเปลี่ยนแปลงจริงๆ ส่วนเอกสารนักพัฒนาที่อยู่คู่กับโค้ดสามารถติดตาม pull request ได้

ฉันจะกระตุ้น GitHub Action เมื่อมีการเผยแพร่เวอร์ชันได้อย่างไร?#

ใช้ on: release ร่วมกับ types: [published] หากการปล่อยเวอร์ชันถูกสร้างโดยเวิร์กโฟลว์อื่นที่ใช้ GITHUB_TOKEN เริ่มต้น มันจะไม่เริ่มเวิร์กโฟลว์ของคุณ ให้ใช้โทเค็น GitHub App หรือโทเค็นการเข้าถึงส่วนบุคคลสำหรับเครื่องมือปล่อยเวอร์ชัน

จะทำอย่างไรถ้าเราไม่ได้เผยแพร่เวอร์ชันบน GitHub?#

ใช้สัญญาณที่คุณมี: เหตุการณ์การปล่อยเวอร์ชันของ GitLab, ท่อส่งแท็กของ Bitbucket หรือการตั้งเวลางานที่อ่านหน้า changelog สาธารณะหรือฟีด RSS ของคุณ Autopilot ของ Clevera สามารถเฝ้าดูหน้า changelog ได้ทุกวันหรือทุกสัปดาห์สำหรับกรณีนี้โดยเฉพาะ

ภาพหน้าจอและวิดีโอสามารถอัปเดตโดยอัตโนมัติได้ด้วยหรือไม่?#

ภาพหน้าจอสามารถจับภาพได้ในการทดสอบ UI ทุกครั้งที่ build ส่วนวิดีโอจำเป็นต้องบันทึกขั้นตอนที่เปลี่ยนไปใหม่ AI recorder สามารถรันคำสั่งที่บันทึกไว้ซ้ำกับ UI ใหม่ได้ และ Autopilot สามารถทำสิ่งนี้สำหรับวิดีโอของ Clevera เมื่อคุณระบุที่อยู่แอปของคุณ (และข้อมูลเข้าสู่ระบบหากแอปของคุณต้องการ) ให้ตรวจสอบวิดีโอใหม่ก่อนอนุมัติ