# 说明书之外 当 AI 接过用户目标，厂商提供的界面、流程和公开接口便不再等于软件的实际用法。软件会被拆开、修改、组合，也可能成为另一个实现的参照。 ## Metadata - HTML: https://glenzli.com/notes/software-beyond-the-manual/ - Markdown: https://glenzli.com/notes/software-beyond-the-manual.md - Collection: Notes - Language: zh-CN - Published: 2026-07-24 - Updated: 2026-07-24 - Tags: ai, software-engineering, agents, capabilities, boundaries, lineage ## Content 最近，一种软件使用方式变得越来越常见：把目标直接交给 AI。 “帮我把这件事做完。” 很多时候，用户说到这里就够了。他不需要先判断文件为什么打不开，也不需要告诉 AI 应该改哪项配置、调用哪个工具或者按什么顺序操作。 这些问题会在执行过程中出现。足够强的 AI 会先尝试正常路径，遇到阻碍后再读报错、查文档、检查配置和文件格式。必要时，它会写脚本、调用命令行，在几个软件之间转换数据，或者补上原软件缺少的那一小段能力。 用户交出去的是目的，中间路径则由 AI 自己寻找。对软件来说，事情也因此变了：它原本为用户安排好的用法，不再是用户实际采用的用法。 ## 界面原本是一种用法预测 软件的界面从来不只是外观。 菜单放在哪里，按钮什么时候出现，一项操作要经过几步，哪些功能可以放在一起使用，这些设计都包含了开发者对用户行为的预测。 公开 API 也是一种用法设计。它把厂商愿意长期承诺的能力整理成一组入口，也表达了产品希望外部系统怎样使用自己。 当软件主要由人操作时，这种预测通常有效。大多数人会顺着界面寻找功能，也会把没有按钮、没有文档、没有 API 的地方理解为“这个软件做不到”。 AI 不一定这样看。 它面对的首先是用户目标，然后才是某个产品提供的流程。界面走不通，并不一定意味着任务走不通。只要还有可以读取的状态、可以调用的能力或者可以转换的数据，它就可能继续寻找别的路径。 于是，产品界面仍然是推荐用法，却不再天然等于实际使用边界。 ## AI 不只是替人操作 关键变化不在于 AI 能替人点击多少按钮，而在于把目标翻译成软件操作的工作也交给了它。 它会自己决定使用哪个工具、绕过哪段流程、在哪里补一段代码，以及哪些中间产物用完就可以丢掉。 这时，同一个 AI 可能先是用户，随后又临时变成集成者、维护者和开发者。 用户说得更少，软件反而可能被用得更深。对人来说，它是一个完成任务的产品；对 AI 来说，它还可能是可以读取、调用和改造的材料。 ## 完整产品也会被拆开使用 这种变化并没有让完整产品失去价值。人仍然需要清楚的界面、稳定的流程和能够直接完成工作的应用。 只是同一份软件开始同时拥有另一种身份。 一个旅行应用可以被正常打开，用来安排每天的行程；也可以只被读取其中的地点和日期，再由另一个工具生成提醒。一个排版工具可以提供完整编辑体验，也可以只贡献分页、字体检查或 PDF 导出。一个桌面软件即使没有公开 API，也可能通过文件格式、命令行或者自动化操作进入更大的执行过程。 因此，面对具体任务，“功能是否完整”不再是唯一的判断。 对当前任务来说，更实际的问题是：它是否已经足够。 有缺陷的软件，加上一个临时修补和一段可靠验证，也许可以完成眼前的工作。功能完整的产品，放进另一条流程以后，也许只剩一个很小的作用。 这种“足够”只对当前任务成立。它不能证明原软件已经正确，也不意味着临时绕行值得长期保留。它只说明在眼下的环境、权限和验证条件下，这个组合可以工作。 ## 遇到限制时，AI 不一定停下来 人与软件之间曾经有一道比较自然的分工：用户使用软件，开发者修改软件。 AI 让这道分工松动了。 当厂商设置的流程阻碍用户目标时，AI 不一定会等待下一个版本。它可能先改变调用方式，改一处本地配置，增加一层封装，转换文件，或者修补一段实现。 这种用法已经不罕见。人不必先理解产品为什么这样设计，只需要把问题和目标交给 AI，看它能不能找到一条可行路径。 这里更值得关心的，不是逐一判断每次绕行是否应该，而是这种能力已经出现以后，设计者该怎样重新理解自己的产品。 过去，流程选择和真正的系统约束经常混在一起。没有按钮、没有导出入口、没有公开某种组合方式，看起来都像是产品边界。只要大多数用户停留在界面里，这些边界也就足够有效。 AI 会把其中的差别暴露出来。有些限制确实保护数据一致性、账户安全或不可逆操作；有些则只是厂商组织功能的方式。前者关系到系统能否继续可靠运行，后者可能只是众多可行路径中的一条。 设计者未必能阻止 AI 寻找别的路径，更无法控制用户已经持有的代码、文件和结果会被怎样处理。真正需要重新思考的是：一项限制究竟保护了什么，绕开以后会发生什么，以及产品的价值是否依赖用户找不到其他路径来维持。 ## 软件也会成为参照物 AI 不只会使用和修改软件，还会观察它。 它可以根据输入输出、界面行为、错误信息、文件结构和实际结果，推测一段软件在做什么，再写出一个新的工具。 新工具可能包裹原软件，也可能组合几个现成系统；可能修改原实现，也可能完全不再依赖原软件，只把它的行为当作参考。 到了这一步，普通的依赖关系已经说不清两者的联系。新工具不再加载原软件，并不表示它与原软件毫无关系。它仍然可能继承了原来的接口习惯、行为假设和操作语义。 问题在于，软件表现出来的行为并不是完整规格。 里面可能有设计选择，也可能有兼容补丁、历史偶然和未修复的缺陷。AI 可以模仿结果，却未必知道哪些行为值得保留。一个看起来很忠实的重新实现，也可能把旧软件的错误一起继承下来。 所以，当软件成为另一个软件的参照时，只比较结果是否相似还不够。更值得追问的是，新工具继承了什么，哪些行为是有意设计，哪些只是历史留下的痕迹，以及它怎样判断自己的实现仍然可靠。 ## 开源与闭源的分界也在移动 AI 并没有让闭源软件自动变成开源。源代码是否可得，仍然会影响审计的深度、修改的精度和长期维护的成本。 但这条分界越来越难只靠“别人看不到实现”来解释。AI 可以观察行为，分析接口、本地文件和运行结果，再重现相当一部分行为与能力。闭源仍然能够限制直接复制，却不再天然阻止理解、适配和近似实现。 于是，开源与闭源的差别会更多落到许可证、合同、服务控制、数据归属，以及开发者选择建立怎样的协作关系上。闭源不只是隐藏代码，开源也不只是公开文本；它们对应着不同的控制方式、信任基础、传播路径、生态和商业空间。 设计者可能需要重新权衡：产品的价值究竟来自实现不可见，还是来自服务、数据、品牌、社区，以及持续演进的能力？AI 不会替所有项目给出同一个答案，但会让以保密本身作为壁垒的做法变得更不稳定。 ## 下游意图已经离开原作者 软件发布以后，原作者当然还可以说明它为什么存在，提供推荐流程，也可以决定公开承诺哪些接口。 但当 AI 成为直接用户，原作者很难再预设下游意图。 它可能被放进一个从未考虑过的任务，和完全无关的工具组合，或者被改造成面向另一类用户的新产品。原来的界面仍然存在，却只是诸多可能路径中的一条。 软件内部保存的是能力、行为和限制。真正决定它们怎样被使用的意图，来自此刻的用户和任务。 这也是为什么，判断 AI 能否使用一个软件，不能只看它有没有专门为 Agent 提供接口。结构化接口当然更可靠，但 AI 也会使用那些原本只为人设计、甚至没有预留集成能力的软件。 区别只在于，它需要付出多少理解、试探和适配成本，以及失败以后能否知道问题出在哪里。 ## 设计者还能决定什么 如果下游意图已经无法预设，设计者还能决定什么？ 这没有一个整齐的答案，也不能简单归结为再加一层权限，让 AI 不要越过边界。 只要资源仍然掌握在系统手里，服务端权限、数据隔离和操作确认当然可以限制一次调用造成的影响。但它们控制的是账户、数据和副作用，不是软件离开原环境以后会被怎样理解，也不是用户会拿自己的文件和本地程序做什么。 因此，设计者需要先分清自己面对的是哪一种边界。 如果一项约束保护的是数据、安全或不可逆结果，就应该把它落实在真正产生影响的系统层，同时说明它保护什么、失败会造成什么后果，而不是只靠界面隐藏入口。即使有人尝试别的路径，系统仍然能够守住不能被破坏的状态。 如果它只是产品偏好的操作顺序，设计者可能需要接受：AI 会拆开它，重新组合它，甚至找到一条更短的路径。此时更有价值的问题不是怎样要求用户回到原流程，而是原流程之外还有哪些语义必须保持稳定。 这不是放弃产品设计。界面仍然要服务大多数人，默认流程仍然可以表达经验和判断。变化在于，设计者不能再把推荐用法当作最终用法，也不能假设没有被正式提供的路径就不会出现。 ## 面对无法预期的使用 过去谈软件的可扩展性，通常是在说插件、API 和几个经过设计的集成点。 以后还要多考虑一种用户：它会阅读状态，试探路径，在遇到缺口时写一点代码，然后把软件放进开发者没有见过的组合里。 这并不要求所有软件开放内部实现，也不意味着产品必须主动支持每一种自动化。设计者需要接受的，只是界面、文档和公开接口无法再单独决定软件的实际用途。 与其试图列尽所有可能路径，不如让能力本身更容易被理解：状态清楚，错误可诊断，数据能够可靠进出，真正不能破坏的条件也不依赖界面隐藏。 这些选择无法决定 AI 最终会怎样使用软件，却能让设计者更清楚地知道，哪些变化只是换了一条路，哪些变化会让软件失去原本成立的条件。 在说明书之外，软件还可能被 AI 读取、修改、绕行、组合，并以另一种形态重新出现。厂商能够给出经过设计的默认路径，却很难再让它覆盖软件的全部实际用途。 在这样的环境里，穷尽所有使用方式并不现实。比预测更重要的，是清楚的语义、可靠的能力，以及对关键条件和后果的坦率说明。 ## 相关材料 - [AI 时代的软件开发变迁](https://glenzli.com/notes/software-cognition-in-ai-era) - [当软件的时间开始松动](https://glenzli.com/notes/software-time-loosens) - [AI Software Engineering Notes](https://github.com/glenzli/ai-software-engineering-notes)