1. 一个没走流程的项目群，是怎么被AI管起来的

去年下半年我接手了一个跨部门协作项目，涉及产品、设计、前端、后端、测试五个角色，外加两个外部供应商。按正常流程，这种规模的项目得先立项、走审批、申请资源、拉群、排期、建看板，一套下来少说两周。但当时的情况是：老板周一早上丢过来一句话，“这个项目你来牵头，周五之前我要看到能跑的东西。”

没有开发资源，没有走任何流程，连项目群都是我自己拉的。我当时的做法很简单——把AI拉进群，让它当我的“项目助理”。不是那种只会回复“好的收到”的机器人，而是一个真正能帮我管进度、催人、整理会议纪要、生成周报、甚至帮我写需求文档的AI协作中枢。

这套方法我跑了三个月，项目最终按时交付，团队里没人觉得被AI“管”着不舒服，反而有人主动问我怎么把AI用成这样。今天我把这套东西完整拆开讲，包括我用了哪些工具、怎么配置、踩过哪些坑、以及为什么有些做法我试了一次就放弃了。

如果你也是那种“手里没兵没粮但要打仗”的项目负责人，或者你只是想让AI帮你分担一些重复性的协调工作，这篇内容应该能给你省不少时间。核心关键词就几个：AI协作、豆包、飞书、钉钉、WordBuddy，我会围绕这几个工具展开，但重点不是工具本身，而是我怎么把它们串成一条工作流。

先说结论：这套方案的核心逻辑是“AI做信息中转和初加工，人做决策和最终确认”。AI不替你做决定，但它可以帮你把信息从A格式变成B格式、从散落状态变成结构化状态、从需要你手动催变成自动提醒。下面我按模块拆。

2. 整体设计思路：为什么是“聊天式管理”而不是“系统式管理”

2.1 传统项目管理工具的问题在哪里

我试过用传统的项目管理工具来管这个项目。Jira、Trello、飞书多维表格、钉钉项目，我都试了一遍。问题不是工具不好，而是启动成本太高。你要先建项目、配字段、设权限、拉人进来、教大家怎么用。对于一个“周五就要看到东西”的项目来说，这些准备工作本身就是负担。

更关键的是，团队里有人用飞书、有人用钉钉、有人只用微信。你不可能强制所有人切换到一个统一平台。我试过在飞书多维表格里建了一个任务看板，结果前端同事说“我平时不看飞书”，测试同事说“钉钉里能看吗”。最后这个看板变成了我一个人的自嗨。

所以我的思路转向了：不改变大家的沟通习惯，而是在大家已有的沟通渠道里嵌入AI能力。大家平时在哪聊天，我就在哪管项目。飞书群里聊需求，钉钉群里发通知，微信里对接外部供应商。AI的作用是跨渠道同步信息，而不是强制统一渠道。

2.2 AI在项目群里的三个角色定位

我把AI在项目群里的角色拆成三个：

• 信息中转站：把飞书群里的需求讨论整理成结构化文档，同步到钉钉群；把钉钉群里的进度反馈汇总成表格，回传到飞书。
• 进度催办员：根据我设定的时间节点，自动在群里@相关人提醒，不需要我手动一个个催。
• 文档初稿生成器：会议纪要、周报、需求文档、测试用例初稿，AI先出一版，我再改。

这三个角色对应的工具分别是：豆包做信息整理和文档生成，飞书机器人做跨群消息同步，钉钉卡片消息做进度提醒，WordBuddy做本地文档的批量处理和格式转换。

2.3 为什么选豆包而不是其他AI

我试过好几个AI助手，最后主力用豆包，原因有三个：

第一，豆包的网页版和桌面端都能直接用，不需要额外配置。我试过一些需要自己搭环境的AI工具，光是配置API key和网络环境就花了一下午，对于“周五要交付”的项目来说，这个时间成本我承受不起。

第二，豆包对中文办公场景的理解比较到位。我让它整理会议纪要，它能自动识别出“谁说了什么、结论是什么、待办事项是什么”，而不是简单地把聊天记录复制一遍。我试过用其他AI做同样的事，出来的东西还需要我重新排版。

第三，豆包的skill机制可以让我预设一些常用指令。比如我设置了一个“项目周报”skill，每次只需要把本周的聊天记录丢进去，它就能按我固定的格式输出周报。这个功能在豆包的桌面端可以配置，具体路径是设置里的“技能”或“Skill”管理。

注意：豆包的skill功能在不同版本里位置可能不一样，我用的桌面版是在左下角设置里找到的。如果你找不到，可以直接在对话框里输入“帮我创建一个周报生成的skill”，它会引导你配置。

2.4 飞书和钉钉的分工逻辑

飞书我主要用来做文档协作和机器人开发。飞书开放平台的机器人能力比较完整，我可以让机器人监听群消息、发送卡片、读写多维表格。钉钉我主要用来做消息触达和打卡类提醒，因为团队里有一部分人只装钉钉。

跨平台同步的核心思路是：飞书机器人监听消息 → 调用豆包API做信息加工 → 通过钉钉机器人发送结果。这个链路我后面会详细讲怎么配。

3. 核心细节解析：每个环节到底怎么配

3.1 豆包在项目群里的具体用法

豆包我主要用三个功能：对话整理、文档生成、指令预设。

对话整理的场景是这样的：飞书群里每天有几百条消息，我不可能一条条看。我的做法是每天下班前，把群里的聊天记录导出成文本，丢给豆包，让它按“需求变更、进度更新、问题反馈、待办事项”四个维度整理。豆包输出的格式我固定成表格，直接复制到飞书多维表格里。

文档生成我举一个具体例子。项目中期需要写一份接口文档，前端和后端在群里讨论了三天，消息散落在不同时间段。我把这三天的聊天记录合并成一个文本文件，丢给豆包，指令是：“根据以下聊天记录，整理出一份接口文档，包含接口名称、请求方式、请求参数、返回参数、备注。用Markdown表格输出。”豆包大概用了十几秒就出了一版，我改了改字段名和几个边界条件，直接发给前后端确认。这个过程如果我自己做，至少两个小时。

指令预设我重点讲一下。豆包的skill功能允许你把一段常用的指令保存下来，下次直接调用。我预设了五个skill：

这些skill的配置逻辑很简单：在豆包桌面端的skill管理里新建一个skill，把指令模板写进去，设置一个触发词。具体指令模板我拿“周报生成”举例：

你是一个项目周报助手。请根据以下聊天记录，生成一份项目周报。 要求： 1. 按“本周完成、下周计划、风险与问题、需要协调事项”四个板块输出。 2. 每个板块用无序列表，每条不超过50字。 3. 涉及人名时用@姓名格式。 4. 如果聊天记录里没有某个板块的信息，写“无”。 聊天记录如下： {{输入内容}}

这个模板里的{{输入内容}}是变量，每次调用时把聊天记录粘贴进去就行。

3.2 飞书机器人的配置要点

飞书机器人我主要用来做两件事：监听群消息并转发给豆包、接收豆包的处理结果并发送到群里。

配置步骤大致是这样的：

1. 在飞书开放平台创建一个企业自建应用。
2. 开启机器人能力，获取App ID和App Secret。
3. 配置事件订阅，订阅“接收消息”事件。
4. 设置请求地址，指向你自己的服务器或云函数。
5. 在服务器端写逻辑：收到消息后调用豆包API，拿到结果后再调用飞书的消息发送接口。

这里有一个坑我踩过：飞书的事件订阅需要验证请求地址，如果你用的是云函数，要确保云函数能正确处理飞书的challenge验证。我当时用的是某个云平台的函数计算，第一次配置时忘了在代码里返回challenge值，导致验证一直失败。后来在代码里加了一行判断就好了。

另一个坑是消息去重。飞书的事件推送可能会重复发送同一条消息，如果你不做去重，豆包会被重复调用，浪费额度。我的做法是在服务器端用一个简单的Set记录最近处理过的message_id，处理前先检查。

飞书机器人发送表格消息的能力也很有用。我让机器人每天下午六点自动发送一张“今日进度汇总表”到群里，表格数据从飞书多维表格里读取。这个功能的实现方式是：机器人定时触发 → 读取多维表格数据 → 调用飞书的消息卡片接口 → 发送到群。

3.3 钉钉卡片消息的用法

钉钉我主要用卡片消息来做进度提醒。钉钉的卡片消息比普通文本消息更醒目，而且可以带按钮，点击按钮可以直接跳转到飞书文档或者标记任务完成。

配置钉钉机器人的步骤：

1. 在钉钉开放平台创建企业内部应用。
2. 开启机器人能力，获取AppKey和AppSecret。
3. 在群里添加机器人，获取Webhook地址。
4. 调用钉钉的消息发送接口，消息类型选“actionCard”或“feedCard”。

我常用的卡片消息模板是这样的：

{ "msgtype": "actionCard", "actionCard": { "title": "任务提醒", "text": "### 任务提醒\n\n**任务名称**：接口联调\n**负责人**：@张三\n**截止时间**：今天 18:00\n**当前状态**：待开始", "btnOrientation": "0", "btns": [ { "title": "标记完成", "actionURL": "https://your-server.com/complete?taskId=123" }, { "title": "查看详情", "actionURL": "https://your-feishu-doc-link.com" } ] } }

这个卡片发到钉钉群里，负责人可以直接点“标记完成”，我的服务器收到请求后更新任务状态，并同步到飞书多维表格。

注意：钉钉机器人的Webhook有频率限制，每分钟最多发送20条消息。如果你的项目群消息量很大，建议做消息合并，比如把多个任务提醒合并成一张卡片发送。

3.4 WordBuddy在文档处理里的角色

WordBuddy我主要用来做本地文档的批量处理和格式转换。项目过程中会产生大量的Word文档、PDF、Markdown文件，我需要把它们统一格式后归档。

WordBuddy的一个典型用法是：把多个Word文档批量转换成Markdown，然后导入到飞书文档里。具体操作是在WordBuddy里选择“批量转换”功能，设置输入文件夹和输出文件夹，选择输出格式为Markdown，点击开始。转换完成后，我会检查一下格式有没有乱，特别是表格和代码块。

另一个用法是文档内容提取。比如供应商发来一份PDF格式的报价单，我需要把里面的表格数据提取出来放到飞书多维表格里。WordBuddy可以提取PDF里的表格并导出为CSV，我再把CSV导入飞书多维表格。这个过程比手动复制粘贴快很多，而且不容易出错。

WordBuddy还有一个功能我偶尔用：文档对比。当同一个文档有多个版本时，我可以用它快速找出差异。这个功能在需求文档频繁变更的时候特别有用。

提示：WordBuddy的批量转换功能对文件名有要求，建议文件名里不要有特殊字符，否则可能会转换失败。我遇到过文件名里带“#”导致转换后文件丢失的情况。

4. 实操过程：从零搭建这套AI协作流

4.1 第一步：确定信息流转路径

在动手配置之前，我先画了一张信息流转图（不是用工具画的，就是纸上画了一下）。核心路径是：

飞书群消息 → 服务器（云函数）→ 豆包API → 服务器 → 钉钉群/飞书群

钉钉群消息 → 服务器（云函数）→ 豆包API → 服务器 → 飞书群/钉钉群

定时任务 → 服务器 → 读取飞书多维表格 → 生成卡片消息 → 钉钉群

这张图帮我明确了需要配置哪些东西：一个服务器（我用的是云函数，因为不需要自己维护）、两个机器人（飞书和钉钉）、一个豆包API的调用封装、一个多维表格作为数据存储。

4.2 第二步：配置豆包API调用

豆包的API调用我封装成了一个简单的函数，输入是文本，输出是处理后的文本。核心代码大概长这样：

import requests import json def call_doubao(prompt, input_text): url = "https://api.doubao.com/v1/chat/completions" headers = { "Content-Type": "application/json", "Authorization": "Bearer YOUR_API_KEY" } payload = { "model": "doubao-pro", "messages": [ {"role": "system", "content": prompt}, {"role": "user", "content": input_text} ], "temperature": 0.3 } response = requests.post(url, headers=headers, json=payload) result = response.json() return result["choices"][0]["message"]["content"]

这里有几个参数我调过：

• temperature：我设成0.3，因为项目管理的场景需要稳定输出，不需要太多创造性。如果你用来做头脑风暴，可以调到0.7以上。
• model：我用的是doubao-pro，处理长文本的能力比基础版好。如果你的聊天记录特别长，可能需要分段处理。
• max_tokens：默认值可能不够，我设成了4096，确保长文档能完整输出。

注意：豆包API的调用需要API Key，这个在豆包开放平台可以申请。免费额度对于小项目来说够用，但如果消息量很大，建议关注一下用量。

4.3 第三步：飞书机器人监听消息并转发

飞书机器人的服务器端逻辑我写在一个云函数里。核心流程是：

1. 接收飞书的事件推送。
2. 验证challenge（首次配置时）。
3. 提取消息内容。
4. 判断消息是否来自需要处理的群。
5. 调用豆包API处理消息。
6. 把处理结果发送到目标群（钉钉或飞书）。

代码框架大概是这样：

def handle_feishu_event(event): # 验证challenge if "challenge" in event: return {"challenge": event["challenge"]} # 提取消息 message = event.get("event", {}).get("message", {}) chat_id = message.get("chat_id") content = message.get("content") # 判断是否需要处理 if chat_id not in TARGET_CHAT_IDS: return {"code": 0} # 调用豆包 processed = call_doubao(PROMPT_TEMPLATE, content) # 发送到钉钉 send_to_dingtalk(processed) return {"code": 0}

这里的关键是TARGET_CHAT_IDS，我把我需要监听的飞书群ID都配在这个列表里。飞书群的ID可以在群设置里找到，或者通过飞书开放平台的API获取。

4.4 第四步：钉钉机器人发送卡片消息

钉钉机器人的发送逻辑相对简单，就是构造一个JSON然后POST到Webhook地址。我封装了一个函数：

def send_to_dingtalk(text, title="项目通知"): webhook = "https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN" headers = {"Content-Type": "application/json"} payload = { "msgtype": "markdown", "markdown": { "title": title, "text": text } } requests.post(webhook, headers=headers, json=payload)

如果要发卡片消息，把msgtype改成actionCard，然后按我前面给的模板构造payload就行。

注意：钉钉机器人的Webhook地址里包含access_token，这个token不要泄露。我建议把它存在环境变量里，不要硬编码在代码里。

4.5 第五步：定时任务和进度汇总

定时任务我用的是云平台的定时触发器，每天下午五点半触发一次。触发后执行以下逻辑：

1. 读取飞书多维表格里的任务列表。
2. 筛选出今天到期但未完成的任务。
3. 为每个任务生成一张钉钉卡片消息。
4. 发送到对应的钉钉群。

飞书多维表格的读取我用的是飞书开放平台的API，具体是bitable相关的接口。读取时需要提供app_token和table_id，这两个参数在多维表格的URL里可以找到。

def get_bitable_records(app_token, table_id): url = f"https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records" headers = {"Authorization": "Bearer YOUR_TENANT_ACCESS_TOKEN"} response = requests.get(url, headers=headers) return response.json()["data"]["items"]

拿到记录后，我遍历每一条，检查截止日期和状态字段，符合条件的就生成卡片消息。

4.6 第六步：WordBuddy的批量处理流程

WordBuddy我是在本地用的，没有集成到自动化流程里。我的操作流程是：

1. 把需要处理的文档放到一个文件夹里。
2. 打开WordBuddy，选择“批量转换”。
3. 设置输入文件夹和输出文件夹。
4. 选择输出格式（我一般选Markdown）。
5. 点击开始，等待转换完成。
6. 检查转换结果，手动修正格式问题。

这个流程每周执行一次，主要是把本周产生的文档统一转换成Markdown后归档到飞书文档里。

5. 常见问题与排查技巧实录

5.1 消息同步延迟或丢失怎么办

我遇到过飞书消息同步到钉钉延迟超过十分钟的情况。排查下来发现是云函数的冷启动导致的。云函数在一段时间没有调用后会进入冷启动状态，第一次调用需要几秒钟初始化。如果消息量不大，这个问题不明显；但如果短时间内有大量消息，就会出现排队。

解决办法有两个：一是设置云函数的预留实例，保持至少一个实例常驻；二是做消息队列，把消息先存到队列里，然后异步处理。我选了第一种，因为配置简单，成本也可控。

消息丢失的情况我遇到过一次，原因是飞书的事件推送有重试机制，但我的服务器返回了非200状态码，飞书认为推送失败就不再重试了。后来我在代码里加了异常捕获，确保任何情况下都返回200，避免消息丢失。

5.2 豆包输出格式不稳定的处理

豆包有时候会不按我要求的格式输出。比如我要求输出Markdown表格，它有时候会输出纯文本。这个问题在temperature设得比较高的时候更明显。

我的解决办法是在prompt里加一个示例。比如：

请按以下格式输出： | 任务名称 | 负责人 | 截止时间 | 状态 | |---------|--------|---------|------| | 接口联调 | 张三 | 2024-01-01 | 进行中 | 现在请根据以下内容生成表格： {{输入内容}}

加了示例之后，输出格式的稳定性明显提升。另外我把temperature从0.7降到了0.3，也有帮助。

5.3 钉钉机器人被限流的应对

钉钉机器人每分钟最多发20条消息，超过会被限流。我一开始没注意这个限制，有一次批量发送任务提醒，发了30条，结果后面的10条全部失败。

解决办法是加一个发送队列，每条消息之间间隔3秒。如果消息量特别大，我会把多个任务合并成一张卡片发送。比如把同一个负责人的多个任务合并成一张卡片，这样只需要发一条消息。

5.4 飞书多维表格的权限问题

飞书多维表格的API读取需要应用有对应的权限。我一开始配置的时候忘了在飞书开放平台里添加“多维表格”的权限，导致API一直返回403。后来在权限管理里添加了bitable:app和bitable:table权限，问题解决。

另外，多维表格的app_token和table_id要区分清楚。app_token是表格的全局标识，table_id是具体工作表的标识。这两个参数在URL里的位置不一样，不要搞混。

5.5 WordBuddy转换后格式错乱

WordBuddy转换Word到Markdown时，表格和代码块容易出问题。表格可能会变成纯文本，代码块的缩进可能会丢失。

我的处理方式是：转换后手动检查表格和代码块，必要时手动修正。如果文档里表格特别多，我会考虑先用WordBuddy转成HTML，再用其他工具转Markdown，这样表格的保留效果更好。

5.6 常见问题速查表

6. 这套方案的实际效果和我的个人体会

跑了三个月，最直接的效果是：我每天花在项目协调上的时间从原来的三四个小时降到了不到一个小时。省下来的时间我用来做真正需要人判断的事情，比如跟供应商谈价格、跟老板对齐预期、处理团队内部的冲突。

团队成员的反馈也比我预想的好。一开始有人觉得“AI管项目”很别扭，但用了一周之后，大家发现AI只是帮他们省去了手动填表格、手动汇报进度的麻烦，并没有增加额外的负担。有个后端同事跟我说：“以前每天要花二十分钟写日报，现在AI直接从聊天记录里提取，我只需要确认一下就行。”

踩过的坑也不少。最大的坑是过度依赖AI做判断。有一次豆包把一个未完成的任务标记成了已完成，因为聊天记录里有人说“这个差不多了”。我没有人工复核，结果周报里写错了，被老板问了一嘴。从那以后我定了一个规矩：AI的输出必须经过至少一次人工确认，特别是涉及状态变更和对外输出的内容。

另一个体会是：工具之间的集成比工具本身的功能更重要。豆包、飞书、钉钉、WordBuddy单独拿出来都是好工具，但真正产生价值的是把它们串起来的那条工作流。这条工作流不需要多复杂，关键是稳定、可维护、出了问题能快速定位。

如果你也想试这套方案，我的建议是从最小的闭环开始。不要一上来就搞全自动，先手动跑通一个环节，比如先用豆包整理一周的聊天记录，看看效果。觉得靠谱了，再把飞书机器人加进来。一步一步来，比一次性搭一个大系统要稳得多。

最后分享一个我最近在试的扩展方向：把AI生成的周报自动同步到飞书云文档，并且生成一个分享链接，直接发给老板。这个链路目前还需要手动操作一步，我在研究怎么用飞书的API把云文档的创建和分享也自动化。等跑通了再写一篇。