AI 时代,企业请放下对一次性做对的执念

最近在读为什么伟大不能被计划。

读的时候我想起经常问自己的一句话，这件事对目标有什么帮助？

AI 在企业中的应用越来越广泛，“又快又好”这句看似矛盾的需求又一次被拉出来重新审视。

在我自己的使用中，AI 已经能够相当准确地理解明确的指令，把要求落实到实现。在执行和理解任务上，它甚至比很多人做得更明白、更利落。

执行能力的变化，让“快”和“好”有了同时成立的可能。

但我觉得，越是在这个时候，越需要警惕对“一次性做对”的执念。

一、企业到底有没有接受不确定性

过去，做错或者做偏之后，纠正的成本很高。所以组织倾向于在前期投入大量时间，试图把目标、需求和验收标准定清楚。

但现在，借助 AI，把一个想法做出来，再根据反馈修改，成本已经低了很多。

执行能力再强，也要面对指令本身是否成立的问题。商业世界充满不确定性。有时连问题是什么，都需要在过程中慢慢认识。

如果组织仍然习惯先把需求定义好，拆成任务，估好时间，再交给执行层完成，上游负责说什么是对，下游负责把它做对，然后再加上“一次做好，别返工”，就有了一个很强的假设，答案可以提前知道，执行过程中也不应该再改变。

可是，想清楚需要的信息，恰恰可能要动手之后才能获得。你要求人在接触现实之前，就交出被现实验证过的答案。

惩罚修正，可能会保护最初的错误。

如果什么都不改，至少看起来是在按计划完成。修改越多，越需要解释自己为什么没有一次做对。

所以我觉得，现代企业经常低估行动带来的信息，却高估事前思考能够获得的确定性。把需要探索的事情也当成能够事先定义完整的任务，嘴上要求创新，实际可自由探索的空间却被压缩，只是为了避免不确定性。

AI 让很多想法更容易被做出来。如果组织仍然把迭代识别成麻烦，它拿走的就只有执行提速，探索的空间却没有增加。

二、伟大为什么不能被计划

这本书让我对“目标”开始产生怀疑。

书里谈到，通往重要成果的垫脚石，往往看起来并不像那个成果。沿途那些真正有用的东西，未必能被“有没有更接近目标”这个标准识别出来。盯着目标，可能反而把它们过滤掉。¹

回到开头，我还是会问，这件事对目标有什么帮助？

有些帮助，现在确实说不出来。一个尝试没有达到预期，却打开了另一种可能；一个意外发现，可能让人意识到，原来真正值得解决的是另一个问题。

如果每一步都必须提前证明自己对目标有用，这些东西就很难留下来。

所以我开始想，有些探索性的事情，是不是应该故意把目标设得模糊一点，甚至暂时不设那个必须抵达的终点？保留一个感兴趣的问题，守住投入和风险的边界，不断尝试，看过程中会出现什么。

这样才有机会出现涌现，长出最初没有设想过的东西。

当然，这需要共同承认暂时不知道答案。如果上游把要求说得含糊，验收时却拿出一个确定的答案，那仍然是在要求下游猜中它。那种模糊留给人的探索空间很小。

最近 DHH 的一系列“暴论”，也给了我一些信心。

去年，他还说宁可退休，也不会把键盘永久交给 AI。今年九月，他说手写代码对大多数程序员来说，已经不是一门划算的手艺了。³

他亲手创造了 Rails，也花了很长时间追求代码的表达。但现在，他可以一边说自己厌恶 Rust 的语法，一边让 AI 用 Rust 把东西做出来，因为他认可它的 memory safety 和效率。他还说，如果出现更好的语言或更好的 Rails，他自己就会去用。²

我受到触动的，是他愿意重新判断那些自己热爱、擅长、投入了几十年的东西。

他在同一访谈里谈到，自己最初学编程，是因为想让某些程序存在。后来爱上了编程这门手艺，投入了二十年。现在，AI 又让他回到那个迫不及待想把想法做出来的状态。²

这种转变很有冲击力。过去帮助我们实现目的的手艺，也应该允许被新的现实重新衡量。

可我仍然看到一些人，坚持自己手写代码、逐行 review、亲手写文档。每一步都经过自己的手，让人觉得踏实，觉得事情仍然在掌控之中。

但是这种安全感有多少来自对结果的验证，又有多少只来自对过程的熟悉？代码亲手写了，文档亲手记了，判断就一定正确吗？

这些工作做得再仔细，仍然可能把错误的设想完整地实现出来。

这些工作可以有价值，但“我亲手完成了”本身，很难证明价值。我们需要问的是，它有没有帮助发现问题、改善结果，是否仍然值得花这些时间。

那些曾经代表专业的习惯，也应该接受这个检验。

三、什么是快，什么是好

“又快又好”到底是什么意思？

我现在同时在做三款 app，一款跨端的健康管理 app，一款面向 agent 时代的 macOS 磁盘清理 app，还有一款以设计为主的 iOS app。

它们让我对快和好有了很具体的感受。

跨端产品正在经历阵痛。底层 architecture 已经不适应新的功能，要重构。先重新梳理 domain boundaries、entity responsibilities 和 business semantics。把规则写成 domain contracts，再让 AI 梳理 entry points、列举 state transitions 和 boundary conditions 的组合，补 counterexamples，在 shadow mode 下 replay 旧业务的变化、做 reconciliation。结构可以重新搭，facts 不能在 migration 里丢掉。这是重构里可以持续分析、枚举和验证的部分。AI 帮我穷举已知规则下的边界组合，原来混在脑子里的东西，现在有了位置，我来决定取舍。

macOS 产品走到 0.6.0，我发现以前的功能完全不够好用，直接全部重写。原来按工具摆开的扫描结果，需要用户自己拼出关系。现在我想让一件工作把散落在 repository、worktree、temporary directory 和 container 里的占用连起来，让人能看懂，敢清理。

以设计为主的 iOS app，基础功能做好之后，时间开始花在具体的交互细节上。非匀速的 easing curve、spring animation 的 duration 与 bounce、素材之间的 stagger delay，都要来回调。下拉收起时，页面要跟着指尖；松手取消时，又要自然回到原位。起步、落位、收回，每一段都得接得上。功能能运行之后，还需要一遍遍看实际效果才能磨出来。

这三款产品都在反复，原因却不同。有的要重新理解结构，有的要推翻已有答案，有的要把已经成立的方向逐渐做好。如果统统算成“之前没想清楚”，就把产品是怎样变好的这件事抹掉了。

我愿意全部重写，也愿意花时间打磨一个动效。这也让我更理解 DHH 的转变。实现手段可以换，对产品结果的判断持续保留，精力跟着它走。

所以，快需要看时间花在了哪里。从一个想法，到获得足以影响下一步判断的反馈，应该尽量缩短。已经获得的反馈，也应该尽快影响下一步行动。

快，不是每一步少花时间，是从想法到反馈的距离短。

一次过审，看起来更顺利。但被现实推翻两次，也可能让我们更早知道，什么才值得继续做。

需要重构，就重新梳理；发现不好用，就修改；一个动效值得继续打磨，就给它时间。

这样理解快，就不能要求每个步骤都少花时间。要尽早知道哪些工作值得做，哪些判断需要改，哪些细节还需要投入。返工少，也可能只是问题发现得晚。

好也需要分情况。

如果我们已经明确知道什么是对，验收标准也说得清楚，那就可以让 AI 执行，检查结果，修改，再检查，快速趋近目标。目标明确，并不意味着第一次就能抵达，也没必要把一次通过当成最重要的能力。

如果连什么是对都不知道，就要看这些尝试有没有让我们更了解问题，有没有发现值得继续的方向。做出一个完全符合原始需求、却没有人需要的东西，很难叫好。

最终交付的质量要守住。过程中，一版被推翻、一条路走不通、一个目标被修改，都可能是获得这个质量需要付出的成本。

我们能提前做清楚的，是风险边界，哪些后果承受不起，哪些东西不能碰，最多能投入多少。边界里面，应该给人快速行动和修改判断的空间。

快可以帮助我们发现什么是好，好也可以在这个过程中被重新认识。

如果我们承认商业世界充满不确定性，就要允许反馈改变做法，也允许反馈改变目标。已知什么是对，就快速迭代趋近它；还不知道，就动手去发现，甚至沿着意外出现的东西走下去。

“又快又好，还不能返工”，要求我们获得探索的收益，同时不承担探索的代价。

企业最该放弃的，就是这种一次把事情做对的执念。知道什么是对，也不等于一次就能做对。还不知道，就更应该允许尝试、修正，以及意外的发现。

如果真想改变什么，就应该给人重新判断这些标准的空间。连判断标准都不能改变，究竟允许什么发生改变？