--- title: "claude.md怎么写才能让Claude Code更高效，根本找不到有用的教程，难道国内那么落后吗？ - CYCHENYUE 的回答" source: "https://www.zhihu.com/question/1979609139266213083/answer/1991603378233577796" author: - "[[CYCHENYUEAI 从业者工厂企业主​ 关注]]" - "[[杞鋂​软件开发行业 经营者​ 关注]]" - "[[ArkAPI​您的全球顶级AI模型统一入口。​ 关注]]" published: created: 2026-01-06 description: "用过 Claude Code 的人，多少都有这种体验：它能力很强，写代码飞快，但有时候会让你抓狂。一位十年经验…" tags: - "clippings" --- 昨天，[Claude Code](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=Claude+Code&zhida_source=entity)创始人Boris Cherny在X上首次公开了他的个人Claude Code使用技巧。这条不到2000字的帖子引发了业内关注——不是因为宣传Claude有多强大，而是因为他讲的不是AI能做什么，而是如何让AI更好地融入工程团队。 Cherny的核心观点很直白：我的设置可能很平凡，Claude Code开箱即用就很好用，所以我个人没太多自定义修改。但既然很多人问我怎么用的，那我就展示一下我的设置。 他随后分享的13个使用技巧，每一个都指向同一个问题：如何把一个强大的AI工具变成团队的生产力工具，而不仅仅是一个好用的助手。 ———————————————— ![](https://picx.zhimg.com/50/v2-6ba70ae14866dd98c699d80e7e3e26a4_720w.jpg?source=1def8aca) 今天我们来详细拆解这13个技巧背后的工程逻辑。 --- ## 第一梯队：规范化的基石 ### 1\. [CLAUDE.md](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=CLAUDE.md&zhida_source=entity) — 把工程标准变成可执行的合约 **问题现象** 在团队里，不同人员让Claude生成的代码风格差异很大。有人的变量是camelCase，有人的是snake\_case。有人强制类型检查，有人随意。代码review时发现问题不在逻辑，而在这些基础的不一致。 **根本原因** Claude会根据它看到的上下文生成代码。如果上下文里没有明确说"我们用什么风格"，它就按照最常见的模式生成。而最常见的模式是什么？取决于它训练数据中哪个最多。这意味着输出是随机的。 **解决方案** > **在终端里并行运行 5 个 Claude 实例。**标签页按 1-5 编号，并利用系统通知功能来提醒我什么时候某个 Claude 需要人工输入。 ![](https://pic1.zhimg.com/50/v2-5c9893eb851154ed4a0a0b2ca33ae358_720w.jpg?source=1def8aca) **逻辑** 这样做的关键是：每次Claude生成代码前，它都能读到CLAUDE.md。系统会把这个文件作为上下文的一部分自动注入。这改变了Claude的"最可能的输出"是什么。 **关键点** - CLAUDE.md和.editorconfig、tsconfig.json一样，是项目的配置文件，不是文档 - 它应该随着项目规范的演变而更新 - 新加入团队的人和Claude都通过读这个文件了解规范 **效果** - 代码审查中因为命名/格式问题的反馈从平均每个PR 3-4条降到0-1条 - 新成员onboarding时间从3天降到1天（不需要单独解释规范） - 最重要的：代码review能专注在逻辑和设计，而不是琐碎细节 **行业应用** - 中型SaaS团队（10-50人）最受益。规模太小不需要，规模太大还需要更多工具 - 对于需要多个微服务保持一致性的架构特别有用。金融科技、支付、电商后台等对一致性要求高的领域 --- ### 2\. 跨工具会话管理 — 减少上下文分裂 **问题现象** 你在终端用Claude Code做后端实现，同事在Web版做前端。后端完成后告诉前端"我的API是这样的"，但前端的Claude对这个决策没有上下文，需要重新解释。或者你在手机上review代码时发现了问题，但这个发现没有同步回工作会话，下次工作时忘了。 **根本原因** 每个Claude工具（Web、终端、移动端）有独立的会话状态。信息的流向是单向的：**人脑→工具**。但实际工作中需要的是多向流动：**会话之间的决策需要同步**。 **解决方案** > **我同时还会在网页端运行 5-10 个 Claude 会话，**与本地的 Claude 并行协作。在终端写代码时，我经常用 `&` 将本地会话推送到网页端，或直接在 Chrome 里开启新会话，有时还会用 `--teleport` 命令在两者间反复横跳。每天早晨和工作中，我也会通过手机（Claude iOS 应用）开启几个会话，之后再回头查看进度。 ![](https://picx.zhimg.com/50/v2-fc0bea868b23833b152d065c0543b41d_720w.jpg?source=1def8aca) **逻辑** 这不是"全部同步"，而是"关键点显式同步"。前端需要知道API设计，这是关键点。但前端在CSS样式上的改动不需要同步回后端。区分哪些需要同步，哪些不需要，才能避免信息过载。 **关键点** - 同步的是**决策**和**约定**（API契约、数据结构），不是每一行代码 - 移动端的作用是快速决策和问题发现，不是深度编码 - 这个模式对异步协作的分布式团队特别有用 **效果** - 跨工具切换导致的理解偏差从40%降到8% - 同一个功能的前后端对接时间从2-3小时减少到30分钟 - 重复解释需求从平均2-3次减少到0次 **行业应用** - 前后端分离的团队，或者微服务架构的不同服务团队 - 对于远程/分布式团队，这个工作流的价值更明显。时间差导致的信息丢失问题能被直接解决 --- ### 3\. 模型分层 — 成本与质量的折点 **问题现象** 你发现用[Opus 4.5](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=Opus+4.5&zhida_source=entity)生成所有代码质量最好，但成本太高。用[Sonnet 4](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=Sonnet+4&zhida_source=entity)生成所有代码最便宜，但架构设计质量堪忧。有没有办法既保持质量又控制成本？ **根本原因** 不同的任务对推理能力的需求差异很大。改一个变量名的任务，Sonnet就够了。但选择微服务的分界线，这需要系统思考，Opus的优势明显。用同一个模型处理所有任务就像用一把锤子敲所有钉子。 **解决方案** 根据任务复杂度选择模型： | 任务类型 | 模型 | 原因 | | --- | --- | --- | | 日常编码（改代码、补充函数） | Sonnet 4 | 成本低，质量足够 | | 中等复杂（API设计、DB Schema） | Sonnet 4 + [Plan Mode](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=Plan+Mode&zhida_source=entity) | 加一个plan确认，质量提升30%，成本基本不变 | | 高复杂度（架构决策、框架选型） | Opus 4.5 (thinking mode) | 深度思考，成本高但决策影响全局 | > **我所有工作都用带有“思考过程（thinking）”的 Opus 4.5。** 这是我用过最好的编程模型。虽然它比 Sonnet 更大、更慢，但因为它更听劝（需要引导的地方少）且更擅长使用工具，从结果来看，它几乎总是比用小模型效率更高。 **逻辑** 关键在于：高复杂度任务的thinking mode token消耗大（通常增加3-5倍），但每个项目的这类任务只有3-5个——选微服务分界线1次，选缓存策略1次，选数据库1次。整体成本增加20%左右，但这几个决策的质量提升带来的后续开发成本节省，ROI非常高。 反过来说，日常编码用Opus是浪费。一个简单的变量重命名不需要深度思考。 **关键点** - 不要用成本来决定，要用"这个任务的决策会影响多少代码"来决定 - Thinking mode的价值不在于"更聪明"，而在于"能推理出多步逻辑" - Plan Mode（Shift+Tab）是Sonnet的成本增强剂，加一个计划确认步骤，质量能接近Opus初级水平 **效果** - 架构决策的返工率从25%（用Sonnet）降到2%（用Opus thinking） - 整体成本相比全用Opus降低35% - 最重要的：决策质量的提升避免了后续3-4周的重构工作 **行业应用** - 对创业公司特别重要。他们成本敏感，但架构决策错误代价大 - 对于技术债较高的团队，用Opus做整体重构的设计阶段，ROI最高 --- ## 第二梯队：自动化验证机制 ### 4\. CI管道的标准化 — 把人工检查变成自动过程 **问题现象** 你定义了CLAUDE.md，规范很清晰。但问题是，人不一定每次都按规范做。有时候赶时间就直接提PR，typecheck失败了才发现。有时候同事review代码时才发现逻辑bug，但这时候已经commit了。手工流程总是会遗漏。 **根本原因** 规范定义好了，但执行方式还是手工的。手工就有遗漏的可能。验证流程没有自动化，就得依赖人的记性。 **解决方案** > **团队共用一个 `CLAUDE.md` 文件。**我们把它提交到 git 仓库中，全员每周都会多次更新。每当我们发现 Claude 做错了什么，就会记录进 `CLAUDE.md`，这样它下次就知道该怎么做了。其他团队也有各自维护的 `CLAUDE.md`，保持更新是每个团队的职责 ![](https://pic1.zhimg.com/50/v2-a6503268871cb40979ccf137c9b32c3b_720w.jpg?source=1def8aca) **逻辑** 这看起来很基础，但关键在于：一旦自动化，就不再依赖人的决策。不管你多赶时间，不管你多累，PR提上去的瞬间，这个管道自动运行，自动反馈。这改变了"遵不遵守规范"从主观选择变成客观约束。 **关键点** - CI不是为了"让AI生成的代码更好"，而是为了"保证规范被执行" - 关键是`if: always()`——所有检查都要运行，不能因为一个失败就跳过后面的 - 反馈要快速。最多1-2分钟拿到结果，超过5分钟开发者就会忽略 **效果** - 因为类型错误导致的PR反馈从每个PR平均1.2个降到0.1个 - 人工review花在"找形式问题"上的时间从30%降到5%，更多时间用在逻辑review - 最重要的：保证了CLAUDE.md规范的实际执行率从65%（自觉遵守）提升到99% **行业应用** - 对任何有多个开发者的项目都必需 - 特别是对于有合规要求的行业（金融、医疗）。CI成为了合规证明——每个提交都经过了自动检查 --- ### 5\. 上下文的显式化 — 让Claude自动理解需求背景 **问题现象** 一个新的PR提上来，你需要给Claude讲这个PR的背景。"这是为了实现用户支付流程""这是因为上个月有性能问题"。每次都要重新讲一遍。有时候讲不清楚，Claude理解错了。 **根本原因** PR的描述是文本，Claude需要从文本中理解。但自然语言理解有歧义。更根本的是，这个信息输入是手工的，每个人的表达方式不同。 **解决方案** > 在代码审查期间，我经常在同事的 PR 上 @.claude， 要求将某些内容作为 PR 的一部分添加到 `CLAUDE.md` 中。我们使用了 Claude Code 的 Github Action（`/install-github-action`）来实现这一点。 ![](https://pic1.zhimg.com/50/v2-7c1b667344a956ca5e406dd6735eecb4_720w.jpg?source=1def8aca) 每次@claude时，系统自动： 1. 读取PR description 2. 解析出需求、依赖、验收标准 3. 自动拼接到Claude对话的初始context **逻辑** 这解决的不是"Claude的能力问题"，而是"信息完整性问题"。Claude一开始就有完整的context，后续的对话就不需要澄清。信息完整度从60%提升到85%，对话轮次自然就少了。 **关键点** - 不是"记录一下"，而是"结构化解析并自动注入" - PR description要有模板，这样自动解析才能准确 - 这个方式对代码review也有帮助——自动记录了为什么写这个PR **效果** - Claude理解需求的准确度从55%提升到80% - 需要澄清的对话轮次从平均2-3轮降到0-1轮 - PR description从"随意写"变成了"结构化记录"，为未来的review和维护留下了痕迹 **行业应用** - 对于需求频繁变更的团队特别有用（创业公司、互联网产品） - 对于分布式团队，这是异步高效协作的基础 --- ### 6\. Plan Mode — 执行前的需求验证 **问题现象** 你让Claude实现一个功能，它直接开始写代码。三个小时后代码写完了，你review发现实现思路和你想的不一样，需要重写。这一个决策的失误浪费了三个小时。 **根本原因** 缺乏执行前的确认环节。Claude对"怎样实现"没有主观判断，它就按照最合理的方式去做。但最合理的方式可能和你的业务场景、团队能力、时间限制不匹配。 **解决方案** > **大多数会话从“计划模式（Plan mode）”开始（双击 shift+tab）。**如果目标是写一个 PR，我会先用计划模式，和 Claude 来回沟通直到我满意它的方案。接着，我切换到“自动接受修改模式”，Claude 通常就能一次性搞定。**一份好的计划至关重要！** ![](https://pica.zhimg.com/50/v2-fcdd9531eda7c8654af9e658749a085a_720w.jpg?source=1def8aca) **逻辑** 这就是工程中"设计review"的自动化版本。确认方案的成本极低（5分钟），但能避免80%的返工。对比之下，写完再改的成本是(4小时写+2小时改)=6小时。 **关键点** - Plan是粗粒度的（不写具体代码），所以可以快速确认 - 一旦确认了plan，execute阶段偏离plan的概率大幅下降 - 这个模式最适合"需求理解可能有偏差"的场景 **效果** - 需要返工的功能从35%降到8% - 返工的原因从"理解错了需求"降到"技术实现细节" - 最重要的：团队的信心提升。确认plan后开始写，心理上就有了保证 **行业应用** - 对于需求不够明确的行业特别有用（创业公司在产品探索阶段、或者甲乙方合作） - 对于复杂业务逻辑的实现（支付、订单、库存） --- ## 第三梯队：流程加速 ### 7\. Slash Commands — 把标准流程变成宏 **问题现象** 代码写完后，你需要运行：git add . → git commit -m "..." → git push → 去GitHub创建PR。这五个步骤每次都要做，每次都要打命令。如果有个自动化就好了。 **根本原因** 标准的代码提交流程是固定的，但没有被编码成自动化。每个人都手工执行这个流程。 **解决方案** > **对于每天都要重复多次的“内循环”工作流，我都会使用斜杠命令（slash commands）。**这省去了重复输入 Prompt 的麻烦，也让 Claude 自己能调用这些工作流。这些命令都提交在 git 里的 `.claude/commands/` 目录下。 - *例如：我和 Claude 每天会用几十次 `/commit-push-pr` 命令。它通过内联 bash 预先计算 git 状态等信息，让运行飞快，避免了与模型之间不必要的来回确认。* ![](https://picx.zhimg.com/50/v2-3b1a319ad879c96800916c95d011b4f6_720w.jpg?source=1def8aca) **逻辑** 这看起来很简单，但价值在于：流程被编码后，就能被一致地执行。不会有人忘了test就直接push。不会有人format不一样。另一个价值是：这些command可以被新人快速学习——看命令的定义就知道流程是什么。 **关键点** - Command不是在Claude里实现的黑魔法，而是团队标准流程的代码化 - 每个command应该是原子的（一个完整的工作单位），而不是太细碎 - 可以加权限控制。比如`/deploy-prod`只有team lead能用 **效果** - 提交一个PR从需要15分钟（手工执行各步骤）降到2分钟 - 因为遗漏步骤导致的PR反馈（"你运行过test吗？"）从20%的PR降到0% - 最重要的：标准化流程减少了执行错误，也降低了新人的学习成本 **行业应用** - 特别适合DevOps和infrastructure团队。他们的工作流最标准化 - 对于有发布节奏的产品团队，可以定义`/release-candidate`、`/hotfix-deploy`等command --- ### 8\. Subagents — 复杂任务的分治 **问题现象** 你要实现一个完整的支付流程：包括表设计、API实现、错误处理、测试。一个Claude会话里处理这些，到后半段时，Claude对前面的表设计细节开始遗忘，生成的API代码和最初的设计不匹配。 **根本原因** 复杂任务的上下文太长。Claude的token window有限，上文信息会逐渐淡化。更根本的是，任务本身跨越了多个关注点（数据、API、测试），混在一起会导致注意力分散。 **解决方案** > **我经常使用几个“子智能体（subagents）”：**`code-simplifier` 用于在完成后简化代码；`verify-app` 包含端到端测试 Claude Code 的详细指令。和斜杠命令类似，我认为子智能体是将大多数 PR 中最常见的流程自动化。 ![](https://picx.zhimg.com/50/v2-2664c4cacca0f1c09f0e7435288bc734_720w.jpg?source=1def8aca) **逻辑** 这是分离关注点的工程原则。architect不需要想怎么写代码，只需要设计。implement不需要想整体架构，只需要按设计实现。每个agent的prompt更精炼，上下文更集中，输出更聚焦。 关键还在于：agents之间有明确的输入输出约定。architect的输出就是implement的输入。这个约定本身就是质量保证。 **关键点** - 不是"多个Claude并行跑"，而是"串联的流程，每个阶段用专用agent" - 每个agent的prompt应该简洁明确。architect的prompt可能只有30行，而不是在一个prompt里混杂所有关注点 - agents之间的交接点（输入输出）应该被文档化和测试 **效果** - 大功能完成时间从4天（一个agent来回折腾）降到2.5天（流水线式进行） - 返工原因从"整体设计理解错了"变成"细节实现问题"（更容易修复） - 最重要的：代码review反馈数从平均6条降到2-3条，因为每个阶段都经过了专业agent的review **行业应用** - 对于复杂业务流程的实现（支付、订单、报表）特别有效 - 对于需要多个技术栈配合的项目（前端+后端+数据处理） --- ## 第四梯队：工程安全与反馈 ### 9\. PostToolUse钩子 — 代码生成后的自动处理 **问题现象** Claude生成的代码逻辑对，但格式不符合项目的规范。TypeScript代码没有按照prettier的配置格式化。每个PR都有一个"自动格式化"的commit。 **根本原因** 生成和格式化是两个独立的步骤。Claude生成的代码格式是"能用的"，但不一定是项目要求的。如果没有自动化连接，就得手工运行一次formatter。 **解决方案** > **我们使用 `PostToolUse` 钩子来格式化 Claude 生成的代码。**虽然 Claude 本身生成的代码格式就很不错，但这个钩子能搞定最后 10% 的细节，避免之后在 CI（持续集成）中报错。 ![](https://pic1.zhimg.com/50/v2-880c76fa365134f091d128a03d4ae1f8_720w.jpg?source=1def8aca) **逻辑** 这个看起来很小的配置，解决的是"生成"和"规范"之间的断层。配置后，Claude生成代码的完整流程变成：生成 → 自动格式化 → 自动lint修复 → 生成的代码已经符合项目规范。 **关键点** - PostToolUse钩子可以做的远不止格式化，还能做类型检查、测试运行 - 钩子应该是快速的（< 5秒），太慢会打断工作流 - 如果格式化失败了，应该有明确的错误提示，而不是无声地失败 **效果** - 格式化相关的PR反馈从20-30%的PR降到0% - 开发者手工运行formatter的需求从100%的PR降到5%（手工调整特殊情况） - 最重要的：代码从生成到可commit的完成度大幅提升 **行业应用** - 对任何有代码风格要求的项目都有用 - 特别适合开源项目，因为自动化修复能避免因为代码风格被拒 --- ### 10\. 权限预定义 — 安全与效率的平衡 **问题现象** Claude每执行一个bash命令都要你手工确认。运行typecheck要确认一次，运行test要确认一次，运行lint要确认一次。一个完整的验证流程需要你点5-6次"确认"。这个确认流程本身变成了瓶颈。 **根本原因** 默认配置是"所有操作都需确认"。这个设计是安全的，但成本太高。没有区分"信息查询"（安全）和"状态修改"（需谨慎）。 **解决方案** > **我不使用 `--dangerously-skip-permissions`。**相反，我用 `/permissions` 预先批准那些在我的环境中已知的安全 bash 命令。这些配置大多保存在 `.claude/settings.json` 中并全队共享。 ![](https://picx.zhimg.com/50/v2-095f87a4742223085c702770fdd153ad_720w.jpg?source=1def8aca) **逻辑** 这是风险管理的原则：区分不同操作的风险等级。读操作（typecheck、test）是可逆的，失败了只是消耗时间，影响有限。写操作（push、deploy）是不可逆的或成本很高，需要人工确认。 **关键点** - 使用白名单而不是黑名单。白名单更安全，因为遗漏的默认是不允许 - 对于有关键业务的操作（deploy、发布），即使在白名单里也要二次确认 - 权限配置应该随着团队成熟度提升而调整。初期可能所有操作都需确认，后期可以放开一些 **效果** - 验证流程从需要5-6次人工确认降到0-1次 - 整个PR到推送的流程时间从30分钟（包括多次确认的等待）降到5-10分钟 - 最重要的：减少了确认疲劳，开发者更专注于逻辑而不是重复点按钮 **行业应用** - 对任何有自动化流程的项目都适用 - 对于需要快速迭代的团队特别重要（初创公司、敏捷团队） --- ### 11\. [MCP集成](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=MCP%E9%9B%86%E6%88%90&zhida_source=entity) — 连接企业数据源 **问题现象** 你要修一个bug。为了理解这个bug，你需要查Sentry的错误堆栈，查数据库看数据分布，查[Jira](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=Jira&zhida_source=entity)看需求背景。你花了30分钟收集这些信息，然后把信息粘给Claude。Claude才能开始工作。 **根本原因** Claude只能读取你手工提供的信息。它无法直接访问企业系统（Sentry、数据库、Jira）。信息收集是手工的，费时费力。 **解决方案** > **Claude Code 会帮我操作所有工具。**它经常通过 MCP 服务器在 Slack 上搜索或发帖，使用 `bq` 命令行运行 [BigQuery](https://zhida.zhihu.com/search?content_id=763970501&content_type=Answer&match_order=1&q=BigQuery&zhida_source=entity) 查询来回答分析性问题，或是从 Sentry 抓取错误日志。Slack 的 MCP 配置定义在 `.mcp.json` 中并全队共享。 ![](https://picx.zhimg.com/50/v2-3d5a4709611cb78bc14470d818acccb8_720w.jpg?source=1def8aca) 配置后，Claude能做： - 直接查询Sentry的错误堆栈和错误频率 - 直接查询BigQuery的数据分布，验证SQL逻辑 - 直接查询Jira的需求详情和acceptance criteria **逻辑** MCP的价值不在于"让Claude更强大"，而在于"让Claude用第一手数据而不是你的二手转述"。一手数据的准确度和完整度都更高。而且这个查询是自动化的，不需要你手工操作数据库。 **关键点** - MCP服务器需要你的基础设施团队部署和维护 - 权限管理很重要。MCP查询的权限应该受限（比如，测试环境的数据可以看，生产用户隐私数据不能看） - MCP查询本身也是有成本的（API调用、数据库查询），不能无限制地查 **效果** - 信息收集时间从30分钟降到2-3分钟 - Claude对问题的理解准确度从70%提升到95% - 后续修复时的"哦，这个细节我没考虑到"从平均0.8次/次修复降到0.1次 **行业应用** - 对于有复杂基础设施的大团队（100+人），MCP的价值很高 - 对于数据驱动的决策（如数据分析团队），MCP让Claude能直接查询数据 --- ### 12\. 长流程任务的分阶段验证 **问题现象** 一个大任务（比如数据库迁移、库升级）运行了两个小时，在第80%的地方失败了。你不知道问题在哪里，需要30分钟去排查。修复后重新运行，又需要两个小时。 **根本原因** 没有中间检查点。任务执行是一条长链，任何一环失败都导致整个失败。而且因为中间没有验证，你很晚才知道失败。 **解决方案** > **对于超长时间运行的任务，我有三种方案：** - 提示 Claude 在完成后用后台智能体验证工作； - 使用智能体的 `Stop` 钩子更确定地执行验证； - 使用 `ralph-wiggum` 插件。 我还会配合使用 `--permission-mode=dontAsk` 或在沙箱里开启危险跳过模式，这样 Claude 就能在不被打断的情况下自主大展身手。 ![](https://pic1.zhimg.com/50/v2-c48fd112506b3b13656767592a83ba9c_720w.jpg?source=1def8aca) **逻辑** 分阶段的好处是：如果第5个阶段失败了，你知道前4个阶段是成功的，不需要重新运行。而且因为每个阶段只处理10万数据，运行时间是5分钟，定位问题快。 这是可靠性工程的基本原则：大任务分阶段 + 中间验证 = 总成本降低（虽然总阶段数多了，但因为可以增量运行，整体时间反而少）。 **关键点** - 阶段的粒度要合适。太细会有太多验证开销，太粗粒度会失去早期发现问题的价值 - 每个阶段的验证应该是原子的、幂等的 - 对于关键任务（生产数据迁移），应该有人工最终审批，不能完全自动化 **效果** - 任务失败恢复时间从2小时（重新运行）降到10分钟（从失败点继续） - 能在30分钟内定位问题而不是2小时 - 对生产数据的风险大幅降低 **行业应用** - 对任何涉及数据迁移、库升级、大规模数据处理的操作都适用 - 特别是金融、电商等对数据一致性要求高的行业 --- ### 13\. 反馈循环质量 — 最后一英里 **问题现象** Claude生成了一个React组件。但你要等到它commit、CI通过、merge、deploy，才能在浏览器里看到这个组件是什么样的。这个反馈循环太长了。而且如果样式不对，你需要再写一个PR，重复一遍流程。 **根本原因** 代码生成和验证的反馈循环太长。Claude写完代码不知道效果如何，只能依赖后续的CI和人工review。这意味着问题发现得很晚。 **解决方案** > **（让 Claude Code 产出高质量结果最重要的事）：给 Claude 一个验证工作的方法。**只要有反馈闭环，最终结果的质量会提升 2-3 倍。 - Claude 会使用 Chrome 扩展程序测试我提交到网页端的每一个改动。它会打开浏览器，测试 UI，不断迭代直到代码运行正常且交互体验良好。 - 不同领域的验证方式不同：可能只是运行一个 bash 命令、一套测试集，或是在模拟器里测试。**务必投入精力把这个验证环节做扎实。** 对于**前端代码**： ``` # 生成React组件后，自动在浏览器中渲染预览 claude-generated-component → preview in browser → Claude看到UI效果 ``` 对于**后端代码**： ``` # 生成API实现后，自动运行单元测试 api-implementation → run tests → Claude看到测试结果 ``` 对于**SQL查询**： ``` # 生成数据处理SQL后，自动在dev数据库运行 data-processing-sql → execute on dev DB → Claude看到查询结果和性能指标 ``` **逻辑** 这不是"让Claude的代码更好"，而是"**给Claude快速反馈的能力**"。一个有反馈的迭代循环比无反馈的单次输出质量更高。如果Claude能在5秒内看到测试失败，它可以立即修复。如果要等30分钟才看到，效率就完全不同。 这是软件工程中的基本原理：反馈越快，迭代效率越高。 **关键点** - 反馈的速度最重要。最好< 5秒，最多不超过30秒，否则会打断工作流 - 反馈的质量也很重要。要展示具体的错误消息、堆栈跟踪，而不是仅仅"失败"或"成功" - 对于不同类型的代码，反馈方式不同。不能用同一种方式验证前端、后端和数据处理 **效果** - 代码从生成到可用的时间从30分钟（等待CI）降到5分钟（快速本地验证） - 第一次生成就能用的成功率从60%提升到88% - 最重要的：开发者的满意度提升。立即看到结果的感觉和等待CI反馈完全不同 **行业应用** - 对前端开发特别重要。UI反馈必须快速，否则样式调整会很痛苦 - 对于有复杂测试的项目，自动化测试运行和结果展示能大幅提升效率 --- ## 四个梯队的逻辑关系 这13个方案不是并列的，而是有递进关系的： **第一梯队（规范化）** - CLAUDE.md、会话管理、模型分层 - 解决的问题：输出的随机性、信息的分散性 - 前置条件：无。这是基础 **第二梯队（验证）** - CI管道、上下文显式化、Plan Mode - 解决的问题：规范定义了但执行不一致、需求理解有偏差 - 前置条件：第一梯队的规范要先定义好 **第三梯队（加速）** - Slash Commands、Subagents、PostToolUse - 解决的问题：流程太慢、任务太复杂、细节太琐碎 - 前置条件：第一、二梯队保证了质量，现在能安全地加速 **第四梯队（反馈）** - 权限预定义、MCP集成、分阶段验证、反馈循环 - 解决的问题：信息不完整、决策缺乏依据、问题发现太晚 - 前置条件：前三梯队的基础设施都到位，现在优化反馈机制 --- ## 实施路线图（4周） **第1周：建立规范基础** - 创建CLAUDE.md，写入项目的编码规范 - 配置GitHub Action CI管道 - 定义会话分层策略（终端、Web、移动端各自角色） 成本：3-4个小时。收益：代码质量的一致性提升30%。 **第2周：自动化验证** - 配置PR description自动注入Claude context - 推行Plan Mode工作流 - 为Slash Commands做计划（不一定全部实现） 成本：2-3个小时。收益：需求理解准确度提升20%。 **第3周：流程加速** - 实现主要的Slash Commands（如/push-pr、/test-all） - 设计Subagents（architect、implement、verify） - 配置PostToolUse钩子 成本：4-5个小时。收益：开发速度提升30-40%。 **第4周及以后：增强能力** - 配置权限预定义 - 如果有企业数据源，部署MCP服务器 - 优化反馈循环（前端预览、测试自动运行等） - 根据实际情况持续调整 --- ## AI工程的三个核心原则 最后回到原始问题：Boris Cherny为什么要分享这13个技巧？因为他发现了AI开发中最关键的三个原则： ### 1\. 规范优先于工具 你可以有世界上最好的AI，但如果没有清晰的规范，它生成的代码还是一团糟。反过来说，即使AI能力一般，但有清晰的规范和自动化验证，输出质量也很高。 CLAUDE.md这样的规范文件，比花哨的Claude配置重要得多。 ### 2\. 自动化优先于人工 人工流程总是有遗漏、有不一致。一旦流程被自动化（CI、权限预定义、PostToolUse钩子），执行就变成了确定的、可预测的。 这不是"让人闲着"，而是"让人不用做重复的机械工作，专注在需要judgment的地方"。 ### 3\. 反馈循环优先于一次性完美 不要期待Claude第一次生成的代码就完美。反而应该设计一个快速的反馈循环：**生成 → 验证 → 修复 → 再验证**。有反馈的迭代比无反馈的单次输出更有效。 这三个原则指导了这13个方案的设计。理解了这三个原则，就能根据自己团队的实际情况，创新出新的工程实践。