HN 提问：您使用什么样的代理目录结构？
5 分•作者: dominiek•6 天前
我越是使用 Claude Code 来生成大块的系统，就越觉得我们缺少很多实践和工具。
第一个让我非常恼火的问题是缺乏对提示（prompts）的跟踪。有很多小的输入信息会影响系统应该做什么，而这些信息似乎非常短暂。从那以后，我开始在代码库中跟踪这些提示。
另一个观察是，如果你想获得良好的代理（agentic）输出，你需要在上下文窗口（context window）中提供大量的信号。看来，对进入上下文窗口的内容保持严谨是关键。使用 AI 生成输入文件可能会很危险，因为它会给人类信号增加熵/噪声。
我开始实践的一种方法是按照特定的方式组织我的项目：
* `/specs` - 纯粹的人类信号，如产品愿景、需求、设计等。
* `/prompts` - 代理的“食谱”，如技能、任务、AI 模式。
* `/references` - 可用于上下文窗口的参考资料（品牌资产、文档、Figma 导出、数据集等）。
* `/plans` - 项目的代理计划。这些计划通常会有迭代。
* `/build` - 从计划和提示交互中构建的代码库和传统的单体仓库。
（我在 rekallai/craft 的公共 GH 仓库中有一个包含上述内容的 AGENTS.md 文件）
我对这个结构还不完全满意。我觉得 `/plans` 这个名字随着我使用它的增多，有点名不副实（例如，我经常需要生成关于代码库或其他数据集的报告）。
我非常想知道其他（拥抱代理编码的）开发者是如何组织他们的项目的。我的目标是在我的团队中标准化这一点。
查看原文
The more I use Claude Code to generate large swaths of systems, the more I feel like we are missing a lot of practices and tools.<p>The first bit that really annoyed me was the lack of tracking prompts. There are lot's of little inputs that inform the what the system should do and it seems to be very ephemeral. I've since started tracking the prompts in the codebase.<p>Another observation is that if you want to have good agentic output, you need to provide lot's of signal into the context window. It seems that being disciplined about what goes into the context window is key. Using AI to generate input files can be dangerous because it adds entropy/noise to the human signal.<p>One practice I have started to do is organize my projects in a certain way:<p>- /specs - Pure human signal such as product vision, requirements, designs, etc.
- /prompts - Agentic recipes such as skills, jobs, AI patterns.
- /references - References that can be used in the context window (brand assets, documents, figma exports, data sets, etc.)
- /plans - The agentic plans for a project. Ususually there are iterations on these plans.
- /build - The codebases and traditional mono repos that are built from plans and prompt interactions.<p>(I have the above with an AGENTS.md as a public GH repo at rekallai/craft)<p>I'm not fully satisfied yet with this structure. I think /plans is a bit of a misnomer the more I use it (e.g. I often have reports that I want to generate on top of the codebase or other data sets).<p>I am really curious how other developers (that embrace agentic coding) here organize their projects. My goal is to standardize this in my teams.