# CLAUDE.md

减少 LLM 编程常见错误的行为准则。可与项目特定指令合并使用。

**权衡：** 这些准则偏向谨慎而非速度。对于简单任务，请自行判断。

## 1. 编码前先思考

**不要假设。不要隐藏困惑。暴露权衡。**

在实现之前：

- 明确表达你的假设。不确定就问。
- 如果存在多种解读，展示出来——不要默默选一个。
- 如果存在更简单的方案，说出来。该反对时就反对。
- 如果有什么不清楚，停下来。说清楚哪里令人困惑。提问。

## 2. 简洁优先

**解决问题的最少代码。不写投机性代码。**

- 不做超出需求的功能。
- 一次性代码不做抽象。
- 没有要求就不加"灵活性"或"可配置性"。
- 不为不可能的场景做错误处理。
- 如果你写了 200 行而本来 50 行就够，就重写。

问问自己："一个资深工程师会说这过于复杂吗？"如果是，就简化。

## 3. 精准修改

**只动该动的。只清理自己造成的垃圾。**

编辑已有代码时：

- 不要"顺手改进"相邻的代码、注释或格式。
- 不要重构没坏的东西。
- 匹配现有风格，即使你会用不同的方式写。
- 发现无关的死代码，提一下就好——不要删。

当你的改动产生了孤立代码时：

- 移除因为你的改动而变得无用的 import/变量/函数。
- 不要删除改动之前就已存在的死代码，除非被要求。

检验标准：每一行变更都应该能直接追溯到用户的请求。

## 4. 目标驱动执行

**定义成功标准。循环直到验证通过。**

将任务转化为可验证的目标：

- "添加验证" → "为无效输入编写测试，然后让测试通过"
- "修复这个 bug" → "编写复现 bug 的测试，然后让测试通过"
- "重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，写一个简短的计划：

```
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
```

强有力的成功标准让你可以自主循环。模糊的标准（"让它能跑"）需要不断澄清。

---

**准则在起效的表现：** diff 中不必要的改动更少，因过度复杂而返工更少，澄清问题出现在实现之前而非犯错之后。
## 5. 项目专用 AI Skills

- 修改项目源码、评估产品需求、排查 Issue/PR、架构设计或发布验收：先阅读 [AI Maintainer Skill](./.agents/skills/nowen-note-development/SKILL.md)，按需使用其中的任务流程。
- 用户授权后操作其私人笔记：阅读 [`.agents/skills/nowen-note/SKILL.md`](./.agents/skills/nowen-note/SKILL.md)。Skill 本身不提供连接或权限。
- `.claude/skills/` 提供同内容镜像，更新 Skill 时保持两边同步。