基于文娱游戏的可掌控抽象编程
超越"教你写代码"
EFCAP 不是"教你写代码"。它是一门关于如何在 AI 时代真正重获工程控制权的实践课程 —— 以游戏开发为训练载体。
为什么是游戏？
为什么选择文娱游戏作为实践载体
真实的系统复杂性
状态、反馈回路、性能约束、行为设计 —— 与真实工程系统结构同构。
高密度反馈
错误迅速暴露。抽象无法隐藏。决策质量在系统行为中立即可见。
低现实风险
安全地将系统推向失败。从崩溃中学习，没有商业后果。自由实验。
课程结构
控制权迁移的三个阶段
第一阶段
控制权归属：主要在 AI / 框架 / 示例
学习内容
- CAP/CAPI 导论与工程直觉恢复
- 状态来源与行为触发器 —— "说出发生了什么"，而非"它怎么编码的"
- 解构 AI 生成的结构：核心逻辑 vs. 包装
- 抽象代价意识：理解抽象 ≠ 进步
- 系统映射（非技术性可视化表达）
- 失败即学习：拥抱不受控实验
关键产出
- 整体描述系统结构与行为
- 行为修改记录（安全 vs. 不安全）
- 识别系统中不可控的部分
- 任意格式的系统图
- 公开系统讲解与同伴反馈
🔓 进入第二阶段的门槛：能整体描述系统 · 区分观察与猜测 · 识别个人控制边界 · 理解修改 ≠ 判断
第二阶段
控制权归属：迁移至核心逻辑、模块边界、状态管理
学习内容
- 关键控制点识别 —— "如果这里坏了，一切都坏了"
- 设计失败解构：为什么补丁会叠加
- 超越语法的结构：隐藏的耦合识别
- 设计权衡：拒绝诱人的"更高级"方案
- 多轮代码评审：解释你为什么敢改
- 破坏性需求注入：测试变更响应能力
关键产出
- 3+ 个关键控制点标注
- 识别自己的"补丁化"代码模式
- 书面控制边界澄清
- "不敢碰"区域文档
- 明确的"AI 搞不定"清单
- 完整的判断依赖链
🔓 进入第三阶段的门槛：关键控制点已掌握 · 修改时承担责任 · 能说出"我控制 X，我不控制 Y" · 他人向你请教判断 · 修改行为已变谨慎
第三阶段
控制权归属：完整的系统结构、抽象层级、复杂性、责任
学习内容
- 判断主体与责任边界
- 复杂性管理：定义"值得保留"的复杂性
- 设计可辩护性：面对反对意见为选择辩护
- 工程表达：为未来的自己和团队编写文档
- 真实工程约束与资源受限下的重构
- 系统演化（非重写）：保护前期判断
- AI 的最终定位：确认判断边界
关键产出
- 书面控制范围与设计辩护文档
- 刻意删除"酷功能"（复杂性所有权）
- 团队预防性修改指导
- 淘汰管理文档
- AI 能/不能清单（终版）
- 最终项目答辩：判断不可收回声明
- 工程判断力手册 —— 可迁移
适合你，如果……
本课程适合你
- 你有 IT/CS 背景，但缺乏系统级控制信心
- 你能完成项目，但从未掌握核心抽象决策
- 你已离开实践一段时间，感到判断力在退化
- 你想恢复工程直觉和系统感知
- 你愿意为设计决策承担后果
- 你想让 AI 服务于你的判断力，而非取代它
不适合你，如果……
诚实的边界
- 你追求速度、证书或就业保证
- 你只想停留在工具使用层面
- 你不愿思考结构和责任
- 你期望"在 Y 周内学会框架 X"
"如果你适合这条路，你会清楚地知道为什么。如果不适合，你也会在不被消耗的情况下得到答案。"
成果
你将收获什么
真实的系统理解
不是记忆模式 —— 而是真正理解系统为什么这样构建。
判断力权威
自信地修改系统、捍卫设计选择、拥有架构决策的能力。
可迁移的控制力
你的判断力可迁移到 Web、SaaS、AI 应用、数据平台、创业 —— 任何工程领域。