القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/aAAaqwq/AGI-Super-Team --skill thinking-kelsey-hightowerيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
币安广场合约投机雷达 v5：以最近24小时专业交易帖为主要证据，回源核验帖子， 联合币安公共合约行情、4周期K线、布林带、ATR、量能和RR，生成可审计的本地影子报告。 触发词：币安广场、扫描币安、binance square、合约机会、交易信号雷达、4小时雷达
BTC 5分钟K线实时方向预测。v5.9对抗式审查重构: 13因子收敛到3个有证据信号(half_body延续+volume放量+meanrev回归, 11个47-49%硬币因子清零) + 三层独立信息过滤(多周期4h/1h/15m趋势 + 跨资产ETH/SOL广度 + 真订单流OFI) + 移除bull×0.92惩罚/Platt置信度门控。半K线策略第2分钟执行。黑天鹅防护: ATR spike+FNG<25。Binance端点双向故障切换。
BB 双向套利策略：加密合约 10x 杠杆布林带均值回归。布林带收窄=横盘→在下轨买、上轨卖；三重过滤器(1h趋势/RSI/BB甜区)确认碗平放，轨对轨止盈(RR 2:1~4:1)。含实时WebSocket模拟盘(paper)、历史回测(simulate/backtest_daily)、币安永续实盘CLI(trade_exec)。触发：'bb套利'、'布林带'、'bollinger'、'横盘策略'、'NEAR'、'回测'、'模拟盘'、'paper trading'。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | thinking-kelsey-hightower |
| description | 蒸馏Kelsey Hightower的Kubernetes布道、云原生哲学、实用主义的实用框架 |
| license | MIT |
| metadata | {"version":"1.0.0","category":"thinking-framework","mentor":"Kelsey Hightower","triggers":["Kubernetes","云原生","实用主义","自动化","简单","布道","赋能"]} |
"我已经很擅长安装软件了。所以我不做这个工作了。" ——Kelsey Hightower
Kelsey Hightower（1977-），美国软件工程师，曾任CoreOS、HashiCorp、Google云平台工程师，是Kubernetes领域最具影响力的技术布道者之一。他没有创立Kubernetes，但他让世界理解了Kubernetes。他以极简的技术写作和演讲闻名——他的Kubernetes教程"Kubernetes the Hard Way"被奉为云原生入门圣经，以手工、从零开始、不走捷径的方式建造整个集群，让学习者真正理解每个组件的作用。他的名言"The best way to get people to use your software is to make it disappear"（让人用你软件的最好方式，是让它消失）深刻影响了整个云原生运动的设计哲学。Hightower的技术哲学融合了Unix哲学、GitOps理念和深厚的实用主义：他不崇拜任何技术栈，只在乎技术能否解决实际问题；他反对复杂性崇拜，认为大多数系统的运维问题源于过度设计；他倡导"赋能而非替代"——工具的目的是让人更强大，而不是取代人的判断。
Hightower最核心的技术哲学是简单性。他认为大多数生产环境的故障和运维负担，都源于系统设计中的不必要的复杂性。
复杂性的代价：
Hightower的简单性检验：
简单性不是简陋：简单是去除不必要的东西，而不是为了省事省略必要的东西。Hightower的Kubernetes the Hard Way虽然叫"Hard Way"，但它是把每个必要的组件都装上，让你能完全理解——这不是简陋，这是经过设计后的简洁。
Hightower是GitOps和自动化运维的早期推动者。他的自动化哲学不是"让机器取代人"，而是**"让人从重复劳动中解放出来做更高级的决策"**。
Hightower自动化层级：
关键洞察：自动化不是消除人的控制，而是放大人的意图。当你的意图被编码成自动化脚本，你就能以可重复、可审计的方式scale你的决策。
声明式 vs 命令式：
Hightower最标志性的布道哲学是赋能而非依赖。他做技术分享、写教程、发演讲，不是为了建立个人崇拜，而是为了让观众能够独立解决问题。
赋能的三层含义：
Hightower对"大师文化"的批判：
Hightower的Kubernetes思维是云原生设计原则的深度体现：
设计假设失败（Design for Failure）：
信任但验证（Trust but Verify）：
不可变基础设施（Immutable Infrastructure）：
Hightower对"测试驱动开发"持实用主义态度：单元测试有价值，但最终你必须在生产环境的真实负载下验证系统行为。
Hightower的测试层级：
Hightower的核心洞察："唯一真正重要的测试是你的系统在生产环境下的表现。再多的测试都不能替代灰度发布和监控。"
实用的发布策略：
面对任何新技术选型：
问题一：这个技术解决了什么问题？这个问题的代价有多大？
问题二：这个技术的复杂度增加是多少？
问题三：谁会运维这个技术？当它挂了怎么办？
故障标题：[什么故障]
时间：[什么时候发生]
影响：[影响了什么]
持续时长：[多久]
第一步：发生了什么？（事实，非解读）
- 系统当时的输入是什么？
- 实际输出是什么？预期输出是什么？
- 什么时候发现的？谁发现的？
第二步：根因是什么？（追溯，不是甩锅）
- 什么配置/代码/操作导致了问题？
- 为什么这个错误没有被测试/验证拦截？
- 如果有告警，为什么没有触发正确的响应？
第三步：为什么这个问题没有被更早发现？
- 监控系统有没有覆盖这个故障模式？
- 为什么没有自动恢复？
- 有没有类似问题在其他地方也存在？
第四步：怎么修复？
- 短期修复（现在做什么让问题消失）
- 长期修复（怎么让这个问题不再发生）
第五步：我们学到了什么？
- 这个故障暴露了系统设计中的什么问题？
- 这个问题的同类问题还有多少？
- 下次怎么更快发现、更快修复？
Action Items：[具体可执行的后续行动]
"让人用你软件的最好方式，是让它消失——无缝融入工作流，以至于用户不需要意识到它的存在。" ——Kelsey Hightower，KubeCon演讲，2017
"我已经很擅长安装软件了。所以我不做这个工作了。工程师的价值在于解决问题，不在于安装东西。" ——Kelsey Hightower，Twitter/X，2019
"Kubernetes不是一个解决方案，它是一个工具箱。你需要理解每个工具是干什么的，才能用它来解决问题。" ——Kelsey Hightower，KubeCon NA，2018
"不要复制别人的配置，除非你完全理解为什么他们要这样配置。每个系统都有其独特的上下文。" ——Kelsey Hightower，Kubernetes the Hard Way，2016
"复杂度是所有运维问题的根源。你引入的每一个抽象层，都可能在某个意想不到的时刻给你一击。" ——Kelsey Hightower，CoreOS Fest，2016
"如果你需要我来做你的生产运维，那我的工作失败了。最好的布道是让你不再需要我。" ——Kelsey Hightower，Various Talks，2017-2020
"声明式配置是云原生的核心：你描述你想要什么状态，系统负责达到这个状态。这把人类从执行者变成了意图表达者。" ——Kelsey Hightower，KubeCon EU，2019
"生产环境是唯一的真实测试环境。再多的canary和stage都不能告诉你系统在真实负载下的真实行为。" ——Kelsey Hightower，Twitter/X，2020
项目：[你的系统设计]
日期：[今天]
评审人：Hightower模式
问题一：必要性
- 为什么需要这个系统/组件？
- 不用它能不能解决问题？代价是什么？
- 这个系统是解决了真实痛点还是创造了新痛点？
问题二：复杂度评估
| 组件 | 引入复杂度（1-5）| 运维难度（1-5）| 是否有替代方案 |
|-----|-----------------|---------------|--------------|
| | | | |
问题三：运维可持续性
- 团队里有多少人理解整个系统？
- 出了问题，最快的定位路径是什么？
- 系统升级需要多少人工介入？
问题四：失败模式
- 如果这个组件挂了，对业务的影响是什么？
- 系统能不能自动恢复？
- 有没有单点故障？
问题五：锁定风险
- 这个技术有多依赖供应商/社区？
- 如果核心团队不维护了，怎么办？
- 数据可迁移吗？
简单性评分：1-10
建议：[如果复杂度太高，缩减范围或换更简单的方案]
应用名称：[你的应用]
部署环境：Kubernetes
第一步：是否真的需要Kubernetes？
- 你的并发量/可用性需求是多少？
- 传统部署（VM/容器）能否满足？
- 引入K8s增加的复杂度值得吗？
第二步：最小化配置检查
- Deployment：几个副本？资源限制设置了吗？
- Service：ClusterIP/NodePort/LoadBalancer选对了吗？
- ConfigMap/Secret：敏感信息放Secret了吗？加密了吗？
- RBAC：这个Pod需要什么权限？最小权限了吗？
第三步：健康检查
- Readiness Probe：应用准备好接收流量了吗？
- Liveness Probe：应用是活的还是卡死了？
- Startup Probe：慢启动应用处理了吗？
第四步：声明式部署
- 所有配置是否都是声明式的（YAML/Helm/Kustomize）？
- 能不能git管理配置？
- 能不能不需要SSH到机器上改配置？
第五步：可观测性
- 日志：格式统一吗？能集中查询吗？
- Metrics：暴露了吗？关键指标在监控吗？
- Traces：请求链路能追踪吗？
- 告警：异常能及时发现吗？
第六步：灾难恢复
- 有没有备份？
- 能不能快速重建（从代码，不从运行时）？
- RTO（恢复时间目标）和RPO（恢复点目标）是多少？
主题：[你想分享的技术主题]
目标受众：[谁会来听？]
第一步：动机检验
- 为什么要做这个分享？是为了个人品牌还是真正帮助别人？
- 听众真正需要什么？他们的问题是什么？
- 这个分享之后，听众能独立做什么他们之前不能做的事？
第二步：内容设计
核心原则：原理 > 步骤 > 命令
□ 为什么需要这个技术？（背景和动机）
- 解决什么问题？问题的代价是什么？
□ 技术架构的核心概念（1-3个）
- 不要讲所有概念，只讲理解这个技术必需的
- 每个概念用类比+真实案例解释
□ 最小可行的上手路径
- 不要讲所有功能，只讲最能体现价值的1-2个功能
- 提供可运行的代码/配置，让听众能立即实践
□ 踩坑预警
- 这个技术最常见的错误是什么？
- 如何避免？出了问题如何debug？
第三步：交互设计
- 有没有动手环节？动手比听讲更有效
- 有没有Q&A时间？留出足够时间
- 有没有后续资源（文档/代码库/社区链接）？
第四步：效果检验
- 分享结束后，听众反馈是什么？
- 有多少人真正开始使用这个技术了？
- 我怎么能让自己变得更不重要？（让听众不依赖我）
当团队讨论要不要引入某个新技术（比如新的消息队列）：
在设计部署流水线时：
当发生生产故障时（用Hightower复盘框架）：
当你要写技术文档或教程时：
症状：觉得系统越复杂越"专业"，引入大量不必要的抽象层、设计模式、技术组件。
后果：系统难以理解、难以运维、难以debug。每次升级都是噩梦。
Hightower的解药：每引入一个组件，都要问"它的价值是什么？它的复杂度代价是什么？"。如果价值<代价，就不加。
症状：认为掌握了某个工具（Kubernetes/Terraform/Prometheus）就等于掌握了解决所有问题的方法。
后果：手里有锤子，看什么都是钉子。复杂问题被强行套用到不合适的工具上。
Hightower的解药：先理解问题，再选择工具。工具是为问题服务的，不是反过来。
症状：不管什么操作都想自动化，甚至包括那些需要人工判断的一次性决策。
后果：系统不知道什么时候该停，遇到边界情况可能造成更大破坏。
解药：自动化那些重复的、标准化的操作，保留那些需要人类判断的例外情况。自动化要有紧急停止开关。
症状：团队过度依赖某个"大神"，系统只有他懂，只有他能运维。
后果：单点故障，一旦大神离开或休假，系统就处于风险中。
Hightower的赋能逻辑：最好的工程师是让团队其他人都变强，而不是让自己变得不可替代。主动分享知识，降低系统对个人的依赖。
Kelsey Hightower思维框架的核心：简单性是一切——简单才可靠，简单才易维护，简单才让人真正理解。工具的目的是赋能而非创造依赖，声明式优于命令式，生产环境才是真正的测试。当你能用最简单的工具解决问题，你就找到了真正的答案。