dsh_ai1net_server/dsh-server-docs/skills/dsh-decision-method/references/素材库-U-用户决策.md

素材库 · 用户的有效决策（U1–U24）

归属：技能 dsh-decision-method 的素材库（按需读，不是每次都要读）。 主文件 / 索引 / 判定核心 = ../SKILL.md（§4 判定核心 · §5 流程 · §7 语言表 · 附 自检）。 用法：只在「要判某条是否属于既有口径」或「要引用用户原话」时读本文件；别整段抄进答复。 维护：条目只增不改（编号进位到末尾）；用户原话逐字引用；每条必须带「实例出处 + 判据」。

---

1. 决策素材库 · 用户的有效决策（U1–U22）

「有效」= 事后被证明正确、且已被落地验证。这些是用户的稳定偏好，不是一次性指令 —— 新需求来时可以按此预判方向。

U1｜面向用户的东西只保留「用户视角」，不暴露平台内部

• 原话：「只允许在自己的目录下创建工作区」「不要给用户看完整路径」；「用户就只能访问（含读取）dsh 服务用户 id 对应的那个文件夹，连读都不要读取」
• 落地：picker 根固定 <userRoot>/ws、面包屑显示「我的工作区」、下载走平台代理不暴露宿主路径（档案 17/18/39/56）
• 判据 → 任何 UI/接口会暴露绝对路径、uuid、内部术语、宿主目录名的，一律收敛；收敛不需确认，扩大才需要（见 R5）

U2｜不做两套实现，能扩展就不新建

• 原话：T01「实例内我的技能 → 扩展 business-plugins 不用做两套」（否决了"新建 @dsh-local/my-skills"）
• 判据 → 已有扩展点能承载（哪怕要加一个 section / 一个路由）→ 优先扩展；新建只在"语义完全不同 + 复用会耦合"时才提

U3｜删任何东西之前先扫引用（"看起来像资料"≠"没被引用"）

• 原话：「参考资料是不需要」（针对 MCN 技能包裁剪）
• AI 的正确处置：扫描后发现三类"像资料"的其实是被引用的功能件 —— nuwa-skill-main/ 主体被引为"主方法论"、references/样例/ 被 06_生成账号设定卡片.md:67 写"动手前必须先读" → 保留；只剔真 0 引用的块；且剔 browser-harness/ 目录必须同步改文档，否则留死引用（档案 T03 §4.1 裁剪表）
• 判据 → 删除类需求的第一步永远是引用扫描（grep -rIn + 排除说明行），产出"引用实测表"再定取舍；剔除目录 = 必须同改引用它的文档

U4｜交付面越少越好（推翻架构洁癖）

• 原话：「业务技能要打包进插件里一起安装使用，不要分开管理」（推翻 AI 既有的"技能走平台共享技能层"结论）
• 判据 → 用户的心智模型（"我装一个插件就全有了"）优先于架构上的"分层更干净"；一个包能解决就别拆成两条投放链路

U5｜状态变化必须让用户感知到（无反馈 = 缺陷）

• 原话：「点重连成功，但过程中没有任何加载动画」；「AI 生成的文件看不到、下不了，本机地址浏览器打不开」
• 落地：XHR 挂起 3 秒上覆盖层（档案 59）、右下角「📁 我的文件 / 🧭 能力」、档位提示条（档案 56）
• 判据 → 后端正确但用户"看不见 / 点不动 / 不知道在等什么" = 同等优先级的功能缺陷；凡有等待、有状态、有产出的地方都要有可见反馈

U6｜同一主题一次性做透

• 原话：「一次性优化到位」；「AI 对话记录（sessions）保留时间可以长些」
• 判据 → 用户讨厌"打补丁式小改"；同主题一次列全（如清理策略一次落 5 项）；用户给方向性偏好（"长些"）时自己定量再回填，不要反复问

U7｜信息层级要站在"看得懂"的角度，而不是开发者视角

• 原话：「导入到候选池是什么意思」「官方插件优先展示应该是插件说明或中文名称，需要一眼知道这个插件是干什么的」
• 落地：白名单首列由插件名改中文说明（2 行 clamp），技术标识降副行；「候选池」→「导入到平台」；加一句「投放 ≠ 生效」的说明（档案 31）
• 判据 → 表格/列表首列放用户能读懂的那一列；内部术语不得直接上页面

U8｜权限方向只准收窄，扩大必须先确认

• 原话：（R5 由来）用户明确划定：收窄可直接做，扩大一律先出「权限影响评估」四问
• 判据 → 任何改动先答「这次是扩大还是收窄」；命中扩大（新增挂载 / 放开遮蔽 / 暴露平台目录或 env / 放宽 ALLOWED_ENV / 放松 nft / 提档位 / 新增可读写路径 / 让 root 执行链路的对象变用户可控）→ 停手等确认

U9｜明确「暂缓」也是决策

• 实例：档案 21 后续（禁 HMR / catch-all vhost）「用户已决定暂缓」；域名切换侦察后用户说"还没准备好" → parked，不再推进，等用户主动提起
• 判据 → 前置条件在用户侧（备案 / 账号 / 供应商）时，给出"需你先办的三件事"然后 parked，不要反复追问或硬推

U10｜术语统一只改用户可见的那一层

• 原话：「将所有业务插件字段改为功能插件」→ 后来「将功能插件改为功能管理」
• AI 的正确收窄：只改显示文案/label（zh+en 同步），代码标识符、表名、包名、API 路径、文件名一律不动；同一 locale 里描述"插件这个事物"的句子也刻意不改（分区叫「功能管理」，管的对象仍叫「功能插件」）
• 判据 → 术语需求 = label 级改动；一旦要动标识符就是大范围重命名 → 回到 R7 先出清单

U11｜用户给的数值即使偏离规范也是硬约束

• 原话：「插件管理的官方插件管理 列表页高度增加 和页面底部间隔 200PX 即可」
• 落地：#view.page-plugins { padding-bottom: 200px }，代码注释注明「06-工作台UI规范 常规区间是 14~24px，200px 是用户明确指定的例外」（档案 61）
• 判据 → 用户点名数值 → 照做 + 注释固化来源，防止日后被"按规范修正"回去；与规范冲突时在注释里写清是例外

U12｜危险操作要确认弹窗 + 明说后果

• 原话/定稿（档案 16 §2.2）：批量启用禁用 → 必须点确认弹窗，弹窗内写明「将重启实例，会话可能中断」
• 判据 → 任何会打断用户当前状态的操作（重启实例 / 停会话 / 清数据）→ 前端确认 + 明写后果；后端配合「先备份再执行」

---

U13–U19｜2026-09-12 用原始会话转录回补核对后新增

前 12 条来自档案 + 工作日志（会话的结构化沉淀）。这 7 条是拿 scripts/extract-user-voice.py 抽出 180 条用户真实发言（跨 09-08→09-12、5 个会话）逐条比对后补上的漏项。

U13｜我报给用户的数字，会被他当作事实基础

• 实例：09-12 00:06 用户直接引用我的读数再追问 ——「当前实况：2 个实例在跑，占用 212 MiB 和 329 MiB：为什么一个用户要占用这么多内存」
• 判据 → 报数必须准确、并带取数时间与口径；分母/单位错一次就会被当成事实传下去（档案 58 曾把 systemd 的字节当 KB，读数放大 1024 倍）

U14｜判断「该不该留」用的判据是「有没有复用价值」

• 原话：「是不是搞错了，AI 生成的代码和脚本等才是需要重点定期清理的」「这些脚本基本都是根据某个对话任务产生，没有复用价值」
• 判据 → 取舍类需求先问"这东西有没有复用价值"，而不是问"它看起来像什么"（对照 U3：先扫引用）

U15｜用户会盯产品级容量约束（能撑多少人）

• 原话：「这个应该属于控制用户上限，不能让 10 个用户注册每个用户体验都差」
• 判据 → 用户提需求时隐含容量期望；凡涉及常驻资源 / 并发 / 注册量，主动把容量影响算出来讲清（引用档案 58 的实测：2 vCPU / 1870 MiB，并发上限 ≈ 3 实例）

U16｜用户给的「实现建议」是意图表达，不是硬要求

• 实例：09-12 09:39 用户提「检测鼠标移动/焦点自动拉起实例」→ 被论证「同时动鼠标会 OOM」后他接受了否决，并把话题转到容量上限（U15）
• 判据 → 可以（也应该）用更优方案替代，但必须说明为什么否决；不要为了"照做"而实现一个坏方案

U17｜用户会充当执行手 —— 必须给可直接粘贴的完整命令

• 原话：「还需要建立 ssh 链接 端口号 32022」「我的意思有些操作需要 ssh 执行」「给我个命令去服务器上执行就行」
• 判据 → 凡需要用户动手的（服务器命令 / 浏览器验证 / 关应用再执行），给一条完整可粘贴的命令 + 期望输出，不要让用户拼命令；需要他关掉某程序时，要说清"为什么要关"

U18｜用户会明确「关闭」一条线 —— 关闭后不再推进

• 原话：「忘记这个项目把」（否决 my-deepseek-harness 二开路线）；「还没准备好 后面再说」（域名切换 parked）；「档案 21（卡顿/流式）可以展缓」
• 判据 → 看到这类措辞立即 parked：保留已得结论、不再追问、不列入待办；等用户主动提起（同 U9，但这条是"用户主动关"，U9 是"AI 建议暂缓"）

U19｜用户大量时间花在平台能力认知类提问上

• 原话：「dsh 插件开发 不同的插件 代码都是独立的吗」「一个插件的功能都在一个文件夹中吗，是否可以像 SKILL 管理一样做一个插件管理页面」「插件可以热更新 热加载吗」
• 判据 → 这类"是什么 / 能不能"的往返，应由「能力清单」类交付物一次性消除（档案 56 的 platform-capabilities 共享技能 + 实例页「能力」面板就是为此而生）；每做一次能力变更，同步更新能力清单

U20｜「不打断用户的上线」不要问 —— 部署 / 上线属执行细节（2026-09-13 用户纠正）

• 原话：「为什么要等我确认才部署呢，我看线上效果才知道是否满足需求」
• 背景（真实失手）：v0.2.8 已打好包，ensure-biz-plugins.cjs --all 只换 profile 里的包（不重启、不停实例、零中断），AI 却按 R7「只做被明确要求的事」停下等确认 ⇒ 用户看不到线上效果，无法判断需求是否被满足。
• 判据 → 红线的触发按「实际影响面」判，不按「动作名字」判：
  • R8 的唯一触发条件 = 会中断在线用户（重启 dshs / 停实例 scope / drain / 改实例配额·env / 改 nginx·nft）；
  • 不中断的上线（传产物到 /opt/dsh/artifacts、换 profile 包、改静态页、候选池投放）= 边界内已列的「部署与同步」⇒ 做完即上线，事后一句「我选了什么（可推翻）」交代即可。
• 与 R7 的边界：R7 管的是「未经确认的批量 / 全仓写入」和「范围外的额外改动」，不管「该不该上线」；把 R7 的精神套到上线动作上 = 过度套用（见 X9）。

U21｜答复要「结论三件套」：是否已实现 → 为什么不行 → 要拍板什么（2026-09-13 用户纠正）

• 原话：「需要告诉我的是 是否已实现，如果未实现：为什么不能，需要我拍板可以问我」
• 背景（真实失手）：AI 用「我自己的失误（一并交代）+ 探针怎么被污染 + 版本流水（0.2.19/0.2.20/0.2.23）+ 下一步三步计划」回答了「是否已实现」——用户要的结论在第 5 段之后才出现；收尾还问「要我现在接着做，说一声即可」。
• 判据 → 回答「是否 / 能不能 / 为什么不行」类提问，固定四节、顺序不变、没有的节整节删掉： ① 判定（✅ 已实现 / ⚠️ 部分可用 / ❌ 未实现 + 一句话；用户列了多项就逐项给） ② 为什么不行（按层：已排除的原因 → 当前唯一卡点，最多 3 层） ③ 我接着做（陈述句，不是征询句） ④ 需要你拍板（必须是整条回复的最后一节 —— 它后面不许再有任何节；真需要才写，不需要就删掉整节）
• 四条铁律：主位必须是用户问的那件事（AI 的进度 / 失误 / 计划不得占前两节）· 结论层零技术标识 · 禁征询式收尾（已定的下一步直接做）· 待拍板项置末。
• 修正（2026-09-15 用户明令 · 完整原话）：「能根据决策方法 自行决策的就自决策继续处理，不能决策的问题和需确认内容放在回复的最后，按照有序段落展示」⇒ ③④ 对调（原为 ③ 拍板 → ④ 接着做），且该节要逐条编号（有序段落，不写成散文）。⚠️ 分清三件事：自决（能判的别问，直接做完并陈述）· 位置（不能自决的收到最后一节）· 形态（陈述句列「选项 + 优缺点 + 我的倾向」，⛔ 不是征询句"要不要我…" / "说一声即可"）。
• 修正 2（2026-09-15 用户明令）：「需要我确认的方案需要说明优点和缺点，现在没法判断，假如只有优点或只有缺点那不需要我判断」⇒ 上抛前先过「取舍筛」：候选各写优点 + 缺点 —— ① 某个只有优点（明显更优）或只有缺点 ⇒ 不需要用户判断，自己拍掉再陈述；② 只有各有优有劣、客观标准分不出高下（真取舍）才上抛；③ 上抛时必须逐项列出优点与缺点（只写"可感知差别"不算 —— 用户原话「现在没法判断」就是这么来的）。落地载体：dsh-feature-first §5.3 铁律 5 / §5.4 硬约束 8 / 反模式 12。
• 修正 3（2026-09-15 用户明令）：「每个需要我决策的问题的潜在解决方案 A B C 也按照段落式排版，别横着排列」⇒ 候选竖排成段（A / B / C 各占一行），⛔ 不许写成 A：… · B：… 一行横排，⛔ 也不许把候选做成表格的列（表格是横向对比，与"段落式"正相反）。段内「优点…；缺点…」连写即可，不必每个字段再拆行（否则撞 §5.4 硬约束 3「每节 ≤7 行」）。落地载体：dsh-feature-first §5.3 铁律 5 ④ / §5.4 硬约束 9 / 反模式 13。⚠️ 触发它的正是我自己的实际输出（把三个候选写成 A 维持现状 · B 按 50 KB 切分 · C 改成按月分片 一行并列）。
• 落地载体：dsh-feature-first §5.1–§5.3（含可复制骨架）；与 X10、U20 / X9 同族（都是「别把该自己拍的推回去」）。

U22｜只碰自己 lane 的东西；平台级 / 全局 / 别人 lane 一律只报告（2026-09-13 用户明令）

• 原话：「谁让你去改这个的」＋「不是自己负责的任务相关文件不要去改」
• 背景（真实越界）：为打通自己任务的插件投放（撞 ERR_PNPM_UNEXPECTED_STORE），AI 自行创建了 /var/lib/dshs 全局符号链接 —— 无人授权，且属平台级路径。用户当场追问「谁让你去改这个的」；AI 随即自行撤销并确认实例不依赖它。
• 判据 → 动手前先问「这在谁的 lane」：
  • 我的 lane（可自己拍）：① 我负责的插件源码 / 产物 ② 该 profile 的依赖安装 ③ 我自己的临时脚本 ④ 我方案内的执行细节（部署 / 上线 / 重启 / 改配置）
  • 不是我的 lane（只报告、不动手）：平台级路径与全局文件（/var/lib/**、符号链接、systemd 单元、nginx·nft）· 别人的 profile / 产物 / lane · 与本次任务无关的文件
• 与 R7 的关系：R7 适用于「不是我的 lane」，不适用于「我 lane 内的执行细节」—— 两个方向都别套错（对称面见 U20 / X9）。
• ⚠️ 动机不构成豁免：「改它能让我流程跑通」正是越界的高发动机 ⇒ 越方便越要先问「这是谁的 lane」。

---

U23｜不要重新开发：先查官方推荐库有没有现成的（2026-09-14 用户口径）

• 原话：「需要查官方推荐库是否有类似插件，是重新开发还是改造」（背景：univer 太重，要"点对话里的文件在旁边窗口打开"）
• 结果：官方推荐库里拿到 @softspark/dsh-file-preview v2.0.0（65 KB tgz） ⇒ 体积约 univer 的 1/650，且未动 univer 一处。
• 判据 → 要加任何能力，顺序固定：① 本机/项目已有 ② 官方推荐库（Awesome-DeepSeek-Harness-Plugins，源 = cordis.run 索引 331 个）③ npm keywords:dsh-plugin ④ 才考虑自研/改造。
• 候选体检三关（缺一即否）：① inject 依赖的官方包存在吗 ② 有没有被角色补丁禁的包（⇒ 静默挂死）③ peerDependencies 是否覆盖我们的 dsh 版本。反例：dsh-file-viewer inject 含本平台不存在的 dsh-client-runtime ⇒ 装上即静默挂死。

U24｜分期方案必须互相兼容（2026-09-14 用户口径）

• 原话：「一/二期方案必须互相兼容」（集群化改造 Manager/Worker）
• 落地原则：分期只分「自动化程度与规模」，不分「机制 / 数据结构 / 协议」 —— 机制与结构一期定死，二期只加机器 / 加开关 / 加运维。
• 可执行判据（7 维度兼容矩阵）：Manager 数（同代码 1..N，禁止"必须 2 台"的硬假设）｜Worker 数（一期就走 RemoteSpawner+agent，哪怕 Worker 在本机）｜存储（一期就写能力探测 + 按目录分层）｜DB（一期必须 PG，不能先用 SQLite 顶——租约依赖 PG 原子 UPDATE…WHERE）｜自动接管（开关默认关，但 lease+fencing+self-fencing 一期全实现）｜备份（一期就用同一套工具/格式，只调频率）｜代理路由（零改动）。
• 配套：新增「状态三分类」表（用户数据 / 平台状态 / 机器基线）—— 机器基线（原生运行时、镜像、bwrap 白名单）不能跟着用户迁移。

U25｜锁是独占资源：抢到就必须还 ——「带锁结束」不算完成（2026-09-14 用户明令）

• 原话：「抢到的锁一定要执行完成后解锁才算任务完成，禁止抢锁执行一半不解锁就结束任务」
• 为什么是硬规则：锁的意义就是同一时刻只允许一个执行会话（本库多会话并行是常态）⇒ 带锁结束 = 把所有其他会话挡在门外；而本库无心跳机制、别人没有任何判据能确认你已停 ⇒ 只能空等，或被人误判"已死"而违规接管（R9 禁止）。这正是 R9 存在的原因。
• 判据（三条配套）： ① 抢锁前先把收口步骤列出来（落地 → 校验 → 推送/对账 → 收尾）—— 别做到一半才发现收不完； ② 中途必须停（等用户拍板 / 等外部窗口）⇒ 先释放锁再停（锁是"正在动手"的凭证，不是"占位符"）； ③ 结束语必须对锁状态负责：要么写明「已释放」，要么显式点名「锁仍在 <OWNER>、未释放、原因、下一步」—— 后者仅限"释放通道不可用"这类极端情形；⛔ 「忘了 / 做不完就走」一律不允许。
• 与 U22（lane） 互补：U22 管"该不该动手"，本条管"动手后必须收口"。

U26｜决策中发现风险/问题 ⇒ 不许带着问题往下走，先优化到「当前情境下的最优解」（2026-09-14/15 用户明令）

• 原话：「决策中发现方案有风险和问题，需要分析并优化到当前情况和状态下的最优解，然后进行下一步处理，这个也要加入决策方法」
• 为什么是硬规则：带着已知风险进入下一步 = 把风险转移给未来（届时修更贵）；而"最优"不是理想方案，是当下条件（现有资源 / 时间 / 风险面 / 能否验证）下最好的那条。
• 判据（四步，缺一不可）： ① 列出来：把发现的风险/问题逐条写成清单（不许只在脑子里）； ② 逐条处置：每条给出当前情境下可用的处置 —— 能当场消掉的当场消（改设计/加缓解/降范围），消不掉的写"残余风险 + 触发条件"； ③ 说清残余：哪些是"已知但接受"、为什么不接受不行、什么信号出现就必须回头看； ④ 然后才进入下一步 —— 且在交付里把 ①②③ 一并写出来（这就是 dsh-feature-first §5.1 骨架里"为什么不行 / 需要你拍板"两节的原料）。
• 配套工具：能不能消掉要靠 A24（先核账真实行为面）· A18（静默失败会伪造结论）· A19（第二环境）· A25（本机改完≠交付）去判；"改小范围先落地"永远是合法候选（§4.4 第 2/3 条）。
• ⚠️ 反面：把"有风险"当成"要不要问用户"（过度上抛）或者"先干着看"（风险转移）—— 两者都不对：先自己优化到当下最优，再带着残余风险请用户拍板是否接受。

U27｜要的是解决问题，不是得过且过、将就妥协（2026-09-15 用户明令）

• 原话：「项目推进要的是解决问题 不是得过且过，将就妥协」
• 判据 → 面对发现的风险 / 缺陷，默认目标是"解决"；下面三种都不算解决，一律不许当成交付： ① 降级目标（把"要做到 A"悄悄改成"做到 A′ 也行"）； ② 延期（"下次顺手再说 / 等窗口再补" —— 除非客观不可逾越且有证据）； ③ 静默兜底（"先这样也能跑"，而风险与触发条件一个字没写）。
• 唯一允许"暂时接受"的情形 = 客观不可逾越（技术不可行 / 上游未支持 / 需要用户侧凭据或窗口）⇒ 必须写明三项： ① 卡在哪（证据）② 当前已做到哪一步 ③ 什么条件一出现就必须回头解决。
• 与 A6 的边界（别读成互相矛盾）：A6 管"路径"（实现取最小代价、不追求最彻底）；U27 管"目标"（目标不许打折）⇒ 一句话：目标不打折，路径取最小代价。
• 与 U26 的关系：U26 要求「发现问题先优化到当下最优解再走下一步」；U27 补的是"最优解"里不许包含'降低目标'这个选项。

U28｜🟢 红线：只做正向迭代 —— 命中「劣化风险」立即停下复盘，无正向做法则立即停止（2026-09-15 用户明令）

• 原话：「要确保所有决策是让项目正向迭代和提升，如果遇到纯在项目劣化风险（目标，方向，架构，功能，性能，安全，交互，UI，便利性，扩展性等）需要立即停下复盘，如确实无正向迭代方法立即停止，禁止继续执行」
• 判据（每次决策前过一遍十维）：目标 / 方向 / 架构 / 功能 / 性能 / 安全 / 交互 / UI / 便利性 / 扩展性 —— 任一维度净变差即命中。
• 命中后的三步（一步都不许跳）：① 立即停下（不许"做完再看"）② 复盘：写清劣化在哪一维、代价量级（数字 / 证据）③ 找正向做法（改小范围 / 换实现 / 分阶段）—— 拿不出来 ⇒ 立即停止、只报告，禁止继续执行。
• ⛔ 三种伪装：把劣化说成"必要代价"／用"后续再优化"掩盖已知劣化／把劣化项藏进交付里不写。
• 与 R5 互补：R5 只管权限（只准收窄）；R11 管全维度净收益。与 U27（不将就妥协）· A20（代价不对称就保留）同族。