Skip to content

01_Philosophy.md

Latest commit

 

History

History
220 lines (153 loc) · 6.43 KB

01_Philosophy.md

File metadata and controls

220 lines (153 loc) · 6.43 KB

SVP 设计哲学

问题本质

当前 AI 编码工具（Cursor、Claude Code、Copilot）直接在代码层工作，导致：

  1. 上下文溢出：大规模代码库超出 AI 上下文窗口
  2. 破坏性编辑：AI "修复"破坏了人类的设计意图
  3. 架构漂移：缺乏语义护栏，系统结构逐渐混乱
  4. Review 困难：人类需要审查成百上千行生成的代码

根本问题：AI 在错误的抽象层次上工作。

核心洞察

就像我们人类写程序时不管机器码一样，AI 不应该直接操作代码。

经典软件工程的启示

人类开发软件的分层过程：

需求/意图 → 架构设计 → 伪代码/详细设计 → 编码 → 汇编/机器码
    ↑                                              ↓
  人类只关心这些                          这些是廉价产物，可重新生成

关键认识：

  • 上层是源数据（Source of Truth）
  • 下层是派生产物（Derived Artifacts）
  • 修改应该发生在上层，下层通过重新编译获得

当前 AI 编码的谬误

用户 Prompt → AI 直接生成代码 → 人类 Review 代码
                    ↑
            问题：AI 在操作派生产物，
                  就像直接修改 .o 文件期望 .c 自动更新

SVP 的解决方案

分层编译模型

SVP 引入五层单向编译架构：

L5: Blueprint    (意图层)     人类编写 —— 为什么、做什么
       ↓ 编译 (AI)
L4: Logic Chain  (架构层)     人类审核 —— 流程、模块、接口
       ↓ 编译 (AI)
L3: Logic Block  (逻辑层)     人类审核 —— 伪代码、契约、约束
       ↓ 编译 (AI)
L2: Code Block   (骨架层)     只读审计 —— 函数签名、类型、占位符
       ↓ 编译 (AI)
L1: Code         (实现层)     派生产物 —— 完整可运行代码

核心原则

原则 说明
单向性 只允许从上到下编译，禁止反向修改
源数据在上层 L5-L3 是源数据，提交到 Git；L2-L1 是派生产物，可 CI 生成
人类编辑边界 人类只编辑 L5-L3，AI 负责编译到 L2-L1
重新编译优于修改 需要改代码？改 L3 然后重新编译，而非直接改 L1
可审计性 每层都透明可见，人类可以审查 AI 的编译结果

与现有方案的关系

MCP 的定位

  • MCP：解决 AI 的外部连接性（数据源、工具、API）
  • SVP：解决 AI 对内部代码的理解深度和操作边界
外部世界 → MCP → AI Agent → SVP → 代码库
                 ↑              ↑
               语境          视野控制

与传统工具的关系

层级 类似概念
L5 需求文档、产品 PRD
L4 架构图、流程图、C4 Model
L3 伪代码、UML 活动图、Design by Contract
L2 代码骨架、头文件/接口定义
L1 实际代码、可执行文件

SVP 的创新：将这些离散文档整合为可编译的中间表示（IR）。

价值主张

对开发者

  1. 意图驱动开发：关注"要解决什么问题"而非"怎么写代码"
  2. 架构可维护：高层设计显式化，不易被代码腐蚀
  3. AI 可控：AI 在边界内工作，人类保留最终决策权

对 AI

  1. 上下文可控：只在需要的层级和范围内工作
  2. 明确约束：契约和伪代码提供清晰的实现指南
  3. 可验证：编译结果可以通过静态分析验证

对团队

  1. 设计即文档：L5-L3 即是设计也是可执行规范
  2. 知识沉淀：领域知识和约束显式记录在 IR 中
  3. 协作界面：人类和 AI 在 L3 层协作（人类写伪代码，AI 实现）

类比理解

编译器类比

C 语言 → 编译器 → 汇编 → 机器码
  ↑                              ↓
人类编写                   机器执行
（高级抽象）               （底层细节）

SVP:
L3 伪代码 → AI 编译器 → L2 骨架 → L1 实现
   ↑                                         ↓
人类编写                               可运行代码
（业务逻辑）                            （实现细节）

建筑类比

L5: 建筑概念 —— "一座环保办公楼"
L4: 建筑图纸 —— 楼层规划、功能分区
L3: 结构详图 —— 承重墙位置、材料规格
L2: 施工蓝图 —— 每根钢筋的位置
L1: 实际建筑 —— 建成的办公楼

工人（AI）根据蓝图（L3）建造（L1）。
如果要改动，建筑师修改图纸（L3），重新施工（L1），
而不是让工人直接砸墙（改 L1）。

设计取舍

为什么选择严格分层？

替代方案：允许 AI 直接修改代码，SVP 作为"智能提示"

拒绝原因：

  1. 无法解决架构漂移问题
  2. 人类仍然需要 Review 大量代码
  3. AI 可能破坏隐含的设计约束

为什么 L3 是人类的最后一层？

  • L5 太抽象，难以指导具体实现
  • L4 描述流程，但不描述算法细节
  • L3 的伪代码 + 契约足够精确，又足够抽象
  • L2-L1 是机械转换，不需要人类干预

为什么不是双向同步？

提案：允许人类改 L1，自动同步回 L3

拒绝原因：

  1. 破坏单向性原则
  2. 从代码推导意图是难题（逆向工程）
  3. 鼓励"临时改一下"的坏习惯

未来愿景

短期（MVP）

  • TypeScript 项目支持
  • 命令行工具链
  • MCP 集成
  • 基础 VS Code 扩展

中期

  • 多语言支持（Python、Go、Rust）
  • 可视化编辑器（编辑 L4-L3 的流程图）
  • 版本迁移工具（现有代码库 → SVP）
  • 团队协作功能

长期

  • 意图编程：人类只写 L5，AI 自动推导 L4-L3
  • 领域语言：各行业有自己的 L5 DSL
  • 生态系统：共享的 L4 模式库、L3 算法库
  • AI 自主演进：AI 在 L3 层提出架构改进建议

总结

SVP 的核心不是"让 AI 写代码更快"，而是重新定义人类和 AI 在软件开发中的分工：

  • 人类：定义问题、设计架构、确立契约（L5-L3）
  • AI：将设计编译为可运行代码（L3→L1）
  • 两者协作：在 L3 层交汇——人类写伪代码，AI 实现它

这是一种回归经典软件工程方法论的尝试，同时充分利用 AI 的能力——不是让 AI 替代思考，而是让 AI 承担机械的实现工作。