laohu-evolution git:20260926.bc495aaA

Immutable. This exact content never changes and is served at /api/v1/blob/ac53633493acc17d.

---
name: laohu-evolution
description: 当已选方法要落实为长期能力时，保留原则、条件、步骤与可变形式的关系，接通实际执行并用下游产物检查；不重判未决专业方法或代改当前作品。
---

开始本入口前，解析当前 `SKILL.md` 所在真实目录为 `{SKILL_DIR}`，读取 `{SKILL_DIR}/../../../docs/runtime.md`；本轮已加载则复用。该文件提供跨项目的路径、授权、交接和保存约定，读完回到本入口执行。

# 老胡能力进化

`{SKILL_DIR}` 是本文件所在目录的真实路径（解析符号链接）；`{PROJECT_ROOT}` 是解析 `{SKILL_DIR}/../../..` 后的项目根目录。执行命令前核实根目录实际包含 `AGENTS.md` 和 `tools/check_project.py`，并替换占位符。

## 职责

把已确认的能力改进落实到实际执行会读取或运行的位置，使预期判断和下游产物真正改变，同时保留有效旧行为及适用条件。实施者负责规则表述、文件组织、依赖接入、必要示范和实现修正；不能把这些工作推回 analysis。任务内可以生成明确标为待验的试作；不得把 AI 自拟的作品、文案或反馈写入正式 Skill／Reference 充当教学范例。长期范例按 [规则表达与方法保留](references/rule-expression.md) 的来源门处理。

专业方法、核心范围和关键取舍以用户已选定的具体方案或 `laohu-analysis` 已确认的结论为依据。当前作品及其图片、视频、封面和提示词成品交给对应专业入口。专业四层的定义由 `{SKILL_DIR}/../laohu-analysis/references/capability-design.md` 唯一维护；本入口检查其关系能否在规则和实际产物中继续发挥作用，不另造定义。

本主文负责落实已确认的整体目标、范围、授权、跨入口职责和全局停止/返回条件；专业 Reference 可以在这一范围内给出并执行领域判据、方法分支和操作判断。Reference 不能借专业细节改变上游确认的目标或权限、接管其他入口职责，或把未定的核心取舍写成既定结论。若新材料使这些整体决定需要重选，按下文把受影响部分交回 analysis；其余可恢复实施继续。

目标领域 Skill 的主文还须保留该能力统领专业工作的核心判断、主要步骤及其衔接；Reference 深入专项方法、复杂判据或独立子流程。不能把主文空化为路径路由，也不能让 Reference 退化为脱离执行的知识摘录。主文与 Reference 共同形成专业执行链，但各自范围保持清楚。

只有会改变专业方法、核心范围、授权或关键取舍的缺项才返回 analysis；退回时指出缺项、影响和依赖它的写入，保留其他已完成工作。常规措辞、结构、格式和可恢复实现由本入口决定并继续。

## 执行

### Step 1：接收并校准依据

用户明确要求维护未来可复用的能力时继续；一次性作品修改交给对应专业入口。

1. 用户已选定的具体方案或 analysis 已选定的实施路径可以执行；备选与待决内容不冒充定案。
2. 有依据且已获授权的候选方法可以制作可恢复版本并试用。分别说明“已选定实施”和“效果已验证”；不能因本项目效果尚未证明而阻止试用。
3. 核对方案中的对象和适用条件是否仍对应目标文件与当前运行路径。这是范围核对，不是重查根因。

**analysis 交接完整性：** 要解决问题时，只核对方案能否实施，不重设计专业方案，也不要求 analysis 先写完每个字符。检查以下内容是否明确：

- 真实控制位置与要增、改、删的内容；
- 含条件和要求强度的核心规则、专业选择、关键分支与目标效果；
- 保护项、实施顺序或依赖、可观察的验收方式。

若缺项会改变目标、授权、专业方法或关键验收，列出缺项及影响，暂停依赖该项的写入并返回 analysis。其他措辞、结构、示范、接入和可恢复实现继续由本入口完成。不得用“优化一下规则”代替方案，也不把待决事项当成已确认。

**外部建议与用户授权：**

- 外部报告、其他 Skill 的建议或用户对原因的解释将决定规则内容、方法、范围或例外，而这些实质判断仍未定：建议先交 analysis 核对，暂停依赖它的部分。
  - 用户已授权调用 analysis：读取 `{SKILL_DIR}/../laohu-analysis/SKILL.md`，交接具体待判项；不得声称尚未发生的调用。
- 用户明确要求跳过 analysis，并亲自选定具体规则：按授权实施；注明这是用户选择，不代表外部依据已经核实。
- 已确定的路径、文案、格式及不依赖待决实质判断的技术操作：照常完成；不把附带原因猜测写成事实。

### Step 2：核对现状与控制位置

已有 Skill 的升级或经验注入，按本轮目标项目读取：

1. 先明确目标项目，读取该项目适用的 `AGENTS.md`（存在时）及目标 Skill 的 `SKILL.md`；不把能力安装仓库自动当成修改对象。
2. 读取目标 Skill 本轮需要的直接引用、脚本、模板和评测。
3. 读取产生反馈的作品、失败输出或变更记录。
4. 只有迁移成熟机制时，才读外部项目对应真源和验证记录。

随后检查目标文件、已确认条件和当前消费者，找出实际控制预期行为的入口、规则、脚本、配置及必要调用方。用简短工作映射对齐目标与依据、预期变化、要保护的旧行为和真实控制点；无需另建映射报告。不能只改解释文字而漏掉实际入口或运行文件。

无论 analysis 交接是否逐项列出，都要核对目标 Skill 所承接的输入、对象、产物、排除任务，以及越界响应、交接和停止条件。只在已确认职责内补成可执行规则；若缺项意味着核心范围、目标、专业方法或授权须改变，返回 analysis，不自行扩张。若目标正式产物属于另一入口，按 `{PROJECT_ROOT}/docs/runtime.md` 判断跨入口授权和负责人，不因目标文件相邻、共用负责人或只读所需 Reference／归档辅助而推断已有正式制作或写回授权。

若发现目标冲突、授权变化，或缺少会改变核心规则／专业方法的判断，暂停依赖该问题的写入；不受影响的工作继续。将材料路径、影响、需要 analysis 决定的问题、可继续部分及返回后的接续步骤交回 analysis。不要自行补理论或扩大成全面审查。

### Step 3：按条件读取实施 Reference

- **文件动作、范围、界面配置、多个消费者或调用链：** 读取 [能力文件增、改、删](references/change-workflow.md)，定位真源、执行者和依赖，完成适用的界面及多文件要求，再回到 Step 4。
- **新增或改写运行规则、迁移已确认方法或较长流程、制作可复用成品示例：** 读取 [规则表达与方法保留](references/rule-expression.md)，按其语义选择 Markdown 形式、方法保真与示范要求写回，再回到 Step 4。
- **普通单文件路径、措辞或配置修正：** 无需读取方法 Reference；按已确认方案实施。

未来执行者必须能凭正常任务输入和随能力交付且会实际加载的文件完成工作。本次已确认的聊天方案要编入运行文件，不让未来任务依赖制作聊天。Reference 应写明专项方法的判断依据、适用条件、动作和局部失败处理；它可以在授权范围内作专业判断，但不得推翻已确认的总体目的、权限、入口职责及全局暂停/返回路由。若依赖 Reference 的专项判断会改动核心方法或范围，先把具体缺项交回 analysis。

如需接入分层知识或选项资源，按本步骤第一项所列 [能力文件增、改、删](references/change-workflow.md) 完成触发条件、实际读取范围、顺序和返回位置；由 analysis 已定的任务依赖指导接入，不在主文重复一套固定加载数量或目录结构。

### Step 4：实施并接通行为链

把每项已定要求落到实际规则、消费者和检查；先前条件、强度、例外与示范作用不能被最近摘要覆盖。规则表达 Reference 负责详细保真方法，`capability-design.md` 负责专业四层定义；本步骤负责接入实际消费者，让输入、执行者、必要动作、适用分支、可检查产物和失败返回形成完整链路。修改所有实际控制预期行为的文件与调用方。

专业关系、适用条件或核心取舍未确定时，带具体缺项返回 analysis；措辞、章节组织、引用接入及其他可恢复实现由本入口完成。本步骤不重判已确认的专业方法，也不弱化用户确认的表达风格。

### Step 5：按变更类型验证

先选择与本次变更相符的检查：

| 变更 | 必查内容 |
|---|---|
| 路径、格式或文件动作 | 真实目标、引用、调用链与保护项 |
| 路由变更 | 正确请求、近邻反例及项目实际发现 |
| 方法迁移 | 代表性输入到实际产物、关键分支、例外、失败路径和应保留的旧行为 |
| 脚本变更 | 实际运行成功与失败路径 |
| 规则表达变更 | 关键对象、必要解释、术语作用、重复真源及正反例 |

方法、表达或交接规则改动后，在选试跑样本前读取 `{SKILL_DIR}/../laohu-analysis/references/validation.md`，按其区分示例复现、旧行为回归和留出验证。由未参与候选设计的执行者使用正常任务输入，实际加载最终交付的 Skill 与所需 References，确认产物能从这些文件独立产生。需要检查迁移时，另选未参与候选设计、对象与关键条件不同的留出样本；旧版和新版都通过只证明原行为保持，不证明能力改善。不提供制作聊天有助于避免提示，但本身不构成留出验证。

**创作方法专用检查：** 只有本次确实迁移或改进一项具备明确原理、作品关系和可变实现的创作方法时，才检查同一原理在不同材料下能否产生有效的不同形式、条件失效时能否退出或换法、示范是否被误读为固定配方。普通路径、标点或不涉及创作方法的格式修改不承担这组检查。

创建或实质改进能力时，用普通需求建立或改进目标能力，并使用最终文件产生下游完整局部产物；不以文件完成替代用户结果。分别记录目标效果与保护项：代表样本显示目标未实现时记 `FAIL`，不能用真实用户质量未知改报 `UNKNOWN`。局部指标全通过而整体效果失败时，检查评价是否漏掉关系或相互作用。只有缺少真实接收者或实际使用质量证据时，质量才记 `UNKNOWN`。

比较旧版时从改前实际快照读取，不能把变动中的当前文件称为旧版；使用实际执行证据报告结构、行为和质量状态。Checker 通过不证明行为或质量提升。按结果处理：

| 发现 | 后续动作 |
|---|---|
| 样本显示实现偏离已确认方案 | 修正实现并重跑对应检查。 |
| 方法已完整执行，代表产物仍未达到目标 | 返回 Step 2，将具体失败证据交给 analysis 重查方法与适用条件。 |
| 输入、环境或评价无效 | 先修复对应部分，再重跑受影响检查；不把这些失败一概归咎于规则。 |
| 关键检查失败或未完成 | 不报告完成。 |

**仓库维护要求：** 维护老胡仓库时，实施前读取 `{PROJECT_ROOT}/docs/maintenance.md` 的本地检查要求，交付前从已核验的仓库根目录运行适用检查；准备版本时再读其版本与发布部分。修改其他项目时，读取并执行目标项目的维护与验证要求，不用老胡仓库检查代替目标验收。维护命令只在 `docs/maintenance.md` 维护。

## 完成交付

在聊天说明实际改动路径、接入位置、验证结果和仍未知之处。只把有长期回归或维护价值的方法、输入和观察保存在既有职责位置，并保留适用条件；替代旧做法时合并或移除失效补丁。默认不创建每次执行的结果 JSON、哈希报告、审计日志或空目录。