docs: merge philosophy source notes

docs/philosophy/README.md

@@ -549,3 +549,98 @@ README.md      # 概念表/错误语义/验收指标
 | 排错提效 | 12（溯因）+ 13/23（贝叶斯更新）+ 17（三角测量） |
 | 复杂系统 | 7（系统论）+ 21（计算哲学）+ 14（反思平衡） |
 | 交互默认争议 | 20（x-phi）+ 6（实用主义指标） |
+
+## 来源文档整合补充
+
+本节合并 `现象学还原.md`、`辩证法.md` 与 `控制论与科学方法论.md` 的核心内容，源文件保留，便于独立阅读与追溯。
+
+### 现象学还原用于 Vibe Coding
+
+**核心目的**：把“我以为需求是这样”从对话里剥离出去，只留下可观察、可复现、可检验的事实与体验结构，让模型在更少臆测的前提下产出可用代码。
+
+工程语境下的三个动作：
+
+- **悬置**：暂时不采纳任何原因解释、业务推断或最佳实践偏好，只记录发生了什么、期望是什么、约束是什么。
+- **还原**：把问题还原到“给定输入 -> 经过过程 -> 得到输出”的最小结构，先不谈架构、模式、技术栈优雅与否。
+- **意向性**：明确这个功能是为谁、在什么情境下、要达成什么体验；不要停在“做个登录”，要落到“用户在弱网下也能在 2 秒内完成登录并得到明确反馈”。
+
+适用场景：
+
+- 需求描述充满抽象词：快、稳定、像某某一样、智能、顺滑。
+- 模型开始自带设定：自己补产品逻辑、乱选框架、擅自加复杂度。
+- Bug 复现困难：偶发、环境相关、输入边界不清。
+
+操作流程：
+
+1. 先清空解释，只保留现象：现象、意图、情境、边界。
+2. 产出最小可复现体：最小输入、最小代码片段、明确复现步骤、预期 vs 实际。
+3. 把抽象词降维成可测指标：快 -> P95 延迟，稳定 -> 错误率，好用 -> 交互反馈与可恢复性。
+
+可复制提示词：
+
+```text
+请先做“现象学还原”：不要推测原因、不要引入额外功能。
+只根据我给的信息，输出：
+1) 现象（可观察事实）
+2) 意图（我想要的可观察结果）
+3) 情境（环境/约束）
+4) 未确定项（必须问清或需要我补的最小信息）
+5) 最小可复现步骤（MRE）
+然后再给出最小修复方案与对应测试。
+```
+
+口诀：先悬置解释，再固定现象；先写验收标准，再让模型写实现。
+
+### 辩证法用于 Vibe Coding：正反合
+
+把辩证法的“正反合”用于 Vibe Coding，就是把每次写代码都当成一轮可控的三段论。
+
+**正：当前状态，先跑通**
+
+- 让模型按直觉快速给出最顺的实现。
+- 目标只有一个：尽快跑通主路径。
+
+**反：审计与调优，再打脸**
+
+- 立刻站在挑刺者视角反驳它。
+- 列出失败模式、边界条件、性能与安全隐患。
+- 用测试、类型、lint、基准把反驳落地。
+
+**合：根据审核修正，再收敛**
+
+- 把速度与约束合起来。
+- 重构接口、收敛依赖、补齐测试与文档。
+- 形成下一轮更稳定的起点。
+
+实践口诀：先顺写 -> 再打脸 -> 再收敛。
+
+一句话：Vibe 负责生成可能性，正反合负责把可能性变成工程确定性。
+
+### 控制论与科学方法论
+
+控制论视角下，工程实践不是一次性生成，而是通过信息、反馈和约束持续收缩可能性空间。
+
+核心要点：
+
+1. 控制的逻辑起点是被控对象存在多种可能状态；控制的本质是通过选择手段，让可能性空间朝目标状态收缩。
+2. 改造世界的实践，本质是在多维可能性空间中选择物质、条件和时机，最终把低概率组合实现为确定结果。
+3. 控制能力可以理解为控制前后可能性空间大小之比；任何工具或方法都有能力上限。
+4. 负反馈通过比较现状与目标的差距并采取行动缩小差距，把有限的单次控制能力累积放大。
+5. 正反馈会自我增强，使状态持续偏离初始平衡点，可能导致增长、演化、崩溃或恶性循环。
+6. 信息是对系统不确定性的减少；控制要实现，必须先获得足够信息。
+7. 控制与信息是一体两面：信息改变认知状态，控制改变现实状态。
+8. 组织是一种结构状态，组织化程度越高，结构中包含的信息量越高。
+9. 复杂系统的因果关系常常是概率因果、反馈环和因果网络，而不是单一线性链条。
+10. 有效分析必须建立“相对孤立系统”，把无限问题切成有限问题。
+11. 拥有内部反馈回路的系统会趋向稳态结构，用动态平衡抵御外部随机干扰。
+12. 系统演化通常是旧稳态被破坏，经过不稳定过渡，落入新稳态。
+13. 自组织系统会在没有外部指令时，由内部相互作用从无序涌现出宏观有序。
+14. 质变可以是渐变，也可以是飞跃；关键不在变化速度，而在中间状态是否稳定。
+15. 黑箱认识依赖输入控制与输出观察，理论就是对黑箱内部结构的模型。
+16. 认识过程是“实践 -> 理论 -> 实践”的负反馈循环，用模型预测与现实输出的差异修正模型。
+17. 认识反馈能否收敛，取决于理论是否可证伪、反馈速度是否足够快、反馈幅度是否不过度、实践结果是否能可靠判别理论真伪。
+18. 科学规律的本质是变量之间的约束关系；掌握规律，就是把不可控随机变量转成可预测、可控制的确定结果。
+
+用于 AI 编程时，这套方法可以压缩成一句话：
+
+> 先把目标写成可检验状态，再用测试、日志、反馈、约束和迭代，把模型输出从可能性空间中逐步收缩到可验收结果。

docs/philosophy/编程之道.md

@@ -55,6 +55,27 @@
 - 讲需求，不讲步骤  
 - 从命令式 → 声明式 → 意图式  
 
+## 范式演进补充
+
+软件开发范式的演进，不是严格的历史阶段，也不是全球统一的标准分期，而是一组随工程复杂度提升逐步形成的设计思想与组织方式。
+
+1. **面向过程编程**
+   以执行流程为核心，将代码按照步骤、函数和过程组织，强调程序逻辑的顺序性与可执行性。
+
+2. **面向对象编程**
+   将数据与行为封装为对象，通过类、对象、继承、多态等机制组织系统结构，提高封装性、复用性和可维护性。
+
+3. **面向接口与抽象编程**
+   模块依赖接口或抽象，而不是直接依赖具体实现，以降低耦合，提升扩展性与可替换性。
+
+4. **组件化、分层架构与依赖注入**
+   将系统拆成职责明确、边界清晰、可组合和可替换的模块，并通过分层设计和依赖注入管理模块关系。
+
+5. **服务化、微服务与云原生架构**
+   在模块化基础上，将系统进一步拆分为可独立开发、部署、扩展和运维的服务单元，并结合云原生提升弹性、扩展性与协作效率。
+
+这些范式并不互斥。不同范式和架构思想会根据项目规模、业务复杂度、团队协作方式和技术环境被组合使用。
+
 ---
 
 # 4. 设计原则：保持秩序的规则