1. 一个没有开发资源的项目群是怎么被聊出来的去年下半年我接手了一个跨部门的项目涉及产品、设计、运营、市场四个方向前后拉了三个群一个全员大群、一个核心推进群、一个临时问题群。按常规做法这种规模的项目要么走内部工单系统排期要么找开发同学帮忙搭个看板工具。但我当时手里既没有开发排期也走不了正式流程——说白了就是没人、没预算、没系统。我最后用的办法是把 AI 当成一个能听懂人话的项目助理用聊天的方式把整个项目群管了起来。核心工具组合是豆包负责理解需求、生成结构化内容、写脚本飞书负责承载多维表格、机器人消息、云文档钉钉负责打卡提醒和群通知中间用WordBuddy做文档格式转换和 Obsidian 知识库同步。整个过程没有写一行后端代码没有申请任何服务器也没有走 IT 审批。这套方法适合谁适合那些手里有项目但没技术资源的人——产品经理、运营负责人、小团队 leader、创业公司里身兼数职的万能选手。你不需要会编程但需要愿意花两三个小时把 AI 的聊天能力调教成执行能力。下面我把整个搭建过程、踩过的坑、以及实际跑起来之后的真实体验完整拆一遍。2. 为什么我放弃了传统项目管理工具转而用 AI 聊天来管2.1 传统工具的重和 AI 聊天的轻我先说清楚为什么不用现成的项目管理工具。市面上的看板、甘特图、任务系统我试过一圈问题不在功能而在启动成本。一个跨部门项目你要让四个方向的人同时注册、学习、养成更新习惯这件事本身就比项目本身还难。我统计过上一个项目的数据拉了 12 个人进看板两周后还在更新的只剩 3 个其余人的任务状态全靠我在群里着问。AI 聊天管项目的逻辑完全不同。它不要求所有人改变习惯——大家还是在飞书群里说话、在钉钉里打卡、在云文档里写东西AI 在中间做翻译和搬运。比如运营在群里说这版物料周五之前给不了要下周一我不需要手动去改看板只需要把这句话丢给豆包让它输出一条结构化的状态更新再通过飞书机器人发到多维表格里。人还是用最自然的方式沟通结构化的事情交给 AI。2.2 豆包在这个链路里到底扮演什么角色很多人把豆包当成一个问答工具问一句答一句。但在项目管理场景里我把它当成三个角色叠加需求翻译器把群里零散、口语化的消息翻译成任务名 负责人 截止时间 依赖项的结构化字段。脚本生成器我需要飞书机器人定时发提醒、需要把多维表格的数据导出成周报这些脚本都是让豆包直接写的我复制粘贴就能跑。异常检测器每天把群里的关键消息喂给它让它标出哪些任务卡住了、哪些人超过 48 小时没更新。这里有个关键细节豆包的请求格式是input而不是message这个差异在对接飞书开放平台的时候会直接影响你传参的方式。我一开始按常规聊天接口的message字段去拼结果一直报参数错误后来翻文档才发现要用input。这个坑后面会详细讲。2.3 飞书和钉钉的分工一个管事一个管人我一开始想全部用飞书搞定但实际跑下来发现钉钉在打卡提醒和群通知触达上更直接。最后的方案是平台承担职责具体用法飞书项目数据中枢多维表格存任务、云文档存周报、机器人发结构化消息钉钉人员触达通道打卡提醒、紧急通知、离线安装包分发豆包内容生成与转换需求翻译、脚本生成、异常检测WordBuddy文档格式处理周报格式转换、Obsidian 知识库同步这个分工不是拍脑袋定的而是根据每个工具最不容易被用户抗拒的场景来分配的。飞书多维表格适合沉淀数据但让人天天打开飞书看表格不现实钉钉的群消息触达率高但让它存结构化数据很别扭。让工具做它最擅长的事人才不会反感。3. 从零搭起这套聊天式项目管理的完整操作链路3.1 第一步把项目群的消息变成结构化任务这是整个链路的地基。我的做法是在飞书群里开一个项目同步专用话题所有和任务相关的消息都往这里发。然后我写了一个简单的处理流程每天固定时间我选的是下午 6 点把当天该话题下的消息导出。把消息内容丢给豆包用一段固定的提示词让它输出结构化结果。把结果通过飞书机器人写入多维表格。提示词我是这样写的可以直接抄你是一个项目助理。下面是一段项目群聊天记录请提取出所有任务相关的信息 按以下格式输出 JSON 数组 [{task: 任务名, owner: 负责人, deadline: 截止时间, status: 状态, blocker: 阻塞项}] 如果某条消息没有明确负责人或截止时间对应字段填待确认。 聊天记录如下 {这里粘贴消息}实测下来豆包对中文口语的识别准确率相当高。像这个物料周五之前给不了要下周一这种话它能正确提取出task: 物料交付、deadline: 下周一、status: 延期。但有个前提群里说话要尽量带上谁、做什么、什么时候这三个要素否则 AI 也猜不出来。我在群里定了个不成文的规矩任务消息尽量用某人 动作 时间的格式这样 AI 的提取准确率能从 70% 提到 90% 以上。3.2 第二步用飞书多维表格做数据底座多维表格是这套方案的核心存储。我建了四张表任务表存所有任务字段包括任务名、负责人、截止时间、状态、阻塞项、最后更新时间。人员表存项目成员字段包括姓名、方向、飞书 ID、钉钉 ID。周报表存每周自动生成的周报内容。问题表存需要升级处理的问题。这里有个飞书多维表格的实用技巧上下合并单元格。我在做周报视图的时候需要把同一个负责人的多条任务合并显示直接用了多维表格的合并单元格功能比手动排版快得多。另外多维表格支持通过 API 写入这就是为什么我要让豆包生成脚本——它写的 Python 脚本可以直接调用飞书开放平台的接口把数据批量写进去。关于飞书开放平台我踩过一个坑异常报错信息非常简略。有一次机器人一直发不出消息报错只显示权限不足我排查了两个小时才发现是应用没有开通多维表格读写权限。所以你在飞书开放平台配置应用的时候一定要把下面这些权限一次性勾全多维表格读写云文档读写机器人消息发送通讯录读取用户 ID3.3 第三步让豆包写脚本而不是自己写我不是开发但豆包能帮我写脚本。整个链路里我用到了三个脚本全部是豆包生成的脚本一每日任务提取与写入import requests import json # 调用豆包接口做结构化提取 def extract_tasks(chat_text): prompt f提取任务信息输出JSON数组{chat_text} # 这里用豆包的 input 字段不是 message payload {input: prompt} resp requests.post(DOUBAO_API, jsonpayload, headersHEADERS) return json.loads(resp.json()[output]) # 写入飞书多维表格 def write_to_bitable(tasks): for task in tasks: requests.post(BITABLE_API, json{fields: task}, headersFEISHU_HEADERS)注意上面那个input字段——这就是我前面说的坑。豆包的请求格式和很多聊天接口不一样它用的是input而不是message。如果你按常规接口去拼参数会一直报错。脚本二每日提醒推送# 找出超过48小时没更新的任务通过钉钉群机器人推送 def send_reminder(stale_tasks): text 以下任务超过48小时未更新\n \n.join([t[task] for t in stale_tasks]) requests.post(DINGTALK_WEBHOOK, json{msgtype: text, text: {content: text}})脚本三周报自动生成# 从多维表格拉数据让豆包生成周报再用 WordBuddy 转格式 def generate_weekly_report(): tasks fetch_all_tasks() report doubao_generate(f根据以下任务数据生成周报{tasks}) wordbuddy_convert(report, output_formatdocx)这三个脚本加起来不到 200 行豆包生成后我只改了几个 API 地址和密钥。关键心得不要试图让 AI 一次生成完美脚本而是先让它生成能跑的版本再根据报错逐步调整。我第一个版本跑了 5 次才成功但每次报错都让豆包看它改得比我快。3.4 第四步WordBuddy 在文档流转里的位置WordBuddy 在这套链路里负责两件事一是把豆包生成的周报从 Markdown 转成 docx 格式方便发给不习惯看纯文本的领导二是把项目文档同步到我的 Obsidian 知识库方便我后续复盘。WordBuddy 和 Obsidian 的配合是我自己摸索出来的。具体做法是WordBuddy 把飞书云文档的内容导出为 Markdown然后我设置 Obsidian 的仓库指向那个导出目录这样每次导出后 Obsidian 会自动索引。这个流程对于需要长期积累项目文档的人来说很实用——项目结束后所有文档已经自动整理进知识库了不需要再手动归档。4. 跑起来之后才发现的坑从能用到好用的排查记录4.1 飞书机器人发不出消息权限和网络的双重排查第一个坑出现在机器人配置阶段。我按文档配好了 Webhook但消息一直发不出去。排查过程是这样的先查权限飞书开放平台里机器人应用需要单独开通发送消息权限而且要在应用的权限管理里勾选不是默认开的。再查网络有一次我在本地能跑通部署到公司内网就不行最后发现是内网对飞书开放平台域名做了限制。解决办法是让脚本走公司允许的出口。最后查参数飞书机器人消息的receive_id_type参数必须和实际 ID 类型匹配我一开始传了open_id但实际用的是user_id导致消息发给了错误的对象。提示飞书开放平台的报错信息通常只给一个错误码不会告诉你具体哪里错了。建议在脚本里把完整的请求和响应都打日志排查效率会高很多。4.2 飞书为什么这么吃 C 盘以及怎么清理跑了一个月后我发现 C 盘空间告急。查了一下飞书的缓存文件确实占地方——聊天记录、云文档缓存、多维表格的本地副本加起来能到几个 G。清理方法是Windows 下飞书缓存路径一般在C:\Users\你的用户名\AppData\Roaming\Lark或者Feishu目录下。可以定期清理cache和temp子目录但不要删config否则要重新登录。如果空间实在紧张可以在飞书设置里把自动下载文件关掉改成手动下载。钉钉的缓存路径类似在C:\Users\你的用户名\AppData\Roaming\DingTalk下。我现在的习惯是每个月清理一次这两个目录能释放不少空间。4.3 豆包清理电脑指令的意外用法这个算是个意外发现。我本来是用豆包做项目管理的后来发现它生成的清理电脑指令特别好用。比如我让它写一段清理临时文件的命令它会给出# Windows 下清理临时文件 del /q/f/s %TEMP%\*但要注意这类指令不要直接无脑执行尤其是涉及系统目录的。我的做法是让豆包生成后先看一遍它删的是什么确认没有重要文件再跑。有一次它生成的指令里包含了清理Downloads目录幸好我检查了不然刚下载的项目资料就没了。4.4 多 AI 协作时的上下文丢失问题我后来尝试用多个 AI 协作——豆包负责中文理解另一个 AI 负责代码生成。结果发现一个共性问题上下文在不同 AI 之间传递时会丢失。比如豆包理解了项目背景但换到另一个 AI 写脚本时它不知道项目背景生成的脚本就不贴合实际。解决办法是把项目背景写成一段固定的系统提示每次调用新 AI 时都带上。我现在的做法是维护一个project_context.md文件里面写清楚项目目标、成员、工具链、命名规范每次让 AI 干活时先把这段贴进去。这样即使换 AI输出质量也不会掉太多。5. 这套方案跑稳之后我实际省下了什么5.1 时间账每天省下 40 分钟的状态同步以前我每天要花至少 40 分钟在群里人问进度、手动更新表格、整理周报。现在这套流程跑起来后这些事基本自动化了。我每天只需要做两件事一是下午 6 点把群消息导出丢给豆包5 分钟二是看一眼自动生成的异常报告5 分钟。一周下来省下的时间大概在 3 到 4 个小时对于我这种同时管三个项目的人来说这个数字很可观。5.2 沟通账群里吵架少了这个是我没预料到的收益。以前项目群里经常因为我以为你做了你没说清楚这类问题扯皮。现在因为所有任务都被 AI 结构化记录在多维表格里谁负责什么、什么时候截止一目了然。有争议的时候直接看表格不用翻聊天记录。这个改变让群里的无效沟通至少少了一半。5.3 知识账项目结束后自动沉淀因为 WordBuddy 会把所有文档同步到 Obsidian项目结束后我直接就有了一个完整的知识库。下次做类似项目时我可以直接搜索之前的方案、踩过的坑、用过的脚本。这个价值是长期的比省下的那点时间更重要。6. 如果你也想试这几件事建议先想清楚第一不要指望 AI 完全替代人。这套方案里 AI 做的是翻译和搬运决策和判断还是得人来。我见过有人想让 AI 自动分配任务、自动催进度结果 AI 把任务分给了已经离职的人闹了笑话。第二群里的沟通习惯要稍微调整。不需要很正式但尽量带上谁、做什么、什么时候。这个习惯养成后不仅 AI 好用人看着也清楚。第三脚本要留好日志。AI 生成的脚本能跑但出问题时如果没有日志排查会很痛苦。我现在的习惯是每个脚本都加一行print把关键参数打出来出问题直接看输出。第四工具选型不要贪多。我一开始想同时用飞书、钉钉、企业微信后来发现维护三套机器人太累最后砍到飞书 钉钉两套。工具是为人服务的不是人为工具服务。最后分享一个我最近在用的技巧把豆包的skill功能用起来。豆包支持自定义 skill我把常用的几个提示词任务提取、周报生成、异常检测都存成了 skill用的时候直接调用不用每次重新写提示词。这个功能对于需要重复做同类任务的人来说能再省不少事。