企业官网建设流程全解析

写在前面：从一个真实的场景说起

上周我们团队用 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 才开始真正写代码。但你别以为它是从零开始写的，它前面已经攒了一堆上下文了。

编码的大致流程是这样的：

1. 调用 CodeGraph 分析影响面，看看哪些文件要改、哪些符号会动。
2. 基于 Tech Spec 设计数据库表和 API 契约。
3. 生成三模块脚手架和 Service 代码，严格遵循包结构、API 规范、审计字段这些约束。
4. 生成一个代码结构树，纵向的目录树，让你一眼能看到生成了哪些文件。

编码 Agent 也是可插拔的。你选了 Claude Code，就是对话式 CLI 生成，你选了 Devin，就是全栈生成。各有各的用法，看你的需求。

产出是代码变更集加生成结构树，交给评审节点去审。

第五步，代码评审，AI 先把第一关

代码写完了，别急着提测，先过评审。

评审是双模式的，AI 评审加人工评审。

• AI 综合评审：自动扫描变更，生成评审结论和建议清单。比如扫完告诉你，“3 条建议，2 个必须改，1 个建议优化”。点进去能看到详细的 AI Issue 列表，每条都有位置、有说明。
• 人工评审：评审人列表管理，可以切换 AI 模式和人工模式。一般是 AI 先过一遍，把明显的问题揪出来，人工再审一遍深层的。

评审的产出是评审结论加缺陷清单。这个缺陷清单不只是给开发看的，测试节点也会用，缺陷驱动的测试补充，哪里有问题就重点测哪里。

第六步，测试验证，自动拆解自动跑

到了测试节点，AI 又上场了。这个节点有个 Test Agent，干三件事，拆解用例、运行测试、瓶颈分析。

用例是从两个来源来的：

• PRD 自动拆解：从 PRD 里拆出端到端的业务用例，确保业务流程覆盖到了。
• 源码扫描：扫描源代码，按文件、按单元、按分支维度，自动给每个单元生成单元测试用例。

两个来源加起来，覆盖就比较全了。

用例生成完了，自动跑，输出通过失败的结果。跑完了 AI 还会出一份瓶颈分析报告，告诉你哪里性能有问题、哪里覆盖率不够。

最后产出测试报告、覆盖率报告、瓶颈分析，这些东西直接就是发布节点的门禁证据。

第七步，发布上线，门禁加灰度

终于到了最后一步，发布上线。这个节点的核心是安全，稳字当头。

流程是这样的：

1. 门禁校验：自动从测试节点拉取门禁证据，冒烟通过、单测全过、压测达标，三样都齐了才能往下走。缺一样都不行。
2. 构建发布候选：打包、构建、数据库迁移脚本生成。数据库迁移是可回滚的，出问题能撤回去。
3. 灰度发布：按流量百分比逐步放量，先 20% 看看，没问题再 50%，最后全量。
4. 监控加回滚：灰度期间盯着监控指标，异常了一键回滚，不用手忙脚乱。

整个过程都有记录，发布记录、灰度日志、回滚证据，全部留痕，事后可查。

工作台是怎么设计的

讲完了流水线，说说工作台。每个 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 看什么。

大概的对应关系是这样的：

用户进去的时候，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 作为流水线的一部分，跟人一起，把整个交付周期压到最短、把质量提到最高。

这就是我们想做的事情。