收好第一版的范围
把下一次修改收成一条完整路径，写清先做什么、暂时不做什么，以及怎样判断结果。
有了第一版之后，很容易想继续加功能。这一篇帮你把下一次修改收好：先完成哪条操作，怎样算做成，哪些想法留到后面。
把上一章的问题改成一条路径#
第一章留下了用户、现有办法和待验证假设。这一章把它们变成产品单页。轻联本机版的主路径只有三步：在自己电脑上运行 npx --yes device-center@beta start；打开 http://127.0.0.1:5174，看到这台电脑真实的内存和磁盘；把 /mcp 加到本机 Agent，让它读到同样的信息。
每一步都要有输入与结果。“支持设备管理”太宽，“本机 Agent 调用 device_center_list_resources，读到这台电脑的真实内存和磁盘”才容易验收。这条路径不需要账号，也不需要服务器；云端面板和日志读取都是可选能力，不在这条路径上。
必要条件也属于最小产品#
可以先不做云端面板、远程日志和 Windows 版。有几样东西却直接影响结果，不能因为追求快就去掉：
- 本机页面和 MCP 只监听回环地址，并检查 Host 与 Origin，不直接公开；
- 状态如实：没有取得数据的设备显示“未知”，快照过期显示“待刷新”；
- 内存和磁盘分开记录，内存读取失败，不会顺带伪造磁盘数据。
这里有个判断办法：拿掉这项能力之后，用户还能否可靠完成那件事？能，先记到后续；不能，放进首版。Agent 读到一台显示“在线”、其实已经关机的设备，会按错的信息去安排工作，所以“状态如实”不能往后放。把首版功能按主路径排列，通常比按“前端、后端、运营”分别拉长清单更容易看见遗漏。
你也可以降低问题的复杂度。轻联设备说明里的“服务与应用”由用户手动登记，并标注为用户填写；当前不扫描已安装的应用、端口或进程，也不承诺这些服务正在运行。先手动登记、写清来源，比急着做一个读不准的自动扫描更容易验收。
写一页产品说明，先把非目标留下#
下面是可以直接填的工作表。每个格子用一两句话，不必写成几十页方案。
| 项目 | 你要填写什么 |
|---|---|
| 用户与场景 | 哪类人，在什么时刻，想得到什么 |
| 主路径 | 入口、操作、结果、失败时怎么办 |
| 首版范围 | 跑通路径所需的最少功能和必要条件 |
| 非目标 | 当前明确不做的能力，以及排除原因 |
| 试用假设 | 别人为什么愿意花时间装上、用一次，并告诉你结果 |
| 观察条件 | 看哪个动作、用什么材料、何时复盘 |
| 停止条件 | 出现什么反馈时缩小、调整或停止 |
非目标最好直接写进对外文档。轻联 README 的能力表最后一行就叫“尚未提供”：任意远程命令、通用文件传输、Windows 原生 Agent、云端 MCP、CF 专用适配器、计费、自动迁移。用户安装前就知道它不做什么；Agent 读 README 时，也不会把这些当成待办顺手做掉。
试用假设也要连到结果。轻联公测不收费，我要验证的不是“会不会付钱”，而是朋友能不能在自己的电脑上装好，让本机 Agent 读到资源和用途。试用指南请大家重点试四件事：资源读数是否真实清楚、给设备写名称和用途、点一次“采集一次”、让 Agent 通过 MCP 读取。收费前要准备什么，放到第 13 篇再讲。
让投入跟着证据走#
开发前写下自己允许投入的时间和服务预算。到复盘时，看用户是否完成关键操作、是否遇到同一种困难、是否愿意继续使用。没有这些材料，继续增加功能只会让下一次判断更贵。
轻联的本机版跑在用户自己的电脑上，不需要我提供服务器。可选的官方云端面板是免费公测，我用后端额度给它划了边界：每个账号最多 16 台有效设备；密文中转每账号每天 100 MiB、全实例每天 1 GiB，按 UTC 日持久计数；当前没有计费、付费服务或 SLA。这些数字写在托管说明里，用户使用前就能看到。
这些条件由你提前选择，不是专题保证的成功公式。一次实验可能说明操作不清楚，也可能说明问题没有那么迫切；先追查原因，再决定是否换一个用户或问题。
轻联是怎么做的#
当时想解决什么。 本机版只回答一个问题：本机 Agent 能不能读到这台电脑的真实资源。
交给 Agent 什么。 范围收在本机：不注册账号，只监听回环地址，一条 npx 命令启动。约束写在项目的 CONTRIBUTING.md 里：保留真实的设备状态和分开的内存、磁盘读数；默认只包含本机真实的 Driver，不预置任何记录。
得到什么。 本机页面和本机 MCP。没有可用数据的设备保持“未知”，快照过期显示“待刷新”，这不代表密钥过期；刷新列表也不会主动连接 SSH。
怎样检查。 标准只有一条：页面和 Agent 看到的，是不是这台电脑的真实情况、采集于什么时候。为了不让假数据混进来，测试数据只能放在临时目录和临时数据库里，不能出现在正式启动中。
为什么调整。 CONTRIBUTING.md 里还有一句：不要恢复示例项目、托管额度展示和模拟的云端同步。示例数据让页面看起来很完整，却会让人和 Agent 都分不清哪些是真的。现在 README 开头就写明：没有默认示例设备，也没有虚构的在线状态。
换成你自己的项目#
请根据 docs/problem-notes.md（第一章的需求记录），写一页产品说明到 docs/product-brief.md。
1. 只围绕一个用户任务写主路径：入口、操作、结果、失败时怎么办。
2. 列出首版范围：跑通这条路径所需的最少功能，以及不能省的条件（权限、如实显示状态、失败提示等）。
3. 单列非目标和排除理由，并检查 README 或页面上是否已经告诉用户“暂不提供”。
4. 写出试用假设、观察条件和停止条件；不把我的猜测写成已验证需求，不编造收入或节省时长。
5. 对照现有代码，指出首版范围里还缺哪一项、哪些已经超出范围。
本次只整理范围，不改代码、不购买服务、不联系用户、不部署。把方括号里的内容换成自己的需求。
-
docs/product-brief.md的主路径能在纸面上从头走到尾，每一步都有输入和结果 - 每个首版功能都能说清“拿掉它，主路径为什么走不通”
- 非目标已经写进 README 或页面，用户使用前就能看到
- 删掉一项延后功能后，主路径依然成立
- 写明了自己允许投入的时间和服务费用上限
下一章把这页说明交给 Agent，学会让它沿着已有项目继续改，并检查改动有没有生效。