https://coolbeevip.github.io/tags/spec-kit/Recent content in Spec-Kit onHugo -- gohugo.ioen-usWed, 04 Mar 2026 00:24:14 +0800https://coolbeevip.github.io/posts/lerobot/lerobot-codex-spec-kit/Wed, 04 Mar 2026 00:24:14 +0800https://coolbeevip.github.io/posts/lerobot/lerobot-codex-spec-kit/“现在问题解决了，但请你重新 Review 一下今天的几轮修改，看看是不是补丁叠补丁式的修改，如果是的话，重构成最优解”，这是我在这个项目里对 AI 说得最多的一句话。 你也可以说 “review the code, think from greenfield” 或者 “/samplify”，但不管怎么说，这句话的核心意思是：当 AI 在一个已经快速迭代过的代码库里继续修改时，它很容易陷入“补丁叠补丁”的陷阱，而不是停下来重新思考最优解。 过去一周，我做了个基于 LeRobot 的 SO-101 机械臂 PoC。最初只是一个能跑起来的遥操作脚本，后来长成具备配置驱动、基础测试、服务接口和调试界面的 MVP。这个项目并不是我一个人独立完成的。我主要搭起了大约 60% 的骨架和核心功能，包括命令行入口、配置体系、API 分层、Web 服务、调试面板（dashboard），以及大部分基础测试。到了后期，团队里的同事也逐步参与进来，补上了模型推理、训练以及一些更贴近业务场景的能力。 现在的结构： 命令行入口：teleoperate、record、replay、serve Python API 分层：src/api FastAPI 服务：src/webapi React 调试面板：dashboard/ 单元测试：tests/unit 配置文件：config/agent.toml 一句话概括：用 Spec-Kit 管"要做什么"，用 Codex 管"怎么更快做出来" 但这不是一个"AI 加 Spec-Kit 就一路顺风"的故事。中间有很多反复、修正和取舍。Spec-Kit 帮了我不少，也带来过混乱；Codex 让我省了很多重复劳动，也把我前端、协作和问题表达上的短板照得很清楚。 这篇文章讲的就是这些真实经验。 一、为什么一开始没有直接写代码 表面上看这是个"硬件 + Python"工具，但做起来才发现是一整条链路的问题： 读取 SO-101 的 follower、leader、camera 配置 跑通 teleoperate（遥操作） 支持 record（数据采集）和 replay（回放） 把能力暴露成 HTTP / WebSocket 服务，方便外部调用 做调试面板，把串口、相机、控制状态、任务状态可视化 后续接入推理和 LLM，而不是推翻重来 直接写代码很容易在第 3 步以后失控。配置解析、硬件连接、任务生命周期、Web 接口、前端调试、测试替身——这些边界一旦不清，后面每加一个功能都牵一发而动全身。