100个 App 开发计划 · 第 1 天|系统的上限,取决于它如何对待遗忘

记录

今日起，开启一项长期实验：独立完成 100 个 App，覆盖 iPhone 与 Mac。

工作方式已与过去不同。一位 AI 负责统筹，五位 AI 分管各条产品线，十余个执行单元并行编码、测试、部署。我不再亲手写代码，只保留三项职能：设定方向，核验结果，否决不合格之物。

首日推进了四个项目，其中一个版本完成送审。但比进度更值得记录的，是系统暴露出的四处结构性缺陷。

方法

一、承诺必须外化。
一条汇报发出后，隔了三小时才被处理。统筹的 AI 并未停工，恰恰相反，它始终满负荷运转，而那个「稍后处理」的承诺，被后来的信息淹没了。

对策是三层防护：凡作出「待某事完成即做某事」的承诺，当即写入清单；巡检时先逐条核对未兑现项；汇报中出现待决问句，即使未标记紧急，也立即唤醒决策者。

组织中的多数失误，不源于能力，而源于承诺只存在于某个人的记忆里。

二、为执行者减负，而非加码。
某条产品线进展迟缓。复盘显示，执行它的 AI 九成以上的时间耗在「理解上下文」，真正执行不足一成。它延续了一段过长的会话，每一步都要重读全部历史，同时兼顾三项互不相关的任务。

改为一事一会话、一次写清边界之后，同一个模型的效率判若两样。

速度的敌人往往不是能力不足，而是负担过重。

三、先界定问题，再动用资源。
当天出现三则成本警示：付款失败、账单滞后、一笔不明扣款。逐一追溯，结论各异：第一则是免费额度耗尽，改为本地执行即可，无需花费；第二则提醒我们不能依赖账单感知开支，于是建立了实时计量与每日硬上限；第三则恰是支撑全部项目的基础设施，反而是性价比最高的一笔。

资源最昂贵的用法，是用来掩盖一个尚未被理解的问题。

四、以真实使用为最终裁决。
一个版本通过了全部自动化测试，却在真机的第一屏即告失效。测试只能证明代码与自身假设一致，唯有真实使用，才能证明它与世界一致。此后每个版本发布前，都须在正式包上完整走一遍核心路径。

感悟

执行变得廉价之后，人的价值向两端迁移：一端是判断，决定什么值得做；一端是验收，确认做出来的东西是否为真。中间那段曾经占据绝大部分时间的「做」，正在被系统接管。

这种转变并不轻松。它不再奖励勤奋，只奖励清醒；衡量一个人的，不再是完成了多少，而是拦下了多少不该发生的事。

入夜前，当日暴露的每一处缺陷，都被整理为规则，写入所有 AI 共享的准则。明日，它们将在这些规则之上继续运转。

100 个 App 的挑战，比拼的不是速度，而是一个系统能否以日为单位，持续地减少重复的错误。

第 1 天，记录在此。