Hướng dẫn dùng Claude Code để phát triển một tính năng từ đầu đến cuối
Mình là Tony, hiện đang làm và vận hành các sản phẩm web, sử dụng Claude Code làm công cụ phát triển chính hằng ngày. Bài viết này thuộc series Claude Code cho dự án thực tế, tập trung vào những vấn đề developer gặp khi đưa coding agent vào quy trình phát triển phần mềm. Nếu bạn đã biết lập trình, quen với Git và terminal nhưng chưa có quy trình ổn định khi giao task cho agent, bài này dành cho bạn.
Mình sẽ đi qua một yêu cầu phát triển tính năng trên ứng dụng SaaS, từ lúc đọc yêu cầu, khảo sát codebase, lập kế hoạch, triển khai đến kiểm tra và bàn giao. Repository và tình huống nghiệp vụ trong bài đều là giả định, nhưng các ràng buộc được xây dựng theo cách một team phát triển sản phẩm thực tế phải xử lý. Cuối bài, bạn sẽ có mẫu task-brief.md, các prompt có thể điều chỉnh để dùng trong Claude Code và checklist review diff trước khi merge.
1. Một task phát triển phần mềm thực sự gồm những gì?
Khi giao task cho Claude Code, developer thường mô tả tính năng rồi yêu cầu agent triển khai ngay. Cách này có thể phù hợp với thay đổi nhỏ, nhưng trên dự án có sẵn, một yêu cầu nghiệp vụ thường liên quan đến nhiều thành phần. Agent có thể tạo được code chạy mà chưa hiểu đầy đủ những ràng buộc của hệ thống.
Xét một ứng dụng SaaS B2B đã có authentication, subscription và phân quyền theo tổ chức. Team muốn bổ sung chức năng export báo cáo, chỉ cho người có quyền quản trị sử dụng, hỗ trợ dữ liệu lớn và không ảnh hưởng đến quyền của các vai trò khác. Nếu chỉ yêu cầu Claude thêm nút Export và API trả về CSV, agent có thể bỏ qua những vấn đề như tenant isolation hoặc cách hệ thống xử lý truy vấn lớn.
Trước khi viết code, developer cần biết hệ thống đang kiểm tra quyền ở đâu, dữ liệu thuộc tổ chức nào và subscription có liên quan đến tính năng mới hay không. Những câu trả lời này quyết định cách triển khai, chứ không phải chi tiết có thể bổ sung sau. Mình chia một task thành năm giai đoạn để kiểm soát các quyết định đó:
- Explore: Khảo sát repository, tìm luồng xử lý hiện tại và các ràng buộc liên quan.
- Plan: Xác định phạm vi, phương án triển khai và tiêu chí hoàn thành.
- Implement: Chỉnh sửa code theo kế hoạch, xử lý từng phần có thể kiểm tra.
- Verify: Chạy test và xác minh hành vi thực tế.
- Review: Kiểm tra diff, đối chiếu kết quả với yêu cầu và chuẩn bị bàn giao.
Đây không phải năm phiên Claude bắt buộc phải tách riêng. Với thay đổi nhỏ, các giai đoạn có thể diễn ra nhanh trong cùng một phiên. Với tính năng liên quan đến phân quyền và dữ liệu khách hàng, mình dành nhiều thời gian hơn cho Explore và Plan vì sửa một giả định sai trước khi code vẫn đơn giản hơn sửa cả implementation.
2. Khảo sát repository trước khi yêu cầu thay đổi
Giả sử team sử dụng monorepo TypeScript với cấu trúc sau:
.
├── apps/
│ ├── admin/ # Ứng dụng quản trị
│ └── api/ # API nhiều tenant
├── packages/
│ ├── ui/ # UI components dùng chung
│ └── shared/ # Types và utilities
├── pnpm-workspace.yaml
└── package.json
Ứng dụng quản trị nằm trong apps/admin, còn apps/api phục vụ nhiều tổ chức khách hàng. Với yêu cầu export báo cáo, agent cần tìm hiểu frontend, authorization, truy vấn dữ liệu và cách hệ thống phân biệt tenant. Các package dùng chung cũng có thể chịu ảnh hưởng nếu tính năng cần thêm component hoặc type.
Mình không yêu cầu Claude đọc toàn bộ repository rồi tự quyết định cách triển khai. Thay vào đó, mình chỉ rõ luồng nghiệp vụ cần tìm và yêu cầu agent dẫn ra những vị trí code liên quan.
We need to add report export for organization admins.
Do not modify code yet.
Explore the repository and identify:
1. How apps/admin requests report data.
2. Where apps/api checks authentication and
organization-level authorization.
3. How database queries are scoped to a tenant.
4. How subscription entitlements are enforced,
if relevant to report features.
5. Existing patterns for large data processing.
6. Existing tests covering reports and permissions.
For each finding, provide relevant file paths
and explain the current behavior.
Separate confirmed findings from assumptions.
Do not propose implementation yet.
Khi Claude báo hệ thống đã có middleware kiểm tra quyền, mình muốn biết middleware nằm ở đâu và được gọi trong luồng nào. Nếu agent cho rằng mọi truy vấn đều được lọc theo tenant, mình cần thấy code thực hiện điều đó. Những nhận định chưa có bằng chứng được giữ dưới dạng giả định để khảo sát tiếp.
Với repository lớn, Claude Code có thể giao một phần khảo sát cho subagent. Subagent đọc file trong context riêng rồi trả về bản tóm tắt, giúp phiên chính không phải giữ toàn bộ nội dung đã đọc. Chẳng hạn, mình có thể tách phần authorization như sau:
Use a subagent to investigate how authorization
and tenant isolation work in apps/api.
Return:
- Relevant file paths
- Permission checks used by report endpoints
- How organization context reaches data queries
- Existing tests
- Risks or unanswered questions
Do not change any files.
Mình cũng giữ đúng ngôn ngữ nghiệp vụ của repository khi trao đổi với agent. Nếu hệ thống gọi quyền quản trị là organization_admin, mình không mặc định nó tương đương admin; organization, workspace, account và tenant cũng có thể mang nghĩa khác nhau. Sau khảo sát, agent phải chỉ ra được luồng hiện tại, vùng code cần thay đổi và những câu hỏi chưa có đủ bằng chứng.
Nếu muốn Claude hiểu các conventions của repository qua nhiều phiên, bạn có thể đọc bài Hướng dẫn viết CLAUDE.md để Claude Code hiểu đúng dự án của bạn. Trong workflow này, CLAUDE.md cung cấp context ổn định, còn Explore tập trung vào những chi tiết riêng của task đang làm. Hai phần bổ sung cho nhau nhưng không thay thế nhau.
3. Chuyển yêu cầu thành kế hoạch có thể kiểm tra
Sau khi khảo sát, mình tách riêng giai đoạn lập kế hoạch vì nhiều quyết định nghiệp vụ chưa nằm trong yêu cầu ban đầu. Coding agent có thể đề xuất giải pháp rất nhanh, nhưng nếu developer chưa xác nhận các giả định, chúng dễ trở thành hành vi thực tế của phần mềm. Kế hoạch cần làm rõ phạm vi thay đổi, phương án triển khai, rủi ro và tiêu chí kiểm tra.
Claude Code hỗ trợ Plan mode để đọc code và đề xuất kế hoạch trước khi chỉnh sửa. Bạn có thể khởi động bằng lệnh:
claude --permission-mode plan
Hoặc bấm Shift+Tab trong phiên để chuyển sang Plan mode. Khi thanh trạng thái hiển thị ⏸ plan mode on, Claude có thể khảo sát và chuẩn bị kế hoạch nhưng chưa sửa code cho tới khi bạn duyệt. Mình dùng chế độ này để tách bước tìm hiểu khỏi bước thay đổi repository.
Với tính năng export, yêu cầu ban đầu vẫn chưa nói rõ dữ liệu lớn là bao nhiêu, ứng dụng tải trực tiếp hay tạo export bất đồng bộ và quyền quản trị được kiểm tra tại thời điểm nào. Những quyết định đó ảnh hưởng đến kiến trúc và cách kiểm thử. Mình yêu cầu Claude trình bày riêng những gì đã xác nhận và những gì cần team quyết định.
Based on the repository exploration, create
an implementation plan for report export.
Requirements:
- Only authorized organization admins can export.
- Exports must contain data from the current
organization only.
- Large exports must not require loading all
records into application memory.
- Existing role permissions must remain unchanged.
Structure the plan into:
1. Confirmed repository behavior
2. Proposed scope
3. Assumptions requiring a decision
4. Implementation steps and affected areas
5. Security and performance risks
6. Acceptance criteria
7. Verification strategy
Do not modify code.
Claude có thể đề xuất streaming hoặc background job tùy kiến trúc hiện tại và yêu cầu về kích thước dữ liệu. Nếu repository đã có cơ chế background processing phù hợp, tái sử dụng nó có thể hợp lý hơn xây mới. Nhưng một kế hoạch chỉ ghi “implement export endpoint, add UI button, write tests” vẫn chưa đủ, vì chưa mô tả cách kiểm tra authorization, tenant isolation và xử lý dữ liệu lớn.
Để tiếp tục tình huống giả định, team chốt các quyết định sau:
- Chỉ vai trò
organization_adminđược export, với điều kiện đã có quyền đọc báo cáo tương ứng. - API xác định organization từ authentication context, không tin organization ID do client tự cung cấp.
- Endpoint kiểm tra quyền trước khi bắt đầu export.
- Export CSV xử lý dữ liệu theo từng phần, không nạp toàn bộ kết quả vào memory.
- Phiên bản này chưa bổ sung lịch sử export, email thông báo hoặc background job.
- Không sửa role definitions hoặc thay đổi quyền của vai trò khác.
Đây là các quyết định dành riêng cho ví dụ, không phải thiết kế mặc định của mọi SaaS. Nếu sản phẩm cần xử lý export kéo dài và cho người dùng quay lại tải sau, team có thể phải chọn kiến trúc bất đồng bộ. Trong phạm vi đã chốt, agent có thể triển khai streaming mà không phải tự mở rộng thêm hệ thống job.
4. Chỉ cho agent triển khai sau khi thống nhất phạm vi
Khi kế hoạch được duyệt, mình chuyển Claude sang triển khai với ranh giới rõ ràng. Agent có thể tự giải quyết những chi tiết kỹ thuật theo conventions hiện tại, chẳng hạn đặt tên helper hoặc bổ sung test cho nhánh lỗi. Nhưng nếu cần dependency mới, database migration hoặc thay đổi quy tắc phân quyền chung, mình muốn Claude dừng lại để giải thích trước khi sửa.
Implement the approved report export plan.
Work in small, verifiable steps.
For each step:
- Follow existing repository conventions.
- Keep changes within the agreed scope.
- Add or update relevant tests.
- Run focused tests after the change.
- Report failures before continuing.
Do not introduce new dependencies, migrations,
or changes to shared permission rules without
asking for approval.
If the implementation conflicts with a confirmed
constraint, stop and explain the conflict.
Với tính năng export, mình ưu tiên triển khai API và cơ chế bảo vệ dữ liệu trước khi hoàn thiện giao diện. Nút Export chỉ hiển thị cho admin chưa chứng minh người dùng khác không thể gọi API trực tiếp. Agent có thể làm endpoint và test authorization trước, tiếp tục với truy vấn export, rồi mới kết nối frontend.
Cách chia nhỏ giúp phát hiện lỗi gần với thay đổi gây ra lỗi. Nếu test authorization thất bại, agent xử lý ngay ở phần API thay vì tiếp tục xây giao diện trên một endpoint chưa được xác minh. Khi thấy Claude sửa nhầm vùng code hoặc đi theo giải pháp ngoài kế hoạch, mình nhấn Escape để dừng sớm và chỉ rõ hướng cần điều chỉnh.
Claude Code cũng hỗ trợ Git worktree nếu cần cô lập task khỏi checkout đang sử dụng:
claude --worktree feature-report-export
Lệnh này tạo checkout riêng trên nhánh riêng, với điều kiện repository đã có ít nhất một commit. Worktree phù hợp khi bạn muốn phát triển tính năng mà không ảnh hưởng đến những thay đổi đang thực hiện ở checkout khác. Nó giúp cô lập môi trường làm việc, còn chất lượng implementation vẫn phải được kiểm tra.
Mình áp dụng nguyên tắc tương tự khi agent đề xuất refactor. Nếu cần thay đổi cấu trúc report service, mình yêu cầu chia thành các bước nhỏ và chạy test sau từng bước. Một đề xuất viết lại toàn bộ service phải có lý do cụ thể, thay vì xuất hiện như phần mở rộng tự phát của task export.
5. Kiểm tra kết quả bằng test và hành vi thực tế
Sau khi Claude hoàn tất code, mình phân biệt ba trạng thái: code hợp lệ, test pass và yêu cầu nghiệp vụ được đáp ứng. TypeScript có thể phát hiện lỗi kiểu dữ liệu nhưng không chứng minh report export lọc đúng organization. Unit test có thể pass trong khi API thực tế vẫn truyền sai authentication context cho hàm xử lý.
Mình chuyển từng yêu cầu nghiệp vụ thành acceptance criteria và xác định bằng chứng tương ứng. Với hệ thống nhiều tenant, bộ test cần kiểm tra cả người dùng hợp lệ lẫn những request không được phép. Nếu chỉ test luồng thành công bằng một tài khoản admin, một lỗi rò rỉ dữ liệu giữa hai organization có thể không xuất hiện.
Ví dụ, bảng kiểm tra có thể được viết như sau:
| Acceptance criteria | Bằng chứng cần có |
|---|---|
| Organization admin được export | API test với role hợp lệ |
| Member không được export | API test trả về lỗi quyền |
| Tenant A không thấy dữ liệu Tenant B | Integration test với dữ liệu hai tenant |
| Export xử lý dữ liệu lớn | Test luồng đọc dữ liệu theo từng phần |
| CSV có cấu trúc đúng | Test header, escaping và giá trị |
| Không đổi quyền hiện tại | Regression tests cho các role liên quan |
Bảng này liên kết yêu cầu với test thay vì chỉ đếm số test pass. Chẳng hạn, test tenant isolation phải có dữ liệu từ ít nhất hai tenant độc lập và chứng minh API không trả dữ liệu của tenant khác. Test CSV cần kiểm tra nội dung thực tế, không dừng ở response status thành công.
Mình yêu cầu Claude chạy test theo framework và conventions có sẵn trong repository, sau đó báo rõ từng kết quả.
Verify the report export implementation.
Use the existing test framework and conventions.
Run the relevant API tests and report:
- Exact commands executed
- Passing and failing tests
- Any tests skipped or not executed
- Acceptance criteria covered by each test
- Remaining gaps in verification
Also inspect the implementation for:
- Missing authorization checks
- Cross-tenant data exposure
- Empty reports
- Large exports
- Invalid input
- Client disconnection or export failure
Do not claim a criterion is verified unless
you have corresponding test evidence.
Với monorepo ví dụ, lệnh chạy test API là:
pnpm -F api test
Nếu test thất bại, mình giữ lại lệnh tái hiện, stack trace và các bước gây lỗi để agent phân tích. Khi lỗi xuất hiện không ổn định, mình bổ sung thông tin về tần suất và điều kiện xảy ra. Những dữ kiện đó hữu ích hơn một yêu cầu chung như “fix the failing test”.
Mình cũng yêu cầu Claude tìm thêm edge cases dựa trên hành vi đang kiểm tra. Với CSV, dữ liệu có thể chứa dấu phẩy, dấu ngoặc kép, xuống dòng, Unicode hoặc giá trị null; báo cáo cũng có thể không có bản ghi. Agent cần kiểm tra code xử lý từng trường hợp ra sao và bổ sung test theo style hiện tại.
Với dữ liệu lớn, test vài chục bản ghi không đủ chứng minh export sẽ hoạt động tốt khi khối lượng tăng. Mình kiểm tra cách code đọc dữ liệu theo từng phần, xử lý bộ nhớ và phản ứng khi export bị gián đoạn. Nếu chưa đo memory hoặc chưa chạy load test, bản bàn giao phải ghi rõ phần chưa xác minh.
Ngoài API, tính năng còn cần được kiểm tra trên browser, gồm trạng thái nút Export, loading, thông báo lỗi và hành vi tải file theo từng role. Mình sẽ đi sâu vào phần này trong bài về browser verification bằng Playwright của series. Ở task hiện tại, những kiểm tra chưa thực hiện sẽ được ghi nhận riêng, thay vì gộp vào kết luận test pass.
6. Review diff trước khi chấp nhận kết quả
Khi agent hoàn tất code và test, mình review diff để kiểm tra cả phạm vi thay đổi lẫn logic triển khai. Test pass không bảo đảm Claude chỉ sửa những phần cần thiết. Nếu task export báo cáo nhưng diff có thay đổi trong subscription billing hoặc shared authentication, mình cần thấy lý do và tác động trước khi chấp nhận.
Checklist review trước khi merge:
- [ ] Mỗi file thay đổi đều phục vụ phạm vi đã duyệt.
- [ ] API kiểm tra authorization ở phía server.
- [ ] Mọi truy vấn export đều giữ đúng tenant scope.
- [ ] Không có thay đổi ngoài ý muốn với role definitions.
- [ ] Không đưa dữ liệu nhạy cảm vào log hoặc thông báo lỗi.
- [ ] Dependency mới, nếu có, đã được giải thích và duyệt.
- [ ] Migration, nếu có, đã được đánh giá về tác động.
- [ ] Code xử lý các trường hợp rỗng, lỗi và dữ liệu lớn theo yêu cầu.
- [ ] Test mới kiểm tra cả luồng thành công và truy cập không hợp lệ.
- [ ] Test hiện tại vẫn pass, hoặc lỗi còn lại được ghi rõ.
- [ ] Giao diện được kiểm tra theo quyền và hành vi thực tế.
- [ ] Không còn thay đổi thử nghiệm hoặc code không sử dụng.
Mình thường nhờ Claude review lại diff trong vai trò reviewer, tập trung tìm rủi ro thay vì giải thích vì sao implementation đã đúng. Prompt yêu cầu agent chỉ ra vùng code cụ thể và phân biệt lỗi đã xác nhận với rủi ro tiềm ẩn. Ở bước này, mình chưa cho agent sửa để có thể đánh giá các phát hiện trước.
Review the current diff against the approved plan.
Do not modify files.
Identify:
1. Changes outside the approved scope
2. Authorization or tenant isolation risks
3. Unnecessary dependencies or abstractions
4. Missing tests and edge cases
5. Potential regressions
6. Migrations or operational impacts
7. Acceptance criteria without evidence
For each finding:
- Point to the relevant file or code area.
- Explain the concrete risk.
- Suggest the smallest reasonable correction.
Distinguish confirmed issues from potential risks.
Khi Claude phát hiện vấn đề, mình xác nhận bằng chứng rồi mới yêu cầu sửa từng phần và chạy lại test liên quan. Đặc biệt, mình đọc cả diff của test vì agent có thể vô tình làm test mất giá trị khi sửa lỗi. Chẳng hạn, nếu test tenant isolation thất bại nhưng agent đổi assertion thành chỉ kiểm tra response không rỗng, test sẽ pass dù yêu cầu bảo mật chưa được đáp ứng.
Sau review, Claude Code có thể hỗ trợ tạo pull request nếu team sử dụng GitHub. Mình yêu cầu PR mô tả thay đổi, quyết định kỹ thuật, test đã chạy và những giới hạn còn lại. Phần mô tả phải dựa trên kết quả thực tế, không mặc định mọi acceptance criteria đã được xác minh.
Create a PR for my changes.
Include:
- What changed
- Why the implementation was chosen
- Tests executed and results
- Security considerations
- Known limitations
- Remaining verification work
Claude cũng có thể tạo PR qua gh pr create trong workflow phù hợp. Khi tạo theo cách này, phiên Claude được gắn với PR và có thể mở lại bằng claude --from-pr <number>. Mình vẫn review nội dung PR trước khi gửi, đặc biệt là những khẳng định về bảo mật, performance và test coverage.
7. Kết thúc phiên bằng một bản bàn giao có thể tiếp tục
Một task có thể kéo dài qua nhiều phiên vì cần review hoặc chờ quyết định từ team. Nếu mọi thông tin chỉ nằm trong lịch sử hội thoại, người tiếp nhận sẽ khó biết agent đã thay đổi gì và những phần nào chưa được kiểm tra. Mình kết thúc phiên bằng bản handoff ghi lại phạm vi, quyết định kỹ thuật, kết quả test và công việc còn lại.
Claude Code hỗ trợ tiếp tục phiên bằng claude --continue để mở phiên gần nhất trong thư mục hiện tại hoặc claude --resume để chọn từ danh sách. Trong phiên đang mở, bạn có thể dùng /resume. Nếu hội thoại dài nhưng task chưa xong, /compact giúp tóm tắt context và có thể kèm chỉ dẫn về những thông tin cần giữ.
Khi chuyển sang task không liên quan, /clear giúp bắt đầu hội thoại mới. Nếu agent đã đi sai hướng và cần quay về checkpoint trước, Claude Code có /rewind để đưa hội thoại và code về trạng thái trước đó. Những công cụ này hỗ trợ quản lý phiên, còn bản handoff giúp developer khác tiếp tục mà không phải đọc lại toàn bộ hội thoại.
Mình yêu cầu agent tạo bản tóm tắt theo cấu trúc cố định:
Prepare a handoff summary for this task.
Include:
1. Objective and final scope
2. Key implementation decisions
3. Files or modules changed
4. Tests executed with exact results
5. Acceptance criteria verified
6. Unverified cases and known limitations
7. Open questions
8. Recommended next actions
Do not mark untested behavior as verified.
Do not modify code.
Với report export, bản bàn giao phải nêu rõ API kiểm tra quyền ở đâu, tenant context được lấy từ đâu và CSV được xuất theo phương án nào. Nếu agent đã chạy integration test nhưng chưa kiểm tra trên browser, hai trạng thái đó phải được ghi riêng. Người tiếp nhận có thể dựa vào handoff để xác định bước kế tiếp mà không phải tái dựng các quyết định trước đó.
Mẫu task-brief.md có thể dùng lại
Để sử dụng workflow cho những task khác, mình lưu mẫu sau dưới tên task-brief.md. Đây là tài liệu của từng task, không thay thế tài liệu kiến trúc hoặc conventions chung của repository. Mình thường điền phần repository context sau khi Explore và chốt acceptance criteria trước khi cho Claude triển khai.
# Task: Report export for organization admins
## Objective
Allow authorized organization admins to export
report data as CSV.
The export must respect tenant boundaries and
handle large datasets without loading all records
into application memory.
## Repository context
- Monorepo: TypeScript, pnpm
- Admin application: apps/admin
- Backend API: apps/api
- Shared UI: packages/ui
- Shared types and utilities: packages/shared
Relevant modules:
- Add confirmed paths after repository exploration.
Existing conventions:
- Follow current API authorization patterns.
- Use the existing test framework.
- Reuse existing report query mechanisms
where appropriate.
## Scope
In scope:
- Export API for authorized admins
- Tenant-scoped report queries
- Large dataset handling
- Export action in admin UI
- Relevant API and UI tests
Out of scope:
- New role definitions
- Changes to subscription pricing or plans
- Export history
- Email notifications
- New background job infrastructure
## Constraints
- Never trust client-provided tenant identity.
- Enforce authorization on the server.
- Do not broaden existing role permissions.
- Avoid new dependencies without approval.
- Avoid database migrations without approval.
- Follow existing repository conventions.
## Acceptance criteria
AC1:
Authorized organization admin can export CSV.
AC2:
Unauthorized roles cannot call the export API.
AC3:
Export contains only data belonging to the
authenticated organization.
AC4:
Large exports are processed incrementally.
AC5:
CSV handles empty data and special characters.
AC6:
Existing report permissions remain unchanged.
## Verification
Required:
- API authorization tests
- Cross-tenant isolation tests
- CSV format tests
- Large dataset processing tests
- Regression tests for related permissions
- Browser verification of export behavior
API test command:
pnpm -F api test
For each acceptance criterion, record:
- Test or manual verification method
- Actual result
- Evidence
- Remaining gaps
## Handoff
Implementation summary:
- Record what changed.
Decisions:
- Record approved design choices.
Tests:
- Record commands and actual results.
Known limitations:
- Record unverified behavior and risks.
Open questions:
- Record decisions still required.
Next actions:
- Record what the next developer should do.
Không phải task nào cũng cần điền mẫu chi tiết như ví dụ. Với bug nhỏ, mình giữ phần mô tả cách tái hiện, phạm vi sửa và test xác nhận. Với thay đổi liên quan đến phân quyền hoặc dữ liệu nhiều tenant, mình dành nhiều chỗ hơn cho Constraints, Acceptance criteria và Verification vì đây là những phần agent dễ hiểu thiếu nếu chỉ đọc yêu cầu tính năng.
Kết lại một task, không chỉ kết thúc một phiên Claude
Mình không đánh giá kết quả dựa trên số dòng code Claude tạo ra hay số file nó chỉnh sửa. Với tính năng export báo cáo, điều cần chứng minh là đúng người có thể export, người không có quyền bị từ chối, dữ liệu giữa các tenant không bị lẫn và hệ thống xử lý dữ liệu lớn theo phương án đã duyệt. Những phần chưa kiểm tra phải được ghi rõ trước khi bàn giao.
Workflow Explore, Plan, Implement, Verify và Review giúp mình giữ các quyết định kỹ thuật ở đúng giai đoạn. Agent có thể tự xử lý nhiều chi tiết triển khai, còn developer kiểm soát phạm vi, rủi ro và bằng chứng hoàn thành. Bạn có thể áp dụng quy trình này cho một task đang có trong backlog, lưu lại kế hoạch, kết quả test và handoff rồi đối chiếu chúng với diff cuối cùng.
Các bài trong series
Series Claude Code cho dự án thực tế, mỗi bài trả lời một câu hỏi dev hay gặp khi đưa Claude Code vào dự án thật:
Bài tiếp theo trong series: Hướng dẫn tạo Skill cho Claude Code từ một quy trình làm việc thực tế.
All rights reserved
