1. 这个项目到底在解决什么问题第一次看到“free-claude-code”这个标题我脑子里蹦出来的第一个念头是又是一个蹭热度的壳子。但仔细拆进去看它其实指向了一个非常具体、非常真实的痛点——在终端里用自然语言指挥一个代码助手干活同时把成本压到接近于零。说白了它做的事情是把 Claude 这类大模型的代码能力通过一个命令行工具暴露出来让你在终端里直接问“帮我重构这个函数”“这个报错什么意思”“给我写个正则匹配日期”然后它把结果吐回来。而“free”这个词核心卖点就在于不花订阅费、不绑信用卡、不依赖官方付费 API而是走一条更轻的路子。这个项目适合谁三类人最该关注天天泡在终端里的后端和运维懒得切浏览器、懒得开 IDE 插件就想在 shell 里把问题解决掉学生党和个人开发者预算有限但又想体验大模型辅助编码的真实手感想研究 CLI LLM 集成方案的人想看看一个命令行 AI 助手从零到跑通中间要处理哪些工程细节。它解决的问题不是“让 AI 写代码”这么泛而是把 AI 编码能力塞进一个零成本、零配置负担的终端工作流里。这一点才是它跟一堆同类工具拉开差距的地方。2. 整体设计思路与方案选型拆解2.1 为什么是命令行而不是插件或网页我试过不少 AI 编码工具插件类的、网页类的、IDE 内置的都用过一圈。最后发现一个规律越是贴近你原本工作流的东西越容易被长期用下去。插件的问题在于它绑死在某个编辑器上。你换个编辑器、换台机器、SSH 到远程服务器插件就没了。网页的问题更明显你得复制代码出去、粘贴结果回来中间还要切窗口打断思路。命令行的优势在于它是操作系统级别的通用接口。不管你用什么编辑器、连的是本地还是远程、跑的是 Linux 还是 macOS只要有 shell它就能用。而且命令行天然适合管道操作你可以把它的输出直接喂给下一个命令这是插件和网页做不到的。所以这个项目选 CLI 作为载体我认为是经过深思熟虑的不是图省事。2.2 “free”背后的成本控制逻辑标题里最扎眼的就是“free”。这里得说清楚免费不等于没有成本而是把成本从“按 token 付费”转移到了“用其他资源换”。常见的几条路子方案类型成本来源稳定性上手难度官方付费 API按量计费高低免费额度 API额度耗尽即停中低本地模型推理电费硬件中高社区共享池排队限速低中这个项目大概率走的是免费额度 本地缓存 请求复用的组合拳。核心思路是把重复的问题缓存下来把能本地判断的简单逻辑本地处理只在真正需要大模型的时候才发请求。这样一来同样的免费额度能撑更久。提示任何号称“完全免费”的 AI 工具背后一定有成本转移。要么是你的硬件在扛要么是额度在扛要么是排队时间在扛。想清楚你愿意付出哪一种再决定要不要用。2.3 架构上的关键取舍一个 CLI 版代码助手架构上要解决三个核心问题怎么跟模型通信——是直接 HTTP 请求还是走 SDK还是走中间层怎么管理上下文——终端里没有编辑器那种天然的文件感知得自己把相关代码喂进去怎么保证响应速度——终端用户对延迟极其敏感超过三秒就开始烦躁。我推测这个项目的做法是轻量 HTTP 客户端 本地上下文收集器 流式输出。流式输出这点特别关键它让用户感觉“它在思考”而不是“它卡住了”。哪怕总耗时一样流式体验就是比一次性返回好得多。3. 核心细节解析与实操要点3.1 环境准备别一上来就装一堆东西很多人拿到这类工具第一反应是把 README 里所有依赖全装一遍。我的建议是先跑最小闭环。你需要的基础环境其实就三样一个能用的终端bash、zsh、fish 都行一个运行时Node.js 或 Python看项目用什么写的一个可用的模型接入方式免费额度或本地模型。先别急着配代理、别急着装插件、别急着改配置文件。先用最裸的方式跑通一次“提问-回答”确认链路是通的再去优化体验。# 以 Node.js 项目为例最小验证流程 node --version # 确认运行时版本 npm install -g 包名 # 全局安装 命令 写一个快速排序 # 直接提问看有没有输出如果这一步就报错那问题一定在环境或网络层跟工具本身无关。先把这层排掉后面会省很多事。3.2 上下文注入终端助手的命门终端里最大的劣势是没有编辑器的文件感知能力。你在 IDE 里问 AI它能自动看到你当前打开的文件、光标位置、选中代码。终端里什么都没有你得自己告诉它。这个项目在这块的处理方式我推测有几种可能手动指定文件命令 --file src/main.js 解释这个文件管道输入cat src/main.js | 命令 找 bug目录扫描自动读取当前目录下的相关文件拼成上下文。我个人最推荐管道输入这种方式。它符合 Unix 哲学灵活度最高而且你可以用head、grep、sed先对内容做预处理只把真正相关的部分喂给模型。# 只把报错相关的代码段喂进去省 token sed -n 120,160p src/service.js | 命令 这段代码为什么空指针注意上下文不是越多越好。喂太多无关代码模型反而容易抓不住重点还会浪费额度。精准比海量重要。3.3 提示词的组织方式命令行工具的一个隐藏难点是用户输入往往很短、很口语。比如“这啥意思”“帮我改改”“报错了”。模型拿到这种输入如果没有额外引导输出质量会很不稳定。所以这类项目通常会在用户输入外面包一层系统提示词把角色、输出格式、约束条件都定好。我见过做得比较好的做法是系统层固定角色“你是一个资深工程师回答简洁直接给代码和原因”用户层保留原始输入不做过度改写输出层强制格式先给结论再给代码最后给注意事项。这样即使用户只打三个字返回的结果也是结构化的。这一点在长期使用中特别重要它决定了这个工具是“能用”还是“好用”。3.4 缓存与去重免费额度的续命关键既然是“free”那额度就是稀缺资源。我实测下来日常提问里有相当一部分是重复的——“这个报错什么意思”“怎么格式化日期”“正则怎么写”。这些问题完全可以缓存。一个实用的缓存策略是对用户输入做归一化去空格、转小写、去掉标点算一个哈希值作为 key命中缓存直接返回不消耗额度设置合理的过期时间避免返回过时答案。// 缓存逻辑示意 const key normalize(input); if (cache.has(key) !isExpired(key)) { return cache.get(key); } const result await callModel(input); cache.set(key, result); return result;这个逻辑不复杂但对免费额度的节省效果非常明显。我自己的使用场景里缓存命中率能到三成左右等于白捡了三分之一的额度。4. 实操过程与核心环节实现4.1 从零跑通第一个请求假设你已经装好了工具接下来是完整的跑通流程。我按实际操作顺序拆一遍。第一步确认命令入口。装完之后先看帮助信息确认命令名和基本参数。命令 --help这一步别跳过。很多工具的默认行为跟你想象的不一样比如有的默认读标准输入有的默认读参数搞错了就会卡住不动。第二步发一个最简单的请求。不要一上来就喂复杂代码先用一句话测试链路。命令 11等于几如果这个能正常返回说明网络、鉴权、模型调用这条链路是通的。如果卡住或者报错问题就在这一层。第三步测试代码理解能力。喂一段短代码看它能不能正确解释。echo function add(a,b){return ab} | 命令 解释这个函数第四步测试代码生成能力。让它写一段代码看输出格式是否可直接使用。命令 写一个防抖函数用 JavaScript第五步测试多轮上下文。看它能不能记住上一轮的内容。命令 刚才那个防抖函数加上立即执行选项这五步走完你对这个工具的能力边界基本就有数了。4.2 参数配置与调优大部分这类工具都支持配置文件常见的位置是用户目录下的隐藏文件夹。核心可调参数一般包括参数作用推荐值说明model指定模型默认即可不同模型能力和额度不同temperature输出随机性0.2-0.3代码场景要稳定别太高max_tokens单次输出上限1024-2048太大浪费额度太小截断timeout请求超时30s网络差可适当调大cache是否启用缓存开启省额度关键temperature 这个参数特别值得说。很多人不知道它是什么简单讲就是控制模型“发挥”的程度。写代码要的是准确和稳定不是创意所以调到 0.2 左右最合适。调到 1.0 以上同样的提示词每次给的答案都不一样反而不好用。4.3 把它接进日常工作流工具跑通只是第一步真正产生价值是把它嵌进你已有的工作流。我分享几个自己常用的组合。场景一看报错。跑测试报错时直接把错误信息管道进去。npm test 21 | tail -20 | 命令 这个报错怎么修场景二快速理解陌生代码。接手新项目时扫一遍核心文件。cat src/core/*.js | 命令 总结这个模块的职责和主要接口场景三生成提交信息。改完代码让 AI 根据 diff 写 commit message。git diff --staged | 命令 根据这个改动写一条 commit message场景四写测试。把函数贴进去让它生成测试用例。sed -n 1,50p src/utils.js | 命令 给这些函数写单元测试这几个场景的共同点是输入来自你本来就要做的事输出直接能用。不需要额外复制粘贴不需要切换窗口这才是命令行工具的真正价值。4.4 性能与延迟优化终端用户对延迟的容忍度极低。我实测下来超过三秒没有反馈人就会开始怀疑是不是卡了。所以延迟优化是刚需。几个有效的做法开启流式输出让结果一个字一个字往外蹦用户能感知到进度缩短上下文只喂相关代码别整个文件往里塞本地预处理能用 grep、sed 过滤的别丢给模型并发请求多个独立问题可以并行发别串行等。流式输出这块如果工具本身不支持可以考虑用stdbuf或者unbuffer强制刷新缓冲区让输出实时可见。stdbuf -oL 命令 写个快排5. 常见问题与排查技巧实录5.1 请求卡住不动怎么办这是最常见的问题。表现是命令执行后光标一直闪没有任何输出。排查顺序先确认网络curl一个公共接口看能不能通确认鉴权检查配置文件里的 key 或 token 是否正确确认额度免费额度可能已经耗尽换一个接入方式试试确认超时设置有些工具默认超时很短网络慢就会静默失败。我踩过最坑的一次是配置文件路径写错了工具读的是默认配置一直用空 key 请求结果就是无限等待。先看日志再看配置最后看网络这个顺序能省很多时间。5.2 输出被截断回答到一半突然没了通常是max_tokens设太小。代码场景建议至少 1024复杂重构可以到 2048。但也有另一种情况模型本身输出就长但工具没做分片处理。这时候可以换个问法让它分步骤回答。命令 分三步解释这个重构方案每步单独输出5.3 回答质量不稳定同一个问题有时候答得好有时候答得离谱。原因通常是temperature 太高调到 0.2 试试上下文太杂喂了无关代码干扰了判断提示词太模糊把“帮我看看”改成“找出这段代码的空指针风险”。我个人的经验是提示词里带上具体目标输出质量能提升一大截。别指望模型猜你想干嘛直接说清楚。5.4 免费额度消耗太快这是“free”类工具的通病。几个续命技巧技巧效果实施难度开启本地缓存高低精简上下文高中本地预处理过滤中中合并同类问题中低错峰使用低低缓存和精简上下文是性价比最高的两个。我自己的做法是凡是能用 grep 解决的问题绝不问模型。模型只用来处理真正需要理解语义的部分。5.5 中文输入乱码终端编码问题老生常谈。检查LANG和LC_ALL环境变量确保是 UTF-8。echo $LANG export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8如果还是乱码可能是终端模拟器本身的编码设置问题换个终端试试。6. 我对这类工具的真实看法用了一段时间这类命令行 AI 助手我最大的体会是它的价值不在于替代 IDE 插件而在于填补插件覆盖不到的场景。远程服务器上、纯终端环境里、快速脚本处理时这些场景插件进不来但命令行工具能进。它不需要你改变工作习惯只需要你在原本的命令后面加一个管道。另一个体会是“free”这个卖点要理性看待。免费意味着你在某个维度上付出了代价可能是速度、可能是稳定性、可能是额度上限。想清楚自己最在意什么再决定用哪种方案。如果你的时间比额度值钱那付费方案反而更划算如果你就是想零成本试试水那这类工具确实是个不错的入口。最后分享一个我自己的小习惯把常用的提问模板存成 shell 别名。比如alias fix命令 找出这段代码的 bug 并给出修复方案用的时候直接cat file | fix省去每次打一长串提示词的麻烦。这个习惯让我用它的频率高了不少因为摩擦成本降下来了。工具好不好用很多时候不取决于工具本身而取决于你有没有把它磨成适合自己手型的样子。
1. 这个项目到底在解决什么问题第一次看到“free-claude-code”这个标题我脑子里蹦出来的第一个念头是又是一个蹭热度的壳子。但仔细拆进去看它其实指向了一个非常具体、非常真实的痛点——在终端里用自然语言指挥一个代码助手干活同时把成本压到接近于零。说白了它做的事情是把 Claude 这类大模型的代码能力通过一个命令行工具暴露出来让你在终端里直接问“帮我重构这个函数”“这个报错什么意思”“给我写个正则匹配日期”然后它把结果吐回来。而“free”这个词核心卖点就在于不花订阅费、不绑信用卡、不依赖官方付费 API而是走一条更轻的路子。这个项目适合谁三类人最该关注天天泡在终端里的后端和运维懒得切浏览器、懒得开 IDE 插件就想在 shell 里把问题解决掉学生党和个人开发者预算有限但又想体验大模型辅助编码的真实手感想研究 CLI LLM 集成方案的人想看看一个命令行 AI 助手从零到跑通中间要处理哪些工程细节。它解决的问题不是“让 AI 写代码”这么泛而是把 AI 编码能力塞进一个零成本、零配置负担的终端工作流里。这一点才是它跟一堆同类工具拉开差距的地方。2. 整体设计思路与方案选型拆解2.1 为什么是命令行而不是插件或网页我试过不少 AI 编码工具插件类的、网页类的、IDE 内置的都用过一圈。最后发现一个规律越是贴近你原本工作流的东西越容易被长期用下去。插件的问题在于它绑死在某个编辑器上。你换个编辑器、换台机器、SSH 到远程服务器插件就没了。网页的问题更明显你得复制代码出去、粘贴结果回来中间还要切窗口打断思路。命令行的优势在于它是操作系统级别的通用接口。不管你用什么编辑器、连的是本地还是远程、跑的是 Linux 还是 macOS只要有 shell它就能用。而且命令行天然适合管道操作你可以把它的输出直接喂给下一个命令这是插件和网页做不到的。所以这个项目选 CLI 作为载体我认为是经过深思熟虑的不是图省事。2.2 “free”背后的成本控制逻辑标题里最扎眼的就是“free”。这里得说清楚免费不等于没有成本而是把成本从“按 token 付费”转移到了“用其他资源换”。常见的几条路子方案类型成本来源稳定性上手难度官方付费 API按量计费高低免费额度 API额度耗尽即停中低本地模型推理电费硬件中高社区共享池排队限速低中这个项目大概率走的是免费额度 本地缓存 请求复用的组合拳。核心思路是把重复的问题缓存下来把能本地判断的简单逻辑本地处理只在真正需要大模型的时候才发请求。这样一来同样的免费额度能撑更久。提示任何号称“完全免费”的 AI 工具背后一定有成本转移。要么是你的硬件在扛要么是额度在扛要么是排队时间在扛。想清楚你愿意付出哪一种再决定要不要用。2.3 架构上的关键取舍一个 CLI 版代码助手架构上要解决三个核心问题怎么跟模型通信——是直接 HTTP 请求还是走 SDK还是走中间层怎么管理上下文——终端里没有编辑器那种天然的文件感知得自己把相关代码喂进去怎么保证响应速度——终端用户对延迟极其敏感超过三秒就开始烦躁。我推测这个项目的做法是轻量 HTTP 客户端 本地上下文收集器 流式输出。流式输出这点特别关键它让用户感觉“它在思考”而不是“它卡住了”。哪怕总耗时一样流式体验就是比一次性返回好得多。3. 核心细节解析与实操要点3.1 环境准备别一上来就装一堆东西很多人拿到这类工具第一反应是把 README 里所有依赖全装一遍。我的建议是先跑最小闭环。你需要的基础环境其实就三样一个能用的终端bash、zsh、fish 都行一个运行时Node.js 或 Python看项目用什么写的一个可用的模型接入方式免费额度或本地模型。先别急着配代理、别急着装插件、别急着改配置文件。先用最裸的方式跑通一次“提问-回答”确认链路是通的再去优化体验。# 以 Node.js 项目为例最小验证流程 node --version # 确认运行时版本 npm install -g 包名 # 全局安装 命令 写一个快速排序 # 直接提问看有没有输出如果这一步就报错那问题一定在环境或网络层跟工具本身无关。先把这层排掉后面会省很多事。3.2 上下文注入终端助手的命门终端里最大的劣势是没有编辑器的文件感知能力。你在 IDE 里问 AI它能自动看到你当前打开的文件、光标位置、选中代码。终端里什么都没有你得自己告诉它。这个项目在这块的处理方式我推测有几种可能手动指定文件命令 --file src/main.js 解释这个文件管道输入cat src/main.js | 命令 找 bug目录扫描自动读取当前目录下的相关文件拼成上下文。我个人最推荐管道输入这种方式。它符合 Unix 哲学灵活度最高而且你可以用head、grep、sed先对内容做预处理只把真正相关的部分喂给模型。# 只把报错相关的代码段喂进去省 token sed -n 120,160p src/service.js | 命令 这段代码为什么空指针注意上下文不是越多越好。喂太多无关代码模型反而容易抓不住重点还会浪费额度。精准比海量重要。3.3 提示词的组织方式命令行工具的一个隐藏难点是用户输入往往很短、很口语。比如“这啥意思”“帮我改改”“报错了”。模型拿到这种输入如果没有额外引导输出质量会很不稳定。所以这类项目通常会在用户输入外面包一层系统提示词把角色、输出格式、约束条件都定好。我见过做得比较好的做法是系统层固定角色“你是一个资深工程师回答简洁直接给代码和原因”用户层保留原始输入不做过度改写输出层强制格式先给结论再给代码最后给注意事项。这样即使用户只打三个字返回的结果也是结构化的。这一点在长期使用中特别重要它决定了这个工具是“能用”还是“好用”。3.4 缓存与去重免费额度的续命关键既然是“free”那额度就是稀缺资源。我实测下来日常提问里有相当一部分是重复的——“这个报错什么意思”“怎么格式化日期”“正则怎么写”。这些问题完全可以缓存。一个实用的缓存策略是对用户输入做归一化去空格、转小写、去掉标点算一个哈希值作为 key命中缓存直接返回不消耗额度设置合理的过期时间避免返回过时答案。// 缓存逻辑示意 const key normalize(input); if (cache.has(key) !isExpired(key)) { return cache.get(key); } const result await callModel(input); cache.set(key, result); return result;这个逻辑不复杂但对免费额度的节省效果非常明显。我自己的使用场景里缓存命中率能到三成左右等于白捡了三分之一的额度。4. 实操过程与核心环节实现4.1 从零跑通第一个请求假设你已经装好了工具接下来是完整的跑通流程。我按实际操作顺序拆一遍。第一步确认命令入口。装完之后先看帮助信息确认命令名和基本参数。命令 --help这一步别跳过。很多工具的默认行为跟你想象的不一样比如有的默认读标准输入有的默认读参数搞错了就会卡住不动。第二步发一个最简单的请求。不要一上来就喂复杂代码先用一句话测试链路。命令 11等于几如果这个能正常返回说明网络、鉴权、模型调用这条链路是通的。如果卡住或者报错问题就在这一层。第三步测试代码理解能力。喂一段短代码看它能不能正确解释。echo function add(a,b){return ab} | 命令 解释这个函数第四步测试代码生成能力。让它写一段代码看输出格式是否可直接使用。命令 写一个防抖函数用 JavaScript第五步测试多轮上下文。看它能不能记住上一轮的内容。命令 刚才那个防抖函数加上立即执行选项这五步走完你对这个工具的能力边界基本就有数了。4.2 参数配置与调优大部分这类工具都支持配置文件常见的位置是用户目录下的隐藏文件夹。核心可调参数一般包括参数作用推荐值说明model指定模型默认即可不同模型能力和额度不同temperature输出随机性0.2-0.3代码场景要稳定别太高max_tokens单次输出上限1024-2048太大浪费额度太小截断timeout请求超时30s网络差可适当调大cache是否启用缓存开启省额度关键temperature 这个参数特别值得说。很多人不知道它是什么简单讲就是控制模型“发挥”的程度。写代码要的是准确和稳定不是创意所以调到 0.2 左右最合适。调到 1.0 以上同样的提示词每次给的答案都不一样反而不好用。4.3 把它接进日常工作流工具跑通只是第一步真正产生价值是把它嵌进你已有的工作流。我分享几个自己常用的组合。场景一看报错。跑测试报错时直接把错误信息管道进去。npm test 21 | tail -20 | 命令 这个报错怎么修场景二快速理解陌生代码。接手新项目时扫一遍核心文件。cat src/core/*.js | 命令 总结这个模块的职责和主要接口场景三生成提交信息。改完代码让 AI 根据 diff 写 commit message。git diff --staged | 命令 根据这个改动写一条 commit message场景四写测试。把函数贴进去让它生成测试用例。sed -n 1,50p src/utils.js | 命令 给这些函数写单元测试这几个场景的共同点是输入来自你本来就要做的事输出直接能用。不需要额外复制粘贴不需要切换窗口这才是命令行工具的真正价值。4.4 性能与延迟优化终端用户对延迟的容忍度极低。我实测下来超过三秒没有反馈人就会开始怀疑是不是卡了。所以延迟优化是刚需。几个有效的做法开启流式输出让结果一个字一个字往外蹦用户能感知到进度缩短上下文只喂相关代码别整个文件往里塞本地预处理能用 grep、sed 过滤的别丢给模型并发请求多个独立问题可以并行发别串行等。流式输出这块如果工具本身不支持可以考虑用stdbuf或者unbuffer强制刷新缓冲区让输出实时可见。stdbuf -oL 命令 写个快排5. 常见问题与排查技巧实录5.1 请求卡住不动怎么办这是最常见的问题。表现是命令执行后光标一直闪没有任何输出。排查顺序先确认网络curl一个公共接口看能不能通确认鉴权检查配置文件里的 key 或 token 是否正确确认额度免费额度可能已经耗尽换一个接入方式试试确认超时设置有些工具默认超时很短网络慢就会静默失败。我踩过最坑的一次是配置文件路径写错了工具读的是默认配置一直用空 key 请求结果就是无限等待。先看日志再看配置最后看网络这个顺序能省很多时间。5.2 输出被截断回答到一半突然没了通常是max_tokens设太小。代码场景建议至少 1024复杂重构可以到 2048。但也有另一种情况模型本身输出就长但工具没做分片处理。这时候可以换个问法让它分步骤回答。命令 分三步解释这个重构方案每步单独输出5.3 回答质量不稳定同一个问题有时候答得好有时候答得离谱。原因通常是temperature 太高调到 0.2 试试上下文太杂喂了无关代码干扰了判断提示词太模糊把“帮我看看”改成“找出这段代码的空指针风险”。我个人的经验是提示词里带上具体目标输出质量能提升一大截。别指望模型猜你想干嘛直接说清楚。5.4 免费额度消耗太快这是“free”类工具的通病。几个续命技巧技巧效果实施难度开启本地缓存高低精简上下文高中本地预处理过滤中中合并同类问题中低错峰使用低低缓存和精简上下文是性价比最高的两个。我自己的做法是凡是能用 grep 解决的问题绝不问模型。模型只用来处理真正需要理解语义的部分。5.5 中文输入乱码终端编码问题老生常谈。检查LANG和LC_ALL环境变量确保是 UTF-8。echo $LANG export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8如果还是乱码可能是终端模拟器本身的编码设置问题换个终端试试。6. 我对这类工具的真实看法用了一段时间这类命令行 AI 助手我最大的体会是它的价值不在于替代 IDE 插件而在于填补插件覆盖不到的场景。远程服务器上、纯终端环境里、快速脚本处理时这些场景插件进不来但命令行工具能进。它不需要你改变工作习惯只需要你在原本的命令后面加一个管道。另一个体会是“free”这个卖点要理性看待。免费意味着你在某个维度上付出了代价可能是速度、可能是稳定性、可能是额度上限。想清楚自己最在意什么再决定用哪种方案。如果你的时间比额度值钱那付费方案反而更划算如果你就是想零成本试试水那这类工具确实是个不错的入口。最后分享一个我自己的小习惯把常用的提问模板存成 shell 别名。比如alias fix命令 找出这段代码的 bug 并给出修复方案用的时候直接cat file | fix省去每次打一长串提示词的麻烦。这个习惯让我用它的频率高了不少因为摩擦成本降下来了。工具好不好用很多时候不取决于工具本身而取决于你有没有把它磨成适合自己手型的样子。
