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 不是仪式，它是可伸缩的控制面。

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 从“我看了一遍”变成“我攻击了四个方向”。

从混乱到可控：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 让开发还能跑在路上。

如何约束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
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 时代代码会来得越来越快。越是这样，我们越需要把测试从一个动作，升级成一条证据链。

广东物理类530分12万名志愿怎么报

有同学问我：妹妹今年广东高考，普通类物理方向，530分，省排名大概12万名，志愿应该怎么考虑？

我整理了一份很长的参考资料。这里放一个简洁版，适合先给家里人看，用来统一思路。先说结论：这个分数不是没得选，但也不是可以随便冲。最重要的不是“530分”这三个字，而是“12万名左右”这个排位。

广东2026年普通类物理本科线是425分，特殊类型招生控制线是539分，地方专项计划物理线是509分。也就是说，530分比本科线高105分，比特控线低9分，比地方专项线高21分。如果孩子有地方专项资格，可以单独研究；如果没有，就不要把它当作主要路径。

真正填志愿时，要以广东省教育考试院志愿填报系统、2026年招生专业目录、高校招生章程和体检结论为准。这篇文章只是帮助家庭讨论，不是最终志愿表，也不承诺录取结果。

先看排位，不要只看分数

高考志愿最容易犯的错误，是拿今年的分数直接套去年的学校。比如去年530分能去哪里，今年530分就照着填。这样很危险，因为每年试卷难度、考生人数、招生计划和专业热度都会变。

更可靠的办法，是看排位。2025年广东物理类530分累计大约在11.3万名附近。今年如果530分约12万名，说明同样分数对应的位置略靠后。所以这位考生不能只按“去年530分”判断，而要按“12万名左右”判断。

我的建议是，用2025年投档最低排位做初筛：

• 冲：去年最低排位大约10万到11.5万。
• 稳冲和稳：去年最低排位大约11.5万到12.8万。
• 保：去年最低排位大约12.8万到14.5万。
• 兜底：去年最低排位大约14.5万以后，必要时看到15万到18万。

这只是粗略区间，不是机械公式。某个专业组今年计划减少、专业变热、选科要求变化，风险都会上升；如果计划增加、专业组拆分、热度下降，机会也可能变大。

广东填的是“院校专业组”

广东新高考不是简单填45所大学，而是填45个院校专业组。普通类本科和专科，物理、历史各有1个平行志愿组，每个志愿组可以填45个院校专业组；每个院校专业组里面可以填6个专业志愿，并选择是否服从专业调剂。

这个规则非常重要。因为同一所学校，不同专业组的录取难度、专业范围、学费、校区、再选科要求，可能完全不同。

比如一所学校可能有物理不限组、物理加化学组、中外合作组、地方专项组、联合培养组。你不是笼统地填“某某大学”，而是在填“某某大学某个专业组”。最后被检索、被投档的，也是这个专业组。

很多家庭的失误就发生在这里：只看学校名字，没看专业组里到底有什么专业。结果投档进去了，却被调剂到完全不想读的专业。

45个志愿怎么分

如果家庭目标是“尽量上公办本科，专业不要太离谱，省内省外都可以比较”，可以大致这样分：

• 6到8个冲刺志愿，放去年最低排位约10万到11.5万的专业组。
• 10到14个核心志愿，放去年最低排位约11.5万到12.8万的专业组。
• 14到16个稳妥志愿，放去年最低排位约12.8万到14.5万的专业组。
• 7到10个保底志愿，放去年最低排位约14.5万以后的专业组。

前面的“冲”不能是纯许愿。冲刺志愿也要满足一个底线：如果真录了，专业组内的调剂结果也能接受。

后面的“保底”更不能随便填。保底不是找几个低分学校凑数，而是找“录了也愿意去”的学校和专业组。否则保底就不是保底，而是新的麻烦。

先删掉不能接受的，再讨论喜欢的

填志愿不是先问“你最喜欢什么”，而是先问“什么绝对不能接受”。因为平行志愿里，一旦被某个院校专业组投档，后面的志愿一般就不再检索。如果进了不合适的组，又不服从调剂，可能退档；如果服从调剂，可能被分到不想读的专业。

家庭可以先开一次会，把这些问题说清楚：

• 民办本科能不能接受？
• 中外合作、国际班能不能接受？一年学费上限是多少？
• 职业本科能不能接受？
• 联合培养、协同培养能不能接受？如果不在主校区读，能不能接受？
• 省外能不能接受？最远能去哪里？
• 医学、护理、药学、农学、食品、材料、化工、环境、土木、航海这些方向能不能接受？
• 如果有地方专项、教师专项、卫生专项资格，能不能接受协议、服务期和定向地区？
• 体检有没有色盲、色弱、视力等限制？

这些问题不提前说清楚，最后很容易变成家长和孩子之间的拉扯。

几个比较现实的方向

第一，省内公办本科。

12万名左右在广东省内不是完全没有公办机会，但要接受取舍。可以重点看地市公办、行业特色院校、联合培养、职业本科，以及一些相对不那么热门的专业组。省内优势是离家近、生活适应成本低；劣势是竞争挤，热门城市和热门专业会更难。

第二，省外公办本科。

这个分段很值得认真看省外公办。很多家庭天然偏好留在广东，导致省内同分竞争很激烈。愿意出省的话，可能用同样排位换到更清晰的专业、更传统的本科体验，甚至更舒服的录取位置。代价是距离、气候、饮食、回家成本和未来就业路径都要提前想清楚。

第三，专业优先。

如果孩子已经很明确想学某一类专业，就应该先圈专业，再看学校。

想学医药，不要一上来就盯临床、口腔、麻醉、医学影像这些热门方向。530分、12万名附近，更现实的可能是药学、医学检验、康复治疗、护理、公共卫生、预防医学、医学技术类等。

想学工科，要先确认有没有选化学。现在大量工科、医学、药学、生物、食品、材料、化工、环境类专业都可能要求物理加化学。没有化学，候选池会明显变窄。

想学师范，要把普通师范和教师专项分开看。教师专项不是普通低分入口，它往往带有定向培养、服务地区和服务期要求。孩子是不是真的愿意当老师，比“分数够不够”更重要。

想学财经、金融、会计、管理，也要现实一点。这类专业名字好听，就业面广，但竞争已经很激烈。本科院校层级、城市、实习资源、考研考证能力，都会影响后续发展。

第四，职业本科、联合培养、中外合作。

这些标签不能一概排斥，也不能一概当作捡漏。职业本科是本科层次，但培养定位更偏应用技术。联合培养、协同培养要查清楚四年在哪里读、毕业证学位证怎么标注、教学管理归谁。中外合作和国际班要看学费、语言要求、课程难度、是否出国和家庭承受能力。

是否服从调剂

一句话：如果一个专业组内所有专业都能接受，一般建议服从调剂；如果组内有绝对不能接受的专业，就要谨慎填这个组。

不要幻想用“不服从调剂”解决专业组选择问题。比如一个专业组里只有2个专业喜欢，其他都不想读，然后填这个组并选择不服从调剂，看起来像是在保护专业，其实是在放大退档风险。

更好的办法是：把专业组看细。喜欢、可接受、勉强、不能接受，逐个标出来。稳和保的志愿，尤其要确保“录了能接受，调剂也不崩”。

最后几天怎么安排

如果现在还没开始整理，可以按这个节奏推进：

6月25日到6月28日，先确认基本信息：官方排位、完整选科、体检结论、专项资格、家庭预算。然后用2025年投档表筛出一批去年最低排位大约10万到18万的院校专业组。

6月29日到7月2日，用2026年招生专业目录逐个核对：今年是否招生、计划数多少、专业组有没有变化、选科要求是否符合、组内专业是否接受、学费和校区是否能接受。

7月3日，做压力测试：前10个冲不上怎么办？热门专业录不到怎么办？被调剂能不能接受？最后保底是不是录了也愿意去？

7月4日，主要做核对，不要大改。代码、专业组、专业、是否服从调剂、保存和确认状态，都要逐项检查。不要卡在截止前最后半小时提交。

广东2026年普通高校招生志愿填报的第二时段是6月29日19:00到7月4日16:00，普通本科志愿就在这个时段完成。这个时间点要记牢。

给这个分数段的一句话

530分、12万名左右，最怕两种极端。

一种是太悲观，觉得没什么好学校可选，于是随便填。其实这个位置仍然有不少本科选择，只是要认真比较。

另一种是太乐观，前面全冲热门城市、热门学校、热门专业，后面拿几个自己根本不了解的民办、高收费或冷门专业组当保底。这样看起来志愿很满，实际上风险很大。

比较稳妥的心态是：她处在一个“选择不少，但每一步都要取舍”的位置。把省内和省外都纳入比较，把专业组看细，把调剂风险控住，把45个志愿铺开，最后让每一个志愿都满足一个底线：录了可以去，不会后悔到无法接受。

参考资料主要来自广东省教育考试院2026年最低分数线通知、2026年志愿填报通知、2026年招生工作通知、2025年一分一段表、2025年本科普通类物理投档情况，以及教育部阳光高考平台。正式填报前，请一定回到官方系统和高校招生章程逐项核对。

参考链接：

• 广东省2026年普通高校招生录取最低分数线
• 广东省2026年普通高校招生志愿填报工作的通知
• 广东省2026年普通高校招生工作通知
• 广东省2025年普通高考成绩各分数段数据
• 广东省2025年普通高考本科批次正式投档
• 教育部阳光高考平台

当前阅读总时间是：20,905小时

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 在第三方技能、文件访问、命令执行、外部服务授权等能力上天然存在的治理风险。