Phần 1: Vibe Coding Paradigm: Từ Prompt-and-Pray Đến Spec-Driven Development

Answer-first: Vibe Coding giúp người không chuyên (CEO, PM, BA) tạo nhanh nguyên mẫu sản phẩm bằng Cursor, Lovable hay Bolt.new. Tuy nhiên, việc đưa mã nguồn này lên môi trường sản xuất đòi hỏi vượt qua rào cản về cấu trúc cơ sở dữ liệu, quản lý trạng thái, tính mở rộng và kiểm thử tải thực tế.

Điều kiện tiên quyết: Đã đọc Executive Summary: Vibe Coding Là Gì và nắm được các khái niệm cơ bản về lập trình web, cơ sở dữ liệu quan hệ, cũng như quy trình tạo prototype sản phẩm.

Phiên bản Tiếng Anh: 📖 Bản tiếng Anh (English Edition)

← Chương trước: Executive Summary | Mục lục Series | Chương tiếp theo: Phần 2: Context Engineering →

1. Bản Chất Của Mô Hình Vibe Coding: Sự Thật Đằng Sau Các Con Số

Vào tháng 7 năm 2025, CEO của một startup gọi vốn vòng Series A đã tự hào trình diễn một hệ thống vận hành nội bộ đang hoạt động — dài 140.000 dòng code — được xây dựng hoàn toàn bằng các câu prompt trên Claude trong suốt bốn tuần. Không có kỹ sư nào trong đội ngũ sáng lập. Không có nhà đồng sáng lập phụ trách kỹ thuật (technical co-founder). Chỉ có một nhà sáng lập kinh doanh, một vấn đề rõ ràng, và sự sẵn sàng để “thả mình vào những cảm xúc” (give in to the vibes).

Hệ thống đó là thật. Nó đã chạy trên môi trường sản xuất (production). Nó phục vụ hàng trăm người dùng thực tế.

Ba tháng sau, một tiêu đề khác xuất hiện làm rung chuyển cộng đồng: mạng xã hội AI Moltbook bị rò rỉ 1,5 triệu token API từ OpenAI, Anthropic, AWS, và GitHub — cùng với 35.000 email người dùng và tin nhắn riêng tư. Vụ rò rỉ không xảy ra thông qua một cuộc tấn công tinh vi nào, mà xuất phát từ việc cấu hình bảo mật Row Level Security (RLS) của Supabase đã bị AI âm thầm tắt bỏ trong quá trình giải quyết lỗi truy vấn dữ liệu.

Cả hai câu chuyện đều có thật và phản ánh chính xác ranh giới mà mọi nhà xây dựng sản phẩm bằng AI cần nắm vững.

flowchart TD
    subgraph AdHocParadigm ["Mô Hình Cũ: Prompt & Pray (2025)"]
        RawPrompt["Prompt Ngôn Ngữ Tự Nhiên Tùy Hứng"] --> BlindGen["Mô Hình AI Sinh Mã Trực Tiếp"]
        BlindGen --> NoSpecCode["Code Chắp Vá, Không Spec, Không Test"]
        NoSpecCode --> VisualCheck["Kiểm Thử Bằng Mắt (Happy Path)"]
        VisualCheck --> DeployRisk["Triển Khai Liều Lĩnh Lên Production"]
        DeployRisk --> CrashDisaster["Sập Hệ Thống & Rò Rỉ Dữ Liệu"]
    end

    subgraph SpecDrivenParadigm ["Mô Hình Mới: Spec-Driven Development (2026-2027)"]
        BizReq["Yêu Cầu Nghiệp Vụ Rõ Ràng"] --> SpecDraft["Soạn Thảo Machine-Readable Spec (AGENTS.md)"]
        SpecDraft --> SchemaLock["Khóa Schema & Ranh Giới Bounded Context"]
        SchemaLock --> GuardedGen["AI Sinh Mã Dưới Ràng Buộc Của Spec"]
        GuardedGen --> AutoVerification["Kiểm Thử Đột Biến & Quét AST Tự Động"]
        AutoVerification --> HumanHandoff["Bàn Giao Kỹ Sư Kèm Bằng Chứng Kiểm Định"]
        HumanHandoff --> HardenedRelease["Phát Hành Production An Toàn"]
    end

2. Vibe Coding Thực Sự Là Gì (Và Không Phải Là Gì)

Andrej Karpathy đã mô tả trải nghiệm đó một cách trực quan: “Tôi chỉ việc nhìn mọi thứ, nói về mọi thứ, chạy thử, và copy-paste.” Quá trình này mang tính ngẫu hứng — bạn mô tả những gì bạn muốn bằng ngôn ngữ tự nhiên, AI tạo ra một bản triển khai (implementation), bạn quan sát kết quả và lặp lại quá trình đó (iterate).

Đến giữa năm 2026, quá trình này đã tiến hóa thành “Vibe & Verify” (Cảm nhận & Xác minh) — chuyển từ việc viết code thủ công sang việc ra quyết định kiến trúc, cung cấp ngữ cảnh và kiểm chứng mạnh mẽ đầu ra của AI bằng các bài kiểm thử. Điều này đánh dấu sự chuyển dịch căn bản từ “Prompt & Pray” sang Spec-Driven Development (Phát triển dựa trên đặc tả).

Vibe coding tạo ra code thực. Đó chính là năng lực vượt trội của nó — và cũng là rủi ro tiềm tàng nếu thiếu sự kiểm soát kỹ thuật.

3. Không Gian Công Cụ Hiện Đại: Lựa Chọn Đúng Vũ Khí

Các công cụ lập trình AI hiện nay phân chia thành các tầng rõ rệt:

Dành Cho Người Xây Dựng Không Chuyên Kỹ Thuật

• Lovable: Không cần thiết lập môi trường cục bộ (local setup), không dòng lệnh, không tệp cấu hình phức tạp. Nhập yêu cầu, hệ thống render giao diện ngay lập tức và cấp live URL sau vài phút.
• Bolt.new & v0 (Vercel): Chạy trực tiếp trên trình duyệt, tạo bản mẫu UI web tuyệt đẹp và hỗ trợ xuất mã nguồn React/Tailwind sạch sẽ.
• Replit: Bổ sung môi trường IDE đám mây hợp tác, giúp người dùng quan sát được các tệp mã nguồn thực tế và từng bước hình thành tư duy hệ thống.

Dành Cho Kỹ Sư Chuyên Nghiệp & Hợp Tác Kỹ Thuật

• Cursor & Windsurf: Các môi trường phát triển tích hợp (IDE) chuyên nghiệp hỗ trợ agentic workflows, khả năng lập chỉ mục toàn bộ codebase bằng vector embeddings và thực thi các quy tắc chỉ dẫn dự án nghiêm ngặt qua .cursor/rules/*.mdc.

4. Kỹ Thuật Viết Prompt Theo Phong Cách Product Manager

Để AI sinh mã chính xác, người dùng không thể đưa ra những câu lệnh mơ hồ. Bạn không phải là người trò chuyện thông thường, bạn là một Product Manager đang giao việc cho một kỹ sư junior có tốc độ gõ phím cực nhanh nhưng hiểu mọi thứ theo nghĩa đen.

Cấu trúc prompt chuẩn hóa dành cho môi trường kỹ thuật:

[VAI TRÒ - ROLE]: Bạn là Chuyên gia Kỹ thuật Backend Go cấp cao chuyên về hệ thống phân tán.
[NGỮ CẢNH - CONTEXT]: Hệ thống đang xử lý 10.000 đơn hàng đồng thời, sử dụng PostgreSQL và Redis cache.
[CHỈ DẪN - INSTRUCTION]: Hãy xây dựng hàm DeductInventory() đảm bảo tính nguyên tử (atomic) và an toàn tuyệt đối trước concurrency race conditions.
[ĐẶC TẢ - SPECIFICATION]:
  1. Sử dụng cú pháp SQL: SELECT ... FOR UPDATE hoặc cơ chế Redis Distributed Lock (Redlock).
  2. Bắt buộc kiểm tra tồn kho khả dụng trước khi trừ; nếu tồn kho < số lượng mua thì trả về ErrInsufficientStock có cấu trúc.
  3. Tuyệt đối không sử dụng lệnh panic(), mọi lỗi phải được bọc bằng fmt.Errorf("deduct inventory failed: %w", err).
[VÍ DỤ - EXAMPLE]: Tham khảo cấu trúc hàm TransferFunds() trong tệp internal/ledger/service.go.

Kỹ thuật cốt lõi: Luôn yêu cầu AI “Hãy suy nghĩ từng bước và trình bày bản thiết kế kiến trúc trước khi viết code” và “Hãy đặt câu hỏi làm rõ nếu có bất kỳ điểm mơ hồ nào trong yêu cầu nghiệp vụ”.

5. Bức Tường Sản Xuất: 5 Tín Hiệu Cảnh Báo Buộc Phải Dừng Lại

Khi phát triển sản phẩm theo mô hình Vibe Coding, các nhà sáng lập thường rơi vào trạng thái hưng phấn ban đầu do tốc độ ra mắt quá nhanh. Tuy nhiên, sự hưng phấn này nhanh chóng bị dập tắt khi ứng dụng bắt đầu va chạm với các ràng buộc vật lý và logic của môi trường thực tế. Đây chính là khái niệm Bức Tường Sản Xuất (The Production Wall).

graph TD
    StartCheck{"Đánh Giá Trạng Thái Ứng Dụng Vibe-Coded"} --> S1{"Tín Hiệu 1: Sửa bug cũ sinh thêm bug mới?"}
    S1 -- Có --> Stop1["DỪNG LẠI: Codebase đã vượt quá cửa sổ ngữ cảnh tin cậy của AI"]
    S1 -- Không --> S2{"Tín Hiệu 2: Hệ thống chạy chậm hoặc lỗi khi có 10 người dùng cùng lúc?"}
    S2 -- Có --> Stop2["DỪNG LẠI: Lỗ hổng Concurrency & Connection Pooling"]
    S2 -- Không --> S3{"Tín Hiệu 3: Xử lý tiền, thông tin thẻ hoặc dữ liệu y tế PII?"}
    S3 -- Có --> Stop3["DỪNG LẠI NGAY: Bắt buộc kiểm toán bảo mật độc lập trước khi mở cổng"]
    S3 -- Không --> S4{"Tín Hiệu 4: Xếp chồng OAuth, Webhooks, và Rate Limits phức tạp?"}
    S4 -- Có --> Stop4["DỪNG LẠI: Giải pháp AI quá mong manh, cần chuẩn hóa kiến trúc"]
    S4 -- Không --> S5{"Tín Hiệu 5: Đã có khách hàng trả tiền thực tế?"}
    S5 -- Có --> Stop5["DỪNG LẠI: Chi phí thất bại lớn hơn lợi ích của việc viết code nhanh"]
    S5 -- Không --> KeepVibing["Tiếp tục khám phá nguyên mẫu trong môi trường thử nghiệm an toàn"]

Dưới đây là 5 tín hiệu cảnh báo rõ ràng nhất cho thấy bạn đã chạm trần năng lực của Vibe Coding và bắt buộc phải đưa kỹ sư phần mềm vào cuộc:

Tín Hiệu 1: Bạn Dành Nhiều Thời Gian Sửa Bug Hơn Là Xây Dựng Tính Năng Mới

Trong giai đoạn đầu, bạn yêu cầu một tính năng và AI hoàn thành trong 30 giây. Nhưng khi codebase chạm ngưỡng 5.000 đến 10.000 dòng, mỗi lần bạn yêu cầu sửa một lỗi nhỏ ở màn hình giỏ hàng, AI lại vô tình làm hỏng logic tính thuế ở màn hình thanh toán. Hiện tượng này xảy ra do mô hình ngôn ngữ bị “mất dấu ngữ cảnh” (Context Drift) đối với toàn bộ dự án. Khi thời gian debug của bạn vượt quá 60% tổng thời gian phiên làm việc, đây là dấu hiệu kiến trúc bên dưới đã bị nứt vỡ thành các mảnh vụn không thể chắp vá bằng prompt.

Tín Hiệu 2: Hệ Thống Tê Liệt Dưới Tải Thực Tế (Concurrency & Connection Exhaustion)

Một ứng dụng do AI sinh ra thường chỉ được thử nghiệm với một người dùng duy nhất — chính là bạn. AI không có trực giác về việc hàng trăm kết nối đồng thời sẽ cạnh tranh tài nguyên như thế nào. Mã nguồn AI thường mở các kết nối cơ sở dữ liệu mới trong mỗi hàm mà không trả lại connection pool, hoặc thực hiện các phép lặp tính toán nặng ngay trong luồng phục vụ HTTP chính (blocking event loop). Khi 20 khách hàng cùng lúc bấm nút đặt hàng, hệ thống sẽ lập tức rơi vào trạng thái nghẽn cổ chai hoặc cạn kiệt bộ nhớ.

Tín Hiệu 3: Xử Lý Dữ Liệu Nhạy Cảm, Thanh Toán Hoặc Thông Tin Cá Nhân (PII)

Đây là lằn ranh đỏ tuyệt đối. Nếu ứng dụng của bạn lưu trữ mật khẩu người dùng, thông tin thẻ tín dụng, hồ sơ bệnh án hoặc các dữ liệu tuân thủ chuẩn GDPR/HIPAA, việc để AI tự do sinh mã cấu hình bảo mật là một hành vi bất cẩn nghiêm trọng. AI không thể hiểu được các quy định pháp lý về quyền riêng tư và thường xuyên để lộ dữ liệu qua các API endpoint không được xác thực.

Tín Hiệu 4: Xếp Chồng Nhiều Tích Hợp Bên Thứ Ba (Webhooks, OAuth, Message Queues)

Khi bạn cần kết nối Stripe để thanh toán, Twilio để gửi SMS, SendGrid để gửi email và Supabase để xác thực, các luồng tương tác bất đồng bộ sẽ trở nên cực kỳ phức tạp. AI thường không xây dựng cơ chế xử lý idempotent (chống trùng lặp giao dịch khi mạng chập chờn) hoặc cơ chế retry có giãn cách số mũ (exponential backoff). Kết quả là người dùng có thể bị trừ tiền hai lần cho một đơn hàng nếu kết nối mạng bị gián đoạn đúng lúc.

Tín Hiệu 5: Doanh Nghiệp Đã Có Khách Hàng Trả Tiền Thực Tế

Khi tiền bạc và niềm tin của người dùng bắt đầu chảy vào sản phẩm, cán cân chi phí - lợi ích đã thay đổi hoàn toàn. Trong giai đoạn làm prototype, tốc độ là số một, lỗi có thể bỏ qua. Nhưng khi đã có khách hàng trả tiền, một giờ ngừng hoạt động (downtime) hoặc một sự cố lộ dữ liệu sẽ dẫn đến kiện tụng pháp lý và hủy hoại vĩnh viễn uy tín thương hiệu. Lúc này, chi phí thuê kỹ sư chuyên nghiệp để gia cố hệ thống là một khoản đầu tư bảo hiểm bắt buộc.

6. Hồ Sơ Sự Cố Moltbook: Phân Tích Nguyên Nhân Gốc Rễ Vụ Rò Rỉ 1,5 Triệu Token

Vụ rò rỉ dữ liệu của mạng xã hội AI Moltbook vào đầu năm 2026 là bài học kinh điển nhất về sự nguy hiểm của việc đưa mã nguồn Vibe-Coded lên môi trường sản xuất mà thiếu sự kiểm duyệt kỹ thuật.

Bối Cảnh Và Triệu Chứng Ban Đầu

Moltbook được phát triển bởi hai nhà sáng lập phi kỹ thuật trong vòng 3 tuần bằng Cursor và Claude 3.5 Sonnet, sử dụng Supabase làm cơ sở dữ liệu và Vercel làm nền tảng hosting. Ứng dụng đạt 50.000 người dùng hoạt động chỉ sau 72 giờ ra mắt trên Product Hunt. Tuy nhiên, vào ngày thứ tư, một chuyên gia nghiên cứu bảo mật độc lập phát hiện toàn bộ cơ sở dữ liệu người dùng — bao gồm khóa API bí mật của các tài khoản doanh nghiệp — có thể được tải về công khai mà không cần bất kỳ quyền quản trị nào.

Phân Tích Kỹ Thuật: Tại Sao Lỗ Hổng Xuất Hiện?

Khi các nhà sáng lập yêu cầu AI tạo bảng dữ liệu api_tokens và viết API cho frontend lấy danh sách token của người dùng hiện tại, AI đã tạo ra bảng nhưng gặp phải lỗi quyền truy cập trong quá trình thử nghiệm cục bộ. Để giải quyết lỗi nhanh nhất nhằm thỏa mãn prompt của người dùng, AI đã đưa ra chỉ dẫn thực thi câu lệnh SQL:

-- Chỉ dẫn tai hại do AI sinh ra để "sửa lỗi nhanh":
ALTER TABLE api_tokens DISABLE ROW LEVEL SECURITY;

Bằng câu lệnh duy nhất này, toàn bộ cơ chế phân quyền bảo mật cấp hàng (Row Level Security) của PostgreSQL đã bị vô hiệu hóa. Khi thư viện Supabase client trong trình duyệt của người dùng gửi yêu cầu supabase.from('api_tokens').select('*'), máy chủ cơ sở dữ liệu không còn kiểm tra xem người yêu cầu có phải là chủ sở hữu của token đó hay không, mà trả về toàn bộ 1,5 triệu bản ghi của tất cả người dùng trong hệ thống.

Nghịch Lý Của Sự Tin Tưởng (The Trust Paradox)

Điểm đáng suy ngẫm nhất của vụ việc là các nhà sáng lập Moltbook hoàn toàn không biết rằng hệ thống của họ đang bị hở sườn. Do bài kiểm tra của họ trên máy cá nhân diễn ra rất suôn sẻ (họ đăng nhập vào tài khoản của mình và thấy hiển thị đúng token của mình), họ tin tưởng 100% rằng tính năng bảo mật đã hoạt động. Đây chính là minh chứng sống động cho Nghịch Lý Sự Tin Tưởng: người không chuyên kỹ thuật thường nhầm lẫn giữa việc “hệ thống hoạt động đúng kịch bản mong đợi” với việc “hệ thống có khả năng tự vệ trước kịch bản tấn công ác ý”.

6. Hiện Thực Hóa Rào Chắn: Go 1.25+ Security Spec Validator Cho Supabase RLS

Để ngăn chặn thảm họa Moltbook lặp lại, các kỹ sư xây dựng các công cụ CLI tự động quét cơ sở dữ liệu và mã nguồn nhằm phát hiện việc thiếu vắng các chính sách Row-Level Security (RLS). Dưới đây là chương trình Go 1.25+ hoàn chỉnh, sẵn sàng tích hợp vào CI/CD:

package securityvalidator

import (
	"context"
	"database/sql"
	"errors"
	"fmt"
	"regexp"
	"strings"
	"time"
)

// TableSecurityStatus phản ánh trạng thái an toàn của một bảng dữ liệu quan hệ.
type TableSecurityStatus struct {
	TableName    string `json:"table_name"`
	RLSEnabled   bool   `json:"rls_enabled"`
	PolicyCount  int    `json:"policy_count"`
	HasOpenWrite bool   `json:"has_open_write"`
	IsExposed    bool   `json:"is_exposed"`
}

// SecurityAuditReport tổng hợp toàn bộ kết quả kiểm toán bảo mật cơ sở dữ liệu.
type SecurityAuditReport struct {
	TotalTablesAudited int                   `json:"total_tables_audited"`
	VulnerableTables   []TableSecurityStatus `json:"vulnerable_tables"`
	AuditPassed        bool                  `json:"audit_passed"`
	ExecutionTime      time.Duration         `json:"execution_time"`
}

// SQLSchemaInspector thực hiện thẩm định mã nguồn SQL tĩnh và cơ sở dữ liệu thực nghiệm.
type SQLSchemaInspector struct {
	rlsPattern    *regexp.Regexp
	policyPattern *regexp.Regexp
}

// NewSQLSchemaInspector khởi tạo bộ kiểm tra bảo mật SQL mới.
func NewSQLSchemaInspector() *SQLSchemaInspector {
	return &SQLSchemaInspector{
		rlsPattern:    regexp.MustCompile(`(?i)ALTER\s+TABLE\s+(?:ONLY\s+)?(\w+)\s+ENABLE\s+ROW\s+LEVEL\s+SECURITY`),
		policyPattern: regexp.MustCompile(`(?i)CREATE\s+POLICY\s+(\w+)\s+ON\s+(\w+)`),
	}
}

// AuditDDLContent phân tích chuỗi mã SQL DDL di chuyển dữ liệu (migrations) được tạo ra bởi AI.
func (si *SQLSchemaInspector) AuditDDLContent(ctx context.Context, ddlContent string) ([]TableSecurityStatus, error) {
	select {
	case <-ctx.Done():
		return nil, ctx.Err()
	default:
	}

	tableRegex := regexp.MustCompile(`(?i)CREATE\s+TABLE\s+(?:IF\s+NOT\s+EXISTS\s+)?(\w+)`)
	tableMatches := tableRegex.FindAllStringSubmatch(ddlContent, -1)

	var results []TableSecurityStatus
	rlsEnabledMap := make(map[string]bool)
	policyCountMap := make(map[string]int)

	for _, m := range si.rlsPattern.FindAllStringSubmatch(ddlContent, -1) {
		if len(m) > 1 {
			rlsEnabledMap[strings.ToLower(m[1])] = true
		}
	}

	for _, m := range si.policyPattern.FindAllStringSubmatch(ddlContent, -1) {
		if len(m) > 2 {
			tbl := strings.ToLower(m[2])
			policyCountMap[tbl]++
		}
	}

	for _, tm := range tableMatches {
		if len(tm) > 1 {
			tName := strings.ToLower(tm[1])
			rlsOn := rlsEnabledMap[tName]
			pCount := policyCountMap[tName]

			isVuln := !rlsOn || (rlsOn && pCount == 0)
			results = append(results, TableSecurityStatus{
				TableName:   tName,
				RLSEnabled:  rlsOn,
				PolicyCount: pCount,
				IsExposed:   isVuln,
			})
		}
	}

	return results, nil
}

// ValidateProductionDatabase kiểm tra trực tiếp cụm PostgreSQL qua truy vấn metadata hệ thống.
func ValidateProductionDatabase(ctx context.Context, db *sql.DB) (*SecurityAuditReport, error) {
	start := time.Now()
	query := `
		SELECT 
			c.relname AS table_name,
			c.relrowsecurity AS rls_enabled,
			COUNT(p.polname) AS policy_count
		FROM pg_class c
		JOIN pg_namespace n ON n.oid = c.relnamespace
		LEFT JOIN pg_policy p ON p.polrelid = c.oid
		WHERE n.nspname = 'public' AND c.relkind = 'r'
		GROUP BY c.relname, c.relrowsecurity;
	`

	rows, err := db.QueryContext(ctx, query)
	if err != nil {
		return nil, fmt.Errorf("không thể truy vấn siêu dữ liệu pg_class: %w", err)
	}
	defer rows.Close()

	var vulnerable []TableSecurityStatus
	total := 0

	for rows.Next() {
		total++
		var status TableSecurityStatus
		if err := rows.Scan(&status.TableName, &status.RLSEnabled, &status.PolicyCount); err != nil {
			return nil, fmt.Errorf("quét kết quả truy vấn thất bại: %w", err)
		}

		if !status.RLSEnabled || (status.RLSEnabled && status.PolicyCount == 0) {
			status.IsExposed = true
			vulnerable = append(vulnerable, status)
		}
	}

	if err := rows.Err(); err != nil {
		return nil, errors.New("lỗi trong quá trình duyệt hàng dữ liệu: " + err.Error())
	}

	return &SecurityAuditReport{
		TotalTablesAudited: total,
		VulnerableTables:   vulnerable,
		AuditPassed:        len(vulnerable) == 0,
		ExecutionTime:      time.Since(start),
	}, nil
}

Đoạn mã trên chứng minh cách áp dụng kỷ luật phần mềm để tự động hóa khâu kiểm tra an ninh cơ sở dữ liệu, đảm bảo không có bảng dữ liệu nào bị phơi nhiễm ra internet công cộng do sai sót của AI.

7. Giao Thức Bàn Giao Kỹ Thuật Chuẩn Mực (The Production Handoff)

Khi chạm vào Bức tường Sản xuất, việc bàn giao dự án từ Vibe Coder cho kỹ sư quyết định sự thành bại và chi phí của dự án. Một gói bàn giao chuyên nghiệp cần bao gồm:

1. Bản Đặc Tả Yêu Cầu Sản Phẩm (PRD Rút Gọn): Liệt kê các luồng nghiệp vụ chính, các quyền hạn người dùng và các tình huống ngoại lệ mong muốn.
2. Minh Bạch Về Nguồn Gốc Mã Nguồn: Khai báo rõ ràng các module được sinh ra bởi AI và những câu prompt ban đầu đã sử dụng.
3. Danh Sách Giả Định Kiến Trúc: Ghi chép lại những gì AI đã tự động quyết định (cấu trúc bảng, thư viện bên thứ ba, cơ chế xác thực).
4. Bản Đồ Cấu Hình & Secret: Cung cấp thông tin môi trường và các biến khóa bí mật qua các kênh an toàn (Vault, 1Password), tuyệt đối không gửi qua chat hay hardcode trong Git.

❓ Câu Hỏi Thường Gặp (FAQ)

← Chương trước: Executive Summary | Mục lục Series | Chương tiếp theo: Phần 2: Context Engineering →