发表于 | 分类于

Harness不是测试工具，而是开发控制面

如果把 Harness 只理解成测试工具，就会错过它最有价值的部分。

测试工具回答的是：这段代码在给定条件下会不会按预期运行。开发 Harness 回答的是：这个任务从被提出到被交付，中间每一步有没有失真、有没有越界、有没有证据、有没有停损点。

测试工具通常包住代码。开发 Harness 包住过程。

一、Test Harness 给我们的启发

一个好的 test harness 会做几件事：

  • 准备被测对象。
  • 构造输入。
  • 替换外部依赖。
  • 控制时间、网络、数据库、文件系统等不稳定因素。
  • 执行动作。
  • 观察输出。
  • 断言结果。
  • 清理环境。

它真正重要的地方，不是“测试”这个词，而是“可控环境”。

没有 Harness 时，代码跑在真实世界里，依赖太多，状态太乱，失败难以复现。有了 Harness，代码被放进一个小型控制舱：输入可知、依赖可知、输出可测。

这件事可以迁移到整个开发过程。

一个需求也是被测对象。它进入开发系统时，天然带着模糊、噪声和缺口。如果不把它放进 Harness，它会在每个阶段变形。最后你得到的不是“解决了问题的代码”，而是“根据一串未验证假设生成的代码”。

二、开发 Harness 控制五件事

开发 Harness 至少有五个控制点。

第一，方向。

方向由 Mode、问题定义、In Scope、Out of Scope 控制。它解决的是“我们到底在做什么”。如果方向没控住，后面所有努力都可能是在加速偏离。

第二，事实。

事实由 Research 控制。它解决的是“我们凭什么这么判断”。开发中最危险的不是未知，而是把未知伪装成已知。Research 要把 Facts、Assumptions、Unknowns 分开。

第三，设计边界。

设计边界由需求、技术设计和实施计划控制。它解决的是“允许怎样改，不允许怎样改”。这里要明确状态流、接口契约、错误态、回滚、监控、验证方式和停损点。

第四，执行。

执行由任务切片、文件边界、测试先行、diff review 控制。它解决的是“怎么保证改动没有偷偷扩大”。AI 参与时尤其重要，因为 AI 很容易把“顺手”变成“已经改了”。

第五，证据。

证据由测试计划、review finding、验收记录、发布报告和复盘控制。它解决的是“我们怎么知道这次真的完成了”。没有证据，完成只是情绪。

三、为什么只靠测试不够

测试很重要，但测试不能替代开发 Harness。

测试通常发生在实现之后。它可以告诉你代码行为是否符合某个预期，但它不一定告诉你预期是否正确。如果问题定义错了，测试越全，越稳定地证明一个错误目标被实现了。

测试通常覆盖代码路径，但不一定覆盖任务边界。一个功能测试通过了，不代表这次没有顺手改坏别的契约。

测试通常验证可观察行为，但不一定验证运维后果。代码能跑，不代表日志足够、指标足够、回滚可行、失败能被发现。

测试通常对付明确输入，但开发失控常常来自隐含输入：一句模糊需求、一个不完整上下文、一段 AI 自行补全的假设。

所以测试是 Harness 的一部分，但不是全部。

更准确地说：

测试 Harness 控制代码运行环境；开发 Harness 控制代码产生过程。

四、一个简单例子

假设任务是：“把文章导出功能优化一下，最近偶尔失败。”

没有开发 Harness 的过程可能是：

  1. 搜索 export。
  2. 看到异常日志。
  3. 猜测是超时。
  4. 增加重试。
  5. 补一个成功导出的测试。
  6. 写结论：已优化。

这个过程很快，但风险很多。

“偶尔失败”到底是什么失败？是生成失败、上传失败、权限失败、任务队列失败、文件过大失败，还是前端轮询超时？

“优化”是什么意思？降低失败率、缩短耗时、改善错误提示、增加重试、增强幂等、补偿历史失败任务，还是增加可观测性？

“增加重试”会不会导致重复导出？会不会重复扣额度？会不会把不可重试错误重试三次？会不会隐藏真正的权限问题？

如果这些都没问，测试成功也只能证明一个很窄的成功路径。

同一个任务放进开发 Harness，过程会变成：

  1. Mode：Hold，只修复和硬化导出失败，不扩展新导出格式。
  2. Research：列出现有导出链路、失败日志、触发条件、相关文件、已有测试。
  3. Problem Framing：确认问题是“导出任务在上传成功但状态写回失败时，会被用户看到为失败且无法恢复”。
  4. Technical Design：设计幂等 key、状态机、错误分类、日志指标、回滚方式。
  5. Implementation Plan：分阶段改状态机、补测试、补指标。
  6. Execution：只改批准文件。
  7. Review：按 happy、nil、empty、error 检查。
  8. Test Plan：记录每条验证命令和证据。
  9. Acceptance：明确剩余风险和是否可发布。

这不是慢。这是把“快但可能错”改成“每一步都知道为什么”。

五、Harness 的几个误区

第一个误区：Harness 等于更多文档。

坏文档确实会拖慢开发。但 Harness 的目标不是写更多字，而是让关键信息不丢。一个好的问题定义可能只有半页，但它能阻止三天偏航。一个好的测试证据台账可能只有一张表，但它能让上线后的复盘有抓手。

第二个误区：Harness 只适合大项目。

小任务更需要轻量 Harness。因为小任务最容易让人觉得“这点事直接改就行”。很多事故不是大项目造成的，而是小改动没有边界、没有测试、没有 review。

第三个误区：AI 可以替代 Harness。

AI 可以帮你生成 Harness 文档，但不能替你决定边界。AI 可以帮你补测试，但不能替你判断哪些风险值得覆盖。AI 可以帮你 review，但如果你没要求它按四路径 review，它很可能给你一段温顺的总结。

第四个误区：Harness 会压制创造力。

真正压制创造力的是混乱。因为混乱会让所有精力都耗在补洞、解释、返工和救火上。Harness 把基本控制面固定住，反而释放了更多思考空间。

六、最小形态

如果一个任务很小，不需要完整文档链，也至少保留最小 Harness：

1
2
3
4
5
6
7
8
9
Mode:
In Scope:
Out of Scope:
Facts:
Assumptions:
Plan:
Validation:
Review Paths:
Residual Risk:

这些字段看起来普通，但它们分别控制不同失控点：

  • Mode 控制变化方向。
  • In Scope 控制本次要做什么。
  • Out of Scope 控制本次不做什么。
  • Facts 控制证据。
  • Assumptions 防止猜测伪装成事实。
  • Plan 控制执行顺序。
  • Validation 控制完成证据。
  • Review Paths 控制边界路径。
  • Residual Risk 控制诚实收尾。

任务变大时，把它展开成完整流程。任务变小时，把它压缩成这几个字段。

Harness 不是仪式，它是可伸缩的控制面。

发表于 | 分类于

从混乱到可控：AI时代代码开发为什么需要Harness

AI 编程最容易让人兴奋的地方，是它让代码来得太快。

你说一句“帮我把这个功能补上”，它就开始读文件、改代码、写测试、解释方案。以前一个下午才能推进的事，现在像被压缩进十几分钟。这个变化当然重要。但越用到后面，我越觉得真正的问题不是速度，而是控制。

代码来得太快以后，新的问题会出现：需求还没钉住，代码已经写完；边界还没说清，重构已经发生；测试只跑了成功路径，结论已经写成“完成”；AI 把不确定的猜测补成了流畅的解释，人看着也觉得合理。

这不是 AI 的问题。这是开发过程没有 Harness。

一、混乱不是从写代码开始的

很多人以为，开发混乱来自代码写得不好。

当然，代码会写坏。但更早的混乱，通常发生在代码之前。

一个需求往往是这样开始的：

“这个同步偶尔不对，帮我优化一下。”
“这个页面加载有点慢，修一下。”
“这个导出最近有失败，你看看。”
“让 AI 帮我把测试补齐。”

这些话听起来像任务，其实不是。它们只是问题的影子。

“同步不对”到底是数据丢了、状态没刷新、冲突没合并，还是 UI 没更新？
“加载慢”到底是接口慢、首屏慢、感知慢，还是空态判断错了？
“导出失败”到底是生成失败、上传失败、状态写回失败，还是用户重复点击造成多个任务？
“补测试”到底要覆盖主路径，还是要覆盖缺配置、空数据、异常和超时？

如果这些问题没有被拆开，开发就已经开始漂了。AI 只会让这种漂移跑得更快。

二、Harness 不是测试工具

很多人听到 Harness，会先想到 test harness。这个理解没有错，但太窄。

测试 Harness 是把代码放进一个可控环境里：准备输入，替换依赖，执行动作，观察输出，断言结果。它的核心不是测试两个字，而是可控条件。

我说的代码开发 Harness，是把整个开发过程放进可控条件里。

一个需求从想法到上线，中间会经过很多次转换：

  • 用户说的话，转换成问题定义。
  • 问题定义，转换成需求。
  • 需求，转换成设计。
  • 设计，转换成计划。
  • 计划，转换成代码。
  • 代码，转换成测试证据。
  • 测试证据，转换成验收结论。
  • 验收结论，转换成发布和复盘。

每一次转换都会丢信息，也会混入猜测。开发 Harness 的作用，就是在这些转换点放控制面，让信息不要随便变形。

所以，Harness 不是让开发变慢的流程。它是让开发在速度变快以后，仍然不失控的结构。

三、AI 时代最危险的是“合理的脑补”

AI 的强项和风险，常常是同一件事：它特别擅长补全。

上下文不完整，它会补。目标不清楚，它会补。边界没写，它会补。测试没覆盖，它也会补一段解释，让你觉得问题不大。

人也会脑补，但人脑补得慢。AI 脑补得快，而且语言很顺。顺到什么程度？顺到你会忘记它中间其实没有证据。

比如你说：“旧接口应该没人用了。”

你只是表达一个猜测。AI 可能在后面的设计里写成：“由于旧接口已无人使用，可以删除兼容逻辑。”

注意，中间那个“应该”消失了。一个假设，变成了事实。

开发 Harness 要做的第一件事，就是把 Fact、Assumption、Unknown 分开。

Fact 是有证据的事实。
Assumption 是当前暂时相信、但还没验证的假设。
Unknown 是还不知道的信息。

只要这三类东西混在一起，AI 越努力，风险越大。

四、真正的控制点是这些

一套实用的开发 Harness，至少要控制五件事。

第一，控制方向。

每个任务先判断它是 Expansion、Hold，还是 Reduction。

Expansion 是扩展能力。Hold 是不扩大范围，只修复、硬化、迁移、清理、提效。Reduction 是收缩范围、下线旧能力、降低复杂度。

为什么要先声明这个？因为不同方向的任务，评价标准完全不同。

如果一个任务是 Hold，却做着做着新增了三个用户可见能力，那就是越界。
如果一个任务是 Reduction，却加了一堆兼容层和配置项，那可能是假减法。
如果一个任务是 Expansion，却没有设计错误态、发布和回滚，那就是只扩能力不扩控制。

第二，控制范围。

每个任务都要写 In Scope 和 Out of Scope。

In Scope 说这次做什么。Out of Scope 更重要，它说这次不做什么。

开发失控，很多时候不是因为没人做事，而是因为太多人顺手做了相关但不属于这次的事。

第三，控制事实。

Research 阶段只做研究，不写方案。列出现有代码怎么做、已有测试覆盖什么、日志显示什么、哪些是猜测、还有哪个问题阻断。

这一步像刹车。不是为了停住，而是为了让后面的加速有方向。

第四，控制执行边界。

AI 写代码时，要明确允许改哪些文件、禁止改哪些文件、不能改变哪些契约、发现范围外问题时只记录不修。

不要指望一句“别改太多”能管住 AI。它需要明确边界。

第五，控制证据。

任务结束不能只写“测试通过”。要写清楚：跑了什么命令，验证了什么路径，输入是什么，输出是什么，哪些没测，剩余风险是什么。

没有证据的完成，只是一种情绪。

五、最小可用 Harness

如果任务很小，不一定要写完整文档。但至少可以保留这十行：

1
2
3
4
5
6
7
8
9
10
Mode:
Goal:
In Scope:
Out of Scope:
Facts:
Assumptions:
Unknowns:
Allowed Changes:
Forbidden Changes:
Validation:

这十行并不复杂，但它们分别挡住了不同的失控点。

Mode 挡住方向漂移。
In Scope 和 Out of Scope 挡住范围膨胀。
Facts、Assumptions、Unknowns 挡住脑补。
Allowed Changes 和 Forbidden Changes 挡住无关改动。
Validation 挡住没有证据的完成。

如果这十行写不出来，不要急着改代码。

六、这不是流程崇拜

我并不喜欢为了流程而流程。很多流程确实只是把人拖慢。

但 Harness 不是那种东西。它的价值不在于格式，而在于它能减少返工、误判和救火。

真正拖慢开发的，从来不是几行边界说明，而是这些事：

  • 做完才发现问题定义错了。
  • 测完才发现只测了成功路径。
  • 上线才发现缺配置。
  • 回滚时发现新数据旧代码不认识。
  • 复盘时发现证据散在聊天记录、终端和脑子里。

这些才贵。

Harness 的目标，是让每一次“我以为”，都变成可以检查、验证、回滚和复盘的东西。

七、AI 编程真正严肃的地方

AI 编程刚开始流行时，大家讨论最多的是效率：能不能快十倍，能不能少写代码，能不能一个人做一个团队的事。

这些都重要。但真正严肃的地方，是当代码生产能力变得很便宜以后，确定性变得更贵了。

你不再缺生成代码的能力。你缺的是判断这段代码该不该生成、生成到哪里停、怎么知道它对、出事怎么退、下次怎么不再犯同样的错。

换句话说，未来工程师越来越像在设计一个代码生产系统。

代码只是结果。Harness 才是让结果可靠地产生的那套控制面。

如果要用一句话总结：

AI 让开发跑得更快，Harness 让开发还能跑在路上。

发表于 | 分类于

happy-nil-empty-error：代码Review的四条路径

Review 最常见的失败，是把“看过了”误认为“审过了”。

看过 diff，不等于审过行为。总结改动，不等于发现风险。提了几个风格建议，不等于覆盖边界。说“整体没问题”，不等于系统真的安全。

好的 Review 不是礼貌地复述改动，而是主动寻找行为错误。

我现在最常用的最低基线，是四条路径：

1
2
3
4
happy
nil
empty
error

这四个词很朴素，但能抓住大量真实问题。

一、Happy：正常世界是否成立

Happy path 检查正常输入、正常权限、正常依赖下，主流程是否成立。

它要问：

  • 正常用户能不能完成操作？
  • 主流程是否返回正确结果？
  • 新旧调用方是否兼容？
  • 用户可见行为是否符合需求？
  • 成功路径是否有测试或人工验证？

Happy path 是最容易被测到的路径，也是最容易让人过早放心的路径。

一个导出功能正常生成文件，一个设置页正常保存选项，一个列表正常展示数据，这都只是说明系统在正常世界里能工作。

但真实世界不总是正常。

所以 happy path 是起点，不是终点。

二、Nil：缺失时会不会炸

Nil path 检查缺失。

缺用户、缺 token、缺配置、缺依赖、缺字段、缺缓存、缺 navigator、缺文件。很多线上问题，不是因为逻辑多复杂，而是因为你以为一定存在的东西不存在。

Nil path 要问：

  • nullable 字段是否处理？
  • 缺用户、缺 token、缺配置时会怎样？
  • 是否存在直接解包、空指针、未判空访问？
  • 缺依赖时是 fail fast，还是悄悄产生半成功状态？
  • nil 和 empty 有没有混用？

举个例子。

一个 iOS 设置页在正常情况下能保存 preset。但如果 navigator 没绑定，点击设置会不会崩？如果 UserDefaults 里没有这个 key，是回到默认值，还是显示一个错误高亮？

这就是 nil path。

它经常抓到“本地能跑、线上炸”的问题。因为本地开发环境通常配置齐全、用户状态完整、fixture 数据漂亮。

三、Empty：空不是缺，也不一定是错

Empty path 检查“存在但没有内容”。

空字符串、空数组、空结果集、零条记录、空响应。

很多 bug 来自 nil 和 empty 被混在一起。

空列表不是缺列表。空字符串不是缺字段。零条记录不是查询失败。接口返回空数组，可能是一次成功的空结果，而不是异常。

Empty path 要问：

  • 空列表是否显示空态，而不是报错？
  • 空搜索结果是否是正常结果？
  • 空输入是否需要拒绝？
  • 空内容是否允许保存？
  • 空响应是否会触发无限 loading 或无限重试？

举个例子。

搜索页面请求成功，返回空数组。正确行为应该是显示“没有找到结果”，并给用户一个修改关键词的入口。错误行为是显示“加载失败”，或者一直转圈。

这类问题看起来小，但非常影响用户信任。

Empty path 的关键是语义。空不一定错，要看需求怎么定义。

四、Error：世界不配合时会怎样

Error path 检查失败。

网络超时、数据库失败、权限不足、磁盘满、第三方接口 500、JSON 解析失败、任务取消、并发冲突。

Error path 要问：

  • 错误是否被捕获？
  • 错误语义是否正确？
  • 用户是否看到合理反馈？
  • 日志是否可定位？
  • 指标是否可观察？
  • 是否需要重试？
  • 重试是否幂等？
  • 失败后状态是否可恢复？

很多系统不是在成功时分出高下，而是在失败时分出高下。

比如导出任务：文件上传成功了，但数据库状态写回失败。这不是简单的失败。它是半成功。如果系统从头重试，就可能重复上传文件。如果系统直接标记 failed，用户会看到失败，但实际上文件已经生成。

这种问题，happy path 永远抓不到。

你必须专门问 error path。

五、Review 不是建议越多越好

坏 Review 经常堆满细节建议：

  • 变量名可以更好。
  • 这里可以抽函数。
  • 这里可以换一种写法。
  • 这个注释不够优雅。

这些建议不一定错，但如果它们淹没了真正的行为风险，Review 就失败了。

Review 的优先级应该是：

  1. 阻断性行为错误。
  2. 可能导致数据、权限、稳定性问题的风险。
  3. 测试缺口。
  4. 契约和发布风险。
  5. 可维护性建议。

风格建议应该让路给行为问题。

六、Review 要贴着任务 Mode

同一段 diff，在不同 Mode 下 Review 重点不同。

如果任务是 Expansion，要问：

  • 新能力是否有完整状态流？
  • 错误态是否设计？
  • 发布和回滚是否考虑？
  • 新接口是否有契约测试？

如果任务是 Hold，要问：

  • 是否保持既有契约？
  • 是否只修当前问题？
  • 是否避免不必要重构？
  • 是否补了回归测试？

如果任务是 Reduction，要问：

  • 旧入口是否真正收口？
  • 删除是否有证据支持？
  • 兼容入口是否有清退说明？
  • 回滚是否可行？

没有 Mode 的 Review，很容易用错尺子。

七、一个好 Finding 应该长什么样

不要写：

1
建议增强错误处理。

这句话太软，不能行动。

改成：

1
2
3
4
5
[P1] 重试路径可能重复上传文件
Path: error
Trigger: 上传成功，但状态写回失败，重试从生成文件重新开始
Risk: 产生重复导出文件，用户状态不一致
Required validation: 从 uploaded_pending_persist 状态重试时，断言 renderer 和 uploader 不会再次调用

这才是有用的 Review。

它说明了路径、触发条件、风险和需要补的验证。

八、让 AI 做 Review 时要禁止它总结

AI 做 Review 时，最容易输出这种东西：

1
本次修改优化了导出逻辑，增加了错误处理，并补充了测试。整体结构清晰。

这不是 Review，这是摘要。

你应该明确要求：

1
2
3
4
请以代码审查姿态输出，优先寻找 bug、行为回归、边界遗漏和测试缺口。
不要先总结 diff。
按 happy、nil、empty、error 四条路径检查。
如果没有发现问题，也要列出剩余测试缺口。

AI 很适合做边界扫描，但前提是你要求它扫描边界，而不是让它“看看”。

九、四路径的真正价值

happy、nil、empty、error 并不是完整的软件质量模型。

但它们有一个巨大优点：简单、稳定、容易记。

每次 Review 前扫一遍：

1
2
3
4
正常路径成立吗？
缺失值会炸吗？
空结果语义对吗？
失败后状态安全吗？

很多问题就会浮出来。

这四条路径的价值，不在于它们高级，而在于它们能把 Review 从“我看了一遍”变成“我攻击了四个方向”。

发表于 | 分类于

把测试通过变成验收证据

“测试通过了”不是证据。

它最多是证据的标题。

真正有用的测试证据，要能回答：

  • 测了什么行为？
  • 用了什么输入？
  • 控制了哪些依赖？
  • 覆盖了哪些路径？
  • 命令是什么？
  • 输出是什么？
  • 哪些风险还没测？
  • 这个结果能不能支持验收？

如果这些问题答不上来，一句“测试通过”并不能让系统更安全。

一、测试不是越多越好，而是越贴边越好

很多项目会陷入一种焦虑：测试覆盖率越高越安全。

覆盖率有价值，但覆盖率不是安全本身。你可以写很多不痛不痒的测试，也可以漏掉真正会让线上出事的路径。

测试要贴着问题定义、设计边界和失败模式。

一个改动如果是修复状态写回失败，最重要的测试不是“导出成功”。最重要的是：

  • 上传成功但状态写回失败时，任务是否保留可恢复状态。
  • 重试是否幂等。
  • 重复触发是否不会生成两个导出文件。
  • 状态为空或历史状态不认识时是否降级。
  • 依赖失败时是否留下可观测错误。

这叫贴边。

二、把测试结果写成台账

我现在更喜欢用测试证据台账，而不是只写一段测试总结。

格式可以很简单：

1
2
3
4
5
6
| 链路 | Path | 输入 / Fixture | 命令 | 结果 | 证据 | 风险 |
| --- | --- | --- | --- | --- | --- | --- |
| 导出成功 | happy | articleWithBody | npm test export.success | pass | terminal log | 无 |
| 缺 token | nil | expiredSession | npm test export.auth | pass | terminal log | 只覆盖 API 层 |
| 空文章 | empty | emptyArticle | npm test export.empty | pass | golden diff | 未覆盖 UI |
| 上传超时 | error | fakeUploaderTimeout | npm test export.timeout | pass | terminal log | 未跑真实存储 |

这张表的价值不是好看，而是让验收者能迅速判断：证据够不够支持发布。

它把“测试通过”拆成了具体问题：

  • 通过的是哪条链路？
  • 属于 happy、nil、empty、error 哪个路径？
  • 输入是什么？
  • 用什么命令验证？
  • 证据在哪里？
  • 风险是否仍然存在？

三、没有测到的也要写

成熟的测试证据不是假装覆盖一切，而是诚实写出没覆盖什么。

例如：

1
2
3
4
Not Covered:
- 未跑真实对象存储，只用 fake uploader 验证超时语义。
- 未跑旧客户端回归，当前根据接口兼容性分析判断风险低。
- 未跑高并发重复导出，记录为后续性能测试。

这比一句“测试通过”有价值得多。

未覆盖风险不是失败。隐藏未覆盖风险才是失败。

工程里真正危险的不是“我们知道这个风险还没测”，而是“大家以为它测过了”。

四、区分 Test Plan 和 Test Blueprint

一个常见混乱，是把“未来想测什么”和“现在已经测了什么”混在一起。

所以要区分 Test Blueprint 和 Test Plan。

Test Blueprint 是目标态自动化蓝图。它可以写：

  • 将来应该补哪些层级的测试。
  • 哪些路径适合单元测试。
  • 哪些路径适合集成测试。
  • 哪些路径需要 UI 自动化。
  • 哪些路径只能人工验收。

Test Plan 是当前可执行验证。它必须写：

  • 本次实际跑哪些命令。
  • 预期结果是什么。
  • 实际结果是什么。
  • 证据在哪里。
  • 哪些没测。

Blueprint 可以理想，Plan 必须诚实。

如果把 Blueprint 当成 Plan，你会得到一种虚假的安全感：文档里看起来什么都覆盖了，但实际上当前没有一条证据。

五、Fixture、Mock、Stub、Fake 的边界

测试证据链离不开依赖控制。

Fixture 是测试输入和环境样本。

坏 fixture 叫：

1
2
3
user1
article1
payload1

好 fixture 叫：

1
2
3
4
5
loggedInUser
articleWithLongBody
emptyArticle
expiredSession
exportTaskUploadedButStatusNotPersisted

命名本身就是测试文档。

Stub 提供固定返回，适合控制简单依赖，比如配置读取、时间、当前用户。

Mock 关注交互是否发生，适合验证“是否调用了某个依赖”“调用参数是什么”“调用次数是否正确”。Mock 用多了会绑死实现细节，所以要谨慎。

Fake 是可工作的轻量实现，比如内存数据库、内存队列、临时文件系统、假的上传服务。Fake 通常比 mock 更适合测试状态流，因为它允许行为自然发生，而不是只验证调用。

选择原则：

  • 想控制输入，用 fixture。
  • 想固定返回，用 stub。
  • 想验证交互，用 mock。
  • 想模拟真实行为，用 fake。

六、验收不是跑完测试

测试通过只是验收材料之一。

验收要回答更大的问题：

  • 本次目标是否完成？
  • In Scope 是否全部覆盖？
  • Out of Scope 是否没有被带入？
  • 关键路径是否验证？
  • 四路径是否覆盖？
  • 哪些风险没有覆盖？
  • 是否需要发布？
  • 如果发布，如何观察？
  • 如果失败，如何回滚？

也就是说，验收是把需求、设计、测试、review 和发布风险收束到一个判断。

验收结论最好不要只有“通过 / 不通过”。

可以分成三类：

  1. Accepted for current scope。
  2. Accepted with residual risks。
  3. Not accepted; requires fix。

第二类很重要。很多真实任务不是零风险，而是在明确风险后接受。

例如：

1
2
3
4
5
6
Accepted with residual risks.

Reason:
- 本次覆盖了 service 层 happy / nil / empty / error。
- 未跑真实对象存储集成测试，但 fake uploader 覆盖了超时语义。
- 由于本次改动不改变存储接口，接受该风险。

这比“通过”更诚实，也更适合复盘。

七、发布前还要问观察和回滚

如果一个改动会影响用户、数据、接口、配置、队列、存储、权限、支付、同步或后台任务，就不能只靠测试结束。

发布前还要问：

  • 发布后观察多久？
  • 看哪些指标？
  • 看哪些日志？
  • 哪些用户路径要冒烟？
  • 什么条件触发回滚？
  • 回滚命令是什么？
  • 回滚会不会破坏新数据？

没有观察窗口的发布，本质上是在靠感觉。

一个更好的发布观察写法是：

1
2
3
4
5
6
7
8
Observe Window: 发布后 30 分钟
Signals:
- export_job_failed_total 不高于过去 7 日同时间均值 20%
- export_job_retry_total 无异常尖峰
- status_persist_failed 日志不连续出现
Rollback Trigger:
- 导出失败率连续 10 分钟超过基线 2 倍
- 出现重复导出文件

这才是把发布拉进控制面。

八、完成必须带证据

任务结束时，最好的收尾不是“已完成”，而是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Changed:
-

Validated:
-

Not Covered:
-

Residual Risks:
-

Follow-up:
-

这几项看起来普通，但它们能显著减少后续扯皮和返工。

“测试通过”是一句话。
“验收证据”是一组可复查事实。

AI 时代代码会来得越来越快。越是这样，我们越需要把测试从一个动作，升级成一条证据链。

发表于 | 分类于

如何约束AI写代码：Mode边界和证据链

让 AI 写代码，最重要的不是 prompt 写得花，而是任务边界写得硬。

很多人使用 AI 编程的方式，是把愿望丢给它：

1
帮我优化一下这个功能，注意代码质量。

这句话看似礼貌，实际很危险。它没有告诉 AI 这是什么类型的任务，也没有告诉它哪些文件能改、哪些不能改、哪些行为不能变、发现旁支问题时该停还是该修。

AI 收到这种指令，只能自己补全边界。补得好，是运气；补得坏，也不奇怪。

一、AI 的强项和危险是同一件事

AI 很擅长补全。

你给它一段不完整上下文，它会补全缺失逻辑。你给它一个模糊目标，它会补全任务范围。你给它一个失败测试，它会补全实现。你给它一组 diff，它会补全解释。

这就是它的力量，也是它的风险。

在人类开发里，模糊有时会停下来。因为人会问，或者会卡住，或者会因为不确定而慢一点。AI 不一定会卡住。它更可能生成一个看起来完整的答案。

越流畅，越容易让人忘记中间有多少猜测。

所以，AI 协作的第一原则不是“让它更聪明”，而是“让它必须暴露不确定性”。

二、先声明 Mode

每个 AI 开发任务，先声明 Mode。

Expansion：扩展能力。
Hold：修复、硬化、迁移、清理、提效，不扩大范围。
Reduction：收缩、下线、删除、降低复杂度。

Mode 不是标签。它是约束。

如果任务是 Hold，AI 就不应该顺手加新功能。
如果任务是 Reduction，AI 就不应该加一堆兼容分支让复杂度继续膨胀。
如果任务是 Expansion，AI 就必须考虑错误态、测试、发布和回滚。

你可以这样写：

1
2
3
4
5
Mode: Hold
目标：修复导出任务偶发失败。
为什么是 Hold：本次只修复和硬化已有导出链路，不新增导出格式。
为什么不是 Expansion：没有新增用户能力。
为什么不是 Reduction：没有下线旧能力。

这几行会让 AI 的工作方式完全不同。

三、边界要写成硬规则

不要对 AI 说“尽量别改太多”。

这句话太软。你应该写：

1
2
3
4
5
6
7
8
9
10
11
Allowed Changes:
- 修改 ExportService。
- 修改 ExportServiceTest。
- 如需新增 test helper，只能放在 test support 目录。

Forbidden Changes:
- 不改导出 UI。
- 不改 StorageClient 接口。
- 不新增导出格式。
- 不做全仓格式化。
- 不修 unrelated lint。

这种写法没有那么优雅，但非常有效。

AI 不是不听话，而是它不知道你的隐含边界。你不写，它就会推断；它一推断，就有可能把“相关”当成“应该做”。

边界越清楚，AI 越能发挥执行能力。

四、Research-first 是刹车

AI 开发最容易出事的时刻，是它还没理解代码库就开始改。

所以第一道 Harness 是 research-first：

1
2
3
4
5
6
先研究代码库现实，不写代码。
列出相关文件。
列出现有实现。
列出已有测试。
区分 Facts、Assumptions、Unknowns。
最多保留一个阻断问题。

这个阶段像刹车。不是为了停住，而是为了让后面的加速有方向。

Research-first 还有一个价值：它能让你提前看到 AI 是否理解错了。

很多错误如果等到 diff 出来才发现，已经晚了。如果 research 阶段就发现 AI 把项目结构、业务名词或失败路径理解错了，修正成本很低。

五、把事实、假设、未知分开

这是约束 AI 的关键动作。

你要让它明确输出：

1
2
3
4
5
6
7
8
9
10
11
12
Facts:
- 当前导出任务由 ExportWorker 执行。
- 测试只覆盖正常导出成功。
- 日志显示上传成功后出现状态写回超时。

Assumptions:
- 用户看到失败可能来自状态写回失败。
- 重试可能会重复生成文件。

Unknowns:
- 当前是否有幂等 key。
- 旧导出文件是否会清理。

这三类东西必须分开。

Fact 可以支撑设计。Assumption 需要验证、隔离或写进风险。Unknown 要么补研究，要么明确不阻塞当前阶段。

如果不分开，AI 很容易把假设写成事实语气。

六、Dirty Worktree 是协作边界

AI 工作时，脏工作区是一个重要信号。

脏工作区可能意味着：你正在做另一件事，另一个 agent 留下了中间产物，脚本生成了文件，或者当前任务已经有未提交改动。

AI 不能把脏工作区当噪音。

任务里应该写：

1
2
3
如果工作区有未提交改动，先报告与当前任务相关的文件。
不要覆盖无关用户改动。
如果某个脏文件是本任务必须修改的，先读懂它，再继续。

这条规则看似普通，但非常关键。没有它，AI 很可能在“整理代码”的过程中覆盖别人还没保存好的意图。

七、让 AI 输出证据，而不是情绪

AI 最差的收尾方式是：

1
已完成。

这句话没有价值。

好的 AI 收尾应该包含：

  • 改了哪些文件。
  • 为什么这么改。
  • 跑了哪些验证。
  • 验证结果是什么。
  • 哪些没测。
  • 剩余风险是什么。
  • 哪些发现属于后续任务。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
完成了 token 过期状态流修复。改动集中在 AuthSessionStore 和对应测试，没有修改登录 UI 或 token refresh API。

验证：
- testExpiredTokenRoutesToLogin: pass
- testMissingNavigatorDoesNotCrash: pass
- testEmptyCachedTokenClearsSession: pass
- testRefreshFailureKeepsRecoverableState: pass

未覆盖：
- 未跑完整 UI 自动化。
- 未覆盖旧客户端真实请求。

剩余风险：
- 旧缓存格式兼容只通过单元测试验证，未在真实设备回归。

这才是能被接住的交付。

八、一个可复制的任务模板

你可以直接复制下面这段给 AI：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Task:
<一句话描述任务>

Mode:
Expansion / Hold / Reduction

Goal:
本次真正要解决的问题是：

In Scope:
-

Out of Scope:
-

Research Rules:
1. 先 research，不直接改代码。
2. 区分 Facts / Assumptions / Unknowns。
3. 如果发现范围外问题，只记录到 residual risks，不顺手修。

Allowed Changes:
-

Forbidden Changes:
-

Review Rules:
按 happy / nil / empty / error 检查。

Validation:
必须记录命令、预期结果、实际结果、未覆盖风险。

它不华丽，但很实用。

九、AI 不是混乱的解药

AI 不是混乱的解药。没有 Harness，AI 会让混乱跑得更快。

但有了 Harness，AI 是非常强的执行器、检索器、测试补全器和风险扫描器。

问题不在 AI。问题在任务有没有被装进控制面。

你要做的，不是把 AI 变成一个“更听话的人”，而是把任务变成一个它能安全执行的结构。

发表于 | 分类于

1

五月份状态很差，连月报都没有写。上一次没有写月报，可以追溯到好几年前。真的很不应该。这次月报就两个月合并到一起写吧。

四月份阅读306.5小时，冥想24.4小时。五月份阅读278小时，冥想11.7小时。数据不理想，而且呈严重的下滑趋势。

接下来跟大家分享我打算执行的三项改进措施。

2

我要做的第一项改进措施很简单，就是坚持每个月1号把月报发出来。

写月报不能拖。我发现了，只要我一拖，就会拖很久。拖着拖着，就很容易不把当月的目标当回事。

不把当月的目标当回事，就很容易状态松懈。看书不好好看了，冥想不好好做了，把时间浪费在各种各样的分心事项上。

3

第二项改进措施是坚持锻炼。

最近一个月没有坚持锻炼，健身房就只去了6次。按之前的频率，一个月至少要去健身房16次以上。

少去健身房，就很容易熬夜。一熬夜，身体状态就会变差。身体状态变差，看书和冥想都不会好好完成。

从下周开始，要恢复锻炼，一周至少三练，理想的话是恢复到之前的一周四练。

4

第三项改进措施是多用AI。

近段时间用AI的次数的确减少了。Codex的额度不仅每周都没用完，而且常常只使用10%到30%。跟ChatGPT对话的次数也少了很多。

跟很多人的想象不一样。多用AI，不仅不会让自己少动脑，反而会多动脑。因为只有多动脑，我们才会有更多的想法让AI帮我们去实现。

多用AI，多用脑。多用脑，就会有更多的好奇心。有更多的好奇心，就会想着多看书，多寻找灵感。

从即刻开始，每周Codex的额度都要用完，每天至少跟ChatGPT对话1小时。

5

这么多年来，很多关注我的朋友都会夸我自律，夸我能坚持。但是最近这一个多月，我真的很不自律，很不能坚持。

我倒不会觉得很愧疚，很难受，更不会就此摆烂。我觉得这是正常的起起伏伏，即便这一次的确状态差得有点离谱。接下来好好改进就是了。

截至2026年5月31日，我一共阅读了20690小时。预计会在2029年11月15日，完成第三个10000小时，也就是总共30000小时的阅读目标。

六月份的阅读目标是460个番茄时间，也就是230个小时。冥想目标是20小时。

发表于 | 分类于

1

前几天跟一个学生讨论 AI，她提到一个很有意思的问题。

她说，自己用过不少模型，也知道它们能干活。有的模型写代码速度很快，有的模型回答问题看起来也不错。但是在使用过程中，她总有一种隐隐的不信任感。

这种不信任感，不一定是对 AI 的傲慢。更准确地说，是她还不知道该如何判断 AI 的回答到底好不好。

过去我们讨论 AI，最常问的问题是：AI 能不能做这件事？

现在这个问题已经不够了。因为很多时候，AI 的确能做。它能写代码，能写文章，能翻译，能做图，能帮你整理材料，能帮你做调研。真正的问题变成了：AI 给出的答案，看起来都比我强，我怎么知道它到底有没有达到我期待的高度？

这就是 AI 时代的第一个重要能力：不是提问能力，而是判断能力。

提问能力当然重要。但是如果没有判断能力，提问能力越强，反而越危险。因为你会得到更多看起来很像答案的东西，却不知道哪些是真的，哪些是假的，哪些是普通正确，哪些是真的高水平。

2

AI 让我们进入了一个更不容易相信世界的时代。

以前伪造一张聊天截图、伪造一张奖状、伪造一个图片证据，多少还需要一点技术门槛。你要会 PS，要懂排版，要花时间调整细节。现在，这个门槛正在迅速降低。

图片可以生成，视频可以生成，聊天记录可以生成，简历上的经历也可以在 AI 的帮助下被包装得越来越像真的。甚至一个人并没有真正做过某个项目，也可以让 AI 帮他准备一套看起来很完整的项目复盘。

这会带来一个直接后果：原来社会里那些简单的评价秩序会变得更复杂。

以前看到奖状，会默认它大概率是真的。看到论文，会默认作者确实参与了。看到视频，会觉得这总不会是假的吧。看到一个学生简历上写了很多成果，也许不会立刻怀疑。

但以后不行了。

不是说我们要把所有人都当成骗子，而是说世界会逼迫我们更谨慎。法律、学校、公司、平台的规则都会慢慢调整，但是规则永远是滞后的。很多权利和边界，本来就是从错误和事故里长出来的。先出现足够大的问题，大家吃了亏，社会才会开始补规则。

AI 时代也是这样。我们很可能要先经历一批谣言、造假、版权纠纷、学术争议、简历包装和信任危机，然后才会慢慢形成新的共识。

所以，年轻人不能只是学习如何使用 AI，还要学习如何在 AI 制造出来的复杂世界里保持清醒。

3

怎么保持判断力？

第一，不要盲目崇拜模型。

有的人一听是某个顶级模型，就天然更相信它。这个心理可以理解，因为好模型的平均能力确实更强。但是具体到每一个任务，模型名字不能替代判断。

同一个模型，做不同任务，表现会差很多。写代码可能很强，做网络安全题可能受安全策略影响。写一篇通用文章可能很顺，判断一个高度专业的问题可能会胡说。哪怕是最好的模型，也可能在某些地方犯很低级的错误。

所以，我们不能把信任建立在模型名字上，而要建立在验证过程上。

第二，要学会交叉验证。

看到一个说法，不要只问一次 AI。可以让不同模型分别判断，可以让 AI 给出处，可以让它列出反方证据，可以让它帮你检查自己的推理漏洞。尤其是涉及合作、求职、论文、项目经历、奖项荣誉这些高价值信息时，更要让 AI 参与事实核查。

比如，一个人简历上写了某篇论文。我们可以让 AI 查这篇论文的期刊、会议、作者列表、引用情况、研究内容和难度。还可以让 AI 判断，这个成果是否符合这个人当时所处阶段的能力范围。

AI 不一定能给出最终判决，但它可以极大降低初步审查的成本。

第三，要看细节。

判断一个项目是不是真的，最好的方法不是问“这是不是你做的”，而是让对方讲细节。

如果他真的做过，他会记得项目从什么时候开始，过程中遇到过哪些困难，哪一次讨论最关键，哪个地方卡了很久，最后为什么选择这个方案。他不一定表达得很漂亮，但是细节会自然冒出来。

如果他没有做过，只是背了一套包装材料，就很难经得起追问。

面试里判断项目经历，论文答辩里判断研究贡献，跟人合作时判断对方实力，本质上都要看细节。细节不是装饰，细节就是证据。

4

AI 时代的实力，也要换一种理解。

过去我们说一个人有实力，常常看他的学校、奖项、论文、实习、项目、工作经历。这些东西仍然重要，但它们会变得越来越不够。

因为这些东西都可以被包装，甚至可以被伪造。

真正重要的是，你能不能经得起审查。

你说自己做过一个项目，那你能不能讲清楚它解决了什么问题？为什么这个问题值得解决？原来最好的方法是什么？你的方法好在哪里？好多少？是正确率更高，还是速度更快，还是成本更低？有没有跟当前最好的方法对比？如果别人质疑“我用 AI 半天也能做一个类似工具”，你怎么证明你的工具不是一个玩具，而是一个成熟的成果？

这些问题都很现实，也很残酷。

我在跟那个学生讨论她的论文时，就做了一次模拟提问。她的论文是一篇工具型论文，不是提出一个全新的理论，而是把已有理论实现成可以使用的工具。

一开始她讲得比较散，说自己做了数据清洗、代码实现、实验测试，整个流程都走了一遍。这个回答能证明她参与过，但还不能很好证明这个成果的价值。

后来我们一点点追问，才追到关键点：她的工具跟已有的冠军级求解器相比，在相同时间内求出的结果数量有五倍以上提升。

这句话才是重点。

如果是面试，或者申请研究生，或者向一个不了解你领域的人介绍成果，你不能等别人追问十几分钟才说到重点。你要一开始就讲清楚：

我解决的是什么问题。
原来的最好方法是什么。
我的结果比它好在哪里。
这个工作体现了我哪些能力。

谦虚是一种美德，但是在需要证明自己的场合，过度谦虚会变成表达能力不足。

5

在一个更不信任的世界里，保持实力还有另一层含义：不要同流合污。

这句话听起来有点重，但现实确实会把人推到这种位置。

如果别人可以买奖、可以买软著、包装简历、论文挂名、实验结果微调一下就能发出去，你怎么办？

你可能会想，既然连一些著名学校、著名教授都会造假，为什么我不能？既然这样做收益很大，惩罚又未必很重，我为什么要吃亏？

这时候就不是技术问题了，而是选择问题。

一个朴素的理由是，你做坏事之后不一定会被抓住，但你永远不知道什么时候会爆雷。更可怕的是，一旦形成路径依赖，你会越来越习惯突破边界。第一次觉得紧张，第二次觉得问题不大，第三次就变成理所当然。

到最后，你不是犯了一次错，而是把自己训练成了一个会持续犯错的人。

还有一个更朴素的理由是，人要能睡得着觉。

不是每个人都要把自己想象成道德英雄。很多时候，不作恶并不是因为自己多高尚，而是因为自己知道，干了坏事会害怕，会心虚，会不安，会担心哪一天被翻出来。

这也挺好。

能对坏事感到害怕，说明人还没有坏到不可救药。能保留这种害怕，很多时候就是普通人最实用的道德防线。

6

除了判断力和实力，AI 时代还需要想象力。

我问过那个学生一个问题：如果你有无限的 token，你会用来做什么？

她说，她问过身边的学长学姐，大家的回答都比较局限。大概就是做科研、跑数据、翻译资料、完成作业。不是这些事情不好，而是这些答案暴露出一个问题：我们还没有真正打开 AI 带来的想象空间。

很多受过良好教育的人，很容易变成功利主义训练出来的高效执行者。

老师说这个重要，就做这个。学长学姐说这个有用，就做这个。竞赛榜单上有这个，就做这个。简历需要这个，就做这个。

这样当然能取得成绩，也很值得肯定。但是如果一个人永远只做别人已经说过有用的事，他的上限会受到限制。

想象力不是坐在那里空想出来的。想象力也需要训练。

怎么训练？多用。

就像读书一样，有一种读书方式是遇到好书才读。还有一种读书方式是，不管有没有遇到所谓好书，这个月就要读够一百个小时。后者听起来有点笨，但它会把你逼进更多可能性里。

使用 AI 也是这样。如果只是在有明确需求的时候才打开 AI，你会永远停留在熟悉场景里。写作业、写代码、改简历、做总结，来来回回就这些。

但是如果你要求自己在有效探索的前提下多用 AI，你就会开始问：我还能让它做什么？它能不能帮我做一个工具？能不能帮我复盘一次谈话？能不能帮我训练表达？能不能帮我做一个给小学老师用的教案系统？能不能帮我把手机里的注意力重新引导到我真正想去的地方？

很多新想法，就是在这种“多用一点”的压力下出现的。

7

最后，功利主义和理想主义并不是对立的。

学生时期，我们很容易把功利主义当成主线，把理想主义当成甜品。周一到周五是功利主义，晚上和假期才是理想主义。先把成绩、论文、保研、实习、工作这些事情做好，如果还有余力，再做一点自己真正感兴趣的事。

这个思路有现实合理性。

但是它也有一个问题：过度功利会让人失去主动性。

别人说什么有用，你就做什么。别人说什么没用，你就不做什么。你看起来很聪明，很会选择，实际上是在把自己的想象力交给外部评价体系。

理想主义的价值，不只是让人活得浪漫一点。它还会反过来帮助一个人取得更大的现实成就。

一个人因为喜欢学习而持续阅读，后来可能在 AI 时代更快适应新工具。一个人因为对编程本身感兴趣而长期探索，后来可能在工作中拥有更强的工程判断。一个人因为想帮助别人而做一个小工具，后来这个小工具也许会变成真正有价值的产品。

功利主义让人知道眼前要做什么，理想主义让人不被眼前困住。

AI 时代也是这样。

如果你只把 AI 当成完成任务的工具，你会变得更高效。但是如果你把 AI 当成扩展想象力的伙伴，你才可能变得更自由。

所以，年轻人最该训练的，确实不是单纯的提问能力。

更重要的是判断力，知道什么是真的，什么是好的，什么是值得相信的。

更重要的是实力，让自己的经历、成果和表达经得起审查。

更重要的是想象力，在别人都沿着既定标准往前跑的时候，还能问一句：我自己真正想做什么？

这三个能力，可能才是 AI 时代最硬的通行证。

发表于 | 分类于

信息管理的终极问题：我们用信息网络建造的，从来不是真理

——在《Nexus》之后，重新看 AI 辅助编程与信息管理

没有人直接生活在现实里

设想一个场景。

一位老人在山东某家三甲医院的结算窗口前出院。他买过一份惠民保。十分钟后，他的医保报销、商保赔付和自付金额，被同一台屏幕一次算清。他不再需要保留发票，不再需要去保险公司柜台递材料，也不再需要拜托儿子拍照上传 App。

从他的角度看，他只是少跑了几次腿。

但从信息网络的角度看，这十分钟里发生的事，比他这一生大部分政治新闻都更重要。一个原本散落在患者、医院、医保部门、商保公司之间的低信任信息链，被改造成了一张可验证、可结算、可监管的网。截至 2024 年，这个平台已在山东全省上线，2760.30 万笔医保业务以「一站式结算」方式完成，惠及 511.22 万参保人，累计报销 13.34 亿元。[^1]

这位老人没有看见这张网，但他的余生将持续生活在这张网定义的现实里。

这就是信息管理。它不是整理资料，不是文件归档，不是把表格做得更漂亮。它决定一个社会如何看见自己，谁被看见，谁被忽略，谁有权行动，谁必须等待。

人类从来不直接生活在现实里。我们生活在被信息网络组织过的现实里。

信息的两张脸

有一种很顺口、也很危险的说法：信息越多，人类越接近真理。

这并不成立。

赫拉利在《Nexus》里反复提醒一件事：信息有两种功能，但它们并不天然重合。第一种功能是发现现实——让我们看见从未被看见的东西。第二种功能是组织人——让分散的个体能够协调、服从、行动。前者通向智慧，后者通向秩序。两者偶尔同向，更多时候各走各路。[^2]

历史上最强大的信息网络，往往不是最接近真理的网络，而是最擅长组织人的网络。

一种宗教让百万人愿意为同一个神而死，靠的不是事实核查，而是叙事的可复制性。一支军队让普通士兵冒着子弹冲锋，靠的不是哲学论证，而是命令链的清晰度。一家公司让员工每天准时打卡，靠的不是科学发现，而是工资单和考勤系统。

这些都是信息网络。它们记录的、传递的、强制的东西,大部分与真理无关。

赫拉利的提醒在 AI 时代变得格外刺耳：一个网络越强大，并不代表它越接近真实。它可能只是更擅长动员人、分类人、约束人，让人按某种规则行动。

社交媒体是信息网络。
医保系统是信息网络。
你公司里的 CRM 是信息网络。
未来部署在企业内部的 AI agent harness，也是信息网络。

它们的力量不在于「记录了什么」，而在于：让什么被看见，让什么被忽略；让谁能行动，让谁承担责任；让什么被当成事实，让什么被当成噪音。

回到那家医院的结算窗口。它表面上多了一个便民流程，实质上重新定义了三件事：医院与商保之间谁有权读取什么数据，费用如何被分类，赔付责任如何被分配。这是新的事实秩序。

信息管理之所以重要，因为它从来不是中性的。

一家公司是怎么变成半盲的

每一个组织都不直接接触现实。

它通过订单、合同、票据、病历、日志、报表、监控指标和会议纪要来感知世界。这些东西如果没记录，组织就看不见；如果记错了，组织就看错了；如果传得太慢，组织就活在过去。

很多小企业不是没业务，是老板看不见自己的业务。

客户在哪个销售手上，他不知道。
合同有没有续签，他要等月会。
发票有没有开，财务还没汇总。
钱到没到账，要在群里问一遍。
售后由谁跟进，全靠当事人记忆。
仓库里到底剩多少货，要去问那个干了十二年的老员工。

现实其实早就发生了。组织只是没形成统一感知。

这就是赫拉利意义上的「半盲」状态：信息已经存在于人世间，但还没有被组织成网络。它分散在每个人的手机、Excel 和大脑里，无法相互校对，也无法被任何一个共同视角看见。

一家公司从半盲走向看得见的过程，从来不是「上一套 SaaS」那么简单。它是一种治理升级。

谁有权录入？
谁有权修改？
什么算重要客户？
什么算正式投诉？
谁负责催款？
员工离职后，客户关系归个人还是归公司？

只要这些问题没答案，再贵的系统也只是把混乱搬进数据库。

信息管理还做了一件容易被忽略的事：它替组织记忆。

人会遗忘。组织也会。一个接口为什么不能改、一个客户为什么有特殊条款、一种药品为什么不能进某个支付流程、一次上线为什么会失败——这些经验如果只活在某个具体的人脑子里，等他离开，组织就会重新犯同一个错误。

信息系统的价值，是把「某个人知道」变成「这个系统知道」。这是从个人能力到组织能力的关键一跳。

协作的真相是：每个人都活在自己的版本里

只要有多人协作，就一定需要一个共享的现实模型。

但大部分项目的失败，不是因为大家不努力，而是因为没有形成共同的现实。

需求文档写在一个地方。
设计图存在另一个地方。
代码是第三套逻辑。
测试不知道真实意图。
运维不知道上线风险。
老板看到的是被销售层层修饰过的进度。

一群人看似在协作，其实活在不同版本的现实里。每个人的版本都不算谎言，但拼起来不构成同一个故事。

更糟糕的是，没有人知道哪个版本最接近真相。

这就是为什么开会越多的组织，往往越混乱。会议本身不是协调，会议是为了消除版本差异而进行的临时手术。如果信息系统是健康的，差异会被自动磨平；如果信息系统是病的，会议只是在不断暴露病情。

信息管理的本质，不是让大家说一样的话，而是让大家看到一样的世界。

任何网络都会犯错，问题是错了之后会发生什么

任何一个信息网络都会犯错。

数据会错，规则会错，模型会错，人会错，AI 也会错。

问题不在「会不会错」，而在「错了之后会发生什么」。

赫拉利用相当大的篇幅讨论过中世纪教会和 20 世纪极权宣传体系。它们都是极其高效的信息网络——覆盖广、传播快、组织严密。但它们都缺一样东西：自我纠错的机制。异见被清除，反对被压制，错误被神圣化。于是，这些网络越高效，灾难就被放大得越彻底。[^3]

一个网络的健康程度，从来不取决于它传播信息的效率，而取决于它识别和修正错误的能力。

软件工程师其实早就懂这个道理，只是用了别的词汇。

测试是纠错。
日志是纠错。
监控是纠错。
审计是纠错。
回滚是纠错。
代码 review 是纠错。
事故复盘是纠错。
权限隔离是预防性纠错。
用户申诉是社会性纠错。

一个没有这些机制的信息系统，会变成非常危险的东西。它不只是错，还会以系统权威的方式错。

接下来谈 AI 时，请记住这一点。我们不是在讨论 AI 会不会犯错——它一定会。我们要讨论的是：当一个能犯错的智能体，被放进一个本来就缺乏纠错机制的网络里，会发生什么。

AI 辅助编程真正降低的，不是写代码的成本

过去几年，关于 AI 辅助编程，所有的注意力都集中在一件事上：写代码更快了。

这个视角太窄。

数据本身不算新鲜。Stack Overflow 2025 开发者调查显示，84% 的受访者已经在使用或计划使用 AI 工具，专业开发者中 50.6% 每天使用 AI；同一份调查里，开发者对 AI 输出准确性的不信任比例已经超过信任比例。[^4] Gartner 预测，到 2028 年，75% 的企业软件工程师会使用 AI code assistants。这个趋势意味着，开发者的角色会越来越多地从「实现」滑向「编排、约束和验证」。[^5]

把这两组数字放在一起，会得到一个并不令人鼓舞但很重要的结论：AI 已经高频进入开发流程，但人类仍然必须验证它的产出。

更深层的变化藏在另一个地方。

写代码从来不是一个软件项目里成本最高的部分。

真正贵的，是沟通需求、设计数据模型、对接权限、写接口、生成报表、清洗脏数据、部署上线、培训用户、修 bug、跟随业务调整、长期维护。代码只是这条长链中的一段。

所以，当一个外包公司不愿意给小工厂做质检系统，不是因为代码难写，是因为整条链都不划算。当一家县医院接不进某个商保产品，不是因为接口神秘，而是因为没人愿意为这点业务量配齐一支团队。当一家养老机构上不了长护险结算系统，不是因为技术不存在，而是因为定制开发的成本永远高于这家机构付得起的金额。

于是这些需求长期被压抑。它们不是「不存在」，它们是「不值得」。

AI 辅助编程改变的，是「不值得」这条边界。

它不是把一个大型系统便宜一点做出来。它是让大量原本不值得做的小型信息系统，第一次变得值得做。

我把这个变化称为：毛细血管信息化。

过去，信息化主要发生在主干道——大型银行的核心系统、大型医院的 HIS、国家医保平台、城市级政务系统、大企业的 CRM。这些系统投入巨大、周期漫长、参与人多。

接下来要发生的事，是信息化向毛细血管渗透。

某个险种和某家医院之间的结算规则。
某个社区里几位独居老人的巡访记录。
某个小工厂的质检异常闭环。
某个外贸公司的回款提醒。
某个老师对学生长期学习状态的追踪。
某家律所的客户材料流转。
某家药房特药的处方核验和支付。

每一个都不大。加起来数量巨大。它们对应的是现实世界里无数尚未被软件覆盖的流程。

这才是 AI 辅助编程的社会意义。软件正在从「大机构的基础设施」，变成「具体流程的低成本管理层」。

医保结算窗口背后的三层信息秩序

让我们再回到那位老人面前的结算窗口。

这一次，把镜头放慢。

第一层是事实层。这位患者是谁？他的住院费用多少？医保应付多少？商保可赔多少？这些是赤裸裸的事实。听起来简单，但在过去，每一项都可能在不同系统里、以不同口径、以不同时点存在。事实层的工作，是让它们以同一种语法被表达。

第二层是秩序层。哪些机构有权读取哪些数据？谁来计算赔付？医院如何出具结算单？商保何时履行赔付责任？患者是否需要垫资？这一层定义的不是事实，是事实如何改变行动。

第三层是纠错层。如果身份匹配错了怎么办？如果费用分类错了怎么办？如果保险责任判断错了怎么办？如果有人骗保怎么办？如果系统接口失败怎么办？这一层决定，当前两层出问题时，谁会发现，多久之内发现，谁有权修正。

三层缺一不可。

少了事实层，秩序无凭可据。
少了秩序层，事实无法行动。
少了纠错层，前两层会以不被察觉的方式偏离真实，最后变成一种自动化的虚假。

这个三层模型不只适用于医保。它适用于所有信息系统。

中小企业的 CRM，事实层是客户、合同、报价、发票；秩序层是谁负责催款、谁有权打折、谁审核回款；纠错层是对账、抽查、客户申诉。

软件工程的代码仓库，事实层是代码、需求、日志、事故记录；秩序层是 review、CI、发布流程、权限分级；纠错层是测试、监控、回滚、复盘。

养老机构的护理记录，事实层是服务时间、服务内容、签字确认；秩序层是排班、保险结算、家属通知；纠错层是抽访、家属申诉、第三方审计。

任何一个信息系统，如果你看不清它的三层结构，那它八成已经在某一层失效了。

创新药支付：当事实链不够长，赔付就无法发生

医保结算窗口只是开始。

国家医保局关于「双目录」机制的文件指出，打破医保、医院与商保之间的数据壁垒，是支持创新药研发和商业健康保险扩张的前提。一些试点已经把保障从「事后补偿」延伸到「全程服务」：上海三甲医院推进「医保+商保一站式秒赔」，广州穗新保与医院实现全流程数据对接。^6

为什么创新药这件事必须由信息网络才能解决？

因为价格只是表面问题。

商保过去很难覆盖创新药，不只是因为药贵，是因为信息不够长。

保司不知道患者的真实疾病轨迹。
不知道用药的真实周期。
不知道疗效是否成立。
不知道停药率有多高。
不知道是否合规使用。
不知道是否存在欺诈。

没有这些信息，就无法做精算。没有精算，就没有可持续的产品。没有产品，患者就无药可保。这是一条被信息缺失锁死的链条。

当信息网络贯通诊断、处方、购药、支付、用药、随访、疗效、不良反应、再次治疗、真实世界数据时，整条链才有可能松动。商保不再面对一份残缺的病历，而是面对一段连续的事实。

这才是信息管理真正可怕的地方。它不只是提高效率。它会改变哪些事情「可能发生」。

一份创新药保单能不能出生，取决于事实链是否够长。

中小企业不是没管理，是管理活在老板脑子里

中国大量中小企业，不是没管理，是管理高度依赖人脑。

客户信息在销售微信里。
报价单在 Excel 里。
合同在网盘里。
发票在财务的电脑里。
回款靠老板亲自追问。
售后靠销售记忆。
库存靠仓库老员工知道。
项目延期靠群里吵出来。
员工离职后，很多客户关系和历史经验一起消失。

很多人会说：上 CRM、上 ERP。

现实是，中小企业经常上不起来。标准 SaaS 太重，字段不贴合，员工不愿意填，流程变得太快，老板想要的报表又是个性化的。大型 ERP 更不现实——成本、实施周期和组织成熟度都不匹配。

AI 辅助编程的机会，是让一家企业可以「长出」刚好够用的系统。

不是一上来买一个庞然大物。
而是从最痛的地方开始。

先把客户、合同、应收账款整理成一个小系统。
再把销售跟进记录接入。
再生成回款提醒。
再接入发票和银行流水。
再生成每周经营报表。
再把售后问题转成工单。
再让一个 agent 每天巡检异常。

每一步都不需要一个完整团队。每一步都可以在不打断业务的情况下增长。

但这里藏着一个赫拉利式的警告：信息系统不能凭空创造秩序。

它只能把已有的秩序显性化，把隐性的秩序结构化，把混乱暴露出来——或者，在更糟的情况下，把混乱固化下来。

如果老板自己也说不清客户分类规则，AI 不会帮他想清楚。
如果销售拒绝录入关键事实，AI 不会替他承担。
如果财务数据本身混乱，AI 只会自动化这种混乱。
如果公司内部权责不清，AI 会把责任的真空写进每一份自动生成的工单里。

中小企业信息化最难的部分，从来不是写代码。是让一家企业愿意面对它自己的真实流程。

Agent 是新一代官僚

现在轮到房间里那只越来越大的灰犀牛：AI agent。

OpenClaw 这一类 agent harness 的关键，不是聊天，是把大模型放进一个带工作区、工具、技能、配置和长期上下文的运行环境。它的 skills 可以作为带有 SKILL.md 的目录来教 agent 如何使用工具，workspace 也可以承载和具体环境相关的上下文。[^7]

如果把它部署在企业内部，它会成为某种东西——一种我们语言里还没有合适词汇的东西。

它不只是工具。
它不只是助手。
它甚至不只是流程自动化。

它是一台微型制度生产机器。

老板说：每天早上列出超过 30 天未回款的客户。Agent 去查合同、发票、收款记录，生成清单。这是一条新的制度。

销售说：这个客户同意了新报价。Agent 自动更新客户状态、生成合同草稿、提醒财务开票。这是另一条新的制度。

财务上传银行流水。Agent 自动尝试匹配合同和发票，标记异常项。又是一条。

售后接到投诉。Agent 自动生成工单，关联客户、产品、合同和历史问题。又是一条。

这些「制度」过去需要一个产品经理、一个工程师、一个运营人员、一个审批流设计者协作几周才能跑起来。现在，一句话之后，它就在运行。

这是非常美好的画面。也是非常危险的画面。

因为制度生产从来有两面。

好制度可以降低摩擦、减少误判、保护弱者、提升效率、让责任清晰。
坏制度可以制造形式主义、增加填报负担、强化监控、固化偏见，把人困在不合理的流程里。

AI agent 的危险在于——它非常勤奋。它可以源源不断地生成流程、表格、指标、看板、规则、提醒。如果没有人类判断介入，它会变成一种新型物种：

自动官僚。

自动官僚的特点，赫拉利在《Nexus》里其实早已勾勒过雏形。它能把所有事情表格化，把所有行为指标化，把所有例外流程化，把所有沟通工单化，把所有人放进某种评分体系里。

它运转良好。它从不抱怨。它每天准时生成报表。它绝不偷懒。

但它未必知道这些东西是否真的接近现实，是否真的减少负担，是否真的提升智慧。

这个风险并不抽象：一旦 agent 可以安装第三方技能、访问文件、执行命令、调用外部服务，技能来源、权限边界、执行日志和外部授权就必须被纳入治理。[^8] 这些不是技术细节，而是治理问题。

一个真正可用的企业内部 agent harness，必须是这样一组东西的总和：

工具能力 + 权限边界 + 审计日志 + 沙箱环境 + 人工审批 + 数据治理 + 回滚机制。

少一项，它就不是基础设施，是事故源。

信息管理会从「搜索」滑向「供给」

传统信息管理基本上围绕搜索展开。

资料很多，你来找。
文档很多，你来搜。
知识库很大，你输关键词。
搜索结果给你，剩下你自己判断。

这种范式建立在一个假设上：信息的最终消费者是人，而人有时间和耐心。

这两个假设都正在失效。

接下来的信息消费者，会越来越多地是 agent。它们没有时间、没有耐心，也没有「自己再判断一下」的习惯。它们要求信息直接、结构化、可执行。

更重要的是，使用者的需求本身在变化。

人们不再想「找到资料」。他们想「完成任务」。

帮我改这个模块。
帮我排查这个 bug。
帮我判断这个客户是否有回款风险。
帮我生成本周经营报告。
帮我看这个患者是否满足保险责任。

完成任务所需的信息，不应该完全靠人去搜，而应该由系统主动供给。

一个 coding agent 要修改支付状态机，它应该自动拿到相关需求背景、状态机文档、接口契约、表结构、历史事故、下游依赖、测试用例、监控指标、上线回滚方案、权限和合规要求。这不是奢侈，这是它能不能被信任的前提。

一个企业经营 agent 要生成回款报告，它应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进、催款历史、账龄规则、异常标记、老板关心的报表口径。

一个医疗支付 agent 要判断商保赔付，它应该自动拿到患者授权、保单责任、诊断、费用明细、医保结果、药品目录、历史理赔、风控规则、人工复核条件。

这叫任务型上下文供给。

它不是知识库的升级，是信息管理范式的转变。

但这里也有一个赫拉利式的危险：系统供给什么，AI 就基于什么行动。

如果上下文错误，AI 会错。
如果上下文缺失，AI 会猜。
如果上下文过期，AI 会用旧现实行动。
如果上下文带有偏见，AI 会放大偏见。
如果上下文没有权限边界，AI 会越权。

未来一家企业真正稀缺的，不是知识库，是可信上下文管理系统。

它要知道哪些信息最新，哪些已经废弃；哪些有权威来源，哪些只是讨论；哪些需要人工确认，哪些不能给 AI 看；哪些可以用于自动执行，哪些只能用于辅助判断。

这件事还没有名字。但它会成为 AI 时代信息管理的新核心。

高效幻觉系统

到这里，必须诚实地谈一件事。

AI 辅助编程降低信息系统建设成本之后，世界不会自动变好。

我们可能得到更高效的医院结算、更精准的企业管理、更好的养老服务。我们也可能得到更多垃圾系统、更多形式主义、更多虚假指标、更多自动化压迫。

最大的风险不是没有信息。

最大的风险，是错误信息被系统化。

过去一个员工误解规则，影响有限。
未来一条 AI 生成的规则被写进系统，可能影响所有人。

过去一位老板拍脑袋，影响一次会议。
未来这条拍脑袋的规则被写入自动审批流，会长期运行。

过去一个基层单位为了应付检查做几张假表，是一次性材料。
未来 AI 可以每天自动生成看似完美的假秩序。

过去一个理赔员判断有偏差，还有人工讨论的空间。
未来如果模型和规则自动拒赔，患者可能连问题出在哪里都不知道。

我把这种系统称为高效幻觉系统。

它有数据，有报表，有看板，有流程，有自动化，有 AI 总结。它运转得无可挑剔。

它只是不接近真实。

它只是更快地产生一种看起来合理的秩序。

这正是赫拉利反复警告的事：一个网络越高效，并不代表越真实；秩序越严密，并不代表越智慧。

未来的信息系统设计者，每天都要在心里问自己几个问题：

这个系统减少了现实摩擦，还是只是增加了填报？
它让真实问题更早暴露，还是更容易被包装？
它帮助一线，还是只是帮助上级制造控制感？
它让弱者更容易申诉，还是让弱者更难反抗系统判断？
它能纠错，还是只会维护自己的权威？
它让组织更聪明，还是让组织更自信地犯错？

这些问题没有标准答案。但不问的人，注定会建出高效幻觉系统。

真正的分水岭：纠错能力

未来组织之间的差距，不会是数据多少的差距，也不会是 AI 能力的差距。

会是纠错结构的差距。

所有组织都会有更多 AI。
所有组织都会有更多数据。
所有组织都会有更多自动化。
所有组织都会生成更多文档、报表、代码和流程。

但并不是所有组织都会因此变聪明。

有的组织会因为 AI 变得更快、更透明、更能学习。
有的组织会因为 AI 变得更乱、更官僚、更自信地犯错。

分水岭就在纠错。

一个强组织会问：

数据从哪里来？
谁验证？
什么时候过期？
规则怎样版本化？
AI 输出如何测试？
异常如何报警？
用户如何申诉？
责任如何追溯？
错误如何转化为制度改进？

一个弱组织只会问：

能不能自动生成？
能不能快点上线？
能不能多出几个报表？
能不能让 AI 替人干活？

这两种组织正走向完全不同的未来。

前者把 AI 当成学习机器。
后者把 AI 当成幻觉机器。

个人也有一张信息网

这篇文章不只关于社会和企业。

每一个人也都是一张小型信息网。

你的事实层，是你记录了什么——读书笔记、工作日志、代码片段、错误清单、会议纪要、想法、情绪、目标。

你的秩序层，是这些记录如何改变你的行动——是否形成 checklist，是否形成决策原则，是否形成可复用的 prompt，是否形成项目模板。

你的纠错层，是你如何发现自己错了——是否复盘，是否记录预测和结果，是否承认误判，是否更新方法，是否定期清理过期的认知。

一个真正强大的个人信息系统，不是资料最多，而是能不断把经历变成经验，把经验变成方法，把方法变成行动，把行动结果再反馈回来。

这就是个人版的 Nexus。

AI 时代，这件事的难度并没有降低。它只是变得更可见。

你过去靠记忆维持的秩序，AI 会要求你显式化。你过去靠直觉做的判断，AI 会要求你提供上下文。你过去能蒙混过去的混乱，AI 会以系统化的方式暴露出来。

这是好事。它逼你成为一个更清醒的人。

一个新的稀缺角色：信息管理架构师

如果把这一切落到职业上，我会说，未来最稀缺的角色不是程序员，不是产品经理，也不是 AI 培训师。

是一种你可以叫它「信息管理架构师」的人。

他做的事情大致是这样：

进入一家企业，观察信息流。
找出关键事实散在哪里。
识别哪些流程靠人肉记忆维持。
判断哪些数据必须结构化，哪些不必。
设计最小可用的数据模型。
用 AI 辅助编程快速生成轻量系统。
部署内部 agent harness。
建立权限、审计、备份、报表、提醒。
把老员工的经验转成规则和 checklist。
把企业从「人脑管理」推向「半自动信息系统」。

这个角色的价值不在于写多少代码，而在于能判断：

什么值得系统化？
什么不值得系统化？
什么必须人工裁决？
什么可以自动化？
什么数据必须准确？
什么流程会制造负担？
什么指标会诱导造假？
什么权限不能开放？
什么动作必须留痕？
什么错误必须能回滚？

他其实是一种微型制度设计师。

AI 辅助编程越强，这个角色就越重要。因为实现成本下降之后，真正稀缺的就是判断力。

当任何人都能让 AI 生成一个系统时，问题就变成——

你生成的，是好秩序，还是坏秩序？

结语：我们要用信息网络建造一个怎样的现实

让我们回到《Nexus》的核心问题。

人类不直接生活在现实里，而是生活在被信息网络组织过的现实里。

医院如何记录病人，决定病人如何被治疗、如何被支付。
企业如何记录客户，决定客户关系如何被维护。
学校如何记录学生，决定学生如何被理解。
政府如何记录基层，决定资源如何被分配。
软件如何记录状态，决定流程如何运行。
AI agent 读取什么上下文，决定它如何行动。

这些记录从来不是中性的。它们定义什么被看见，什么被忽略；什么算事实，什么算异常；谁有权行动，谁必须等待；谁承担责任，谁拥有解释权。

AI 辅助编程降低了建造信息网络的边际成本。这会释放巨大的社会生产力。医院和商保会更好衔接。中小企业会拥有刚好够用的系统。养老、教育、制造、基层治理、专业服务都会被毛细血管式地信息化覆盖。

但赫拉利的警告必须留在每一个建造者的耳边：信息网络不一定通向真理。它也可能通向幻觉、权力、官僚主义和失控。

所以未来真正重要的问题，不是「AI 能不能写更多代码」，也不是「我们能不能建更多系统」。

是这样一个问题：

我们要用这些低成本的信息系统，建造一个更接近真实、更能纠错、更尊重人的现实——

还是建造一个更高效，但更虚假的秩序？

这才是信息管理的终极问题。

对个人而言，它决定你能不能把经历变成成长。
对企业而言，它决定它能不能把个人经验变成组织能力。
对社会而言，它决定资源能不能被更准确、更公平、更低摩擦地配置。
对 AI 时代而言，它决定非人类智能能否安全地进入人类的现实。

信息管理不是整理资料。

它是智能的地基，是组织的神经系统，是社会的连接方式，是权力的分配机制，是错误能否被修正的制度条件。

它是我们用信息网络建造现实的能力。

而 AI 辅助编程的到来，只是让这个古老问题——变得更迫切、更具体，也更值得每一个认真对待未来的人，重新坐下来学习一次。

[^1]: 国家医保局：山东医保商保一体化同步结算平台已实现全省上线，2024 年山东省 2760.30 万笔医保业务通过「一站式结算」完成，惠及 511.22 万参保人，累计报销 13.34 亿元。

[^2]: Yuval Noah Harari, Nexus: A Brief History of Information Networks from the Stone Age to AI (2024). 信息有“两种功能”的论述贯穿全书，尤其见关于“真理与秩序”的张力的章节。

[^3]: 同上。Harari 关于信息网络自我纠错机制的讨论，是《Nexus》中针对 AI 风险最核心的论证之一。

[^4]: Stack Overflow Developer Survey 2025: 84% 的受访者正在使用或计划使用 AI 工具；专业开发者中 50.6% 每天使用 AI 工具；同份调查显示开发者对 AI 输出准确性的不信任比例已超过信任比例。

[^5]: Gartner 预测：到 2028 年，75% 的企业软件工程师将使用 AI code assistants。开发者角色从“实现”转向“编排、约束和验证”，是本文基于这一趋势作出的延伸判断。

[^7]: OpenClaw 官方文档：skills 可以作为带 SKILL.md 的目录承载 agent 使用工具的方式；workspace 可承载与具体环境相关的长期上下文。

[^8]: 这里指 agent harness 在第三方技能、文件访问、命令执行、外部服务授权等能力上天然存在的治理风险。

发表于 | 分类于

从泥板账本到 AI Agent：信息网络如何建造现实

几千年前，在美索不达米亚的一座城市里，一个书记员把一袋麦子、一头羊、一笔债务，刻在泥板上。

对今天的人来说，这只是一个古老的记录动作。但在当时，这个动作已经改变了现实。

在麦子被刻上泥板之前，它只存在于仓库里，存在于某个人的记忆里，存在于交易双方的口头承诺里。泥板出现之后，麦子开始进入另一个世界：一个由符号、账本、税收、债务、库存和行政命令组成的世界。

这个世界不完全等同于物理现实，却能反过来支配物理现实。

谁欠谁多少粮食，谁必须交税，谁有权领取配给，谁没有完成义务，都可以被泥板决定。一个人可以不认识国王，也从未见过帝国，但只要他的名字出现在账本上，帝国就已经伸手进入了他的生活。

这就是信息网络最古老的力量。

它不仅记录现实。它建造现实。

今天，我们以为自己生活在钢筋、水泥、汽车、手机和互联网之中。但更深一层看，我们生活在无数信息网络之中。

医院的病历决定一个人如何被治疗。医保和商保的结算系统决定一笔医疗费用如何分摊。公司的 CRM 决定一个客户属于谁。学校的成绩和档案决定一个学生如何被理解。政府的统计口径决定资源如何被分配。代码仓库、测试、日志和监控决定一个软件系统如何运行。AI agent 读取什么上下文、拥有什么权限，决定它如何行动。

所以，信息管理不是整理资料。

信息管理是人类用符号、制度和机器建造现实的方式。

一、信息网络让陌生人生活在同一个现实里

如果一个部落只有几十个人，信息管理很简单。

谁欠谁一只羊，谁今天生病，谁昨天打猎失败，谁和谁发生冲突，这些事情可以靠记忆、闲谈和共同生活来管理。每个人都认识每个人。现实被保存在人的脑子里。

但当人类社会变大之后，记忆就不够用了。

城市需要知道仓库里有多少粮食。国家需要知道谁该服兵役。寺庙需要知道谁献了祭品。商人需要知道远方的合伙人是否守约。公司需要知道客户是否回款。医院需要知道患者用过什么药。软件团队需要知道某个接口为什么不能改。

规模一旦扩大，人类就必须发明一种东西：可共享的现实。

文字、账本、档案、合同、地图、货币、法律、数据库、知识库，都是可共享现实的技术。

它们让互不相识的人，可以围绕同一套事实和规则行动。

一个现代公司，就是这样一种信息网络。

销售说客户很重要，财务说客户欠款 90 天，仓库说库存不足，法务说合同条款有风险，老板说本月现金流很紧。如果这些信息散在不同人的微信、Excel、电脑硬盘和记忆里，公司就不是一个统一行动的组织，而是一群各自握着碎片现实的人。

公司真正成为公司，不只是因为它有营业执照、办公室和员工，而是因为它能把客户、合同、发票、库存、回款、售后、责任和决策连成一个共同现实。

同样，医院真正成为医院，不只是因为它有医生和病床，而是因为它能把身份、诊断、检查、药品、费用、病历、医保、商保和后续随访连成一个可信现实。

人类文明的扩大，就是信息网络不断扩大的过程。

但有一个问题也随之出现：可共享的现实，并不一定是真实的现实。

二、信息的目的不只是发现真理，也可能是制造秩序

现代人常常有一个天真的信念：信息越多，我们就越接近真理。

这并不一定成立。

信息有两种完全不同的功能。

第一种功能，是帮助我们发现世界。例如医学数据帮助医生发现疾病，财务数据帮助企业发现经营风险，测试日志帮助工程师发现 bug。

第二种功能，是把人组织起来。例如宗教经典组织信徒，法律条文组织国家，绩效指标组织公司，平台算法组织流量，行政表格组织基层治理。

发现真理和制造秩序，当然可以相互支持。但它们不是同一件事。

一个信息网络可以非常强大，却不一定真实。它可以把很多人高效组织起来，让他们按照某种规则行动，却未必让他们更接近现实。

历史上有许多这样的信息网络。

帝国的户籍、教会的名册、殖民地的地图、现代公司的 KPI、社交媒体的推荐算法，都能把复杂的人和事压缩成可管理的类别。压缩本身不是坏事，没有压缩就没有管理。但每一次压缩都会丢失一些东西。

一个活生生的人，进入系统后变成“参保人”“用户”“客户”“员工”“学生”“高风险账户”“低价值客户”。这些标签能帮助组织行动，也可能让组织忘记标签后面的人。

这就是信息管理的悖论。

没有信息网络，大规模协作无法发生。只有信息网络，人又可能被网络重新定义。

所以真正的问题不是要不要信息管理，而是要建造什么样的信息管理。

三、AI 编程让信息秩序第一次进入毛细血管

过去，信息系统是一种昂贵的东西。

大型银行可以建设核心系统，大型医院可以建设 HIS，大型企业可以上 ERP，国家可以建设医保平台，城市可以建设政务系统。主干道上的信息化，已经持续了几十年。

但社会并不只由主干道构成。

一个社区里老人有没有按时吃药？一个小工厂的哪道工序经常返工？一个外贸公司的哪笔应收账款快变成坏账？一个小诊所如何记录患者复诊？一个教培老师如何持续追踪学生的错题、情绪和目标？一个律所如何管理客户材料、合同版本和交付证据？

这些需求是真实的。

但在过去，它们常常不值得被系统化。

不是因为没人需要，而是因为定制开发太贵，标准 SaaS 太重，实施周期太长，维护成本太高，业务变化太快。于是大量现实只能停留在微信群、Excel、纸质单据、口头经验和老员工脑子里。

AI 辅助编程改变了这个经济学。

它当然能让程序员更快写代码。但更重要的是，它降低了小型信息系统的建造成本。过去需要一个小团队才能做的事，现在可能由一个懂业务的人、一个 AI coding 工具和一套验证流程逐步完成。

这会带来一种新的历史现象：

毛细血管信息化。

信息化不再只发生在银行、医院、政府和大企业这些主干道上，而会渗入每一个具体流程。它会进入养老院的护理记录，进入小工厂的质检照片，进入教培机构的成长档案，进入诊所的复诊提醒，进入外贸公司的回款预警，进入药房的特药核验，进入律所的材料流转。

每一个系统都很小，但数量巨大。

它们会像毛细血管一样，把软件带到现实世界的末端。

这可能是 AI 编程最深远的社会影响：不是让少数大公司拥有更强的信息系统，而是让无数小组织第一次可以拥有刚好够用的信息秩序。

四、医院、医保和商保：患者为什么曾经是接口

医疗支付提供了一个清晰例子。

患者看病产生大量信息：身份、诊断、检查、治疗、药品、耗材、费用、票据、病历、医保结算、商保责任、历史疾病、用药记录。每一项信息都可能影响谁来付钱、付多少钱、什么时候付。

如果医院、医保和商保之间没有可信的信息网络，患者就会变成接口。

医院把信息给患者。患者把发票、病历和费用清单拍照上传给保险公司。保险公司再用人工方式判断材料真假、责任范围、费用重复、药品目录和骗保风险。

换句话说，现实已经在医院发生了，但保险公司无法直接访问那个现实。它只能通过患者搬运的材料，重新拼接现实。

这就是低级信息网络的典型状态：信息存在，但不能以可信、结构化、授权可用的方式流动。

山东医保商保一体化同步结算平台的意义，就在于改造了这条链。国家医保局披露，2024 年山东省有 2760.30 万笔医保报销业务享受医保、惠民保“一站式结算”，惠及 511.22 万参保人，累计报销 13.34 亿元。

这不是简单的便民服务，而是现实组织方式的改变。

原来，一个患者出院后还要在医院、医保、商保之间来回奔波。现在，系统可以在结算时识别参保关系，计算基本医保和商业医疗保险的赔付金额，并把个人自付部分一起呈现出来。

这背后有三层结构。

第一层是事实：患者是谁，诊断是什么，费用是多少，医保报销多少，商保责任是什么。

第二层是秩序：谁有权读取数据，谁来计算赔付，谁承担费用，患者是否需要垫资，医院和保险公司如何结算。

第三层是纠错：身份错了怎么办，费用分类错了怎么办，保险责任判断错了怎么办，有人骗保怎么办，接口失败怎么办。

如果只有事实，没有秩序，数据只是一堆记录。如果只有秩序，没有纠错，系统就会以制度的名义规模化犯错。

创新药支付会让这个问题更明显。

许多创新药不是完全没有价值，而是缺乏可持续支付机制。商业保险要设计产品，需要知道真实风险、用药周期、疗效、停药率、合规使用情况和欺诈风险。没有信息，就没有精算。没有精算，就没有保险。没有保险，许多昂贵疗法就很难被普通人触达。

所以医疗信息管理不只是让报销更快。

它会改变哪些治疗可以被支付，哪些药物可以被纳入保障，哪些患者可以获得新的机会。

信息网络不仅反映现实。它扩大或缩小现实中的可能性。

五、AI Agent：一种新的非人类书记员

过去的信息系统，大多是被动的。

数据库不会自己决定拒赔。文档库不会自己修改流程。报表不会自己给员工发提醒。搜索引擎不会自己执行 SQL、发邮件、部署代码或生成合同。

AI agent 改变了这一点。

当一个 agent 能够读取文件、调用工具、访问数据库、操作浏览器、发送消息、修改代码、生成报表、触发工作流时，它就不再只是一个回答问题的工具。

它变成了信息网络中的行动者。

这是一种新的历史角色：非人类书记员。

古代书记员把谷物、税收和债务写进泥板，帮助国家管理人。现代 AI agent 可以把自然语言中的意图转成字段、表单、脚本、流程、权限、提醒、审计、测试和报表，帮助组织管理现实。

OpenClaw 这类 agent harness 的意义，不只是聊天窗口里多了一个聪明助手。它把模型放进一个有工作区、有工具、有技能、有长期上下文的运行环境中。技能可以由 SKILL.md 这样的文件定义，工作区可以承载具体环境的上下文，工具可以让 agent 对外部系统采取行动。

这相当于给非人类书记员配备了眼睛、手、记忆和一套制度手册。

老板说：列出超过 30 天未回款的客户。agent 可以查询合同、发票、银行流水，生成清单。

销售说：客户同意新报价。agent 可以更新客户状态，生成合同草稿，提醒财务开票。

财务上传银行流水。agent 可以匹配合同和发票，标记异常项。

售后收到投诉。agent 可以生成工单，关联客户、产品、合同和历史问题。

这看起来像效率工具。但更深层看，它是在生产制度。

一个原来靠微信群催款的企业，开始拥有回款提醒制度。一个原来靠护士记忆复诊的诊所，开始拥有复诊任务系统。一个原来靠纸质记录服务的养老机构，开始拥有护理证据链。

AI agent 的危险，也恰好来自这里。

它不是太懒，而是太勤奋。

它可以不断生成流程、表格、指标、看板、规则、提醒和评分体系。它可以把所有例外流程化，把所有沟通工单化，把所有人放入某种标签和分数中。

如果没有人类判断，它可能成为一种自动官僚。

自动官僚不会疲惫，不会抗议，也不会主动质疑自己的指标是否荒谬。它只会高效执行。

但高效执行不等于接近真实。

六、三个闸门：事实、秩序和纠错

任何信息系统，无论是古代帝国的税册、现代医院的结算平台，还是未来企业内部的 AI agent，都可以用三个闸门来判断。

第一个闸门是事实。

系统是否准确记录了发生的事情？患者身份、诊断、费用、药品是否准确？客户、合同、发票、回款是否准确？需求、设计、代码、测试、日志是否准确？

许多组织第一关就过不了。数据没有记录，记录不完整，字段口径不一致，关键事实藏在聊天记录里，系统里的数据和真实情况分离。

事实层不稳，后面所有智慧都会变成幻觉。

第二个闸门是秩序。

事实如何改变行动关系？

一个客户欠款 60 天，只是事实。谁去催，何时催，是否暂停发货，是否进入风险名单，这是秩序。

一个患者使用创新药，只是事实。是否符合商保目录，是否需要医生确认，是否触发随访，是否进入赔付流程，这是秩序。

一个测试失败，只是事实。是否阻断发布，是否通知负责人，是否回滚，是否触发事故复盘，这是秩序。

秩序层是信息系统最有权力的地方。

因为谁定义流程，谁就在定义行动。谁定义指标，谁就在定义重要性。谁定义权限，谁就在定义谁能看见、谁能改变现实。

第三个闸门是纠错。

事实错了怎么办？规则错了怎么办？系统错了怎么办？AI 错了怎么办？

有没有测试、校验、监控、审计、申诉、人工复核、版本管理、回滚、异常处理和事故复盘？一个弱系统会把错误藏起来。一个强系统会把错误变成下一次制度改进。

AI 时代最关键的不是生成更多事实，也不是生成更多流程，而是设计更强的纠错结构。

因为 AI 会同时加速事实生产和秩序生产。它会生成更多文档、更多代码、更多表格、更多指标、更多审批节点。如果没有纠错，错误也会获得自动化的翅膀。

未来组织之间的差距，不是信息多少的差距，而是纠错能力的差距。

强组织会问：数据从哪里来？谁验证？什么时候过期？规则如何版本管理？AI 输出如何测试？异常如何报警？用户如何申诉？责任如何追溯？错误如何进入复盘？

弱组织只会问：能不能自动生成？能不能快点上线？能不能多出几个报表？能不能让 AI 替人干活？

前者把 AI 变成学习机器。后者把 AI 变成幻觉机器。

七、从搜索时代，到上下文供给时代

过去的信息管理围绕搜索展开。

文档很多，你来搜。知识库很大，你输关键词。搜索结果给你，剩下自己判断。

这种模式有一个隐含假设：人是行动者，系统是资料库。

但 AI agent 时代，这个假设会改变。

人往往不是想找资料，而是想完成任务。

帮我修改支付状态机。帮我排查这个 bug。帮我判断客户是否有回款风险。帮我生成本周经营报告。帮我判断某个患者是否满足保险责任。帮我给学生制定下阶段学习计划。

完成任务需要的不是资料列表，而是正确上下文。

一个 coding agent 修改支付状态机时，应该自动拿到需求背景、状态机文档、接口契约、数据库表结构、历史事故、下游依赖、测试用例、监控指标和回滚方案。

一个经营 agent 生成回款报告时，应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进记录、历史催款记录、账龄规则和异常标记。

一个医疗支付 agent 判断商保赔付时，应该自动拿到患者授权、保单责任、诊断、费用明细、医保报销结果、药品目录、历史理赔和人工复核条件。

这意味着信息管理会从“搜索资料”变成“供给上下文”。

未来真正重要的系统，不只是知识库，而是可信上下文管理系统。

它要知道哪些信息最新，哪些已经废弃，哪些来自权威来源，哪些只是讨论，哪些需要人工确认，哪些不能给 AI 看，哪些可以用于自动执行，哪些只能用于辅助判断。

上下文供给错了，AI 就会基于错误现实行动。上下文缺失，AI 就会猜。上下文过期，AI 就会使用旧现实。上下文没有权限边界，AI 就会越权。

于是，一个古老问题在 AI 时代重新出现：谁有权定义现实？

过去，这个权力属于书记员、官僚、神职人员、会计、档案管理员、数据库管理员、产品经理和管理者。未来，它还会属于那些设计 AI 上下文和 agent 权限的人。

八、更高效的幻觉系统

AI 辅助编程会让世界出现许多好系统。

老人护理可以更连续，学生成长可以更细致，小工厂生产可以更透明，医疗支付可以更顺畅，中小企业可以不再完全依赖老板记忆和微信群。

但同一种技术也可以制造坏系统。

一个坏系统不一定看起来很坏。它可能有漂亮的界面、实时的看板、自动生成的总结、完整的流程、严密的指标和看似客观的评分。

它的问题是：它不接近真实。

它只是把某种偏见、某种偷懒、某种权力意志、某种拍脑袋规则，写进了系统。

过去一个老板的拍脑袋决定，可能只影响一次会议。未来这个决定可以被写进自动审批流，长期运行。

过去一个基层单位为了应付检查做假表，只是一份材料。未来 AI 可以每天自动生成看似完美的假秩序。

过去一个理赔员判断错误，患者还可能找到人争论。未来如果模型和规则自动拒赔，患者可能连问题出在哪里都不知道。

这就是更高效的幻觉系统。

它让组织更快、更整齐、更自信，却未必更聪明。

这种风险并不新。人类历史上，信息网络一直可能制造幻觉。只是 AI 让幻觉拥有了新的速度、新的规模和新的执行能力。

九、中小企业信息管理架构师

当任何人都可以让 AI 生成代码时，真正稀缺的就不是代码，而是判断。

未来可能出现一种新的角色：中小企业信息管理架构师。

这个人不是传统程序员，也不是传统咨询顾问，更不是单纯教别人使用 AI 工具的培训师。

他的工作是进入一家企业，观察信息如何流动。

关键事实散在哪里？哪些流程靠老员工记忆维持？哪些数据必须结构化？哪些流程值得系统化？哪些事情必须人工裁决？哪些权限不能开放？哪些指标会诱导造假？哪些动作必须留痕？哪些错误必须能回滚？

然后，他用 AI 辅助编程快速生成轻量系统，部署内部 agent harness，接入文件、表格、邮件、飞书、企微、数据库，建立权限、审计、备份、报表和提醒，把老员工经验转成规则、模板和 checklist。

这个角色的价值，不在于把所有东西自动化。

恰恰相反，他最重要的能力，是知道什么不该自动化。

有些问题需要记录，有些问题需要流程，有些问题需要谈判，有些问题需要组织变革，有些问题需要老板亲自做裁决。

AI 可以把秩序执行得更快，但不能替人判断秩序是否正当。

实现成本越低，判断力越值钱。

这也是为什么 AI coding 时代，真正重要的人不只是会写代码的人，而是能设计可执行、可验证、可纠错的信息网络的人。

十、信息管理的终极问题

人类不只是生活在自然现实里。

我们还生活在信息网络建造的现实里。

一个人在医院里如何被记录，决定他如何被治疗和支付。一个客户在公司里如何被记录，决定他如何被维护或放弃。一个学生在学校里如何被记录，决定他如何被理解。一个基层问题在政府系统里如何被记录，决定资源是否会抵达。一个 bug 在工程系统里如何被记录，决定它会被修复、忽略，还是再次发生。

AI agent 出现以后，这个问题变得更紧迫。

因为信息网络不再只是记录和传播信息。它开始生成信息、解释信息、做出判断、采取行动。

过去我们管理的是信息。现在我们还要管理基于信息行动的智能体。

这要求新的制度能力：上下文管理、工具权限管理、行动边界管理、人机责任分配、模型输出验证、自动化审计、异常回滚、多 agent 协作治理、提示注入防护、敏感数据隔离、人工审批节点。

这些听起来像技术细节，实际上是未来组织治理的核心。

因为当 AI agent 能够访问文件、数据库、邮件、代码仓库、财务系统、客户系统和生产环境时，它就不再是一个助手。它已经成为组织行动网络的一部分。

所以，AI 编程的真正问题不是“代码会不会更便宜”。

代码当然会更便宜。

真正的问题是：当建造信息网络的成本下降之后，我们会建造什么样的现实？

我们会建造一个更接近真实、更能纠错、更尊重人的现实，还是建造一个更高效、更整齐、更虚假的秩序？

这才是信息管理的终极问题。

它不是资料整理问题。它是智能的地基，是组织的神经系统，是社会的连接方式，是权力的分配机制，也是错误能否被修正的制度条件。

几千年前，书记员把麦子刻在泥板上，人类第一次大规模把现实转化为可管理的符号。

今天，AI agent 正在把自然语言中的意图转化为流程、代码、权限、报表和行动。

泥板、账本、数据库和 AI agent 之间，隔着几千年的技术史，却连接着同一个问题：

我们如何用信息网络建造现实？

以及，当这个网络错了以后，我们是否还有能力把现实夺回来？

参考资料

发表于 | 分类于

信息管理的终极问题：AI 编程真正改变的不是代码，而是现实

有一个词，我们一直把它理解小了：信息管理。

一说信息管理，很多人想到的是文档、表格、知识库、ERP、CRM、OA、Notion、飞书、Confluence。它听起来像一种行政工作，最多是管理效率问题：资料别丢，文件好找，流程能走。

但如果把镜头拉远一点，信息管理真正管理的不是资料，而是现实。

一个公司能不能知道客户欠了多少钱，是信息管理。一个医院能不能把诊疗、医保、商保、药品和结算连起来，是信息管理。一个小工厂能不能知道哪批货快延期、哪道工序频繁出错，是信息管理。一个 AI agent 能不能拿到正确上下文、在正确权限下行动、出错后能不能追溯，也是信息管理。

这篇文章的核心判断只有一句：

AI 辅助编程真正降低的不是写代码的成本，而是建造信息秩序的成本。

如果这个判断成立，那么 AI coding 的意义就不只是程序员生产效率提升，而是大量过去“不值得系统化”的现实流程，会第一次拥有被软件化、结构化、自动化、可追溯化的机会。

这件事会释放巨大生产力，也会制造新的风险。

因为信息系统从来不是中性的。它决定什么被看见，什么被忽略，谁能行动，谁承担责任，什么算事实，什么算异常，以及错误能不能被修正。

一、先纠正一个天真的想法：信息越多，不等于越接近真理

赫拉利在《Nexus》里提供了一个很大的视角：人类历史不仅是工具史、战争史、经济史，也是一部信息网络史。

《Nexus》的官方介绍把问题放得很大：从石器时代到 AI，信息网络如何塑造世界，以及信息与真理、官僚制与神话、智慧与权力之间的复杂关系。

这里最关键的提醒是：信息不天然等于真理。

信息至少有两张脸。

第一张脸，是帮助人类发现现实。比如病历记录帮助医生判断病情，财务流水帮助企业判断经营状态，测试日志帮助程序员发现 bug。

第二张脸，是把人连接起来、组织起来、动员起来、约束起来。宗教经典、帝国文书、公司制度、绩效指标、平台算法，都是信息网络。它们未必更真实，但它们能让大量人按照同一套规则行动。

所以一个信息网络越强大，不代表它越智慧。它可能只是更擅长分类、监控、分配、动员和制造服从。

这也是为什么 CRM 不是一个简单的客户表。

一个公司上线 CRM，看起来只是录入客户名称、联系人、合同金额和回款状态。但它实际上在重新定义企业现实：

谁是重要客户？哪个销售真正拥有客户关系？欠款由谁跟进？客户投诉算不算正式流程？老板相信销售口头汇报，还是相信系统数据？员工离职后，客户关系属于个人，还是属于公司？

CRM 不是工具，它是组织内的信息权力重分配。

医疗支付也一样。

过去患者看完病，要自己垫钱，自己保存发票、病历、费用清单，再上传给保险公司理赔。表面看是流程低效，深层看是医院、医保、商保之间缺少可信的信息网络，于是患者被迫成为信息搬运工。

国家医保局披露，山东医保商保一体化同步结算平台已经全省上线。仅 2024 年，山东省就有 2760.30 万笔医保报销业务享受医保、惠民保“一站式结算”，惠及 511.22 万参保人，累计报销 13.34 亿元。

这个案例的意义不只是“少交几张纸”。它意味着原本分散在患者、医院、医保、商保之间的低信任信息链，被改造成了一个可识别、可计算、可结算、可监管的信息网络。

信息管理的本质，是把现实变成可以共同确认、共同执行、共同纠错的结构。

二、信息管理的四个底层功能

为什么信息管理这么重要？可以拆成四个功能：感知、记忆、协调、纠错。

第一，信息管理是组织的感知系统。

组织并不直接接触现实。它通过订单、合同、票据、病历、日志、报表、会议纪要、客户反馈、监控指标来感知现实。

如果这些信息没有被记录，组织就看不见。如果这些信息被错误记录，组织就看错了。如果这些信息传递太慢，组织就滞后于现实。

很多小企业并不是没有业务，而是老板无法实时看见业务。客户在哪个销售手上，合同有没有续签，发票有没有开，钱有没有到账，售后有没有处理，库存够不够，下周哪个订单会延期，这些问题散在微信、Excel、记忆和口头承诺里。

现实发生了，但组织没有形成统一感知。

第二，信息管理是组织的记忆系统。

人会遗忘，组织也会遗忘。

为什么这个系统当初这么设计？为什么某个接口不能改？为什么某个客户有特殊条款？为什么去年某次上线失败？为什么某个供应商被拉黑？

如果没有信息管理，这些经验会随着人员流动、项目结束、群聊沉底而消失。组织就会不断重复犯错。

所以信息管理的价值，是把“某个人知道”变成“这个系统知道”。

第三，信息管理是组织的协调系统。

多人协作的前提，是大家共享同一个现实模型。目标是什么，谁负责什么，当前进度是什么，依赖关系是什么，完成标准是什么，风险由谁处理，变更发生在哪里。

很多项目混乱，不是因为大家不努力，而是因为每个人都活在不同版本的现实里。需求写在一个地方，设计写在另一个地方，代码又是第三套逻辑，测试不知道真实意图，运维不知道上线风险，老板看到的是被美化过的进度报告。

第四，信息管理是组织的纠错系统。

这是最容易被忽略、但最关键的一层。

系统不可能永远正确。数据会错，规则会错，模型会错，人会错，AI 也会错。成熟的信息系统，不是不犯错，而是能快速发现错误、定位错误、修正错误，并把错误转化为下一次的制度改进。

软件工程师对这一点非常熟悉。

测试是纠错，日志是纠错，监控是纠错，审计是纠错，回滚是纠错，代码 review 是纠错，事故复盘是纠错，权限隔离是预防性纠错。

一个没有纠错机制的信息系统，会以系统权威的方式犯错。

这比普通错误更危险。

三、AI 编程改变了信息系统的经济学

过去几年，大家讨论 AI 辅助编程，重点常常放在“代码生成”。

这个视角太窄。

Stack Overflow 2025 开发者调查显示，AI 工具已经高频进入开发流程，专业开发者中有一半左右每天使用 AI 工具；但同一份调查也显示，开发者对 AI 输出准确性的主动不信任比例高于信任比例。

这说明 AI coding 的真实状态不是“AI 替代程序员”，而是“AI 高速生成，人类必须验证”。

Gartner 的预测也很类似：到 2028 年，75% 的企业软件工程师会使用 AI code assistants。开发者角色正在从纯粹实现，转向约束设计、上下文供给、agent 编排和结果验证。

但这只是第一层变化。

更深的变化是：当代码生产成本下降后，很多过去不值得做的信息系统，开始变得值得做。

过去做一个小系统，成本不只在写代码。要沟通需求，要设计数据模型，要写前后端，要接权限，要部署，要培训用户，要修 bug，要适应流程变化，还要长期维护。

一个小企业想做客户回款提醒系统，找外包公司不划算。一个小工厂想做质检异常闭环，买大型 MES 太重。一个养老机构想做护理记录和长护险结算，定制开发不划算。一个教培机构想做学生成长档案，标准 SaaS 又不贴合。

于是这些需求长期被压抑。

AI 辅助编程的意义，不是让大型系统便宜一点，而是让大量长尾流程第一次可以被系统化。

我把它叫做：

毛细血管信息化。

过去信息化主要发生在主干道：银行核心系统、大型医院 HIS、国家医保平台、大型 ERP、城市级政务系统、大企业 CRM。

未来信息化会进入毛细血管：某个社区的老人巡访，某个小工厂的质检流程，某个外贸公司的回款提醒，某个老师对学生长期学习状态的记录，某个律所的客户材料流转，某个药房的特药支付和处方核验。

这些系统每一个都不大，但数量巨大。它们对应现实世界里无数尚未被软件覆盖的流程。

软件正在从大机构的基础设施，变成具体流程的低成本管理层。

四、医院和商保，是一个非常好的样本

医疗支付是典型的信息管理问题。

患者看病产生的信息包括身份、诊断、检查、治疗、药品、耗材、费用、票据、病历、结算、医保报销、商保责任、历史疾病和用药记录。每一项信息都可能影响支付结果。

过去商保理赔麻烦，不是因为保险公司不知道用户希望快赔，而是因为它缺少可信、结构化、合规可用的数据链。

患者上传照片，保险公司要判断发票是不是真的，病历是否完整，诊断是否符合责任，药品是否属于保障范围，费用是否重复报销，是否存在骗保风险。

这等于保险公司要从一堆材料里重建现实。

当医保与商保一站式结算出现，信息网络就升级了。事实层记录患者是谁、费用是多少、医保报销多少、商保可赔多少。秩序层规定哪些机构有权读取哪些数据、谁来计算赔付、医院如何出具结算单、患者是否需要垫资。纠错层处理身份匹配错误、费用分类错误、责任判断错误、接口失败和欺诈风险。

这三层缺一不可。

创新药支付会把这个问题推向更深处。国家医保局关于“双目录”的文章提到，创新药支付正在从事后补偿延伸到全程服务，一些地方已经在探索“医保+商保”一站式秒赔和全流程数据对接。

这意味着医疗信息管理正在从“报销一笔钱”，变成“管理一条健康服务链”。

诊断、处方、购药、支付、用药、随访、疗效、不良反应、再次治疗、真实世界数据、保险产品迭代、医保目录谈判，这是一整条链。

没有信息，就没有精算。没有精算，就没有可持续产品。没有可持续产品，很多高值创新药就很难进入支付体系。

信息管理不仅提高效率，还会改变哪些事情可能发生。

五、中小企业真正需要的，不是 SaaS，而是刚好够用的秩序

中国大量中小企业不是没有管理，而是管理高度依赖人脑、微信群、Excel、口头承诺和个人经验。

客户信息在销售微信里。报价单在 Excel。合同在网盘。发票在财务电脑。回款靠老板追问。售后靠销售记忆。库存靠老员工知道。员工离职后，客户关系和历史信息一起消失。

过去很多人会说：上 CRM，上 ERP。

但现实中，中小企业常常上不起来。标准 SaaS 太重，字段不贴合，员工不愿意填，流程变动快，老板想要的报表又很个性化。

AI 辅助编程带来的机会，是让企业可以逐步长出刚好够用的信息系统。

不是一上来买一个庞然大物，而是从最痛的地方开始。

先把客户、合同、应收账款整理成一个小系统。再把销售跟进记录接入。再自动生成回款提醒。再接发票和银行流水。再生成每周经营报表。再把售后问题转成工单。再让 AI agent 每天巡检异常。

这个过程过去需要产品经理、后端、前端、运维、实施顾问共同参与。现在不代表完全不需要人，但每一步的成本会显著下降。

OpenClaw 这类 agent harness 的意义，也应该放在这里理解。它的关键不是聊天，而是把模型放进一个带有工作区、工具、技能、权限和长期上下文的运行环境。它不只是回答问题，而是能执行流程。

在企业内部，它可以成为一种“轻量信息系统工厂”。

老板说：每天早上列出超过 30 天未回款的客户。agent 去查合同、发票、收款记录，生成清单。

销售说：这个客户同意了新报价。agent 更新客户状态，生成合同草稿，提醒财务开票。

财务上传银行流水。agent 尝试匹配合同和发票，标记异常项。

售后收到客户投诉。agent 生成工单，关联客户、产品、合同和历史问题。

但这里有一个底线：

AI 可以帮助企业系统化流程，但不能替企业做业务裁决。

如果老板自己也说不清客户分类规则，如果销售不愿录入关键事实，如果财务数据本身混乱，如果公司内部权责不清，那么 agent 只能把混乱自动化。

信息系统不能凭空创造秩序。它只能把已有秩序显性化，把隐性秩序结构化，把混乱暴露出来，或者在坏情况下把混乱固化下来。

六、Agent harness 是微型制度生产机器

如果从《Nexus》的视角看，OpenClaw 或类似 agent harness 不应该只被理解成 AI 工具。

它更像一台微型制度生产机器。

因为它可以把自然语言中的意图，转化成表单、字段、数据库、流程、权限、脚本、报表、提醒、审批、审计、测试和文档。

一家企业原来靠微信群催款，agent 可以把它变成回款提醒制度。一家诊所原来靠护士记患者复诊，agent 可以把它变成复诊任务系统。一个小工厂原来靠老师傅判断设备异常，agent 可以把它变成巡检记录、异常分类和维修闭环。

这就是制度生产。

但制度生产有两面性。

好的制度可以降低摩擦、减少误判、保护弱者、提升效率、让责任清晰。坏的制度可以制造形式主义、增加填报负担、强化监控、固化偏见、把人困在不合理流程里。

AI agent 的危险在于，它很勤奋。它能不断生成流程、表格、指标、看板、规则、提醒。如果没有人类判断，它可能变成一个自动官僚。

自动官僚的特点是：它能把所有事情表格化，把所有行为指标化，把所有例外流程化，把所有沟通工单化，把所有人放进某种评分体系里。

但它未必知道这些东西是否接近现实，是否减少负担，是否提升智慧。

所以企业内部部署 agent harness 时，不能只问“它能做什么”，还要问：

它能看什么？它能改什么？它能代表谁行动？哪些动作必须人工确认？谁能修改它的规则？它引用的数据从哪里来？它生成的报表如何验证？它错了以后谁负责？它是否把管理者的偏见系统化？

一个真正可用的企业内部 agent harness，必须同时具备工具能力、权限边界、审计日志、沙箱环境、人工审批、数据治理和回滚机制。

没有这些，它只是一个很强但不安全的自动化入口。有了这些，它才可能成为企业信息管理的基础设施。

七、所有信息系统，都可以用三层模型看

为了把讨论落到实践，可以用一个三层模型理解信息管理系统：事实层、秩序层、纠错层。

事实层回答：发生了什么？

它包括数据、文档、记录、日志、表单、票据、病历、合同、代码、监控指标、聊天记录、邮件和交易流水。

事实层的关键标准是准确、及时、完整、结构化、可追溯。很多组织的问题，第一层就失败了。数据没有记录，记录不完整，字段口径不一致，关键事实藏在聊天记录里，系统里的数据和真实情况不一致。

事实层不稳，后面所有分析都会漂。

秩序层回答：这些事实如何改变行动关系？

一个客户欠款 60 天，这是事实。谁去催，什么时候催，是否暂停发货，是否进入风险名单，这是秩序。

一个测试失败，这是事实。是否阻断发布，是否通知负责人，是否回滚，是否记录缺陷，这是秩序。

信息系统最强大的地方就在第二层。它不是记录现实，而是组织现实。

这也是权力最容易隐藏的地方。谁定义流程，谁就在定义行动。谁定义指标，谁就在定义什么重要。谁定义权限，谁就在定义谁能看见、谁能行动。

纠错层回答：如果事实错了、规则错了、系统错了，如何发现和修正？

它包括测试、校验、监控、审计、申诉、人工复核、版本管理、回滚、异常处理、抽样检查、事故复盘和制度更新。

这是 AI 时代最关键的一层。

因为 AI 会加速事实层的生成，也会加速秩序层的生成。它能快速生成文档、流程、代码、规则、报表和审批节点。但如果没有纠错层，错误也会被快速放大。

未来信息管理最值钱的，不是事实层，也不是秩序层，而是纠错层。

真正成熟的人不会只问“能不能自动化”，而会问：

这个系统错了以后怎么办？

八、信息管理会从搜索，变成上下文供给

传统信息管理很大程度上围绕搜索展开。

资料很多，你来找。文档很多，你来搜。知识库很大，你输关键词。搜索结果给你，剩下自己判断。

AI agent 时代，这个模式会变。

因为用户往往不是想找资料，而是想完成任务。

帮我改这个模块。帮我排查这个 bug。帮我判断这个客户是否有回款风险。帮我生成本周经营报告。帮我看这个患者是否满足保险责任。

完成任务所需的信息，不应该完全靠人搜索，而应该由系统主动供给。

一个 coding agent 要修改支付状态机，它应该自动拿到相关需求背景、状态机文档、接口契约、数据库表结构、历史事故、下游依赖、测试用例、监控指标和上线回滚方案。

一个企业经营 agent 要生成回款报告，它应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进记录、历史催款记录、账龄规则和异常标记。

这叫任务型上下文供给。

所以信息管理会从“文档整理”升级成“上下文基础设施”。

但这里也有危险。系统供给什么，AI 就基于什么行动。如果上下文错误，AI 会错。如果上下文缺失，AI 会猜。如果上下文过期，AI 会用旧现实行动。如果上下文没有权限边界，AI 会越权。

未来企业真正需要的，不只是知识库，而是可信上下文管理系统。

它要知道哪些信息最新，哪些信息废弃，哪些信息有权威来源，哪些只是讨论，哪些需要人工确认，哪些不能给 AI 看，哪些可以用于自动执行，哪些只能用于辅助判断。

九、最大风险：建成一个更高效的幻觉系统

到这里，不能只讲机会。

AI 辅助编程降低信息系统建设成本后，世界不会自动变好。我们可能得到更高效的医院结算、更精准的企业管理、更好的养老服务；也可能得到更多垃圾系统、更多形式主义、更多虚假指标、更多自动化压迫。

最大的风险不是没有信息，而是错误的信息被系统化。

过去一个员工误解规则，只影响局部。未来一个 AI 生成的规则进入系统，可能影响所有人。

过去一个老板拍脑袋，只影响一次会议。未来这个拍脑袋规则被写进自动审批流，就会长期运行。

过去一个基层单位为了应付检查做假表，只是一次性材料。未来 AI 可以每天自动生成看似完美的假秩序。

这就是高效幻觉系统。

它有数据，有报表，有看板，有流程，有自动化，有 AI 总结。但它不接近真实。它只是更快地产生一种看起来合理的秩序。

所以未来信息管理设计者必须不断问：

这个系统减少了现实摩擦，还是增加了填报？它让真实问题更早暴露，还是更容易被包装？它帮助一线工作，还是帮助上级制造控制感？它让弱者更容易申诉，还是让他们更难反抗系统判断？它能纠错，还是只会维护自己的权威？

十、未来最稀缺的角色：信息管理架构师

如果把前面的判断落到职业和商业机会，我会提出一个角色：

中小企业信息管理架构师。

这个人不是传统程序员，不是传统咨询顾问，也不是纯 AI 培训师。

他进入一家企业，观察信息流，找出关键事实散在哪里，识别哪些流程靠人肉记忆维持，判断哪些数据必须结构化，设计最小可用数据模型，用 AI 辅助编程快速生成轻量系统，部署内部 agent harness，建立权限、审计、备份、报表、提醒，把老员工经验转成规则和 checklist。

这个角色的价值不在于写多少代码，而在于判断：

什么值得系统化？什么不值得系统化？什么必须人工裁决？什么可以自动化？什么数据必须准确？什么流程会制造负担？什么指标会诱导造假？什么权限不能开放？什么动作必须留痕？什么错误必须能回滚？

AI 辅助编程越强，这个角色越重要。

因为实现成本下降后，真正稀缺的是判断力。

当任何人都能让 AI 生成一个系统时，问题就变成：

你生成的是一个好秩序，还是坏秩序？

结语：信息管理不是整理资料，而是建造现实

我们可以回到最开始的问题：信息管理为什么重要？

因为人类不是直接生活在现实里，而是生活在被信息网络组织过的现实里。

医院如何记录病人，决定病人如何被治疗和支付。企业如何记录客户，决定客户关系如何被维护。学校如何记录学生，决定学生如何被理解。政府如何记录基层，决定资源如何被分配。AI agent 读取什么上下文，决定它如何行动。

AI 辅助编程降低了建造信息网络的成本。这会释放巨大的社会生产力。医院和商保可以更好衔接，中小企业可以拥有刚好够用的系统，养老、教育、制造、基层治理、专业服务都可以被毛细血管式信息化覆盖。

但赫拉利提醒我们，信息网络不一定通向真理。它也可能通向幻觉、权力、官僚主义和失控。

所以未来最重要的问题不是“如何让 AI 写更多代码”，也不是“如何建更多系统”，而是：

我们要用这些低成本信息系统，建造一个更接近真实、更能纠错、更尊重人的现实，还是建造一个更高效但更虚假的秩序？

这才是信息管理的终极问题。

参考资料