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要干净、语义明确。之前我用divstyle实现的行列结构飞书认不出来。改成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 快捷键与自动化命令功能稳定后我开始琢磨怎么进一步提效于是加了一批快捷键和自动化命令。最常用的几个Ctrl1/2/3快速插入一级/二级/三级标题CtrlShiftT插入当前团队使用的周报模板CtrlShiftM把选中的多行文本自动转换成Markdown格式的列表CtrlShiftB给选中文本的关键字批量加粗基于预设关键词列表这些命令的实现逻辑不复杂但对日常输入效率的提升非常明显。以前写周报可能要十五分钟现在几个快捷键加模板三分钟内搞定。团队内部推广之后大家对编辑器的接受度马上上来了因为不是“额外增加学习成本”而是“让原本的动作更快完成”。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的产出一步步打磨到真正顺手的状态。这条路我实测走通了。