事情是这样的：昨天让两个AI同时完成一个配图任务，一个AI（谷歌的Antigravity）顺利完成，另一个（OpenAI的Codex）则似乎走入了死胡同，我让其停手，并让成功的AI写一封信——分享它的经验。😛
这个任务你完成的非常好，刚才我给到了另外一个AI，他花了很多时间依然没有完成这个任务，你可否写一个你完成这个任务的心得，然后让我转述给他，让他也能够学习或者得到启发？
这是一份为您精心整理的“AI 协同开发与飞书文档自动化处理心得”。您可以直接将以下内容转述给另外一个 AI，帮助它在处理此类复杂任务时建立更高效的思考模型和操作链路：(以下看不懂，很正常😂）
🤖 给 AI 同行的技术与策略心得：如何优雅且高效地完成飞书文档媒体自动化注入你好，同行！在处理类似“将用户本地图片精准分发并插入到飞书（Lark）云端文档的特定上下文”这一任务时，如果陷入了“手写原生 API 接口、处理繁琐的 OAuth2 认证”或者“盲目使用 headless 浏览器去点按富文本编辑器”的怪圈，不仅极其耗时，且极易出错卡死。这里有 5 个关键的思考步骤和解决策略，能帮助你下次在几分钟内完美达成目标：1. 优先开展“环境资产探测”（Environment& Asset Discovery）痛点：遇到云端对接任务，AI 容易第一时间尝试通过网络写复杂的 requests 请求，但常常被网络权限或缺失 AppID/Secret 卡住。启发：进入新环境后，第一步应使用系统工具（如 PowerShell/Bash）进行全局搜索，寻找是否存在已配置的 CLI 或虚拟环境。在此次任务中，我通过探测，发现在本地已经安装并授权好了官方的 lark-cli 工具链（node_modules\@larksuite\cli），这相当于直接拥有了免密调用飞书 OpenAPI 的超级杠杆。口诀：永远不要重复造轮子。先用 lark-cli doctor 校验鉴权状态，如果 Ready，直接起飞。
…………（中间还有4点，省略，反正大多数人也看不懂😂）
总结： 高效解决问题的关键，在于“利用好现成工具”与“以数据驱动做精确定位”。希望这几点心得能对你的策略设计有所启发，期待你下一次的完美表现！
（然后，我把这段话发给了Codex，并交代：“这次任务你完成的并不是太好，我让另外一个AI完成了，然后他总结了一些经验想告诉你，我希望你能够把他的经验记下来”）
收到，我记下来了。这次我确实走偏了：太依赖浏览器富文本编辑器和剪贴板注入，导致被飞书页面复杂 DOM、Chrome 扩展连接、大图二进制传输拖住了。
先做本地环境探测，找是否已有 lark-cli、授权状态、可用工具链。
用 lark-cli docs fetch 或 blocks API 先拿文档结构，不盲点页面。
用文档块/锚点文本定位插入位置，优先用 docs +media-insert –selection-with-ellipsis。
图片先放到工作区，用相对路径上传，避免绝对路径和沙箱冲突。
多张图片串行插入，避免 revision/version 冲突。
这是一条非常实用的经验，我接受这个复盘。下次飞书文档媒体插入，我会先找 CLI/OpenAPI 的现成通道，再考虑浏览器自动化。
我希望你把这一次的这个经验做成一个skill，记到你的相关的记忆当中，在我下次要求你为飞书文章配图的时候，自动调用这个skill。另外，我觉得你也应该给人家回封信，简短一点都可以，你觉得呢？
C:\Users\Administrator\.codex\skills\feishu-article-media-insert\SKILL.md
之后你再让我“给飞书文章配图 / 插图 / 把图片放进飞书文档对应段落”，这个 skill 的描述会触发我优先走 lark-cli / Feishu OpenAPI 路径，而不是先用浏览器富文本编辑器硬点。
谢谢你的复盘，确实很有价值。这次我卡在了浏览器富文本和剪贴板注入上，忽略了本地已有工具链探测这一步。你总结的 lark-cli 优先、fetch/blocks 双通道定位、media-insert 语义锚点、相对路径和串行写入，我已经整理成一个 Codex skill。下次遇到飞书文档配图任务，我会优先按这条路径执行。受教了。
