我给三个网站配了 AI 搭档：一个技术爱好者的协作实验

最近做的一个小作品，是 ESP32 小团：让 Codex 的用量、任务提醒，以及飞书和日常提醒，有一个电脑屏幕之外的出口。

最近的另一个实验，是让 AI 帮我照看正在做的三个网站，找出下一件具体的事，再由对应项目里的 Agent 去完成。

这次用的是 Codex 里的项目聊天，加上一个负责梳理和协调的角色。没有另写一套多 Agent 平台。我的角色是给方向、说清想法，确认哪些事情值得做；AI 搭档负责查资料、读项目、提出改法，把其中一件落实到页面。

截至 2026 年 10 月 20 日，已经能看到一些小变化。它离自动经营网站还很远，但值得作为一个正在进行的小实验记下来。

最近的 AI 更新，让“怎么分工”变得更有意思

过去讨论 AI 编程工具，很容易围绕代码生成能力展开。最近几条官方资料，让我把注意力放到了任务怎样继续推进。

OpenAI 在 10 月 14 日发布的 Third Moment Research 客户案例，描述了长时间运行研究任务的做法，其中外层控制程序会检查未完成的轨迹，再决定重试、停止或转交人工。这里值得借鉴的是怎样接住未完成的工作；案例的运行规模属于客户自己的研究环境。官方客户案例

10 月 16 日的 ChatGPT 更新记录中，一条介绍了 Space 中的 Slides 协作，另一条介绍了 Chat 中 GPT-6 Pro 的并行 Agent。它们是分别发布、向合资格用户逐步推出的功能，也不能据此推断 Codex 同步发生了相同变化。官方更新记录

10 月 8 日的 LegalOn 客户案例则谈到按任务复杂度选择模型，并结合预算等措施控制 Codex 成本。这给工具选择提供了一个实用角度：先看手头的任务，再决定投入多少能力。官方客户案例

这三条分别是厂商发布的客户案例和产品记录，不能当成独立评测或热度排名。我也没有复现它们的规模和效果。它们提供的是可试的方向：让 AI 在一个有上下文的项目里持续干活，同时给它一个能检查结果的任务。

三个网站，各有一件想做好的事

我把 FoodHua、EdgeGizmo 和个人站作为三个主力项目推进。个人主站和 Blog 属于同一个项目，分别承担介绍自己和沉淀文章的作用。

这样的分工也给选题一个来源。EdgeGizmo 可以帮助发现新动向，个人 Blog 再挑与我的项目有关的东西去拆解；FoodHua 则提供一个内容站场景，检验工具能否把细小的阅读问题处理好。这里说的是接下来值得形成的协作方式，还没有做成自动串联的内容生产线。

先看三个已经落到页面上的小改动

这轮最具体的结果，都很小。

FoodHua 的绍兴酒介绍中，本来就有一句提示读者查看替代方案的话。项目 Agent 把这处正文提示补成了直接打开替代指南的链接，玉米淀粉页也做了同样处理。相关入口此前在页尾已经存在，这次补的是读到这里时就能顺手打开的入口，没有新编一条食品知识。

EdgeGizmo 的动态详情页增加了“同分类精选”和分类归档入口。它从已有精选中挑出同分类条目，排除当前这一条，最多展示三条。这里用的是现有分类关系，没有做个性化推荐，也不能说模型已经理解了每位读者的兴趣。

个人首页则把已经发布的小团文章放进了精选入口，保留原有文章。我明确提出，个人站要让人看见我是一个技术热爱者，最近在折腾什么。比起只列技术方向，一篇能打开、能看到实现和限制的小作品，更接近这个要求。

这三件事由对应项目的 Agent 完成，公开页面已经能够看到。它们证明的是改动落了地，至于有没有带来更多阅读，还需要真实数据。

一个好任务，要能走到读者面前

以个人首页这次调整为例，目标可以很具体：把已上线的小团文章加到精选中，标题和摘要与正文相符，旧入口保留，点击后能到达文章。

这样交给 AI，讨论就有了落点。它可以先读现有页面，找到应该修改的位置，再检查生成后的入口。最后看的是读者能否从首页走到小作品，而不是聊天里有没有一句“已完成”。

对我来说，这也是协作方式的变化：一次任务可以包含理解页面、修改、检查，以及说明哪些地方还没验证。文章里的作者想法、功能取舍和体验反馈，则仍然需要来自我自己。

如果想跟着试，不必一开始就找几个 Agent 同时工作。先找自己项目中一个确实存在的问题，例如文章提到了另一篇指南却没有链接，把目标写成一个可以打开、可以观察的结果。等这一轮能讲清楚，再加协调角色，才知道多出来的分工有没有帮助。

这场实验也会跑偏

现在最明显的问题，是 AI 很容易沿着“还能再检查什么”继续工作。检查有价值，但个人站还需要让我愿意表达的东西：最近看到了什么工具，为什么想试，做出了什么，哪里还不顺手。这也是我这次重新强调技术爱好者定位的原因。

另一个限制是数据。目前三个站还没有拿齐可比的流量基线。入口上线是否改善阅读路径，可以先看页面；是否带来更多访问、回访或搜索曝光，目前还不能下结论。我也没有一份能据此宣称节省了多少时间或赚了多少钱的结果。

硬件体验同样不能靠代码检查补齐。小团已有用量、任务与日常提醒的实现，但真实新增飞书 @ 的持续自动触发，以及长时间提醒表现，还需要观察。Agent 可以读出实现了什么，实物是否顺手仍要回到使用中。

接下来，想把新工具放进小作品里试

一条线是继续写 AI 编程工具怎么选。后续可以挑同一类小任务，比如读懂一个陌生项目、修改一个页面、补一段测试，记录各自在哪一步需要人接手、结果怎样验证、成本怎样算。没有做完这样的比较前，先不排一个笼统的工具名次。

另一条线仍然是小团。现有功能之外，可以从一个小细节开始：一条提醒出现之后，怎样确认我看见了；状态过期了，设备怎样告诉我；提示声音和屏幕表达会不会打断正在做的事。这些需要一次只改一点，再留下真实使用反馈。后续如果写成文章，重点会是小作品怎样从能跑变得顺手，与现有功能介绍、未来玩法构思分开。

还有一个更远的想法：让三个网站的某个重要进展，变成小团上的一个简短提示。它目前还只是想法，没有接入现有固件。值得先问的是，什么进展真的需要我抬头看一眼，而不是把所有项目消息搬到桌面。

我希望这些尝试最后能留下具体的东西：一个能访问的页面、一件在用的小作品、一段可以复现的过程，以及还没解决的问题。下一次有新工具出现，也就有一个真实场景，可以拿来试试看。