为什么我把行程 skill 砍掉一半

我有一个自用的 Claude skill，叫 trip-structure：把松散的旅行想法压成可执行的日程。今年 4 月初，我嫌它的输出”不够结构化、不够完整”，让 skill-creator 重写它。这篇是那次重写的复盘——重点不是重写本身，而是中间那段滑向 over-design、又被拉回来的经过。

“更完整”是一个危险的需求表述

起点的不满是真实的：原版输出松散，行程信息要靠读散文去拼。但当我把”更结构化、更完整”递给 AI 时，它的默认响应是做加法——模板长出了 Header 加四个 section 的结构，每个 section 各管一摊。看起来很专业，每一块单独看都有存在理由。

问题在于我停下来问了一个问题：我在什么场景下读这个输出？答案是两个：出发前扫一眼全程的骨架；到了现场，在一个具体地点面前想知道”我在看什么”。四个 section 的报告对这两个场景都不友好——骨架被摊薄在多个章节里，深度又不在我需要它的位置上。“完整”被实现成了”更多”，而我要的其实是密度。

收敛动作：合并两个，删掉两个

拉回的动作很具体：

• Header 保留——城市、天数、一句话概览，没有争议。
• Section 1 和 2 合并成一张事件表——每个事件一行，列是：日期/周几、区域、项目名、类型 emoji、开始时间、预估时长、预算+描述、备注。吃饭、交通、休息也各占一行，表本身就是行程，可以逐行照着走。
• Section 3、4 整体删除——不是压缩，不是合并，是删除。

砍掉一半的模板，换来的是剩下那一半的密度被逼到极限。

删掉的深度去了哪里：备注栏

如果只是删，输出会退化成一张干巴巴的清单。这次重写真正的设计判断在最后一列：备注栏对景观/游览类事件强制写成详尽的迷你导览——历史背景、文化语境、结构性解释（政治/经济/宗教/族群）、体验路径、观察重点。相当于把 LLM 当现场策展人用。

于是最终形态是一个双层结构：表是骨架，导览是肉。这个结构同时防住了两种退化——只有骨架没有肉，输出退化成清单；只有肉没有骨架，输出退化成散文。原来四个 section 想用”更多模块”解决的问题，最后用”两层”解决了。

这次收敛后来变成了方法

这个 skill 后来没有停在自用脚本：它和另外几个旅行 skill 一起，被重构成一个可安装的 Claude Code 插件——v0.5 是 9 个技能覆盖”建画像→选目的地→路线→选项→深判→日程→在途仲裁→对抗审计→行后学习”的完整生命周期，v0.6 又并入横切的 grounding 纪律（每个具体事实要么经 MCP/搜索核实，要么标”需查询”，绝不编造），共享一套锁定的 SABCD± 评分卡。

有意思的是，“砍”在那个套件的演进里反复出现：全程约 5 个材料级决策被冷对抗评审反转——包括把最性感的”越用越懂你”功能限制成只提议不写入，以及刻意舍弃自动代订。trip-structure 那次砍 section，现在回头看是同一个肌肉的第一次发力。

复盘

三条 takeaway：

1. “更完整”要翻译成场景再交给 AI。不翻译，AI 会用”更多”来兑现它——这不是 AI 的错，是需求方把品味外包了。
2. 结构化不等于更多结构。判断一个模块该不该存在的标准，是用户在哪个场景消费它，而不是它单独看有没有道理。
3. over-design 最好的解药是删除而不是压缩。压缩是和每个模块讨价还价；删除是承认这个位置本来就不该有东西。

我对 AI 协作里的这类时刻越来越敏感：AI 不会替你喊停，它只会把你上一句话执行得更彻底。喊停那一下，目前还是人的工作——大概也是 PM 这个工种在 AI 时代剩下的、最不可外包的部分。