文章摘要
Agnes AI

这次旅行计划不是从一张空白纸开始的。

我让 AI 调用 lark-cli 读取飞书知识库里的旅行文档，再对路线、住宿、交通和风险提醒进行反复核对，最后写回飞书文档，形成一份可以继续更新的旅游计划书。

这条链路可以概括成：

1
2
3
4
5
AI 读取任务背景
    -> lark-cli 获取飞书文档
    -> AI 统一路线、日期和约束
    -> lark-cli 更新文档
    -> 飞书成为最终执行清单

为什么要把旅游计划放进飞书

普通聊天适合讨论想法，却不适合长期维护一份复杂行程。旅行计划通常同时包含：

  • 每天去哪里，以及当天是否需要长距离转场。
  • 高铁、飞机、景区接驳的先后关系。
  • 酒店是否已定、是否可取消、行李如何处理。
  • 门票和车票什么时候开售，最晚什么时候要买。
  • 下雨、晚点、赶不上车时的备选方案。

这些信息分散在聊天里，很容易出现“前面说住沟口，后面又写成住景区内”的冲突。飞书文档提供了稳定的正文、表格和待办区，AI 每次修改前先读取当前版本，就能在原有结构上继续迭代，而不是重新生成一篇互相矛盾的攻略。

lark-cli 读取飞书文档

AI 可以直接调用 lark-cli，先以带 block ID 的 XML 形式读取文档：

1
2
3
4
5
6
lark-cli docs +fetch `
  --doc "https://my.feishu.cn/wiki/<wiki-token>" `
  --as user `
  --doc-format xml `
  --detail with-ids `
  --format json

with-ids 很重要。飞书文档中的标题、段落、表格和复选框都会对应一个 block ID，后续更新时需要准确定位目标 block。直接把整篇文档复制出来再覆盖，容易丢失原有结构，也更容易把旧版本内容带回来。

读取后，AI 先做事实整理，而不是马上改文档。我会把内容拆成四类：

  1. 已经确认的事实，例如已支付的酒店订单和已确定的航班。
  2. 推荐方案，例如为长距离转场安排更稳妥的交通衔接。
  3. 待确认事项，例如车票开售、门票预约和接驳询价。
  4. 风险和兜底，例如为天气、晚点和体力变化预留替代方案。

这样处理后，AI 不会把“建议住哪里”误写成“已经订好了”。

用 block 更新，而不是盲目重写全文

确认要修改的区域后，再使用 block 级更新：

1
2
3
4
5
6
7
8
9
10
11
@'
<table>
  <tr><td>日期</td><td>住宿落点</td><td>执行提醒</td></tr>
  <tr><td>某日</td><td>景区住宿</td><td>配合当天游览安排，轻装入住</td></tr>
</table>
'@ | lark-cli docs +update `
  --doc "https://my.feishu.cn/wiki/<wiki-token>" `
  --command block_replace `
  --block-id <block-id> `
  --content - `
  --as user

每做一次 block 修改，我都会重新 fetch 相关章节。因为一次更新可能改变后续 block 的结构，继续使用旧 ID 有机会得到“block not found”，也可能更新到错误位置。

文档更新完成后，至少检查三项：

  • 飞书返回 result: success，并且 revision ID 已变化。
  • 重新读取的内容中，旧路线和旧住宿描述已经消失。
  • 待办、表格和正文之间没有互相冲突的日期。

这次实际生成的计划

这次以一份跨城山地旅行计划为例。文档没有停留在“推荐几个景点”，而是把城市段、景区段、交通节点和住宿落点放进同一套结构，再为关键转场保留主选、备选和确认时间。

其中最关键的不是景点数量，而是把约束写清楚：长距离转场日要控制节奏，景区游览要和住宿位置衔接，返程交通要倒排，天气和体力变化要有弹性方案。

AI 真正帮上忙的地方

AI 的价值不是凭空推荐更多景点，而是把分散信息变成有约束的执行方案。

例如，住宿表最终按“日期、酒店 / 落点、费用、简要备注”整理，明确区分已定和待定项目。交通表则把每一段的主选、备选、预算和最晚确认时间放在一起。

这种结构让计划书具备了三个属性：

1
2
3
能看懂：按日期和地点组织
能执行：每项都有下一步动作
可维护：以后可以继续修改同一份文档

如果下一次酒店变更，AI 只需要重新读取住宿章节，更新受影响的几行，再检查返程接驳是否仍然成立，不必从头写一篇攻略。

这套工作流的边界

AI 和 lark-cli 各自负责不同的事情：

组件负责什么不负责什么
Codex理解上下文、运行命令、整理方案保证外部票务信息永远准确
lark-cli读取和更新飞书文档替代飞书权限管理和数据备份

所以，外部信息仍然需要人工确认。高铁时刻、景区限流、接驳班次和节假日价格都可能变化，AI 生成的“推荐”不能当成已经出票或已经预约。更稳妥的做法，是在文档中明确标记“已定 / 推荐 / 待确认 / 备选”。

结语

这次实践让我看到，AI 对接飞书最有用的地方，不是把聊天内容搬到另一个窗口，而是建立一条可持续的工作链路：AI 负责推理和执行，lark-cli 把结果写回飞书，飞书再成为下一次修改的事实来源。

旅游计划书只是一个例子。同样的方法也可以用于会议纪要、项目排期、采购清单和家庭事务。只要文档结构稳定、权限边界清楚、每次更新后重新校验，AI 就能从“一次性生成器”变成真正参与维护的协作工具。