对小智AI说一句话,Kimi Code替我跑完2项真实
摘要
我用小智AI的ESP32-S3开发板接通MCP,说一句话就调起PowerShell交给Kimi Code,2项真实任务跑通后又把黑箱改造成可见窗口。文中有最小复现路径和四条工程规则,业务代码零改动。
今天，我把 AI 开发的入口从键盘挪到了一块开发板上。
收到小智 AI 的 ESP32-S3 开发板之后，我先走完了账号连接、官网配置和常用功能测试，然后做了一件更像野生码农会干的事：不再只跟它聊天，而是让它通过 MCP 调起我 Windows 电脑上的 PowerShell，把开发任务直接交给 Kimi Code 执行。
这事对我的分量不在省几次键盘操作。此前我的 AI 开发全发生在软件和终端里，从这天起，硬件开始成了整个开发系统的语音入口。
一、跑通了吗？两项真实任务已经验收
跑通了。我对小智 AI 说出任务，它通过 MCP 调起 PowerShell，Kimi Code 先后完成 IPMS 后台服务启动和 GEO 博客文章推送，两项都返回成功。
中间没有演示道具，没有专门搭建的测试工程，跑的就是我日常工作里真实存在的两件事。这篇文章就把整个过程拆开讲：官方功能到底什么水平，架构怎么搭，以及跑通之后我为什么又返工了一次。
二、先按普通用户测一遍：能用，但不懂我的工作
我没有急着写代码，而是先把官方功能完整走了一遍：登录小智官网、连接账号、切换模型、语音对话、打断、点歌、查天气，再拿一个实际工作中遇到的高速公路相关问题测它。
真机体验如下：
| 测试项 | 本次表现 | 我的判断 |
|---|---|---|
| 模型选择 | 后台可切换 DeepSeek 4.0、豆包 2.0、千问和小智自有模型 | 四套模型的响应都挺快 |
| 语音识别 | 部分指令和歌名会出现识别偏差 | 日常能用，识别率仍有提升空间 |
| 对话打断 | 可以在对话过程中打断 | 体验比较顺畅 |
| 音乐播放 | 让《五百年桑田沧海》成功播放并不容易 | 语音识别与曲库搜索是两层问题，不能混为一谈 |
| 天气查询 | 定位只到金华市一级 | 离更细粒度的本地天气还有距离 |
| 高速公路问题 | 没有给出有效答案 | 当时是否真正触发联网搜索尚未确认，不能武断归因 |
该有的都有，响应也不慢。作为通用语音助手，它是合格的。
三、通用助手的天花板：它不认识我的项目
问题也正出在这里。官方功能不是不好用，而是停留在通用助手层：它不知道我电脑上有哪些项目，不知道 IPMS 是什么，也不知道我的开发任务该怎么执行。
IPMS 是我自研的自媒体内容生产管理系统，我日常写文章、排版、做发布准备，都在它里面完成。对小智来说，这套东西完全不存在。
我不想只跟它唠嗑，我想让它调动我整个开发环境。对一个技术玩家来说，测到这里，真正的乐趣才刚开始。
四、一句话到 Kimi Code，中间走了七站
我的第一个二次开发目标很明确：
我对小智 AI 说一句任务，它通过 MCP 调起 Windows 上的 PowerShell，再把开发要求交给 Kimi Code。
MCP（模型上下文协议）可以简单理解为 AI 调用外部工具的标准接口。分工上，小智云端负责理解我的意图和选择工具，真正操作电脑、执行开发任务的，仍然是我的 Windows 主机。
跑通后的完整链路是这样：
我的语音
→ ESP32-S3
→ 小智云端 ASR / 大模型
→ MCP tools/call
→ Windows 上的 mcp_pipe.py
→ 本地 pc_tools.py
→ PowerShell
→ Kimi Code
→ IPMS、GEO 博客及其他本地项目
USB 在这套方案里只负责供电、烧录或串口调试，真正的业务控制链路走网络。电脑上的桥接程序主动连接小智云端，所以不需要把开发板改造成一台直接执行代码的电脑，它就是一支麦克风加一个入口。
五、只开四扇门，不开任意 Shell 的大门
本地 MCP 服务一共只暴露了四类能力：
| 工具 | 作用 |
|---|---|
list_kimi_projects | 列出允许调用的项目别名 |
start_kimi_task | 在指定项目中启动 Kimi Code 任务 |
get_kimi_task_status | 查询任务正在运行、成功还是失败 |
get_kimi_task_result | 读取任务结果摘要 |
这里没有开放"执行任意 Shell"的大门，采用的是项目白名单加固定工具契约。小智能做什么，不由一句提示词决定，而由我实际注册了哪些工具决定。
这个边界是我刻意留的。语音入口意味着指令来源变得随意，识别偏差又客观存在，这种情况下把权限收口到四个动词，比事后补救要便宜得多。
六、不拿 demo 凑数，直接上两项真实任务
架构搭好以后，我没有拿"你好世界"安慰自己，而是直接上了两项现有工作里的任务：
| 真实任务 | 发起时的状态 | 结果 |
|---|---|---|
| 启动 IPMS 后台服务 | 我的自媒体文章生产系统后台没有启动 | 小智通过 MCP 调起 Kimi Code，服务启动成功 |
| 推送近期 GEO 博客文章 | 本地已有待推送内容 | 推送任务执行成功 |
这两项任务的价值不只是省了几次键盘操作。它证明我不需要把现有软件系统重新改造成"硬件专用版"，只要增加一层 MCP 工具适配，小智就能成为原有系统的语音调度入口。IPMS、GEO 博客和 Kimi Code 都继续沿用原来的工作方式，改变的只是它们被调起的方式。
到这一步，我可以正式宣布：
使用小智 AI 进行 AI 开发的工作流程，正式打通。
七、跑通之后，我反而心里没底
第一轮成功之后，马上暴露了第二个问题：任务都在后台执行，我看不到过程。
服务启动成功、文章推送成功当然很好。但一个开发任务如果只告诉我"做完了"，却不让我看到它执行了什么，我仍然不放心。命令对不对、路径有没有走错、中间有没有报错被吞掉，这些黑箱里的事，"成功"两个字概括不了。
我随即提了一个新要求：
最好是显示的。调用 PowerShell，我能在窗口中看到所有的命令过程。
这句话直接改变了实现方式。
八、把黑箱改成看得见的窗口
原先的隐藏进程被改成"每个任务一个独立 PowerShell 窗口"，同时保留任务编号、日志和状态查询：
| 改造点 | 原来的方式 | 现在的方式 |
|---|---|---|
| 任务进程 | 隐藏在后台 | 每个任务打开独立 PowerShell 窗口 |
| 执行输出 | 主要写入日志 | 窗口实时显示，同时保留结果日志 |
| 状态判定 | 依赖进程是否结束 | 依据退出码标记，窗口保持打开也不会误判 |
| 完成后复查 | 不清楚中间做了什么 | 可以滚动查看全过程，按回车再关闭窗口 |
这里有个关键细节：任务完成后，窗口要留给我检查，但 MCP 状态不能一直显示"运行中"。所以实现上把"窗口是否打开"和"Kimi 是否完成"拆成两件事，用退出码标记判断任务状态。
改造后的联调结果也很明确：PowerShell 可见窗口检查通过，Kimi 任务退出码为 0，结果查询返回成功；正式桥接重启后，小智云端重新连接并请求了工具列表。至此，这套东西不只是"能调用"，而是能调用、能观察、能追查。
九、想复现这套玩法，最小路径并不复杂
第一步，先在小智控制台取得 MCP 接入点，用官方示例验证连接：
git clone https://github.com/78/mcp-calculator.git
cd mcp-calculator
pip install -r requirements.txt
$env:MCP_ENDPOINT="<你的 MCP 接入点>"
python mcp_pipe.py calculator.py
计算器能调用之后，再把 calculator.py 换成自己的电脑工具脚本。Kimi Code 的非交互入口是：
kimi -p "检查当前仓库并汇总问题"
但真正用于语音开发，我建议至少补上这四条工程规则：
- 项目白名单：语音里说项目别名，不让模型自由传入任意路径。
- 长任务异步化：启动后立即返回任务编号，再提供状态和结果查询，避免一次 MCP 调用长时间卡住。
- 过程可观测：窗口展示给人看，日志留给事后排查，退出码给机器判断。
- 权限有边界：不开放任意 Shell，接入点不提交 Git，正式修改项目前先留恢复点。
十、真正值得抄走的，是这四层
这套方案最值得带走的不是某一条 PowerShell 命令，而是"语音入口、工具契约、任务执行、过程观测"四层拆开的设计。以后无论接 IPMS、GEO 博客，还是接其他本地服务，都可以沿用同一套骨架，换个项目只是多注册一组工具。
搬去公司场景也一样成立：给既有系统加 AI 语音入口，不需要动业务代码。我这次接入两个系统，IPMS 和 GEO 博客的业务代码改动是零行，全部工作量只有一层 MCP 适配加四个工具函数。对比一次针对硬件入口的系统重构，这个成本基本可以忽略。
以前，我的数字员工团队在终端里等我输入；现在，它开始听得见我说话。这才是我在意的转折：不是多了一块会聊天的开发板，而是我的整个 AI 开发系统，多了一种可以被声音驱动的方式。
FAQ
问：需要改 ESP32 固件吗？
不需要。这次我没有改任何固件，用的是小智云端现有的 MCP 能力，电脑上的桥接程序主动连接云端。先利用现成能力把流程跑通，比一上来就改固件划算。
问：小智会不会乱执行命令，把电脑搞坏？
本地只暴露了四个固定工具，配合项目白名单，不开放任意 Shell。语音里说的是项目别名，模型没有机会自由传入路径。它能做什么，取决于我注册了什么。
问：代码能直接抄吗？
最小路径就是第九节那两条命令：先用官方 mcp-calculator 示例验证接入点，再把 calculator.py 换成自己的工具脚本。真正值得抄的是四条工程规则和四层拆分的设计，命令本身反而是最简单的部分。
问：任务跑久了，小智那边会卡住吗？
不会。start_kimi_task 启动后立即返回任务编号，之后用状态查询和结果查询两个工具轮询，一次 MCP 调用不会被长任务占住。
我是野生码农，AI实战派。17年全栈工程师，一人AI公司实践者。打造个人IP内容体系、软件全链路产品产线，拥有百套企业AI方案、200多个岗位Agent；自研知识库、AI数字员工系统，公开实战复盘。
本文所有内容均为本人 AI 实战的过程和结果，经 AI 整理后发布，无任何瞎编虚构内容。
这篇来自《AI员工团队》系列。
关注我，看真的。
野生码农AI实战 · 全网同名
作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)