波仔
🧡 第四章 核心工作模式：把Claude Code变成真正的【生产力工具】
📄 一句话概括

权限的本质是一张你自己写的判断表：红线在哪只有你知道；把判断写成规则，而不是每次临场决定。

📝 本节和前面几节的关系

上一节分的是【放不放手】，这一节讲【规矩从哪来、怎么固定下来】。

一、先承认一件事：它的判断力不如你

它会自信地做错事，而且不会主动提醒你这件事有风险。 所以权限规矩不能指望它自觉——只能由你来定。 这不是不信任，是分工：它跑得快但边界感弱，你有边界感。

二、把判断写成表，而不是临场决定

临场决定的问题是：同一件事，这次你答应了，下次你忘了，规矩就形同虚设。 写成表之后，规矩就住在文件里，每次都一样，不靠记性。 本节的演示把规则写成了一段真判断函数——同样的逻辑，你照着改成自己的红线就行。

三、三类权限，一次配好

红线（永远拒绝）：删数据、推远端、发布上线。这类词直接进拒绝名单。 要确认（每次问一句）：装依赖、升级版本、改配置。范围说清了再放。 放行：读文件、看代码、跑只读查询。 配好之后，你只需要在要确认那一档多说一句范围，其余不必管。

四、规矩要定期回头看

规矩不是一配终身。新出现的动作类型（部署、发消息、改权限）要补进对应档位。 每季度花十分钟回看一遍：你现在授权的动作里，有没有哪条其实该挪到红灯？

五、动手 Demo：权限判定器——你自己定规矩

下面把三类权限写成真代码，跑八个动作看判定结果。

def decide(action, dest=""):
    for k in (u"删", u"推送", u"发布", u"覆盖环境变量"):
        if k in action:
            return u"拒绝", u"命中红线：%s" % k
    for k in (u"装", u"升级", u"改配置", u"覆盖", u"远程"):
        if k in action:
            return u"要确认", u"命中黄灯：%s" % k
    return u"放行", u"只读或本地改动"

实跑输出：

--------------------------------------------------------------------
权限判定器——你自己定规矩
--------------------------------------------------------------------

权限的本质是一张判断表。下面这段把规则写成真代码，跑一遍看它怎么判：

  动作                   判定       依据
  ---------------------------------------------------
  读取项目文件           放行       只读或本地改动
  跑测试看结果           放行       只读或本地改动
  修改日期格式化函数     要确认     改动落在源码目录
  修改页面样式           要确认     改动落在源码目录
  安装一个新依赖         要确认     命中黄灯：装
  升级依赖版本           要确认     命中黄灯：升级
  删掉临时目录           拒绝       命中红线：删
  推送到远端仓库         拒绝       命中红线：推送

这张表的价值不在判定逻辑，在**它是你写的**——红线在哪只有你知道。

八个动作里：四个放行、两个要确认、两个拒绝。顺序很重要——先查红线再查黄灯，否则【删除配置】会被当成要确认。 这段逻辑的价值不在判定，在于它提醒你：红线清单只能自己写。

30 秒实验

  1. 写下你的三条红线（不许删／不许推送／不许动配置），写到能看见的地方。
  2. 想一想：这个月有没有出现过一个【不在你清单里】的新动作？补进去。

常见误区

  1. 把规矩定得太松。【删数据】这类动作一旦进了绿灯档，代价不可逆。
  2. 定完就不再看。新工具、新动作类型一直在出现，规矩要定期回头补。
自测三问（点开对答案） 1. 权限为什么必须由你来定？ —— 它会自信地做错事且不会提醒风险，边界感这件事它不如你。 2. 三类权限分别是什么？ —— 红线（永远拒绝）、要确认（每次问一句）、放行（只读与本地改动）。 3. 判断表里为什么先查红线再查黄灯？ —— 像【删除配置】这种会同时命中两个关键词，先查红线才不会漏判。

相关笔记