lijigang/ljg-skills

ljg-is

把一个名词或概念写成可使用的理解:?

Trending #8878 First seen Jul 31, 2026

Installation

$ npx skills add lijigang/ljg-skills --skill ljg-is

Summary

把一个名词或概念写成可使用的理解:先用普通话讲清它是什么、与相邻概念差在哪里,再说明它怎样运作、会改写什么判断,最后给出面对它时的行动抓手。USE WHEN 用户问 X 是什么、怎么理解、意味着什么、为什么重要、以后怎样判断或使用;尤其适合技术概念、制度、产品、角色、方法、规范与实践。NOT FOR…

Also in this package

Other skills from lijigang/ljg-skills · top by installs.

npx skills add lijigang/ljg-skills

Browse all from lijigang/ljg-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 7.3K
License LICENSE
Default branch master
Open issues 1
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version5.0.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,712 B
  • docs SUMMARY.md 556 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 352 installs

SKILL.md

把一个名词讲到能用

只给定义,读者可能记住了词,却仍不知道怎样认出它。只讲动词,读者又可能知道它做了什么,却不清楚它究竟是哪一类东西、边界在哪里。

ljg-is 把两者接起来:名词回答「它是什么」,让概念在认知地图里站稳;动词回答「它怎样起作用」,让概念在现实里动起来。真正完成的理解还要继续走一步:它改写了读者原来的什么判断,下次遇到它时又能怎样行动。

它是什么,和什么不一样?
它靠什么动作产生结果?
知道这一点后,我不再怎样想?
下次遇到它,我先看什么、怎样做?

这四个问题是一条理解路径,不是四个正文栏目。文章要像一个人顺着疑惑把事情讲明白,而不是把答案依次填进表格。

赵汀阳的「动词」思想在这里仍然重要,但它是一副有条件的透镜。面对制度、平台、角色或规范,可以继续追问谁选择了这种做法,它怎样改变参与者;面对目标函数、递归这类技术概念,动词首先是对象自身的运算与作用。材料没有显示社会反制,就不把技术说明硬拽成制度批判。

Workflow Routing

Workflow Trigger File
UnderstandInUse 把「是什么」与「怎样运作」接成可辨认、可判断、可行动的 Org 解读 Workflows/TraceCreation.md

成品标准

一篇合格解读会让读者发生四个连续变化:

  • 能用一句普通话说出 X 属于什么,以及它与最容易混淆的对象差在哪里。定义要给边界,不能只给比喻或用途。
  • 能顺着一个真实例子说明 X 怎样起作用。技术概念讲清输入、关键动作和结果;制度概念讲清参与者、规则怎样进入行动以及实际后果。只写对象真正具有的机制。
  • 能指出自己原来哪种看法需要修改。认知变化必须由前面的定义和机制推出,不另起炉灶追求「深刻」。
  • 能在一个具体情境里使用这番理解。行动指导要说清先看什么、怎样判断、何时调整,并能解释为什么。

正文从一个普通读者真的会有的疑惑、误解或使用场景进入,不强制编造人物故事。概念要尽早出现,例子负责验证解释,不负责制造戏剧性。

最后可以落在一句判断、一个行动原则或一个真实未决问题上。哪一种自然,由前文决定;问号不是深度证明。

默认写入:

~/Context/{时间戳}--理解-{目标片段}__is.org

新成品使用 ljg-is-v5 schema。正文使用两到四个随内容生出的标题和四到十个自然段,不把「是什么 / 怎样运作 / 认知改变 / 行动指导」直接用作四个栏目。

判断边界

  • 定义与理解不同。 用户若只要形式化定义、公式证明或术语翻译,直接回答即可;只有当他想理解概念如何工作、意味着什么或怎样使用时,才进入本技能。
  • 动词不等于社会创制。 技术对象可以通过计算、映射、比较、压缩或递归起作用,不必虚构一个创造者故事。制度对象才追问选择者、规则与反作用。
  • 行动指导不是操作手册。 本技能给判断抓手,不替代某个软件、流程或行业的逐步教程。
  • 理由不能伪造。 区分材料支持的事实和分析者的推断。不知道就缩小判断,不替人物补写动机,也不把一般机制冒充具体案例事实。

Gotchas

  • 不要把新合同写成新清单。 「定义、机制、启发、建议」若各占一栏,文章仍然生硬。它们应当像一条推理:因为 X 是这样运作的,所以原来的判断不够准确,下一次才应当这样做。
  • 不要只给用途当定义。 「目标函数用来优化」没有说明它是什么;要补上它怎样给候选方案建立可比较关系,读者才可能把它与约束、指标或奖励区分开。
  • 不要强制具体场景。 一个真实疑惑往往比虚构工程师或司机更自然。只有当人物行动确实承载机制时才使用故事。
  • 不要强造赵汀阳式转折。 未选可能、反制、本源和未来不是必填项。它们只有能解释对象,并且有现实根据时才进入正文。
  • 不要在结尾突然升级尺度。 前文讲算法,结尾忽然质问社会正义,通常不是深刻,而是换了问题。认知改变与行动指导必须能够逐句追溯到已经讲清的机制。
  • 不要给万能建议。 「保持关注」「综合考虑」「具体问题具体分析」删除概念名后仍然成立,说明它没有使用前文的理解。
  • 不要让元数据替正文说话。 definitionoperationrecognitionguidance 是后台索引;正文可以用更自然的说法,但全文读回必须找到同一内容。

Examples

目标函数

不要写:目标函数是优化的灵魂,它最终会反过来支配设计者。
可以写:目标函数是一把供求解过程比较方案的尺子。它给每个候选方案一个
可比较的结果,让程序知道往哪边改进。因此看到「最优」时,先补问一句:
这是按照哪把尺子得到的最优?

绩效考核

先讲清:它是组织定期判断工作表现并连接后续决定的一套正式做法。
再讲它怎样通过指标、叙述或评议进入奖金与机会。由此自然推出:考核不只
记录工作,也会改变人们接下来选择什么工作;设计考核时要检查它正在奖励的
行为,而不能只检查表格是否完整。

边界案例

User: 请给出递归函数的形式化定义并证明这个定理。
→ 不调用 ljg-is;这是形式定义与证明任务。

User: 我知道递归是自己调用自己,但还是不懂它到底是什么,写程序时怎么判断该不该用?
→ 调用 ljg-is;这需要把定义、运作方式、认知修正与使用判断接起来。