从 Plan-Perfectly 到 Try-and-Improve

Source: Dev.to

（请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式、代码块和链接。）

旧方程式

在传统开发中，修改代码的成本很高。

• 编写需要时间。
• 测试需要时间。
• 调试需要时间。

每次迭代都要花费数小时甚至数天，所以我们学会了完美规划——前期投入思考，尽量减少返工。当生产成本高时，这种做法是有道理的。

新方程式

AI 重写成本结构。

当生产成本大幅下降时，投资平衡会转移。

大部分工作转向评估，而非创作。

为什么完美的计划会失败

这里有一个令人不舒服的真相：你在看到它之前根本不知道自己想要什么。

计划是抽象的。可运行的软件是具体的。

当你在计划时：

• 你想象它将如何工作。
• 你预测会出现哪些问题。
• 你假设自己已经理解了需求。

当你在构建时：

• 你看到它实际是如何工作的。
• 你发现了之前未预测到的问题。
• 你意识到自己的理解并不完整。

计划基于假设，构建揭示现实。
计划与现实之间的差距并不是计划的失败；它是复杂工作固有的特性。

Source: …

Ksql.Linq 故事

从六月到八月，我四次从头开始重建我的库。每一次重建都是一次完整的重写——架构、API 和核心概念都发生了变化。

第一次重建

发现我们没有共享基本前提。AI 与我在解决不同的问题。

第二次重建

发现我们的优先级排序不一致。我认为关键的，AI 却视为可选。

第三次重建

意识到我自己的意图不够明确，难以传达。

第四次重建

最终，形成了共享的理解。

每一次完整的重写并不是失败——它是诊断。构建和审查的过程恰好暴露了对齐中断的具体位置。借助 AI 辅助开发，每个循环只需几天时间，使发现的成本降至几乎为零。

关键技术： 在重新开始时，将其视为回滚上下文——把共享理解倒回到已知的良好点，然后以不同的方式继续。这需要保留上下文，而这正是共享内存系统变得至关重要的原因。

（关于上下文管理和共享内存的更多内容，请参阅本系列后续文章。）

核心洞见

一旦某事具备形态，任何人都可以评估它。

• 计划需要想象力来评估；不同的人模拟方式不同，导致难以达成一致。
• 可运行的实现不需要想象力——只需运行它并观察结果。评估是直接的。

这改变了策略：

尽可能快地达到可评估的状态。

Source: …

实践中的变化

原型成本低廉

当构建只需要几天而不是几周时，原型就成为常规工作流，而不是特殊的投入。
“我们应该做 A 还是 B？”变成了“我们把两者都做了再看看”。

规格随实现而来

传统流程：Spec → Build → Discover gaps → Revise spec → Rebuild
AI 驱动流程：Rough idea → Build → Evaluate → Refine understanding → Rebuild
第二条路径听起来可能浪费，但在 AI 加速的开发环境下，它更快。

失败不再刺痛

当每次尝试只花一天时，“失败”只是“学习”。
问题从“我们如何避免构建错误的东西？”转变为“我们如何尽快学到正确的东西？”

完美规划仍然重要的情况

这并不是“根本不做计划”。有些决策需要深思熟虑：

• 不可逆的选择：外部 API 合约、其他人依赖的数据模式。
• 高成本的转向：需要跨团队协同变更的架构。
• 合规/法律约束：在这种情况下“试试看”会产生真实后果。

对于这些，需要仔细规划。对于其他所有情况，则倾向于直接构建。

心态的转变

最难的不是流程，而是心理。我们被训练去重视细致的规划：“量两次，切一次”。构建可能会被丢弃的东西让人感觉不对劲。随着 AI 的出现，“切割”的成本降低了 10 倍，旧的智慧需要更新。

量一次，切，评估，如有必要再切。
这并非鲁莽，而是在新约束下的高效做法。

Summary

当 AI 让构建变得快速时，最佳策略从 完美规划 转向 尝试并改进。

不要规划你能构建的东西。构建你需要学习的东西。

这属于“超越提示工程”系列，探讨结构性和文化性方法如何在 AI 辅助开发中胜过提示优化。