AI时代如何从代码提取产品规范实现自动化开发

千纸鹤Amanda

1. 从代码到AI可理解的产品规范：Spec提取与执行实战

在AI辅助开发逐渐成为主流的今天，我们面临一个根本性问题：AI如何真正理解一个产品的业务逻辑？传统开发模式下，新加入的工程师需要花费大量时间阅读文档、理解代码，而AI面临同样的困境。本文将分享我们通过SpecExtract和SpecExecute两个核心技能构建的解决方案——直接从产品代码中提取机器可读的规范（Spec），并实现基于Spec的自动化变更执行。

这个方案已经在真实项目中验证，成功从代码库提取出28个action、8个entity和4个rule的完整产品规范，并实现了包括添加compress参数、新建pdf_password模块在内的Delta变更。下面我将详细拆解这套方法的技术实现和实操要点。

2. 为什么需要Spec驱动开发

2.1 传统开发模式的效率瓶颈

在常规开发流程中，每当需要为一个产品添加新功能时，开发者必须经历以下循环：

code复制产品A新功能 → 理解产品A（3天） → 写代码（2天）
产品B新功能 → 理解产品B（3天） → 写代码（2天）
...

实际观察表明，开发者80%的时间花费在"理解产品"而非"编写代码"上。这种低效主要源于四个结构性问题：

文档不完整：需求文档通常只说明"做什么"，很少详细描述"怎么做"
文档代码脱节：代码变更后文档往往不及时更新
知识隐性化：产品逻辑存在于开发者头脑中，人员变动导致知识流失
AI理解障碍：现有AI工具能写代码，但无法理解产品业务上下文

2.2 AI时代的放大效应

在AI辅助开发场景下，这些问题被进一步放大。考虑一个典型场景：

用户对AI说："帮我把VIP的API配额改成无限"

传统AI开发流程会这样处理：

code复制用户指令 → AI生成代码 → 执行

但由于缺乏产品规范理解，AI可能：

错误修改了非VIP用户的配额
忽略了配额变更需要审计的要求
破坏了现有的配额计算逻辑

2.3 Spec驱动的解决方案

我们提出的解决方案是通过Spec建立产品理解的中间层：

code复制产品代码 → SpecExtract → 机器可读的Spec → AI基于Spec开发和定制

这套方案的核心价值在于：

对开发者：将产品知识显式化，减少重复理解成本
对AI系统：提供结构化的产品规范，使AI能做出符合业务逻辑的决策
对产品维护：保持代码与规范同步，降低维护成本

3. 核心能力架构

3.1 两大核心技能

我们的系统提供两个关键能力：

技能	功能	技术特点
SpecExtract	从代码提取规范	静态分析+动态追踪结合
SpecExecute	执行规范变更	差异计算+安全校验

3.1.1 SpecExtract工作流程

代码扫描：解析源代码构建AST（抽象语法树）
行为追踪：运行时记录API调用关系
规则提取：识别业务约束条件
规范生成：输出标准化的Spec文档

3.1.2 SpecExecute工作流程

变更提案：解析用户需求生成proposal.md
差异计算：对比现有Spec生成delta.md
安全校验：验证变更不违反核心规则
代码生成：输出最小变更集

3.2 与OpenSpec的差异

虽然借鉴了OpenSpec的格式，但我们的系统有本质不同：

维度	OpenSpec	我们的方案
目标	人类协作	AI驱动
来源	需求文档	产品代码
更新	手动维护	自动同步
粒度	功能级	代码级

4. Spec规范详解

4.1 目录结构设计

规范的目录结构设计考虑了可扩展性和机器可读性：

code复制specs/{product}/
├── SPEC.md              # 产品概览
├── actions/            # 操作定义
│   └── action_*.md     # 每个操作单独文件
├── entities/           # 数据实体
│   └── entity_*.md     # 每个实体单独文件  
├── rules/              # 业务规则
│   └── rule_*.md       # 每条规则单独文件
└── changes/           # 变更记录
    └── {change-id}/
        ├── proposal.md # 变更背景
        ├── delta.md    # 规范差异
        ├── design.md   # 技术方案
        └── archive.md  # 执行结果

4.2 文件内容规范

4.2.1 Action文件示例

markdown复制# action_user_login.md

## Description
处理用户登录请求

## Scenarios
1. 正常登录
   - Precondition: 用户已注册
   - Steps:
     1. 提交用户名密码
     2. 验证凭证
     3. 生成会话token
   - Output: 登录成功响应

2. 密码错误
   - Precondition: 用户已注册
   - Steps: [...]
   - Output: 错误提示

4.2.2 Entity文件示例

markdown复制# entity_user.md

## Fields
- id: string (required)
- name: string (max:100)
- roles: array<RoleEnum>

## Constraints
- 用户名必须唯一
- 密码强度要求：至少8字符，含大小写和数字

4.2.3 Change Proposal示例

markdown复制# proposal.md

## Change Request
添加PDF文件密码保护功能

## Reason
客户需要符合ISO27001对敏感文档的保护要求

## Impact Analysis
- 新增pdf_password模块
- 修改文件上传逻辑
- 新增密码强度校验规则

5. 实战案例解析

5.1 Spec提取过程

以提取PDF处理模块规范为例：

代码扫描：
- 识别出PDFProcessor类
- 解析出compress(), encrypt()等方法
- 提取方法参数和返回值类型
行为追踪：
- 记录实际调用时的参数范围
- 捕获异常处理逻辑
- 分析性能特征
规则提取：
- 发现加密需要至少8位密码的约束
- 识别压缩率限制在50-90%之间
规范生成：
- 生成action_pdf_compress.md
- 生成entity_pdf_file.md
- 生成rule_pdf_security.md

5.2 变更执行示例

需求：为PDF压缩添加密码保护

变更提案：

markdown复制# changes/pdf-password/proposal.md
## Change Request
在compress操作中添加密码参数

差异计算：

markdown复制# changes/pdf-password/delta.md
## actions/pdf_compress.md
+ Parameters:
+   password: string (required, min:8)

代码生成：

python复制# 生成的新代码
def compress(file, ratio, password=None):
    if password:
        validate_password_strength(password)
    ...

6. 关键实现技术

6.1 静态代码分析

使用ANTLR解析多种语言的语法树，关键步骤：

词法分析：将源代码转换为token流
语法分析：构建AST抽象语法树
语义分析：识别类、方法、依赖关系
模式匹配：识别特定业务逻辑模式

6.2 动态行为追踪

基于AOP（面向切面编程）的实现：

java复制@Around("execution(* com.example..*(..))")
public Object traceMethod(ProceedingJoinPoint pjp) {
    String method = pjp.getSignature().getName();
    Object[] args = pjp.getArgs();
    
    // 记录调用信息
    SpecRecorder.record(method, args);
    
    return pjp.proceed();
}