企业官网建设流程全解析

Caveman Native Core 详解：一份 560 Token 的 Agent 编码策略如何被编译、预算约束与多宿主分发

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman

本文以 skills/native-core.md 为主体，逐段解读这份 Caveman 项目中的"原生核心"（Native Core）工程策略——它是一份以极简 token 预算（560 token 上限）编写的强制性默认编码准则，在 Claude Code、Codex、Gemini、Hermes、OpenCode、Aider 等宿主 Agent 中作为系统级默认策略生效。读完后你能完整理解这份策略的五级决策阶梯、安全豁免边界与最小证明纪律，以及它在 skills/registry.json、skills/compile.mjs 中如何被校验、编译并分发给各宿主（含 token 预算的硬性闸门与任务类型到技能的 fail-closed 选择机制）。

Native Core 是什么：一份"最高优先级默认值"

Native Core 是整个 Caveman 技能体系中最底层的一份工程策略文本，全文仅 16 行英文指令，却是所有"native 交付"技能的强制底座。它的定位可以从 skills/registry.json 的native_pack元数据中直接确认：

{ "native_pack": { "id": "caveman-local", "version": "2.2.0", "protocol": 1, "core_source": "native-core.md", "core_prompt_token_budget": 560, "targets": ["claude", "codex", "hermes", "gemini", "opencode", "aider"] } }

其中三个字段定义了 Core 的身份：core_source指向唯一的权威来源文件（skills/native-core.md，且 skills/compile.mjs 明确禁止该字段包含路径分隔符，防止指向仓库其他位置）；core_prompt_token_budget: 560是 token 预算上限；targets枚举了六个宿主。编译产物中 Core 被标记为mandatory: true（见 skills/generated/claude/pack.json 的core.mandatory字段），意味着它不是可选项——宿主注入任务技能时，Core 必须先行在场。

Native Core 与 Caveman 的其他技能（如caveman输出压缩、caveman-explore只读探索等 CLI 交付技能）是两套并行的交付通道：前者走delivery: ["cli"]，经agent-skills.generated.ts进入 CLI；后者走delivery: ["native"]，经 native pack 进入各 Agent 宿主的钩子系统。本文聚焦后者，且只以 native-core.md 的内容为核心。

策略全文：16 行文本的逐段解读

下面给出 skills/native-core.md 的完整原文（与编译产物 skills/generated/claude/pack.json 中core.instructions逐字节一致，可交叉验证）：

Build simplest complete system. Trace behavior and invariants before editing. System, user, and repository instructions outrank this default. Consider in order; accept first with correctness and architectural fit without distortion: 1. Required behavior already exists: reuse it or change nothing. 2. Responsible layer, type, helper, or pattern owns it: extend there. 3. Standard library, native platform, browser, database, runtime, or installed dependency owns it: use it. 4. Small new implementation fits current architecture: build where invariant belongs. 5. Existing structure obstructs clear ownership: make coherent refactor task needs. Optimize total system complexity, clarity, and ownership—not lines or files changed. Coherent wider change beats cramped patch, duplicated guard, or misplaced logic. Reuse fitting abstractions; do not contort code to avoid abstraction. Prefer consolidation. Fix root cause. Avoid speculative features and extension points, single-implementation interfaces, configuration for fixed values, premature services, and imagined scaffolding. Dependency or public surface is valid for correct design or lower lifecycle cost; explain material tradeoff. Simplicity never removes trust-boundary validation, authorization, security,>const coreEstimatedTokens = Math.ceil(Buffer.byteLength(nativeCore) / 3); if (coreEstimatedTokens > nativePackMeta.core_prompt_token_budget) { die(`native Core exceeds conservative token estimate: ${coreEstimatedTokens} > ${nativePackMeta.core_prompt_token_budget}`); }

估算基础是ceil(utf8_bytes / 3)（即 3 字节 ≈ 1 token 的保守换算，编译产物中该口径被显式记录为estimate_basis: "ceil_utf8_bytes_divided_by_3"）。当前 skills/native-core.md 全文约 1668 字节，估算约 556 token，低于 560 的预算上限（skills/generated/claude/pack.json 中estimated_tokens: 556与prompt_token_budget: 560可以查证）。一旦有人修改 Core 文本使其超出预算，die()会直接让编译失败——这是 fail-closed 设计：预算超支的 Core 绝不会被分发。

加载期闸门在 Go 侧的 proxy/internal/nativepack/pack.go。native pack 的 JSON 被//go:embed内嵌进二进制（pack.go），validate在Load()的sync.Once内对运行时副本做同构校验：

if !pack.Core.Mandatory || pack.Core.Instructions == "" || pack.Core.EstimatedTokens > pack.Core.PromptTokenBudget { return errors.New("native pack: invalid Core budget or instructions") }

即 Core 必须为强制项、指令非空、且估算 token 不超预算——与编译期完全相同的三条约束在运行时再验一遍。测试用例 proxy/internal/nativepack/pack_test.go 固化了这组不变量。

这种"双闸门"的意义在于：即使有人绕过编译直接手改生成的 JSON（生成文件头部都标有GENERATED ... DO NOT EDIT），运行时也会拒绝加载。对 Agent 策略这类"每次会话都进上下文"的内容，token 预算就是硬成本，治理必须到可执行的程度。

编译与多宿主分发：从单一 Markdown 到六个宿主的钩子

skills/compile.mjs 是整个 native 交付链的单一入口，其流程为：校验registry.json→ 读取 Core 与每个 native 技能的 SKILL.md 正文 → 通过 skills-verbs 门（技能不得引用不存在的 CLI 命令/MCP 工具/SDK 调用，见 compile.mjs）→ 输出四路产物。与 Native Core 相关的产物路径如下：

编译产物中，Core 与任务技能被组装为caveman.native-pack.v1schema（compile.mjs），其中core块携带source、mandatory、prompt_token_budget、estimated_tokens、estimate_basis与完整指令文本。

真正的"多宿主"差异体现在targets的激活钩子映射上。skills/compile.mjs 为每个宿主硬编码了 Core 与任务技能各自的注入时机，编译结果（以 skills/generated/claude/pack.json 为准）：

从这张映射可以看出 Core 的分发策略：在每个宿主中，Core 都选择会话最早、最贴近系统提示层的位置注入（SessionStart、developer_instructions、pre_llm_call 等），确保它在任何任务技能之前进入上下文；而任务技能则在用户提交提示时按分类结果注入。Aider 的注入方式最为特殊——从 packages/cli/src/index.ts 可以看到，Aider 的 Core 文本被包在一个带标记的块中写入其约定文件：

const AIDER_NATIVE_CORE_MARKER = "<!-- caveman:native-aider-core -->"; // ... return `${AIDER_NATIVE_CORE_MARKER}\n${NATIVE_CORE}\n\nHost limits: Aider repository map remains authoritative. ...`;

该标记同时用于回读时判断"当前文件中的 Core 是否由 Caveman 拥有"（index.ts），避免覆盖用户对约定文件的自行修改。另外 CLI 还暴露了think.core配置开关（index.ts 的提示文本给出了caveman tools config set think.core off的用法），允许用户在静态启用的 Core 上整体开/关，且提示"start new session to clear delivered context"——即已注入的上下文需要新会话才会清除。这印证了 Core 的定位：它是默认开启的策略基线，用户可以显式退出。

Native Core 与六个任务技能：分类、优先级与 fail-closed 选择

Native Core 从不单独行动，它与六个delivery: ["native"]的任务技能组成完整策略包。这六个技能都在 skills/registry.json 中登记，其元数据被编译进各宿主 pack（示例见 skills/generated/claude/pack.json 的skills数组）：

每个 native 技能元数据都要求activation: "classified"，即注入前提是宿主先对任务做了分类（compile.mjs 对非 classified 激活直接拒绝，见 skills/compile.mjs），并且指令正文的字节数不得超过prompt_byte_budget（skills/compile.mjs）。Core 与技能之间是明确的分层：lean-build的指令开篇即写"Native Core's architecture-first simplicity remains mandatory"，护栏里也把core_architecture_first_simplicity放在第一位——Core 是基线，技能是基线之上的任务特化。

运行时如何选择技能？proxy/internal/nativepack/pack.go 的Select(taskType)按 task_type 匹配并在多个候选中取最高precedence（当前六个技能均为 100，因为编译期要求同一 task_type 下的冲突对必须互报 conflicts 且 precedence 不同——目前每个 task_type 只有唯一属主，约束为未来扩展预留）。关键是它的 fail-closed 行为：无法匹配的 task_type 返回(Skill{}, false)，调用方落回 Core。这一点被测试固化：

if _, ok := Select("review"); ok { t.Fatal("unowned task type must fail closed to Core") }

（proxy/internal/nativepack/pack_test.go。）也就是说，分类失败时系统不会注入任何技能、也不会报错阻塞，而是"只有 Core 在场"——Core 因此必须自身构成一份完整可执行的策略，这正是它 16 行内覆盖决策、优化、安全与验收四个维度而不依赖任何技能的原因。

对 Agent 行为的实际约束：一条可验证的因果链

把以上证据串起来，Native Core 在 Caveman 中的完整因果链是：

1. 单一来源：skills/native-core.md 是唯一权威文本，skills/registry.json 的core_source字段指认它，编译器拒绝其他来源（路径校验，compile.mjs）。
2. 预算闸门：编译期按ceil(bytes/3)估算并与 560 对比，超限即编译失败；运行时 Go 侧再验一遍（pack.go）。
3. 编译分发：Core 文本连同六个任务技能、目标钩子映射一起被编译进 CLI 的 TypeScript 嵌入、Go 的 embed JSON 与六个宿主的 pack.json，CLI 与代理都"不手抄提示词"（skills/compile.mjs 文件头注释）。
4. 运行时注入：按各宿主的激活钩子在会话最早期注入 Core，任务技能按 classified 分类注入，未分类的任务 fail-closed 落回 Core。
5. 策略内容：五级阶梯压低"写新代码"的优先级，反投机清单约束抽象膨胀，安全豁免段保住十一类工程控制，最小证明条款定义验收与汇报边界。

从源码结构看，这套设计把"希望 Agent 怎么写代码"从一个模糊的价值观问题，转化成了三个可机械验证的契约：token 预算不超（数字比较）、schema 与冲突规则成立（validate）、预算与行为测试通过（pack_test.go）。策略文本本身只允许在预算内演化，任何扩写都必须先通过编译闸门。

相关路径索引

• 策略权威来源：skills/native-core.md
• 登记与预算元数据：skills/registry.json
• 编译器（校验 + 产物生成）：skills/compile.mjs
• 各宿主编译产物：skills/generated/claude/pack.json、skills/generated/codex/pack.json、skills/generated/gemini/pack.json、skills/generated/hermes/pack.json、skills/generated/opencode/pack.json、skills/generated/aider/pack.json
• CLI 侧嵌入与注入：packages/cli/src/native-pack.generated.ts、packages/cli/src/index.ts（Aider 标记块见 L7026 附近）
• 代理侧加载与选择：proxy/internal/nativepack/pack.go、proxy/internal/nativepack/pack_test.go、proxy/internal/nativepack/native-pack.generated.json

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman