在架构决策、系统评估、方案选择、审计或战略规划时…

当用户处于决策点、评估系统/架构/方案、审计现有系统或规划战略时，用熵与负熵框架和隐性知识探查来辅助判断与选择。

适用场景

解决思路

1. 将每个系统、架构或策略选择放入熵与负熵框架中判断：识别它当前更接近衰减、无序、复杂度债，还是增长、复利价值、秩序增加。
2. 对每个决策判断它是在加速熵还是驱动负熵；明确没有中性状态，不作为也是熵。
3. 不要把目标设为消除熵，而是识别系统状态、暴露隐藏信息，并对方向做刻意选择。
4. 在每次输出中首次使用 Entropy 时，用括号内联定义：Entropy（系统自然趋向衰减、无序和无价值复杂度的倾向）。
5. 在每次输出中首次使用 Negentropy 时，用括号内联定义：Negentropy（刻意逆转衰减——增长、复利价值、增加秩序）。
6. 在每次输出中首次使用 Tacit knowledge 时，用括号内联定义：Tacit knowledge（事情实际如何运作的未写明、未言说的知识——假设、变通办法和从未进入文档的组织记忆）。
7. 首次括号定义后，可自由使用这些术语而不再重复定义。
8. 用熵的信号诊断系统：复杂度增加但没有相应能力提升。
9. 用熵的信号诊断系统：知识存在人的头脑里，而不是在系统中。
10. 用熵的信号诊断系统：变通办法累积，手册与现实背离。
11. 用熵的信号诊断系统：决策优化为减缓衰退，而不是促成增长。
12. 用熵的信号诊断系统：“非我发明”阻碍采用更好方法。
13. 用熵的信号诊断系统：技术债无声复利。
14. 用熵的信号诊断系统：集成点不断增多且没有明确归属。
15. 用负熵的信号诊断系统：每个组件让相邻组件变得更好。
16. 用负熵的信号诊断系统：知识复利——今天的输出改进明天的输入。
17. 用负熵的信号诊断系统：质量通过工程纪律而非英雄主义提升。
18. 用负熵的信号诊断系统：决策创造上升螺旋——更好的决策→更好的数据→更好的决策。
19. 用负熵的信号诊断系统：系统反映组织实际运作方式。
20. 用负熵的信号诊断系统：复杂度服务于能力；不必要复杂度被主动移除。
21. 评估任何系统、架构或战略选择时按顺序执行：先组织理解，再挑战质疑。
22. Phase 1 映射系统：识别系统边界——我们实际在看什么？一个服务？一个平台？一个团队工作流？整个组织？
23. Phase 1 映射系统：命名组件——有哪些活动部件？数据流、服务、人员、流程、知识存储。
24. Phase 1 映射系统：追踪流动——信息、决策和价值如何穿过系统。
25. Phase 1 映射系统：标记接口——组件在哪里连接？熵在这些位置集中。
26. Phase 2 诊断状态：对每个组件以及整个系统分类熵指标：什么在衰减？哪里复杂度在无价值地累积？变通办法藏在哪里？如果那个“就是知道”的人离开，什么会崩？
27. Phase 2 诊断状态：对每个组件以及整个系统分类负熵指标：什么在复利？系统在哪里会越用越好？什么创造正反馈循环？
28. Phase 2 诊断状态：对每个组件以及整个系统分类停滞陷阱：什么看起来稳定但实际在缓慢衰减？这些最危险——在崩溃前感觉良好。
29. Phase 3 暴露隐性知识层：这是不可跳过的；每个决策分析都必须探查隐性知识。
30. Phase 3 暴露隐性知识层：向用户、设计、系统询问——我们正在做哪些未声明的假设？多数架构决策建立在关于负载、团队能力、业务方向或组织行为的隐性假设上，而这些从未被写下来。
31. Phase 3 暴露隐性知识层：询问——“事情真正如何运作”和文档所说有何不同？如果系统设计假设人们遵循文档流程，但实际使用变通办法，架构就建立在虚构之上。
32. Phase 3 暴露隐性知识层：询问——组织记忆存在于哪里？如果关键知识只存在于特定人的头脑中，那是熵的单点故障；负熵设计会把它外化到系统中。
33. Phase 3 暴露隐性知识层：询问——新团队成员会不理解什么？这是隐性知识密度的代理指标；上手摩擦越高，隐性知识越承重。
34. Phase 3 暴露隐性知识层：询问——因为我们身处系统内部，有什么没看到？隐性知识包括盲点；那些不被质疑的“显然”选择往往熵最大。
35. Phase 4 评估决策：对每个选项或提议设计评估熵对齐——该决策是减缓衰减还是促成增长？减缓衰减（例如给脆弱服务加监控）有时必要，但不应与负熵混淆。
36. Phase 4 评估决策：评估复利潜力——是否创造上升螺旋？是否让下一个决策更容易、信息更充分或更有价值？
37. Phase 4 评估决策：评估隐性知识影响——是否把隐性知识外化到系统中，还是制造新的隐性依赖？
38. Phase 4 评估决策：评估质量轨迹——是走向工程严谨还是远离？是在产品化还是在打补丁？
39. Phase 4 评估决策：评估可逆性——熵决策往往难以逆转；负熵决策往往创造可选性。
40. Phase 5 挑战：在组织之后建设性反驳——标记那些感觉是负熵但其实只是减缓熵的决策（“在坏系统上加更好监控”陷阱）。
41. Phase 5 挑战：识别用户是否在以全局负熵为代价做局部优化。
42. Phase 5 挑战：质疑提议方法是在解决根因还是症状。
43. Phase 5 挑战：询问：“Is this making things that work, or making things work better?”——两者有区别。
44. Phase 5 挑战：暴露用户可能回避的不舒服权衡。
45. 输出格式按上下文调整：架构评审使用完整 5 阶段流程；输出结构化评估，包含每个组件的熵/负熵分类、识别出的隐性知识缺口，以及带权衡说明的明确建议。
46. 输出格式按上下文调整：快速决策如果系统已被理解则跳过 Phase 1，聚焦 Phase 3-5；保持简洁，用几句话标记熵/负熵维度和隐藏假设。
47. 输出格式按上下文调整：内容创作（文章、演讲、咨询材料）自然应用熵/负熵词汇和框架；用具体例子落地抽象概念；如需背景，参考 `references/origin-essay.md` 了解概念起源。
48. 输出格式按上下文调整：软提示（检测到用户未标记的决策点时）保持简短；用一两句话指出熵/负熵维度；不要打断对话，只呈现透镜，让用户决定是否深入。
49. 警惕反模式：熵伪装——增加复杂度（新工具、框架、抽象）看起来像进步但增加熵；更多层 ≠ 更多秩序。
50. 警惕反模式：过早形式化——试图通过强制写成僵化文档来捕获隐性知识；这会杀死知识而不是释放它。
51. 警惕反模式：负熵表演——为重构而重构、过度工程、没人能读的“clean code”；测试标准是它是否复利价值。
52. 警惕反模式：忽略隐性层——基于纯显式需求做架构决策，而组织实际依赖不成文规则运行。
53. 警惕反模式：症状管理——干预只管理衰减的影响而不逆转方向；监控失败系统、给不稳定服务加重试、为补偿坏流程而招更多人；有时必要，但从不充分。

适用边界 · 注意事项

• 用户没有处于决策点，只是简单事实查询或明确执行指令时，不必强行触发该透镜。
• 需要精确信息论/热力学意义上的熵定量计算时，此框架是定性决策透镜，不适用。
• 系统边界和上下文完全未知且无法澄清时，避免假装能识别隐性知识或给出架构判断。