全栈学习路线：手敲 vs Agent 协作¶
最优混合路线¶
核心思路：把系统拆成三层，区分“必须自己啃透的骨架能力”和“可外包给 agent 的体力活”。
A. 必须手敲（决定你能不能独立的骨架能力）¶
这些不手敲，后面一定会卡：
- HTTP 请求链路
- 路由 → controller → service → repo/DAO → DB
- 鉴权与权限
- JWT / Session
- 刷新机制
- RBAC 最小实现
- 数据库基本功
- 建表
- 索引
- 事务
- 分页
- N+1
- 读写分离（先理解前四个）
- 错误处理与日志
- 统一 error code
- structured log
- trace id
- 部署闭环
- Dockerfile
- 环境变量
- 迁移脚本
- 最小 CI（能跑测试 + 构建）
这些是“可迁移能力”的来源：手敲一次，胜过看十次。
B. 可以交给 agent（高耗时、低价值体力活）¶
- CRUD 样板代码、DTO/类型定义批量生成
- Swagger / OpenAPI 文档生成与对齐
- 管道式配置
- lint
- format
- 基础 CI
- docker compose 模板
- 普通单元测试样板
- 但关键用例要自己补
C. Agent 先写，但你要反推（提速且不空心）¶
适合“先跑起来，再结构化吸收”的部分：
- 缓存（Redis）策略
- 过期
- 一致性方案
- 队列 / 异步任务
- BullMQ / RabbitMQ / Kafka 先选一个
- 性能与压测
- 慢查询治理
- 可观测性
- metrics
- trace
- dashboard
执行原则（实操版）¶
- 先 A 后 B/C：先把骨架能力打牢，再大量借助 agent 提速。
- Agent 产出必须过三关：能跑、可解释、可回滚。
- 每次用 agent 后都做反推：
- 这段代码解决了什么问题？
- 为什么这样设计？
- 我能不用看答案重写最小版本吗？
这套路线的目标不是“写得更快”，而是“在更快的同时，能力真的长在自己身上”。