claude-md-guide

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CLAUDE.md Guide (conversational)

对话式CLAUDE.md指南

This is the loose companion to

claude-md-generator

. Instead of marching through 32 fixed questions, you infer what you can, ask what matters, and let the user steer the depth.

这是

claude-md-generator

的非正式配套工具。它不会按部就班抛出32个固定问题，而是先推断已知信息，再询问关键内容，让用户掌控深入程度。

Principles

原则

Infer before asking. Skim the repo first. Don't ask questions the code already answers.
Core first, depth optional. Eight questions are non-skippable. Everything else is opt-in.
Conversation, not interview. Group related questions, ask follow-ups on thin answers, skip what doesn't fit the user's business.
Their words, not yours. Don't paraphrase free-text answers into corporate-speak when writing the file.
Partial is fine. A 10-answer CLAUDE.md is better than a 32-answer form the user abandoned at Q14.

先推断，再提问：先浏览代码仓库。不要询问代码已经给出答案的问题。
核心优先，深度可选：8个问题为必问项，其余均为可选。
对话而非面试：将相关问题分组，对简短答案进行跟进提问，跳过不符合用户业务的内容。
保留用户原话：撰写文件时，不要将用户的自由文本回答改写为企业话术。
部分完成也可行：一份仅回答10个问题的CLAUDE.md，比用户在第14题就放弃的32题表单更有价值。

Flow

流程

1. Scan first

1. 先扫描仓库

Before asking anything, quickly look at:

```
package.json
```
/
```
pyproject.toml
```
/
```
Gemfile
```
/
```
go.mod
```
→ tech stack, likely team size
```
README.md
```
→ pitch, target user, often the revenue model
```
git log
```
/
```
git remote
```
→ solo vs. team, commit cadence
Existing
```
CLAUDE.md
```
(if any) → start from what's there, don't overwrite blindly
```
.cursorrules
```
,
```
AGENTS.md
```
,
```
copilot-instructions.md
```
→ voice/style signals already written down

Make a short mental list of what you can fill in with high confidence, what you'd want to confirm, and what you genuinely don't know.

在提问之前，先快速查看以下内容：

```
package.json
```
/
```
pyproject.toml
```
/
```
Gemfile
```
/
```
go.mod
```
→ 技术栈、团队规模推测
```
README.md
```
→ 产品定位、目标用户、通常包含盈利模式
```
git log
```
/
```
git remote
```
→ 个人项目还是团队项目、提交频率
已有的
```
CLAUDE.md
```
（如果存在）→ 基于现有内容继续，不要盲目覆盖

.cursorrules

AGENTS.md

copilot-instructions.md

→ 已记录的语气/风格信号

在脑海中列出三类内容：可高置信度填充的信息、需要确认的信息、完全未知的信息。

2. Open conversationally

2. 以对话方式开场

Something like:

I'll help you put together a CLAUDE.md. I took a quick look at the repo — looks like a {stack} project, {team signal}. I'd like to ask around 8 core questions, then we can go as deep as you want on voice and working style. Some I'll just ask you to confirm from what I saw. Sound good?

Adjust tone to match the repo (playful brand → playful; legal tech → crisper).

示例话术：

我会帮你创建一份CLAUDE.md。我快速浏览了仓库——看起来是一个{技术栈}项目，{团队信号}。我想问大约8个核心问题，之后我们可以根据你的需求深入探讨语气和工作风格相关内容。其中有些问题我会直接让你确认我从仓库中看到的信息。可以吗？

根据仓库风格调整语气（活泼品牌→活泼语气；法律科技→更简洁正式）。

3. Ask the 8 core questions

3. 提出8个核心问题

These are required. Ask them in whatever order feels natural, and group when it flows:

#	Topic	What you're trying to learn
1	Pitch	One-sentence "what do you do?"
2	Customer	Specific person being helped — give them a name/role
3	Non-negotiables	Rules Claude should never break (ethics, quality, boundaries)
4	Brand adjectives	3 words that describe the brand as a person
5	BLUF vs build-up	Answer-first, or walk-me-through-the-reasoning?
6	Ambiguity	Ask / guess / assume-and-flag?
7	Brain-dump handling	Clean grammar, preserve voice, or keep raw?
8	Next steps	Auto-suggest next actions, or only when asked?

For selects, use

AskUserQuestion

. For open-ended ones, just ask. If an answer is thin or generic, ask one follow-up — don't interrogate.

这些问题为必问项。可按自然顺序提问，也可适当分组：

序号	主题	要了解的内容
1	产品定位	用一句话描述“你们是做什么的？”
2	目标客户	具体的受助人群——给出其姓名/职位
3	不可违背规则	Claude绝对不能违反的规则（伦理、质量、边界）
4	品牌形容词	3个能将品牌拟人化的形容词
5	BLUF（结论先行）vs 逐步推导	是先给出答案，还是先讲解推理过程？
6	歧义处理方式	提问/猜测/假设并标注？
7	头脑风暴内容处理	修正语法、保留语气，还是保持原始状态？
8	后续行动建议	自动建议下一步行动，还是仅在被询问时提供？

对于选择题，使用

AskUserQuestion

。开放式问题直接提问即可。如果答案过于简短或笼统，仅进行一次跟进提问——不要过度追问。

4. Offer depth

4. 提供深度探讨选项

After the core 8:

That's the foundation. I can keep it there, or we can go deeper on any of these:

Business: goals, revenue model, competitors, secret sauce, budget, team, stack, hard lessons

Voice: POV, data vs. story, emojis, reading level, hook style, banned words, headline style, email style, visuals

Working style: approval cadence, yes-man vs. devil's advocate, format preference, plan detail, web search, financial estimates, meeting summaries

Pick a category, name specific topics, or say "that's enough."

Let them pick topics à la carte. If they say "all of voice," walk through voice questions conversationally — grouping related ones (e.g. reading level + headline style + email style often come as a set).

See

questions.md

for the full bank with hints, placeholders, and select options.

完成8个核心问题后：

基础信息已经收集完毕。我们可以就此结束，也可以深入探讨以下任意领域：

业务层面：目标、盈利模式、竞争对手、核心优势、预算、团队、技术栈、经验教训

语气风格：观点立场、数据vs故事、表情符号、阅读难度、钩子风格、禁用词汇、标题风格、邮件风格、视觉呈现

工作风格：审批节奏、附和vs唱反调、格式偏好、计划细节、网页搜索、财务估算、会议总结

选择一个分类、指定具体话题，或者说“就到这里”。

让用户按需选择话题。如果用户说“所有语气相关内容”，则以对话方式逐一探讨语气相关问题——将相关问题分组（例如阅读难度+标题风格+邮件风格通常可归为一组）。

完整问题库及提示、占位符和选项请参考

questions.md

。

5. Confirm inferences

5. 确认推断内容

For anything you inferred from the repo, show the user what you're about to write and ask them to confirm or edit. Example:

I put this for your tech stack based on the repo — sound right, or want to tweak?

TypeScript, Next.js 15, Postgres, Stripe, Vercel

Don't silently bake inferences into the file.

对于所有从仓库中推断出的信息，向用户展示你将要写入的内容并请求确认或修改。示例：

根据仓库内容，我填写了以下技术栈信息——是否正确，或者需要调整？

TypeScript, Next.js 15, Postgres, Stripe, Vercel

不要将推断内容默默写入文件。

6. Write the file

6. 撰写文件

Use the template in

output-template.md

. Rules:

Skip sections the user didn't answer — don't write "N/A" or "Skipped."
Verbatim for free text — don't rewrite their words into cleaner prose.
Use the select-value → sentence mappings in
```
output-template.md
```
so the file reads naturally.
Check for existing
CLAUDE.md
— if one exists, ask whether to merge, overwrite, or save as
```
CLAUDE.generated.md
```
. If merging, preserve any sections the user already had that aren't covered by new answers.
Always include the Self-Updating Instructions preamble (see template).

使用

output-template.md

中的模板。规则如下：

跳过用户未回答的部分——不要写入“N/A”或“已跳过”。
自由文本内容完全保留原话——不要将用户的回答改写为更工整的文案。
使用
output-template.md
中的选项值→语句映射，确保文件读起来自然流畅。
检查是否存在现有
CLAUDE.md
——如果存在，询问用户是合并、覆盖还是另存为
```
CLAUDE.generated.md
```
。如果选择合并，保留用户已填写且未被新回答覆盖的部分。
务必包含自更新说明前言（见模板）。

7. Close

7. 收尾

Tell them where it was written, and suggest one concrete thing: "Try giving Claude a real task in this repo and see if the voice feels right — you can edit the file any time, or come back to me to add the sections we skipped."

告知用户文件的保存位置，并给出一个具体建议：“尝试让Claude在这个仓库中执行一项真实任务，看看语气是否合适——你可以随时编辑该文件，或者回来找我补充我们跳过的部分。”

When NOT to use this skill

何时不使用此工具

User explicitly asks for the "full questionnaire" or "all 32 questions" → use
```
claude-md-generator
```
instead.
User just wants a CLAUDE.md template with placeholders to fill in manually → write one directly, don't start a conversation.
A
```
CLAUDE.md
```
already exists and is well-developed → offer to augment specific sections rather than running the whole flow.

用户明确要求“完整问卷”或“全部32个问题”→改用
```
claude-md-generator
```
。
用户仅需要带占位符的CLAUDE.md模板自行填写→直接生成模板，不要开启对话。
已存在一份内容完善的
```
CLAUDE.md
```
→仅针对特定部分提供补充，而非执行完整流程。

Anti-patterns

反模式

❌ Asking all 8 core questions in one giant message — kills the conversational feel.
❌ Re-asking something visible in the repo ("what's your tech stack?" when
```
package.json
```
is right there).
❌ Padding skipped sections with "The user did not specify..." — just omit them.
❌ Treating the optional depth as a second mandatory round. It's optional.
❌ Writing the file before confirming the user is done adding topics.

❌ 一次性抛出所有8个核心问题——破坏对话感。
❌ 询问仓库中已明确可见的内容（比如
```
package.json
```
就在眼前却问“你们的技术栈是什么？”）。
❌ 用“用户未指定...”填充跳过的部分——直接省略即可。
❌ 将可选的深度探讨视为第二轮必问环节——它是可选的。
❌ 在确认用户是否还需添加话题前就撰写文件。