CtrlK
BlogDocsLog inGet started
Tessl Logo

ljg-structure

找出一段信息中母题级别的结构,把抽象关系展开回具体可见的现象,再用风洞检验关键因果与边界。USE WHEN user says '找结构', '母题是什么', '结构风洞', '背后的结构', '不要只做AB测试', or wants the generative mechanism beneath a problem. 仅当用户明确要求时展开跨域来源或多母题组合。NOT FOR 普通摘要、单个类比、事实查询或已有明确唯一解的执行题。

69

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

母题结构风洞

输入一段信息,穿过表象找到它反复上演的母题,再把真正起作用的几根结构画清楚,送进风洞校准。默认结果要轻:读者带走一个说得明白的母题、一张能运行的关系图、一个既能迁移又会改口的结论。

四个概念,不能混

  • 主题:信息在谈什么对象,如「团队讨论」「AI 注意力」。它只圈定语义范围。
  • 母题:不同领域反复遭遇的同一类根本困境。它不是把原题换成更大的抽象词,而是用更普通的话保留那条可迁移的关系。
  • 类比:两个案例看起来相像,如「团队像陪审团」。它只是发现入口。
  • 结构:删掉领域名词后仍成立的因果骨架。它说明什么关系会生成什么结果。

一句话:主题是名字,母题是难题,类比是线索,结构是因果机器。

理解契约

结构分析不是让读者记住一组抽象名词,而是让他能在心里把关系跑一遍。完成的解读必须做到:

  • 概念明确:每个承重概念都能用普通话说明「这里具体指什么」,并给出一个可见标志。
  • 关系明确:读者能复述「在什么条件下,谁怎样影响谁,先出现什么变化,最后得到什么结果」。
  • 示例承载关系:例子不只让人觉得相似;其中的角色、作用方向和结果都能对应抽象关系。
  • 边界可以判断:条件变化时,读者能预判关系会怎样变化,也知道什么观察会迫使自己修改判断。

案例负责让模型运行,不负责证明模型普遍为真;风洞负责在内部改变条件、寻找边界和校准判断,最终只把有信息量的试压结果交给结论。

风洞如何进入结论

  • 风洞是内部方法:沿用同一个示例,改变一个关键条件,观察预测怎样变化,并找出模型何时失效、什么信号会让判断改口。它不再单列为可见章节。
  • 结论是校准后的交付物:先呈现同一示例在条件变化后的关键差异,给读者具体抓手;再把差异压成一条可迁移的抽象规则,回到原现象说明现在应该看见什么。

风洞的完整推演留在内部,结论只带出最能区分模型的条件变化、边界或改口信号。它们与抽象规则必须形成递进,而不是把同一因果链说两遍。

适用边界

适合:问题机制不明、现成方案贫乏、多个现象彼此牵动,或需要超出普通 AB 测试的探索。

不适合:纯事实查询、只有一个确定步骤的执行题、输入中没有可识别的困境。医疗、法律、安全等高风险领域可以借结构生成假设,但不能用类比代替本领域证据。

Workflow Routing

WorkflowTriggerFile
FindStructure从信息中找母题、结构关系与风洞实验Workflows/FindStructure.md

Gotchas

  • 「团队沟通」「AI 认知」仍是主题;「怎样做得更好」又宽得没有约束。母题必须保留真正的关系或张力。
  • 母题不是更抽象的标题。若一句母题仍含两个以上无法用普通话解释的承重词,先解码,再输出。
  • 母题下只放一个最小示例,用来让关系第一次运行;不要展开跨域案例清单。
  • 默认只设一个贯穿全文的示例锚点。结构卡指回其中的具体瞬间,关系图串起全局,风洞改变它的条件;不要在四处重讲同一个故事。
  • 「像免疫系统」「采用双盲」只是来源或方案名。拿掉来源名后仍能说清因果,才叫结构。
  • 跨域搜索是内功,不是默认目录。把三个领域逐项铺开,往往只会压住真正的母题。
  • 结构卡默认只留一至两个,第三个必须证明不能并入前两者。每张卡都要完成「概念明确、关系明确、示例映射」,但不强制显示成三个字段。
  • 例子必须映射角色与因果。只说「这像某某」会制造熟悉感,不会让关系变明确。
  • 有多个结构时,先判断它们是串联、并联、嵌套、制衡还是反馈,再画图;不要看到多个结构就排成链。
  • 默认不做笛卡尔积、不算组合数。多母题也先找结构关系;只有用户明确要求组合时才展开。
  • 风洞是方法,不是章节。它先锁定基准预测,再改变一个条件,比较最先出现的差异,最后指出适用边界和判断更新规则;成文只保留其中最能改变理解的一次试压。
  • 结论不是全文摘要。它依次完成「具体试压 -> 抽象规则 -> 回到现象」,让例子提供抓手,让抽象关系获得迁移力。
  • 具体试压与抽象规则必须递进:前者回答「条件变了会怎样」,后者回答「这说明哪条更一般的关系」。若两段只是换词复述,删掉较弱的一段。
  • 最小可逆实验只用于行动问题。概念解读默认给判别检验,不把每个思想问题都改造成行动建议。
  • 概念模型不能靠事后收窄边界逃避反例。先声明适用条件和区别性预测;边界外案例只负责画边界,不算支持或反驳。
  • 风洞不引入一套新术语。若必须发明新概念才能解释试压结果,先回到结构卡重新解码。
  • 证据边界只在结尾交代一次。不要在每张结构卡反复插入警告,打断推理。
  • 不确定事实时,把它留在内部候选层;若必须输出,明确写成待核验,不把记忆中的故事当事实。

输出要求

默认约 800-1500 汉字。一级标题严格只有:输入母题结构结论。风洞是内部推理步骤,不作为一级标题输出。母题用一问一例让关系先跑起来;结构卡以自然短段完成「概念明确、关系明确、示例映射」,不强制可见字段。跨域来源不设默认标题;通常不输出,确有帮助时只用一句话带一个例子。结构超过一个时,用纯 ASCII 连接符画关系图,禁止 Unicode 箭头和方框字符。关系图后用一句普通话说明「这张图在例子里怎样运行」。

默认取得两个时间值:date +%Y%m%dT%H%M%Sdate "+%Y-%m-%d %a %H:%M"。写入:

~/Documents/notes/{时间戳}--结构-{主题}__structure.org

若用户明确说「只分析」「不落盘」或 read-only,直接在对话中给出同等完整的分析,不创建文件。

文件必须是 org-mode,禁止 Markdown。最小结构:

#+title: 结构:{主题}
#+date: [{可读时间}]
#+identifier: {时间戳}
#+filetags: :structure:

* 输入
* 母题
* 结构
* 结论

结论用两段自然收束。第一段回到同一个示例锚点,只改变一个关键条件,写出最先出现的差异以及什么结果会迫使模型改口。第二段从该差异抽出一条可迁移的关系,直接回答母题,再点回原现象说明现在应该怎样理解它。末尾只出现一次证据边界,区分说明性案例、结构推演、本领域已有支持与仍待实验的部分。保存后读回文件并报告路径。

Examples

Example 1:首个发言者锁定团队

User: 「为什么团队讨论总被第一个人带偏?找其中的结构。」
→ 母题用普通话追问:为什么越早出现的信息越容易成为后续判断的参照物?
→ 用会议现场的一句话,让这条关系先运行一次
→ 结构卡说明「参照物」指什么、怎样影响后来者,并给具体例子
→ 内部风洞改变发言顺序或信息来源,比较预测怎样变化
→ 结论先给出条件变化后的具体差异,再抽出「先出现的信息会取得解释权」

Example 2:AI 深挖与异常发现

User: 「这个 AI 擅长深挖局部,却总错过改变全局的异常,用结构风洞分析。」
→ 母题:有限注意力如何兼顾局部开发与未知探索
→ 抽出局部深挖与外围巡逻的关系骨架
→ 内部用风洞找出最小异常升级实验,把试压结果并入结论

Example 3:用户明确要求展开

User: 「请给出这个母题的跨域来源,并分析三个母题怎样组合。」
→ 才展开来源或多母题处理
→ 仍先判断结构间的串联、并联、嵌套、制衡或反馈并画图
→ 只有用户继续要求组合数学时,才计算组合空间
Repository
lijigang/ljg-skills
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.