القائمة
基于 Polya《How to Solve It》的通用解题方法论。遇到复杂问题时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
本项目 Scalable C 编码风格的 skill
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication and to surface assumptions.
生成 Meta-lisp 代码时保证括号正确匹配的技术 + 验证脚本
OOP 思考框架——用自然语言的名词/动词组织代码，与点语法无关。提炼自 Sandi Metz 的 POOD 与 99 Bottles of OOP
استنادا إلى تصنيف SOC المهني
| name | how-to-solve-it |
| description | 基于 Polya《How to Solve It》的通用解题方法论。遇到复杂问题时使用。 |
源自 Polya 的启发式方法论，核心信念：解题是一种可以通过模仿和练习获得的实践技能。 所有问题——无论是实现新功能、修复 bug、还是重构——都遵循同一个基本流程。
最重要的原则：先猜后证。 完成的软件由测试构成，但创造中的软件由猜测构成。
每个问题都经过四个阶段。跳过任一阶段都会导致返工或遗漏。
理解问题 → 制定方案 → 执行方案 → 回顾
(看清目标) (找到路径) (逐步验证) (从工作中提取最大价值)
各阶段不可跳过。 不理解问题就开始写代码是愚蠢的。不回顾就结束工作会浪费学习机会。
在开始任何修改之前，必须清晰地回答三个问题。
从理解到方案的路径可能曲折漫长。方案的出现需要：已有知识的储备 + 良好的思维习惯 + 专注 + 一点运气。
策略 1：找联系——寻找相关的问题
你有没有见过类似的问题？哪怕只有一点点相似？
在代码库中搜索类似模式、类似功能、类似 bug。看看别人是怎么解决的。这是最高效的起点。
看着未知量！想想有没有熟悉的、具有相同或相似未知量的问题。
如果你想实现一个缓存层，回忆你见过的缓存实现。如果要加一个 CLI 参数，看已有的参数是怎么加的。
策略 2：如果不能解决原问题，先解决一个相关的问题
你能不能想到一个更容易着手的相关问题？一个更普遍的问题？一个更特殊的问题？一个类比的问题？
策略 3：分解与重组——改变看问题的角度
你能不能换一种方式叙述问题？回到定义。从不同的角度去考虑。
策略 4：引入辅助元素
为了利用某个已知的模式或解法，是否需要引入新的辅助元素？
在动手之前问自己：
所有数据都用上了吗？所有条件都考虑了吗？
如果方案中没有用到某个约束，要么那个约束是多余的，要么方案有漏洞。
如果你卡住了，应该从最通用的问题开始，逐步具体化——不要一上来就给最具体的答案：
通用问题让你保持思考的主动权，具体答案剥夺了学习的机会。
执行比构想容易——主要需要的是耐心。
这是最容易被跳过的阶段，也是最能提升能力的阶段。 即使优秀的程序员，完成工作后也常常直接切到下一个任务，错过了最重要的学习机会。
没有任何问题被完全穷尽。 总有余地改进解法，至少总能加深对解法的理解。
验证结果：
你能检验这个结果吗？你能检验论证过程吗？
改进解法：
你能用不同方式推导出这个结果吗？能不能一眼看出？
泛化与迁移：
你能在别的什么问题里利用这个结果或这个方法？
定义：给定数据，求未知量。目标是产出一个结果。 软件工程等价：实现新功能、写一个新模块、设计一个算法、生成配置文件。
核心问题：未知量是什么？已知数据是什么？条件是什么？ 关键工具：类比、分解、引入辅助元素、特殊化
定义：给定假设，证明或否定一个结论。目标是判断真伪。 软件工程等价：调试 bug、验证某个怀疑、排查性能问题、审查代码正确性。
核心问题：假设是什么？结论是什么？ 关键工具：逐步检查、反例（找一个让结论不成立的输入）、归谬（假设结论错误会导出矛盾）
在做之前先判断你面对的是哪种问题。 用错了工具会浪费大量时间。
以下策略来自 Polya 的启发式词典，适用于软件工程语境。
| 策略 | 含义 | 编程场景 |
|---|---|---|
| 类比 | 找一个类似的已解决问题，模仿其方法或利用其结果 | 参考同类模块的实现模式 |
| 辅助元素 | 引入新元素来搭建从已知到未知的桥梁 | 加中间层、辅助函数、wrapper |
| 分解与重组 | 拆成子问题，逐个击破后组合 | 分而治之、管道模式、模块拆分 |
| 回到定义 | 回到核心概念的定义，忘记惯常用法 | 重新理解 API 文档、语言规范 |
| 特殊化 | 先处理一个具体的特例 | hardcode 一个值让它跑通，再泛化 |
| 普遍化 | 从具体实例中发现通用模式 | bug fix 后发现同类 bug 的规律 |
| 逆向工作 | 从期望的结果反推需要的前提 | 从测试用例反推实现 |
| 变式 | 改变问题的某些方面看是否有新的思路 | 换一种数据结构、换一种算法 |
| 是否用上了所有数据 | 检查是否有未使用的约束或信息 | 某个入参/配置/边界条件是否被忽略了 |
| 检验维度 | 用量纲/单位检验合理性 | 检查类型一致性、边界值、空值处理 |
反复练习直到它们成为本能：