当软件可以边用边长大

我对AI时代开发方式的一点思考

今晚，Jeff 又在群里发来一篇新作，前面附了一句：

「又写了一篇拙作，给大家参考，欢迎讨论和批评。写写我对AI时代软件开发的一点不成熟的思考。」 —— Jeff

下面是这篇文章的完整内容。想保留原版排版与图示的，原始 PDF 在这里：

📄 当软件可以边用边长大（原文 PDF） Jeff 著 · 164 KB · 点击下载

我越来越觉得，AI 给软件开发带来的变化，远不止代码写得更快。它正在缩短一个过去经常被忽略的距离：从「我有一个想法」，到「我可以亲手试一试」，究竟要等待多久。

过去，需求常常要经过沟通、排期、开发和测试，用户可能数天甚至数周后才能看到功能。今天，对于范围明确的小功能，这段时间有时可以缩短到数小时。上午提出想法，下午就能上手，再根据体验继续修改。这是有条件的实践观察，并非适用于所有项目的速度承诺。

等待几周交付时，人主要在想象软件；很快就能上手时，人开始通过使用来思考软件。编码提效由此改变了需求如何形成、用户如何参与，以及软件怎样成长。

漫长而不可见的开发过程，容易让普通人感到无力：不知道需求是否被理解，也担心一次改口会带来巨大返工。亲眼看到自己的意见变成可用功能，则让人更愿意继续尝试。

让能用的软件成为沟通工具

计划驱动的开发习惯先整理产品需求文档（PRD）、设计架构、约定接口，再分工实现。这有其合理性：人工开发与多人协调成本较高，提前想清楚可以减少返工。但业务用户往往只能清楚描述眼前的问题，难以预见全部流程和例外。

例如，用户最初只想「把发票整理起来」。看到第一版后，才发现需要按供应商筛选；处理一批真实单据，又意识到必须识别重复发票。这些想法可能来自使用后的新认识，不能简单归咎于最初「没提清需求」。

因此，我更愿意从一个最小可用闭环开始：先完成一张发票的上传、识别、核对和保存。功能不多，但能从头到尾做成一件事。用户围绕结果反馈，AI 据此调整，需求记录也随之完善。

DORA 也强调「小批量工作」：缩小每次变化，有助于更快获得反馈，并控制 AI 加速开发带来的交付不稳定性 [3]。因此，我的判断不是「AI 只能做小软件」，而是：无论系统最终多大，每轮工作都应当足够小、边界清楚、能够验收。

一个实用的验收问题：拿一份真实材料，用户能否独立完成这件事，并得到正确结果？

体验驱动的渐进式开发

我暂且用这个名字概括自己的想法，它还不是成熟的方法论。我希望把开发设计成两个互相配合的循环：一个不断发现值得做的功能，一个维护继续开发的能力。

体验循环 · 每次只推进一个可用目标

治理循环 · 出现结构性问题时介入

小循环里，用户决定什么值得做，AI 负责辅助实现与验证。每轮都留下可运行版本、需求变化和检查结果，让下一轮有据可依。反馈也可以导向删减功能，而不只是不断增加。

大循环里，AI 梳理代码、数据流和依赖，说明哪些问题妨碍扩展、怎样分步改善。这里的「治理」，就是把内部关系整理清楚，让后续修改更可靠。它的完成标准应是原有功能仍然正确，目标问题有所改善。

日常小修整持续进行，跨模块问题集中评审。两个循环按问题触发，不必机械地每隔几轮就重构，更不能等系统失控后才整体重写。

这与传统敏捷有什么不同？

首先，它继承了敏捷。尽早交付、接受变化、业务与开发协作，本来就是《敏捷宣言》的核心原则；敏捷也强调良好设计 [4]。我并不认为自己发明了替代敏捷的新理论，更愿意把它看作面向非专业用户的一种具体组织方式。

表中是实践侧重的比较，并非互斥分类；成熟敏捷团队也可以采用右侧做法。

我认为，AI 的意义在于降低了这种协作的实现成本。反馈若能在同一天发生，用户还记得刚才为什么那样想，就已经可以检查结果。与此同时，许多原本由工程师默默承担的工作，需要被主动写进流程。

把治理设计进开发过程

从小功能开始，仍然需要适度的前期设计。核心数据怎样保存、谁能够访问、模块怎样分工，以及哪些选择日后难以改变，都应该尽早想清楚。可以推迟没有依据的复杂设计，但不能省略已经明确的基本约束。

Martin Fowler 讨论的「演进式设计」指出，设计可以伴随实现逐步发展，但需要测试、持续集成和重构支撑，也允许适度的初始架构 [5]。这为我的设想提供了重要基础：架构能够逐步完善，前提是每一步都有维护秩序的办法。

AI 也需要这种约束。Anthropic 在长时间运行的智能体实验中发现，一次承担太多工作、会话间丢失进展、没有充分测试便宣布完成，都会阻碍项目推进；其改进包括逐项实现、记录进度和端到端验证 [6]。这支持小步推进，但不是所有模型和项目都适用的保证。

所以，我设想每轮至少留下三样东西：可恢复的版本、更新后的需求与决策记录，以及实际验证结果。架构调整先说明目的，再分步实施，并检查已有功能是否受损。AI 自查可以帮助发现问题，却不能自动等同于质量保证。

对于非技术用户，职责也随之变化：不必掌握每段代码，却需要提供真实案例、明确优先级，并判断结果是否符合业务事实。涉及资金、敏感数据或关键业务链路时，还需要相应的专业审查。

这仍然是个人尚不成熟的思考，更适合从边界清楚、风险可控的应用开始。已有研究分别支持它的若干环节，整套方式的效果仍需实践验证。但我相信，当普通人能持续看到自己的想法产生作用，软件开发就有机会成为一种可以亲身参与、逐步学会的创造过程。

观点依据与延伸阅读

以下资料分别支持动机、需求验证与工程实践；它们并未共同验证本文提出的完整方案。正文中的编号对应下列来源。资料核验：2026 年 10 月 7 日。