你的代理上下文需要一个开发生命周期：CDLC 框架

技能、代理配置、提示词指令和规则文件——这些工件现在决定了你的编码代理产出什么。它们塑造代理写的每一行代码，但没有人像对待代码那样对待它们。团队写好一个技能、提交到仓库，就再也不测试它在模型更新后是否仍然有效；代理配置被跨团队复制粘贴而不做版本管理；规则文件与它们描述的代码库逐渐脱节。出问题时，信号是一个开发者注意到奇怪的输出然后在 Slack 上抱怨。问题来了：如果上下文是新的代码，它的软件开发生命周期是什么？

1. CDLC：把上下文当作代码

Patrick 提出了一个框架来回答缺失的部分：上下文开发生命周期（CDLC）。CDLC 不是关于上下文窗口管理或往提示词里塞更多 token，而是关于管理进入上下文窗口的各部分的质量。一个技能是最新的吗？模型真的正确响应它吗？你是不是在提供模型已经知道的上下文？CDLC 有四个阶段，直接映射到我们写代码时已经在做的事：生成（Generate）是写技能、构建提示配置、设置代理规则——相当于写代码，也是今天花费大部分时间的地方；评估（Evaluate）是测试——检查 front matter 的 lint 是否正确、语法是否过长，高级做法是跑场景：加载技能、问特定问题、检查代理是否产出预期结果；分发（Distribute）是发布——最基础是提交到仓库，成熟做法是发布到带版本、可发现性和访问控制的可安装注册表；观察（Observe）是生产监控——技能是否被使用、是否产出正确结果、开发者介入前代理跑了几轮。

// The CDLC framework: if context is the new code, it
// needs a software development lifecycle. Four phases map
// directly onto what we already do with code.
const CDLC = {
  "generate": "write skills, prompt configs, agent rules",
  "evaluate": "test: scenario runs, trigger words, model
                versions, token waste",
  "distribute": "ship: commit to repo -> installable registry
                 with versioning and access controls",
  "observe": "monitor: usage, results, interventions, overrides"
};
// Maturity curve mirrors software engineering: teams
// generate and distribute first, skip evaluation, ship to
// production, and wait to see what happens.

2. 为什么团队会跳过评估

成熟度曲线与过去二十年软件开发实践完全相同：组织先生成和分发，完全跳过评估，把技能发布到生产（也就是使用它们的开发者那里），然后等着看会发生什么。这就像团队跳过测试驱动开发：他们不知道痛点，所以直接上生产。痛点到来时是这样的：一个技能在一个模型版本上工作，在下一个版本上就坏了；或者它在错误的问题上触发，给开发者自信但错误的指令；或者技能强制执行的约定六个月前是对的，但代码库已经变了。这些正是未测试代码的失败模式：回归、误报、过时假设。

// A TDD loop for context: write the skill, write the
// scenario, check the output, iterate. This scenario test
// loads a skill, asks a specific question, and verifies
// the agent produces the expected result.
async function testSkill(skillName, question, expected) {
  const skill = await loadSkill(skillName);
  const output = await runAgent({ skill, question });
  const pass = output.includes(expected);
  await recordResult({ skillName, question, pass });
  return { skillName, pass, output: output.slice(0, 120) };
}
// Test across models and versions. Check whether you are
// writing in context the model already knows (token waste).
// Verify the skill activates on the right trigger words.

3. 两个新指标：人工介入率与复用乘数

Patrick 用两个位于传统 DORA 指标之上的指标来框定扩展问题。第一个是人工介入率（human touch）：在给定代理工作流中，开发者需要多久介入一次？每次介入都是上下文缺失或错误的信号。减少人工介入点直接衡量你的 agentic 编码循环到底有多自治，而且往往与成本相关，因为更多轮次意味着更多代理支出。第二个是复用乘数（reuse multiplier）：改进一个技能让多少开发者受益？如果一个开发者修复了一个技能，只有他自己受益，那是 1x；如果修复进入共享注册表，50 个开发者拿到它，那是 50x。优化自己代理循环的开发者能获得更好的个人结果，但改进只属于他自己：修复技能时没人受益，发现失败模式时没人学习。ROI 是 1x。

// Distribution maturity: pasting a skill into Slack is
// not distribution, the same way emailing a .jar file is
// not dependency management. A registry gives you
// versioning, discoverability, and access controls.
{
  "registry": {
    "skills": [
      { "name": "refactor-early-returns", "version": "2.3.1",
        "models": ["claude-sonnet-5", "gpt-5.6-terra"],
        "triggers": ["refactor", "early return"],
        "owner": "platform-team" }
    ],
    "publish": "git push -> CI validates scenarios -> tag",
    "install": "agent picks latest compatible version"
  }
}
// When one developer fixes a skill, the fix goes into the
// shared registry and 50 developers get it -- that is the
// reuse multiplier in action.

4. 不变式与 AI slop 登记册

每个代码库都有 AI 持续搞错的模式：约定失明、幻觉 API、cargo-cult 代码、过度设计。在 Aviator，这些被称为不变式（Invariants），或者叫 AI slop 登记册。技能注册表和 AI slop 登记册体现了开发生命周期两端同样的底层原则：把工程标准编目并喂给代理。代码生成之前，那就是技能；代码审查时，它是 AI 在你代码库中持续搞错的模式目录。slop 登记册为自动化检查提供信息，捕捉漏网之鱼。「你无法通过让人类更仔细地审查来扩展代码质量。你要通过投资于在两端固化标准的护栏来扩展它。」

5. 代码实战：测试、注册表与追踪

本文的代码块把框架拆开：代码块一是 CDLC 四阶段——生成、评估、分发、观察；代码块二是上下文的 TDD 循环——写技能、写场景、检查输出、迭代，跨模型和版本测试；代码块三是分发成熟度——从提交到仓库到带版本、可发现性和访问控制的注册表；代码块四是人工介入追踪——记录工作流、介入前轮数、原因和时间戳；代码块五是复用乘数计算——修复进入共享注册表时，受益开发者数量就是乘数。

// Human touch: how often does a developer need to
// intervene in a given agent workflow? Every intervention
// is a signal that context is missing or wrong.
async function trackIntervention(run) {
  return {
    workflow: run.workflow,
    turnsBeforeIntervention: run.turns,
    reason: run.reason,       // wrong output | missing context
    correctedBy: run.developer,
    timestamp: new Date().toISOString(),
  };
}
// Reducing human touchpoints is a direct measure of how
// autonomous your agentic coding loop actually is -- and
// it correlates with cost, since more turns mean more
// agent spend.

6. 行动建议

把上下文当成一等工程工件。第一步：为你的技能和规则文件建立仓库与版本控制，哪怕只是简单的 git tag。第二步：为最高频的三个技能写场景测试，让它们在每次模型升级时自动跑。第三步：给每个代理工作流加一个人工介入计数器，把它当作自治性的北极星指标。第四步：把开发者发现的失败模式编入 AI slop 登记册，让检查自动化。规模化的关键不是让人类更努力，而是把标准固化进护栏，让每次改进都通过注册表复利到整个组织。

// The reuse multiplier: how many developers benefit when
// you improve a single skill? If one developer fixes a
// skill and only they benefit, that is 1x. If the fix goes
// into a shared registry and 50 developers get it, 50x.
function reuseMultiplier(fix) {
  const affected = registry.consumersOf(fix.skill);
  const solo = fix.keptLocally ? 1 : affected.length;
  return { skill: fix.skill, multiplier: solo };
}
// The failure modes are the same as untested code:
// regressions, false positives, stale assumptions. A skill
// works on one model version but breaks on the next, or
// triggers on the wrong question and gives a developer
// confidently wrong instructions.