当一个人工智能生成的最小可行产品看起来井井有条时，人们往往会忍不住立即将其转化为待办事项列表。
我试图在此刻踩下刹车。
在将原型转化为冲刺任务之前，我会进行一项剔除测试。我在与 NxCode 合作时频繁使用这种方法，因为它能让我快速得到一个可审查的工作流，但关键的决策不在于人工智能生成了什么，而在于我剔除了什么。
我的剔除测试
1. 用一句话定义核心操作
如果我无法用一句具体的话描述主要操作，说明这个最小可行产品仍然模糊不清。
示例：
- 过于宽泛：“一款用于协调内部支持的应用程序”
- 更佳：“一人报告内部事件，另一人接手处理，双方均可查看状态变更直至问题解决”
这句话成为我的基本准则。
2. 审查最小数据模型是否真正存在
在审查设计之前，我先列出最小必要元素：
- 用户
- 事件
- 负责人
- 状态
- 截止日期
如果生成的工作流没有明确显示这些数据存储在哪里，我就不会认为它是一个准备就绪的最小可行产品。
3. 寻找工作流中断的第一个点
这是最有用的部分。
我会测试以下情况：
- 必填字段为空
- 重复记录
- 错误角色执行的状态变更
- 重新打开的任务
如果原型没有展示这些情况，它仍然只是一个演示，而非可工作的基础。
4. 标记仍需人工判断的部分
我不会将这些部分委托出去：
- 权限
- 安全性
- 边界情况
- 敏感文本
- 计费或审批规则
人工智能加速了初稿的生成，但审查工作仍需由人来完成。
5. 在开启冲刺前进行裁剪
我总是试图在第一个周期中以更小的范围结束，而不是拥有更多的页面。
通常我会裁剪掉：
- 次要仪表盘
- 高级筛选器
- 早期集成
- 非必要的通知
- 过早的个性化设置
NxCode 如何帮助我
对我而言，NxCode 的价值在于：
初始想法 -> 具体提示词 -> 生成的工作流 -> 人工审查 -> 裁剪 -> 更好的交接
这有助于我基于可见的内容讨论范围，避免将速度混淆为验证。
如果你想查看该工具，可以从 NxCode 及其入门文档开始。
我的最终准则
我不问“它生成得快吗？”
我问：
“如果明天这进入冲刺阶段，我会因为今天没有裁剪掉哪个范围错误而后悔？”
这个问题比任何漂亮的演示都为我带来了更好的最小可行产品。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
