JitHub程序员

分享下一些个人 AI Coding 的实践技巧

最近一直用第三方 App 记录养娃数据，但它的统计图不够直观，且不知道是否科学喂养，然后就想把自己的数据拿出来丢给 AI 分析分析，于是开始捣鼓抓包。

结果给抓包工具越改越多：接上 MCP，让 AI 能直接查看请求、分析接口、整理和导出数据；又加入各种各样的功能工作台。

最后干脆开源了：
👉 github.com

（图 1 是抓包工具，图 2 是 codex 生成的数据分析图

我以一己之力，用三年时间，带起来了国内独立开发做出海网站赚美元养老行业。
让不少中老年程序员焕发了第二春，让不少新程序员找到了人生方向。
今天是中秋节，大家有什么想说的吗？

今天给大家推荐一个网站，作者是 @limbopeng

dev.limbo101.win

网站是 limbo 写的一系列教程，这才是教程该有的样子，每个教程都有详细的文字介绍，配上可视化可交互的图示讲解，深入浅出。他的教程范围很广，包括 Pi、JEV、DSH、GPU 和 LLM，也都是我感兴趣的领域。

之前我想了解下各种模型的各种参数怎么理解，本地部署的话要选择什么配置，TTFT跟什么因素有关，输出token速度跟什么因素有关，权重、精度、KV Cache、并发、上下文、带宽、Perfill、Decode等很多模糊的概念也都有了新的认识，现在自己也能手算各种参数各种配置了 😂

总之，非常推荐这个网站，一起学习，夯实基础 👊

经历了不知道多少次的反复挣扎，我们决定把过去三年积累的 48 场内部主题分享、10 节推特增长课和 13 节出海实战课，累计 68 小时 14 分钟，
做成一份完全免费的 Playbook 分享给想做出海产品的大家！

累计消耗 16.19 亿 Token，历时 31 天，
梳理出 15 个主题任务簇、270 个知识点、118 个案例和 226 项重复或冲突记录，制作 48 份逐章来源映射，核查 218 个外部网址，
最终重编为 9 个模块、48 篇、约 30.4 万字的 Playbook。

今天 Beta 版免费开放给大家 👉 chq.sh

从选品验证、设计、定价、发布，一直走社媒、增长、运营合规等等，希望对大家出海之路有所帮助！

在大家都讨论 Muse 的时候，有一件事好像被大家忽略了。

Workbuddy 的用户，现在可以直接开发小程序了。

开源未必一定为他人做嫁衣，但当嫁衣做了太多次，缝衣的人总会想停下来看看自己还剩什么。

Jev + 输入法

经常在打字的过程中，发现想输入的那个字在输入法的很后面，要找半天，于是测试了一下 jev + 开源输入法鼠须管 / rime，感觉还不错！
但是 jev 没有预测，无法扩展用户的输入，还得接一个类似 cursor 的 tab 补全模型。

Douchat × Jev：让多个 Agent 围绕任务协作

最近在 Douchat 接入了 Jev，尝试把群聊里的多个 Agent，从“轮流回复消息”变成“围绕一个任务协作”。

整体思路是：Jev 负责结构化判断，LLM 负责规划和执行，程序负责调度、状态记录和故障恢复。

下面是目前的实现，以及接下来想完善的方向。

## 1. 决策配置

提供两种决策模式：

- 默认决策：复用群成员配置的 LLM，不需要单独配置决策模型。
- Jev 决策：使用 Douchat 云端决策服务，消耗决策积分。

决策模型负责“谁来做、怎么组织”；真正执行任务时，各个 Agent 仍使用自己的模型和工具。

Jev 不可用、判断不确定，或者任务需要复杂规划时，会自动回退到成员 LLM。

## 2. Leader 选择

新任务进入群聊后，程序先检查成员的可用性，再结合任务、群聊上下文和成员能力选择 Leader。

默认模式由成员 LLM 返回 Leader 和执行计划；Jev 模式通过 Choice 选择适合的 Leader。

Leader 不固定为群里的第一个 Agent。对于同一个任务的后续协作，会尽量保留健康且合适的 Leader，避免频繁切换。

这里的 Leader 是任务组织者，真正的派发、超时处理和状态持久化由程序完成。

## 3. 判断是否需要协作

不是每条群消息都需要所有 Agent 回复。

决策层先判断当前应该：

- 无需回复；
- 由一个成员直接处理；
- 由多个成员独立并行处理；
- 按顺序完成成员贡献；
- 进入更复杂的任务规划。

当前 Jev 会通过 Noul，逐个判断候选成员是否仍有必要参与。明确相关的成员入选，明确不相关的排除；判断模糊时交给 LLM 进一步规划。

Leader 选择、路由和成员相关性等独立问题，可以合在一次 Jev 请求里，减少多次请求的等待。

## 4. 任务分工与执行

简单任务直接分配，复杂任务由成员 LLM 生成计划，明确：

- 哪些成员参与；
- 每个成员具体交付什么；
- 按什么顺序执行；
- 是否需要 Leader 最后汇总；
- 是否缺少必要信息，需要先等待用户补充。

当前支持单人、串行和并行执行。串行任务中，后续成员能看到前序结果；独立任务可以并行，最多同时执行 4 个成员。

不要求 Leader 每次都先说一句“收到”。能直接开始的工作就直接开始，需要主持、准备或澄清时才先由 Leader 发言。

## 5. 故障恢复与任务收尾

成员执行失败后，调度器会再次请求决策，选择跳过、替补或暂停。

不同任务的处理不同：个人参与类任务不能由别人冒充完成；明确要求的交付物不能因为成员失败就静默跳过。

已完成的结果会记录下来。对于中断后可能已经产生外部操作的步骤，不会盲目重跑。

需要继续协作时，决策层结合已有结果安排下一步；需要用户补充时进入等待；完成后由 Leader 按需汇总。执行过程也有次数和超时限制，避免 Agent 无限互相交接。

## 6. 接下来想补齐的部分

目前的计划主要还是“成员分工＋串行／并行”，下一步希望升级为显式 DAG：

A、B 并行调研 → C 整理方案 → A 审核 → Leader 汇总。

每个任务节点拥有独立 ID、依赖、执行者、交付物和状态，由程序根据依赖推进。

在此基础上，再补三件事：

- 任务级监工：执行器上报心跳、实际进展和阻塞原因，区分“还在线”和“还在推进”。
- 结构化接管：替补继承已完成工作、产物和剩余任务，避免从头再来或重复操作。
- 结果验收：每轮先检查交付物是否满足要求，再决定完成、返工或继续拆解。

成员选择也可以进一步引入 Score，针对不同子任务评估适配度，同时考虑置信度和团队能力覆盖。

我觉得多 Agent 群聊真正难的地方，在于让每一次参与都有明确责任：为什么需要你、你要交付什么、依赖谁的结果，以及什么情况下才算完成。

---

欢迎来 douchat.ai 建群玩谁是卧底。😄