平台二开的老问题：不在技术，在协作

企业很少从零造一个平台。更多时候，是在一个已经运行很久的系统上做二次开发：加一项新能力、改一个流程、补一个权限。

这类工作的难点，常常不在写代码，而在协作。产品经理理解的"要什么"，到研发手里可能已在层层传递中失真；研发踩过的坑、沉淀的经验，项目一结束就散了，下一次二开又得从零摸索。

两道老问题由此而来：一是产研脱节，需求在传递中损耗；二是经验不沉淀，组织能力随项目结束而流失。

一个闭环：产品与研发在同一处协同

织灵 Coda Loom 2.0（下文简称"织灵"）的数字研发团队（ADE Teams），把产品设计与研发实现放进同一平台协同完成平台二开。从需求理解、原型验证，到技术方案、分阶段开发，再到验收与沉淀，形成一条有依据、有确认、有验证、可复用的产研闭环。

八步走：从需求理解到经验沉淀

01 读懂现有产品 — 从知识库调取上下文
产品经理接到平台二开需求后，ADE 从企业知识库获取现有产品手册、历史需求、页面说明和产品规范，理解当前产品结构，识别可复用的已有能力以及新需求可能影响的产品模块。

02 形成初步方案 — 先评审，再投入原型
ADE 分析新能力在现有产品中的位置，梳理目标用户、核心流程、页面变化和关键规则，先形成便于评审的初步产品方案，帮助团队在投入完整原型制作前确认方向。

03 验证产品原型 — HTML 预览 + 浏览器跑通
产品经理确认功能范围、核心用户流程和交互方案后，ADE 生成完整产品原型。产品经理通过 HTML 预览持续评审和迭代，再由 ADE 使用浏览器运行核心用户路径，验证关键交互是否符合预期。在真实的产品设计实践中，首版原型常因功能位置理解偏差被否决、经重新分析形成第二版——这恰说明原型不是一次性产出，而是在"人确认"中迭代出来的。

04 衔接研发阶段 — 产品成果即研发依据
需求、产品方案、原型和验收标准确认后，研发人员通过 ADE 承接后续开发。产品阶段的成果成为研发阶段的明确依据，使研发人员清楚要实现什么，以及最终按什么标准验收。

05 读懂现有代码 — 结合记忆定位改动
ADE 从知识库获取架构资料、接口说明和工程规范，并参考记忆中的过往研发经验，读取现有代码，定位本次改动涉及的模块、接口、数据关系和潜在风险，形成与现有工程相适配的技术方案。面对数十乃至上百个原有工程文件、成千上万行待解读代码，智能体先读后改，而非盲目动手。

06 确认与拆解 — 人拍板，任务分阶段
研发人员评审架构选择、兼容方式、模块依赖、实施顺序和风险控制。技术方案确认后，ADE 将开发目标拆解为可分阶段完成的任务，并明确每个阶段的验证方式。

07 开发与验证 — 边改边测，问题闭环
ADE 按确认后的方案分阶段修改代码，每完成一部分即通过编译和测试验证。发现功能遗漏、兼容问题或代码错误后，定位原因、完成修复并重新验证，直至满足产品验收标准。

08 验收与沉淀 — 资料入知识库，经验入记忆
ADE 汇总代码、工程文档、测试结果和验证证据，交给产品经理对照原型与验收标准验收。验收完成后，经过确认的产品与工程资料进入知识库，关键产品决策与可复用的研发经验进入记忆，为后续迭代持续复用。

织灵的差异化：产研一体、越用越聪明、人在回路

把上述过程连起来看，织灵带来的不是"多一个写代码的工具"，而是三种更底层的能力：

其一，产研一体，需求零损耗。 产品方案、原型与验收标准在确认后直接进入研发阶段，成为"要实现什么、按什么标准验收"的明确依据。需求不再靠口头传递，也不在部门交接中失真。

其二，知识库与记忆，让二开越用越聪明。 经过确认的产品与工程资料沉淀进企业知识库，关键决策与可复用经验进入记忆。下一次二开，不是从空白开始，而是带着此前的积累启动。这里补一句定义：知识库是企业项目资料、产品规范、工程文档的沉淀池；记忆是跨任务复用的关键决策与研发经验。这正是"工程级 AI 研发平台"与"AI 写代码工具"的分野——前者让组织能力随时间累积，后者每次都是一次性消耗。

其三，人在回路，关键决策由人拍板。 ADE 形成初步方案、原型、技术方案后，由产品经理与研发人员确认；执行与验证交给智能体。人从重复劳动中抽身，专注在确认与决策上。这不是"替代人"，而是把人放在最该在的位置。

让每一次二开，成为下一次的起点

平台二开的真正成本，往往不在写代码，而在需求失真与经验流失。织灵把产品、研发与沉淀放进同一个闭环，让每一次二开都成为下一次的起点。

更进一步看，当知识库与记忆持续累积，平台二开就不再是一项次次归零的任务，而变成组织研发能力的复利——人做的决策越多、智能体跑的验证越多，下一次的起点就越高。这正是工程级 AI 研发平台区别于单点编码工具的根本：它交付的不是一个功能，而是一套会随使用生长的能力。