ubuntu 一键安装docker+compose
国外的
1 | 能访问国外的一件搞定,比如我的Bandwagon |
国内的
1 | !/bin/bash |
1 | # 能访问国外的一件搞定,比如我的Bandwagon |
1 | #!/bin/bash |
在当今高流量的互联网环境中,应用程序需要处理的请求量正在迅速增长。作为Java开发者,我们经常面临如何扩展Spring Boot应用以处理大量并发请求的挑战。本文将探讨如何将Spring Boot应用从处理每秒5万请求优化到每秒100万请求的实用策略,并提供详细的代码示例和实施步骤。
想象一下这样的场景:你的团队被告知应用需要在三个月内实现20倍的流量增长,从每秒5万请求提升到每秒100万请求,而且硬件预算有限。这听起来几乎是不可能完成的任务。然而,通过深入分析性能瓶颈和应用一系列优化技术,我们可以达成这一目标。
在开始优化之前,我们需要了解系统的现状:
在开始优化过程之前,了解我们的目标至关重要。成功优化后的应用应该达到以下性能指标:
最有影响力的变化是采用Spring WebFlux进行响应式编程。这不仅仅是简单的替换,而是需要重新思考应用程序的结构。首先,更新项目依赖:
1 | <!-- 将spring-boot-starter-web替换为spring-boot-starter-webflux --> |
然后,改变控制器实现方式:
1 | // 传统Spring MVC控制器 |
服务层也需要相应改变:
1 | // 传统的服务实现 |
数据库通常是系统的主要瓶颈。以下是一些优化数据库访问的详细策略:
将传统的JDBC驱动替换为响应式数据库驱动:
1 | <!-- 添加R2DBC依赖 --> |
配置R2DBC连接:
1 | @Configuration |
创建响应式Repository:
1 | public interface ReactiveProductRepository extends ReactiveCrudRepository<Product, Long> { |
引入Redis缓存:
1 | <!-- Redis响应式支持 --> |
配置Redis缓存:
1 | @Configuration |
在服务层实现缓存:
1 | @Service |
使用索引优化:
1 | -- 为常用查询字段添加索引 |
优化查询方法:
1 | // 避免使用count(*) |
配置主从数据源:
1 | @Configuration |
创建读写分离的Repository:
1 | @Repository |
性能提升往往来自于正确的配置调整。以下是详细的配置优化步骤:
在application.yml中配置Netty参数:
1 | spring: |
在Java代码中自定义Netty配置:
1 | @Configuration |
在application.properties中添加JVM参数,或者直接在启动脚本中配置:
1 | # 堆内存设置 |
配置R2DBC连接池:
1 | @Configuration |
配置Redis连接池:
1 | @Configuration |
配置WebClient高性能连接池:
1 | @Configuration |
不是所有的端点都需要改为响应式的。下面是混合架构的详细实现:
使用Spring的路由器函数:
1 | @Configuration |
1 | @Component |
创建适配器以支持新旧代码互操作:
1 | @Component |
在优化应用程序之后,可以通过Kubernetes进行智能水平扩展。以下是详细的配置和实现:
1 | FROM openjdk:17-jdk-slim |
1 | apiVersion: apps/v1 |
1 | apiVersion: v1 |
1 | apiVersion: autoscaling/v2 |
在应用程序中添加断路器模式:
1 | <!-- 添加Resilience4j依赖 --> |
配置断路器:
1 | @Configuration |
这几天想起翻起来Google之前新发布的白皮书《Prompt Engineering》,学习下再简单用Claude提取下主要内容记录下。
在人工智能迅猛发展的今天,提示工程(Prompt Engineering)已成为连接人类意图与AI输出的关键桥梁。Google最新发布的白皮书《Prompt Engineering》为我们提供了全面而深入的指南,让我们一起探索如何通过精心设计的提示让大语言模型发挥最大潜力。
提示工程是设计高质量提示的过程,旨在引导大语言模型(LLM)产生准确、相关且有用的输出。正如白皮书中所强调的:
“你不需要成为数据科学家或机器学习工程师——每个人都可以编写提示。然而,设计最有效的提示可能很复杂。”
大语言模型本质上是一个预测引擎,它接收序列文本作为输入,然后基于训练数据预测下一个词元(token)应该是什么。当你编写提示时,你正在尝试设置LLM以预测正确的词元序列。
在开始提示工程之前,了解如何配置LLM输出至关重要:
控制模型生成的词元数量是一项重要配置。生成更多词元需要更多计算资源,导致能耗增加、响应时间潜在变慢,以及成本提高。限制输出长度对于某些提示技术特别重要,如ReAct(推理与行动),在这种情况下,LLM会在你想要的响应后继续生成无用词元。
LLM不会正式预测单个词元,而是为每个可能的下一个词元分配概率。这些词元概率然后被采样以确定下一个生成的词元。
温度控制词元选择中的随机性程度:
这两种设置限制预测的下一个词元只能来自概率最高的词元:
综合配置时,一般起点建议:
最简单的提示类型,仅提供任务描述和一些文本让LLM开始。适用于模型已经理解的简单任务。
示例:
1 | 将电影评论分类为积极、中性或消极。 |
通过在提示中提供一个或多个示例,帮助模型理解所需的输出格式或模式。这种方法特别适用于需要特定输出结构的任务。
示例:
1 | 解析客户的披萨订单为有效的JSON: |
少样本提示的示例数量取决于任务复杂性、示例质量和模型能力。一般建议至少使用3-5个示例,复杂任务可能需要更多。
这三种技术都用于引导LLM生成文本,但侧重点不同:
设置语言模型的整体上下文和目的,定义模型应该做什么的”大局观”。
示例:
1 | 将电影评论分类为积极、中性或消极。只返回大写的标签。 |
为语言模型分配特定角色或身份,帮助模型生成与该角色一致的响应。
示例:
1 | 我希望你扮演旅游指南的角色。我会告诉你我的位置,你将为我推荐3个附近可以参观的地方。在某些情况下,我还会告诉你我想参观的地点类型。 |
提供与当前对话或任务相关的具体细节或背景信息,帮助模型理解要求的细微差别。
示例:
1 | 上下文:你正在为一个关于80年代街机视频游戏的博客撰写文章。 |
先考虑与特定任务相关的一般问题,然后将答案用于后续提示,激活相关背景知识和推理过程。
示例:
1 | 步骤1:基于流行的第一人称射击游戏,什么是5个虚构的关键设置有助于第一人称射击游戏中挑战和引人入胜的关卡故事线? |
通过生成中间推理步骤来改善推理能力,特别适用于数学问题、逻辑推理等需要分步思考的任务。
示例:
1 | 当我3岁时,我的伙伴是我年龄的3倍。现在,我20岁了。我的伙伴多大?让我们一步一步思考。 |
思维链提示可以与单样本或少样本结合使用,效果更佳:
1 | 问题:当我哥哥2岁时,我的年龄是他的两倍。现在我40岁了。我哥哥多大?让我们一步一步思考。 |
结合抽样和多数投票,生成多样化的推理路径并选择最一致的答案。这种方法改进了LLM在各种任务中的准确性和回答一致性。
过程:
允许LLM同时探索多个不同的推理路径,通过在树的不同节点分支来解决问题。特别适合需要探索的复杂任务。
结合自然语言推理与执行外部工具操作的能力,使LLM能够解决复杂任务。例如,查询网络获取信息,然后基于结果继续推理。
Python示例:
1 | from langchain.agents import load_tools |
利用LLM自身生成更多提示,评估它们,并可能修改好的提示,然后重复这个过程:
LLM可以帮助开发人员加速编写代码过程,实现各种自动化任务:
示例:
1 | 用Bash编写一个代码片段,询问文件夹名称。然后将该文件夹的内容重命名,在文件名前加上"draft"。 |
LLM也可以帮助理解他人的代码:
示例:
1 | 解释以下Bash代码: |
将代码从一种语言翻译到另一种语言:
示例:
1 | 将以下Bash代码翻译为Python片段: |
修复代码中的错误并提供改进建议:
示例:
1 | 以下Python代码报错: |
在提示中提供示例是最重要的最佳实践之一,它作为强大的教学工具,展示期望的输出或类似响应,提高模型输出的准确性、风格和语调。
提示应简洁、清晰、易于理解。如果对你来说已经令人困惑,对模型来说也可能如此。避免使用复杂语言和提供不必要的信息。
示例改进:
1 | 改进前: |
具体说明所需的输出形式。简洁的指令可能无法充分引导LLM或过于笼统。
示例:
1 | 生成一篇关于5大视频游戏主机的3段落博客文章。博客文章应该信息丰富且引人入胜,并以对话风格撰写。 |
指令和约束在提示中用于引导LLM输出,但研究表明,专注于积极指令比严重依赖约束更有效:
示例:
1 | 推荐做法: |
通过配置或在提示中明确要求特定长度来控制生成的LLM响应长度:
1 | 用推特长度的消息解释量子物理学。 |
使用变量使提示更加动态和可重用,特别是在集成到应用程序中时:
1 | 变量: |
不同的模型、配置、提示格式、词汇选择可能产生不同结果。因此,尝试不同的提示属性如风格、词汇选择和提示类型(零样本、少样本、系统提示)非常重要。
例如,关于Sega Dreamcast的提示可以表述为:
对于分类任务的少样本提示,确保混合可能的响应类别,避免模型只是记住示例顺序而非学习每个类别的关键特征。
随时了解模型架构变化、添加的数据和新功能。尝试新版模型并调整提示以更好地利用新特性。
考虑实验输出格式,对于非创意任务(如提取、选择、解析、排序、排名或分类数据),尝试使用JSON或XML等结构化格式。
JSON输出优势:
虽然以JSON格式返回数据提供了众多优势,但也存在一些缺点。JSON的结构化特性虽然有利于解析和在应用程序中使用,但需要比纯文本更多的词元,导致处理时间增加和成本提高。此外,JSON的冗长可能轻易消耗整个输出窗口,特别是当生成由于词元限制而突然中断时,这通常会导致缺少关键的闭合大括号或方括号,使输出无法使用。
幸运的是,json-repair库(可在PyPI上获取)在这些情况下非常宝贵。此库智能地尝试自动修复不完整或格式错误的JSON对象。
JSON模式定义了JSON输入的预期结构和数据类型。通过提供模式,您为LLM提供了一个清晰的数据蓝图,帮助它专注于相关信息并减少误解输入的风险。此外,模式可以帮助建立不同数据片段之间的关系,甚至通过包含特定格式的日期或时间戳字段使LLM”时间感知”。
如果您需要尝试制定良好的提示,找多人进行尝试可能会有所帮助。当每个人都遵循最佳实践时,您会看到不同提示尝试之间的性能差异。
详细记录您的提示尝试至关重要,这样您可以随着时间的推移了解什么有效,什么无效。建议使用谷歌表格,包含以下字段:
除了这些字段外,跟踪提示版本(迭代)、结果是否OK/NOT OK/SOMETIMES OK的字段,以及反馈字段也很有帮助。
提示工程是一门艺术,也是一门科学,需要持续的实践和改进。通过掌握本白皮书中详述的各种技术和最佳实践,您可以有效地引导大语言模型产生准确、相关且有用的输出,充分发挥AI的潜力,无论是用于个人项目还是企业级应用。
记住,提示工程是一个迭代过程。设计并测试不同的提示,分析并记录结果。根据模型的表现优化您的提示。不断实验,直到达到所需的输出。当您更换模型或模型配置时,回顾并继续使用先前使用的提示进行实验。
通过这种方法,您将能够与AI系统建立更有效、更精确的交互,释放其真正的潜力。
在与 AI 协作编程,尤其是进行大型项目或跨多个会话工作时,我们常常会遇到一个挑战:AI(如 Cursor)的”记忆”通常是短暂的,它可能在两次交互之间忘记之前的上下文、项目目标或技术决策。为了解决这个问题,社区借鉴了 Cline 的 Memory Bank 概念,并将其适配到了 Cursor 中,旨在为 AI 提供一个持久化的”项目记忆库”。
本文将介绍 Memory Bank 的由来、原理、作用以及如何在 Cursor 中配置和使用它。
以下为论坛帖子截图,展示了 Memory Bank 和 Plan/Act 模式的设置步骤:
[图像描述:一张论坛帖子的截图,标题为 “How to add Cline Memory Bank feature to your cursor”。内容分为三部分:1. 添加 Plan/Act 模式到 cursor agent,包含创建 .cursor/rules/core.mdc 文件和规则代码;2. 添加 Memory Bank 到 cursor agent,引用 Cline 文档并包含创建 .cursor/rules/memory-bank.mdc 文件和规则代码,展示了 Memory Bank 的文件结构图;3. 设置 Memory Bank,包括创建 memory-bank/ 文件夹和要求 Cursor agent 初始化。]
Memory Bank 的概念受到 Cline Memory Bank 的启发,其核心思想是解决 AI 在不同会话间记忆重置的问题。
原理:
projectbrief.md 是基础,定义了项目核心目标,其他文件在此基础上展开。1 | flowchart TD |
Memory Bank 的主要目标是成为 Cursor 理解和参与项目的 唯一可靠信息源。它解决了 AI 短期记忆的问题,确保开发过程的连续性和一致性。具体作用包括:
projectbrief.md, productContext.md)。systemPatterns.md, techContext.md)。activeContext.md, progress.md)。核心文件及其职责:
projectbrief.md: 项目基础,定义核心需求和目标。productContext.md: 项目存在的意义,解决的问题,用户体验目标。activeContext.md: 当前工作焦点,最近变更,下一步计划。systemPatterns.md: 系统架构,关键技术决策,设计模式。techContext.md: 使用的技术,开发设置,技术限制,依赖项。progress.md: 已完成功能,待办事项,当前状态,已知问题。在 Cursor 中启用和使用 Memory Bank 需要以下步骤:
创建规则文件 (.cursor/rules/memory-bank.mdc):
.cursor/rules 文件夹(如果尚不存在)。rules 文件夹内创建一个名为 core.mdc 的文件。rules 文件夹内创建一个名为 memory-bank.mdc 的文件。. 开头的文件或 .mdc 后缀的文件,可以先创建为 memory-bank.md,粘贴内容后,再重命名为 memory-bank.mdc。core.mdc 文件中: 1 | --- |
memory-bank.mdc 文件中: 1 | --- |
创建 Memory Bank 目录 (memory-bank/):
memory-bank 的文件夹。初始化 Memory Bank 文件:
memory-bank/ 文件夹内,创建上述提到的核心 Markdown 文件:projectbrief.mdproductContext.mdactiveContext.mdsystemPatterns.mdtechContext.mdprogress.mdinitialize memory bank“。Cursor 会尝试根据当前项目理解(可能需要你提供信息)来填充这些文件的初始内容。之后你需要检查并完善这些内容。维护和更新:
memory-bank/ 中的 Markdown 文件。update memory bank“。根据规则,它会重新审视所有 Memory Bank 文件,并根据当前状态和你的指示进行更新(尤其关注 activeContext.md 和 progress.md)。(可选)配合 Plan/Act 模式:
core.mdc 规则)。在 Plan 模式下,Cursor 会先读取 Memory Bank 来制定计划;在 Act 模式执行任务后,它可能会被指示更新 Memory Bank(尤其是 progress.md 和 activeContext.md)。
Cursor Memory Bank 提供了一种有效的机制,通过持久化的结构化文档来弥补 AI 短暂记忆的不足。通过强制 AI 在每次任务开始时读取这些信息,可以显著提高其对项目上下文的理解,从而提升协作效率和代码质量。虽然需要投入一些精力来初始化和维护,但对于复杂或长期的项目来说,这种投入往往是值得的。
参考来源:
最近找工作,有些大数据岗位我想投,但是奈何之前的工作内容大数据不是主业,大数据经验不够看,我最早要追溯到15年当时spark+hive,然后17年的storm+hbase,到最近的flink+ck,我觉得我努把力看能不能够一够大数据相关的岗位。
把我给媳妇儿配的打LOL的电脑,偷偷拿来用一用,当成小型服务器,反正性能对LOL来说,很过剩了,不影响。
我之前鼓捣其它技术的时候就在电脑上装了虚拟机,所以也不折腾了,直接装个ubuntu,然后装个docker+docker compose,就差不多了。
单独说下,因为docker默认用的国外的镜像源所以安装后几乎是不可用的,这时候需要配置国内的镜像。
要注意验证镜像源,比如通过curl等命令,看是否能正常访问是否能免验证访问,我就是被阿里云的镜像加速器耽搁了小半小时,就是按照官方的配置始终403,最后才发现,原理阿里前几个月更新了协议,大概意思是,不再支持外部直接用加速镜像,而是支持阿里云本身的产品使用。
1 | # 1. 验证镜像源 |
1 | # 1. 获取ck镜像 |
https://www.coderjia.cn/archives/dba3f94c-a021-468a-8ac6-e840f85867ea
https://hub.docker.com/r/clickhouse/clickhouse-server/
最近准备面试嘛,看到好些JD里,特别是关于大模型的JD,里面有个技能要求Prompt Engineering。刚好我也有兴趣,平时也是claude.ai和chatgpt、deepseek的重度用户,美元都花了好些,问题问的多了,慢慢的知道问题描述的准确性与预期的答案相关性确实很大。确实感觉Prompt Engineering(提示词工程)已经成为一项重要技能。无论你是开发者、内容创作者还是普通用户,掌握这项技能都能帮助你更有效地与AI交流,获得更满意的结果。刚好借此JD机会,更深入的学习下怎么才能写好Prompt。
Prompt Engineering是指设计和优化输入到AI模型(如ChatGPT、Claude等)的提示词的过程,目的是引导AI生成更准确、更符合预期的输出内容。
简单来说,就像我们与人交流时,清晰表达自己的需求会得到更好的回应一样,与AI的交流也需要”说人话”,而Prompt Engineering就是学习如何更好地”对AI说话”的艺术。
一个好的提示词通常包含以下几个要素:
不好的提示词:
1 | 写一篇关于AI的科普文章 |
好的提示词:
1 | 请写一篇800字左右的科普文章,主题是"人工智能的发展历程",适合完全不动技术的人阅读, |
越具体的提示词越能得到准确的回答。包括具体描述:
例子:
1 | 请用简单的语言向我10岁女儿解释光合作用,不超过200字,使用至少2个生活中的比喻,避免使用专业术语。 |
通过提供几个输入-输出的示例,可以更好地引导AI理解你的期望。
例子:
1 | 请按照以下格式将这些句子翻译成英文: |
让AI扮演特定角色,能使回答更符合特定专业或风格需求。
例子:
1 | 请你扮演一位经验丰富的营销专家,分析我的产品定位问题,并提供改进建议。我的产品是一款... |
引导AI一步步思考问题,可以获得更准确的结果,特别是对于复杂问题。
例子:
1 | 请帮我解决这个数学问题,在回答前,请先分析问题,列出已知条件,然后逐步推导求解过程,最后给出结论。 |
明确要求特定的输出格式,使结果更易于使用。
例子:
1 | 请分析这家公司的优势和劣势,并以下面的JSON格式输出结果: |
引导AI展示其思考过程,对于复杂推理特别有效。
例子:
1 | 问题:小明有12个苹果,他给了小红3个,又给了小李他手中苹果数量的一半,最后他还剩下多少个苹果?请一步一步地思考,解释每一步的计算过程和原因。 |
引导AI探索多种可能性和解决方案路径。
例子:
1 | 请用思维树的方式分析我创业的三个不同选择(开咖啡店、做在线教育、开发APP),每个选择探索三个可能的发展路径,考虑不同条件下的结果,然后总结最优选择。 |
让AI评估自己的输出并进行改进。
例子:
1 | 请写一篇关于气候变化的短文,然后评估这篇文章的优缺点,并基于评估给出一个改进版本。 |
例子:
1 | 请为我的科技博客生成一篇文章大纲,主题是"5G技术如何改变我们的生活"。大纲应包含引言、3-5个主要部分、每部分2-3个小节,以及结论。每个小节都需要有简短描述。 |
例子:
1 | 我正在设计一个以"海洋保护"为主题的儿童故事书。请创作5个可能的故事情节,每个情节包含主角描述、基本冲突和教育意义。 |
例子:
1 | 我有一组销售数据,包含产品名称、月份和销售额。请帮我分析这些数据,找出销售趋势,并提出改进建议。数据如下: |
例子:
1 | 请编写一个Python函数,用于分析文本情感倾向。函数应接受一段文本作为输入,返回积极、消极或中性的评价以及置信度分数。请包含必要的注释和简单的使用示例。 |
免费课程与教程
免费电子书与指南
免费在线社区与资源
免费网站
Prompt Engineering不仅是一项技术技能,更是一门艺术。通过不断实践和调整,你会发现与AI交流的效率和质量都会显著提升。记住,最好的学习方式是实践——从今天开始尝试这些技巧,记录效果,持续改进。

根据图中内容,HTTPS(Hypertext Transfer Protocol Secure)的工作原理可以分为三个关键步骤:
这是建立安全连接的第一步:
这一步确保了用户正在与合法网站通信,而不是某个冒充者。证书颁发机构作为可信第三方,保证了服务器的身份。
验证服务器身份后,需要建立加密通信:
此时,服务器也拥有了会话密钥,为后续加密通信做好准备。
在完成前两步后:
这形成了一个安全的加密通信隧道,即使数据在传输过程中被拦截,没有会话密钥的第三方也无法解密内容,保证了数据传输的安全性。
作为一个研发不到10人的团队,从0到1构建SAAS平台,且每周需要发布2-3个版本,所以总有些团队管理等问题会慢慢暴露,我们再慢慢修复,就跟修BUG一样,这一篇就是因为上线出过SQL脚本的问题(阿里云的SQL控制台对一些写的不太规范的sql执行存在兼容性问题会导致SQL执行不符合预期),所以有了这篇SQL规范,先说问题,当前SQL脚本管理存在以下问题:
本规范旨在提供一套简单、实用且专业的SQL脚本管理方案,帮助团队高效管理数据库变更,可根据实践情况持续优化。
采用精简的目录结构,既能满足版本管理需求,又不过于复杂:
1 | /PG # 数据库名称 |
采用序号_描述[_rollback].sql格式:
001、002create_user_table、add_email_column_rollback后缀示例:
001_create_user_table.sql001_create_user_table_rollback.sql表命名:
sys_user、order_item列命名:
identity_id格式,如user_idcreate_time、update_time索引命名:
pk_表名uk_表名_列名idx_表名_列名所有SQL脚本必须包含统一的文件头注释:
1 | -- ======================================== |
原子性:一个脚本只完成一个独立任务
幂等性:脚本可以重复执行而不产生副作用
1 | -- 好的做法 |
向后兼容:尽量避免破坏性变更
1 | -- 推荐 |
安全性:敏感信息不应明文存储
关键字大写:所有SQL关键字使用大写形式
1 | SELECT * FROM users WHERE status = 'active'; |
适当缩进:使用一致的缩进提高可读性
1 | SELECT |
添加注释:为复杂SQL语句添加适当注释
1 | 数据字典和菜单: |
针对高频发版小团队,简化流程但不降低质量要求:
1 | graph TD |
为确保数据库变更的安全有序,按以下顺序执行:
团队应当将本规范视为基础标准,在实践中不断完善和优化,形成最适合团队的工作方式。
亲爱的招聘团队:
如果软件工程师是一道菜,那我就是那种经过12年慢火熬制的老汤底——看起来平淡无奇,但一尝就知道功夫在里头。
我的技术栈就像一个资深玩家的技能树:主技能点满了Java和React,副技能解锁了Vue、Docker、Python和Go等。在我的职业旅程中,我善于将复杂问题分解为简单模块,轻松应对各种技术挑战。但我最厉害的外挂其实是曾经当过产品助理——这让我不仅能听懂产品经理说的”简单调整”背后隐藏的36个子需求,还能在技术与业务之间自如翻译,堪称”产品语言通”。
在我的12年职业生涯中,我从”这bug在本地没问题啊”进化到了”这需求有啥实际意义”再到”好的,我来搞定!”。带团队的经历让我明白,比起Debug代码,Debug人际关系才是真正的高难度挑战。所幸,我在这两方面都交出了不错的成绩单。
相信我的技术能力、产品思维和团队协作经验能为您的团队带来实质性的贡献。代码之外,我能够搭建开发者与产品、业务之间的桥梁,确保我们不只是在开发功能,而是在创造价值。我们一定能擦出技术的火花——毕竟,一个能理解产品、带过团队、写了12年代码还没秃顶的工程师,不是每天都能遇到的。
代码问候,
[软件开发特种兵]
联系方式:
电话:[18515068121]
邮箱:[gamehu@yeah.net]
Wechat:[GamehuDB]
P.S. 我的GitHub贡献图可能不够绿,但我的生产环境代码从不让服务器变红。
Dear Hiring Team:
If software engineers were dishes, I’d be that slow-simmered stock that’s been cooking for 12 years — looking unassuming, but one taste reveals the expertise within.
My tech stack resembles a veteran player’s skill tree: maxed-out primary skills in Java and React, with unlocked secondary abilities in Vue, Docker, Python, Go, and more. Throughout my professional journey, I’ve honed the ability to break complex problems into simple modules, easily tackling various technical challenges. But my most powerful perk comes from my experience as a product assistant — I can decode the 36 hidden sub-requirements behind a product manager’s “simple adjustment” and fluently translate between technical and business languages, making me a true “product whisperer.”
During my 12-year career, I’ve evolved from “but the bug doesn’t appear on my local machine” to “what’s the actual purpose of this requirement” to “I’ll handle it!” My team leadership experience taught me that debugging human relationships is far more challenging than debugging code. Fortunately, I’ve managed to achieve good results in both areas.
I believe my technical abilities, product mindset, and team collaboration experience will bring substantial value to your team. Beyond coding, I can build bridges between developers, product teams, and business units, ensuring we’re not just developing features but creating value. We’ll definitely create technical sparks together — after all, an engineer who understands products, has led teams, and has written code for 12 years without going bald isn’t someone you meet every day.
Code regards,
[Software Development Special Forces]
Contact Information:
twitter:[Gamehu520]
email:[gamehu@yeah.net]
Wechat:[GamehuDB]
P.S. My GitHub contribution graph might not be very green, but my production code never turns servers red.
很多人听到 Skills 第一反应:不就是保存的提示词吗?
这是个误解。
Skills ≠ 提示词模板
Skills 更像是AI 的专业工具包——就像人类专家脑子里随时能调用的知识库。你不用每次都解释”什么是好的 UX 设计”,而是告诉 Claude:”用 iOS 设计专家的脑子帮我看看这段代码”。
技术上说,它是可复用的指令集:定义方法、遵循模式、输出格式。优势就是不用每次从零开始解释需求。
作者有个有趣的比喻:Skills 像强化版的保存提示词。你不用每次都解释想要什么,只要调用某个 Skill,Claude 就知道该用什么”剧本”。
作者最近实验了一个工作流:Claude 生成 PRD → 设计工具出图 → Figma → Claude Code 用 SwiftUI 构建应用。
跑通了,但不对劲:硬编码文本样式、间距不一致、导航像混合应用不像原生 iOS。
然后他试了 mobile-ios-design 这个 Skill。
它会扫描整个应用,强制执行 iOS Human Interface Guidelines:修正系统颜色、应用原生导航、使用正确的文本样式。
结果:初次构建后跑一次,应用突然就像”苹果原生出品”了。
我的感受:不是说 Claude 不懂 iOS 规范,问题是如果你每次都要告诉它按 HIG 设计,那还不如自己写。有了 Skill,一个命令就能让 Claude 像专业 iOS 开发者那样思考。
Impeccable 是设计工具包,有 15+ 子技能。作者常用这几个:
| 子技能 | 用途 | 解决什么问题 |
|---|---|---|
| critique | 感觉”哪里不对”但说不上来 | 获取 UX 反馈,找痛点 |
| polish | 交付前最后检查 | 对齐、间距、一致性 |
| simplify | 过度设计需要做减法 | 剥离到核心要素 |
| normalize | AI 生成的组件不符设计系统 | 匹配现有 tokens |
工作流变化:以前 Figma 里手动调 → 导出代码 → 再调;现在直接 impeccable:polish 在代码层面优化。
这不是说 Figma 没用了,而是**”设计”可以从代码层面开始**,而不是必须从 Figma 开始。
作者在电商公司,团队维护 4 个平台。每次上新功能前要做大量研究——“正确”的话可能很久。
但有时候只是想快速验证一个想法:没有 sprint planning,没有 Jira tickets,没有 OKR meetings。只想要一个快速回答:**”这是个好主意吗?”**
所以他做了这个 Skill。
你给 Skill 一个功能想法,Claude 跑六个阶段:
可以按顺序全做,也可以每个阶段后停下来评估。作者用它解决的问题:”桌面端导航用汉堡菜单好吗”、”iOS 列表页要不要加单列视图”。
他的结论:”它不会替代思考,但能帮我更快评估一个想法是否值得深挖。”
这个是给个人项目用的,相对更简单有趣。
流程:给 Claude Code 一个 niche(比如 “sleep apps”),它开始干活:
场景:输入 “sleep apps”,几小时后拿到的原型——基于真实用户抱怨,不是个人假设。
作者说:”这原型可能没那么’高级’,但能直接用。想继续做的话,之后再优化品牌和设计。”
他的反思:”不是每次都能找到金子。但把 ‘我想看看 X 领域有没有机会’ 从周末研究项目,变成了做别的事时能自动跑的任务。”
作者这句话点到了核心:
“Claude Code 本身很强大。你能构建应用、修复 bug、交付项目。”
“但加了 Skills 的 Claude Code 是完全不同的工具。它不是’帮我把这个做出来’,而是’如果我有无限时间,我会怎样做这个——帮我按那个标准做出来’。”
**从”能跑通”到”像专业工程师那样做”**:
| 维度 | Claude Code 原生 | Claude Code + Skills |
|---|---|---|
| 产出质量 | 能用,但有各种问题 | 符合专业标准 |
| 知识调用 | 每次要解释 | 一次定义,永久复用 |
| 时间分配 | 80% 调细节 | 80% 思考核心问题 |
mobile-ios-design 比 HIG 文档背得熟;Impeccable 能发现注意不到的设计问题;Feature Discovery 做懒得做的竞品研究;Niche Hunter 探索永远不会去做的事情。
**不是”替代”而是”赋能”**。Skills 不会让你的判断力消失,它释放时间让你专注在真正重要的事上:这个想法值得继续吗?这个设计够好吗?现在该做什么?
作者的建议:
从小处入手
找每天做、重复性高、烦人的任务,变成 Skill:
design-system skillbest-practices skillsecurity-review skill不要追求完美
先让跑通,再迭代优化。
分享你的 Skills
公开本身就是机会。作者当初没投简历,只是在 X 上发小项目、踩过的坑、试过的提示词。公司的人看到了,主动找过来。
作品就是机会。
想起那句话:当”把东西做出来”变得无比廉价,什么会变得无比稀缺?
清晰度、品味、判断力。
Skills 能帮你快速做到”能跑通”,甚至”符合专业标准”。
但真正的魔法感——让用户第一次点开页面时心里”哇”一声;让同事用你的内部工具时感觉”这比商业软件还顺手”——仍然来自你。
来自你的判断力:知道什么该留,什么该砍,什么该磨三天,什么该一键生成。
来自你的清晰度:能把脑子里那团模糊兴奋的感觉,翻译成工具能理解的指令。
来自你的品味:能区分”还行”和”惊艳”,能在所有人都满足于”跑通了”时,对自己说:
“还可以更好。”