From e22cb57718e0514783534e744a36b28b61d12554 Mon Sep 17 00:00:00 2001 From: cjp Date: Mon, 23 Mar 2026 13:41:59 +0800 Subject: [PATCH] docs(zh-CN): add prune command translation --- docs/project-overview.zh-CN.md | 391 --------------------------------- docs/zh-CN/commands/prune.md | 31 +++ 2 files changed, 31 insertions(+), 391 deletions(-) delete mode 100644 docs/project-overview.zh-CN.md create mode 100644 docs/zh-CN/commands/prune.md diff --git a/docs/project-overview.zh-CN.md b/docs/project-overview.zh-CN.md deleted file mode 100644 index 9023f445..00000000 --- a/docs/project-overview.zh-CN.md +++ /dev/null @@ -1,391 +0,0 @@ -# Everything Claude Code 项目分析 - -## 项目定位 - -这个仓库本质上不是一个“业务应用”，而是一套给 AI 编码代理使用的“工程化运行时 + 能力分发包”。它把提示词、子代理定义、技能库、命令库、hooks、规则、安装器、状态管理、测试与跨平台适配整合在一起，目标是把 Claude Code、Codex、Cursor、OpenCode 这类 agent harness 调教成更稳定、更可控、更像资深工程师的工作流系统。 - -从仓库里的实际内容看，它当前是一个成熟的产品化分发仓库，而不是零散配置集合：有 `25` 个 agents、`57` 个 commands、`108` 个 skills、完整的 hook runtime、选择性安装 manifest、CLI、SQLite 状态查询命令，以及测试与校验链。核心说明在 [README.md](../README.md)、[package.json](../package.json)、[AGENTS.md](../AGENTS.md)。 - -## 它到底在做什么 - -它做的事可以概括成 5 层： - -### 1. 规则层 - -把团队/个人想让 AI 始终遵守的工程规范固化下来，比如 TDD、80% 覆盖率、安全检查、immutability、Git 工作流、性能与上下文管理。这部分在 `rules/` 下面，按 `common + language packs` 组织。 - -### 2. 能力层 - -把不同任务拆成可复用能力单元。 - -- `agents/` 是“角色型子代理”，例如 planner、architect、security-reviewer、code-reviewer、build-error-resolver。 -- `skills/` 是“方法论/领域知识包”，例如 TDD、verification-loop、frontend-patterns、market-research、deep-research、security-review、frontend-slides、x-api 等。 - -### 3. 交互层 - -把常用工作流做成斜杠命令。比如 `/plan`、`/tdd`、`/code-review`、`/verify`、`/quality-gate`、`/loop-start`、`/model-route`、`/sessions`、`/harness-audit`。这部分在 `commands/`。 - -### 4. 自动化运行时 - -通过 hooks 在会话开始、编辑文件、运行命令、会话结束等时机自动触发行为，例如： - -- 加载上下文 -- 保存 session -- 建议 compact -- 格式化代码 -- TypeScript 检查 -- `console.log` 检查 -- 质量门禁 -- 成本跟踪 -- 从会话中提取可学习模式 - -配置在 `hooks/hooks.json`，实现主要在 `scripts/hooks/`。 - -### 5. 安装与适配层 - -它不是只服务 Claude Code，而是做了多平台适配： - -- `.claude-plugin/` 面向 Claude Code 插件 -- `.codex/` 面向 Codex -- `.cursor/` 面向 Cursor -- `.opencode/` 面向 OpenCode - -安装不是硬编码复制，而是 manifest 驱动的 profile/module/component 选择性安装，见： - -- `manifests/install-profiles.json` -- `manifests/install-components.json` -- `manifests/install-modules.json` - -## 主要功能 - -按功能看，这个项目覆盖面非常广： - -- `工程开发工作流` - 规划、TDD、代码评审、构建修复、E2E、覆盖率、重构清理、文档更新、质量门禁。 -- `多语言支持` - TypeScript、Python、Go、Java、Kotlin、Rust、Perl、PHP、Swift、C++ 等都有规则或技能包。 -- `安全能力` - 安全 reviewer、security-review skill、安全扫描、输入校验、secret 管理、提交前检查。 -- `上下文与记忆管理` - SessionStart/Stop hooks、pre-compact、strategic compact、持续学习、instinct import/export/evolve。 -- `多代理编排` - worktree/tmux orchestration、multi-plan、multi-execute、loop-start、loop-status、PM2 工作流。 -- `研究与内容能力` - deep-research、market-research、article-writing、investor-materials、investor-outreach、crosspost、x-api。 -- `媒体与文档能力` - frontend-slides、fal-ai-media、video-editing、visa-doc-translate、document-processing 类技能。 -- `运行状态与诊断` - `ecc` CLI 支持 `install/plan/list-installed/doctor/repair/status/sessions/session-inspect/uninstall`。 - -## 这个仓库的实际架构 - -你可以把它理解成下面这条链路： - -用户请求 -→ 命令或 AGENTS 指令触发 -→ 选择合适 agent / skill / rule -→ hooks 在关键时机做自动检查与状态保存 -→ scripts 负责真正执行安装、审计、诊断、状态查询 -→ 不同平台目录把同一套能力映射到 Claude / Codex / Cursor / OpenCode - -这也是为什么它看起来像“文档很多”，但其实不是文档仓库。Markdown 只是配置载体，真正的产品能力来自： - -- 结构化规则 -- 可组合技能 -- 自动化 hooks -- 安装与运行时脚本 -- 测试和校验链 - -## 最值得注意的几个特点 - -- 它强调“agent-first”，不是单 agent 直接硬做，而是主动委派给 planner、reviewer、security-reviewer 等角色。 -- 它强调“research-first”和“verification-first”，不是只生成代码，还要求验证、评审、学习、沉淀。 -- 它已经从 Claude Code 配置包，演化成“AI agent harness performance system”。 -- 它支持“按需安装”，不是所有用户都要装全量能力。 -- 它把“经验”产品化了：把作者长期使用中总结的流程，固化成规则、命令、hook 和技能。 - -## 适合什么人用 - -最适合这几类人： - -- 想把 Claude Code / Codex / Cursor 调成稳定工程助手的个人开发者 -- 想给团队统一 AI 编码规范和工作流的技术负责人 -- 需要多语言、多框架、多工具链支持的工程团队 -- 想做 AI agent orchestration、持续学习、自动质量门禁的人 - -## 一句话总结 - -这个项目是在做一套“给 AI 编码代理装上的工程操作系统”。它不是帮你开发某个业务功能，而是帮你把 AI 开发这件事本身标准化、自动化、可复用、可审计。 - -## AI 代码正确性保障与自动化测试 - -这个项目保证“AI 生成代码正确”的方式，不是靠某一个单点机制，而是靠一整套分层校验体系。核心思路是：先用规则约束 AI 的行为，再用 hooks 做即时检查，再用命令触发系统性验证，最后用测试和覆盖率把这些机制本身也测住。 - -先说结论：它并不能“数学上保证” AI 代码一定正确，但它把常见错误尽量前移、自动化、制度化了。也就是说，它主要保证的是“高概率正确 + 尽早暴露问题 + 可重复验证”，而不是一次生成就绝对无误。 - -### 一、它如何保证 AI 代码更靠谱 - -#### 1. 规则约束 - -仓库把 TDD 设成默认工作方式，明确要求先写测试，再写实现，再验证覆盖率，最低 80%。这不是建议，而是写进规则和 skill 的硬约束。也就是说，AI 理想状态下不是“先瞎写代码再补测试”，而是按 RED → GREEN → REFACTOR 的节奏工作。 - -#### 2. 任务分工 - -它鼓励把任务分给专门 agent，比如： - -- `tdd-guide` 负责测试优先 -- `code-reviewer` 负责改完后的质量检查 -- `security-reviewer` 负责敏感逻辑 -- `build-error-resolver` 负责构建和类型问题 - -这能降低一个 agent 同时负责“写代码、判断自己对不对、审查自己”的自我偏差。 - -#### 3. Hooks 即时纠偏 - -只要 AI 编辑文件，hooks 就会在后台做一些轻量但高频的自动检查，尽量在错误扩散前拦住。 - -#### 4. 人工触发的深度验证 - -比如 `/verify`、`/quality-gate`、`/test-coverage`、`/eval`，这些命令要求 AI 在关键节点主动跑构建、类型检查、lint、测试、覆盖率、安全扫描、差异审查。 - -#### 5. 项目自身也被测试 - -这个仓库不只是要求别人测试，它自己的 hook、安装器、manifest、命令和适配逻辑都有自动化测试和 CI 校验。 - -### 二、具体自动化机制有哪些 - -#### 1. TDD 机制 - -TDD 是第一道“正确性”防线。它要求： - -- 先写测试 -- 先运行并确认测试失败 -- 再写最小实现让测试通过 -- 再重构 -- 最后检查覆盖率是否达到 80%+ - -它强调三类测试都需要： - -- 单元测试：函数、组件、工具方法 -- 集成测试：API、数据库、服务交互 -- E2E 测试：关键用户路径 - -这意味着它不是只关心“代码能跑”，而是要求对行为、边界条件、错误路径都建立测试样例。 - -#### 2. 编辑后的自动 hook 检查 - -这是最接近“实时守门员”的部分。 - -- `post-edit-format` - 文件编辑后自动格式化 JS/TS，支持 Biome 或 Prettier。 -- `post-edit-typecheck` - 编辑 `.ts/.tsx` 后自动找最近的 `tsconfig.json`，跑 `tsc --noEmit`，并尽量只过滤出和当前文件相关的错误。 -- `quality-gate` - 编辑后跑轻量质量门禁。对不同语言用不同工具： - - JS/TS/JSON/MD 走 Biome 或 Prettier - - Go 走 `gofmt` - - Python 走 `ruff format` -- `check-console-log` - 每次响应结束时检查已修改的 JS/TS 文件里是否残留 `console.log`。 - -这一层解决的是“写完马上出问题”的场景，比如格式错、类型错、调试语句没删掉。 - -#### 3. 系统化验证命令 - -最核心的是 `/verify`。它要求按顺序做： - -1. Build Check -2. Type Check -3. Lint Check -4. Test Suite -5. Security / Secrets / `console.log` 审计 -6. Git diff 审查 - -这里的关键点不是“有这些命令”，而是顺序。比如 build 都不过，就不应该继续往下假装验证通过。 - -另外还有两个辅助命令： - -- `/quality-gate` - 按路径或项目范围手动执行质量管线，适合在 hook 之外主动检查。 -- `/test-coverage` - 专门做覆盖率分析，找出低于 80% 的文件，并按缺口补测试。 - -这说明它不把“测试通过”当成终点，还要求你看覆盖率盲区。 - -#### 4. Eval 机制 - -这是更偏 AI 工程的方法，不只是传统代码测试。 - -它引入几类概念： - -- `Capability eval` - AI 是否具备某个新能力 -- `Regression eval` - 新改动是否破坏旧行为 -- `pass@1 / pass@3 / pass^3` - 用来评估 AI 在多次尝试中的稳定性 - -这和普通单元测试不同。普通测试是“代码对不对”，eval 更像“AI 工作流整体是否稳定地产出对的结果”。 - -#### 5. 会话级持续学习与回放 - -这不是直接验证代码是否正确，但它能减少 AI 因“失忆”导致的错误重复。 - -- `session-start` - 会话开始时加载上次 session 摘要、已学习技能、项目类型等上下文。 -- `session-end` - 每次 Stop 时从 transcript 中提取用户请求、用过的工具、修改过的文件，写入 session 文件。 -- `evaluate-session` - 会话结束时判断这次对话里有没有可抽取的稳定模式，供后续沉淀成 skill。 - -这层对“正确性”的贡献是减少上下文断裂、避免同类错误反复出现。 - -### 三、这个仓库自己做了哪些自动化测试 - -这部分很关键。因为如果这些 hooks、命令、安装器本身不可靠，那整套“保障正确性”的系统就是空的。 - -当前仓库有 50+ 个测试文件，覆盖范围很广，测试类别大致分为： - -- `hooks 测试` - 覆盖 quality-gate、evaluate-session、auto-tmux-dev、hook flags 等行为。 -- `安装与配置测试` - 覆盖 install-plan、install-apply、manifest、install-state 等逻辑。 -- `CLI 和脚本测试` - 覆盖 `ecc`、`harness-audit`、`doctor`、`repair`、`session-inspect` 等命令。 -- `底层库测试` - 覆盖 formatter 解析、包管理器检测、项目类型识别、状态存储等基础能力。 -- `集成级测试` - 验证 hooks 和整体链路在组合情况下是否按预期工作。 - -### 四、除了业务测试，还有“结构正确性”校验 - -这个项目还有一类很实用的自动化：不是测业务逻辑，而是测仓库里的“配置资产”有没有坏掉。也就是 agents、commands、skills、rules、hooks 这些内容是否仍然有效。 - -`npm test` 里会先跑一串 validator，再跑测试，包括： - -- `validate-agents.js` - 检查 agent Markdown 是否有 frontmatter、必需字段、合法模型值。 -- `validate-commands.js` - 检查命令文档非空，以及引用的 command / agent / skill 是否存在。 -- `validate-rules.js` - 检查所有 rule 文件是否非空可读。 -- `validate-skills.js` - 检查每个技能目录是否有 `SKILL.md`。 -- `validate-hooks.js` - 检查 `hooks/hooks.json` 的 schema、事件名、matcher、hook 类型和字段是否合法。 - -这类测试很重要，因为 ECC 本身大量依赖 Markdown 和 JSON 配置文件。少一个字段、拼错一个 agent 名称，普通代码单测未必能及时发现，但 validator 能直接拦住。 - -### 五、覆盖率是怎么要求的 - -它明确要求 80%+ 覆盖率，这既出现在规则里，也出现在 npm 脚本里。 - -`package.json` 中的 `coverage` 脚本使用 `c8`，并设置了硬阈值： - -- lines 80 -- functions 80 -- branches 80 -- statements 80 - -也就是说，不是“跑个 coverage 看看”，而是没到门槛就失败。 - -### 六、它能保证“用户项目里的代码正确”到什么程度 - -这里要区分两件事： - -#### 1. ECC 仓库自身 - -它自己的 hooks、命令、安装器、适配层，是有自动化测试和覆盖率门槛的。 - -#### 2. 用户正在开发的业务项目 - -ECC 并不会天然知道你的业务逻辑是否正确。它做的是提供一套强制工作流，让 AI 去： - -- 先写测试 -- 跑构建、类型、lint、测试 -- 看 coverage -- 做 diff review -- 做安全检查 -- 必要时做 eval - -所以它对用户项目的保障，本质上是“把正确性验证流程自动化和制度化”，而不是“替代业务测试”。 - -换句话说，它更像质量系统，而不是万能判题器。 - -### 七、这套体系的优点和边界 - -优点很明确： - -- 错误暴露得更早，尤其是格式、类型、调试残留这种低级问题 -- AI 不容易跳过测试和验证步骤 -- 支持回归验证，不只是“这次能跑” -- 对复杂 agent 工作流有 eval 思维，不只盯着代码编译通过 -- 这个系统本身也被测试，不是空口宣言 - -但边界也很明确： - -- 它不能自动理解你的业务需求是否“真正满足用户意图” -- 没有业务测试数据时，它无法凭空证明正确性 -- 某些 hook 是“提醒/警告型”，不是强阻断 -- 很多质量检查依赖目标项目本身配置了 `build`、`lint`、`test`、`tsc`、formatter 等工具链 - -### 一句话总结 - -这个项目保证 AI 代码“更正确”的核心，不是靠单次生成更聪明，而是靠“测试优先 + 编辑后即时检查 + 提交前系统验证 + 覆盖率门槛 + eval + 仓库自身被充分测试”的组合拳。 - -## 自动化测试与验证方法总表 - -下表汇总了这个项目中主要的自动化测试与验证方法。这里的“测试”不仅包括传统单元测试，也包括构建检查、类型检查、质量门禁、配置校验、回归评估等自动化验证手段，因为 ECC 的目标本来就不是只测代码函数，而是保障整套 AI 工程流程的正确性。 - -| 什么测试 | 测试的方法 | 为什么要做这个测试 | 能解决什么问题 | -|---|---|---|---| -| 单元测试 | 对单个函数、工具方法、组件逻辑编写独立测试，用最小输入输出断言行为 | 最小粒度验证功能正确性，是发现逻辑错误最快的手段 | 解决函数实现错误、边界条件遗漏、重构后回归问题 | -| 集成测试 | 测 API、数据库、服务交互、模块间协作，验证请求到响应或服务到服务的完整链路 | 很多错误不在单个函数，而在模块之间的拼接处 | 解决接口联调失败、数据库交互错误、服务调用顺序问题 | -| E2E 测试 | 用 Playwright 等浏览器自动化测试关键用户流程 | 最终用户看到的是完整流程，不是单个函数 | 解决页面流程跑不通、按钮可点但业务不成功、前后端联通失败 | -| TDD 红绿重构测试 | 先写失败测试，再写最小实现让其通过，最后重构并保持测试为绿 | 强制 AI 先定义正确行为，再写实现，降低拍脑袋写代码的概率 | 解决“先写代码后补测试”导致的伪验证、需求理解偏差 | -| Build Check | 执行项目构建命令，先确认能完整 build | 如果项目连构建都过不了，其他验证意义很小 | 解决打包失败、缺依赖、构建配置错误、语法级阻断问题 | -| Type Check | 执行 `tsc --noEmit`、`pyright` 等类型检查 | AI 很容易写出语法正确但类型不一致的代码 | 解决类型不匹配、参数传错、返回值不符合约定的问题 | -| Lint Check | 执行 ESLint、Ruff 等静态检查 | 代码不仅要能跑，还要符合项目约定和最佳实践 | 解决潜在坏味道、危险写法、风格不一致、简单逻辑疏漏 | -| 覆盖率检查 | 用 `c8`、Vitest/Jest 覆盖率、pytest-cov 等统计并设置 80% 门槛 | 测试通过不等于测得充分，需要知道哪些代码根本没被触达 | 解决测试盲区、分支未覆盖、表面通过但风险仍高的问题 | -| `/verify` 全量验证 | 按固定顺序执行 build、types、lint、tests、安全检查、diff review | 需要一个统一、可复用的“提交前体检流程” | 解决只做局部检查、漏掉关键验证步骤的问题 | -| `/quality-gate` 质量门禁 | 对文件或项目范围手动执行格式、lint、类型等质量检查 | hook 是自动触发的，但需要人工随时重跑统一质量管线 | 解决改动较多时遗漏局部错误、需要集中复查的问题 | -| `/test-coverage` 覆盖率补强 | 分析低覆盖文件，定位缺失测试并补齐 | 覆盖率不足时，仅看总体数字不够，需要知道缺口在哪 | 解决“知道不够测，但不知道该补哪”的问题 | -| `/eval` 能力/回归评估 | 定义 capability eval 和 regression eval，并记录 pass@k | AI 工程中很多问题不是普通单测能完全表达的 | 解决 prompt/agent 变化后的能力退化、稳定性不足问题 | -| Capability Eval | 为一个新能力定义成功标准并自动检查是否达成 | AI 需要被验证“会不会做这件事”，而不只是“代码能不能跑” | 解决新增能力不可度量、结果模糊、是否达标难判断的问题 | -| Regression Eval | 为已有能力定义基线，更新后重新验证 | 新功能上线最常见的风险是破坏旧功能 | 解决历史行为被破坏、升级后退化、版本回归问题 | -| pass@k / pass^k 评估 | 多次尝试统计成功率和稳定性 | AI 输出存在波动，单次成功不能说明真正可靠 | 解决“偶尔成功但不稳定”的假可靠问题 | -| 编辑后自动格式化 | `post-edit-format` 在文件编辑后自动运行 Biome/Prettier | 很多低级问题不该等到人工发现 | 解决格式漂移、代码风格不统一、格式导致的 review 噪音 | -| 编辑后自动类型检查 | `post-edit-typecheck` 在编辑 TS 文件后自动执行局部类型检查 | 越早看到类型错误，修复成本越低 | 解决刚编辑完就引入的类型错误，避免后续扩散 | -| 编辑后自动质量门禁 | `quality-gate` 按文件类型执行 Biome/Prettier/gofmt/ruff | 需要低延迟的自动化守门，尽快把错误暴露给 AI | 解决语言级格式/质量问题，减少提交前集中爆炸 | -| `console.log` 审计 | Stop hook 自动扫描修改文件中的调试输出 | AI 和人类一样，都会忘删临时调试代码 | 解决调试日志残留、噪音输出、生产代码不干净的问题 | -| 安全扫描 | 搜索 secrets、危险模式，必要时配合安全 skill / reviewer | AI 生成代码时常会忽视 secrets、输入验证等安全问题 | 解决密钥泄漏、明显安全疏漏、调试信息暴露问题 | -| Git diff 审查 | 自动查看变更文件和 diff 范围 | 仅看最终代码不够，需要知道到底改了什么 | 解决误改文件、无关改动混入、遗漏清理的问题 | -| Session Start / End 验证链 | 会话开始加载上下文，会话结束提取摘要、记录变更和工具使用 | AI 的错误很多来自上下文断裂，而不是实现能力本身 | 解决跨会话失忆、重复犯错、接手历史任务时上下文缺失 | -| 持续学习评估 | `evaluate-session` 根据会话长度和内容判断是否可提炼模式 | 好的解决方案应沉淀成可复用能力，而不是每次重学 | 解决经验无法积累、同类问题重复探索的问题 | -| Hook 配置校验 | `validate-hooks.js` 校验 `hooks.json` schema、事件、字段、hook 类型 | hook 是自动化核心，配置一坏，整套机制就失效 | 解决 hook 配置拼写错误、事件名错误、字段不合法的问题 | -| Agent 配置校验 | `validate-agents.js` 校验 agent frontmatter、必填字段、模型合法性 | agent 定义是编排基础，损坏后会直接影响 AI 工作流 | 解决 agent 元数据缺失、配置非法、引用失败的问题 | -| Command 文档校验 | `validate-commands.js` 检查命令文档非空，且引用的 command/agent/skill 存在 | 命令是用户入口，文档失真会导致执行流程错误 | 解决命令引用失效、文档和真实能力脱节的问题 | -| Skill 结构校验 | `validate-skills.js` 校验每个技能目录都存在 `SKILL.md` | skill 是核心知识单元，结构必须稳定 | 解决 skill 缺失、目录不完整、安装后不可用的问题 | -| Rule 文件校验 | `validate-rules.js` 检查规则文件是否可读且非空 | 规则是 AI 行为约束基础，空文件等于失效 | 解决规则丢失、空规则、安装后行为退化的问题 | -| 安装器测试 | 测 `install-plan`、`install-apply`、manifest、install-state 等逻辑 | 安装层错误会让整个系统装不对、装不全、装错位置 | 解决 selective install 失效、路径错误、状态记录异常 | -| CLI 测试 | 测 `ecc`、`doctor`、`repair`、`harness-audit`、`sessions` 等脚本 | CLI 是用户直接操作系统的入口，必须可靠 | 解决命令行参数解析错误、输出不符合预期、功能失效 | -| Hook 脚本测试 | 对 `quality-gate`、`evaluate-session`、`auto-tmux-dev` 等脚本做独立测试 | hook 运行频率高，任何错误都会被快速放大 | 解决 hook 误报、漏报、跨平台行为不一致的问题 | -| 集成级 hook 测试 | 将多个 hook 或相关脚本组合起来验证完整链路 | 单个模块正确，不代表组合后仍然正确 | 解决组合行为异常、事件触发顺序错误、整体链路不通的问题 | -| 状态存储测试 | 测 session aliases、state store、install state 等持久化逻辑 | ECC 很依赖状态记录来支持连续工作 | 解决状态写坏、会话恢复失败、安装状态漂移的问题 | -| 工具解析测试 | 测 formatter 检测、包管理器检测、项目类型识别等基础能力 | 自动化链路依赖环境探测，探测错了后续全错 | 解决检测错误导致执行了错误工具、走错工作流的问题 | -| Harness 审计 | `harness-audit` 检查仓库在工具覆盖、上下文效率、质量门禁等维度是否达标 | 需要从系统层面评估一个 AI harness 是否“配齐了” | 解决功能缺失、能力不完整、质量体系不闭环的问题 | - -### 如何理解这张表 - -这张表里的方法可以分成四组： - -- `开发前与开发中` - TDD、单元测试、集成测试、E2E、编辑后 hooks。 -- `提交前与交付前` - `/verify`、`/quality-gate`、覆盖率、安全扫描、diff review。 -- `AI 工程专项` - `/eval`、Capability Eval、Regression Eval、pass@k、持续学习。 -- `ECC 自身质量` - validators、hook tests、CLI tests、install tests、state/store tests、harness audit。 - -也就是说，这个项目不是只在“代码写完以后”才测，而是把测试和验证铺在了整个 AI 开发生命周期里。 diff --git a/docs/zh-CN/commands/prune.md b/docs/zh-CN/commands/prune.md new file mode 100644 index 00000000..8d9d5a67 --- /dev/null +++ b/docs/zh-CN/commands/prune.md @@ -0,0 +1,31 @@ +--- +name: prune +description: 删除超过 30 天且从未被提升的待处理 instinct +command: true +--- + +# 清理待处理 Instinct + +删除那些由系统自动生成、但从未经过审查或提升的过期待处理 instinct。 + +## 实现 + +使用插件根目录路径运行 instinct CLI： + +```bash +python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" prune +``` + +或者当 `CLAUDE_PLUGIN_ROOT` 未设置时（手动安装）： + +```bash +python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py prune +``` + +## 使用方法 + +``` +/prune # 删除超过 30 天的 instinct +/prune --max-age 60 # 自定义年龄阈值（天） +/prune --dry-run # 仅预览，不实际删除 +```