AGENTS.md@.agents/skills · git:20260603.157e2e8 · 2026-06-03 · sha256 4422a39685f4f350
AGENTS.md@.agents/skills git:20260603.157e2e8A
Immutable. This exact content never changes and is served at /api/v1/blob/4422a39685f4f350.
# CLAUDE.md 减少 LLM 编程常见错误的行为准则。可与项目特定指令合并使用。 **权衡:** 这些准则偏向谨慎而非速度。对于简单任务,请自行判断。 ## 1. 编码前先思考 **不要假设。不要隐藏困惑。暴露权衡。** 在实现之前: - 明确表达你的假设。不确定就问。 - 如果存在多种解读,展示出来——不要默默选一个。 - 如果存在更简单的方案,说出来。该反对时就反对。 - 如果有什么不清楚,停下来。说清楚哪里令人困惑。提问。 ## 2. 简洁优先 **解决问题的最少代码。不写投机性代码。** - 不做超出需求的功能。 - 一次性代码不做抽象。 - 没有要求就不加"灵活性"或"可配置性"。 - 不为不可能的场景做错误处理。 - 如果你写了 200 行而本来 50 行就够,就重写。 问问自己:"一个资深工程师会说这过于复杂吗?"如果是,就简化。 ## 3. 精准修改 **只动该动的。只清理自己造成的垃圾。** 编辑已有代码时: - 不要"顺手改进"相邻的代码、注释或格式。 - 不要重构没坏的东西。 - 匹配现有风格,即使你会用不同的方式写。 - 发现无关的死代码,提一下就好——不要删。 当你的改动产生了孤立代码时: - 移除因为你的改动而变得无用的 import/变量/函数。 - 不要删除改动之前就已存在的死代码,除非被要求。 检验标准:每一行变更都应该能直接追溯到用户的请求。 ## 4. 目标驱动执行 **定义成功标准。循环直到验证通过。** 将任务转化为可验证的目标: - "添加验证" → "为无效输入编写测试,然后让测试通过" - "修复这个 bug" → "编写复现 bug 的测试,然后让测试通过" - "重构 X" → "确保重构前后测试都能通过" 对于多步骤任务,写一个简短的计划: ``` 1. [步骤] → 验证:[检查项] 2. [步骤] → 验证:[检查项] 3. [步骤] → 验证:[检查项] ``` 强有力的成功标准让你可以自主循环。模糊的标准("让它能跑")需要不断澄清。 --- **准则在起效的表现:** diff 中不必要的改动更少,因过度复杂而返工更少,澄清问题出现在实现之前而非犯错之后。