主题
界面
前沿方向：云原生与 AI 应用开发
1. 本节定位
技术方向的选择不该靠焦虑，该靠雷达 —— 四环（采纳 / 试验 / 评估 / 暂缓）+ 每条一个「下一步动作」。
★ 本节用工具生成一份带依据与行动项的技术雷达（10 条，全部锚定本知识库的实测） ✓✓：
text
采纳（2）：容器化 + 12-Factor（S6-020 已实测）、可观测三支柱（T2-016 已有实践）
试验（3）：服务网格（S6-019 手写微型 Sidecar）、LLM 辅助编码（本仓库的 AI 协作规则）、向量检索
评估（3）：eBPF、Serverless、AI Agent 工作流
暂缓（2）：自研分布式事务框架、盲目多语言微服务
★ 每条都配「下一步动作」—— 没有动作的条目会变成谈资 ✗✓★ 工具：python -X utf8 scripts/growth/tech_radar.py ✓
2. 学习目标
- 会用四环雷达给技术方向分档 ★★★；
- 理解「采纳/试验/评估/暂缓」的判据与投入策略 ★★★；
- 能说出云原生与 AI 应用在 Java 生态的落点 ★★★；
- 知道「只在试验环投入时间」的取舍 ★★★。
3. 前置知识检查
4. 为什么需要这个知识
★ 面对新技术，两种极端都亏 ✗✓：
| 极端 | 代价 |
|---|---|
| 全都追（每个热点都学一点）✗✗ | 全是皮毛，没有一项能落地 |
| 全不碰（只守旧栈）✗✗ | 错过结构性机会（如容器化、AI 辅助） |
★★ 雷达的价值 ✓✓✓：把「要不要学」变成「在哪个环、投多少时间」 —— 个人只投「试验」环（采纳已会、评估只读、暂缓不碰）✓✓。
5. 核心概念
5.1 四环口径与投入策略 ★★★
| 环 | 含义 | 个人投入 |
|---|---|---|
| 采纳 | 已在生产使用，团队共识 | 用熟、写规范 ✓ |
| 试验 | 做 PoC，明确验证目标 | 主投入（本环才是学习区）✓✓✓ |
| 评估 | 读案例，判断是否值得试 | 只读（半天/条）✓ |
| 暂缓 | 有更好替代或时机未到 | 不碰 ✗ |
5.2 实测雷达（节选，含依据与动作）★★★
★ 试验环（最值得投时间） ✓✓✓：
text
· 服务网格（Sidecar 模式治理）
依据：S6-019 手写过微型 Sidecar（金丝雀 / 超时重试 / 熔断）
下一步：挑一个非核心服务做试点 —— 把重试与超时策略从代码下沉到代理
· LLM 辅助编码与评审
依据：本仓库已用 AI 协作完成 200+ 节课程与实验（含规则文件治理）
下一步：沉淀《AI 协作规则》—— 什么交给 AI、什么必须人审（对照 .codebuddy/rules）
· 向量检索（RAG 基础件）
依据：日志/文档检索的下一站；与 S8-008 的搜索栈相邻
下一步：用本地文档做一次最小 RAG：切分 → 嵌入 → 检索 → 引用 ✓✓★ 评估环（只读，判断趋势） ✓：
text
· eBPF 可观测性：内核级观测，与 Arthas 互补 —— 读两篇生产案例再判断 ✓
· Serverless：与容量规划目标一致，评估冷启动与成本模型 ✓
· AI Agent 工作流：把「排查三板斧」做成编排 —— **只读诊断可自动化，写操作必须人工确认** ✓✓✓★ 暂缓环（抵制诱惑同样重要） ✓✓：
text
· 自研分布式事务框架 —— 已有成熟方案（S4-023 / S6-014 四件套），把精力放在对账与幂等
· 盲目上多语言微服务 —— 每多一跳，可用性乘一次折损（S4-019 的教训）5.3 AI 应用的三个落点（Java 生态）★★★
| 落点 | 做法 | 与本知识库的衔接 |
|---|---|---|
| AI 辅助研发 ✓✓ | 编码、评审、文档、测试生成 | 本仓库的 AI 协作实践 + .codebuddy/rules 治理 ✓✓✓ |
| AI 增强应用 ✓ | 检索增强（RAG）、智能客服、内容摘要 | 依赖向量检索 + 提示词工程 ✓ |
| AI 基础设施 ⚠️ | 推理服务、网关、可观测 | 与云原生栈重合（《服务网格》、《云原生》）✓ |
★★ 一条清醒的边界 ✓✓✓：AI 擅长「生成候选」，不擅长「承担后果」 —— 涉及写操作、资金、权限的动作，必须人工确认或强校验 ✓✓（呼应 《分布式事务》 的幂等与对账思维）。
5.4 扫描与更新节奏 ★★
text
① 每季度扫一次雷达（30 分钟）：升/降/新增 ✓
② 「试验」环最多 2 项同时进行（否则都做不完）✗✓
③ 每项试验必须有**退出判据**（什么情况下判定"不适用"，然后降环）✓✓✓6. 递进示例
6.1 给一条技术写「雷达条目」
text
名称：向量检索
环：试验
依据：日志/文档检索的下一站（S8-008）
验证目标：用 500 篇本地文档做 RAG，检索命中率 ≥ 80%
退出判据：两周内跑不通检索质量 → 降为「评估」6.2 用本知识库练「AI 辅助」的边界
text
可以让 AI 做的：生成测试用例草稿、解释报错、写文档初稿 ✓✓
必须人审的：涉及数据库写操作、权限逻辑、生产配置的改动 ✗✗✗
★ 本仓库的 .codebuddy/rules 就是这份边界的落地（构建陷阱、编码约束、验证顺序）✓✓✓6.3 反例：把「学新技术」等同于「收藏文章」
text
收藏 100 篇「云原生最佳实践」✗（收藏 ≠ 学习）
正解：**一个环一条线**：选 1 项试验 → PoC → 写结论 → 降/升环 ✓✓✓7. 完整可运行工具与实测
工具：scripts/growth/tech_radar.py
运行：
powershell
python -X utf8 scripts/growth/tech_radar.py实测输出（节选）：
text
【试验】（3 项）
· 服务网格（Sidecar 模式治理）
依据：S6-019 手写过微型 Sidecar（金丝雀 / 超时重试 / 熔断）
下一步：挑一个非核心服务做试点：把重试与超时策略从代码下沉到代理
===== 共 10 项；四环口径：采纳（在用）/ 试验（PoC）/ 评估（看案例）/ 暂缓（不动）=====
★ 雷达的用法：**每一项都必须配「下一步动作」** —— 没有动作的条目会变成谈资 ✗✓
★ 对个人的用法：**只在「试验」环里投入时间**（采纳已会、评估只读、暂缓不碰）✓✓✓8. Debug 观察点
- 把你的技术清单填进四环：哪些其实该降环？（"想学"≠"该学"）✓✓；
- 给「试验」环的每项写退出判据（写不出来 = 目标不清）✓✓✓；
- 检查「暂缓」环：有没有你正在花时间的东西？（及时止损）✓✓；
- 季度复盘：过去三个月，试验环有几项真的产出了结论？✓✓
9. 常见错误
| # | 错误 | 说明 |
|---|---|---|
| 1 | 把「关注」当「学习」 ✗✗ | 收藏与阅读不算投入 ✓ |
| 2 | 同时开 5 个试验 ✗✗ | 每个都半途而废 ✓✓ |
| 3 | 没有退出判据 ✗✗ | 会无限期"研究中" ✓✓ |
| 4 | 在暂缓环上花时间 ✗ | 先问「有没有更好的替代」✓ |
| 5 | AI 能力边界不清 ✗✗✗ | 写操作必须人工确认 ✓✓ |
| 6 | 雷达半年不更新 ✗ | 季度扫一次 ✓ |
10. 动手实验
- 跑
tech_radar.py，把你的技术清单映射到四环 ✓✓✓； - 选 1 项「试验」做两周 PoC，写一页结论（升/降环）✓✓✓；
- 为你的项目写一份《AI 协作边界》：AI 可做 / 必须人审 / 禁止 ✓✓；
- 季度复盘：统计过去一季「落地了几项」✓。
验收方式：产出个人技术雷达（≥ 8 条，每条含依据与下一步），并完成至少 1 项试验的结论页。
扩展任务：把雷达里「采纳」环的条目写成团队规范文档（如日志规范、容器化清单）✓✓
11. 练习题
- 四环的含义与个人投入策略？
- 为什么「试验」环才是学习区？
- 一条雷达条目必须包含哪三部分？
- AI 应用在 Java 生态的三个落点？
- 「AI 只生成候选、不承担后果」在工程上怎么落地？
参考答案（要点）
- 采纳（用熟）/ 试验（主投入）/ 评估（只读）/ 暂缓（不碰）✓✓★
- 采纳已会、评估只读；只有试验是「做不完的 PoC」 ✓✓★
- 名称 + 依据 + 下一步动作（外加退出判据）✓✓★
- AI 辅助研发 / AI 增强应用（RAG 等）/ AI 基础设施 ✓✓★
- 写操作、资金、权限必须人工确认或强校验 ✓✓★
12. 掌握标准
- [ ] 会用四环给技术分档 ★★★；
- [ ] 每条雷达有依据与下一步 ★★★；
- [ ] 会设「试验」的退出判据 ★★★；
- [ ] 清楚 AI 的能力边界 ★★★。
13. 扩展资源
14. 下一步学习
《搜索与日志技术栈视野》 搜索与日志技术栈视野 —— 把「可观测」这条线补全。
前置知识
无，可直接开始
后续知识
暂无
进度只保存在本机浏览器，可随时清除