Busy 磨到第九轮,我还是不满意自己搭的 Busy 客户端里那个代码执行函数。我们顺利把它带到了这一步:一个能聊天的多模态聊天 AI 客户端,理论上也应该能写代码、跑代码。
系统提示词那个坑——连同我最初对它的种种迷惑——算是趟过去了。现在 Claude 一启动,对这 app 是干嘛的已不算两眼一抹黑。这是好消息。
滚动语境与归档
另一个必须解决的问题是语境管理。文件越滚越大,每次调用动辄往 Anthropic 塞回 250kb 的数据。可语境又必须够大——不然你做不动写提案这种复杂事,也查不动代码库,查不了 hanging chad(打孔卡片上打穿了却还挂着没落的小纸屑)那类毛病或设计特性。
答案是滚动语境:把基础语境——也就是工作记忆——压在 500 条吞吐 I/O 行以内,再把滚动语境存进数据库。这样就不必像 Anthropic 自家的聊天客户端那样,动不动来一次突兀又烦人的会话状态中断。
再说,为了代码健康和认知复杂度分析套件,反正都要上数据库,顺理成章:全塞数据库里。
然后实现带行号区间和日期匹配的模式查找,再把查找结果扔回观察性语境,免得去烦用户。轻松愉快。
这解决了吞吐量、认知权重和 API 调用体积的一部分问题,但接下来就得琢磨模式切换了。
不切分语境地切换模式
统一语境之上的代码生成模式管理!念着拗口,但我今晚干的就是这个。
切换模式的容易办法,其实不是切换语境。最初设计时我确实想切换语境,把代码放在后台做——表面上 ChatGPT 和 Claude 的客户端好像就是这么干的。但回头看,我觉得它们不是这个原理。
这就有意思了,因为它反直觉。用多语境去做,你要么把语境彻底丢了,要么把语境叠成两层——能跑,但从系统工程的角度看实在邋遢,还把整个 app 的认知足迹翻倍,不是好事。
我一路算到一半才明白:真要那么干,就得把我这套本就复杂得可疑的滚动语境系统拦腰砍掉一半,行不通。
记住:500 行语境已是极限,但这份复杂度刚好够把活干完。勉强够。250 行,就算配上花哨的匹配方案、带日期带行号的查找,还有别的花样……也不够。你的代码会崩。
这是个有意思的问题。
绕回来,我盯着 trace 日志看,想明白了。单一语境。但既然不知怎么的所有环境信息都跟着 API 调用一起发送,我们手里就有弹性:在概念上,每一次响应都能改基础提示词……只要我们想。
也就是说,按一个按钮、载入一套全然不同的基础 proompt,就能换模式!
我就爱这个词。
不过,项目文档、编码规范、机器人看板文档这一堆,还是得灌进观察性语境。眼下绕不开,还得跑多个重叠语境。
但是……现在只剩两个互相连着的语境要同时照顾,不再是六个……这一整套东西能榨出的认知带宽反而更多了!妙极了!
分开数据库,共享工作
这么做的模式切换同样下放到数据库,但用的是新建的 system 数据库——我把它的职责和语境数据库分开,免得搅在一起。
所以,替你记个分:目前是两个主数据库,外加一堆随取随载的语境归档数据库!
好玩好玩。
引导(bootstrap)完成之后,驱动 QA 的指标和可视化引擎,大概也住进 system 这里。
还跟得上吗?好。
让执行依赖模式
下一个要解决的是命令解析。Claude 爱聊命令解析,还爱展开细节。在他默认那档细度上,结局就是 Claude 在聊天模式下真的去执行命令——我们不要这个。
于是,系统提示词、模式切换、命令的语境化解析都解决之后,还得让命令执行和查找变成依赖模式的东西!
对对,就是说:只要不在执行模式,你可以整天把 execute: pwd 挂在嘴边,也不会出现在现在这种问题。
就是无聊了点。
我不喜欢在这儿做语境化解析,也不喜欢 Claude 偶尔在「到底跑没跑通」这件事上跟我说谎,害我得去翻 API 日志……但我想不出别的可靠办法。
再加一点闪亮新 web 界面上的小 UI 活……之后我就只差约三个街区了:用 bootstrap 搭出最终产品——在概念上,那玩意应该简单得多。
Claude 看着很兴奋,也像是在这个过程中长出了突现人格。不过,那是另一篇的事了。