# ฉันสร้างผลิตภัณฑ์ด้วย AI—จะปรับปรุงอย่างไรโดยไม่ทำลายสิ่งที่ใช้งานได้ดีอยู่แล้ว

> การดูแลผลิตภัณฑ์หลังเปิดตัวอย่างปลอดภัย: git, การย้อนกลับ, staging, การปกป้องความลับ, โฮสติ้ง, การสำรองข้อมูล และการบำรุงรักษา คงพรอมป์ต์ทั้งหกไว้ครบถ้วน

Source: https://ailoot.ai/blog/th/ai-product-maintenance-after-launch/
Canonical: https://ailoot.ai/blog/th/ai-product-maintenance-after-launch/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-033
Revision: sha256-a59fe94230fe558fea08c72691a581ccfa9dc16b888e54e61a1d320e6165adaf




อ่านเพิ่มเติมเกี่ยวกับการทำงานกับโมเดลได้ใน[เอกสารประกอบ Ailoot](https://ailoot.ai/docs/)

## ทำไมงานที่มีค่าใช้จ่ายสูงที่สุดจึงเริ่มหลังเปิดตัว?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

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

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

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

| เงินหนึ่งดอลลาร์ไปอยู่ที่ไหน | จำนวน | ความหมายในทางปฏิบัติ |
|----|----|----|
| เข้าสู่ผลิตภัณฑ์ | **18 เซนต์** | ฟีเจอร์ที่ใช้งานได้จริงสำหรับผู้ใช้ |
| แก้บั๊กจาก AI | 44 เซนต์ | แก้สิ่งที่ AI เขียนไปแล้ว เพื่อไม่ให้พัง |
| ทำงานใหม่ | 27 เซนต์ | เขียนโค้ดที่ AI ทำไว้ใหม่ เพราะไม่ตรงกับโจทย์ |
| ตรวจทาน | 11 เซนต์ | ทำความเข้าใจโค้ดและค้นหาจุดที่ผิดพลาด |

คู่มือ [“ต้นทุนแฝงของ vibe coding”](https://ailoot.ai/blog/th/vibe-coding-cost-time/) อธิบายตัวเลขเหล่านี้อย่างละเอียดกว่าเดิม ที่นั่นคำถามคือคุณกำลังจ่ายเงินไปกับอะไร ส่วนที่นี่คำถามต่างออกไป: เงินทุกดอลลาร์ 44 เซนต์ถูกใช้ไปกับการแก้บั๊ก—และบทความนี้ทั้งบทว่าด้วยการป้องกันไม่ให้สัดส่วนนี้เพิ่มขึ้น งานที่ทำให้ควบคุมเรื่องนี้ได้เรียกว่าการบำรุงรักษา

ความแตกต่างระหว่างคนที่ทำ vibe coding แบบผู้ใหญ่กับคนที่คอยเฝ้า neural net ปรากฏให้เห็นหลังเปิดตัว คนกลุ่มแรกทำให้ codebase เติบโต ปรับปรุงสิ่งต่าง ๆ และไม่มีอะไรพัง หนึ่งเดือนต่อมา ผลิตภัณฑ์ของคนกลุ่มที่สองกลับกลายเป็นของพัง ๆ ที่รั่วไปหมดและเจ้าตัวไม่กล้าแตะ ต่อไปฉันจะอธิบายว่าจะทำอย่างไรให้ไปอยู่กลุ่มแรก

## อะไรพังจริง ๆ: 5 ภัยพิบัติหลังเปิดตัว

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ผลิตภัณฑ์ที่สร้างด้วย AI พังจากสาเหตุเดิม ๆ ไม่กี่อย่าง: key และฐานข้อมูลรั่ว AI ลบ production และคนแปลกหน้าเรียกเก็บเงินจากลูกค้า ภัยพิบัติแต่ละอย่างมีวิธีป้องกันเพียงขั้นตอนเดียว

</div>

นี่คือรายงานหลังเกิดเหตุที่เปิดเผยต่อสาธารณะเกี่ยวกับผลิตภัณฑ์จริงที่สร้างด้วย AI มีทั้งตัวเลขและวันที่ คิดเสียว่าเป็นแผนที่สนามทุ่นระเบิด—ทุ่นแต่ละลูกเคยระเบิดใส่ใครบางคนมาแล้ว และรู้วิธีหลบเลี่ยงมัน

| เกิดอะไรขึ้น | เกิดขึ้นอย่างไร | อะไรจะป้องกันเรื่องนี้ได้ |
|----|----|----|
| **Key รั่ว 1.5 ล้านรายการ** | key ฐานข้อมูลที่เปิดเผยต่อสาธารณะอยู่ในโค้ดหน้าเว็บ และเปิดให้เข้าถึงฐานข้อมูลโดยไม่มีรหัสผ่าน | เปิดใช้ row-level security (RLS) ในทุกตาราง |
| **เปิดเผยแอป 170 แอป** | แอปเชื่อมต่อฐานข้อมูลโดยตรงจากเบราว์เซอร์โดยใช้ public key และไม่มีการกำหนดกฎการเข้าถึง | ตรวจสอบสิทธิ์การเข้าถึงฐานข้อมูลก่อนขาย และอย่าไว้ใจค่าปริยาย |
| **AI ลบฐานข้อมูล production** | เอเจนต์ได้รับสิทธิ์เข้าถึงฐานข้อมูล production และลบข้อมูลแม้จะมีคำสั่งห้าม | แยกฐานข้อมูล production ออกจากสภาพแวดล้อมของเอเจนต์ทางกายภาพ |
| **key ชำระเงินในเบราว์เซอร์: \$87,500** | key ของระบบชำระเงินไปอยู่ในโค้ดหน้าเว็บ มีคนพบ key เหล่านั้น และลูกค้า 175 รายถูกเรียกเก็บเงิน | เก็บ secrets ไว้บนเซิร์ฟเวอร์เท่านั้น ห้ามไว้ในเบราว์เซอร์ |
| **เปิดเผยรูปภาพและเอกสาร 72,000 รายการ** | ที่เก็บไฟล์ไม่มีรหัสผ่าน ใครก็ตามที่มีลิงก์จึงดาวน์โหลดภาพเซลฟีและเอกสารยืนยันตัวตนได้ | กำหนดให้ที่เก็บไฟล์ต้องมีการยืนยันตัวตนเป็นค่าเริ่มต้น |

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

ปัญหาไม่ใช่การไม่ได้เขียนโค้ดด้วยตัวเอง—มีคนทำงานแบบนี้มากมาย ปัญหาคือการไม่ได้ถามว่า “ฐานข้อมูลปลอดภัยหรือยัง?” ต่อไปฉันจะแสดงพรอมป์ต์ที่ช่วยถามคำถามนี้ให้คุณ

## ตาข่ายนิรภัยชั้นแรกคือ git และการย้อนกลับไป “เหมือนเมื่อวาน”

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ตาข่ายนิรภัยหลักหลังเปิดตัวคือความสามารถในการย้อนกลับการเปลี่ยนแปลงได้ทุกอย่าง มีสองชั้นที่ทำงานร่วมกัน: git เป็นประวัติถาวรของโปรเจกต์ และ snapshot ในเครื่องของ Claude Code สำหรับ “ยกเลิกสิ่งที่เพิ่งทำ” อย่างรวดเร็ว repository แบบ private พร้อมไฟล์ secrets ที่อยู่ในรายการ ignore คือสิ่งขั้นต่ำที่คุณต้องมี ก่อนปล่อยให้คนอื่นใช้ผลิตภัณฑ์

</div>

เมื่อ Claude ทำอะไรพัง คุณต้องมีปุ่ม “คืนสภาพให้เหมือนเมื่อวาน” ในทางเทคนิค ปุ่มนั้นเรียกว่า git และใช้ง่ายกว่าที่คิด

คำศัพท์สามคำที่คนไม่ใช่โปรแกรมเมอร์ควรเข้าใจ:

1.  **Repository** — โฟลเดอร์โปรเจกต์ที่บันทึกไว้บนคลาวด์ (โดยปกติอยู่บน GitHub) เป็นสำเนาโค้ดทั้งหมดของคุณที่ไม่ได้อยู่แค่ในคอมพิวเตอร์เครื่องเดียว
2.  **Commit** — จุดย้อนกลับ คุณกำลังบอกโค้ดว่า “บันทึกไว้ในสถานะนี้” แต่ละ commit เป็นหมุดหมายที่คุณย้อนกลับไปได้
3.  **Deploy** — การย้าย โค้ดเคยอยู่ในเครื่องคอมพิวเตอร์และทำงานได้แค่กับคุณ การ deploy จะส่งโค้ดไปยังเซิร์ฟเวอร์ภายนอกเพื่อให้ทุกคนใช้งานได้

ตราบใดที่คุณมีจุด commit ล่าสุด คุณก็ย้อนกลับจากความเสียหายใด ๆ ได้ด้วยประโยคเดียว จริง ๆ นะ

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: ย้อนกลับไปยังเวอร์ชันที่ใช้งานได้

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

</div>

ควรตั้งกฎสองข้อนี้ทันที ก่อนที่คนอื่นจะเห็นผลิตภัณฑ์:

- **repository ต้องเป็น private** ไม่ใช่ public มิฉะนั้นใคร ๆ ก็อ่านโค้ดของคุณและทุกอย่างที่อยู่ในนั้นได้
- **ใส่ไฟล์ secrets ไว้ในรายการ ignore** key รหัสผ่าน และข้อมูลรับรองสำหรับเข้าถึงฐานข้อมูลจะอยู่ในไฟล์แยกต่างหาก (ปกติคือ `.env`) และไฟล์นั้นจะไม่เข้าไปอยู่ใน repository เพิ่มบรรทัดสำหรับ `.env` ใน `.gitignore` แล้ว secrets จะยังอยู่กับคุณ

มีคู่มือแยกเกี่ยวกับการย้อนกลับการเปลี่ยนแปลงอย่างปลอดภัยใน Claude Code: [วิธีย้อนกลับการเปลี่ยนแปลงใน Claude Code](https://ailoot.ai/blog/th/claude-code-undo-changes/) หากไม่มีจุดย้อนกลับ คุณก็เหมือนเดินบนเชือกโดยไม่มีตาข่ายนิรภัย และไม่ช้าก็เร็วคุณจะตกลงมา

## `/rewind` ย้อนกลับอะไรได้ และย้อนกลับอะไรไม่ได้?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

Claude Code มีคำสั่ง `/rewind`—คำสั่งนี้ถ่าย snapshot ก่อนการแก้ไขแต่ละครั้ง และย้อนโค้ดกับบทสนทนากลับไปยังจุดที่เลือก แต่จะย้อนกลับเฉพาะไฟล์ที่ Claude แก้ไขเองเท่านั้น ไม่แตะต้องแพ็กเกจที่ติดตั้ง การอัปโหลดขึ้นคลาวด์ การเปลี่ยนแปลงฐานข้อมูล หรือการเรียกใช้บริการภายนอก git คือประวัติถาวร ส่วน `/rewind` คือ “undo” ในเครื่องแบบรวดเร็ว

</div>

Claude Code ถ่าย snapshot ของสถานะก่อนเปลี่ยนแปลงทุกครั้ง คำสั่ง `/rewind` (หรือกด Esc สองครั้ง) จะย้อนทั้งไฟล์และบทสนทนากลับไปยังจุดที่เลือก สะดวกมาก: หากคุณทำฟีเจอร์พังเมื่อห้านาทีก่อน ก็ย้อนกลับไปห้านาทีที่แล้วได้

แต่มีหลุมพรางที่ทำให้มือใหม่สูญเสียข้อมูล `/rewind` ย้อนกลับทุกอย่างไม่ได้:

| สิ่งที่ `/rewind` ย้อนกลับ | สิ่งที่ไม่ย้อนกลับ |
|--------------------------------------|-------------------------------------|
| การแก้ไขไฟล์ที่ Claude ทำ | การติดตั้งแพ็กเกจ (`npm install`) |
| บทสนทนาในเซสชันนี้ | การอัปโหลดโค้ดขึ้นคลาวด์ (`git push`) |
| สถานะในเครื่องของโปรเจกต์ | การเปลี่ยนแปลงฐานข้อมูล |
| \- | การเรียกใช้บริการภายนอกและการชำระเงิน |

Anthropic อธิบายไว้อย่างตรงไปตรงมา: snapshot คือปุ่ม “undo” ในเครื่อง ส่วน git คือประวัติถาวร Snapshot ช่วยเสริมการควบคุมเวอร์ชัน แต่ใช้แทนกันไม่ได้

<figure>
<blockquote>
<p>Snapshot คือ “undo” ในเครื่อง ส่วน Git คือประวัติถาวร Snapshot ช่วยเสริมการควบคุมเวอร์ชันเต็มรูปแบบ แต่ใช้แทนกันไม่ได้</p>
</blockquote>
<figcaption>— เอกสารประกอบ Claude Code, https://code.claude.com/docs/en/checkpointing</figcaption>
</figure>

ข้อสรุปในทางปฏิบัติสำหรับคนที่ไม่ใช่โปรแกรมเมอร์คือ `/rewind` ช่วยคุณจากสถานการณ์ “Claude เพิ่งทำฟีเจอร์พัง” ได้ แต่ถ้ามันลบแถวในฐานข้อมูลหรืออัปโหลดโค้ดขึ้นคลาวด์ไปแล้ว มีเพียง git และข้อมูลสำรองฐานข้อมูลเท่านั้นที่กู้คืนได้ ดังนั้นควรมีทั้งสองชั้น: snapshot สำหรับย้อนกลับอย่างรวดเร็ว และ commit สำหรับเก็บประวัติถาวรของโปรเจกต์

## จะปรับปรุงโดยไม่ทำลายสิ่งที่ใช้งานได้ดีอยู่แล้วได้อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

อันตรายหลักเมื่อลงมือปรับปรุงคือการเบี่ยงเบนของตรรกะ: คุณขอให้ AI แก้สิ่งหนึ่ง แต่มันกลับเปลี่ยนตรรกะที่อยู่ข้างเคียงอย่างเงียบ ๆ เพราะ vibe coding ให้ผลลัพธ์ที่ไม่เป็นแบบกำหนดแน่นอน วิธีป้องกันคือกฎทอง: อย่า deploy โค้ดที่คุณอธิบายให้คนอื่นฟังไม่ได้ เปลี่ยนแปลงทีละน้อย แต่ละครั้งผ่าน commit และตรวจดูให้ชัดเจนเสมอว่ามีอะไรเปลี่ยนไปบ้าง

</div>

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

วงจรนี้เกิดขึ้นเพราะ vibe coding ไม่ได้ให้ผลลัพธ์แบบกำหนดแน่นอน พรอมป์ต์เดียวกันอาจให้โค้ดต่างกันในแต่ละครั้ง ดังนั้นการแก้ไขแต่ละครั้งจึงอาจเปลี่ยนตรรกะรอบข้างอย่างเงียบ ๆ: เกณฑ์ส่วนลดขยับจาก 10 เป็น 12 เปอร์เซ็นต์ หรือกฎตรวจสอบเปลี่ยนพฤติกรรม—โดยที่คุณไม่ได้ตรวจสอบและไม่มีคำเตือนแม้แต่ข้อเดียว สิ่งนี้เรียกว่าการเบี่ยงเบนของตรรกะ และมันค่อย ๆ ทำลายสิ่งที่สร้างรายได้โดยตรง ได้แก่ ราคา การเข้าถึง และการชำระเงิน

มีกฎข้อเดียวที่ช่วยป้องกันการเบี่ยงเบน ซึ่งง่ายพอที่จะนำไปติดไว้บนผนัง: อย่า commit โค้ดที่คุณอธิบายให้คนอื่นฟังแบบคำต่อคำไม่ได้

ในทางปฏิบัติ กฎนี้กลายเป็นกรอบคำสั่งสำเร็จรูปที่ใช้ได้ก่อนเปลี่ยนโค้ดที่ทำงานอยู่ทุกครั้ง มันบังคับให้ AI ทำทีละขั้นเล็ก ๆ และแสดงให้คุณเห็นอย่างชัดเจนว่ามีอะไรเปลี่ยนไป

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: วางแผนการเปลี่ยนแปลงอย่างปลอดภัย

```
ก่อนเปลี่ยนโค้ด ให้ทำสิ่งต่อไปนี้:

บันทึกสถานะปัจจุบันที่ยังทำงานได้ไว้เป็นจุดย้อนกลับแยกต่างหาก (commit)

อธิบายเป็นคำพูดให้ชัดเจนว่าคุณวางแผนจะแก้ไขอะไรและในไฟล์ใดบ้าง

เปลี่ยนแปลงให้น้อยที่สุดเท่าที่ทำได้—ทำเฉพาะสิ่งที่แก้โจทย์ของฉันได้เท่านั้น อย่าทำอย่างอื่นเพิ่ม

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

</div>

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

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



## จะตรวจสอบการเปลี่ยนแปลงก่อนเผยแพร่ได้อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ก่อนนำการเปลี่ยนแปลงไปใช้กับผู้ใช้จริง ให้ทดสอบผ่านสถานการณ์สำคัญ ได้แก่ การชำระเงิน การลงทะเบียน การเข้าถึง และราคา วิธีที่ดีที่สุดคือใช้สำเนาทดสอบของสภาพแวดล้อม production (เรียกว่า staging ในเครื่องมือสำหรับนักพัฒนา) เพื่อตรวจสอบขั้นสุดท้าย ลำดับคือ สร้างในสภาพแวดล้อมพัฒนา ตรวจสอบบนสำเนาทดสอบ แล้ว deploy ไปยัง production ทุกการเผยแพร่มีความเสี่ยง ส่วนสำเนาทดสอบช่วยขจัดความเสี่ยงนั้น

</div>

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

1.  สร้างและตรวจสอบการเปลี่ยนแปลงด้วยตัวเอง (development)
2.  deploy ไปยัง staging—สำเนาของ production ที่ไม่มีผู้ใช้จริง
3.  ทดลองสถานการณ์สำคัญและตรวจสอบว่าไม่มีอะไรเปลี่ยนแปลง
4.  จากนั้นจึง deploy ไปยัง production

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

เพื่อไม่ต้องตรวจสอบทุกอย่างด้วยตัวเองทุกครั้ง ให้พรอมป์ต์ AI เปรียบเทียบการทำงานของเวอร์ชันใหม่กับเวอร์ชันเก่าในจุดสำคัญ

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: ตรวจ regression ก่อนเผยแพร่

```
ฉันกำลังจะ deploy การเปลี่ยนแปลง ให้ตรวจสอบสถานการณ์หลักของผลิตภัณฑ์ตามลำดับ และดูว่าแต่ละอย่างยังทำงานเหมือนเดิมหรือไม่:

การลงทะเบียนและเข้าสู่ระบบของผู้ใช้ใหม่

การชำระเงินและการให้สิทธิ์เข้าถึงหลังชำระเงิน

สิทธิ์การเข้าถึง—ผู้ใช้ทั่วไปต้องดูข้อมูลของคนอื่นหรือส่วนผู้ดูแลระบบไม่ได้

ตัวเลขสำคัญในตรรกะทางธุรกิจ (ราคา ส่วนลด ขีดจำกัด) ไม่เปลี่ยนแปลง
หากมีสิ่งใดทำงานต่างจากเวอร์ชันก่อน ให้หยุดและแสดงให้ฉันเห็นอย่างชัดเจนว่าเปลี่ยนอะไรไป
```

</div>

## ความลับของคุณอยู่ที่ไหน? ช่องโหว่ใหญ่ที่สุดสำหรับมือใหม่

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ข้อผิดพลาดหลังเปิดตัวที่พบบ่อยและมีค่าใช้จ่ายสูงที่สุดคือการเก็บ secrets ไว้ในโค้ดหน้าเว็บ key ของฐานข้อมูล ระบบชำระเงิน และบริการภายนอกควรอยู่บนเซิร์ฟเวอร์เท่านั้น ใน environment variables และห้ามอยู่ในเบราว์เซอร์ ช่องโหว่นี้ทำให้ผลิตภัณฑ์หนึ่งทำ key รั่วไหลไปแล้ว 1.5 ล้านรายการ และทำให้ลูกค้าของผู้ก่อตั้งรายหนึ่งถูกเรียกเก็บเงิน $87,500

</div>

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

ผู้ก่อตั้งที่ลูกค้าถูกเรียกเก็บเงิน $87,500 กล่าวภายหลังว่าพรอมป์ต์เดียวอาจป้องกันเรื่องนี้ได้ ในที่สุดก็คืนเงินที่เรียกเก็บไป แต่ค่าธรรมเนียมที่ขอคืนไม่ได้และความสบายใจที่เสียไปยังคงอยู่ นี่คือพรอมป์ต์นั้น

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: ตรวจสอบว่า secrets ของฉันจัดเก็บไว้ที่ไหน

```
ตรวจสอบทั้งโปรเจกต์และยืนยันว่าไม่มี secret key ใดไปอยู่ในเบราว์เซอร์:

ค้นหา key ทั้งหมดของฐานข้อมูล ระบบชำระเงิน และบริการภายนอก

ตรวจสอบว่าแต่ละ key จัดเก็บอยู่บนเซิร์ฟเวอร์เท่านั้น ใน environment variables และไม่ได้อยู่ในโค้ดของหน้าเว็บ

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

</div>

กับดักใกล้เคียงอีกอย่างคือการตรวจสอบสิทธิ์การเข้าถึงเฉพาะฝั่งเบราว์เซอร์ หากผลิตภัณฑ์ตัดสินใจในโค้ดหน้าเว็บว่าจะ “แสดงส่วนผู้ดูแลระบบ” หรือไม่ ใคร ๆ ก็ข้ามการตัดสินใจนั้นได้ ต้องตรวจสอบสิทธิ์การเข้าถึงบนเซิร์ฟเวอร์เสมอ ฐานข้อมูลต้องส่งข้อมูลกลับเฉพาะผู้ที่มีสิทธิ์เท่านั้น—นี่คือจุดประสงค์ของ row-level security (RLS) และต้องเปิดใช้ในทุกตาราง

ก่อนขายสิทธิ์การเข้าถึงหรือเปิดให้คนอื่นเข้ามา ให้ตรวจสอบความปลอดภัยของผลิตภัณฑ์โดยรวม

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: ตรวจสอบโปรเจกต์หลังเปิดตัว

```
ตรวจดูโปรเจกต์ในมุมมองของผู้โจมตีและค้นหาช่องโหว่ด้านความปลอดภัย:

มี secret key ใดจัดเก็บอยู่ในโค้ดที่ส่งไปยังเบราว์เซอร์หรือในประวัติโปรเจกต์หรือไม่

เปิดใช้ row-level security (RLS) ในทุกตารางฐานข้อมูลแล้วหรือยัง และมีการตรวจสอบสิทธิ์การเข้าถึงบนเซิร์ฟเวอร์ แทนที่จะตรวจแค่ในเบราว์เซอร์หรือไม่

กำหนดค่าการสำรองข้อมูลฐานข้อมูลอัตโนมัติไว้หรือยัง และฉันเคยตรวจสอบหรือไม่ว่าสามารถกู้คืนจากข้อมูลสำรองได้

ฐานข้อมูล production แยกจากสภาพแวดล้อมที่เอเจนต์ AI ทำงานอยู่หรือไม่
สำหรับแต่ละข้อ บอกฉันว่าทุกอย่างเรียบร้อยดีหรือมีอะไรที่ต้องแก้ไขโดยเฉพาะ
```

</div>

มีคู่มือฉบับเต็มแยกต่างหากเกี่ยวกับความปลอดภัยของ vibe coding: [วิธีรักษาความปลอดภัยให้แอปที่สร้างด้วย vibe coding](https://ailoot.ai/blog/th/vibe-coding-security/) กฎนั้นเรียบง่าย: ให้ถือว่าสิ่งที่ AI ทำไว้ยังไม่ปลอดภัยเป็นค่าเริ่มต้น จนกว่าคุณจะตรวจสอบแล้วว่าไม่เป็นเช่นนั้น

## จะโฮสต์ผลิตภัณฑ์ไว้ที่ไหน: ขั้นบันไดการโฮสต์

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

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

1.  **โฮสติ้งฟรี** (เช่น Vercel)—สำหรับตัวคุณเอง การทดสอบ และโปรเจกต์ขนาดเล็ก ใช้ได้หากแพลตฟอร์มเข้าถึงได้สำหรับกลุ่มเป้าหมายของคุณ และคุณไม่ได้เก็บข้อมูลส่วนบุคคลของใคร
2.  **แพลตฟอร์มที่ deploy ได้ด้วยคำสั่งเดียว** (Railway)—เมื่อคุณมี backend และฐานข้อมูล คุณ deploy ได้ด้วยคำสั่งเดียวโดยไม่ต้องตั้งค่าเซิร์ฟเวอร์ อุปสรรคในการเริ่มใช้งานมีน้อยมาก
3.  **เซิร์ฟเวอร์เฉพาะของตัวเอง**—เมื่อโหลดสูงและคุณต้องการควบคุมทุกอย่าง ย้ายไปใช้ตัวเลือกนี้ทีหลัง เมื่อคุณชนขีดจำกัดของแพลตฟอร์ม


สำหรับคนที่ไม่ใช่โปรแกรมเมอร์และเพิ่งเปิดตัว ตัวเลือกที่ง่ายที่สุดคือแพลตฟอร์มที่ deploy ได้ด้วยคำสั่งเดียว โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์เอง ค่อยย้ายไปใช้เซิร์ฟเวอร์ของตัวเองภายหลัง หากอยากทำตามแนวทางนี้โดยดูตัวอย่างจริง โปรดอ่านคู่มือเรื่อง[การ deploy โปรเจกต์ที่สร้างด้วย vibe coding ไปยังเซิร์ฟเวอร์ของตัวเองด้วย Coolify](https://ailoot.ai/blog/th/coolify-claude-code-deploy/)

## เมื่อไรจึงควรแยกแอป ฐานข้อมูล และข้อมูลสำรองออกจากกัน?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ขณะที่ผลิตภัณฑ์ยังเล็ก แอปและฐานข้อมูลอยู่ในเครื่องเดียวกันได้ ถึงเวลาต้องแยกเมื่อโหลดสูงสุดคงอยู่เหนือ 70–80 เปอร์เซ็นต์ หรือฐานข้อมูลกับแอปเริ่มทำให้กันและกันช้าลง การสำรองข้อมูลใช้กฎ 3-2-1: มีสามสำเนา อยู่บนสื่อสองประเภท และมีหนึ่งสำเนาอยู่นอกสถานที่ อีกทั้งต้องสำรองข้อมูลโดยอัตโนมัติ ไม่ใช่ “ตอนที่นึกขึ้นได้”

</div>

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

- **ย้ายแอปและฐานข้อมูลไปไว้คนละเครื่อง** สัญญาณคือในช่วงโหลดสูงสุด CPU และหน่วยความจำใช้งานเกิน 70–80 เปอร์เซ็นต์ต่อเนื่อง คำขอเริ่มช้าลง และแอปกับฐานข้อมูลแย่งใช้ทรัพยากรเดียวกัน หลังแยกกันแล้ว คุณสามารถเพิ่มประสิทธิภาพฐานข้อมูลโดยไม่แตะแอป และในทางกลับกัน
- **ทำตามกฎการสำรองข้อมูล 3-2-1** สำเนาข้อมูลสามชุด บนสื่อสองประเภทที่ต่างกัน โดยหนึ่งชุดอยู่นอกสถานที่ วิธีนี้ช่วยป้องกันความเสียหายจากฮาร์ดแวร์และ ransomware สิ่งสำคัญคือการสำรองข้อมูลต้องทำโดยอัตโนมัติ

ความถี่ในการสำรองข้อมูลขึ้นอยู่กับว่าการสูญเสียข้อมูลหลายชั่วโมงมีต้นทุนสูงเพียงใด สำหรับบริการสมาชิกออนไลน์ที่ยอมเสียบันทึกชำระเงินหนึ่งชั่วโมงไม่ได้ ต้องสำรองถี่กว่าหนึ่งชั่วโมง หรือมี transaction logs และ point-in-time recovery (PITR) ที่ตรวจแล้ว กำหนดช่วงตามข้อมูลสูงสุดที่ยอมเสียได้ และทดสอบเวลาในการกู้บริการแยกด้วย ส่วนบล็อกสำรองวันละครั้งก็เพียงพอ หลักคิดง่าย ๆ คือ ตัดสินใจว่าคุณยอมเสียข้อมูลได้มากแค่ไหน แล้วตั้งค่าการสำรองข้อมูลให้เหมาะสม

<div class="section" data-semantic="prompt" aria-label="พรอมป์ต์">

พรอมป์ต์: ถึงเวลาย้ายไปใช้เซิร์ฟเวอร์แยกกันหรือยัง?

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

ที่ช่วงโหลดสูงสุด CPU และหน่วยความจำมีการใช้งานเท่าไร—การใช้งานอยู่สูงกว่า 70–80 เปอร์เซ็นต์ต่อเนื่องหรือไม่

ฐานข้อมูลกับแอปอยู่ในเครื่องเดียวกันหรือคนละเครื่อง

กำหนดค่าการสำรองข้อมูลฐานข้อมูลอัตโนมัติไว้หรือยัง และฉันทดสอบการกู้คืนจากข้อมูลสำรองแล้วหรือไม่

มีสำเนาสภาพแวดล้อมแยกต่างหาก (staging) สำหรับตรวจสอบก่อน deploy หรือไม่
จากผลที่ได้ ให้คำแนะนำที่ชัดเจนว่าอะไรควรปล่อยไว้ตามเดิม ควรแยกอะไรออกก่อน และเพราะเหตุใด
```

</div>

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

## จะทำให้การบำรุงรักษาทำงานอัตโนมัติได้อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

การบำรุงรักษาด้วยมือทำให้เหนื่อยล้า คุณสามารถลดภาระลงได้สองวิธี: การตรวจสอบระบบและเอเจนต์ตรวจตรา

การตรวจสอบระบบใช้เครื่องมือสองชนิดที่ทำหน้าที่คนละอย่าง:

1.  **“เว็บไซต์ออนไลน์อยู่หรือไม่?”**—เครื่องมือตรวจสอบ uptime (เช่น UptimeRobot) เครื่องมือนี้จะ ping ผลิตภัณฑ์ทุกสองสามนาที และส่งการแจ้งเตือนหากระบบล่ม มีแพ็กเกจฟรี
2.  **“อะไรพังโดยเฉพาะ?”**—เครื่องมือติดตามข้อผิดพลาด (เช่น Sentry) เครื่องมือนี้รวบรวมข้อผิดพลาดภายในแอปและแสดงว่ามีอะไรล้มเหลวที่ไหนและเพราะเหตุใด

เครื่องมือแรกตรวจพบว่าผลิตภัณฑ์ล่ม ส่วนเครื่องมือที่สองบอกว่าฟีเจอร์ใดล้มเหลวและเพราะอะไร ทั้งสองอย่างตอบคำถามว่า “ฉันจะรู้เรื่องระบบขัดข้องก่อนที่ลูกค้าจะเขียนมาหาฝ่ายสนับสนุนหรือไม่?”

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

<div class="aside" data-semantic="callout" role="note" aria-label="คำเตือน">

คำเตือน

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

</div>

อีกกฎหนึ่งเกี่ยวกับการให้ AI เข้าถึงฐานข้อมูล production: ให้บัญชีผู้ใช้ที่อ่านได้อย่างเดียว และซ่อนข้อมูลส่วนบุคคลไว้หลังชั้นตัวกลาง เพื่อให้เอเจนต์เห็น “ชื่อ” แทนชื่อจริงของบุคคล จากนั้น แม้เอเจนต์จะทำผิดพลาด มันก็ไม่มีทางลบหรือทำให้ข้อมูล production เสียหายได้ เหตุการณ์ในตารางด้านบนที่เอเจนต์ล้างฐานข้อมูล production เป็นตัวอย่างตรง ๆ ของการไม่มีข้อจำกัดนี้ คู่มือ [ควรทำอย่างไรหาก AI ลบฐานข้อมูลของคุณ](https://ailoot.ai/blog/th/ai-deleted-database-recovery/) อธิบายว่าต้องทำอย่างไรหากภัยพิบัติเกิดขึ้นแล้ว

## เมื่อไรจึงถึงเวลาปิดผลิตภัณฑ์?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

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

เกณฑ์เวลาที่ใช้ประกอบการตัดสินใจได้:

1.  **สองสัปดาห์**—นานพอที่จะเห็นว่าแนวคิดใช้ได้หรือไม่ หากผู้ใช้จริงกลุ่มแรกกลับมา ก็ทำต่อ ความเงียบคือคำตอบ
2.  **สามเดือน**—เพดานสูงสุด หากไม่ประสบความสำเร็จภายในสามเดือน ก็ปิดมัน ด้วยความเร็วของ vibe coding การใช้เวลาหกเดือนทดสอบแนวคิดเดียวถือว่านานเกินไป

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

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

<div class="section" role="doc-bibliography" aria-label="แหล่งที่มา">

### แหล่งที่มา

- [Anthropic - การทำ checkpoint ใน Claude Code](https://code.claude.com/docs/en/checkpointing)
- [Anthropic - โมเดลความปลอดภัยของ Claude Code](https://code.claude.com/docs/en/security)

</div>

การสร้างผลิตภัณฑ์ด้วย AI ในคืนเดียวเป็นเพียงครึ่งหนึ่งของงาน การทำให้ผลิตภัณฑ์มีชีวิตและปลอดภัยขณะที่เติบโต—นี่คือความหมายของ vibe coding สำหรับผู้ใหญ่





ขั้นต่อไปของคุณคือ [Ailoot](https://ailoot.ai/).

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

### บริการมีการชำระเงินควรสำรองถี่เท่าไร?

กำหนดตามปริมาณข้อมูลสูงสุดที่ยอมสูญได้ หากเสียหนึ่งชั่วโมงไม่ได้ต้องสำรองถี่กว่ารายชั่วโมงหรือใช้ transaction-log/PITR ที่ตรวจแล้ว และทดสอบเวลากู้คืนจริง

### uptime monitor เพียงพอตรวจสุขภาพผลิตภัณฑ์หรือไม่?

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


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ