AI Coding làm sai yêu cầu? Cách giao Task rõ ràng để AI không sửa đi sửa lại

Có một câu mà những người lập trình với AI rất dễ nói:

"Tôi yêu cầu rõ rồi mà, sao AI vẫn làm sai?"

Ví dụ, chúng ta yêu cầu AI bổ sung chức năng thanh toán cọc cho đơn hàng. Một lúc sau, AI thông báo hoàn thành. Giao diện có nút thanh toán, API đã được viết, database cũng được cập nhật.

Nhìn qua khá ổn.

Nhưng khi kiểm tra kỹ, chúng ta phát hiện khách hàng có thể thanh toán hai lần, đơn hàng được ghi nhận đã thanh toán dù cổng thanh toán chưa xác nhận, còn nhân viên không đủ quyền vẫn có thể sửa số tiền cọc.

AI viết sai?

Có thể. Nhưng trước khi kết luận, chú Nha 27 tuổi muốn nhìn lại yêu cầu ban đầu.

Nếu chúng ta chỉ nói "Hãy làm chức năng thanh toán cọc", AI chưa biết phải xử lý thanh toán trùng thế nào, trạng thái nào được phép thanh toán, ai có quyền chỉnh sửa và điều kiện nào chứng minh giao dịch thành công.

AI có thể tự đưa ra giả định.

Và giả định hợp lý với AI chưa chắc đúng với nghiệp vụ của chúng ta.

Hơn 10 năm làm việc với phần mềm khiến tôi ngày càng chú ý đến một kỹ năng tưởng đơn giản nhưng rất đáng đầu tư: giao việc rõ ràng.

Trong bài Vibe Coding, tôi đã chia sẻ tư duy con người quyết định WHY, WHAT, RULES và AI hỗ trợ triển khai HOW.

Trong bài Context Engineering, chúng ta tìm hiểu cách tổ chức tài liệu để AI đọc đúng thông tin.

Với AGENTS.md, chúng ta xây dựng những quy tắc làm việc ổn định cho AI Coding Agent.

Nhưng đến lúc giao một công việc cụ thể, vẫn còn một câu hỏi:

Làm thế nào để AI biết chính xác việc cần làm, những điều không được thay đổi và khi nào được phép báo hoàn thành?

Đó là lý do cần Task Specification và Acceptance Criteria.

1. Task Specification là gì?

Task Specification là bản mô tả có cấu trúc về một công việc cần thực hiện.

Trong phát triển phần mềm với AI, một Task Specification tốt thường trả lời được:

• Công việc này giải quyết vấn đề gì?
• Kết quả mong muốn là gì?
• Yêu cầu nghiệp vụ nào liên quan?
• AI cần đọc tài liệu và mã nguồn nào?
• Phạm vi được phép thay đổi đến đâu?
• Những phần nào không thuộc nhiệm vụ?
• Có những quy tắc hoặc giới hạn nào?
• Làm thế nào để kiểm chứng kết quả?
• Những hành động nào cần con người phê duyệt?

Task Specification có thể được lưu trong một file Markdown, một GitHub Issue, hệ thống quản lý công việc hoặc công cụ phù hợp với nhóm phát triển.

Không nhất thiết phải sử dụng một định dạng duy nhất.

Điều quan trọng là thông tin phải đủ rõ để người lập trình hoặc AI Coding Agent có thể thực hiện và kiểm chứng nhiệm vụ.

2. Task Specification khác Prompt và AGENTS.md ở điểm nào?

Ba khái niệm này có vai trò khác nhau.

AGENTS.md - Quy tắc chung

Ví dụ:

Không tự ý thay đổi API công khai. Không chỉnh sửa production. Phải kiểm tra phân quyền tại backend. Phải báo cáo những test chưa chạy.

Đây là những nguyên tắc áp dụng cho nhiều task.

Task Specification - Công việc cụ thể

Ví dụ:

Task: PAY-001

Bổ sung API tạo yêu cầu thanh toán cọc cho đơn hàng chưa thanh toán.

Không thay đổi chức năng hoàn tiền. Không thay đổi cơ chế đăng nhập.

Phải kiểm tra trạng thái đơn hàng, số tiền và idempotency.

Đây là phạm vi của một nhiệm vụ.

Prompt - Chỉ dẫn thực hiện tại thời điểm hiện tại

Ví dụ:

Hãy đọc tasks/PAY-001.md và những tài liệu liên quan.

Chưa viết code.

Trước tiên, phân tích yêu cầu, kiểm tra repository và đề xuất kế hoạch triển khai.

Như vậy, AGENTS.md hướng dẫn AI làm việc thế nào. Task Specification mô tả việc phải hoàn thành. Prompt chỉ dẫn AI thực hiện bước nào ngay lúc này.

Chúng bổ sung cho nhau.

3. Acceptance Criteria là gì?

Acceptance Criteria, hay tiêu chí nghiệm thu, là những điều kiện có thể kiểm chứng để xác định một yêu cầu hoặc chức năng đã đáp ứng mong đợi hay chưa.

Ví dụ, yêu cầu:

Hệ thống phải hỗ trợ thanh toán cọc.

Câu này mô tả chức năng nhưng chưa đủ để nghiệm thu.

Chúng ta cần cụ thể hơn:

AC-001: Chỉ đơn hàng đủ điều kiện mới được tạo yêu cầu thanh toán cọc.

AC-002: Số tiền cọc phải tuân thủ business rules đã phê duyệt.

AC-003: Một yêu cầu thanh toán được gửi lại không tạo giao dịch thu tiền trùng.

AC-004: Đơn hàng chỉ được cập nhật trạng thái đã thanh toán khi có xác nhận thành công hợp lệ.

AC-005: Người dùng không đủ quyền không thể chỉnh sửa số tiền cọc.

Đây là những điều kiện có thể được kiểm tra.

Điểm quan trọng là Acceptance Criteria phải mô tả kết quả mong muốn, không chỉ mô tả cách lập trình.

Ví dụ, "Sử dụng một class có tên PaymentService" thường là quyết định triển khai hoặc quy ước kiến trúc.

Trong khi "Không được ghi nhận thanh toán thành công khi cổng thanh toán báo thất bại" là điều kiện về hành vi nghiệp vụ.

Cả hai có thể cần thiết, nhưng không nên nhầm lẫn.

4. Một task tốt cần bốn thành phần tối thiểu

Tài liệu hướng dẫn sử dụng Codex của OpenAI đề xuất một cách giao việc ngắn gọn dựa trên bốn thành phần: Goal, Context, Constraints và Done when.

Tôi thấy đây là khung khá dễ áp dụng, kể cả khi chúng ta không sử dụng Codex.

Goal - Mục tiêu

Task cần tạo ra kết quả gì?

Ví dụ:

Cho phép khách hàng tạo yêu cầu thanh toán cọc cho một đơn hàng đủ điều kiện.

Context - Thông tin liên quan

AI cần đọc những tài liệu hoặc phần mã nguồn nào?

docs/modules/payment/srs.md docs/modules/payment/business-rules.md docs/modules/payment/api-contract.md docs/security/authorization.md

Constraints - Giới hạn

Những điều không được tự ý thay đổi.

Không thay đổi cơ chế đăng nhập. Không sửa chức năng hoàn tiền. Không thực hiện thay đổi production. Không thay đổi API contract nếu chưa được phê duyệt.

Done when - Điều kiện hoàn thành

Kết quả phải được kiểm chứng như thế nào?

Acceptance Criteria được đáp ứng. Unit tests liên quan chạy thành công. Integration tests phù hợp được thực hiện. Không có thay đổi ngoài phạm vi. Báo cáo rõ test chưa thể chạy.

Bốn thành phần này chưa thay thế toàn bộ BRD hoặc SRS. Chúng giúp một nhiệm vụ có điểm bắt đầu, giới hạn và điểm kết thúc rõ ràng.

5. Đừng giao cho AI một task quá lớn

Một câu lệnh như "Xây dựng toàn bộ hệ thống quản lý bán hàng" có thể hữu ích khi muốn tạo prototype nhanh.

Nhưng nếu chúng ta muốn xây dựng một sản phẩm có thể kiểm thử và bảo trì, nên chia phạm vi công việc thành những phần nhỏ hơn.

Ví dụ, thay vì một task duy nhất:

Build complete payment module.

Chúng ta có thể chia thành:

PAY-001: Define payment request contract PAY-002: Implement deposit calculation PAY-003: Create payment request PAY-004: Verify payment callback PAY-005: Update payment status safely PAY-006: Implement reconciliation PAY-007: Add payment audit history PAY-008: Integration and security tests

Đây là một ví dụ phân chia, không phải danh sách cố định cho mọi hệ thống thanh toán.

Mỗi task nên có kết quả có thể kiểm tra độc lập hoặc một phần hành vi đủ rõ để xác nhận.

Nhưng cũng đừng chia quá nhỏ đến mức một thay đổi đơn giản phải đi qua hàng chục nhiệm vụ và nhiều lượt trao đổi.

Tôi thường sử dụng câu hỏi này để đánh giá:

Sau khi task hoàn thành, chúng ta có thể chỉ ra một kết quả cụ thể và chứng minh nó hoạt động đúng không?

Nếu câu trả lời còn mơ hồ, task có thể cần được định nghĩa lại.

6. Ví dụ thực tế: Từ một yêu cầu mơ hồ đến Task Specification rõ ràng

Hãy lấy tình huống xây dựng chức năng thanh toán cọc.

Yêu cầu ban đầu:

Hãy bổ sung chức năng thanh toán cọc cho đơn hàng.

Chúng ta chưa biết:

• Đơn hàng ở trạng thái nào được phép thanh toán?
• Số tiền cọc được tính theo công thức nào?
• Một đơn hàng có được thanh toán cọc nhiều lần không?
• Ai được phép tạo hoặc thay đổi yêu cầu thanh toán?
• Khi cổng thanh toán phản hồi chậm thì xử lý thế nào?
• Nếu callback được gửi nhiều lần thì sao?
• Trường hợp thanh toán thành công nhưng việc cập nhật database thất bại sẽ xử lý thế nào?

Không nên giao AI tự đoán toàn bộ những câu hỏi này.

Thay vào đó, hãy sử dụng AI Research hoặc Business Analyst để rà soát yêu cầu, đề xuất phương án và đưa ra danh sách vấn đề cần người có trách nhiệm phê duyệt.

Chỉ sau khi chốt business rules, chúng ta mới tạo Task Specification để AI Coding Agent triển khai.

7. Mẫu file TASK-PAY-001.md có thể sử dụng ngay

Dưới đây là ví dụ một task có cấu trúc.

Những quy tắc về thanh toán trong ví dụ chỉ để minh họa kỹ thuật. Khi áp dụng vào hệ thống thật, phải thay bằng nghiệp vụ đã được phê duyệt.

# TASK-PAY-001

## Title
Create Deposit Payment Request

## Status
Ready for Implementation

## Objective
Implement an API to create a deposit payment request for eligible orders.

## Business
Context Customers need to make deposit payments without paying the full order amount.

## Approved
Requirements
- PAY-FR-001
- PAY-FR-002

## Business
Rules
- BR-PAY-001
- BR-PAY-002
- BR-PAY-003
- BR-AUTH-004

## Relevant
Documents
- docs/modules/payment/srs.md
- docs/modules/payment/business-rules.md
- docs/modules/payment/api-contract.md
- docs/security/authorization.md

## Expected
Behavior
- Validate the order.
- Validate payment eligibility.
- Determine deposit amount

using approved business rules.
- Create a payment request.
- Return the required response.

## Scope
- Payment request endpoint
- Application service
- Required persistence changes

only after approval
- Automated tests
- Related documentation

## Out of
Scope
- Refund functionality
- Full payment functionality
- Authentication redesign
- Unrelated order management changes
- Production deployment

## Acceptance
Criteria

AC-PAY-001: Eligible orders can create a valid deposit payment request.

AC-PAY-002: Ineligible orders are rejected with an appropriate error.

AC-PAY-003: Deposit amount follows approved business rules.

AC-PAY-004: Repeated requests do not create duplicate payment operations.

AC-PAY-005: Unauthorized users are rejected.

AC-PAY-006: Failures do not leave inconsistent internal payment records.

## Security
Requirements
- Enforce server-side authorization.
- Validate untrusted input.
- Do not expose payment credentials.
- Do not log sensitive payment data.
- Verify integration security controls.

## Constraints
- Preserve approved API contracts.
- Do not modify unrelated modules.
- Do not change business rules.
- Do not access production.
- No destructive database operations.

## Dependencies
- Order module
- Authentication and authorization
- Payment provider integration

## Verification
- Build
- Unit tests
- Integration tests
- Authorization tests
- Duplicate request tests
- Failure handling tests

## Approval
Required For
- Public API changes
- Database schema changes
- Payment provider changes
- Changes to business rules

## Definition of
Done
- Acceptance criteria verified
- Tests executed and reported
- Relevant changes reviewed
- No unauthorized scope expansion
- Documentation updated
- Known risks documented

## Deliverables
- Code changes
- Tests
- Change summary
- Verification report
- Open issues

Nhìn vào file này, AI biết phần việc được giao và những giới hạn phải tuân thủ.

Quan trọng hơn, người kiểm thử cũng có cơ sở để xác nhận kết quả mà không phải suy đoán ý định của người giao việc.

8. Viết Acceptance Criteria theo Given - When - Then

Một cách viết tiêu chí nghiệm thu khá dễ hiểu là Given - When - Then.

Cấu trúc gồm:

• Given: Điều kiện hoặc trạng thái ban đầu.
• When: Hành động xảy ra.
• Then: Kết quả hệ thống phải đáp ứng.

Ví dụ:

Scenario: Create deposit request successfully

Given: The user is authenticated and authorized.

And: The order is eligible for deposit payment.

When: The user submits a valid deposit payment request.

Then: The system creates a valid payment request.

And: The amount follows approved rules.

Một trường hợp khác:

Scenario: Reject unauthorized payment request

Given: A user does not have permission to access the order.

When: The user submits a request using that order ID.

Then: The system rejects the operation.

And: No payment request is created.

Hay trường hợp xử lý trùng:

Scenario: Prevent duplicate payment operations

Given: A payment request has already been accepted for an order.

When: The same logical request is submitted again.

Then: The system must not create an additional charge operation.

And: The resulting state must remain consistent with the approved rules.

Những kịch bản này giúp người phát triển và người kiểm thử trao đổi dễ dàng hơn.

Tuy nhiên, Given - When - Then không tự động bảo đảm tiêu chí nghiệm thu tốt. Nếu điều kiện ban đầu vẫn mơ hồ, chúng ta chỉ đang viết sự mơ hồ theo một định dạng đẹp hơn.

9. Acceptance Criteria phải kiểm chứng được, không chỉ nghe có vẻ đúng

So sánh hai cách viết.

Cách viết chưa tốt

Hệ thống phải nhanh. Giao diện phải đẹp. API phải bảo mật. Không được xảy ra lỗi. Code phải tối ưu.

Những câu này thể hiện mong muốn, nhưng rất khó xác nhận khi nào đã đạt.

Cách viết tốt hơn

API trả mã phản hồi phù hợp khi dữ liệu đầu vào không hợp lệ.

Người dùng không đủ quyền không thể truy cập đơn hàng không thuộc phạm vi của mình.

Không tạo giao dịch trùng khi cùng một yêu cầu thanh toán được gửi lại.

Các bài test được chỉ định phải chạy và có kết quả thực tế.

Hiệu năng phải đạt ngưỡng được quy định trong NFR dưới điều kiện tải đã thống nhất.

Đối với hiệu năng, những giá trị như thời gian phản hồi, tải đồng thời và tỷ lệ lỗi phải được xác định từ yêu cầu thực tế.

Không nên tự đặt ra những con số chỉ vì chúng thường xuất hiện trong tài liệu kỹ thuật.

Một tiêu chí nghiệm thu tốt cần có điều kiện kiểm tra, kết quả mong đợi và cách xác định đạt hay không đạt.

10. Cần phân biệt Acceptance Criteria và Definition of Done

Hai khái niệm này liên quan nhưng khác nhau.

Acceptance Criteria thường gắn với yêu cầu hoặc chức năng cụ thể.

Ví dụ: Không cho phép tạo yêu cầu thanh toán trùng.

Definition of Done thường mô tả điều kiện chung để công việc được xem là hoàn thành theo quy trình của nhóm.

Ví dụ:

• Mã nguồn đã được review.
• Các bài kiểm thử bắt buộc đã chạy.
• Không còn lỗi chặn nghiệm thu.
• Tài liệu liên quan được cập nhật.
• Những thay đổi ngoài phạm vi được xử lý.
• Các rủi ro còn lại được ghi nhận.

Một chức năng có thể đáp ứng Acceptance Criteria nhưng chưa đạt Definition of Done vì chưa được review hoặc chưa chạy đủ kiểm thử bắt buộc.

Ngược lại, code có thể build thành công và qua lint nhưng vẫn không đáp ứng nghiệp vụ.

Đừng đánh đồng hai việc.

11. Quy trình giao Task cho AI Coding Agent qua bốn bước

Tôi đề xuất một quy trình gồm bốn bước để kiểm soát những thay đổi quan trọng.

Bước 1 - AI đọc và phân tích

AI phải đọc Task Specification, project instructions, tài liệu liên quan và mã nguồn hiện tại.

Ở bước này chưa yêu cầu viết code.

Bạn là AI Coding Agent.

Hãy đọc:
- AGENTS.md
- tasks/TASK-PAY-001.md
- Các tài liệu được task tham chiếu
- Mã nguồn hiện tại có liên quan

Chưa chỉnh sửa file.

Hãy trả về:
1. Mục tiêu của task
2. Business rules cần tuân thủ
3. Các file và module liên quan
4. Những yêu cầu chưa rõ
5. Dependency
6. Rủi ro
7. Kế hoạch triển khai dự kiến
8. Kế hoạch kiểm thử

Không tự bổ sung nghiệp vụ chưa được phê duyệt.

Bước 2 - Người phụ trách duyệt kế hoạch

Chúng ta kiểm tra xem AI có hiểu đúng phạm vi và có đề xuất thay đổi không cần thiết hay không.

Với task nhỏ, ít rủi ro, có thể quy định cơ chế thực hiện nhanh hơn. Không nhất thiết mọi chỉnh sửa đều cần một vòng phê duyệt thủ công.

Nhưng khi liên quan đến dữ liệu, tiền, phân quyền hoặc thay đổi kiến trúc, nên có điểm kiểm soát rõ ràng.

Bước 3 - AI triển khai

Sau khi kế hoạch được chấp thuận theo quy trình, giao AI thực hiện.

Triển khai TASK-PAY-001 theo implementation plan đã duyệt.

Yêu cầu:
- Không thay đổi business rules.
- Không mở rộng scope.
- Không sửa module không liên quan.
- Viết kiểm thử cho hành vi mới.
- Kiểm tra những trường hợp lỗi.
- Không thao tác với production.

Nếu phát hiện xung đột tài liệu, dừng phần bị ảnh hưởng và báo lại để xác nhận.

Bước 4 - AI báo cáo và con người nghiệm thu

Khi hoàn thành, không nên chỉ nhận một câu "Done".

Yêu cầu báo cáo có bằng chứng.

Hãy báo cáo TASK-PAY-001:
1. Files changed
2. Requirements implemented
3. Acceptance criteria status
4. Tests executed
5. Actual test results
6. Security considerations
7. Out-of-scope changes
8. Known limitations
9. Pending approvals

Phân loại mỗi acceptance criterion:
- PASS
- FAIL
- NOT VERIFIED
- NOT APPLICABLE

Chỉ đánh dấu PASS khi có bằng chứng phù hợp.

Nếu test chưa chạy, ghi rõ lý do.

Đây là cách tạo một vòng kiểm soát từ yêu cầu đến kết quả.

12. Ma trận truy vết: Từ yêu cầu đến code và test

Với dự án nhiều module, tôi đề xuất sử dụng Requirement Traceability Matrix, gọi ngắn là ma trận truy vết yêu cầu.

Ví dụ:

Requirement: PAY-FR-001

Business Rules: BR-PAY-001 BR-PAY-002

Task: TASK-PAY-001

Acceptance Criteria: AC-PAY-001 AC-PAY-002 AC-PAY-003

Implementation: PaymentController PaymentService

Tests: PaymentRequestTests PaymentAuthorizationTests

Status: Pending Verification

Ma trận này giúp chúng ta trả lời:

• Yêu cầu nào đã được triển khai?
• Yêu cầu nào chưa có test?
• Một task đang ảnh hưởng đến business rules nào?
• Một thay đổi trong nghiệp vụ sẽ ảnh hưởng đến module nào?
• Có tiêu chí nghiệm thu nào bị bỏ sót không?

Với dự án nhỏ, có thể đưa thông tin này vào file task.

Với dự án lớn, nên quản lý có cấu trúc hơn trong issue tracker, tài liệu hoặc hệ thống quản lý yêu cầu.

13. Khi AI phát hiện yêu cầu mâu thuẫn thì phải làm gì?

Đây là một tình huống cần được xử lý đúng.

Giả sử SRS quy định rằng số tiền cọc không được thay đổi sau khi tạo yêu cầu thanh toán.

Nhưng một task mới lại yêu cầu bổ sung chức năng cho phép nhân viên sửa số tiền cọc bất cứ lúc nào.

AI có thể tìm cách thực hiện yêu cầu mới.

Tuy nhiên, nếu làm như vậy mà không xác nhận, AI có thể phá vỡ quy tắc đã được phê duyệt.

Trong trường hợp này, agent nên báo:

Requirement Conflict Detected

Existing Rule: BR-PAY-003

Current Task: TASK-PAY-009

Conflict: Task requests modification of payment amount after creation.

Approved rule prohibits this under specified conditions.

Action: Implementation paused for the affected behavior.

Required: Human decision and documentation update before implementation.

Nếu quy tắc cũ thực sự cần thay đổi, con người phê duyệt yêu cầu mới, cập nhật tài liệu và xác định những phần hệ thống bị ảnh hưởng.

Chúng ta không nên để AI tự sửa SRS chỉ để mã nguồn phù hợp với task mới.

14. Khi nào nên dừng một task và giao lại?

Không phải cứ AI gặp khó khăn là phải tiếp tục yêu cầu "Sửa tiếp".

Có những lúc cần dừng lại để đánh giá.

Ví dụ:

• Yêu cầu quan trọng chưa có người xác nhận.
• Business rules mâu thuẫn nhau.
• Task vượt khỏi phạm vi đã duyệt.
• Muốn hoàn thành task phải thay đổi API công khai hoặc cấu trúc dữ liệu ngoài kế hoạch.
• Không có quyền truy cập hoặc môi trường cần thiết để kiểm chứng.
• Kiểm thử phát hiện lỗi ảnh hưởng đến dữ liệu hoặc bảo mật.
• AI liên tục sửa cùng một lỗi nhưng chưa xác định nguyên nhân.

Khi đó, có thể tạo một task nghiên cứu riêng để xác định nguyên nhân hoặc yêu cầu còn thiếu.

Đừng biến một task nhỏ thành một cuộc sửa chữa không có điểm dừng.

15. Đo xem cách giao Task có thực sự hiệu quả hơn không

Một điều tôi muốn nhấn mạnh là không nên chỉ dựa vào cảm giác.

Nếu áp dụng Task Specification có cấu trúc, hãy theo dõi kết quả.

Chẳng hạn:

• Số lượt phải giải thích lại yêu cầu.
• Số vòng sửa code.
• Số file thay đổi ngoài phạm vi.
• Tỷ lệ Acceptance Criteria đạt.
• Số lỗi phát hiện trong review.
• Số lỗi phát hiện sau triển khai.
• Tổng token và chi phí AI cho mỗi task.
• Thời gian từ khi giao task đến khi nghiệm thu.

Chúng ta có thể thử trên những nhiệm vụ tương đương, với cùng mô hình, công cụ và điều kiện kiểm thử.

Một nhóm sử dụng prompt ngắn thông thường. Nhóm còn lại sử dụng Task Specification, tài liệu liên quan, giới hạn phạm vi và tiêu chí nghiệm thu rõ ràng.

Đừng vội kết luận chỉ từ một vài task.

Điều cần tìm hiểu là phương pháp nào giúp nhóm hoàn thành công việc đúng hơn, ít phải sửa lại hơn và có tổng chi phí hợp lý hơn.

16. Checklist 15 mục trước khi giao Task cho AI Coding

1. Task có mục tiêu cụ thể chưa?
2. Đã xác định vấn đề cần giải quyết chưa?
3. Đã có yêu cầu nghiệp vụ được phê duyệt chưa?
4. Đã tham chiếu những business rules liên quan chưa?
5. Đã xác định rõ Scope chưa?
6. Đã ghi Out of Scope chưa?
7. Đã xác định những tài liệu AI phải đọc chưa?
8. Đã kiểm tra dependency chưa?
9. Đã có Acceptance Criteria kiểm chứng được chưa?
10. Đã mô tả trường hợp ngoại lệ quan trọng chưa?
11. Đã có yêu cầu bảo mật và phân quyền chưa?
12. Đã xác định hành động cần phê duyệt chưa?
13. Đã có kế hoạch kiểm thử chưa?
14. Đã có Definition of Done chưa?
15. Đã xác định hình thức báo cáo kết quả chưa?

Không phải task nhỏ nào cũng cần một tài liệu dài. Nhưng những câu hỏi trên giúp chúng ta xác định thông tin nào đang thiếu trước khi AI bắt đầu làm việc.

17. Checklist 15 mục sau khi AI hoàn thành Task

1. Đã đối chiếu kết quả với mục tiêu task chưa?
2. Đã kiểm tra toàn bộ Acceptance Criteria chưa?
3. Đã xác minh business rules được tuân thủ chưa?
4. Đã review những file thay đổi chưa?
5. Có thay đổi ngoài phạm vi không?
6. Đã kiểm tra authentication và authorization chưa?
7. Đã kiểm tra dữ liệu đầu vào không hợp lệ chưa?
8. Đã kiểm tra những tình huống biên chưa?
9. Đã chạy unit tests phù hợp chưa?
10. Đã chạy integration tests nếu cần chưa?
11. Đã kiểm tra regression chưa?
12. Có ảnh hưởng database hoặc API contract không?
13. Đã lưu bằng chứng kiểm thử chưa?
14. Đã ghi nhận những giới hạn và rủi ro còn lại chưa?
15. Đã có người chịu trách nhiệm nghiệm thu chưa?

Nếu nhiệm vụ liên quan đến thanh toán, dữ liệu cá nhân hoặc hệ thống production, cần bổ sung những bước kiểm tra chuyên sâu tương ứng.

Tôi đã chia sẻ bộ 150 checklist trước và sau Vibe Coding, trước khi Go-live website dưới dạng Google Sheets miễn phí. Bạn có thể sử dụng bộ đó cho giai đoạn nghiệm thu tổng thể.

Tạo bản sao miễn phí bộ 150 checklist Vibe Coding và Website Go-live

18. Những sai lầm thường gặp khi giao việc cho AI

Chỉ mô tả chức năng, không có business rules

AI có thể triển khai một chức năng hợp lý nhưng sai quy tắc thực tế.

Không xác định phạm vi được sửa

Một task nhỏ có thể kéo theo thay đổi ở nhiều module không liên quan.

Acceptance Criteria quá chung chung

Những câu như "Hoạt động tốt" hoặc "Bảo mật cao" không đủ làm tiêu chí nghiệm thu.

Không kiểm tra hệ thống hiện tại

AI có thể tạo lại một chức năng đã tồn tại hoặc không nhận ra dependency quan trọng.

Nhầm báo cáo của AI với bằng chứng

AI nói đã chạy test không thay thế log kiểm thử hoặc kết quả xác minh thực tế.

Cho phép AI sửa tài liệu yêu cầu để phù hợp với code

Tài liệu nghiệp vụ cần được cập nhật theo quyết định có thẩm quyền, không phải theo cách triển khai thuận tiện nhất.

Không có điều kiện dừng

Khi gặp một vấn đề chưa rõ, AI tiếp tục thử nhiều cách và có thể làm thay đổi hệ thống ngoài kế hoạch.

Chia task quá vụn

Mỗi bước nhỏ đều tạo thêm chi phí quản lý và mất context. Nên chia theo những kết quả có thể thực hiện và kiểm chứng hợp lý.

19. Từ Task Specification đến một quy trình AI Coding có kiểm soát

Đến đây, chúng ta có thể kết nối những nội dung đã chia sẻ trong series này.

Vibe Coding giúp chúng ta tận dụng AI để phát triển phần mềm nhanh hơn.

Context Engineering giúp tổ chức đúng thông tin AI cần đọc.

AGENTS.md hướng dẫn AI làm việc theo những nguyên tắc nhất quán.

Task Specification xác định công việc cụ thể, phạm vi và yêu cầu cần thực hiện.

Acceptance Criteria cho biết kết quả nào được xem là đạt.

Testing và Review cung cấp bằng chứng để kiểm tra.

Những phần này tạo thành một quy trình liên kết với nhau:

HUMAN + AI RESEARCH
        | v APPROVED BRD / SRS
        | v BUSINESS RULES
        | v TASK SPECIFICATION
        | v AI IMPLEMENTATION PLAN
        | v HUMAN APPROVAL IF REQUIRED
        | v AI CODING AGENT
        | v TEST + CODE REVIEW
        | v ACCEPTANCE CRITERIA
        | v HUMAN ACCEPTANCE
        | v RELEASE PROCESS

Không phải nhiệm vụ nào cũng phải đi qua đầy đủ những bước với cùng mức độ kiểm soát.

Một thay đổi giao diện đơn giản có thể cần ít thủ tục hơn một chức năng xử lý thanh toán.

Điều quan trọng là mức độ kiểm soát phải tương xứng với mức độ rủi ro.

20. Kết luận: Giao việc tốt cũng là một kỹ năng lập trình

Có một điều khá thú vị khi sử dụng AI Coding.

Trước đây, chúng ta thường tập trung vào việc viết code sao cho đúng. Bây giờ, một phần thời gian được chuyển sang việc mô tả yêu cầu, tổ chức context, kiểm tra kế hoạch và nghiệm thu kết quả.

Điều đó không làm kỹ năng lập trình trở nên kém quan trọng.

Ngược lại, càng hiểu về phần mềm, chúng ta càng biết phải yêu cầu AI điều gì, cần cẩn thận ở đâu và cách kiểm chứng như thế nào.

Với chú Nha 27 tuổi, một Task Specification tốt không cần quá dài. Nó chỉ cần đủ rõ để người thực hiện biết mình đang giải quyết vấn đề gì, được phép thay đổi những gì và phải chứng minh kết quả ra sao.

AI có thể viết code nhanh.

Nhưng nếu yêu cầu ban đầu thiếu rõ ràng, tốc độ ấy cũng có thể khiến chúng ta tạo ra sai sót nhanh hơn.

Vì vậy, trước khi gửi một yêu cầu lập trình, hãy dành thêm một chút thời gian viết Task Specification và Acceptance Criteria.

Đôi khi, năm phút làm rõ một quy tắc nghiệp vụ còn đáng giá hơn nhiều lượt yêu cầu AI sửa lại code.

Và nếu lần tới AI hoàn thành đúng việc, không tự ý sửa thêm module khác, có test rõ ràng và báo cáo đầy đủ, biết đâu chú Nha sẽ không còn phải hỏi câu quen thuộc:

"Ủa, ai nhờ em sửa luôn phần này vậy?"

Nguồn tham khảo

• OpenAI - Codex Best Practices
• OpenAI - Using Goals in Codex
• GitHub - Best Practices for Using Copilot to Work on Tasks
• Anthropic - Claude Code Best Practices
• NIST - Secure Software Development Framework
• OWASP - Application Security Verification Standard