从长报告到运维资产中枢：一次 AI 产品实践
让 AI 盘点完全部数字资产，我得到了一份看起来很完整的长报告，用起来才发现它留不住。这篇写它为什么不好用，以及范围收窄成本地面板的过程。
- AI 产品
- 数字资产
- Agent 上下文
- Personal Ops Panel
问题从哪里来
设备、自托管服务、账号和域名慢慢多起来以后，我经常记不清某项资产放在哪里、从哪个入口访问、和哪些凭据有关。让 Agent 帮我排障时，还要先花时间解释环境。
这些信息原本散在聊天记录、配置文件和记忆里。单项内容并不复杂，真正麻烦的是缺少一个稳定入口。
它们在哪里
怎样恢复
第一版是一份长报告
我先借助 AI 做了一次完整盘点，把电脑、路由器、NAS、云服务、域名、账号、SSH Key、Docker 服务和 AI API 整理到一份报告中。它解决了“我到底有什么”这个问题，也让我第一次看清这些资产之间的关系。
报告很快暴露出新的问题。内容太长，查找慢；设备或入口变化后，需要重新修改大段文字；Agent 读到旧结论时，也可能把已经过期的判断当成当前事实。
我真正需要的是一组能持续更新、可以按需查询的稳定记录。
把范围收窄
我把长期保存的内容收窄到几类事实：资产是什么、放在哪里、有什么用途、与哪些账号或入口关联、凭据线索保存在哪。故障结论和临时方案继续留在具体任务中，不写进长期资产记录。
敏感信息也单独处理。普通查询只返回凭据是否存在和保存位置，密钥明文留在本地，需要额外确认的查看操作走独立接口。
这个范围决定了后面的产品形态：它是个人运维资产索引和 Agent 上下文入口，不承担企业知识库或完整 CMDB 的功能。
从报告变成面板
我主导搭建了 AI Agent 个人运维资产中枢。面板按设备、服务、账号、域名和路径组织信息，可以搜索资产，也能查看关联入口与凭据线索。
面向 Agent 的接口只提供维护需要的上下文。Agent 可以先查询服务位置、用途和关联关系，再决定去哪里读取实时配置和日志。这样减少了重复说明，也避免把密钥明文塞进普通对话。
项目目前可以本地或在私网中部署，公开仓库包含通用程序、空数据模型、Docker 配置、命令行客户端和对应的 Codex Skill。真实资产与凭据不进入仓库。
这次取舍留下了什么
最初的目标是“把所有信息整理完整”，实际使用后，目标变成了“让需要的信息容易找到，并且保持更新”。字段、接口和权限边界都由这次收缩决定。那份越来越长的盘点报告，最后被一个可本地部署、可以持续维护的小面板替代。