大家都在做这个动作：建一个 project、起个名字、丢一句模糊指令、然后开始像平时那样聊天。
结果跟普通 Claude chat 几乎一样。
那不是一个真正的 project。
真正的 Claude Project 应该在第一条消息发出来之前就表现成「一个被训练过的助手，只为一份工作存在」——它已经知道你的目标、你的风格、你的文件、你的标准、你的过程、最终答案长啥样。
差别是数量级的。 弱 project 给你通用输出。强 project 让你免于每天重复解释同一个 context。
三个常见问题
1.「Help me write better」远远不够
Claude 已经知道怎么 help。它不知道的是：
- 你的 voice
- 你的 audience
- 你的 standards
- 你的 examples
- 你偏好的 structure
- 你眼里「bad output」长啥样
Project 指令需要教 Claude 你是怎么工作的。
2. 没有文件的 project 本质上就是一个命名的 chat
真正的 power 来自给 Claude 看参考材料：
- 你的 writing samples
- 你的 brand notes
- 你的 customer research
- 你之前做过的内容
- 你的 templates
- 你的 internal docs
没文件，Claude 瞎猜。有文件，Claude 才对得上你真实 context。
3. 不要建一个叫「Work」的 project 然后指望它 handle 一切
Writing、research、strategy、coding、sales、planning 需要不同 context。一个 project 只做一件主工作。
一个有用的 project 需要 6 件东西
Role
告诉 Claude 它在这个 project 里是谁。
不要写「You are a helpful assistant」。
要写具体的。
示例：You are my senior content assistant. You help me research, plan, draft, and edit practical AI content for people who want useful workflows, not theory. You know my style: direct, simple, specific, and low on fluff. Your job is to help me produce clear content that feels useful immediately.
这能 work 是因为 Claude 在 role 具体时表现明显更好。
Style
定义整体表达风格——直接 / 实用 / 具体 / 短段落 / 排版易扫 / 不灌水 / 不绕。
Rules
Rules 是大多数人跳过的部分。
这是你定义 Claude 必须 always do 什么、必须 avoid 什么的地方。
Always:
- 写短段落
- 用清晰的标题
- 第一行要强
- 用具体例子
- 结构易扫
- 解释简单
- 删 filler
Never:
- 用通用商务语言
- 过度解释明显的点
- 写长块 text
- 写没具体例子的虚指
- 听起来像 corporate blog
- 没必要别加 disclaimer
Rules 把你的偏好变成一个 system。
每次你纠正 Claude，把那个 correction 加回 rules。
Process
不只告诉 Claude 做什么。告诉它怎么想。
写作 project 的 process 举例：
- Identify 读者已经相信什么
- 找 gap 或 misconception
- 围绕这个 contrast 建文章
- 写之前先建结构
- Draft 整篇
- 对照 project rules 复审
- 砍掉任何感觉通用的部分
- 让最终版更好扫
这能阻止 Claude 一上来就奔着 average output 跑。
Output Format
Claude 应该知道成品长啥样。
- Title: 清晰、具体、激发好奇
- Intro: 错误方式 vs 更好方式的短对比
- Body: 编号章节配具体例子
- Paragraphs: 短、好读
- Ending: 直接 takeaway + 一个强收尾点
这消除猜测。
如果同时要 threads、articles、emails、reports、scripts，为每一种各自定义 format。
Files
这是 project 真正变有用的地方。
Content project 上传：
- Style guide
- 表现最好的 posts
- Audience profile
- Topic list
- Content templates
- 竞品 examples
- 被 reject 过的 examples（展示你不想要什么）
Coding project 上传：
- Architecture notes
- Code conventions
- API docs
- 常用 commands
- Testing rules
- Good patterns 的 examples
文件才是让 output 感觉像你写出来的原因。
第一条消息很重要
不要只说「Write this」。
用一个简单的 briefing 格式：
Today we are working on: [TASK]
Goal: [WHAT I WANT]
Audience: [WHO THIS IS FOR]
Context: [WHAT MATTERS]
Use these files: [STYLE GUIDE / TEMPLATE / EXAMPLES]
Before drafting, tell me:
- What angle would make this stand out?
- What would the reader expect?
- What should we avoid?
- What structure would work best?
After I approve the direction, write the full draft.
这让 Claude 在写之前先 plan。
可复制粘贴的 project 模板
ROLE
You are my [ROLE] for this project.
Your job is to help me [PRIMARY JOB] for [AUDIENCE].
You understand my style, standards, and goals. Your output should feel like it belongs to my existing work, not like a generic AI response.
STYLE
Write in a direct, practical, specific style.
Use short paragraphs.
Make the structure easy to scan.
Avoid filler, vague advice, and corporate language.
RULES
Always:
- [Rule 1]
- [Rule 2]
- [Rule 3]
- [Rule 4]
- [Rule 5]
Never:
- [Anti-rule 1]
- [Anti-rule 2]
- [Anti-rule 3]
- [Anti-rule 4]
PROCESS
For every task:
1. Understand the goal.
2. Check the relevant knowledge files.
3. Identify the strongest angle.
4. Create the structure.
5. Draft the output.
6. Review against the rules.
7. Improve clarity and remove weak parts.
OUTPUT FORMAT
Default format:
- Title: [FORMAT]
- Length: [LENGTH]
- Structure: [SECTIONS]
- Style: [STYLE NOTES]
- Ending: [ENDING TYPE]
你不需要 20 个 project。先建 5 个就够。
Posts、articles、newsletters、scripts、content ideas。
至少要包含的文件：
- Writing samples
- Style guide
- Audience profile
- 表现最好的内容
这条在 2026 Claude Project 设置里的位置
真正的 Project 失败模式不是「prompt 不够长」——是「Project 没有 files」。
真正的项目门槛不是「写得有多精巧」——是「在第一条消息发出来之前你为它准备了多少 context」。
第一次建 project 花一个下午填完 6 件套 + 5 类文件，这条 project 之后每天帮你省下半小时到一小时的「重新解释 context」。真正的杠杆不在每次提问时，在项目搭建的那一下午。