docs: 新增 Claude Code 使用指南与 Codex 最佳实践指南

新增两篇 AI 编程工具深度指南文章，并更新侧边栏配置和索引页。
同步修订 Agent Skills、Workflow Graph Loop、RAG 向量存储等已有文章。

Author: Snailclimb

docs/.vuepress/sidebar/ai.ts

@@ -60,6 +60,14 @@ export const ai = arraySidebar([
         text: "Claude Code 接入第三方模型实战",
         link: "cc-glm5.1",
       },
+      {
+        text: "Claude Code 使用指南",
+        link: "claudecode-tips",
+      },
+      {
+        text: "OpenAI Codex 最佳实践指南",
+        link: "codex-best-practices",
+      },
     ],
   },
 ]);

docs/ai/README.md

@@ -124,6 +124,8 @@ AI 编程工具正在深刻改变开发者的工作方式。在面试中，你
 - [《IDEA 搭配 Qoder 插件实战》](./ai-coding/idea-qoder-plugin.md)：从接口优化到代码重构，展示如何在 JetBrains IDE 中利用 AI 完成从分析到落地的完整闭环
 - [《Trae + MiniMax 多场景实战》](./ai-coding/trae-m2.7.md)：使用 Trae IDE 接入 MiniMax 大模型，通过 Redis 故障排查和跨语言重构场景，分享 AI 辅助编程的实战经验与踩坑心得
 - [《Claude Code 接入第三方模型实战》](./ai-coding/cc-glm5.1.md)：通过 Claude Code 接入 GLM-5.1，完成 JVM 智能诊断助手搭建和百万级数据量慢查询治理，分享 AI 辅助编程的工作方法与踩坑经验
+- [《Claude Code 使用指南》](./ai-coding/claudecode-tips.md)：整理自 Anthropic 官方技术文档并融合实战经验，系统梳理 Claude Code 的配置、能力扩展、高效工作流与进阶技巧
+- [《OpenAI Codex 最佳实践指南》](./ai-coding/codex-best-practices.md)：综合官方文档与实战经验，系统梳理 Codex 云端智能体和 CLI 的提示工程、工具配置与安全策略
 
 ## 文章列表
 
@@ -151,6 +153,8 @@ AI 编程工具正在深刻改变开发者的工作方式。在面试中，你
 - [IDEA + Qoder 插件多场景实战：接口优化与代码重构](./ai-coding/idea-qoder-plugin.md) - 通过深分页优化、祖传代码重构两个真实案例，展示 AI 辅助编程的实战效果
 - [Trae + MiniMax 多场景实战：Redis 故障排查与跨语言重构](./ai-coding/trae-m2.7.md) - 使用 Trae IDE 接入 MiniMax 大模型，通过 Redis 故障排查和跨语言重构场景，分享 AI 辅助编程的实战经验
 - [Claude Code 接入第三方模型实战：JVM 智能诊断与慢查询治理](./ai-coding/cc-glm5.1.md) - 通过 Claude Code 接入 GLM-5.1，完成 JVM 智能诊断助手搭建和百万级数据量慢查询治理
+- [Claude Code 使用指南：配置、工作流与进阶技巧](./ai-coding/claudecode-tips.md) - 整理自 Anthropic 官方技术文档并融合实战经验，系统梳理 Claude Code 的使用技巧
+- [OpenAI Codex 最佳实践指南：提示工程、工具配置与安全策略](./ai-coding/codex-best-practices.md) - 综合官方文档与实战经验，系统梳理 Codex 的最佳实践
 
 ## 配图预览
 

docs/ai/agent/skills.md

@@ -13,7 +13,7 @@ head:
 
 但真正上手做项目后，这些想法很快会被现实打脸。LLM 的输出天然不确定，单次生成往往不达标，工具调用随时可能失败，上下文窗口还有硬上限。你需要的不是“跑一遍就完事”的线性流程，而是一套能**动态决策、自动修正、可控收敛**的执行机制。
 
-今天这篇文章就来梳理 AI 工作流中三个核心概念——**Workflow、Graph、Loop**，帮你建立从概念到实现的完整认知。本文约 1w 字，建议收藏，通过本文你将搞懂：
+今天这篇文章就来梳理 AI 工作流中三个核心概念——**Workflow、Graph、Loop**，帮你建立从概念到实现的完整认知。本文约 1.9w 字，建议收藏，通过本文你将搞懂：
 
 1. **为什么 AI 系统需要工作流**：单轮对话和固定流程为什么不够用？动态决策、自动修正、可控收敛分别解决什么问题？
 2. ⭐ **Workflow、Graph、Loop 三者的层次关系**：Workflow 是目标与过程，Graph 是结构与载体，Loop 是图上的控制模式——三者如何协作？
@@ -22,7 +22,7 @@ head:
 5. ⭐ **从概念到代码**：Spring AI Alibaba 和 LangGraph 的概念映射表 + 完整的“生成→审核→修改”工作流代码实现。
 6. **工作流设计的分水岭**：高抽象 vs 低抽象，Node、Edge、State 的抽象原则。
 
-> **📌 系列阅读**：本文是 AI Agent 系列的一部分，相关文章：
+> **系列阅读**：本文是 AI Agent 系列的一部分，相关文章：
 >
 > - [AI Agent 核心概念：Agent Loop、Context Engineering、Tools 注册](https://javaguide.cn/ai/agent/agent-basis.html)
 > - [大模型提示词工程实践指南](https://javaguide.cn/ai/agent/prompt-engineering.html)
@@ -35,7 +35,7 @@ head:
 
 单轮对话虽然可以回答问题，但很难稳定地**交付结果**。在真实场景中，一个完整任务往往不仅仅是“生成答案”，还包含检索信息、调用工具、输出结构化结果、质量检查、失败重试，以及在结果不满意时进行多轮修正。这些行为本身就是系统结构的一部分，靠一段超长 Prompt 解决不了，需要一种**可分支、可循环、可观测**的执行路径。
 
-传统软件流程通常是确定性的：输入固定、步骤固定、输出相对稳定。但 LLM 的特点恰恰相反——它“能力很强，但不完全稳定”。它可能答非所问、格式错误、产生幻觉，或者在调用工具时失败。这就引出了三个核心问题：
+传统软件流程通常是确定性的：**输入固定、步骤固定、输出相对稳定**。但 LLM 的特点恰恰相反——它“能力很强，但不完全稳定”。它可能答非所问、格式错误、产生幻觉，或者在调用工具时失败。这就引出了三个核心问题：
 
 1. 下一步并不唯一，需要根据当前结果动态决策路径；
 2. 当结果不理想时，系统需要自动修正，而不是直接失败；
@@ -113,7 +113,7 @@ AI 工作流与传统工作流的关键差异在于：路径选择依赖于运
 | next_step          | String    | 控制流跳转节点（可选，部分框架如 Spring AI Alibaba 通过此字段配合条件边实现路由；其他框架如 LangGraph 通过条件边函数返回值路由，无需此字段） | 当前执行 |
 | output             | String    | 最终输出结果                                                                                                                                 | 结束     |
 
-如果只看 Node 和 Edge，我们会得到一张“能跑起来的路径图”；而把 State 一起放进来，我们才真正拥有了一张“可以在运行时做决策的图”。
+如果只看 Node 和 Edge，我们会得到一张”能跑起来的路径图”；加上 State，这张图才能在运行时做决策。
 
 总之图结构比线性结构更贴近 AI 系统的真实形态，因为很多 AI 应用的控制流本来就是图，只是早期常被临时写成 `if-else`、重试逻辑或分散在不同模块里的状态机。
 
@@ -142,7 +142,7 @@ AI 场景里，第二类通常更有代表性。因为“跑几次”往往不
 
 如果没有这些约束，Loop 很容易从“自我修正”变成“无限打转”。
 
-仍然放回文章审核的例子里，Loop 不只是“多试几次”，它是“审核结论驱动下一跳”。只有当评分未达标、且还没超过最大轮次时，流程才会从 `ReviewNode` 回到 `ReviseNode`；一旦达到阈值或触发边界条件，就应该退出并给出结果。这时我们看到的就不只是循环，而是一种可控的回溯机制。
+仍然放回文章审核的例子里，Loop 不只是“多试几次”，它是“审核结论驱动下一跳”。只有当评分未达标、且还没超过最大轮次时，流程才会从 `ReviewNode` 回到 `ReviseNode`；一旦达到阈值或触发边界条件，就应该退出并给出结果。到这里，循环已经变成了一种可控的回溯机制。
 
 ## 五、概念整合：把 Workflow、Graph、Loop 串起来
 
@@ -339,7 +339,7 @@ public static CompiledGraph buildWorkflow(ChatModel chatModel) throws GraphState
 
 ![高抽象与低抽象工作流对比](https://oss.javaguide.cn/github/javaguide/ai/workflow/abstraction-comparison.svg)
 
-上图可以看到高抽象工作流将四个判断节点抽象成一个判断节点：评估是否达标。如果使用低抽象，那么当我们需要减少/添加新的判断节点时，需要花费时间去阅读源码寻找对应的节点。好的工作流不在于步骤多少，而在于 Node、Edge、State 的抽象是否经得起复用与扩展。
+上图可以看到高抽象工作流将四个判断节点抽象成一个判断节点：评估是否达标。如果使用低抽象，那么当我们需要减少/添加新的判断节点时，需要花费时间去阅读源码寻找对应的节点。好的工作流关键看 Node、Edge、State 的抽象能否经得起复用与扩展，和步骤多少关系不大。
 
 很多初学者设计工作流时，容易把每一步都写成具体动作，例如：调用模型生成文案；检查标题长度；检查语气是否合适；判断是否需要补资料；再调用模型修改。这样做短期可用，但流程会越来越碎，复用性也很差。更成熟的方式是把流程抽象到更稳定的结构层：
 
@@ -409,7 +409,7 @@ Loop 会自然放大 token 与延迟。设计时要提前思考：
 
 ## 九、总结
 
-用这套视角看问题，工作流就不只是可视化画布上的箭头图，而是一种工程建模能力。常见演进方向包括：
+用这套视角看问题，工作流就是一种工程建模能力。常见演进方向包括：
 
 - **Agent 化**：节点从「固定脚本」变成「能自主选工具、拆子目标」的执行单元，但底层仍需要清晰的图与状态边界，否则难以观测与兜底。
 - **多智能体协作**：多个角色分工、对话或委托；与 CrewAI、LangGraph 多子图等思路一致，难点往往在**共享 State 的权限**与**冲突解决**。
@@ -421,4 +421,4 @@ Loop 会自然放大 token 与延迟。设计时要提前思考：
   - **工具调用的权限边界**：遵循最小权限原则，每个节点只能访问其任务所需的工具，高风险操作（删除、发送）需通过人机协同节点确认。
   - **输出内容安全过滤**：LLM 输出在进入下游系统（数据库、前端渲染、Shell 命令）前必须经过校验，防止注入攻击、隐私泄露和幻觉传播。
 
-  工作流框架会换代，但「图结构 + 状态 + 可控循环」这层抽象会持续存在，所以我们需要深入思考这种思想，摒弃框架思维。
+工作流框架会换代，但「图结构 + 状态 + 可控循环」这层抽象会持续存在。理解这套底层机制，比追逐具体框架更有价值。