大家好，我是双越。wangEditor 作者，前百度 滴滴 资深前端工程师，慕课网金牌讲师，PMP，前端面试派 作者。

我正致力于两个项目的开发和升级，感兴趣的可以私信我，加入项目小组。

• 划水AI Node 全栈 AIGC 知识库，包括 AI 写作、多人协同编辑。复杂业务，真实上线。


• 智语 AI Agent 智能体项目。一个智能面试官，可以优化简历、模拟面试、解答题目等。

本文总结了我最近调研和学习 SKILLS 的一些记录，帮助大家对 SKILLS 全面的学习和理解。

SKILLS 是什么

SKILLS 本质上就是组织 prompt 提示词。

不仅 SKILLS，很多包装得很复杂的 Agent 框架，剥开来看确实都在做"往 Prompt 里塞什么、怎么塞"这件事。

SKILLS 比传统 prompt 多了一个：按需注入。这样就能极大减少 token 使用量，关键是能省钱。

基于什么发展而来？

Skills 的概念来源于以下几个演进脉络：

1. Prompt Engineering 的沉淀

早期开发者发现，同样的任务，提示词写法不同，结果差异巨大。经过大量试错后，好的提示策略需要被复用和共享，Skills 就是这种沉淀的容器。

2. RAG（检索增强生成）的思路迁移

RAG 是在运行时动态注入外部知识，Skills 借鉴了这个思路——在任务执行前动态注入过程性知识（How-to），而不仅仅是事实性知识。

3. Tool Use / Function Calling 的延伸

LLM 有了调用工具的能力后，下一步自然是让 Agent 知道**"什么场景用什么工具、怎么用得好"**，这正是 Skill 要解决的事。

4. ReAct / Chain-of-Thought 框架的落地需求

ReAct 等框架让 Agent 有了规划-行动-观察的循环能力，但每个领域的规划策略不同，Skills 为不同领域提供了领域专属的推理引导。

Agent Skill = 将人类专家经验编码为 Agent 可读的操作手册，在运行时动态注入，让 Agent 像专家一样执行特定领域任务。

单一任务 Agent 使用 SKILLS 的价值

对于单一任务类型的 Agent，Skill 的核心价值——"按需选择合适的知识"——确实没有用武之地。

但 Skill 还有另一个价值维度值得考虑：知识的组织与维护，而不仅仅是"选择"。

即使是单任务 Agent，你仍然面临这些问题：

• 这个任务的最佳实践怎么沉淀？


• Prompt 写在哪、谁来维护、怎么迭代？


• 新同事怎么快速理解这个 Agent 的设计意图？

这时候 Skill 文档的形式本身是有价值的——它是对 System Prompt 的结构化管理方式，而不只是动态检索的载体。

所以

• 多任务 Agent：Skill 的动态检索能力是核心价值


• 单任务 Agent：Skill 作为动态检索机制价值有限，但作为Prompt 知识库的组织形式仍有一定工程价值

如果单任务 Agent 的 Prompt 本身也很简单：那 Skill 机制确实基本没必要引入，直接写死在 System Prompt 里最省事

看几个 SKILLS 的例子

SKILLS 怎么写，可以看看几个官方的例子。

第一，在 Claude desktop 中内置了很多 SKILLS examples ，例如这个 MCP-builder

第二，看 SKILLS 官方给出的例子 github.com/anthropics/…

例如这个是 python 处理 PDF 文档的 SKILL

第三，Vercel 推出的 react best practice skills github.com/vercel-labs…

规定了 AI 编程工具如何正确的编写 React 代码。同理，现在 vue nextjs svelte 也都有了自己的 skills

实际体验 SKILLS

在 Claude desktop 中试一试，既然它有 MCP-builder SKill 那就让它开发一个 MCP server

使用 nodejs 技术栈帮我开发一个 MCP server ，

用于在 cursor 中连接 notion ，

可以查看和搜索我在 notion 中的文档和内容。

它会主动搜索 skills ，并识别合适的 skill ，然后按照 skill 里的步骤来操作

然后就卡在了这里，我一度以为这是卡死了。结果等待了大概 10-15 分钟，终于做完了

它说明了制作的步骤，使用方法，其中带有哪些 tools ，最后可以下载代码。

如果没有 skills ，纯靠笨拙的、混在一起的 system prompt ，很难想象 AI 能如此精细的开发一个任务。

SKILLS 和 Tools

Skills 中会定义很多脚本和命令，python 脚本，js 脚本，或者 shell 命令行等。

这些代码和 skill 其他文字一样，也会作为 prompt 被传递给 LLM ，而 LLM 无法直接执行这些代码。它们需要调用 agent 相关的 tools 来执行。

Skill.md 里的 Python 脚本

        ↓

   只是文本/模板

        ↓

Agent 通过 Tool 执行

        ↓

   才真正产生结果

如果要自己开发一个 agent ，你需要自己定义执行 python 代码的 tool ，skill 中的 python 脚本才能被执行。

const executePythonTool = tool(

  async ({ code }) => {

    const tmpFile = `/tmp/script_${Date.now()}.py`;

    fs.writeFileSync(tmpFile, code);

    

    return new Promise((resolve) => {

      exec(`python3 ${tmpFile}`, (error, stdout, stderr) => {

        fs.unlinkSync(tmpFile);

        resolve(error ? `执行失败: ${stderr}` : stdout);

      });

    });

  },

  {

    name: 'execute_python',

    description: '执行 Python 脚本',

    schema: z.object({

      code: z.string().describe('要执行的 Python 代码'),

    }),

  }

);

SKILL 中的“中间数据”

例如 SKILL 中有如下描述，这里的 JSON 数据就是一个中间数据，不是最终输出。

1. 先把文档转换为一个 JSON 格式；2. 再把 JSON 格式生成 表格 。

skill 的“中间数据”一般不需要管理，会把这个描述作为 prompt 一起传递个 LLM 统一由 LLM 处理。

但如果中间数据过大，需要提供一个 write_file tool ，让 LLM 调用，写入本地/服务器的临时文件。

Skill 说"写入 /tmp/intermediate.json"

        ↓

LLM 理解这个意图，生成如下代码：

  fs.writeFileSync('/tmp/intermediate.json', JSON.stringify(data))

        ↓

LLM 调用 execute_nodejs Tool 执行这段代码

        ↓

Tool 在服务器/沙箱环境里真正创建了这个文件

SKILLS 和 RAG

RAG 本质上也是一种信息注入机制，和 Skill 类似，但目的不同：

Skill   → 注入"怎么做"（操作规范、流程）

RAG     → 注入"知识内容"（业务数据、文档库）

所以 RAG 在架构里的位置是：

用户输入

    ↓

[RAG 检索] ──→ 从知识库找相关内容 ──→ 注入 Prompt

[Skill 检索] ─→ 找对应操作规范 ────→ 注入 Prompt

    ↓

[LLM] 结合两者生成计划

    ↓

[Tool 执行]

RAG 和 Skill 是同一层次的东西，都在 LLM 推理前注入 Prompt。Skill 给方法，RAG 给数据，Tool 负责执行。

async function runAgent(userInput) {



  // Step 1: 并行检索（RAG + Skill）

  const [ragContext, skill] = await Promise.all([

    retrieveFromRAG(userInput),      // 检索业务知识

    retrieveSkill(userInput),        // 检索操作规范

  ]);



  // Step 2: 组装 Prompt

  const systemPrompt = `

你是一个智能助手。



<knowledge>

${ragContext}

</knowledge>



<skill>

${skill}

</skill>

  `;



  // Step 3: LLM 推理 + Tool 执行

  const agent = createReactAgent({ llm, tools, prompt: systemPrompt });

  return agent.invoke({ input: userInput });

}

说一个真实的例子，用户问"把我们公司 Q3 销售数据生成 Word 报告"

RAG 检索

  → 从公司文档库找到 Q3 销售数据.csv 的内容

  → 注入 Prompt："以下是相关数据：销售额 300万，同比+15%..."



Skill 检索

  → 匹配到 docx Skill

  → 注入 Prompt："生成 Word 文档请遵循以下规范：..."



LLM 结合两者

  → 知道数据内容（来自 RAG）

  → 知道怎么生成文档（来自 Skill）

  → 生成代码调用 Tool 执行

没有 RAG，LLM 不知道 Q3 数据是什么。 没有 Skill，LLM 不知道怎么规范地生成 Word。 两者缺一不可。

如何在 Agent 中实现 SKILLS 功能

SKILLS 说白了就是一堆文本，而且除了 name description 之外没有其他约定。如果你自己开发 Agent 是需要自己实现 SKILLS 功能的。

以 langChain 框架为例子，要开发 agent 实现 SKILLS 主要有如下步骤。

第一，skills 存储，可以是本地文件，可以是数据库，反正都是文本。

/skills

  /docx.md

  /text-parser.md

  /excel.md

第二，按需获取 Skill（按需动态检索），推荐使用向量检索，这样更适合配置多种 skill

const { MemoryVectorStore } = require('langchain/vectorstores/memory');

const { OpenAIEmbeddings } = require('@langchain/openai');



// 启动时把所有 Skill 索引进向量库

async function indexSkills() {

  const skills = [

    { name: 'docx', content: loadSkill('docx'), desc: '生成Word文档' },

    { name: 'excel', content: loadSkill('excel'), desc: '生成Excel表格' },

  ];

  

  const vectorStore = await MemoryVectorStore.fromTexts(

    skills.map(s => s.desc),

    skills.map(s => ({ name: s.name })),

    new OpenAIEmbeddings()

  );

  

  return vectorStore;

}



// 按需检索最相关的 Skill

async function retrieveSkill(userInput, vectorStore) {

  const results = await vectorStore.similaritySearch(userInput, 1);

  return loadSkill(results[0].metadata.name);

}

第三，把检索出来的 Skill 注入到 prompt

const { ChatPromptTemplate } = require('@langchain/core/prompts');



async function buildPromptWithSkill(userInput, skill) {

  const prompt = ChatPromptTemplate.fromMessages([

    ['system', `你是一个文档生成助手。

    

以下是你完成任务需要遵循的操作规范：

<skill>

{skill}

</skill>



请严格按照规范中的步骤和要求完成任务。`],

    ['human', '{input}']

  ]);

  

  return prompt.formatMessages({

    skill: skill,

    input: userInput

  });

}

第四，定义必要的 tools 。上文有介绍。

第五，完成 agent 串联，包括 LLM toos prompt ，这就是 agent 最基础的结构了，

const { createReactAgent } = require('langchain/agents');

const { ChatOpenAI } = require('@langchain/openai');



async function runDocumentAgent(userInput) {

  const llm = new ChatOpenAI({ model: 'gpt-4o' });

  

  // 1. 按需加载 Skill

  const skill = await retrieveSkill(userInput, vectorStore);

  

  // 2. 构建带 Skill 的 System Prompt

  const systemPrompt = `你是文档生成助手，严格遵循以下规范：

<skill>${skill}</skill>`;



  // 3. 创建带 Tool 的 Agent

  const agent = createReactAgent({

    llm,

    tools: [generateDocxTool, installDepTool],

    prompt: systemPrompt,

  });



  // 4. 执行

  const result = await agent.invoke({ input: userInput });

  return result;

}



// 调用

runDocumentAgent('把这段文字转成 Word 文档：...');

这个 agent 整体的工作流程如下：

用户输入

   ↓

[Skill 检索] ──→ 读取 .md 文件 ──→ 注入 System Prompt

   ↓

[LangChain Agent] ──→ LLM 规划步骤

   ↓

[Tool 调用循环]

   ├── install_npm_package  （环境准备）

   ├── generate_docx        （执行代码）

   └── 验证结果 / 自我修正

   ↓

返回文件路径 / 下载链接

最后

以上就是我对于 SKILLS 及其周边功能的理解，如果你有新的见解欢迎留言补充。

Hello，兄弟们，我是V哥！

最近不少粉丝私信问我：“V哥，现在这行情卷得跟麻花似的，35岁危机就在眼前，你说咱们搞IT的，到了2026年还有出路吗？这技术迭代快得像坐火箭，我到底该往哪边押注？”

V哥我就一句话：焦虑个屁！机会全是给有准备的人留着的。

你们现在看是“寒冬”，V哥我看是“洗牌”。等到2026年，IT行业的格局早就翻天覆地了。那些只会写重复代码的“代码搬运工”确实该慌，但懂趋势、会借力的兄弟，那会儿绝对是香饽饽。

今天，V哥我就掏心窝子地聊聊，2026年咱们这行的几大“风口”。特别是最后两块大肉，听进去了，你下半年的年终奖就稳了。

一、 AI智能体开发：2026年的“新物种”

兄弟们，先把“ChatGPT”这种对话机器人放一边。V哥告诉你，2026年是AI智能体爆发的一年。

啥叫智能体？现在的AI像个博学的书呆子，你问它答。而智能体，那是带着“脑子”和“手脚”的打工人。它不仅能理解你的意图，还能自己拆解任务、自己去调用工具、自己反思纠错，最后把活儿干完了给你交差。

• 现在是： 你写代码，AI帮你补全一行。


• 2026年是： 你说“帮我做个电商后台”，智能体自己写代码、自己测、自己部署、甚至自己写文档。

V哥的研判：
到了2026年，不会开发智能体的程序员，就像2010年不会用智能手机的人一样落伍。你不需要自己去造一个大模型（那是大厂的事儿），你需要做的是做中间的“Controller”（控制器）。怎么用LangChain（或者那时候更牛的框架）把大模型串起来？怎么给智能体挂载API接口？怎么设计它的“记忆”和“规划”能力？

这块儿目前还是蓝海，谁能率先把“数字员工”搞定，谁就是那个省下百万人力成本的老板眼里的红人。

二、 鸿蒙开发：国产操作系统的“成年礼”

这块儿，V哥必须得敲黑板！这可能是未来几年里，中国普通程序员最大的红利期。

别总盯着Android和iOS卷了，那是存量市场，杀得头破血流。你看华为现在的动作，HarmonyOS NEXT（纯血鸿蒙） 已经切断了对安卓代码的依赖。这意味什么？意味着这不仅仅是换个皮肤，这是一套全新的、独立的生态！

V哥的预言：
到了2026年，鸿蒙不再是手机的配角，而是全场景（手机、车机、家电、工控）的霸主。

• 技术栈： 赶紧把ArkTS（Ark TypeScript）学熟了，ArkUI这套声明式开发范式非常顺手。


• 机会在哪？ 现在市面上大量的APP都需要重构鸿蒙原生版。这中间有一个巨大的缺口！前两年进去的那批人，现在都成技术总监了。2026年，随着万物互联真正落地，鸿蒙开发者的薪资会比同级别的安卓开发高出至少30%。

V哥我一直说，技术要跟着国运走。鸿蒙这条路，不仅是写代码，更是在参与基础设施建设。这碗饭，香！

三、 后端开发：告别“CRUD”，拥抱“编排”

兄弟们，别再笑话写Java/Go的后端枯燥了。虽然简单的增删改查（CRUD）真的会被AI干掉，但后端的逻辑核心地位永远不会动摇。

2026年的后端，不再是单纯的写接口，而是做“AI时代的管家”。

以前你的服务是给前端APP用的，2026年，你的服务大部分是给上面的“AI智能体”用的。智能体需要调用你的数据库、调用你的业务逻辑。你的接口设计得更规范、更原子化、响应更快。

V哥建议：
Go语言和Rust会在后端越来越火（因为性能好、并发强）。而且，后端得懂点云原生，容器化、Service Mesh（服务网格）这些都是标配。你得学会怎么把一个庞大的系统拆得碎碎的，还能用AI把它们管得服服帖帖。

四、 前端开发：从“画页面”到“造体验”

前端死了吗？V哥告诉你，前端才刚刚开始“性感”起来。

写HTML/CSS这种活儿，2026年估计UI设计师直接说一句话，AI就生成了。那前端干嘛？前端负责“交互的灵魂”。

随着WebGPU的普及，浏览器里能跑3D大作、能跑复杂的物理引擎。鸿蒙的ArkUI也是跨端的前端技术。未来的前端，更多是图形学、人机交互和3D可视化。你打开一个网页，不再是看图文，而是进入一个虚拟空间，这背后全是前端工程师的功力。

V哥一句话： 放下jQuery，搞深Three.js，搞透React/Vue原理，往图形学和全栈方向发展。

五、 嵌入式开发：软硬件结合的“硬核浪漫”

以前搞嵌入式感觉是“修收音机的”，2026年搞嵌入式那是“造智能机器人”的。

因为上面说的鸿蒙和AI，最后都要落脚到硬件上。智能眼镜、智能家电、自动驾驶，哪个离得开嵌入式？

重点来了： 嵌入式未来会和AI深度融合，叫TinyML（微型机器学习）。在芯片上跑小型的AI模型，让摄像头能识别人脸，让传感器能听懂声音。如果你既懂C语言底层，又懂一点AI算法部署，你是各大硬件厂抢着要的“国宝”。

六、 大数据开发：从“存数据”到“喂AI”

大数据没凉，只是换了个活法。

前几年大家搞Hadoop、Spark，是为了存日志、做报表。2026年，搞大数据主要是为了给AI当“饲养员”。

AI需要高质量的数据清洗、向量化处理。这就涉及到向量数据库、数据湖、实时计算流。怎么把企业的几十亿条数据，变成AI能看懂的“知识”，这是大数据工程师的新活儿。不懂AI的数据工程师，未来路会越走越窄。

七、 AI运维与 AI测试：机器管机器

最后说说这两个容易被忽视的领域。

• AI运维： 以前服务器报警了，运维兄弟半夜爬起来看日志。2026年，AI运维系统会自动定位故障、自动修复、自动扩容。运维工程师不需要敲那么多命令了，而是负责训练这个“运维AI”，制定策略。这叫SRE（站点可靠性工程）的进化版。


• AI测试： 测试不仅是找Bug，更是“攻防演练”。用AI去生成几万条变态测试用例去轰炸你的系统，甚至用AI去对抗AI生成的代码。只有AI才能测出AI写的Bug。

V哥总结一下

兄弟们，2026年其实并不远。

V哥我看了一圈，未来的趋势就两个字：融合。

• 鸿蒙是万物互联的底座，必须要抓；


• AI智能体是提升效率的神器，必须要懂；


• 其他所有的后端、前端、嵌入式、数据，都要围绕着这两者去进化。

别再纠结Java还是Python，Go还是Rust了。语言只是工具，解决问题的思路才是王道。从今天起，试着用AI去帮你干活，试着去了解一下鸿蒙的ArkTS，试着把你的工作流程“智能化”。

等到了2026年，当别人还在为裁员瑟瑟发抖时，V哥希望看到你已经站在风口上，笑傲江湖！

我是V哥，带你不仅看懂技术，更看懂未来。

一、引言

又到了一年一度的年终复盘时刻。

复盘，从来不只是回看已经发生的事情，更重要的是——为尚未发生的未来，提前铺路、校准方向。

回望 2025 年，其实很长一段时间里，我始终没有真正找到自己的方向。工作之外，谈不上热爱，也谈不上笃定，只是在惯性中前行。

直到 2025 年的尾声，才终于看清了一些东西：哪些是必须坚持的，哪些是可以放下的，也逐渐摸索出几条更属于自己的路径。这一年，并非突然开悟，而是反复碰壁后的沉淀与取舍。

依旧按照惯例，沿着时间的轨迹，回到 2025 年的起点，梳理这一整年里的得与失、进与退，也为下一阶段的自己，留下些什么。

二、技术（AI驱动）

2025 年，是 AI 加速演进的一年。

这一年里，我写博客明显少了，最直接的原因，正是 AI 带来的冲击。曾经需要熬夜查资料、翻文档、啃源码的事情，在今天的 AI 面前显得异常高效——只需要给出合适的关键词，答案往往已经被系统性地整理好。

从宏观来看，2025 年的主旋律，几乎全部围绕着大模型基础设施展开。各大厂商持续投入巨额资金，用于模型规模、算力和训练能力的迭代升级。但与之形成鲜明对比的是：​大模型的应用落地，依然是一个尚未被彻底解决的问题​。

这就像高速公路已经修好，但真正决定胜负的，是谁家的车最先跑起来、跑得最稳。

基于这一判断，我越来越坚定地认为：2026 年的主旋律，一定是 AI 的落地与应用。

对技术人而言，未来不再只是把业务“做深做熟”，而是在既有业务基础上，思考如何与大模型更好地结合、适配、放大价值——这或许才是更长远的终局。

纯业务型技术路线，势必会遭遇一定冲击。原因并不复杂：当业务格局趋于稳定，公司往往不会再在传统方向上投入重资产。努力当然重要，但在技术浪潮面前，​方向的优先级，永远高于努力本身​。风口之上，选择往往比埋头苦干更关键。

坦白说，我曾长期对 AI 保持距离。并非否定它的价值，而是因为它太新——标准未定、路径未明、变量太多。这种不确定性，本能地让人抗拒。

真正的转折，来自一次和老板的绩效沟通。在 AI 飞速演进的节点，如果只是站在一旁观望，等别人把位置站稳、红利吃完，再回头跟进，我们注定只能咀嚼别人剩下的成果，且永远慢一步。

从那次谈话之后，我逐渐接受了一个事实：AI 不是选修，而是必须正视的方向。

客观来说，2025 年我并没有系统性地学习太多 AI 知识。但我也越来越确信，学习本身并不是最难的事，真正重要的，是先选对方向。

立下 2026 年的第一个 Flag：持续系统性地学习 AI，构建完整的技术体系，至少让自己始终站在行业前列。

三、工作（Agent/晋升）

2025 年，几乎可以被视为 ​Agent 的元年​。

对风控工程师而言，这是一个难得的历史窗口期。大模型天然擅长图文理解，而内容风控的核心风险，恰恰集中在图文与多模态层面，二者之间的契合度，几乎是为内容风控量身定做。

在过去一年里，我们更多是在​夯实底层能力​：包括大模型与小模型的协同、向量检索体系、敏感词与规则匹配等基础设施建设。而今年，则顺应技术演进的方向，在此之上，开始系统性地推进​内容风控 Agent 的建设​。

从系统设计角度看，传统架构往往以同步模式为主。但在大模型时代，推理延迟不可避免地成为整体架构的瓶颈，在高 QPS 场景下，单纯依赖同步调用已难以支撑规模化落地。因此，架构形态也不得不随之演进，从同步模式逐步向异步化、任务化转变。

不过，相比架构调整，Agent 本身长期存在的两个核心问题更加关键：幻觉问题与​成本问题​。

对于幻觉问题，业界较为成熟的做法，是通过 Workflow 对大模型的行为路径进行约束，让其在预设的流程和边界内完成推理，从而降低不确定性。

而成本问题则更具挑战性。目前主流思路可以拆解为两个方向：一是降低大模型​​的调用频次​，二是​降低单次调用成本​。前者往往引入搜广推体系中的粗排 / 精排架构，由小模型或规则先行过滤，仅将必要样本交由大模型处理；后者则更多依赖自建推理服务，通过部署开源模型（如千问、DeepSeek 等）来降低整体成本。

更进一步来看，自建模型还有一个明显优势：当前开源模型大多是通用基模，而真实业务更需要的是​领域大模型​。这也意味着，必须通过微调、蒸馏等手段，构建并持续演进真正贴合业务的模型体系。

整体来看，这一阶段的工作，相比传统开发，多了更多的不确定性，但也因此更具挑战性和成长空间，是真正与 AI 深度接轨的一段经历。

也幸运地得到了老板的认可，拿到了来之不易的晋升名额，完成了职业生涯中的第二次晋升——上一次是在上一家公司。回头看，确实有运气成分，也更需要珍惜。

立下新年的第二个 Flag：2026 年，持续精进 Agent 架构能力，从整体设计到细节实现全面吃透，建立真正的体系化掌控力，同时对自己保持足够严格的技术要求，始终心存技术敬畏。

四、健康（运动/旅游）

又到了这个多少有些老生常谈的栏目。

坦率地说，2025 年的运动状态可以用全面崩盘来形容。不仅没有瘦下来，反而稳步增重，这一项只能毫不留情地给自己打一个最低分，甚至有点不忍直视。唯一能做的，大概只能把希望寄托在 2026 年，重新做人。

相比之下，生活并非全然失守。这一年，还是走了不少地方。公司团建去了昆明、大理，看到了心心念念的洱海；个人也陆续去了深圳、香港、天津、北戴河、南京等城市，在不同的节奏里切换视角，多少算是给自己留了一些喘息的空间。

也期待明年能继续把“在路上”这件事延续下去——更重要的是，明年对象终于有年假了。

立下新年的第三个 Flag：坚持运动，至少别再继续发胖；同时走进几个尚未抵达过的城市，让生活保持一点新的变量。

五、家庭（买房/订婚）

去年看过的房子，最终还是和对象商量后定了下来。位置在县城里算是比较成熟的小区，四面都有学校，整体价格也在可承受范围内。房贷已经还了一年，对日常生活的影响并不大。

唯一的遗憾是交付时间要到 2027 年，目前仍在建设中。不过好在并不着急，慢一点也无妨。地理位置也和去年设想的一样——我和亲姐选择了同一个小区、同一个单元、上下楼，只需要一分钟，就能“传送”到她家蹭饭。考虑到我和对象都不太擅长做饭，这个选择现在看起来，格外明智。

另一件重要的事情，是订婚。和对象谈了七年恋爱，最终还是给了彼此一个相对笃定、也让双方家庭都满意的答案。整个过程比预想中顺利得多，几乎没有在流程或观念上产生大的分歧。订婚前和订婚后，心态确实发生了一些变化——一种更明确的“我们已经是一家人了”的心理确认。

当然，现实层面仍然存在异地的问题。对象在老家县医院工作，我则在北京从事互联网相关工作。所幸的是，老家县城今年将开通直达北京的高铁，往返的成本和难度都会降低，这也算是一个不小的利好。

整体来看，家庭这一块在 2025 年算是比较稳定的一年，没有突发的波折，一切都在预期内向前推进。

立下新年的第三个 Flag：家庭层面继续顺其自然、稳步发展；如果房子能提前交付，也不排除提前去拍个婚纱照——不强制，慢慢来。

六、投资（美股/港股/A股）

2025 年，也算是我个人投资生涯的起点。

在长桥关门前开通了账户，在汇丰调整政策前办好了银彳亍卡，时间点刚好卡在一个“来得及”的窗口期。12 月份正式进入美股市场后，才真正意识到：投资这件事，本身就像一门需要长期修炼的技术。

这一阶段，最大的收获并不在于盈亏，而是对投资这件事的​认知重构​。至少有几件事，是必须补上的基础能力。

第一，是​仓位控制​。如何在不踏空的前提下，避免一次性打光子弹，是非常难的一件事。仓位过低，行情来了只能旁观；仓位过高，下跌时却失去补仓空间。合理的仓位，本质上是为了​尽可能长时间地留在牌桌上​。

第二，是​买卖策略​。不同股票对应不同策略：有的适合长期持有，有的更偏交易属性。对陌生标的，更需要分批建仓，区分观察仓、交易仓与核心仓，而不是一次性下注。

第三，是​情绪管理​。这一点的冲击远超预期。下跌时容易冲动补仓，情绪持续低落；上涨时又容易过度乐观，放松纪律。回头看，绝大多数错误操作，都不是判断失误，而是典型的“情绪杀”。

第四，是​交易复盘​。 每一笔交易都值得被复盘：究竟是基于清晰逻辑做出的决策，还是随市场情绪跟风的结果。如果连自己为什么买、为什么卖都说不清楚，那么这笔交易本身就是不合格的。

事实上，这些问题最终都可以归结为一个核心：是否拥有一套成熟、可执行、可复盘的交易系统。

只有在系统的约束下交易，才能尽可能屏蔽情绪干扰，让结果更多由概率而非情绪决定。

某种程度上，这和前面提到的技术路径并无本质区别——就像 2026 年是 Agent 的关键一年一样，投资领域同样需要系统化思维。在美股市场中，也有不少值得长期观察的优质标的，新的一年，我会重点关注：​谷歌、英伟达、台积电、特斯拉​。

立下新年的第四个 Flag：建立并持续迭代属于自己的交易系统，在控制风险的前提下，争取 2026 年实现 10% 的年度收益目标。

七、总结

2025 年过得很快，一转眼就到了年末。回头算了一下，自己已经毕业四年半了。

还记得刚毕业的时候，对周围的一切都充满好奇，对技术保持着最纯粹的热情。那时知道的不多，需要承担的事情也不多，反而简单、专注，也更容易感到快乐。

随着年龄和阅历的增长，不得不考虑的事情越来越多，责任与压力也随之而来，这是成长过程中无法回避的一部分。

回看从毕业到现在的这几年，多少还是带着一些运气。整体来看，很少在关键节点上做出错误选择，生活与事业也在持续向更好的方向推进。正因如此，也愈发珍惜当下所拥有的一切。

但运气从来不是全部。对我而言，更重要的是始终保持一种行动上的自觉—想到就去做，决定了方向，就尽力把事情做成。

接下来，也对 2025 年年初立下的 Flag 做一次完整复盘，给自己这一年的选择与投入，留下一份相对坦诚的答案。

回到终点，再看起点，会发现很多事情并非一蹴而就，而是在一次次选择中逐渐变得清晰。

这一年，没有奇迹，也没有偏航。有的，只是在关键问题上站对方向，在重要事情上持续投入。

花有重开日，人无再少年。2026，让我们顶峰相见。

如果你也对 后端架构 和 中间件源码 感兴趣，欢迎添加博主微信：​hls1793929520​，一起学习，一起成长。

我是 ​爱敲代码的小黄，​阿里巴巴 Java 开发工程师，CSDN 博客专家，专注后端架构与中间件源码。

我从清晨走过，也拥抱夜晚的星辰。人生没有捷径，你我皆平凡。你好，陌生人，一起共勉。

引言

「2025」 年就这么稀里糊涂的过去咯, 前不久正巧听到这期播客 《请收下这枚记录 2025 年的声音时光胶囊》 不禁感慨, 于世界而言「2025」这一年属实精彩:

• 年初的 Deepseek、宇树机器人爆火


• 特朗普上台后各种折腾, 关税战一度引起全球股市暴跌, 而最后又好像啥也没发生一样


• 后面泡泡马特爆火、小红书出圈...


• 之后又有雷军塌房、西贝塌房、俞敏洪塌房...


• 再之后又是美团、京东、淘宝三方外卖大战...


• 最后高德闭关整了个用脚投票, 最后好像也没声了


• 然后就是各大厂商的 AI 争夺战了


• ...

然而这一切又和我有啥关系, 各种风口并没有让我踩到, AI 的出现也只会让我更难找到合适的工作, 2025 我依然过得平庸, 比起 2024 也没啥起色....

而 2026, 我的生活大概率还是不会有起色? 谁知道呢? 随便吧....

一、无业游民这半年

从去年九月份被裁后就一直在 GAP, 属实没想到这一 GAP 就 GAP 了近一年....

不幸的 2024 又是失业又是车祸, 所以年初一直在处理工伤的事; 从劳动能力鉴定、出劳动能力鉴定结果、提交工伤赔偿申请到最后 💰 到账。折腾了三四个月, 跑了好几次社保局, 捡钱好像也没那么容易

当然最后结果是好的, 小赚了一笔。 钱到账前还计划着出去奢侈一把, 到账后还是不舍得花钱, 还是老老实实存着吧....

上半年除了折腾工伤这事, 其余时间就是准备面试咯, 这期间还尝试写日记、做 TODO...

然鹅并没有什么用, 回头过了下上半年写的内容, 每天写的最多的就是:

• 去健身房


• 煮饭


• 没有面试机会


• 焦虑


• 今天又啥都没干


• ....

是的失业这半年基本上也没干啥, 有面试机会就面试, 没有就宅家里和 “自律” 抗争...

最后自然也不会有出乎意料的结果, 破罐子破摔罢了。最后入职了一家外包公司, 主要是看给的薪资也还行就去了

二、 外包这半年

人生第一次外包工作, 好像也没想象🤔中那么差

有免费的零食吃、无限自助咖啡, 偶尔一天干它个三杯 😂)。过节也有各种礼盒、去了半年 T 恤、衣服、帽子、鼠标垫都不知道领了多少个了, 同时外包公司过节偶尔也有礼盒, 这过一次节领双份礼盒了都 👍

对了, 还有免费的早中晚餐。刚开始去还自己带饭, 后面杭州这边可以集体点餐了, 自此三餐就全包咯。晚餐不吃, 就带回去给对象, 第二天她带去公司当午饭吃, 一家人全靠公司养活了

唯一不好的就是得加班, 每天得 8.30 下班, 这样就更不想去健身了。下班到家都 9 点了, 如果去健身那么到家都得 10 点多了。不对, 还有就是没有年假, 这坑爹的外包公司必须入职满一年才给年假....

没有绩效压力, 纯牛马好像过得也挺爽的, 运气好的是还有机会接触到 Agent 相关的工作(虽然只是边缘的对接工作)

二、好好生活

2.1 见家长

人生进程 +1: 51 去了对象老家, 10 月份趁着周末带对象也回了趟我的老家, 一切都还挺顺利的。实际上好像也没想象中那么紧张, 在对象老家这一待就待了 5 天, 每天就是吃吃喝喝...

2.2 旅游

上半年一直忙着工伤和工作的事, 下半年也一直在上班, 所以这一年也没去几个地方。

五月份大学舍长结婚, 就和对象一起去了趟福建, 之后就顺便就绕道去厦门玩了几天。厦门不错, 就是物价忒贵了, 如果去鼓浪屿千万自带吃食, 要不然就等着被宰吧。住的酒店就挺不错的, 服务周到、还有个大天台...

之后就是十月份, 去了心心念念的重庆。不愧是山城啊, 有被惊到, 刚去就按错电梯了 🐶。和美食荒漠的杭州相比, 那重庆简直是美食天堂了吧。可惜了, 上了年纪了真真感觉没以前能吃了, 一吃多肚子就难受得很....

再之后又去了趟桐庐, 当然主要目的是对象在支付宝上白嫖了医美项目(只有那边能预约到), 顺带着就想着溜达溜达。景点就去了「石舍村」, 主要是淡季很多景点都闭园修整了, 在富春江溜达了两天就溜了, 江边一路风景倒是挺不错的。

2.3 健康

是不是人一到 30 往后, 身体毛病就开始多起来了。 上半年差点不能入职了, 主要就是体检「心电图」有点异常, 吓坏了都。后面第二天又跑医院重新做了一次, 还是有一点点「异常」又补了其他检查, 最后没发现问题, 让医生开了个证明, 才顺利入职。

可能是那几天生活作息不良引起的「心电图」波动, 但是那时才感觉真的老咯, 以前可不这样。并且还检查出血压偏高, 当然我血压偏高这事其实早就知道, 只是一直不重视而已。这次检查医生说我的一个心房好像偏大, 问是不是血压高, 我说是的, 然后就建议我吃药、减肥...

好咯, 谨遵医嘱。 现在就是每天食用降压药, 还给自己安排上了血压仪。

后面就开始尝试减肥了, 到目前为止已瘦 20 斤吧。大部分都是前面几个月减下来的, 主要最开始上班都是自己带饭, 做的也干净(基本水煮), 所以瘦得还挺快的。

后面公司有免费的早中晚餐, 就放弃自己带饭咯。 慢慢的就反弹了点, 人啊一破防就容易破罐子破摔, 现在也不关注体重了, 现在估计又反弹不少....

2.4 理财

今年大家都回本了吧 🐶。 毕竟今年大 A 表现这么好, 再不回本也太说不过去了。

今年我也可算回本了, 感谢大 A 🙇。往年我的理财账户是另一个支付宝, 只为了眼不见为净毕竟亏了那么多。今年做了个改变:

• 将所有基金都转托管到常用的那个支付宝上


• 追求稳健、分散, 并卖掉亏损大的


• 大仓位放在债劵、固收、红利上


• 还配置了点纳指


• 最后只有一小部分放在科技上

这种做法是稳, 但注定不能赚太多。在今年行情这么好的情况下, 今年收益也就 8.25% 远远跑输大盘。慢慢来吧, 起码今年的收益可以把我一年的房租给 cover 掉, 还是挺满意的。

今年半场还进了股市, 折腾了大半年, 小赚 400 大洋 😆。小资金, 玩得不亦说乎....

今年黄金、白银也有点给力。黄金入场了, 可惜中场没拿住卖了, 后面又进场, 少赚了(虽然也没买多少)。后面白银出现套利的机会, 没整明白就瞎炒作, 导致耽误了好几天, 少套利了不少。我对象场外买了不少, 也因此错过了最高点(就差那么一天), 可惜了...

2.5 其他

七月份大热天搬了个家, 在这小区已经换了三个窝了, 第一个主要是楼上太吵了, 第二个就是有点贵外加顶楼夏天实在是热得不行。

这一个也不知道能坚持多久呢, 主要问题就是二房东总是要房东催好几次才肯给他房租, 房东都找上我了让我催二房东给钱, 还说明年不租给他了 😭

双十二对象整了个烘干机, 那是真后悔没早点整, 简直太香了。特别是对我这种租房党, 晚上洗个衣服, 白天出门上班前把衣服丢烘干机就完事咯。主要还能收集灰尘和毛絮, 烘出来的衣服看起来就和新买的一样。强力推荐, 免去晒衣服的烦扰, 而且这样常年也只需要买 2~3 套衣服就行 🐶

两个崽: 妹妹越吃越胖、就像头猪; 姐姐倒是自律得很, 这一年身材管理起码比我好太多了, 没胖没瘦一切如旧。年初二狗子还了场病, 一直流鼻涕(怀疑是鼻炎), 被整的够呛的。还担心今年冬天会不会复发, 现在看着应该不会了吧, 对了这家伙年初应该还被俺们给噶了。

一年 365 天, 说长不长说短不短

翻翻照片总会有些收获的...

三、工作与成长

3.1 工作

新的工作, 工作难度一般吧, 反正轻松驾驭! 就是整体会更难? 或者说是更乱, 工期赶加上一群外包一起开发的项目, 虽然说有正式员工在把控, 但是项目质量也很难起来。正式员工也只是参与初期的项目开发, 后面的维护基本也就不管了, 毕竟只有新项目、新玩意才能出绩效。

但总的来说还是有点新东西可以学到, 毕竟不同的团队他们的开发习惯、开发范式都是不同的。总是能看到一些新玩意, 即便有些玩意个人也不太喜欢, 但是也是可以玩一玩的。

后面也有幸参与了 vscode 插件相关工作, 这里也涉及到 Agent, 虽然只是一些简单的对接工作, 但是我可以接触到 Agent 代码呀。明年一大目标就是好好研究研究大佬们写的代码, 应该是会有所收获的吧。

这大半年工作唯一的感受就是, 太多工作都没啥意义, 都是用一群人内卷换来一小撮人的自嗨罢了。但是又能咋样, 牛马嘛给钱就干。先把钱赚到了再说。

3.2 读书 & 播客

今年相比去年阅读量少了些, 当然去年其实也没读多少书。书嘛, 都是随便瞎看的, 看过了 26 本书, 但真正看完的也就 10 本。本着先培养习惯的目的, 所以很多书看几眼不感兴趣也就不会强迫自己去读。也不会抱着太强的目的去看书, 也不要求一定会有啥收获。

今年还入坑了博客, 平常做家务、坐地铁、撸铁、上班... 无聊时就会听听博客。大部分都是财经类的、科技类的, 再则就是几个脱口秀平台。

3.3 开源? 独立作品

今年 小绿点还行, 出乎意料的多....

今年主要新开了两个坑, 当然也都没有填上:

• 智账: 一个记账的 APP, 为此还去研究了下 React Native 还输出了五篇博客, 整了个专栏, 实际上连项目都还没搭建起来, 就研究了下 React Native


• writeflow: 基于 prosemirror 写的一个富文本编辑器吧, 整体架构主要参考 Tiptap 全当是学习了。之所以要写这么一个东西一为折腾, 二是 昆仑虚 中文章编辑器用的是代码编辑器, 不是很方便想要换成富文本编辑器。

其他的, 昆仑虚 今年应该也做了些调整, 没做记录也不知道改了啥, 也懒得查了, 就这样吧....

3.4 写文 & 视频

今天拢共就写了 11 篇文章, 主要还是发布在掘金、公众号上, 掘金上整体数据也就一般般吧。大部分都是上半年失业时闲得无聊写的, 下半年基本就荒废了, 毕竟当牛马的日子那么累, 谁还写文章啊 🐶

今年公众号粉丝从 830 到 1394 涨了 500 多吧, 主要也都是上半年涨的, 下半年也都没怎么更新了。

对了, 油管、B 站还发了一期视频, 配套文章 还原 Mac Dock 栏动效: 一步步打造流畅的波形缩放动画

内容创作收入: 掘金金石 300+、公众号累计收入 47

四、展望 2026

照例, 定定 2026 目标, 至于能不能实现另说....

• 好好生活
  
  
  
  
  • 身材管理(减肥、撸铁): 撸铁每周四次(下雨可以不去)、体重维持在 80~82 (目前 2025.12.31 体重 90)
  
  
  • 吃喝玩乐: 好好吃饭(不吃饱)、养生(少喝饮料)、多出去逛逛(去次新疆或韩国)
  
  
  • 财务理财: 保护钱袋子、稳定理财(别浪)
  
  
  • 人生体验: 整个人生第一辆小车(10w 左右)、人生大事安排起来、学习打网球
  
  
  
  


• 工作与成长
  
  
  
  
  • 保住饭碗: 简历常更新(6月、12月)、保持学习
  
  
  • 通过软考: 为了 E 类人才、为了买车
  
  
  • AI 学习: 把公司 Agent 那一套研究明白、侧重应用端、AI Coding 技巧掌握
  
  
  • 算法学习
  
  
  • 多输出: 写文(每月 2 篇)、公众号(每月 2 篇)、视频(每月 1 个)
  
  
  • 独立作品: 昆仑虚(增加两个 APP、开放注册)、智帐(完成开发)
  
  
  
  


• 习惯养成:
  
  
  
  
  • 坚持写日记、做月度总结、季度总结
  
  
  • 阅读: 每天 30 分钟, 微信读书打卡
  
  
  • 早起(给自己找个活干)
  
  
  
  

选择大于努力

友友们，我是卷福同学，上次写2024年终总结的时候还在武汉，谁能想到一年之后会在上海写2025的年终总结。今年下半年经历的事情比较多，总结来说就是，人生经历又丰富了

1.再次选择

去一线大城市闯荡人生还是留在武汉岁月静好呢？

1月

1月时候还在武汉国企里呢，彼时因为项目变少了，武汉人员要重新分配，没分到项目组的人要进资源池等候下一步安排。而我这个小组之前武汉是有2个人的，北京1个项目经理，给我分配了半个人的工时，另一个人直接让去资源池。关于这个项目经理，去年也写过吐槽的帖子。这个人在武汉的名声非常不好，就完全是对待牛马一样对待底下干活的人。

我想着以后的日子可能过得更难受，还不如直接进资源池算了。于是就和他说了，他倒也爽快，想着再从武汉随便捞个人进来呗，反正还有很多人没安排项目组的。没想到的是，他接连找了两个人，但是因为武汉的人都听说过他的名号，都表示不想去他的项目组。最后，他把项目给外包人员做了。武汉的人，宁愿待池子里，也不想跟着他干。。。

这让我想起以前上小学的时候，以前农村小学的老师，打学生都很厉害的。而打的原因不仅仅是因为调皮捣蛋，我那个班教数学的老师，就是其中打人最厉害的。上课的讲台两边会有两个座位嘛，每次她讲课的时候，都会从这两个座位的学生手里拿课后作业讲，要是讲的时候发现写错了，直接冲过去打头，提耳朵等等。有一次因为班上写错作业的人太多了，直接一节课没上，轮流上去扎马步。而我呢，又恰巧有一学期是坐在讲台旁边的座位，于是这学期每逢她的课必挨打，打到后面，居然在课上说，卷福坐在这，已经被我打肿了，你们再敢做错题试试。到第二学期开学的时候，大家选座位直接把前面两个位置空着了，有两个人宁愿在后面站着也不坐那位置。

我感觉是不是历史又一次重演了呢？

现在回头看，当时没继续跟着他的选择是对的。在武汉，也没有岁月静好啊。

再次选择

虽然5月份的时候拿了上海的offer，但是等真的要走的时候，还是会纠结的。就和刚毕业的时候去北京一样，一切都要重头开始了。走的那天，出租屋里只有个保洁阿姨在打扫卫生，就和我刚回武汉的时候一样。不同的是，上次阿姨说的是房子很快就打扫好了，这次说的是，祝老板以后去上海了发大财啊

2.沪漂

探索新事物

上海就是机会多啊，休息日都会出去逛逛，探索些新事物。想想来上海之后，去周边城市参加徒步、参加ChinaJoy漫展、看了开心麻花的话剧《疯狂理发店》、还有市区内的一些公园、大学、图书馆、动物园、演唱活动等等，生活非常丰富多彩。

• 徒步活动在小红书上找个团报就行，很多都是一天游，一半时间都在路上


• 漫展里的coser都美如画，非常适合集邮

3.第一次演讲

3月

今年参加的线下活动还比较多呢，3月份的时候受腾讯云社区的邀请去杭州参加线下的技术训练营活动，主要也是想趁机会多认识些大佬，说不定大佬招人，有内推机会。倒也认识了不少人，喵喵、小智，还有社区的泽敏姐。晚上一起吃饭交流的时候，泽敏姐说下次有机会让我上去演讲。当时只以为是说说而已，毕竟社区里大佬太多了

9月

9月份的时候收到社区的邀请，去深圳参加腾讯全球数字生态大会，作为讲师上去做分享。我是非常想去的，这样就能达成从学生到老师角色转变的目标，输入变输出。比较纠结的是分享什么内容比较好呢，想了一晚上，最后觉得分享自己用AI两年的经历、沉淀的一些使用心得体、还有变现方式会比较好。

现场的分享也是比较顺利，讲完下来的时候和小智老师沟通上台演讲体验，小智说我讲的非常干货，讲的很稳，刚才他自己讲的时候非常紧张，腿都在抖。我说，我也是啊，腿都在打颤，反而看你讲一点也不慌的样子。。。

第二天又和喵喵一起去腾讯数码大厦找泽敏姐，非常感谢泽敏姐的邀请，第一次到腾讯的大楼参观。期间见识到了超豪华的二次元工位，满墙的手办，非常震惊。

4.AI探索

选择适合自己的方向比较重要，2024年投入了很多时间在AI视频、绘画上，虽然也有涨粉嘛，但是变现不行，一年下来也就三位数的收益。今年主要在写作还有AI编程方向投入，因为换工作的原因，其实投入精力没去年那么多。反而收益还更多了，有四位数的收益。也产出了百万阅读的文章和10w+播放量的视频

出爆款的诀窍就是追热点，这是普通人出爆款最容易的方式了。比如年初的Deepseek，国庆期间的sora2，趁着刚出来热度最高的时候，随便写点东西或者做个视频，流量都非常好的。那像现在再去写Deepseek，流量肯定不如之前了。

11月

11月看到小智老师发的华为鸿蒙线下编程活动的信息，拉着在上海的一个前同事一起去参加玩玩，前同事是我在北京阿里工作时同组的，后来来了上海后，我居然在一个公交站碰到他了，也是十分震惊，居然在上海遇到曾在北京的前同事。鸿蒙的编程活动都是基础的操作，正好也买了Codebuddy的会员，用AI编程轻松解决了，拿到个小礼品

12月

年底了，AI破局俱乐部在深圳举办行动家大会，我看分享嘉宾和内容挺干货的，也报名跑去深圳参加了，到现场才发现，高手云集，天下英雄如过江之鲫。我把这次参会了解的东西整理了下：

• AIPPT.com ：赵充老师以肯德基为例分享做产品不要做全家桶，用户只想要个甜筒（不要做大而全的产品，而是在垂直领域找到需求，在单点，堵上一切）


• AI编程出海：老外付费意愿更强，大公司不愿意做的垂直小市场，才是个人最大的机会。remove.bg网站仅有去除背景这一项功能，流量却非常高


• 搜索流量比推荐流量更值钱：用户主动搜的，说明有明确需求。而平台推的，用户只是随便看看。获取搜索流量的方法：研究用户搜索的关键词，围绕关键词输出内容，时间久了，用户搜索这个关键词，自然就找到你了

活动分享的内容挺多的啊，这里就不继续写了。

同样的听课，结果可能完全不同，会场的1000人，参加完会回去后，可能大部分人就是感慨一下，然后继续原来的生活

5.相亲

离开武汉前，和大学同学聚餐，聊了下发现同学要准备去女方家提亲了，问对象是从哪里找的，说了个相亲软件。不过也很难，同学相亲了十几个女生，才和现在这个走到谈结婚这一步。知道了相亲软件（青藤）后，我来上海也开始了相亲之旅，到目前为止，还没有一个相上的，简单说下相亲的几个女生吧：

• 91年，初中老师。其实是在武汉相亲的，家里给介绍的。感觉年龄差的太大了，差不多5岁了，不过因为是家里介绍的，还是得见上一面。3月的时候，武大樱花还开着，便想去武大里逛逛聊聊。让她把身-份-证号发我，用校友通道预约。然后犹犹豫豫半天没有发我，说是个人隐私等等之类的，要自己预约。结果没约上，想再用校友通道时已经约满了，无奈只好约着去学校旁边一家冷锅鱼店吃饭好了，计划约的12点见面，我预估12点半应该能吃上饭（不知道为什么，武汉相亲的女生都迟到），没想到她直到1点多才到，迟到1个多小时，期间也就各种尬聊，回去后两人都没再发消息了，凉凉


• 93年，上海公务员。家里的亲戚介绍的，是我相亲过的最优秀的女生了。以前的高考文科状元，武大校友，长得像袁咏仪，聊天说话情商也很高。接触了一个月吧，期间也一起吃过饭，看过话剧。最后一次见面聊天说起她前男友，海归，年入百万，金融行业。长相没说啊，应该也不差，妥妥高富帅。我一听这条件，心里顿时凉凉，差距太大了。问起为什么分了呢，说是男的虽然有钱，但是不给女的花，什么事都要AA。就是网上那种观念：钱是给女人看的，不是给女人花的。这次聊完之后就结束了，又凉凉。


• 95年，幼师。在上海相亲的，青藤上找的，见面后感觉非常漂亮啊。不过性格比较强势，刚开始聊的还是开心的话题，突然画风一转，她就开始吐槽模式，吐槽支教的山里小学的领导等等，后半段全是听她吐槽，没再聊相亲的话题了。回去后又聊了几周，但是幼师可能时间太紧，也可能她同时聊的人太多，后面想再约见面就没时间了，于是凉凉


• 97年，互联网数据分析师。来上海后相亲的第一个女生，也是非常漂亮，加上好友，看了我动态后，说非常崇拜技术大佬（多写博客还是有好处的嘛），想请我吃饭。于是爽快赴约，期间聊分布式、高并发等等，最后吃完饭结束的时候，说感觉身高不够


• 00年，主业机械设计，副业自媒体。遇到同行了，聊天话题特别多，情绪价值拉满。约线下去CJ漫展玩，让她把身-份-证号发我来买票，本来还想着怎么解释说明的，下一秒就把身-份-证号和手机号发来了，没有任何犹豫。约好了早上9点半去会展中心，没想到她早早到我这边来等我一起过去，连零食和水都买好了。遂开心前往，妹子是第一次逛漫展，逛的非常开心。只不过回去后还是说了性格不合，只好当朋友了。后续还是保持联系，偶尔见面

这里列出不同年龄段的相亲女生，其他还有一些都是软件上匹配了没说话，或者说两句话就不继续聊了的。给兄弟们做个负面教材的参考啊，今年的相亲就到此为止，明年再说吧。。。

6.2026目标

最后不都得展望下未来吗，2026年你们又给自己制定了哪些目标和规划呢，我给自己定下的目标，希望明年都能做到

• 神山转山


• 樱花巡礼


• 新手上路


• 恰老外米

最后，感兴趣的朋友可以关注我的公众号:卷福同学

引言:从通用助手到领域专家

想象一下这些场景:

场景 1: 重复的上下文说明

你: "帮我分析这个 BigQuery 数据,记住要排除测试账户,使用 user_metrics 表..."

Claude: "好的,我来分析..."



[第二天]

你: "再帮我分析一次销售数据,还是那个表,记得排除测试账户..."

Claude: "好的,我来分析..."  # 😓 又要重复一遍

场景 2: 领域知识的重复传授

你: "帮我处理这个 PDF 表单,PDF 的表单字段结构是..."

Claude: "明白了"



[一周后]

你: "再处理一个 PDF 表单..."

Claude: "请告诉我 PDF 表单的结构"  # 😓 忘记了

场景 3: 工作流程的不一致

你: "生成 API 文档,记得包含请求示例、响应格式、错误码..."

Claude: "好的" # ✅ 这次做得很好



[下次]

你: "再生成一份 API 文档"

Claude: [生成的文档] # ❌ 这次忘记了错误码部分

这些问题的根源是:每次对话都是全新的开始,Claude 无法记住你的领域知识、偏好和工作流程。

💡 Skills 系统的价值

Skills 就是解决这个问题的方案——它让你能够:

本文核心内容:

"把你反复向 Claude 解释的偏好、流程、领域知识打包成 Skills,让 AI 成为你的领域专家"

一、什么是 Skills?

1.1 核心概念

Agent Skills(智能体技能)是一种模块化的能力扩展系统,它为 Claude 提供了:

• 领域专业知识: 如 PDF 处理技巧、数据库 schema、业务规则


• 工作流程: 如代码审查流程、文档生成流程、数据分析流程


• 最佳实践: 如命名规范、代码风格、错误处理模式

1.2 Skills vs 普通 Prompt

类比理解:

• 普通 Prompt 像是每次都要"现场培训"新员工


• Skills 像是给员工提供"岗位手册",需要时自己查阅

1.3 Skills 遵循开放标准

Claude Code Skills 基于 Agent Skills 开放标准,这意味着:

• ✅ 标准化格式,跨 AI 工具兼容


• ✅ 社区生态,可以使用他人创建的 Skills


• ✅ 长期支持,不会因产品升级而失效

Claude Code 在标准基础上扩展了:

• 🔧 调用控制机制


• 🤖 子代理执行能力


• 📥 动态上下文注入

二、Skills 工作原理:渐进式披露架构

2.1 为什么需要渐进式披露?

问题:如果把所有 Skills 的详细内容都加载到上下文中会怎样?

假设你有 10 个 Skills,每个包含 5000 tokens 的详细指导...

总共: 50,000 tokens



但你可能只需要使用其中 1-2 个 Skill!

浪费: 40,000+ tokens(80% 的上下文窗口!)

解决方案:渐进式披露——只加载需要的内容,按需展开详细信息。

2.2 三级加载机制

第一级:元数据(Metadata)- 始终加载

---

name: pdf-processing

description: Extract text and tables from PDF files, fill forms, merge documents.

             Use when working with PDF files or when the user mentions PDFs, forms,

             or document extraction.

---

• 加载时机: Claude 启动时


• Token 消耗: 每个 Skill 约 100 tokens


• 作用: 让 Claude 知道有哪些 Skills 可用,以及何时触发

关键字段解析:

• name: Skill 标识符(小写字母、数字、连字符)


• description: 功能说明 + 触发场景(最重要的字段!)

⚠️ 重要: description 是 Skill 触发的关键。Claude 根据用户请求与 description 的匹配度决定是否加载该 Skill。

第二级:指令(Instructions)- 触发时加载

# PDF Processing



## Quick start



Use pdfplumber to extract text from PDFs:



\`\`\`python

import pdfplumber



with pdfplumber.open("document.pdf") as pdf:

    text = pdf.pages[0].extract_text()

\`\`\`



For advanced form filling, see [FORMS.md](FORMS.md).

• 加载时机: 当用户请求匹配 Skill 描述时


• Token 消耗: 通常少于 5k tokens


• 作用: 提供具体的操作指导和工作流程

第三级:资源和代码(Resources & Code)- 按需访问

pdf-skill/

├── SKILL.md          # 主指令文件(第二级)

├── FORMS.md          # 表单填写指南(按需读取)

├── REFERENCE.md      # 详细 API 参考(按需读取)

└── scripts/

    └── fill_form.py  # 工具脚本(执行时不加载代码)

• 加载时机: 仅当 SKILL.md 中引用时


• Token 消耗: 脚本执行时只有输出占用 tokens


• 作用: 提供专业参考材料和可执行工具

2.3 实例演示:从触发到加载

场景: 用户请求"帮我提取 PDF 中的文本"

┌─────────────────────────────────────────┐

│ 步骤 1: Claude 检查所有 Skill 的元数据 │

└─────────────────────────────────────────┘

              ↓

┌─────────────────────────────────────────┐

│ 匹配到 pdf-processing Skill             │

│ description 包含 "Extract text from PDF"│

└─────────────────────────────────────────┘

              ↓

┌─────────────────────────────────────────┐

│ 步骤 2: 加载 SKILL.md 的指令内容        │

│ (~3k tokens)                            │

└─────────────────────────────────────────┘

              ↓

┌─────────────────────────────────────────┐

│ 步骤 3: Claude 发现需要表单填写         │

│ 读取 FORMS.md (~2k tokens)              │

└─────────────────────────────────────────┘

              ↓

┌─────────────────────────────────────────┐

│ 总 Token 消耗: 约 5k tokens             │

│ 其他 9 个 Skills: 0 tokens(未加载)      │

└─────────────────────────────────────────┘

对比无渐进式披露:

❌ 传统方式: 10 个 Skills × 5k = 50k tokens

✅ 渐进式披露: 只加载 1 个 Skill = 5k tokens

节省: 45k tokens (90% 的上下文!)

三、Skills 的文件结构

3.1 最小化 Skill

最简单的 Skill 只需要一个文件:

my-skill/

└── SKILL.md          # 唯一必需的文件

SKILL.md 示例:

---

name: code-review-checklist

description: Provides a code review checklist for pull requests. Use when reviewing code or when the user asks for code review guidelines.

---



# Code Review Checklist



When reviewing code, check:



1. **Functionality**: Does the code do what it's supposed to?

2. **Readability**: Is the code easy to understand?

3. **Tests**: Are there appropriate tests?

4. **Performance**: Are there any obvious performance issues?

5. **Security**: Are there any security vulnerabilities?



For each item, provide specific feedback with examples.

3.2 完整 Skill 结构

对于复杂的 Skills,可以组织成多文件结构:

pdf-processing-skill/

├── SKILL.md              # 核心指令(必需)

├── FORMS.md              # 表单填写详细指南

├── REFERENCE.md          # PDF 库 API 参考

├── EXAMPLES.md           # 常见用例示例

└── scripts/

    ├── analyze_form.py   # 分析表单工具

    ├── fill_form.py      # 填写表单工具

    └── validate.py       # 验证输出工具

3.3 YAML Frontmatter 规范

必填字段:

---

name: skill-name              # 必填

description: Skill description # 必填

---

字段要求:

命名规范:

✅ 推荐: 动名词形式(Gerund Form)

processing-pdfs

analyzing-spreadsheets

reviewing-code

managing-databases

❌ 避免: 过于模糊

helper          # 太模糊

utils           # 不知道干什么

tool            # 功能不明确

3.4 Description 字段的重要性

⚠️ 警告: description 是 Skill 触发的关键,必须用第三人称!

为什么必须第三人称?

description 会被注入到系统提示中,视角不一致会导致困惑:

系统提示: "You are Claude, an AI assistant..."

Skill description: "I can help you process PDFs"  # ❌ 第一人称,视角冲突!

正确示例:

---

name: pdf-processing

description: Extract text and tables from PDF files, fill forms, merge documents.

             Use when working with PDF files or when the user mentions PDFs, forms,

             or document extraction.

---

不正确示例:

❌ description: I can help you process Excel files  # 第一人称

❌ description: You can use this to process Excel   # 第二人称

❌ description: Helps with documents                # 过于模糊

编写技巧:

四、创建你的第一个 Skill

4.1 确定需求

问题导向:

问自己:

示例场景:

场景 1: BigQuery 数据分析

• ❌ 每次都要说明表结构


• ❌ 每次都要强调"排除测试账户"


• ❌ 每次都要说明查询模式


• ✅ 创建一个 BigQuery Skill!

场景 2: 公司文档规范

• ❌ 每次都要说明文档模板


• ❌ 每次都要强调格式要求


• ❌ 每次都要纠正不符合规范的部分


• ✅ 创建一个文档规范 Skill!

4.2 编写 SKILL.md

步骤 1: 创建目录和文件

mkdir my-bigquery-skill

cd my-bigquery-skill

touch SKILL.md

步骤 2: 编写 YAML Frontmatter

---

name: bigquery-analytics

description: Analyze BigQuery data from the user_metrics and sales tables. Use when the user asks about data analysis, metrics, or BigQuery queries. Always exclude test accounts and apply standard date filters.

---

步骤 3: 编写核心指令

# BigQuery Analytics



## Database Schema



### user_metrics table

- user_id (STRING): Unique user identifier

- event_date (DATE): Event date

- metrics_value (FLOAT): Metric value

- account_type (STRING): "production" or "test"



### sales table

- order_id (STRING): Order identifier

- user_id (STRING): User ID (foreign key to user_metrics)

- amount (FLOAT): Order amount

- order_date (DATE): Order date



## Standard Filtering Rules



**Always apply these filters:**

1. Exclude test accounts: `WHERE account_type = 'production'`

2. Date range: Default to last 30 days unless specified

3. Remove null values: `WHERE metrics_value IS NOT NULL`



## Query Patterns



### Pattern 1: User activity analysis

\`\`\`sql

SELECT

  event_date,

  COUNT(DISTINCT user_id) as active_users,

  AVG(metrics_value) as avg_metric

FROM user_metrics

WHERE account_type = 'production'

  AND event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)

GR0UP BY event_date

ORDER BY event_date;

\`\`\`



### Pattern 2: Sales analysis

\`\`\`sql

SELECT

  DATE_TRUNC(order_date, MONTH) as month,

  COUNT(*) as order_count,

  SUM(amount) as total_revenue

FROM sales s

JOIN user_metrics u ON s.user_id = u.user_id

WHERE u.account_type = 'production'

GR0UP BY month

ORDER BY month;

\`\`\`



## Important Notes



- **Performance**: Always use partitioned date fields in WHERE clause

- **Costs**: Preview query cost before running on large datasets

- **Timezone**: All dates are in UTC

五、核心最佳实践

5.1 简洁为王(Conciseness is Key)

核心原则: 上下文窗口是公共资源,你的 Skill 要与系统提示、对话历史、其他 Skills 共享。

✅ 好的示例(约 50 tokens)

## Extract PDF Text



Use pdfplumber for text extraction:



\`\`\`python

import pdfplumber



with pdfplumber.open("file.pdf") as pdf:

    text = pdf.pages[0].extract_text()

\`\`\`

❌ 糟糕的示例(约 150 tokens)

## Extract PDF Text



PDF(便携式文档格式)是一种常见的文件格式,包含文本、图像等内容。

要从 PDF 中提取文本,你需要使用一个库。有很多 PDF 处理库可用,

但我们推荐 pdfplumber,因为它易于使用且能处理大多数情况。

首先,你需要使用 pip 安装它。然后你可以使用下面的代码...

为什么简洁版更好?

• ✅ 假设 Claude 已经知道 PDF 是什么


• ✅ 假设 Claude 知道库的工作原理


• ✅ 直接提供关键信息:用什么库、怎么用


• ✅ 节省 100 tokens,留给其他 Skills 使用

⚠️ 记住: 不要低估 Claude 的智能!它是通用 AI,不需要你解释基础概念。

5.2 设置适当的自由度

根据任务的脆弱性和可变性,选择合适的指导程度。

🌟 高自由度(基于文本的指令)

适用场景:

• 多种方法都可行


• 决策依赖上下文


• 启发式方法指导

示例:代码审查流程

## Code Review Process



1. Analyze code structure and organization

2. Check for potential bugs or edge cases

3. Suggest improvements for readability and maintainability

4. Verify compliance with project standards

特点: 给出大方向,信任 Claude 根据具体情况调整。

🎯 中等自由度(伪代码或带参数的脚本)

适用场景:

• 存在首选模式


• 允许一定变化


• 配置影响行为

示例:生成报告

## Generate Report



Use this template and customize as needed:



\`\`\`python

def generate_report(data, format="markdown", include_charts=True):

    # Process data

    # Generate output in specified format

    # Optionally include visualizations

\`\`\`

特点: 提供模板和参数,允许根据需求调整。

🔒 低自由度(特定脚本,少量或无参数)

适用场景:

• 操作易错且脆弱


• 一致性至关重要


• 必须遵循特定顺序

示例:数据库迁移

## Database Migration



Execute this script strictly:



\`\`\`bash

python scripts/migrate.py --verify --backup

\`\`\`



Do not modify the command or add extra parameters.

特点: 精确指令,不允许偏离。

🌉 类比理解

把 Claude 想象成在不同地形上探索的机器人:

• 悬崖边的窄桥(低自由度): 只有一条安全路径 → 提供详细护栏和精确指令


• 丘陵地带(中等自由度): 几条推荐路径 → 提供地图和指南针


• 无障碍的开阔草地(高自由度): 多条路径都能成功 → 给出大致方向,信任 Claude 找到最佳路线

5.3 渐进式披露模式

模式 1:高层指南 + 引用

结构:

SKILL.md (简要指南)

   ↓ 引用

[FORMS.md] [REFERENCE.md] [EXAMPLES.md]

示例:

# PDF Processing



## Quick Start



Use pdfplumber to extract text:

\`\`\`python

import pdfplumber

with pdfplumber.open("file.pdf") as pdf:

    text = pdf.pages[0].extract_text()

\`\`\`



## Advanced Features



**Form Filling**: See [FORMS.md](FORMS.md) for complete guide

**API Reference**: See [REFERENCE.md](REFERENCE.md) for all methods

**Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns

优势:

• Claude 只在需要时才读取 FORMS.md、REFERENCE.md 或 EXAMPLES.md


• 未使用的文件 = 0 tokens 消耗

模式 2:按领域组织

适用场景: 多领域的 Skills,避免加载无关上下文

结构:

bigquery-skill/

├── SKILL.md              # 概述和导航

└── reference/

    ├── finance.md        # 财务指标

    ├── sales.md          # 销售数据

    ├── product.md        # 产品分析

    └── marketing.md      # 营销活动

示例:

# BigQuery Analytics



## Domain Reference



- **Finance Metrics**: See [reference/finance.md](reference/finance.md)

- **Sales Data**: See [reference/sales.md](reference/sales.md)

- **Product Analytics**: See [reference/product.md](reference/product.md)

- **Marketing Campaigns**: See [reference/marketing.md](reference/marketing.md)

优势:

• 用户询问销售指标时,只读取 sales.md


• finance.md 和其他文件保持在文件系统中,消耗 0 tokens

模式 3:条件细节

# DOCX Processing



## Create Documents



Use docx-js to create new documents. See [DOCX-JS.md](DOCX-JS.md).



## Edit Documents



For simple edits, modify XML directly.



**Track Changes**: See [REDLINING.md](REDLINING.md)

**OOXML Details**: See [OOXML.md](OOXML.md)

优势:

• 常见操作(创建文档)在主文件中


• 高级功能(追踪更改)按需引用

💡 重要: 保持引用层级为一级深度。避免 SKILL.md → advanced.md → details.md 这样的深层嵌套。

5.4 工作流和反馈循环

复杂任务的工作流模式

为多步骤任务提供清晰的检查清单:

## PDF Form Filling Workflow



Copy this checklist and track progress:



\`\`\`

Task Progress:

- [ ] Step 1: Analyze form (run analyze_form.py)

- [ ] Step 2: Create field mapping (edit fields.json)

- [ ] Step 3: Validate mapping (run validate_fields.py)

- [ ] Step 4: Fill form (run fill_form.py)

- [ ] Step 5: Verify output (run verify_output.py)

\`\`\`



**Step 1: Analyze Form**



Run: `python scripts/analyze_form.py input.pdf`



This extracts form fields and their locations, saving to `fields.json`.



**Step 2: Create Field Mapping**



Edit `fields.json` to add values for each field.



**Step 3: Validate Mapping**



Run: `python scripts/validate_fields.py fields.json`



Fix any validation errors before proceeding.



**Step 4: Fill Form**



Run: `python scripts/fill_form.py input.pdf fields.json output.pdf`



**Step 5: Verify Output**



Run: `python scripts/verify_output.py output.pdf`



If validation fails, return to Step 2.

实现反馈循环

常见模式: 运行验证器 → 修复错误 → 重复

这种模式极大提高输出质量。

示例:文档编辑流程

## Document Editing Flow



1. Make edits to `word/document.xml`

2. **Validate immediately**: `python ooxml/scripts/validate.py unpacked_dir/`

3. If validation fails:

   - Review error messages carefully

   - Fix issues in XML

   - Run validation again

4. **Only proceed when validation passes**

5. Repack: `python ooxml/scripts/pack.py unpacked_dir/ output.docx`

6. Test output document

为什么反馈循环重要?

• ✅ 及早发现错误(在应用更改前)


• ✅ 机器可验证(脚本提供客观验证)


• ✅ 可逆计划(Claude 可以迭代而不破坏原始文件)


• ✅ 清晰调试(错误消息指向具体问题)

5.5 内容指南

避免时间敏感信息

❌ 糟糕示例(会过时):

如果你在 2025 年 8 月之前做这件事,使用旧 API。

2025 年 8 月之后,使用新 API。

✅ 好的示例(使用"旧模式"部分):

## Current Method



Use v2 API endpoint: `api.example.com/v2/messages`



## Legacy Patterns



<details>

<summary>Legacy v1 API (deprecated 2025-08)</summary>



v1 API uses: `api.example.com/v1/messages`



This endpoint is no longer supported.

</details>

使用一致的术语

在整个 Skill 中选择一个术语并坚持使用:

✅ 一致性好:

• 始终使用 "API endpoint"


• 始终使用 "field"


• 始终使用 "extract"

❌ 不一致:

• 混用 "API endpoint"、"URL"、"API route"、"path"


• 混用 "field"、"box"、"element"、"control"


• 混用 "extract"、"pull"、"get"、"retrieve"

六、高级技巧

6.1 包含可执行代码的 Skills

解决问题,而非推卸责任

编写 Skills 脚本时,显式处理错误情况,而非推卸给 Claude。

✅ 好的示例:显式处理错误

def process_file(path):

    """处理文件,如果不存在则创建。"""

    try:

        with open(path) as f:

            return f.read()

    except FileNotFoundError:

        # 创建默认内容而非失败

        print(f"文件 {path} 未找到,创建默认文件")

        with open(path, 'w') as f:

            f.write('')

        return ''

    except PermissionError:

        # 提供替代方案而非失败

        print(f"无法访问 {path},使用默认值")

        return ''

❌ 糟糕示例:推卸给 Claude

def process_file(path):

    # 直接失败,让 Claude 自己想办法

    return open(path).read()

提供工具脚本

即使 Claude 可以编写脚本,预制脚本也有优势:

工具脚本的好处:

• 比生成代码更可靠


• 节省 tokens(无需在上下文中包含代码)


• 节省时间(无需代码生成)


• 确保使用的一致性

示例:

## Tool Scripts



**analyze_form.py**: Extract all form fields from PDF



\`\`\`bash

python scripts/analyze_form.py input.pdf > fields.json

\`\`\`



Output format:

\`\`\`json

{

  "field_name": {"type": "text", "x": 100, "y": 200},

  "signature": {"type": "sig", "x": 150, "y": 500}

}

\`\`\`



**validate_boxes.py**: Check for boundary box overlaps



\`\`\`bash

python scripts/validate_boxes.py fields.json

# Returns: "OK" or lists conflicts

\`\`\`



**fill_form.py**: Apply field values to PDF



\`\`\`bash

python scripts/fill_form.py input.pdf fields.json output.pdf

\`\`\`

💡 重要区分: 在指令中明确说明 Claude 应该:

• 执行脚本(最常见): "运行 analyze_form.py 以提取字段"


• 读取作为参考(用于复杂逻辑): "参见 analyze_form.py 了解字段提取算法"

6.2 创建可验证的中间输出

当 Claude 执行复杂、开放式任务时,可能会出错。"计划-验证-执行"模式通过让 Claude 首先创建结构化格式的计划,然后在执行前用脚本验证该计划,从而及早发现错误。

示例场景

要求: Claude 根据电子表格更新 PDF 中的 50 个表单字段。

没有验证:Claude 可能:

• ❌ 引用不存在的字段


• ❌ 创建冲突的值


• ❌ 遗漏必填字段


• ❌ 错误应用更新

有验证:工作流变为:

分析 → 创建计划文件 → 验证计划 → 执行 → 验证输出

添加一个中间 changes.json 文件,在应用更改前进行验证。

实现示例

## Bulk Form Update Workflow



**Step 1: Analyze**

- Extract current form fields

- Save to `current_fields.json`



**Step 2: Create Change Plan**

- Based on spreadsheet, create `changes.json`:

  \`\`\`json

  {

    "field_updates": [

      {"field": "customer_name", "value": "John Doe"},

      {"field": "order_total", "value": "1250.00"}

    ]

  }

  \`\`\`



**Step 3: Validate Plan**

- Run: `python scripts/validate_changes.py changes.json`

- Script checks:

  - All referenced fields exist

  - Values are in correct format

  - No conflicts

- **Only proceed if validation passes**



**Step 4: Execute**

- Apply changes: `python scripts/apply_changes.py changes.json`



**Step 5: Verify Output**

- Run: `python scripts/verify_output.py output.pdf`

为什么此模式有效

• 及早发现错误: 在应用更改前验证发现问题


• 机器可验证: 脚本提供客观验证


• 可逆计划: Claude 可以在不触及原始文件的情况下迭代计划


• 清晰调试: 错误消息指向具体问题

使用时机

• 批量操作


• 破坏性更改


• 复杂验证规则


• 高风险操作

💡 实现技巧: 让验证脚本输出详细的错误消息:

❌ 模糊: "Validation failed"

✅ 清晰: "Field 'signature_date' not found. Available fields: customer_name, order_total, signature_date_signed"

这帮助 Claude 快速修复问题。

6.3 MCP 工具引用

如果你的 Skill 使用 MCP(Model Context Protocol)工具,始终使用完全限定的工具名称以避免"工具未找到"错误。

格式

ServerName:tool_name

示例

## Query Database Schema



Use the BigQuery:bigquery_schema tool to retrieve table schema.



\`\`\`

Use tool: BigQuery:bigquery_schema

Parameters: {"table": "user_metrics"}

\`\`\`



## Create GitHub Issue



Use the GitHub:create_issue tool to create an issue.



\`\`\`

Use tool: GitHub:create_issue

Parameters: {"title": "Bug report", "body": "Description"}

\`\`\`

说明

• BigQuery 和 GitHub 是 MCP 服务器名称


• bigquery_schema 和 create_issue 是这些服务器中的工具名称

没有服务器前缀,Claude 可能无法找到工具,特别是当有多个 MCP 服务器可用时。

七、常见反模式

❌ 反模式 1:Windows 风格路径

问题:使用反斜杠 \ 作为路径分隔符

❌ 错误:

参见 scripts\helper.py

参见 reference\guide.md

✅ 正确:

参见 scripts/helper.py

参见 reference/guide.md

原因:

• Unix 风格路径跨所有平台工作


• Windows 风格路径在 Unix 系统上会导致错误

❌ 反模式 2:提供太多选项

问题:列出所有可能的方法,让 Claude 困惑

❌ 错误:

你可以使用 pypdf,或 pdfplumber,或 PyMuPDF,或 pdf2image,

或 pikepdf,或 PyPDF2,或 pdfrw,或 pdfminer...

✅ 正确:

使用 pdfplumber 进行文本提取:

\`\`\`python

import pdfplumber

\`\`\`



对于需要 OCR 的扫描 PDF,改用 pdf2image 配合 pytesseract。

原则:

• 提供默认推荐方法


• 只在特殊情况下提供替代方案


• 不要列出所有可能性

❌ 反模式 3:深层嵌套引用

问题:引用链太长,Claude 难以跟踪

❌ 错误:

SKILL.md → advanced.md → details.md → examples.md

✅ 正确:

SKILL.md

  ↓ 直接引用

[ADVANCED.md] [DETAILS.md] [EXAMPLES.md]

原则:

• 保持从 SKILL.md 的引用为一级深度


• 所有引用文件应直接从 SKILL.md 链接

❌ 反模式 4:过度解释基础概念

问题:解释 Claude 已经知道的内容

❌ 错误:

PDF(Portable Document Format,便携式文档格式)是 Adobe 公司

开发的一种文件格式,可以在不同操作系统上保持一致的显示效果。

PDF 文件包含文本、图像、矢量图形等多种内容类型...

✅ 正确:

使用 pdfplumber 提取 PDF 文本。

原则:

• 假设 Claude 的智能


• 只提供 Claude 不知道的领域特定知识

❌ 反模式 5:第一人称描述

问题:使用"我"、"你"等人称

❌ 错误:

description: I can help you process Excel files and generate reports.

✅ 正确:

description: Process Excel files and generate reports. Use when working with spreadsheets or when the user mentions Excel, CSV, or data analysis.

原因:

• description 被注入系统提示


• 第一人称会导致视角冲突

八、总结与行动

8.1 核心收益

通过 Skills 系统,你可以:

8.2 Skills 与其他功能的关系

8.3 实践建议

对于个人开发者:

对于团队:

对于技术 Leader:

8.4 未来展望

Skills 系统的发展方向:

"把你反复向 Claude 解释的偏好、流程、领域知识打包成 Skills,让 AI 成为你的领域专家"

实用资源

• Claude Code 官方 Skills


• 一人公司所需要的Skill集合


• AI Coding资料集合，内含github众多高星skill项目

🔗 相关文章:

• 上一篇: Agent 系统详解:从使用到自定义开发


• 下一篇: Plugin 扩展实战:增强 Claude Code 的能力

如果这篇文章对你有帮助,欢迎点赞、收藏、分享!有任何问题或建议,欢迎在评论区留言讨论。让我们一起学习,一起成长!

也欢迎访问我的个人主页发现更多宝藏资源

简单写个自我介绍。

我在团队里算不上的管理层，没有人事权，也不决定谁走谁留，但我参与的项目一旦出问题，最后都会落到我这里。进度卡住、需求反复、线上事故，会议上可以绕一圈再绕一圈，最终还是要有人把代码改完、把锅兜住。我清楚自己的位置，用武之地比较多的一个“多功能开发者”而已。还依稀记得，当初总部另外一个项目的入侵测，找的还是我，而不是再招一个人。

所以我很少参与评价人，只谈事，谈事实，谈项目是怎么一步步偏离轨道的。

先直接告诉大家结果吧，他被辞退了。

当初公司决定要不要这个人的时候，无意中跟我提到过。我只讲述了几个项目事故，以及其他同事和他合作时的态度。至于留不留他，我不想决定，也决定不了。

那个项目经理，其实并不“坏”。他不吼人，也不甩脸色，会议纪要写得很勤，群里回复永远是“收到”“我跟一下”。问题出在另一层面：需求变更没有留痕，风险评估永远是“可控”，节点延期总能找到外部理由。

上面看到的是一条被不断抚平的曲线，下面看到的是每天被推翻重来的开发计划。我们不是没提醒过，只是提醒被整理成了更好看的版本，再往上递的时候，已经失去了原本的锋利。当然，这些最后都会被归结为一句话——开发同学多努努力，多扩展下思维，补补这个缺点就好了。

但我认为，有些问题其实在内部一直被反复提起，只是从来没有被真正放到台面上说过。

团队里的其他项目经理，大多都有过开发背景。哪怕代码早就不写了，对功能复杂度、实现成本、技术边界心里都是有尺度的。评估的时候会留余量，也知道什么时候该踩刹车。

只有他完全没有开发经验，对一个需求的理解停留在“看起来不难”的层面。既怕自己显得不专业，又怕在会上被认为拖进度，于是每次评估都偏向最激进的版本，功能报得满，时间压到极限。

开发这边明知道不现实，那又怎么办呢？你能说得过他吗？况且领导也是只看结果，活干得快，公司赚得多，干得慢赚得少。所以开发也只能硬着头皮往前推。

一次延期还能解释成意外，两次三次之后，延期就成了默认选项。项目表面上在跑，实际上每一步都在透支客户的耐心。

他甚至能把一个月的功能，压成 7 个工作日。

结果显而易见。项目连夜上线，第二天直接崩溃：APP、小程序白屏，数据无法保存，ToC 的用户一个都打不开。我们凌晨 4 点发完版本，早上 6 点半问题出现，7 点钟起床开始处理。

我起床的时候就已经料到了。项目有他管控着，您就放一万个心吧，麻烦肯定少不了。

当时写功能的时候，有个同事请了丧假。他来了句逆天发言：“到时候你能把电脑带上吗？有事可以找你。”

我当时真想告诉他，兄弟，全公司不是只有他一个前端，这个项目也不是只有他一个前端。人家就请假 3 天，已经很紧张了，还让人把电脑带着，真特么丧良心。

真正的转折点，是那次 A 项目上线。

我没有提任何人的名字，也没有用情绪化的词，只是把时间线拉直：哪一天确认需求，哪一天推翻，哪一天出 PRD，哪一天出 UI，最终导致了什么结果。那份文档写得很长，不好读，也不“体面”，但它有一个特点——每一个问题，都自然地指向了同一个岗位职责。

我提交的时候，甚至没多想，只觉得这次总算把事情说清楚了。

事后我想过，如果我当初不写那份复盘，不跟领导说这些事，会不会结果不同。答案大概是否定的。项目不会因为沉默变好，问题也不会因为不点名而消失。

那天没人替他说话，并不是因为他人缘差，而是因为在那个位置上，他已经很久没有为任何人、任何结果，真正说过一句“这是我的责任”。

系统从来不需要情绪，它只是在某个时刻，停止了包容。

我后来也明白了一件事：在很多公司里，项目经理这个角色，本质上是一个缓冲层。缓冲需求、缓冲压力、缓冲管理层的焦虑。

但一旦缓冲只剩下过滤，没有承担，系统就会重新校准。

那天被裁的不是一个人，而是一种失效的角色设计。而这件事，迟早会发生在任何一个不再为结果站出来的位置上。

大家好呀，我是飞鱼

我今年已经从北京回长沙了，这里谈谈感受。

❝

首先我回长沙不是逃离，而是换一种更舒服、更可持续的生活方式。

北京给了我视野和能力，长沙给了我生活和归属。

最直观的变化

• 节奏慢了：不用挤早高峰了，走路不用小跑，回家路更短。


• 心态稳了：不再天天赶进度、追KPI，人也没那么紧绷了。

生活成本：压力明显小了

❝

房租、通勤、日常开销都降了不少，以前在北京工资高，但大头都被生活成本吃掉了。

现在收入可能少些，但心里踏实很多。

个人生活：更松弛也更有边界

❝

回来后作息更规律了，能早点睡、早点起，周内也会留出时间运动或散步。

以前下班只想躺着刷手机，现在会给自己留一点空白时间，用来读书、整理思路或者陪家人聊天。

生活变简单，但心里更笃定，能把注意力放在真正重要的人和事上。

城市气息：更有生活感

❝

长沙烟火气足，我现在每周都会去爬一次岳麓山（离得近）。

周末也能随时约上朋友一起吃饭聊天，不用再掐着时间赶路。

个人成长：从外部驱动到自我驱动

❝

以前在北京，节奏和环境会推着我走，事情一件接一件，来不及想太多。

回长沙后，外部推力小了，但我开始主动搭自己的节奏：给自己设目标、做复盘、安排学习计划。

慢下来之后，反而更能看清自己擅长什么、缺什么，也更容易把工作和生活都经营得更稳。

给同样选择的人一点建议

• 先想清楚你想要什么：是离家近、生活压力小，还是职业成长更快？别只因为累了就决定，要有明确的取舍。


• 提前做资源准备：无论去哪，职业发展都得靠自己，技能储备、作品、圈子都要主动经营。


• 规划现金流：收入变化要提前算清楚，别让生活压力反过来影响判断。


• 给自己一个过渡期：回去不是立刻完美适应，给自己几个月调整节奏，别太焦虑。

最后想说

适合自己的地方，不一定是机会最多的地方，而是能让你活得更从容、有力量的地方。

❝

最后想看技术文章的，可以去我的个人网站：hardyfish.top/

在程序员的职业字典里，每次提到“外包”这两个字，似乎往往带着一种复杂的况味，不知道大家对于这个问题是怎么看的？

包括我们在逛职场社区时，也会经常刷到一些有关外包公司讨论或选择的求职帖子。

的确，在如今的 IT 职场大环境里，对于许多刚入行的年轻人，或者很多寻求机会的开发者来说，外包公司或许也是求职过程中的一个绕不开的备选项。

今天这篇文章，我们先来聊一聊 IT 江湖里经常被大家所提起的“四大软件外包公司”，每次打开招聘软件，相信不少同学都刷到过他们的招聘信息。

他们在业内也一度曾被大家戏称为“外包四大金刚”，可能不少同学也能猜到个大概。

1、中软国际

中软可以说是国内软件外包行业的“老大哥”之一，拥有约 8 万名员工，年收入规模高达 170 亿。

而且中软的业务版图确实很大，在国内外 70 个城市重点布局，在北京、西安、深圳、南京等地均拥有自有产权的研发基地。

提起中软，很多同学的第一反应是它和华为的“深度绑定”。

的确，华为算是中软比较大的合作伙伴之一，同样，这种紧密的合作关系，让中软在通信、政企数字化等领域获得了不少份额。

在中软的体系里，经常能看到一种非常典型的“正规化”打法。它的流程比较规范，制度也非常完善。这对于刚毕业的大学生或者想要转行进入 IT 的人来说，算是一个不错的“练兵场”。

不过近年来，中软也在拼命转型，试图摆脱单纯的外包标签，在 AIGC 和鸿蒙生态上投入了不少精力。

2、软通动力

如果说上面的中软是“稳扎稳打”的代表，那么软通给人的感觉就是“迅猛扩张”。

软通虽然成立时间比中软晚了几年，但发展势头却非常迅猛。

根据第三方机构的数据显示，软通动力在 IT 服务市场的份额已经名列前茅，甚至在某些年份拔得头筹。

软通这家公司一直给人的印象是“大而全”。它的总部在北京，员工规模甚至达到了 90000 人。

而软通动力的上市，一度给行业打了一剂强心针。它的业务线覆盖了从咨询到 IT 服务的全生命周期，包含了金融、能源、智能制造、ICT 软硬件、智能化产品等诸多方面。

3、东软集团

如果说前两家是后来居上的代表，那么东软就是老牌子软件公司的代表。

成立于 1991 年的东软，是中国上市较早的软件公司之一，早在 1996 年就上市了。

东软最初创立于东北大学，后来通过国际合作进入汽车电子领域，并逐渐踏上产业化发展之路，其创始人刘积仁博士也算是软件行业的先驱大佬了。

东软的业务重心很早就放在了医疗健康、智慧城市和汽车电子等这几个领域。

说不定现在很多城市的医院里，跑着的 HIS 系统有可能就是东软做的。

虽然近年来东软也面临着转型阵痛，但它在医疗和智慧城市等领域的积淀，依然是其他外包公司难以撼动的。

4、文思海辉（中电金信）

这家公司的发展历程比较特殊，它经历过文思创新和海辉软件的合并，后来又加入了中国电子（CEC）的阵营，成为中国电子旗下的一员，并且后来又进一步整合为了中电金信。

所以它现在更多地以“中电金信”的身份出现。

文思海辉的强项在于金融和数智化领域，尤其银行业 IT 项目这一块做了非常多，市场份额也很大。

那除了上面这几个“外包巨头”之外，其实很多领域还有很多小型外包公司，有的是人力资源外包，有的则是项目外包。

每次提到「外包」这个词，可能不少同学都会嗤之以鼻，那这里我也来聊聊我自己对于外包的一些个人看法和感受。

说实话，我没有进过外包公司干过活，但是呢，我和不少外包公司的工作人员共事过，一起参与过项目。

记得老早之前我在通信公司工作时，我们团队作为所谓的“甲方”，就和外包员工共事过有大半年的样子，一起负责公司的核心网子项目。

有一说一，我们团队整体对外包同事都是非常友好的。

我看网上有那种什么外包抢了红包要退钱、什么提醒外包注意素质不要偷吃的零食的事情，有点太离谱、太夸张了，这在我们团队那会是从来没有发生过的。

大家平时在一起上班的氛围也挺融洽，大家一起该聊天聊天，该开玩笑开玩笑，该一起吃饭一起吃饭，在相处方面并没有什么区别。

但是，不同地方的确也有。

比方说，他们上班时所带的工牌带子颜色就和我们不太一样，这一眼就能看出来，另外平时做的事情也有点不太一样。

我记得当时项目的一些抓包任务、测试任务、包括一些标注任务等等都是丢给外包同事那边来完成，我们需要的是结果、是报告。

另外对于项目文档库和代码库的权限也的确有所不同，核心项目代码和文档确实是不对外包同事那边开放的。

除此之外，我倒并没有觉得有什么太多的不同。

那作为程序员，我们到底该如何看待这些外包公司呢？

这就好比是一个围城，城外的人有的想进去，城里的人有的想出来。

每次一提到外包，很多人的建议都是不要进，打亖别去。但是，这里有个前提是，首先得在你有的选的情况下，再谈要不要选的问题。

不可否认的是，外包公司确实有它的短板。最被人诟病的两点，一个“职业天花板”问题、一个“归属感缺失”问题。

但是在当下的就业环境里，我们不得不承认的是，外包公司也承担了 IT 行业“蓄水池”的角色。

毕竟并不是每个人一毕业就能拿到互联网大厂的 offer，也并不是每个人都有勇气去创业公司搏一把。

对于有些学历一般、技术基础一般或者刚转行的程序员来说，外包也提供了另外一个选择。

而如果你现在正在外包或者正在考虑加入外包，那这里我也想说几句肺腑之言：

第一，不要把外包作为职业生涯的终点，而应该把它看作一个跳板或过渡。

如果你刚毕业进不去大厂，或者在一二线城市没有更好的选择，那外包可以为你提供一个接触正规项目流程的机会（当然前提是要进那种正规的外包），我们也可以把它看昨一个特殊的职场驿站。

在那里的每一天，你都要问问自己：我学到了什么？我的技术有没有长进？我的视野有没有开阔？

第二，一定要警惕“舒适区”。

很多同学在外包待久了，可能会陷入一种拿工资办事的机械式工作中，看起来很舒适，实际上很危险。

注意，一定要利用能接触到的资源，去学习项目的技术架构和业务流程，去想办法提升自己的核心竞争力，而不是仅仅为了完成工时。

最后我想说的是，无论你是在大厂做正式员工，还是在小团队里打拼，亦或是在外包公司里默默耕耘，最终决定职业高度的，并不是工牌上公司的名字，而是会多少技术，懂多少业务，能解决多少问题，大家觉得呢？

好了，今天就先聊这么多吧，希望能对大家有所启发，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

0. 前言

在 2025年的尾巴上，发生了一件非常有趣的事，我在微信公众号上的 AI 四格漫画 意外爆火。之前公众号上发的技术文章，基本上阅读量不过 300，每天广告收益也就几毛钱。目前最火的美杜莎，浏览量已经达到惊人的 5W。这样让我不禁感叹:

十年技术无人问，一曲漫笑广人闻。

火爆之后，带来的最直接价值就是迎来了泼天富贵。从未想过有一天，我的日广告收益能达到 400+ ，目前已经连续四天高位。除了金钱，自己的作品受到欢迎，以及大家在评论区的吐槽、讨论，也为我带来了很大的情绪价值。

-	-

1. 缘起

先简单介绍一下：我是一个籍籍无名的编程技术小博主，全网统一名号 张风捷特烈 。 编程之王 是我维护的公众号，一直是输出编程技术的文章，主要以 Flutter 技术为主。

但技术文章更新的不是非常频繁，而公众号每天有一篇发文的机会。本着 不想浪费 的优良传统，在 AI 重塑一切的浪潮中，我想用 AI 画些四格漫画的笑话试试。于是开启了 慧心一笑 专栏， 《小火柴的倒霉日常》 就是第一篇，现在还没火。大家也可以点开看看，内容非常精简，就是一幅图+提示词。

这个系列整体是诙谐幽默的，下面是第一篇的内容：

一开始我是用自然语言的提示词，感觉效果并不是太好，四格漫画有着连续的信息和一致性的人物、场景等。由于编程出身，在 结构一致性 方面有着天然的敏锐嗅觉。于是基于 yaml 文件来定义统一的场景、角色、样式、色调等信息：

comic_info:

  type: "四格漫画"

  style: "手绘简笔画、柔软线条、轻松冷幽默、统一角色"

  color_scheme: "暖黄主色调，红橙色点缀，柔和明暗层次"

  character:

    name: "小火柴"

    appearance: "细长圆柱身体、红色火柴头、两根短竖眉毛、圆点眼睛、呆萌可爱"

    personality: "迷糊、天真、略倒霉"

  background_style: "白色简约背景，搭配少量手绘街景或物件增强生活感"

面板列表放在 panels 节点下，每个宫格由 panel[x] 固定场景内容。包括描述、场景、动作、表情、细节、文本等：

panels:

  panel1:

    description: "第一格：日常铺垫"

    scene: "温暖的手绘街道：地面为淡黄色纹理，简单的路灯、几株小草、远处一座小房子，空气里飘着幾颗小亮点"

    action: "小火柴双手背在身后，踩着轻快的小步子前进"

    expression: "轻松微笑，眼睛微弯"

    details: "路灯用细线勾勒，小草三两稀疏点缀，天空加几朵柔软的白云"

    text: "今天天气真好呀～"

定义完结构，一个 yaml 文件就对应了一个四格故事，把这个内容丢给 AI 生图的工具，就能得到对应的图片。

2. 关于 AI 生图工具与质量

我的理念是: 文本是一种序列的约定：

它可以视为一个四格漫画的 基因，而 AI 工具会将基因 实例化 为个体。

所以，生成图的好坏取决于两个因素：基因序列 和 成长环境。也就是提示词好不好，以及 AI 工具厉不厉害。 AI 生图的工具有很多，单目前大多数，对于标准的四格漫画都无法准确输出，下面列举几个:

• 即梦 AI

• 豆包

• Nano Banana

目前来看，国产的 AI 仍有很大的进步空间，Nano Banana 能符合我对图片产品的预期。但是 AI 正在蓬勃发展中， AI 生图也是最近一两年才逐渐可用的，我对他们的未来持有乐观的态度，包括我们国产的大模型。所以如果 成长环境 将会越来越好，那么 基因序列 本身将会成为非常重要的因素。

目前我只是简单设计了一下 yaml，按照版本控制，称为 v0.0.1 吧，后续随着创作需求的升级，我也会逐步迭代整体结构，设计更合理的 DNA 结构 😁

3. 选定方向? Flow Heart

有人问我，你是怎么想到这些稀奇古怪的方向的，而且你是怎么坚持下来的。

对于一个创作者来说，拓宽自己的边界是一个很必要的事。特别是对一个编程创作者，广泛涉猎是家常便饭。使用一切手段，解决自己遇到的问题；没有问题时就去发展自己，在新的领域中寻找问题。至于坚持嘛，遵循内心的指引，做自己喜欢的事，是不需要坚持的，就像你每天都要喝水一样自然。

可能有人会问，如果 AI 的笑话漫画没有火，你还会坚持下去吗？刚做前两个漫画文章时，还没有火，一天收入 1 块钱，我已经觉得很美滋滋了。投入的产出符合我的预期，毕竟只需要准备个笑话雏形，其他都交给 AI 写就行了。我还和女朋友炫耀：

-	-

最后还是想强调一点：如果一件事，对社会、对他人没有危害，自己做着觉得开心，起来没有负担和压力，就会大胆去做。反之，可以在其他方面继续延伸，找到自己喜欢的那个领域。AI 工具的加持，让个体拥有了前所未有的能力，个人的边界可以极度拓宽。

4. 为什么会火？

第一次感觉会火，是因为擎天柱 这篇，浏览量异常上升：

从数据统计来看，发布第一天只有 102 个浏览量，和往常没什么区别。持续一周，没有任何波澜，突然在 12-20 号，增加了近 5000 的浏览量，第二天持续上涨过万，然后逐渐平息：

在第一篇爆火的后一天，慧心一笑#03 | 爸爸去钓鱼~ 数据开始上升，感觉像是连带效应：

为了验证一下是不是偶然火爆，我在 20号和 21 号又发表了两篇小笑话。结果不温不火，似乎感觉也不是必然的。
在 23 号，我发布了 慧心一笑#06 | 被美杜莎石化...，这篇在当晚直接火爆，

从数据来看，第二天浏览量直接过 2.6W，后面还有持续几天的流量：

至于为什么火爆，从阅读渠道构成来看 98.7% 的阅读量来自于公众号推荐。只能说是老天喂饭吃 ~

5. 小结一下

接下来几天的 慧心一笑#07 | 爸爸回来了... 和 慧心一笑#09 | 农夫与蛇 也阅读过 3万。目前慧心一笑系列发布了 9 篇，阅读量超过 2.5W 的爆款有 5 篇，比例算是很高了。

感觉微信公众号的推荐阅读机制应该有所变化。另外也不是每篇都会火爆，应该和作品本身质量、流传度也有关系。这个有趣的现象让我非常欣喜，后续我还会继续创作更有意思的四格漫画，来继续验证数据。大家也可以关注 《编程之王》 公众号和我一起见证。等到第 30 篇后，我会再写一个复盘报告，和大家分享。

另外可能会有人问，你发这个就不怕别人也抄你的模式，跟你竞争吗。我只想说：

更多文章和视频知识资讯，大家可以关注我的公众号、掘金和 B 站 。让我们一起成长，变得更强。我们下次再见~

• QQ交流群： 1046304516


• 掘金账号： 张风捷特烈


• bilibli 账号： 张风捷特烈


• 公众号： 编程之王

你有没有在朋友圈或者知乎上看到过这样的声音：“前端这行是不是快没前途了？”、“前端是夕阳行业，学不起来就晚了”。听起来很吓人吧？今天周五公司不忙~ 所以就想就想聊聊，为什么这些说法有点夸张，而且，实际上，前端比你想的要活跃、要有意思得多。

前端行业现状与就业趋势深入分析

其他废话少说，我先列出一组数据。

市场数据说明：招聘活跃度与求职热度

在判定某个岗位是否是“夕阳行业”前，我们得看看实实在在的数据，而不是空谈。虽然我们没有官方完整的每月统计数据，但从招聘平台侧面指标可以窥见市场动态：

BOSS直聘平台整体使用频次趋势（2024 年）

数据来自行业研究监测，反映招聘平台月度活跃度（平台月访问次数，单位为万次）。它可以折射出用户在找工作和发布岗位的活跃程度：

从这张表可以看到几个趋势：

• 春节前后及 3 月、4 月经常会有求职与招聘高峰，这与校园招聘和年终奖金兑现周期有关。


• Boss直聘的整体使用频次明显高于其他招聘平台，表明它在人才市场中具有更高的活跃度。

这说明整体就业市场并没有冷却到技术岗位“没市场”的程度，但伴随着整体求职竞争压力也在增加（尤其毕业季之后）。

2024–2025 前端岗位薪资与供需情况（综合公开数据）

下面给出一个简要的薪资与供需趋势对比，是基于公开行业报告和招聘平台上职位薪资调研整理的（单位：人民币）：

前端薪资水平（2024–2025）

小结：大厂或高级岗位薪资明显高于平均，而整体前端岗薪资按城市和经验差异明显（北上深等一线城市更高）。中高级工程师薪资已进入较高收入层。

前端岗位供需趋势（24 年–25 年）

真实可公开的按月份招聘/求职人数统计不容易直接获得（需付费或数据授权），但我们可以根据人才供需比报告和其他间接指标构建趋势理解：

人才供需比（供给 vs 需求）变化

供需比上升意味着“求职者数量增速快于岗位数量”，这反映就业市场总体竞争压力上升，但这主要是整体技术类岗位，不仅限前端。技术类岗位中核心和稀缺型（例如 AI、架构方向）仍然紧缺。 开源中国

招聘/求职活跃度趋势示意

timeline

    title 

    2024 : 招聘需求 ↑, 求职人数 ↑

    2025 : 招聘需求 ↓, 求职人数 ↑↑

• 招聘需求在 2024／2025 年虽整体活跃，但增长略收敛。


• 求职人数增速仍然高（尤其高校毕业生和转行人才增多）。 PDF 文档助手+1

“前端到底是做什么的”

以前的前端，其实很简单——写页面。你写几个 HTML、CSS，再加上点 JS，页面能跑就算完成任务。大部分人只要会写代码，基本就能找到工作。那时候，技术门槛不高，但随之而来的问题是：大家都能做，稀缺性不强。

到了现在，前端已经不是单纯写页面那么简单了。现在你需要考虑性能优化、工程化、架构设计，甚至还得会和 AI 工具配合来提高效率。也就是说，前端的工作量和复杂度已经大幅升级了，光会写代码，已经不再稀缺。

普通前端 / 工程型前端 / 架构型前端

我一般把前端分成三类：

会写代码不再稀缺，会“用 AI 写代码”才是门槛

你可能注意到了，现在很多人说“前端会写代码不稀缺了”。这是真的。基础的 JS、CSS、HTML 很多人都会，但如果你能用 AI 辅助写代码、自动生成模板、快速优化性能，那才是真正的核心竞争力。就像以前会打字的人很多，但会用 Excel 做财务建模的人少，差距就出来了。

举个例子，现在有些大型项目，我们用 AI 帮忙生成表单验证逻辑，或者做自动化测试脚本，效率能提高好几倍。这种能力，不是简单敲几行代码能替代的。

前端未来,更像产品工程师

所以，到底前端是不是夕阳行业？我觉得恰恰相反。未来的前端，更像产品工程师——你不仅要写代码，还要思考性能、用户体验、架构设计、工程化流程，甚至要和 AI、云端、数据打交道。前端的职业宽度比以前更大，技能组合也更加稀缺。

换句话说，前端不再只是写界面的小伙伴，而是能把技术和产品结合起来，创造可落地系统的人。

总结

不是前端“夕阳”，只是门槛提高了

从薪资和招聘活跃度看：

• 前端岗位依旧铺开在招聘平台上，高薪职位数量没有消失，只是分布更广、更分层。


• 高端工程师、架构型前端、全栈/AI 前端人才仍然供不应求。


• 竞争压力主要来自技术同质化人才与行业整体求职人数增长的趋势（特别是毕业季）。 开源中国

真实情形是：前端并非夕阳，而是在职业形态和薪资结构上出现了更明显的分层。

你看到普通前端岗位薪资增长缓慢，是因为市场供给大，但 高技术、高工程化能力者反而更加吃香，门槛变了，而不是需求消失。

总结：结合数据再看“前端是否夕阳”

既然有数据支撑，我们再回到那个问题：

前端是否是夕阳行业？结论是：

所以说：前端不是夕阳行业，前端职业更像是正经历升级版的“技术工程”方向，更接近综合产品工程师，而不是单纯的页面写手。

要在这个岗位上活得更好，与 AI 协作、提升工程化能力、掌握架构与性能优化，成为未来核心竞争力。

数据来源说明

本文涉及的前端薪资、招聘人数、求职人数及市场趋势数据，主要来源公开渠道：

• BOSS直聘：招聘岗位示例及薪资参考 官网，招聘活跃度趋势及职位需求变化 年度报告


• 前端薪资参考：全国平均薪资及高端岗位薪资 Teamed Up China、大厂薪资对比 Levels.fyi、高端技术岗位薪资 脉脉高聘年度报告


• 前端供需数据：技术类岗位供需比及求职活跃度 公开行业报告

数据仅供行业分析参考，实际薪资及岗位信息可能随城市、公司和岗位等级变化。

作为一名Java工程师，效率就是生产力。那些能让你少写代码、少改BUG、少加班的工具，往往能为你节省大量时间，让你专注于解决真正有挑战性的问题。

下面分享的这些工具几乎覆盖了Java开发全流程，从编码、调试到构建、部署，每一个环节都能大幅提升你的工作效率。

一、IDE增强类工具

1. IntelliJ IDEA终极版 + 精选插件

作为Java开发的首选IDE，IntelliJ IDEA本身已经非常强大，但配合以下插件，效率可以再提升一个档次：

• Key Promoter X: 显示你手动操作的快捷键，帮助你养成使用快捷键的习惯


• AiXcoder Code Completer: 基于AI的代码补全，比IDEA自带的更智能


• Maven Helper: 解决Maven依赖冲突的神器


• Lombok: 减少模板代码编写


• Rainbow Brackets: 彩色括号，让嵌套结构一目了然

实用技巧：创建多个Live Templates（代码模板），比如定义日志、常用异常处理、单例模式等。每天能节省几十次重复输入。

2. Lombok

虽然这是一个库，但它堪称效率工具。通过注解的方式，自动生成getter/setter、构造函数、equals/hashCode等方法，大幅减少模板代码量。

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class UserDTO {

    private Long id;

    private String username;

    private String email;

    // 无需编写getter/setter/构造函数/toString等

}

注意事项：使用@EqualsAndHashCode时，注意排除可能造成循环引用的字段；使用@Builder时，考虑添加@NoArgsConstructor满足序列化需求。

二、调试与性能分析工具

3. Arthas

阿里开源的Java诊断工具，它能在线排查问题，无需重启应用。最强大的是它能够实时观察方法的入参、返回值，统计方法执行耗时，甚至动态修改类的行为。

常用命令：

• watch 监控方法调用


• trace 跟踪方法调用链路


• jad 反编译类


• sc 查找加载的类


• redefine 热更新类

实战示例：线上问题排查，不方便加日志时，用watch命令观察方法执行：

watch com.example.service.UserService queryUser "{params,returnObj}" -x 3

4. JProfiler

Java剖析工具的王者，能够分析CPU热点、内存泄漏、线程阻塞等问题。与其他分析工具相比，JProfiler的UI更友好，数据呈现更直观。

核心功能：

• 内存视图：找出占用内存最多的对象


• CPU视图：定位热点方法


• 线程视图：发现死锁和阻塞


• 实时遥测：监控线上应用，无需重启

技巧：养成定期对自己负责的服务做性能分析的习惯，很多问题在上线前就能发现。

5. Charles/Fiddler

抓包工具是API调试的必备利器。Charles(Mac)或Fiddler(Windows)能够拦截、查看和修改HTTP/HTTPS请求和响应。

实用功能：

• 模拟网络延迟


• 请求重写


• 断点调试HTTP请求


• 反向代理

在前后端分离开发和调试第三方API时，这类工具能节省大量时间。

三、代码质量工具

6. SonarQube + SonarLint

SonarQube是静态代码分析工具，可以检测代码中的漏洞、坏味道和潜在bug。而SonarLint是其IDE插件版，能在你编码时实时提供反馈。

最佳实践：

• 在CI流程中集成SonarQube


• 为团队制定"质量门"标准


• 使用SonarLint实时检查，避免代码审查时返工

技巧：自定义规则集，忽略对特定项目不适用的规则，避免"过度洁癖"。

7. ArchUnit

用代码的方式测试架构规则，确保项目架构不会随着时间推移而腐化。

@Test

public void servicesAndRepositoriesShouldNotDependOnControllers() {

    ArchRule rule = noClasses()

        .that().resideInAPackage("..service..")

        .or().resideInAPackage("..repository..")

        .should().dependOnClassesThat().resideInAPackage("..controller..");

    

    rule.check(importedClasses);

}