01 · 产品概述
Northstar（NS） 是一个对话驱动的 AI 研发协作平台。用户提出产品目标，AI 协助调研、设计与实现，系统把需求、文档、代码和验证记录连接起来，让每一步都有明确的依据、责任与结果。
Chat in. Ship out.
把讨论接成一条持续推进的研发流程
一个想法落地，需要先说清为谁解决什么问题，再决定如何实现、怎样验收，以及发生变化后如何调整。Northstar 以需求为组织单位，让这些工作共享同一份产品上下文。
对话用于表达目标和讨论取舍；确认后的结论进入产品需求文档（PRD）、技术设计文档（TD）以及测试和执行记录。后续工作能追查前面的决定，文档变化也能带回评审与交接流程。
适合哪些人
- 独立开发者与产品创造者：从一个具体想法开始，借助不同角色的视角澄清需求、推敲设计并组织实现。
- 产品与研发人员：围绕确认过的需求持续工作，处理调研发现、设计异议、评审问题和待办。
- 技术负责人：核对需求与实现的关系、当前版本的评审依据，以及交付遇到的阻塞。
当前主要使用方式是一个人在同一产品中切换产品（PM）、开发（Dev）和质量验证（QA）角色。多人共同处理需求、共享责任与权限，是后续演进方向。
人、模型与系统怎样分工
- 人负责决策：确定目标、范围与取舍，确认风险，并对签核、发布等关键操作作出决定。
- AI 协助完成工作：理解背景、开展调研、提出方案、编写文档和代码，并给出评审意见。
- 系统落实规则：检查角色、状态、版本和权限，执行已获授权的动作，记录实际变更与验证结果。
PM、Dev、QA 各有职责和待办。技术设计中的业务问题交回 PM 澄清，实现问题由 Dev 处理，质量验证由 QA 承接；人的确认与系统记录共同构成后续工作的依据。
一条需求如何推进
- 澄清并确认需求：PM 确认用户、场景和范围，整理调研发现，编写、评审并签核 PRD。
- 形成技术方案：Dev 开展技术调研，编写和评审 TD；产品异议由 PM 决策，再同步设计与实现步骤。
- 组织代码实现：确认修改范围与验收方式，在受管工作区执行代码工作，核对改动和验收结果。
- 验证质量：QA 根据需求和设计组织测试，记录缺陷，由 Dev 修复后交回 QA 复测。
- 准备发布并复盘：核对产品签核、质量结论、目标环境、发布步骤和回滚准备，积累后续改进依据。
公开演示覆盖 PM 需求调研至 PRD 签核，以及 Dev 技术调研至实现步骤确认。Dev 签核、QA、缺陷修复、发布检查、复盘与发布后变更已有相关机制，仍处于实验性阶段，正在持续完善。
在哪些入口使用
| 入口 | 主要用途 |
|---|---|
| Desktop · 桌面端 | 主要交互入口，用于对话、角色切换、卡片确认和工作现场恢复。 |
| Viewer · 文档查看器 | 按角色查看需求、文档和待处理事项，业务产物保持只读。 |
| CLI · 命令行 | 提供终端对话、调试与自动化接入，使用同一套服务端流程。 |
看一段真实使用过程
公开视频以家庭图片与视频管理项目 media-harbor 为例：从浏览本地素材、筛选打印照片的想法出发，逐项确认调研结果并形成 PRD；随后进入技术调研与设计，将评审发现的业务问题交回 PM 处理。
继续观看 Dev 技术流程，了解需求异议如何进入 PM 决策，再回到技术设计与实现步骤确认。