ARTICLE · 1095429

AI正在把软件工程从成本变成投资:为什么一个人也开始养得起专业工程能力

发布时间：2026-09-29 07:37:21 最近访问：2026-09-29 07:37:22

我先给大家看一张表。

我没有传统的软件开发背景，但最近几个月，我一直在借助 AI 开发一个复杂的系统。

项目做到今天，为了不让它在快速迭代和多个 Agent 并行施工中失控，我实际已经开始维护下面这些工程机制：

工程机制	它解决什么问题
场景工程	一个真实用户目标怎样开始、完成、失败和恢复
产品义务追踪（Obligation Traceability）	每一条产品承诺到底有没有工程承载
架构责任分配	一件事情到底由谁负责、谁拥有最终权威
执行单元（Execution Unit）	把长期工程责任划成稳定责任域
执行切片（Execution Slice）	把责任继续拆成可以施工和验收的工程切片
接口 / 依赖图	谁依赖谁，哪些能并行，哪些必须先完成
变更影响分析	改一处以后，哪些场景、接口和旧证据需要重新验证
验收 / Evidence	怎样证明“完成”，而不是只证明“代码写了”
配置、版本和资产治理	当前事实是什么，历史资产属于谁，怎么交接
CI / Semantic Validator	自动发现工程关系的缺边、漂移和矛盾
Prewarm	让 Agent 从“看过项目”进入真正可施工的理解深度
多层独立评审	自评、内审、外部反证，避免一个模型自己证明自己
Delta Alignment	版本变化以后只更新差异，而不是重新理解整个项目
Field Reconciliation	把目标工程设计与仓库真实代码、资产重新对齐

注意，这里面还没有算真正写产品代码的工作。

这些劳动只是在回答：

为什么要做？谁负责？和谁连接？哪里可能坏？修改以后影响什么？最后怎样证明这个产品路径真的成立？

传统公司当然不一定会为每一项单独设岗。小团队通常多人兼任，大型组织则可能拆成需求 / 系统分析、架构、QA/V&V、配置管理、CI、安全、技术项目管理等不同专业职责。

如果持续覆盖这些职责，往往意味着几个资深岗位长期共同承担。

以北京目前公开招聘为参照，高级测试开发岗位常见约 2.5–4.5 万元/月，测试专家和 Leader 可达 5–9 万元/月以上；架构类岗位从约 3–4.5 万元/月一直到 6–9 万元/月甚至更高，安全架构也属于资深专业岗位。也就是说，把这一组专业职责长期组织起来，人力成本进入每年数百万元人民币的量级并不难理解。这只是数量级参照，不代表任何项目必须照这个编制招聘。

而我现在的情况是：

一个人。一台电脑。加上一组按需调用的 AI Agent。

而且更反常识的是：

这里面很多软件工程方法具体怎么实现、怎么维护，我其实并不会。

我能理解它为什么存在。能理解它解决什么问题。能做产品取舍。

但追踪关系怎么维护、依赖闭包怎么算、Validator 怎么写、版本变化以后怎么重新核对，大量具体工作实际由 AI 完成。

所以我真正想讨论的问题不是：

AI 能不能让普通人写程序？

而是：

为什么过去需要一支专业团队长期维护的软件工程能力，现在一个个人开发者开始用得起了？

我越来越觉得，答案不是 AI 发明了新的软件工程。

而是：

AI 重新给软件工程定价了。

一、为什么很多资深工程师看 Vibe Coding，会说“能跑，但还不能交付”

现在越来越多没有传统开发经验的人，开始借助 Codex、Claude Code 之类的 Agent 做软件。

几天时间，就能做出：

语音输入；

图片识别；

AI 搜索；

学习工具；

文件管理；

一个看起来相当完整的 App。

这些功能完全可能真的能跑。

但很多资深工程师仍然会问另一组问题：

网络断了怎么办？ API 超时怎么办？权限会不会越界？数据写到一半崩溃怎么办？升级以后旧数据怎么办？改一个接口会不会悄悄弄坏另外几个场景？出问题以后能不能定位？失败以后能不能恢复？三个月以后还能不能继续维护？

所以：

功能做出来，不等于产品做出来。

可以粗略分成三个层次：

Demo：Happy Path 能跑。

Feature：单个功能在定义范围内相对完整。

Product：大量 Feature 被组织成一个长期可运行、可维护、可升级、可恢复、可验证的整体。

第一波 AI 编程极大降低了：

Feature Production

的成本。

真正值得观察的下一步，是 AI 能不能继续降低：

Product Engineering

的成本。

也就是：

普通人能不能用个人开发者的成本，把这些功能治理成一个真正的软件产品？

二、过去个人开发者为什么很少搞这么重的工程？因为不划算

成熟软件工程师真正昂贵的，不是敲键盘。

而是他背后积累的人力资本：

多年的学习；

实际项目经验；

大量失败以后形成的判断；

持续更新知识的成本；

某个行业和技术栈里的专用经验；

以及为这些能力支付的机会成本。

而复杂软件需要的还不是一种专业能力。

需求、架构、测试、安全、配置、质量和技术管理，本来就是不同的专业领域。

即使一个公司没有这些正式职位，这些劳动也不会消失，只是由别人兼任。

所以传统复杂软件工程真正贵的是：

先花很多年培养不同专业的人，再让这些人长期共同工作。

同时，治理还是持续性成本。

项目持续两三年，需求追踪、架构维护、配置管理、验证和版本治理也要持续两三年。

项目周期越长，同一套工程机制的持有成本越高。

过去个人项目往往选择：

少一点治理，快一点上线，出了问题再修。

很多时候，这是正确的经济选择。

不是工程纪律没价值。

而是：

ROI 不成立。

三、AI同时改变了三种价格，却制造出一种新的稀缺资源

第一，专业知识取得成本下降

过去想使用一种成熟工程方法，通常要先学会它。

现在顺序可以反过来。

我先提出问题：

“我要知道每个用户场景到底经过哪些工程责任，改一块以后又会影响哪些场景。”

我甚至不需要先知道 Requirements Traceability、Architecture Allocation、Impact Analysis 这些名字。

AI 可以把问题映射到已有的软件工程知识，再根据当前项目产生方案。

于是人需要掌握的东西开始上移到：

它解决什么问题；边界在哪里；是否符合我的产品目标。

大量具体实现可以由 Agent 承担。

第二，专业工程劳动成本下降

过去每次设计变化以后重新：

查追踪关系；

重算依赖；

分析影响面；

更新验证关系；

做独立评审；

主动构造反例；

都是昂贵的高级工程劳动。

现在其中相当一部分开始变成：

Token + 算力。

我们实际会让不同 Agent 分别负责：

设计 → 自评 → 内审 → 独立攻击。

过去让几个资深工程师轮流攻击一个普通软件设计，成本可能不合理。

现在第三个、第四个 reviewer 的边际成本已经显著下降。

第三，项目周期下降

Agent 不只是单点工作快。

还可以并行。

一个 Agent 读代码，一个查接口，一个盘资产，其他 Agent 同时处理不同责任域。

大量过去按周、按月计算的分析、整理和实现活动，现在可以被压缩到天甚至小时。

所以至少三个价格在下降：

Knowledge Acquisition Cost ↓ Engineering Labor Cost ↓ Project Duration ↓

但这并不意味着一切都变便宜。

相反，一种新的稀缺资源变得越来越明显：

人的判断和注意力。

AI 可以一天给我十份方案、几十个 unresolved decision。

但：

哪件事值得做？哪个产品目标重要？哪个风险可以接受？哪套设计太重？哪一层治理应该砍掉？

这些问题仍然不能简单外包。

模型天然倾向于继续结构化：

再加一层状态机；再加一个 gate；再多一次 review。

Owner 的重要职责反而越来越像：

做价值判断、控制复杂度、分配注意力，以及踩刹车。

AI 降低了知识、劳动和时间的价格，却把稀缺性进一步推向了人的判断。

四、我不懂这些专业细节，那我凭什么相信 AI 做的是对的？

这是最合理的质疑。

答案不是：

“因为 AI 懂软件工程。”

我也不会把一个模型的自信当成正确性。

现在我实际依靠的是几层互相独立的检验。

第一层：多模型交叉反证

一个模型负责设计，另一个模型不接受它自己的 PASS，而是专门找漏洞。

不是“几个 AI 投票”。

而是：

作者负责构造，Reviewer 负责攻击。

第二层：故意制造错误

如果系统说某条工程关系必须存在，我们就直接删掉它。

然后看 Validator 会不会变红。

如果删掉一条必要关系，系统仍然 PASS，那么说明我们的治理本身就是假的。

第三层：最终仍然要回到真实运行

任何设计文档、Validator、模型评审都不能替代：

真机、真实构建、真实产品场景。

所以我自己的角色并不是掌握每一种软件工程技术的全部实现细节。

我负责的是：

产品方向；

价值判断；

约束；

优先级；

成本预算；

最终取舍；

什么时候停止过度设计。

AI 可以替代大量专业操作。

但不能替代最终责任。

换句话说：

AI 降低的是使用专业知识的门槛，不是取消人的判断责任。

五、软件治理为什么开始像一笔投资，而不只是成本

这是我现在最想给个人开发者建立的观念。

我们目前维护着类似这样的工程链：

场景 Scenario → 产品义务 Obligation → 执行单元 Execution Unit → 执行切片 Execution Slice → 接口 / 依赖 → 验收 / Evidence

第一次建立这张图当然要花钱。

但它不是一次性消费。

以后任何修改，都可以反向知道：

影响哪些场景？哪些接口需要重新确认？哪些旧证据已经失效？

它会持续产生一些工程红利：

少做不应该做的东西；

少重复造轮子；

减少返工；

提前发现权限和安全边界问题；

减少隐藏耦合；

更快定位 bug；

更精确地做回归；

减少 Agent 每次重新理解项目的成本；

把只存在开发者脑子里的知识沉淀到项目里。

可以粗略地把这笔账理解成：

Governance ROI = 生命周期中减少的返工、缺陷、安全风险、协调和认知重建成本 − 治理本身的维护成本

但必须说一句非常重要的实话：

我自己的项目目前还处在投资期，这个 ROI 还没有被证明。

投入已经真实发生，而且并不小。

一次大规模深度 Prewarm，一天可以消耗我 60%–70% 的 Codex 额度。

此前某些阶段，治理和调度甚至占过约 25%–33% 的 Token 消耗；我的长期目标是把这一比例压到大约 3%–10%。

而到目前为止，还没有一个完整用户场景真正从：

NOT_RUN

走到：

RUNTIME_PROVEN

所以现在不能宣称：

“这套方法已经证明自己更高效。”

真正的检验将在下一阶段发生：

当我们开始沿真实场景施工以后，这些前期工程投入到底有没有显著减少返工、缺陷、定位时间和后续维护成本？

如果没有，

那这套方法同样应该被削减。

六、工程图本身也必须能被攻击

我们实际遇到过一个很有意思的例子。

有一版工程包，人工看起来已经相当完整。

场景有责任单元。

执行切片也反向标了场景。

后来独立模型做了一个破坏：

把某个场景与全部执行切片之间的关系删除。

结果 Validator 仍然 PASS。

这说明：

有 Traceability 文档，不代表有真正可执行的 Traceability。

我们随后补上权威的 Scenario → Slice Assembly，并让校验器真正检查它。

继续攻击以后，又发现第二层问题：

场景与切片虽然完整，但把场景要求的几条产品义务删除以后，Validator 仍然可能 PASS。

也就是说：

Scenario → Slice 完整，

并不能自动证明：

Scenario → Obligation → Slice 完整。

截至现在，这第二层关系仍然是我们正在修的工程问题之一。

我反而觉得这件事情很重要。

因为它说明：

这套方法本身也没有因为写进工程包，就获得豁免。

它必须继续接受自己的反证机制。

我们把这个方向叫做：

Executable Traceability。

一个已经确认必须存在的关系，如果无声消失，机器就应该自动报错。

但它只能保证：

一致性。

不能自动创造：

正确性。

所以一句非常重要的原则是：

Validator guarantees consistency, not truth。

设计最初是不是正确，仍然需要人、独立 Reviewer 和最终运行证据裁决。

七、“完成”也必须拆成三层，否则工程文档很容易制造幻觉

我们现在至少区分三个状态。

Design Closed：设计闭合

场景要求的责任、切片、依赖、接口和验收路径已经完整。

Implementation Bound：实现绑定

这些工程对象能够绑定到真实代码、资产和具体 Source SHA。

Runtime Proven：运行证明

同一个受控版本，在真实设备和真实条件下，把完整场景跑通并留下证据。

只有最后一层，才是真正的产品事实。

前两层再漂亮，也不能冒充第三层。

而一旦相关实现发生变化，旧的：

RUNTIME_PROVEN

就可能重新进入：

REVALIDATION_REQUIRED

直到真实证据重新建立。

八、Agent 的“理解”本身也开始变成一种资产

Agent 第一次真正理解一个复杂工程责任域，同样很贵。

它需要读：

产品定义；

历史方案；

当前代码；

资产；

接口；

依赖；

已知问题；

验收方法。

我们把这个过程叫做 Prewarm。

第一次投入很高。

所以不应该每个版本重新支付。

完整 Prewarm 做完以后，后续默认应该：

只维护 Delta。

什么发生变化，就更新什么。

这种知识积累很像一种上下文资本。

它能不能复利，又依赖另外一个条件：

工程身份要相对稳定。

如果责任单元不断拆分、合并和重编号，旧知识不会全部消失，但要重新支付迁移成本。

所以 lineage、split / merge、successor mapping 这些枯燥记录，其实是在保护以前已经支付过的认知投入。

九、最后还要防一件事：便宜的官僚主义

AI 不仅能让好的工程方法变便宜。

它同样能让坏的流程变便宜。

一个 Agent 可以非常容易地生成：

几百页文档；

状态表；

架构图；

Review；

Validator；

PASS。

这会产生一种新的风险：

Engineering Theater。

工程体系看起来越来越专业，产品却没有更快交付。

这不是我拿来提醒别人的问题。

它正是我自己的项目现在必须接受的检验。

我们已经投入了大量工程治理成本。

但真实场景的运行收益还没有兑现。

所以接下来的判断标准非常简单：

如果这套治理不能让真实用户场景更快、更稳定地从 NOT_RUN 走向 RUNTIME_PROVEN，它就没有资格因为自己“很专业”而继续膨胀。

工程治理必须有预算。

也必须有退出机制。

十、AI 真正重新定价的，也许是“把功能变成产品”的能力

今天大家最容易看到的是：

AI 让代码变便宜了。

但这可能只是第一阶段。

更深的一层变化是：

AI 正在重新定价专业知识、专业工程劳动和时间。

过去一个个人开发者可以自己写一些功能。

但如果想长期拥有成熟软件组织的工程能力，就必须支付昂贵的专业人力成本。

现在，这第二层成本也开始下降。

这不意味着：

一个人 + AI 就等于银行、军工或者航空系统的 assurance 水平。

当然不是。

那些系统还有法规、认证、组织责任、独立审计和真实运行验证。

真正变化的是：

个人开发者开始可以用极低的边际成本，调用过去主要由成熟工程组织长期维护的很多工程思想、流程和验证方式。

所以在 Agent 时代，我越来越倾向于一个和过去不同的判断：

个人软件开发中的工程治理，可能不再只是应该尽量省掉的 overhead。

当少量 Token 的治理投入能够持续减少：

返工；

bug；

安全风险；

协调成本；

认知重建；

长期维护成本；

它就开始具有投资属性。

当然，这笔投资必须最终证明自己的回报。

但如果 AI 真能把治理成本压低到足够小，而工程红利可以贯穿整个产品生命周期，那么过去个人开发里的一个经典判断可能就要反过来了：

以前，不做软件工程是为了省钱。

以后，不做软件工程，可能才是更贵的选择。