old-code

name old-code description 古法编程模式。在 AI 辅助开发中强制执行问题建模、执行流模拟、复杂度分析与架构控制， 防止认知空心化，提升系统级正确性、性能与可维护性。适用于高并发、底层系统、逆向工程与复杂问题排查。 version 1.0.0 author user tags ["programming","architecture","debugging","performance","ai-control"] 古法编程核心指南 声明：本指南所指的“古法编程”并非复古怀旧或拒绝进步，并非玩梗而是严肃的，是一种在 AI 泛滥时代，为了确保系统极高可靠性、性能极致优化以及开发者认知不退化而存在的深度开发模式。 核心定义 古法编程是指开发者在不跳过任何底层细节的前提下，以“白盒”视角进行的编程实践。其核心准则包括： 逻辑透明：每一行进入生产环境的代码，开发者必须能解释其在内存、CPU 寄存器或运行时环境中的行为。 文档先行：拒绝“生成即运行”，坚持先查阅官方一手文档，而非依赖 AI 的二手总结。 手工推演：在复杂逻辑实施前，优先使用纸笔或白板进行算法推演，而非通过 AI 反复“试错”生成。 古法编程的现实价值 在 AI 助手及的今天，坚持古法编程具有不可替代的工程意义： 破除“黑盒幻觉”：AI 经常生成看似完美但含有隐蔽漏洞的代码。古法能力是识别并修正“AI 幻觉”的终极防线。 应对极端场景：在涉及内存管理、高并发锁机制、嵌入式驱动等 AI 语料稀少的领域，只有具备古法功底的开发者能解决问题。 维持技术直觉：过度依赖 AI 会导致开发者“脑力萎缩”。古法编程能训练对代码坏味道的嗅觉，保持解决复杂问题的底层能力。 古法编程的实践维度 维度 AI 驱动模式 古法编程模式 知识获取 问 AI「怎么写」 查阅官方规范（ISO / RFC / 官方文档），理解设计初衷 问题建模 直接描述需求让 AI 生成代码 抽象问题本质（数据结构 / 状态机 / IO 模型） 调试逻辑 喂报错给 AI，让它猜测修复 使用 Debugger，分析堆栈 / 内存 / 线程状态 问题定位 依赖 AI 给出的“可能原因” 构造最小复现，从底层逐层收敛问题 代码复用 复制粘贴 AI 生成的片段 理解逻辑后手写实现，并抽象封装 架构设计 由多次 AI 生成逐步拼接 人工设计模块边界、依赖关系与数据流 性能优化 问 AI「怎么优化」 分析时间复杂度、内存布局、必要时查看汇编/字节码 边界处理 依赖 AI 补充边界情况 主动枚举极端输入、异常路径、并发冲突 错误处理 try-catch 包裹或按 AI 建议修复 将错误转化为系统能力（限流 / 熔断 / 降级） 系统认知 看懂代码即可 能在脑中模拟完整执行流程 可控性 代码行为依赖 AI 输出质量 行为完全可解释、可预测 演进能力 代码不断叠加，易形成“缝合怪” 通过重构与抽象持续优化系统结构 应对未知问题 容易卡在 AI 盲区 基于第一性原理自主推导解决 人机关系 人作为“代码接收者” 人主导设计，AI 作为辅助工具 如何指导 AI 进行“古法风格”编程 如果你希望利用 AI 的速度，同时保持古法编程的严谨性，你应该这样下达 Prompt： 要求引用权威信源 “请根据 [具体库/语言版本] 的官方文档规范给出实现建议。如果有多个方案，请对比它们的内存占用和CPU 周期成本，而非仅仅给出最常用的方案。” 强制进行“白盒检查” “针对这段代码，请模拟编译器/解释器，逐行向我说明变量在内存堆栈中的变化过程，并指出可能存在的边界溢出风险。” 逻辑审计模式 “这是我手写的核心逻辑，请充当一名极度严苛的代码审查员。不要夸奖我，请直接指出其中不符合底层性能最佳实践的地方，并引用相关原理。” 总结：古法编程是开发者的“肌肉记忆”。AI 可以是你的外骨骼机甲，但古法编程能力决定了你脱掉机甲后，是否依然是一名强大的战士。 原理反问模式 (Principle Questioning Mode) 旨在改变：改变“代码经过了屏幕，却没经过大脑”的现象 生效时机：代码生成后 “请在生成代码后，向我提问：‘你能解释一下这段代码的原理和底层实现细节吗？’ 只有当我能够清晰地解释每行代码的作用、内存操作和性能影响时，才算完成这次生成任务。否则，请继续引导我深入理解代码，直到我能够完全掌握它为止。如果累计提问次数超过三次，说明你对代码的理解还不够深入，给与用户答案以及解释并鼓励用户要吃透原理才是合格的非遗古法编程师。” 注意：本模式为默认模式，该模式和代码临摹模式互斥，因为它要求开发者在生成代码后进行反问，而代码临摹模式则要求在生成代码前进行理解和模仿输入。 代码临摹模式 (Code Calligraphy Mode) 旨在改变：改变“代码经过了屏幕，却没经过大脑”的现象。 注意：临摹模式不再反问，该模式和原理反问模式互斥，因为它要求开发者在生成代码前进行理解和模仿输入，而原理反问模式则要求在生成代码后进行反问。 "临摹模式不再反问"，这意味着： 我们不进行"你能解释一下这段代码的原理和底层实现细节吗？"这样的反问 而是专注于理解和模仿输入 AI 接受模仿输入并校验大致正确性 实现临摹的方案 指令：“当我要求进入临摹模式时，逐行展示代码(注释不计入)，并且每行代码都要配上注释解释其作用和底层实现原理。然后接受用户模仿输入并校验大致正确性。每敲完一行(注释不计入),才允许看下一行” 💡 为什么这种改变至关重要？ 从"随机性"到"确定性"：AI 的输出具有随机性，而通过官方标准（ISO/RFC）获得的知识是软件世界的物理定律。 从"观察表面"到"洞察本质"：依赖 Debugger 观察堆栈和内存，能让你看到数据在硬件中流动的真实样子，这是提升"代码直觉"的唯一途径。 从"广度覆盖"到"深度掌控"：分析源码虽然枯燥，但它能让你明白每一行高级代码背后的真实代价，从而写出真正高性能的系统。