从统一任务看板到 AI 研发控制平台：一个内部工作台的设计思路
我们公司在研发过程中，需求、原型、UI、代码、测试、发布和反馈分别散落在不同平台里。每个平台都有成熟的专业能力，但一个任务跨过多个阶段后，参与者需要不断切换工具、寻找链接、重复解释上下文。
我想设计的并不是另一个 Jira、Figma 或 GitLab，而是一层位于这些工具之上的统一研发工作台：能力仍由专业平台提供，团队日常的查看、协作、审批和状态推进尽量在同一个工作台完成；大模型则基于结构化项目上下文参与分析和执行。
一、产品定位：不是替代工具，而是统一研发控制面
这套系统的核心定位是：
以任务为中心，聚合需求、设计、代码、测试、发布和反馈，并为不同编辑器与 AI Agent 提供一致的项目上下文和受控操作入口。
专业工具继续承担各自最擅长的工作：
- Figma 负责高保真 UI、组件和专业设计编辑；
- GitHub 或 GitLab 负责代码、分支、提交和 Pull Request；
- CI、Playwright 等系统负责构建与自动化测试；
- 现有部署平台负责真正的发布和运行控制；
- 企业微信负责移动端通知、反馈和快捷审批；
- DeepSeek Harness 作为可扩展的 Agent Runtime，负责模型调用、工具执行和会话过程。
工作台掌握的则是任务主线：为什么做、当前做到哪里、使用哪个版本、下一步由谁处理，以及整个过程中发生过什么。
二、统一任务，而不是统一所有界面
每个 Feature 或 Bug 都需要一个稳定的任务身份。需求、Figma Frame、代码分支、PR、测试运行、部署版本和用户反馈，都作为制品关联到这个任务。
例如，一个登录页移动端优化任务可以同时关联：
- 已确认的需求版本；
- 验收标准；
- 可点击原型；
- Figma 设计节点；
- Git 分支和 PR；
- Playwright 测试结果；
- Preview 环境；
- 生产发布版本；
- 企业微信中的用户反馈。
团队打开任务详情页后，可以在需求、原型、设计、代码、测试、发布和时间线之间切换，而不必先判断信息存在于哪个平台。
但统一工作台不意味着所有操作都必须重新实现。高频的查看、评论、评审、审批和状态操作应在工作台原生完成；精细设计、复杂 Git 冲突、本地调试等专业操作仍然保留外部入口。
三、各阶段的合理边界
需求
需求和任务关系是整条流程的源头，最好由工作台原生管理。如果公司已经使用 Jira、TAPD、禅道等系统，则可以先通过 API 和 Webhook 建立本地投影，不急于迁移主数据。
工作台至少需要保存需求版本、验收标准、负责人、依赖关系、评审结论和历史决策。
原型
原型采用双轨制。
低保真、偏交互验证的原型，可以由 AI 生成 React Preview，直接在工作台沙箱中运行和评论。高保真原型继续使用 Figma，并通过嵌入方式在任务页中查看。
UI 设计
UI 设计继续依赖 Figma 等专业工具。工作台负责关联设计节点、显示版本、发起评审、汇总评论、标记通过状态，并在条件允许时调用设计 Agent 生成或调整草案。
没有必要重新开发矢量编辑、自动布局、组件 Variant 和多人设计协作。
开发与测试
开发者可以在工作台中查看分支、提交、Diff、PR、Review 和 CI 状态。复杂编码仍在编辑器中完成，但编辑器插件能够绑定当前任务，从工作台获取需求、设计、验收标准、历史决策和测试证据。
测试结果则应尽可能原生展示，包括失败截图、运行录像、控制台日志、网络错误和验收标准覆盖情况。
四、工作台同时成为项目上下文服务
如果看板能够通过插件、MCP Server 或 API 接入 VS Code、Cursor、Codex、Claude Code 等工具，它就不再只是信息面板，而会成为公司的项目上下文控制层。
不同编辑器中的大模型可以通过标准工具读取：
- 当前任务；
- 已批准的需求版本；
- 验收标准；
- 对应的设计节点；
- 相关代码范围；
- 项目规范；
- 历史技术决策；
- 测试失败证据；
- 可执行操作和审批要求。
这样，即使团队成员使用不同模型和编辑器，也能获得一致的事实和任务边界。模型可以更换，但公司的上下文不会被锁定在某个聊天记录或编辑器里。
编辑器插件还可以把结构化进度回传工作台，例如开始处理、修改完成、测试失败、需要澄清、创建 PR。工作台记录项目事实，而不是监控开发者的每一次输入或完整私人对话。
五、DeepSeek Harness 的位置
DeepSeek Harness 适合作为 Agent Runtime，但不应该成为任务数据库。
工作台之外需要增加一层 Agent Gateway，负责：
- 用户和项目鉴权；
- 模型路由；
- 任务上下文组装；
- 工具权限；
- 敏感数据过滤；
- Token 和费用限制；
- 人工审批；
- 执行日志和结果回传。
Harness 通过插件连接 Git、设计、测试和其他系统。由于它仍处于快速迭代阶段，业务层应通过 Adapter 与其隔离，避免任务数据和 UI 直接依赖 Harness 内部结构。
模型在这里负责理解、整理、建议和执行；确定性的状态机、权限系统和审批策略负责约束模型。
六、发布与运行控制
加入发布能力后，工作台才能形成完整闭环：
需求 → 设计 → 开发 → 测试 → 发布 → 运行观测 → 用户反馈 → 新任务。
工作台不需要自研 CI/CD，也不应该默认持有服务器最高权限。它作为发布控制面，汇总发布证据、检查前置条件、发起审批、触发现有流水线并接收最终状态。
一个发布候选应包含：
- 关联需求、PR 和 Commit；
- Code Review 状态；
- 单元测试和 E2E 结果；
- 配置和数据库变化；
- 安全检查；
- 已知风险；
- 发布说明；
- 回滚方案；
- 审批记录。
生产发布应遵循固定流程：
- Agent 或人员提出发布操作；
- Policy Engine 检查权限和前置条件；
- 负责人审批；
- 部署平台执行；
- Webhook 返回最终状态；
- 工作台写入审计时间线；
- 发布后进入观测阶段。
AI 可以总结变更、分析风险、解释监控指标并建议暂停或回滚，但不应自行发布生产、调整流量、执行数据库迁移或绕过测试。
七、数据和同步架构
工作台不能在每次打开页面时临时请求所有平台。否则会遇到接口限流、加载缓慢、外部故障和历史状态缺失。
更合理的方式是：
自有任务主数据 + 外部制品主数据 + 本地数据投影 + API 发起操作 + Webhook 确认结果。
Git、Figma、CI 和企微的变化先转成统一事件，再更新工作台投影。用户发起操作后，工作台调用外部 API，最终以 Webhook 或再次查询确认真实状态。
所有事件进入统一时间线，让团队能够看到：
- 谁修改了需求；
- 设计使用哪个版本；
- 哪个 Agent 修改了哪些文件；
- 为什么测试失败；
- 谁批准了发布；
- 哪个版本正在生产环境运行；
- 新反馈是否与本次发布相关。
八、实施顺序
第一阶段不开发完整平台，只验证一条真实闭环：
需求任务 → 编辑器获取上下文 → Agent 开发 → 创建 PR → Playwright 测试 → 人工验收。
第一版需要：
- 公司登录和基础权限；
- 统一任务详情页；
- GitHub 或 GitLab 集成；
- DeepSeek Harness Agent Gateway；
- 测试结果展示；
- Agent 操作审批；
- 完整活动与审计时间线。
第二阶段再增加 Figma 嵌入、设计评审、React Preview 和企业微信。
第三阶段增加 Release Candidate、生产发布审批、流水线状态、运行监控和回滚入口。
九、如何判断是否值得继续
这套工具的价值不能通过页面数量判断，而要通过团队实际减少的摩擦判断：
- 一个任务需要切换的平台数量是否下降；
- 查找需求、设计和 PR 的时间是否下降；
- “现在做到哪了”的沟通是否减少；
- 测试问题从发现到修复的时间是否缩短；
- AI 建议和代码修改的采纳率；
- 需求、设计、实现不一致造成的返工是否减少；
- 团队是否主动从工作台开始工作。
如果最终只是看板、统计图和外部链接的集合，就没有必要单独开发。真正有价值的部分是：
- 统一任务上下文；
- 跨平台可执行操作；
- 可被不同编辑器和 Agent 使用的上下文服务；
- 权限明确、需要审批并且可审计的 AI 执行；
- 从需求一直延伸到发布与反馈的闭环。
这套系统最终管理的不只是任务状态，而是一个任务如何被不同角色、不同专业工具和不同 AI Agent 共同完成。