这段时间，我在做一个公司信息化建设里的基础数据项目：搭建统一的采购材料库。
这个材料库不是简单的“采购物资清单”，而是要把公司历史上分散在不同部门、不同表格、不同项目里的物料数据，重新整理成一套可以长期使用的标准底库。
原始数据横跨机械、材料、后勤、行政等多个场景，存量记录有几万条。里面既有钢材、水泥、管件，也有车辆、机械配件、办公用品、生活物资；同一种东西可能有不同叫法，不同部门可能使用不同单位，名称和规格还经常混在同一个单元格里。
有些数据看起来只差一个括号、一个型号、一个单位，但实际上可能代表完全不同的物料；有些记录看起来不同，清洗以后又会发现其实是同一个东西。
最终要完成的，不只是“把数据合并”。
而是要把这些历史数据经过清洗、拆分、去重、标准化、分类、人工复核以后，整理成一套能够真正进入信息化系统长期使用的材料数据库。
这个项目我主要借助 DSH 这样的 Agent 来推进。
我原本认为，这类项目其实非常适合 Agent。
它可以同时读取很多 Excel，可以批量处理，可以写脚本，可以做分类，可以对规则进行反复检查，还可以通过 Git 保留每一次修改过程。
一开始，效果也确实非常好。
直到项目越做越深，我才慢慢发现：
我对 Agent 的能力边界，产生了一个很自然、但并不准确的理解。
一、AI 最危险的时候，不一定是它算错了
整个项目其实并不是没有治理。
从比较早的时候开始，我就已经建立了 Git、基线文件、专项审计、人工确认、会议结论等机制。
按照我过去做软件项目的经验，这套管理方式已经不算松。
但随着数据不断被清洗、分类、修订，还是开始出现一些很奇怪的问题。
昨天已经确认修掉的错误，今天又重新进入人工复核表；
会议中已经确认的名称和规格，没有完整进入最终 Demo；
不同阶段生成的文件，被重新组合以后，又形成了一个新的“当前结论”。
最典型的一次，是 AI 给了我一个非常完整的汇总：
当前只剩 40 多项遗留问题。
这个结果看起来没有任何异常。
有问题分类，有数量统计，有表格，还有处理建议。
如果只看这份报告，很容易产生一种感觉：
项目已经基本收口了。
但继续往下追以后，我才发现，其中一个所谓的“一级分类为空”，背后其实对应了 263 条不同的底层记录。
继续展开以后，真正需要进入人工复核范围的记录变成了 311 条。
这里其实不能简单说 AI 算错了。
“40 多项”可能是在统计问题类型；
“311 条”统计的则是受影响的底层记录；
而真正需要多少次人工独立判断，又可能是第三个数字。
问题出在：
我没有在任务开始时把统计粒度定义清楚。
而 AI 非常认真地完成了它所理解的那个任务。
这件事情对我的冲击反而比一次明显算错更大。
因为明显错误很好发现。
真正危险的是：
AI 在一个不够准确的问题定义下，生成了一个非常完整、非常专业、甚至逻辑完全闭合的结果。
如果人看到“40 多项”以后就停止追问，这个结果完全可能以“已完成”的状态进入下一阶段。
所以后来我开始养成一个习惯。
看到 AI 给出的数字，不再首先问：
“算得对不对？”
而是先问：
这个数字到底在数什么？
二、working 文件夹让我第一次真正理解“数据血缘”
这次让我印象最深的，其实还不是数字问题。
而是项目里的一个普通文件夹：
working
项目刚开始时，我把它理解成一个很正常的工作目录。
AI 需要生成一些临时成果，就放进去。
随着工作推进，里面逐渐出现了各种文件：
原始清洗表、
专项分析表、
会议前版本、
会议后版本、
修正版、
审计表、
人工复核表、
补执行版、
内部验证版。
刚开始我并不觉得这是问题。
因为我的潜意识里一直有一个假设：
这些文件既然都是 DSH 在项目过程中生成的，它应该知道它们之间是什么关系。
哪一个是旧版本；
哪一个已经被替代；
哪一个只是审计文件；
哪一个才是当前最新的数据源。
后来我发现，这其实是我自己的想象。
对于我来说，这些文件组成了一段有连续性的项目历史。
我知道昨天下午为什么生成这个表，晚上为什么又修了另一版，也知道哪次会议推翻了此前的一个结论。
但如果项目没有把这些关系显式记录下来，那么对 Agent 来说，这些文件首先只是：
一组现在可以读取的文件。
文件名、修改时间、Git 历史都能提供线索。
但线索不等于关系。
Git 可以告诉它：
某个文件什么时候被修改；
哪个 commit 增加了哪些内容。
但 Git 并不会自动告诉它：
这个文件现在已经失去业务效力；
那个表只能用于追溯，不能再次参与生成；
这次人工会议已经覆盖了此前的 AI 分类；
Demo 必须从哪一个唯一基线继续派生。
于是项目里真正发生了一次“双链分叉”。
一条链里，会议确认后的数据已经继续修正；
另一条链里，Demo 数据却还在沿着旧基线继续往后生成。
两条链都能正常工作。
两边的文件也都是真实的。
甚至两边的 Git 都没有问题。
但它们已经不属于同一个“现在”。
最后就出现了一个很荒诞的现象：
昨天已经处理掉的问题，今天又重新被 AI 当成待处理问题。
这件事让我第一次真正理解：
文件存在，不等于关系存在。
版本存在，也不等于血缘存在。
如果没有显式定义来源、继承、替代和失效关系，一个越来越大的工作目录，最后很容易变成一个“数据沼泽”。
里面所有东西都可能是真的。
但你已经不知道：
哪一个真，才是当前应该相信的真。
三、我把“Agent 能连续执行”，误认为了“Agent 会连续治理”
这其实是我这次最核心的误解。
过去我一直认为，DSH 已经不是普通聊天机器人了。
它是 Agent。
它可以读文件、写文件、执行命令、运行脚本、检查 Git、连续完成多步任务。
所以我自然会觉得：
既然它拥有这么强的项目操作能力，那么它应该也会自然维护项目状态。
现在看，这两件事情并不是一回事。
Agent 能连续执行任务，并不等于它会自动维护项目级的强一致状态。
它可以根据文件名、内容、时间和上下文，推断哪份文件最可能是最新版本。
但“推断最新”与“项目已经正式定义唯一事实源”，完全是两个概念。
它可以记得此前的一些结论。
但“有记忆”也不等于“当前状态已经被严格维护”。
它可以读取 Git。
但 Git 解决的是版本历史，不是业务效力。
这也是为什么我现在觉得，简单说“AI 会忘”其实不够准确。
这次真正暴露的，更像是：
我把记忆，当成了状态管理。
又把：
自主执行，当成了自主治理。
我之前潜意识里把 Agent 想成了一个长期连续工作的工程团队。
昨天做过什么，今天自然知道；
昨天废弃什么，今天自然不会再使用；
昨天确认的规则，今天自然会继续继承。
但实际上，如果这些关系没有在项目结构中被明确记录，Agent 仍然要重新判断。
而只要需要重新判断，就存在重新解释的空间。
所以现在我会把这个区别记得非常清楚：
Agent 负责执行连续性。
项目结构负责状态连续性。
这两件事不能混为一谈。
四、数据项目也要尽早建立“基本法”
这次还有一个让我重新认识的问题，就是我一直习惯使用的“基本法”。
过去在做软件项目时，我通常会在项目已经比较成熟以后，专门整理一份基本规则。
例如：
哪些架构不能随便改变；
哪些规则优先级最高；
哪些结论已经冻结；
哪些临时需求不能推翻全局设计。
以前我一直认为，这套东西主要是为了防止软件开发后期跑偏。
这次才发现：
复杂的数据分析、数据清洗、数据整合项目，其实更需要，而且应该更早建立。
因为数据项目最容易出现的不是代码突然坏掉。
而是：
规则一点一点变化。
比如材料数据库里，很多事情刚开始都可以探索：
什么算重复；
名称怎么标准化；
名称和规格如何拆分；
单位不同是不是同一物料；
包装不同是不是不同 SKU；
分类冲突时谁优先。
前几轮探索本身没有问题。
问题是，一旦这些规则逐渐稳定，就应该立即从聊天记录、专项报告和临时提示词里抽出来。
把它正式写成项目规则。
否则随着项目继续推进，人和 AI 都会越来越容易受局部问题影响。
某一次遇到特殊案例，临时修改了一条判断逻辑；
下一轮 AI 看到这次修改，又可能把它理解成新的全局规则；
过几轮以后，人自己也已经记不清：
这到底是一个例外，还是正式规则已经改变。
项目往往不是某一天突然彻底错误。
更多时候，是在很多次“看起来都合理”的微调里一点点漂移。
所以以后我会把这类数据项目明确分成两个阶段：
前期允许探索。
主要口径稳定以后，立即立法。
而且规则本身也要版本化。
以后每一次 AI 执行，都应该能明确回答：
当前使用的是哪一版数据；
哪一版规则；
人工结论与 AI 判断冲突时谁优先；
这一次临时处理是否允许改变全局规则。
五、以后同类项目，开工时先把这些词写死
后来我把这次问题重新整理了一遍。
其实最终只需要管理好两件事情。
第一件事是：
什么是当前事实。
这依靠数据血缘、当前基线、唯一事实源和版本替代关系。
第二件事是：
按照什么规则解释当前事实。
这依靠基本法、规则版本、规则优先级和人工确认。
两者缺一个都不行。
只有规则，没有血缘，可能拿着正确规则处理旧版本数据。
只有血缘，没有规则，又可能拿着正确数据不断改变解释口径。
所以以后再做类似的材料库、数据库清洗、历史数据整合、主数据治理项目，我不会再等问题出现以后补治理。
开工时就要提前把一组关键词写进项目结构：
唯一事实源（SSOT）
数据血缘（Lineage）
当前基线（Canonical Baseline）
派生关系（Derived From）
替代关系（Superseded By）
废弃状态（Deprecated）
输入白名单（Allowed Inputs）
规则版本（Rule Version）
规则优先级（Priority）
人工确认覆盖（Human Override）
例外边界（Exception Scope）
人工复核粒度（Review Granularity）
这些概念不一定都要做成复杂系统。
甚至第一版完全可以只是一个清晰的目录、一份 manifest、一份规则文件和几个强制字段。
重要的不是形式。
而是：
不能再把这些关系留给 Agent 自己猜。
回头看，这次真正的问题并不是 DSH 本身做错了什么。
相反，它完成了大量过去可能需要人工花很多天才能完成的事情。
问题在于，我因为它已经是 Agent，就无意中又往前多推了一步：
我以为它既然能够自主工作，就自然会维护整个项目的秩序。
这次之后，我不会再这样理解 Agent。
对我来说，今后这类项目有三句话应该在第一天就写下来：
Agent 负责执行，不等于负责治理。
记忆不等于状态，Git 不等于血缘。
先定义什么是真的，再定义按什么规则处理，最后才让 AI 去做。
这可能才是我这次材料数据库项目真正留下来的东西。