02 · 核心价值

Northstar 希望减少研发过程中反复解释背景、追问进度和核对结果的成本。它把讨论形成的决定、工作产物与下一步任务连接起来，让一次需求能持续推进。

换一个角色，工作能接得上

PM 完成需求澄清、PRD 编写、评审与签核后，Dev 接着开展技术设计。切换到 Dev 时，Northstar 将当前需求、已确认文档、未解决问题和待办带到新的工作视角；产品问题、实现任务与质量工作各有归属。

例如照片管理产品已确定“仅在本地处理素材”，Dev 可以从这项约束继续考虑存储、索引与性能。接手时能核对决定来自哪里，也能看到还有哪些问题需要补充，减少重复梳理背景。

技术设计遇到“重复照片是否自动合并”时，这个选择会影响用户对内容保留与删除的预期。Dev 可以把它记录为 PM 待确认问题，由 PM 澄清规则或修订产品需求，再更新技术设计。

异议因此有了明确的处理位置：提出的问题、人的决定和后续修改可以一起回看。产品取舍经过确认后再进入实现，降低开发人员替用户猜测规则带来的返工。

假设产品需求新增“离线使用”，之前通过评审的设计仍可能依赖在线服务。Northstar 将评审结论关联到当时的文档和上游依据；这些材料变化后，系统会检查原结论是否仍适用于当前版本。

需求、设计、代码和测试之间的关联也可以检查缺失与断裂。团队更容易发现哪些依据已经过期、哪些内容尚未覆盖，再有针对性地补充设计和验证。具体机制见知识与版本一致性。

当 AI 完成一次文档修改或代码任务，用户可以检查文件差异、工具执行记录、授权决定和验证结果。具备变更契约的受管文件工具在写入后校验实际内容；编码候选还会按已确认的验收命令独立检查。

这样，“改动已经产生”“验收命令通过”“进入需求分支”分别有可核对的结果。失败也能留下具体原因，便于继续处理。自动化验收与 QA 的质量签核承担不同职责，详见外部 Agent 委派与交付。

一次任务分批写入，前两批成功、第三批失败时，已记录的成果和失败信息可以帮助系统核对剩余工作。结果尚不明确时，先查询实际状态，再决定继续或重试，减少重复执行造成的混乱。

如果需要重新选择产品方向，可以查看已有恢复点，核对能恢复的版本与范围。执行与失败恢复关注当前任务怎样续接；恢复点与回滚关注怎样回到此前的工作现场。

这些场景指向同一个目标：让研发中的决定、变化和结果可以被承接与核验。下一章卡片式交互介绍用户如何在日常对话中完成这些操作。