给编程智能体留下设计决策的理由

AI 编程助手能保留表单代码，却未必知道你为什么坚持单页、为什么提交前必须展示摘要。下一次改需求，它可能又把流程改回三步向导。作者提出的办法是：给那些返工代价高的设计选择，留一份简短的决策记录。

这套 Design Decision Method 值得看的地方，是把「为什么这样做」和「验证到了哪一步」一起交给后续任务。但原文没有证明它能节省多少时间，订单表单也只是说明用法的假设案例。

代码留下来了，设计理由却可能丢失

原文从一个订单表单讲起：团队已经选定单页填写、提交前检查摘要，并把交付日期放在用户容易找到的位置。新提示词重新生成表单时，agent 却回到了三步向导。

问题在于，代码呈现的是最终结构，未必能解释取舍。单页可能是审美偏好，也可能是为了让用户同时核对规格、数量和价格。这两种理由，对后续修改的约束完全不同。

Design Decision Method 要求为撤销成本高的选择记录两件事：选错会付出什么代价，以及最终选择了什么模式、为什么。

值得保留的不是每次编辑过程，而是那些你不想反复争论的选择。

作者用经营小型印刷店的订单表单作示例，明确说明它不是案例研究，也没有实测结果。输入提供的原文提到了「决策行」，但没有展示具体内容，因此不能据此补出一份作者用过的完整模板。

判断表单省不省力，不能只数点击次数

这套方法要求比较五类负担：阅读、记忆、输入、导航和出错后的恢复。

三步流程每屏字段更少，看起来更清爽，但用户如果必须回到第一步确认自己填过什么，就增加了记忆和来回切换的负担。单页字段更多，也可能更方便交叉核对。该选哪种，要看任务和错误代价，不能只凭页面数量判断。

引用设计资料也有约束：只有当来源解决了一个实际设计问题时才引用，不能拿参考资料装饰结论。

如果设计偏离了所引用来源的规则，需要补一条适配说明，依次写清「来源规则 / 当前设计采用什么 / 为什么使用频率、熟悉程度或错误代价要求这样调整」。自己的调整不能包装成来源的建议。

这能让后续 agent 分清：哪些是通用规则，哪些是项目条件下的取舍。

决策记录还要交代，究竟验证过什么

记录理由不等于证明设计有效。方法第 6 步要求为每项结果标明证据状态：proposed、heuristic review、automated check、manual test 或 user research。

原文给出的表单状态很克制：

• 有效输入能否在校验失败后保留：尚未测试，计划进行手动测试。
• 提交前能否同时看到规格、数量和价格：经过启发式评审。

前一项仍然是待验证行为；后一项也没有被写成用户研究结论。文档不能把计划做的检查变成已经得到的证据。

下一周增加「加急配送」时，后续提示词从这份记录出发。agent 就能看到，单页结构与错误代价有关，于是在现有结构里增加选项。结果仍然需要人检查。

完整流程共有六步：建立上下文、选择视觉系统、先映射对象再布局、编写决策记录、组织各个视图、交付并验证。决策记录位于第 4 步。

项目如果已有设计记录，可以保存到 docs/design/<slug>.md；没有这类惯例，也可以随改动附上几行说明。仓库模板只是支架，小改动不必承担整套文档成本。该方法遵循开放的 Agent Skills 格式，采用 MIT 许可证，README 提供 Claude Code、Cursor、Gemini CLI 和 Codex 的安装路径。

我的判断

我认同把理由和证据状态一起保存。相比只写「必须保持单页」的规则，它能给后续修改提供判断依据；相比只留聊天记录，它也更便于随代码交接和复查。

但原文没有对照数据，未测量减少了多少轮提示，也未测量是否节省时间。这仍是一个有合理解释的工作方法，不能当作已经验证的提效结论。

它还有一个执行前提：后续任务确实会读取记录。把文件放进仓库，不代表 agent 自动看过。原文也没有说明记录过时、需求变化或多份记录冲突时如何处理。团队需要自行约定读取和更新方式，否则旧理由也可能变成新的束缚。

能拿来做什么

• 给订单表单这类返工成本较高的界面补几行记录，写清错误代价、所选模式和理由，优先记录跨字段核对、提交确认及错误恢复等取舍。
• 让 AI 修改已有界面时，在提示词中明确提供相关记录，并要求它说明新需求是否影响原来的设计理由。
• 把验证状态写到具体行为上，例如「校验失败后保留有效输入尚未测试」，避免用笼统的「已验证」覆盖整张表单。
• 对低成本样式调整保持轻量；需求条件变化时同步修改决策理由，别让记录只增不改。