张拼拼AI实战教练
← 回首页

让 AI 改代码不再翻车 — 一个 change-workflow 配置

真人长视频 · EP0025 2026年5月31日 07:17
这一期讲什么

前天那期「我们的 Claude Code 不一样」讲了 harness 配置，很多朋友追问能不能分享点具体的。

今天就拆其中一个文件：change-workflow —— 加上它，AI 改代码不再翻车：小改动不再大费周章想一圈，牵连一大片的改动也不再直接上手出 bug。

我第一版按「难度」分高中低三级，失败了，因为难度判断不准（改的文件多 ≠ 任务复杂）。后来改成两个维度：不确定性 × 风险，把改动分成简单和复杂两类。这一期讲我怎么一步步拆出来的，外加一个细节——为什么这个配置要中英文混着写。

配套下载 · 给你的 Claude Code 学
change-workflow.md（rules 配置文件） MD 4 KB
视频里那份 rules 原文件，直接下载丢进自己的 ~/.claude/rules/ 改成你的。

前天我发了一期「我们的 Claude Code 不一样」，讲的是它的 harness 配置不同——就像来了一个非常天才的管培生，我先针对公司情况给他做了一套详细的入职培训。那期有几万播放，很多人追着问：能不能分享点具体的东西。

今天就分享其中一个文件。

rules 文件夹里的 change-workflow

进到 Claude 的配置文件夹，里面有个 rules 文件夹，存的都是「原则」——像一份行为指南，Claude Code 做事的时候会按这里面的一系列流程规范来执行。

我今天要分享的，是其中一个叫 change-workflow 的文件：当它改代码的时候，该用什么方式去思考、去执行。

最头疼的那件事

让 Claude Code 写代码，最头疼的是它对所有改动一个态度：

  • 有时候一个很小的改动，比如改个前端、改句文案，它也大费周章做一整套思考才动手——效率很低；
  • 有时候一个看着很小的功能改动，其实牵扯到很多模块、很多管线、很多后台数据，本来应该先调研再动手，它却直接上手——结果一堆 bug。

怎么解决？

第一版失败了：别按难度分级

我一开始是想，把改动按难度分成高、中、低三个层级，让它先判断，再走不同流程。

但用下来发现，分三级并不好。因为它判断不准任务的复杂度——比如按「改了多少文件」来估，可改的文件多，也不一定就是复杂任务。

所以经过一轮调研，我把难度分级从三级压成了「低 / 高」两种。而真正的拆法，是先做两个维度的思考。

两个维度：不确定性 × 风险

第一个维度，不确定性——动手之前，是不是已经有明确方案了？这个改动能不能用一句话描述清楚？要改的内容是不是足够清楚？

第二个维度，风险——如果改错了，代价有多大？要不要我反复测试？还是干脆直接上线，看看 OK 不 OK 就行？

用这两个维度一判断，改动就分成了简单改动和复杂改动两类。

  • 简单改动 → 直接执行。
  • 复杂改动 → 走四个阶段。

复杂改动的四个阶段

  1. 澄清——先拿到一个客观的验收标准：做到什么样，这件事才算做完。它会用澄清性的问题跟我沟通。
  2. 调研——搜技术方案，看看社区有没有现成的最佳实践，别人做过就借鉴，不重复造轮子。
  3. 策划——进策划模式，做方案对比、技术选型，列一份执行前的审查清单。
  4. 审核——让我完成审核之后，才真正动手。

执行完之后，还会按风险层级做不同级别的校验，专门有一个「挑刺」的环节，挑完再检验。再加上一道验收门：按另一个文档去做 git 的部署、确定要更新哪些记忆，全写清楚。哪些任务可以并行，它也会提前想好，去提效率。

一个细节：为什么中英文混着写

这个文件是中英文混着写的——中文写叙述、写判断逻辑，但技术词我全保留英文。

这不是装样子，是为了让指令更稳。因为 Claude 训练的时候，大量用的就是这些英文技术词，像 commit、push，全是用英文训练出来的；用这种「原配」的英文词，它对配置的理解会更稳定。

而中文做骨架，是因为我的中文表达比英文好——配置文件我能调得更快，也能更快判断它是不是既严谨又简洁，用足够简洁的话把配置讲清楚。当然，如果你的英文比中文好，整篇用英文写，执行的鲁棒性可能还会更高。

最后说句题外话。我免费花时间分享，也是想在更大的平台上交点朋友、把自己的经验传出去。有人留言说「治好咳嗽再来讲」——是中肯的建议，但朋友之间，大概会先关心一句难不难受吧。也有很多朋友会主动告诉我，把这些经验用到了哪、有了什么收获，那种时候我就觉得，每天一刀不剪录这十几分钟，时间没白费。所以我还会继续分享下去。

一个改动该多用心，不看它多难，看两件事——动手前清不清楚，改错了代价多大。