让AI为你打工吧：从收拾好你的AI工作台开始

很多金融白领、研究员和投资从业者，第一次认真把 Claude Code、Opencode 或 Codex 用到工作里时，常常一开工就是两件事同时压过来：新能源汽车月度研报要出，基金组合监控也要更新。数据、研报、聊天记录、旧版本摊了一桌，真正卡住人的，往往不是不会写，而是现场太乱。

这时候把 Claude Code、Opencode 或 Codex 叫进来，常常也救不了场。材料没分区，规则没落盘，输出没约定，它只能跟着一起猜，越帮越乱。

项目启动的第一步不是提问，而是整理工作现场。 先把目录、规则文件和协作顺序定下来，AI 才能真正接手。下面就从这个问题讲起，再回到新能源汽车月报和基金组合监控这两个常见场景。

为什么项目启动不能直接开始提问

项目启动决定三件事。

第一，决定智能体能看到什么。一个清晰的目录结构，本质上是在给上下文做分区。输入材料、参考模板、输出结果和临时笔记分开后，模型更容易判断“该读什么”“不该改什么”。

第二，决定长期规则放在哪里。如果所有规则都靠口头补充，这轮还能勉强记住，下一轮就容易漂。只有把稳定信息落成文件，项目才有跨轮次的一致性。

第三，决定首轮会话怎样开始。好的首轮会话不是直接要求生成结果，而是先探索现场、确认材料、澄清目标，再进入计划和执行。没有这一层，后面的速度只会让偏差放大。

项目启动的核心很简单：先把现场整理成看得懂、改得稳、验得到的状态，再开始协作。

一个适合协作的最小项目骨架

不是每个项目都需要复杂骨架，但一个最低限度可协作的目录，至少要把四类东西分开：输入、输出、参考、规则。

一个足够小、也足够稳的骨架可以是这样：

project/
├── inputs/         # 原始材料、待处理文件、用户输入
├── outputs/        # 最终交付物和中间产出
├── references/     # 模板、样例、背景说明
├── notes/          # 临时笔记、状态记录、问题清单
└── CLAUDE.md       # 项目规则文件

这个结构解决的是协作中的实际问题。

• inputs/ 让智能体知道事实来源在哪里。
• outputs/ 让它知道产出该写到哪，而不是随手散落到根目录。
• references/ 把模板、风格说明、术语表这类辅助材料隔出来，避免和原始输入混淆。
• notes/ 给探索结果、待确认问题、阶段性状态一个临时落点，避免把这些内容硬塞进最终交付物。

目录设计不是为了好看，而是为了控边界。 输入区和输出区没分开，智能体就更容易误改原文件；参考区和临时笔记混在一起，模型就更难判断什么是硬约束，什么只是草稿。

这里不追求固定模板，更重要的是建立两个原则。

第一，目录命名要让陌生人一眼看懂。第二，目录划分要直接服务后续动作：读什么、写什么、查什么、暂存什么。 只要这两个原则成立，项目就已经有了可协作的基础。

最小骨架原则

项目目录不需要一步到位。先用 4-5 个顶层文件夹把输入、输出、参考、临时笔记和规则分开，后续再按需细化。起步阶段，目录越少越好维护。

CLAUDE.md 的定义、作用域与最小模板

有了目录之后，下一步要解决的是稳定规则写在哪里。在 Claude Code 中，这个文件叫 CLAUDE.md，它是项目 memory 的重要入口，承担的核心工作是：把长期有效、会反复影响结果的项目规则落成文件。

跨平台命名对照

这里以 Claude Code 的 CLAUDE.md 作为项目规则文件的标准名称。在 Opencode 中，同一功能的文件叫 AGENTS.md；在 Codex 中也是 AGENTS.md。三者格式和作用完全相同，只是文件名随平台不同。如果你的项目需要同时兼容多个平台，只需维护一份 CLAUDE.md，再用软链接生成副本：

ln -s CLAUDE.md AGENTS.md

这样两个平台都能识别，而规则内容只需维护一处。

这类规则文件最适合写五类内容。

1. 项目背景：这个项目是做什么的，核心产出是什么。
2. 目录约定：输入在哪里，输出写到哪里，参考资料放在哪。
3. 工作方式：先探索、再计划、再执行，还是先核对资料、再生成结果。
4. 关键约束：不要改哪些目录，哪些信息不能臆造，什么情况下必须停下来确认。
5. 验证方式：完成前需要自查什么，最终交付应包含哪些内容。

同样要明确哪些内容不该写进去。

• 一次性任务目标，不该长期留在规则文件里。
• 高频变动的临时细节，不该塞进主规则。
• 自动触发、外部接口、环境变量、权限策略这类运行细节，不该混进规则正文。

下面是一份适合初学者的最小模板：

# 项目背景
- 本项目用于整理行业研究资料并生成课程讲稿。

# 目录约定
- 原始材料在 `inputs/`
- 输出写入 `outputs/`
- 模板和术语表放在 `references/`

# 工作规则
- 先探索目录和材料，再开始生成正文
- 资料不足时先指出缺口，不自行臆造
- 不改动 `inputs/` 中原始文件

# 输出要求
- 输出前给出使用材料清单
- 结果写入指定文件，并附简短状态说明

这份模板有效，不是因为它全面，而是因为它覆盖了会反复影响结果的关键点。对项目规则来说，精简比求全更重要。

CLAUDE.md 的核心定位

CLAUDE.md 不是说明文档，也不是任务清单。它的职责是记录长期有效、会反复影响执行结果的项目规则。写进去的每一条，都应该在多轮会话中持续生效。

规则文件与当前会话的分工

项目一旦变复杂，最常见的混乱不是没写规则，而是把长期规则和当轮要求写进同一个地方。要避免这种情况，最好从一开始就把规则文件和当前会话分开。

最常见的错误，是把规则文件写成临时任务板。比如这一轮说先整理目录、不要写正文，就顺手把这类阶段性要求塞进 CLAUDE.md。等任务阶段一变，旧要求还留在文件里，后面就会反复干扰判断。

另一个常见误区，是把当前会话里说过的话当成项目规则。比如这一轮你说“先只做目录梳理，不要生成正文”，这很可能只是当前阶段要求，而不是以后每一轮都有效的规则。如果这种临时要求也写进主规则文件，文件很快就会膨胀并过时。

两层分工可以压成一句判断：

• 会反复生效的，写进规则文件。
• 只对这一轮有效的，留在当前会话。

守住这句话，后面的混乱会少很多。

常见错误：把临时要求写进规则文件

当前阶段的任务重点，如“这一轮只整理目录，不写正文”，不应写进 CLAUDE.md。一旦任务阶段变化，这些过期要求会持续干扰后续执行，而且很容易被遗忘在文件里。

常见误区、维护边界与过渡

最常见的四个问题如下。

第一，目录分区太粗。所有东西都堆在根目录，看似省事，实际是在给后面制造噪音。智能体每次都要重新猜哪些文件有用，哪些只是历史遗留。

第二，规则文件过长。很多人一开始就想把所有经验都写进去，结果 CLAUDE.md 越写越像百科，真正高频、关键的规则反而被淹没。规则文件重在稳定，不在堆积。

第三，职责混写。把当前会话里的临时要求长期固化，或者把阶段性安排写成永久规则，都会让后续维护变得困难。

第四，写完就不维护。规则文件不是启动仪式。 项目结构变了、输出路径变了、验证方式变了，都应该同步更新。否则它很快就会变成误导性的旧说明。

看到这里，最该留下的不是一个固定模板，而是一套维护边界。

• 规则文件只保留长期有效的信息。
• 当前会话只处理这一轮任务。
• 项目变化后，优先更新规则，不要只靠临时补充。

案例一：新能源汽车月度研报

场景如下：你要写一份新能源汽车行业的月度研报。手头已有三类材料——自己从公开渠道收集的行业数据、几篇券商研报作为参考范本、以及上个月的研报终稿。目标是让智能体帮你基于这些材料，产出本月研报初稿。

项目目录

先把材料按职责分开放。

ev-report-202603/
├── data/                    # 自己收集的原始数据
│   ├── 销量数据_202603.xlsx
│   ├── 政策摘要.md
│   └── 产业链价格跟踪.csv
├── references/              # 参考范本，只读不改
│   ├── 某券商_新能源月报_202602.pdf
│   └── 某券商_新能源月报_202601.pdf
├── previous/                # 上期自己的终稿
│   └── 月度研报_202602_终稿.md
├── output/                  # 本期产出，所有新文件写这里
└── CLAUDE.md

三个要点：data/ 放你的一手材料，references/ 放别人的范本，previous/ 放你自己上期的成品。产出统一进 output/。这样智能体一进项目就能分清什么是输入、什么是参考、什么该产出。

规则文件

CLAUDE.md 不用长，把项目目标、边界和质量要求写清楚就够了。

## 项目

本项目用于撰写 2026 年 3 月新能源汽车行业月度研报。

## 目录约定

- data/：原始数据，只读不改
- references/：参考范本，只用于学习格式和分析框架，不直接复制内容
- previous/：上期终稿，用于保持口径一致
- output/：所有产出写入此目录

## 写作要求

- 结构参照 references/ 中的范本格式：市场概览 → 细分赛道 → 政策动态 → 投资建议
- 数据必须来自 data/ 中的文件，不可自行编造或补充数据
- 与上期研报保持术语和口径一致
- 投资建议部分只做趋势分析，不给出具体标的推荐

这份规则文件大约 20 行。它做了三件事：告诉智能体目录怎么读、内容从哪来、什么不能做。后面不管开多少轮会话，这些规则都自动生效。

首轮会话

项目准备好之后，在 Claude Code 中开始首轮对话。第一轮不急着出稿，先让智能体摸清现场。

请先阅读 data/ 目录下的所有文件，列出本期可用的数据类型和覆盖范围。
再对照 references/ 中的范本结构，给出本期研报的章节提纲和每章的数据支撑情况。
如果某个章节的数据不足，标注出来。
暂时不要写正文。

这轮会话的目标是让智能体产出一份带数据缺口标注的提纲。你确认提纲没问题后，再在下一轮让它逐章生成正文。

这三步——整理目录、写规则文件、首轮探索——就是一个项目启动的完整闭环。 目录让现场清楚，规则让边界长期有效，首轮会话让动作顺序先被确认。后面无论是逐章写作还是引入子智能体分工，都建立在这个基础之上。

案例二：基金组合监控

场景：你管理一个 FOF（Fund of Funds）组合，持有 8 只基金，需要每周生成持仓分析和再平衡建议。数据来源包括基金净值、持仓明细和基准指数。你希望智能体每周读取最新数据，自动产出监控报告。

项目目录

fund-monitor/
├── nav/                     # 基金净值数据，按周更新
│   ├── nav_week12.csv
│   └── nav_week11.csv
├── holdings/                # 持仓明细与权重
│   └── current_holdings.csv
├── benchmark/               # 基准指数数据
│   └── csi300_daily.csv
├── reports/                 # 产出目录
└── CLAUDE.md

nav/ 存放每周更新的净值文件。holdings/ 是当前持仓快照。benchmark/ 放基准数据用于归因分析。所有产出写入 reports/。

规则文件

## 项目

FOF 基金组合周度监控。持有 8 只基金，基准为沪深 300。

## 目录约定

- nav/：基金净值时间序列，只读
- holdings/：当前持仓权重和成本价，只读
- benchmark/：基准指数日频数据，只读
- reports/：所有产出写入此目录，文件名格式为 weekly_YYYYMMDD.md

## 分析要求

- 计算每只基金的周收益率、月收益率和相对基准超额收益
- 组合层面输出加权收益和最大回撤
- 偏离目标权重超过 5% 的基金标注为待再平衡
- 数据全部来自项目目录，不可假设或补充数据
- 报告末尾附数据来源文件清单

## 输出格式

Markdown 表格为主，分三部分：组合概览 → 单基金明细 → 再平衡建议

规则文件约 25 行，覆盖三个层面：数据从哪读、怎么算、输出什么格式。偏离阈值 5% 这类业务判断写进规则，避免每次会话重复交代。

首轮会话

请读取 holdings/current_holdings.csv 和 nav/ 目录下最新一期净值文件。
列出 8 只基金的名称、当前权重、本周收益率。
标注偏离目标权重超过 5% 的基金。
暂时不要生成完整报告。

这轮会话让智能体先完成数据校验和偏离扫描。确认数据无误后，下一轮再生成完整周报。

最后

这篇文章讨论的重点不是多问几个问题，而是先把新项目搭成可协作的工作现场。目录骨架、规则文件和首次会话，是这个阶段最重要的三件事。

其中最关键的判断有三条：

1. 稳定规则写进 CLAUDE.md，不要只靠临时口头补充。
2. 当前会话只处理这一轮目标和临时判断，不把短期要求误固化成长期规则。
3. 目录、规则和首轮会话要一起设计，不能只补其中一块。

只要把输入、输出、参考和笔记分开，把规则边界写清，后面的协作流程才有可靠地基。

实践建议

1. 新项目先整理目录，再开始首轮对话。
2. 规则文件保持精简，只写会反复影响结果的信息。
3. 项目结构或输出路径变了，就同步更新规则文件。
4. 当同类任务开始高频重复时，再考虑把规则进一步沉淀为可复用能力。