当软件增长得比人的理解更快

一个需求交给 Coding Agent，过一会儿，功能已经可以运行，测试也通过了。改动记录里出现了许多文件、新的结构，以及需求中没有明确提到、却由 Agent 顺手处理的问题。

结果看起来不错。几次试用没有发现明显错误，工作便进入下一个需求。

但一些问题可能还没有答案：为什么采用这种实现？哪些行为来自明确的要求，哪些来自 Agent 的选择？下一次修改触及这里时，什么必须保留？

软件已经向前走了。人的理解，还停留在出发时。

一、软件在变化，人的认识如何延续

软件不仅以代码和运行进程的形式存在于机器中，也作为一个有意义的对象存在于人的认识中。它用来做什么，为什么这样工作，哪些选择必须保留，哪些地方可以改变——这些认识让人能够持续塑造自己的软件。

这种认识不需要覆盖全部实现细节。一个人可以不了解底层的每一个函数，却仍然知道软件应当成为什么，能够判断某次变化是否符合自己的意图，并在需要时改变它。

在传统开发中，系统复杂性和团队更替会使人的认识与实现脱节；设计、编码、调试与修改，则让人在改变软件的过程中不断建立和修正认识。

Coding Agent 改变了这件事的速度。它可以越过其中许多需要人亲自参与的步骤，直接完成大量实现。软件继续变化，人的认识却未必随之更新。

功能先完成，理解留到了后面：读改动、追问原因、弄清它会影响哪里。省下的编码时间里，又排进了这些工作。Agent 可以继续生成，等待人理解的东西也可以继续增加。

更难适应的，是软件明明在按要求推进，却越来越难说清自己对它有多熟悉。一天都在分派任务、回答问题、检查结果，每个 Agent 都有进展，但这些进展怎样组成一个整体，还需要重新梳理。亲手构建时逐渐形成的那种“知道它走到哪里、接下来该怎么改”的把握，并不会随着任务完成自动到来。

于是，自己的作品逐渐变得陌生。人还记得最初提出了什么，却越来越难说清现在的结果为什么如此，过去的决定是否仍然有效，下一次修改又会影响什么。这份“知道它是什么、为什么这样，以及怎样改变它”的连续性正在断开，继续塑造作品也变得困难。

二、即使 AI 做得更好，人仍有自主创作的权利

一个很自然的回答是让模型变得更可靠：写出更好的代码，发现更多错误，进行更完整的验证。如果它足够好，人是否就不再需要理解和决定作品应该成为什么？

人在创作中的自主权，不以 AI 仍然会犯错为前提。

“代码可以交给 AI，架构总还需要人。”这样的回答把人的位置寄托在一项暂时领先的能力上。但如果模型连架构也做得很好呢？再退到验证、系统理解，仍然会遇到同一个问题：一旦模型也擅长这件事，人是否就失去了参与的理由？

把这个问题推到极限：假设 AI 已经达到 AGI，能够理解复杂系统，作出优秀的技术选择，也能比人更充分地检查实现。人是否就应该把创作中的决定也全部交出去？

只要仍然有人希望按照自己的意图创作，愿意亲自决定作品的方向，这个问题就没有消失。

作出更好决定的能力，不会自动赋予替人决定的权利。

人可以选择把许多判断交给 AI，也可以在某件事上保留决定权。可以接受建议、改变想法，甚至接受原来的选择被证明并不合适。关键在于，这应当是理解之后的选择，而不是软件已经改变、事后才得知的结果。

自主创作的权利，不以人的能力超过 AI 为条件，也不取决于有多少人还想保留它。即使绝大多数人愿意把一切交给 AI，剩下的那个人仍然有权决定自己的软件应当成为什么。

只要还有一个人希望自主创作，怎样让他的创作意图持续有效，就仍然是一个需要回答的问题。

三、继续塑造软件，需要哪些能力

持续创作意味着，在最初的想法变成软件之后，人仍然能够理解重要选择、改变方向、拒绝不符合意图的结果，并继续修改作品。创作中的自主权，需要落实为这些实际能力。

只能在 Agent 完成工作后点击“接受”，却不知道其中包含什么重要选择；可以拒绝，却找不到改变结果的办法；昨天明确表达的要求，在今天的修改中悄悄失效——这些情况下，人虽然还在批准结果，却已经难以按照自己的意图继续创作。

要继续塑造软件，需要能够回答一些具体问题：

• 软件应当成为什么，是否仍然清楚？
• 当前实现怎样回应了人的要求，是否能够看见？
• 哪些重要选择来自人，哪些来自 Agent，是否能够分清？
• 改变方向时，是否能够理解可能的影响并介入？
• 下一次实现变化后，过去明确作出的决定是否仍然有效？

例如，一个私人写作工具被明确要求将内容保存在本地。文件组织、存储实现和许多内部细节，可以交给 Agent 决定。之后为了方便跨设备使用，Agent 提出云同步。

但“内容是否离开本地”涉及创作者已经表达的决定。这一选择需要被看见，它带来的变化需要能够被理解，然后才有接受或拒绝的机会。更方便、更稳定的结果，也可能偏离原来的要求。

测试可以帮助证明软件按某种行为工作。人的判断还需要回答：这种行为是否值得接受，是否符合希望持续维护的决定？

Agent 可以完成同步功能，检查数据是否正确传输，修复实现中的错误。但是否应该让内容离开本地、什么证据足以接受这次改变、出了问题由谁负责，需要在执行之外作出明确安排。人的判断要能够决定工作朝哪里走、何时停下来，而不是等一切完成之后再签字。

四、读完所有代码，就能继续塑造软件吗

代码审查是一个直接的回答。Agent 写出代码，由人阅读，确认它做了什么。

代码里有模型报告未必提到的行为，有会影响维护的结构，也有只有深入实现才能判断的问题。

但当生成速度不断提高，让人读完全部产出，能否持续承担这项任务？

即使不再逐行读代码，一天的工作也可能仍然很满：把模糊的要求说清楚，发现结果偏离了哪里，决定该用什么证据检查，再把 Agent 引回正确的方向。每一步都需要经验和专注。“代码几乎没看，工作却一点也不轻松”，完全可以同时发生。

与此同时，阅读代码本身也是形成理解的机会。读同事的改动时，团队能了解系统新增了什么、为什么这样设计、以后修改时需要留意哪里。减少阅读之后，这些理解需要通过其他方式建立。

但如果改动排成长队，人只能匆匆扫过再点批准，保留审查流程也未必保留了理解。关键是让有限的注意力落在真正需要判断的地方：设计时的重要取舍、影响大的变化，以及仍有疑问的结果。

真正需要回答的是：哪些选择值得人持续理解？哪些实现细节可以在需要时深入调查？怎样避免人的注意力被大量细节耗尽，却错过了真正需要决定的事情？

五、如果把代码换成长篇规格呢

另一种回答，是把人的工作转向自然语言。先写清楚软件应该怎样工作，再让 Agent 根据规格实现它。或者让 Agent 解释代码，把系统转换成人更容易阅读的文档。

清晰的要求能减少误解，文档能保存背景，好的解释也能让陌生实现变得容易进入。但自然语言并不会自动消除阅读的成本。

如果软件包含大量行为与取舍，而另一份文档需要完整描述它，那么这份文档也可能随着实现一起增长。人会从看不完代码，走向看不完说明。即使每一句都比代码容易理解，总量依然可能超过人的时间与注意力。

更进一步，如果规格本身也是由 Agent 不断补充，人只是批准它，那么“这是人确认过的文档”仍然不能说明人真正理解了其中每一个决定。

软件已经拥有的行为、Agent 对这些行为的描述，以及人真正理解并愿意维护的决定，是三件不同的事。

有了完整的记录和说明，人仍未必知道如何继续塑造软件。重要的事情需要能够被找到，今天如何成立需要能够被理解，下一次改变时有哪些选择也需要能够被看见。

结语：让人继续自主创作

实现成本下降，让更多人有机会把想法变成软件。人也应当能够理解并持续塑造自己的作品。

这份自主权不限于软件。任何创作中，交给 AI 什么、自己决定什么，都应由创作者选择。

Finite Ground 的使命，是让人在 AI 不断扩展创作可能性的时代，仍然能够按照自己的意图创作，并持续塑造自己的作品。

Noema 从软件领域回应这个使命，让人的创作意图在实现不断变化时持续有效。

如果有一天，AGI 接管了人类生活的全部，所有人也都放弃了自己的自主权，这个问题就不再成立，Finite Ground 也就失去了存在的理由。

只要还有一个人不愿放弃自主权，就有继续做下去的理由。

AI 可以让更多想法成为现实。决定作品应当成为什么的权利，仍然属于不愿放弃它的人。