AI 写代码越来越快，为什么项目却越来越难维护？

事件核心：发生了什么

这篇发布在掘金的技术文章记录了 Flow2Spec 团队的一线观察：AI 编程工具能完成复杂编码，却常反问一些项目基础事实——接口能否重试、批处理幂等键由谁维护、状态字段归属哪个模块。这些问题代码里其实都有，但新会话无法继承上一次的实现语境，只能重新搜索仓库。

Flow2Spec 没有选择把规则堆进单个 AGENTS.md 或 CLAUDE.md，而是设计了一套仓内分层知识协议：.Knowledge/ 目录下分 L0 路由索引（manifest-routing.json）、L1 关键词分片（matchers）、L2 主题摘要（topics）、L3 长文档（stock-docs/req-docs）。Agent 按“match → expand → verify → act”四步读取知识，避免一次性加载整个项目文档。知识变更则通过 kb-delta.json 结构化提交，用 topic revision 乐观锁阻止多开发者基于过期版本写入。

为什么重要

这触及了 AI 编程工具从“写单文件”走向“维护真实项目”时的核心瓶颈：上下文不是越大越好，而是需要按任务路由。传统 RAG 和语义检索擅长“可能相关”，但权限、幂等、数据边界这类硬约束不能靠相似度模糊命中。

Flow2Spec 的价值不在目录命名，而在于把项目知识当成代码一样管理：有路由、有依赖、有版本号、可 Code Review。它提出一个判断标准——知识层能否进入 Git diff，决定了 AI 修改代码时是否会对既有约束产生不可追踪的破坏。目前公开信息显示，该方案已通过 Codex 在一个空仓库完成最小初始化验证，生成了 .Knowledge/、root AGENTS.md 和 flow2spec.config.json。

对用户/开发者/创作者的影响

对正在使用 AI 编程工具的开发者，这篇文章提供了一个直接可复用的排错思路：如果 Agent 总在问“项目里已有”的问题，问题通常不在模型能力，而在知识没有路由入口。建议团队在引入 AI 协作前，先按 L0-L2 分层梳理高频约束（如重试策略、幂等键、模块边界），而不是把规则倒进一个几千行的规则文件。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对 AI 编程工具厂商，Flow2Spec 的 revision 机制值得关注：它用“baseRevision 与磁盘 revision 比对”替代自动文本合并，明确拒绝“能插进去≠业务语义兼容”的风险。这与 Claude Code 的 CLAUDE.md 模式形成差异化，也更适合多人协作的企业仓库。

对技术管理者，这篇文章给出了一条维护边界：.task/ 本地任务现场不入 Git，.Knowledge/ 团队事实随代码入库，避免把个人 Agent 会话同步成另一套项目管理系统。

值得关注的后续

第一，Flow2Spec 已通过 npx 完成初始化，后续可观察其 CLI 在 plan/apply 阶段对 revision 冲突的处理是否稳定，以及是否支持主流的 Claude Code、Codex 之外的 Agent 框架。

第二，该方案限定在“代码仓库内”，不覆盖跨仓库、跨服务的知识路由；后续是否会扩展分布式知识同步值得留意。

第三，作者明确表示这不是语义检索的替代品，而是偏确定性的仓内协议。两者将来是竞争还是并存，会影响 AI 编程工具在大型项目中的架构选型。

来源：juejin