我们在 MissionControl 中实际交付的内容

两天时间。二十一次提交。输入英文，输出拉取请求。

如果你是中途加入本系列的：第一篇文章介绍了那次耗时十六小时的构建——输入 Telegram 机器人指令，输出拉取请求，并采用了端口与适配器架构。第二篇和第三篇文章则记录了随后的“漏洞狩猎”过程，其中包括一项花费 5.84 美元却未产生任何有效成果的任务，迫使我们重新思考整个信任链。这就是系统在经历这一切之后的样子。

用户界面

MissionControl 以 Telegram 机器人的形式运行。没有网页用户界面，也没有仪表盘。你向它发送消息，它执行任务，再回复你。

每次交互都发生在聊天气泡中。遛狗途中用手机发送一个任务，到家前就能收到拉取请求链接。这一限制——所有内容必须能塞进一条 Telegram 消息——最终被证明是一项功能，而非缺陷。

完整的命令集如下：

• /task <描述> —— 将任务加入默认项目的队列。代理会拾取该任务，创建分支，完成工作，推送代码，并打开拉取请求。
• /task slug: <描述> —— 指定目标项目。
• /status —— 显示当前正在运行的任务、队列深度以及最近完成的任务。
• /cancel <编号> —— 终止正在运行的任务或从队列中移除待处理任务。
• /retry <编号> —— 重新排队已失败或已取消的任务。
• /logs <编号> —— 查看某项任务执行日志的最后 50 行。
• /budget —— 显示今日支出、剩余每日预算以及每项任务的费用明细。
• /addproject <标识符> <路径> --github 所有者/仓库名 —— 注册一个代码仓库。自动将 .git/ 目录的所有权赋予工作用户。
• /create <标识符> —— 初始化新项目目录，初始化 Git 仓库，创建 GitHub 仓库并完成注册。
• /rmproject <标识符> —— 注销并清理项目。

无需上下文切换。无需浏览器标签页。

数据表现

在最初 48 小时内，三个项目共提交了二十项任务。

20% 的完成率看起来很差，但实际情况并非如此。任务 1 至 4 均因同一个 CLI 启动问题而失败——即第二篇文章中提到的“零标准输出”漏洞。我们在理解问题本质前，对同一故障重试了四次。修复该漏洞后，新任务的完成率跃升至约 50%。其余失败原因包括预算超时以及新注册项目上的权限问题，均非系统性缺陷。

真正重要的数字是：四项已完成任务均产出了可运行的代码、通过了构建，并成功合并了拉取请求。其中一项任务——一个健身教练仪表盘——是一个完整的全栈 Next.js 应用，包含身份验证、数据可视化以及 PostgreSQL 后端。全程自主构建，仅花费 2.00 美元。

安全防护体系

这里的每一层防护机制，都是因为我们当初未部署它而导致系统出过问题。

预算上限。 全局每日限额 50 美元。每项任务默认限额 5 美元，最高可配置至 10 美元。任务启动前会进行检查，并由 CLI 自身的 --max-budget-usd 标志强制执行。第三篇文章中提到的任务 #19——那项花费 5.84 美元却毫无产出的灾难——证明了预算强制执行的必要性。