30 KiB
功能优先协作协议（用户只提功能卡 · AI 自主决策）
🔴🔴 归属：2026-10-04 起本档归
session-mechanism（用户定案逐字：「这个属于会话的自决策方法，应该属于会话逻辑」）为什么搬：这套协议答的是「在会话里做事时，该自己定还是该问用户」—— 而
session-mechanism管的就是「主会话 ↔ 执行会话怎么协作、活怎么派、结果怎么验」。 判据落在会话机制里 ⇒ 主会话派活时与任务会话执行时读的是同一份，⛔ 不会两处口径打架。 provenance：原技能dsh-feature-first（已退役）全文 ＋dsh-decision/references/01（2026-10-04 逐行搬入，内容守恒；⛔ 只改档名与 skill 名，判据正文一字未动）。 ✅ 本档即权威（2026-10-04 改，用户定案："只想复制一个技能到别的机器，这些功能都可以正常使用"）： 自决策白名单（§2）· 只准提报用户 3 类（§3）· 功能卡 4 问（§1）· 语言转换表（§3.3） 的判据实体就在本档正文里 ⇒ 只复制session-mechanism一个技能即可用，⛔ 不依赖任何其他技能。 📌 来路（保留以便追溯）：本档 2026-10-04 从dsh-decision/references/01逐行搬入； 其判据 2026-09-12 起的「完整版」曾寄放在agent-operating-rules §1.6／§1／§2／§2.5（跨项目通用技能）。 ⇒ 本机若同时装了那个技能，以本档为准（避免两处各存一份、改一处忘另一处）。 ⚠️dsh-decision/references/01侧的残留摘要仍在（那份技能本机也有）⇒ 若两处都读， 改判据以本档为准；dsh-decision那份已于 2026-10-06 按用户令删除（该技能现只留指针）⇒ 不必再同步。
dsh-feature-first — 功能优先协作协议
一句话：把「事前请示」改成「默认自主 + 事后可推翻」。 用户的输入只到功能层（谁、在哪、做什么、怎样算成功）；技术层全部由 AI 自主决定并记录。
0. 为什么要有这条协议（复盘证据，2026-09-12）
0.1 事实：用户的时间被技术问题吃掉了
对 dsh-server-docs/04-调整方案/ 全部档案按「触发来源」分类（含「触发」字段的 42 份）：
| 类别 | 份数 | 占比 | 含义 |
|---|---|---|---|
| 用户的功能 / 交互需求（用户的主场） | 15 | 36% | 16 / 18 / 19 / 31 / 34 / 36 / 37b / 38b / 53 / 54 / 56① / 57 / 60 / 61 / 62 |
| 技术类（用户被拉进技术判断，或 AI 做技术排查） | 17 | 40% | 12 / 14 / 22 / 23 / 26 / 27 / 29 / 32 / 33 / 35 / 37a / 38a / 42 / 55 / 58 / 64 / 65 |
| 用户报障（用户只能看到现象，被迫当测试） | 10 | 24% | 15 / 17 / 21 / 24 / 25 / 30 / 49 / 51 / 56② / 59 |
⇒ 技术类 + 报障类 = 27/42 ≈ 64% —— 用户 2/3 的注意力花在自己不擅长的领域。
复核命令：
cd dsh-server-docs/调整方案 && grep -Hn "触发" *.md（分类可按档案号逐一核验） ⚠️ 该比例是快照，会随档案增长变化；引用时须重新取数。
0.2 五个根因（按影响排序）
| # | 根因 | 表现 |
|---|---|---|
| 1 | 技术问题被"决策化"了 | AI 把"我不确定选哪条技术路径"包装成「决策点」提报用户：走 CF 代理还是改 DNS、要不要 watchdog、内存能否降到 512M、要不要 enablePatch。用户没有判断依据，只能凭感觉点头 |
| 2 | 需求没有"规格层" | 用户说「AI 生成的文件看不到、下不了」→ AI 直接跳到技术方案（新增端点 + 注入脚本 + 面板）。中间的"谁在什么场景要看到什么、怎样算成功"没有沉淀 → 每次都要重新谈技术 |
| 3 | 报障驱动 | 平台上线后用户输入大量来自"坏了"而不是"我要什么"；报障的根因排查天然是技术沟通 |
| 4 | 没有"技术默认值" | 项目其实有大量技术原则（红线 R1-R8、只准收窄、最小代价路径、能一行代码就不改平台），但没有一条"AI 自主技术决策的授权边界" → 每次都重新分析、重新提报用户 |
| 5 | 交付语言是技术语言 | AI 汇报用 commit / 文件 / md5 / 端点；用户只能靠技术语言参与验收 → 反过来推高了技术沟通量 |
1. 用户的输入：只填「功能卡」4 问
用户不需要描述技术方案、不需要指定改哪个文件、不需要选技术路径。只回答这 4 件事（缺的 AI 自己补默认值并标注）。
1. 谁用？ （角色：admin / 普通用户 / 两者）
2. 在哪用？ （哪个界面：门户某页 / 实例内设置 / 会话页 / 右下角…）
3. 要做什么？ （用户视角的动作与结果，一句话）
4. 怎样算成功？ （用户能亲眼看到/亲手验证的验收点）
示例（用户侧的正确写法）
「普通用户要能在设置里看到自己能启停哪些功能插件，勾选后确认，重启后生效。」
示例（不要这样写）
「在 business-plugins 的 settings.section 里加一个 id、调 /api/plugins/mine/apply、重启实例生效」—— 这是实现，不是需求。
AI 侧：拿到功能卡后，缺什么自己定；定完在档案里记「技术选择」段（见 §5）。
2. AI 自主决策的 9 类白名单（永不问用户） → 本档 §2 即权威
✅ 判据实体＝本档下方那张表（2026-10-04 起；⛔ 不再是"内联摘要"，它就是权威）。 命中以下任一类 ⇒ 直接定、直接做，只在档案里记一句「我选了什么（可推翻）」——
| # | 类别 |
|---|---|
| 1 | 技术选型（API / 表 / 库 / 协议 / 存储格式） |
| 2 | 实现路径（改哪一层、配置还是改码、复用哪个扩展点） |
| 3 | 命名与结构（变量 / 路由 / 表名 / 目录 / 文件拆分） |
| 4 | 性能与资源调参（内存 / 并发 / 超时 / 缓存 TTL / 退避） |
| 5 | 部署与同步流程（scp 姿势 / 权限位 / 行尾 / 对账 / 脚本） |
| 6 | 排查方法（journalctl 还是埋点、怎么复现与取证） |
| 7 | 版本与依赖（选版本 / 预装还是按需拉 / 打包方式） |
| 8 | 兼容与降级（显式抛 unsupported，不假装支持） |
| 9 | 文档与档案的技术内容（编号 / 模板 / 章节 / 脚本实现） |
判断口诀：「用户能不能从功能视角判断这个选项的好坏？」 能 → 可提报用户（见 §3）；不能 → 这就是 AI 的工作，不要问。
3. 只准提报用户的 3 类（+ 语言转换表）
唯一判据（用户 2026-09-12 原话）：只问「超过现有判断方法边界」的问题。 边界内 → 一律自决策；边界外（§3.1–§3.4）→ 必须问。没有第三条路。
3.1 (a) 功能语义分叉 —— 选项之间存在用户能感知的差别
例：技能随插件包投放 vs 走平台共享层（差别 = 用户"要不要分开管理"）；新开会话 vs 迁移老会话（差别 = 用户"要不要重开一个"）；提示 vs 自动改档位（差别 = "AI 会不会悄悄改我的设置"）。
3.2 (b) 红线门禁 —— 必须用户点头
- 扩大权限/可见面（R5）
- 批量 / 全仓写入（R7，>10 文件）
- 不可逆的破坏性操作（删数据 / 迁 DB / 清目录 ⇒ 先出清单）
- ⛔ 「中断在线用户」已不是门禁（2026-09-13 用户明令 + 2026-09-16 收口）：
R8原文 —— 47 是「开发环境服务器」，不用担心中断用户 ⇒ 重启服务 / 停实例 scope / drain / 改配额·env / 改 nginx·nft 均可直接做，只需动手前一句话说明在动什么。 ⚠️ 原表述「只有真会中断的（重启服务 / 停实例 / drain / 改配额·env / 改 nginx·nft）才提报用户」是会话ddea70b7提报用户的直接依据 —— AI 据此把"106 旧控制面要不要停"拿去问用户，而用户随后两次（U5 / U7）自己给出"删除"。⛔ 别再拿"重启 / 停实例 / nginx"当提报用户理由。 - ⚠️ 判据：按「实际影响面」判，不按「动作名字」判（2026-09-13 用户纠正）—— 看到「部署 / 上线 / 生产 / 铺包」就提报用户是过度套用：
不中断在线用户的上线（传产物 / 换 profile 包 / 改静态页 / 候选池投放）属边界内的执行细节 ⇒ 做完即上线，自决策。详见
dsh-decision-methodU20 / X9。 - 🔑 "平台级" ≠ "别人的"（2026-09-16 收口）：
dshs*·dsh-*systemd 单元、/var/lib/dshs/**、nginx·nft、端口，在我们自己的 47 / 106 / 本工作区上 ⇒ 本平台自己的资源 ⇒ 直接做。只有别人的 / 归属不明的才"只报告不动手"。判据看"归属"，不看"是不是平台组件"。
3.3 提报用户格式（强制） → 本档 §3.3 即权威（下方即全表）
完整对照表已收敛到通用技能。最小摘要（3 条铁律）： ① 提报给用户时不出现包名 / 环境变量 / 文件路径 / commit / API 路径 / 代码标识符 —— 出现即是没转换。 ② 翻译方向 = 从"技术选项"翻成"用户能感知的差别"。例：不问「要不要启用
enablePatch」，而问「要让用户自己装插件，还是只由管理员统一装？」 ③ 一轮最多一个问题，且同类不连问两次。
3.4 (c) 超出决策方法边界的事 —— 必须问（用户 2026-09-12 明确）
用户原话：「有超过现有决策方法边界的事情，还是需要问的。」 即：方法覆盖得到 → 自己定；覆盖不到 → 必须问。这条是 §2 的例外出口，也是闸门的 fail-open 依据。 ⚠️ 判据是「有没有客观可判的优劣」：有 → 方法能判，自己定；没有 → 那是用户的取向，必须问。
| # | 边界外的类别 | 例子 | 为什么方法判不了 |
|---|---|---|---|
| 1 | 业务目标与优先级 | 先做哪个功能、这个功能要不要做、值不值得投入 | 方法只能判"怎么做得最优"，判不了"该不该做"。 ⚠️ 出口（2026-09-16 加）：方向已定（用户已说"要做这几个功能 / 该谁处理就开发对应功能"）时，"先做哪个"若候选有客观排序（如"先做能闭环真实缺陷的那项"、"3 项 P0 阻塞真实场景"）⇒ 属边界内，自决策。只有"几个都该做、用户对节奏/取舍有偏好"才提报用户。 实证：会话 ddea70b7 把"D1–D6 先做哪些"归进本类 ⇒ 提报用户 ⇒ 用户回「按照你的规划执行」（AI 自己其实已排出顺序并写了"我倾向先 D1+D2"） |
| 2 | 成本与资源承诺 | 买云资源 / 开第三方账号 / 花钱买额度 | 涉及用户的钱，不是技术优劣问题 |
| 3 | 对外承诺与合规 | ICP 备案、资质、合同、对外 SLA、对外品牌文案 | 法律与商业后果，超出工程判断 |
| 4 | 需要用户提供的第三方凭据 / 审批 | API Key、DNS 权限、企业审批、账号授权 | 只有用户有 |
| 5 | 用户体验偏好（无客观优劣） | 审美与文案语气、默认值取向、提示语措辞 | 没有"更优"，只有用户"更喜欢" |
| 6 | 影响面超出本平台 | 会波及其他系统 / 他人数据 / 不可逆的对外影响 | 影响半径超出我能判断的范围 |
| 7 | 红线门禁（R5 扩大 / R7 批量>10 / 不可逆破坏性操作） | — | 安全与影响面变更必须用户知情同意。⛔ 不含 R8 —— "中断在线用户"已于 2026-09-13 修正（开发环境服务器 ⇒ 直接做，只须动手前一句话说明） |
| 8 | 方法确实判不准 | 两边都无依据、事实不足以判断 | 宁可问，不要卡死 |
提报用户方式：这 8 类照实说人话说明「你为什么需要他决定」，不要包装成技术选项。
3.5 方法本身的演进 —— 改为自决策（用户 2026-09-12 明确）
用户原话：「以后决策方法的问题就不需要再问了。」
- 方法的日常应用不问：边界内的一切判断，按 §2 +
dsh-decision-method §4.4自己定。 - 方法本身的修订也不问：发现方法有缺口 / 有反例 / 需要加规则时，直接改、直接记录（改完在交付回执里说一句"我更新了方法：因为 X"），不要拿"要不要加这条规则""这么写好不好"去问用户。
- 唯一例外：方法修订若扩大了 AI 的自主权或收窄了用户的门禁 → 属边界外的第 1/7 类，必须问。
3.6 ⛔ 拆包提报用户：红线问题不得与技术方案捆在一起问（2026-09-12 实证）
实证（会话「任务执行2」14:39）：AI 把「要不要现在重启服务（R8，该问）」和「用 A 还是 B 实现（技术项，不该问）」捆成一个提问，用户被迫先读懂两套技术方案才能回答那个红线问题 → 用户的体感依然是"又在让我确认技术问题"。这才是"设置了却没用"的真正形态：不是问得太多，而是把该问的和不该问的混在一次提问里。
三条规则：
- 剥出红线问题单独问，且只问用户能判断的维度：要不要现在动生产 / 影响谁 / 断多久 / 能否避开。
- 技术形态自己定，作为已定项写进回复（"我按 B 做，因为…；可推翻"），不要做成选项让用户选。
- 一轮最多一个问题；同一个问题不要连问两次（实证：11:16 与 11:42 两次问"用哪个账号验收"，第二次只是细化 → 本可合并成一次，或直接自定）。
该会话 6 次提报用户的逐条判定（反例对照）：
| 时间 | 问的什么 | 判定 |
|---|---|---|
| 10:34 | 21 处 Windows 专属指引怎么处理（一并改 / 只改单子 / 先出清单） | ❌ 纯技术项（范围 + 实现路径）——该自己定 |
| 10:21 | 行尾 CRLF 怎么处理 | ✅ 该问（命中 R7：批量换行符转换需授权） |
| 11:16 / 11:42 | 验收用哪个实例 / 账号 | ✅ 该问（影响面）· ❌ 连问两次，可合并 |
| 13:32 | admin 崩溃怎么修 | ✅ 该问（R8 + 跨会话）· ❌ 选项里混了"我拆 / 转给对方 / 只给命令"三种技术路径 |
| 14:39 | 选 A/B 方案 + 要不要重启 | ✅ 红线该问 · ❌ 技术方案不该问 → 典型捆包 |
正确写法（照这个格式写）：
我先按 B 做（平台侧自动摘除坏插件，覆盖所有装法）——**已定，可推翻**。
但它要重启 dshs：
· 影响谁：当前所有在线用户（刚实测 guest 实例在跑）
· 断多久：数秒；实例"访问即拉起"，会话数据不丢
· 能否避开：可以等空闲；或并入 T04 那批改动只重启一次
**请定：现在就重启，还是等窗口？**
4. 报障闭环前置（让用户不必报障）
报障类占 24%，大部分可以从源头消掉。凡涉及"用户会撞上的状态"，必须同时交付：
| # | 要求 | 已落地先例 |
|---|---|---|
| 1 | 错误页给人话 + 下一步，禁止裸 JSON / 英文原文 | 档案 25（not_running 不再吐 JSON） |
| 2 | 等待必有可见反馈（导航路径 + XHR 路径都要有） | 档案 59（3 秒后亮覆盖层） |
| 3 | 状态可自查（能力清单 / 我的文件 / 档位提示） | 档案 56 |
| 4 | 能自愈就不报错（401 透明重放、回收后自动恢复） | 档案 24 / 45 / 49 / 51 |
| 5 | 缓存/后台任务的状态可见（"更新于 X 前"、可手动重拉） | 档案 62 |
判断口诀：「用户遇到这个情况，会不会只能来问我？」 会 → 先把反馈做出来。
5. 答复与交付格式（功能性语言优先）
5.1 结论骨架（回答「是否已实现 / 能不能 / 为什么不行」类提问）
2026-09-13 用户纠正原话：「需要告诉我的是 是否已实现，如果未实现：为什么不能，需要我拍板可以问我」 触发场景：用户问「是否已实现」，AI 却用「我自己的失误（一并交代）+ 探针怎么被污染 + 版本流水 + 下一步三步计划」作答 —— 要的结论被埋在第 5 段之后，用户只能再追问一句。
固定四节，顺序不许换；没有的节整节删掉，不要留空标题：
⚠️ 「需要你拍板」必须是整条回复的最后一节（2026-09-15 用户明令：「要把需要我确认或决策的内容放在 最后，别隐藏在回复内容中间 | 按照有序段落展示」）—— 它后面不许再有任何节，且必须逐条编号（有序段落），不写成散文。理由：夹在中间 ⇒ 用户扫不到、漏答。 ✅ 配套的反向要求（同一句原话前半段）：「能根据决策方法 自行决策的就自决策继续处理」⇒ 能自决策的不要停下来问，直接做完并陈述；只有不能自决策的（真门禁 / 需你给凭据或窗口）才收进这一节。 🎯 提报用户标准 = 存在"真取舍"（2026-09-15 用户明令：「需要我确认的方案需要说明优点和缺点，现在没法判断，假如只有优点或只有缺点那不需要我判断」）：把候选各写 优点 + 缺点 —— 某个只有优点（明显更优）或只有缺点 ⇒ 不需要用户判断，自己拍掉再陈述；只有各有优有劣、且客观标准分不出高下才算真取舍，才提报用户，且必须逐项列出优点与缺点（只写"差别在哪"不算）。 📐 候选方案必须"竖排成段"（2026-09-15 用户明令：「每个需要我决策的问题的潜在解决方案 A B C 也按照段落式排版，别横着排列」）：A / B / C 各占一行（各自成段）；⛔ 不许写成
A：… · B：…一行横排，⛔ 也不许把候选做成表格的列。段内「优点…；缺点…」连写即可 —— 不必每个字段再拆行，否则撞 §5.4 硬约束 3「每节 ≤7 行」。
## 判定
❌ 未实现 / ⚠️ 部分可用 / ✅ 已实现 —— <一句话>
| 目标 | 状态 |
|---|---|
| <用户列的第 1 项> | ✅/❌ + 半句依据 |
| <第 2 项> | … |
## 为什么不行（只在有 ❌ 时写；最多 3 层，结论层零技术标识）
- 已经排除的：<今天已经修完、不再是原因的> —— 一句话带过
- 当前唯一卡点：<一句人话>
- 为什么难（可选）：<1–2 句；不确定性要写进**结论句**，例：「还不能说做不到，只能说这一步还没试」>
## 我接着做
- 下一步 <X> —— **陈述句，不是征询句**
## 需要你拍板（**最后一节**；真需要才写，不需要 → 整节删掉；**逐条编号**）
**1. <问题一句话>**
**A** —— 优点：…；缺点：…
**B** —— 优点：…；缺点：…
我倾向 **A**（一句话理由，可推翻）
**2. <下一件>** —— 同上
5.2 交付回执（已完成功能的交付）
AI 交付时先说功能，技术细节折叠在后：
## 做了什么（功能）
<2-3 句：现在多了一个什么能力，在哪儿>
## 你现在能看到
- <具体位置> 出现了 <什么>；点它会发生 <什么>
- 验证方式：<用户亲手可做的一步>
## 不用你决策的技术选择（已定，可随时推翻）
- <易感知的一条，一句话>（若你希望反过来，说一声即可）
…
## 技术附录（可选读）
<文件 / commit / md5 / 端点 / 档案号>
第 3 段是这条协议的关键：把"事前请示"改成"事后可推翻" —— 用户获得了知情权与推翻权，但不需要在读之前做判断。
5.3 五条铁律（都来自本工作区的真实失手）
| # | 铁律 | 反例（实证） |
|---|---|---|
| 1 | 回答主位 = 用户问的那件事；AI 的进度 / 失误 / 计划不得占前两节 | 用户问「是否已实现」，AI 先写「五、我自己的失误（一并交代）」+ 版本流水 → 用户被迫再追问一句才拿到结论 |
| 2 | 结论层零技术标识（版本号 / commit / 包名 / 内部函数名 / 路径 / 探针名）—— 最多放「技术附录」 | 0.2.19 / 0.2.20 / 0.2.23、TDZ、chr(10)、requestOverUnixSocket 全在主线，用户读不出结论 |
| 3 | 禁止征询式收尾：「要我接着做吗 / 说一声即可 / 你看怎么弄」—— 下一步已定且不命中门禁（现行门禁 = 不可逆破坏性操作，见 CODEBUDDY.md §3 R8）⇒ 直接做，用陈述句交代。⚠️ 本条禁的是形态；位置要求见铁律 4 |
「要我现在接着做，说一声即可」—— 把本该自己拍的执行细节又推回用户（同 X9 一族） |
| 4 | 能自决策的继续做；不能自决策的收到最后一节 —— 能按决策方法自决策 ⇒ 自决策 + 继续处理（不为"要不要继续"而停）；不能自决策（真门禁 / 需凭据·窗口）⇒ 收进整条回复的最后一节，按有序段落逐条编号（每条 = 问题 + 选项优缺点 + 我的倾向），⛔ 不许夹在中间，也不许散在正文里问 | 2026-09-15 用户原话：「能根据决策方法 自行决策的就自决策继续处理，不能决策的问题和需确认内容放在回复的最后，按照有序段落展示」—— 待拍板项夹在「进度 + 下一步」之间 ⇒ 用户扫不到、漏答 |
| 5 | 提报给用户前先过「取舍筛」：把候选各写 优点 + 缺点 —— ① 某个只有优点（明显更优）或只有缺点 ⇒ 不需要用户判断，自己拍掉再陈述；② 只有各有优有劣、客观标准分不出高下（真取舍）才提报用户；③ 提报给用户时必须逐项列出优点与缺点（只写"差别在哪"不算）；④ 候选竖排成段（A / B / C 各占一行），⛔ 不横排、不做成表格的列 | 2026-09-15 用户原话两段：「需要我确认的方案需要说明优点和缺点，现在没法判断，假如只有优点或只有缺点那不需要我判断」+「每个需要我决策的问题的潜在解决方案 A B C 也按照段落式排版，别横着排列」—— 此前只写"可感知差别"且横排，用户没法判断 |
自己失误的交代：只在两种情况下写 —— ① 它改变了结论（例：某次改动引入了新问题）；② 用户问根因。否则放最后一节一行，或先不提。
5.4 排版规范（让长回答可扫读） → 本包 references/03-回复排版-核心块.md（随包，⛔ 不依赖外部）
✅ 排版契约随包自带 ⇒
references/03-回复排版-核心块.md（reply-style-guard.py每轮现读注入，⛔ 不设冷却）。 完整十条硬约束 ＋ 十四条反模式 ＋ 去 AI 味（删填充词／破公式／变节奏／信任读者／删金句）见本档 §5.3 自检与下方骨架表。 最小摘要 —— 十条硬约束的自检问法：
| # | 自检怎么数 |
|---|---|
| 1 | 前 3 行有没有判定（✅/⚠️/❌ + 一句） |
| 2 | 有没有第 4 级标题（层级须 ≤3） |
| 3 | 有没有连续 >12 行的文字墙（每节 ≤7 行） |
| 4 | 每节加粗是否 ≤2 处、有没有整句加粗 |
| 5 | 表格是否 >5 列、单元格塞整句 |
| 6 | 同一条信息有没有重复出现 |
| 7 | 翻到最后一节 —— 是不是拍板项、有没有编号 |
| 8 | 每个候选是否优缺点各至少一条 |
| 9 | 有没有 A：… · B：… 一行塞多个候选（须竖排） |
| 10 | 有没有 ①…；②…；③… 挤在一段（须逐条独占一段） |
待用户拍板项：位置 = 最后一节｜形态 = 逐条编号｜语气 = 陈述句。 去 AI 味（说话像人）：本档 §5.3 —— 删填充词、破公式、变节奏、信任读者、删金句。
6. AI 自检清单（每次动手前 / 交付前）
动手前
0. 用户本轮点名了某个技能 / 方法吗（如「参考决策方法」「按你的规划」「别问我」「自行决策」）？—— 点名了 ⇒ 必须先用 Skill 工具加载对应技能，⛔ 不得以"我已经知道判据"为由跳过。
（机制层有 dsh-server-docs/07-scripts/skill-load-guard.py 钩子强制注入提醒 · 2026-09-16 加；实证：会话 ddea70b7 用户点名后 AI 全程 Skill 调用 0 次，仍按旧判据提报用户）
- 我手上有一张功能卡吗（谁/在哪/做什么/怎样算成功）？没有 → 先问这 4 条，不要问技术。
- 我准备提报用户的每一件事，用户能从功能视角判断吗？不能 → 撤掉，自己定。
- 我提报用户的文案里，有没有包名 / 环境变量 / 路径 / commit？有 → 翻译成"能感知的差别"。
- 有没有命中红线（R5 扩大 / R7 批量>10 / 不可逆破坏性操作）？按实际影响面判，不按动作名字判（X9）—— 命中 → 必须提报用户并说明影响面；⛔ R8 不算门禁（开发环境服务器 ⇒ 重启 / 停实例 / drain / nginx·nft 直接做，动手前一句话说明即可）；没命中就别拿「这是生产操作 / 会中断用户」当理由停下。
交付前
5. 我有没有按 §5 的格式给"做了什么 / 你能看到什么"？还是又只给了技术清单？
6. 用户会不会因为缺少某个反馈又来报障？（对照 §4 五条）
7. 技术选择我记进档案了吗（§2 的 9 类，做完要留痕，否则下次重新吵）。
8. 用户问的是「是否 / 能不能 / 为什么不行」吗？—— 是 → 用 §5.1 结论骨架（判定在前，过程在后）。
9. 结论层有没有技术标识（版本号 / commit / 包名 / 内部函数名 / 路径）？有 → 挪进「技术附录」。
10. 我有没有用「要我接着做吗 / 说一声即可」收尾？—— 有 → 改成陈述句，并直接去做（除非命中门禁 = 不可逆破坏性操作）。
11. 这条回复能被扫吗？—— 首屏 3 行给判定 / 层级 ≤3 / 每节 ≤7 行 / 加粗 ≤2 处每节 / 表格 ≤5 列 / 一条信息只说一次 / 待拍板项在末节（§5.4；执行信息·报障·提问各有骨架）
12. 需要用户确认 / 决策的内容，在整条回复的最后一节吗？—— 它后面若还有别的节 ⇒ 挪到最后（2026-09-15 用户明令）；且必须逐条编号（有序段落），不是散文一段；形态是陈述句，不是征询句。反向也查一遍：能自决策的事，我是不是停下来问了？
13. 我要提报用户的每一项，优缺点都写了吗？—— 若某个候选只有优点或只有缺点 ⇒ 不该问，自己拍掉再陈述（§5.3 铁律 5）。
14. 候选竖排成段了吗（A / B / C 各占一行）？—— 横排成 A：… · B：… 或塞进表格的列 ⇒ 改成竖排（§5.4 硬约束 9 · 2026-09-15 用户明令）。
7. 与其他约定/技能的关系
- 红线优先级最高：R1–R7 / R9–R11 命中一律先停手 —— 本协议不构成豁免，只约束"该不该问"。
⛔ 唯一例外 = R8：它已按用户 2026-09-13 明令修正为"开发环境服务器 ⇒ 不必等确认" ⇒ 不构成提报用户理由（只保留"动手前一句话说明"）。把 R8 当门禁 = 本站最常见的过度提报用户（
ddea70b7实证）。 dsh-decision-method：管"怎么想、怎么定"（判定矩阵、十问、验收分级）。本协议管"谁定什么、用什么语言问"。dsh-change-workflow：管"怎么落地"（六阶段、档案模板、并行调度）。01-规范/06-工作台UI规范.md：前端强制基线，冲突以其实测 Token 为准。- 单一来源：本协议即唯一来源（技能必须本地加载才生效）；文档库
INDEX.md只放指针，不复制全文。
变更历史（原 frontmatter · 逐字保留）
name: dsh-feature-first
description: dsh 多租户平台（ai1net.com）的「功能优先」协作协议 —— **用户只提功能需求，AI 自主完成全部技术决策**。当用户提出任何平台功能/交互需求、报障、说「我要把精力放在功能搭建上」，或问「**先做哪个 / 优先级怎么排 / 做不做**」（⇒ 属边界外第①类，该问）时使用；也用于 AI 自查「这件事该不该拿去问用户」。核心 = 复盘证据（技术类+报障类占 64%）+ 用户的「功能卡」4 问 + **AI 自主决策的 9 类白名单（永不问）** + **只准提报用户的 3 类（功能语义分叉 / 红线门禁 / 超出方法边界）** + **决策方法边界定义（边界外必须问的 8 类）** + 提报用户格式 + 报障闭环前置 + 交付回执格式 + 方法本身演进改为自决策 + **§3.6 拆包提报用户：红线问题不得与技术方案捆在一起问** · **§3.2 红线按「实际影响面」判、不按「动作名字」判** · **§5.1 结论骨架（答「是否已实现 / 为什么不行」）** + **§5.3 铁律 4–5 / §5.4 硬约束 7–9：待确认项 = 回复的最后一节、逐条编号；每个候选各占一段（竖排、不横排）且必须写「优点 / 缺点」；只有优点或只有缺点 ⇒ 自决策、自决策**（2026-09-15 用户明令）。**配套：`dsh-decision-method`（怎么想）· `dsh-change-workflow`（怎么落地）。**
version: 1.0.0
updated_at: 2026-09-22
last_change: 【2026-09-22 按要求统一版本号】frontmatter `version` → `1.0.0`（原 v1.8.1）；正文与历史中的版本号为当时记录，未改动。此前 v1.8.1（2026-09-22）：补触发说法「先做哪个 / 优先级怎么排 / 做不做」—— 实测盲区：这三类说法原本命不中本技能（而它们恰是「该不该问用户」的典型场景）；顺带补齐缺失的 `last_change` 字段（12 个技能里只有本技能没有）。
agent_created: true