博观而约取，厚积而薄发。
苏轼《稼说送张琥》
这八个字原本谈的是读书、积累与人才成长，但放到今天的 AI 编程环境里，却有一种意外准确的现实意义。
AI Coding Agent 正在快速降低从“一个想法”到“一个可运行实现”的门槛。过去需要几天甚至几周完成的调研、原型、代码修改和测试，如今可以在很短时间内由 AI 协助完成。问题也随之发生变化：当越来越多东西都能很快做出来时，真正困难的已经不只是“怎么做”，而是“什么值得做、什么时候应该做，以及什么值得长期留在系统里”。
本文将这种面向 AI 软件项目的开发思路称为“博约开发法”：广泛探索，但谨慎承诺；充分验证，但克制拥有；最后以最小而完整的价值切片稳步交付。
一、AI 编程正在把问题从“实现稀缺”推向“实现丰裕”
传统软件开发有一道天然的过滤器：实现很贵。
一个功能从提出到上线，需要产品设计、UI、技术方案、编码、测试、代码审核&查验、部署以及长期维护。团队的工程容量有限，因此即使有很多想法，也只有一小部分能够真正进入生产系统。
Agentic Coding 正在削弱这道天然门槛。2026 年发布的 AIDev 数据集已经识别出 932,791 个由 AI Coding Agents 创建的 Pull Requests，涉及 116,211 个 GitHub 仓库，覆盖 Codex、Claude Code、Cursor、GitHub Copilot 和 Devin 等工具。这至少说明，AI Agent 产生真实软件变更已经不再只是实验室演示，而开始形成规模化的软件工程行为。
但这里必须区分两个完全不同的成本：
Implementation Cost ≠ Ownership Cost
把代码写出来的成本，不等于未来长期拥有这段代码的成本。
一个 Agent 可能半小时就能增加一个功能，但这个功能进入生产以后，可能持续产生测试、兼容、安全、迁移、文档、运维和用户支持成本。
因此，本文把一种越来越值得关注的软件开发状态称为“实现丰裕（Implementation Abundance）”：
当团队生成候选方案和候选实现的能力，明显超过其判断、验证、整合以及长期维护这些实现的能力时，软件项目的主要瓶颈就会部分从“生产能力不足”转向“决策和复杂度治理不足”。
这并不意味着 AI 一定让所有软件开发更快。METR 在 2025 年对熟悉自身成熟开源项目的资深开发者进行随机实验时，观察到当时的 AI 工具使这些任务平均耗时增加 19%；而 METR 在 2026 年继续研究时又指出，随着新一代 Agent 普及，越来越多开发者已经不愿在“禁止使用 AI”的条件下工作，导致新的实验出现明显选择偏差。AI 对生产率的影响仍然高度依赖任务、代码库、人员和工具能力。
更稳妥的结论是：AI 正在显著扩大我们能够快速生成、比较和尝试的候选实现空间。因此，未来的软件团队不能只优化 Code Generation Rate，更要优化从“可能性”到“长期用户价值”的转化效率。
二、两道必须重新建立的边界
AI 把 Idea、Prototype、Code 和 Pull Request 之间的距离压得越来越短。一个想法刚出现，几分钟后就可能已经有能跑的 Demo。这很有价值，但也容易形成一种危险错觉：
“既然已经做出来了，就顺便加进去吧。”
博约开发法因此强调两道边界。
1. Commitment Boundary：承诺边界
第一道边界区分：
- Could Build：我们可以做。
- Should Invest：它值得我们投入。
AI 提出的功能、竞品已有的能力、团队想到的新架构、一个已经跑通的 Prototype，首先都只是 Option，而不是 Roadmap。
Option ≠ Commitment
因此，候选项不应该只有简单的“做 / 不做”，而应该至少有三种结果：
- COMMIT：证据足够，现在值得投入。
- DEFER：方向可能有价值，但证据、时机或条件尚不成熟。
- DISCARD：当前已有足够理由明确放弃。
DEFER 尤其重要。它允许团队保留未来的可能性，却不会让所有“也许有用”的想法永久堆积成一个越来越大的 Backlog。
2. Ownership Boundary：所有权边界
即使一个功能已经值得投入，也不等于它一定应该进入长期生产系统。
第二道边界区分：
- Should Build：值得验证和实现。
- Should Own：值得我们未来几年持续维护。
Implementation ≠ Ownership
一个 Production Feature 不只是代码，它还意味着兼容性、数据、权限、测试、文档、监控和支持责任。
所以在真正进入生产以前，应该问一个非常简单但很有力量的问题：
如果未来三年都必须维护这项能力，我们今天仍然愿意让它进入产品吗？
三、博约开发法：四种工作模式
“博观、约取、厚积、薄发”不是新的瀑布式四阶段流程。一个成熟项目完全可以同时存在：功能 A 正在开发，功能 B 正在塑形，候选 C 正在筛选，而未来方向 D 仍在调研。
| 模式 | 管理对象 | 核心目标 |
|---|---|---|
| 博观 Explore | Option Space | 降低认知盲区 |
| 约取 Select | Commitment | 减少错误承诺 |
| 厚积 Shape | Uncertainty | 降低高代价不确定性 |
| 薄发 Deliver | Ownership Growth | 控制新增长期复杂度 |
1. 博观：扩大认知，而不是扩大 Roadmap
博观阶段可以大胆使用 AI。用户研究、竞品分析、开源项目调查、失败案例、技术方案、商业模式、架构比较，甚至多个实验性代码实现，都可以同时存在。
关键区别是：
AI 一次产生的 30 个 Idea，是 30 个候选假设，不是 30 个待办事项。
博观也不能无限持续。当继续增加调研材料已经很少改变用户问题、主要风险、候选方案类别和战略判断时，就应该停止发散，进入下一轮筛选。
2. 约取：管理承诺，而不是追求删得多
约取不是“删除比例越高越成功”，而是提高 Commitment Quality。
可以通过用户价值、证据强度、战略匹配、替代方案、长期成本和风险等维度判断每一个候选项。对于重要方向，还可以使用 Working Backwards / PRFAQ 的思想，先回答“用户为什么需要它”，再讨论“技术怎么实现”。
尤其值得明确写出 Non-goals：这个项目当前不解决什么问题、不支持哪些场景、不追求什么能力。成熟的产品规划，不只是知道“做什么”，还必须知道“为什么这些东西暂时不做”。
3. 厚积：错误越昂贵，越值得提前验证
“厚积”最容易被误解成“大量写 PRD、架构文档和 UI 稿，然后才允许开发”。这并不是本文主张的方式。
Shape according to the cost of being wrong.
错误越昂贵、越难逆转，越应该充分塑形。
按钮文案、布局实验、Feature Flag 后面的内部功能通常高度可逆，可以快速试验；Public API、身份认证、计费逻辑、权限模型、数据库核心结构和不可逆数据迁移，则值得投入更多前置验证。
因此“厚积”的产物不应该以文档数量衡量，而应该以关键不确定性是否获得足够证据衡量。
4. 薄发：最小而完整地进入生产
“薄发”也不是做一个残缺 MVP，而是采用最小完整价值切片（Minimum Coherent Value Slice）。
一个合格的价值切片应该完成一个真实用户目标，同时具备与风险匹配的必要 UI、数据、权限、错误处理、可观测性以及合理的回滚或禁用机制。
薄，是变更面薄，不是质量薄。
工程上可以通过 Vertical Slice、Walking Skeleton、Tracer Bullet 等成熟实践来实现：不要先把整个数据库层做完、再做后端、最后才做 UI，而是优先打通一个真实用户目标所需的完整纵向路径。
四、AI 项目要大胆做实验，但不要过早拥有
AI 项目有大量无法只靠文档推演得到答案的问题：
- 模型对真实输入是否稳定？
- 结构化输出失败率多高？
- 长上下文是否明显退化？
- RAG 的召回和噪声是否可接受？
- 延迟和 Token 成本能否支撑商业模式？
- 规则代码是否其实比 LLM 更可靠？
这些问题应该尽早通过 Disposable Spike、PoC 和 Prototype 获得证据。
Prototype Is Not Ownership.
原型不是生产承诺。
也就是说，博约开发法并不反对“快速写代码”，而是反对“快速把未经验证的复杂度变成长久责任”。
这可以浓缩成一句非常适合 AI Coding 的原则：
试验可以激进，拥有必须克制。
五、五道决策 Gate
为了避免“博约开发法”只停留在哲学表达，可以把它压缩成五个日常应该反复追问的问题。它们不是五场审批会议，而是五个决策检查点。
| Gate | 核心问题 | 结果 |
|---|---|---|
| Exploration Gate | 继续研究还会显著改变当前判断吗？ | 继续 / 停止发散 |
| Commitment Gate | 当前证据足够让我们正式投入吗？ | Commit / Defer / Discard |
| Risk Gate | 如果判断错了，后果多严重、多难撤销？ | 决定 Shaping 深度 |
| Ownership Gate | 我们真的愿意长期维护它吗？ | Own / Reduce / Reject |
| Evidence Gate | 上线后的真实证据仍支持原判断吗？ | Expand / Maintain / Modify / Retire |
六、删除也应该成为正式的开发能力
AI 显著降低了“增加功能”的即时成本，却没有同步降低“删除功能”的成本。
一个功能上线后很快会出现用户习惯、历史数据、文档、API 集成和兼容责任。因此软件复杂度天然具有“只增不减”的倾向。
博约开发法因此建议进行定期的 Retirement Review（退役审核&查验）：
- 哪些功能长期无人使用？
- 哪些设置增加了大量状态，但几乎没人需要？
- 哪些 Feature Flag 已经成为永久垃圾？
- 哪些依赖只是因为过去“看起来先进”而加入？
- 哪些 API、页面和工作流已经不再产生足够价值？
删除并不是开发失败。如果某项复杂度不再值得它的 Ownership Cost，删除本身就是价值创造。
七、不同项目，不应该使用同样重量的方法
任何方法论都可能被流程化过度。博约开发法也不例外。
| 项目类型 | 建议方式 |
|---|---|
| 一次性实验 / Demo | 快速 Explore → Spike → Evidence，不需要完整文档 |
| 普通产品 Feature | 明确价值 → 轻量筛选 → 风险适配 Shape → Vertical Slice |
| 长期核心能力 | 完整 Commitment Decision + 风险验证 + Ownership Gate |
| Public API / Auth / Billing / Core Data | 严格筛选 + 深度 Shaping + 小范围、强验证交付 |
核心原则只有一个：
治理成本应该与错误成本相匹配。
八、一套可以直接落地的实践工具箱
| 模式 | 核心问题 | 可采用的实践 | 主要产物 |
|---|---|---|---|
| 博观 | 我们是否理解了足够多的可能性？ | 用户研究、竞品分析、技术雷达、AI Spike、PRFAQ 草案 | Option Map、Evidence Log |
| 约取 | 什么真正值得投入？ | Working Backwards、Non-goals、Commit / Defer / Discard | Commitment Decision |
| 厚积 | 哪些关键风险还没有被证据消除？ | Prototype、PoC、ADR、UI Test、AI Eval | Shaped Proposal |
| 薄发 | 最小且完整、值得长期拥有的变化是什么？ | MCVS、Walking Skeleton、Vertical Slice、Feature Flag | Production Slice |
| 反馈 | 它还值得继续存在吗？ | Usage Metrics、用户反馈、Rework Analysis、Retirement Review | Expand / Maintain / Modify / Retire |
九、五条核心原则
- Explore broadly without committing broadly.
广泛探索，但不要广泛承诺。 - Prototype freely; own selectively.
大胆原型，谨慎拥有。 - Options are cheap; commitments are expensive.
候选可以丰富，承诺必须珍贵。 - Shape according to the cost of being wrong.
错误越昂贵，塑形越充分。 - Deliver the smallest coherent change worth owning.
只让最小、完整且值得长期维护的变化进入系统。
十、这套方法有什么局限？
“实现丰裕”目前更适合作为一种分析 AI 软件开发的概念框架，而不是已经得到充分实证验证的软件工程定律。不同项目之间的差异也非常大：一次性原型、普通 SaaS、数据库基础设施和安全关键系统显然不应该使用同样的治理尺度。
其次，AI Coding Agent 的能力仍在高速变化。METR 从 2025 到 2026 的研究变化已经说明，仅仅隔半年，工具能力和开发者使用习惯就可能让原有实验设计变得困难。
更重要的是，博约开发法自身也有被过度流程化的风险。如果一个按钮颜色都需要 PRFAQ、ADR 和复杂审批，那么这个方法本身就成了应该被“约取”掉的复杂度。
因此它不是“流程越多越好”，而是：
让真正昂贵的错误获得足够思考，让低风险、可逆的尝试保持高速。
结语：AI 时代真正稀缺的，也许正在变成判断力
过去的软件团队经常面对：
想做的东西，远远多于能够实现的东西。
AI 时代越来越可能出现另一种状态：
能够很快实现的东西，远远多于真正值得长期拥有的东西。
所以优秀的 AI 软件开发，不应该是“想到什么，就让 Agent 做什么”，而应该形成一种新的纪律：
大胆探索，大量试验，谨慎承诺，克制拥有。
博观扩大的是认知，不是需求；约取控制的是承诺，不是想象力；厚积增加的是证据，不是文档数量；薄发限制的是长期复杂度，而不是产品质量。
也因此，“博观而约取，厚积而薄发”放到 AI 软件工程中，可以有一个非常现代的解释：
博观管理可能性，约取管理承诺；厚积管理不确定性，薄发管理复杂度。
最终值得优化的，不只是 Agent 每小时能生成多少代码，而是从可能性到长期用户价值的转化效率。
参考资料
- Design Council：The Double Diamond
- Basecamp：Shape Up
- Martin Fowler：YAGNI
- DORA：State of AI-assisted Software Development 2025
- DORA：User-centric Focus
- METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- METR：We are Changing our Developer Productivity Experiment Design
- AIDev：Studying AI Coding Agents on GitHub
评论