脚手架可以拆，护栏不该拆

有人把"/goal 是如何实现的"当成面试题来考候选人，有位老师公开唱了反调，四点讲得相当不客气（转述自原帖）：

一，Prompt 写得足够好，也可以不依赖 /goal——目标线程管理、生命周期、工具设计，靠 vibe coding 实现算不上难；他甚至不觉得 /goal 有多优雅，反而可能消耗额外的 token。

二，Claude Code 早期的 Ralph Loop 加 stop hook，某种意义上就是早期的 /goal。三，在 Codex /goal 发布之前，他一直用"do not stop until"来驱动长时任务——三月份之前的模型就已经能连续执行十几个小时了。

四，/goal 感觉更多是名字取得好听，语义上像在向它许愿、愿望就能达成，实践中几乎没有任何帮助。

结论更狠：就像 /plan、/superpowers 这类工具一样，随着模型上下文与长时任务能力提升，/goal 早已被模型内化，调用这些 command 工具只会产生副作用——只是使用者的操作习惯还没改过来。

这段话的价值在于它给今晚的斜杠命令线补上了必要的一面。我们一路讲"方法论的终点是一组斜杠命令"（59805）、讲 Skill 货架百万条（59493）、讲工具默认先喂 agent——那条线说的是命令怎么让流程变便宜；这位老师说的是另一头：命令是脚手架，而脚手架的宿命是被内化。

当模型自己就会先想清楚再动手，/plan 的价值就从"引导"退化成"多一道仪式"；当模型自己知道不许中途停，/goal 反而成了多余的一声令下。同一组命令，在能力不足时是补药，在能力足够后是阻力——这与"hallucination 会随模型进步自动消失"是同一个判断的翻版：很多当下的技巧，是今天的能力缺口买下的权宜。

但这不构成"命令无用论"。真正的分界在约束的强度：模型内化的是"怎么做"的习惯，命令承担的常常是"不许怎么做"的硬边界——批准闸、预算线、验收条件这些，模型再进步也不会自发给自己上锁。

脚手架可以拆，护栏不该拆；把两者混为一谈，才是 /goal 讨论里最容易摔的坑。今晚从 sandbox kit 的权限注解到"批准之前绝不擅自动工"，讲的全是护栏那一侧——命令退场与否，要看它站在哪一边。

给面试与选型的人一句落地的：遇到"/goal 怎么实现"这类题，别急着背实现——先答它的动机（为什么需要外部驱动长任务），再答它的退化条件（模型强到什么程度就不再需要）。能把一个工具讲到"它何时该被卸载"，比只会装它更能证明你懂工程；而日常用命令的人也记住一条：每年回头试一次，把某个命令摘掉看会不会出事——不出事，就该退休了。