第三章：一个最小可用工作区

第三章：一个最小可用工作区

一个最小可用的 ACW，不需要复杂。

你不必一开始就设计几十个目录、上百条规则，也不必试图预测未来所有场景。真正好的工作区，通常是从一个很小的结构开始，然后随着任务不断沉淀出来的。

一个通用的起点可以是：

AGENTS.md
projects/
background/
conventions/
artifacts/
tmp/

这几个名字没重要到不可更改。你可以根据工具、团队和领域调整命名。但它们背后的职责非常重要。

AGENTS.md 是入口文件。

不同工具可能读取不同入口文件。有的工具叫 AGENTS.md，有的工具可能使用其他名字。名字不是重点，重点是：AI 进入工作区时，需要一个最先阅读的地方。这个文件不应该放所有内容，而应该放最关键的全局说明、目录路由和行为约束。

入口文件像地图，不像仓库。它告诉 AI：这里是什么项目，哪些目录有什么作用，开始任务前应该读取哪些规范，最终成果应该放到哪里，哪些行为被禁止。它不应该堆满长篇背景、所有历史记录和每个任务的细节。入口文件越重要，越要克制。

projects/ 是成果层。

这是当前 ACW 设定中最需要讲清楚的目录。最终产物应该放在 projects/ 下，而不是散落在过程目录里。每个一级子目录代表一个具体项目，例如：

projects/
└── acw-book/
    ├── outline.md
    ├── style-guide.md
    └── manuscript/

写作场景里，projects/story/ 可以是一部故事的项目目录。软件场景里，projects/ 下可能有 frontend/、backend/、docs/、scripts/ 等多个项目或模块。这样设计的好处是兼容性强：ACW 不预设你只做一种工作，而是把每个具体落地对象都放进项目层。

projects/ 还有另一种重要用途：当你已经有一个现成项目时，可以把它作为进入 ACW 的起点。也就是说，已有工程放进 projects/{project}/ 后，AI 可以反向分析它，抽取背景、规则、流程和索引。这个过程可以叫“反向 ACW 化”。但要注意，projects/ 不是只为反向整理而存在。它首先是最终成果和具体项目的承载层。

background/ 是稳定背景层。

这里放长期有效的事实、项目背景、世界观、读者定位、业务资料、研究材料、历史决策等。它回答的问题是：“这个项目是什么？我们已经知道什么？”

写小说时，background/ 可以放世界观、题材边界、平台要求。做软件时，它可以放业务背景、用户画像、系统约束。做研究时，它可以放主题资料、关键概念、来源摘要。

background/ 的关键是稳定。它不适合放一次任务里的临时草稿，也不适合放未经确认却被当成事实的猜测。涉及真实经历、客户信息、法律条款、医疗金融等高风险内容时，更应该区分“已确认事实”“素材推断”和“待确认事项”。

conventions/ 是规则层。

它回答的问题是：“AI 应该怎么做？”

这里可以放写作规范、代码规范、审校规则、任务流程、命名规则、质量标准、长期记忆、错误修正规则。很多 ACW 的长期质量，不取决于 background/ 有多丰富，而取决于 conventions/ 是否足够清楚。

如果 AI 经常犯同一种错误，不要只在当前对话里纠正它。把错误和修正方式写进 conventions/。例如：“不得把未确认事实写成确定事实”“最终正文必须写入 projects/{book}/manuscript/”“过程审校报告必须写入 artifacts/”“小任务不要机械套完整流程”。这些规则会成为下一次协作的基础。

artifacts/ 是过程层。

这个目录用来保存单次任务的过程产物，包括原始输入、需求拆解、结构设计、写作规格、草稿说明、审校报告、决策记录、废弃方案等。

它不应该承载最终产物。最终书稿、最终代码、最终方案应该进入 projects/。artifacts/ 的价值在于让过程可追溯。你能知道这次任务为什么这样做，哪些要求被采纳，哪些方案被放弃，审校发现了什么风险，后续应该如何继续。

在 AI 协作中，过程产物非常重要。没有过程留痕，长任务很难接续。一个对话结束后，下一次 AI 只能猜测之前发生了什么。保留 artifact 后，新任务可以读取它，快速恢复上下文。

tmp/ 是临时层。

这里放短期转换文件、临时输出、中间缓存、实验结果。它的特点是可丢弃，不承载长期知识，不承载最终成果。很多工作区混乱，是因为临时文件没有明确归属，最后大家也不知道哪些文件有用，哪些只是一次性中间物。

这六个部分加起来，就形成了最小 ACW。

它看起来像目录结构，实际上是一套分工：

入口负责路由，项目负责成果，背景负责事实，规范负责行为，过程负责留痕，临时目录负责消化杂物。

你可以用它管理一本书，也可以管理一个软件、一组视频脚本、一个研究主题或一个团队知识库。领域不同，目录里的内容会变，但职责不变。

刚开始搭 ACW 时，不要追求完整。你可以先创建入口文件和几个空目录，再随着任务推进逐步补充。每当 AI 需要重复读取某类信息，就把它沉淀到合适位置。每当 AI 犯错，就把修正规则写进 conventions/。每当任务变复杂，就让过程进入 artifacts/。每当成果稳定，就放进 projects/。

ACW 不是一次设计完成的。它是长出来的。

Comments

Post a Comment

Popular posts from this blog

How to turn off Sass warning prompts in Nuxt.js projects

Background of the Issue When developing projects with Nuxt.js, it’s common to encounter a large number of Sass-related warning messages in the console. These warnings mainly include: Warnings about the order of mixin declarations. Warnings about the use of Legacy JS API. Although these warnings do not affect the operation of the program, they can degrade the development experience by cluttering the console. Today, we will explore how to elegantly address this issue. Solutions 1. Disable Warnings via Configuration In the nuxt.config.js file, we can modify the Sass configuration to suppress these warning messages: export default { build: { loaders: { scss: { sassOptions: { quietDeps: true , // Suppress warnings from dependencies logger: { warn: function ( message ) { return null ; // Silence warning messages }, debug: function ( message ) { return null ; // Silence ...
Read more

Configuring SSH Access to a Docker Container via an Alternative Port

Configuring SSH Access to a Docker Container via an Alternative Port If you want to configure SSH access to a Docker container using an alternative port, such as port 6666 , follow the steps below carefully. This guide assumes that you have administrative access to your Docker host and are familiar with basic Linux commands. Step 1: Run the Container with SSH Service Start by running a new container from your image with port 6666 on the host mapped to port 22 inside the container: sudo docker run -it -p 6666 : 22 --name ssh-container testimage Make sure to replace testimage with the actual name of your Docker image. The --name option gives the container a specific name for easier management. Step 2: Install OpenSSH Server in the Container Once inside the container, update the package list and install the OpenSSH server: apt-get update && apt-get install -y openssh-server Step 3: Set the Root Password Set a password for the root user, which will be required when l...
Read more

Quickly Set Up a Cloud Database Using MongoDB Atlas

Quickly Set Up a Cloud Database Using MongoDB Atlas MongoDB Atlas is the official fully managed cloud database service from MongoDB, simplifying the deployment, management, and scaling of MongoDB in the cloud. This article will guide you on how to quickly create a MongoDB Atlas cluster and set up basic connection configurations. Creating a MongoDB Atlas Cluster Sign Up & Log In If you do not have a MongoDB Atlas account yet, head over to MongoDB Atlas to sign up. After logging in, click on “Build a Cluster” to start creating a new cluster. Select Cluster Configuration To meet the needs of most development and testing scenarios, you can choose the free tier (M0) shared cluster, which is usually sufficient for small applications or personal projects. When choosing a cloud provider, select based on your preference. Here we chose Azure, but AWS and GCP are also great choices. Specify Geographic Location For geographic location selection, choose according to your u...
Read more