hai-stack 不是一堆零散的 prompt，也不只是一个 skills 目录。它是一套让 AI 助手更像一个可靠合作者的工作系统：帮你判断想法、框定方案、定义 PRD、写清目标、审视架构、用测试驱动实现、同步文档，并把关键结论变成能直接拿去展示和传播的报告。
概要
hai-stack 不是一堆零散的 prompt，也不只是一个 skills 目录。它是一套让 AI 助手更像一个可靠合作者的工作系统：帮你判断想法、框定方案、定义 PRD、写清目标、审视架构、用测试驱动实现、同步文档，并把关键结论变成能直接拿去展示和传播的报告。
README
hai-stack
一套面向 AI 编程助手的工作方法论：先判断，再定义；先写清楚，再执行；先验证，再交付。
hai-stack 不是一堆零散的 prompt，也不只是一个 skills 目录。它是一套让 AI 助手更像一个可靠合作者的工作系统：帮你判断想法、框定方案、定义 PRD、写清目标、审视架构、用测试驱动实现、同步文档，并把关键结论变成能直接拿去展示和传播的报告。
这些技能会在 AI 助手识别到意图后自动激活——你不需要记命令，只要把目标说清楚。
为什么需要它
和 AI 协作最大的成本，往往不是 AI 不够聪明，而是协作太随意：
- 想法没判断就开干，做到一半才发现不值得。
- 需求没边界就写代码，越写越偏。
- 方案要么太怂，要么太飘，要么塞满了不必要的概念。
- 做完没验证就交付，靠"感觉能跑"过关。
- 文档和代码各说各话，新人被误导。
hai-stack 把一套工作方法固定成可触发的能力，让想法、需求、实现和文档都能被检查、被验证、持续推进——降低和 AI 协作时的随意性。
核心方法论：一条从想法到交付的链
Idea → Frame → PRD → Goal → Architecture → TDD → Audit → Report
每一步都对应一个明确的问题。该判断时不急着写 PRD，该写目标时不急着动手，该验证时不靠感觉过关：
| 阶段 | 核心问题 | 对应能力 |
|---|---|---|
| Idea | 这个想法值得做吗？ | hai-idea |
| Frame | 方案是太怂、太飘，还是太繁？ | geju / goudi / hai-razor |
| PRD | 需要 PRD 吗？边界和粒度怎么定？ | hai-prd |
| Goal | 动手前，目标、阶段和验证是什么？ | hai-goal |
| Architecture | 复杂度藏在正确的边界里吗？ | hai-architecture |
| TDD | 行为先被测试定义，再被实现了吗？ | hai-tdd |
| Audit | 文档内部一致吗？文档和代码一致吗？ | hai-audit-docs-internally / hai-audit-docs-against-code |
| Report | 关键判断能被清楚展示和复用吗？ | hai-visual-report / create-visual-card |
这条链不是强制流程，而是一组随时可用的判断点。
对冲 AI 的方案偏差：治怂、治飘、治繁
Frame 阶段特意放了三个方向不同的技能，用来对冲不同 AI 编程助手的典型偏差：
geju（格局）· 治怂——主要给 Codex 用。Codex 常常过度考虑兼容性、历史包袱和局部实现形状，把方案做得小心翼翼。geju负责把它从"补丁化思维"里拉出来，先看清更干净、更高位的目标模型，再谈迁移和落地。goudi（苟帝）· 治飘——主要给 Claude Code 用。Claude Code 常常把方案想得太大、太飘，愿景很强但第一步不够扎实。goudi负责把宏大判断压实成可执行、可验证、可止损的最小推进。hai-razor（剃刀）· 治繁——用奥卡姆剃刀审视"存在的必要性"。对需求、字段、状态、模块、层逐个判定保留 / 合并 / 删除 / 延后，砍掉不能自证必要的概念，又不误伤真正承担责任的复杂度。
一句话：geju 把格局打开，goudi 把路踩实，hai-razor 把多余的东西砍掉。
能带来什么
对使用者来说，这套方法论带来的不是"AI 回答更长"，而是：
- 减少无效投入——用
hai-idea先判断想法值不值得，而不是每个点子都进入执行。 - 减少方案偏差——用
geju打开格局、goudi压实落地、hai-razor砍掉冗余。 - 减少需求返工——用
hai-prd判断是否需要 PRD、粒度是否合理、验收是否可验证。 - 减少中途改向的浪费——用
hai-goal把目标、阶段和 proof 写清楚再动手。 - 减少陷入局部最优的架构决策——用
hai-architecture从复杂度、边界和信息隐藏审视系统。 - 减少"补测试式自我安慰"——用
hai-tdd先看测试失败，再写最小实现。 - 减少文档失真——用文档审计技能保持文档内部一致、并与代码同步。
- 减少"结论写完就沉没"——用
hai-visual-report和create-visual-card把复杂内容变成能展示的产物。
技能一览
hai-* 是核心方法论技能，负责判断、定义、约束和验证；其余是支撑工具，负责具体审查、代码质量和展示产出。
判断与框定 · 先想清楚要不要做、方案对不对
| 名称 | 用途 | 收益 |
|---|---|---|
hai-idea |
判断一个想法值不值得做，给出 做 / 先验证 / 重塑 / 延后 / 砍掉 的明确结论和评分卡 | 先判断价值和机会成本，别让"听起来有趣"的点子白白吃掉时间 |
geju |
打开格局：给出高位方向 thesis、该删该合该拆的 kill-list、保守 vs 干净 vs 分阶段的选项和验证路径，收尾一张收益账单讲清为什么值得 | 治怂——先看清系统该成为什么，别被兼容和重构成本吓住 |
goudi |
苟帝：把宏大方案压成最小可验证的第一步，给出砍掉清单、成功/失败信号和止损规则 | 治飘——保留野心，但先证明它能落地 |
hai-razor |
用奥卡姆剃刀逐个审需求/字段/状态/模块/层，判定保留 / 合并 / 删除 / 延后 | 治繁——砍掉不能自证必要的概念，不误伤真正承担责任的复杂度 |
定义与规划 · 把边界、目标和数据模型写清楚
| 名称 | 用途 | 收益 |
|---|---|---|
hai-prd |
判断是否需要 PRD、从产品问题起草、打磨已有 PRD、判断 PRD 的拆分与合并 | 把所有 PRD 判断收敛到一个入口，先定边界粒度，再写清目标、范围和可验证验收 |
hai-goal |
动手前先产出 goal document：可验证目标、边界、阶段、带 proof 的 todo 和 Go/No-Go 判断 | 把"一边跑一边看"换成先写清路线和验证规则，减少中途返工 |
entity-model-auditor |
对照 PRD 逐字段审实体数据模型，输出目标 vs 现状对比表和迁移变更清单 | 开发前就对齐 PRD 与数据库，减少联调阶段的字段返工 |
架构与代码质量 · 让设计和代码经得起推敲
| 名称 | 用途 | 收益 |
|---|---|---|
hai-architecture |
基于 APoSD/Ousterhout 做架构审查：架构图、复杂度痛点、多镜头评审、why-not 备选和红蓝对抗 | 在架构决策阶段发现系统性复杂度，而不是停在局部代码风格 |
hai-naming |
命名顾问：给出 3-5 个候选 + 推荐名 + 三阶段推理链；做命名审查时给改名清单 | 好命名就是好设计，减少"读代码猜意图"的成本 |
react-component-diagnosis |
从 7 个维度给单个 React 组件出结构化体检报告，基于逐行读代码而非表面评价 | 一次诊断定位组件的结构性问题，避免反复重构 |
clean-code-reviewer |
基于《代码整洁之道》从 7 个维度出带严重度和重构建议的报告，只改实现不改行为 | 系统化代码体检，而不是凭经验零散挑问题 |
hai-ast-grep |
用 ast-grep 做结构化搜索 / 批量改写 / lint 守护：一次性搜索给 pattern 和命令，可复用场景产出带正反样例和验证命令的 YAML 规则 | 搜索和重构按语法树匹配而非文本正则，误报漏报大幅减少；可复用规则杜绝同类问题再犯 |
验证与一致性 · 用反复验证抵抗幻觉
| 名称 | 用途 | 收益 |
|---|---|---|
hai-tdd |
用红绿重构驱动实现，产出测试证据报告：失败的 RED、最小 GREEN、重构决策、验证命令 | 把"我觉得能跑"换成可重复验证的行为证据，减少补测试和返工 |
hai-audit-docs-internally |
审一份/一组文档内部的冲突、过期、术语漂移和重复，给 P0-P3 修复清单和修复顺序 | 先让文档自身自洽，别让读者被互相打架的段落误导 |
hai-audit-docs-against-code |
对照代码、配置和接口契约审文档，给出 P0-P3 的过时与不一致清单和最小修复 | 文档与实现保持同步，新人不再被过时说明误导 |
hai-rewrite-doc |
逐块核实漂移腐烂的文档：核实通过的保留原文，核实不过的直接移除，输出重写全文 + 保留/删除/待定处置表 + 遗留问题 | 核实即移除——不把错误内容修补成"看起来对"的版本，每个判定都有核实依据 |
hai-ssot |
诊断代码库的单一数据源（SSOT）违规：十类症状逐一排查，产出带 file:line 证据、诚实判定和治理配方的编号 findings 报告 | 多源定义、形状漂移、冗余转换在出事故前被点名；"不计违规"清单保住报告公信力 |
展示与交付 · 把结论变成能传播的产物
| 名称 | 用途 | 收益 |
|---|---|---|
hai-visual-report |
把想法/需求/评审/方案做成自包含的多 section HTML 报告：结构图、决策矩阵、风险表、下一步 | 不只是写总结，而是用图、矩阵、阶段把复杂判断讲清楚、可复用 |
create-visual-card |
把内容做成杂志级视觉卡片，输出自包含 HTML 并截成可分享的 PNG | 快速把文字变成可分享的精美卡片，适合社交传播和笔记归档 |
readme-beautifier |
接收杂乱 README，输出结构清晰、格式统一的版本，内容不增不减只改结构 | 一键美化，不用再纠结排版细节 |
快速安装
克隆仓库后，运行 make link 即可将所有技能以符号链接方式安装到 ~/.claude/skills/ 和 ~/.codex/skills/：
git clone https://github.com/hylarucoder/hai-stack.git
cd hai-stack
make link
其他管理命令：
make status # 查看各技能的安装状态
make unlink # 移除所有符号链接
新增技能后再跑一次 make link，已安装的会自动跳过。
怎么用
下面这些自然说法都能直接触发对应的技能：
这个想法是不是个好主意？值得做吗？
帮我把格局打开，不要被兼容性和重构成本吓住
这个方案太飘了，用苟帝模式压成可执行、可验证、可止损的第一步
这个需求是不是有点过度设计了？哪些字段/状态该砍掉？
帮我判断这个需求需不需要 PRD，要不要拆
先别一边跑一边看，帮我写一份 goal document 再开始
帮我从架构层面 review 一下这个模块的设计
帮我诊断一下这个 React 组件的架构质量
这个变量叫什么名字好？帮我起个名
这个功能用 TDD 来做，先写失败测试
帮我检查一下代码质量，看看有没有 code smell
对照这份 PRD，检查一下数据模型字段是否对齐
帮我检查 README 和代码有没有不一致的地方
帮我审一下这组文档内部有没有冲突、过期或该删的内容
这份文档讨论了好几轮已经烂了，按我们最新的结论重写一遍
帮我美化一下这个 README
给这个想法做一份可视化 HTML report
请你阅读这篇文章，最后生成一张视觉卡片
约定与结构
每个技能都自包含在自己的目录里：
skills//
SKILL.md # 执行源文件
SKILL.zh_CN.md # 中文阅读版（hai-* 技能必备）
references/ # 按需加载的参考资料、输出模板
scripts/ # 配套脚本（如截图工具）
语言约定：
SKILL.md是执行源文件，主体内容使用英文；SKILL.zh_CN.md是中文阅读版，两者冲突时以SKILL.md为准。- frontmatter
description可包含中文触发词，帮助中文请求匹配；用户可见的输出模板可按场景使用中文。 - 新增或重命名
hai-*技能时，必须同时提供SKILL.md和SKILL.zh_CN.md。
运行要求
仓库本身依赖很少：只是阅读和使用技能，不需要安装任何东西。要把 HTML 报告/卡片截成 PNG 时，需要 Node.js 和 Playwright。
推奨ツール
別のキーワードを試すか、フィルタを外してください。
インストール
npx skillfish add hylarucoder/hai-stack