前言

AI 生成代码已经相当成熟，但在实际项目落地中，仍然存在一个核心痛点：上下文碎片化。需求在传递过程中走样，设计与代码脱节，变更无法追踪——这些问题不是 AI 能力不足，而是缺少一套把各个 AI 节点串联起来的工程体系。

本文记录了一次关于”AI 编排式软件工厂”的产品构想与可行性讨论。

一、核心流程设计

整体流程可以概括为一条带反馈回路的流水线：

1
2
3

需求输入 → 需求文档化 → 需求颗粒化 → UI设计 → 代码生成 → 测试 → 交付
    ↑                                                              |
    └──────────────── 变更需求反馈回路 ◄──────────────────────────┘

各节点的职责划分如下：

阶段	动作	参与方
需求采集	结构化问卷/对话式收集	客户 + AI 引导
需求整理	补充/纠偏/确认优先级	人工
需求文档	生成 PRD/SRS 文档	AI
需求颗粒化	思维导图拆解为任务树	AI + 人工审阅
UI 设计	生成线框图/原型	UI AI（Figma/v0 等）
客户确认	调整原型	客户 + 人工
代码生成	前后端代码 + DB 设计	AI
自动测试	生成测试用例并执行	AI
问题修复	AI 修复 → 循环至通过	AI
变更管理	评估影响 → 生成迭代标识 → 按需跳过 UI 阶段	AI + 人工

二、可行性分析

技术已成熟的部分

需求文档化：大模型生成 PRD 已经相当可靠
代码生成：Cursor/Copilot 等工具已在生产环境验证
自动化测试：测试用例生成与执行有完整工具链
变更追踪：git + AI diff 分析完全可实现

有挑战的部分

需求颗粒化的准确性
AI 拆分颗粒度容易出错——要么太粗、要么错误理解业务边界。这个环节如果出错，后续全部受影响，是整个流程的最高风险点。

Figma 转代码的质量
这个短板正在快速缩小。Figma 最新提供的 MCP 接口，配合各类 AI，已经能生成相当完整的前端项目（缺少后端对接部分）。生成的代码可以直接作为基础在上面修改，不再需要从零重写。

跨节点上下文一致性
这是整个方案最核心的难点，也是下一节重点讨论的内容。

三、跨节点上下文一致性方案

问题本质

每个 AI 节点只看到局部，但决策需要全局。靠 prompt 传递上下文既消耗 token，又容易信息失真。

解决思路：项目知识核（Project Knowledge Core）

建立一份结构化项目状态树，所有节点读写同一份状态，而不是靠自然语言传递上下文：

ProjectState
├── meta          # 项目基本信息、版本、迭代标识
├── requirements  # 需求树（颗粒化后的节点，带状态和优先级）
├── decisions     # 关键决策记录（为什么这样设计）
├── entities      # 数据实体定义（DB schema 的语义层）
├── ui_contracts  # UI 组件与数据的契约（约定，不是代码）
├── constraints   # 技术约束（用什么框架、不能用什么）
└── changelog     # 每次变更的 diff 记录

每个 AI 节点的输入 = 当前任务 + 相关的 ProjectState 切片，输出 = 结果 + 对 ProjectState 的更新。

三个关键机制

1. 节点间传递”决策摘要”而非原始内容

需求文档很长，但传给代码生成 AI 的不是全文，而是精准的切片：

本次任务涉及的实体：[User, Order]
相关约束：[必须支持多租户, 用 PostgreSQL]
UI 契约：[订单列表页需要分页, 字段见 ui_contracts.order_list]
变更历史：[v1.2 新增了退款状态字段]

token 消耗可控，信息精准不失真。

2. 变更传播机制

需求变更时，不重新跑全流程，而是增量处理：

变更输入
  → AI 分析影响范围（哪些 requirements 节点受影响）
  → 标记受影响的下游节点为"待同步"
  → 按依赖顺序触发各节点更新
  → 人工只审阅"有变化的部分"

类似 git 的增量 diff，而不是全量重跑。

3. 实体定义作为语义锚点

数据实体（User/Order/Product）是整个项目的语义锚点。需求、UI、代码、测试都引用同一份实体定义。实体变更时，所有引用它的节点自动标记为需要重新检查。

技术选型参考

需求	可用方案
结构化状态存储	JSON + Git（天然版本追踪）
节点编排	LangGraph / 自研状态机
上下文检索	RAG（向量检索相关需求片段）
变更影响分析	依赖图 + AI 语义分析

LangGraph 特别适合这个场景，它本身就是为”有状态的多节点 AI 流程”设计的，节点间共享 state 是一等公民。

四、差异化与竞争分析

真正的护城河

这个产品的核心价值不是”用 AI 做开发”（这个太泛），而是：

把软件开发过程的”知识损耗”降到最低 —— 需求不走样、设计有据可查、变更有追踪

护城河在于：

行业垂直化的需求模板库 —— 深耕特定行业的需求语义
变更追踪和版本关联 —— 目前所有工具都没做好的部分
人工审阅节点的交互设计 —— 决定产品体验上限

与现有产品的差异

Lovable、Bolt、v0 等产品在做下半段（代码生成），而这个产品的差异化在上半段（需求工程 + 变更管理）。这段市面上没有人做好。

五、建议的切入策略

不要一次做完整链路，分阶段验证：

阶段一（验证期）
需求采集 + AI 文档化 + 思维导图颗粒化
→ 最容易出价值，可作为独立 SaaS 工具卖给产品经理

阶段二（扩展期）
接入代码生成 + 测试自动化
→ 目标用户需要有技术背景的团队

阶段三（完整闭环）
Figma 对接 + 变更管理
→ 此时竞争压力增大，但护城河也已建立

MVP 最简验证方式

先不做完整平台，用结构化 Markdown 文件模拟 ProjectState：

1
2
3

需求采集 → 人工整理成结构化 MD →
AI 读 MD 生成代码 → AI 读 MD 生成测试 →
变更时只改 MD 对应部分 → 重新触发受影响节点

手动跑通这个流程后，再考虑自动化编排。验证的核心问题是：ProjectState 的 schema 设计对不对，这比技术选型更重要。

总结

维度	评价
方向可行性	可行，赛道真实存在
技术成熟度	7.5/10，Figma MCP 的出现补强了短板
最大难点	跨节点上下文一致性
解决思路	结构化 ProjectState + 增量变更传播
建议切入点	先做需求管理 + 颗粒化，验证市场再扩展
核心差异化	需求工程 + 变更追踪，而非代码生成本身

这个方向的本质是在做软件开发的知识工程，AI 是执行者，结构化的项目状态是真正的资产。