写在前面从一个真实的场景说起上周我们团队用 Claude Code 做了一个小功能。编码阶段前后加起来一天半就写完了。但你猜从需求提出来到真正上线花了多久两周。为什么会这样我把整个过程拆开看了看产品写 PRD 花了 3 天中间跟架构师对了两轮方案技术方案写了 2 天因为要翻历史文档、查已有接口、确认数据库规范编码 1.5 天这部分确实快AI 帮了大忙代码评审 1 天来回改了几轮测试写用例 跑 2 天中间还补了几个边界场景发布排期 灰度 2 天等窗口、等验证你看编码只占了不到 20%。AI 把写代码这件事的效率提上去了但前后的环节还是老样子该慢的地方还是慢。更让人头疼的是每个环节之间的信息传递基本靠人传人产品写的 PRD 开发要重新理解一遍开发写的代码测试又要重新理解一遍等到了发布的时候谁也说不清这个需求到底改了哪些东西、风险点在哪。这就是我们做这个平台的初衷。不是要做一个更厉害的编码工具而是要把 AI 从一个点的工具变成一条线上的生产力让它贯穿从需求到上线的每一步。我们到底在解决什么问题先别急着讲架构我想先把问题说清楚。现在市面上 AI 编码工具很多Claude Code、Cursor、Copilot各有各的长处。但用了一圈你会发现它们解决的都是写代码这一件事。而产研流程里写代码只是其中一环。问题一AI 只解决了一个点没有解决一条线编码速度提上去了但需求理解偏差、技术方案遗漏、测试覆盖不足、发布回归出问题这些事儿一样没少。反而因为编码快了下游的瓶颈更明显了。就像一条马路前面的路口畅通了后面的红灯没变整体通行效率还是上不去。问题二上下文在每个环节都在丢失产品写的 PRD 在文档系统里架构师的方案在 wiki 上代码在 GitLab测试用例在 TestLink。每个环节的人各写各的各理解各的。到了 AI 这儿更麻烦每换一个环节AI 都要从零开始理解项目你得把 PRD 粘一遍、把代码 一遍、把规范再说一遍。上下文没有结构化的传递全靠人工搬运效率低不说还容易丢东西。问题三质量门禁基本靠人拍脑袋代码评审过没过单测覆盖率够不够压测有没有问题这些事情目前基本靠人工确认。评审人说过了就过了测试说没问题就没问题没有可度量的、自动采集的证据链。发布的时候一问三不知全凭感觉放行。这三个问题就是我们做这个平台要解决的核心问题。不是更快的电钻是一条装配流水线我经常用一个比喻Claude Code 是一把很好的电钻钻孔速度快、精度高。但如果你要造一辆车光有一把好电钻是不够的你需要一条装配流水线把工序、质检、物料流转都串起来。我们的平台就是这条流水线。它的核心思路可以用一句话概括不是 AI 帮你写代码而是 AI 贯穿从需求到上线的每一步每一步都留下可追溯的产物。展开来说有这么几个核心的价值点。全链路上下文不丢失传统模式下信息散落在各个系统里PRD 在飞书、方案在 Confluence、代码在 GitLab、测试在 TestLink。AI 每次干活都得从零开始你得手动把上下文粘进去。在这个平台上所有的知识都沉淀在一个统一的知识库里。Spec 契约、CodeGraph 索引、历史 PRD、框架方案、开发规范全部结构化管理。每个 AI 节点启动的时候平台会自动根据当前阶段把相关的上下文注入进去不用你手动粘。举个例子到了编码阶段AI 自动加载对应的 PRD、Tech Spec、包结构规范、API 规范、CodeGraph 索引。你不用跟 AI 说我们的表都要有 tenant_id 字段它早就知道了。节点之间的产物自动传递流水线有 7 个节点每个节点的产出物就是下一个节点的输入。不用人工搬运不用来回导文件。需求登记填的信息直接进需求生成 Agent 的首轮对话。需求生成的 PRD技术方案节点直接读。技术方案里的 DB 契约和 API 规范编码节点直接用。编码的变更集评审节点直接审。评审的缺陷清单测试节点直接参考。测试的报告发布节点直接当门禁证据。整个链条是通的不是一截一截的。质量门禁自动化这一点我觉得特别重要。以前的质量门禁基本靠人盯开发说我测过了测试说覆盖率够了发布就放行了。出了问题再回头找谁也说不清当时是怎么过的。在这个平台上门禁证据是自动采集的。准入门禁代码评审通过率、单测覆盖率、压测结果这些指标自动从上个节点拉过来达标了才能进下一个节点不达标就卡着。放行证据链发布节点不用问来问去直接展示门禁证据冒烟通过38 个单测全过压测达标。有据可依不是拍脑袋。灰度发布加监控按流量百分比逐步放量20%、50%、全量灰度期间监控指标有问题一键回滚。全局看得见能量化有了流水线就有了数据。每个需求在哪个节点、卡了多久、谁在负责全部看得见。看板视图看板、列表、甘特图三种视角实时反映需求在全流程中的位置。不用天天开站会问进度看板上一目了然。报表统计按人产出统计、阶段分布、部门对比、趋势同比环比、热力图。管理层要量化团队效能直接从报表里拿数。SLA 监控每个需求在每个节点都有时效跟踪超时了自动预警。不用等到延期了才发现不对。AI 工具不绑死想换就换新建需求的时候你可以选编码智能体Claude Code、OpenCode、Z.ai、Devin想用哪个用哪个还能多选并行对比。平台不跟任何一个工具强绑定后面哪个工具火了接进来就行。这一点其实是个架构决策。工具迭代太快了今天 Claude 最强明天可能就有别的出来。把鸡蛋放一个篮子里风险太大。跟直接用 Claude Code 到底有啥不一样这个问题被问得最多。很多人说不就是用 Claude Code 吗我自己也能用为啥还要整个平台我从几个维度说说我的理解。覆盖范围不一样直接用 Claude Code覆盖的只有编码这一步。需求你得自己写方案你得自己出测试你得自己搞发布你得自己弄。Claude Code 是第七步之前的第四步只占了一小段。平台不一样7 个节点全覆盖。从你把需求登记进去开始到最后上线完每一步都有 AI 参与每一步都有结构化的产出。上下文管理不一样你自己用 Claude Code每次开新对话都得重新说一遍项目背景。“我们是做什么的用什么技术栈表结构是怎样的有哪些规范”说一遍就得好几分钟还经常说不全。在平台上这些都在知识库里存着。Spec 契约、CodeGraph 索引、历史 PRD、框架方案全部按节点自动注入。AI 一上来就知道user.profile.v2是干啥的、user.auth.spec里有哪些约束、哪些接口已经废弃了。而且 CodeGraph 能告诉你这个改动会影响多少文件、多少符号不是瞎猜的。质量和流程管控不一样自己用 Claude Code代码写得好不好、测试够不够、能不能上线全靠开发者自觉。没人给你把关全凭经验。平台不一样节点之间有门禁。代码评审不通过进不了测试测试覆盖率不够进不了发布。AI 评审加人工评审双模式结论都留痕可追溯。发布有灰度、有监控、有回滚不是拍脑袋就上了。团队协作不一样Claude Code 是个单人工具你在你的电脑上用我在我的电脑上用各干各的。团队协作基本靠开会、靠文档、靠口口相传。平台是多人协作的。看板是共享的大家都能看到需求在哪。统计是按人按部门的谁产出多少一目了然。知识是沉淀的新人进来翻一翻历史 PRD、看一看 CodeGraph 索引很快就能上手。一句话总结Claude Code 是平台在编码节点调用的一个智能体仅此而已。平台干的事儿是把 7 个节点串成流水线管理产物传递和门禁统一知识库和上下文做质量治理和效能度量然后把 AI 编码工具做成可插拔的。还是那句话电钻再好也替代不了流水线。整体架构长什么样说了这么多概念来看看具体的架构。整体是个分层的结构从上到下一共 5 层。我从上往下说。最上层给人用的界面也就是前端展示层。用户能看到的、能操作的都在这一层。主要有这么几块需求登记表单一切的入口用户在这里填需求的基本信息。节点工作台每个 AI 节点的主交互界面左边是知识库中间是对话右边是能力面板。后面我会单独讲这个。看板视图看板、列表、甘特图三种视角看需求进度用的。报表统计KPI、按人统计、阶段分布、部门对比、趋势图、热力图。发布控制台灰度发布的操作面板看进度、看指标、点回滚。第二层流程的骨架流程编排层。这一层是整个平台的骨架负责把 7 个节点串起来。它干的事情说起来也简单7 节点流水线定义了有哪些节点、顺序是什么、每个节点的输入输出是什么。节点间门禁上一个节点的产出满足什么条件才能进入下一个节点。产物传递上一个节点的产出怎么交给下一个节点当输入。SLA 计时每个需求在每个节点待了多久超没超时要不要预警。这一层很关键它是整个流水线的传送带。没有它各个 AI 能力就是散的串不起来。第三层AI 能力的弹药库AI 能力层。这里面是各个节点的 AI Agent每个 Agent 干一件事。有这么几个需求生成 Agent负责把需求意向变成结构化的 PRD。技术方案 Agent负责把 PRD 变成章节化的 Tech Spec。编码 Agent负责把 Tech Spec 变成代码。评审 Agent负责评审代码出评审结论和缺陷清单。测试拆解 Agent负责从源码和 PRD 里拆解测试用例。瓶颈分析 Agent负责分析性能瓶颈、覆盖率瓶颈。这些 Agent 都是可插拔的。编码 Agent 可以接 Claude Code可以接 OpenCode可以接 Z.ai也可以接 Devin。哪个好用用哪个想换就换。第四层让 AI 真正懂项目的东西知识与上下文层。这一层我觉得是整个平台的灵魂。没有它AI 就是个只会干活的工具人干得快但不一定干得对。知识库里存了这些东西Spec 契约库各个模块的接口契约、数据契约。比如user.profile.v2、user.auth.spec还有哪些是将要废弃的。CodeGraph 索引代码的符号关系图谱哪个函数调用了哪个、哪个类依赖了哪个清清楚楚。历史 PRD之前写过的 PRD按版本归档写新需求的时候可以参考。框架与中间件方案用什么框架、什么中间件、什么架构模式有定数的东西都在这儿。开发规范包结构怎么定、API 怎么命名、数据库表要有哪些审计字段全部写清楚。AI 干活的时候这些东西自动注入进去它就不是从零开始了。最底层基础设施基础设施层。都是一些支撑性的东西Git 仓库代码存在这儿。CI/CD构建、部署、流水线。监控告警线上指标、异常报警。灰度发布引擎控制流量比例、做灰度放量。对象存储存各种产物文件。数据库存需求、看板、报表这些业务数据。这一层没啥好说的都是标配但缺一不可。顺着流水线走一遍架构讲完了我带你顺着 7 个节点走一遍看看一个需求从登记到上线到底经历了什么。第一步需求登记一切的起点这一步很简单就是填个表单。但表单不是随便填的每一个字段都是后面 AI 的上下文。关键字段有这么几个需求标题、类型、优先级这些是基本信息。需求意向、目标自由文本AI 主要靠这个理解你想干啥。关联项目决定加载哪套 Spec 契约、哪份 CodeGraph 索引。编码智能体选择Claude Code、OpenCode、Z.ai、Devin想用哪个选哪个还能多选。设计要点就一句话表单即上下文。你填的每一个字都会直接注入需求生成 Agent 的首轮对话不用你再跟 AI 说一遍。第二步需求生成AI 写 PRD 是怎么回事填完表点下一步就到了需求生成节点。这个节点的核心是 PRD Agent它的任务是跟你对话把你的需求意向变成一份结构化的 PRD。AI 不是上来就瞎写的。它会先判断这是个新项目还是老项目的新需求。如果是新项目它会加载 PRD 模板、需求写作规范从零开始跟你聊。如果是老项目的新需求它会自动加载主干 Spec比如user.profile.v2、user.auth.spec还有历史 PRD、CodeGraph 影响面分析。它会告诉你“你这个改动大概会影响 18 个文件、1284 个符号”让你心里有数。生成出来的 PRD 不是一坨文字是结构化的每一段引用了哪个知识源都有 inline 标记点进去能看到原文。可追溯不是瞎编的。最后产出一份结构化的 PRD 文档直接交给技术方案节点用。第三步技术方案从骨架到血肉PRD 确认完了就到了技术方案节点。这个节点的 AI 能力有点意思不是一个 Agent 在干活是两个 Agent 协同。openspec负责搭总体框架先把方案的骨架搭出来确保大方向不跑偏。superpowers负责逐节细化安全怎么搞、性能怎么保障、兼容性怎么处理每一节都往深了挖。先骨架后血肉比一次性生成一大坨质量高多了。技术方案里会定一些全局规则这些规则很重要后面编码节点要照着来数据库表结构规范每个表都要有tenant_id、要有审计字段。API 定义规范RESTful 端点怎么命名、参数怎么传、返回格式是什么。包结构规范代码分哪几层、每层放什么东西。方案是增量生成的你能看到进度比如已生成 6/9 章节可以一节一节确认不用等全部写完再改。最终产出一份章节化的 Tech Spec里面有 DB 表结构、API 契约、模块划分、全局规则。编码节点直接读这个。第四步AI 编码不是从零开始写到了编码节点AI 才开始真正写代码。但你别以为它是从零开始写的它前面已经攒了一堆上下文了。编码的大致流程是这样的调用 CodeGraph 分析影响面看看哪些文件要改、哪些符号会动。基于 Tech Spec 设计数据库表和 API 契约。生成三模块脚手架和 Service 代码严格遵循包结构、API 规范、审计字段这些约束。生成一个代码结构树纵向的目录树让你一眼能看到生成了哪些文件。编码 Agent 也是可插拔的。你选了 Claude Code就是对话式 CLI 生成你选了 Devin就是全栈生成。各有各的用法看你的需求。产出是代码变更集加生成结构树交给评审节点去审。第五步代码评审AI 先把第一关代码写完了别急着提测先过评审。评审是双模式的AI 评审加人工评审。AI 综合评审自动扫描变更生成评审结论和建议清单。比如扫完告诉你“3 条建议2 个必须改1 个建议优化”。点进去能看到详细的 AI Issue 列表每条都有位置、有说明。人工评审评审人列表管理可以切换 AI 模式和人工模式。一般是 AI 先过一遍把明显的问题揪出来人工再审一遍深层的。评审的产出是评审结论加缺陷清单。这个缺陷清单不只是给开发看的测试节点也会用缺陷驱动的测试补充哪里有问题就重点测哪里。第六步测试验证自动拆解自动跑到了测试节点AI 又上场了。这个节点有个 Test Agent干三件事拆解用例、运行测试、瓶颈分析。用例是从两个来源来的PRD 自动拆解从 PRD 里拆出端到端的业务用例确保业务流程覆盖到了。源码扫描扫描源代码按文件、按单元、按分支维度自动给每个单元生成单元测试用例。两个来源加起来覆盖就比较全了。用例生成完了自动跑输出通过失败的结果。跑完了 AI 还会出一份瓶颈分析报告告诉你哪里性能有问题、哪里覆盖率不够。最后产出测试报告、覆盖率报告、瓶颈分析这些东西直接就是发布节点的门禁证据。第七步发布上线门禁加灰度终于到了最后一步发布上线。这个节点的核心是安全稳字当头。流程是这样的门禁校验自动从测试节点拉取门禁证据冒烟通过、单测全过、压测达标三样都齐了才能往下走。缺一样都不行。构建发布候选打包、构建、数据库迁移脚本生成。数据库迁移是可回滚的出问题能撤回去。灰度发布按流量百分比逐步放量先 20% 看看没问题再 50%最后全量。监控加回滚灰度期间盯着监控指标异常了一键回滚不用手忙脚乱。整个过程都有记录发布记录、灰度日志、回滚证据全部留痕事后可查。工作台是怎么设计的讲完了流水线说说工作台。每个 AI 节点需求生成也好、技术方案也好、AI 编码也好用的都是同一个工作台界面三栏布局。为什么统一成三栏因为 AI 干活这件事本质上就是看着知识库、跟 AI 对话、盯着产出生成进度这三件事。三栏刚好对应这三件事。左边知识库放的是当前节点相关的知识。不是全量给你是按节点动态过滤的。需求阶段只加载 PRD 模板和需求规范东西不多不会乱。到了编码阶段就多了包结构、开发规范、CodeGraph 索引这些编码用得上的东西。知识库里能看到 Spec 契约、CodeGraph 索引、历史 PRD、框架方案都是结构化的点进去能看详情。中间AI 对话区域这是主交互区你跟 AI 就在这儿聊。跟普通的 AI 对话不一样的地方是AI 的回复里会 inline 引用知识源你看到引用的地方点一下就能看到原文不用去别的地方翻。还有生成进度条比如技术方案生成了 6/9 章节你能看到进度不用瞎等。底部是输入框支持 引用知识源你想让 AI 参考某份 Spec直接 进去就行。右边AI 能力面板这一栏展示的是当前 AI 的状态和产物。Agent 信息当前用的是哪个模型、哪个 Agent、协同了哪些技能。比如claude-opus-4-6 · 协同 openspec superpowers。AI 配置温度设的多少、上下文策略是什么这些参数都能看到。生成产物树生成出来的东西用目录树展示比如代码生成了哪些文件、PRD 有哪些章节一目了然。看板和报表长什么样工作台是给干活的人用的看板和报表是给管理者和团队用的。工作台视图工作台里有三种看需求的方式看板视图按阶段列分组需求登记、方案、编码、评审、测试、发布每列一堆卡片。卡片上有 SLA 徽章快超时了会变色。列表视图表格式的状态、负责人、优先级、SLA什么都有适合批量操作和筛选。时间轴甘特视图按时间区间展示需求跨阶段的进度条有里程碑、有风险标记适合看整体排期。下面还有个流水线步骤条7 个节点依次排开当前需求走到哪一步了一眼就能看到。报表视图报表这边东西比较多都是量化的东西KPI 卡片最上面一排需求总数、已交付数、平均周期、准时率四个核心指标一目了然。按人统计表每个人的产出排名、所属部门、各阶段分布 chip。谁干得多谁干得少清清楚楚。阶段分布各个阶段有多少需求堆积图展示看瓶颈在哪。部门对比多个部门横向对比看哪个部门效能高。趋势图周、月、季粒度都有同比环比都能看。热力图按人乘时间的维度颜色深浅表示工作量。谁最近闲谁最近忙一眼就看出来了。数据是怎么流转的刚才讲了每个节点干什么现在讲讲数据是怎么在节点之间流的。这张图把每个节点的输入和输出都画清楚了。我再补充两个重要的机制上下文注入和知识库管理。上下文注入策略每个 AI 节点启动的时候平台会根据节点类型自动从知识库里挑出对应的子集注入到 AI 的上下文里。不用用户手动粘也不用用户操心该给 AI 看什么。大概的对应关系是这样的节点自动注入的上下文需求生成PRD 模板、需求写作规范、历史 PRD、CodeGraph 影响面技术方案PRD、Spec 契约、CodeGraph 索引、框架与中间件方案AI 编码PRD、Tech Spec、包结构、API 规范、CodeGraph 索引代码评审代码变更集、评审规范、历史缺陷模式测试验证PRD端到端用例、源码、Tech SpecAPI 契约用户进去的时候AI 首轮就会告诉你“已识别为老项目自动加载主干 Spec…”你就知道它已经把该加载的都加载好了。知识库怎么管理知识库按类型分了 5 大类每类有不同的图标和管理方式Spec 契约比如user.profile.v2、user.auth.spec每一份都标注了有效性将要废弃的会标出来提醒你别再用了。CodeGraph 索引代码的符号关系图谱按模块按服务组织能查调用关系、依赖关系。需求 PRD历史上写过的 PRD按版本归档写新需求的时候可以参考也可以让 AI 参考。框架方案中间件选型、架构模式文档这些定了就不太变的东西都存在这儿。AI 能力库干系人对齐、风险识别这些辅助 Agent 能力按需引用不是每个节点都用。几个纠结过的技术决策做架构的过程中有几个决策我们纠结了挺久我拿出来说说。这些决策不一定是最优的但在我们的场景下是权衡之后的选择。为什么用 CodeGraph不用纯文本搜索这个问题其实挺好回答的。纯文本搜索grep 也好全文搜索也好找的是字符串匹配。你搜user.profile它把所有包含这个字符串的文件都给你列出来但它不知道哪个是定义、哪个是调用、哪个是引用。CodeGraph 不一样它是符号级的。它知道哪个函数调用了哪个、哪个类实现了哪个接口、改动一个地方会影响多少地方。比如它能告诉你“这个改动影响 18 个文件、1284 个符号”这个粒度是纯文本搜索比不了的。在需求生成阶段就能预判改动范围在编码阶段能约束 AI 只改必要的文件避免无关改动。跨服务跨模块的依赖追踪也能搞定适合微服务架构。为什么用 openspec 加 superpowers 生成技术方案一开始我们想过让一个 Agent 从头到尾生成技术方案但试了几次发现质量不太稳定。有时候框架搭得好但细节不够有时候细节写得细但大方向偏了。后来改成了两个 Agent 协同。openspec负责搭总体框架先把骨架定下来确保大方向不跑偏。superpowers负责逐节细化每个章节安全、性能、兼容性都往深了挖。先骨架后血肉质量稳定多了。虽然多了一步但产出的方案靠谱程度上去了。为什么 AI 编码工具要做成可插拔的这个决策其实是出于风险考虑。AI 编码工具迭代太快了今天 Claude Code 最好用明天可能 OpenCode 追上来了后天又冒出来个新的。如果平台跟某一个工具绑死了后面工具不行了或者停更了整个平台就废了。而且不同工具有不同的优势。Claude Code 对话式生成质量高适合复杂需求。Devin 全栈生成快适合简单需求。OpenCode 支持本地模型适合数据敏感的场景。做成可插拔的想用哪个用哪个还能并行对比择优采用。不绑死供应商主动权在自己手里。为什么门禁证据要自动采集这个说起来也好理解人工填报的门禁不可信。你让开发自己填单测覆盖率达标了吗他肯定填达标了。你让测试自己填冒烟通过了吗她也肯定填通过了。不是说大家故意撒谎是人都有侥幸心理都觉得应该没事。自动采集就不一样了数据是从上个节点直接拉过来的改不了。测试报告是 Test Agent 跑出来的评审结论是 Review Agent 审出来的都是客观数据形成了不可篡改的证据链。发布节点直接展示证据“冒烟通过38 个单测全过压测达标”决策有据可依不用拍脑袋。为什么一定要灰度发布不能直接全量这个跟 AI 生成代码的特性有关。AI 写的代码测试全过也不代表就一定没问题总有一些边界场景是覆盖不到的。AI 生成的代码有不确定性这一点我们必须承认。灰度发布就是为了应对这个不确定性。先放 20% 的流量试试有问题影响面也小。没问题再慢慢放量直到全量。数据库迁移也做成可回滚的出问题能撤回去降低不可逆操作的风险。稳一点总没错。最后想说的写到这儿整个平台的架构差不多就讲完了。最后我想再回到最开始那个问题我们到底在做什么我觉得我们在做的事情本质上是把 AI 从一个编码工具升级成产研流水线的编排对象。纵向覆盖从需求到发布的全链路每一步都有 AI 参与每一步都有结构化的产物。横向统一知识库和上下文管理让 AI 懂项目而不是每次从零开始。治理门禁、SLA、报表让 AI 产研的过程可度量、可管控、可回溯。跟 Claude Code 的关系我再强调一遍。Claude Code 是平台在编码节点可以调用的智能体之一平台不替代编码工具而是给编码工具提供上下文、提供门禁、提供编排、提供度量。直接用 Claude Code解决的是写代码快不快的问题。做这个平台解决的是从需求到上线全流程顺不顺、质量可不可控、效能可不可度量的问题。这两件事不在一个层面上。我相信未来的产研一定是 AI 深度参与的。但不是 AI 取代人而是 AI 作为流水线的一部分跟人一起把整个交付周期压到最短、把质量提到最高。这就是我们想做的事情。