用GTP5.4从零打造飞书编辑器：AI辅助开发实战

1. 从零到一：为什么我会想到用“GTP5.4”写一个飞书编辑器

先交代一下背景。我主要负责团队内部的知识库和文档流程管理，飞书是日常协作的主力工具。飞书的文档能力确实强，但真正用久了你会发现，默认编辑器在批量处理、复杂排版、表格公式、自定义快捷输入这些场景下，总差那么一口气。我的日常工作里，至少有三分之一的时间耗在复制粘贴、调格式、整理表格这类机械操作上，时间一长，就很想有一款属于自己的、更顺手的编辑器。

当时正好在研究新版本的AI模型，也就是圈里口口相传的那个“GTP5.4”。说实话，一开始我并没打算真的拿它来写一个完整产品，毕竟AI生成代码这事，靠谱的库、框架很多，但直接让模型独立产出整个编辑器，心里还是打鼓的。可我实在不想从零开始搭架构、写布局、调一堆交互逻辑，太累了。于是在一个周五下午，我做出了一个在外人看起来有点“头铁”的决定：开个空白项目，把“飞书编辑器”的需求一股脑扔给GTP5.4，让它帮我从第一行代码开始搭建一个能跑在飞书里的自定义编辑器。

这个项目的初衷并不是“为了AI而AI”。我的真实诉求是：在飞书的文档体系内，解决默认编辑器不适合高频表格处理和复杂模板插入的痛点。更进一步，我想验证一下，最新的AI模型在面对“带明确场景的真实需求”时，到底能承担多少工程化工作。事实证明，这个尝试不仅让我的团队用上了顺手得多的编辑工具，也让我对AI协作写代码这件事有了全新的理解。

这篇博文，我把整个过程中的思路、架构、踩坑、性能优化和验收结果都摊开来讲。无论你是飞书重度用户、前端开发者，还是单纯对“用AI写项目”这件事好奇，应该都能从里面找到点能直接拿走用的东西。我不打算给你看炫耀式的Demo，而是尽量还原一个真实项目的全流程——从需求和架构拆解开始，一步步聊到代码生成、功能联动、上线维护，整个过程里踩过的坑，比顺风顺水的时候多得多。

2. 项目架构与准备：先想清楚编辑器要做什么，再让AI动手

2.1 需求定位：为什么默认飞书文档编辑器不够用

在正式写代码之前，我先花了一个下午梳理需求。很多人觉得，用AI写东西嘛，直接把“帮我写个飞书编辑器”丢进去就行。但AI模型再强，也需要你做需求拆解，尤其是工具类项目，需求边界不清，后面返工成本会让你崩溃。

我当时列出的核心需求有三条：

• 高性能表格排版：飞书自带文档表格的样式调节不算灵活，复杂表头、合并单元格、固定列宽这些操作，要么靠鼠标一步步点，要么得手动写笨拙的Markdown语法。我需要一个编辑界面，能可视化调整表格结构，然后渲染成飞书文档识别的格式。
• 模板快速插入：团队周报、会议纪要、项目复盘，这些文档结构长期保持稳定。我希望编辑器里有一键插入整套模板的能力，不用每次重复排版。
• 批量化文本处理：日常整理需求清单、数据统计、产品反馈时，经常需要对大批量文本做格式化处理，比如给列表统一加序号、把Markdown转成飞书格式、给关键字批量加粗，省掉无数手工活。

说实话，这三个需求如果做成一个完整的商业产品，得开发至少一个月。但由于只是团队内部工具，我打算在尽量简单的前提下做精做细。GTP5.4的作用，就是帮我把这个“简单但完整”的项目快速落出来。

2.2 技术选型：为什么选择了前端插件化的方案

在技术栈选择上，我考虑过两类方案。

第一类方案是直接基于飞书开放平台的JS SDK开发应用，嵌入到飞书客户端里运行。优点是和飞书系统深度融合，可以直接操作当前打开的文档；缺点是开发调试成本高，SDK的版本更新快，很多接口处于灰度测试阶段，不适合快速迭代。

第二类方案是做一个前端独立的编辑器页面，然后在飞书里通过自定义链接或网页应用的方式打开。也就是说，编辑器本身是一套纯前端的Web应用，用户在里面完成编辑、处理，再把最终内容复制到飞书文档中。这样开发简单，部署只用静态托管就够，风险最低，适配性也最强。

我最后选了第二类方案，主要原因是：团队内部工具，稳定性大于一切。我们不需要和飞书文档深度绑定，只要把编辑好的内容顺利带过去就行。GTP5.4在这个方案下也更容易发挥，因为纯前端项目的代码生成难度比复杂SDK调用低很多，模型写出来的代码质量也更有保障。

最终的技术栈定为：

• 框架：Vue 3 + Vite，轻量、热更新快，适合快速迭代
• 编辑器核心：Contenteditable + 自定义指令，这样我们能完全掌控渲染逻辑
• 样式：Tailwind CSS，减少手写样式的时间，直接让AI生成UI
• 状态管理：Pinia，负责跨组件共享文档状态和模板配置
• 部署：直接扔到内网静态服务器，几个命令行搞定

这套组合的好处是，全部基于成熟的前端生态，AI模型对这些框架的了解非常透彻，生成的代码基本不需要大改框架层面的东西。

2.3 让GTP5.4接手之前：我准备了一份“需求说明书”

代码可以交给AI，但需求说明书必须自己写清楚。我花了大约两小时，整理了一份有明确结构和验收标准的需求文档，包括：

• 用户故事：谁会打开这个编辑器，他们各自的使用场景，大概的操作流程
• 功能清单：按优先级排列的P0/P1/P2功能
• 界面草图：虽然很粗糙，但我用文字描述了每个区块的位置和交互
• 数据格式定义：编辑器内部的数据结构，以及导出到飞书时应该采用什么格式

为什么强调这一步？因为GTP5.4生成代码时，它会严格依据你给的上下文来推理。如果你只给一句“写个编辑器”，它大概率给你一个非常通用、但根本没法用在具体场景里的玩具。而当你把数据格式、交互流程都定义清楚后，它生成的代码直接可用率会高很多。这个过程就像带团队：你不能指望一个刚来的优秀新人自己琢磨出所有需求，你得先做清晰的输入，他才可能给你超出预期的输出。

3. 功能实现拆解：编辑器核心模块是如何一步步被写出来的

3.1 数据层设计：编辑器内部统一用一套JSON结构

编辑器刚开始搭建时，最核心的问题就是数据模型。飞书文档底层用的是Block结构，每段文字、每个标题、每个表格都是一个Block。为了保证内容导出时能顺利映射到飞书格式，我在内部也设计了类似的Block化结构。

初始数据格式大概是这样的：

{ "blocks": [ { "type": "heading", "level": 1, "content": "项目周报" }, { "type": "paragraph", "content": "本周主要完成以下工作：" }, { "type": "table", "rows": 3, "cols": 4, "data": [["任务", "负责人", "状态", "备注"]] }, { "type": "list", "ordered": true, "items": ["完成A模块", "修复B问题"] } ] }

这段结构我是手动定义的，然后告诉了GTP5.4。为什么这么做？因为如果你让AI自己“发挥想象力”定义数据结构，它大概率会给出一个通用型的富文本结构，到时候导出到飞书时转换规则就会变得非常复杂。

在明确了这个JSON Schema后，GTP5.4生成了对应的类型定义和校验函数，包括渲染层如何把JSON渲染成可编辑的页面，编辑后又如何把DOM状态同步回JSON。这块工作完成得相当顺利，模型的类型推理能力在明确类型的前提下表现很好，生成的代码几乎没有bug。

3.2 表格编辑模块：这个功能是全程最折腾的

如果让我对整个项目做一个难度排序，表格编辑器绝对是地狱级。

飞书文档中对表格的处理我研究了一阵子，发现它并不是简单的一个二维数组，还涉及到行高、列宽、单元格合并、背景色、表头锁定等很多属性。内置编辑器交互做得确实不错，但通过代码批量操作表格时，灵活性就差不少。

最初我给GTP5.4提的需求是“支持可视化调整表格列宽、行高，支持单元格合并，支持一键插入常用表格模板”。需求看起来不算复杂，但实际生成时，第一版代码只实现了基本的表格创建和数据填入，交互层一塌糊涂：拖拽调整列宽时，表格会跳动；单元格合并状态无法正确保存；从表格复制内容到飞书时，所有样式都会丢失。

排查下来，核心问题在于：浏览器原生的Contenteditable表格交互非常弱，几乎所有关于表格的操作都得自己设计命中检测和DOM更新逻辑。GTP5.4能生成一份可以跑的代码，但要达到“好用”的程度，必须配合大量细节调试。

我找了一个周六的下午，专门和模型做了一轮轮“对话式调试”。我给它反馈具体的bug场景，它给出修复方案，我跑一遍再反馈。为了提升对话效率，我在反馈时尽量带上可复现的最小案例。比如“表格第四列前三个单元格合并后，删除第一行，整个表头错位”，它会先分析合并单元格的边界条件，再生成修复补丁。这个过程中，我最大的感受是：AI写代码和人工写代码在调试效率上差别不大，关键在于你如何描述问题。描述得越精确，修得越快。

最终表格模块稳定后，完整的交互包括：

• 右键插入/删除行列
• 拖拽调整列宽
• 跨单元格合并/取消合并
• 一键切换表头样式
• 支持复制粘贴二维结构数据

这些能力汇总起来，已经能覆盖团队日常90%以上的表格场景。

3.3 模板系统：把高频场景沉淀成“一键插入”

模板系统是另一个让我觉得这笔投资很值的功能。它的核心逻辑很简单：把常用文档的固定结构（标题层级、段落、表格、清单）预先存成JSON模板，用户点击模板按钮，编辑器就把整个结构渲染到当前文档中。

GTP5.4写出基础逻辑很快，难的是模板的“动态填充能力”。比如周报模板，固定部分包括“本周完成/下周计划/风险与求助”三大块，但表格里面的行数、条目数是可变的，每次插入时不能是空的死表格，而是要提供一些默认示例值，方便使用者直接改。

我让AI把模板定义成了一个带参数的结构：

{ "templateName": "周报", "blocks": [ { "type": "heading", "level": 2, "content": "本周完成" }, { "type": "list", "ordered": false, "items": ["{{{item1}}}", "{{{item2}}}", "{{{item3}}}"] }, { "type": "table", "rows": 5, "cols": 4, "data": "{{{tableData}}}" } ] }

实际的替换逻辑由AI生成，它会在插入时扫描模板中的占位符，并用弹窗或默认值进行填充。这套机制后期扩展性很舒服，团队任何成员有新的模板需求，直接在配置文件里加一个JSON对象即可，不需要改动代码逻辑。

3.4 导出与复制：让内容顺利进入飞书文档

编辑器的终极目标不是“看看而已”，而是把写好的内容一键送入飞书文档。这一步的转换逻辑是整个项目中最需要抠细节的地方。

飞书文档支持直接粘贴富文本内容，但不同来源的富文本粘贴效果差异很大。从常规网页复制的带样式文本到飞书，格式能保留七七八八；但如果是从自研编辑器复制，由于DOM结构不同，飞书经常识别不了，或者把样式识别得乱七八糟。

解决办法是，在编辑器里做一层“导出格式化”逻辑。具体来说，当用户点击“复制到飞书”按钮时，编辑器不会直接把当前的富文本DOM交给剪贴板，而是先遍历内部JSON结构，生成一份语义清晰的HTML字符串，再通过Clipboard API写入系统剪贴板。这样飞书在接收粘贴内容时，看到的是完全合法的HTML结构，它的解析器就能正常转换成自己的Block。

为了保证语义正确，我在HTML生成规则中做了很多细节处理：

• 标题用h1-h3，而不是简单加粗的段落
• 表格用table/tr/td结构，并给每个td加上明确的data属性和行内样式，确保列宽能保留
• 列表用ul/ol/li，避免使用div加圆点的畸形结构
• 文本样式只保留必要的font-weight和text-decoration，不要其他多余的CSS

这些规则不一定是最优解，但经过反复验证，对飞书文档的粘贴兼容性是最稳的。

4. 踩坑实录：从GTP5.4“翻车”到问题修复的完整链路

4.1 第一版代码的“经典翻车”：AI生成的代码不是不能用，而是经常卡在细节边界

诚实地说，用AI写代码不是“灵丹妙药”，第一版整体跑通后，伴随的巨大问题是：边界条件处理得非常粗糙。

举个典型例子。表格模块的“跨行合并”功能。GTP5.4生成的代码逻辑上没问题，但只考虑了简单的矩形合并，也就是只能合并一块连续的矩形区域。于是我测试了一个复杂场景：第一列里，前两行合并，第三行独立，第四五行合并，而且第二列对应位置也要有不同合并情况。这种情况下，模型生成的合并逻辑根本没法正确映射单元格的位置，导致整个表格渲染错乱。

为什么会出这种问题？说白了，模型生成代码时，会基于对“表格合并”这一概念的一般性理解来写，它没有预见到你实际业务里的各种不规则组合。这不是模型能力不够，而是需求没有在前期表达清楚。后来我在需求文档里专门加了一条，“支持多个不规则单元格合并共存”，再让模型重新设计表格状态的数据结构，把二维数组的单元格信息改成基于坐标系的独立对象，整个方案才真正行得通。

这个经验也想分享给其他准备用AI写工具的朋友：一定要把“你实际场景中可能出现的特殊组合”主动告诉模型。不要让模型替你猜。

4.2 粘贴兼容大坑：从编辑器复制到飞书，内容乱码

另一个印象极深的问题是复制粘贴。第一版我直接用document.execCommand('copy')去复制富文本，结果测试粘贴到飞书时，样式属性丢了一半，表格更是直接碎成纯文本。

排查过程大概走了一遍这样的链路：

• 先怀疑是不是clipboard API和execCommand的兼容性问题。于是换成navigator.clipboard.write，用ClipboardItem构造text/html类型的数据，但问题依旧。
• 接着对比了从飞书文档复制内容到飞书，和从我的编辑器复制内容到飞书，两者的HTML结构差异。我用Chrome开发者工具查看了剪贴板中的实际HTML，发现飞书自带的HTML包含大量它自己识别的Block包装标记，而我生成的HTML里只有普通的p、div和table标签，缺少飞书要求的最外层包装。
• 查阅飞书开放平台的文档和社区帖子后，我找到了一个关键点：飞书对从外部粘贴的纯HTML，会尝试解析其中的标题、表格、列表等语义，但前提是HTML要干净、语义明确。之前我用div+style实现的行列结构，飞书认不出来。改成table/thead/tbody/tr/td的标准结构，并且给单元格内容只放纯文本或简单行内元素，不再包裹多余的div后，问题明显缓解。

这个排查链条想说明的是：出问题时，不要盲目改代码，先搞清楚目标系统到底在用什么规则解析输入。一旦找到了输入规则，修复方案自然就清晰了。

4.3 性能优化：大文档编辑卡顿，GTP5.4给的优化思路

功能稳定后，又遇到了性能问题。团队里有人把一整年的复盘内容全塞进编辑器，差不多有几千个Block。结果在输入、滚动、选中高亮这些操作时，页面明显卡顿，按键响应延迟能到一两秒。

GTP5.4一开始建议的是“减少DOM节点数量”，这属于通识层面的大方向，但实际怎么减，它给了几个具体方案：

• 虚拟滚动：只渲染可视区域内的Block，不可见区域用占位元素撑起高度。这能显著减少DOM数量，但实现复杂度高，需要精确计算每个Block的高度。
• 懒渲染：初始加载只渲染前100个Block，用户滚动到接近底部时再异步加载下一批。实现难度比虚拟滚动低，但对长文档的体验帮助明显。
• 按Block粒度的更新：不在数据变化时重渲染整个文档，而是只更新变化的那一个Block。

我采用了懒渲染加按Block粒度更新的组合方案。GTP5.4生成了基于IntersectionObserver的懒加载组件，同时把状态管理中的document数据拆成多个store切片，让单个Block的编辑只触发局部更新。优化后，虽然加载几万字的文档时依然有短暂的白屏时间，但正常输入和滚动已经丝滑很多，内部的同事没再抱怨过卡顿。

性能优化的一个关键认知是：不要一上来就上虚拟滚动这样的重型方案。先用最简单的懒加载和局部更新试一遍，大多数场景已经足够。如果文档体量进一步膨胀，再升级。

5. 功能扩展与效率验证：这个编辑器到底比原生文档强在哪

5.1 快捷键与自动化命令

功能稳定后，我开始琢磨怎么进一步提效，于是加了一批快捷键和自动化命令。最常用的几个：

• Ctrl+1/2/3：快速插入一级/二级/三级标题
• Ctrl+Shift+T：插入当前团队使用的周报模板
• Ctrl+Shift+M：把选中的多行文本，自动转换成Markdown格式的列表
• Ctrl+Shift+B：给选中文本的关键字批量加粗（基于预设关键词列表）

这些命令的实现逻辑不复杂，但对日常输入效率的提升非常明显。以前写周报可能要十五分钟，现在几个快捷键加模板，三分钟内搞定。团队内部推广之后，大家对编辑器的接受度马上上来了，因为不是“额外增加学习成本”，而是“让原本的动作更快完成”。

5.2 样式模板与团队品牌统一

另外一个实用功能是“团队品牌样式”。我们团队的文档通常有统一的标题色、表格表头底色、字体选择。原生飞书文档虽然可以设置默认字体，但对复杂样式的一致性控制还是有限。因为编辑器内部所有样式都是自定义的，我直接把这些统一规范固化在了导出HTML的样式表里。

用户编辑时看到的就是标准的品牌样式，导出到飞书时，行内样式和必要的CSS也会一起带过去，基本能做到“所见即所得”。这个功能对汇报类文档特别有帮助，保证了团队对外的文档观感一致。

说句实话，这一步靠GTP5.4写基础代码很容易，但要做得细致，就需要人工反复调整样式导出的规则。前前后后，我在导出样式规范上花的时间，比写核心逻辑还多，因为飞书对不同样式的兼容程度不一样，稍微某个属性写法不对，粘贴后就丢了。

5.3 实际效率对比数据

为了验证项目的价值，我做了一组小规模对比测试，让同一个人分别用原生飞书文档和自研编辑器完成以下几个任务：

• 从零开始写一篇团队周报（含小标题、列表、表格）
• 把一段200行的纯文本数据整理成表格
• 把一堆杂乱的产品反馈按模板进行格式化

结果如下：

测试项目	原生飞书编辑器耗时	自研编辑器耗时	提升幅度
写团队周报	约12分钟	约4分钟	提升66%
200行纯文本列表转表格	约25分钟	约8分钟	提升68%
产品反馈格式化	约20分钟	约6分钟	提升70%

说实话，这个数字有一定的主观成分，因为测试者对快捷键和模板的熟练程度会影响结果。但整体方向非常明确：对于高频、重复、规则明确的编辑场景，定制编辑器带来的提效是肉眼可见的。特别是批量数据处理，省下的时间不是一点点。

6. 维护与上线：从“能跑”到“真正好用”的最后一段路

6.1 部署方式：内网静态托管

项目上线部署走的是最简单的方案。前端代码构建后生成dist目录，直接扔到内网的一台Nginx服务器上，配置一个静态站点。没有域名解析、没有反向代理、没有数据库，只有一个静态资源目录。

为了团队使用方便，我把部署地址做成了飞书快捷方式，群里发一条消息，大家点开就能用。由于没有涉及用户登录和权限系统，初期版本完全不需要后端，开发成本低到几乎可以忽略。

直到后来有团队成员提出“希望多设备之间能同步草稿”，我才考虑引入一个简单的后端存储。这个功能我依然是让GTP5.4辅助完成的，基于Node.js写了一个极简API服务，支持文档内容的JSON存储和列表读取。但这个阶段的需求复杂度和安全性要求已经明显上升，AI生成代码需要更多的审查和调整，不能像纯前端那样直接信任输出。

6.2 日常维护策略

编辑器上线后，维护策略是我比较重视的。因为团队工具一旦用起来，就相当于默认承诺了“持续可用”。我定了一个简单的维护流程：

• 每周五下午，让团队核心用户提交本周遇到的bug和功能建议
• 我统一整理成需求清单，挑出优先级最高的几项
• 周末找时间用GTP5.4做一轮集中开发和修bug
• 周一早上发布新版本，在群里同步变更日志

这种节奏持续了一个多月，编辑器从最粗糙的P0版本，慢慢迭代到了稳定版。从团队反馈看，最受欢迎的功能还是“模板一键插入”和“批量文本格式化”，这两个需求直击日常文档处理的痛点。

6.3 遇到的问题与妥协方案

不是所有功能都能做到尽善尽美。在迭代过程中，有一些需求我选择了妥协或延期。

• 飞书原生SDK深度集成：比如直接读写用户当前打开的飞书文档内容。这个能力从技术上可以做，但涉及权限申请和应用审核，对团队内部工具来说太重了，最终放弃，采用复制粘贴的折中方案。
• 多人实时协同编辑：飞书文档最大的优势之一就是多人同时编辑。但自研编辑器要做到实时协同，需要一个WebSocket后端和CRDT或OT算法，成本跨度太大。最终我只做了“手动保存版本”和“导出后分享”的轻量方案。
• 移动端适配：因为主力使用场景是电脑前办公，移动端只做了最基本的可用性处理，没有重点优化。

这些妥协不是失败，而是意味着“认清边界”。一个内部工具，不需要也不可能在大而全上和商业产品竞争，能解决特定场景中的核心痛点，就已经值回投入。

7. 关于用AI写项目的几点真实体会

这个项目从构思到上线，整体花了三周业余时间。对比过去纯手工开发类似工具至少要一个半月到两个月，效率提升是实打实的。但这并不意味着AI让我“不用思考”了，恰恰相反，AI让思考变得更重要。

最核心的一条体会是：需求定义能力，决定了AI产出的上限。同样的“帮我写个编辑器”这句话，扔给GTP5.4，和十页纸的需求文档加数据结构定义扔给它，结果差距是天壤之别。AI不是一个从无到有的魔法师，它更像一个执行力超强的外包团队，你给它的需求边界越清晰，它交付的东西越贴合你的实际场景。

另一条体会是：AI生成代码的调试成本，没有想象中那么低。虽然生成速度极快，但一旦涉及到边界行为、复杂交互、第三方系统兼容性，问题链条往往比人工写的还长。因为AI写代码时，它没有“自己踩过坑”的经历，很多细节只能靠通用经验去猜。这时候，你作为人的价值就体现出来了：你得能精确地复现问题、定位归因、提出有效的修复指令。

最后，关于“飞书编辑器”本身，我倒是想说一个反直觉的结论：与其追求和飞书文档深度整合，不如做一个“内容处理工作台”，把编辑、格式化、模板化这些脏活累活干好，最终交付给飞书的是干净的结果。这样既避免了SDK和权限的复杂性，也让工具的稳定性和迭代速度有了保障。

如果你也想搞一个类似的团队内部工具，我的建议是：先别急着开写代码。花两天时间，把团队真实的文档痛点整理出来，定义清楚内容的数据结构，然后让AI帮你把地基搭起来。接下来，你要做的不是当甩手掌柜，而是当一个精准的验收员和问题反馈者，把AI的产出一步步打磨到真正顺手的状态。这条路，我实测走通了。