Home on AI Developer Starter

关于本站

Mon, 13 Apr 2026 11:22:38 +0800

关于本站

本站主要记录 bestony 的 AI 之旅；

选题建议

我的日常有非常多的经验，但受限于知识的诅咒，我并不知道你想要什么，所以，你可以点击你想知道什么? ，来提交你感兴趣的问题。我会结合我自己的经验和体会，撰写相关的文章。

请放心大胆的来蒸馏我吧！

一日一技：使用 Claude Code Usage Monitor 做个用量大屏

Sun, 31 Aug 2025 10:17:27 +0800

在你的 Claude Code 中 CCUsage 来检测当前对话用量中，我介绍了如何在 Claude Code 中加入一个统计 UI，实现展示内容。

但他的分析主要还是一边修改代码一边看。如果你和我一样，平时会开多个窗口来干活，这个时候看每个窗口的统计就有点累了，而 ccusage 展示的表格的方式又不够有趣，这个时候，你就可以考虑使用 Claude Code Usage Monitor 来做个监控大屏。

安装

如果你和我一样，使用 uv 来管理你的 Python 环境，那么你可以执行如下代码，来安装，并启动 Claude Code Usage Monitor。

1# Install directly from PyPI with uv (easiest)
2uv tool install claude-monitor
3
4# Run from anywhere
5claude-monitor # or cmonitor, ccmonitor for short

或者，如果你喜欢用 pip，则可以执行如下命令

1# Install from PyPI
2pip install claude-monitor
3
4# If claude-monitor command is not found, add ~/.local/bin to PATH:
5echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
6source ~/.bashrc # or restart your terminal
7
8# Run from anywhere
9claude-monitor # or cmonitor, ccmonitor for short

用法

安装完成后，你就可以直接执行 claude-monitor 来启动 Claude Code Usage Monitor 了。不过，为了让他更精准的使用，我推荐你可以执行一些简单的命令，来优化其展示。

一日一技：在你的 Claude Code 中引入 CCUsage，统计你的每日 ClaudeCode 消耗

Sun, 10 Aug 2025 10:14:54 +0800

在使用 Claude Code 时，如果你使用的是自己的 Claude 订阅登录的，那么大部分时候，你不太需要关心你的使用成本；但除了使用 Claude 订阅，还有不少人是使用 Claude API 或者是 Claude 中转站点来使用订阅的，使用不同的模型的成本不同，很有可能会让你发现，一下子跑完了自己的所有余额和预算，因此，你需要更加关注自己的使用情况。

安装

你可以直接执行 npm install -g ccusage 来安装 CCUsage，或者可以选择使用 npx 来执行，比如直接执行 npx ccusage 就可以执行了。

用法

用法 1 ：直接在命令行中查看

直接在命令行中执行 npx ccusage，会自动为你展示出最近几天的消耗量，并按日进行展示。比如，你可以看到我最近已经消耗了 90 美元的模型。

用法 2 ：基于项目查看

如果你和我一样，同时使用 CC 开发多个项目，那么你可能也会有像我这样按项目统计成本消耗的需求。你可以执行 npx ccusage -i 来展示 by 项目查看。这样就可以快速的统计不同的项目的成本消耗了。

用法3 ：将 CCUsage 配置到 Claude Code 的状态栏中实时观测

如果你希望在使用 Claude Code Vibe Coding 的时候，可以随时查看你的消耗状态，则可以考虑将 CCUsage 配置到你的 Claude Code 当中。

使用编辑器打开 ~/.claude/settings.json ，在其中添加如下代码，即可实现在状态栏中实时展示消耗情况。

评测即业务：大模型应用开发的生存法则

Sun, 05 Jan 2025 10:11:39 +0800

大模型应用开发，我们真的准备好了吗？我们是否还停留在过去「只要功能正常运行就好」的阶段？

在软件过程发展的过去几十年里，软件工程一直在通过各种各样的手段，来降低系统整体的风险和不确定性。我们设计了大量的方案和框架，来帮助业务快速发展：TDD、BDD、DDD，不同的名词和对应的工具，都在引导我们通过各种各样的手段，来降低项目工程的不确定性，确保系统的整体稳定性。但，大模型的到来，过去稳定的软件工程带来了新的预期—— 可能也不是所有事情都是稳定的。

大模型自身的复杂度和特性，决定了其并不如我们过去软件工程通过代码来完成的逻辑那么的稳定和明确。对于一段代码，在设计良好的情况下，我们可以认为其 Input 确定的情况下， Output 也是确定的。但对于大模型来说，至少此刻，我们还没有那么的笃定我们相同的输入一定可以获得相同的输出。这使得过去的软件工程的常规手段出现了裂痕 —— 虽然你的逻辑一切都很清晰和明确，但系统自身的输出依然随机的。而这些随机，为项目自身的稳定性带来了隐患。

也正是因为这些随机问题，使得大模型应用时代的开发，和过去我们熟悉的应用开发开始略有不同 —— 我们需要开始关注模型层面的评测。评测从一个边缘指标，只有算法需要关注的指标，成为如今每一个大模型应用开发者需要关注的指标。如果要下一个论断，那便是 —— 评测即业务。

我们为什么要做测评？

作为一个传统工程出身的同学，我很擅长基于对于业务的理解，建设出一个业务系统，帮助业务解决的问题。我曾经和团队一起开发了一款AI文档生成工具，起初只关注功能是否能跑，直到Leader问我「业务效果如何？准召指标如何？」，我一脸懵，在那一时刻我才知道何为评测，让评测进入到我的项目流程中。

是的，那个时候的我，脑海中完全没有评测的概念，所以也没有做评测的意识，只知道业务在稳定的跑，我们可以拿到正向的用户反馈，但对于业务的效果到底如何？其实我并没有概念。也是在那一次，我开始恶补评测相关的知识，懂得应该如何进一步去做评测，也才有了写这篇文章，告诉你不要犯和我一样的错误。

为什么过去不需要评测？

评测并非大模型的出现时才有的话题，只是在过去，我们大部分时候调用的是一些稳定的服务，比如数据库或者是第三方的 API，他们的行为是可预测的，所以我们只需要关心功能本身。而大模型则不同，大模型本身就是不确定性的来源。

实际上，在传统搜索领域、机器学习领域，评测也是早已有之的概念，只不过这些功能过去往往是作为一个单独的模块存在，所以在工程上使用相关能力的时候，默认假设是相关的模块是可信的，模块内部的准召指标由模块内部的工程和算法同学来完成。业务工程团队更多关注的是工程实现层面的功能是否可用，而非关注效果指标 —— 比如设计的功能是否正常运转，相关的功能模块是否可见、可用。

而大模型应用的时代，大模型不再是作为一个额外的业务模块被调用，而是嵌入在我们的业务系统之中，这种从「外部」到「内部」的转变，意味着我们必须将评测融入到开发的每一个环节，而不是把它看作一个独立的模块。相比于传统的测试和评测只关注功能是否可用，我们开始需要关注模型的性能、数据的质量、用户体验等多哦个不同的模块。其占比也有了巨大的提升。在过去，我们的产研测的配比往往是 1:(5～10):1，但如今随着评测的重要性不断提升，一个更加合理的比例可能是 1：(5～10): 2，这里多出来的1 个人，就是服务于大模型所带来的不确定性的变化所导致的 —— 我们需要有更多的人来保障模型的效果。

我们应该怎么做好评测？

如果你认可前面的逻辑，那么就意味着我们拥有了共识：大模型是不那么稳定的，我们需要支付额外的成本，来保障大模型在我们业务系统当中的保持稳定。而基于这个共识，我们就可以开始设计我们的评测系统和方案了：

以终为始：定义业务指标和技术指标

进行评测的第一步，便是定义业务指标的含义和价值，明确模型的输入和输出。评测即业务的含义也在于此，如果你在第一步完成的足够好，其实评测的 80% 的价值便已经拿到手。业务指标因为和业务强相关，不具备太强的通用性，这里就按下不表，我们把精力放在更加通用的技术指标上。

如果你的业务系统当中接入了大模型，则应该关注下面这些指标：

生成质量指标：评估大模型生成内容的质量。这部分有一些可以参考的评测方式（比如Bilingual Evaluation Understudy、 Recall-Oriented Understudy for Gisting Evaluation 等），不过更加靠谱的还是依赖人工进行打标，毕竟最终是需要由人来评估生成的内容是否符合要求。在人工打标的时候，一般而言，大家会关注生成的内容的有效性、流畅度、连贯性、相关性等指标。
模型效率指标：评估大模型的推理速度、吞吐量、计算资源消耗等。如果你使用的是云端的大模型 API，则可以重点关注模型推理速度和吞吐量，这些可能会直接影响到你的业务系统体验和业务模式涉及（让用户等待还是直接做成异步的任务模式）。而如果你使用的是本地的模型进行运算，则还需要进一步关注到模型大小、内存占用和计算资源消耗，这些指标可能会影响到你的业务系统选型和成本计算。
模型安全指标：评估大模型针对一些恶意请求的处理能力。这部分则可以重点关注模型是否会生成出有害、不当或歧视的内容；是否会出现敏感信息泄露的等。大模型在落地的过程中，会遇到一些不友好的用户请求，如果没有相对应的处理能力，可能会直接让你的应用遭遇滑铁卢，因为安全审核没做好直接被举报挂掉。

如果你的系统在接入大模型的基础之上，还做了相应的数据库系统，来实现 RAG，那么还要额外关注：

准确率：评估在所有召回的文档中，真正与用户相关文档的性能占比有多少，可以帮助你衡量召回结果的效果，减少给大模型的噪音和无关信息，提升生成的准确率。准确率低通常是因为检索模型召回了太多不相关的文档，此时应该提高相似度阈值或优化检索模型使其更严格；
召回率：评估在所有用户意图相关文档中，被召回的文档占据所有用户意图相关的文档的占比，可以帮助你确保检索结果的完整性，确保不遗漏重要的信息。召回率低通常是因为检索模型漏掉了很多相关的文档，此时应该降低相似度阈值或优化模型使其更宽松。
命中率：评估在用户的多次意图查找中，能命中至少一个文档的比率，可以帮助你判断当前知识库内容的是否可以覆盖用户的意图。如果命中率低，可能意味着你需要去补充知识库当中的内容，或者是去优化查询的 Query。

而如果你的业务系统是诸如生成代码之类的场景，可能还需要观测代码执行成功率、代码执行成功率等一系列指标。

上述的这些指标，只能作为一个初步的导览，到了具体的业务当中，肯定还要和业务结合做一些调整。但总的来说，当你想清楚你要观测哪些指标，要进行何等的评测时，其实你的业务已经想的大差不差了，剩下的只不过是通过评测选择出合适的模型和 Prompt，并用工程手段将其串联起来。

清洗数据：高质量评测的关键

定义出了指标，下一步要做的事情，是清晰出高质量的数据，参与到评测，这里就需要你有高质量的数据，能够辅助你的业务进行评测。不同的评测目标对应着不同的数据，因此，也需要维护多组不同的数据集，用于进行不同目标的评测。

随着业务的不同，你所选择的数据集很有可能是无法使用公开数据集覆盖的，则就需要考虑自己去准备数据集，这部分数据可能来自于线上的数据，也可能是人工便携的数据，或对于现有的数据进行标注，从而清洗出高质量的数据参与评测。

获得第一步数据后，下一步则需要对拿到的数据进行清洗。上一环节拿到的数据很有可能存在噪声，或者是数据的不规范，因此，你需要对这些数据进行清洗，移除数据中的错误、重复和不完整的信息，并对格式进行统一，去除无用的数据，规范化数据。如果你的数据可能涉及到一些敏感数据，还要进行数据的脱敏处理，以保护用户的隐私。

在数据的清洗这部分，你会耗费大量的时间和精力，因此，要提前规划数据的收集和清洗，以降低后续的压力。同时，也要提前准备相关的人力，来支持数据集的建设。

除了上述的问题，还要关注到数据集的质量（代表性、准确性、多样性和完整性）、规模、数据偏差等。确保数据集本身不会出现偏见和问题，而将模型导向一个错误的方向。

当你准备好上述的这些数据，接下来要做的事情就相对简单 —— 维护好数据，定期更新，以适配业务，并持续性的对系统和模型进行评测和指标观测，确保各项指标没有出现问题。

作为 CRUD Boy，如何跟上 AI 时代?

Fri, 19 Apr 2024 09:36:04 +0800

在英伟达成为世界上市值第一的公司之时，我们来聊聊作为 CURD Boy 如何跟上时代，开始动手搞 AI。

目前的 AI 并不够强，也不足以把技术专家给完全替代。而且我非常相信即使你完全不懂 AI，依然可以找到一份工作。但掌握 AI 并不是为了与 AI 对抗，而是给自己新增一个技能树分支，做到人无我有，人有我优，最终提升自己获得更好工作机会的概率；让自己在市场上拥有更多的可能。

如果你想好了，也准备跟上这个 AI 的时代，那么就继续往下看吧！

学 AI，从用 AI 开始

我不知道你在日常的工作中是否有使用任何基于大模型的 AI 工具，如果你已经在用了，那么很好，继续使用，深度使用，并在使用中不断思考，哪些事情是 AI 可以做的很好的事情？哪些是 AI 做不到很好的事情？以及，为什么这个事情 AI 做不到很好？这些问题可以帮助你更好的理解 AI 的边界，从而找到 AI 的能力圈，并在后续的开发过程中，找到 AI 能提供的价值，并始终在 AI 的能力圈内做事。

而如果你没有开始使用 AI，那么不妨从一些面向开发者的 AI 工具开始，比如：

Perplexity：当你需要搜索东西的时候，可以试试先不要丢 Google，丢 Perplexity 试试看，他给你的答案有什么不同？
Devv.ai：当你遇到一些卡住的问题，不妨丢给它试试看，看看这个面向开发场景优化的 AI 是如何解决这个问题的。
GPTCommit：如果你像我一样懒得写 Commit Message，试试让 AI 来帮你写 Commit Message。

当然，除了用上面的工具，别忘了思考这几个灵魂拷问：

什么事情是 AI 可以做的很好的事情？
什么事情是 AI 做的不好的事情？为什么这个事情做的不好？
做什么可以让 AI 把做的不好的事情变得更好一点

先用 AI，再复盘和推演，能够帮助你更好的获得对于 AI 的手感，以及对更深一步的认知。不用太着急写代码，因为当你没有基础的 AI 理解时，你用 AI 可能也不过是高射炮打蚊子。

Home on AI Developer Starter

关于本站

关于本站

选题建议

一日一技：使用 Claude Code Usage Monitor 做个用量大屏

安装

用法

一日一技：在你的 Claude Code 中引入 CCUsage，统计你的每日 ClaudeCode 消耗

安装

用法

用法 1 ：直接在命令行中查看

用法 2 ：基于项目查看

用法3 ： 将 CCUsage 配置到 Claude Code 的状态栏中实时观测

评测即业务：大模型应用开发的生存法则

我们为什么要做测评？

为什么过去不需要评测？

我们应该怎么做好评测？

以终为始：定义业务指标和技术指标

清洗数据：高质量评测的关键

作为 CRUD Boy，如何跟上 AI 时代?

学 AI， 从用 AI 开始

用法3 ：将 CCUsage 配置到 Claude Code 的状态栏中实时观测

学 AI，从用 AI 开始