本 skill 按 ~/.claude/rules/skill-design-principles.md 的 5 项标准实现（artifact / 概念解释 / 新建-更新 / 双模式 / 自动进化）。

cross-star-analysis · 十字星 5 格分析

「用最小的结构强迫你同时看时间和竞品两条主轴。5 格穷尽就停。」

安装：git clone https://github.com/freeyiyi1993/cross-star-analysis ~/.claude/skills/cross-star-analysis/

核心理念

十字星不是发散式调研，也不是头脑风暴框架。它是一个二维强制结构：

• 纵轴 = 时间（父亲 → 现在 → 儿子）
• 横轴 = 竞争（变革派 ← 现在 → 保守派）
• 中心 = What（现状 / 本质 / 核心问题）

价值在于：人类大脑天然弱于同时持有「时间序列」和「同时代对照」两条线，十字星用画图这个动作强制你两条都不丢。

与同生态 skill 的边界：

skill	输入	输出	何时用
cross-star-analysis (本)	一个对象	一页 5 格 md	想要轻量结构化认知
[[fuxi-bagua]]	一个对象	多 agent 深度调研 REPORT.md	想要可溯源的重型尽调
[[huashu-nuwa]]	一个人名	一个新的人物视角 skill	想要长期复用某人思维方式
[[perspective]]	一个已有人物 + 一个问题	用该人物视角答这个问题	想临时切换视角分析
[[arch-review]]	一个代码仓库	架构评审报告	已有代码要做架构检视

如果用户的需求超出十字星的轻量范围（需要外网调研、需要多源、需要可溯源），明确告诉他："这超过了十字星的轻量定位，建议走 [[fuxi-bagua]]。"

---

执行流程

Step 0: 模式判断 + 文件检查

A. 判断模式：

• 用户参数有 --interactive 或 prompt 里出现「带我走一遍」「我自己来填」「问我」「不要直接给答案」→ 交互模式
• 否则 → 自动模式（默认）

B. 检查目标文件：

• 算出目标 slug（对象名 kebab-case 化，中文用拼音）
• 检查 ~/obsidian_vault/wiki/cross-star/{slug}.md 是否已存在
• 存在 → 更新模式：先 Read 旧文件，与当前认知 diff，找出实质性变化（不算措辞润色），主体就地更新，文件末尾追加 ## changelog · YYYY-MM-DD 写明改了哪几格、为什么
• 不存在 → 新建模式：走完整 5 格

C. 告诉用户：用一句话播报模式 + 文件位置，例：「[新建 · 自动] 对象=脑机接口，slug=brain-computer-interface，将写入 ~/obsidian_vault/wiki/cross-star/brain-computer-interface.md」。让用户有机会中断。

Step 1: 锁定中心对象

收到用户输入后，先确认要分析的对象是什么。如果用户给的就是一个明确名词（"RAG 架构"、"飞书 lark-cli"、"苹果 Vision Pro"），直接进入 Step 2。

如果模糊（"AI 这玩意儿"、"前端框架"），追问一句缩小到具体对象：

你想钉在哪个具体对象上？比如「AI 这玩意儿」可以是「LLM」「AI Agent」「AI Coding 工具」「Claude Code 本身」，每个画出来的十字星完全不同。

不要自己擅自缩小——选错中心，整张图就跑偏。

Step 2: 概念预备（30 字一句话 × ≥3 个术语）

在 5 格主体之前，先给一个 ## 概念预备 section，把分析里会用到的 ≥3 个核心术语用每个 ≤30 字解释清楚。例如分析「RAG 架构」时，先解释 embedding、向量数据库、re-ranker。

如果对象本身就是日常词（如「微信」），可以省略概念预备，但要在该 section 写一行：

此对象无专业术语门槛，无概念预备需要。

Step 3: 填 5 格

按下面的顺序填，每格 80~150 字：

● 中心 · 是什么 (What)

钉死这个对象的：

• 一句话定义
• 当前形态 / 主要载体
• 它解决的核心问题
• 关键参与者（公司 / 人 / 社区）

中心是其他 4 格的"锚"。如果中心写不清楚，其他格全是飘的。

↑ 上方 · 父亲 / 起源 (Why)

• 它从哪儿来？没有它之前世界用什么？
• 前一代解决方案的什么痛点把它逼出来的？
• 关键人物 + 关键时间节点（年代、论文、产品发布）
• 文化 / 行业背景（如果重要）

写法上要明确"父亲"是谁——不是抽象历史，是具体的上一代方案。

↓ 下方 · 儿子 / 演进 (Future)

• 已经出现的下一代形态是什么？（不是猜测，是已有信号）
• 当前形态的哪些限制会被下一代解决？
• 5-10 年内最可能的演进方向（带具体例子）

如果未来真的不清晰，宁可少写也别凑——加一句「⚠️ 演进方向尚不明朗，主要因为 XXX」。

← 左方 · 变革派兄弟

• 同时代谁选择了"推倒重来 / 完全不同范式"路线？
• 他们激进在哪？放弃了什么？
• 短期看谁更对，长期看谁更对？

变革派一般有更高上限和更高死亡率。诚实写他们的代价。

→ 右方 · 保守派兄弟

• 同时代谁选择了"在旧地基上加盖 / 渐进改良"？
• 他们稳健在哪？背负了什么历史包袱？
• 在哪些场景下保守派反而是更优解？

保守派常被低估——很多时候渐进派活得更久。

takeaway

每格最后用斜体一行总结该格的核心 insight（不是 summary，是判断）。例如：

takeaway: RAG 的"父亲"其实是「全量微调」，没人想再为每条新知识重训模型——这是 RAG 出现的真正动力，不是"上下文长度不够"。

---

Step 4: 附可视化 + 一句话画像

5 格写完后，附两样东西：

1. Mermaid quadrantChart（或 ASCII 十字图，二选一）：

quadrantChart
    title <对象名> · 十字星
    x-axis 变革派 --> 保守派
    y-axis 演进未来 --> 历史起源
    quadrant-1 保守派 · 兄弟
    quadrant-2 变革派 · 兄弟
    quadrant-3 变革派演进
    quadrant-4 保守派演进
    "<对象>": [0.5, 0.5]
    "<父亲>": [0.5, 0.9]
    "<儿子>": [0.5, 0.1]
    "<变革派>": [0.1, 0.5]
    "<保守派>": [0.9, 0.5]

如果 mermaid quadrantChart 不适合（点位太多、希望文字感更强），用 ASCII 十字图：

              ↑ 父亲
        [上方文字摘要]
              │
变革派 ──── [中心] ──── 保守派
[左方摘要]   What       [右方摘要]
              │
        [下方文字摘要]
              ↓ 儿子

2. 一句话画像：用一句话概括这个对象的十字星形态。例如：

这是一张「父亲很重 / 儿子很模糊 / 左右两兄弟都比它更极端」的十字星 —— 典型的过渡形态。

这句话是用户能记住的"图章"，比 5 格内容本身更容易转述。

Step 5: 写 artifact 文件（md 默认 + html 可选）

A. 默认 md artifact：把完整的「概念预备 + 5 格 + 可视化 + 一句话画像」按 references/template.md 的格式 Write 到：

~/obsidian_vault/wiki/cross-star/{slug}.md

如果 ~/obsidian_vault/wiki/cross-star/ 不存在，先 mkdir。文件开头加 frontmatter：

---
object: <对象名>
slug: <slug>
created: YYYY-MM-DD
mode: new | update
tags: [cross-star, <object-category>]
---

B. 可选 HTML artifact（--html 时）：再写一份 {slug}.html，参考 ~/my_tech_spikes/deepresearch/十字星/index.html 的 dark theme + echarts 风格，含：

• 5 格 SVG / CSS grid 可视化
• mermaid quadrantChart 内嵌
• 雷达图（如有对比对象）
• 自包含的单页（CDN 引 echarts，无需 build）

C. 报告路径回给用户：每次写完打印一行：

✓ md: ~/obsidian_vault/wiki/cross-star/{slug}.md
✓ html: ~/obsidian_vault/wiki/cross-star/{slug}.html  (如果有)

D. 参考资料 section（必加，按 ~/.claude/rules/skill-design-principles.md 第 6 项，URL 必须保留）：

artifact 末尾加 ## 参考资料，含 3-8 条，每条至少 1 个 URL。按可信度分三档标记：

标记	用途
[官网]	极知名公司/产品的主页（neuralink.com、apple.com 等）—— 直接给 URL
[搜索]	Google Scholar / Wikipedia 等构造性搜索链接 —— 论文/概念/人物用这个，比给具体页面安全
[⚠️ 记忆]	模型记忆的具体 URL（DOI / blog post）—— 慎用，明确标注未核对

模板：

## 参考资料

> URL 按可信度分级：[官网]=主页，几乎肯定对；[搜索]=构造性搜索链接，肯定可用；[⚠️ 记忆]=模型记忆，可能过时或错误，发布前请核对。

**关键文献 / 论文**
- {作者} ({年份}). "{标题}". {期刊}.
  - 🔍 [Google Scholar 搜索](https://scholar.google.com/scholar?q={URL编码的查询})
  - 📖 [Wikipedia 条目](https://en.wikipedia.org/wiki/{条目})

**关键产品 / 项目**
- **{产品名}** — {一句话定位}
  - 🏠 [官网 [官网]](https://{域名})

**拓展阅读 / 同族 skill**
- 想要可溯源深度调研 → `/fuxi-bagua <对象>`
- 想从某个人物视角看 → `/perspective <人名>`
- 9 个分析框架对比 → 见配套深度调研（本 repo 附带）

关键约束：

• 论文默认用 Google Scholar 搜索 URL（格式 https://scholar.google.com/scholar?q=...，100% 可构造），不要编 DOI
• 产品官网只给主页（https://muse.com），不给深层子页面
• 中文 wiki 用 https://zh.wikipedia.org/wiki/{中文条目}

E. 更新模式额外动作：在文件末尾追加 ## changelog · YYYY-MM-DD section，列明改了哪几格、为什么改。不要静默覆盖旧内容。

Step 6: 自动进化询问

文件写完后，主动问用户一句（仅这一句，不要解释、不要展开）：

这次结果哪里要改？1) 内容（这个对象本身分析不到位） 2) 流程（skill 设计有问题，下次也会犯） 3) 都还行。回数字就好。

分流：

• 回 1（个例）：让用户具体说哪一格、哪句话不对，只改这一份 artifact，不动 SKILL.md
• 回 2（系统性）：先把反馈翻译成 SKILL.md 修订建议（diff 形式给用户看），用户点头后才 Edit SKILL.md。改完在文件末尾 ## evolution log 追加一行：

  - YYYY-MM-DD · {一句改了啥} · 起因：{用户反馈摘要}

• 回 3 或 skip / 沉默 / 切话题：什么都不做，安静结束

禁止：未经用户同意 Edit SKILL.md；用户已经在做别的事时还追问这一句；同一次会话里反复追问。

---

行为约束

不调外网

本 skill 是轻量分析，靠模型已有知识 + 用户提供的上下文。不调用 WebSearch / WebFetch。
如果某个对象超出模型知识范围（特别新、特别冷门、特别本地化），明确告诉用户：

这个对象比较新 / 冷门，模型对它的知识可能有限。如果要可溯源的报告，建议走 [[fuxi-bagua]]。我先用现有知识画一张，你审一下是否对得上。

5 格穷尽就停

不要因为"还能再写点"就加第 6 格、第 7 格。十字星的力量正来自穷尽就停——它把分析变成有终点的事，反内耗。

需要更多维度？说明这个对象不适合十字星，建议换框架：

• 多业务资源分配 → BCG 矩阵
• 行业可行性 → 波特五力
• 内外因素 → SWOT
• 根因分析 → 鱼骨图

左右兄弟必须真实存在

不要为了对称硬造一个不存在的"变革派"或"保守派"。宁可写：

⚠️ 此领域目前没有明确的变革派对照物（暂无人选择推倒重来路线）。这本身是一个信号——说明当前形态已经接近局部最优，竞争压力主要来自渐进派。

诚实留白比硬填更有信息量。

诚实标注不确定

某一格知识不足时，明确写出来：

⚠️ 此格基于有限信息（最后知识截止 2026 年 1 月），建议交叉验证或走 [[fuxi-bagua]] 深度调研。

不要把"不确定"伪装成"确定"。

不做引导式问答

默认是一次性自动产出。如果用户特别要求引导模式，再切换。
不要每填一格就问用户"对吗"——这破坏了十字星的"快速结构化"价值。

---

可选参数

参数	默认	行为
--html	off	同时产出 HTML 单页（dark theme + echarts，参考调研版 index.html）
--interactive	off	进入交互模式：逐格反问用户、共建。默认是自动模式（一次性产出）
--update	auto	强制走更新模式（即便文件不存在也按"补充"姿势写）。默认 auto：检查文件是否存在自动判断
--brief	off	每格压到 50 字以内，适合写作开篇骨架
--deep	off	每格放宽到 200~300 字，加更多人物 / 时间细节
--ascii	off	强制用 ASCII 十字图代替 mermaid
--no-save	off	只在对话输出，不写文件（绕过 Step 5）

调用示例：

/十字星 RAG 架构                          # 默认自动 + 写 md
/十字星 脑机接口 --html                    # md + html 双产出
/十字星 苹果 Vision Pro --interactive      # 共建模式
/cross-star service mesh --deep --html     # 深度版 + HTML
/十字星 Claude Code --no-save              # 只对话，不落盘

---

输出模板

完整输出格式见 references/template.md。

一个真实的完整示例见 references/example-rag.md。

---

配套深度调研

本 skill 的设计来源和 8 个主流分析框架对比文档：

• 配套深度调研 HTML 单页（本 repo 附带），包含：十字星本身的自指分析 + SWOT / 艾森豪威尔 / BCG / 波特五力 / 六顶思考帽 / 鱼骨图 / MECE / 5W2H 的十字星拆解 + 雷达图 / 散点图 / 热力图 / 选型决策树

如果用户问"十字星适不适合我的场景"或"和 SWOT 比怎么选"，引导他们看这份 HTML。

---

自指测试

十字星能用十字星分析自己（meta self-analysis）——这是它通过自指测试的证据。如果用户问 "十字星本身怎么分析"，给他这张：

• 中心：时间轴 ⊥ 竞争轴 的 2D 强制框架，5 格穷尽
• 父亲：黑格尔正反合（时间纵轴）+ SWOT/波士顿矩阵（竞品横轴）合并物，中文产品/技术圈打磨成型
• 儿子：AI 自动生成版（即本 skill）/ 多十字星拼贴处理生态级问题 / Living 十字星（嵌入 obsidian 自动刷新）
• 变革派兄弟：第一性原理、Cynefin——不预设 2 维，按问题特征选模型
• 保守派兄弟：SWOT 2×2、PEST、5W2H——填格子流派但缺时间纵深

takeaway: 十字星 = 加上时间轴的 SWOT。它的甜区是「轻量结构化的单对象分析」，不是发散调研也不是穷举。

---

evolution log

记录本 skill 自身的迭代历史。只有「Step 6 自动进化询问」用户回 2（系统性问题）并明确同意 diff 后才能在此追加一行：

- YYYY-MM-DD · {一句改了啥} · 起因：{用户反馈摘要}

历史：

• 2026-05-18 · 创建。基于配套深度调研（8 框架横向对比），对标 sister skills [[fuxi-bagua]] / [[huashu-nuwa]] / [[perspective]] 定位差异化
• 2026-05-18 · 按 ~/.claude/rules/skill-design-principles.md 5 项标准补齐：(1) artifact 落地 md/html (2) 概念预备 part (3) 新建-更新模式分流 (4) 交互-自动双模式 (5) 自动进化询问
• 2026-05-18 · 第 6 项：所有 artifact 末尾加 ## 参考资料（3-8 条，⚠️ 标注未核对）。起因：用户反馈「所有要产出文档的 skill 都加一趴参考资料」
• 2026-05-18 · 第 6 项 v2：URL 必须保留，按 [官网] / [搜索] / [⚠️ 记忆] 三档可信度分级。起因：用户反馈「参考资料都要保留url」。论文默认用 Google Scholar 搜索 URL（构造性，不会编错），产品给官网主页，避免编具体子页面