AI PRODUCT FIELD NOTES · 2026
一套AI产品，
如何在持续纠偏中
长出质量标准。
不是“踩过很多坑”值得展示。
值得展示的是，我没有用同一种方式再踩第二遍。
用 7 个问题，还原我如何定位根因、做出取舍，再把经验写回系统。
这些经验，
从真实研发现场长出来。
任务、纠偏、方法与架构主题彼此连接，让一次解决问题的过程成为下一次可以调用的产品能力。
个历史研发任务被整理为可回看的问题现场。
条从现象、根因到产品改变的完整记录。
条方法把一次性修复升级为下一轮工作机制。
个主题连接状态、路由、质量、成本与协作。
如果你是负责人，
你想先验证我什么？
同一段研发经历，对不同部门意味着不同能力。选择视角，页面只保留与你相关的案例。
筛选结果当前显示完整判断系统，共 7 个案例。
左右滑动查看 7 个案例 →
已打开案例编号 01 · 当前结果 1/7 · 完整判断系统
接口成功，用户却没有拿到结果。
当时看见了什么
五个主Skill被读取，成果也能保存；两个关键入口返回HTTP 200，却是空正文，流程仍停在重试中。
真正的公共根因
系统把协议成功、模型响应、流程终态和用户可用结果混成了一个“成功”。
做完这个系统后，
我给自己立下三条底线。
- 01不让AI自己宣布成功。
接口、模型、页面和保存分别成功，都不等于用户任务完成。必须回到联合成功合同。
CASE-121 · 方法109 - 02不让规则在不同地方各自决定。
页面、Skill、API与测试各写一套判断，只会制造重复提问、状态错乱和隐性返工。
CASE-092 / 095 / 110 · 方法111 / 116 - 03不拿漂亮绿灯越过证据边界。
候选通过、测试高分、零失败或没有新问题，都要先问：样本、版本、环境和原始证据在哪里？
CASE-118 / 123 / 126 · 方法106 / 130 / 177
我对“完成”的定义，
被这个项目改写了五次。
左右滑动选择五个成熟度阶段 →
会生成
- 以前容易误判为完成
- 回答看起来完整
- 后来形成的真实门槛
- 内容不虚构，能回应当前问题