CRM 的 review-first 是建议流程，还是强制审核？

CRM 模板上的 review-first 首先是使用约定：提醒大家「重要商机变更先走变更请求、给人审核」，不是单靠这几个字就锁死所有写入路径的强制开关。

拥有写权限的人，如果用 AirApp、CLI 或其他客户端以「直接保存／自动合并」的方式提交，仍可能立刻生效——除非空间或这次操作真正启用了需要审核的机制。

（示意图：约定 ≠ 权限闸门；要强制审核须在权限／本次提交上关掉自动合并。）

（本地演示：需要审核时，变更会出现在收件箱，而不是静默写进表里。）

（本地演示：审核视图里能看到将要生效的字段差异。）

约定和强制分别指什么

操作前到哪里确认「会直接保存还是进审核」

1. 看这次提交的反馈

• 提示已保存／表里立刻出现新值 → 本次是直接生效。
• 出现「待审核／变更请求」并进收件箱 → 尚未落库，等人批准。

1. 看收件箱

打开空间的变更请求列表：有没有对应本条商机的待审项。

1. 看客户端／Agent 怎么写的

若使用「仅提案／不要自动合并」类选项，应进审核；若默认带写权限自动合并，可能直接生效。

1. 不要只看模板标题里的 review-first

那是提醒，不是权限面板上的唯一开关。

怎样确认自己理解对了

• 用写权限做一次无害小改（或在演示空间）：观察是表内立即变化，还是只多了一条待审请求。
• 批准合并后，商机字段才与请求一致；拒绝则表内保持原样。
• 团队若要求强制审核：应在规范里写明「Agent／CLI 必须提案、禁止自动合并」，并抽查收件箱而不是抽查「模板有没有写 review-first」。

边界

• 模板文案 ≠ 权限系统。
• 「我有写权限」时，默认路径常常是可以合并的；需要闸门时要在这次写入或空间策略上显式要求审核。
• 只读用户不会因为模板写了 review-first 就突然能写。

可交给 Agent 的目标（示例）

按 CRM 的 review-first 约定修改商机：只提交变更请求，不要自动合并。改完后告诉我收件箱里的待审项标题，等批准后再核对字段。

把「建议怎么协作」和「这次会不会直接写进库」分开看，就不会被模板上的四个字误导。