备注：根据近期笔记，使用 Gemini 探索，prompt 如下： 请根据我的思考笔记： - [[H项目]]使用aicoding的用量，使用 AI 是个 ROI 决策的问题。注意：H项目不是一个vibecoding项目，而是一个拆解了结构，人工监督ai实现可靠性功能的基于openspec驱动的正式项目。 - 每日 100-200M，opus4.6 token。 input：output=50：1 - 正式使用API，可能要$8000。 灰产API一个月也要1万多人民币。 - 在项目早期搭框架阶段，浪费一些消耗，可以拿来换时间。但不应该是常态。 - 需要计算解决了多少需求，对应多少token消耗。以此来评估效率，和人力成本。还需要考虑时间维度 - 如果消耗高，则应该换其他方式实现。 - 拆架构，拆上下文，让token最小消耗解决问题。减少浪费。 - 如何监督这个过程，成了项目管理资源评估的一个新变量。 - 而不是一股脑的都丢给ai。完成项目了，也是个亏损项目。 结合英文互联网环境的讨论，请给出一篇有鲜明论点和有解决方案的博客文章。以html方式输出。
技术复盘 / 工程管理

别让 AI 变成亏本买卖：告别 Vibecoding，走向高 ROI 的 AI 工程学

从 H项目的千万级 Token 消耗看 AI 时代的软件工程经济学

最近在英文技术社区（如 Hacker News 和 X）上，AI 编程的讨论正逐渐从“蜜月期”走向“深水区”。很多人还沉浸在 “Vibecoding”（直觉/氛围编程） 的狂欢中——随口给 AI 提个需求，几秒钟吐出一个能跑的网页，便直呼魔法。

但 H项目 的实践彻底打破了这个滤镜。需要首先澄清的是：H项目绝不是一个凭感觉写代码的 Vibecoding 玩具项目，而是一个基于 OpenSpec 规范驱动、严密拆解了系统结构、并由人工深度监督 AI 以实现极高功能可靠性的正式工程项目。

然而，正因为我们摒弃了“黑盒盲盒”式的乱写，追求严谨与可靠性，我们遭遇了一个极其残酷的商业现实：使用 AI 编程绝不仅仅是个技术选择，它本质上是一个严格的 ROI（投资回报率）决策问题。

一、昂贵的“可靠性”：H项目的 Token 账单

当你不再满足于写个 Demo，而是要求 AI 严格遵守规范、阅读复杂上下文并产出生产级代码时，成本会呈指数级飙升。以下是我们在搭建 H项目框架期的一组真实数据，足以让任何技术负责人倒吸一口凉气：

这 50:1 的读写比并非毫无意义的浪费，而是 OpenSpec 驱动下高可靠性验证的代价：AI 需要不断读取系统规范、接口契约和上下文依赖，才能写出那 1 行正确的代码。但从商业角度来看，这 50 份的 Input 阅读量，都是以美元计价的真金白银。

二、核心论点：不能把亏损项目当成技术胜利

如果在项目结束时，你节省的人力时间成本，甚至覆盖不了高达 8000 美元的 API 账单，那么这就不是技术革新，而是商业灾难。

这就引出了 AI 时代项目管理的核心变量：我们需要计算 “解决一个确定的需求，到底消耗了多少 Token？对应多少资金成本？”

1. 早期可以“拿钱换时间”，但绝不能常态化

在 H项目的从 0 到 1 阶段（搭框架、验证 OpenSpec 基础链路），我们需要极高的迭代速度。这时候，“忍受高消耗去换取研发时间”在商业逻辑上是完全成立的。但当项目进入常态化开发期，如果依然保持 100M/天的极高消耗，那就意味着利润正在被吞噬，项目本身将沦为亏损项目。

2. 将 Token 消耗作为架构腐化的预警雷达

如果一个需求的 Token 消耗畸高，通常意味着：要么这个问题不适合全自动丢给 AI，要么当前的架构对 AI 极其不友好。如果消耗过高，必须果断由人工介入叫停，换一种更低碳的实现方式。

三、破局方案：如何建立高 ROI 的 AI 工程闭环？

告别 Vibecoding，我们需要的是一套真正的 “AI 软件工程单位经济学”（Unit Economics of AI Engineering）。H项目跑通的解决方案可以总结为以下三点：

💡 方案 1：基于 OpenSpec 的物理级架构拆解

面对庞大的代码库，绝对不能图省事把整个项目丢给 AI。我们在 H项目中实行了严格的物理级拆解。依托 OpenSpec，我们将庞杂的系统打碎成极小的、指责明确的模块。在交给 AI 编写或修改时，仅需提供当前模块的局部 Spec 即可。拆架构，本质上就是在拆上下文，用最小的 Token 消耗锁定问题的边界。

💡 方案 2：人工强监督与上下文节流

人类工程师的角色从“打字员”彻底转变为“资源调度员与质量监督员”。不加筛选的 Context 是 Token 吞金兽。在 H项目中，人工必须对提供给 AI 的上下文进行“节食”（Context Pruning）。精准投喂核心文件，砍掉 50:1 这种畸形的输入输出比，强迫 AI 在极度精简但准确的上下文中工作，这是减少浪费的最直接手段。

💡 方案 3：引入 AI 时代的“项目管理新变量”

项目管理（PM）必须升级。管理者不仅要监督看板上的任务流转，还要监督 API Dashboard：

  • 建立阈值：评估单个需求解决所消耗的 Token 对应的美元成本，是否优于人类工程师的时薪。
  • 过程监督：如何精细化监督 AI 的编码过程（而不是写完才发现跑偏了），成为了资源评估的新变量。一旦发现 Token 异常燃烧，人工必须立即切断并复盘。

四、结语

Vibecoding 只是一场美丽的幻梦，真正的软件工程从不相信魔法，只相信规范与经济学。

把一切需求一股脑丢给 AI，看似解放了双手，实则是放弃了作为架构师的责任。在 H项目的探索中我们深刻认识到：在未来，谁能通过 OpenSpec 拆解系统、谁能用极低 Token 成本调度 AI 实现可靠的功能、谁能把控 AI 的 ROI 边际效应，谁才能真正在 AI 时代站稳脚跟，而不是沦为大模型厂商的昂贵打工仔。

原文

源链接