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