Nhật ký công việc cho nhiệm vụ "Phát triển và ra mắt trang web"

Tiến độ: Từ application engine đến cơ sở giải pháp kỹ thuật cho AI

Trong quá trình thiết kế tiếp theo, mô hình chung của HAIH đã được làm rõ và kiểm chứng cách thức nó thể hiện trong haih.site hiện tại, đặc biệt là trên trang /solutions.

1. Không bắt buộc phải tái sử dụng application engine

Giả thuyết cốt lõi đã trở nên cấp进 hơn: trong kỷ nguyên của các coding agent, phần lớn giá trị của một application framework/engine lớn có thể được chuyển dịch từ mã nguồn tổng quát có sẵn sang tri thức kỹ thuật có thể tái sử dụng.

Mô hình mới:

requirements
+ best practices
+ showcases
+ evidence
+ mature primitives
        ↓
   coding agent
        ↓
project-specific implementation

Tức là việc tái sử dụng vẫn tồn tại, nhưng đối tượng của nó ngày càng không phải là việc triển khai tổng quát của tầng nghiệp vụ và ứng dụng, mà là phương pháp đã được kiểm chứng để giải quyết vấn đề.

2. Ranh giới không nằm giữa "có sẵn" và "tự viết"

Không có mục tiêu viết lại PostgreSQL, OpenSSL, Sharp và các primitives chuyên biệt trưởng thành khác. Nhưng các framework tích hợp nên được đánh giá dựa trên các capabilities thực tế được sử dụng.

Ví dụ với Next.js: vấn đề không phải là tạo ra một bản sao Next.js của riêng mình, mà là xác định những tính năng nào của nó thực sự cần thiết cho dự án — routing, layouts, build, SSR/SSG, image processing, v.v. Nếu một tập hợp yêu cầu cụ thể được thực hiện rẻ hơn và minh họa rõ ràng hơn thông qua React + Vite + các primitives chuyên biệt + một chút glue code dành riêng cho dự án, thì một framework lớn không còn là bắt buộc.

Tác động chính của các coding agent: chi phí viết và bảo trì glue code chuyên biệt nhỏ đã giảm mạnh. Do đó, quy tắc cũ "không tự viết vì sẽ phải bảo trì" không còn có thể áp dụng mà không so sánh với giá của mô hình trừu tượng của bên thứ ba, lộ trình nâng cấp và các ràng buộc tương thích.

3. React — ví dụ về dependency có architectural leverage cao

Đã được làm rõ riêng rằng sự tối giản không có nghĩa là loại bỏ một cách máy móc các dependency dạng framework/library.

React phù hợp với mô hình mới: với bề mặt khái niệm tương đối nhỏ gọn, nó loại bỏ khối lượng lớn công việc tổng quát phức tạp về UI khai báo, trạng thái, bố cục và rendering, mà không áp đặt kiến trúc persistence/API/deployment của toàn bộ ứng dụng.

Tiêu chí hữu ích:

Dependency lấy đi bao nhiêu độ phức tạp hữu ích từ dự án và buộc dự án phải chấp nhận bao nhiêu độ phức tạp của kẻ khác?

Do đó, HAIH không nên tối ưu hóa dependency count. Cần phải tối ưu hóa architectural leverage và tổng mức friction.

4. /solutions đã là mầm mống của knowledge layer

Trang hiện tại haih.site/solutions thực tế đang triển khai một phần của mô hình này. Nó phân tách application, development/build, production runtime và optional deployment services, đồng thời mô tả các công nghệ thông qua các capabilities và dependency mà chúng thực hiện.

Mô hình trạng thái giải pháp đặc biệt hữu ích: In use, Optional, Configured, Connected; verification in progress, Implementation open, Future branches. Điều này cho phép coding agent thấy không chỉ giải pháp mà còn cả trạng thái độ tin cậy của tri thức về nó.

Trang này cũng để ngỏ các capabilities trong tương lai — standalone API, persistence, typed API/data contracts, identity/authorization, payments, formal solution composition — mà không ấn định trước công nghệ bắt buộc cho mọi yêu cầu.

5. Bước tiếp theo — đảo ngược danh mục giải pháp

Hiện tại /solutions chủ yếu trả lời câu hỏi: "Cái gì đang được sử dụng trong haih.site và thực hiện công việc gì?"

Cấp độ tiếp theo nên cho phép đi từ yêu cầu đến việc cấu phần các giải pháp:

Requirement
    ↓
Capabilities needed
    ↓
Trade-offs
    ↓
Solution composition
    ↓
Implementation
    ↓
Verification
    ↓
Evidence

Ví dụ: responsive images → on-demand transformation → Sharp → expensive deterministic computation → cache → Varnish/CDN/giải pháp phù hợp khác.

Điều quan trọng là showcase không bắt buộc phải quy định stack cụ thể. Agent phải có khả năng lấy kinh nghiệm kỹ thuật và thích ứng nó: ví dụ, không cài đặt Varnish nếu việc caching cần thiết đã được CDN hiện tại cung cấp.

6. Sự phát triển có thể có: machine-readable solution graph

Một hướng đi đầy hứa hẹn là mô tả solutions có thể đọc được bằng máy (machine-readable): giải pháp cung cấp những capabilities nào, yêu cầu những prerequisites nào, những verification checks nào xác nhận tính chính xác và nó tương thích về mặt cấu phần với những giải pháp nào.

Khi đó HAIH có thể không phải là một runtime framework hiện diện trong mọi dự án production, mà là một hệ thống tri thức kỹ thuật từ đó coding agent tổng hợp kiến trúc của một dự án cụ thể theo các requirements.

Công thức hiện tại của hướng đi

Không phải là "động cơ mô-đun mới", mà là hệ thống tái sử dụng kinh nghiệm kỹ thuật:

Libraries provide primitives. Cases provide engineering experience. Agents synthesize the application. Evidence verifies it.

haih.site/solutions đã có thể được coi là lớp thực tế đầu tiên của hệ thống này; các showcase nên bổ sung các chuyển đổi theo chiều dọc hoàn chỉnh từ requirement đến kết quả đã được kiểm chứng.