四条斜杠命令的自动改进循环：串起AI智能体全生命周期  

一个开局只有70分水平的智能体，丢进一个自动化的“自我递归”循环里，反复用自己跑出来的报错数据折磨自己，直到所有考试全部满分。这个过程的恐怖之处在于：它不需要你熬夜修bug，只需要你按下启动键然后去睡觉。

一条流程图把整个工程队装进四个斜杠命令

先别急着看正文，我把这套玩意的全貌直接甩你脸上。下面这个流程图，就是整个智能体从出生到上线的完整生命周期，四个斜杠命令串起全部工序：

markdown
   /create-agent            scaffold a new agent
        │
        ▼
   /improve-agent ◄──────┐  improve it against its own spec
        │                │
        ▼                │
   /extend-agent ────────┘  add a capability, then improve again
        │
        ▼
   /deploy-platform         launch it
        │
        └──► back to /extend-agent when you want it to do more

这张图没有花哨的箭头特效，但信息量足够让你愣三秒。入口只有一个，/create-agent，跑完得到个能跑的初始版本。然后进入一个循环，/improve-agent和/extend-agent互相衔接，改完功能就跑测试，跑完测试再改功能，反复摩擦直到完美。最后/deploy-platform一键上线，上线之后想加新功能，不需要回到起点，直接走/extend-agent继续循环。

四个命令，覆盖了传统开发里产品经理、开发、测试、运维四个角色的全部活。你不需要写一行代码，只需要在恰当的时机输入恰当的斜杠加单词。这套流程的核心设计哲学是“收敛”——每一次改进都是在往规格说明书那个固定点靠拢，而不是漫无目的地变强。所以它永远不会跑偏，永远不会出现“改着改着突然开始说胡话”的翻车事故。

下面我把每个命令单独拎出来解剖，从它背后的认知逻辑到实操细节，一条一条拆干净。

/create-agent：脚手架搭好，骨架自己长出来

新智能体的第一行代码怎么来？大部分人打开编辑器，从import开始一行一行敲。但在这个流程里，一个斜杠命令就把整个架子搭完了。/create-agent的作用不是写业务逻辑，而是把目录结构、配置文件、工具接口、日志管道全部铺好，就像建筑工地上先浇筑地基和立柱，至于里面怎么装修后面再说。

这个命令背后跑了一套模板引擎。它读取你写在文档里的需求描述，比如“我需要一个每天抓取行业动态并生成简报的智能体”，然后从预设的组件库里挑出搜索引擎插件、网页解析器、简报格式化工具，把它们像乐高块一样拼在一起。拼出来的代码能直接跑，虽然功能简陋但五脏俱全，这就叫“脚手架”。你拿到的是一个70分水平的半成品，能干活但漏洞百出，然而它确实在干活。

从认知心理的角度看，这个命令解决了一个巨大的启动阻力问题。人类面对空白屏幕的时候，大脑的默认模式网络会异常活跃，焦虑感直线上升，你盯着光标闪了十分钟还没敲出第一个字符。但当你面对一个已经能跑起来的半成品，哪怕它错漏百出，你的大脑也会自动切换到修改模式，修改比创造轻松太多。/create-agent就是在利用这个心理机制，把“从零创造”降级成“从七十分改到一百分”，焦虑感直接砍掉一大半。

/improve-agent：自动找茬循环，跑一轮等于加班三小时

有了初始版本之后，核心命令上场了。/improve-agent是这个流程的心脏，它不写新功能，只干一件事：翻来覆去地测试现有功能，直到所有预设考题都及格。你输入这条命令之后，编码智能体会先读目标智能体的系统指令，再去数据库里刨使用日志，从这两个来源里提炼出一套考题，然后用这些考题去反复拷打目标智能体。

这套考题叫“探针”，每一个探针包含一个具体输入和一个预期输出。比如输入“给我五条今天的AI新闻”，预期是返回五条以内、每条一行、都有链接、没有形容词、且跟上一次的不重复。探针分好几类：黄金路径是正常问答，边缘测试是刁钻擦边球，工具选择是看它会不会调错API，对抗测试是故意问矛盾信息。生成完探针之后，编码智能体挨个去考目标智能体，考挂了的就改代码，改完重启，只重考挂掉的题，直到全绿。

这个命令最反直觉的地方在于它完全不依赖人工标注的测试集。传统开发里，测试用例是程序员手写的，写的时候就已经带着偏见——你会下意识绕开自己觉得没问题的功能点。但这里的考题从真实使用日志里长出来，用户问过的刁钻问题、模型答错过的边缘情况、工具调用失败过的路径，全都被自动转化成考题，逃无可逃。跑完一轮大概二十五分钟，相当于一个人类工程师加班三小时的找茬工作量。

循环迭代的过程像极了人类学习时的“主动召回”机制。认知心理学里有一个被反复验证的结论：反复阅读课本的效果远低于逼自己回忆内容，每回忆一次，记忆回路就被强化一次。/improve-agent正是在干这个事，让目标智能体一次次被召回考题，答错了就改代码，改完再考，直到答案稳定在最优解。而且它没有“厌烦”情绪，可以盯着同一个功能点换一百种方式去问，问到你崩溃它都不会累。

/extend-agent：加新功能不拆旧台子，依赖链条自动理顺

业务需求永远在变，今天要查新闻，明天就要查股票，后天还要查天气。在传统开发流程里，给一个已经跑通的系统加新功能是最容易翻车的时候，你永远不知道改了一行代码之后哪个老功能会突然崩掉。但在这个流程里，/extend-agent专门处理这个场景。

这条命令的工作方式是：先读取当前智能体的全部代码和规格说明书，然后把你描述的新需求翻译成新增的工具调用、规则条目和输出格式，最后把新代码塞进现有的目录结构里。它不会盲目追加，而是会检查新功能和旧规则之间有没有冲突。比如你要求新增股票查询功能，但规格说明书里有一条“每次输出最多五条信息”，那它就会自动把股票行情也压缩到五条以内，不会出现输出格式突然暴走的情况。

加完之后，/extend-agent并不会直接宣告完成，它会自动触发/improve-agent的一个精简版循环，只针对新增和修改过的代码块跑测试。这个设计借鉴了软件工程里的“回归测试”理念，但传统回归测试需要人工配置测试范围，而这里的范围是智能体自己根据代码改动量推算出来的。你只需要负责说“我想要什么”，至于“加上之后会不会搞坏别的东西”，它全包了。这就好比你在一个运转中的机器上换零件，换完之后机器自己会做一遍全身体检，只检查换过零件的部位，确保没有松动。

从认知负担的角度看，/extend-agent解决了“多任务切换”带来的心智损耗。人类程序员在加新功能时，大脑需要同时加载旧逻辑和新逻辑两套模型，来回切换极其耗能。而这个命令把切换成本全扛了，它负责维护两份逻辑的一致性，你只需要描述新需求，剩下的对齐工作全部自动化。

/deploy-platform：一键推到生产环境，连带启动参数全搞定

代码改完了，测也测通了，最后一步是让它真正上线干活。/deploy-platform就是干这个的。这条命令会检查当前环境里的容器配置、API密钥、数据库连接池、日志级别这些生产环境必需的参数，然后一次性全部推到线上。

为什么这个命令值得单独拎出来讲？因为部署这件事，看起来就是“按个按钮上传代码”，但实际上藏着大量琐碎的配置坑。OpenAI的API密钥有没有过期？Docker容器有没有分配足够的内存？日志存储路径有没有写权限？这些东西每一种都足以让部署失败，而且每一种报错信息都又长又臭，人类看着就头大。/deploy-platform的编码智能体会逐项检查，缺什么补什么，哪项配置不对就改哪项，改完再检查一遍，确认万无一失才开始真正的部署流程。

从风险管理角度来说，这个命令也自带“金丝雀发布”逻辑。它不会一次性把所有流量切到新版本，而是先在内部环境跑几个典型用例，确认所有探针都过了才开始对外服务。如果你观察过人类运维工程师的操作习惯，会发现他们最紧张的时刻就是点下“发布”按钮的那三秒钟。而这个命令把这三秒钟拉长成了三分钟的自动化检查，焦虑感全交给代码去承担了，你只需要等最后一行“部署成功”的日志。它的检查清单比任何人类运维都细致，因为它不会因为疲劳而漏掉一个环境变量。

四个命令串成的闭环，把认知负担碾碎了

回到最开头那张流程图，箭头走向已经把逻辑说透了。/create-agent是唯一的入口，跑完得到初始代码。然后进入一个由/improve-agent和/extend-agent组成的循环：改功能→测试→再改功能→再测试，无限迭代直到功能完整且全部测通。最后/deploy-platform上线。上线之后如果需求变了，不会回到/create-agent，而是直接走/extend-agent然后继续循环，因为代码骨架已经定了，只需要在骨架上添肉。

这个循环的设计暗合“最小可行产品”加“持续迭代”的现代软件工程理念，但把它完全自动化了。传统流程里，产品经理提需求、开发写代码、测试写用例、运维管部署，四个角色接力跑。而在这里，四个命令把四个环节全吞进去了，你一个人的角色从“执行者”变成了“命令调度员”。

表面上看这四个命令是在操作代码，但底层机制其实是对认知负担的逐级拆解。/create-agent把“怎么写代码”降维成“选什么组件”，把开放性创造任务变成封闭性选择任务。/improve-agent把“怎么找bug”降维成“跑通预设考题”，把无边界的质量保证变成有边界的考试刷分。/extend-agent把“怎么加功能不翻车”降维成“自动回归测试”，把高风险手术变成低风险微创。/deploy-platform把“怎么上线不崩”降维成“自动化检查清单”，把临场紧张变成按部就班。

这四个降维动作合在一起，产生了一个非常反直觉的效果：写代码这件事的复杂度没有消失，但被重新分配了。以前复杂度集中在程序员的大脑里，你要同时记住全局架构、局部逻辑、边界条件、部署参数。现在复杂度被分散到了四个命令的执行过程中，你的大脑只需要管一件事——在合适的时机输入正确的命令。这就像从手动挡换到自动挡，发动机的复杂度还在，但你再也不用操心离合器和换挡时机了。

说真的，我第一次跑完整套流程的时候，盯着那条“/deploy-platform”的日志发呆了好几分钟。从空白屏幕到线上服务，中间的所有代码行、测试用例、配置参数，没有一行是我亲手敲的。我做的事情就是在四个节点各输入了一次斜杠加单词。这感觉不像在写程序，更像在遥控一支从来不睡觉的工程队。以前我教实习生改bug，要讲三遍逻辑再看着他改两遍，最后还得自己上手擦屁股。

现在好了，我只需要敲一条命令，然后去泡杯咖啡，回来连测试报告都打印好了。这世界确实在变，变得让我这个写了十年代码的人，开始认真思考自己是不是也该去学点新技能了——比如怎么更好地给智能体写命令。