如果你有其他开发经验但不熟悉LLM应用，这篇文章会帮你理解这个领域的基础概念。

传统应用遵循确定性逻辑：输入 → 处理 → 输出。LLM应用引入了概率性推理，模型基于上下文和提示词做决策。这需要新的架构模式。

内容包括：

• LLM应用的基本架构
• Function Calling、RAG等能力
• LangGraph vs Pydantic AI框架对比
• 技术选型建议

转载说明

本文转载自： 微信公众号「Import AI」

原文作者： Import AI

原文链接： https://mp.weixin.qq.com/s/9OOV_phsQacXQjeUF1jVug

发布时间： 2026年3月19日

很多人以为，Claude Code 好不好用，主要取决于模型够不够强。但用久了你会发现，真正把人和人拉开差距的，往往不是模型本身，而是另一层东西：你有没有把一批高频、稳定、可复用的 skills 装进自己的工作流。

同样一个 Claude Code，有的人拿它写几个函数、改几段文案；有的人已经让它跑浏览器、查资料、整理文档、控制终端、维护测试、辅助重构。差别不只是会不会写提示词，而是有没有把外部能力接进来，让它从”会回答”变成”会做事”。

所以这篇文章不想讨论哪个模型分数更高，也不想给你堆一串目录。我只想回答一个更实际的问题：如果你在用 Claude Code，最值得优先装的 10 个 skills 到底是什么？

AI 编程工具普及，Claude Code、Cursor、Windsurf 等已成为开发者的日常工具。但也带来了问题：如何让 AI 准确理解需求并保持决策一致性？

答案是规范驱动开发（Spec-Driven Development，SDD）。

社区已涌现多款实现 SDD 理念的技能包，代表性的是 OpenSpec、Superpowers、Get Shit Done（GSD）和 Spec-Kit。

共同点：都提供了规范驱动开发能力，帮助开发者在编码前明确”要做什么”。

不同点：在设计理念、实现方式、工具支持、适用场景上各有侧重。

内容包括：

1. SDD 的理念和价值
2. 四大 SDD 技能包对比
3. 选型建议

一、现状分析

1.1 当前开发流程现状

在多数中小型开发团队中，代码质量保障流程通常如下：

开发阶段：开发人员在本地完成功能开发
自测阶段：开发人员进行功能自测，确保业务流程正常
提交阶段：直接推送到develop分支或测试环境
测试阶段：测试人员进行功能测试和环境验证
发布阶段：测试通过后发布到生产环境

一、Agentic Systems 架构概览

1.1 Workflows 主导企业应用

根据 Anthropic 官方研究，Agentic Systems 分为两大类：

graph TD
    A[Agentic Systems<br/>智能体系统] --> B[Workflows<br/>工作流 - 企业主流 80-90%场景]
    A --> C[Agents<br/>智能体 - 动态自主 10-20%场景]

    B --> B1[Prompt Chaining<br/>链式处理]
    B --> B2[Routing<br/>路由分类]
    B --> B3[Parallelization<br/>并行执行]
    B --> B4[Orchestrator-Workers<br/>编排-工作者模式]
    B --> B5[Evaluator-Optimizer<br/>评估-优化循环]

    C --> C1[Feedback Loop Agents<br/>基于环境反馈的循环智能体]

Anthropic 的观点：

“Success isn’t about making the most sophisticated system. It’s about building the right system for your needs.”
—— Anthropic, Building Effective Agents

企业应用现状：

• ✅ Workflows：解决 80-90% 企业需求，成本可控、可预测
• ⚠️ Agents：仅用于真正需要自主决策的场景（开放式问题、探索性任务）

Claude Code 完整教程：从入门到精通

本教程整合了 Claude Code 的核心功能、隐藏技巧、终端美化以及项目实战经验，助你快速掌握这款革命性的 AI 编程工具。

一、Claude Code 是什么

1.1 核心定位

Claude Code 本质上是一个运行在终端里的 AI 编程代理。你可以把它理解为：

一个懂代码的同事坐在你旁边，你说需求，他直接改文件

它能读你的项目代码、执行 shell 命令、操作 Git，甚至帮你做 Code Review。

线程池

JDK为我们提供了4种构造线程池的方式，分别是

• newFixedThreadPool
  • 固定数量的线程
• newSingleThreadExecutor
  • 只有一个线程的线程池
• newCachedThreadPool
  • 线程数量不固定，不停的创建线程，用完了以后又回收
• newScheduledThreadPool
  • 提交任务后，在指定的时间去执行

我们也可以构造自己的线程池，来实现一些我们想要的一些功能。

ThreadLocal

1
2
3
4
5
6
7

public class ThreadLocalDemo {
    public static void main(String[] args) {
        ThreadLocal<Long> requestId = new ThreadLocal<Long>();
        requestId.set(1L);
        System.out.println(requestId.get());
    }
}

ThreadLocal在并发编程里，非常常用，每个线程执行的时候，都保存一个变量的副本，每个线程自己用自己的，互不影响，经常用于保存一些上下文信息，或者请求的id之类的。

synchronized

synchronized就是加锁，一旦加锁以后，就只能当前线程访问和修改加锁的变量，其他线程只能阻塞等待，这就保证了原子性。

synchronized可以锁两种对象，一种是对某个实例对象进行加锁，一种是对类进行加锁。对类加锁，本质上也是对实例加锁，只不过是对class对象进行加锁。

如果用synchronized修饰普通方法，那就是对当前类的实例进行加锁。

AtomicInteger

AtomicInteger，可实现原子化的操作，不需要加锁，他底层是通过CAS实现的，看下使用方式