Wubuntu Tech & Life

每个任务都有一个生命周期。AI Context Workspace 用一套简单的状态机来管理它。 六个状态： pending → in_progress ↔ paused in_progress/paused → completed completed → in_progress (返工) pending/in_progress/paused → cancelled completed/accepted-review/cancelled → archived pending（待处理） ——任务已创建，但还没开始。适用于任务拆分后等待执行的情况。 in_progress（进行中） ——正在执行。这是任务的主要状态，大部分时间都在这里。 paused（暂停） ——因为阻塞、等待外部输入或优先级调整而暂停。暂停不是放弃，是"暂时不做"。 completed（完成） ——任务执行完毕，交付物已产出。但 completed 不等于"可以归档"，还需要通过 Review 门禁。 cancelled（取消） ——任务不再需要。取消不需要 Review，但需要记录取消原因。 archived（已归档） ——最终状态。任务通过 Review（PASS 或被接受的 REVIEW）后归档，或取消后归档。归档后不再修改，只可查阅。 状态机不是为了管控，而是为了恢复上下文。 想象一下：你半年后回到一个项目，打开 artifacts/index.json ，看到： 任务 A：in_progress 任务 B：paused 任务 C：archived (completed) 三行信息，你就知道：A 正在做，B 等着继续，C 已经完成。不需要问任何人，不需要读任何文档。这就是状态机的价值—— 让 AI 和人都不需要靠记忆理解当前局面。 状态转移的门禁 不是所有转移都允许。比如： completed 不能直接变成 archived，必须通过 Review（PASS 或 REVIEW+接受） archived 不能回到 in_progress，如果需要继续，创建新任务，用 parentArtifactId 关联 paused 不能直接 completed，必须先回到 in_progress 这些门禁不是官僚主义。...

不是所有任务都需要写文档、走流程、做 Review。一个拼写错误改三秒钟的事，你非要写一份需求文档，那是浪费。但一个数据库迁移你直接上手改，那是冒险。 所以 AI Context Workspace 定义了四个流程等级，AI 根据风险自主选择最轻但足够安全的等级。 L0——直接处理。 适用场景：明显的小错误、格式调整、无行为风险的单点修改。产出：最终总结和最小检查结果。不需要 Artifact，不需要记录，改完就行。 L1——快速执行。 适用场景：目标明确、范围局部、容易撤销、有直接检查方式。产出：执行摘要和检查结果。Artifact 可选，需要留痕时创建。 L2——标准执行。 适用场景：目标明确，但涉及多个步骤、外部约定或需要完整检查。产出：Artifact、requirements、spec、execution、review。这是最常见的等级。 L3——完整流程。 适用场景：关键目标无法确定、重大结构变化、高风险或难撤销。产出：完整阶段记录和风险说明。 怎么选？ 满足任一条件，至少用 L2： 修改对外约定、长期保存的数据、自动执行规则或多个相关工作单元 需要新增外部依赖、访问外部服务或改变重要数据 目标或完成标准存在需要显式记录但可以自行消除的歧义 缺少直接检查方式，但可以设计替代证据 满足任一条件，用 L3： 目标或完成标准存在无法自行消除的歧义 涉及权限、安全边界、不可逆或破坏性操作 对外约定或跨工作区变化影响重大且难以撤销 缺少可靠检查方式，且错误结果会产生明显损失 全部满足以下条件，才可以用 L0 或 L1： 用户目标明确，没有阻塞执行的开放问题 变化局部且容易撤销 不涉及数据、安全、权限、外部约定或不可逆操作 有可执行的最小检查，或能明确说明无法检查的原因和风险 核心原则：流程为任务服务，不是反过来。 很多项目管理方法的问题在于流程太重，导致大家为了走流程而走流程。AI Context Workspace 的流程等级设计是为了防止这个问题的——最低等级从 L0 开始，只有当你确认需要更重流程时，才升级。 这就像写代码：默认用最直接的方式实现，只有当复杂度达到一定程度时，才引入设计模式。不要一开始就想着用 Visitor 模式。

AI Context Workspace 定义了一个标准工作流，用于描述任务上下文从原始材料到完结归档的完整演变。 raw → requirements → design → spec → execution → review → archive 这不是瀑布模型。它不是要求你严格按顺序走完所有阶段，它是一个 上下文成熟度的标尺 。你的任务上下文当前处于哪个阶段，它应该回答什么问题，一目了然。 每个阶段的核心问题： raw（原始材料） ——用户实际提供了什么？一段文字、一个链接、一个需求描述、一段代码。不管是什么，先把它放在这里，不做任何加工。这个阶段的核心是"忠实记录来源"。 requirements（需求） ——什么结果才算完成？目标是什么？范围多大？边界在哪？有什么约束？完成标准是什么？这个阶段把模糊的想法变成可判断的完成标准。 design（设计） ——准备怎样达到目标？方案是什么？有哪些关键决策？做了哪些取舍？为什么选 A 不选 B？这个阶段产出的不是代码，而是"怎么做"的思考过程。 spec（规范） ——具体按什么约束执行？接口定义、数据格式、检查方式、执行步骤。这个阶段把设计转化为可执行的规则。 execution（执行） ——实际完成了什么？代码、文档、配置、数据。执行阶段产出的是实际交付物，以及执行过程的记录。 review（检查） ——结果是否满足完成标准？逐项核对需求阶段定义的完成标准，给出证据，得出结论。PASS 就归档，没过就返工。 archive（归档） ——是否可以结束这个任务？记录摘要、更新状态、移入冷存储。归档不是删除，是"标记为完结，内容可查"。 不是每个任务都需要走完所有阶段 一个简单的任务，比如"修复一个拼写错误"，直接从 raw 跳到 execution，然后 review 确认就归档了。不需要 requirements、design、spec。 一个复杂的任务，比如"设计新的数据库模型"，可能需要花大量时间在 design 和 spec 上，execution 反而很简单。 工作流的作用是提供一套共同语言，不是一套流程模板。 你说"这个任务在 design 阶段"，别人就知道...

AI Context Workspace 里所有的文件只有两种格式：Markdown 和 JSON。 Markdown 写给人看，也写给 AI 看。 背景文档、约定规范、任务说明，都用 Markdown。Markdown 是人类可读的纯文本，也是 AI 理解效率最高的格式之一。没有专有格式，没有二进制，没有需要渲染才能理解的富文本。 JSON 写给脚本看。 生命周期状态、检查结论、索引记录，都用 JSON。JSON 有固定字段，可以被脚本解析和校验，可以作为机器之间的契约。 为什么分开？ 因为状态和说明是两回事。 "这个任务完成了"是一个状态，应该用 JSON 记录，因为它可以被脚本读取、校验、转换。"这个任务是怎么完成的"是一个说明，应该用 Markdown 记录，因为它需要人（和 AI）阅读和理解。 如果把状态混在 Markdown 里，脚本就得解析 Markdown 才能拿到状态，容易出错，也不稳定。如果把说明塞进 JSON，JSON 的可读性会急剧下降，不适合长篇叙述。 分开的核心原则：机器状态写入 JSON 契约，说明和证据写入 Markdown。 具体来说： 任务的 artifact.json 用 JSON 记录：ID、流程等级、生命周期状态、创建时间、更新时间、交付物列表。这些字段是固定的，脚本可以读、可以写、可以校验。 任务的执行记录用 Markdown 记录：做了什么、怎么做的、遇到了什么问题、有什么结论。这些内容不需要固定字段，需要灵活叙述。 Review 结论用 JSON 记录检查项和结果，确保"是否通过"这个判断可以被脚本自动处理。 背景和约定用 Markdown，因为它们是给人（和 AI）阅读的，不是给脚本处理的。 这套设计的实际效果是什么？ 你可以在脚本中批量检查所有活跃任务的状态，而不需要解析任何 Markdown。你可以在 CI 中配置一个检查：归档时必须有 Review 结论，且 Review 结论必须是 PASS 或被接受的 REVIEW。 同时，AI 在理解任务时，读的是 Markdown——自然的、可读的、有上下文的叙述。它不需要从 JSON 键值对中脑补故事。 机器契约保证了自动化可靠，Markdown 保证了人机可读。两者...

AI 的上下文窗口在变大，从 4K 到 8K、16K、32K、128K，甚至 1M。但上下文窗口越大，越不能啥都往里塞。 这个道理很简单：给你一百本书，让你从里面找答案，你也能找到，但效率远不如直接给你一本相关的书。AI 也一样。更大的上下文窗口解决的是"能不能装下"的问题，不是"该不该装下"的问题。 路由机制的核心思想是：AI 按需读取，只加载当前任务需要的上下文。 怎么做到？靠一个索引文件。 在 AI Context Workspace 中，根目录有一个 AGENTS.md （或类似的入口文件）。这个文件不是上下文仓库，而是 路由表 。它告诉你： 背景信息在哪里（ background/ ） 约定规范在哪里（ conventions/ ） 当前有哪些活跃任务（ artifacts/index.json ） 每个目录下有什么、是干什么用的 路由表只放路径和一句话说明，不放具体内容。具体内容存在各自的文件里，AI 在需要的时候按路径去读。 这样做的好处是什么？ 第一， 上下文精简。 入口文件只有几十行，AI 一眼就能看懂整个工作区的结构。不需要在 10 万 token 的上下文里找入口。 第二， 按需加载。 一个任务只需要读背景中和当前任务相关的部分，以及约定中适用的规范。其他内容不加载，不占上下文窗口，不产生噪音。 第三， 可扩展。 工作区可以无限增长。背景可以写一百份文档，约定可以写几十条规范，但入口文件始终保持精简。新增内容不影响已有任务的上下文质量。 路由机制在实践中怎么用？ 一个典型的工作流是这样的： AI 读入口文件，了解工作区结构 AI 读 artifacts/index.json ，了解当前任务状态 AI 根据任务需要，按路径读取 background/ 中的相关背景 AI 读取 conventions/ 中的相关规范 AI 执行任务，更新 artifacts/ 中的状态 完成后，AI 不再需要保留背景和约定的上下文，可以释放 整个过程，AI 只加载了完成任务所需的最小上下文集合。不多不少。 路由不是新技术，但很少有人把它用在 AI 协作上。 互联网用 URL 路由页面，操作系统用 PATH 路由文件，代码用 import 路由模块。路由是信息...

AI Context Workspace 有一个核心设计原则： 上下文只是文件，谁都能读，谁都能写。 这个原则听起来简单，但它推导出的结果很重要。 模型无关 意味着不依赖任何特定模型的特性。你不用因为换了一个模型就重建工作区。GPT-4 能用，Claude 能用，开源模型也能用。上下文只是文本，任何理解自然语言的模型都能处理。 Agent 无关 意味着不绑定任何 Agent 框架或编排工具。你不用装 LangChain、不用配置 AutoGPT、不用学任何框架的 DSL。工作区是一套目录结构和文件约定，不是一套软件。 为什么这很重要？ 因为 AI 领域变化太快了。今天的主流模型，六个月后可能就过时了。今天的 Agent 框架，明年可能就没人维护了。如果你把工作方式绑定在某个具体工具上，你就得跟着工具升级，永远被动。 但上下文不一样。上下文是"AI 需要知道的信息"，而不是"AI 处理信息的方式"。信息本身比处理方式稳定得多。你的项目背景半年不会变，但用哪个模型来处理这个背景，可以每周换。 那 Agent 框架的价值在哪？ Agent 框架解决的是"怎么让 AI 自动执行多步任务"的问题，不是"怎么让 AI 理解上下文"的问题。两者是正交的。你可以用一个 Agent 框架来自动路由任务，同时用 AI Context Workspace 来管理上下文。两者不冲突，可以叠加使用。 事实上，AI Context Workspace 做得越好，Agent 框架就越容易工作。因为 Agent 的核心难题之一就是"上下文怎么管理和传递"。这个难题被工作区解决了，Agent 可以专注于编排和决策。 具体来说，工作区里有什么？ 只有文件。Markdown 文件、JSON 文件、目录结构。没有二进制格式、没有专有数据库、没有需要特定软件才能读取的格式。任何文本编辑器都能打开，任何 AI 客户端都能读取。 这意味着你可以用 VS Code 查看工作区，用 Git 提交变更，用 Obsidian 链接知识，用任何 AI 工具处理任务。工作区不限制你用什么工具，它只负责组织上下文。

AI Context Workspace 的核心是一个三层结构。每一层解决一个问题，三层合起来构成完整的上下文体系。 第一层：背景。 背景是稳定的、不常变的事实。项目的定位是什么？技术栈是什么？领域知识有哪些？这些信息一旦确定，不会频繁变化。背景层的作用是让 AI 在启动时就能理解"这是一个什么样的项目"。 背景应该写在哪里？写在 background/ 目录下。每次进入工作区，AI 先读背景，建立对项目的基本认知。背景是只读的——不是说不让改，而是说不会被任务流程自动修改。改背景是一个显式操作，需要确认。 第二层：约定。 约定是做事的方式。工作流是什么？质量标准是什么？代码风格是什么？这些规则指导 AI 怎么执行任务。约定不像背景那样稳定，但也不像任务状态那样频繁变化。它随着项目演进逐步完善。 约定写在 conventions/ 目录下。每个约定是一份 Markdown 文件，按需读取。AI 不需要把所有的约定都加载到上下文里，只需要加载当前任务相关的部分。 第三层：状态。 状态是当前任务的具体进展。做到哪了？做了哪些决策？有什么证据？完成了什么？状态是高频变化的，每次任务推进都会更新。 状态写在 artifacts/ 目录下。每个任务一个 Artifact，包含生命周期状态、检查结论、交付物引用。这一层是 AI 在任务执行中主要读写的地方。 为什么是三层？ 因为这三层的更新频率和读取频率天然不同。背景一年改几次，约定一个月改几次，状态一天改几次。把它们分开，AI 就不用每次都在一堆过时的信息里找当前需要的东西。 更好的比喻是：背景是操作系统，约定是应用配置，状态是当前打开的文档。操作系统不会频繁换，配置会按需调整，文档在持续编辑。三者混在一起管理，你就没法工作了。 三层之间的交互 背景为所有任务提供基础认知。约定规定了任务该怎么执行。状态记录了任务实际执行的情况。一个任务开始时，AI 读取背景理解项目，读取约定知道怎么做，然后创建状态开始执行。任务结束时，状态归档，背景和约定保持不变。 这个结构可以逐层独立演化。你不需要因为改了一个约定而重建整个背景，也不需要因为完成一个任务而重新整理所有约定。

既然上下文这么重要，那有没有现成的方案？有，但都不够。 Git 管代码版本。 Git 记录的是"谁在什么时候改了什么"。它回答的是"怎么变成这样的"这个问题，而不是"现在 AI 需要知道什么"。你可以从 Git 历史里推断上下文，但那是人的工作，不是 AI 能高效做的事情。 Obsidian 管个人知识。 Obsidian 是"人学了什么"的整理。它按人的认知结构组织，而不是按 AI 的任务需求组织。一个笔记可能包含多个主题的混合，一个任务可能需要跨多个笔记的信息。知识点和任务上下文之间，有一层转换工作要做。 AI 聊天记录管对话。 聊天记录记录了曾经的问答，但问答是线性的、有始有终的。一个项目有多个方向、多个阶段、多个并行任务，全都混在一条对话流里，不可分割，不可复用。 Prompt 模板管指令。 很多人写 Prompt 模板，试图把上下文固化到模板里。但模板是静态的，项目是动态的。今天加了新功能，明天改了技术选型，模板跟不上变化。而且模板越长，维护成本越高。 这几个方案各管一个维度，但没有一个管"AI 在当前任务中需要知道什么"这个维度。 这不是谁的错。因为这些工具在设计时，AI 还不是协作对象，它们的用户是人。人可以根据上下文碎片自己拼出全貌，AI 不行。 那需要什么？ 需要一个专门为 AI 设计的上下文管理系统。它应该： 以 AI 为第一读者，而不是人 按任务组织，而不是按文件或个人知识 结构化的，可被 AI 路由和索引的 可持久化、可版本化、可跨会话复用的 模型无关、工具无关的 听起来很复杂？其实很简单。一个目录结构，几份约定文件，一套工作流，就够了。这就是接下来要讲的 AI Context Workspace。

如果把 AI 协作比作一个经济体，那上下文就是它的货币。没有货币，交易无法进行。没有上下文，AI 无法有效工作。 这不是比喻，这是技术事实。 大语言模型的核心机制是"根据输入预测输出"。输入就是上下文，输出就是回答。上下文的质量——相关性、完整性、清晰度——直接决定了输出质量。这是底层技术决定的，不是谁的设计偏好。 上下文有三个关键维度： 第一，相关性。 AI 收到 10,000 个 token 的上下文，其中 8,000 是无关的，那么 AI 要从 8,000 个噪音里找到 2,000 个信号。这不是做不到，但浪费了模型的注意力预算。好的上下文应该只包含当前任务需要的信息，不该有的一个字都不要有。 第二，完整性。 上下文有缺失，AI 会脑补。有时候脑补对了，有时候错了。错了你也不知道，因为 AI 不会主动告诉你"你给我的信息不全"。它只会给出一个看似合理的答案，然后在某个细节上暴露问题。上下文缺失的后果是隐性的，比显性错误更难排查。 第三，结构清晰度。 同样一段信息，写成一段连续的文字，和写成结构化的分层文档，AI 的理解效率差很多。结构化的信息更容易被 AI 的路由和索引机制利用，非结构化的信息只能靠模型硬读。 所以，上下文管理不是"写文档"，而是"设计信息结构"。 大多数人使用 AI 的方式是：打开对话框，把背景信息粘进去，开始提问。这个方式看似高效，但每次都在重新构建上下文，没有积累。 而一个成熟的 AI 协作方式应该是： 上下文是预先准备好的，任务是按需启动的，AI 读取的是结构化的上下文，而不是对话历史。 就像你写代码不会每次重新打一遍标准库，而是 import 进来。上下文也应该被 import，而不是被重复。

很多人遇到 AI 协作不顺畅时，第一反应是换工具。 ChatGPT 不够好，换 Claude。Claude 上下文不够长，换 Gemini。Web 端不好用，用 API。Prompt 写不好，上 Prompt 框架。单模型不够，上 Agent 编排。 但问题解决了吗？通常没有。换了一圈，发现新工具也有新问题。 为什么？ 因为问题不在工具层面。你换一个模型，AI 仍然不知道你项目的背景。你换一个客户端，对话历史仍然无法跨 session 复用。你写更长的 Prompt，AI 仍然会在长上下文中迷失。 这些问题有一个共同的根： 上下文没有被作为基础设施来管理 。 模型负责推理，客户端负责交互，Prompt 负责指令——但没有一个组件负责"让 AI 理解它当前所处的整个情境"。这个职责被甩给了用户，用户通过"不断重复"来弥补。 你想想，一个项目里，你跟 AI 说"我们是做电商平台的，技术栈是 Next.js + PostgreSQL"这句话，要说多少次？每一次新对话、每一个新任务、每一次换工具，你都要说一遍。这不合理。 工具解决的是"怎么问"的问题，但你没解决的是"AI 需要知道什么"的问题。 后者比前者重要得多。一个知道所有背景的 AI，用最原始的模型，也能给出不错的答案。一个什么都不知道的 AI，配最先进的模型，也可能答非所问。 所以，不要在工具层面找答案。 先把上下文管好。然后你会发现，用什么工具、什么模型、什么 Prompt 框架，都变得简单了。因为 AI 已经知道它需要知道的一切，你要做的只是问问题而已。 这不是一个技术问题，这是一个结构问题。技术问题有标准答案，结构问题需要你自己设计。

你打开 ChatGPT，开始一个新的对话。你描述了项目的背景，说了你的需求，AI 给出了一个不错的回答。你继续追问，AI 理解你的意思，来回几轮，事情推进得挺顺利。 第二天，你打开同一个对话，发现上下文太长，AI 开始遗忘前面的内容。或者你干脆新建了一个对话，把昨天说过的话再说一遍。 这个场景你熟悉吗？熟悉就对了。几乎每个 AI 重度用户都在经历这个循环。 问题出在哪？ 问题在于我们把"对话"当成了"上下文"。对话是一条线，从左到右，从开始到结束。但一个项目是网状的，有背景、有历史、有依赖、有多个并行任务。用一条线去承载一个网，必然断裂。 想想你平时怎么跟人协作的。一个新同事加入项目，你不会把过去三个月的聊天记录扔给他，让他自己看。你会给他一份文档：项目背景、技术选型、当前进度、接下来要做什么。这份文档就是上下文。 但跟 AI 协作时，我们恰恰在做相反的事情。我们每次都给 AI 一段对话历史，期望它自己从中提取出真正需要的信息。但对话历史里充满了试错、方向调整、废话和重复。AI 要从这些噪音里找出信号，不是做不到，但 token 数量和注意力都有限，效果必然随着对话长度衰减。 对话适合什么？ 对话适合探索、头脑风暴、快速问答。这些场景的特点是：不需要长期记忆，不需要跨任务复用上下文，一次性的。 但当你开始做一个项目，需要分多个阶段完成，需要 AI 理解项目的全貌而不是当前这一小段对话时，对话模式就失效了。 那怎么办？ 你需要把"上下文"从对话中剥离出来，独立管理。上下文应该是一个结构化的、可持久化的、可跨对话复用的资产，而不是对话的附属品。 这是整本书的起点。如果你认同这个问题的存在，后面的内容就都是围绕这个问题展开的。

前言 这本书不讲 LangChain、不讲 RAG、不讲 Function Calling。市面上关于 AI 的书已经够多了，不缺我这一本讲技术的。 我想讲的一件事是： 为什么你用了那么多 AI 工具，还是觉得 AI 不够聪明？ 这些年我用过 ChatGPT、Claude、Copilot、Cursor、Codex、OpenCode……几乎每个主流 AI 客户端我都深度使用过。我得出的结论是：问题不在模型，不在工具，在于 上下文 。 你跟 AI 对话一小时，它表现惊艳。但第二天继续，它忘了昨天的一切。你换一个项目，它把上个项目的记忆混进来。你尝试用 Prompt 模板解决这个问题，但 Prompt 越长，AI 越容易跑偏。 这不是你的问题，这是当前 AI 协作方式的根本缺陷—— 对话不是上下文 。 我花了很长时间摸索，最终沉淀出一套解决方案： AI Context Workspace 。它不是一个新的 AI 工具，而是一种组织上下文的方法。它不绑定任何模型、任何客户端、任何框架。它只是一个目录结构、一套约定、一个工作流。 这套方法我已经在多个项目中实际使用，效果显著。它不复杂，核心思想一个下午就能讲清楚。但需要你转变一个认知： 不要告诉 AI 怎么回答问题，要为 AI 准备好回答问题的上下文。 这本书不长，大约三万多字，分六个大篇。你可以从头读到尾，也可以按需跳读。如果你读完后觉得"这个思路有意思，但好像也没那么复杂"，那说明我写对了。 那就开始吧。

第八章：从写作工作区看通用结构 写作是理解 ACW 的好样本。 因为写作天然包含长期背景、风格约束、过程草稿、最终正文和审校反馈。一本书不可能只靠一次对话完成。它需要主题、读者、目录、素材、章节、术语、风格、事实边界、版本管理和交付信息。 假设我们要写一本技术书，项目目录可以是： projects/acw-book/ ├── AGENTS.md ├── README.md ├── proposal.md ├── outline.md ├── style-guide.md ├── manuscript/ ├── materials/ ├── references/ └── submission.md 这个结构不是只适合写书。我们先从写书理解它，再抽象到通用项目。 proposal.md 写选题定位。 它说明这本书讲什么、不讲什么、面向谁、读者读完能获得什么。没有 proposal，AI 很容易在写作中偏题。比如一本讲 ACW 的书，不能写成普通 Prompt 技巧书，也不能写成某个工具的操作手册。 outline.md 写目录。 目录是全书结构的骨架。它不仅列标题，也说明每章承担什么功能。好的目录能让 AI 知道当前章节在全书中的位置，避免某一章重复讲前文内容，或者提前展开后文应该讲的东西。 style-guide.md 写风格和术语。 一本书最怕前后语气不一致、术语不断漂移。比如本书中， artifacts/ 必须指过程产物， projects/ 必须指成果层和项目层， conventions/ 必须指协作规则和流程标准。如果这些术语不稳定，读者会被带乱，AI 也会被带乱。 manuscript/ 放正式正文。 这是最终产物所在的位置。正文可以是一整个文件，也可以按章节拆分。关键是让 AI 和人类都知道：这里是当前有效书稿，不是过程草稿。 materials/ 放长期素材。 它可以保存观点、案例、术语表、待确认事项、读者问题、后续扩写方向。这些材料不一定直接进入正文，但会长期影响写作。 references/ 放参考资料入口。 参考资料需要谨慎处理。不是所有外部材料都能直接复用。涉及版权、事实、引用、直播文本时，都应该明确来源和使用边界。 submission.md 放交付信息。 如果书要出版、投稿或发布，...

配置与失败恢复 article-slide-video 的设计强调可恢复和可审计。每个阶段写入固定文件，调度器通过这些文件判断下一步能否继续，以及失败后应该从哪里重跑。 输出目录策略 article-slide-video 读取自身根目录的 env.json ： { "ARTICLE_SLIDE_VIDEO_OUTPUT_ROOT": "~/ai-artifacts/article-slide-video" } 默认输出路径是： ARTICLE_SLIDE_VIDEO_OUTPUT_ROOT/<输入文件名或安全主题名>/ 用户明确指定输出目录时，指定值覆盖默认策略。 所有中间产物和交付物都必须写入这个目录，包括口播稿、规划、HTML、音频、视频、字幕、封面、QA 帧和报告。 配置分布 每个依赖外部参数的原子 Skill 都读取自己的 env.json ，运行时同名环境变量可以覆盖默认值。 这种设计避免把所有配置集中到调度器里，也让每个 Skill 可以独立运行和测试。 典型配置来源： article-slide-video/env.json ：输出根目录。 bytedance-tts/env.json ：TTS 接口、音色、模型、采样率等。 slide-video-delivery/env.json ：视频尺寸、封面尺寸、FFmpeg、Playwright、imagegen 相关参数。 凭据边界 BYTE_TTS_API_KEY 必须由运行时环境变量提供，不写入仓库产物，也不能输出到日志。 TTS 阶段只把正文发送给接口， slide_id 、时间线、静音停顿和最终 manifest 都在本地处理。 封面生成可能使用 imagegen。交付 Skill 只把非空的 OPENAI_BASE_URL 和 OPENAI_API_KEY 注入 imagegen 子进程，不把凭据写入交付物或日志。 失败恢复原则 失败后不默认从头重跑，而是根据产物边界定位失败阶段。 常见恢复方式： voiceover.md 不存在或内容不对：回到 voiceover-editor 。 分页或停顿不合理：回到 slide-narration-planner ，重新生成 n...

用 AI 自动完成行政巡检闭环 在公司日常管理中，行政部门经常需要远程检查宿舍、办公室、浴室等场所。 传统做法是让各地子公司或事业部的相关人员定期拍摄照片、填写情况说明，再发送给总部。总部的行政人员收到以后，要人工查看照片和描述，从多个维度进行分析和打分。如果检查不通过，还要告诉对方如何整改，并持续催促。整改完成后，总部还得再次核对新提交的信息，直到问题彻底解决，或者进入绩效考核。 这个流程并不复杂，但重复工作很多。那么，AI 能不能把它自动化？ 我们公司正好遇到了这样的真实场景。一开始采用的方案，是钉钉的 AI 表格。你可以把它理解成一个带有 AI 能力的 Excel，也就是 Office 表格里增加了一类 AI 字段。 在这个 AI 字段中，可以直接给大模型配置指令。同时，表格本身提供了触发机制。比如表格中有一个用于收集照片的字段，一旦照片发生变化，对应的 AI 字段就会自动触发，把预先配置的指令和关联照片一起发送给钉钉的 AI 服务。 AI 收到内容后，会按照指令分析照片，并返回检查结果。我们可以让它从多个维度进行评价、打分，指出存在的问题，再给出相应的整改建议。这样，原来需要人工处理的检查工作，就可以自动完成。 不过，钉钉原生 AI 服务有一个实际问题。普通情况下，请求需要排队。每个月大约有 300 个算力点，如果一次调用消耗 0.1 个算力点，大致可以调用 3000 次。次数本身可能够用，但免费额度需要等待。如果希望提高处理速度、不排队，就需要购买更高规格的服务。原转写中提到的价格大约是四万元，但具体是按年还是按月收费，我记得不够准确，需要再确认。至少对我们公司来说，这笔费用没有获批。 所以，我们又做了一套更节省成本的方案。 钉钉 AI 表格本身带有自动化能力，有点像低代码平台，可以通过拖拉拽的方式编排流程。比如表单提交、新增一条记录，或者某个字段发生变化，都可以触发后续动作。 我们保留了钉钉表格和自动化流程，但没有继续使用钉钉原生的 AI 字段，而是把 AI 能力放到了阿里云百炼。 阿里云百炼支持创建 AI 智能体。智能体配置完成后，会提供标准的 HTTP API。我们在百炼中创建了几个智能体，实现和原来钉钉 AI 字段基本一致的分析能力。 整个流程就变成了这样：用户提交表单，必填的照片字段被写入后，钉钉自动化流程随即触发。自动化...

我们有那种很传统的需求，就是人工操作的，常见的就是写名片，那比如你公司有很多人啊，几几百几千甚至上万人，然后呢，给一个名片模板。 早期呢啊，包括现在吧，还有一些公司都是人工去按照模板去修改你的姓名啊，职位啊，电话呀等等相关东西，其实就是个很枯燥的复制粘贴，然后导出的一个工作，尤其像用PS这种软件的时候。 ，， 然后呢。 其实好一点你就做个软件嘛，你就做个软件嘛，然后。 把表格导进去，让这个让软件给你按照固定的格式去处理嘛，这样也行。 那把AI结合进去呢，可以做什么呢？ 其实AI结合进去是有一些场景的，这个不单单是个数字化，场景有两个场景一定是可以用到的。 第一，AI帮你审核录入的数据是否合法。 对吧，你比方说把手机号填到了姓名里啊，把姓名填到了手机号里啊，啊或者干脆就写错了，或者说甚至严重一点，有一些。 啊，不那么好的信息填进去了啊，AI可以帮你做一层过滤啊，之前可能都是人工过滤的啊，这一点是AI能力的。 然后第二点呢，是你比方说你电脑上装了 啊，Work body啊，或者codex啊等等相关这种软件桌面版的，然后呢，你可以做一个skill。 Skill里面把之前的那个我们说的那个应用做成脚本化，然后呢，你通过对话，对话的方式把那个。 Excel文件啊发给发给AI，然后呢，AI吭哧吭哧调用skill啊，花个1分钟两分钟帮你做完，哎这样也就是一种AI使用场景，它很适合那种。 不懂电脑软件的啊，他但是又擅长AI对话的，通过这种方式呢，也可以降低认知。

视频交付与 QA slide-video-delivery 是最终交付阶段。它被设计为不可拆分的阶段：只有视频、字幕、横屏封面、竖屏封面和 QA 全部完成，才算交付成功。 输入 交付阶段需要四类输入： deck-manifest.json ：描述 HTML 入口、画布和页面 ID。 deck.html ：实现 window.__SLIDE_VIDEO__ 的 HTML 幻灯片。 tts-manifest.json ：记录真实音频时间线。 voiceover.wav ：TTS 生成的完整音频。 执行前会校验 schema version、画布尺寸和 slide_id 集合。这里禁止按页面数量猜测映射。 逐页渲染 render_slides.js 使用 Playwright 打开 deck.html ，按 deck-manifest.json 中的顺序逐页调用： await window.__SLIDE_VIDEO__.showSlide(slideId); await window.__SLIDE_VIDEO__.ready(slideId); 然后等待 settle_ms ，截图到 frames/ 。默认画布来自 manifest 的 canvas ，通常是 1920×1080。 这个阶段的目标是把动态 HTML 固化成稳定帧序列。 视频合成 make_video.py 读取 tts-manifest.json ，按每页所有片段的 audio_duration + break_after 计算页面持续时间，然后把帧序列和 voiceover.wav 合成为 final.mp4 。 关键点是视频时长跟随真实 TTS manifest，而不是用估算字数或固定页时长。 字幕生成与烧录 make_ass_subtitles.py 从 tts-manifest.json 直接生成 subtitles.ass 。 字幕时间轴使用片段的 start 、 audio_duration 和 end 。这样字幕、音频和画面都来源于同一条实际时间线。 burn_subtitles.py 再把字幕烧录进视频，生成 final-subtitled.mp4 。 双封面 交付阶段固定生成两张封面： 横屏 cover.p...

幻灯片生成器契约 article-slide-video 默认使用 frontend-slides 生成 HTML 幻灯片，但系统设计上不绑定它。生成器只要满足同一份视频渲染契约，就可以替换。 为什么要有生成器契约 不同 HTML 幻灯片工具的内部实现差异很大： DOM 结构不同。 CSS class 不同。 切页方式不同。 是否有路由不同。 动画、图片加载、字体加载策略不同。 如果视频交付脚本直接依赖 .slide 、 .active 、某个控制条或特定路由，后续就很难替换生成器。当前设计把这些差异封装在 HTML 自己内部，下游只调用统一接口。 生成器必须输出什么 生成器至少输出两个文件： deck.html deck-manifest.json 并且 deck.html 必须暴露： window.__SLIDE_VIDEO__ = { async showSlide(slideId) { // 切换到指定页面，并关闭控制条、编辑态和动画。 }, async ready(slideId) { // 等待字体、当前页面图片、异步数据和布局稳定。 }, }; ready(slideId) 是可选方法，但强烈建议实现。视频渲染器会设置 30 秒超时，避免被隐藏页面的懒加载资源拖死。 浏览器桥接负责什么 showSlide(slideId) 负责把浏览器切到指定页面，并让页面进入适合截图的静态状态： 找到对应 slide_id 的页面。 只显示目标页面。 关闭动画和 transition。 隐藏控制条、编辑按钮、热区等非视频元素。 把当前页面图片改为 eager 加载。 ready(slideId) 负责等待截图前的稳定条件： 字体加载完成。 当前页面图片加载完成或失败返回。 异步数据和布局稳定。 不等待隐藏页面的资源。 这样视频渲染器只关心：“给我 slide-03 的最终画面”。至于页面内部怎么切换，由生成器自己处理。 deck-manifest.json 的安全边界 deck-manifest.json 的 entry 只能是相对路径，而且解析软链接后仍必须留在 manifest 所在目录内。 这个限制有两个目的： 防止渲染器...

数据契约 article-slide-video 的稳定性来自文件契约。每个阶段只消费上游明确产物，并把自己的产物写回输出目录。 voiceover.md 来源： voiceover-editor 用途：冻结后的唯一口播文本来源。 格式要求： Markdown 文件。 不带 frontmatter。 第一行为不参与朗读的 H1 标题。 后续正文使用自然段。 不包含未经确认的新事实。 关键约束：后续阶段不得直接回到原文重新解释内容。需要改内容时，必须先修改并重新冻结 voiceover.md 。 narration-plan.json 来源： slide-narration-planner 用途：定义页面、口播片段和页面停顿。 典型结构： { "schema_version": 1, "title": "标题", "slides": [ { "slide_id": "slide-01", "segments": [ { "segment_id": "slide-01-segment-01", "text": "这一页的口播正文。", "break_after": 0.4 } ] } ] } 字段约束： schema_version 固定为 1 。 slides 必须是非空数组。 slide_id 唯一，格式匹配 ^slide-[a-z0-9][a-z0-9_-]*$ 。 segment_id 唯一。 text 不能为空。 break_after 范围为 0 到 0.5 秒。 设计含义：它既是分页计划，也是后续 deck 和 TTS 的对齐基准。 deck-manifest.json 来源：HTML 幻灯片生成器，例如 frontend-slides 。 用途：告诉视频交付阶段如何加载 HTML、...

调度流程 article-slide-video 的流水线从输入文章、讲稿或脚本开始，到带字幕视频、横竖封面和 QA 报告结束。每一步都产出可落盘检查的中间文件。 1. 创建输出目录 默认输出根目录来自 article-slide-video/env.json ： { "ARTICLE_SLIDE_VIDEO_OUTPUT_ROOT": "~/ai-artifacts/article-slide-video" } 如果用户没有指定输出目录，调度器按输入文件名或安全主题名创建子目录。所有中间产物和最终交付物都写入这个目录，禁止写到输入文件旁边。 2. 生成冻结口播稿 调度器加载 voiceover-editor ，把输入文本整理为 voiceover.md 。 这个阶段的原则是编辑而不是创作： 成熟口播稿只修复明显错字、断句和朗读问题。 普通文章或笔记改成自然口语和适合换气的句长。 转写文本删除口头禅、口吃重复和重新起头残句。 不添加原文没有的事实、数据、案例或结论。 voiceover.md 的第一行是 H1 标题，正文是自然段。写入后它被视为后续流程唯一文本来源。 3. 生成讲述规划 调度器加载 slide-narration-planner ，从冻结的 voiceover.md 生成 narration-plan.json 。 默认规则是： 空行分隔视为页面边界。 页面 ID 使用稳定格式： slide-01 、 slide-02 。 每页尽量一个口播片段。 页面停顿通常为 0.35s 到 0.4s ，最长不超过 0.5s 。 只允许重新分页，不允许改写口播稿措辞。 从这一阶段开始， slide_id 成为全流程主键。 4. 生成视频可渲染的 HTML deck 调度器选择 HTML 幻灯片生成器。默认是 frontend-slides ；用户指定其他工具时，可以替换为 Hyperframes 或其他生成器。 生成器必须输出： deck.html deck-manifest.json HTML 内部的 window.__SLIDE_VIDEO__ 浏览器桥接 生成器必须使用 narration-plan.json 中的原始 slide...

总体设计 article-slide-video 是文章口播幻灯片视频工作流的调度 Skill。它本身不编辑文本、不请求 TTS、不渲染 HTML、不合成视频，也不生成字幕或封面；这些能力分别交给独立原子 Skill 完成。 它的职责是： 创建统一输出目录。 调用上游和下游 Skill。 确保中间产物按契约落盘。 校验 slide_id 在各阶段一致。 只在失败阶段重跑，不无差别推倒重来。 最终汇总交付物路径和 QA 状态。 设计目标 1. 把内容生产和工程交付拆开 文章转视频同时包含写作、视觉设计、语音合成、浏览器渲染、FFmpeg 合成和人工视觉检查。如果都放在一个 Skill 里，边界会迅速失控。 当前设计把流程拆为几个明确阶段： voiceover-editor ：只产出冻结口播稿。 slide-narration-planner ：只做分页和讲述规划。 frontend-slides 或其他生成器：只产出视频可渲染的 HTML deck。 bytedance-tts ：只产出音频和音频时间线。 slide-video-delivery ：只负责最终视频、字幕、封面和 QA。 article-slide-video 只管编排和验收。 2. 用文件契约连接阶段 阶段之间不共享内存状态，也不依赖对话上下文里的临时描述，而是通过固定文件传递： voiceover.md narration-plan.json deck.html deck-manifest.json voiceover.wav tts-manifest.json delivery-report.json 这样做的好处是中断后可恢复、失败后可定位、交付物可审计，也方便替换某个阶段的实现。 3. 用稳定 slide_id 防止错页 视频生成最容易出问题的地方是“第几页”和“哪段音频”的映射漂移。当前设计要求从 narration-plan.json 开始生成稳定 slide_id ，例如 slide-01 、 slide-02 。 后续阶段必须复用这些 ID： HTML 页面使用同一组 slide_id 。 deck-manifest.json 记录同一组 slide_id 。 TTS manifest 记录...

12 尾声：从说清楚，到沉淀清楚 标题备选 AI 时代，比会提问更重要的是会沉淀 从 Prompt 到 ACW：从说清楚，到沉淀清楚 真正稳定的 AI 协作，不靠临场聊天 开场钩子 AI 时代，很多人把注意力放在“如何说清楚”上。 这当然重要。 但只会说清楚，还不够。 正文口播 你越能清楚表达目标、背景、约束和标准，AI 越容易给出有用答案。 Prompt 能力仍然是基础能力。 但复杂任务不是一次说清楚就能完成的。 它会变，会返工，会积累材料，会产生版本，会遇到错误，会出现新的规则。 你今天说清楚的东西，如果没有沉淀，明天还要再说一次。 你这次纠正的错误，如果没有变成规则，下次还会再犯。 所以更重要的能力，是沉淀清楚。 把稳定背景沉淀到 background。 把协作规则沉淀到 conventions。 把任务过程沉淀到 artifacts。 把最终成果沉淀到 projects。 把临时材料放进 tmp，不要污染长期上下文。 把入口文件写成地图，而不是垃圾桶。 把 AI 的错误转化为规则。 把一次任务的经验转化为模板。 把临时对话中的有效信息转化为可复用上下文。 这就是 ACW 的核心。 它不神秘，也不昂贵。 它只是要求我们承认一件事：AI 协作不是只有提问和回答，它也需要项目管理、知识组织、流程设计和质量验证。 当你开始这样工作，AI 的角色会发生变化。 它不再只是聊天窗口里的回答者，而是一个能进入项目、读取背景、遵守规则、留下过程、产出成果、接受审校并持续改进的协作者。 它仍然会犯错，仍然需要人类判断，仍然不能替代责任。 但它可以在一个更清楚的环境里工作。 而你要做的，也不只是写出更长、更复杂、更漂亮的 Prompt。 你要搭一张桌子。 桌子上有地图，有资料，有规则，有草稿，有成品，有检查清单。 每一次协作结束后，桌面不会清空，而是变得更有秩序。 下一次 AI 进来时，不必从零开始。 这就是从 Prompt 到 ACW 的升级。 从说清楚，到沉淀清楚。 从一次回答，到长期协作。 从临场聊天，到工程结构。 结尾引导 如果你之前一直觉得 AI 很强，但用久了又很不稳定，可以试着不要先优化 Prompt，而是先整理你的工作区。 下一步不是问：我该怎么把这句话说得更漂亮？ 而是...

11 常见错误与演进路线 标题备选 ACW 看起来简单，但最容易踩这 6 个坑 AI 工作区别变成形式主义 从最小工作区到团队协作，ACW 怎么演进 开场钩子 ACW 看起来简单，但实践中很容易走偏。 有些人把它做成一个超长入口文件，有些人只建目录不写规则，还有些人把每个小任务都搞成重流程。 这些都不是 ACW 真正想解决的问题。 正文口播 第一个常见错误，是把所有东西塞进一个文件。 这通常发生在入口文件上。 用户希望 AI 一进来就知道全部内容，于是把背景、规则、历史、任务、模板、示例都写进 AGENTS.md。 短期看似方便，长期一定混乱。 解决方法是分层。 入口文件只做定位、路由和最高优先级约束。 背景进 background，规则进 conventions，过程进 artifacts，成果进 projects。 第二个错误，是只建目录不写规则。 目录本身不会自动产生秩序。 AI 需要知道目录的用途、文件的优先级、任务的流程和输出标准。 如果没有规则，工作区只是一个空壳。 解决方法是从最小规则开始。 先写清楚成果放哪里、过程放哪里、哪些事实不能编、任务前要读什么、完成后要检查什么。 第三个错误，是过程产物和最终成果混放。 这会让 AI 无法判断哪一版有效。 尤其在写作、设计、代码生成中，草稿、废弃方案和正式成果混在一起，会造成严重污染。 解决方法是坚持 projects 和 artifacts 分工。 最终产物在项目层，过程记录在 artifact 层。 第四个错误，是过度流程化。 有些人理解 ACW 后，会把所有任务都套完整流程。 改一个标点也要建 artifact，润色一句话也要写需求文档。 这会让工作区变慢，用户也会很快放弃。 解决方法是任务分级。 小任务直接做，中等任务轻量留痕，大任务完整流程。 工程化不是繁琐化，工程化是让复杂任务可控。 第五个错误，是没有验证闭环。 AI 输出一段内容，不代表任务完成。 复杂任务必须检查。 写作要审校，代码要测试，方案要核对约束，研究要检查来源。 解决方法是在 conventions 中写明各类任务的验收标准，并在 artifact 中保留 review。 第六个错误，是把 ACW 当成一次性模板。 很多人希望找到一个完美目录，复制...

10 把已有项目反向 ACW 化 标题备选 已有项目别推倒重来，反向 ACW 化就行 一堆旧文件怎么变成 AI 工作区 让 AI 先理解项目，而不是立刻修改项目 开场钩子 很多人不是从空白开始搭 ACW。 你可能已经有一本写了一半的书，一个正在开发的软件，一个混乱的资料库，一个运营了一年的账号。 这时候，不要急着推倒重来。 正文口播 更好的做法，是让已有项目反向 ACW 化。 第一步，把已有项目放进 projects/project。 这里要再次强调：projects 既是最终产物目录，也是已有工程进入 ACW 的起点。 已有项目放进来后，它既是当前成果，也是后续整理的原始对象。 第二步，让 AI 先读项目结构，而不是立刻修改。 很多人一接入项目，就让 AI “帮我优化一下”。 这太急了。 更稳的做法，是先让 AI 输出项目理解： 有哪些文件？ 哪些看起来是最终产物？ 哪些像素材？ 哪些像过程稿？ 哪些规则可能隐含在文件中？ 哪些地方存在混乱？ 第三步，反向生成背景。 AI 可以从已有项目中抽取稳定信息，写入 background。 例如一本小说的世界观、人物关系、时间线。 一个软件的业务目标、核心模块、用户角色。 一个研究项目的主题、资料来源和关键概念。 这里要注意事实边界。 AI 可以总结和推断，但不能把推断伪装成已确认事实。 最好明确标注：从现有材料推断、待用户确认、已在项目文件中明确出现。 第四步，反向生成规则。 已有项目里往往隐藏着许多规则。 代码风格、命名习惯、目录约定、写作语气、术语用法、发布流程，可能没有单独成文，但已经体现在文件中。 AI 可以把这些隐含规则整理到 conventions。 这一步很有价值。 因为一旦隐含规则显性化，后续 AI 就更容易遵守项目风格，而不是每次靠猜。 第五步，建立索引和路由。 已有项目通常最缺的不是内容，而是入口。 AI 不知道从哪里读起，人类也不一定清楚哪个文件代表最新状态。 通过 AGENTS.md 或目录索引，可以建立清晰路由：项目总览在哪里，最终成果在哪里，素材在哪里，历史版本在哪里，哪些文件不要动。 第六步，设计后续任务流程。 反向整理完成后，才适合进入具体任务：续写、重构、审校、开发新功能、整理资料、生成发布稿。 ...

09 从写作工作区看通用结构 标题备选 用写一本书，讲清楚 ACW 的通用结构 AI 写作工作区怎么搭？其实能迁移到所有复杂任务 ACW 的通用性，来自职责分离 开场钩子 写作是理解 ACW 的好样本。 因为写作天然包含长期背景、风格约束、过程草稿、最终正文和审校反馈。 一本书不可能只靠一次对话完成。 正文口播 假设我们要写一本技术书，项目目录可以是这样： projects/acw-book 下面，有 AGENTS.md、README.md、proposal.md、outline.md、style-guide.md、manuscript、materials、references、submission.md。 这个结构不是只适合写书。 我们先从写书理解它，再抽象到通用项目。 proposal.md 写选题定位。 它说明这本书讲什么、不讲什么、面向谁、读者读完能获得什么。 没有 proposal，AI 很容易在写作中偏题。 比如一本讲 ACW 的书，不能写成普通 Prompt 技巧书，也不能写成某个工具的操作手册。 outline.md 写目录。 目录是全书结构的骨架。 它不仅列标题，也说明每章承担什么功能。 好的目录能让 AI 知道当前章节在全书中的位置，避免某一章重复讲前文内容，或者提前展开后文应该讲的东西。 style-guide.md 写风格和术语。 一本书最怕前后语气不一致，术语不断漂移。 比如在 ACW 里，artifacts 必须指过程产物，projects 必须指成果层和项目层，conventions 必须指协作规则和流程标准。 如果这些术语不稳定，读者会被带乱，AI 也会被带乱。 manuscript 放正式正文。 这是最终产物所在的位置。正文可以是一个文件，也可以按章节拆分。 关键是让 AI 和人类都知道：这里是当前有效书稿，不是过程草稿。 materials 放长期素材。 它可以保存观点、案例、术语表、待确认事项、读者问题、后续扩写方向。 references 放参考资料入口。 参考资料需要谨慎处理。不是所有外部材料都能直接复用。涉及版权、事实、引用时，都应该明确来源和使用边界。 submission 放交付信息。 如果书要出版、投稿或发布，这里可以记录书名、字数、简介、版本、...

08 任务流程：从一句需求到可验收产物 标题备选 复杂任务别让 AI 直接开写 从一句需求到可验收产物，AI 应该这样走流程 ACW 不是目录，而是一条可检查的任务链路 开场钩子 ACW 不只是静态目录，还需要任务流程。 没有流程时，AI 很容易从一句需求直接跳到最终输出。 小任务没问题，但复杂任务这样做，返工概率非常高。 正文口播 比如你说：帮我写一本 1.5 万字的专业书。 如果 AI 立刻开始写正文，它可能会忽略读者定位、章节结构、术语边界、已有材料、最终文件位置。 等正文写完，你再发现方向不对，成本就很高。 一个更稳的流程是： raw-input、requirements、structure、writing-spec、drafting、review、submission。 这条链路来自写作场景，但可以迁移到很多领域。 raw-input 保存原始输入。 原始输入很重要，因为它保留了用户最初怎么说。 整理后的需求可能更清楚，但也可能丢失语气、重点和限制。 保存原始输入，可以在后续发生争议时回看源头。 写作任务中，它可以是用户需求、素材、直播文本、参考目录说明。 软件任务中，它可以是 issue、报错日志、需求描述、用户反馈。 requirements 提炼任务要求。 它回答：这次到底要做什么？目标是什么？读者是谁？字数范围是多少？验收标准是什么？事实边界在哪里？哪些问题必须确认？ 很多 AI 输出失败，不是写作能力不足，而是需求没有被拆清楚。 structure 设计结构。 写书要目录，写文章要论证路径，写软件要模块设计，做研究要分析框架。 结构阶段的目标，是先确定骨架，再进入生产。 你审一份目录，比审一万字正文容易得多。 你审一个接口设计，比审几千行代码容易得多。 writing-spec，也就是执行规格，定义如何写、如何做。 这里包括语气、格式、术语、素材使用、禁区、目标文件、质量标准。 如果是软件任务，它可以叫 implementation spec，写明修改范围、技术方案、测试要求和兼容性边界。 drafting 是起草或实现。 这是最容易被看见的阶段，但它不应该孤立存在。 好的 drafting 应该响应前面的需求、结构和规格。 review 是审校或验证。 复杂任务不能只...

06 conventions 为什么是中后期最重要的目录 标题备选 AI 老犯同一个错？把错误写进 conventions ACW 里最容易被低估的目录：conventions 背景告诉 AI 是什么，规则告诉 AI 怎么做 开场钩子 很多人搭 AI 工作区时，最重视 background。 这很自然。背景资料最像知识。 但一个 ACW 进入中后期以后，真正决定质量稳定性的，往往是 conventions。 正文口播 background 告诉 AI：这个项目是什么。 conventions 告诉 AI：你应该怎么做。 这两句话的差别非常大。 一个 AI 可能知道项目背景，却仍然用错格式、改错文件、跳过验证、编造事实、忽略风格、把过程稿当成终稿。 它不是缺少背景，而是缺少规则。 人类协作也是一样。一个新人读完公司介绍，并不意味着他知道如何提交代码、如何写会议纪要、如何处理客户投诉、如何做质量检查。 conventions 的价值，就是把隐含经验变成显性规则。 比如写作工作区里，你可能逐渐发现一些问题： AI 喜欢把摘要写得像广告。 喜欢在纪实内容里补细节。 喜欢把审校意见写得很泛。 喜欢直接输出长文而没有先确认结构。 喜欢把最终正文放错目录。 每次问题出现时，你当然可以在对话里说：下次不要这样。 但如果这句话只停留在当前对话，它很快就会消失。 更好的做法，是把它写进 conventions。 比如： 纪实类内容不得补写用户未确认的真实经历。 最终正文必须写入 projects。 artifacts 只保存过程产物，不保存最终正文。 全篇起草前必须先形成结构或目录。 审校报告必须列出具体问题、位置和修改建议。 这些规则不只是限制 AI，它们也在帮助人类减少重复管理成本。 conventions 通常可以包含几类文件。 第一类是原则文件。 它写工作区最重要的价值判断。比如事实边界优先于表达流畅，小任务不套重流程，过程产物和最终产物必须分离，用户最新输入优先于旧文档。 第二类是流程文件。 它写不同任务如何推进。写作任务怎么从需求到正文，软件任务怎么从影响分析到测试，研究任务怎么从资料收集到引用检查。 第三类是质量标准。 它写什么叫做好。写作看结构、风格和事实边界。代码看测试、类型、边界情况和...

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

04 一个最小可用工作区 标题备选 搭一个最小可用 ACW，只需要这 6 个东西 AI 工作区怎么建？先别复杂化 一个能长期协作的 AI 工作区结构 开场钩子 一个最小可用的 ACW，不需要复杂。 你不需要一开始就设计几十个目录、上百条规则。真正好的工作区，通常是从一个很小的结构开始，随着任务慢慢长出来。 正文口播 一个通用的起点可以是六个部分： AGENTS.md、projects、background、conventions、artifacts、tmp。 名字不是绝对的。你可以根据工具、团队和领域调整。 但它们背后的职责非常重要。 第一个，AGENTS.md，是入口文件。 不同工具可能读取不同入口文件，有的叫 AGENTS.md，有的可能叫别的名字。 名字不是重点，重点是：AI 进入工作区时，需要一个最先阅读的地方。 这个文件不应该放所有内容，而应该放最关键的全局说明、目录路由和行为约束。 入口文件像地图，不像仓库。 它告诉 AI：这里是什么项目，哪些目录有什么作用，开始任务前应该读取哪些规范，最终成果应该放到哪里，哪些行为被禁止。 第二个，projects，是成果层。 最终产物应该放在 projects 下，而不是散落在过程目录里。 每个一级子目录代表一个具体项目。写作场景里，可以是一部书。软件场景里，可以是前端、后端、文档、脚本。课程项目里，可以是讲义、课件、录制脚本。 projects 还有另一个用途：当你已经有一个现成项目时，可以把它作为进入 ACW 的起点。后续让 AI 反向分析它，抽取背景、规则、流程和索引。 第三个，background，是稳定背景层。 它回答的问题是：这个项目是什么？我们已经知道什么？ 写小说时，它可以放世界观、人物关系、平台要求。 做软件时，它可以放业务背景、用户画像、系统约束。 做研究时，它可以放主题资料、关键概念、来源摘要。 background 的关键是稳定。一次任务里的临时草稿、未经确认的猜测，不适合直接放进这里。 第四个，conventions，是规则层。 它回答的问题是：AI 应该怎么做？ 这里可以放写作规范、代码规范、审校规则、任务流程、命名规则、质量标准、错误修正规则。 很多 ACW 的长期质量，不取决于 background 有多丰富，而取决于...

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

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

01 为什么要给它起名叫 ACW 标题备选 别再只学 Prompt 了，AI 协作真正缺的是工作区 Prompt 解决一句话，ACW 解决长期协作 我为什么要给 AI 协作起一个新名字：ACW 开场钩子 你有没有发现一个问题：AI 写一篇短文很强，改一个函数也很快，但只要任务一变长，它就开始忘前文、乱风格、改错文件、重复犯错。 很多人以为这是 Prompt 没写好。 但我越来越觉得，问题不只在 Prompt，而在于我们还在用聊天框的方式，处理本来应该工程化管理的长期任务。 正文口播 过去几年，很多人学习 AI 的入口都是 Prompt。 这很正常。Prompt 是最容易被看见的东西。你输入一句话，AI 返回一段答案。你说得越清楚，答案就越接近你想要的样子。 所以大家开始学怎么写角色、怎么写背景、怎么写步骤、怎么给示例、怎么规定输出格式。 这些当然有用。 但只要任务稍微变长，Prompt 的边界就会马上出现。 比如你让 AI 写一篇短文，它可以写。你让它长期写一本书，记住前后设定，保留统一风格，维护目录，记录每次修改原因，根据审校意见反复迭代，它就很容易乱。 再比如你让 AI 改一个函数，它可以改。你让它理解整个工程架构，遵守团队规范，知道哪些文件能动，哪些文件不能动，测试怎么跑，上线风险在哪里，单条 Prompt 就开始不够用了。 所以问题不是 Prompt 没用。 问题是，Prompt 主要解决的是“一次表达”，而很多真正有价值的任务，需要的是“长期协作”。 长期协作需要环境。 它需要稳定背景、明确规则、可追溯过程、可验证结果，也需要一个地方承载最终成果。 对人类团队来说，这些东西很自然。我们会有项目目录、需求文档、会议纪要、代码规范、设计稿、测试报告、版本记录。 但一到 AI 协作，很多人又退回最原始的方式：打开一个聊天框，把所有东西塞进一段话里，然后希望 AI 立刻接住全部复杂度。 这就是我想讨论的问题。 我们需要把 AI 协作从“会写 Prompt”，升级到“会搭工作区”。 这个工作区不是为了显得专业，也不是为了把文件夹分得很漂亮，而是为了让 AI 能按工程方式管理上下文。 它要知道：从哪里读背景，从哪里找规则，过程产物放在哪里，最终成果放在哪里，什么时候该停下来确认，什么时候可以自主执行，做错了以后怎...

ACW B站口播资料索引 使用说明 这份资料是基于 blog/ 目录下 ACW 系列文章转写的口播版。 建议做成一个 12 集短视频系列，每集 3 到 6 分钟。整体语气不走“教程腔”，而是像一个长期使用 AI 协作的人，把自己踩过的坑和总结出的工作方法讲给同频开发者、创作者、知识工作者听。 核心表达主线： 不要只学习怎么写 Prompt，要学习怎么搭一个 AI 能持续工作的上下文工作区。 系列标题备选 别只会写 Prompt 了：真正稳定的 AI 协作，靠的是工作区 我把 AI 协作从聊天框，升级成了一个工程结构 AI Context Workspace：让 AI 不再每次从零开始 为什么你的 AI 总是忘？因为你缺的不是 Prompt，是工作区 从 Prompt 到 ACW：普通人也能搭的 AI 协作系统 分集文件 [[01 为什么要给它起名叫 ACW]] [[02 先做一个上下文实验]] [[03 Prompt 解决一次表达，ACW 解决长期协作]] [[04 一个最小可用工作区]] [[05 入口文件不是垃圾桶]] [[06 conventions 为什么是中后期最重要的目录]] [[07 真正值得沉淀的是高质量中间产物]] [[08 任务流程：从一句需求到可验收产物]] [[09 从写作工作区看通用结构]] [[10 把已有项目反向 ACW 化]] [[11 常见错误与演进路线]] [[12 尾声：从说清楚，到沉淀清楚]]

尾声：从说清楚，到沉淀清楚 AI 时代，很多人把注意力放在“如何说清楚”上。 这当然重要。你越能清楚表达目标、背景、约束和标准，AI 越容易给出有用答案。Prompt 能力仍然是基础能力。 但只会说清楚，还不够。 复杂任务不是一次说清楚就能完成的。它会变，会返工，会积累材料，会产生版本，会遇到错误，会出现新的规则。你今天说清楚的东西，如果没有沉淀，明天还要再说一次。你这次纠正的错误，如果没有变成规则，下次还会再犯。 所以更重要的能力，是沉淀清楚。 把稳定背景沉淀到 background/ 。 把协作规则沉淀到 conventions/ 。 把任务过程沉淀到 artifacts/ 。 把最终成果沉淀到 projects/ 。 把临时材料放进 tmp/ ，不要污染长期上下文。 把入口文件写成地图，而不是垃圾桶。 把 AI 的错误转化为规则，把一次任务的经验转化为模板，把临时对话中的有效信息转化为可复用上下文。 这就是 ACW 的核心。 它不神秘，也不昂贵。它只是要求我们承认一件事：AI 协作不是只有“提问”和“回答”，它也需要项目管理、知识组织、流程设计和质量验证。 当你开始这样工作，AI 的角色会发生变化。 它不再只是一个聊天窗口里的回答者，而是一个能进入项目、读取背景、遵守规则、留下过程、产出成果、接受审校并持续改进的协作者。它仍然会犯错，仍然需要人类判断，仍然不能替代责任。但它可以在一个更清楚的环境里工作。 而你要做的，也不只是写出更长、更复杂、更漂亮的 Prompt。 你要搭一张桌子。 桌子上有地图，有资料，有规则，有草稿，有成品，有检查清单。每一次协作结束后，桌面不会清空，而是变得更有秩序。下一次 AI 进来时，不必从零开始。 这就是从 Prompt 到 ACW 的升级。 从说清楚，到沉淀清楚。 从一次回答，到长期协作。 从临场聊天，到工程结构。

第十章：常见错误与演进路线 ACW 看起来简单，但实践中很容易走偏。 第一个常见错误，是把所有东西塞进一个文件。 这通常发生在入口文件上。用户希望 AI 一进来就知道全部内容，于是把背景、规则、历史、任务、模板、示例都写进 AGENTS.md 。短期看似方便，长期一定混乱。 解决方法是分层。入口文件只做定位、路由和最高优先级约束。背景进 background/ ，规则进 conventions/ ，过程进 artifacts/ ，成果进 projects/ 。 第二个错误，是只建目录不写规则。 目录本身不会自动产生秩序。AI 需要知道目录的用途、文件的优先级、任务的流程和输出标准。如果没有规则，工作区只是一个空壳。 解决方法是从最小规则开始。先写清楚成果放哪里、过程放哪里、哪些事实不能编、任务前要读什么、完成后要检查什么。之后随着错误和返工继续补充。 第三个错误，是过程产物和最终成果混放。 这会让 AI 无法判断哪一版有效。尤其在写作、设计、代码生成中，草稿、废弃方案和正式成果混在一起，会造成严重污染。 解决方法是坚持 projects/ 和 artifacts/ 分工。最终产物在项目层，过程记录在 artifact 层。 第四个错误，是过度流程化。 有些人理解 ACW 后，会把所有任务都套完整流程。改一个标点也要建 artifact，润色一句话也要写需求文档。这会让工作区变慢，用户也会很快放弃。 解决方法是任务分级。小任务直接做，中等任务轻量留痕，大任务完整流程。工程化不是繁琐化，工程化是让复杂任务可控。 第五个错误，是没有验证闭环。 AI 输出一段内容，不代表任务完成。复杂任务必须检查。写作要审校，代码要测试，方案要核对约束，研究要检查来源。 解决方法是在 conventions/ 中写明各类任务的验收标准，并在 artifact 中保留 review。验证不是最后的附加动作，而是任务流程的一部分。 第六个错误，是把 ACW 当成一次性模板。 很多人希望找到一个完美目录，复制后永远使用。但真正的 ACW 一定会随着项目演进。初期结构应该简单，中期根据任务沉淀规则，后期再考虑自动化和团队协作。 一个可行的演进路线是： 第一阶段，最小工作区。 创建入口文件、 projects/ 、 background/ 、 conv...

第九章：把已有项目反向 ACW 化 很多人不是从空白开始。 你可能已经有一个写了一半的书稿，一个正在开发的软件，一个混乱的资料库，一个运营了一年的账号，或者一个堆满文档、表格、PPT 和代码的项目文件夹。 这时候搭 ACW，不是先把一切推倒重来，而是把已有项目接入工作区。 更准确地说，是让已有项目反向 ACW 化。 第一步，把已有项目放进 projects/{project}/ 。 这里要再次强调： projects/ 既是最终产物目录，也是已有工程进入 ACW 的起点。已有项目放进来后，它既是当前成果，也是后续整理的原始对象。 第二步，让 AI 先读项目结构，而不是立刻修改。 很多人一接入项目，就让 AI “帮我优化一下”。这太急了。更稳的做法是先让 AI 输出项目理解：有哪些文件，哪些看起来是最终产物，哪些像素材，哪些像过程稿，哪些规则可能隐含在文件中，哪些地方存在混乱。 第三步，反向生成背景。 AI 可以从已有项目中抽取稳定信息，写入 background/ 。例如一本小说的世界观、人物关系、时间线；一个软件的业务目标、核心模块、用户角色；一个研究项目的主题、资料来源和关键概念。 这里要注意事实边界。AI 可以总结和推断，但不能把推断伪装成已确认事实。最好明确标注：“从现有材料推断”“待用户确认”“已在项目文件中明确出现”。 第四步，反向生成规则。 已有项目里往往隐藏着许多规则。代码风格、命名习惯、目录约定、写作语气、术语用法、发布流程，可能没有单独成文，但已经体现在文件中。AI 可以把这些隐含规则整理到 conventions/ 。 这一步很有价值。因为一旦隐含规则显性化，后续 AI 就更容易遵守项目风格，而不是每次靠猜。 第五步，建立索引和路由。 已有项目通常最缺的不是内容，而是入口。AI 不知道从哪里读起，人类也不一定清楚哪个文件代表最新状态。通过 AGENTS.md 或目录索引，可以建立清晰路由：项目总览在哪里，最终成果在哪里，素材在哪里，历史版本在哪里，哪些文件不要动。 第六步，设计后续任务流程。 反向整理完成后，才适合进入具体任务：续写、重构、审校、开发新功能、整理资料、生成发布稿。此时 AI 已经不是面对一堆陌生文件，而是面对一个有背景、有规则、有路由的工作区。 反向 ACW 化尤其适合几类场景。 第一...

第七章：任务流程：从一句需求到可验收产物 ACW 不只是静态目录，还需要任务流程。 没有流程时，AI 容易从一句需求直接跳到最终输出。对于小任务，这没有问题。你让它改一个错别字、优化一句标题、解释一个概念，直接回答就是最高效的做法。 但对于复杂任务，直接跳到最终输出往往会制造返工。 比如你说：“帮我写一本 1.5 万字的专业书。”如果 AI 立刻开始写正文，它可能会忽略读者定位、章节结构、术语边界、已有材料、最终文件位置。等正文写完，你再发现方向不对，成本就很高。 一个更稳的流程是： raw-input → requirements → structure → writing-spec → drafting → review → submission 这条链路来自写作场景，但可以迁移到很多领域。 raw-input 保存原始输入。 原始输入很重要，因为它保留了用户最初怎么说。整理后的需求可能更清楚，但也可能丢失语气、重点和限制。保存原始输入，可以在后续发生争议时回看源头。 在写作任务中，raw-input 可以是用户需求、素材、直播文本、参考目录说明。软件任务中，它可以是 issue、报错日志、需求描述、用户反馈。咨询任务中，它可以是客户访谈记录和原始资料。 requirements 提炼任务要求。 它回答：这次到底要做什么？目标是什么？读者是谁？字数范围是多少？验收标准是什么？事实边界在哪里？哪些问题必须确认？ 需求提炼的价值，是把一句自然语言请求变成可执行任务。很多 AI 输出失败，不是写作能力不足，而是需求没有被拆清楚。 structure 设计结构。 写书要目录，写文章要论证路径，写软件要模块设计，做研究要分析框架。结构阶段的目标，是先确定骨架，再进入生产。 结构不是为了拖慢速度，而是为了让人类能用更低成本检查方向。你审一份目录，比审一万字正文容易得多。你审一个接口设计，比审几千行代码容易得多。 writing-spec 或执行规格，定义如何写、如何做。 这里包括语气、格式、术语、素材使用、禁区、目标文件、质量标准。对于软件任务，它可以叫 implementation spec，写明修改范围、技术方案、测试要求和兼容性边界。 规格的价值，是把“我大概知道要什么”变成“AI 可以按这个标准执行”。 drafti...

第六章：真正值得沉淀的，是高质量中间产物 很多人使用 AI 时，只盯着最终答案。 写文章，就看最后那篇文章。做视频，就看最后的视频。写代码，就看最后的代码。做方案，就看最后的 PPT 或文档。 最终产物当然重要。没有最终产物，协作就没有交付。但在 AI 工程里，真正值得长期沉淀的，往往不只是最终产物，而是驱动最终产物生成的高质量中间产物。 这句话需要仔细区分。 按当前 ACW 设定，最终产物应该进入 projects/ 。书稿、代码、方案、项目文件、视频脚本的最终版本，都属于具体项目。 artifacts/ 不应该取代 projects/ 。 但从工程价值看，很多时候最能复用、最能降低成本的，是中间产物：摘要、执行大纲、结构设计、生成指令、检查清单、审校报告、评估标准、修订决策。 为什么？ 因为 AI 的最终输出可以重新生成，但高质量的中间产物会持续影响生成质量。 以写作为例。如果你直接让 AI 写一篇一万字的文章，它可能写得很快，但你很难控制方向。一旦发现问题，修改成本很高。更好的方式是先写两百字摘要，确认主题和角度；再写一千字执行大纲，确认结构和论证；再逐章写正文；最后做审校和修订。 这个过程里，摘要和执行大纲就是关键中间产物。 它们不是最终正文，却比一版失控的长文更有价值。因为人类可以用很低的成本审查它们，一旦上游方向正确，下游正文跑偏的概率就会降低。 视频生成也是一样。最终视频可能由模型生成，但真正值得打磨的是镜头描述、风格约束、角色一致性说明、分镜脚本、负面提示、质量检查标准。这些指令越稳定，后续生成越可控。 软件开发中，中间产物包括需求拆解、影响范围分析、接口约定、测试计划、迁移方案、审查清单。AI 写代码之前，如果没有这些中间产物，很容易只解决表面问题，留下架构或边界风险。 咨询方案中，中间产物包括客户背景摘要、问题树、假设清单、资料来源、决策矩阵、风险表。最终方案只是结果，真正体现专业能力的是这些推理和组织过程。 ACW 要做的，就是给这些中间产物一个稳定位置。 通常它们应该进入 artifacts/ 。一次任务一个 artifact，里面保留原始输入、需求、结构、规格、草稿说明、审校报告。这样做有几个好处。 第一，可追溯。 你可以知道某个最终结果为什么这样写。半年后回看，不必猜当时的决策依据。 第二，可接续。...

写在前面：我们为什么要给它起名叫 ACW 过去几年，很多人学习 AI 的入口都是 Prompt。 这并不奇怪。Prompt 是最容易被看见的部分：你输入一句话，AI 返回一段答案；你把话说得更清楚，答案就更接近你想要的样子。于是大量教程开始教人如何写角色、写背景、写步骤、写示例、写输出格式。对刚开始使用 AI 的人来说，这些方法确实有效。 但只要任务稍微变长，Prompt 的边界就会立刻出现。 你让 AI 帮你写一篇短文，它可以完成。你让它长期写一本书，记住前后设定、保留风格、维护目录、记录每次修改原因、根据审校意见反复迭代，它就很容易开始混乱。你让 AI 修改一个函数，它可以完成。你让它理解整个工程的架构、遵守团队规范、知道哪些文件能改、哪些文件不能动、测试如何运行、上线风险在哪里，单条 Prompt 就不够了。 问题不在于 Prompt 没用。问题在于 Prompt 主要解决的是“一次表达”，而很多真正有价值的任务需要的是“长期协作”。 长期协作需要环境。它需要稳定背景、明确规则、可追溯过程、可验证结果，也需要一个地方承载最终成果。对人类团队来说，这些东西很自然：我们会有项目目录、需求文档、会议纪要、代码规范、设计稿、测试报告、版本记录。可是当我们使用 AI 时，很多人又退回到最原始的方式：打开一个聊天框，把所有东西塞进一段话里，然后希望 AI 立刻接住全部复杂度。 这就是本书要讨论的问题。 我们需要把 AI 协作从“会写 Prompt”，升级到“会搭工作区”。这个工作区不是为了好看，不是为了把文件夹分得很整齐，而是为了让 AI 能够按工程方式管理上下文：知道从哪里读背景，从哪里找规则，把过程产物放在哪里，把最终成果放在哪里，什么时候该停下来确认，什么时候可以自主执行，做错了以后如何把错误沉淀成下一次不会再犯的规则。 老外喜欢造词，我们也来。这个东西以后就叫 AI Context Workspace ，简称 ACW 。 ACW 不是某个软件的专属功能，也不是某个模型的隐藏技巧。它是一种组织 AI 协作的方法：把上下文、规则、流程、产物和验证标准放进一个可持续演化的工作空间里。你可以把它用于写作、软件开发、研究、运营、咨询、个人知识管理，也可以用于团队内部的复杂项目。 这本书不会把 ACW 讲成一种神秘框架。相反，我们会从一个非常小的实验开始...

AI Context Workspace 博客系列索引 母版书稿：[[../AI 上下文工作区 ACW]] 阅读顺序 顺序 文章 说明 01 [[001 写在前面：我们为什么要给它起名叫 ACW 写在前面：我们为什么要给它起名叫 ACW]] 02 [[002 先做一个上下文实验 第一章：先做一个上下文实验]] 03 [[003 Prompt 解决一次表达，ACW 解决长期协作 第二章：Prompt 解决一次表达，ACW 解决长期协作]] 04 [[004 一个最小可用工作区 第三章：一个最小可用工作区]] 05 [[005 入口文件不是垃圾桶 第四章：入口文件不是垃圾桶]] 06 [[006 conventions 为什么是中后期最重要的目录 第五章： conventions/ 为什么是中后期最重要的目录]] 07 [[007 真正值得沉淀的，是高质量中间产物 第六章：真正值得沉淀的，是高质量中间产物]] 08 [[008 任务流程：从一句需求到可验收产物 第七章：任务流程：从一句需求到可验收产物]] 09 [[009 从写作工作区看通用结构 第八章：从写作工作区看通用结构]] 10 [[010 把已有项目反向 ACW 化 第九章：把已有项目反向 ACW 化]] 11 [[011 常见错误与演进路线 第十章：常见错误与演进路线]] 12 [[012 尾声：从说清楚，到沉淀清楚 尾声：从说清楚，到沉淀清楚]]

AI Context Workspace：把 AI 协作从 Prompt 升级为工程结构 写在前面：我们为什么要给它起名叫 ACW 过去几年，很多人学习 AI 的入口都是 Prompt。 这并不奇怪。Prompt 是最容易被看见的部分：你输入一句话，AI 返回一段答案；你把话说得更清楚，答案就更接近你想要的样子。于是大量教程开始教人如何写角色、写背景、写步骤、写示例、写输出格式。对刚开始使用 AI 的人来说，这些方法确实有效。 但只要任务稍微变长，Prompt 的边界就会立刻出现。 你让 AI 帮你写一篇短文，它可以完成。你让它长期写一本书，记住前后设定、保留风格、维护目录、记录每次修改原因、根据审校意见反复迭代，它就很容易开始混乱。你让 AI 修改一个函数，它可以完成。你让它理解整个工程的架构、遵守团队规范、知道哪些文件能改、哪些文件不能动、测试如何运行、上线风险在哪里，单条 Prompt 就不够了。 问题不在于 Prompt 没用。问题在于 Prompt 主要解决的是“一次表达”，而很多真正有价值的任务需要的是“长期协作”。 长期协作需要环境。它需要稳定背景、明确规则、可追溯过程、可验证结果，也需要一个地方承载最终成果。对人类团队来说，这些东西很自然：我们会有项目目录、需求文档、会议纪要、代码规范、设计稿、测试报告、版本记录。可是当我们使用 AI 时，很多人又退回到最原始的方式：打开一个聊天框，把所有东西塞进一段话里，然后希望 AI 立刻接住全部复杂度。 这就是本书要讨论的问题。 我们需要把 AI 协作从“会写 Prompt”，升级到“会搭工作区”。这个工作区不是为了好看，不是为了把文件夹分得很整齐，而是为了让 AI 能够按工程方式管理上下文：知道从哪里读背景，从哪里找规则，把过程产物放在哪里，把最终成果放在哪里，什么时候该停下来确认，什么时候可以自主执行，做错了以后如何把错误沉淀成下一次不会再犯的规则。 老外喜欢造词，我们也来。这个东西以后就叫 AI Context Workspace ，简称 ACW 。 ACW 不是某个软件的专属功能，也不是某个模型的隐藏技巧。它是一种组织 AI 协作的方法：把上下文、规则、流程、产物和验证标准放进一个可持续演化的工作空间里。你可以把它用于写作、软件开发、研究、运营、咨询、个人知识管理，也可以用于团队内...

LikeGame MVP 开发需求 一、产品定位 LikeGame 是一个通过组合技能创建 AI Agent，并让 Agent 在标准化工作区中完成真实工作的桌面平台。 它借用游戏职业的概念解释 Agent：基础模型相当于没有职业的初始角色，装载不同技能后形成不同职业，从而完成不同类型的工作。 核心模型只保留三层： 原子 → 技能 → 职业（Agent） 原子 ： references 、 assets 、 scripts 等基础资源。 技能 ：多个原子组成的一项完整能力。 职业（Agent） ：多个技能组成的工作角色。 职业决定 Agent 会什么，工作区决定 Agent 面对什么背景、遵循什么规则、处理什么项目。 二、核心流程 创建或选择职业 → 选择需要装载的技能 → 下载 AI Native 工作区模板 → 添加背景、规范和项目资料 → AI 初始化并梳理整个工作区 → 生成工作区图谱 → 进入正式工作 三、资源模型 3.1 原子 原子是构建技能的最小资源，MVP 支持： references ：知识、说明和参考资料。 assets ：模板、图片、示例和其他静态资源。 scripts ：可被 AI 调用的本地脚本。 3.2 技能 技能遵循 Agent Skills 规范 ，以独立目录保存。每个技能必须包含 SKILL.md ，并可以按需包含 references/ 、 assets/ 和 scripts/ 。 3.3 职业 职业就是 Agent 配置，由一个或多个技能组成。MVP 支持创建、编辑、复制和删除职业，不引入等级、队伍或多 Agent 编排。 四、工作区模板 工作区不由 LikeGame 自行生成，直接使用 kvker/ai-native-template 作为基础模板。 创建工作区时执行以下流程： 从 GitHub 下载模板默认分支 main 的归档文件。 解压到用户选择的本地目录，不保留模板仓库的 .git 信息。 将用户选择的职业和技能写入模板工作区。 将用户导入的项目或资料放入 projects/{工作单元}/ 。 调用 OpenCode SDK 启动模板自带的 /an-init 初始化能力。 初始化成功后才能进入正式工作台。 每个工作区需要记录模板仓...

从 gpt-5.5 (xhigh) 到 gpt-5.6-sol (xhigh) 版本：v1.0 ｜ 适用对象：研发 / 算法 / 平台工程团队 ｜ 用途：内部迁移落地 基线设定：当前生产环境统一使用 gpt-5.5 ，推理强度 reasoning.effort = xhigh ；目标： gpt-5.6-sol ，推理强度保持 xhigh 。 1. 核心结论 在保持 xhigh 不变的前提下，GPT-5.6 通常能 维持甚至提升质量，同时消耗更少 token 。风险主要来自"行为变化"而非"能力退步"——模型更主动、更简洁、更会推断意图，因此原有提示中的冗余指令可能失效或产生副作用。 维度 gpt-5.5 (xhigh) gpt-5.6-sol (xhigh) 对团队的意义 推理强度 xhigh xhigh（同档） 无需重新调参找基线 Token 效率 基准 同等质量下更省 直接降本 前端美学 一般 布局/层级/设计判断更强 生成页面可用性提升 意图理解 需逐步指令 能从上下文推断目标 提示可更精简 新能力 无 PTC / 多智能体 / 显式缓存 / 持久化推理 / pro / max 按场景选开 ⚠️ 关于数字：文档给出的是 提示精简 带来的实测区间（评测分 +10~15%、token −41~66%、成本 −33~67%），并非模型切换本身的固定收益。案例中的具体数值为 示意值 ，请以你团队在代表性任务上的 A/B 评测为准。 2. 模型与命名变化（必读） GPT-5.6 引入新命名方案，避免团队误用： gpt-5.6 → 别名，路由到 gpt-5.6-sol（旗舰） gpt-5.6-sol → 本次迁移目标：旗舰能力 gpt-5.6-terra → 智能/成本平衡（后续降本可选） gpt-5.6-luna → 高吞吐、低成本（批量任务可选） 团队落地规则 ：生产环境统一写 gpt-5.6-sol （不要写别名 gpt-5.6 ，便于审计与回滚）；待压测通过后，对成本敏感链路再评估 terra 。 3. 迁移路线图 以下逐项摘自官方指南 ...