赛博鸡生蛋，7小时用Claude Vibe Coding一个Mini-Claude

本文章是小白向文章, 面向想要了解或者自己动手验证 Coding Agent 行为逻辑的技术/非技术同学, 使用Vibe Coding的方式, 参考Claude实现一个精简的Mini-Claude。

最近，Vibe Coding 的风头正盛，无数技术与非技术背景的开发者纷纷投身其中。然而，对于 Coding Agent 背后真实的交互机制——例如 Agent Loop、ReAct 等核心理论，纸上得来终觉浅。于是我决定亲手实践，直接调用原始的 LLM API，亲身感受一次 Coding Agent 的完整行为链路。

之前看到一篇文章受到启发, 决定用Vibing Coding, 模拟Claude, 实现一个小粒度功能的Mini-Claude。

Mini-Claude是模拟Claude CLI给Coding LLM发送API请求, 然后自己实现CLI交互, Chat交互, Tool调用循环, 请求上下文组装等基本的Coding Agent的能力, 实现构建一个轻量版的Copilot能力; 整个开发过程，我特意安排在下班后的三个夜晚进行。利用碎片化的时间一点点打磨，累计投入的开发时间甚至不足 7 小时。

https://github.com/q43607238/mini-claude

工程内部的docs文件包含关键交互代码的详细解读, 并且都配有保姆级别的细致注释, 阅读起来轻松易懂。

• 安装node环境: 已经安装过Claude的可以跳过这个步骤,我们就不过多赘述了;
  
• 配置ApiKey & 选择模型:

cd <yourProjectPath>/src/
# 首次启动, 会提示在用户目录创建好了工作目录~/.mini-claude 和配置文件 ~/.mini-claude/mini-claude-config.jsonnode app.js
# 这时候将你的baseUrl和ApiKey填入Config的对应位置vim ~/.mini-claude/mini-claude-config.json
# 重新启动, 展示出了mini-claude字样则启动成功, 可以开始正常的CLI使用了node app.js

配置参考:

model: kimi-k2.5, GLM-5等等

baseUrl: kimi官方https://api.kimi.com/coding

{  "apiKey": "你的API KEY",  "model": "",  "thinking": {    "enabled": true,    "type": "adaptive"  },  "baseURL": "",  "systemPrompt": "你是一个AI编程助手" // 可以自定义你的system prompt}

• dashboard安装node_module: 

cd <yourProjectPath>/src/dashboard# 下载依赖tnpm install# 下载完毕后, 就可以启动dashboard页面拉npm run dev

1.“基础”任务：修改指定代码

2.“进阶”任务：修改批量代码

3.“高阶”任务：使用dashboard查看session日志

• 第一步：强烈安利安装cc-viewer, 现在可以直接抓包看到 Claude 请求的明文数据。

• 第二步：准备好自己的Claudecoding模型, 这里我采用的是KIMI官方的KIMI 2.5, 作为开发主力。

接下来,我们从最底层的工程结构开始, 构建起Mini-Claude的整体框架; 整体思路遵循prompt的大方向, 按照这个顺序, 不仅能够更好地保持各项原子能力的稳定, 也能有效降低整体出错的风险。

第一步, 我们通过JS自行实现一个针对KIMI的调用, 旨在打通最基础的请求逻辑：

使用cc-viewr可以抓取到Claude 的请求, 同样可以喂给Coding Agent;

具体代码可访问文末代码学习链接查看。

Prompt: 现在我要求你使用JS生成一个对KIMI的大模型接口调用, 消息格式参考Anthropic_Messages格式, BaseUrl是https://api.kimi.com/coding/v1/messages?beta=true, 请求明文如下

生成完毕后, 可以让Claude生成一个针对各种返回逻辑的测试。

Prompt: 现在我要求你针对kimi-api.js写一个全面的测试, 测试各种请求逻辑: simple chat, stream chat, tool use response, 重点关注流式是否可以正常消费, tool use是否能合理识别到tool use, 然后mock下tool调用

测试已基本完成，与后端接口的调用链路畅通无阻, 但有一个细节需要注意：header中要模拟Claude请求的header, 具体可以使用cc-viewer获取, 因为Coding Plan的KIMI后端会校验你的请求是否自范围内的Coding CLI/ IDE。

当前工程结构：

project/ └── src/ └── kimi-api.js

Tool use 基本构成了 Coding Agent 实现编程能力的核心逻辑，因此在这一阶段，我们需要让 Agent 具备对工具的实现与调用能力。

Prompt: 现在我要你实现一个tool的实现, 实现Write(创建, 全量写入文件), Read(读取文件), Exec(执行bash指令) 3个工具; 实现了tool后, 修改之前的api测试demo, 让之前mock的tool调用, 实际执行tool的执行, 返回tool执行结果给我;

至此基础测试已圆满收官, 验证tool的实现没有问题,值得一提的是在构建工具描述时, 直接询问Claude自身具备哪些工具能力，随后，再指令Coding Agent用JS精准复刻并实现相应功能;

当前工程结构：

project/└── src/├── kimi-api.js└── tool.js

实际上对于LLM来说, 每一次的api请求都是无状态的, 它不存储历史会话, 所以对话的组装需要我们自己进行处理, 这里要做一个manager来维护session对话和组装system prompt和message;

同时, 要让Coding Agent顺利完成编程任务, 本质上就是一个不断 "读 -> 改 -> 写 -> 读 -> 改 -> 完成目标" 的循环过程;

接下来我们将聚焦两大核心功能:

• 核心1：消息的组装, 存储历史message, 每次将工具调用, 上一轮的LLM response, 拼接到message数组的最后面, 保持前缀不变, 这样才可以用命中KV Cache;
• 核心2：tool loop的处理;

Prompt: 现在我要你实现一个manager的实现, 它接收用户的文本, 拼接到请求的message信息, 如果是文本回复, 就直接回复, 如果是工具调用, 就先把调用结果返回给LLM, 完成工具Loop, 直到LLM不返回工具调用, 再把文本结果返回给用户;

在tool loop的处理上, 我投入了相当多的精力进行打磨, 不过整体思路并不复杂：可以通过观察 KIMI 返回的 API 报错信息，来判断是否存在参数缺失或传递不完整的情况。例如我就碰到过一个典型错误"当带thinking的tool调用时, 下一次Request必须带上thinking的部分信息", 其实这类问题交给Claude持续试错和调整, 就可以顺利完成修改完成;

当前工程结构：

project/└── src/├── kimi-api.js├── tool.js└── session-manager.js

该界面模块可采用独立开发策略, 暂时无需考虑和session-manager的联动, 类似于我们的前后端独立开发~

这种界面的prompt就见仁见智了, 完全可以根据个人偏好灵活定制。只要能够实现基本的进入和退出功能，这一阶段的目标就算达成了;

Prompt: 现在我要你实现一个CLI的实现, 先简单实现用户执行CLI进入CLI界面, 双击Ctrl + C退出, /quit, /clear等命令...

当前工程结构:

project/└── src/├── cli.js├── kimi-api.js├── tool.js└── session-manager.js

这一步让我们的Mini-Claude终于已经初具雏形啦~ 它已经可以丝滑得进行终端交互了, 接下来就是持续优化过程, 过程中记得让session-manager把每一次的请求和LLM response信息都储存到一个session文件里, 以便后续我们可以实现快速排查问题哦。

Prompt: 修改CLI的实现, 当用户回车发送消息的时候, 调用session-manager拼接请求给LLM, 接收到返回或者工具调用结果的时候, 在CLI上展示出来; session-manager把每一次的请求和LLM response信息都存到一个session文件里。

当前工程结构:

project/└── src/├── cli.js├── kimi-api.js├── tool.js└── session-manager.js

这一步的核心优化在于 CLI 的展示效果，鉴于LLM返回的结果大多为是markdown形式，所以我们需要额外增加一层 Markdown 渲染处理。该渲染逻辑同样可交由 Claude实现。

Prompt：新增CLI的对LLM文本回复的渲染, 其中优先渲染除了表格之外的行内代码样式, 待渲染结果长度定下后, 再渲染表格的样式

这一步也是一边走一边调试，不断踩坑进步的过程, 表格部分尤其让人头疼, 因为有些LLM的回复在表格里也有行内代码样式, 如果先渲染表格再渲染行内代码, 长度就会发生变化, 这样展示出来的表格就彻底乱套了XD

当前工程结构：

project/└── src/├── cli.js├── kimi-api.js├── tool.js└── session-manager.js

此刻虽然核心能力已初步完备, 但是代码已经“长的不忍直视了”—— 动辄几千行, 一个 JS 文件里还混杂着多种能力，重复定义随处可见。这个时候，适当的停下来重构一个AI Native项目就显得十分重要! 你可以选择完全交由 LLM 决定如何分层与重组，但我更倾向于结合自己的开发经验，采用 MVC 结构来重新梳理这个小而杂的项目。这样不仅结构更清晰，也能让后续的优化和扩展更顺畅。

Prompt：现在我想重构这个工程, 我觉得可以采用MVC架构, 你先给我一个拆分方案, 先不要改代码。

在直接执行改造前, 最好先让LLM给出一份方案, 经过充分的确认后再按照方案执行, 这样能够有效减少LLM“乱搞事”的情况; 这套思路与“SSD驱动编程”等理念有异曲同工之妙, 所以在讨论过程中随时输出自己的观点就显得尤为重要，这样可以确保设计方向与我们预期一致。

Prompt：嗯, 把tool层里面的工具实现也拆成每个小JS文件... 好, 现在开始改代码

优化后, 我有了一个相对明朗清晰的工程结构;

当前工程结构：

project/└── src/ ├── app.js # 应用程序入口，初始化并协调View层和Controller层 ├── controllers/ │ └── conversation/ │ └── manager.js # 对话管理控制器，维护对话状态、流程控制、Tool use循环编排 ├── models/│ ├── api/│ │ └── llm-client.js # LLM API原生调用封装，支持system prompt、tools、stream模式│ ├── storage/│ │ ├── index.js # 存储模块入口，导出SessionStorage│ │ └── session-storage.js # 会话存储模块，负责会话文件的创建和管理、增量追加写入│ └── tools/│ ├── index.js # 工具模块入口，导出所有工具定义和处理器，执行工具调用分发│ ├── definitions.js # 工具定义集合，导出所有可用于LLM调用的工具定义│ ├── handlers/│ │ ├── exec.js # Bash命令执行工具，用于执行shell命令并返回结果（带安全检查）│ │ └── file.js # 文件操作工具，用于读取、写入、编辑文件│ └── security/│ └── validator.js # 命令安全验证模块，验证bash命令是否包含危险操作└── views/├── cli/│ ├── index.js # CLI视图层主类，负责用户界面、输入输出、事件展示│ ├── display.js # 显示模块，负责Logo、帮助信息、提示符等界面元素│ ├── input.js # 输入处理模块，负责命令补全、Tab补全、输入捕获│ └── loading.js # Loading动画和进度显示模块└── renderers/└── markdown.js # Markdown渲染器，将Markdown转换为ANSI转义码格

在项目结构基本搭建完毕后, 最终还需对代码进行清理消除冗余内容，并在格式与写法层面加以优化，毕竟AI生成的代码, 最终还是要给人看的。在长期的AI Native项目的开发中, 由于上下文的不断累计, AI常常会忽略一些小细节, 导致出现方法命名不规范、逻辑相似代码重复定义等问题; 为了体验纯Vibe Coding, 我选择让一个完整的上下文贯穿始终，只由Claude做自动执行compact处理。但是在实际工作项目中, 我任然建议还是根据专家经验进行模块化处理, 约束AI的范围进行开发;

Prompt: 现在我需要你给我提供一个方案, 你需要仔细察看所有的逻辑, 优化冗余代码, 有一些命名和逻辑不匹配的, 或者有重复逻辑定义的代码, 都给我一个优化方案, 如果有我没提到的, 你认为可以优化的, 也一并列出来, 先不要改代码;

在正式大刀阔斧改造前先输出完整方案, 经过多轮探讨和打磨后再动手执行;

Prompt: 好, 按照方案开干吧!

这个参考cc-viewer的形式, 简单实现一个读取本地文件, 并在前端渲染展示出来即可。

Prompt: 帮我实现一个前端, 使用react和antdesign, 实现用户点击解析session, 左侧tab显示具体请求摘要, 右侧显示选中的当前请求的详情, request, response, header和body, body要支持json折叠, body和header支持一键复制;

和之前的工作相比, dashboard的实现简直就是小菜一碟, 访问http://localhost:5173/

点击想要分析的文件时间戳

Mini-Claude实现了最基础的 Coding CLI 交互能力，包括 CLI 交互、LLM 交互及工具调用，形成了初步的闭环操作流程，并能够支持简单的 Tool Loop 机制以进行代码修改。

• MCP / Skills: 在理解tool的调用机制基础上, MCP 和 Skills 的实现方式与之类似, 通过抓包Claude可知，Skills的description是放在message数组的首位, 并以<system_reminder>标签包裹, 这和预先内置tools的描述本质上一致; Claude的具体提现方式是提供一个Skill的tool, 该工具以用户所选 Skill 名称为参数，其功能大致为读取 SKILL.md的内容，以"渐进式披露"的方式, 将Skill预先放置好的脚本或prompt加载至上下文中;
• 并发调用：我们时常可以观察到Claude能迅速完成多个文件的更新或查找操作, 通过Mini-Claude的监控面板发现, 部分LLM的返回中,有时会包含多个tool_use的内容, 例如执行不同正则内容的bash find, 在当前Mini-Claude我采用“循环进行tool_use调用”方式, 实际未来可优化为并行执行方式以提升效率;
• 上下文处理: 目前Mini-Claude尚未处理上下文窗口的问题, 如何有效地压缩上下文, 减少前文信息丢失, 是比tool loop更为关键且需深入研究的课题。

到底如何转型AI开发, 把握住一个AI Native项目?

回顾近半个月的深度实践里, “半自动开发+手动约束Coding Agent的职责范围+随时把控方向,”是我目前认为最高效稳妥的开发方式; 正如Mini-Claude的开发流程一样, 每推进到一个关键节点, 就需要重整架构、梳理冗余代码、合并通用逻辑, 或许本质上LLM还是在进行“文字接龙”, 在当前阶段依然离不开程序员的审阅与干预;

我一直听闻Opus 4.6表现卓越, 虽然因为预算有限还没有亲自体验, 但我推测这类模型在纯 AI Native 项目中的发挥空间应更为显著，反之对于一些遗留项目，如果试图引入 AI 进行改造，为使其理解复杂的历史包袱，半自动开发反而可能比全 AI 驱动更加高效。

我主要从事 Java 业务开发,诚如业界大牛所言, Java的项目设计, 设计模式, 高内聚低耦合的业务共识, 可能反而会给LLM带来很多无用的上下文知识, 实际实践过程中我也深有体会; 

Java 依然是不可或缺的存在， Spring 全家桶在 Web 服务时代为开发者和服务稳定性都做出了巨大贡献。然而，站在 AI 原生开发的新时代路口，JS, Python与AI开发确实有天然的优势，写起来都更加流畅顺手。

到底啥是Agent?

纵观各家的Coding Agent和近期备受瞩目的OpenClaw, 将其抽丝剥茧来看, 其核心机制均可归纳为以下流程:

WHILE (!LLM_STOP_TOOL_CALL()) {  TOOL [] = GET_LLM_TOOL_CALL();  RES[] = RUN_TOOL(TOOL);  RETURN_TO_LLM(RES);}

1.如何组装上下文；2.如何检索上下文；3.如何最大程度地保留上下文语义。

包括OpenClaw这类系统, 也在探索如何更好地管理用户的长期上下文，实现持续的自我进化——这或许正是下一阶段 Agent 发展的关键课题。 既然Mini-Claude已经诞生, 下一步我们或许可以尝试开发一个Mini-Claw以进一步深入体验其上下文管理机制。 XD

本文抛砖引玉, 作者也一直在学习中, 希望可以帮助到对Coding Agent底层逻辑想有些了解的同学。