产品经理如何将Cursor的MD文档转化成可阅读的飞书文档

如果你也在 Cursor 里写公众号文章、竞品分析、PRD，那你大概率踩过这个坑：内容写完了，还要手动导飞书；导完了，还得再调格式；文档一多，目录和版本又乱。

这次我和 AI 做了一件很“产品经理”的事：把“手工导入”变成“固定三问 + 一键同步 + 在线文档化”的流程。

一、目标先说清楚

本次共建目标只有一个：

把 Cursor 产出的 .md，稳定同步到指定飞书文件夹，并支持直接转成飞书在线文档（docx）。

并且流程要可复用：

支持多 AppID
支持多 folder token
支持名称化选择，不靠记忆长串 token

二、完整提示词时间线（逐条原文）

说明：以下为本次主题相关沟通中的完整提示词时间线，按先后顺序整理。

提示词 1（凡是不知道的，就先问）

“我现在会经常让你帮忙输出公众号文章和竞品分析文档，但每次我都要手动导一遍到飞书，我想知道怎么样能够把你输出的 MD 文件？直接连接到我的飞书的某个文件夹，输出之后我只要触发一个同步的一个命令，就可以直接帮我同步到对应文件夹，我可能是不是应该要授权我的飞书？权限，还有对应的一个文件夹权限。嗯，帮我看看这个问题怎么解决，给我具体的操作步骤”

提示词 2（看懂了，但是觉得很麻烦）

“那我现在是不是先去飞书开放平台创建自建应用？”

提示词 3（找下前人们的东西让他自己判断下，不要傻乎乎跟着他的思维）

“我查到有直接安装飞书CLI的GitHub库https://github.com/larksuite/cli ，你看看，是不是达到我们要求的效果？”

提示词 4（我怎么可能会做，当然是你自己做了）

“你现在就这样落地（最短路径）安装 CLI npm install -g @larksuite/cli 初始化与登录 lark-cli config init lark-cli auth login --recommend 确认权限 lark-cli auth status 先手工验证一篇 md 能上传到目标文件夹再做一条统一命令例如：npm run sync:feishu（内部调用你的同步脚本）如果过程中碰到什么问题，及时反馈给我获取支援，比如需要我去自建应用什么的”

提示词 5（他自己运行后给出对应创建应用或者授权的链接，直接点开操作即可）

“我没有在我个人的XXXX的企业飞书里看到你创建的CLI？”

但是我反正一直找不到，实在不行，我自己打开飞书开发者平台自己手动创建了一个，反正都能用。

“算了，我看不到，我自己手动建立了一个cli_aXXXXZXZXXX，你看下这个应用是不是可以？”

提示词 6（按他给的指令进行运行）

“read -s FEISHU_APP_SECRET printf "%s" "$FEISHU_APP_SECRET" | lark-cli config init --app-id cli_a9737b682739dcd1 --app-secret-stdin --brand feishu”

提示词 7（还是自己去平台拿，命令什么的对我来讲还是很难，反正我知道他要什么就行了）

“App Secret的获取方式"

提示词 8( 按照他的逻辑，让他自己去运行就行)

“已授权4”

提示词 9（说明很多npm的运行命令的东西，我也看不懂，直接举个例子，看看要怎么做吧）

“给我举个例子，比如，我现在就需要把这篇文章@skills/公众号文章技能包/TT-gzh-jn/产品经理如何将墨刀需求文件转化成知识库.md 同步到我飞书云文档的这个TT-gzh-jn文件夹下。”

提示词 10（folder_token不知道是啥，不懂就问）

“TT-gzh-jn 文件夹的 folder_token？是指文件夹链接里这个最后的拼接内容吗？”

对的，就是这个，你们后面不用了，哈哈

提示词 11（好了，链接完成，测试）

“lark-cli markdown +create --as user --file "skills/公众号文章技能包/TT-gzh-jn/产品经理如何将墨刀需求文件转化成知识库.md" --folder-token "IoKWf5RQmlfhHtdFxMVcm3pFnkc"”

提示词 12（技能沉淀）

“我看到已经同步成功了，现在我希望我们可以简化一下同步方式，你帮我直接创建一个文档同步飞书的技能，然后会需要维护我的多个飞书文件夹的older token，甚至多个应用APPID；做到后面我就拖入对应的文档路径，你就问我3个问题，1、你想同步那份文档？2、你想同步到那个APPID应用？想同步哪个飞书文件夹的folder token？最好给出我对应的名称选项，方便我一眼就看懂。后面我可以把我所有的应用ID和文件夹token都发给你。”

提示词 13（文章输出）

“好了，现在我需要把我们整体从cursor同步md文档到飞书文件夹的沟通过程写成公众号文章，你调取这个@XXXXSKILL.md 提取我们本次沟通的所有的我的完整提示词信息，和你接收提示词的优化点等帮我输出一篇“产品经理如何将cursor的md文档转化成可阅读的飞书文档”的文章，可以参考之前的文章包。”

三、我为什么说这次是“产品化升级”，不是“命令演示”

这次最关键的不是某条命令，而是 4 次能力升级：

从可用到可验证先跑 config / login / status，再手工上传验收，不靠想象。
从一次性到可复用落地脚本 + npm run sync:feishu，不再每次复制长命令。
从文件上传到在线文档把 .md 同步升级为 .md -> 在线 docx，直接可读可协作。
从参数散落到配置中心维护多 AppID、多 folder token 的名称映射，并固定“三问流程”。

四、现在的标准动作（可直接抄）

1）单文件转在线文档

lark-cli drive +import \
  --as user \
  --file "你的文件路径.md" \
  --type docx \
  --name "文档标题" \
  --folder-token "你的folder_token"

2）目录批量转在线文档

npm run sync:feishu:doc

3）每次执行前固定三问

你要同步哪份文档（或目录）？
你要用哪个 AppID？
你要同步到哪个飞书文件夹？

五、这次踩坑清单（你可以直接避开）

审批中应用无法授权，报 pending approval
管理后台和开放平台视图不同，容易“看不到应用”
已登录不等于有写权限，必须看 auth status 的 scope
bash 版本差异会导致脚本兼容问题（如 mapfile）
Secret 不要在聊天里明文传，建议本机 read -s 输入

六、给产品经理的 5 条经验建议

提示词尽量写成“目标 + 验收 + 顺序”
先把单文件跑通，再谈批量和产品化
token 一定要名称化管理，不然迟早混
每个失败都沉淀为流程规则
把“重复动作”做成能力，才有复利