我们把 AI 塞进工作群，135 个代码任务、127 次答疑，它没建一个首页

一个 20 多人的技术团队，上线 AI 一个月，没做过任何培训。

没发手册，没开会，没排班，没搞「AI 学习周」。

就那么放进去了。

一个月之后：135 个代码任务、127 次群内业务答疑、20 多个活跃用户。

覆盖了团队 60% 以上的日常任务答疑和存量页面开发。

第一次看到这组数字，我第一反应是——他们是不是做了什么了不起的架构。

后来我才知道，最了不起的那件事是：他们什么都没建。

最反常识的地方，是他们没做那个「平台」

这是阿里云云原生团队 Domino 助手做的事。

按常理，团队做 AI，第一步都是先搭个门户：让用户登录、进工作台、想清楚要创建什么任务，再去跟 AI 聊。他们也想过，然后发现：没人用。

团队自己写下的一句判断，我认为是今年读到最扎心的产品洞察：

用户通常不会先打开一个 AI 平台，再思考该创建什么任务；问题往往直接发生在钉群里。

所以他们反过来做：不建入口，只认「在哪儿」。需求卡在哪个群里，它就出现在那个群里，你不用换场景。

这不是交互技巧，这是承认一个前提：工作发生在工位上，不发生在 AI 产品的界面里。

于是有了那句我常拿来提醒自己的结论：AI 要进入工作，而不是让工作迁移到 AI。

难点不是让它会答，是让它别每次都像第一次见面

一个在群里答题的 AI，最容易翻车的地方是失忆。你上午在 A 群问过的背景，下午在 B 群又要重讲一遍。

Domino 的解法是分三层上下文：

层级

范围

作用

群级 Session

只在当前这个群

眼前这摊事的连续性

KBase 空间记忆

跨群、跨会话

「这个人是谁、这事以前怎么处理的」

知识库 + CodeWiki

全局

正式事实源，唯一可信答案

关键是分层，不是堆叠。团队的原话：

上下文越多不一定越好，分层比堆叠更重要——把它们混成一段超长 Prompt，不仅浪费 token，也会模糊事实边界。

这句话我建议贴在任何 AI 项目的墙上：你最该保护的不是「记得多」，而是「什么算事实」。

边界也划得很硬：空间记忆不保存个人信息，工具按授权和白名单注入。翻译成人话：记得住你，但不许记你的隐私。

群里问两个开关，它追出了 5 个调用方

先说三个开关那个。

一位工程师在群里问：SUPPORT_STREAMING_BUY_USER_LIST 和 SUPPORT_STREAMING_BUY_REGION 这两个开关的逻辑是什么？

这种问题人回答得翻代码、串链路。它的做法是往下追，找到 isSupportStreamingRegion 的5 个调用方，然后输出一张总结表。

但真正值得看的是后半段。工程师补了一句：「国际站和国内站的 Viper 配置不一样。」

它的回应是：

这个背景很关键，我存到空间记忆里，同时修正我之前的说法。

这句「我修正我之前的说法」，是整套设计里最值钱的部分：它承认刚才那个答案是有条件的，现在条件变了，答案跟着变。

真正的日常长这样：从发现 bug 到合入，中间没人来回搬

另一个任务很具体：修 Confluent 售卖列表页的 GetSubscriptionPrice 重复请求，还偶尔报错，原因是参数 ServicePeriodQuantity 还没就绪。

它走完的路是：

Grep / Glob / Read → 改代码 → ESLint + build → commit push → CodeReview → 绑定迭代号。

从「发现」到「合入」，中间没有一次人工搬运。

但注意最后两步：CodeReview 和绑定迭代号。它干的是执行，人守的是流程。这条线从第一天到最后一天，一次都没松过。

但你同事问它，拿回来的建议和你不一样

这是整个故事里最扎人的地方，也是 Domino 身上最普遍的影子。

同一份团队规则，同一个任务，你和同事分别问各自的 AI，拿回来的建议不一样。

腾讯技术工程今年 9 月开源了 teamai-cli（MIT 协议，TypeScript）就是冲这个去的。它 README 里写着支持 11 款 AI 工具，但真正做到全能力覆盖的只有 5 款。

作者说得很直白：

不是模型不行，是你们加载的规则版本不同。

配套的痛点也很具体：新人入职，得挨个给 Claude Code、Cursor、Codex 手动配一遍 Skills 和工具权限，一下午就没了。

这个工具的识别机制我倒觉得挺聪明——它只认三种「摩擦信号」：你打断了它、它的工具调用被拒绝了、或者 60 秒内说了「不对 / 重来 / 错了 / wrong / redo」。

它不猜你满不满意，只记录你明确不满意的那几次。

把尺度拉到整个团队，这几个数字更值得盯

腾讯安全中心公开过一组实践数据：

指标

之前

之后

代码审查轮次

2-4 轮

1.1 轮

代码审查平均耗时

3.4 分钟

需求交付周期

天级

小时级

新人上手

30 天

10 天

舆情风险事件日处置量

400 条

1200 条

还有一个我更在意的数字：知识 99.7% 由流程和 AI 自动沉淀。

但里面有一条原则，我觉得比任何数字都重要：

人机共读——如果一条知识人看着都觉得莫名其妙，它的维护质量也不会好。

他们给每条知识设了默认 90 天有效期，过期治理完成率 90.2%。

让 AI 生成知识很容易，难的是让知识过期。

结尾

回到最开始那句「我们没做任何培训」。

AI 不用培训就能用起来，是因为它长在群里。但它能不能一直好用，取决于背后那三层上下文、有没有人 review 那些规则、有没有人定期删掉过期的知识。

全是笨活，也全是门槛。

所以如果你今天就想试一件事，别去申请平台。

去看你们团队最热闹的那个群，数一数今天有多少个问题，其实只是有人懒得翻文档。

至于更远一步的那个问题，我更想留给管事的人——

你的团队，愿意为自己写的 AI 规范走一次 code review 吗？

这是「数字生命岐伯」第 10 问。我，野慢，广东，25岁。白天在大厂做AI产品，晚上被AI教做人。今天这题我替你们问过了，坑也替你们踩了。想让我测哪个AI，评论区点单。我们，下篇见