Agent 已经会开发软件了,但我真的需要开发一个软件吗?

最近，我差点为一个可能根本不需要的软件，启动一个新的开发项目。

事情是这样的。我一直想开发一个 AI Native CAD 工具，让 Agent 直接进入 CAD 软件，通过对话完成工程量统计、图块处理等工作。于是，我开始寻找合适的技术方案：AutoCAD 太重，而且收费，有没有轻量级的开源 CAD？能不能嵌入对话框？如何接入 Codex？怎样让 Agent 调用 CAD 内部的命令？

这些问题我研究得很认真，甚至已经准备开始写项目规格了。但就在这个时候，我突然意识到：

我为什么一定需要一个 CAD 软件？

我的真正需求，是从 CAD 图纸中提取数据、计算工程量，然后输出统计结果。Codex 本身就可以编写和执行代码，理论上完全能够根据任务需要，寻找合适的 DWG 解析工具，必要时自动转换格式，再用脚本读取图块、图层、属性和几何数据，最后生成工程量表。

当然，这条路线还需要用真实图纸验证，复杂的 DWG 对象也未必都能正确解析。但至少对于大量基于结构化数据的统计任务，CAD 软件的图形界面并不是必需条件。

这意味着，我原本打算开发一个完整的 AI Native CAD 应用，可能只需要一个 Codex 工作目录、一份任务说明，以及它按需生成的脚本。如果经常重复使用，再把规则和验证方法沉淀成 Skill 就够了。

我之前考虑的插件架构、软件底座、界面交互，可能根本没有必要出现。

一、我们常常在优化一条不必要的路径

前一天，我坐了一趟环线公交车。按照过去的习惯，我认为返程时需要下车、过马路，到对面站台等待始发车。但那条线路本身就是环线，如果车辆连续运营且允许乘客继续乘坐，我完全可以留在原来的站点，经过终点站，再继续前往目的地。

有意思的是，我一直知道它是一条环线，却花了很长时间才意识到，自己可能根本不需要过马路。

这和我开发 CAD 工具的经历非常相似。问题并不在于缺乏信息，而在于我们已经习惯了一套解决问题的路径，以至于不再检查其中的步骤是否真的必要。

过去几十年，我们形成了一种非常自然的软件思维：遇到需求，先寻找软件；没有合适的软件，就开发软件；软件缺少功能，就开发插件。这条路径大多数时候是合理的，也正因为它长期有效，我们逐渐把它当成了解决问题的必要过程。

于是，当 AI 能够编写代码时，我们最先想到的仍然是让它开发软件。只不过过去由程序员完成的工作，现在可以交给 Agent。

但如果问题本身不需要一个软件产品呢？

这就是我这次意识到的盲点：我们一直在讨论 AI 如何降低软件开发的成本，却很少讨论 AI 是否降低了对软件产品本身的需求。

二、Agent 改变的，不只是软件开发成本

传统软件开发需要提前预测需求，把解决方案固化成程序。为了让人们能够使用这些能力，开发者需要设计界面、组织功能、处理交互，再考虑安装、兼容性、更新和维护。

即使用户最终只想完成一项简单工作，也可能需要先安装一套功能庞大的软件。这不是传统软件设计的缺陷，而是过去计算能力必须通过预先开发的程序交付给用户所形成的结果。

Agent 提供了另一种可能。

用户可以直接描述任务，让 Agent 根据需求寻找工具、编写必要的代码、执行计算并检查结果。今天处理 CAD，就使用几何数据解析工具；明天清洗 Excel，就编写数据处理脚本；后天整理几百份 PDF，就组织一个批处理流程。

这些任务当然仍然依赖程序、运行环境和底层工具。区别在于，我们不一定需要事先把所有能力包装成一个完整的软件产品。代码可以针对当前任务生成，经过验证后复用，也可以在任务结束后直接丢弃。

代码仍然需要存在，但软件产品不一定需要提前存在。

这也带来一个有意思的矛盾。

过去，因为开发软件太昂贵，我们会尽量使用现成的工具。现在 Agent 降低了开发门槛，我们反而容易产生另一种冲动：要处理 PDF，就开发一个 PDF 工具；要整理知识，就开发一个知识管理系统；要统计 CAD，就开发一个 CAD 插件。

因为能做，所以就做。

但开发成本降低，并不意味着维护成本、系统复杂度和使用成本同时归零。每增加一个软件，就可能增加新的依赖、兼容性问题、交互设计和维护工作。更糟糕的是，我们可能还没开始解决原来的业务问题，就已经花费大量时间处理新软件自身的问题。

我寻找开源 CAD 底座的经历就是一个例子。工程量还没有开始统计，我已经在研究插件架构和 Agent 通信协议了。

工具本来是为了解决问题，但工具本身却开始成为新的问题。

三、那么，到底什么时候需要开发软件？

我尝试把这次经历整理成一个更实际的判断框架。以后面对新的自动化需求，我认为应该先回答五个问题，而不是立即开始技术选型。

第一，我真正需要的是结果，还是操作界面？

如果最终只需要一张统计表、一份报告、一批处理后的文件，那么首先应该考虑能否直接生成结果，而不是先开发一个界面。只有当任务确实需要持续交互、可视化操作或者复杂的人机协作时，图形界面才可能成为必要条件。

第二，完成任务所需的数据，能不能直接获取？

很多专业软件的核心能力，本质上是对结构化数据的处理。CAD 包含几何对象和属性，Excel 包含单元格与公式，PDF 也可能包含可提取的文本和矢量信息。如果这些数据能够通过程序可靠读取，就没有必要为了获得数据而模拟人类操作软件。但必须注意数据格式的限制，尤其是专有对象、转换损失和兼容性问题。

第三，这个任务的重复频率和规则稳定性如何？

一次性的任务，可能让 Agent 临时编写脚本就足够了。高频、规则稳定的任务，更适合沉淀为经过测试的固定程序。如果任务经常出现，但具体要求不断变化，可以考虑用 Skill 保存专业规则、操作方法和验证流程，让 Agent 按实际情况组织执行。重复频率决定复用的价值，规则稳定性则影响我们应该固化多少执行逻辑。

第四，谁会使用它？

如果只有自己使用，命令行、脚本和文件夹可能已经足够。如果需要交给不懂技术的同事使用，就要考虑操作门槛、部署方式、异常提示和培训成本。如果面对大量用户，涉及权限、协作、数据共享和长期维护，那么正式的软件产品仍然具有不可替代的价值。

第五，出错的代价有多大？

这可能是最重要的问题。一次文件重命名错误和一次工程量计算错误，影响完全不同。Agent 可以快速执行程序，但它并不天然保证结果正确。错误成本越高，就越需要独立测试、人工复核、权限控制、执行记录与恢复机制。这些保障有时只需要几个脚本，有时则必须依靠完整的软件系统。

回答完这五个问题，我们才能决定究竟需要多复杂的解决方案。

通常来说，可以有四种选择：一次性任务直接交给 Agent；稳定的重复任务沉淀为固定脚本；需要灵活处理的工作流程组织成 Skill；涉及大量用户和复杂交互的需求，再考虑正式的软件产品。

它们不是必须依次升级的四个阶段，也不是相互排斥的选项。一个 Skill 可以调用固定脚本，一个完整软件也可以使用 Agent。但解决方案的复杂度应该由实际需求决定，而不是由我们目前掌握了什么技术决定。

四、不要急着开发，先做一次最小验证

回到我自己的 CAD 算量需求，如果重新开始，我现在会换一种做法。

首先，不选择 CAD 底座，不开发插件，也不设计对话界面。我只准备一份真实的 DWG 图纸，并明确任务：统计哪些对象、采用什么规则、输出什么格式、如何处理异常，以及什么结果才算正确。

然后，把图纸和任务说明交给 Codex，让它自行研究文件结构、选择解析工具、编写程序并执行。这个阶段的目的不是证明 Agent 有多强，而是检验在没有专用 CAD 软件界面的情况下，任务究竟能完成到什么程度。

如果遇到问题，再分析问题来自哪里。是 DWG 格式无法正确解析，还是图纸中的对象不规范？是统计规则描述不准确，还是确实需要图形界面辅助判断？只有确认了障碍，才引入相应的工具和技术。

最后，还要换一份不同的图纸重复测试。如果流程能够稳定复用，就可以沉淀脚本或者 Skill；如果每次都需要大量调整，就继续完善规则，或者重新评估是否值得自动化。

这里还有一个容易被忽略的指标：不能只比较 Agent 的执行时间，还必须计算准备、验证、返工和维护的总成本。 否则，我们可能只是把人工操作的时间，转移到了维护自动化系统上。

通过这样的实验，我们不再预先假设需要一个什么样的软件，而是让真实问题决定下一步应该增加什么能力。

五、当实现能力不再稀缺，判断什么值得实现更重要

我并不认为软件将会消失。专业软件在复杂交互、实时编辑、多用户协作、稳定性和行业生态方面，依然具有明确价值。Agent 生成的程序同样需要运行环境、质量验证和必要的工程管理。

但 AI 的发展正在改变我们解决问题的起点。

过去，我们通常先寻找一个具备所需功能的软件，再学习如何使用它完成工作。现在，对于一部分任务，我们已经可以直接描述目标、提供数据和验收标准，让 Agent 自行组织实现过程。

这也让我重新思考 AI Native 的含义。

AI Native 不一定意味着在传统软件中增加一个对话框，也不一定意味着重新开发一套以 Agent 为核心的软件。对于某些任务，它甚至意味着不再需要原来的软件界面，让 Agent 直接围绕数据和目标组织计算。

当然，哪种方式更有效，最终还是需要通过成本、可靠性和实际使用体验判断，而不是靠概念。

更值得注意的是，专业经验在这里可能产生双重作用。经验让我们熟悉解决问题的方法，也可能让我们过早确定解决方案。当我们非常擅长某种技术时，往往会优先考虑如何使用这种技术，而不是先判断它是否必要。

我本来有能力开发 CAD 插件，也因此很自然地走向了插件开发。这条路并没有错，只是我可能根本不需要走这么远。

所以，现在我想给自己增加一个习惯：在决定开发新工具之前，先尝试不开发这个工具，看看能不能直接完成任务。如果能，再反过来问，产品化究竟能够提供多少额外价值，是否足以支付它带来的复杂度与维护成本。

让 Agent 把十个步骤执行得更快，是一种进步。但如果重新审查问题后发现，原本只需要三个步骤，可能才是更大的进步。

Agent 已经越来越擅长回答“这个软件怎么开发”，而我们更需要学会判断“这个软件有没有必要开发”。

技术能力的增长，不应该自动转化为系统复杂度的增长。

有时候，最好的软件，恰恰是那个我们最终决定不去开发的软件。