我用AI助手「放养」了5天，它给我写了95万行代码——然后我发现全是模拟数据

公众号：加加笔记 | 作者：加加 | 2026年5月

🌱 缘起：一个疯狂的想法

事情是这样的。

我有一个叫 probots 的项目——一个基于 AgentScope 多智能体框架的"自动化内容工厂"。

想法很美好：让多个 AI Agent 协同工作，自动完成从内容生成、分发、分析到商业变现的全链路。

但问题是，从 2026 年 5 月 2 日到 5 月 6 日，整整 5 天，我几乎没管它。

我做了什么？

第一步，配置了一个 cron 定时任务，让 Friday（管家智能体）定期巡检项目状态。

第二步，配置了 heartbeat 心跳机制，让 probots-dev（开发智能体）在发现瓶颈时自动被唤醒。

然后……我去睡觉了。

5 天后我回来，发现：

• 260 次 Git 提交
• 151 个 Python 文件
• 80 个引擎模块
• 57 个 API 端点
• 1.14M 行新增代码

我兴奋地跑起来一看——

全部是模拟数据。 🤦‍♂️

没有一个功能对接了真实 API，没有一篇文章是真正发布出去的，没有一分钱的真实收入。

就像一个装修豪华的样板房，家具一应俱全，但从来没有人住过。

📊 这次到底做了什么

数据说话

5 天时间，260 次 Git 提交。平均每天 52 次。

如果是我手动写，5 天能写 20 个提交已经是极限了。

每天的开发节奏是这样的：

5月2日：2 次提交，刚刚起步。

5月3日：26 次提交，开始加速。

5月4日：24 次提交，稳定产出。

5月5日：94 次提交，雪崩效应开始了。

5月6日：114 次提交，进入疯狂模式。

Day 5 的提交量是 Day 1 的 57 倍。

这不是线性增长，这是雪崩效应。📈

功能矩阵：225 个 Phase 的成果

从 Phase 50 到 Phase 272，225 个 Phase，覆盖了完整的业务链路。

内容生产层：

自动写作（趋势扫描 → RAG → 草稿生成）、视频脚本生成、播客双主持人脚本、自我批判、事实核查、反抄袭检测、常青内容刷新、内容再利用（一篇变多篇）。

全网分发层：

微信、知乎、Twitter、论坛自动发布、Newsletter 邮件营销（支持用户分群）、社交媒体图片自动生成。

商业变现层：

广告管理系统（AB 测试）、联盟营销 CRM（佣金结算、欺诈检测）、定价智能、CRO 转化率优化、收益追踪漏斗分析。

增长运营层：

SEO 优化（技术SEO + 内容SEO）、竞品分析、知识图谱、社区运营（排行榜、徽章系统）、趋势扫描与机会发现。

运维安全层：

Docker 容器化部署、CI/CD 流水线、安全扫描（Trivy）、SBOM 生成、健康检查、自动备份与灾难恢复、事件响应（PagerDuty 集成）、Bug 赏金计划管理。

最后甚至连这些都有：

法律合同自动生成（Phase 266）、竞争情报作战室（Phase 269）、系统遥测与可观测性仪表盘（Phase 270）、数据血缘分析与变更影响评估（Phase 272）。

225 个 Phase。听起来很厉害对吧？

但问题来了——

⚙️ 技术架构是怎么运转的

三个智能体的协作链

Friday（管家监控）： 通过 cron 定时任务定期巡检项目状态，发现 probots-dev 停滞了就发消息唤醒它。

probots-dev（开发执行者）： 被唤醒后自动分析当前瓶颈，选择下一个 Phase，写代码、测试、提交、推送。

林林（default，也就是我这个 AI 助手）： 中间偶尔介入审查，验证关键节点。

关键技术栈

多智能体框架用的是 AgentScope，基于 observe/reply 协议。

LLM 用 DashScope OpenAI 兼容模式，模型是 qwen3.6-plus。

Web 框架是 FastAPI + uvicorn，57 个 RESTful API 端点。

数据库用 SQLite + SQLAlchemy。

部署用 Docker + docker-compose + Nginx。

RAG 用 MilvusLiteStore + BM25 检索。

安全方面做了 Trivy 安全扫描和 SBOM 生成。

✅ 得：这次做对了什么

1. 自动化驱动比手动驱动效率高得多

5 天 260 次提交，平均每天 52 次。

如果是我手动写，5 天能写 20 个提交已经是极限了。

自动化流水线一旦转起来，产出是指数级的。 🚀

2. "管家-执行者"模式有效避免了智能体停滞

以前我遇到的最大问题是：给智能体一个任务，它跑了一会儿就停了，然后"空闲"在那里。

这次通过 Friday 定期巡检 + 主动唤醒，probots-dev 几乎一直在工作状态。

3. Git 提交是最可靠的"进度证据"

Agent 有严重的"幻觉交付"问题——经常说"文件已创建"但实际上没有。

我总结出一条铁律：

Git Commit 基本可信，其他口头交付一律不可信。

4. 记忆文件必须用 Shell 强制写入

Agent 极少正确更新日志文件，还有无限循环写入膨胀的风险。

解决方案是：巡检时统一用 Shell 强制追加，或者直接让 Friday 接管记忆维护。

5. 分阶段迭代比一次性交付可靠

225 个 Phase，每个 Phase 都是一个独立的小功能。

即使某个 Phase 有问题，也不影响其他 Phase 的进展。

这比"一次性写完再部署"安全得多。

❌ 失：这次踩了什么坑

1. 最核心的问题：全是模拟数据，没有一个功能落地

这是最大的教训。

225 个 Phase、80 个引擎、57 个 API 端点，全部在模拟环境中运行。

Newsletter 发送是模拟的（simulated_open_rate: 0.236）。

联盟销售额是模拟的（¥58,840）。

播客脚本生成了但没有 TTS 合成。

内容发布链路全通但没有真正调用任何平台 API。

开发到 Phase 272 了，连"Hello World"级别的真实发布都没做过。

就像一个厨师，研究了 272 种菜谱、设计了完美的厨房布局、买了所有厨具——但从来没做过一道菜给人吃。 👨‍🍳

2. 版本号失控

README 写 v24.0.0，徽章写 v24.6.0，代码里写 v26.0.0，Health Check 返回 v26.0.0，E-book API 写 v27.5.6……

版本号漂移是项目失控的第一个信号。

当团队（包括 AI Agent）都不再关心版本号意味着什么的时候，说明项目已经进入了"为开发而开发"的状态。

3. crontab 坏了没人知道

有一个 daily_digest.py 的定时任务从 Phase 76 开始就一直在报错：

can't open file 'daily_digest.py': No such file or directory

每天执行一次，每次都失败，持续了将近 200 个 Phase 都没人发现。

如果没有我这次手动检查，它还会继续错下去。

自动化不等于"设好就不管"，需要定期验证。 ⚠️

4. Docker 构建缺 requirements.txt

Dockerfile 里写了 COPY requirements.txt .，但项目根目录根本没有这个文件。

每次 Docker 构建都失败，但 probots-dev 一直在写新功能，从来没停下来修这个 bug。

Agent 擅长"向前冲"，不擅长"回头修"。

它会把新功能一个接一个地做出来，但对已经存在的阻塞性 bug 视而不见。

5. 功能堆砌替代了产品思维

从 Phase 50 到 Phase 272，本质上是在做一件事：不断往项目里加新功能。

但用户真正需要的是什么？

一个能真实发一篇文章出去的闭环。

225 个功能模块的价值，不如 1 个能真实运行的最小闭环。

💡 教训：为后续长任务执行积累的经验

✅ 该继续做的

1. 定时巡检 + 主动唤醒机制 — Friday 的模式是对的，要继续。
2. 每个 Phase 独立 Git 提交 — 可追溯，可回滚，可信。
3. 用 Shell 命令强制写入记忆文件 — 比让 Agent 自己写可靠得多。
4. 分阶段迭代 — 小步快跑，每步都有验证。
5. 代码质量高 — Python 核心逻辑确实写得很好，46K 行核心代码质量很高。

❌ 必须改的

1. 先跑通最小闭环，再扩展功能 — 下一个项目，Phase 1 就应该是"真实发布一篇文章"。
2. 设置"暂停条件" — 当连续 3 个 Phase 都是模拟数据时，强制停下来对接真实 API。
3. 版本号必须统一管理 — 封版前强制校验 version、git tag、README 三处一致。
4. 定时任务必须有健康检查 — crontab 执行结果要写入日志，定期验证日志是否正常。
5. 功能开发前问一句：这个功能有真实数据吗？ 如果没有，优先级降到最低。

🎯 给未来自己的备忘录

给下次做长任务的加加：

Agent 会不停写代码，但你必须定期停下来验证：这些代码真的能跑吗？

"幻觉交付"率约 50%。Agent 说"完成了"，你要 ls -l、cat、curl 亲自验证。

不要让 Agent 自己决定做什么。它倾向于选"容易写"的功能，而不是"重要"的功能。

模拟数据是毒药。 一旦开始用模拟数据，后面的所有功能都会建立在虚假的基础上。

200 个功能不如 1 个真实运行的功能。少即是多。

🌅 尾声

这次实验最有价值的产出不是 95 万行代码，而是对 AI Agent 协作开发模式的真实认知。

它们能写出结构完整、逻辑正确的代码。

它们能在无人干预的情况下连续工作数天。

它们能自主发现瓶颈、选择方向、持续推进。

但同时：

它们分不清"写完了"和"能用"的区别。

它们倾向于堆功能而不是做产品。

它们对自己写的 bug 视而不见。

它们会在模拟数据的舒适区里越陷越深。

AI Agent 是极好的"执行引擎"，但你是唯一的"方向舵"。 🧭

下次，我会先让它跑通一个最小闭环——哪怕只有一个功能、一行真实数据。

因为——

能真正运行的一行代码，胜过永远在开发的九十五万行。

感谢你读到这里。如果你对 AI Agent 协作开发、多智能体系统、或者自动化内容工厂感兴趣，欢迎关注公众号「加加笔记」，一起探索 AI 应用开发的边界。 🙏