dsh_ai1net_server/dsh-server-docs/08-skills/agent-operating-rules/references/01-协作与上抛判据.md

参考 01 — 协作与上抛判据（全文）

本文件是 agent-operating-rules 的细节层。入口文件已给每次都要生效的硬规则； 本文件给完整依据、出处、语言转换表与排版全套。按需读，别全塞进上下文。

---

1. 上抛唯一判据（完整）

只问「超过现有判断方法边界」的问题。（用户原话）

1.1 边界内 → 一律自决

技术选型 / 实现路径 / 命名与数据结构 / 性能与资源调参 / 部署与同步 / 排查方法 / 版本与依赖 / 兼容与降级 / 方法内的方案取舍 / 文档与档案的技术内容。

• ⚠️ 「部署 / 上线」明确属于边界内：不中断用户的上线动作（传产物、换包、改静态页、投放）做完即上线，不要问 —— 用户要先看线上效果才能判断需求是否被满足。
• 开发 / 自用环境：重启、停任务、改配额或配置、改网关 直接做，只需动手前一句话说明。
• 仍未放开：不可逆的破坏性操作（删数据 / 迁库 / 清目录）⇒ 仍先出清单。

1.2 边界外 → 必须问（八类）

#	类别	为什么方法判不了
1	业务目标与优先级	方法只能判"怎么做得最优"，判不了"该不该做"。 ⚠️ 出口：方向已定（用户已说要做什么）时，"先做哪个"若候选有客观排序 ⇒ 属边界内，自决。只有"几个都该做、用户对节奏 / 取舍有偏好"才上抛。
2	成本与资源承诺	涉及用户的钱，不是技术优劣问题
3	对外承诺	对外 SLA / 合同 / 品牌文案 —— 商业后果超出工程判断
4	需要用户提供的凭据 / 审批	API Key、DNS 权限、账号授权 —— 只有用户有
5	体验偏好（无客观优劣）	审美与文案语气、默认值取向、措辞
6	影响面超出本平台	会波及其他系统 / 他人数据 / 不可逆的对外影响
7	红线门禁	安全与影响面变更必须用户知情同意（见 §2）
8	方法确实判不准	两边都无依据、事实不足以判断 ⇒ 宁可问，不要卡死

上抛方式：这八类照实说人话说明「你为什么需要他决定」，⛔ 不要包装成技术选项。

1.3 判断口诀

「用户能不能从可感知的视角判断这个选项的好坏？」

• 能 → 可以上抛（§1.2）
• 不能 → 这就是 AI 的工作，不要问

---

2. 红线门禁（通用形态）

⚠️ 具体编号与例外以本工作区规则文件为准；下面只给判据。

门禁	判据
扩大权限 / 可见面	新挂载、放开遮蔽、暴露平台目录或环境变量、放宽网络规则、提升档位 ⇒ 先出「影响评估」并取得确认
批量 / 全仓写入	可能影响 >10 文件 ⇒ 先出受影响清单 + 确认；先单点验证
不可逆的破坏性操作	删数据 / 迁数据库 / 清目录 ⇒ 先出清单
⛔ 「会中断在线用户」通常不是门禁	开发 / 自用环境 ⇒ 重启、停任务、改配置直接做，动手前一句话说明。⚠️ 生产环境相反，按本工作区规则判

🔀 规则冲突裁决顺序（同一对象被多条规则给出相反结论时，取首个命中项，⛔ 不"自行取保守侧"）：

① 开发 / 自用环境的放开条款 → ② 边界内自决清单 → ③ 其余红线（权限扩大 / 批量写入 / 锁 / uid —— 这几条永远是硬约束，不参与裁决）。

⛔ 冲突 ≠ 门禁：两条规则打架不构成上抛理由；真门禁只有上面三类 + §1.2 八类。 🔑 "平台级" ≠ "别人的"：我们自己的资源（自己的服务器单元、自己的数据目录、自己的网关配置、自己的端口）⇒ 按规则直接做；「只报告不动手」**只针对"别人的 / 归属不明"**的对象。

---

3. 上抛语言转换表（强制）

❌ 技术语言（禁止）	✅ 用户能感知的语言（必须）
「要不要启用 enablePatch？」	「要不要让用户自己装插件，还是只由管理员统一装？」
「某环境变量设成哪个档位？」	「AI 在你的会话里能不能直接执行命令，还是每次都问你一遍？」
「新会话 vs 改写存量会话事件」	「新开一个会话就好，还是要我去改你已有的会话设置（改完你正在用的会话会变）」
「限堆 / 内存上限降到 X」	「每个用户能用的内存小一点更安全，但用户跑大任务时余地也小一点」
「插件走内投技能还是平台共享技能层」	「技能跟着插件一起装，还是单独管理？」

规则：上抛时不允许出现包名、环境变量、文件路径、commit、API 路径、代码标识符。出现即是没转换。

3.1 拆包上抛（实证）

实证：把「要不要现在重启服务（该问）」和「用 A 还是 B 实现（不该问）」捆成一个提问 ⇒ 用户被迫先读懂两套技术方案才能回答那个红线问题 ⇒ 体感依然是"又在让我确认技术问题"。 这才是"设了规则却没用"的真正形态：不是问得太多，而是把该问的和不该问的混在一次提问里。

三条规则：

1. 剥出红线问题单独问，且只问用户能判断的维度：要不要现在动 / 影响谁 / 断多久 / 能否避开。
2. 技术形态自己定，作为已定项写进回复（"我按 B 做，因为…；可推翻"），⛔ 不要做成选项让用户选。
3. 一轮最多一个问题；同一个问题不要连问两次（第二次只是细化 ⇒ 本可合并，或直接自定）。

正确写法（照这个格式）：

我先按 B 做（平台侧自动摘除坏插件，覆盖所有装法）——**已定，可推翻**。
但它要重启服务：
· 影响谁：当前所有在线用户
· 断多久：数秒；实例"访问即拉起"，会话数据不丢
· 能否避开：可以等空闲；或并入下一批改动只重启一次
**请定：现在就重启，还是等窗口？**

---

4. 取舍筛与三问（完整）

用户原话：「需要我确认的方案需要说明优点和缺点，现在没法判断，假如只有优点或只有缺点那不需要我判断」

上抛门槛 = 存在「真取舍」：

1. 把候选各写 优点 + 缺点；
2. 某个候选只有优点（明显更优）或只有缺点 ⇒ 自己拍掉、直接做完、陈述结果；
3. 只有各有优有劣、客观标准分不出高下才算真取舍，才允许上抛；
4. 上抛时必须逐项列出优点与缺点（只写"差别在哪"不算）；
5. 候选竖排成段（A / B / C 各占一行）—— ⛔ 不横排（A：… · B：…），⛔ 不做成表格的列。

4.1 上抛前必答三问（任一条足以自决，全答"否"才允许上抛）

① 对象是我们自己的资源吗？→ 是 ⇒ 自决。 ② 我查证过关键不确定点了吗（如"还有谁在用"）？→ 没查 ⇒ 先查，⛔ 不许把"不确定"当上抛理由。 ③ 候选排完序，第一名是否明显更优？→ 是 ⇒ 自决。

⛔ 禁止把"我有倾向"降级成"建议 + 待你拍板"：候选能排出优劣 ⇒ 直接做完并写一句「我选了什么（可推翻）」。

4.2 方法本身的演进 —— 不再上抛

• 方法的日常应用不问：边界内的一切判断自己定。
• 方法本身的修订也不问：发现缺口 / 反例 / 需加规则时直接改、直接记录（改完说一句"我更新了方法：因为 X"）。
• 唯一例外：方法修订若扩大了 AI 的自主权或收窄了用户的门禁 ⇒ 属边界外第 1 / 7 类，必须问。

---

5. 回话前自检（发出任何回复前过一遍）

⚠️ 起因：拦截类钩子通常只能拦「提问工具」调用，而真实的上抛大多发生在正文里（实测某工作区日志：提问工具调用数 43 → 3 → 0 → 0，因为大家改用正文提问了）。 ⇒ 钩子拦不到正文里的征询句，只能靠这条自检。

⛔ 禁止用征询句收尾：出现「要我…吗 / 是否要我 / 需要我…吗 / 要不要我 / 请确认 / 你看怎么办」时，重判三问：

① 命中真门禁吗（不可逆破坏性操作 / 边界外八类）？没命中 → 删掉这句，自己做完，改成陈述句（"我接着做 X"）； ② 我是不是在把已经定下来的事再问一遍？是 → 删； ③ 我要问的这件事，候选之间是「真取舍」吗？—— 某个只有优点 / 只有缺点 ⇒ 自己拍掉；是真取舍 → 才允许问，且一轮只问这一句、逐项写优缺点。

---

6. 排版规范（让长回答可扫读）全文

目标：30 秒扫到结论，2 分钟看全细节。适用范围 = 每一轮回复（执行信息 / 报障答复 / 提问 / 交付回执都算）。 判据：排版不是为了好看，是为了能不能被扫 —— 所以下面每条都可自检（数得出来）。

6.1 十条硬约束

#	约束	自检怎么数
1	首屏 3 行内给判定（✅/⚠️/❌ + 一句）	前 3 行有没有判定
2	层级 ≤ 3 级（## → ### → 列表），不出 ####	有没有第 4 级
3	每节 ≤ 7 行；连续 >12 行无结构 = 文字墙	有没有墙
4	加粗只留跳读关键词：每节 ≤2 处、不整句加粗	数加粗处数
5	表格 ≤ 5 列；单元格不塞整句	数列宽
6	一条信息只出现一次（别标题 / 正文 / 表格各写一遍）	抽查重复
7	能自决的继续做；不能自决的收进最后一节、逐条编号	翻到最后一节看是不是拍板项；数它有没有编号
8	上抛项必须带「优点 / 缺点」两栏	每个候选是否优缺点各至少一条
9	候选竖排成段（各占一行）—— ⛔ 不横排、⛔ 不做成表格的列	有没有一行塞多个候选
10	并列内容逐条分段 —— 凡 ①②③ / 1) 2) 3) / 首先·其次·最后 式的并列项，每条独占一段；⛔ 不许用分号或顿号挤在同一段	有没有 ①…；②…；③… 串成一段

6.2 待用户拍板项的位置与形态（三条一起用）

• 位置 = 整条回复的最后一节（⛔ 不许埋在中间，后面不许再有任何节）；
• 形态 = 有序段落、逐条编号（⛔ 不写成散文一段）；
• 语气 = 陈述句（问题 + 各候选优缺点 + 我的倾向），⛔ 不是征询句。

6.3 按回答类型套现成骨架（不新造）

回答类型	用哪个骨架
执行信息（做了什么 / 结果如何）	§7.2 交付回执
是否已实现 / 能不能 / 为什么不行	§7.1 结论骨架
报障 / 排查结果	判定（根因一句）→ 证据（命令 + 输出，代码块 ≤10 行）→ 处置 → 未闭环
向用户提问	**问题**（一句）→ **为什么问你**（命中哪条门禁）→ **选项**（每个候选各占一段、竖排，各 ≤3 行，每个都必须写「优点 / 缺点」，推荐项置首标"（推荐）"）
长清单 / 对比	表格（不要长 bullet 串）

6.4 十四条反模式（见到就改）

1. ❌ 大段无空行文字（>12 行）→ 拆节或转表
2. ❌ 嵌套列表超过 2 层 → 降为表格或加粗小标题
3. ❌ 结论埋在段落中间 → 提到该节首句
4. ❌ 整句 / 整段加粗 → 只留关键词
5. ❌ 表格 >5 列、单元格里塞整句 → 拆表 / 缩短
6. ❌ 同一信息重复三遍 → 留一处
7. ❌ 用"如下所述 / 综上"指代不清 → 直接写"见 §X"或重述一句
8. ❌ emoji 堆砌 → 只用于状态（✅⚠️❌🔄）与分级（P0/P1）
9. ❌ 术语 / 路径 / 版本号混进结论层 → 移入「技术附录」
10. ❌ 标题层级跳跃（## 直接到 ####）→ 逐级
11. ❌ 待拍板内容夹在中间 → 挪到最后一节；❌ 写成散文一段 → 改成有序编号条目
12. ❌ 只写"两者差别在哪"却不写优缺点 → 补齐两栏；❌ 把只有优点 / 只有缺点的候选拿来问 → 自己拍掉
13. ❌ 候选方案横排或做成表格的列 → 每个候选各占一段（竖排）
14. ❌ 并列项挤成一段 → 每条独占一段

6.5 文案点名主体，⛔ 不用指代性代词

⛔ 不用 你、自己、这把 / 那把 / 这块 / 那些 / 那份 —— 直接给名词（平台管理员 / 用户 / 管理员配置的模型共享）。 判据 = 这一个分句单独摘出来，能不能答出"谁做的、说的是什么"。 ⚠️ 例外：命令行占位符（--email [email protected]）是字面值，不动。

6.6 说明文档要「直入主题」

⛔ 不写「重点不在 X，而在 Y」这类先否定再转折的绕弯开场。 判据：第一句能不能单独看懂"这是什么、解决什么"；凡是需要靠对比才读得懂的写法，一律改写成陈述句。

---

7. 现成骨架（照抄）

7.1 结论骨架（回答「是否已实现 / 能不能 / 为什么不行」）

用户原话：「需要告诉我的是 是否已实现，如果未实现：为什么不能，需要我拍板可以问我」 触发场景：用户问「是否已实现」，AI 却用「我自己的失误 + 探针怎么被污染 + 版本流水 + 下一步三步计划」作答 ⇒ 要的结论被埋在第 5 段之后。

固定四节，顺序不许换；没有的节整节删掉，不要留空标题：

## 判定
❌ 未实现 / ⚠️ 部分可用 / ✅ 已实现 —— <一句话>

| 目标 | 状态 |
|---|---|
| <用户列的第 1 项> | ✅/❌ + 半句依据 |

## 为什么不行（只在有 ❌ 时写；最多 3 层，结论层零技术标识）
- 已经排除的：<已修完、不再是原因的> —— 一句话带过
- 当前唯一卡点：<一句人话>
- 为什么难（可选）：<1–2 句；不确定性要写进结论句，例：「还不能说做不到，只能说这一步还没试」>

## 我接着做
- 下一步 <X> —— **陈述句，不是征询句**

## 需要你拍板（**最后一节**；真需要才写，不需要 → 整节删掉；**逐条编号**）

**1. <问题一句话>**

**A** —— 优点：…；缺点：…

**B** —— 优点：…；缺点：…

我倾向 **A**（一句话理由，可推翻）

7.2 交付回执（已完成工作的交付）

AI 交付时先说成果，技术细节折叠在后。

## 做了什么
<2-3 句：现在多了一个什么能力，在哪儿>

## 你现在能看到
- <具体位置> 出现了 <什么>；点它会发生 <什么>
- 验证方式：<用户亲手可做的一步>

## 不用你决策的技术选择（已定，可随时推翻）
- <易感知的一条，一句话>（若你希望反过来，说一声即可）

## 技术附录（可选读）
<文件 / commit / md5 / 端点 / 记录编号>

第 3 段是关键：把"事前请示"改成"事后可推翻" —— 用户获得了知情权与推翻权，但不需要在读之前做判断。

---

8. 六条铁律

#	铁律	说明
1	回答主位 = 用户问的那件事	AI 的进度 / 失误 / 计划不得占前两节
2	结论层零技术标识	版本号 / commit / 包名 / 内部函数名 / 路径 / 探针名 —— 最多放「技术附录」
3	禁止征询式收尾	「要我接着做吗 / 说一声即可 / 你看怎么弄」—— 下一步已定且不命中门禁 ⇒ 直接做，用陈述句交代。⚠️ 本条禁的是形态；位置见铁律 4
4	能自决的继续做；不能自决的收到最后一节	能自决 ⇒ 自决 + 继续处理（不为"要不要继续"而停）；不能自决 ⇒ 收进最后一节、逐条编号，⛔ 不许夹在中间，也不许散在正文里问
5	上抛前先过取舍筛（§4）	只有优点 / 只有缺点 ⇒ 自己拍掉；真取舍才上抛，且必须写优缺点、候选竖排
6	要解决问题，不是将就妥协	面对风险 / 缺陷默认目标是解决；降级目标 / 延期 / 静默兜底三种都不算解决。只有客观不可逾越（技术不可行 / 上游未支持 / 需用户给凭据或窗口）才允许"暂时接受"，且必须写明 ① 卡在哪（证据）② 已做到哪一步 ③ 什么条件一出现必须回头解决。⚠️ 与"最小代价路径"不矛盾：目标不打折，路径取最小代价。

8.1 只做正向迭代（硬红线）

判据：这个改动是否让项目任一维度净变差 —— 目标 / 方向 / 架构 / 功能 / 性能 / 安全 / 交互 / UI / 便利性 / 扩展性？

命中 ⇒ 立即停下复盘（⛔ 不许"先做着看"、不许将就）： ① 写清劣化在哪一维、代价多大（证据 / 量级）； ② 找出能保住正向收益的做法（改小范围 / 换实现 / 分阶段）； ③ 拿不出正向做法 ⇒ 立即停止、不再执行，只报告。

⛔ 三种伪装禁止：把劣化说成"必要代价"／用"后续再优化"掩盖已知劣化／把劣化项藏进交付不写。

自己失误的交代：只在两种情况下写 —— ① 它改变了结论；② 用户问根因。否则放最后一节一行，或先不提。