970
LAB

一、970 LAB 是什么

970 LAB
一个长期公开运行的个人 AI Lab

我把 AI 真正用进工作、家庭、生活和创造里。

做产品，做内容，搭系统，也会做一些以前因为开发成本、技术门槛、时间投入或者市场太小，而根本不值得专门去做的小东西。

但"AI 做出来了"不是终点。

东西做出来以后，还要放进真实世界：

有人看吗？
有人用吗？
真的解决问题吗？
真的节省时间和成本吗？
有人愿意持续使用，甚至愿意付费吗？

成功的留下。
失败的也留下。

这就是 970 LAB。

---

01｜在做什么

我在用 AI 做真实的东西。

有的是工作里真正运行的系统，有的是家里自己使用的应用，有的是已经公开的网站和内容，也会有一些很小、过去不值得专门开发的工具。

目前已经存在的实践包括：

• KOTOFAMI 集团母站；
• 客户问卷查询页；
• Yanfami 顾问平台；
• 日常运营驾驶舱；
• iPad 陪伴应用；
• 内容数据分析；
• 持续运行的 AI 协作机制。

其中已经公开可访问的包括：

• KOTOFAMI 集团母站，全站 V2 已于 2026 年 8 月发布；
• 客户问卷查询页，已经能够让用户凭编号查询、修改和删除属于自己的记录。

其他一些项目仍然只在真实业务或家庭环境中运行，不因为建立 970 LAB 就默认公开。

现在正在做的：970.group

970.group 本身也是一个 Experiment。

这一次，我想验证：

一个不亲自写代码的人，能不能把需求研究、方案、设计、开发、测试和上线的大量执行工作交给 AI、Agent 和不同工具完成，而自己主要负责目标、判断、授权和验收。

最终要验证的不是：

"AI 能不能生成一个网页。"

而是：

AI 能不能参与把一个真实网站从想法一直做到上线，并继续维护。

02｜在测什么

眼下通过 970.group，我主要在验证两件事情。

第一件：AI 能不能从工具变成持续工作的系统？

不是：

我问一句，AI 答一句。

而是：

我确定目标和边界，不同 AI、Agent、工具和基础设施根据各自能力承担研究、规划、设计、开发、检查和执行，关键动作留下可以核查的证据。

我想知道：

这种工作方式到底能不能长期运行。

而不是偶尔完成一次漂亮的 Demo。

第二件：当 AI 把"做东西"的成本压下来以后，会发生什么？

过去很多想法不是没有价值。

而是：

• 开发太贵；
• 团队太小；
• 技术门槛太高；
• 制作周期太长；
• 潜在用户太少；

所以根本不值得做。

现在我更想验证：

AI 能不能让这些过去"不值得做"的小需求，第一次变得值得尝试。

它最终可能变成：

• 一个网站；
• 一个小应用；
• 一个家庭工具；
• 一个工作系统；
• 一段内容；
• 一个 Workflow；
• 一个 Agent；
• 一个 IP；
• 甚至一门很小但真实存在的生意。

970 LAB 不预设答案。

先做。

再看真实世界怎么回答。

03｜什么成功了

最先确认的一件事情是：

AI 已经不只是能给建议，它真的可以参与把东西做出来。

现在已经有公开上线的网站，有在真实工作中运行的内部系统，也有在家庭环境中实际使用的应用。

这背后不是一次聊天完成的。

每天早上 07:30，所有项目的状态会自动汇总成一份，不需要我挨个去问。

这套东西已经无人干预地跑了很久。它不是我某天心血来潮做的一次演示，是每天都在发生的事。

不同 AI 和工具承担不同工作。

有的负责研究。
有的参与规划。
有的处理内容。
有的操作电脑、修改代码、运行测试。
有的承担自动化和长期任务。

具体工具会变化，分工也会变化。

角色应该跟着能力走，而不是跟着品牌走。

更重要的是：

关键动作要能够被检查。

谁改了什么、为什么改、测试有没有通过、最后运行成什么样，应该尽可能留下证据。

因为：

AI 说"完成了"，不等于真的完成了。

内容侧也已经出现了真实实践。

"四分离100讲"前 7 篇内容已经完成抖音、小红书、B站三个平台的数据抓取：

21 行数据，0 失败。

数据抓回来以后，并不是简单按照总播放量排名，而是进一步按照"发布后天数"进行日均归一。

否则刚发布的内容天然比老内容累计播放少，直接比较没有意义。

这类事情真正有价值的部分，不是：

"AI 会抓数据。"

而是：

AI 能不能把数据变成实际可以用于下一轮决策的东西。

05｜学到了什么

目前最大的一条：

东西做完了，不等于做成了。

长期以来很容易出现一种情况：

开发完成。
然后等审核。
审核完成。
然后没有发布。
发布完成。
然后没有推广。

最后东西一直留在本地或者内部。

真正去盘点以后会发现：

做出来的东西不少，真正公开让别人看到和使用的反而只是其中一部分。

从实验角度看：

没有进入真实世界，就很难完成真正的验证。

970.group 本身很大程度上就是为了解决这个问题：

把实践真正发布出去。

还有一条：

截止日期本身没有意义，必须先定义那一天到底要交付什么。

这次建站确定时间以后，真正有用的不是"三天"这个数字。

而是把范围钉死以后，才发现最先必须处理的是域名和基础设施，而不是首页到底用什么动画。

实验应该优先找到：

真正的瓶颈。

04｜什么失败了

失败也记录。

不是为了展示"AI 翻车合集"，而是因为：

失败本身就是实验数据。

目前已经发生过一些非常具体的问题。

一次构建直接改变了线上网站

AI 在电脑上执行了一个构建命令。

结果那台机器的实际部署结构里：

Build 本身就等于改变线上内容。

线上网站因此被换成演示版本，而且三天后才被发现。

问题并不只是"执行错了命令"。

更深层的问题是：

原来的安全边界只规定了"不允许部署"，却没有识别出这套基础设施里"构建就是部署"。

一份项目状态断了 77 天

最后排查发现：

几份规则互相引用，都认为状态维护应该由另外一个位置负责。

结果就是：

每一条规则看起来都合理，但最后没有任何一条真正负责。

一个没写单位的验收标准，让 AI 白跑三轮

验收标准只规定了数量，却没有明确单位。

AI 连续检查三次都无法匹配，最终甚至报告了一个实际上不存在的故障。

这些事情让我慢慢发现：

AI 协作出问题时，不能只问"是不是模型不够聪明"。

目标有没有说清楚。
权限有没有划对。
上下文够不够。
验收标准能不能真正执行。
基础设施有没有隐藏行为。
人的判断有没有遗漏。

这些因素经常一起决定结果。

所以：

失败也必须留下证据。