AI 脚手架的半衰期

最近，我把一个 AI 脚手架仓库几乎重置了一遍。

一次提交，删掉了一万多行代码、测试和配套文档。

它原本围绕项目知识库长出了一整套工具链：盘点项目，规划知识，分批建立、查询、更新和检查；代码评审、测试评审、迁移与复盘，也各有对应的 skill。为了避免知识过期，它会追踪源码变化，提醒哪些内容需要重新整理。后来，它还有了 CLI、规格、发布流程和大量测试。

这次不是继续减配，而是把整套脚手架拆了。

仓库不再保存一份实现知识的副本，不再提供源码索引和 CLI，也不再试图覆盖完整的开发周期。留下来的，只有几份模板和四条很短的 skill：项目为什么存在，哪些约束相对稳定，事实去哪里找，什么地方需要人确认。至于代码怎样组织、接口长什么样、模块之间如何调用，让模型自己读源码。

真正动手时，我没有太多意外。

更多是一种：嗯，终于来了。

我一直认为，通用 AI 脚手架多半不会很长命。没有实际作用的结构会直接碍事；真正有用的部分，也可能在一两次模型升级以后，被模型和运行环境吸收。

所以，我当初尽量把它拆小。不是为了让它活得更久，而是让每一层都能被绕开、单独衡量，并在失去必要性以后独立删除。

结果就是现在这样。一万多行没了，仓库还在，真正需要留下的东西也还在。

过时不会报错

普通软件过时，多少会留下点信号。依赖停止维护，接口宣布废弃，测试开始报错。

AI 脚手架的过时安静得多。

模型不会自己找相关文件，就替它规定阅读路线；不善于处理长上下文，就要求它先摘要、再下钻；容易漏检查项，就安排几个角色轮流评审；推理偶尔跑偏，系统提示里便多出一段提醒，让它核对来源、识别前提，不要把猜测写成事实。

这些设计当时往往有效。否则，它们也不会从一次次实测里长出来。

麻烦是，后来模型开始自然完成其中越来越多的步骤，旧流程却不会主动退休。它仍然可以运行，模型带着它也照样给出不错的结果。只是结果究竟来自脚手架，还是模型已经增强的默认能力，越来越难分清。

我维护过的一套逻辑纠偏 Prompt，也经历过同样的过程。

它不是为了收集“好用的提示词”而建立的。模型会顺着输入里的 typo 一本正经地推演，会把资料中的命令当成对自己的指令，也会忘记当前问题的范围、时间和来源。问题反复出现，Prompt 才一条条长出来。

在我看来，模型本来就不该有这些问题。所以，我一直把引导压到最低：只提醒它看见问题，让它自己完成纠偏，不再用另一套逻辑接管推理。

这些 Prompt 最理想的去向，也不是不断扩展。

是被逐条删掉。

后来，我给它们补了配对测试，比较加与不加 Prompt 究竟有什么差别。测试不能证明所有问题都已消失，但足以说明整套 Prompt 不值得继续常驻。于是，我把它从日常使用中移除，仓库停止维护，只留下实验记录。

这正是我建立它时希望看到的结果。

归档前，我还和 AI 讨论过接下来值得投入什么。它建议我放弃通用 Prompt，转向更具体的知识库工作流。

我没有完全接受这个答案。

真正值得保存的是私有知识：不会进入公共训练语料，也不可能随着模型升级自动出现的项目事实和历史。但保存知识，不等于必须保留一整套规定模型如何建立、查询和更新知识的流程。模型已经会推理、检索和阅读源码以后，也许只需要一点引子：事实在哪里，哪些内容不能从源码推断，哪些地方需要人确认。

后来重置知识库仓库，我得到的还是同一种感觉。私有知识没有失去价值，围绕它建立的通用流程却到期了。

两个仓库的寿命不同，判断它们时可以问同一个问题：

它还能运行，还是它仍然有用？

两者不是一回事。

拆掉才知道

一套 skill 发布时，人们通常会展示装上以后，模型做得多好。

几个月后，基础模型变强了。带着同一套 skill，结果仍然很好，这份成绩便很容易继续记在 skill 名下。很少有人把它彻底拿掉，再用新模型跑一次基线。

但真正值得问的是：

拿掉以后，究竟还差多少？

如果不做删除实验，模型本身的进步就会不断写进脚手架的功劳簿。一套流程甚至不必继续提供明显帮助；只要没有严重干扰结果，它就能长期维持“仍然有效”的样子。

要回答这个问题，读 skill 的内容不够，看装上以后的结果也不够。至少要在同一批任务上，比较有它和没有它时究竟发生了什么。

SkillsBench 做的正是这种配对测试。我更在意的也是这一点：skill 不只要展示装上以后发生了什么，还要解释拆掉以后失去了什么。

结果并不整齐。Skill 整体上可以改善表现，但也有任务会因为多余或冲突的指导而退步；面面俱到的长版本，有时还不如短而集中的版本。

这很合理。一份面面俱到的 skill 很难真正成立。如果它能在大片任务上稳定改善结果，通常说明模型存在一个明确的通用短板，需要由外部结构暂时补齐。模型补上以后，这层结构也就开始失去作用。

专业 skill 的增益往往更清楚，因为它提供的是领域知识、专门约束或验证方式，不是在重写模型的一般思考习惯。通用 skill 要么足够短，只处理一个明确问题；要么为了适用于更多场景不断折中，最后变得中庸。

所谓面面俱到，往往也就是面面不到。

当然，短小不等于有效，专业也不等于永不过期。一段文字看起来合理、完整、富有经验，不代表它会一直提供同样的帮助。

模型和运行环境仍在吸收原本需要外置的能力。写这篇文章时，OpenAI 刚在 Responses API 中为 GPT-5.6 提供程序化工具调用和多 Agent 协作。这个型号很快也会变旧，所以这里只把它当作时间戳：原本需要应用层自行编排的事情，还在不断被底层吸收。

发布说明只能提醒人重新测试，不能替人判断。某条 skill 是否该删，最后仍要回到自己的任务和基线。

留下无法重建的东西

拿掉流程，不等于把知识一起拿掉。模型越来越会找资料，也不意味着项目不再需要文档。

一个项目仍然应该告诉后来者：它为什么存在，哪些方向试过但已经放弃，什么东西不能随手修改。只是，这些内容应该帮助模型找到事实，而不是替模型预演一遍阅读源码的过程。

重置以后，我只保留了一套最小项目骨架。它不再维护一份跟着实现变化而过期的知识副本，只记录目的与非目标、稳定约束、事实来源、验证方式，以及必须由人确认的边界。

它不再复述模块、类、接口和调用关系。那些内容变化得快，也更适合由模型在具体任务中直接读取。

我不再让文档替源码说话，只让它保存源码说不清的东西。

同样的取舍，也出现在另一个处理长期上下文的项目里。早期版本不只规定信息怎样保存，还规定模型怎样路由、摘要、逐层展开和整理内容。

后来，我把这些过程大多拿掉，只留下一个朴素的概念：历史应被保存为可寻址、有来源、可以修订的 Page。协议约束 Page、Scope、Revision、来源和基本读写；任何获得授权的模型，都可以自己搜索、读取和整理。

至少在我现在使用的模型和任务里，模型已经能处理眼前的上下文，不再需要协议教它怎样翻页。但模型能力再强，也读不到一段从未向它开放的历史。旧会话、其他项目和没有写进仓库的想法，不会因为推理增强而凭空出现。

保存上下文，和规定模型怎样使用上下文，是两件事。

前者仍然需要基础设施。后者会随着模型能力变化不断变薄，甚至退出协议。

所以，面对一套工作流，我现在会先问：删掉以后，丢失的是某代模型的操作步骤，还是项目无法从源码和现有工具里恢复的约束与来历？

搜索顺序、摘要层级、反思步骤和角色分工，都隐含着对模型能力的假设。模型一换，这些假设就该重新测试。

一次发布必须通过哪些测试，什么操作需要人确认，项目明确不准备解决什么问题，则不会轻易被模型升级带走。它们来自现实，更适合落在测试、权限和简短的项目说明里，而不是期待模型每次临场体会。

源码能告诉模型系统现在如何运行，却未必解释一个方向为什么被放弃。模型可以找到一种完成任务的方法，却不会自动知道哪种取舍属于这个项目。

因此，我现在更倾向于这个判据：

能由当前源码和工具即时重建的内容，不必长期复述；不能从源码反推出的意图、历史、责任与边界，才值得保存。

更强的模型减少了动作编排，却没有替人保存历史，也没有接管最后的判断。

总要拆的东西

这些结构后来被删除，不代表它们从一开始就不该存在。我也不愿意事后把它们全部叫作过度设计。它们大多从真实问题里一点点长出来，确实完成过自己的过渡任务。

人们喜欢造轮子，仿佛造过一次，未来就能一直省力。可真正耐用的轮子并不好造。换一个项目、换一批人、换一种环境以后，它还得有用，还要承担测试、兼容和维护。

造轮子很费事，于是投入本身很容易被误认为价值：既然花了这么多时间，它就应该留下，最好还能到处复用。

AI 降低了把东西造出来的成本，却没有让耐久变得容易。

很多时候，眼前需要的只是一根临时拐杖，补上当前模型的短板。能力跟上以后，拐杖就可以放下。解决一个眼前问题，不必事事纳入所谓的 BIG PICTURE，更没必要把临时结构包装成“有价值的沉淀”，再背上长期维护的责任。

回头看这几个仓库，知识库脚手架留下了建立项目骨架的方法；上下文协议留下了持久 Page、来源和基本读取方式；Prompt 库留下了做基线和评估的习惯。它们没有成为永久基础设施，却都帮我分清了：哪些东西只是某个阶段的辅助，哪些东西更接近项目本身。

AI 工作流当然还会继续做。一个问题反复出现，也确实影响结果时，临时增加一层结构很自然。哪怕问题可能被下个月的模型解决，这个月仍然有人需要工作。

只是搭的时候，最好给删除留个位置。它应该可以被绕开，效果可以单独衡量；模型跨过那道门槛以后，整层删掉也不至于伤到项目本身。

以后我仍然会搭脚手架，也会尽量把它做小。

不是指望它多活几年。只是希望模型跨过那道门槛时，我能把它删掉，而不必牵动整个项目。

至于永久产权，就算了。

相关仓库

• Dev Skeleton：从知识库脚手架中保留下来的最小项目骨架生成方法。
• LLM Prompt Evals：已经停止主动维护的通用 Prompt 与评估实验。
• Paged Context Protocol：由用户拥有的跨会话、跨项目 Page 空间；当前协议只保留持久化与访问语义，早期的固定路由和摘要流程已经归档。