Wubuntu Tech & Life

第五章： conventions/ 为什么是中后期最重要的目录 很多人搭工作区时，最重视 background/ 。 这很自然。背景资料最容易被看见，也最像“知识”。写小说要有世界观，做产品要有用户画像，写方案要有客户资料，写代码要有业务背景。没有背景，AI 很难理解任务。 但当一个 ACW 进入中后期，真正决定质量稳定性的，往往是 conventions/ 。 background/ 告诉 AI：“这个项目是什么。” conventions/ 告诉 AI：“你应该怎么做。” 这两句话的差别非常大。 一个 AI 可能知道项目背景，却仍然用错格式、改错文件、跳过验证、编造事实、忽略风格、把过程稿当成终稿。它不是缺少背景，而是缺少规则。人类协作也是一样。一个新人读完公司介绍，并不意味着他知道如何提交代码、如何写会议纪要、如何处理客户投诉、如何做质量检查。 conventions/ 的价值，是把隐含经验变成显性规则。 比如写作工作区里，你可能逐渐发现一些问题：AI 喜欢把摘要写得像广告；喜欢在纪实内容里补细节；喜欢把审校意见写得很泛；喜欢直接输出长文而没有先确认结构；喜欢把最终正文放错目录。每次问题出现时，你当然可以在对话里说：“下次不要这样。”但如果这句话只停留在当前对话，它很快就会消失。 更好的做法是，把它写进 conventions/ 。 例如： 纪实类内容不得补写用户未确认的真实经历。 最终正文必须写入 projects/{project}/manuscript/。 artifacts/ 只保存过程产物，不保存最终正文。 全篇起草前必须先形成结构或目录。 审校报告必须列出具体问题、位置和修改建议。 这些规则不只是限制 AI。它们也在帮助人类减少重复管理成本。 当规则沉淀下来，下一次任务就不需要重新解释。AI 可以读取规则后直接遵守。团队成员也可以看到同一套标准，不必依赖某个人在对话里反复提醒。 conventions/ 通常可以包含几类文件。 第一类是原则文件。 它写工作区最重要的价值判断。例如：事实边界优先于表达流畅；小任务不套重流程；过程产物和最终产物必须分离；用户最新输入优先于旧文档；不确定时标注待确认。 第二类是流程文件。 它写不同任务如何推进。例如写作任务可以分为 raw-input、requiremen...

第四章：入口文件不是垃圾桶 很多人第一次理解入口文件时，会犯一个错误：既然 AI 进入工作区会先读它，那就把所有重要内容都塞进去。 这听起来合理，实际上很危险。 入口文件当然重要。它是 AI 进入工作区时最先看到的上下文，决定了 AI 对项目的第一印象。但正因为它重要，它才不能成为垃圾桶。一个塞满所有背景、规则、历史、任务、示例和废弃信息的入口文件，很快会失去导航能力。 入口文件最该承担三个职责。 第一，说明工作区定位。 AI 需要知道这里是写作项目、软件项目、研究项目，还是通用模板。它需要知道本工作区的目标、边界和默认语言。比如：“本项目用于撰写一本 ACW 技术书，正式正文写入 projects/acw-book/manuscript/ ，过程产物写入 artifacts/ 。” 第二，提供目录路由。 AI 不应该猜每个目录的用途。入口文件应该清楚说明： projects/ 存最终项目， background/ 存稳定背景， conventions/ 存协作规则， artifacts/ 存过程产物， tmp/ 存临时文件。更进一步，它还可以告诉 AI：做写作任务前读取哪些规则，做审校任务前读取哪些标准，初始化已有项目时走哪条流程。 第三，写下最高优先级约束。 有些规则不应该藏在很深的文档里。例如：不要编造真实事实；不要覆盖用户未要求修改的文件；最终产物不要写到过程目录；默认中文沟通；遇到隐私和高风险领域要标注待确认。这类规则应该放在入口文件或入口文件明确指向的规范中。 入口文件不应该承担什么？ 它不应该保存全部背景。背景应该放在 background/ 。 它不应该保存每次任务记录。任务过程应该放在 artifacts/ 。 它不应该保存最终成果。最终成果应该放在 projects/ 。 它也不应该不断堆叠临时提醒。临时提醒如果只对当前任务有效，应该进入任务 artifact；如果长期有效，应该整理成规范，再进入 conventions/ 。 一个好的入口文件像机场大厅的指示牌。它告诉你登机口在哪里、安检在哪里、行李在哪里，但不会把每一架飞机的维修手册都贴在墙上。 这引出 ACW 的另一个核心机制：按需加载。 AI 的上下文窗口有限。即使模型越来越强，也不意味着我们应该把整个项目一次性塞进去。更好的方式是让 AI 先...

第三章：一个最小可用工作区 一个最小可用的 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/ 不是只为反向整理而存在。它首先是最终成果和具体项目的承载层。 bac...

第二章：Prompt 解决一次表达，ACW 解决长期协作 Prompt 仍然重要。 没有清楚的指令，AI 很难给出稳定结果。你要告诉它目标、背景、约束、输出格式和判断标准。一个好的 Prompt，确实能显著提升单次回答质量。 但 Prompt 有一个天然限制：它是一次性的表达容器。 你可以把很多信息塞进一条 Prompt。你可以写角色、写步骤、写示例、写风格、写禁区，甚至写一大段项目背景。可是当任务需要多天、多轮、多文件、多角色、多阶段协作时，单条 Prompt 会变得越来越臃肿。它不仅难写，也难维护。更糟糕的是，Prompt 越长，越容易混入过期信息、重复要求和互相冲突的指令。 很多人使用 AI 卡住，并不是因为不会写句子，而是因为把所有协作责任都压在了 Prompt 上。 比如你正在写一本书。第一天你告诉 AI：书名、目标读者、章节结构、语气要求。第二天你让它改第一章。第三天你又让它写第五章。第四天你发现它忘了第二章已经改过的概念。第五天你补充了新的术语规则。第六天你要求全书统一风格。到这个阶段，如果所有东西都靠对话里反复提醒，协作成本会急剧上升。 软件开发也是一样。你可以让 AI 写一个函数，但如果它不知道项目架构、依赖版本、测试命令、代码风格、数据库约束、上线禁区，它就可能写出“看起来能跑、实际上不能合并”的代码。你当然可以在 Prompt 里补充这些信息，但每次都补充，既浪费，也容易漏。 ACW 的意义，就是把这些长期有效的协作信息，从 Prompt 中拿出来，放进工作区。 Prompt 变成任务入口。ACW 变成协作环境。 在 ACW 中，Prompt 不再需要承担全部记忆。你可以对 AI 说：“请按照本工作区规范，继续写第三章。”这句话之所以可行，不是因为它神奇，而是因为工作区里已经有书稿项目、目录、风格规范、既有正文和任务流程。AI 可以按需读取这些内容，再执行当前任务。 这也是为什么 ACW 不是简单的“文件夹分类法”。 如果你只是建了一堆目录，但 AI 不知道这些目录是什么意思，不知道什么时候读哪个文件，不知道哪些规则优先级更高，不知道产物应该写到哪里，那这些目录只是在硬盘上排队。ACW 真正要建立的是一种协作协议：文件结构、命名、入口、规则、流程和验证标准共同组成 AI 可以理解的行动环境。 我们可以把 ACW 拆成五...

第一章：先做一个上下文实验 我们先从一个简单实验开始。 你打开一个 AI 对话框，对它说：“我叫张三。”然后你问：“我叫什么？”AI 会回答：“你叫张三。”这时候很多人会说，AI 记住了我的名字。 但更准确的说法是：这句话还在当前对话上下文里。 如果你关掉这个对话，重新打开一个新的会话，再问：“我叫什么？”AI 大概率不知道。它不是突然健忘，也不是故意装傻，而是新会话里没有那句“我叫张三”。AI 能回答什么，取决于它当前能看到什么。 这件事听起来简单，却是理解 ACW 的第一块基石。 AI 协作里所谓的“记忆”，很多时候并不是真正意义上的长期记忆，而是上下文可见性。当前对话中出现过的信息，它能用；当前对话没有出现的信息，它就不能凭空知道。即使某些产品提供记忆功能，也不意味着复杂项目可以完全依赖产品记忆。因为项目需要的不只是“记住几个事实”，而是稳定地组织大量材料、规则、流程和产物。 我们再做第二个实验。 假设你把“我叫张三”写进一个项目入口文件里。每次 AI 进入这个工作区，都先读取这个文件。此时即使你开启新的对话，只要 AI 重新读到了入口文件，它仍然可以知道“你叫张三”。这就从对话上下文，变成了工作区上下文。 差异就在这里。 对话上下文是临时的。它跟着一个会话走，适合讨论一个问题、修改一段文字、解释一个概念。工作区上下文是可持续的。它写在文件里，可以跨会话存在，可以被索引，可以被更新，可以被审查，也可以被其他人或其他 AI 继续使用。 这不是小差异，而是协作方式的差异。 当你只用对话上下文时，你每次都要重新解释项目背景。你可能会说：“我们之前说过……”但 AI 未必真的看得到“之前”。你会不断复制粘贴要求、重复强调禁区、反复纠正同一种错误。时间一长，你不是在使用 AI 提升效率，而是在替 AI 维护记忆。 当你使用工作区上下文时，关键背景被写入文件，协作规则被放在固定位置，任务过程有记录，最终产物有归属。新会话不再是一张白纸，而是一次重新进入项目现场。 当然，工作区上下文并不意味着 AI 每次都应该读完整个项目。恰恰相反，一个真正可用的 ACW 必须承认上下文窗口有限。AI 不能、也不应该在每次任务开始时，把所有文件全部塞进上下文。一个稍微复杂一点的项目，资料、草稿、代码、日志、素材加起来很快就会超过模型能够处理的范围。 所以 AC...

AI 时代，文科生如何建立自己的知识工程 AI 时代，文科生最容易陷入两个误区。 一个误区是：AI 已经能写文章、做总结、查资料，文科能力会越来越不值钱。 另一个误区是：要想不掉队，就必须转行学编程，追逐每一个新模型和新工具。 这两个判断都忽略了真正的变化。 AI 降低了资料整理、内容生成和标准化表达的成本，却没有替人决定什么问题值得研究、什么来源可以相信、什么结论能够成立、什么表达符合真实的人和具体语境。 这些恰好是文科训练最有价值的部分：理解语境，辨别来源，解释复杂问题，组织论证，感受人的处境，并对最终判断负责。 文科生真正需要补上的，不是“技术身份”，而是把这些能力从个人经验变成一套可持续使用的结构。 文科生不需要先变成程序员。更重要的是，把专业背景、判断标准、工作过程和真实成果，组织成 AI 能读懂、人能审查、自己能复用的知识工程。 为什么需要知识工程 只使用聊天框时，每次协作都接近重新开始。 你要反复介绍研究背景、读者、写作风格和引用要求；AI 犯过的错误，下次仍可能重犯；对话里形成的好提纲、好标准和好判断，也很难稳定进入下一次任务。 知识工程要解决的，就是把长期有效的信息从临时对话中拿出来，放进一个有入口、有背景、有规则、有成果的工作区。 Prompt 负责发起一次任务，工作区负责承载长期上下文。 这样一来，AI 不再只能依据通用知识和当前对话给出一份通用答案，而是能够基于你的领域材料、判断标准和既有成果工作。 这套系统如何服务文科生 一个最小可用的知识工作区，只需要四个部分： AGENTS.md background/ conventions/ projects/ 位置 保存什么 对 AI 协作的作用 AGENTS.md 领域定位、目录地图、当前入口和最高优先级边界 告诉 AI 先读什么、去哪里找、哪些事情不能擅自判断 background/ 概念、历史语境、人物资料、来源摘要和已核实事实 让 AI 基于你的专业上下文工作，而不是泛泛生成 conventions/ 引用规范、证据标准、写作风格、伦理边界和检查清单 把“什么叫做好”写清楚，减少重复纠正 projects/ 论文、教案、报告、课程、文章和研究项目 让知识进入真实成果，而不是停留在收藏夹里 ...

本文从一个产品设计视角，客观分析不同 AI 编程助手在"上下文持久化"方面的设计思路，帮助理解各方案的取舍逻辑。 一、问题背景：AI 助手为什么需要"记忆文件"？ AI 助手本质上是"无状态"的——每次对话开始时，它不记得上一次聊了什么。这在简单问答场景下没问题，但在编程、项目管理等持续协作场景下，就会出现问题： 你上次说"这个项目用 TypeScript"，这次它又默认用 JavaScript 你上次定义了"代码风格遵循 Airbnb 规范"，这次它又用别的 你上次让它扮演"资深架构师"，这次它又变回通用助手 为了解决这个问题，不同的 AI 工具发展出了不同的"记忆持久化"方案。 二、主流方案：项目级指令文件 以 CLAUDE.md（Claude）、AGENTS.md（跨工具标准）、.cursorrules（Cursor）为代表。 工作方式 在项目根目录放一个 Markdown 文件，AI 每次会话启动时自动读取，文件内容就是 AI 的行为指令。 你的项目/ ├── CLAUDE.md ← AI 读取这个 ├── src/ ├── package.json └── ... 文件内容通常是混合的： # 项目指令 ## 身份 你是一个资深 Rust 工程师。 ## 编码规范 - 使用 cargo fmt 格式化 - 禁止使用 unsafe - 所有公开函数必须有文档注释 ## 架构约定 - 数据层用 SQLx - 业务逻辑和 IO 分离 设计哲学 一份文件 = 一个项目的全部 AI 上下文。 简单、直观、可发现。任何团队成员打开仓库就能看到 AI 在遵循什么规则。 三、WorkBuddy 的方案：三层分离 WorkBuddy 选择了不同的路径——不把所有信息塞进一个文件，而是按 信息的性质 拆分到不同层次。 层次结构 用户级（~/.workbuddy/） ← 跨所有项目生效 ├── SOUL.md 性格、价值观、行为边界 ├── IDENTITY.md 身份...