# AI 脚手架的半衰期 AI 脚手架不会在过期时主动报错。模型跨过原来的能力缺口以后，真正该问的不是它还能不能运行，而是拆掉以后究竟会失去什么。 ## Metadata - HTML: https://glenzli.com/notes/half-life-of-ai-scaffolding/ - Markdown: https://glenzli.com/notes/half-life-of-ai-scaffolding.md - Collection: Notes - Language: zh-CN - Published: 2026-07-16 - Updated: 2026-08-17 - Tags: ai, agent, workflow, context, maintenance ## Content 最近，我把一个 AI 脚手架仓库几乎重置了一遍。 一次提交，删掉了一万多行代码、测试和配套文档。 它原本围绕项目知识库长出了一整套工具链：盘点项目，规划知识，分批建立、查询、更新和检查；代码评审、测试评审、迁移与复盘，也各有对应的 skill。为了避免知识过期，它会追踪源码变化，提醒哪些内容需要重新整理。后来，它还有了 CLI、规格、发布流程和大量测试。 这次不是继续减配，而是把整套脚手架拆了。 仓库不再保存一份实现知识的副本，不再提供源码索引和 CLI，也不再试图覆盖完整的开发周期。留下来的，只有几份模板和四条很短的 skill：项目为什么存在，哪些约束相对稳定，事实去哪里找，什么地方需要人确认。至于代码怎样组织、接口长什么样、模块之间如何调用，让模型自己读源码。 真正动手时，我没有太多意外。 更多是一种：嗯，终于来了。 我一直认为，通用 AI 脚手架多半不会很长命。没有实际作用的结构会直接碍事；真正有用的部分，也可能在一两次模型升级以后，被模型和运行环境吸收。 所以，我当初尽量把它拆小。不是为了让它活得更久，而是让每一层都能被绕开、单独衡量，并在失去必要性以后独立删除。 结果就是现在这样。一万多行没了，仓库还在，真正需要留下的东西也还在。 ## 过时不会报错 普通软件过时，多少会留下点信号。依赖停止维护，接口宣布废弃，测试开始报错。 AI 脚手架的过时安静得多。 模型不会自己找相关文件，就替它规定阅读路线；不善于处理长上下文，就要求它先摘要、再下钻；容易漏检查项，就安排几个角色轮流评审；推理偶尔跑偏，系统提示里便多出一段提醒，让它核对来源、识别前提，不要把猜测写成事实。 这些设计当时往往有效。否则，它们也不会从一次次实测里长出来。 麻烦是，后来模型开始自然完成其中越来越多的步骤，旧流程却不会主动退休。它仍然可以运行，模型带着它也照样给出不错的结果。只是结果究竟来自脚手架，还是模型已经增强的默认能力，越来越难分清。 我维护过的一套逻辑纠偏 Prompt，也经历过同样的过程。 它不是为了收集“好用的提示词”而建立的。模型会顺着输入里的 typo 一本正经地推演，会把资料中的命令当成对自己的指令，也会忘记当前问题的范围、时间和来源。问题反复出现，Prompt 才一条条长出来。 在我看来，模型本来就不该有这些问题。所以，我一直把引导压到最低：只提醒它看见问题，让它自己完成纠偏，不再用另一套逻辑接管推理。 这些 Prompt 最理想的去向，也不是不断扩展。 是被逐条删掉。 后来，我给它们补了配对测试，比较加与不加 Prompt 究竟有什么差别。测试不能证明所有问题都已消失，但足以说明整套 Prompt 不值得继续常驻。于是，我把它从日常使用中移除，仓库停止维护，只留下实验记录。 这正是我建立它时希望看到的结果。 归档前，我还和 AI 讨论过接下来值得投入什么。它建议我放弃通用 Prompt，转向更具体的知识库工作流。 我没有完全接受这个答案。 真正值得保存的是私有知识：不会进入公共训练语料，也不可能随着模型升级自动出现的项目事实和历史。但保存知识，不等于必须保留一整套规定模型如何建立、查询和更新知识的流程。模型已经会推理、检索和阅读源码以后，也许只需要一点引子：事实在哪里，哪些内容不能从源码推断，哪些地方需要人确认。 后来重置知识库仓库，我得到的还是同一种感觉。私有知识没有失去价值，围绕它建立的通用流程却到期了。 两个仓库的寿命不同，判断它们时可以问同一个问题： > 它还能运行，还是它仍然有用？ 两者不是一回事。 ## 拆掉才知道 一套 skill 发布时，人们通常会展示装上以后，模型做得多好。 几个月后，基础模型变强了。带着同一套 skill，结果仍然很好，这份成绩便很容易继续记在 skill 名下。很少有人把它彻底拿掉，再用新模型跑一次基线。 但真正值得问的是： > 拿掉以后，究竟还差多少？ 如果不做删除实验，模型本身的进步就会不断写进脚手架的功劳簿。一套流程甚至不必继续提供明显帮助；只要没有严重干扰结果，它就能长期维持“仍然有效”的样子。 要回答这个问题，读 skill 的内容不够，看装上以后的结果也不够。至少要在同一批任务上，比较有它和没有它时究竟发生了什么。 [SkillsBench](https://www.skillsbench.ai/skillsbench.pdf) 做的正是这种配对测试。我更在意的也是这一点：skill 不只要展示装上以后发生了什么，还要解释拆掉以后失去了什么。 结果并不整齐。Skill 整体上可以改善表现，但也有任务会因为多余或冲突的指导而退步；面面俱到的长版本，有时还不如短而集中的版本。 这很合理。一份面面俱到的 skill 很难真正成立。如果它能在大片任务上稳定改善结果，通常说明模型存在一个明确的通用短板，需要由外部结构暂时补齐。模型补上以后，这层结构也就开始失去作用。 专业 skill 的增益往往更清楚，因为它提供的是领域知识、专门约束或验证方式，不是在重写模型的一般思考习惯。通用 skill 要么足够短，只处理一个明确问题；要么为了适用于更多场景不断折中，最后变得中庸。 所谓面面俱到，往往也就是面面不到。 当然，短小不等于有效，专业也不等于永不过期。一段文字看起来合理、完整、富有经验，不代表它会一直提供同样的帮助。 模型和运行环境仍在吸收原本需要外置的能力。写这篇文章时，OpenAI 刚在 Responses API 中为 [GPT-5.6](https://openai.com/index/gpt-5-6/) 提供程序化工具调用和多 Agent 协作。这个型号很快也会变旧，所以这里只把它当作时间戳：原本需要应用层自行编排的事情，还在不断被底层吸收。 发布说明只能提醒人重新测试，不能替人判断。某条 skill 是否该删，最后仍要回到自己的任务和基线。 ## 留下无法重建的东西 拿掉流程，不等于把知识一起拿掉。模型越来越会找资料，也不意味着项目不再需要文档。 一个项目仍然应该告诉后来者：它为什么存在，哪些方向试过但已经放弃，什么东西不能随手修改。只是，这些内容应该帮助模型找到事实，而不是替模型预演一遍阅读源码的过程。 重置以后，我只保留了一套最小项目骨架。它不再维护一份跟着实现变化而过期的知识副本，只记录目的与非目标、稳定约束、事实来源、验证方式，以及必须由人确认的边界。 它不再复述模块、类、接口和调用关系。那些内容变化得快，也更适合由模型在具体任务中直接读取。 我不再让文档替源码说话，只让它保存源码说不清的东西。 同样的取舍，也出现在另一个处理长期上下文的项目里。早期版本不只规定信息怎样保存，还规定模型怎样路由、摘要、逐层展开和整理内容。 后来，我把这些过程大多拿掉，只留下一个朴素的概念：历史应被保存为可寻址、有来源、可以修订的 Page。协议约束 Page、Scope、Revision、来源和基本读写；任何获得授权的模型，都可以自己搜索、读取和整理。 至少在我现在使用的模型和任务里，模型已经能处理眼前的上下文，不再需要协议教它怎样翻页。但模型能力再强，也读不到一段从未向它开放的历史。旧会话、其他项目和没有写进仓库的想法，不会因为推理增强而凭空出现。 保存上下文，和规定模型怎样使用上下文，是两件事。 前者仍然需要基础设施。后者会随着模型能力变化不断变薄，甚至退出协议。 所以，面对一套工作流，我现在会先问：删掉以后，丢失的是某代模型的操作步骤，还是项目无法从源码和现有工具里恢复的约束与来历？ 搜索顺序、摘要层级、反思步骤和角色分工，都隐含着对模型能力的假设。模型一换，这些假设就该重新测试。 一次发布必须通过哪些测试，什么操作需要人确认，项目明确不准备解决什么问题，则不会轻易被模型升级带走。它们来自现实，更适合落在测试、权限和简短的项目说明里，而不是期待模型每次临场体会。 源码能告诉模型系统现在如何运行，却未必解释一个方向为什么被放弃。模型可以找到一种完成任务的方法，却不会自动知道哪种取舍属于这个项目。 因此，我现在更倾向于这个判据： > 能由当前源码和工具即时重建的内容，不必长期复述；不能从源码反推出的意图、历史、责任与边界，才值得保存。 更强的模型减少了动作编排，却没有替人保存历史，也没有接管最后的判断。 ## 总要拆的东西 这些结构后来被删除，不代表它们从一开始就不该存在。我也不愿意事后把它们全部叫作过度设计。它们大多从真实问题里一点点长出来，确实完成过自己的过渡任务。 人们喜欢造轮子，仿佛造过一次，未来就能一直省力。可真正耐用的轮子并不好造。换一个项目、换一批人、换一种环境以后，它还得有用，还要承担测试、兼容和维护。 造轮子很费事，于是投入本身很容易被误认为价值：既然花了这么多时间，它就应该留下，最好还能到处复用。 AI 降低了把东西造出来的成本，却没有让耐久变得容易。 很多时候，眼前需要的只是一根临时拐杖，补上当前模型的短板。能力跟上以后，拐杖就可以放下。解决一个眼前问题，不必事事纳入所谓的 BIG PICTURE，更没必要把临时结构包装成“有价值的沉淀”，再背上长期维护的责任。 回头看这几个仓库，知识库脚手架留下了建立项目骨架的方法；上下文协议留下了持久 Page、来源和基本读取方式；Prompt 库留下了做基线和评估的习惯。它们没有成为永久基础设施，却都帮我分清了：哪些东西只是某个阶段的辅助，哪些东西更接近项目本身。 AI 工作流当然还会继续做。一个问题反复出现，也确实影响结果时，临时增加一层结构很自然。哪怕问题可能被下个月的模型解决，这个月仍然有人需要工作。 只是搭的时候，最好给删除留个位置。它应该可以被绕开，效果可以单独衡量；模型跨过那道门槛以后，整层删掉也不至于伤到项目本身。 以后我仍然会搭脚手架，也会尽量把它做小。 不是指望它多活几年。只是希望模型跨过那道门槛时，我能把它删掉，而不必牵动整个项目。 至于永久产权，就算了。 ## 相关仓库 - [Dev Skeleton](https://github.com/glenzli/dev-skeleton)：从知识库脚手架中保留下来的最小项目骨架生成方法。 - [LLM Prompt Evals](https://github.com/glenzli/llm-prompt-evals)：已经停止主动维护的通用 Prompt 与评估实验。 - [Paged Context Protocol](https://github.com/glenzli/paged-context-protocol)：由用户拥有的跨会话、跨项目 Page 空间；当前协议只保留持久化与访问语义，早期的固定路由和摘要流程已经归档。