Kiến thức / Công nghệ – Phần mềm / Công nghệ / Phần mềm

AI Agent cho Lập trình viên: use case, dữ liệu và quyền

AI Agent cho Lập trình viên: danh mục use case, hợp đồng dữ liệu và ranh giới quyền

Tình huống thật: hàng đợi code review ngày càng dài

Sáng đầu tuần, nhóm GitHub có nhiều pull request chờ đọc, Zalo của đội liên tục nhắc người review, phản hồi sản phẩm từ Messenger chưa được nối về ticket, danh sách người sở hữu module nằm trong Google Sheets và việc ưu tiên ở Base.vn. Một lập trình viên phải mở từng tab để biết thay đổi nào cần chuyên gia bảo mật, thay đổi nào chỉ cần kiểm convention và ai có quyền quyết định.

AI Agent cho Lập trình viên có thể hỗ trợ hàng đợi này nếu đội bắt đầu bằng inventory use case thay vì nối Agent thẳng vào repository. Agent nên đọc metadata, đối chiếu quy ước và tạo bản nháp phục vụ review; nó không được tự phê duyệt, merge, thay đổi kiến trúc hay triển khai. Bản đồ này chỉ tập trung vào use case, data contract, ma trận rủi ro và permission boundary, rồi dừng trước giai đoạn thực thi.

Việc giao cho AI trong inventory use case

Nhóm “định vị tri thức” gồm tìm tài liệu đúng phiên bản, nối module với CODEOWNERS, tóm tắt quyết định kiến trúc và giải thích thuật ngữ nội bộ có nguồn. Nhóm “chuẩn bị review” gồm tạo change summary, liệt kê tệp tác động, đối chiếu naming convention, phát hiện tài liệu chưa cập nhật và dựng checklist theo loại thay đổi.

Nhóm “duyệt bắt buộc” gồm nhận xét về kiến trúc, bảo mật, dữ liệu, hiệu năng và khả năng tương thích. AI chỉ tạo câu hỏi hoặc DRAFT để chuyên gia xem. Nhóm “chỉ con người” gồm chấp nhận đánh đổi, phê duyệt migration, cấp secret, merge vào nhánh bảo vệ, thay policy và triển khai production. Mỗi use case phải có đầu ra quan sát được, owner, nguồn, rủi ro cùng quyền tối đa. Cùng một thao tác có thể mang mức quyền khác nhau theo module: kiểm quy ước ở vùng tài liệu công khai khác hoàn toàn việc đọc cấu hình bảo mật nội bộ.

Dữ liệu cần chuẩn bị thành hợp đồng rõ ràng

Data contract cho Agent không phải toàn bộ codebase. Nó gồm sơ đồ repository, danh mục module, CODEOWNERS, coding convention, ADR còn hiệu lực, API contract, dependency policy, nhãn rủi ro và mẫu đầu ra review. Mỗi nguồn có mã, phiên bản, branch, owner, phạm vi sử dụng và ngày rà soát. Tài liệu hết hiệu lực không được ghép với mã hiện tại.

Đội cũng cần taxonomy cho loại thay đổi: giao diện, API, dữ liệu, cấu hình, quyền, hạ tầng hoặc tài liệu. Mỗi loại gắn trường bắt buộc và reviewer. Secrets, dữ liệu production, khóa cá nhân và nội dung ngoài phạm vi bị loại. Agent đọc bản sao hoặc view đã lọc. Nếu contract thiếu owner, branch hoặc policy version, đầu ra phải chuyển CHỜ_BỔ_SUNG.

Workflow sáu bước lập ma trận rủi ro và quyền

Bước 1 — Thu thập use case: ghi việc, người dùng, đầu vào, đầu ra và quyết định liên quan. Bước 2 — Chuẩn hóa data contract: chỉ định trường, nguồn, phiên bản và owner cho từng use case. Thiếu nguồn thì chưa đưa vào thí điểm.

Bước 3 — Chấm rủi ro: đánh giá tác động tới bảo mật, dữ liệu, nhiều dịch vụ, nhánh bảo vệ và khả năng quay lại. Bước 4 — Gán permission boundary: dùng ĐỌC, TẠO_NHÁP, YÊU_CẦU_REVIEW hoặc CHỈ_CON_NGƯỜI. Không gộp quyền đọc với quyền ghi.

Bước 5 — Chạy bộ tình huống đánh giá: gồm tài liệu cũ, owner trống, thay đổi nhạy cảm và yêu cầu vượt repository. Bước 6 — Duyệt cùng thu hẹp: tech lead xem kết quả, lỗi nguồn và quyền; nếu Agent vượt ranh giới, thu hồi kết nối và sửa contract trước khi chạy lại.

Bản đồ inventory use case, data contract, risk matrix và permission boundary cho lập trình viên — Sơ đồ minh họa cách đi từ danh mục use case tới quyền tối đa và cổng tech lead duyệt.

Prompt mẫu để thiết kế bản đồ kỹ thuật

Năm prompt của bài phục vụ thiết kế hệ thống: tạo inventory use case, viết data contract, dựng ma trận rủi ro, xác định permission boundary và lập bộ đánh giá thí điểm. Chúng kết thúc ở thiết kế inventory và tài liệu quản trị; mọi hành động vận hành nằm ngoài phạm vi. Mỗi đầu ra là tài liệu DRAFT để đội kỹ thuật duyệt.

Khi điền, dùng module giả lập như MODULE-DEMO-A và loại bỏ tên hệ thống nhạy cảm. Không yêu cầu Agent đề xuất quyền rộng hơn để “tiện”. Kết quả phải chỉ rõ nguồn, owner và lý do phân loại. Một use case chưa có reviewer hoặc không có cách quay lại nên giữ ngoài phạm vi, dù giá trị dự kiến có vẻ lớn.

Công cụ phù hợp và cách tách vùng truy cập

GitHub hoặc GitLab giữ metadata repository, review và ownership; VS Code là không gian lập trình viên đọc gợi ý. Base.vn quản lý trách nhiệm ngoài repository; Google Sheets có thể là sổ inventory tạm. Zalo và Messenger chỉ nhận thông báo có liên kết về nguồn chính. Agent không lấy nội dung kỹ thuật từ nhóm chat làm nguồn chuẩn.

Tách vùng NGUỒN_CHỈ_ĐỌC, AI_NHÁP và NGƯỜI_ĐÃ_DUYỆT. Tài khoản Agent không có secret ghi, quyền merge, thay branch protection hoặc sửa CODEOWNERS. Mỗi lần truy xuất lưu use_case_id, data_contract_version, prompt_version và reviewer. Quyền có hạn và được thu hồi khi module đổi owner hoặc use case kết thúc.

Ma trận use case, dữ liệu, rủi ro và quyền repository minh họa — Hình minh họa bốn mức quyền và các vùng dữ liệu tách biệt cho Agent cùng reviewer.

AI làm gì và người duyệt quyết định gì

AI lập danh mục, chuẩn hóa metadata, trích tài liệu, so version và tạo change summary hoặc checklist nháp. Nó có thể báo thiếu CODEOWNER, ADR hết hiệu lực hay loại thay đổi chưa được gắn nhãn. Agent không phán quyết thiết kế đúng hay sai và không thay reviewer chịu trách nhiệm.

Lập trình viên xác nhận ngữ cảnh module, đọc mã và chỉnh nháp. Tech lead sở hữu risk matrix, permission boundary và quyết định kiến trúc. Chuyên gia bảo mật, dữ liệu hoặc hạ tầng duyệt phần thuộc miền của họ. Repository administrator quản lý token cùng branch protection. Không một điểm quyết định nào được chuyển cho AI vì câu trả lời có vẻ hợp lý.

Sai lầm và rủi ro cần tránh

Sai lầm đầu tiên là xem “đọc repository” như một quyền duy nhất. Thứ hai là dùng tài liệu không gắn branch và version. Thứ ba là gộp việc tìm thông tin với quyền đưa nhận xét quyết định. Thứ tư là cho Agent đọc secret vì nghĩ nó sẽ không lộ. Thứ năm là dùng cùng permission cho mọi module.

Rủi ro còn nằm ở dependency license, mã sở hữu trí tuệ, prompt injection trong tài liệu và gợi ý vượt phạm vi. Cần coi nội dung repository là dữ liệu, không phải lệnh điều khiển. Nếu Agent yêu cầu thêm quyền, truy cập ngoài contract, tạo thay đổi thay vì DRAFT hoặc thiếu nguồn, hệ thống dừng và chuyển người quản trị.

Triển khai cá nhân, đội và doanh nghiệp

Cá nhân bắt đầu với một use case đọc, chẳng hạn nối tệp với guideline. Đội nhỏ chọn ba use case khác rủi ro, thống nhất contract và reviewer. Doanh nghiệp thêm catalog, identity, policy, audit và bộ đánh giá theo miền. Không triển khai cùng lúc trên mọi repository; ownership cùng risk profile khác nhau.

Mỗi chu kỳ đo độ đúng nguồn, phần nháp phải sửa, yêu cầu vượt quyền, thời gian reviewer và số trường hợp fail-closed. Chỉ mở rộng quyền đọc khi bằng chứng ổn định; quyền ghi, merge hoặc deploy vẫn thuộc con người. Nếu ownership thay đổi hoặc contract lỗi thời, use case quay lại trạng thái thiết kế.

Kết quả đầu ra mẫu và câu hỏi thường gặp

Dữ liệu minh họa: MAP-DEV-DEMO-03 có 16 use case, 6 data contract, 4 mức quyền và 5 nhóm rủi ro. Chín use case ở ĐỌC hoặc TẠO_NHÁP, bốn YÊU_CẦU_REVIEW và ba CHỈ_CON_NGƯỜI; không có repository thật hoặc secret.

Nên chọn use case đầu tiên thế nào?

Chọn đầu ra đọc hoặc nháp, nguồn rõ, owner sẵn sàng, hậu quả thấp và có cách đối chiếu độc lập.

Agent có cần đọc toàn bộ repository không?

Không. Data contract chỉ cấp module, metadata và tài liệu cần cho use case; quyền theo nguyên tắc tối thiểu.

Permission boundary gồm những gì?

Gồm hệ thống, vùng dữ liệu, hành động, thời hạn, reviewer, log và trigger thu hồi; không chỉ là một token truy cập.

Khi nào use case phải dừng?

Khi nguồn hết hiệu lực, owner trống, Agent vượt phạm vi, xuất hiện secret hoặc đầu ra cần quyết định ngoài quyền.

Xem tiếp delivery lifecycle có change request và bộ prompt incident. Cần xây inventory theo repository hiện có, liên hệ NganAds hoặc Zalo 0983543063.

Workflow

Bước 1: Thu thập inventory use case — Ghi người dùng, việc, đầu vào, đầu ra, owner và quyết định liên quan cho từng use case.
Bước 2: Chuẩn hóa data contract — Chỉ định nguồn, branch, version, owner, allowed use và dữ liệu bị loại.
Bước 3: Chấm risk matrix — Đánh giá bảo mật, dữ liệu, phạm vi, khả năng phục hồi và phán đoán chuyên môn.
Bước 4: Gán permission boundary — Tách ĐỌC, TẠO_NHÁP, YÊU_CẦU_REVIEW và CHỈ_CON_NGƯỜI; không có merge hoặc deploy.
Bước 5: Chạy bộ tình huống đánh giá — Kiểm nguồn cũ, thiếu owner, secret giả lập, nội dung điều khiển và yêu cầu ngoài phạm vi.
Bước 6: Tech lead duyệt và thu hẹp — Xem lỗi nguồn cùng quyền; vượt ranh giới thì thu hồi kết nối và sửa contract.

Prompt mẫu

Tạo inventory use case theo vai trò

MỤC TIÊU: Chuyển danh sách việc kỹ thuật thành inventory use case có người dùng, đầu ra và quyết định liên quan.

[ĐẦU VÀO]
WORK_ACTIVITIES = [VIỆC, TẦN SUẤT, NGƯỜI LÀM]
REPOSITORY_AREAS = [MODULE GIẢ LẬP]
CURRENT_HANDOFFS = [NGƯỜI GIAO, NGƯỜI NHẬN]
KNOWN_FRICTION = [CHỜ REVIEW, TÌM NGUỒN, SAI VERSION]

YÊU CẦU: Chỉ lập danh mục, không đề xuất hành động thực thi hoặc quyền công cụ. Mỗi use case chỉ có một đầu ra quan sát được và một owner.

ĐỊNH DẠNG ĐẦU RA: Bảng Use case | Người dùng | Vấn đề | Đầu vào | Đầu ra | Quyết định còn lại | Owner.

VÍ DỤ ĐIỀN SẴN: MODULE-DEMO-A có use case tìm guideline, nối CODEOWNER và tạo change summary nháp cho hàng đợi review.

Viết data contract cho tri thức repository

MỤC TIÊU: Xác định bộ trường, nguồn, phiên bản và owner tối thiểu cho một use case AI trong repository.

[ĐẦU VÀO]
USE_CASE_ID = [MÃ USE CASE]
SOURCE_CANDIDATES = [REPO MAP, ADR, CODEOWNERS, CONVENTION]
BRANCH_AND_VERSION = [PHẠM VI]
EXCLUDED_DATA = [SECRET, PRODUCTION DATA, NGOÀI MODULE]

YÊU CẦU: Không cấp toàn bộ codebase theo mặc định. Nguồn mâu thuẫn hoặc thiếu owner phải CHỜ_BỔ_SUNG; ghi allowed_use cho từng trường.

ĐỊNH DẠNG ĐẦU RA: Bảng Trường | Nguồn | Version | Owner | Allowed use | Consumer | Review date | Stop condition.

VÍ DỤ ĐIỀN SẴN: UC-DEMO-04 chỉ đọc repo map, ADR-07 và CODEOWNERS ở branch demo; loại secret cùng dữ liệu thật.

Dựng risk matrix cho use case

MỤC TIÊU: Phân loại rủi ro của use case theo bảo mật, dữ liệu, phạm vi ảnh hưởng, khả năng phục hồi và phán đoán chuyên môn.

[ĐẦU VÀO]
USE_CASES = [DANH SÁCH ĐÃ DUYỆT]
DATA_CLASS = [CÔNG KHAI/NỘI BỘ/NHẠY CẢM]
AFFECTED_SCOPE = [MỘT MODULE/NHIỀU DỊCH VỤ]
REVERSIBILITY = [DỄ/KHÓ]

YÊU CẦU: Merge, migration, secret, policy và production luôn giữ ở CHỈ_CON_NGƯỜI. Không hạ rủi ro vì AI có confidence cao.

ĐỊNH DẠNG ĐẦU RA: Ma trận Use case | Rủi ro | Lý do | Bằng chứng cần | Reviewer | Stop trigger | Mức chấp nhận.

VÍ DỤ ĐIỀN SẴN: Change summary nháp rủi ro thấp; đánh giá kiến trúc cần tech lead; sửa branch protection bị loại.

Thiết kế permission boundary

MỤC TIÊU: Gán quyền tối đa cho từng use case mà không nối quyền đọc với hành động thay đổi repository.

[ĐẦU VÀO]
RISK_MATRIX = [BẢNG ĐÃ DUYỆT]
SYSTEM_ZONES = [REPOSITORY, TÀI LIỆU, HÀNG ĐỢI NHÁP]
IDENTITIES = [AGENT, DEVELOPER, TECH LEAD, ADMIN]
AUDIT_REQUIREMENTS = [TRƯỜNG LOG]

YÊU CẦU: Dùng ĐỌC, TẠO_NHÁP, YÊU_CẦU_REVIEW, CHỈ_CON_NGƯỜI. Agent không có merge, deploy, secret read, delete hay policy write.

ĐỊNH DẠNG ĐẦU RA: Bảng Identity | Zone | Action | Scope | Expiry | Reviewer | Audit | Revoke trigger.

VÍ DỤ ĐIỀN SẴN: Agent đọc MODULE-DEMO-A, ghi change summary vào AI_NHÁP; tech lead duyệt; admin quản lý thu hồi.

Lập bộ đánh giá thí điểm

MỤC TIÊU: Tạo kế hoạch đánh giá một use case đọc hoặc nháp trước khi mở cho đội.

[ĐẦU VÀO]
PILOT_USE_CASE = [MỘT USE CASE]
DATA_CONTRACT = [VERSION]
PERMISSION_BOUNDARY = [BẢNG QUYỀN]
REVIEW_TEAM = [VAI TRÒ]

YÊU CẦU: Có tình huống nguồn cũ, owner trống, prompt injection, secret giả lập và yêu cầu ngoài module. Đo đúng nguồn, phần sửa và vi phạm quyền.

ĐỊNH DẠNG ĐẦU RA: Kế hoạch Tình huống | Kết quả mong đợi | Log | Người xác nhận | Fail-closed | Điều kiện dừng.

VÍ DỤ ĐIỀN SẴN: UC-DEMO-04 chạy 12 tình huống minh họa; Agent chỉ đọc hoặc tạo nháp, vượt contract thì dừng.

Câu hỏi thường gặp

Nên chọn use case đầu tiên thế nào?

Chọn đầu ra đọc hoặc nháp, nguồn rõ, owner sẵn sàng, hậu quả thấp và có cách đối chiếu độc lập.

Agent có cần đọc toàn bộ repository không?

Không. Data contract chỉ cấp module, metadata và tài liệu cần cho use case; quyền theo nguyên tắc tối thiểu.

Permission boundary gồm những gì?

Gồm hệ thống, vùng dữ liệu, hành động, thời hạn, reviewer, log và trigger thu hồi; không chỉ là một token truy cập.

Khi nào use case phải dừng?

Khi nguồn hết hiệu lực, owner trống, Agent vượt phạm vi, xuất hiện secret hoặc đầu ra cần quyết định ngoài quyền.

Bài liên quan

Muốn xây inventory use case, data contract và permission boundary theo repository hiện có? Liên hệ NganAds để thiết kế thí điểm có kiểm duyệt.