让编程智能体先估算规模再动手

给 AI 编程助手一张需求单，它可能把 CSV 导出做成一次性读入内存，也可能为一个简单筛选功能规划出 Kafka。前者漏掉规模约束，后者把问题做大了。作者给 Claude Code 做了一个 skill，让它在较大功能动工前先估算负载、阅读现有实现，再提交设计方案。

这套方法的价值，是把容易遗漏的约束提前摆出来，同时让小修复保持简单。不过，原文展示的是有限的对比观察，还不足以证明它能稳定改善交付质量。

写代码之前，先补上需求单没写的约束

作者指出，编程代理往往能完成需求明确写出的功能，却容易忽略没写出的条件。

例如，CSV 导出能正常生成文件，不代表它能处理最大客户的数据量。如果实现把整个文件放进内存，数据一大就可能失败。反过来，一个简单筛选需求如果引入 Kafka，功能还没交付，方案复杂度已经先上去了。

这两个例子指向同一个问题：代理需要先判断问题的规模，以及什么程度的设计才合适。原文没有说明它们是否来自真实生产事故，不能当成作者亲历的故障案例。

作者的做法是把这一步整理成 skill，也就是给编程代理使用的一套工作指令。它面向 Claude Code，原文称也适用于 Codex、Cursor 等工具，但没有分别介绍适配过程或验证结果。

大功能先交短方案，小修复直接处理

这套流程会根据任务大小调整处理方式。

对于较大的功能，Claude 先粗略估算负载，再阅读现有代码如何工作，然后写一份包含取舍和待确认问题的短方案，最后才编码。用户提出要求时，它还可以在终端绘制架构图。

这里最有用的是顺序：先拿现有实现和规模约束校准方案，再决定怎么改。负载估算也不需要一开始就很精确，但至少应该让设计有依据，避免凭空猜测。

设计步骤应该帮助控制复杂度，小修复仍然要保持简单。

作者特意提到，拼写修复没有被扩展成一轮设计工作。不过，原文没有给出「小修复」与「较大功能」的明确划分标准，也没说短方案是否必须经用户确认后才能继续。

下面是原文给出的安装命令，用来添加这个 skill：

npx skills add Baukaalm/system-design-first

需要核对的是命令中的 Baukaalm/system-design-first，它指定了要安装的 skill。项目免费开源，采用 MIT 许可证。

我的判断

我赞成把「读现有代码、估算规模、列出问题」放到复杂功能的编码之前。相比一接到需求就生成代码，这样更容易让开发者发现：代理究竟理解了哪些条件，又有哪些地方仍在猜。

它与手动要求代理「先给方案」很接近，差别在于把要求保存成可重复使用的 skill。相比所有任务都先规划，它又试图保留小修改的效率。这个取舍合理，实际效果取决于任务大小判断是否准确。

证据还比较薄。作者确实用相同任务做了启用和未启用 skill 的对比，观察到方案开始包含具体数字和未决问题，拼写修复也保持了原有范围。但原文没有公布任务数量、具体数字、模型版本、提示词或评估标准，也没有给出内存占用、耗时、缺陷率等结果。

所以，这目前更接近作者的经验验证。方案里出现数字，不等于数字可靠，更不等于实现已经通过验证。 粗算采用了什么假设，仍然需要人检查。

能拿来做什么

• 在 Node 服务增加 CSV 导出时，可以要求代理先检查现有数据读取方式，估算数据规模与内存需求，再决定具体实现，避免只以「能下载文件」作为完成标准。
• 给现有项目增加较大功能时，可以借用这套顺序：先读相关代码，再列出设计取舍和待确认问题，审阅后进入编码。
• 处理拼写等小修复时，可以检查 skill 是否确实控制住修改范围；评估它时，同时观察大任务的方案质量和小任务的额外成本。