Tuesday, 7 July 2026

让自闭症孩子说出了“我爱你”

 还意外做成了一门小生意。

自闭症并不是一个小众议题。

世界卫生组织显示,2021年,全球大约每127人中就有1人处在自闭症谱系上。

对很多家庭来说,自闭症带来的挑战并不只存在于诊断书里。孩子想吃什么、想玩什么、哪里不舒服、害怕什么、喜欢什么,很多时候都难以被准确地表达出来。

多篇研究和综述提到,大约25%到30%的自闭症儿童在5岁后仍处于最低限度语言状态,难以发展出功能性口语。

本文的主角就是一位自闭症儿童的父亲。

他的儿子不是完全不能发声,但能说出的话很少,也很难稳定表达自己的需求。

他们试过传统的辅助沟通工具,做过语言治疗,做过他们所能接触到的各种尝试。但传统辅助沟通工具那些通用的图标、抽象的符号、陌生的声音,并没有真正抓住孩子的注意力。

于是,这位父亲决定自己做一个工具。

一个父亲,给儿子做了,一个定制的沟通工具

传统的AAC,也就是增强和替代沟通工具,通常是一块装满词语和图标的平板。孩子点击图标,把词语组合成句子,再由设备读出来。

有点像超市里会卖的那种给小孩子学拼音的早教点读面板,或者(原谅我使用这个比喻),像我们刷萌宠视频可能看到过的宠物交流按钮。

它们都有一个相似的基本逻辑:把需求拆成一个个按钮,按下去,声音就被说出来。

对一些难以发声的人来说,这类工具很有价值。尤其是那些能够理解语言、只是身体上很难把词说出来的人,AAC可以成为非常重要的表达方式。

但它未必适合所有孩子。

这位父亲发现,传统AAC的问题在于,它太依赖一套既有的符号系统:红色八边形代表“停止”,小箭头代表“下一步”,简笔小人代表某个动作……对成年人来说,这套系统有点像交通标志,看得多了就知道是什么意思。

但对他的儿子来说,这些符号太抽象了,孩子很难从这些陌生图标里看见自己的生活。

他们试着用了大约一年。孩子会拿起来玩几分钟,然后就把它放下,去找下一个玩具。治疗师和老师都认为,他对这个工具不感兴趣,很难被强行引导进去。

这位父亲后来意识到,这个工具离他的儿子太远了。他的儿子需要的不是什么通用图标库,而是一套能让他一眼认出来的东西。

于是,他开始自己做。

他不是完全的技术外行,按他自己的说法,如果一定要给他一个身份,大概可以把他理解成“前线部署型AI工程师”,但他自己并不太用这个词定义自己。他长期接触AI工具,也很熟悉怎么把这些工具用到真实任务里。

这一次,他先用两个小时vibe coding了一个便宜的网站原型,搭出基础导航,然后用ChatGPT Images生成了几百张词汇图片。

这些图片不是素材库里的标准图标。贝果是他儿子熟悉的奶酪贝果,玩具是他儿子真正拥有的那个玩具,那些动作图标,看起来就像他儿子自己在做那些动作。

这位父亲还把图片都做成儿子最喜欢的动画风格,这样一来,这个工具看起来就更像一本关于他自己生活的绘本,或者一集他熟悉的动画片。

声音也是定制的。

这位父亲克隆了自己的声音。因为在所有人里,儿子最常听他的声音,也最容易对他的声音产生反应。他希望当孩子按下按钮时,设备读出来的不是陌生机器音,而是爸爸的声音。

他还按照自己对孩子的理解,重新安排了词语和界面。这个工具不是要求孩子去适应一套通用系统,而是反过来,让系统尽可能靠近孩子已经熟悉的世界。

做好之后,他把这个网站加载到一台触屏笔记本上,拿给儿子试用。

孩子立刻被吸引住了。他不需要再费力理解“这个图标代表什么”,因为他一眼就能认出这是自己的食物、这是自己的玩具,这是自己的家人。

这孩子一遍又一遍地按着屏幕上他爷爷的照片,然后,他说出了有生以来最长的一句话:

“I really love you a lot.”

我真的非常爱你。

当时,大家都抬起头对着天花板(怕眼泪流下来),不知道该做什么反应。

那是他爷爷经常对他说的一句话,被这个孩子记住了,用自己的声音说了出来。

之后,变化开始变得更日常。

父母拍下他常吃的食物,告诉他伸出手的图片代表“我想要”,再教他进入食物列表。过去四年,父母很难弄清楚他到底想吃什么;现在,他可以点出“我想要橙子”“我想要花生酱饼干”“我想要法式吐司条”。

不过,这个工具带来的变化,也并不全是温情时刻。用了一段时间后,这个孩子反而变得很不高兴。

原因很简单:他现在有了一个“声音”,但他还不习惯拥有这个声音。

过去,他饿了、不舒服了、闹情绪了,父母会围着他猜。猜他是不是想吃东西,猜他是不是累了,猜他是不是哪里不舒服。

但现在不一样了,父母会指着平板,一遍遍对他说:“Tap to Talk”,按一下,说出来。

理解带来了新的责任。一个孩子突然有了表达工具,也意味着他要开始学习使用这个工具,不能再完全依赖大人的猜测。这当然会让他受挫。

但与此同时,他确实开始说得更多了。

按照这位父亲的观察,孩子开口说话的次数大约是此前的五倍。

他不只是按下“椒盐脆饼”的按钮,还会自己补一句:“I like that。”

他不只是按下“橙子”的按钮,还会用自己的声音说橙子“yummy”。

有一次在五金店,收银员给了他一颗糖,他向店员道谢:“thank you so much.”

这或许是这个工具所带来的最真实的变化,它把表达的入口往前推了一步,让孩子开始意识到:自己的需求可以被说出来,也需要被说出来。

从一个孩子到更多孩子,这位父亲意外做成了一门生意

这位父亲一开始并没有想创业。

他只是想给自己的儿子做一个更好用的沟通工具。用他自己的话说,这个工具是“专门围着儿子做出来的”:儿子的食物,儿子的玩具,儿子熟悉的人,儿子喜欢的动画风格,还有爸爸的声音。

但这个工具第一次被带到语言治疗机构时,事情就开始变得不一样了。

在候诊室里,其他几位母亲也看到了这个工具,而她们的孩子和他的儿子一样,很难靠口语稳定表达自己的需求——所以她们几乎立刻明白了这个工具的意义。

这位父亲说,那些母亲看到后哭了。他也在那一刻意识到,事情已经没法停在“这是我儿子专用的工具”这一步了。

很多孩子都困在和他儿子相似的问题里。他们不是没有需求,只是传统工具太标准化、太抽象,没能把他们熟悉的世界递到眼前。

儿子的语言治疗诊所想把这个工具用于其他孩子,学校也想用。按照这位父亲的说法,他没有主动推销过,只是“意外做成了一门小生意”。

他手头已经有太多事,但还是决定挤出时间,把这个东西做成能给更多孩子使用的版本。但从“给自己儿子做一个工具”,到“让别的家庭也能用”,中间还差很远。

如果只是把现在这套东西复制给别人,其实没有意义。因为这套工具之所以有效,恰恰是因为它不是通用的。换一个孩子,食物要换,玩具要换,家人要换,声音要换,动画风格也可能要换。

问题变成了:怎么让每个家庭都能快速做出一套“只属于自己孩子”的工具?

这位父亲开始把复杂度揽到自己身上。他知道,真正会使用这个工具的父母,往往已经很疲惫了。他们可能白天要工作,晚上要照顾孩子,而他们家里还可能有其他孩子。

所以,他设想的产品不能是“给家长一个空白面板,让他们自己填”。它应该尽量简单。

家长只需要告诉系统孩子喜欢什么颜色,选择孩子喜欢的动画风格,也许读一段30秒的脚本,再上传几张照片。剩下的事情,系统来做。

系统自动生成初始词汇表,自动生成图片,自动放到合适的位置,自动用熟悉的声音读出来。家长之后再慢慢补充:这个是孩子常吃的食物,那个是孩子最喜欢的玩具,这个人是爷爷,那个人是老师。

为了做到这一点,他还要重新整理词语和短语的分类方式。因为如果词汇没有稳定的位置,孩子就很难形成记忆;如果每个家庭都从零开始乱放,后面的教学模式、数据记录和自动调整也做不起来。

他甚至设想,未来家长可以像聊天一样告诉系统孩子的情况:孩子已经会哪些词,哪些词还不熟,最近对什么东西特别着迷,哪些按钮总是找不到。系统再根据这些信息,实时调整界面和训练内容。

由此,这个工具开始从一个家庭网页,变成了一个真正的产品雏形。

而到了这一步,价格、成本和边界也必须被想清楚。

这位父亲在原文里提到,他不能把它称为医疗设备,也不能直接把它称为AAC。它还太早期,也涉及太多合规问题。他只能以简单明了的方式描述其功能,然后才能在市场上销售它。

上面提到的AAC设备价格相当昂贵,如果直接从供应商那里购买硬件,成本可能会超过七千美元。但只要有一台平板,就可以接入他制作的程序。

价格上,他当时设想的是每月9.99美元;如果需要持续使用语音克隆,则可能是每月19.99美元。

他的目标是,当一个家庭不再需要持续生成新图片时,可以提供免费或更低成本的基础版本。

以上的这些内容是这位父亲在6月6日的分享。他在文章的最后写到:“再过几周,我觉得就可以让其他家庭也来尝试一下了。无论如何,希望能给大家带来好消息。”

我们翻到了后续,在7月4日,这位父亲又发了一篇文章,记录了这项工具的进展。

一个月过去了,这个工具的用途变得更加具体。

比如,孩子开始用它“告状”:有一次,弟弟偷偷脱掉尿布,他就反复按弟弟的按钮和“我需要上厕所方面的帮助”,直到妈妈注意到。

他也开始表达更复杂的愿望。爷爷奶奶离开之后,他会按下爷爷奶奶的头像,再按“again”和“more”,告诉家人他想让他们再来一次。

在餐厅里,他甚至能和父母“谈判”:再吃两根薯条,就可以得到一个冰淇淋甜筒。父母说出这些词,设备会在词块翻译模式里把它们变成一张张闪卡,让孩子看见每个词对应的含义。按照这位父亲的说法,几周前,这种来回沟通几乎是不可能的。

更重要的是,这个工具开始帮助孩子表达情绪和疼痛。

有一次,他在Costco崩溃。父亲问他为什么这么难过,他自己导航到情绪面板,按下了“nervous”。到了车上冷静下来后,父亲又问他感觉怎么样,他再次自己打开情绪面板,按下了“embarrassed”。

还有一次,汽车安全座椅的带子弄疼了他,他反复按“hurt”和“help me”,直到父母把车停下来,帮他调整好。放在过去,父母可能要等到回家以后,才知道他为什么一路不舒服。

这位父亲表示,如今儿子要玩具、食物、电影和节目,几乎都会通过这个设备表达,这让他有些恍惚,好像过去那个“不知道孩子想要什么”的世界真的过去了。

这门“小生意”也进入了更实际的阶段。

到了7月4日,他已经开始公开招募早期测试家庭。

他写道,目前这个工具只在另一个孩子身上测试过,还需要更多家长参与。他希望先找到大约10到20个孩子作为早期beta测试对象,测试期间,沟通主要通过邮件进行。他也希望在接下来两周内,把应用推向Android和Apple应用商店。

AI让高度个性化软件变得便宜

传统软件最擅长服务的是用户画像。

比如,一个产品面向“自闭症儿童”,面向“特殊儿童家庭”,面向“语言治疗机构”,这些标签当然有意义,它们帮助产品找到一群大致相似的人,也帮助公司判断市场规模、定价方式和销售渠道。

但真实的人很少刚好长在用户画像里。

一个孩子喜欢什么颜色,熟悉哪一种动画风格,常吃什么早餐,最喜欢哪个玩具,对谁的声音最有反应,看到什么图片愿意停下来注意,哪些词已经听过很多次,哪些动作和情绪还完全陌生,这些东西都很私人,很难被塞进一个标准产品。

传统AAC工具对很多人非常重要,但它天然要依赖一套通用符号系统:统一的图标,统一的分类,统一的词汇位置,统一的机器发声。

因为系统要服务很多人,就必须尽量抽象。可抽象并不代表全能,文章里,这位父亲的儿子就恰恰卡在抽象这里。

软件为了规模化,通常要把差异抹平;但这个孩子真正需要的,正是那些差异。

AI改变的是这件事的成本。

过去,为一个孩子单独生成几百张图片,按照他的喜好调整动画风格,克隆父母的声音,建立只属于他的词汇系统,再根据他的使用数据不断调整界面,几乎是一件不划算的事。很多家庭只能接受一个足够通用、但未必足够贴近自己的工具。

但生成式AI让这个逻辑开始松动。图片可以生成,声音可以克隆,词汇可以自动分类,界面可以根据反馈调整,甚至功能本身也可以借助AI工具快速搭建出来。

这位父亲在后续里直接写到:这是一件没有Claude Code就做不出来的事。

过去,我们谈AI应用,总是喜欢谈“通用”:通用助手、通用智能体、通用办公入口、通用工作流。但在这个故事里,AI的价值反而来自“不通用”。

它让每个有需要的孩子都能拥有一套更接近自己生活的界面,不要求孩子适应软件,而是让软件向孩子靠近。

在文章里,这位父亲分享,他的儿子在逛超市的时候,指着多芬肥皂上的那个白色图案,大声地(和他的妈妈说):“妈妈!看!有一只白鸽!”

这并不是一个非常宏大的技术场面,但它可能比很多宏大场面更接近技术真正改变生活的时刻。

一个孩子不是“自闭症儿童”这个标签本身,他是一个会记住爷爷说过的话、会想念爷爷奶奶、会因为安全座椅不舒服而难受的,真实的人。

这个故事同时也感动了很多人,网友纷纷留言:这就是人工智能的真正意义所在。

当我们谈论AI改变生活时,也许不能只看它替人写了多少代码、生成了多少文档、节省了多少时间。

还应该看见那些更小的时刻。

一个沉默了太久的人,终于有了更容易被听见的声音。

本文来自微信公众号“字母AI”,作者:袁心玥,36氪经授权发布。

Tuesday, 10 March 2026

连续运行30天的AI Agent系统

 智东西3月10日报道,海外知名AI科技博主、前谷歌产品经理Shubham Saboo近日在社交平台公开复盘了自己连续运行30天的AI Agent系统。 

在他的设想中,这支“龙虾团队”应该像一个自动运转的小型内容工作室:有人负责研究行业信息,有人负责写内容,还有人负责发布和运营账号,整个流程全天候自动运行。但现实很快给了他一记闷棍。 

最初几天,这套系统几乎可以用“灾难”来形容:负责写内容的Agent写出来的推文又长又空,读起来像模板拼接;负责搜集信息的Agent一天抓回47条所谓的“行业线索”,其中40条都是没用的假消息。 

Saboo后来回忆,那几天他几乎一直在给Agent“擦屁股”。他花在修改Agent输出上的时间,甚至比自己手动把这些事情做完还多。上线第4天,他差点直接把整套系统关掉。 

但事情在几周后开始出现转折。同样的模型、同样的提示词,第4周时,这些Agent生成的内容已经可以直接拿来用,大多数草稿只需要改两三个词就能发布。原本需要他反复返工的任务,开始自动跑通。 

在这份复盘里,他回答了一个问题:为什么那么多人“养虾”时,第一周就速速放弃,而有些人却能把龙虾变成同事,效率倍增。 

01 第1周几乎是“负收益”:改Agent比自己干活还累

Saboo最早上线的Agent是运营Agent——“Kelly”,负责运营他的X账号。第一天只是搭建环境,第二天开始生成推文,但结果并不理想。 

Kelly写出来的内容既冗长又套路化,经常使用列表和箭头符号,开头是“我很高兴宣布……”,结尾再配上一串标签,整体风格不是作者平时的表达方式。 

Saboo回忆,在第一周里,他几乎每天都在修改这些内容,花在修正Agent输出上的时间,比自己直接写一条推文还多。原本期待AI带来效率提升,现实却是不断修补错误输出,同时还要维护系统本身。 

后来复盘这段经历时,他把这个过程称为 “纠错式Prompt工程(Corrective Prompt Engineering)”。与其一开始就设计完美提示词,不如先在SOUL.md(Agent行为设定文件) 中写一个粗略设定,然后通过持续反馈不断修正,就像管理新员工一样。第一版通常很普通,第十版开始能用,第三十版才会真正稳定。 

Saboo坦言,在第一周结束前,他一度差点把整个系统关掉。 

02 把具体反馈写进文件,而不是停留在聊天里

Saboo发现,Agent真正变好的关键在于具体规则的积累。在“运营Agent”Kelly第一次生成推文后,他把一组明确规则写入Agent的记忆文件。 

这个记忆文件后来逐渐形成两个部分:一个叫“BAD”,记录所有被否定的写作模式,比如使用bullet points(项目符号列表)、箭头格式或领英帖子的语气;另一个叫“GOOD”,里面放的是作者过去表现最好的推文,让Agent在每次写作时进行模仿。 

随着这些规则不断累积,Kelly的表现逐渐改善。第10天时emoji基本消失,第15天开始模仿作者的句式结构,到第20天时,大部分草稿只需要改一两个词就能发布。 

Saboo认为,很多人使用Agent时会忽略一个关键环节:反馈必须写入文件,而不是停留在聊天记录里。如果反馈只存在对话记录中,下一次任务Agent就会再次犯同样的错误。只有当这些经验被写入可持续加载的文件,系统才会真正进化。 

03 一次错误,让研究Agent学会判断“信号”和“噪音”

Saboo的第二个Agent是研究Agent——“Dwight”,负责每天扫描AI行业信息,为内容团队寻找选题线索。第一次扫描时,Dwight推送了47条信息,其中40条都属于噪音:包括各种小更新、未经验证的传闻,以及几乎没有价值的项目。 

于是Saboo给了它一个非常严格的规则:如果读者Alex今天无法据此做任何事情,就不要推送。Alex是Saboo设定的目标读者画像:一位AI产品开发者。 

这个规则很快改变了Agent的行为。第10天时,Dwight每天只推送18条信息,而且大多有价值;到第25天时,数量减少到7条,但每一条都值得阅读。 

此外,一次错误也让系统进一步优化。Dwight曾把一个工具当成“新发布项目”推荐给Saboo,后来才发现,这个工具早已存在,只是当天有人在X上提到它。Dwight误把“被讨论”当成“刚发布”。 

Saboo随后调整流程,要求Agent在推荐项目之前必须验证发布时间,例如检查GitHub仓库创建日期、Hacker News发布时间以及实际发布记录。如果项目已经存在一周以上且没有明显更新,就直接跳过。 

他还彻底移除了GitHub趋势榜作为信息源,因为那里噪音太多,很多项目只是被重新讨论而已。取而代之的是goodailist.com(专门筛选新AI项目的网站)。 

04 Agent团队也会“发胖”:上下文太多反而拖慢系统

随着系统不断积累经验,一个新的问题出现了:上下文膨胀。 

Kelly的上下文一度达到161000个token,Dwight也超过156000个token。大量历史记录占据了模型的上下文空间,导致响应变慢,输出质量也开始下降。

Saboo最终对两个Agent进行了“压缩”:Kelly的上下文从161K减少到40K,Dwight从156K减少到43K。做法很简单,只保留当前真正有用的规则和记忆,其余内容全部归档。 

他后来把这件事变成固定流程,每两周检查一次Agent记忆文件。Saboo形容,这个过程就像软件项目里的代码重构,如果长期不清理,系统就会越来越臃肿。 

同一时期,他还解决了另一个系统问题。 

第三周时,定时任务调度器出现Bug:任务在队列中推进,但实际上并没有执行。Saboo几个小时后才发现问题,因为系统表面状态看起来一切正常。 

于是他新增了一个“首席运营Agent”——Monica。Monica负责定期检查系统“heartbeat(任务心跳信号)”。如果某个任务超过26小时没有运行,她会自动触发重新执行。 

05 每个Agent团队,都会经历的三个阶段

根据自己的实践经验,Saboo认为大多数Agent团队都会经历三个阶段。 

第一阶段是混乱期,通常发生在上线后的前一周。Agent输出内容普遍比较普通,修改成本甚至高于人工完成任务,很多人会在这一阶段放弃。 

第二阶段是稳定期,大约在第8到第21天之间。随着反馈不断积累,明显错误逐渐消失,输出开始接近可用状态,只需要少量编辑。 

第三阶段是复利期。当系统积累了足够多的规则和上下文后,Agent会逐渐理解用户的表达习惯和判断标准,新任务也能继承过去的经验,整体效率明显提升。 

在他看来,能够坚持度过“混乱期”的人,最终得到的是一套会不断学习的自动化系统;而那些中途放弃的人,则每一次都要从零开始。 

06 真正提升效率的是:两类文件和一个闭环

Saboo在复盘这30天时特别强调,真正会随着时间不断变好的,其实只有三样东西,其他部分基本都没有本质变化。 

第一类是记忆文件。记忆文件存放的是Agent从反馈里学到的“偏好”,每一条反馈一旦写进记忆文件,就意味着这类错误以后不必再纠正一次。 

第二类是技能文件。和记忆文件不同,技能文件记录的是从失败中提炼出来的“操作规则”。Saboo认为,技能文件更像是任务说明书,它告诉Agent这项工作到底该怎么做,而不仅仅是用户个人偏好是什么。也正因为更具指令性,技能文件往往比记忆文件积累得更快,效果也更直接。 

第三类真正持续起作用的东西,是反馈闭环。Saboo认为,这是最容易被忽略的一环。很多人搭完Agent之后就让它自己运行,过几天发现效果没提升,便觉得系统没有用。但问题往往不在模型,而在于反馈没有真正进入系统。 

比如“运营Agent”Kelly写完一条推文,如果Saboo只是当场说一句“太长了,把第一段删掉”,但这句反馈没有被写进文件,那么下一次Kelly还是会犯同样的错误。只有当这条反馈被记录进记忆文件或技能文件,并在下一次任务开始时重新加载,Agent才会真正“记住”这件事。

Saboo自己后来形成了一套固定动作:先给反馈,再由Agent更新记忆文件或技能文件,下一轮任务开始时把这条经验重新加载进去。整个流程并不复杂,但前提是执行上必须足够严格。

在他看来,模型在第1天和第30天其实没有变化,不会越用越“聪明”。真正发生变化的,是围绕模型构建的系统——包括规则文件、记忆记录以及持续反馈形成的工作流程。 

07 他踩过的坑,也正是多数人会放弃的地方

回头看这30天,Saboo也总结了几个自己最典型的失误。 

第一个问题是Agent上得太快、太多了。 

他在两周之内一口气搭了6个Agent,结果很快发现:单个Agent本身都还没有进入稳定状态,多个Agent之间的衔接自然更容易混乱。更合理的方式应该是先把一个Agent做到稳定可用状态,再去加第二个。 

第二个问题是文件结构一开始就设计错了。 

最初两周里,他把所有内容都塞进同一个文件:偏好、规则、经验、教训混在一起。结果就是,Agent加载到的上下文经常互相打架。比如第一周形成的是一种表达偏好,第二周又写入了一条更明确的规则,二者之间可能彼此冲突,最终反而让Agent理解混乱。 

Saboo后来才把记忆文件和技能文件彻底拆开,并给自己定了一条更明确的要求:当上下文达到15万token以上时,就必须强力压缩,不能再拖。

第三个问题是反馈给得太模糊。 

Saboo认为,“把这个改好一点”这种话几乎不会留下任何有效积累,因为它无法写成一条规则,也无法指导下一次任务。真正有用的反馈,必须具体到足以直接写进文件。可靠的反馈不仅能解释为什么有问题,也能直接告诉Agent下次应该怎么改。换句话说,只有能被规则化的反馈,才有复利价值。 

08 如果从零开始,前30天应该怎么跑

在文章最后,Saboo也给出了一套更适合新手照着执行的30天方案。 

第一周,最重要的不是追求复杂系统,而是只挑一个自己每天最重复、最机械的任务。 

围绕这个任务搭建一个Agent,写好SOUL.md,设置一条简单的定时任务,让它先跑起来。Saboo提醒,这一周产出的内容大概率会很普通,甚至很糟糕,这本来就是正常现象。第一周唯一的任务是把所有错误都具体地纠正出来,不是简单说“这个不行”,而是明确告诉它:“这条不行,是因为X;下次请按Y来做。”

第二周,要开始检查这些经验到底有没有真正留下来。

Saboo建议,可以让同一个Agent跑两次相似任务,然后观察它是否还会犯同样的错误。如果同样的问题再次出现,就说明反馈闭环没有成型,也就是经验没有真正进入可持续存储的文件。这一阶段,用户应该开始建立自己的技能文件,把那些反复重复的规则正式写下来。

第三周,如果前两周执行得比较扎实,Agent通常会逐渐进入第二阶段,也就是“内容需要编辑,但不需要重写”。这个阶段可以开始记录一个更实际的指标:每次审稿到底花了多久。

Saboo认为,这个数字应该是一周比一周下降的。如果没有下降,通常不是模型不行,而是反馈仍然不够具体。 

到了第四周,才适合考虑引入第二个Agent,而且前提是第一个Agent已经能够稳定产出有用结果。 

Saboo建议,这时两个Agent之间的配合也不要设计得太复杂,最简单的方式就是基于文件协作:第一个Agent把产出写进共享文件,第二个Agent去读取这个文件再继续处理。集成方式越简单,系统越不容易失控。