Hai tháng gia nhập big tech, những đúc kết về phát triển AI của tôi

Link bài viết gốc： https://x.com/huangtongxueh/status/21085...

Hoàng Đồng Học h · X · @huangtongxueh · 2026-10-09 23:15

Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc

Bối cảnh

Mọi chuyện bắt đầu từ vài buổi one-on-one với sếp trong team. Anh ấy rất hứng thú với cách tôi dùng công cụ AI hiện tại, cách dựng Harness cá nhân, cũng như workflow AI Coding. Lý do chính là vì các requirement tôi làm hiện tại vừa nhanh vừa chuẩn, và tôi đã là Owner chính của một số dự án. Nhân dịp này, tôi tổng hợp lại workflow AI hàng ngày của mình. Hiện tại, trong team tôi chủ yếu làm Agent development, đồng thời duy trì các nghiệp vụ backend sẵn có.

Trước đây, tôi từng chia sẻ workflow liên quan trên Xiaohongshu. Bối cảnh lúc đó là GPT-5.4 và Opus 4.6 đã có thể hoàn thành tốt nhiệm vụ khi nhận đủ context chính xác và các ràng buộc hợp lý. Sự phát triển của Harness Engineering cũng giúp mọi người nhận ra: hoàn toàn có thể kiểm soát model mạnh mẽ tốt hơn bằng cách tăng cường các ràng buộc.

Ví dụ như Skill dạng Superpowers cung cấp một bộ triển khai khá nặng, chủ yếu xoay quanh Spec và TDD, giúp người dùng dễ dàng tổ chức và thúc đẩy nhiệm vụ hơn.

Nhưng làm vậy cũng có mặt hạn chế. Cảm nhận rõ nhất là: tiêu hao token rất nhanh. Những Skill như Superpowers chứa rất nhiều workflow dùng để ràng buộc bước đi tiếp theo của model. Ngay cả khi xét về tổng thể, một bước nào đó đã không còn cần thiết—chẳng hạn context đã đủ và có thể bắt đầu code ngay—thì model vẫn có thể tiếp tục chạy theo quy trình định sẵn.

Cùng với sự ra mắt của các model mới, tôi thấy nhiều developer chia sẻ rằng họ gần như không còn dùng những Skill quá nặng này nữa. Nguyên nhân chính là khi năng lực của model được nâng cao, một số ràng buộc và quy trình từng được xem là hữu ích nay lại trở thành nhiễu đối với model. Chẳng hạn, khi OpenAI ra mắt Astra, họ đã viết hẳn một bài blog hướng dẫn cách dọn dẹp các Skill và prompt hệ thống không cần thiết để tối ưu trải nghiệm sử dụng model.

Vì vậy, bài viết này sẽ kết hợp với kinh nghiệm thực tế vài tháng qua của tôi để chia sẻ những cách làm đang phát huy hiệu quả tốt, cùng trao đổi về cách khai thác tối ưu các loại Agent nhằm nâng cao hiệu suất phát triển hàng ngày.

I. Các Skill và prompt tôi thường dùng

Phân chia công cụ hiện tại của tôi

Hiện tại, tôi chủ yếu dùng Codex + GPT-5.6 Sol để viết code, dùng Astra để lập kế hoạch. Trước khi Astra ra mắt, việc lập kế hoạch chủ yếu do GPT-5.6 Sol Max đảm nhiệm.

Với các requirement đơn giản, tôi dùng pi + DeepSeek V4 Flash để thực hiện; việc rà soát phản biện phương án và Code Review chủ yếu giao cho Claude 5 Fable. Ở các dự án cá nhân, tôi vẫn dùng GPT-6 Pro bản web để thiết kế phương án chính.

Các Skill tôi thường dùng

1. suy nghĩ : Skill của tw93, chủ yếu dùng để thống nhất phương án và brainstorm.
2. grill me / grill with docs : Chủ yếu dùng để làm rõ requirement. Thông qua việc liên tục truy vấn để làm rõ mục tiêu, ràng buộc và đánh đổi, sau đó lưu lại vào ADR hoặc CONTEXT.md tùy theo quy trình phát triển. Nó giúp tôi đào sâu những vấn đề chưa lường tới trong giai đoạn thống nhất ban đầu.
3. implement : Dùng phối hợp với grill, nằm trong bộ Skill của Matt Pocock, dùng để hiện thực hóa kế hoạch hoặc Issue đã xác định rõ.
4. ponytail : Dùng để loại bỏ phần over-engineering của AI, giảm bớt độ phức tạp khi Review. Tôi dùng cái này rất thường xuyên, vì GPT-5.6 Sol rất hay thiết kế thừa thãi.
5. bàn giao : Tổng hợp context hiện tại thành file, thuận tiện để tiếp tục nhiệm vụ trong session mới. Tôi thường dùng để bàn giao từ Codex sang Claude Code hoặc pi agent.
6. check : Dùng để review code, thường dùng khi tạo MR.
7. Skill đúc kết từ công việc và dự án cá nhân: Chủ yếu là các SOP quy trình có thể tái sử dụng, ví dụ như kiểm thử end-to-end. Lời khuyên của tôi là: trong công việc hàng ngày, nếu một quy trình lặp lại quá ba lần, bạn nên cân nhắc nhờ Codex đóng gói thành Skill để dùng lại sau này.

Các prompt tôi thường dùng

Hiện tại tôi rất ít khi tự viết những đoạn prompt dài. Khi cần, tôi thường để Codex tổng hợp giúp. Ví dụ, sau nhiều vòng thảo luận, tôi muốn chuyển giao context hiện tại cho GPT Pro để thiết kế phương án, tôi sẽ nhờ Codex tạo trước một prompt bàn giao hoàn chỉnh.

Bên cạnh đó, tôi thường xuyên dùng những prompt cực ngắn thuộc các nhóm dưới đây.

Đôi khi chúng mang lại hiệu quả "một câu bằng ngàn lời". Tôi coi chúng như những "phím tắt tư duy" dành cho model.

Chúng không phải câu thần chú màu nhiệm, mà là các phương pháp luận đã được chuẩn hóa cao độ trong tri thức nhân loại. Trong quá trình huấn luyện, model đã đọc vô số bài báo, mã nguồn, tài liệu thiết kế và thảo luận liên quan, nên nhiều khi bạn không cần viết tay hàng trăm dòng workflow, chỉ cần chỉ định cho nó biết nên dùng lối tư duy nào. Dưới đây là những prompt tôi đã đúc kết và thấy cực kỳ hiệu quả trong thực tế:

• Nguyên lý khởi nguyên (First Principles): Đừng tiếp tục tối ưu hóa dựa trên phương án hiện có, hãy đặt lại câu hỏi xem vấn đề này thực chất cần giải quyết như thế nào. Ví dụ, một API chạy rất chậm, bạn có thể viết:

Không tiếp tục thiết kế dựa trên phương án định sẵn là "thêm cache Redis". Hãy phân tích từ nguyên lý khởi nguyên xem tại sao API này lại chậm, và giải pháp tối thiểu cần thiết là gì.

Trọng tâm của model sẽ lập tức chuyển từ "nên thiết kế Redis ra sao" sang:

Điểm nghẽn thực sự nằm ở SQL, mạng, serialization, tranh chấp lock hay tính toán trùng lặp? Nếu chỉ cần thêm một index vào SQL là giải quyết được, tại sao phải đưa thêm Redis vào?

Dạng prompt này rất phù hợp khi bạn nghi ngờ "ngay từ đầu đề bài đã bị đặt sai".

• Rà soát đối kháng (Adversarial Review): Đừng tìm lý do bênh vực phương án của tôi, hãy tìm cách chứng minh nó sai

Cách hỏi thông thường:

Xem giúp tôi phương án kỹ thuật này có vấn đề gì không.

Có thể đổi thành:

Hãy thực hiện một đợt adversarial review cho phương án này, ưu tiên tìm các phản ví dụ có thể lật đổ những giả định cốt lõi.

Giả sử phương án của bạn là "đưa distributed lock vào để xử lý trùng lặp request", model sẽ không dừng lại ở việc bảo bạn chỉnh timeout của lock thế nào, mà sẽ bắt đầu chất vấn:

Request trùng lặp có thực sự cần mutual exclusion không? Tính idempotency của API có xử lý được không? Dịch vụ lock bị sập thì sao? Lock hết hạn nhưng nghiệp vụ chưa chạy xong thì tính thế nào? Liệu có phải để giải quyết một lỗi cục bộ mà bạn lại tạo thêm một điểm lỗi phân tán mới?

Dạng prompt này đặc biệt hữu ích khi thẩm định phương án và Code Review.

• Thí nghiệm bóc tách (Ablation Study): Hệ thống chạy tốt hơn không đồng nghĩa với việc mọi thứ bạn thêm vào đều có ích

Ví dụ, bạn thực hiện cùng lúc ba tối ưu hóa:

Sau khi thêm index, cache Redis và batch query, thời gian xử lý API giảm từ 800ms xuống còn 100ms.

Lúc này bạn có thể hỏi thẳng:

Hãy thiết kế thí nghiệm bóc tách (ablation study) cho ba tối ưu hóa này để xác định lợi ích thực sự đến từ đâu.

Model sẽ thiết kế các nhóm đối chứng dựa trên các tổ hợp khác nhau, ví dụ lấy Baseline làm mốc, so sánh: chỉ thêm index, index + cache, index + cache + batch query, v.v.

Cuối cùng bạn có thể nhận ra:

Chỉ riêng việc thêm index đã kéo thời gian xử lý từ 800ms xuống 120ms, hai phương án phức tạp còn lại chỉ đóng góp thêm 20ms.

Nhờ đó, bạn biết chính xác đoạn code nào đáng giữ lại và phần phức tạp nào là thừa thãi.

• Dao cạo Ockham: Khi hiệu quả tương đương, ưu tiên chọn phương án ít giả định hơn và ít phức tạp hơn

Ví dụ, Agent thiết kế cho bạn một phương án như sau:

Kafka + Redis + distributed lock + state machine + cơ chế bù trừ định kỳ.

Bạn có thể bồi thêm một câu:

Dùng dao cạo Ockham rà soát lại thiết kế này, với điều kiện đáp ứng đủ requirement, hãy loại bỏ toàn bộ các cơ chế không cần thiết.

Nhiều trường hợp, cuối cùng nó sẽ thấy:

Bối cảnh hiện tại chỉ ghi vào một database duy nhất, một transaction cùng unique index là đã đủ.

Câu này đặc biệt hữu ích với các Coding Agent hiện nay, vì model rất dễ over-engineering chỉ để trông có vẻ "toàn diện".

• High cohesion, low coupling: Kiểm tra lại trách nhiệm và ranh giới của code

Ví dụ, bạn thấy một OrderService đã dài tới 2000 dòng, có thể hỏi:

Hãy rà soát ranh giới trách nhiệm của OrderService theo nguyên tắc high cohesion, low coupling, đừng chia tách chỉ để cho có.

Model thường sẽ bắt đầu kiểm tra:

Tại sao service đơn hàng lại kiêm cả kho bãi, coupon, SMS, thanh toán và báo cáo? Logic nào thuộc về domain đơn hàng, logic nào nên bàn giao cho module khác qua API ổn định?

Thao tác mà nó kích hoạt không chỉ là việc "tách file", mà là toàn bộ đánh giá về tính module hóa, information hiding, hướng phụ thuộc và phân định trách nhiệm.

Vì vậy, hiện tại tôi rất hiếm khi viết:

Bước 1 phân tích requirement, bước 2 kiểm tra giả định, bước 3 tìm giải pháp thay thế, bước 4...

Nhiều phương pháp luận hoàn chỉnh vốn đã được model học kỹ. Tôi thường chọn cách nói thẳng:

Phân tích lại từ nguyên lý khởi nguyên, rà soát đối kháng (adversarial review) cho phương án hiện tại; cơ chế cốt lõi phải được kiểm chứng qua ablation study; giải pháp tuân thủ dao cạo Ockham, code đảm bảo high cohesion, low coupling.

Đằng sau vài chục chữ này thực chất đã kích hoạt năm hành động tư duy riêng biệt:

Định nghĩa lại vấn đề → Công kích giả định → Xác minh đóng góp → Loại bỏ độ phức tạp → Sắp xếp ranh giới hệ thống.

Đây cũng là bước chuyển trong prompt Engineering thời kỳ model mới theo góc nhìn của tôi: Thay vì viết cứng toàn bộ quy trình tư duy cho model, hãy dùng phương pháp luận chuẩn xác để hướng dẫn nó "cần tư duy theo góc độ nào", rồi bổ sung các ràng buộc thực sự cần thiết cho nhiệm vụ cụ thể.

II. Workflow phát triển hàng ngày của tôi

Khi nhận được một requirement, tôi thường đưa context liên quan cho Agent trước, chẳng hạn như PRD, biên bản họp, lịch sử chat và phản hồi từ người dùng, rồi dùng grill để thống nhất requirement với nó.

Các tư liệu này thường không phải là một requirement hoàn chỉnh và nhất quán. PRD có thể chưa cập nhật, cuộc họp có thể đã bổ sung hạn chế mới, tin nhắn chat lại thay đổi mức độ ưu tiên. Bản thân cách tôi hiểu requirement cũng có thể ngầm chứa những giả định chưa từng được nói ra.

Tôi sẽ để Agent kết hợp Wiki của team và code hiện có để hiểu tài liệu, sau đó liên tục truy vấn để làm rõ các mục tiêu, ranh giới và đánh đổi ảnh hưởng đến việc triển khai. Có câu hỏi tôi trả lời được ngay, có câu cần quay lại xác nhận với Product hoặc đồng nghiệp liên quan.

Ở bước này, tôi giữ một chừng mực: Khi những câu hỏi còn lại không làm thay đổi đáng kể hướng triển khai và kết quả nghiệm thu, tôi sẽ bắt đầu code.

Tôi không bắt nó phải lên kế hoạch trước cho từng chi tiết triển khai, nếu không chính bước thống nhất requirement lại trở thành một quy trình cực kỳ cồng kềnh.

Các kết luận sau khi thống nhất sẽ được lưu lại vào Spec hoặc CONTEXT.md, chủ yếu ghi lại vấn đề cần giải quyết lần này, phạm vi, các quyết định then chốt và tiêu chí nghiệm thu. Điều này cũng giúp các Agent phụ trách triển khai và review sau đó chia sẻ chung một context, mà không cần phải đọc lại toàn bộ cuộc trò chuyện trước đó.

Sau khi phương án được chốt, tôi sẽ để Agent chính quyết định cách thực thi dựa trên độ phức tạp của nhiệm vụ. Nhu cầu đơn giản sẽ được trực tiếp triển khai; nhu cầu phức tạp sẽ được tách thành các Issue có ranh giới rõ ràng và có thể nghiệm thu độc lập. Chỉ những phần có thể thúc đẩy độc lập mới được giao cho các subagent phát triển song song trong các worktree khác nhau, cuối cùng Agent chính sẽ chịu trách nhiệm tích hợp.

Agent lập trình sẽ hoàn thành việc test trước. Khi nó cho rằng đã có thể bàn giao, tôi sẽ dựa vào độ phức tạp của nhiệm vụ để đưa các Agent khác vào làm review đối kháng chéo. Các vấn đề phát hiện được sẽ phản hồi tập trung cho Agent lập trình chính, tức là Codex, để nó sửa và xác thực lại.

Trước khi tôi tự mình Review, việc kiểm thử end-to-end cũng sẽ được tiến hành.

Hiện tại tôi không đọc từng dòng toàn bộ code được tạo ra nữa, mà chủ yếu xem kết quả test và logic nghiệp vụ cốt lõi. Ở đây có một tiền đề rất quan trọng: phạm vi của mỗi MR đều phải đủ nhỏ, và cùng với tiến độ phát triển, từng bước xác thực luồng nghiệp vụ hoàn chỉnh.

MR nhỏ giúp những thay đổi cần hiểu và đánh giá mỗi lần luôn nằm trong phạm vi kiểm soát; còn kiểm thử end-to-end sẽ giúp tôi kiểm tra xem những thay đổi này khi đưa vào quy trình nghiệp vụ thực tế có hoạt động đúng hay không. Khi Review thủ công, tôi sẽ tập trung xác nhận lại logic nghiệp vụ và liệu kết quả test hiện tại đã đủ để hỗ trợ cho lần bàn giao này hay chưa.

3. Cách xây dựng kiểm thử end-to-end thân thiện với Agent

AI hiện đã rất giỏi viết test case, hở một chút là viết cả trăm dòng test cho một Bugfix (đặc biệt là 5.6 sol). Nhiều khi, việc viết nhiều test tự nó không có vấn đề gì, nhưng sau khi triển khai lên production, chúng ta vẫn gặp phải những lỗi ngoài dự kiến.

Trong thực tế của tôi, một vấn đề cốt lõi là: chưa cung cấp cho Agent một môi trường kiểm thử end-to-end để nó có cơ hội phát hiện ra những vấn đề này ngay từ giai đoạn lập trình và tự test.

Nếu có thể dựng được một môi trường như vậy, giúp Agent dễ dàng thực thi nhiệm vụ từ entry point thực tế của môi trường test, và kiểm tra xuyên suốt cho đến kết quả mà người dùng cần, chúng ta sẽ yên tâm hơn rất nhiều khi để code do AI viết chạy trong hệ thống thực tế.

Trong quá trình phát triển thực tế, tôi đã dựng một môi trường phát triển và kiểm thử end-to-end cho nghiệp vụ của chúng tôi. Agent có thể thuận tiện truy vấn bảng cơ sở dữ liệu, tra cứu log, cũng như kết nối tới máy chủ để điều tra xử lý sự cố.

Toàn bộ quá trình xây dựng thực chất là để Agent đúc kết quy trình phát triển và tự test hàng ngày của tôi, tích hợp các công cụ và năng lực phân tán lại với nhau: năng lực nào có thể công cụ hóa thì làm thành MCP hoặc CLI; quy trình nào có thể tái sử dụng thì viết thành Skill.

Việc này ở giai đoạn đầu đúng là cần bỏ ra một chút công sức, nhưng đừng ngại phiền phức. Sau khi dựng xong, nó có thể tăng tốc độ phát triển rõ rệt, giảm nguy cơ phải làm lại và phát sinh sự cố trên production, bản thân bạn cũng không phải suốt ngày lo lắng liệu code do AI viết có gây ra sự cố hay không.

Xoay quanh việc kiểm thử end-to-end thân thiện với Agent, tôi chủ yếu làm bốn việc:

1. Giúp Agent làm quen với môi trường: ví dụ như hỗ trợ khởi chạy môi trường test chỉ bằng một thao tác, tạo dữ liệu test, làm rõ phiên bản hiện tại, tài khoản và quyền hạn test, đồng thời cung cấp khả năng dọn dẹp và reset.
2. Cho phép Agent thao tác với hệ thống nghiệp vụ: thông qua trình duyệt, API hoặc CLI để thực thi các quy trình nghiệp vụ thực tế.
3. Giúp Agent thuận tiện tra cứu bảng cơ sở dữ liệu và log: thông qua MCP cơ sở dữ liệu chỉ đọc để xác nhận kết quả lưu vào DB, thông qua Skill hệ thống log và Trace để truy vấn trạng thái luồng xử lý và định vị sự cố.
4. Tái sử dụng các quy trình rườm rà nhưng ổn định: viết các thao tác ổn định thành script, tổng hợp entry point và phương pháp xử lý sự cố thành Skill, nhằm giảm bớt sự can thiệp thủ công và các hội thoại lặp đi lặp lại.

Dựa trên nền tảng những công việc này, tôi xin chia sẻ thêm vài cách làm mà hiện tại tôi thấy khá hiệu quả.

1. Tự động hóa trình duyệt: Khi hệ thống nghiệp vụ cần thao tác trên trình duyệt, tôi khá đề xuất trình duyệt mã nguồn mở ego lite. Dùng rất tiện lợi và tốc độ cũng nhanh. Kết hợp với pi agent + DeepSeek V4 Flash, bạn có thể chạy xong test tương đối nhanh, giảm bớt thời gian chờ đợi kiểm thử.
2. Đóng gói đồng nhất các thao tác thành CLI: Tích hợp các Skill tái sử dụng được, các MCP đã cấu hình và script đã viết vào một CLI test thống nhất, cung cấp các khả năng như kiểm tra môi trường, chuẩn bị dữ liệu, thực thi kịch bản, tra cứu kết quả và dọn dẹp. Điều này thực chất cũng có thể trở thành một công cụ nâng cao hiệu suất nội bộ. Hiện tại, tôi đã đóng gói toàn bộ bộ công cụ này thành CLI, bình thường khi gặp sự cố, dùng nó để troubleshoot cũng rất tiện lợi.
3. Để công cụ trực tiếp phục vụ cho việc nghiệm thu: Truy vấn DB dùng để xác nhận trạng thái, log và Trace dùng để giải thích nguyên nhân thất bại, nhưng kết quả kỳ vọng vẫn phải bắt nguồn từ hợp đồng nghiệp vụ, không thể để Agent thấy hệ thống trả về cái gì thì mặc định cái đó là đúng. Dưới logic nghiệp vụ phức tạp, hệ thống hoàn toàn có thể trả về một kết quả trông có vẻ hợp lý nhưng thực chất lại không đúng với yêu cầu. Công cụ giúp chúng ta thu thập bằng chứng, chứ không thay chúng ta định nghĩa câu trả lời chính xác.
4. Khi bản thân sản phẩm là Agent, cần kiểm tra thêm chất lượng câu trả lời: Nếu sản phẩm được test bản thân nó chính là Agent, ngoài việc quy trình nghiệp vụ có chạy thông suốt hay không, còn cần cân nhắc đến chất lượng câu trả lời. Đây chính là điều chúng ta thường gọi là Agent Eval, ở đây tôi sẽ không đi sâu chi tiết.

4. Cách Review code do AI viết

Phía trên tôi đã chia sẻ cách để AI viết ra code chất lượng cao, nhưng cuối cùng, người chịu trách nhiệm đầu tiên về yêu cầu nghiệp vụ vẫn là lập trình viên.

Nếu không Review, trong các hệ thống lớn sẽ rất dễ phát sinh sự cố.

Chắc bạn cũng không muốn nửa đêm bị dựng dậy On-call, để rồi cuối cùng phát hiện ra nguyên nhân là do code của AI viết gặp sự cố đâu nhỉ.

Đối với việc Review, hiện tại tôi có một vài kinh nghiệm thực tế sau.

1. Xem tiêu chí nghiệm thu trước, xem kết quả test sau: Trước tiên hãy kiểm tra tiêu chí nghiệm thu do Agent đưa ra, sau đó đối chiếu với kết quả kiểm thử end-to-end ở phía trước để xác nhận xem có đúng như kỳ vọng và có bỏ sót gì không. Không thể chỉ nhìn vào số lượng test pass, mà còn phải xem các bài test đó có thực sự xác thực những điểm mà yêu cầu lần này thực sự quan tâm hay không.
2. Bám theo luồng nghiệp vụ để xem phần triển khai, tập trung sức lực vào các phần có rủi ro cao: Tôi sẽ tập trung kiểm tra các phần rủi ro cao như phân quyền, biến đổi trạng thái, đồng thời, retry, tính nhất quán của dữ liệu, cũng như migration và rollback. Đối với một số CRUD có pattern ổn định, bạn có thể dành ít thời gian hơn — phần này thậm chí hiện tại tôi còn không xem nữa.
3. Kiểm tra chuyên biệt các abstraction và cơ chế mới thêm: Đối với các abstraction và cơ chế mới bổ sung, tôi sẽ áp dụng tư duy như Dao cạo Occam, để AI review lại giúp tôi một lượt: Liệu chúng có thực sự cần thiết hay không, có cách triển khai nào đơn giản hơn không, và liệu có phải vì giải quyết một vấn đề cục bộ mà đưa vào quá nhiều độ phức tạp hay không.
4. Khi có nhiều MR, hãy cân nhắc xây dựng một Review Bot chuyên dụng: Nếu trong team có lượng MR tương đối lớn, bạn có thể thiết kế một Review Bot chuyên trách để đảm nhận việc review chéo. Nó khác với việc trực tiếp gọi pi agent / Claude Code để làm review đối kháng như ở trên, mà nhấn mạnh hơn vào việc kết hợp thông tin thay đổi trong Git với quy trình review đã được thiết kế sẵn, tạo thành một bộ năng lực review có thể thực thi lặp lại và phục vụ chuyên biệt cho MR.

5. Một số tổng kết và suy nghĩ

Điểm nghẽn rõ ràng nhất trong quá trình phát triển của tôi hiện tại chính là tốc độ Review.

Agent có thể thúc đẩy nhiều nhiệm vụ cùng lúc, nhưng tốc độ tôi hiểu nghiệp vụ, đánh giá phương án và xác nhận bàn giao thì không thể tăng theo cấp số nhân như vậy được. Nếu chỉ để nó viết nhiều hơn, kết quả rất có thể chỉ là ùn ứ thêm nhiều code chờ được review.

Do đó, điều tôi muốn cải thiện tiếp theo là để các vấn đề lặp đi lặp lại được phát hiện và sửa chữa trước khi chúng được giao đến tay tôi.

Những vấn đề có thể phát hiện qua kiểm tra kiểu dữ liệu, test và assertion nghiệp vụ, hãy cố gắng để Agent tự xử lý trong quá trình phát triển; những gì cần tôi đánh giá sẽ tập trung vào việc yêu cầu đã được hiểu đúng chưa, logic nghiệp vụ then chốt có hợp lý không, và lần thay đổi này còn tiềm ẩn những rủi ro nào chưa được xác thực.

Một Review Bot chuyên dụng có thể hỗ trợ làm những việc này, nhưng giá trị của nó nằm ở việc liệu có thể giảm bớt việc bỏ sót các vấn đề thực sự và giảm tải gánh nặng thủ công hay không, chứ không thể chỉ nhìn vào số lượng comment mà nó đưa ra.

Điều này cũng giúp tôi hiểu cụ thể hơn về Harness: Ngoài việc cung cấp context chính xác cho Agent, còn cần phải cung cấp cho nó một môi trường có thể thực thi nhiệm vụ, cùng với căn cứ để đánh giá kết quả.

Tôi đã tổng hợp các thao tác lặp đi lặp lại trong quá trình tự test hàng ngày thành CLI, script và Skill, để nó có thể tự chạy hệ thống, kiểm tra kết quả và tìm ra bằng chứng khi thất bại. Sau này khi gặp các nhiệm vụ tương tự, những năng lực này có thể tiếp tục được sử dụng, và cũng có thể dần dần chuyển giao cho các thành viên khác trong team tái sử dụng.

Đồng thời, workflow này cũng cần phải được tinh giản định kỳ.

Một số bước vốn sinh ra để bù đắp cho điểm yếu của một thế hệ model nào đó. Khi model thay đổi, chúng ta nên đánh giá lại xem các bước đó còn mang lại lợi ích hay không. Nhiệm vụ đơn giản thì làm trực tiếp, nhiệm vụ phức tạp mới bổ sung thêm việc lập kế hoạch, phân rã và review chéo. Ví dụ sau khi Astra cập nhật, tôi đã xóa bớt một số ràng buộc quá khắt khe trong AGENTS.md. Model liên tục cải tiến, workflow của chúng ta cũng cần phải cải tiến theo.

Tất nhiên, việc test và Review có thể giảm bớt sự không chắc chắn, nhưng vẫn cần con người đưa ra tiêu chí nghiệm thu chính xác. Ngay cả khi code và test khớp nhau, vẫn có khả năng cả hai đang cùng hiểu sai yêu cầu. Kiểm thử end-to-end cũng chỉ bao quát được các hành vi trong môi trường và kịch bản đã chọn; traffic, tính đồng thời và phân phối dữ liệu trong môi trường production vẫn có thể kéo theo những vấn đề mới.

Đối với một lập trình viên mới đi làm chưa lâu như tôi, tôi vẫn rất mong muốn học hỏi thêm nhiều kiến thức chuyên môn trong ngành qua công việc. Dù vậy, AI quả thực cũng đã làm giảm bớt một phần cơ hội tự mình trải nghiệm va vấp. Có những kinh nghiệm quý báu vốn dĩ phải đích thân trải qua sự cố, điều tra nguyên nhân mới đúc kết được, thì giờ đây có thể chỉ còn lại một câu của AI:

"Tôi sai rồi, giờ tôi sửa ngay đây."

Vì vậy,

Hiện tại, tôi cũng trích một phần thời gian phát triển mỗi ngày để học tập và review lại, đồng thời suy ngẫm: Trong kỷ nguyên AI, năng lực mà các bạn kỹ sư phát triển thực sự cần là gì.

Những gì bài viết này ghi lại là một bộ phương pháp mà tôi đã dần tìm tòi, đúc rút được trong mảng nghiệp vụ của mình suốt mấy tháng kể từ khi vào công ty. Về phạm vi áp dụng cũng như những điểm còn thiếu sót của nó, tôi vẫn đang tiếp tục tìm hiểu thêm.

Mọi người có thể chọn trước một luồng tự test mà mình hay làm nhất, thử để Agent chạy thông suốt một cách độc lập và lưu lại bằng chứng, rồi đúc kết các bước hiệu quả lại.

Do yêu cầu bảo mật của công ty, nhiều chi tiết không thể trình bày sâu hơn trong bài viết. Hy vọng bài viết này có thể gợi mở đôi điều, và tôi cũng rất muốn lắng nghe những kinh nghiệm hay của mọi người trong quá trình phát triển thực tế~

Học tương tác với AI (NotebookLM)

Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.

Mở không gian học tương tác