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