Biến Claude Code thành đối tác thiết kế tốt nhất

 (betweentheprompts.com)
37 điểm bởi GN⁺ 2025-08-25 | 2 bình luận | Chia sẻ qua WhatsApp
  • Khi mới dùng Claude Code, tác giả ban đầu tiếp cận theo cách chỉ ra lệnh bằng prompt và lặp lại việc chỉnh sửa, nhưng với các tác vụ phức tạp thì gặp vấn đề về sự phụ thuộc vào lịch sử hội thoại và giới hạn ngữ cảnh
  • Để giải quyết, trước khi triển khai tính năng, tác giả yêu cầu viết tài liệu kế hoạch (plan document) và dùng nó làm nguồn chân lý duy nhất (SSOT) cho một phiên mới
  • Tài liệu kế hoạch bao gồm việc diễn giải lại yêu cầu, mô tả chi tiết triển khai, các lệnh kiểm tra chất lượng mã và tiếp tục được cập nhật trong suốt quá trình triển khai như một tài liệu sống (living document)
  • Cách này giúp giải quyết vấn đề mất ngữ cảnh, và ngay cả trong phiên mới cũng có thể tiếp tục dự án chỉ với một tài liệu duy nhất
  • Kết quả là AI không còn chỉ là công cụ thực thi đơn thuần mà đóng vai trò đối tác thiết kế cộng tác, thúc đẩy lập trình viên suy nghĩ và ghi chép sâu hơn về thiết kế

Nhận diện vấn đề: giới hạn của cách làm việc chỉ bằng hội thoại

  • Khi làm việc tương tác với Claude Code, cách này phù hợp với tác vụ đơn giản, nhưng khi công việc phức tạp tăng lên thì phát sinh nhiều giới hạn nghiêm trọng
    • Hội thoại trở thành nguồn chân lý duy nhất, nên tin nhắn mới có thể dễ dàng ghi đè chỉ dẫn trước đó, và rất khó nhận ra chính xác thời điểm điều này xảy ra
    • Do giới hạn kích thước ngữ cảnh của AI, khi hội thoại kéo dài thì thông tin trước đó có thể bị rơi mất
    • Dù Claude Code có tính năng nén hội thoại, điều này cũng không thể giải quyết hoàn toàn giới hạn trên

Thử nghiệm cách tiếp cận lấy tài liệu kế hoạch làm trung tâm

  • Để giải quyết vấn đề này, tác giả thử cách tiếp cận dựa trên tài liệu kế hoạch
    • Khi bắt đầu, tác giả mô tả với Claude Code càng chi tiết càng tốt về tính năng cần triển khai hoặc lỗi cần sửa
    • Đồng thời cũng nhắc đến các tệp mã nguồn hiện có hoặc các tài liệu kế hoạch đã viết trước đó để tham chiếu
    • Tác giả tránh đưa ra chỉ dẫn triển khai quá cụ thể, nhằm khuyến khích AI đóng vai trò đề xuất thiết kế
    Quảng cáo
  • Khi tài liệu kế hoạch đã đủ thỏa đáng, tác giả xóa lịch sử hội thoại và bắt đầu lại chỉ với chính kế hoạch đó làm ngữ cảnh
    • Kế hoạch bao gồm tóm tắt tính năng, kế hoạch triển khai, mã và mã giả, các lệnh type/lint/test, v.v.

Quy trình thiết kế cộng tác

  • Khi không hài lòng với thiết kế do AI đề xuất, tác giả cung cấp phản hồi cụ thể để dẫn tới cách tiếp cận đã được điều chỉnh
  • Trong quá trình thảo luận, đôi khi tác giả nhận ra đề xuất ban đầu của AI lại phù hợp hơn, và cách này hiệu quả hơn so với việc chỉ lập thiết kế rồi tự mình viết mã
  • Các cuộc trao đổi có hệ thống mang lại trải nghiệm tương tự như thảo luận kế hoạch với một đồng nghiệp lập trình viên
  • AI không tự mình đưa ra một hướng tiếp cận hoàn toàn khác, nhưng nếu được hỏi thì vẫn có thể đề xuất các phương án thay thế khác

Phương thức Tài liệu sống (Living Document)

  • Tài liệu kế hoạch không được viết một lần rồi thôi, mà tiếp tục được cập nhật ngay trong quá trình triển khai tính năng
    • Những thay đổi bộc lộ trong quá trình triển khai, kiểm tra kiểu, lint và test sẽ được phản ánh theo thời gian thực
    Quảng cáo
  • Tác giả hình thành thói quen yêu cầu kiểm tra trạng thái mới nhất của kế hoạch mỗi khi commit mã
  • Nhờ luôn duy trì kế hoạch ở trạng thái mới nhất, ngay cả trong một phiên hội thoại mới cũng chỉ cần đính kèm kế hoạch là có thể tiếp tục mà không mất ngữ cảnh

Đánh giá mã và thay đổi trong thói quen phát triển

  • Sau khi bắt đầu triển khai, tác giả định kỳ kiểm tra các thay đổi và, nếu thấy hài lòng, cũng tin tưởng hơn vào công việc của AI
  • Khi rà soát mã cuối cùng, tài liệu kế hoạch đã được cập nhật giúp nắm bắt cơ sở cho các quyết định kỹ thuật
  • Việc lập kế hoạch kỹ lưỡng và tài liệu hóa từ trước mang lại trải nghiệm giúp tác giả trở thành một lập trình viên tốt hơn
    • Vì phải giải thích cho AI, tác giả buộc phải sắp xếp rõ ràng hơn chính quá trình ra quyết định của mình

Từ hỗn độn đến có hệ thống

  • Cách làm này biến tài liệu kế hoạch thành nguồn chân lý duy nhất, giải quyết vấn đề mất ngữ cảnh và thúc đẩy tư duy kiến trúc
  • Tài liệu kế hoạch bao gồm cả đặc tả lẫn nhật ký triển khai, ghi lại không chỉ “cái gì” mà cả “vì sao” và “như thế nào”
  • Kết quả cuối cùng là một quy trình phát triển có kế hoạch, được tài liệu hóa tốt và đáng tin cậy
  • AI không còn là người triển khai đơn thuần mà trở thành đối tác thiết kế cộng tác

Bài viết liên quan

2 bình luận

 
jamsya 2025-08-26

Có vẻ như trong quy trình làm việc của lập trình viên, vai trò của PM và kiến trúc sư đang trở nên quan trọng hơn.
 
GN⁺ 2025-08-25
Ý kiến trên Hacker News

  • Trong 2 tuần qua, tối nào tôi cũng tập trung cao độ để tạo ra một "prompt hoàn hảo" có thể dùng claude code hoàn thành dự án trong một lần. Cuối cùng tôi đã thiết kế cấu trúc để một CLAUDE.md tham chiếu tới 8 file markdown khác nhau, bao gồm kiến trúc dự án, đặc tả mô hình, thứ tự build, tầng kiểm thử, kịch bản, v.v. Dự án này phục vụ governance dựa trên mô hình của Databricks Unity Catalog; tôi có khá nhiều kinh nghiệm liên quan, nhưng không thấy các công cụ hiện có đủ linh hoạt. Cuối cùng, tôi nhận được hỗ trợ trong việc xử lý các file kế hoạch thực tế từ 3 sub-agent: chuyên gia Databricks, chuyên gia Pydantic và chuyên gia prompt. Nhờ vậy, chất lượng các file markdown đã được cải thiện rất nhiều, từ các vấn đề về phiên bản Pydantic cũ cho tới những hiểu nhầm của chính tôi về Unity Catalog. Hôm qua tôi đã chạy thử thực tế, và ngoài vài lần tôi phải phê duyệt việc dùng công cụ, thì chỉ trong 2 giờ phần lớn công cụ và bài test đã hoàn thành. Cách làm này khác quá nhiều so với trước đây nên tôi thấy rất kỳ diệu; tôi thực sự cảm nhận được tương lai nằm ở việc viết tài liệu kỹ thuật cẩn thận và làm cho mọi người cùng nhìn về một hướng. Tôi cũng nghĩ năng suất của nó tốt hơn so với việc tự mình đào sâu vào code. Tuy nhiên, lúc làm code tôi tập trung hơn nhiều, còn khi xử lý nhiều tài liệu markdown thì sự tập trung lại dễ bị phân tán hơn. Đúng là một thời đại rất thú vị

    • Tôi cảm nhận được một kiểu mẫu mới đang nổi lên, giống như Test-Driven Development, buộc người ta phải thiết kế hệ thống từ trước. Trước đây, khi viết code ta sẽ dần dần hình dung ra hệ thống, còn phát triển dựa trên AI như lần này thì lại khiến ta thiết kế và mapping miền bài toán trước, để phần code thực tế chỉ còn như công việc boilerplate hiện thực hóa bản thiết kế. AI cực kỳ giỏi ở phần boilerplate này

    • Tôi cũng đang băn khoăn vì đúng là mình năng suất hơn nhưng sự tập trung lại phân tán hơn nhiều. Có gì đó hơi lạ, nhưng hiện tại thì vẫn hiệu quả. Về lâu dài chắc phải tìm cách giải quyết. Cách phù hợp nhất với tôi lúc này là để nhiều agent xử lý các task khác nhau trên nhiều repository của dự án, còn tôi liên tục làm phần phê duyệt. Nó giống như cảm giác làm quản lý dự án điều hành một đội ngũ rất lớn. Đúng là một thời đại thú vị

    • Cách này thực sự mới mẻ. Tôi tò mò framework nào đang chạy các agent trong những thử nghiệm thực tế đó

    • Dạo này tôi cũng ghi âm bằng giọng nói các chi tiết sản phẩm, hành trình người dùng, rồi dùng đó để bắt đầu quy trình tài liệu kỹ thuật. CLAUDE.md ở mức tối thiểu, phát triển phần mềm thì dùng workflow của Github, nhưng tạo một workflow CI tốt thì rất khó. Playbook của tôi là https://nocodo.com/playbook/

  • Tôi không thật sự đồng cảm với luận điểm "lập kế hoạch trước thì kết quả sẽ tốt hơn". Từ xưa đến nay, với các tính năng lớn hay cả dự án, tôi vẫn luôn nghĩ trước về cấu trúc, lý do và cách làm, dù là trong đầu, trên giấy, trong Confluence hay trên bảng trắng. 80% của software engineering là quá trình suy nghĩ và chốt xem sẽ làm "cái gì, vì sao, và như thế nào". Ta xác nhận ý tưởng và mục tiêu với các bên liên quan, rồi nghiên cứu nữa. Chỉ 20% cuối cùng mới là coding thực sự. Xưa nay vẫn vậy, nên tôi không chắc AI có thật sự cần thiết cho việc lập kế hoạch hoặc định nghĩa mục tiêu một cách bài bản hay không

    • Điều đó có thể đúng ở các đội lớn hoặc môi trường đã có văn hóa làm việc ổn định, nhưng rất nhiều hoạt động phát triển lại tập trung vào dự án cá nhân, nhóm nhỏ, side project, POC nhanh hoặc công cụ tự động hóa dùng một lần. Những việc như vậy thường không bắt đầu bằng tài liệu/đặc tả/test ngay từ đầu, mà tiến hành bằng cách trộn lẫn code với quá trình suy nghĩ và triển khai. Có nơi TDD phù hợp, nhưng cũng có nhiều trường hợp không thực sự cần. Tuy nhiên, sau khi đưa AI coding agent vào, quá trình định nghĩa ý tưởng rõ ràng và sắp xếp nó thành đặc tả trở nên quan trọng hơn rất nhiều. Việc diễn đạt thành lời mọi thứ đang hiện ra trong đầu tôi giờ gần như là bắt buộc. Ngôn ngữ lập trình hot nhất hiện nay là tiếng Anh

    • Tôi thường phát triển bằng cách trộn lẫn giữa coding và thiết kế. Tôi cứ bắt đầu code trước rồi liên tục tinh chỉnh và phát triển dần. Trong đa số trường hợp, cách giải quyết đại khái đã khá rõ ràng, nên tôi cảm thấy không cần bỏ thời gian lên kế hoạch quá sâu

  • Trước đây prompt engineering còn là trò đùa, nhưng giờ tôi thực sự cảm nhận được nó. Có lúc tôi dành 10~20 phút chỉ để trau chuốt prompt và kế hoạch ban đầu thật cẩn thận nhằm sử dụng cloud code một cách có hệ thống. Tôi cũng giống OP ở chỗ lưu kế hoạch thành file rồi chạy nó trong một context mới. Điều tôi thực sự mong muốn là một CLI tốt hơn nữa (charm, cc hiện đang dùng). Sẽ là tuyệt nhất nếu có thể dùng model riêng cho phần triển khai, phần lập kế hoạch và từng sub-agent. Một cấu trúc tiết kiệm chi phí bằng cách triển khai bằng model local, còn lập kế hoạch bằng model cloud hoặc hoán đổi khi cần. Charm hiện là công cụ tôi dùng thấy làm tốt nhất chuyện qua lại mà không mất context. Tính năng sub-agent chạy song song cũng là một trong những điểm mạnh nhất của claudecode. (Tôi đã thử CCR nhưng thất vọng vì nó không vượt quá model mặc định)

    • Prompt engineering trở thành chủ đề nóng hiện nay là vì các hot take trên Twitter hay những chủ đề liên quan tới sản xuất nội dung. Nhưng trên thực tế, prompt engineering vốn đã quan trọng từ lâu. GIGO ("Garbage In, Garbage Out" — đầu vào rác thì đầu ra cũng rác) là chân lý trong mọi dự án machine learning. Vì vậy tôi luôn khuyên đồng nghiệp và bạn bè rằng "phải tự mình dùng thử". Điều không làm được 6 tháng trước thì bây giờ có thể đã làm được. Phải thực sự tự tay dùng quen thì mới biết điều gì đã thay đổi, điều gì đã khả thi. Tôi nghĩ thay vì sự tiêu cực, những câu chuyện thành công thực tế, bài blog, gist hay ví dụ cụ thể có giá trị hơn nhiều. Không phải để làm vài phép tính đơn giản hay bắt lỗi chính tả, mà là để nó thực sự cải thiện và hỗ trợ workflow của tôi. Prompt engineering giống như việc 10~15 năm trước người ta đắm mình vào kỹ năng dùng Google, liên tục học những thay đổi mới và các pattern hiệu quả

    • Để cộng tác với AI thì prompt engineering thực sự là cốt lõi

    • Những dự án tôi dùng AI lại là những dự án được tài liệu hóa và kiểm thử tốt nhất. Vì muốn kéo được hiệu năng từ LLM thì bắt buộc phải có context, nên tài liệu trở nên đầy đủ hơn; hơn nữa chi phí tạo test đã giảm xuống nên số lượng test cũng tăng lên. Trái với dự đoán rằng chất lượng code sẽ đi xuống, tôi nghĩ nó sẽ còn tốt hơn

    • Thành thật mà nói, thuật ngữ "prompt engineering" thực chất là thiết kế kiến trúc bằng một loại phương tiện mới. Cũng như trước đây kỹ năng "thiết kế bằng sơ đồ" từng được coi trọng, thì giờ đây đây là một cách làm kiến trúc mới

  • Gần đây tôi thử Claude Code một chút và định sẽ áp dụng workflow được khuyên dùng. Có vẻ là một cách làm khá ổn. Nhưng chi phí dùng CC cao hơn tôi nghĩ. Tôi chỉ làm một đợt refactor đơn giản, 5 phút thao tác + 15 phút review mà đã tốn 4 đô. Nếu tự làm thì chắc chỉ mất 15~20 phút là xong. Tôi tò mò không biết mọi người thường tốn khoảng bao nhiêu cho một tính năng khi dùng CC. Chẳng thấy ai nói về giá cả cả

    • Nếu đăng ký gói thì sẽ là mức phí cố định $20~$200 kèm giới hạn lượng token sử dụng theo ngày/tuần. https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan

    • Hướng đi mà các nhà đầu tư AI mong muốn là một cấu trúc trong đó AI thay thế thị trường lao động với biên lợi nhuận 15%. Sẽ đến thời kỳ mà ngân sách dành cho developer và AI ngang 1:1. Ví dụ, phần việc của một senior developer lương 100 nghìn đô sẽ được thay bằng 100 nghìn đô ngân sách AI. Ngân sách AI sẽ được trích từ chi phí phát triển, lương senior có thể giảm xuống, và quy mô đội ngũ phát triển có thể bị thu hẹp mạnh. Hiện tại vẫn đang là giai đoạn "chiếm lãnh thổ" được VC trợ cấp toàn phần, nhưng nhìn không khí VC trên Twitter thì có vẻ giai đoạn này sắp kết thúc. Việc liên tục kéo thêm hàng trăm triệu đô cho 9 tháng chi phí vận hành cũng đang chạm giới hạn

    • Từ khi chuyển một phần từ Cursor sang Claude Code, chi phí của tôi tăng khá nhiều. Vì chủ yếu dùng ở công ty nên việc thuyết phục sếp không khó, nhưng với side project thì khá phân vân. Tôi không muốn cứ mỗi lần bootstrap một app cho vui lại phải bỏ ra 20 đô

    • Có thể chọn đăng ký hai model là Sonnet (20 euro/tháng) và Opus (100 euro/tháng). Tôi dùng Sonnet một thời gian rồi sau đó chuyển sang Opus. Sonnet cũng đã đủ dùng rồi. Trong giới hạn token thì với nhu cầu của tôi hiện tại chưa thấy thiếu. Nhưng tương lai thì tôi không chắc

    • Bạn nói "nếu tự làm thì cũng chỉ mất 15~20 phút", nhưng có lẽ 15~20 phút đó có thể được dùng cho việc khác thì sao

  • Cách tôi dùng tổ hợp Visual Studio Code/ChatGPT5 preview khá giống workflow này {có lẽ tôi đang thanh toán qua gói Github Copilot, nhưng dạo này cũng không còn chắc nữa}. Tôi cảm thấy LLM không-agent có xu hướng làm code hỏng rất nhanh. Từ khi dùng agent mode thì việc xây dựng code thay đổi hẳn. Tôi không phải Python developer, nhưng thực sự đã bị ấn tượng khi thấy LLM viết ra cả một đống code mới. Sau khi hoàn thành, tôi định chạy một LLM nhỏ trên BitGrid rồi từ từ hiểu toàn bộ code về sau. Cấu trúc là lặp lại các bước khám phá nhỏ, và chỉ chỉnh sửa một phần để giữ cho thiết kế tổng thể đúng như mình muốn. Điều đó khiến tôi tin vào tương lai nơi LLM trở thành đối tác lập trình. Tôi tò mò không biết có ai khác cũng dùng tổ hợp Visual Studio Code/ChatGPT5 không

  • Thật thú vị khi việc tối ưu hóa các công cụ AI dường như đang khiến developer tái khám phá giá trị của "giao tiếp tốt" và "thiết lập kỳ vọng". Có lẽ đã đến lúc phải xem lại hình tượng 10x developer kiểu người ngoài lề hay lập dị bấy lâu nay

  • Tôi có trải nghiệm tương tự với Replit. Khi ứng dụng lớn dần, nếu tài liệu thiết kế không trở thành task và nguồn chân lý duy nhất thì mọi thứ sẽ sụp rất nhanh. OpenAI thì chat chậm đi và nhanh chóng đơ, nên việc tạo tài liệu riêng rồi import vào chat mới rất hữu ích. Ở góc độ con người cũng vậy, tôi cảm thấy chính chúng ta cũng nên làm thế. Bằng cách tự nhìn lại, tài liệu hóa và ghi lại "memory" vào tài liệu thiết kế, cả chúng ta lẫn LLM đều có thể trở nên tự do hơn

  • Tôi cũng mới khám phá workflow này gần đây và rất ngạc nhiên. Điều quan trọng là chỉ cung cấp cho claude những yêu cầu tối thiểu, rồi để nó tự do chạy plan mode. Ví dụ nếu là báo cáo chỉ số sales, chỉ cần nói "Ultrathink relevant sales metrics" là nó sẽ đưa ra nhiều chỉ số khác nhau và xếp hạng để ta chọn lọc. Tôi tạo một directory riêng cho từng tính năng mới, và để nó viết file plan cho tính năng đó. Sau đó tôi bảo nó lần lượt làm kế hoạch triển khai, các truy vấn dữ liệu cần thiết, phần hiện thực, test, tài liệu người dùng rồi gửi sang QA. Trước đây để làm một tính năng dự báo sales cần cả một đội lớn và rất nhiều thời gian, còn claude thì hiện thực nó trong container Docker chỉ trong nửa ngày. Sự thay đổi này đang làm thay đổi cách tôi nhìn về phần mềm. Trước đây vì NDA, IP, v.v. mà các công ty tuyệt đối không đưa source code ra bên ngoài. Nhưng giờ thì ngay cả một hệ thống ERP phức tạp được xây dựng suốt 20 năm, claude cũng có thể tái hiện khá nhanh và còn kèm theo tài liệu, test. Thực tế thì nó chưa hoàn hảo ngay lập tức, nhưng tốc độ tiến triển thật sự rất nhanh

  • Muốn khai thác được tính năng tốt từ Claude Code thì mấu chốt là phải viết plan tử tế trước. Gần đây tôi dùng GPT-5 High trong Cursor để lập plan, rồi đưa nó vào Claude Code để triển khai. Nếu để nó tài liệu hóa trước những phần cần thay đổi trong codebase thì có thể cho kết quả tốt hơn thêm 15~20%. Nếu model lập kế hoạch ghi lại cách hệ thống hoạt động, kiến trúc, pattern, rồi lồng cả thiết kế tính năng vào đó thì đầu ra sẽ tốt hơn. Cuối cùng, việc trực tiếp review và chỉnh sửa tài liệu cũng như plan là cực kỳ hữu ích

    • Ở công ty tôi dùng Google Workspace nên Gemini rất mạnh trong kiểu viết "phong cách học thuật", nhưng lại yếu hơn CC khi viết code. Vì vậy tôi để Gemini chuẩn bị plan đủ chi tiết, rồi chuyển nó cho CC để chỉnh sửa và triển khai trên codebase của mình. Cách này cho hiệu quả đáng kinh ngạc khi phát triển tính năng mới hoặc mở rộng tính năng cũ. Trong 8 tuần, sản phẩm do chính tôi làm hiện đã chạy trong production thực tế và còn đang demo cho khách hàng. Tôi rất hài lòng với trải nghiệm và đầu ra của CC. Như tôi từng nói trên HN trước đây, với nguồn lực trong đội thì lẽ ra chúng tôi cũng làm được phần lớn việc đó, nhưng riêng frontend thì gần như không dám nghĩ tới. Công việc lẽ ra mất hơn 1 năm, đòi hỏi thêm nhiều kỹ sư và data scientist, thì giờ phần lớn đã hoàn thành trong 2 tháng. Việc thêm tính năng giờ gần như không còn tính bằng thời gian mà bằng "vài giây". Nhờ CC mà tôi thấy thú vị khi kinh nghiệm của mình đang được chia sẻ với nhiều người

  • Tôi tò mò không biết có ai đã tìm ra cách hay để đưa frontend design vào quy trình này một cách thanh lịch chưa. Phần lớn những gì tôi thấy chỉ dừng ở việc nhắc đến frontend framework, hoặc ảnh figma. Như vậy chưa mang lại cảm giác là một giải pháp thiết kế tích hợp toàn diện