【More than Coding】用 SOLO + 飞书 CLI 打造智能活动策展助手

SOLO挑战赛专区
1

【More than Coding】用 SOLO + 飞书 CLI 打造智能活动策展助手，从一堆活动清单中一键筛选推荐并创建飞书文档和日程

1. 摘要

我使用 TRAE SOLO 从零创建了一个名为「Event Curator」的智能活动策展技能（Skill）。它基于飞书官方开源的 lark-cli 命令行工具，能够从用户提供的活动清单（文本、CSV、网页链接等）中，基于用户画像智能筛选出值得关注的优质活动，自动整理为飞书云文档，并为确认参加的活动一键创建飞书日程。整个过程从需求梳理到技能编写、测试验证、问题排查、GitHub 发布，全部由 SOLO 辅助完成。

2. 背景

我是一名开发者，日常工作中经常接触到大量的技术活动信息——来自公众号推送、社群分享、同事转发、活动平台等。面对十几甚至几十个活动，手动筛选非常耗时：要逐个判断是否与自己的技术方向相关、时间是否冲突、地点是否方便，然后再手动创建日历提醒。

飞书在 2026 年 3 月底开源了官方 CLI 工具 @larksuite/cli（lark-cli），支持通过命令行直接操作飞书云文档、日历、多维表格等。这让我想到：如果能把这个 CLI 工具和 SOLO 的 Skill 能力结合起来，就能打造一个"活动筛选 + 文档生成 + 日程创建"的全自动化工作流。

3. 实践过程

3.1 任务拆解

整个项目我拆解为以下步骤：

  1. 需求梳理与用户调研 — 明确技能的输入来源、输出格式、用户画像机制

  2. 飞书 CLI 能力调研 — 研究 lark-cli 的文档创建和日程创建命令

  3. 技能编写（SKILL.md） — 定义 6 阶段工作流

  4. 测试验证 — 设计 3 个不同场景的测试用例并行运行

  5. 全面排查与修复 — 发现并修复 8 个问题（含 1 个 CLI 命令 bug）

  6. 迭代优化 — 根据测试反馈调整流程（增加用户确认环节）

  7. GitHub 发布 — 脱敏处理后上传开源

3.2 用了 SOLO 哪些能力

  • Skill Creator 技能：SOLO 内置的技能创建框架，提供了完整的"编写 → 测试 → 评估 → 迭代"工作流

  • 子代理并行执行：同时启动 3 个子代理运行测试用例，大幅缩短验证时间

  • 飞书 CLI 集成：通过 RunCommand 工具直接调用 lark-cli 创建真实文档和日程

  • WebFetch + WebSearch：调研飞书 CLI 文档和 GitHub 仓库

  • 文件读写 + Grep：全面排查项目中的敏感信息

3.3 关键 Prompt / 操作过程

技能创建的核心 Prompt：

“我要基于飞书 CLI 创建一个技能，当我提供一堆的活动清单时，你能快速读取活动信息，并基于你对我的理解挑选出我值得关注的活动，将这些活动整理成一个飞书云文档，并且创建上相应的飞书日程。”

SOLO 的 Skill Creator 框架接收到这个需求后，自动引导我完成了：

  • 需求澄清（活动来源格式、用户画像策略、文档格式偏好等）

  • 飞书 CLI 能力调研（通过子代理搜索 GitHub 仓库和官方文档）

  • SKILL.md 编写（定义了 6 阶段工作流）

  • 测试用例设计（3 个覆盖不同场景的 eval）

发现关键 Bug 的过程：

在全面排查阶段，SOLO 通过实际执行 lark-cli docs +create --dry-run 命令发现了一个文档中未提及的陷阱——飞书 CLI 的 @file 语法只支持相对路径，不支持绝对路径。原技能中写的 --markdown @/path/to/content.md 会直接报错。这个 bug 如果不排查，用户在实际使用时一定会遇到。

# 报错信息
--markdown: invalid file path "/tmp/test.md": --file must be a relative path 
within the current directory (hint: cd to the target directory first)

修复方案：先 cd 到文件所在目录，再使用相对路径引用。

3.4 中间踩过什么坑

坑 描述 解决方式
飞书 CLI @file 路径限制 @file 语法不支持绝对路径 先 cd 再用相对路径
流程顺序矛盾 先创建文档再确认日程，但文档模板已写"日程已创建" 新增阶段 4（用户确认），调整流程为 6 阶段
文档格式单一 只有卡片模板，活动多时不适用 补充表格、时间线、分类三种模板
边界情况缺失 0 个推荐活动时无处理逻辑 增加"放宽条件"的交互分支
测试中文档创建失败 文件夹权限问题导致创建失败 增加降级策略，保存本地 Markdown
GitHub push 超时 网络环境无法直连 GitHub 443 改用 GitHub API 逐文件上传

4. 成果展示

4.1 技能架构

Event Curator 采用 6 阶段流水线架构：

用户画像收集 → 活动信息解析 → 智能筛选推荐 → 用户确认 → 创建飞书文档 → 创建飞书日程

4.2 实际运行效果

测试场景：北京后端开发者，关注 AI 和云原生

输入 8 个活动，技能自动：

  1. 建立用户画像（角色、兴趣、城市、时间偏好等）

  2. 筛选出 5 个推荐活动，分为 3 个级别

  3. 为每个活动生成个性化推荐理由

  4. 创建飞书云文档

  5. 为强烈推荐的活动创建飞书日程

筛选结果示例：

级别 活动 推荐理由
:star: 强烈推荐 KubeCon China 2026 CNCF 主办的云原生顶级大会，北京本地举办
:star: 强烈推荐 AI Agent 开发者日 AI 最热方向，飞书团队主办，北京+线上
:star: 强烈推荐 GTC 2026 大会 NVIDIA 全球顶级 AI 大会
:+1: 值得关注 PyCon 2026 Python 核心语言大会，线上零成本
:light_bulb: 可选参加 React Conf 2026 拓展全栈视野，线上参与

未推荐：设计师之夜（方向不匹配）、Web3 黑客松（关联度低）、创业者咖啡局（非技术导向）

4.3 多场景测试结果

测试用例 输入格式 用户角色 推荐数量 飞书文档 飞书日程
后端开发者 + 文本列表 纯文本 后端开发者 5/8 :white_check_mark: 已创建 :white_check_mark: 3 个日程
产品经理 + 活动列表 文本 产品经理 5/8 :white_check_mark: 已创建 —
前端开发者 + CSV 文件 CSV 文件 前端开发者 4/7 :warning: 降级本地 MD :white_check_mark: 4 个日程

4.4 项目链接

5. 效果与总结

提效了多少？

环节 手动操作 使用技能后
活动筛选（20个活动） 30-60 分钟逐个判断 < 1 分钟自动完成
整理推荐文档 20-30 分钟排版 自动生成飞书文档
创建日历日程 5-10 分钟逐个添加 一键批量创建
合计 约 1 小时 约 2 分钟

SOLO 在整个流程中做了什么？

SOLO 不仅仅帮我写了代码，它真正扮演了一个"全栈 AI 助手"的角色：

  1. 产品经理：帮我梳理需求、澄清模糊点、设计用户交互流程

  2. 技术调研员：通过子代理并行调研飞书 CLI 的 200+ 命令，提取出我需要的文档和日程 API

  3. 技能设计师：编写了结构清晰、覆盖全面的 SKILL.md（6 阶段工作流 + 错误处理 + 降级策略）

  4. QA 工程师：设计 3 个测试用例并行运行，自动评估输出质量

  5. 安全审计员：全面排查敏感信息，发现了 CLI 的 @file 路径 bug

  6. DevOps：处理 GitHub 发布中的网络问题，改用 API 上传

可复用的方法

  1. 先调研再动手：让 SOLO 先调研工具能力（如飞书 CLI 的 help 输出），再写技能定义，避免凭想象写出的命令不work

  2. dry-run 验证：对 CLI 命令使用 --dry-run 先验证语法和参数，再实际执行

  3. 并行测试：利用子代理同时运行多个测试用例，快速发现问题

  4. 全面排查：技能写完后做一次系统性的排查（命令准确性、边界情况、错误处理、敏感信息），能发现很多盲点

个人感受

这次使用 SOLO 创建 Skill 的体验非常流畅。最让我印象深刻的是 SOLO 的"自查能力"——在全面排查阶段，它不是简单检查语法，而是实际运行 CLI 命令来验证，从而发现了文档中未提及的 @file 相对路径限制。这种"不只是读文档，而是实际验证"的做事方式，是传统开发中很容易忽略的。

飞书 CLI 的开源也让整个方案变得非常优雅——不需要处理复杂的 API 认证和鉴权，一行命令就能创建文档和日程。这种"CLI 即 API"的理念，加上 SOLO 的自动化能力，让"想法 → 产品"的距离变得前所未有的短。