一套面向 AI 编程助手的工作方法论：先判断，再定义；先写清楚，再执行；先验证，再交付。
hai-stack 不是一堆零散的 prompt，也不只是一个 skills 目录。它是一套让 AI 助手更像可靠合作者的工作系统：帮你判断想法、框定方案、定义 PRD、写清目标、审视架构、用测试驱动实现、同步文档，并把关键结论变成能被别人读懂的报告。
这些 skill 会在 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 |
这条链不是强制流程，而是一组随时可用的判断点。
Frame 阶段特意放了三个方向不同的 skill，用来对冲不同 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先看测试失败，再写最小实现。 - 减少文档失真——用文档审计 skill 保持文档内部一致、并与代码同步。
- 减少结论不可传播——用
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 个维度出带严重度和重构建议的报告，只改实现不改行为 | 系统化代码体检，而不是凭经验零散挑问题 |
ast-grep-rule-crafter |
写 ast-grep YAML 规则做结构化搜索 / lint / 自动改写，附正反样例和验证命令 | 把一次性手工查改变成可复用的 lint/codemod，杜绝同类问题再犯 |
| 名称 | 用途 | 收益 |
|---|---|---|
hai-tdd |
用红绿重构驱动实现，产出测试证据报告：失败的 RED、最小 GREEN、重构决策、验证命令 | 把"我觉得能跑"换成可重复验证的行为证据，减少补测试和返工 |
hai-audit-docs-internally |
审一份/一组文档内部的冲突、过期、术语漂移和重复，给 P0-P3 修复清单和修复顺序 | 先让文档自身自洽，别让读者被互相打架的段落误导 |
hai-audit-docs-against-code |
对照代码、配置和接口契约审文档，给出 P0-P3 的过时与不一致清单和最小修复 | 文档与实现保持同步，新人不再被过时说明误导 |
| 名称 | 用途 | 收益 |
|---|---|---|
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-name>/
SKILL.md # 执行源文件（英文为主，是事实源）
SKILL.zh_CN.md # 中文阅读版（hai-* 技能必备）
references/ # 按需加载的参考资料、输出模板
scripts/ # 配套脚本（如截图工具）
语言约定：
SKILL.md是执行源文件，主体内容使用英文；SKILL.zh_CN.md是中文阅读版，两者冲突时以SKILL.md为准。- frontmatter
description可包含中文触发词，帮助中文请求匹配；用户可见的输出模板可按场景使用中文。 - 新增或重命名
hai-*skill 时，必须同时提供SKILL.md和SKILL.zh_CN.md。
仓库本身依赖很少：只看技能说明不需要安装任何东西。要把 HTML 报告/卡片截成 PNG 时，需要 Node.js 和 Playwright。