把 AI 原型做成可维护产品：五个需要保留的决策记录

示例文章：以下内容用于演示站点结构和内容模型，发布前应由作者替换或审核，不代表作者真实经历。

原型阶段最容易丢失的不是代码，而是代码背后的判断。一次演示可以依靠默认参数、临时提示词和熟悉上下文的开发者运行；产品却需要让其他人知道系统为什么这样工作，以及何时应该改变它。

记录输入边界

先写清楚模型接收什么、不接收什么。输入边界应该包含数据来源、允许格式、长度限制和敏感信息规则。它让后续测试有明确范围，也避免把偶然成功当作稳定能力。

保存失败样本

只收藏满意输出会制造错误信心。每次调整提示词或模型时，都保留少量有代表性的失败样本，并说明失败标准。这样才能判断一次优化究竟解决了问题，还是把问题移动到了别处。

区分产品规则与模型建议

涉及权限、金额、发布状态等确定性约束时，应由普通程序执行；模型适合生成建议、草稿和排序信号。把两者分开，异常就能被定位和回退。

写明成本与延迟预算

每次模型调用都记录目标延迟、最大重试次数和成本上限。超出预算时，团队应该知道是降级、排队，还是直接失败，而不是无限等待。

为变更留下证据

决策记录不需要很长，但至少回答：我们观察到了什么、选择了什么、拒绝了什么、何时复查。它比一份事后补写的宏大总结更能帮助维护者理解系统。