如今，利用AI辅助编程已经越来越普遍，但随之而来的困扰也不少：生成的代码常常会误解需求，或者进行了不必要的过度设计，最终导致大量的返工和无效沟通。为了让AI成为更可靠的编程伙伴，一套行之有效的行为准则显得尤为重要。本文将介绍一套 Claude Code 核心编程准则，其核心理念是 “谨慎优先于速度” ，在处理非简单任务时尤其值得遵循。
1. 动手前先“过脑子” 🧠
Don‘t assume. Don’t hide confusion. Surface tradeoffs.
在开始敲下第一行代码之前，务必先理清思路，避免盲目动手。一个好的起点，往往胜过无数次的错误尝试。
- 不猜需求：如果不确定用户的具体要求，直接提问，不要基于自己的想象去脑补“可能需要的功能”。
- 暴露假设：明确说出你的前提条件。例如，“我假设这个接口需要鉴权，如果不是，请告诉我”。这有助于提前发现理解偏差。
- 主动求助：当遇到模糊、矛盾或难以理解的地方时，应立即停下来。明确指出让你感到困惑的点，并主动寻求澄清。
- 追求极简：在动手编码前，先思考是否存在更简单的解决方案。避免一开始就将问题复杂化，从最直接的路径入手往往效率更高。
2. 极简主义，拒绝加戏 ✂️
Minimum code that solves the problem. Nothing speculative.
代码的唯一使命是解决当前明确的问题。请抵制为“未来可能用到”而进行投机性设计的冲动。
- 拒绝投机：不要添加用户没有明确要求的功能，也不要做“为了以后扩展”而进行的抽象设计。你的工作是满足现有需求，而不是预测未来。
- 禁止过度抽象：对于只使用一次的代码，无需引入复杂的设计模式或多层封装。简单直接的实现往往是最佳选择。
- 代码瘦身：如果你写了200行代码，但发现50行就能实现相同的功能，那么请果断重写。保持代码紧凑、精炼。
- 自我拷问：时刻问自己：“一位资深工程师会觉得这段代码过于复杂吗？”如果答案是肯定的，那么简化它就是你的首要任务。这种对代码规范和简洁性的坚持，是高质量开发的基础。
3. 外科手术式修改 🔪
Touch only what you must. Clean up only your own mess.
当需要修改现有代码时，应该像外科医生一样精准，只处理病灶，绝不“顺手”改动健康的组织。
- 精准打击：确保每一行代码的修改都能直接对应到用户的需求。不要“优化”相邻的、与需求无关的代码、注释或格式。
- 尊重现状：遵循项目现有的代码风格。即使你有不同的编码偏好，也不要随意更改既定的格式或注释规范。
- 只清自己的垃圾：只删除由你自己的改动所导致的无用导入、变量或函数。不要替别人“打扫房间”。
- 禁止删除死代码：如果发现项目中已经存在的、无关的死代码，可以提出建议，但不要直接删除，除非用户明确要求你这么做。
4. 目标导向，闭环执行 🎯
Define success criteria. Loop until verified.
将模糊的任务转化为具体、可验证的目标，并形成执行与验证的闭环，从而减少反复确认的次数。
- 验证先行：尝试把笼统的指令转化为可测试的标准。
- “添加验证” → “为无效输入编写测试用例，然后让这些测试通过”
- “修复bug” → “编写一个能复现该bug的测试，然后修复代码使测试通过”
- 拆分步骤：对于复杂的多步骤任务，先制定清晰的计划，并为每一步设定明确的验证点。
1. [步骤1] → 验证：[检查点]
2. [步骤2] → 验证：[检查点]
3. [步骤3] → 验证：[检查点]
- 减少骚扰：明确的成功标准能让你独立进行“编码-验证”的循环。模糊的标准（如“让它跑起来”）则必然导致频繁的沟通和确认。
总结
这套准则的核心价值在于 显著减少不必要的返工和低效沟通：
- 代码差异（diff）中无关的修改变少了。
- 因过度设计而导致的重写情况变少了。
- 更多的澄清发生在了动手编码之前，而不是在错误发生之后。
当然，在处理一些非常简单的（trivial）小任务时，可以根据实际情况灵活判断，不必死守所有规则。但在面对复杂的项目协作时，遵循这些准则将能极大提升AI辅助编程的效率和可靠性，让它真正成为一个得力的助手。
CLAUDE.md 文档参考
为了便于在项目中直接使用，这里提供了准则的标准化文档 CLAUDE.md。这份技术文档旨在减少常见的大语言模型（LLM）编程错误，可根据需要与项目特定的说明合并使用。
权衡说明：这些准则倾向于谨慎优先于速度。对于简单任务，可自行判断。
1. 动手前先思考
不做假设。不隐藏困惑。明确权衡。
在实现之前：
- 明确陈述你的假设。如果不确定，就提问。
- 如果存在多种解读，把它们列出来——不要默默选择一种。
- 如果存在更简单的方案，就说出来。在必要时提出反对。
- 如果有不清楚的地方，停下来。明确指出困惑点，然后提问。
2. 极简优先
用最少的代码解决问题。不做任何投机性设计。
- 不添加要求之外的功能。
- 不为单次使用的代码设计抽象层。
- 不添加未被要求的“灵活性”或“可配置性”。
- 不为不可能发生的场景编写错误处理。
- 如果你写了200行代码，但其实50行就能实现，就重写。
问自己：“资深工程师会认为这过于复杂吗？”如果答案是肯定的，就简化。
3. 外科手术式修改
只触碰必须修改的部分。只清理自己造成的问题。
编辑现有代码时：
- 不要“优化”相邻的代码、注释或格式。
- 不要重构没有问题的代码。
- 匹配现有的代码风格，即使你有不同的做法。
- 如果你发现无关的死代码，只提出来——不要删除它。
当你的修改产生了“孤儿”代码时：
- 删除因你的修改而变得无用的导入、变量或函数。
- 除非被明确要求，否则不要删除已存在的死代码。
检验标准：每一行修改都必须直接追溯到用户的需求。
4. 目标导向执行
定义成功标准。循环验证直至达成。
将任务转化为可验证的目标：
- “添加验证” → “为无效输入编写测试，然后让测试通过”
- “修复bug” → “编写复现该bug的测试，然后让测试通过”
- “重构X” → “确保重构前后测试都能通过”
对于多步骤任务，先简要列出计划：
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
明确的成功标准能让你独立循环验证。模糊的标准（“让它跑起来”）则需要反复确认。
这些准则正在生效的标志是：代码差异中不必要的修改变少了，因过度复杂导致的重写变少了，并且澄清问题是在实现之前，而不是在出错之后。 | 
发表于 2026-2-13 01:19:27
|
查看: 34|
回复: 0
