制品生命周期收敛拓扑：CodeStable与AGE模式深度对比

一、引言

先看一个AI开发工程模板的自我定位。CodeStable在它的README里是这样描述的：

CodeStable的核心命题很明确：它是做什么的，以及如何上手应用。

而AGE选择的路径截然不同。它的出发点并非“约束”行为，而是基于更底层的控制原理来构建。

需要澄清一点：AGE模板并非让你原封不动照搬的固定分类法。它提供了一个默认的仓库治理结构——先把项目事实源、owner文档、过程记录、计划闭合、审计和技能使用的关系搭建起来，然后允许具体项目根据自身领域特点进行裁剪和扩展。这里要特别提一下nop-chaos-flux，它是一个高强度的AGE实例，可以作为实际应用时的参考。

所以，这篇文章的核心，就是要把CodeStable和AGE的差异讲清楚：

• CodeStable，一个即装即用、围绕软件生命周期制品和/cs-*技能入口来组织的AI编码工作流。
• AGE，一个围绕仓库事实源、owner文档权威、时效性、计划闭合、审计独立性和轨迹收敛来组织的收敛框架。

二、制品拓扑：codestable/ 聚合根 vs repo-wide owner 拓扑

CodeStable接入目标项目后，cs-onboard生成的运行时制品结构会集中在一个codestable/聚合根下面：

codestable/requirements/architecture/roadmap/features/issues/refactors/compound/tools/reference/

这套结构对应它的“6个实体+3个流程”：需求、架构、路线图、特性、问题、知识；特性引入、问题修改、代码重构。它的强项在于，能把“上次那个feature/bug当时是怎么搞的”集中收纳起来，三秒就能找到。

AGE模板的结构则不同，它不是单一聚合根，而是一张仓库范围的owner关系图。docs/index.md里明确说明了：

它把不同的事实放到不同的owner区域：

• docs/context/：强制AI上下文、事实源优先级、项目规则
• docs/backlog/：可选下一步工作和AI自治状态
• docs/input/：原始输入
• docs/discussions/：需求澄清与未决问题
• docs/requirements/：可供实现的、综合后的需求
• docs/design/：稳定的应用层特性/业务流owner文档
• docs/architecture/：稳定的技术基线和跨特性结构规则
• docs/plans/：非平凡工作的执行与闭合条件
• docs/audits/：审计方法和审计证据
• docs/process/、docs/references/：流程与稳定参考资料
• docs/lessons/、docs/analysis/、docs/retrospectives/：经验、研究与复盘
• docs/logs/、docs/bugs/、docs/testing/：过程记忆和证明记录
• docs/archive/：由人来决定移入的非活动历史记录

简单来说，CodeStable以软件生命周期实体为主轴；AGE则以“哪个文件对哪类事实拥有权威”为主轴。

而且，这个“权威”不只是Markdown文档的专利。AGE模板要求在冲突时去查阅source-of-truth-and-precedence.md，并在目录职责中明确区分owner文档、模型/Schema、代码、测试、部署和审计证据各自回答的问题。换句话说，AGE的事实源是仓库内多种制品的权威关系，而不仅仅是“文档多一些”。

三、时效模型：长效档案 vs owner doc / time-sensitive record 分离

CodeStable也对长效档案和过程制品做了区分：特性、问题、重构被放进带日期的目录；compound/则用YYYY-MM-DD-{doc_type}-{slug}.md来累积learning、trick、decision、explore。

AGE模板则把这个问题进一步规范化，分成了两类文件。在document-naming-and-timeliness.md里明确区分了：

稳定的owner文档通常使用稳定的文件名，原地更新，包括docs/design/、docs/architecture/、docs/process/、docs/references/。而过程记录通常带日期，比如logs、testing notes、discussions、analysis、audits、retrospectives，还有大多数plans和一次性requirements。

这个分离非常关键：AGE不允许把历史演进的痕迹混进规范性的owner文档里。模板的docs/architecture/README.md明确要求：

并且：

CodeStable也说architecture“只记现状”，但AGE把“稳定owner文档必须保持最新、过程历史放到带日期的记录里”变成了一条跨目录的命名与权威规则。

四、路由顺序：先选 skill vs 先找 owner truth

CodeStable的日常入口是/cs：

也就是说，一个开放式的用户诉求会被路由到一个具体的skill上去，比如cs-req、cs-roadmap、cs-feat-design、cs-issue-fix、cs-learn等等。CodeStable并不只靠skill，它也有codestable/制品树；但它的可操作入口主要是skill。

CodeStable的skill还有一个具体的运行时约束：

因此，跨skill共享口径必须由cs-onboard复制到目标项目的codestable/reference/，再由其他skill读取。这是一种package-runtime层面的隔离设计。

AGE模板的顺序正好相反。AGENTS.md要求先分类任务类型，然后去读docs/index.md，接着读owner文档，最后再检查是否有可复用的skill：

docs/index.md也明确提到：

AGE template的docs/skills/README.md把这个原则进一步制度化：

并且：

从模板内置的skills也能看出这个定位。它们不是feature生命周期的主入口，而是治理和审计方法：plan-audit-prompt.md、closure-audit-prompt.md、document-audit-prompt.md、bug-diagnosis-prompt.md、code-quality-audit-prompt.md、code-refactor-discovery-prompt.md、code-refactor-prompt.md、open-ended-audit-prompt.md、multi-dimensional-audit-prompt.md、index-routing-audit-prompt.md、requirement-gap-retrospective-prompt.md。

这些skill大多用于挑战、诊断、复盘、审计和方法选择，而不是去替代requirement、design、architecture的事实归属。plan-audit-prompt.md要检查baseline是否诚实、closure gates是否真实、proof是否覆盖了acceptance criteria；closure-audit-prompt.md要独立检查live beha vior、plan gates、proof evidence和docs alignment；index-routing-audit-prompt.md专门审查文档索引是否能把人和AI路由到正确的owner文档。

AGE对skill的批评，不是“skill没用”，而是skill不能变成事实源。agent-skills-vs-age-practice.md这篇文章明确指出：

它还进一步给出了判断标准：

这一点是非常明确的区别：CodeStable的skill是生命周期流程的主要执行入口；AGE的skill是owner truth已经确定之后的工作方法选择和审计工具。CodeStable把工作流包装成了skills；AGE则把skills放在仓库事实拓扑之下，限制了它们的权力。

五、Plan 机制：roadmap/design/acceptance vs closure contract

CodeStable没有AGE意义上的docs/plans/。它有三类相近的制品。

CodeStable的roadmap/用于大需求的事前规划：

features/下面则是：

{slug}-design.md{slug}-checklist.yaml{slug}-acceptance.md

其中，cs-feat-design起草design作为后续的唯一输入，cs-feat-impl按design的顺序实现，cs-feat-accept逐层对照design核对实现。

AGE模板中的plan不是roadmap，也不是feature design。大需求的拆分在AGE模板中通常分布在docs/requirements/、docs/design/、docs/architecture/、docs/backlog/和必要时使用的docs/plans/里，而不是一个单独的roadmap文件。docs/plans/00-plan-authoring-and-execution-guide.md在开头就定义得很窄：

它只在非平凡工作时才被触发：比如API、数据库/模型、auth、integration、public contract、多模块共享行为、多session、超过大约5个文件或200行、需要分阶段实现或显式proof的情况；AGENTS.md还把不能藏在chat里的未解决产品/技术风险列为planning trigger。模板同时明确允许低风险的本地修改跳过正式的plan。

AGE plan的关键不是“计划得更详细”，而是closure语义：

• 必须从live baseline开始，不能依赖记忆或旧计划
• 必须写Goals/Non-Goals，防止scope drift
• execution item必须标记Fix | Add | Decision | Proof | Follow-up
• 确认的live defect或contract drift必须是Fix，不能降级为Follow-up
• skill usage要写明，但skill选择方法，不决定business truth
• 在closure之前，所有checklist和closure gates必须一致
• 创建好的plan必须经过独立的plan audit，完成前必须经过独立的closure audit
• source-of-truth冲突或受保护的风险需要human/subagent review，或者保持open状态

这和CodeStable的design → impl → accept链条完全不同。CodeStable的验收重点是“实现是否符合design”。而AGE plan的闭合重点是“这一轮执行是否真的在live repo中满足了closure criteria，并且没有把in-scope的缺陷偷偷降级”。

两者都有轻量路径，但表达方式不同。CodeStable直接提供cs-feat-ff和cs-refactor-ff这类轻量级的bypass skill；AGE模板则通过planning triggers和“No plan”条件，限定低风险的本地改动可以跳过formal plan。

六、人的位置：人在环 workflow vs repo-governed autonomy

CodeStable明确称自己为：

并说：

这不是偶然的措辞。CodeStable的流程呈现方式就是人通过/cs-*入口来驱动工作：整理需求、规划roadmap、设计feature、实现、验收、报告issue、分析根因、修复、沉淀知识。

AGE不等于“无人自动开发”。AGE的人机边界更细：人类的判断优先放在attractor定义、方向裁决、受保护风险和source-of-truth冲突上；plan/closure则要求独立的reviewer或subagent进行审计；细粒度的实现可以更多地交给AI，但必须受到repo truth、owner docs、plan gates、verification和independent audit的约束。

AGE的文章说：

AGE模板的docs/context/ai-autonomy-policy.md定义了autonomy labels；backlog/README.md把这些label应用到具体的工作项上：implement、plan-first、ask-first、research-only、blocked。它还规定AI可以把过时的行降级，但不能自行升级为ready或清除blocker：

所以，准确的区别不是“CodeStable有人，AGE没人”，而是：CodeStable把人放在workflow driver的位置上；AGE则把人类的裁决和AI的自主边界写进了repo的状态与audit gates里。

七、知识反馈：compound 复用库 vs authority-preserving memory topology

CodeStable的知识沉淀集中在compound/：

它的飞轮是：

也就是说，CodeStable把learning、trick、decision、explore放入一个可搜索的复用库，再由后续的skill去读取。

AGE的memory则不是把所有经验都塞进一个目录，而是按照authority和timeliness拆分开：

• owner docs保存当前baseline，不保存逐步历史
• logs保存带日期的implementation memory
• bugs保存非显而易见的回归历史和根因
• audits保存挑战过程和审计证据
• testing保存手工或探索性的证明
• lessons保存可复用的工程经验
• skills保存可复用的prompt/review playbook

AGE模板还定义了经验升级的路径。AGENTS.md说，当同类错误反复出现时，不要只写一段prose lesson：先把它提升成audit prompt、checklist、review playbook；如果仍然复发，再评估是否需要写成heuristic script、static check、lint rule、CI guard、codemod。

这比“记下来下次读”多了一层控制升级的逻辑。CodeStable的compound主要是跨工作流的复用库；AGE的memory topology则同时维护了当前真相、过程证据、复盘经验和可自动化guardrail的升级路径。

八、架构文档：当前结构档案 vs attractor carrier

CodeStable把architecture放在了长效档案层：

AGE也要求owner docs描述当前支持的baseline，而不是历史。但AGE额外强调，这些owner docs是attractor的工程载体：它们不只是记录现在长什么样，还定义了系统应向哪里收敛。

AGE的文章给出了分层裁决：

这就是区别所在：CodeStable README中的architecture更像一份当前结构的档案；AGE中的design/architecture owner docs是稳定的owner truth，同时也是attractor carrier。两者都反对把历史过程塞进架构文档，但AGE把“当前baseline + source-of-truth precedence + convergence direction”放在同一个owner-doc系统里。

九、工程判断：哪个更好

如果问题是“一个普通项目，今天怎样快速获得AI编码的纪律”，那么CodeStable更直接。它把入口、目录、流程、验收和知识沉淀都包装好了，程序员可以从/cs开始，把AI工作纳入需求、设计、实现、验收、问题修复和复盘的链条。它解决的是AI coding从“chat improvisation”进入“managed workflow”的问题。

但如果问题是“一个长期系统，在AI高强度参与后，怎样保持结构不漂移”，那么AGE更强。它不把核心能力放在某个skill是否聪明上，而是放在owner truth、事实源优先级、时效分层、plan closure、独立审计和人机裁决边界上。它解决的是多轮变更之后，仓库是否仍能维持可证明的方向感和结构收敛。

打个比方：CodeStable更像是可安装的生命周期工作台；AGE则更像是repo级别的收敛治理协议。想要短期提升AI编码的可控性，CodeStable的收益更快；但要是应对长期复杂的领域和多agent变更，AGE的结构安全边界更深。

十、结论

CodeStable和AGE都反对把AI开发只理解为“让agent更会写代码”。但它们解决的问题确实不同。

CodeStable是一个打包好的workflow。它的README列出了22个skill，实际目录还包含若干辅助/扩展skill；它用这些/cs-*入口和codestable/制品树，把需求、架构、roadmap、feature、issue、refactor、compound串成了一个可执行的生命周期。它的优势是即装即用、入口明确，很适合让程序员以人在环的方式管理AI编码过程。

AGE则是一个repo级别的治理/收敛框架。它首先建立source-of-truth routing、稳定的owner docs、带日期的过程证据、backlog readiness、plan closure、audit independence和skill-as-method的关系，然后再让AI在这个拓扑中执行。它的docs/skills/不是没有价值，而是被明确限制为审计、诊断、复盘、重构等可复用的方法。AGE的优势不是把生命周期动作都包装成更多的skill，而是让仓库在多轮AI扰动后，依然知道：什么是当前真相，谁拥有它，怎么证明它，什么时候必须停下来审计或去问人。

压缩成一句话：CodeStable解决的是“让AI编码变得可管理”，而AGE解决的是“让AI编码后的仓库依然可治理”。

来源：互联网