AI 时代，真正重要的不是产物，而是生成产物的系统

关联文档：[[acw/blog/004 一个最小可用工作区|一个最小可用工作区]]、[[acw/blog/007 真正值得沉淀的，是高质量中间产物|真正值得沉淀的，是高质量中间产物]]

最终产物只是一次结果

过去做一件事，我们最关心的是最终产物。产物当然重要，因为它直接解决问题，也决定一次任务有没有完成。

但进入 AI 时代后，我越来越确定：更值得长期积累的，是那套能够持续生成产物的系统。它可能是一组指令、一套规范，也可能是一个组织良好的工作区。

最终产物解决的是“这一次交付什么”，生成系统解决的是“下一次能否更快、更稳定地交付”。前者创造当下价值，后者决定价值能否复利。

如果一篇文章只能依靠漫长对话偶然写出来，那么换一个对话、换一个模型，许多背景和判断都要重新解释。相反，如果选题定位、读者画像、写作规范和审校标准都已经沉淀，文章就不再是一次性的答案，而是一个可重复运行过程的结果。

以软件开发为例。过去我们创建一个 my-code/ 目录，把源码、配置、测试和构建脚本放进去。现在常见的做法，是让 AI 直接进入这个目录阅读和修改代码。更进一步，有人会添加 docs/ 或 ai/，专门保存需求、提示词和沟通记录。

这种方式能工作，但 AI 所需的上下文仍是附属信息。面对大量源码和工具配置，它未必能立即判断：项目为什么存在，当前目标是什么，哪些规则必须遵守，以及这次任务应该如何验收。

问题不在于 AI “看不懂代码”，而在于代码只能描述系统现在如何运行，不能完整解释系统为什么这样设计。许多关键知识散落在人的记忆、聊天记录和历史决策中。AI 能读取文件，却无法自动补全这些缺失的上下文。

因此，AI Native 并不是多建一个 ai/ 目录，而是重新安排信息的主次关系：先让 AI 获得完成任务所需的背景、规则和路径，再让它按需进入代码或其他项目文件执行工作。

Markdown 很适合承载这类信息，并不是因为 AI 对某种格式有偏好，而是因为它结构清楚、成本低、容易检索和版本管理，也能同时被人和机器阅读。真正重要的不是文件后缀，而是信息是否被明确分类、建立入口并持续维护。

一个最小工作区可以这样组织：

AGENTS.md
background/
conventions/
artifacts/
projects/

AGENTS.md 是入口和路由，告诉 AI 这里是什么、不同信息放在哪里，以及执行任务前应该读取什么。

background/ 保存相对稳定的事实和领域知识，conventions/ 保存长期有效的规则、标准与流程，artifacts/ 保存一次任务中的需求、方案、决策和审查记录，projects/ 则承载代码、文章、视频等最终成果。

这套结构的重点不是目录名称，而是职责分离。背景不能混进规则，草稿不能冒充最终版本，临时讨论也不能和长期结论拥有相同权重。明确区分信息的类型和有效性，AI 才能在有限上下文中优先读取重要内容。

把工作区改成 AI 优先，并不意味着代码或最终产物沦为次要资产。没有可靠的代码，软件无法运行；没有合格的成稿，内容无法交付。真正发生变化的是：代码不再是工程知识的唯一中心，最终产物也不再是唯一值得保存的结果。

需求如何形成，约束从何而来，方案为什么被选择，任务如何验收，这些过去依赖人脑维持的信息，现在必须成为显式资产。它们决定 AI 能否理解现状、延续决策并稳定复现结果。

判断一份内容是否值得沉淀，可以看三个问题：它能否帮助下一次任务减少重复说明，能否解释当前结果为何如此，能否让另一个人或 AI 接手后继续工作。如果答案都是肯定的，它就不应该只留在聊天记录里。

AI 大幅降低了生成成本，也让单次产物更容易被替换。今天生成的代码、文案和页面，明天可能被更好的版本覆盖。但经过验证的背景、规则、流程、评价标准和决策记录，会持续影响之后的每一次生成。

所以，AI 时代真正重要的，不是把每一个结果都保存下来，而是建立一套能稳定产生好结果的系统。产物负责证明这次任务完成了，工作区负责确保下一次不会从零开始。

当这套系统能够被读取、执行、修正和复用时，AI 才不只是一个临时工具，而会成为长期协作关系中的一部分。