AI Developer Mindset — Think in Prompts, Rules & Skills

A bilingual guide on the developer mindset for working effectively with AI. From crafting prompts to defining rules and skills — the thinking framework that separates power users from casual prompters.

MAY 29, 2025 11 MIN READ

Tại sao tư duy quan trọng hơn cú pháp

Hầu hết dev tiếp cận AI như công cụ tìm kiếm — gõ câu hỏi, nhận câu trả lời. Cách này hoạt động cho task nhỏ. Nhưng với công việc nghiêm túc, sự khác biệt giữa người dùng AI tốt và xuất sắc không phải cú pháp prompt — mà là cách họ nghĩ về sự hợp tác.

Bài viết này bao gồm ba cấp độ tích hợp AI-developer:

tầng hội thoại
tầng rào chắn
tầng quy trình

Mỗi cấp độ giải quyết một vấn đề cụ thể. Kết hợp lại, chúng tạo thành hệ thống tiến triển khiến AI thực sự hữu ích thay vì chỉ tiện lợi.

Mô hình tư duy

Hãy nghĩ AI agent như thành viên mới trong team:

┌─────────────────────────────────────────────────────────────┐
│                    Your AI Integration Stack                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  SKILLS ──── "Here's the full playbook for X workflow"      │
│              "Đây là cẩm nang đầy đủ cho quy trình X"      │
│              (complex, multi-step, reusable)                 │
│                                                             │
│  RULES ───── "Always follow these conventions"              │
│              "Luôn tuân theo các quy ước này"               │
│              (persistent, automatic, lightweight)            │
│                                                             │
│  PROMPTS ─── "Do this specific thing right now"             │
│              "Làm việc cụ thể này ngay bây giờ"            │
│              (ephemeral, contextual, one-shot)               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Nhận thức then chốt: bạn nên nâng cấp pattern lên trên. Nếu bạn cứ viết cùng một prompt → biến nó thành rule. Nếu rule trở nên phức tạp → biến nó thành skill.

Cấp 1: Prompt hiệu quả

Khung CIDER

Mọi prompt hiệu quả đều có năm yếu tố:

Element	Nghĩa	Ví dụ
Context	Thông tin nền AI cần	”This is a Next.js 16 app using App Router”
Intent	Bạn muốn đạt được gì	”Add error handling to the checkout flow”
Details	Chi tiết và ràng buộc	”Use toast notifications, not alert()“
Examples	Cho xem, không chỉ nói	”Like how /login handles auth errors”
Restrictions	Những gì KHÔNG được làm	”Don’t modify the payment service”

Prompt tệ và tốt

Tệ — mơ hồ, không ngữ cảnh, không rõ ràng:

Fix the bug in the login page

Tốt hơn — có ý định và một ít ngữ cảnh:

The login form submits but doesn't redirect to /dashboard after success.
Fix the redirect logic in app/login/actions.ts.

Tốt nhất — đầy đủ CIDER, AI hầu như không cần đoán:

Context: Next.js 16 app with App Router. Auth uses server actions in
app/login/actions.ts. After successful login, user should go to /dashboard.

Problem: Login succeeds (I can see the session cookie set) but the page stays
on /login. No errors in console.

Constraint: Don't change the auth logic — only fix the redirect. We use
redirect() from next/navigation, not router.push().

Reference: The /register flow works correctly — check app/register/actions.ts
for how it handles post-auth redirect.

Quy tắc 80/20 của Prompting

80% chất lượng prompt đến từ:

Cụ thể về điều bạn muốn — không phải “làm tốt hơn”, mà “giảm bundle size bằng cách lazy-load thư viện chart”
Cho thấy trạng thái hiện tại — dán lỗi, đính kèm file, mô tả những gì đang xảy ra BÂY GIỜ
Xác định ranh giới — ""chỉ sửa các file này”, “không thêm dependency mới”

20% còn lại là giọng điệu, định dạng, và hướng dẫn persona — tốt để có, không thiết yếu.

Các pattern prompt cho Developer

Pattern Khoá phạm vi

Ngăn AI làm thay đổi không cần thiết:

Scope: ONLY modify src/components/Modal.tsx
Do NOT touch: global styles, other components, package.json

Task: Add keyboard trap (focus stays inside modal when open, ESC closes it)

Pattern Trước/Sau

Khi bạn muốn một biến đổi cụ thể:

Current behavior: clicking "Save" shows a loading spinner that never disappears
Expected behavior: spinner shows for max 3s, then either success toast or error toast
File: src/components/SaveButton.tsx

Pattern Dạy-Tôi

Khi bạn muốn hiểu, không chỉ nhận code:

Explain how React Server Components decide what to include in the client bundle.
Use a concrete example from this codebase. Show me which imports would end up
in the browser and why.

Pattern Từng-bước

Chia task phức tạp thành các điểm kiểm tra:

We're adding dark mode. Let's do this step by step:
1. First, add CSS variables for both themes in global.css
2. Wait for my review before proceeding to step 2

Cấp 2: Rules — Rào chắn vĩnh viễn

Khi nào tạo Rule

Tạo rule khi bạn thấy mình sửa AI về cùng một điều lặp đi lặp lại:

Pattern recognition:
{Nhận diện pattern:}

"Don't use any"         → 3rd time → Rule: "No `any` in TypeScript"
"Use kebab-case"        → 3rd time → Rule: "File naming: kebab-case.ts"
"We use pnpm not npm"   → 2nd time → Rule: "Package manager: pnpm only"
"Don't add comments"    → 5th time → Rule: "Comments: only explain WHY"

Quy tắc 3-lần: nếu bạn sửa AI cùng một điều ba lần, đã đến lúc viết rule.

Cấu trúc Rule tốt

Một rule nên: ngắn, cụ thể, và có thể hành động.

# TypeScript Conventions

- No `any` — use `unknown` then narrow with type guards
- No `@ts-ignore` — fix the actual type error
- No `as` assertions unless after runtime validation (e.g. after zod.parse())
- Prefer `type` for unions, `interface` for object shapes
- Import types with `import type` for tree-shaking

Rule tệ — quá mơ hồ để thực thi:

# Code Quality
Write good code. Follow best practices. Make it clean.

Rule tốt — cụ thể, kiểm tra được:

# Naming
- Files: kebab-case.ts (utils), PascalCase.tsx (components)
- Variables: camelCase
- Types/Interfaces: PascalCase, no "I" prefix
- Constants: UPPER_SNAKE_CASE only for true compile-time constants

Phân loại Rule

Tổ chức rule theo phạm vi:

Loại	Mục đích	Ví dụ
Prohibitions	Những thứ KHÔNG BAO GIỜ làm	No `any`, no `!important`, no hard-coded secrets
Conventions	Cách mọi thứ nên được làm	Naming, file structure, import order
Architecture	Ranh giới hệ thống	”No React — pure Astro”, “SSG only”
Content	Tiêu chuẩn viết	”Start from h2”, “max 5 tags”, “description required”

Bộ rule tối thiểu khả dụng

Bắt đầu với 4 rule này cho mọi project:

project này LÀ gì
đặt tên, style, type safety
những thứ KHÔNG BAO GIỜ được xảy ra
mọi thứ ở đâu, cấu trúc thế nào

Vậy đủ. Bốn rule bao phủ 90% những gì bạn sẽ lặp lại trong prompt.

Cấp 3: Skills — Tự động hoá quy trình

Khi nào tạo Skill

Tạo skill khi:

Một quy trình có 5+ bước phải xảy ra theo thứ tự
Quy trình lặp lại — bạn làm hàng tuần hoặc nhiều hơn
Quy trình cần kiến thức chuyên môn cụ thể

Examples of skill-worthy workflows:
{Ví dụ các quy trình đáng tạo skill:}

- "Implement a Jira ticket" (read ticket → plan → code → test → PR)
- "Self-review before push" (diff → lint → type-check → review → fix)
- "Write a blog post" (research → outline → draft → edit → publish)
- "Split work into PRs" (analyze changes → group → create branches → push)

Skill vs Rule vs Prompt — Cây quyết định

Is this instruction...

  One-time? ─────────────────────── → PROMPT
  {Một lần?}                           {just say it in chat}

  Repeated & simple? ───────────── → RULE
  {Lặp lại & đơn giản?}               {write a .mdc file}

  Repeated & complex (5+ steps)? ─ → SKILL
  {Lặp lại & phức tạp (5+ bước)?}     {write a SKILL.md}

Cấu trúc Skill tốt

Skill là cẩm nang từng bước mà AI tuân theo tự động:

# Deploy to Production

## Steps

1. Run `npm run build` — verify no errors
2. Run `npm run test` — all tests must pass
3. Check `git status` — no uncommitted changes
4. Create git tag with format `v{version}`
5. Push tag: `git push origin v{version}`
6. Wait for CI to pass (check GitHub Actions)
7. If CI fails, report the error and stop

## Constraints

- Never deploy on Friday after 4pm
- Never skip tests even if "just a typo"
- If build fails, fix it before retrying

Pattern Nâng cấp tiến triển

Xem cách một kiến thức tự nhiên phát triển:

Day 1 (Prompt):
  "Use pnpm, not npm. And use kebab-case for filenames."
  {Dùng pnpm, không phải npm. Và dùng kebab-case cho tên file.}

Day 3 (Still prompting the same thing):
  "Remember — pnpm! And kebab-case files!"
  {Nhớ nhé — pnpm! Và kebab-case cho file!}

Day 5 (Create a Rule):
  # coding-standards.mdc
  - Package manager: pnpm (never npm or yarn)
  - File naming: kebab-case.ts for utilities

Day 30 (Rule grows into a Skill):
  # create-component/SKILL.md
  1. Create file: src/components/{category}/{name}.astro
  2. Use kebab-case for filename
  3. Add Props interface with JSDoc
  4. Register in barrel export if exists
  5. Add to Storybook if component is reusable

Quy trình AI của Developer

Vòng lặp hàng ngày

Morning:
{Buổi sáng:}
  1. Review what AI did yesterday (if async tasks ran)
     {Xem lại AI đã làm gì hôm qua (nếu có task chạy nền)}
  2. Plan today's tasks — which ones benefit from AI?
     {Lên kế hoạch ngày — task nào được lợi từ AI?}
  3. Start with hardest task (your brain is fresh, AI benefits from clear thinking)
     {Bắt đầu với task khó nhất (não bạn còn tươi, AI hưởng lợi từ tư duy rõ)}

During coding:
{Trong lúc code:}
  4. Use AI for implementation after YOU design the approach
     {Dùng AI để implement sau khi BẠN thiết kế cách tiếp cận}
  5. Review every change — AI is fast but makes subtle mistakes
     {Review mọi thay đổi — AI nhanh nhưng mắc lỗi tinh vi}
  6. When you correct AI → ask "Should this be a rule?"
     {Khi bạn sửa AI → hỏi "Cái này có nên là rule không?"}

End of day:
{Cuối ngày:}
  7. Reflect: what repeated? What was slow? What was wrong?
     {Suy ngẫm: cái gì lặp? Cái gì chậm? Cái gì sai?}
  8. Promote patterns: prompt → rule → skill
     {Nâng cấp pattern: prompt → rule → skill}

Phân chia 70/30

Phân chia AI-người lý tưởng cho engineering nghiêm túc:

Bạn làm (30%)	AI làm (70%)
Quyết định kiến trúc	Implement các pattern đã quyết
Nhận diện edge case	Viết code thực tế
Review code	Refactoring, renaming, restructuring
Thiết kế trải nghiệm	Boilerplate, tests, documentation
""Nên xây gì?"	""Cách implement cái bạn đã quyết”

KHÔNG BAO GIỜ giao cho AI:

Quyết định bảo mật quan trọng
Thiết kế data model
“Nên dùng thư viện X hay Y?”
Đánh đổi hiệu năng

LUÔN giao cho AI:

Viết test cho logic đã thiết kế
Tạo khung file và boilerplate
Tìm pattern trong codebase
Định dạng, lint, sắp xếp import

Các Anti-Pattern phổ biến

1. Prompt “Làm hết đi”

❌ "Build me a complete e-commerce site with auth, payments, and admin panel"

Cái này thất bại vì: tràn context window, không có điểm dừng rõ ràng, AI đưa ra hàng chục quyết định kiến trúc bạn không duyệt.

Sửa: chia thành các giai đoạn, thiết kế trước, implement từng phần.

2. Tư duy “Tin hết”

❌ AI writes code → You commit without reading → Bug in production

Sửa: luôn review. Đọc diff. Chạy test. AI là người nháp, bạn là biên tập.

3. Bẫy “Không bao giờ tuỳ chỉnh”

❌ Using AI for 6 months with zero rules, zero skills
   Correcting the same mistakes 500 times

Sửa: dành 30 phút viết 4 rule đầu tiên. ROI ngay lập tức.

4. Bẫy “Thiết kế quá mức”

❌ 50 rules, 20 skills, configuration more complex than the codebase

Sửa: bắt đầu tối thiểu. Thêm rule chỉ khi bạn thấy khó chịu. Nếu rule không được kích hoạt hàng tuần, xoá nó.

Mẫu thực tế

Mẫu Rule khởi đầu

# Project Context

## What this is
[1-2 sentences: what the project does, who uses it]

## Stack
[List: framework, language, key libraries]

## Key directories
[Table: path → purpose]

## Conventions
- [Naming rules]
- [File organization rules]
- [Import rules]

## Prohibitions
- [Things that must never happen]
- [Security boundaries]

Mẫu Prompt cho task phức tạp

## Context
- Project: [name, stack, current state]
- File(s): [which files are relevant]

## Task
[What needs to happen — be specific]

## Constraints
- Only modify: [list files]
- Don't change: [list things to preserve]
- Must maintain: [backwards compatibility? types? tests?]

## Reference
- Similar implementation: [point to existing code]
- Docs: [relevant documentation URL]

## Acceptance Criteria
- [ ] [Specific checkable outcome 1]
- [ ] [Specific checkable outcome 2]

Sự chuyển đổi tư duy

Nhận thức cuối cùng: làm việc với AI không phải về biết cú pháp prompt đúng. Mà là về suy nghĩ đủ rõ ràng để một thực thể khác có thể thực thi ý định của bạn.

Đây là cùng kỹ năng với:

Viết Jira ticket rõ ràng
Onboard thành viên mới
Viết documentation
Thiết kế API

Nếu bạn có thể giải thích ý định rõ ràng cho người, bạn có thể prompt AI hiệu quả. AI chỉ ít kiên nhẫn hơn với sự mơ hồ.

Bắt đầu hôm nay:

Viết 4 rule cho project hiện tại
Lần tới bạn sửa AI, hỏi: “Cái này có nên là rule không?”
Sau 2 tuần, kiểm tra prompt nào bạn cứ lặp lại → nâng cấp chúng

Hiệu ứng kép là thật. Trong một tháng, AI của bạn sẽ cảm thấy như một công cụ khác — vì bạn đã dạy nó cách TEAM BẠN làm việc.