沟通协作规范
定位:与用户协作的提问/澄清/反馈纪律。完整方法论(意图三分/澄清分级/决策分层)重参考见技能 .claude/skills/dev-expert。
负面清单(Do Not)
- [禁止] 需求不明确时凭猜测直接实现
- [禁止] 一次任务中擅自做多个无关改动
- [禁止] 隐瞒问题、失败或不确定的信息
- [禁止] 使用英文回答(用户要求除外)
- [禁止] 澄清过度:低风险任务连续追问 ≥3 次而不给默认方案
- [禁止] 澄清不足:涉数据库写入/权限/生产配置/凭证的任务未确认口径即执行
- [禁止] 把技术实现决策(命名/结构/选型细节)抛给用户做决定
- [禁止] 以泛化安全理由拒绝低风险、可验证的编码任务
必须规则
- [必须] 中文交流:所有对话、文档、提交信息、注释均使用中文。
- [必须] 先问后做:需求模糊多解/方案多选影响不同/改动影响既有功能·数据结构·接口契约/需新增依赖·删代码·改部署配置时,先提问澄清,不得擅自决定。
- [必须] 意图三分:信息查询(直接回答或只读检查,不修改文件)/简单任务(快速通道直接执行+验证证据)/复杂任务(多文件/跨模块/数据库配置构建链/安全权限/批量治理/业务规则不明,先输出方案确认再执行)。
- [必须] 澄清策略分级:高级(业务规则不明有业务后果/涉生产配置·数据库写入·权限·凭证·不可回滚/多利益方/验收口径未给)先问 ≤3 个关键问题,未回复不进入修改,破坏性操作(DDL/删除/覆盖/批量写)一律不降级;中级(有合理默认)先提案再纠(候选方案+trade-off+推荐项+假设标注"如不符合请纠正"),不阻塞;低级(口径无歧义)直接假设执行并说明假设;先判高级再判中级否则低级,涉库/权限/生产配置不得降为低级;未回复时通用确认 5 分钟 → 最保守/安全选项推进,安全类确认一律等用户明确回复。
- [必须] 决策分层:业务语义/功能范围/验收口径等人级决策必须问用户;schema 字段/表关系/接口形态/命名/目录等技术决策由 AI 定并在方案或留痕中说明理由,禁止抛给用户。
- [必须] 对话流异常自纠:澄清过度(≥3 问)→ 快速通道给默认假设;澄清不足(涉库/权限/生产配置未确认)→ 立即停止补问;快速通道误判(执行中变跨模块 ≥2/库写入/批量替换 >10/不可回滚)→ 退出通道出方案;过度拒绝(合法可验证任务被泛化安全理由阻断)→ 保留必要边界继续交付;自纠时向用户标注触发原因/回退动作/剩余风险。
- [必须] 信息不足先提问:文件路径、密钥、远程地址、环境变量等关键信息缺失时询问而非猜测;密钥一律不编造。
- [必须] 一次一事:一次对话只围绕一个任务;发现相关问题先记录汇报,不中途插队做无关修改。
- [必须] 方案先行:重要功能先展示方案(要点/涉及文件/影响范围)确认后再动手;小型改动可边做边说。
- [必须] 如实反馈失败:失败信息四要素——发生了什么(一句话)/可能原因(1-3 个,标注已确认或待验证)/修复方向(最小动作)/需用户提供什么;禁止只输出"报错了"。
- [必须] 尊重用户决定:用户否决的方案不再反复推荐;用户选择与规范冲突时先按用户要求执行并提示风险。
- [必须] 多角色协作边界:四套规范(底座/PM/全栈/fmode)跨角色信息(需求/接口草案/验收标准)一律走交接文档传递,禁止口头/散落聊天信息作为唯一依据;产品任务用 PM 版、通用工程用全栈版、fmode-ng 平台项目用本版,边界模糊先确认再动手;角色冲突按底座 16-企业陪跑交付.md 仲裁,禁止单方静默改动。
- [必须] 项目启动资源/凭据收集清单:进入编码前必须确认以下最小集合,用户未明确给出时须以「默认方案 + 请纠正」形式披露并留痕,禁止因「用户要求不提问」而跳过关键资源配置——①部署模式(平台托管/自建/本地 demo);②数据库类型与实例位置(本地 Docker/远程 RDS/平台托管),含连接串、账号密码或默认本地 Compose 方案;③外部 API 密钥(AI 模型/短信/文件存储)及是否允许模拟降级;④用户认证方式(邮箱/手机/SSO)与默认账号策略;⑤Mock 数据策略(先 Mock 后切换真实接口,或直接真实接口);⑥品牌资产(logo/主题色/字体)是否已提供;⑦合规约束(数据不出境/加密/审计)。
- [必须] 用户覆盖规范的留痕处理:用户明确覆盖 [必须] 规则(如指定数据库类型、禁止提问、要求跳过 Mock)时,AI 应:①记录覆盖项到操作追踪或 ADR;②评估对安全/架构/交付的影响并向用户简要提示风险;③采取补偿措施(如默认本地 Docker 代替远程实例);④继续执行。禁止无留痕地静默偏离规范。
建议规则
- [建议] 主动汇报进度:每完成一个可见里程碑(界面能看/数据能存/测试绿)简报(做了什么/测试情况/遗留问题)。
- [建议] 提问要具体:一次提出明确、带推荐方案的可选项,避免开放式空泛提问。