PDesk

重新思考 AI 时代的产品交付方式

让一次需求成为持续演进的产品变化

柏柏柏XXX 技术团队

AI 正在进入更多研发交付环节

完整产品交付还有哪些成本值得重新看？

业务诉求
需求与方案
需求澄清目标 · 范围方案定义流程 · 规则 · 原型
研发任务
开发实现
测试验证
代码审查
代码合并
发布反馈
需求是否清楚、方案是否形成共识这些工作同样有成本，也值得重新看
自动化范围继续向验证、审查与合并延伸合并取决于风险分级、检查结果与审批策略

贯穿完整交付的协作成本

理解讨论决策表达上下文传递
既看研发交付效率，也看完整产品交付效率

企业产品研发，往往是在已有状态上持续发生变化

当前产品状态+新业务诉求
产品变化一次持续演进的工作对象
页面流程规则接口服务数据
阶段性产物方案·原型·PRD·结构化需求·研发任务

让一次产品变化，在同一个工作空间中持续演进

PDesk · 产品变化工作空间产品定义 / 完整变化的工作空间
业务意图
当前产品与系统
企业知识
产品变化
理解讨论·澄清·判断
决策方案·规则·关键取舍
表达页面·原型·PRD·结构化需求
交付反馈研发任务·实现状态·验证反馈

产品方向：产品变化跨越方案、实现与验证持续演进

当前 MVP已经真实跑通
BRD / 想法 + H5 / Web 页面+ 页面知识产品方案PRD / 结构化对象

一个真实业务诉求，如何逐步形成可交付的产品方案？

基于业务诉求、已有产品和企业知识，逐步形成可交付的产品方案

业务诉求→已有产品与知识→产品方案→结构化需求
打开 PDesk Demo ↗

从真实案例回看产品价值

PDesk 当前重点验证的价值

01

方案质量

基于当前产品状态、
企业知识和已有规则，
减少信息缺失和理解偏差，
形成更完整、研发可消费的产品方案

02

上下文连续

让一次产品变化中的讨论、决策、
工作产物和实现反馈持续关联，
减少角色切换中的重复理解
和上下文重建

03

责任扩展

让交付负责人和小团队
借助 Agent 承担更完整的交付范围，
推动角色边界和协作方式
持续演进

让一次需求，在方案、实现与验证中持续演进

通用 Agent 已经很强

这些事情今天能不能做？

能做到

熟练 AI 用户，实际上一直在自行承担

上下文组织 / Context Engineering

Agent 现在需要知道什么

工作流编排 / Workflow Orchestration

下一步做什么、用什么工具、如何延续上下文

通用 Agent 提供能力，产品化解决能力可用

把少数高手依赖个人技巧完成的能力组合，沉淀为低门槛、稳定、可复用的组织工作方式

上下文 · 工作产物 · 工作流程 · 企业约束

原型与产品变化，是什么关系？

产品变化
当前产品状态新业务诉求企业知识讨论与决策

原型

业务规则系统变化实现与验证研发反馈

让“要变成什么样”更容易被看见、体验和讨论

原型承载可体验、可讨论的产品共识
产品变化持续连接当前状态、业务意图、决策、工作产物、实现与反馈

从 PDesk MVP 走向更加连续的产品交付

01 交付闭环→02 能力支撑→03 交付责任
产品变化
理解现状→定义变化→实现变化→验证变化→反馈调整
在反馈中继续理解与调整

同一次产品变化，贯穿理解、决策、实现、验证与反馈

PDesk

管理产品变化本身

为什么变 · 现在是什么 · 要变成什么持续记录判断与决策

方案 / 反馈

WebLoop

负责产品变化的工程实现、验证与交付闭环

工程理解 · Coding · 运行验证 · 修复 · 发布 · 反馈

PMind
贯穿其中的企业知识和上下文产品知识 · 业务知识 · 工程知识与证据

当前能力可以分开建设，长期可以产品统一、能力分层

未来可能由 PDesk 提供统一入口，WebLoop / PMind 作为背后的能力层

今天 · 多角色协作

业务 / 产品 / 前端 / 后端 / QA

专业分工，共同推进一次变化

→责任扩展

未来可能 · 更完整的交付责任

交付负责人（Feature Owner）
更小团队 + Agent

XX方向 · 全栈研发试点

验证专业分工基础上的能力边界扩展和更完整交付责任

工作对象相对稳定，角色边界可以变化

让模型能力、研发交付和组织分工，都围绕“产品变化”继续演进