很多人用 AI 编程工具时，第一反应是继续优化提示词。但实际项目里，Cursor、Claude Code、Codex 是否稳定，往往不只取决于一句提示词，而取决于它进入项目后能不能快速看懂：代码在哪里、配置在哪里、测试怎么跑、哪些文件不能乱动。
如果项目结构混乱，AI 很容易在错误位置新建文件，重复实现已有逻辑，或者为了完成一个小需求顺手改掉无关模块。整理项目结构不是为了“显得专业”，而是为了降低 AI 理解成本，让每一次修改都更接近可上线的结果。
先把项目分成 4 个固定区域
无论是个人工具站、WordPress 自动化脚本，还是一个简单的 SaaS 原型，我建议先把项目拆成 4 个区域：
- 入口区：用户真正访问或运行的入口，例如页面、CLI 命令、API 路由。
- 业务区：核心逻辑，例如文章发布、数据清洗、订单处理、提示词模板。
- 支撑区：配置、工具函数、类型定义、公共组件、脚本。
- 验收区：测试、示例数据、截图、检查脚本、发布清单。
这 4 个区域越清楚，AI 越容易判断“我要改哪里”和“我不该碰哪里”。如果你正在学习 AI 编程，可以先看 AI编程工具专题 和 AI编程学习路线，再回头整理自己的第一个项目。
README 不是介绍文案，而是 AI 的项目地图
很多项目 README 写得像产品介绍，真正有用的信息却没有。对 AI 编程来说，README 最好包含 6 件事：
- 这个项目解决什么问题，不解决什么问题；
- 主要目录分别负责什么；
- 本地启动、构建、测试命令；
- 常见任务应该优先改哪些文件；
- 禁止随意改动的文件和原因；
- 发布或交付前必须检查什么。
例如“新增一个表单字段”，AI 如果只看到文件列表，可能会同时改前端表单、后端接口、数据库迁移和样式；如果 README 明确写出字段流转路径，它就更容易沿着既有结构做最小修改。
给 AI 留一个任务入口文件
如果项目经常交给 Cursor、Claude Code 或 Codex 处理，可以在项目根目录保留一个任务入口文件，例如 AGENTS.md、CLAUDE.md 或 docs/ai-workflow.md。它不需要很长，但要回答三个问题：
- 这个仓库的工作风格是什么；
- 遇到需求时先读哪些文件；
- 完成后用什么方式验证。
这和 AI编程任务说明模板 是一组搭配：任务说明解决“这一次要做什么”，项目入口文件解决“在这个仓库里应该怎么做”。两者都有，AI 才不容易靠猜。
文件夹命名要让人和 AI 都少猜
AI 对项目结构的判断，本质上来自文件名、目录名、导入关系和上下文。命名越稳定，误判越少。几个实用原则：
scripts放一次性或运维脚本，不要混入业务组件；lib或utils放通用能力，避免塞进页面专属逻辑；components只放可复用界面组件，页面级组合放到对应路由目录；docs放人和 AI 都需要看的背景、流程、接口说明；tests或e2e放验证入口，不要让测试散落在项目各处。
如果你已经在做代码审查，可以参考 AI代码审查工作流。项目结构清楚以后，AI 审查差异时会更容易发现“这个改动是不是放错层了”。
把验收清单写进项目，而不是每次重新说
AI 编程最常见的问题之一，是“代码看起来改了，但不知道是否真的可用”。解决办法不是每次都手动提醒，而是把验收清单固定下来：
- 改前先说明影响范围；
- 优先复用现有函数和组件；
- 改动后跑对应测试或检查脚本；
- 涉及 UI 时提供截图或浏览器验证；
- 涉及发布时检查标题、摘要、链接、图片和 SEO 信息；
- 无法验证的地方要明确写出原因。
这类清单特别适合放在 老达AI实践专题 里反复沉淀。因为真正提升效率的不是某一次“神提示词”，而是把可复用的检查动作变成项目习惯。
一个适合个人项目的最小结构
如果你不知道从哪里开始，可以先用这个最小结构：
project/
README.md
AGENTS.md
docs/
workflow.md
acceptance-checklist.md
src/
app/
components/
lib/
scripts/
tests/
assets/
它不一定适合所有技术栈，但适合普通人把“想法、代码、脚本、文档、验收”分开。等项目变复杂，再按实际框架调整，不要一开始就追求大公司的目录规范。
老达点评
AI 编程工具越来越强以后，普通人最容易忽略的反而是工程秩序。项目结构混乱时，AI 会放大混乱；项目结构清楚时，AI 才能真正变成执行者。
我的建议很简单：先别急着让 AI 写更多代码，先让它读懂你的项目。把目录、README、任务入口、测试命令和验收清单整理好，再去写功能、修 Bug、做发布。这样 Cursor、Claude Code、Codex 不只是“能帮你写”，而是更接近“能帮你把事情做完”。
