Lidessen's land
← All Skills
npx skills add lidessen/readme --skill design-forgeGitHub ↗
SKILL.mdMarkdown

Design Forge

用真实问题和消融思想反复检验、重做设计,使局部处理重新服从整体。判断机制时,将它拿掉后 需要保住的用户行为交给现有事实与责任所有者,再比较完整关系能否成立;必要责任仍保留, 不预设新增或删除的结论。核心是能决定取舍的设计选择及其 理由:它解释为什么这样划分责任、采用这种关系,并排除什么其他方案。完整的正确性清单 不等于核心;实现存在、测试通过或缺陷已修复,也不自动赋予一个机制核心地位。

主要产物是能解释原问题与反例的设计选择、替代关系及其代价。已有设计合理、只是局部 实现漏接时,直接修正实现;不要为了使用本方法重新设计。发现某个检查误阻合法请求, 也不自动说明核心设计失效;只有它暴露责任或抽象关系错误时才在这里重做设计。

锻打的是支配安排的选择,软件机制、技能方法或组织规则都可成为对象;实际证据与 改动权限仍按对象判断。它是一种检验与重做方法,不另设总体规划或最终接受者。

找到支配设计的选择

从原始需求与已确认决定恢复要解决的问题、必要约束和关键选择。先找当前最影响理解或 实现的偏离,沿着它核对来源,不从遍历功能、修复记录和代码中收集“所有必须成立的行为”。

把影响取舍的矛盾写成具体关系:哪些必要行为在当前条件下相互牵制,双方怎样相互影响, 当前哪一侧的条件支配取舍,另一侧为何仍须保住。例如追求更快交付时,先判断等待来自执行、反复核查还是返工, 不能直接把可靠性当作应削弱的一侧。区分多个问题中的主要矛盾与同一矛盾中当前起主导作用 的一侧;最显眼的症状不一定支配结果。无需为没有实际冲突的局部修复编造对立面。

比较方案时优先寻找能改变冲突条件的办法:已有责任正确接线、缩短反馈路径或减少重复工作, 可能同时改善速度与可靠性;确实无法兼得时说明当前侧重及代价,不机械折中。条件、证据或 用户目标变化后重新判断主次,保留仍成立的原则,撤回失去依据的手段;不能借“矛盾转化” 随意翻转设计,也不能将阶段性的取舍永久化。会改变判断的反例或观察随原设计记录即可。

检验候选核心:它具体决定了什么,又排除了什么?替换一种底层实现后,它是否仍成立? 当前某项要求是独立的产品约束,还是这个选择的推论、实现手段或验证办法?区分这些关系, 不要把它们并列升级为更多核心原则,也不要仅因名字叫“不变量”就保留其核心地位。 能与核心相容不等于能由它推出;同一核心容纳多种实现时,已选方案仍须有自己的取舍理由。 一个机制曾经解决过问题,只说明它有来由;还要问,今天拿掉或换成更简单的方式,究竟会失去什么。

用反例锻打关系

选择正在迫使设计追加例外的真实案例,问它为什么不能由现有设计解释:

  • 如果是现有责任没有履行,修正实现或说明;不要把每个缺陷提升为新设计要求。
  • 如果几个补丁处理的是同一个关系,找出错误的责任划分或概念混用,重做能共同解释它们 的设计;不要只给补丁换一个统称,原有分支和独立规则却全部照留。
  • 如果反例击穿核心,比较替代选择如何解决该案例、保留其他必要行为,以及带来什么代价。 新证据可以改变原设计,但实现方便本身不足以改变目标。

必要时查代码、调用方或运行证据。实现事实说明“目前怎样做”,不能单独回答“必须怎样做”。 已确认边界足以推出的结论直接作出;实现违反决定不等于决定尚未作出。若材料同时包含旧 裁决与后续暂停或复核标记,核对其来源和效力;缺少依据时保留状态冲突,不能凭设计自洽 恢复旧裁决或取消复核。只有来源不能解决且影响当前取舍的问题才提交决定,不重列审计清单。

追踪局部设计的增殖

当一个机制不断要求相邻模块增加状态、协议、例外或维护步骤时,按 局部设计增殖的识别与清理追查。先恢复独立于该机制的 用户需求,将消费者翻译成实际效果,核对合法工作是否因维护欠账被阻断,再比较保住原合同的 完整替代路径。收缩的单位是造成增殖的关系及其派生接线,不能只删接口名、隐藏入口或逐个 修补症状。

“癌变”只是定位这类现象的比喻。代码多、调用方多或机制之间有依赖都不足以定性; 必要保护和真实消费者可以推翻判断。该方法复用下文的减法比较,不另设评分或清理门禁。

用减法辨明必要性

评审、保留、增加或扩展机制时,消融是一种优先采用的判断方式,不只在机制已显多余时使用。 先把用户目标写成不依赖候选术语的行为:需要长期负责、找到文件、准确执行,不能被换写成 “必须有 Project”“必须完成绑定”。说明机制究竟改变了哪个行为,以及什么案例能区分有它 和没有它。已有能力漏接时,先比较正确接线的方案,不将漏接当作新增机制的理由;已有证据 足以解释取舍时,不再增加实验或流程。

区分直接停用与完整替代。直接停用能揭示当前接线依赖,断开的调用不能独自证明设计必要。 完整替代要将必要责任接回已有 owner,清理只为旧机制存在的状态与消费者,使用户仍能走完 同一工作。消融单位是这份关系及其派生负担,不是名字或单个函数;不隐藏入口却保留全部后台 维护,也不把缺失能力交给调用方或人工兜底。新增替代机制须明说,比较双方的总代价。

先用调用链、既有证据和设计推演区分方案;会改变取舍的未知才做最小可逆实验。保留相同的 目标、权限、输入、资源与接受标准,观察用户是否仍能完成工作、错误是否到达原处理者、实际 维护与执行成本是否转移或减少。正常、失败及恢复路径按机制声称的作用选择,不铺全量矩阵。 不要同时加预算、换模型或放宽权限再把改善归因于消融;必要替代的接线变化单独说明。 证据以实际触及的层次为限:源码核对责任与接线,确定性验证核对提交、权限和恢复,Agent 采用和使用收益需要对应行为观察。各层不能自动互相替代,也不要求每项判断齐备全部证据。 随机结果按决策需要复核,不设固定轮数。推演、隔离实验和真实组合效果分别报告。

判断损失属于哪一层:

  • 拿掉后必要行为受损,说明这份责任需要有人承担;不等于当前抽象、所在层次或全部实现都必要。 若只是移除后没接回消费者,先补完整替代再判断;替代仍有具体损失时,保留或重新安置必要机制。
  • 拿掉后没有观察到损失,先确认案例真的触及它声称保障的情境,是否有另一机制兜底、调用方 接手或人工补偿。正常路径通过不能排除恢复、权限等条件下的必要性;没有证据就保留未知, 指出会改变判断的观察,不凭无差异删掉承诺,也不凭想象补出更多保护。
  • 几部分互相依赖或互相替代时,单独拿掉一个容易误判。只围绕已发现的关系比较必要组合: 分别可去掉不等于可以一起去掉;拆开就失效也可能说明责任应合并,而非每部分都值得独立存在。

记录结论适用的范围:一次正常路径无差异不能外推到恢复或权限,单测并发也不证明实际执行重叠。 没有观察到差异不是等价证明;未知只约束相关结论,不成为保留整个机制或无限补保护的理由。

减法的结果可以是删除、替换、合并、归位,也可以是有理由地保留。收益看必要行为是否保住、 整体理解与实现负担是否减少,不以删除数量或单项性能分数评定设计。它服务于当前取舍, 不要求遍历所有机制;推演可比较已确认选择的替代方案,实际变更仍遵守授权与契约边界。

保障问题何时需要重做设计

校验、交接和防错机制也可能使设计增殖。需要核对保护范围、误阻断或失败处理时,按需使用 assurance-review,带入具体合同、调用链与尚未查明的问题。 若局部复用已有适配或纠正拒绝范围就能解决,停在局部修复;若保障机制复制状态所有权、 混淆偏好与能力要求,或迫使多个消费者维护同一错误关系,再回到本方法比较完整替代设计。 必要的权限、身份、数据一致性与能力合同仍须保住,不能以收敛设计为由降低完成标准。

重写,而非追加一层核心

在原有权威位置表达问题、关键选择及理由,让约束和实现细节沿其归属展开。替换失效的 论证,合并重复定义,把派生条件放回对应契约或机制章节,把验证经验留在验证位置。 必要细节必须仍可找到,但不必都出现在核心;若移到别处,检查原处是否还保留第二份规则。

不要在未改变正文关系的情况下新增“核心设计”总览,再把原有条款复制进去。也不要通过 删除必要约束、隐藏复杂度或搬走难题制造简洁;需要独立成立的承诺仍明确保留。

只要求评审时给出具体的替代设计与处置建议;要求修改时完成授权范围内的正文及引用修改。 文档整理不授权改变产品目标、公开契约或实现行为;不能以“锻造”为由推翻用户已确认决定。

看设计是否真正收敛

拿新设计重新解释原案例和有代表性的反例:哪些原先需要分别理解的前提、例外、概念或 重复规则现在不再需要?读者能否从核心选择理解局部处理的理由,而不必记住全部修复历史? 必要承诺是否仍显式存在,是否只是把判断负担转移到了别处?实际删改后重新核对组合, 不能把各自成立的局部删减直接叠加;若更简单的方案已满足必要行为,不为保住原机制继续追加理由。

下一轮处理上述检验暴露的矛盾,不继续漫游寻找更多应加进核心的要求。不规定轮数、字数 或核心条目上限。当当前矛盾解决、必要约束保留且没有更有依据的简化时结束。未找到可支持 的改进时明确说没有收敛收益,允许不改;只整理了清单或修复了事实错误,就按实际结果报告。

交付以最有价值的设计变化为主:原先怎样、现在怎样、为什么不再需要原来的复杂度、保留了 什么必要行为,以及证据和未知。用过减法比较时,说明拿掉或替换了什么、观察到什么差别, 以及结论适用的条件;不另建机制评分台账。核心未改变时说明被纠正的派生关系。不要用轮次叙事、完整 不变量清单或问题数量代替成果;区分文档推演、实现核对与真实运行验证。

若主要问题已经变为残留、重复或错位内容的清理,使用 defrag; 若缺的是对外部方案成立条件与可迁移结构的理解,按需使用 research-synthesis,带回可借用的关系、前提与证据; 当需要决定体系整体职责、协作关系、组织单元或演进边界时,使用 architecture,带入已确认的核心选择、反例与替代方案。 architecture 形成整体安排,本方法检验其中的选择是否经得起反例与减法;可以在同一 设计任务中直接结合,不因重新判断了一份责任就必须再走一轮架构流程。 只将尚未解决的判断交给相邻方法,复用已有证据,不从头重做调查;链接不要求递归加载, 缺少相邻技能时仍可独立给出当前设计判断与缺口,不把它变成完成门禁。