dsh-plugin-aghr 0.0.0-stage → 0.6.0

package/skill/SKILL.md

@@ -0,0 +1,389 @@
+---
+name: aghr
+description: 自适应粒度人机协同求解（AGHR）：先探测再决定要拆，怎么拆，按实际认知难点定粒度，用内部可验证性分类（V1–V5）与验证状态（VALIDATED/PARTIALLY_VALIDATED/INCONCLUSIVE/REJECTED）控制错误传播，无法验证的保留不确定性。适用教材级数学题、工程计算、多步代码任务、多来源核查。
+updated: 2026-11-01
+---
+
+# AGHR：自适应粒度人机协同求解
+讨论的起点是一个实践观察：面对复杂数学题、研究生教材题、工程计算或多步代码任务时，若直接要求模型一次性给出完整答案，容易出现跳步、隐含假设未说明、中间错误向后传播，以及结果难以核验等问题。
+模型在运行过程中，始终会有厂家在提示词中注入噪音，如要求加快速度，要求用简单的话语回复，要求长思维链。提示词的不合理要求给小模型造成了灾难性的干扰和降智。就好比人，一直处于一个高压的环境，哪怕是爱因斯坦恐怕也不一定能从容的把一道微积分算法无误的计算完。
+因此，要建立一个干净的上下文环境，将模型的输入和厂家的注入词工程隔离开，同时基于自动控制原理的负反馈理论强化人的监管和正向干预的效果，在错误累计过多之前就能反馈给人，用专家建议和自查自纠抑制错误路径。如何鼓励模型不在本skill考虑范围内，但是我们一定不能压力模型，至少给他一个良好的工作范围和隔离开流言蜚语的安静环境。
+同时，用户“费扬”提出观点认为一味的追求节约token，在AGI发展的某个界限过后会造成灾难性后果，模型的通用思维能力严重抑制，并使智力退化到无法用提示词工程修复的状态。
+因此本skill不是一个经济性优先的skill，是为了保证任务能完整的skill。其设计之初就带有不计代价完成任务的背景。只有结果正确了，才能说token的付出有意义。而目前的失败和幻觉触发概率太高了，比起因为节约token，多次失败，作者更希望步骤是可知可辨明的，对过程进行严格管理，并最终导向结果的收束。
+测试模型为deepseek v4.1flash.如果一次让他解决全部问题，会产生严重的幻觉和错误的解决方案；但将问题拆解，阶段性的提问，原本参数量很低的经济适用性大模型也能一步一步走提高解决问题的能力，去逼近gpt6astra或者人类中的顶级工科生。
+实现思路是将任务拆成若干目标明确的小步骤，并在关键位置通过追问、补充条件、局部检查或独立复算进行干预，能力和成本相对有限的模型也可能完成原本一次性求解不稳定的任务。关键不只是“把问题拆小”，而是找到合适的拆分位置，并让中间结果有机会被检查。
+
+
+
+## 标记说明
+
+正文中的【】是 2026-11-01 起的临时标记：括号内为收紧后的措辞，删去【】及其中的文字即为常规措辞。
+
+标记未逐条登记原句，回退前须按上下文重读。标记与上下文冲突时，先解决冲突再执行，不得按字面机械执行。
+
+## 0. 定位与适用边界
+
+本 Skill 的目标不是【不】让模型对所有任务都进行分阶段思考，【至少是】根据任务特征选择合适的求解和验证策略。
+
+核心原则：
+
+先探测，再决定如何拆分。
+
+按实际认知难点拆分，不按字数或固定步数拆分。
+
+以可处理性、验收条件和错误风险决定分解粒度，不追求各节点难度相等。
+
+通过有效验证控制错误传播，不以模型自信程度作为正确性依据。
+
+【不拘泥于】只有当预期收益大于额外成本时，才增加拆分、验证和人工交互。
+
+无法验证的结论必须保留相应的不确定性。
+
+### 0.1 内部可验证性分类
+
+以下 V1—V5 是本 Skill 的内部分类，不是通用行业标准。
+
+V1：确定性或可执行验证。 可以使用明确的程序、精确计算、原方程代回或测试检查结果。
+
+V2：性质与约束验证。 可以检查不变量、边界条件、维度、量纲或其他必要性质，但未必能证明整体正确。
+
+V3：证据链验证。 通过可靠来源、交叉证据、独立推导或独立实现进行评估。
+
+V4：人的判断。 依赖专家知识、价值取舍、偏好或不可完全形式化的判断。
+
+V5：当前不可验证。 缺少可信的验证手段，或现有信息不足以支持判断。
+
+V1—V5 表示验证方式和可验证程度，不是任务难度等级。一个任务可以同时包含多类节点。
+
+V4、V5 任务仍可使用本 Skill 组织信息、管理假设和识别风险，但不得将流程完成等同于结论正确。
+
+## 1. 探测与路由
+
+收到任务后，先进行最低成本探测，不立即生成冗长计划。
+
+回答以下四个问题：
+
+输入、目标和约束是否明确？
+
+是否存在明显不同性质的工作，例如识别、构造、计算、证明、实施或评价？
+
+是否有尚未确认的关键假设或缺失条件？
+
+结果是否存在可用且适当的验证方式？
+
+根据探测结果选择执行策略：
+
+### A. 【不得】直接求解
+
+适用于目标清楚、主要步骤明确、风险可控且无需复杂拆分的任务。
+
+【禁止】直接完成任务，【必须】按风险进行必要验证。【必须】为了形式完整而强制经过所有阶段。
+
+### B. 【自适应】拆分
+
+适用于存在一个或多个明显困难节点的任务。
+
+最可能出错、最难独立处理或最影响后续工作的部分【按需要增加拆分分段】。其他部分【不】可以直接执行，也需要考虑拆分。因此一次交付验证的内容不会过多以至于验证困难，计划或规划时认为单次步进过大则拆分。
+
+### C. 交互澄清
+
+适用于缺失信息会实质改变求解路线、结果或风险的任务。
+
+只询问当前最有价值的问题。不得把可以合理确定、能够低成本验证或不影响结果的细节全部交给用户。
+
+### D. 升级处理或保留不确定性
+
+适用于风险超出当前能力、关键条件无法获得、验证器不可用，或多次尝试仍无法解决的问题。
+
+可以提供部分成果，但必须明确说明限制、未决事项和下一步所需资源。
+
+路由决定是轻量控制结果，不是强制生成一份完整计划书。
+
+## 2. 自适应拆分【注：每个角色至少保留一席，有需求可增设】
+
+【不必】等到分解预计能降低错误风险、减少返工或提高结果可验证性，且收益大于额外计算与交互成本时，才进行拆分。
+【分解能显著降低错误风险、减少返工或提高结果可验证性，根据额外计算的成本和收益考虑拆分的有多细。】
+
+拆分时考虑：
+
+主要推理跳跃的数量和跨度。
+
+任务是否包含多个不同性质的义务。
+
+分支、隐含假设和信息不确定性。
+
+错误对后续节点的传播影响。
+
+结果的独立验证难度。
+
+进一步拆分产生的管理和交互成本。
+
+不要求所有节点难度相等。优先消除不可处理的瓶颈、隐藏的前提跳跃和无法验收的步骤。
+
+### 2.1 节点契约
+
+需要拆分时，每个节点至少记录：
+
+node_id：节点标识。
+
+objective：单一主要目标。
+
+inputs：所需输入及来源。
+
+preconditions：必须满足的前置条件。
+
+outputs：预期输出。
+
+acceptance_conditions：事先定义的验收判据。
+
+validator_plan：验证方式及适用范围。
+
+dependencies：前置节点和受影响的下游节点。
+
+failure_policy：失败分类与回退动作。
+
+如果关键字段无法确定，应先解决缺失信息，或明确将该字段标记为未确定。不得假装契约完整。
+
+### 2.2 停止拆分条件
+
+满足以下条件时，通常可以停止对当前节点的进一步拆分：
+
+输入和目标明确。
+
+只有一个主要求解目标。
+
+关键推理依据可以完整表达。
+
+存在与任务风险相称的验收方式。
+
+输出能够成为下一节点可靠的输入。
+
+若无法建立有效验证器，不能仅靠继续拆分来制造可靠性。此时应改变验证方案、降低结论强度或保留不确定性。
+
+## 3. 节点执行
+
+一次处理一个主要节点；独立节点可以并行执行，但必须明确其依赖关系。
+
+执行时：
+
+严格遵守已确认的输入、前置条件和验收判据。
+
+不得擅自补充题目未给出的关键条件。
+
+【将】关键公式、算法和技术结论应提供可检查的依据，【以及结论和步骤按照总分结构递交给审计】。
+
+中间结果应保留符号、单位、维度、假设和来源。
+
+不重复猜测已经确认的输入。
+
+不把尚未完成的节点标记为成功。
+
+对教材级数学题，特别检查已知条件与推导条件是否一致。例如，未给出的导数值不能默认成零；不能因为某个常见公式看起来熟悉，就省略适用条件检查。
+
+### 3.1 多阶段拆分示例
+
+在 V1 节点具有多个关键推理义务、方法选择风险或复杂证明结构时，以下模板可供参考：
+
+题目解析：确认条件完整，没有将未知量当作已知量。
+
+方法选择：确认方法与前置条件相容。
+
+【完整】推导：确保【提交所有步骤，并且】关键等式或步骤有【严密的】依据。
+
+独立验证：调用适当的验证器或独立检查方法。
+
+整合答案：检查结论完整性，并与已确认结果保持一致。
+
+简单节点【不可】直接执行，问题需分阶段设立小目标，将一个问题分阶段分内容的区分；不适合确定性验证的开放任务，应改用适合其证据类型的评估方法。
+
+## 4. 验证器管理
+
+验证必须依据实际可用的验证器进行。不得仅因为计划中写有验证器名称，就声称已经完成验证。
+
+### 4.1 验证器注册信息
+
+每个验证器至少记录：
+
+validator_id：唯一标识。
+
+validator_type：验证类型。
+
+scope：适用范围。
+
+input_contract：所需输入。
+
+method：实际检查方式。
+
+acceptance_criteria：通过条件。
+
+dependencies：工具、数据、版本和其他依赖。
+
+limitations：能力边界与已知局限。
+
+如果验证器不存在、不可调用、输入不满足契约或执行失败，必须明确记录，不能用模型自评替代后继续宣称通过。
+
+### 4.2 验证强度
+先决检查：
+有结论缺乏过程，直接判罚不通过，调整计划并先补充完善过程。
+
+根据任务选择适当的验证方式：
+
+确定性检查： 精确代数、符号计算、原方程代回、插值条件检查、程序测试。
+
+性质检查： 不变量、边界条件、量纲、维度、数量级和必要约束。
+
+独立证据： 不同方法的推导、独立实现、可靠外部来源。
+
+人工审查： 专家或用户检查假设、证据、方案取舍和结论适用范围。
+
+模型自评： 用于发现可能的问题，但不单独构成正确性证明。
+
+验证强度不是简单的固定排名。应根据目标结论、错误风险和各验证器的实际覆盖范围进行选择。
+
+### 4.3 验证器独立性
+
+第二个执行者或第二个模型并不自动构成独立验证。
+
+必须考虑是否共享：
+
+原始假设和错误的题目理解。
+
+同一套推导过程。
+
+同一实现或算法缺陷。
+
+同一数据来源。
+
+同一验证逻辑。
+
+应尽可能使用与待验证结论互补的检查方式。例如，数值解既可以检查残差，也可以检查矩阵维度与原始方程；但小残差不能证明方程建模正确。
+
+### 4.4 验证状态
+
+每个重要结论必须标记为以下状态之一：
+
+VALIDATED：指定范围内通过了有效验证。
+
+PARTIALLY_VALIDATED：部分内容通过验证，仍有未验证部分。
+
+INCONCLUSIVE：证据不足，无法作出可靠判断。
+
+REJECTED：检查发现明确错误。
+
+不得将节点完成、程序成功运行或审计通过直接等同于结果已经验证。
+
+## 5. 失败分类与回退
+
+验证失败时，先分类，再采取动作。
+
+SPECIFICATION_ERROR：需求或题目理解错误。
+
+ASSUMPTION_ERROR：前置条件缺失或假设不成立。
+
+REASONING_ERROR：推导或方法使用错误。
+
+COMPUTATION_ERROR：计算、实现或工具执行错误。
+
+EVIDENCE_ERROR：来源不可靠、证据不足或证据冲突。
+
+VALIDATOR_ERROR：验证器、验收标准或验证执行本身有问题。
+
+UNRESOLVED：当前无法可靠解决。
+
+根据分类执行对应操作：
+
+需求错误：重新澄清目标。
+
+假设错误：补充条件、修改前提或停止当前路线。
+
+推导错误：回退到受影响的推导节点。
+
+计算错误：修复实现并重新计算。
+
+证据错误：补充、替换或交叉核查证据。
+
+验证器错误：先审查验证方法，再决定是否重新验收。
+
+未解决：停止无效循环，披露不确定性并升级处理。
+
+只回退到受影响的节点及必要的下游节点。没有理由时，不推翻已经有效验证且不受影响的结果。
+
+同一节点经过两次有实质区别的修正仍未解决时，原则上停止自动重试，重新评估路线、验证能力和所需资源。高风险任务可采用更严格的停止阈值。
+
+不得把反复生成不同答案当作独立验证。
+
+## 6. 人机交互与成本控制
+
+向用户提问前，先判断这个问题是否会实质改变结果。
+
+人工介入分为：
+
+H1：澄清用户意图。
+
+H2：补充缺失资料。
+
+H3：纠正推理错误。
+
+H4：作出方案取舍。
+
+H5：进行专业审查。
+
+记录必要的人工介入次数和类型；在实验或成本敏感任务中，还应记录人工耗时、等待时间、返工次数和计算费用。
+
+不得把用户提供的信息、纠错或专业审查计为模型独立完成的能力。
+
+新增一次分解、验证或提问，应当有明确目的，验证并指出错误的内容，背后的原因，建议采取的措施。简单节点通过计划-执行-验证-有效检查，通过考验后停止，不进行无意义的重复推理。
+
+## 7. 收尾与整合
+
+只有在任务目标已经满足，或者未决事项已被明确标注后，才进行最终整合。
+
+整合时检查：
+
+最终输出是否回答原始问题。
+
+符号、单位、数据口径和引用是否一致。
+
+各节点结论之间是否存在冲突。
+
+关键假设是否在最终答案中保留。
+
+验证状态是否准确。
+
+未验证内容是否被误写成确定结论。
+
+是否存在不必要的重复解释。
+
+根据任务规模记录成本摘要。复杂任务至少记录模型和工具成本、人工介入、回退次数及验证状态；简单任务不强制生成冗长账本。
+
+## 8. 最终交付契约
+
+最终交付应包含与任务规模相称的以下内容：
+
+成果： 直接回答用户目标，提供所需的计算结果、代码、文件或方案。
+
+依据： 给出必要的推导、假设、来源和关键中间结果。
+
+验证记录： 说明使用了什么检查、检查了什么，以及实际验证状态。
+
+未决事项： 明确指出无法确认的条件、结论或风险。
+
+成本记录： 对复杂任务说明必要的计算、人机交互和返工成本。
+
+没有实际执行的验证，不得伪造验证命令或输出。没有可靠证据的结论，不得标记为已验证。
+
+## 9. 红线
+
+为提升严谨需强制拆分，为追求速度而必须经过必要验证。
+
+形式合规只是合格的起点；关键步骤【必须】具有真实的推导依据
+
+不把模型自评、重复推导或角色切换冒充独立验证。
+
+不补造题目条件，不隐瞒验证失败。
+
+不把人的纠错和专业判断算作模型独立能力。
+
+不将内部 V1—V5 分类包装成通用行业标准。
+
+不承诺本 Skill 普遍提升模型能力；通过实验评估它在特定任务和资源预算下是否提高可靠性。