DSH 第一周工作流：从空白环境到稳定工作台
按第 1 天到第 7 天安排模型配置、首个插件、场景组合、备份与复盘；每一步都有完成标准，避免一开始装一堆插件。
约 9 分钟读完
读完这篇你会
- 用七天建立一套稳定、可回滚的 DSH 工作台
- 每天只验证一个新能力，不让环境在第一周失控
- 把“会用 DSH”变成可重复的个人工作流
适用版本
Compatible with: dsh 0.1.x。你不需要在第一周学会写插件；目标是建立一套你愿意每天打开的环境。
原则：先完成，再扩展
新工具最容易失败的原因不是功能少，而是第一天配置太多。第一周的规则很简单：每天只引入一个变化，并给它一个完成标准。
| 天数 | 重点 | 当天完成标准 |
|---|---|---|
| 第 1 天 | 基础安装与模型 | 能发起一轮正常对话 |
| 第 2 天 | 工作区 | 用一个真实小任务读写项目文件 |
| 第 3 天 | 第一个插件 | 安装、重启、完成一次最小验证 |
| 第 4 天 | 场景组合 | 为一个工作场景挑 2–3 个候选，不全装 |
| 第 5 天 | 可靠性 | 记录 profile、命令与回滚方式 |
| 第 6 天 | 安全边界 | 审查一个涉及文件或网络的插件 |
| 第 7 天 | 复盘 | 删掉没用的东西，写下下周要改善的一件事 |
第 1–2 天：先让基础链路可用
完成安装 DSH和配置模型后，不要立刻切换多家模型。选一个自己有权限、响应稳定的提供方，用一个真实但低风险的任务测试：总结一段会议记录、解释一段代码或生成待办清单。
第二天再把工作区接进来。目标不是“让 Agent 接管电脑”，而是验证三个基础动作：它能读到你指定的文件、解释它看到的内容、在你确认后写出一个小改动。每一步都应该可检查、可撤销。
第 3 天：安装一个能立刻省时间的插件
从插件目录或场景组合挑一个只解决当前痛点的插件。安装前用兼容性检查看资料是否齐全，再按下面顺序验证：
- 复制并保存原始安装命令；
- 确认命令的 profile 与当前环境相同；
- 安装后重启或刷新；
- 用 README 中最简单的例子验收一次；
- 不符合预期就卸载，不要“先留着”。
第一个插件的价值是让你学会完整闭环，不是让桌面看起来更热闹。
第 4 天：为一个场景设计流程，而非堆功能
选择一个高频场景，例如“把需求变成网页原型”或“每周整理项目进展”。写下输入、产物、人工检查点，再决定是否需要第二个插件。
输入：三条产品需求
过程：澄清问题 → 生成结构 → 产出初稿
人工检查点：确认事实、术语和敏感信息
产物：可编辑文档或代码草稿
如果第二个插件不能明确缩短其中一步，就先不要装。真正有效的工作流是步骤少、交接点清晰、失败后知道从哪里重来。
第 5–6 天：把可恢复性和安全变成习惯
建立一个简单的 dsh-notes.md 或笔记页面，记录：
- profile 名和用途；
- 已安装插件及其上游 URL；
- 需要授权构建脚本的依赖；
- 常用提示词/工作流；
- 卸载或回滚时要做什么。
第六天专门审查一个有更高权限的插件。它会读哪里、连到哪里、是否需要 token、失败时会不会执行额外命令？详情页的机审证据只能帮助你提问；最终仍要看上游 README 和源码边界。完整方法见安装插件前的安全检查清单。
第 7 天：做一次小复盘
问自己四个问题：
- 哪个任务比不用 DSH 更快？
- 哪个插件从没真正用过？
- 哪一步最容易让 Agent 误解或越权？
- 下周只改哪一件事？
卸载无用插件、保留有效提示词、把一个失败案例记下来。稳定的工作台不是一次配置完成的，而是每周删掉噪音后留下来的。
常见问题
第一周应该装几个插件？
通常 1–3 个足够。超过这个数量时，先解释每个插件解决哪个具体步骤；解释不清的先不装。
我能直接复制别人的完整配置吗？
可以当参考，不能跳过验证。对方的模型、系统、profile 和权限边界都可能不同。先复制一个能力，再用你的真实任务验收。
下一步
当工作流稳定后，再学习插件的升级与卸载，避免配置慢慢失控。