发表于 | 分类于

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

——在《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 编程真正改变的不是代码，而是现实

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

一说信息管理，很多人想到的是文档、表格、知识库、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 写更多代码”，也不是“如何建更多系统”，而是：

我们要用这些低成本信息系统，建造一个更接近真实、更能纠错、更尊重人的现实，还是建造一个更高效但更虚假的秩序？

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

参考资料

发表于 | 分类于

从泥板账本到 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 之间，隔着几千年的技术史，却连接着同一个问题：

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

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

参考资料

发表于 | 分类于

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 时代最硬的通行证。

发表于 | 分类于

1

前几天，我跟一个学生讨论了一个问题：在证明自己和自我实现之间，应该怎样取得平衡？

我先问她，你在什么时候觉得自己证明了自己？

她说，对学生来说，最直接的就是取得成绩。小时候上台领奖，拿很多奖状，会觉得很自豪。现在也是，如果自己实现了同龄人还没有实现的事情，就会觉得这段努力是有效的。

这个回答很真实。

对很多学生来说，证明自己就是考出好成绩，拿到奖，发表论文，进入更好的学校，获得老师和同学的认可。再往后一点，证明自己就是找到好工作，升职加薪，买房买车，让别人觉得你过得不错。

我们从小就被这样的评价体系训练。小学有奖状，中学有排名，大学有绩点，工作之后有薪水、职级和头衔。每个阶段都有一个榜单，明着的或者暗着的。你在榜单上往前一点，就觉得自己更有价值。

这当然不是坏事。

人需要阶段性的证明。没有这些证明，我们很容易陷入迷茫，不知道自己到底有没有进步，也不知道自己过去的努力是否值得。

问题在于，如果一个人一直活在“证明自己”里面，他会越来越不知道自己真正想做什么。

2

那个学生刚发了一篇论文。对她来说，这是一个很重要的成果。

但是她说，自己当时其实有一点失落。

她第一时间把消息发到家里的群里，家人没有太多反应。妈妈私聊她，说弟弟快中考了，让她好好督促弟弟学习。爸爸在群里发的是自己五一出去兼职的照片。

她突然意识到，自己的喜悦好像没有人能够接住。

我对这种感受很熟悉。

升职加薪，工作做得不错，收入提高了，这当然是值得开心的事情。但是要跟谁分享呢？

跟父母说，他们不一定懂。跟兄弟姐妹说，关系未必到那个程度，而且别人可能会觉得你在炫耀。跟朋友说，朋友能不能真心为你高兴，也很难讲。

我自己很骄傲的一件事情，是阅读超过一万小时。以后如果到两万小时、三万小时，我也会很开心。但是这个喜悦更难分享。别人可能会说，读这么多书很厉害，可是这个能挣多少钱？

很多喜悦，注定只有少数人懂。

这一点越早接受越好。

小时候我们拿奖状回家，父母嘴上说不要骄傲，继续努力，但你还是能从他们脸上看到骄傲。长大之后，事情变复杂了。你的成就不一定符合他们的想象，他们也未必有能力理解你的艰难。

这不是谁的错。

人长大之后，就是要慢慢学会为自己保存喜悦，也学会寻找真正能理解你的人。

我写公众号，很大程度上就是这样。关注的人不多，经常读的人更少。但是我相信，在那些读者里面，总有十个二十个人，能够理解我为什么会因为阅读、写作、AI、编程这些事情感到开心。

有些知己未必认识你，也未必评论过你。他只是读到了，然后懂了。这样也很好。

3

证明自己，很多时候是向别人证明。

向父母证明，向老师证明，向同学证明，向面试官证明，向社会证明。

小时候，很多人听到的话是：你要争气。

这句话前面常常还有一个隐藏的主语：你要为爸爸妈妈争气。于是考一百分、拿第一名、考上好学校，不只是你自己的成就，也像是在完成家族里的某种使命。

这样的动力当然有用。

很多人就是靠着这股劲，一路读书，一路考试，一路从更小的地方走到更大的地方。如果没有“争气”这两个字，可能根本撑不到今天。

但是，证明自己终究只是一种任务。

考试是任务，拿学历是任务，找工作是任务，赚钱也是任务。这些任务很重要，因为它们给我们提供基本的生存条件和社会位置。

可是任务完成之后，人总要问下一个问题：然后呢？

如果我已经证明自己是一个合格的人，一个有能力的人，一个不比别人差的人，那我接下来要做什么？

很多人在这里卡住了。

因为他过去的人生一直在回答外部评价体系提出的问题。考试问他，你能考多少分？学校问他，你绩点多少？公司问他，你能创造多少价值？社会问他，你赚多少钱，住什么房子，配偶怎么样？

可是自我实现问的是另一个问题：你自己想成为什么样的人？

4

自我实现不是一个很好定义的词。

它肯定不是单纯地挣更多钱。钱很重要，我从来不反对挣钱。没有钱，人很难自由，也很难自律。但是对我来说，成为亿万富翁不是自我实现。

它也不是娶一个让别人羡慕的妻子，不是住大豪宅，不是开豪车，不是当大官。

这些东西不是不好，而是它们属于外部评价体系。别人看了会羡慕，亲戚朋友听了会觉得你混得好。但是如果你自己并不真正认同，它们就不是你的自我实现。

我更愿意这样理解自我实现：

发挥自己的创造力、想象力和聪明才智，做成一些自己认为有价值的事情，并且对他人产生积极影响。

比如，我如果能做出一个很好的开源项目，让很多人因此受益，我会觉得这是自我实现。

比如，我在阅读上持续进步，不只是自己读得开心，还能把学习和阅读的观念分享给更多人。哪怕只影响一两个人，让原本不怎么看书的人开始愿意看书，我也会觉得这件事有价值。

自我实现不一定轰轰烈烈。

它不一定要成名成家，不一定要改变世界，不一定要得到很多掌声。一个人做了自己真正认可的事情，并且让另一个人的生活变好了一点点，这就已经不是一件小事。

利他，是自我实现很重要的一部分。

人看到别人过得不好，会有恻隐之心。看到偏远地区的孩子吃午饭不方便，我愿意给免费午餐项目捐款。看到学生被应试教育困住，我愿意跟他们讨论学习和 AI。看到有人因为不知道怎么读书而痛苦，我愿意写文章分享自己的经验。

这些事情不一定能带来多大的世俗回报，但是它们会让我觉得，自己活得更像自己。

5

有意思的是，证明自己和自我实现并不是完全对立的。

很多人会把功利主义和理想主义分开。周一到周五是功利主义，晚上和假期是理想主义。先把现实任务完成，再用剩下的时间做一点自己喜欢的事。

这种安排很现实，也很容易理解。

但是我越来越觉得，理想主义不是功利主义之外的甜品。理想主义会反过来帮助一个人获得更大的现实成就。

如果一个人年轻的时候只想着进大厂、加班、刷题、跳槽、涨薪，他当然可能在短期里取得更好的收入。但是他可能没有时间阅读，没有时间探索，没有时间做那些看起来没什么用的事。

这些没用的事，将来可能会变得很有用。

我一开始用 AI 辅助阅读和思考，更多是出于兴趣，不是为了工作。后来 AI 辅助编程越来越流行，这种长期跟 AI 对话的习惯，反而让我更快适应新的工作方式。

阅读也是一样。很多书在读的时候并不知道有什么用。但是读得多了，理解能力、表达能力、跨学科思考能力都会慢慢增长。等到某一天机会出现，你才会发现，原来过去那些看似没有用的积累，都在暗处帮了你。

过度功利的人，看起来很聪明，其实容易失去主动性。

别人说什么有用，他就做什么。别人说什么没用，他就不做什么。学长学姐说这样，他就这样。老师说那样，他就那样。

听劝当然是优点。

但是一个人不能只有听劝。你还要有一些别人没有要求你做、甚至别人不理解但你仍然想做的事情。

这些事情，才可能把你的天花板往上抬。

6

回到那个学生身上。

她刚发了论文，接下来要把这篇论文写进简历，作为自己能力的重要证明。

我提醒她，一定要好好准备怎么讲这篇论文。

不是简单地说，我做了一个工具。也不是说，我很努力，做了数据清洗、代码实现和实验测试。

这些当然是真的，但还不够。

如果你想让别人理解这项成果的价值，就要讲清楚：

这个问题为什么重要。
已有最好的方法是什么。
你的工具相比它提升在哪里。
提升有多大。
这个过程中你真正贡献了什么。
你遇到的最大困难是什么，又是怎么解决的。

她后来讲到一个关键点：她的工具相比已有的冠军级求解器，在相同求解时间里，能求出五倍以上的结果。

这就是一句很有力量的话。

很多年轻人不是没有实力，而是不会证明自己的实力。明明做了很好的工作，讲出来却像是在描述一次普通作业。

这不是包装造假。

包装造假是把没有的东西说成有，把很小的东西说成很大。真正需要训练的表达，是把真实的信息组织成一个别人能理解、能相信、会被打动的故事。

尤其是在 AI 时代，一个人的成果会被更多审查。别人会问，这是不是你做的？是不是 AI 帮你写的？是不是导师安排好了你只是执行？是不是第二作者做了主要贡献？

你要经得起这些问题。

经得起问题，不是靠嘴硬，而是靠细节、逻辑和真实参与。

7

证明自己之后，年轻人还应该做什么？

我的答案是：把人生慢慢从外部评价里拿回来。

不是不考试，不发论文，不找好工作，不赚钱。不是这样。

这些事情仍然要做，而且要认真做。一个人连基本任务都完成不了，就很难谈自由，更难谈自我实现。

但是在完成这些任务的同时，要开始建立自己的评价体系。

你要知道，什么事情会让你真心开心。什么事情即使没人夸，你也愿意继续做。什么事情虽然现在看起来没有用，但你相信它会让你变成更好的人。什么事情能让你帮助别人，也让你觉得自己的人生更有意义。

证明自己，是从别人那里拿到一张通行证。

自我实现，是你拿着这张通行证，去走自己的路。

很多人拿到通行证之后，又急着去拿下一张。拿了一张又一张，最后忘了自己本来想去哪里。

这很可惜。

年轻的时候，证明自己很重要。因为你需要机会，需要资源，需要别人相信你。

但是越往后走，越要把问题换回来：

我想创造什么？
我想理解什么？
我想帮助谁？
我想成为什么样的人？

这些问题没有标准答案，也不会像考试一样给你明确分数。

可是，一个人真正的人生，往往就是从这些没有标准答案的问题开始的。

发表于 | 分类于

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境的朴素工程哲学

今天我想跟你聊一位工程师——Mitchell Hashimoto。他是 HashiCorp 的联合创始人，你可能没听过这家公司，但你一定用过它的产品：Terraform、Vault、Consul、Vagrant。过去十年云计算的基础设施，有相当一部分是他参与设计的。

但今天不聊云。今天要聊他关于 AI agent 的一个观点。这个观点极其朴素，朴素到你第一反应可能是“就这？”——

当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

就这。他把这件事命名为 harness engineering（驾驭工程）。

这个观点的魅力，恰恰在于它看起来毫不性感。你想想，在关于 AI 的讨论里，大家平时都在谈什么？谈模型又更新了；谈 agent 能不能替代人；谈某个公司估值又涨了；谈今年 AGI 是不是就要来了。声音越大越戏剧，流量越大。

Mitchell 不凑这种热闹。他只讲一件事——agent 犯错之后，人该干嘛。 我越琢磨这件事，越觉得它可能是整个 AI 编程讨论里，最经得起时间考验的一句话。

咱们分几层来拆。

第一层：先搞清楚 agent 到底是什么

很多人对 AI 编程的理解，其实停留在“会写代码的聊天框”。你问它，它答；你复制，它生成。这是 chatbot 模式。

Mitchell 在《My AI Adoption Journey》里做了一个非常重要的区分——chatbot 和 agent 是两种不同的东西。

chatbot 主要靠模型已有的知识回答问题。它不进入你的环境，它不知道你的代码库长什么样，它也不会主动跑任何东西。你给它一段代码，它给你一段建议；中间要来回复制粘贴。你要纠正它，得靠你自己读完输出、发现问题、再告诉它。

agent 不是这样。agent 的最低标准，他给得很具体——至少要能读文件、执行程序、发起 HTTP 请求。 也就是说，agent 不是在回答，它是在“行动”。它能进入一个工作环境，尝试一件事，看结果，再决定下一步做什么。

这个区分看着简单，但它改变了整个协作方式。chatbot 是“我问它答”，agent 是“我给目标，它在环境里尝试”。前者每一次失败都回到 prompt——“这次我该怎么说才能让它听懂”；后者每一次失败都回到系统——“这个环境该怎么设计才能让它更容易做对”。

划重点：把 AI 当 chatbot 的人，最重要的杠杆是 prompt；把 AI 当 agent 的人，最重要的杠杆是环境。

这就是 Mitchell 观点里最重要的前提。如果你不接受这个前提，下面的所有话都听不进去。

第二层：agent 犯错意味着什么

好，假设我们接受 agent 是一个会在环境里行动的东西。那它会犯错吗？一定会。

这时候普通人会怎么想？三种本能反应：

第一种，骂模型。“Claude 就是笨。” “GPT 更新之后反而更蠢了。” 这种反应最多，因为便宜。
第二种，重写 prompt。“我再把需求讲得更清楚一点。” “我再给它加几个例子。” 这种反应看起来很勤奋。
第三种，自己上手。“算了，它搞不定，我自己写吧。” 这种反应最干脆。

Mitchell 的反应不是这三种里的任何一种。他的反应是——把这次错误，变成环境的一个永久约束。

我给你举个具体的例子。

Ghostty 是一个终端模拟器，代码在 GitHub 上开源。它的 src/inspector 目录下有一个小文件叫 AGENTS.md。这文件里写了什么？写了五句话——

  • inspector 类似浏览器的开发者工具。
  • dcimgui.h 这个头文件在哪个位置。
  • widget 的例子在哪里可以参考。
  • macOS 上构建时，要加哪些特定参数。
  • 这个包没有单元测试。

就这五条。没有高深理论，没有 AI 指南，没有 prompt 模板。全是 agent 之前犯过错的地方——它找不到 dcimgui.h 时胡乱猜测、它用错构建参数时反复失败、它不知道这个包没有测试时以为可以跑测试。每一次错误，Mitchell 都把它写成了一句环境说明。

这就是 harness engineering 的基本形状：把 agent 的每一次具体错误，沉淀成环境里的一条具体约束。

他把 harness 的形式分成两类——一类是这样的隐式提示文件，改变的是 agent 的认知上下文；另一类是程序化工具，比如截图脚本、过滤测试脚本、轻量的模拟环境，改变的是 agent 的行动能力和反馈质量。

你细想一下：这不就是你工作了十年的老工程师天天在做的事吗？写文档、建脚本、加测试、立规矩、把口头知识落成文字。只不过以前这些东西是给新员工看的，现在是给 agent 看的。

换句话说，harness engineering 不是什么 AI 新学科，它就是把老工程师的常识搬进了新场景。

第三层：为什么这比“更好的 prompt”更值得投入

你可能会问——“写个 prompt 不就好了？为什么要搞这么重的基础设施？”

这个问题值得用一个类比来回答。

prompt engineering 和 harness engineering 的区别，像“出门前嘱咐孩子”和“把楼梯口装上防撞条”的区别。

出门前嘱咐孩子“别在楼梯口跑”——这是 prompt。你说得越具体越好。但嘱咐这件事的收益是一次性的，这次管用，下次可能就忘了，换一个孩子可能完全没用。

给楼梯口装一个防撞条——这是 harness。一次性投入，永久生效。不管是哪个孩子、哪天、什么状态，都有效。

这两件事都重要。但从投入产出比来看，只要是你会反复做的事情，投入到环境里的成本，收益会复利累积；投入到 prompt 里的成本，收益会随着对话消失。

Mitchell 的工作方式就是这样：他允许自己这一次写一个 prompt 把问题解决掉，但如果同一类问题出现了第二次，他会停下来想一下——这件事能不能变成一条环境里的规则？如果能，就花时间写进去。

这种思路在软件工程里叫“把人工 checklist 自动化”。它在 AI 之前就存在了几十年——写测试、做 CI、统一环境、封装脚本、加 lint、把散落的知识写进文档。Mitchell 的原创之处在于，他把这套思路显性地移植到了 AI agent 时代，并给它起了一个名字。

OpenAI 后来在讨论 Codex 的一篇文章里，也采用了非常类似的框架——他们说，当 agent 失败时，不要问“怎么让模型更努力”，而要问“这里缺了什么能力？这个能力怎么让 agent 可读、可执行、可约束”。LangChain 干脆把这件事写进了定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。

这些都是后来发生的事。Mitchell 更早就已经在做了。

第四层：架构不外包，agent 是 junior engineer

现在还有一个疑问——harness 做得再好，agent 不还是会犯错吗？那人类到底还干什么？

Mitchell 对此有一个非常清晰的比喻：和 agent 合作，像指导一个 junior engineer。

这个比喻我要稍微展开一下，因为它特别准。

设想你刚带一个实习生。他聪明、听话、能写代码，唯一的问题是没有工程经验——不知道你们团队的约定、不理解系统的历史包袱、对“哪里不能碰”没有感觉。这时候你会怎么安排他？

有经验的带人者，不会说“你去优化我们的订单系统”。他会说——“你看这个接口，加一个重试逻辑，重试条件是 A 和 B，不要改 C，写一个对应的单元测试，完成后我 review 一下。”

区别在哪？前者是一个无边界的开放式问题，后者是一个边界清楚、护栏齐全、验证明确的小问题。junior engineer 在后一种任务上能干得非常好；在前一种任务上，99% 会出事。

agent 目前的位置，几乎和一个聪明但没经验的 junior 完全一样。 它不是笨，它是缺上下文、缺约束、缺反馈。

所以 Mitchell 从不把架构外包给 agent。他负责代码结构、数据流、状态归属——这些决定“这个系统长什么样”的问题，他一个都不交。他把设计做好，把问题切成合适的形状，然后让 agent 在那个形状里行动。

他在 Zed 的访谈里说过一句很实在的话——如果你只告诉 agent “这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下一个你以后一定要还的债。

一句话总结：agent 不是价值判断者，不是架构负责人，更不是最终责任人。它是团队里速度最快、但需要明确边界才能干好活的成员。

第五层：一个不能外包的东西——责任

这是我认为 Mitchell 最有分量的一块。

他在 2025 年 10 月写过一篇文章叫《Vibing a Non-Trivial Ghostty Feature》，公开了他用 AI 完成 Ghostty 一个具体功能的全过程——16 次 agentic coding session，成本 15.98 美元，8 小时墙钟时间。很多人引用的是这些数字。

但我想让你记住的是另一段。

他在做这个功能的过程中，遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，测试都能过，但里面藏着一个关键 bug。他尝试了几次更精确的 prompt，都没修好。

这时候，常规的工程师本能有好几条路——再换一个 prompt、再换一个模型、等下个版本出来。

Mitchell 选的都不是。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解 bug 的原理。然后他在博客里写了一句，我觉得是整个 AI 编程讨论里最该被加粗的一句话：

如果 agent 找到了解法，我会学习。如果我不理解，我就回退。我不交付自己不理解的代码。

这句话为什么重要？因为今天关于 AI 编程的讨论，大部分都停在速度层面——更便宜、更快、更多产出。这些都是真的。但 Mitchell 想让你记住的另一件事是——你理解了吗？你能维护吗？它会不会回归？下一个读这段代码的人，会更容易还是更困难？

AI 可以写代码。但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试；但最终合进代码库的是你。产品出了 bug，用户不会说“这是 Claude 写的所以不算”；维护者也不能把不可理解的复杂性推给模型。

这才是真正的分水岭——AI 时代成熟的工程师和不成熟的工程师，最大的差别不在于谁 prompt 写得漂亮，而在于谁更敬畏“自己不理解的代码”。

第六层：为什么这条原则很难过时

我知道你可能会说——“这些经验不都是暂时的吗？等模型更聪明了，不就不用搞这一套了？”

Mitchell 自己就承认这一点。他在 Open Source Ready 里说，今天很多 AI 协作技巧——比如怎么管理 context、怎么打开正确的 buffer、怎么塑造反馈回路——可能都是几年后不再需要的“临时技能”。

这种自我警觉非常珍贵。很多 AI 讨论者的问题，恰恰是把当下的具体技巧说成永恒真理。

但是请注意，即使具体技巧会过时，harness engineering 背后的姿态不会过时。这个姿态是什么？

简单说就是：不把错误当成模型的偶然失误，而当成系统的缺口；不指望模型下次自己变聪明，而是改造环境让同样的错更难发生。用可重复的反馈回路替代一次性的人工祈祷，让机器做重复劳动，人来做判断和创造。

这些原则，软件工程已经用了三十年。它们在 Vagrant 解决“环境难复现”的时候成立；在 Terraform 解决“基础设施难声明”的时候成立；在今天 Mitchell 做 agent harness 的时候成立；在未来某个更聪明的模型来临时，很可能仍然成立。

Mitchell 自己在 2019 年接受 WIRED 采访时就说过一句话——“我这辈子做的事情有一条连续的线索：自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

你看，这句话放到 2026 年的 agent 时代，一个字都不用改。变的只是“重复劳动”的内容——以前是搭虚拟机、写配置、管理 secret；现在是查资料、跑测试、写样板、做 refactor。工具变了，工具背后的那条线没变。

这就引出一个判断标准：一个观点能不能穿越技术周期，关键看它绑定的是“当下的工具”还是“不变的原则”。 绑定工具的观点，工具变就死了；绑定原则的观点，工具怎么变都活着。

第七层：给你的三条可直接用的 takeaway

好，理论讲完了，给你三条可以今天就用上的行动建议——

第一条：别一上来就追求一个完美 AI 流程。 Mitchell 的 harness 不是设计出来的，是从错误里长出来的。agent 跑错命令，就记录；误用 API，就加说明；忘记跑测试，就写脚本。一次修一个错，半年之后你会发现自己已经有了一整套 harness。追求一次到位的人，往往最后什么都没做。

第二条：给 agent 的任务，要像给 junior engineer 的任务。 不要说“把这个系统优化一下”，要说“只改这个模块，先读这几个文件，不要改公共 API，新增这个测试，运行这个命令”。agent 的速度会诱惑你把问题丢大，但 Mitchell 的经验恰恰相反——小块工作更容易 review、理解和迭代。

第三条：不要 ship 你自己不理解的代码。 不管 agent 多聪明，多便宜，多快——代码合进去了，责任就是你的。如果 agent 修了一个你看不懂的 bug，停下来，去学，去研究。如果学不会，回退。这个规矩听起来像在给你踩刹车，但它其实是 AI 时代最保护你的一条。

Mitchell Hashimoto 的价值，不在于他提出了什么新词，也不在于他用了哪个模型。他的价值在于，在一个嘈杂到让人恍惚的时刻，他用非常朴素的一句话，把 AI agent 这个看起来很玄的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

他让你相信一件事——AI 时代的成熟工程师，可能不是最会写 prompt 的人，而是最会把一次错误，变成永久护栏的人。

这是一种很笨的智慧。但好多笨的智慧，最后都赢了。

发表于 | 分类于

人物雷达｜Mitchell Hashimoto 和他的朴素工程哲学

我观察 Mitchell Hashimoto 有一段时间了。

在讨论 AI agent 的人里，他是一个奇怪的存在。他不做预测，不讲愿景，不谈谁会被替代，甚至承认自己今天使用 agent 的很多技巧，三年以后可能就不再需要。他只是在博客和访谈里，讲他怎么用的、哪里用得好、哪里被卡住、卡住之后怎么想。

但如果你把他过去一年的表达拼起来看，会发现它们形成了一个克制、朴素、也很难被时间淘汰的结构。

这个结构可以用他自己的一句话概括：当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话听起来几乎不像一个“观点”。它不锋利，不性感，没有流量。但它恰恰是我愿意花一篇文章写他的原因。

他先是个做环境的人，然后才是个用 agent 的人

要理解 Mitchell 现在的 AI 观，得先绕开 AI，回到他过去十几年做的事情。

他在自己网站上把履历写得非常冷静——主要在做 Ghostty；曾在 HashiCorp 做过四年 CEO、五年 CTO、两年个人贡献者，2023 年离开。这份简历背后，是 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint——几乎构成了过去十年云基础设施的默认词汇。

有意思的是，把这些工具并排放着看，会发现一条相当连贯的线索：它们都在解决同一件事——怎么让一个开发者环境，从“存在于某个老员工脑子里”，变成“可以被代码描述、被机器复制、被工具执行”。

Vagrant 让本地开发环境可以被复制，Terraform 让云基础设施可以被声明，Nix 让整台桌面可以被代码重建——Ghostty 是终端，看起来和前几样不太一样，但仍然是开发者环境的一部分。

他在 Open Source Ready 聊 Nix 的时候有一句话让我印象挺深——他说自己其实想要的只是一种“可靠、一致、可用代码重建”的桌面。这听上去很简单，但放进他过去所有工具里都成立。

这个人一辈子都在做一件事：把人对环境的隐性依赖，转成环境本身的显性约束。

所以当他进入 agent 时代时，他看 agent 的角度和大多数人不一样。他不觉得 agent 是一个需要仰望的智能体，也不觉得它是一个需要贬低的补全工具。他看到的是一个会在环境里读文件、执行命令、调用工具、观察结果、循环行动的东西——换句话说，一个新的、可以被工程化地约束和塑形的对象。

这是他和大多数 AI 讨论者的分水岭。

他一开始其实不太满意

我不喜欢过度拔高一个人的“先见之明”。Mitchell 对 AI 的态度不是一开始就那么清晰的，他自己也聊过这件事。

在《My AI Adoption Journey》里，他说自己第一次认真用 Claude Code 的感觉是——不太行。生成的东西要大改，改完还不如自己写。他一度怀疑自己是不是不适合这套工作方式。

然后他做了一件我觉得很能代表他性格的事情。

他没有得出“agent 不行”的结论，也没有得出“我不行”的结论。他选了一条更笨、更慢的路——把自己已经手写完成的 commit 拿出来，关掉答案，逼自己用 agent 在看不见答案的前提下，复现同等功能和质量的结果。

这件事其实很反效率。他在正常交付之外，又凭空给自己加了一层工作量。但也正是在这段笨功夫里，他开始真正理解 agent 适合什么、不适合什么。

他自己总结出了三条结论，简单到几乎像一本软件工程教科书：任务要拆小；模糊需求要先规划再执行；最重要的——给 agent 一个能自己验证工作的办法。

读到第三条的时候，很多人会觉得这不就是测试吗？是的。这正是他的风格。他不造新词，他把那些我们本来就熟悉的工程原则原样搬了过来。只是以前我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次会变聪明，要把这次错误变成环境的一个约束”。

为什么是“环境”，而不是“prompt”

Mitchell 讨论 AI 时，很少聊 prompt。

这件事本身就值得注意。今天大多数关于 AI 编程的内容，核心都是 prompt——怎么写出更好的 prompt，怎么骗模型一步步思考，怎么给它塞上下文让它听话。但 Mitchell 几乎从不谈这些。

他谈的是 harness——套在 agent 外面的那一整层环境：规则、文档、工具、脚本、测试、权限、工作目录、反馈信号、观察机制。

LangChain 早就有过一句简洁的定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。Mitchell 不是提出了这个概念，他只是把它变成了日常工作的重心。

他把 harness 分成两类。一类他叫“更好的隐式提示”，最典型的载体是项目里的 AGENTS.md 文件。Ghostty 仓库的 src/inspector/AGENTS.md 是个小而具体的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；widget 例子在哪里；macOS 构建时要加什么参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的本地说明。

另一类是真正的程序化工具——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者加起来是这样一件事——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再违反架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 很像，但不是一回事。prompt engineering 是“这一次我怎么说”，harness engineering 是“这个系统怎么设计”。前者的收益随对话消散，后者的收益会长期累积。

Mitchell 相信的是后者。原因不复杂——他一辈子都在相信后者。

责任不能外包：一句分量很重的话

他在 2025 年 10 月发过一篇文章，《Vibing a Non-Trivial Ghostty Feature》。那篇文章公开了他用 AI 辅助完成 Ghostty 一个具体功能的全过程——macOS 上不打断用户的自动更新提示。

很多人关注里面的数字：16 次 agentic coding session，token 成本 15.98 美元，约 8 小时墙钟时间。他自己也承认效率提升是真实的，尤其是 SwiftUI 细节迭代那部分，AI 帮了大忙。但我读那篇文章时，印象最深的不是这些数字，而是他在遇到 bug 时的一段话。

他遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，甚至测试都能过，但里面藏着一个关键 bug。他换了几次更精确的 prompt，都没有修好。

这时候，工程师的本能会告诉你——再换一个 prompt；再换一个模型；或者等 Claude 下个版本。

他没有选任何一条。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解为什么会出错。然后他在博客里写下了一句让我反复想了很多次的话：

如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。

这句话的分量，在 AI 编程的讨论里不太常见。

今天太多人在讨论 AI 带来的速度，这些都是真的。但 Mitchell 更在意另一样东西：你理解了吗？下一个看到这段代码的人——不管是人类还是 agent——会因此更轻松，还是更痛苦？

AI 可以写代码，但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试、整理结构；但最终合进代码库的是你。产品出了问题，用户不会说“这是 Claude 写的”；维护者也不能把不可理解的复杂性推给模型。

Mitchell 的这句话，我私下认为是整个 AI 编程讨论里最接近“工程伦理”的一句。没有宏大叙事，但它把一个特别容易被模糊掉的边界，清晰地钉下来了。

他把 agent 当 junior engineer，不当 superhero

Mitchell 有一个常用的类比——和 agent 合作，就像带一个 junior engineer。

如果你是个带过人的工程师，你会立刻懂他在说什么。

把一个开放式问题丢给 junior，比如“去优化一下我们的订单系统”，基本等于灾难。把一个边界清楚、护栏齐全、验证明确的小问题丢给 junior，比如“这个接口加一个重试逻辑，条件是 A 和 B，不要改 C，写一个对应测试”，他往往能做得不错。

AI 目前处在一个很类似的位置。

这也是为什么 Mitchell 从不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，再让 agent 在那个形状里行动。他在 Zed 的访谈里说过——如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式，把症状敲掉，留下一个你将来一定要还的债。

他对 agent 的能力边界，也判断得很具体。

重构、重命名、整理结构、清理死代码、填空式的样板代码——agent 几乎总能做得很好。他把这类任务称作“outsource the slam dunks”，专门挑高把握的扔给它。

开放式架构、高性能数据结构、小众语言——agent 目前仍然很差。Ghostty 底层是 Zig，但 Zig 的训练数据太稀缺，agent 常常幻觉出根本不存在的语法。他的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己手工翻成 Zig。

这不是什么宏大的理论。这就是一个老工程师在分配任务。只是他现在多了一个**“永远不抱怨、永远不累、但需要护栏”**的新成员。

他不相信“X + AI”

Mitchell 有一个经常被误解的立场——他对 AI 产品的批评。

很多人以为他是 AI 怀疑派。其实不是。他反对的不是 AI，而是一种特定的做法——把 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一类典型的 AI 产品：一个邮件客户端本身已经不好用，只是外面加了 AI 功能；一个笔记应用本身已经割裂，只是加了个 AI 总结。他的判断简单粗暴——AI 集成可以很好，但用户最终仍然要使用完整产品；如果基础体验不成立，AI 救不了它。

这句话背后其实是一以贯之的工程哲学：基础要扎实，环境要可靠，工具要真正解决人的问题。 一个糟糕的产品加上 AI，不会变成好产品；一个混乱的代码库加上 agent，不会变成可维护系统。AI 会放大已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也在发生变化。在 The Pragmatic Engineer 那篇访谈总结里，他提到开源可能会从 default trust 走向 default deny——因为 AI 让“看起来合理但实际低质量”的贡献变得太容易。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制。

他的 Ghostty 里那个被反复删除的 issue，就是这种态度的具体体现。有人贴了另一个终端的 GPL 代码片段，他立刻删了。对方说你让 ChatGPT 生成类似的就行，他反问——这样做安全吗？是不是把代码通过模型洗了一遍？他没有给答案，他只是说希望法律先例先明确。

一个愿意在具体问题上说“我不知道”的人，才有资格在大问题上被信任。

一条不变的线索

WIRED 在 2019 年做过一期关于他的报道。文章里他自己说——“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放到 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界在移动。过去是搭环境、建虚拟机、管理 secret、写配置；现在扩展到了查资料、跑测试、写样板、做 refactor、修构建错误。

变化的是工具，不变的是原则。

所以 Mitchell 的 agent 哲学，从来不是“让人退场”。他从不说编程会消失，也不说工程师会被替代。他说的是另一件更温和、也更诚实的事情——人要换一个位置。 过去大量时间花在亲手写代码，现在要有一部分时间转向设计“agent 能成功工作的环境”；过去经验沉淀在资深工程师脑子里，现在要沉淀进 AGENTS.md、脚本、测试和约束。Review 不只是看人写的代码，还要看 agent 是否被正确引导。

这个位置迁移，听起来不像一个很性感的故事。它没有“一切都将改变”的戏剧感。但它可能更接近真实发生的事情。

一个很难被淘汰的想法

我想最后回到那句话——当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话的好处是，它不依赖任何一个具体模型、任何一个具体工具、任何一个具体版本。模型会变，工具会变，今天的 harness 明天可能就过时。但这句话所表达的姿态——把错误当成系统暴露出来的缺口，而不是模型的偶然失误——几乎可以迁移到任何技术的任何时代。

也许几年以后，agent 比我们所有人想象的都聪明。到那时候，很多具体技巧会被扔进“临时技能”的抽屉里，包括 Mitchell 今天讨论的很多。但我不觉得 harness engineering 的姿态会过时。

因为它本质上说的是一件很老的事——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是系统暴露出来的可工程化信号。

软件工程里，所有真正有复利的东西，几乎都是这个形状。

Mitchell Hashimoto 的价值不在于他发明了什么新术语，而在于他在一个很喧嚣的时刻，把 AI agent 这个看似魔法般的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

这种姿态不一定最能吸引眼球。但时间通常比较偏爱这种人。

发表于 | 分类于

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境

一个被反复删除的 issue

2025 年春天，Ghostty 的 GitHub 仓库里出现过一个很短的插曲。

有用户在 issue 里贴了另一个终端模拟器的源代码片段，希望 Ghostty 参考实现。Mitchell Hashimoto 很快把这段代码删掉了，并留下一条说明：Ghostty 是 MIT 许可，对方是 GPL，贴进来就污染了整条上游。

几小时之后，那位用户回来了，补上一条看似合理的建议：“那你让 ChatGPT 生成一段类似的代码就行。”

Mitchell 没有立刻同意，也没有立刻拒绝。他反问了一句——“这样做安全吗？是不是只是把代码通过一个模型洗了一遍？”

这是一个微小到几乎不值得记录的交互。但在今天回看，它几乎是 Mitchell 所有 AI 观点的浓缩：他愿意使用 AI，但不相信任何关于 AI 的“捷径叙事”；他接受不确定性，但不愿意用自信掩盖不确定。

过去两年，硅谷工程师里谈 AI 的声音被分成两派。一派是布道者，宣称编程即将终结；一派是反对者，认定 agent 只是高级补全。Mitchell Hashimoto 很少被归进任何一派，但他在自己的博客、Zed 的访谈、Heavybit 的播客、Open Source Ready 的长对话里，一砖一瓦地搭出了第三条路——AI agent 并没有那么神秘，它只是软件工程里一个新的、需要被工程化的对象。

这个姿态里，最常被引用的一句话是他自己写下来的：“当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。”

他把这件事叫做 harness engineering。

一个“不愿意交付自己不理解的代码”的人

要理解 Mitchell 的这套哲学，不能从 AI 开始，要从终端开始。

在自己网站上，他把现在的身份写得极简——主要在做 Ghostty；曾在 HashiCorp 做过约四年 CEO、五年 CTO、两年个人贡献者，2023 年离开公司。HashiCorp 旗下的 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint，今天几乎是云基础设施的默认词汇。他把一家公司做到上市之后选择抽身，回到一个没有融资计划、没有商业化路径的开源终端项目上，这在硅谷是个很任性的选择。

但只要把这些工具连起来看，会发现一条不算太隐秘的主线：他做的每一样东西，几乎都在回答同一个问题——怎么让开发环境变得可描述、可复制、可被机器执行？

Vagrant 解决本地开发环境的复现；Terraform 解决云基础设施的声明；Nix 让整台桌面可以用代码化的方式重建；Ghostty 是终端，仍然是环境的一部分。他在 Open Source Ready 谈 Nix 时顺便说过一句，自己对 Nix 的兴趣，其实是想要一种可靠、一致、可被代码重建的桌面。这句话放在 Terraform 的早期也完全成立。

所以当 Mitchell 进入 agent 时代，他看它的视角不是“模型崇拜”，而是“环境工程”。对他来说，agent 不是黑箱智能体，而是一个会在环境里读文件、执行程序、调用工具、观察结果、继续行动的系统。它要行动，环境就必须能纠错；它会重复犯错，系统就该把错误沉淀成规则、脚本和反馈回路。

从“改比写还慢”到“强迫自己复现”

Mitchell 并非天然的 AI 乐观派。

在《My AI Adoption Journey》里，他承认自己第一次认真用 Claude Code 的体验相当糟糕——生成的代码要大改，改完比自己写还慢，他一度怀疑这东西是不是真的能用。

他没有就此下结论。相反，他做了一件很笨的事：先用手写 commit 把一个任务完成，然后关掉答案，让 agent 在看不到自己答案的前提下，复现同等功能和质量的结果。

过程很折磨人，因为它妨碍了正常交付；但他坚持了下来，因为这是建立“直觉”的唯一方式——agent 到底适合什么、不适合什么，不是读 paper 读出来的，是一个一个任务试出来的。

这段经历沉淀成几条朴素的心得：

  • 任务要拆小，不要把一个模糊的大目标丢给 agent。
  • 模糊需求先规划再执行——想清楚做什么，再让它动手。
  • 最关键的一条：给 agent 一种验证自己工作的办法。只要它能自己跑测试、自己看输出，往往就能自己修好。

读到最后一条可能会愣一下——这不就是 CI、测试、lint、端到端脚本吗？是的。这正是 Mitchell 的风格——他不造新词，他把老工程师的常识原样搬进 AI 时代。过去我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次变聪明，要把这次错误变成环境的约束”。

Harness Engineering：错误不是事故，是系统的缺口

Harness 这个词本身不新。LangChain 早就把它写进定义里：Agent = Model + Harness。模型提供智能，harness 让智能变得可用——文件系统、bash、沙箱、工具、状态、反馈回路，都是 harness 的一部分。

Mitchell 的贡献不在术语，而在一种工作习惯：他把所有 agent 的错误都当作系统缺口，而不是模型愚蠢。

在 Zed 的访谈里，他把 harness 的形式拆成两类——

第一类是“更好的隐式提示”，最典型的载体是 AGENTS.md。如果 agent 总是跑错命令、找错 API、误解子系统，就把这些经验写进项目根目录或子目录的指导文件。Ghostty 的 src/inspector/AGENTS.md 就是个小而典型的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；如何查 widget 示例；macOS 构建要加哪些参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的环境说明。

第二类是“真正的程序化工具”——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者结合起来，就是一句话——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再破坏架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 是两条不同的路径。prompt engineering 是语言技巧，收益随对话消失；harness engineering 是基础设施，收益会复利累积。Mitchell 相信的是后者。

16 个 session，8 个小时，$15.98 和一个“slop zone”

2025 年 10 月，他写了一篇《Vibing a Non-Trivial Ghostty Feature》，公开展示自己如何用 AI 辅助完成一个真实的非平凡功能——在 macOS 上不打断用户的自动更新提示。

文章里最诚实的数字是这些：16 次 agentic coding session，token 成本 15.98 美元，估计墙钟时间约 8 小时。他承认自己确实比纯手写快了，尤其是 SwiftUI 细节迭代那部分；但他更强调的不是成本，而是工作结构——AI 最大的价值，不是每行代码变便宜，而是他离开电脑时，机器仍然能帮他产生候选。

这篇文章另一个被反复引用的部分，是他对“slop zone”的描写。

所谓 slop，是指 agent 生成的代码看起来合理、能跑、甚至能过测试，但里面藏着关键 bug。他试了几轮更具体的 prompt，没用。工程师的惯性反应是：再换个 prompt，再换个模型，再等 Claude 4.6 出来。

Mitchell 的选择是——停下来，自己学，自己研究。他在文章里写了一句很重的话：“如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。”

这句话在他所有 AI 表达里，分量最重。它把 AI 工作流里最模糊的那块——责任——钉死了。你可以让 agent 试、写、改、跑测试、找资料；但最终合进代码库的是你，用户遇到问题时不会说“这是 Claude 写的”，维护者不能把不可理解的复杂性推给模型。人工 review 不是流程，是工程伦理。

架构师不外包，junior engineer 要护栏

Mitchell 反复强调一个类比：与 agent 协作，像指导一个 junior engineer。

把一个开放式问题丢给 junior，经常是灾难；但要是问题边界清楚、护栏齐全、验证明确，junior 往往能做得很好。AI 目前就在这个位置上。

所以他从来不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，然后让 agent 在那个形状里行动。他甚至说过一句话：如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下长期不可维护的债。

这不是对 agent 的不信任，而是对任务分配的成熟判断。优秀的工程师不会把所有任务平均分给团队，他会按能力、上下文、风险和验证成本分配。对待 agent 也是如此——它擅长什么？Mitchell 的经验是：重构、重命名、整理结构、清理死代码、填空式的样板代码，几乎总能做得很好。它不擅长什么？开放式架构、高性能数据结构、小众语言。

Zig 是他最常举的反例。Ghostty 底层是 Zig，但 Zig 的训练数据太稀。Mitchell 的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己转成 Zig。他后来在 Heavybit 访谈里补充过一句：“让它直接写大段 Zig，它常常幻觉出不存在的语法。”

这是成熟工程师在 AI 时代的思路：不指望一个模型解决所有问题，按任务的形状分配工具。

X + AI 救不了底层不成立的东西

外界常把 Mitchell 误认成 AI 怀疑派，其实他只是反对一种特定的倾向——拿 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一批所谓 AI 产品：邮件客户端本身不好用，只是加了 AI 功能；笔记应用本身功能割裂，只是加了 AI 总结。他的判断是，AI 集成可以做得很好，但用户最终仍然要使用完整产品，如果基础体验不成立，AI 救不了它。

这句话背后仍然是同一条工程哲学：基础要扎实，环境要可靠，工具要真的解决人的问题。 一个混乱的代码库加上 agent，不会变成可维护系统，只会变成一个被 AI 放大的混乱代码库。AI 是放大器，放大的是你已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也受此影响。在 The Pragmatic Engineer 的访谈总结里，他认为 AI 让“看起来合理但实际低质量”的贡献变得太容易，开源会从 default trust 走向 default deny。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制——更明确的贡献规范、更强的测试、更严格的 review，更少对“看起来像样”的默认信任。

不变的底色：让机器做机器该做的事

WIRED 在 2019 年写过一篇关于 Mitchell 的人物报道。文章里有一句他自己的话：“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放在 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界变了——过去是搭环境、建虚拟机、管理 secret、写配置；现在是查资料、整理 issue、跑测试、写样板代码、做 refactor、生成模拟场景、修构建错误。变化的是工具，不变的是原则。

所以 Mitchell 并不认为 AI agent 会让工程师消失。他只是认为工程师的位置要往上挪一格——过去大量时间花在亲手写代码，现在有一部分要转向设计“agent 能成功工作的环境”。经验不再只沉淀在资深工程师脑子里，还要写进 AGENTS.md、脚本、测试、文档和约束。Review 也变了，不光看人写的代码，还要看 agent 是否被正确约束，错误是否被系统性预防。

一个朴素的、很难被模型淘汰的原则

与 Mitchell 同时代的 AI 声音里，不乏宏大叙事。有人宣布编程已死，有人断言工程师只会剩下十分之一，有人笃定三个月后这一切都将被改写。Mitchell 从不说这些话。他在每一次访谈里都很小心地划分自己的边界——这块我用得很好；那块我不知道；这里我不想过度自信；那里我需要法院先给答案；这个技巧三个月后可能失效。

也正因为他不给大判断，他的小判断才格外可信。

“每次 agent 犯错，就改造环境”——这句话的力量在于，它把 AI 的不确定性转化成了工程的确定性。你没法保证模型下次一定变聪明，但你可以让错误更容易被发现，把误解写进规则，让测试、脚本和 review 形成闭环。每一次失败都变成环境的一次升级，系统就会越用越好。

这就是 Mitchell Hashimoto 的朴素工程哲学——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是可以被工程化的信号。

AI agent 时代真正成熟的工程师，可能不是最会写 prompt 的人，而是最会把一次错误变成永久护栏的人。

发表于 | 分类于

从写代码到设计代码生产系统：Ryan Lopopolo 的 Harness Engineering 给中文工程师的启示

最近 OpenAI 有一个工程师叫 Ryan Lopopolo，他和团队做了一件挺刺激的事：从空仓库开始，五个月时间，没有人手写一行代码，全部用 Codex 生成了一个差不多一百万行规模的内部产品仓库。1500 个 PR，应用、测试、CI、文档、可观测性、内部工具，全是 agent 写的；他自己估计相当于人手写代码的十分之一时间成本。

这件事我先看到的是 OpenAI 官方博客的那篇《Harness engineering: leveraging Codex in an agent-first world》（2026 年 2 月 11 日），后来又听了 Latent Space 在 4 月 7 日对他的长访谈。看完之后我有一个明显的感觉：这不是又一个“AI 让程序员失业”的故事，而是一份关于“AI 时代工程师该怎么重新组织自己的生产系统”的实地报告。

下面这篇文章，我想用平时跟工程师朋友聊天的口吻，把 Ryan 这套观点拆给你看，再补一些我自己对中文工程师的具体建议。如果你已经在用 Cursor、Codex、Claude Code，但总觉得“提效不够丝滑”——这篇可能正好对上。

一、先把那句最容易被误读的话说清楚：humans steer, agents execute

Ryan 在文章里反复用一句话来描述这套实验：人类掌舵，agent 执行。 中文圈很多人看到这句话，第一反应是“那不就是 AI 干活、人当甲方吗”。

这个理解不对。

我把 Ryan 的真实意思翻译一下，应该是这样：工程师还在 loop 里，只是不再坐在 implementation layer，而是上移到 systems layer。 他还在做判断、还在定优先级、还在拍架构、还在守边界，只是不再把“在键盘上敲源代码”当成主要的产出形态。

为什么这一点重要？因为它直接决定了你怎么使用 AI。如果你把“humans steer”理解成“我提个需求然后等 AI 交活”，你大概率会很失望——因为 AI 不会自动知道你的业务、你的代码风格、你的部署环境、你不想踩的那些坑。Ryan 那个团队恰恰相反：他们花了大量时间，把这些“人脑里的东西”全部翻译成 agent 能读、能执行、能验证的系统组件。

所以这个故事的副标题，与其叫“无人工程”，不如叫“无人工手写源码”。人没有走，只是从打字员的位置，挪到了 tech lead、平台 owner、QA 系统设计者这几个位置。

我的体会是：如果你想用 Ryan 这套方法的十分之一红利，先把“我作为人做什么”重新定义清楚。 你的产出不再是 diff，而是约束、反馈回路、文档、工具和可机械验证的验收标准。

二、Ryan 的起点：先给自己设一个看上去离谱的约束

Ryan 在访谈里讲了一个细节，我觉得特别值得抄作业。他给自己设的初始约束是：完全不写任何代码。

他的理由很冷静：如果 OpenAI 要把 agents 部署到企业里，那 agents 理论上就应该能做我自己能做的事；既然我和 coding harness 已经一起工作了大半年，那我就反过来设计自己的工作方式——唯一能完成工作的办法，就是让 agent 完成工作。

这个约束的妙处在哪里？妙在它封死了“我下次自己上手”这条退路。

很多人用 AI 编程之所以提不上去，就是因为退路太多。AI 写得不好怎么办？我自己改两行就行了。AI 找不到那个 bug 怎么办？我打个断点自己看一下。AI 不知道项目结构？我口头跟它解释一下。这些在单次任务里都很合理，但一旦你有这个退路，你就不会真的去补齐 agent 缺的那些系统能力。

Ryan 把这条退路砍掉之后，每一次 agent 出错都被迫升格成“环境缺陷”——不是 prompt 不够好，而是这个 repo 没有给 agent 配齐它该有的工具、上下文、文档和反馈通道。是缺一个 lint？缺一段 doc？缺一个 CLI wrapper？缺一个 trace 入口？还是 PR 的生命周期没有 agent 化？

他把这种工作起名叫 harness engineering——驾驭工程。它的对象不是 prompt，不是模型，是整个软件生产环境。

中文工程师可以怎么用：你不需要真的禁止自己写代码，但可以试一个更弱的版本——这一周，凡是 agent 能做的事，我就不自己做；它做不好的，我不直接动手改代码，先去补一条规则、一段文档或一个工具。 一个礼拜下来，你就知道你的 repo 离 agent-first 还差多远。

三、模型可以并行，token 可以扩，人类注意力才是真正的瓶颈

Ryan 在访谈里反复强调一件事：模型 trivially parallelizable——你愿意花 GPU 和 token，随时能让一群 agent 同时干活。真正稀缺的，是团队白天能同步投入的那点注意力。

这句话的含义比表面更深。

过去做软件工程，稀缺资源是工程师的写代码时间和 review 代码时间。所以我们的所有流程默认：每个 PR 都要认真看，每个改动都要严格阻塞，每个 merge gate 都要尽量保守。 这套流程在人力是瓶颈的时候没毛病。

可一旦 agent 把代码产能拉到人类 review 容量的十倍，这套流程就会瞬间反过来变成最大的瓶颈。Ryan 团队后来被迫调整了 merge philosophy：PR 的寿命变短，阻塞性的 gate 减少，flaky test 有时先合后修。OpenAI 那篇文章里有一句很实在的话：这种选择放在低吞吐环境里就是不负责任，但放在高吞吐环境里常常是正确取舍。

注意，他不是在劝大家放弃 review。他真正在说的是：当人类 review 变成瓶颈，质量控制就必须前移、机械化、agent 化。 人不应该再花大量时间逐行检查代码，而是要把过去常见的 review 意见，转成 lint、structural test、文档规则、review agent、验收脚本。这样人类的判断只需要被捕捉一次，就能在所有未来 agent 生成的代码上持续生效。

我自己在带团队和做开源时一个反复验证过的判断是：判断什么是“高级工程师”的最简单标准，是看他每次解决一个问题时，是只解决这一次，还是顺手让这一类问题再也不会出现。 Ryan 这套就是把这个标准放大到 agent 时代——agent 一犯错，你的第一反应不是骂它，而是问自己“以后怎么让这种错更难发生”。

一个简单的试金石：你在 Cursor 或 Codex 里反复跟 AI 说“别那么写”、“那个目录不要碰”、“这个字段叫 xxx 不是 yyy”——每一次都是信号。你说过两次以上的话，都该写进 AGENTS.md 或者一条 lint。

四、AGENTS.md 不是百科全书，而是一张目录页

Ryan 文章里我觉得最实操、最容易抄的一条经验是：给 Codex 一张地图，而不是一千页说明书。

他们最早试过那种“什么都往里塞”的巨型 AGENTS.md，结果如你所料：上下文被挤占、所有规则都“重要”等于没有规则、文件很快腐烂、而且没法机械验证。后来他们把 AGENTS.md 砍到大约一百行，定位从“百科全书”降级为“目录”——一个稳定入口，指向 repo 内更深的 source of truth。

真正的知识被搬到结构化的 docs/ 目录里：design docs、execution plans、product specs、references、quality score、reliability、security 等等。计划被当成一等公民——复杂工作有 execution plan，active plans、completed plans、tech debt 都跟代码一起 versioned。

我特别想强调他这套做法背后的一个底层原则：从 agent 的视角看，运行时拿不到的知识就等于不存在。

这条原则一旦你接受了，它会改变你对很多东西的态度。

Slack 上某次架构讨论达成的一致——agent 看不到，等于不存在。Google Doc 里那份 design doc——agent 没把它拉进 context，等于不存在。某位大佬脑子里“我们这里就是这么干的”的 tacit knowledge——只要他没把它写进 repo，等于不存在。code review 留下的那条意见——只要没沉淀成规则，下次另一个 PR 还会犯同样错误。

Ryan 团队为了保证这些文档真的有用，还做了两件事很值得学：

第一，用专门的 lint 和 CI 检查文档的健康度——是否最新、是否交叉链接、结构是否符合规范。
第二，有一个常驻的 doc-gardening agent——定期扫描“文档说的”和“代码做的”是否一致，发现偏差直接开 PR 修。

落地建议：别再写动辄几千行的 AGENTS.md。砍成 100 行的索引就好——项目目录怎么走、关键约束在哪、架构文档去哪、质量规则去哪、运行命令去哪、owner 去哪。剩下的内容拆到 docs/ 里，每个文件管一件事。

五、Agent legibility：代码不是只写给同事看，也要写给模型看

Ryan 提了一个我很喜欢的概念，叫 agent legibility——“对 agent 的可读性”。

他说，因为他们的仓库完全由 agent 生成，所以首要优化目标已经从“对新员工友好”，变成了“对 Codex 可读”。这听起来挺极端，但他的态度其实很微妙：代码不一定要符合人类的所有审美偏好，但只要它正确、可维护、对未来 agent runs 可读，就达标了。

换句话说，human taste 没有消失，只是被重新定义了：从“我喜欢这个实现长什么样”，变成了“这个实现是否可验证、可维护、可被 agent 稳定理解和复用”。

这个观念会反过来影响你的技术选型。OpenAI 文章说，他们偏好那些 agent 能完整 internalize 的依赖和抽象。传统上被称为“无聊”的技术——组合性强、API 稳定、训练集中出现得多——反而更容易被 agent 建模。文章举了个例子：他们没有引入一个通用的 p-limit 风格并发包，而是自己写了一个 helper，跟 OpenTelemetry 集成得好、测试覆盖完整、运行时行为可预期。

Ryan 在访谈里把这个逻辑往前推了一步——内部化依赖。他说，一个几千行的小依赖，可能可以让 agent 一个下午重写一遍，只保留你真正需要的部分；这样以后做安全审查、修 bug、做适配时，Codex 能直接深入修改，而不必等 upstream patch、发布、升级。

但他也老实承认：内部化依赖意味着你回到零，需要重新建立信心和测试。这不是免费的。

我的解读是这样：当代码本身的生成成本下降，软件的价值就从“代码资产”转向“可验证的系统形状”。 以前我们倾向于复用第三方库，是因为重写很贵；Ryan 这套世界里，重写的边际成本下降了，但验证、可观测、边界、安全的成本仍然很贵。所以“用不用第三方库”这个决策，不再只是“不要重复造轮子”，而是要问：这个轮子对 agent 是不是透明？我能不能用我自己的 harness 去约束、测试、审查、修复它？

六、让 agent 能看见应用：UI、日志、指标、trace 都要变成可操作反馈

Ryan 团队后来的代码吞吐量上去之后，很快撞到下一个瓶颈：人类 QA 跟不上。

他们的解法不是雇更多 QA，而是让 agent 自己能 QA。具体做了几件事：

  • 应用支持按 git worktree 启动，每个 change 都能对应一个隔离的实例。
  • 把 Chrome DevTools Protocol 接入 agent runtime，给 Codex 写处理 DOM snapshot、screenshot、navigation 的 skill，让它自己去复现 bug、验证修复、推理 UI 行为。
  • 每个 worktree 配一个隔离的 observability stack，Codex 可以查 logs、metrics、traces，会用 LogQL、PromQL。

这一套搭起来之后，“确保服务启动低于 800ms”、“这四条关键用户路径里没有 span 超过两秒”——这种 prompt 才真正变得可执行。

Ryan 在访谈里讲了一个我觉得很有代表性的例子：他们让 Codex 直接生成 Grafana dashboard 的 JSON，然后发布 dashboard；Codex 也会响应 page。因为 dashboard、alert、log、code 都被 collate 在一起，告警发生时 agent 能知道是哪个 alert 被哪条 log 触发的；如果某个 outage 没有 page，它还可以根据已有 dashboard 找到观测缺口并修复。

这就是“agent-first 可观测性”的真正含义：可观测性不是给人类 on-call 看图用的，而是给 agent 闭环修复用的。

他还说了一个反直觉的观察：他们工程师有人花了一个下午做了个漂亮的 trace visualization 工具，结果后来发现，直接把 trace tarball 丢给 Codex 让它分析修复，反而更符合 agent-first 的路线。 因为最终修代码的是 Codex，而不是人类盯着图看完再去改。

留意一个信号：每次你在 chat 里给 AI 贴日志、贴报错、贴截图，说明这条反馈路径还没进 agent 的工具链。与其每次手动复制粘贴，不如花半小时写一个能直接拉日志、跑测试、截图、读 trace 的小工具。

七、不要 micromanage 实现，要机械化边界

Ryan 还有一条很硬核的观点：文档本身不足以让一个完全 agent-generated 的 codebase 保持一致。 你不能只跟 agent 说“请写得优雅”，也别指望它自然遵守团队的 tacit taste。那些不可妥协的架构边界和 invariant，必须机械化。

OpenAI 那篇文章里讲了他们怎么做的：把业务 domain 切成固定层级，用 custom lint 和 structural test 强制依赖方向。大致是 Types → Config → Repo → Service → Runtime → UI，横切关注点通过 Provider 这种显式接口进入，其他边一律禁止。

但 Ryan 的关键判断是：约束 invariant，不要 micromanage implementation。 比如他们要求 Codex 在边界上解析数据形状，但不指定一定要用某个库。这样 agent 既能快速出货，又不会破坏地基。

这种“七人团队做五百人公司架构”的做法，初看显得过度。Ryan 在访谈里直接回应过这个质疑：他们的仓库有差不多 500 个 NPM packages，按普通七人团队标准是过度分解；但如果每个工程师实际上在驱动 10 到 50 个 agent，那这就更像一个 350 人的团队了。深度 decomposition、sharding、清晰接口边界，这些“大公司病”的产物在 agent-first 团队里反而是必需品。

这里其实藏着一个对小团队特别有指导意义的判断：agent-first 团队的人数不能按 head count 计算，要按并发执行单元计算。 七个人加几十个 agent，已经是几百人协作的规模问题；命名、边界、依赖、复用、日志、测试、文档、ownership，必须提前结构化。

如果你已经开始让一个人挂 5–10 个 agent 干活，赶紧把“小团队就别搞这些虚的”这个心态收起来。你实际上已经是大团队了，只是 head count 没涨。

八、PR review 的未来：从逐行审查转向“可信任的证据包”

Ryan 对 review 的看法在中文圈应该会有点争议。他在 OpenAI 文章里说：人类可以 review PR，但不总是必须；随时间推移，他们把几乎所有 review 努力推向 agent-to-agent。访谈里他更直白：大部分 human review 已经是 post-merge。

听到这里你可能本能不舒服，但他自己也明确补了一句限定：他们做的是 native application，不是连续部署的高可靠基础设施；发布分支和分发前 smoke test，仍然有人类批准。

所以 Ryan 真正想说的不是“取消 review”，而是审查对象和信任机制要变。

他在访谈里有一句话我很喜欢：他希望 coding agent 在 PR 上附一个视频，展示功能在真实产品里能跑起来。 这相当于把 agent 完整的工作轨迹压缩成一个 reviewer 可读的“信任包”。

这个类比特别精准：人类同事提 PR 时，我们不会要求他屏幕录制整个写代码过程；我们只要他给出足够证据，让我们相信代码可以 merge。 Ryan 把 agent 也当 teammate 看：不要 shoulder-surf 它每个动作，而要让它产出 reviewer 需要的压缩证据。

证据可以是什么？——单元测试、E2E 测试、trace、video walkthrough、log 摘要、review agent 给出的结论、CI 状态、structural check 结果、quality score、tech debt 更新。人类 review 的价值，就从“逐行检查生成物”，转向了“检查验证体系是否覆盖了风险”。

下次你 review AI 写的 PR 时，别再老老实实一行行看了。换个问法：这个变更动了什么风险面？这些风险有没有被自动化覆盖？如果没有，第一件事是补覆盖，而不是用人眼去当 lint。

九、错误不是一次性修补，而是进入“垃圾回收”系统

Ryan 很清楚完全 agent autonomy 会带来新问题。OpenAI 文章里提过：Codex 会复制 repo 里已有的模式，包括不均匀或次优的模式；时间一长会 drift。他们最早每周五花 20% 时间清理“AI slop”，但很快发现这种打地鼠模式不可扩展。

后来他们做了两件事：

第一，把 golden principles 编码进仓库——这些是有观点的机械规则，目标是维持代码对未来 agent runs 的可读性和一致性。比如偏好 shared utility package、不允许 YOLO 猜数据形状、网络调用必须有 timeout 等等。
第二，建立 recurring cleanup process——后台 Codex 任务定期扫偏差、更新 quality score、开 targeted refactoring PR；很多可以在一分钟内 review 并 automerge。

Ryan 把这事叫 garbage collection。我觉得这个比喻特别到位——技术债像高利贷，最好持续小额偿还，而不是让它复利增长到痛苦爆发。

这个概念之所以重要，是因为它把“AI slop”从道德议题变成了工程对象。Ryan 不否认 slop 存在，他说的是：如果 agent 会复制坏模式，那就要设计持续回收坏模式的系统。所谓 human taste，不是每次人类出来骂一句“这个写得丑”，而是把 taste 捕捉成原则、lint、review prompt、quality score 和后台清理任务。

这一点，跟 Mitchell Hashimoto 在 2026 年 2 月那篇《Engineer the Harness》里讲的几乎是一回事——发现 agent 犯错，就工程化一个解决方案让它以后别再犯。Ryan 这边是在更大规模上展示了它怎么变成一个团队系统。

十、Symphony：让 issue tracker 成为 agent 的 control plane

Ryan 最近还有一项工作值得单独拿出来讲，叫 Symphony。OpenAI 在 2026 年 4 月 27 日发布了 Symphony 文章，虽然不是 Ryan 单独署名，但它直接继承了 harness engineering 实验：团队在“无人手写代码”的工作流里继续撞墙，下一个瓶颈是 context switching。

Ryan 在访谈里说，到了 GPT-5.2 之后，每个工程师每天能稳定推 5–10 个 PR；但代价是不断在 tmux pane 之间切换，人开始疯。同时管理 3–5 个 Codex session 就开始痛苦：忘记哪个 session 在做什么、agent 卡了你不知道、复杂的长任务总是要回头检查。

Symphony 的核心设计很 elegant：不要直接监督 agent，让 agent 从任务系统里拉活。 Linear 上的每个 open task 对应一个 agent workspace；Linear 的状态本身变成了一台状态机；agent crash 或 stall 了，Symphony 自动重启；新 work 出现，Symphony 自动拾取；复杂任务可以让 agent 先分析 codebase + Slack + Notion 产出 implementation plan，再把 plan 拆成任务 DAG，未阻塞的任务自然并行。

OpenAI 文章给了一个数字：有些团队上 Symphony 三周后 landed PRs 增加了 500%。 但更深层的变化是：每个 change 的感知成本下降了。人不再亲自驱动实现，所以 speculative task 变得便宜——试一个想法、探索一个 refactor、测试一个假设，不行就丢掉。产品经理和设计师甚至可以直接向 Symphony 提 feature request，拿回一个包含真实产品视频 walkthrough 的 review packet。

Ryan 在访谈里特别提了一个 Symphony 的 rework state 设计，我觉得非常符合 agent-first 思维：如果 PR 不可 merge，就把 worktree 和 PR 整个丢掉，从头再来。然后追问“它为什么是垃圾”——先修 prompt、skill 或 guardrail，再把 ticket 重新推入 progress。

这背后是一个非常不一样的成本观：当代码便宜时，保留错误路径不一定值得。 有时丢弃、补护栏、重跑，反而比 patch 干净。这种思路在传统工程师脑子里很难一下接受，但在 token 便宜、模型够强的世界里，是合理的。

十一、不要把 agent 关进过度僵硬的盒子，要给它目标、上下文和工具

Ryan 还有一个很重要的演进判断：早期的 agent 适合放在预定义 scaffold 或状态机里；但 reasoning model 一旦变强，过度僵硬的 scaffold 反而会限制它。

他们后来“反转”了系统：不是先搭一个环境再把 coding agent spawn 进去，而是让 Codex 本身成为入口，再通过 skill 和 script 给 Codex 启动 stack、设置环境变量、查询 observability 数据的能力。

在 Symphony 那边，他们也意识到把 agent 当成状态机里的 rigid node 效果不好——模型变聪明后，能解决的问题比你试图塞给它的 box 更大。早期只让 Codex implement task 太限制；后来给它 gh CLI、读 CI logs 的 skill，让它去关掉旧 PR、拉报告、做更多事情。最终他们更倾向于给 agent 一个 objective，而不是一串严格的 transition。

但他立刻又补了一句关键限定：给它 context 和 tools。 也就是说，box 不是没有，box 变成了整个 harness：权限、工具、repo 结构、workflow policy、observability、CI、lint、skill、sandbox、human escalation——共同构成一个可操作的环境。

我看到很多团队失败的 agent workflow，都掉在两个极端里：要么把 agent 关进过窄的工具箱，期待它 magically 完成复杂任务；要么给它完全开放的环境，却没有日志、测试、边界和 policy。 Ryan 的中间道路非常清晰——不要 micromanage 每一步，但要严肃设计 agent 可见的世界。给目标，也给观测；给自由，也给 invariant；给工具，也给反馈；给上下文，也给可机械执行的验收标准。

十二、文本是 agent 的血液：把经验、失败、评论、日志都“吸回仓库”

Ryan 在访谈里有句话我觉得特别准：模型 fundamentally crave text。

他们做的很多事，本质上都是在把文本注入这个系统让 agent 能用。比如某次缺 timeout 导致 page，他们直接在 Slack 里 @ Codex，让它不光是给那个调用加 timeout，还要更新 reliability documentation，把“所有网络调用都必须有 timeout”写进规则。这样团队不只是修了一个点，而是把“什么是好”持久编码进流程知识。

他们还做了一件挺有意思的事：对 session log 做 skill distillation。Codex 自己的 session log 收集到 blob storage，每天跑 agent loop 分析“团队哪里做得不够好”，再把结论反馈回 repo。PR comment、failed build——所有这些都是信号，代表某个时刻 agent 缺上下文；这些信号要被吸收，然后塞回 repo。

这件事让 harness engineering 有了一种自改进的味道。它不是一次性配置，而是持续学习系统——agent 失败 → 失败变成文本信号 → 文本信号被分析 → 规则、skill、文档、工具更新 → 未来 agent 更少失败。这个循环越顺畅，团队的经验复利越强。

Ryan 还说了一个反共识但其实很对的观察：改 agent behavior 比改 human driver behavior 便宜得多。 团队里每个人都去养成新习惯很难；但你把新习惯写进 shared skill、lint、workflow prompt 或 CI，所有 agent 立即继承，所有人间接受益。

十三、CLI-first 与 token 效率：给 agent 的工具，要少废话、结构化、只吐失败信息

Ryan 对工具输出格式有非常具体的偏好：CLI 对 agent 友好，因为 token efficient，而且容易被改造得更 token efficient。

他举了个例子：构建输出常常是一大墙文本；过去 dev productivity team 会写工具把真正异常抽出来放到顶部。给 agent 的 CLI 也应该这样——格式化命令不必输出每个已格式化文件，agent 只要知道 formatted or not；测试输出尽量只吐失败部分。

听起来是小优化，但在 agent-first 系统里是大事。人读日志可以扫一眼跳过；LLM 处理日志时，无关 token 会占 context、干扰注意力、增加成本，还可能触发错误推理。 好的 agent tooling 应该把输出压缩成“下一步行动所需信息”。

他还提了一个相关的细节：让非文本的事物也尽量适配文本形态。讨论 agent 怎么“看” UI 时他说，agent 不是像人一样用视觉感知 layout 的——有时候 rasterize 图像 + OCR、或者把 DOM/截图/导航事件一起喂进去，模型才能更好地理解它在操作什么。

我把这点单独拎出来，是因为它给所有做工具的人指了一个明确方向：未来的软件工具不只要 human-readable，也要 agent-readable。 日志、CLI、错误消息、lint message、dashboard、trace、PR comment、issue description——都应该考虑一个问题：模型看到这一段输出后，能不能直接做出正确的下一步？

这可能是 Ryan 整套观点里最容易被低估的一点：agent-first 不只是“使用 agent 写软件”，还意味着整个软件生态的接口都要为 agent 优化。

十四、Ghost Libraries：当代码便宜时，软件可以以 spec 的形式分发

Ryan 在访谈里还谈到一个挺未来感的概念：Ghost Libraries。

Symphony 的开源形式很特别，它不是先给一个完整实现，而是先给一个高保真的 spec，让 coding agent 可以在本地重新组装出来。OpenAI 那篇 Symphony 文章里说，仓库第一眼看到的是一个 SPEC.md，定义问题和预期解法，而不是只给一个复杂的监督系统。

Ryan 描述他们提取 spec 的过程也挺有意思：从内部 proprietary repo 里抽 scaffolding，开新仓库，让 Codex 参考原 repo 写 spec；再让一个断开的 Codex 实现 spec；再让另一个 Codex 比较实现与 upstream，更新 spec 让它更少偏离；如此循环，直到 spec 能高保真地复现系统。

这是一种非常不同的软件分发观。过去我们分发软件，主要分发 source code、binary、library、API。Ryan 设想里，如果 agent 足够会写代码，spec 本身就可能成为软件资产——它描述问题、边界、流程、接口、状态机、成功标准和非目标，由本地 agent 根据具体环境生成实现。

OpenAI 的 Symphony spec 就强调：它是 scheduler / runner 和 tracker reader，ticket 写入通常由 coding agent 在 workflow runtime 里完成；它不强制单一 sandbox 或 approval policy，而要求实现者明确自己的 trust and safety posture。

这有两个我觉得很值得想一想的后果：

第一，软件变得更 adaptable。 spec 可以让 Jira、Bitbucket、Linear、GitHub 等不同环境替换具体集成，只保留更柏拉图式的抽象。

第二，工程里“实现细节”的价值在下降，“可复现的高质量规格”的价值在上升。 如果 agent 能从 spec 生成不错的实现，那么真正稀缺的是：问题定义是否准确？边界是否清晰？验收标准是否可执行？安全姿态是否明确？观测是否足够？——这又回到 Ryan 的主线：工程师的价值从写代码转向设计可执行环境。

十五、Ryan 也承认限制：hard + new、复杂重构、长期一致性，仍然要人

Ryan 的观点激进，但他不盲目。OpenAI 那篇文章在结尾很坦诚地说：他们也不知道完全 agent-generated 系统的架构一致性多年后会怎么演化；也还在学人类判断在哪里最有杠杆、怎么把判断编码进去。文章的结论不是“软件工程不需要纪律了”，而是纪律更多体现在 scaffolding 上，而不是代码本身——工具、抽象、反馈回路对维持代码库一致性越来越重要。

访谈里 Ryan 把任务分了象限。他认为 hard and new 的问题仍然需要人类驱动；其他象限在合适 scaffold + drive-to-completion 的系统下，已经大体可解。人类有限的注意力，应该放在 hardest stuff——纯白纸的问题，或者最深的 refactoring——因为这些地方的接口形状还不清楚，正是人类判断最有价值的地方。

他还提到，当前模型对某些“从零到一”的产品想法和最复杂的重构，仍然需要同步互动。原因是：如果你脑子里的东西没进到模型 context 里，模型也不知道；white space 项目常常要在 agent trajectory 中才显露出缺失信息，需要 harness 或 scaffold 把这些非功能要求、模板和框架偏好提取出来。

这里的边界感很重要。Ryan 不是要把人完全移走，他是把人放到更难、更新、更高杠杆的问题上。

反过来看普通工程师：routine implementation、QA smoke、CI 修复、文档 gardening、技术债清理、review comment 处理——这些都该逐渐交给 agent；目标选择、架构方向、产品 taste、风险边界、复杂拆解——这些仍然需要人类强参与。

十六、给中文工程师的五条可操作建议

这套实验直接照搬到普通团队风险很大。它发生在 OpenAI，token / 模型 / Codex 资源、团队能力、greenfield 条件、产品类型、风险承受能力都很特殊。Ryan 自己也承认不该泛化成“所有场景都适用的脚本”。

但你不需要复制极端形式，只需要复制工程原则。 我把它翻成五条可以这周就开始做的建议：

第一条，每次 agent 犯错，都问“如何让这个错误以后更难发生”。 答案可能是一条 AGENTS.md 入口、一个测试、一段 lint、一个 CLI wrapper、一个 PR checklist，或者一个 recurring cleanup agent。形式不重要，关键是不要原地修了就走。

第二条，把不可见的知识变成 repo-local 的知识。 只在你脑子里的约定，对 agent 不存在；只在聊天记录里的架构决策，对未来 agent 不存在；只在某次 review comment 里的判断，没被吸收成规则就不会复利。把隐性经验逼成可版本化、可链接、可验证的文本和工具。

第三条，把验证权尽量交给 agent 能调用的工具。 如果 agent 能自己跑应用、看 UI、查 log、看 trace、生成视频、重跑 CI、处理 review comment，它就能端到端完成更大任务。没有这些工具，再强的模型也会反复问人、反复猜、反复产生不可验证输出。

第四条，把 human taste 编码成边界，而不是审美抱怨。 人类有品味没问题，但在 agent-first 系统里，品味必须落成 invariant：结构化日志、schema 命名、文件大小、依赖方向、数据边界解析、可靠性要求、测试质量、文档新鲜度。否则你就会一辈子在 review 里重复那句“我们这里不这样写”。

第五条，不要 babysit agent，而是设计它不需要 babysit。 你未必要上 Symphony，但可以从最小版本开始：为每类任务准备清晰的 issue、验收标准、运行命令、测试脚本、失败输出摘要、重跑规则。让 agent 自己跑、失败、重启、提交、附证据、必要时升级给人。

结语：把判断变成系统，是 AI 时代工程师的真正护城河

Ryan Lopopolo 这套观点真正预示的，不是程序员马上失业，也不是代码不再重要，而是软件工程的重心在移动。代码越来越容易生成，真正稀缺的是：目标定义、环境设计、反馈回路、架构边界、验证机制、组织知识、风险判断。人类工程师仍然重要，但重要的方式变了。

在这个范式里，优秀工程师不再是亲自写最多代码的人，而是能让一群 agent 稳定产出高质量代码的人。他不是每次都能救火的那个人，而是能把火灾模式变成传感器、护栏和自动修复流程的人。他脑子里的隐性经验不比别人少，但他会把这些经验转化成 repo-local、agent-legible、mechanically enforced 的系统。

Ryan 自己在文章最后说得很谨慎——他们最困难的挑战已经集中在 designing environments、feedback loops 和 control systems 上，以帮助 agent 大规模构建和维护复杂可靠软件。也就是说：未来的软件工程纪律没有消失，只是从代码文本本身，转移到了代码产生、验证、合并、修复和演化的系统。

如果让我用一句话总结 Ryan 的 Harness Engineering 观给中文工程师的启示，我会这样写：

AI 时代的软件工程，不是让模型替你写代码，而是把你的工程判断、团队规范、产品品味和质量标准，变成一群 agent 可以持续执行的生产系统。

懂这件事的人，未来十年会越走越轻。不懂的人，会发现自己在跟一个永远写不完代码的 AI 比手速——这比赛你赢不了，也不该参加。