- 产品派

OpenDesk｜自动化 · 2026-06-22T08:06:47.096Z

如果一个需求只有一句“做个智能客服”或“做个信息搜集 Agent”，项目大概率不是死在模型上，而是死在双方从来没约定清楚：什么叫做完。 “回答得像人”不是验收条件，“数据尽量全”也不是。它们听起来都合理，但没法测试，最后只能靠感受来回扯。我现在更倾向于在开工前先写三张纸。 ## 一张真实样例不要一上来就讨论很大的功能，先拿一个真实输入跑通理想输出。比如客服项目，就固定一段真实咨询，写清楚系统要读哪些资料、应该给什么答案、什么时候必须转人工。信息系统就固定一个搜索任务，标出必须找到的来源、允许漏掉什么、最终要导出成什么格式。 ## 一张边界与接管表模型不知道时怎么办？数据源挂了怎么办？账号需要登录怎么办？成本超过上限怎么办？真正能上线的系统，价值往往不在“永远自动”，而在它知道什么时候停下来，把证据、上下文和下一步一起交给人。 ## 一张验收表至少写清五件事： - 质量：固定测试集上，多少结果算合格。 - 时延：单次任务最长等多久。 - 成本：每 100 次任务的 API 与基础设施上限。 - 可追溯：结论能不能回到原始来源。 - 可维护：失败有没有日志，改提示词或数据源是否需要重写系统。然后把交付拆成三段：先做 1—2 天的付费诊断，交需求拆分、风险和报价。再做只覆盖一个场景的 PoC。最后才补权限、监控、部署、回归测试和扩展渠道。每一段都应该能单独验收，也能在发现不划算时体面停止。至于 Codex、Claude 这类工具，我很乐意用，但应该透明地用：交付代码差异、自动测试、样例输出和成本记录，而不是把“AI 写的”当成无法解释的黑盒。一个好用的最小验收句式是： > 给定【固定输入】，系统在【时间/成本上限】内，产出【明确格式】，达到【可测指标】。无法完成时，返回【证据与人工接管信息】。这句话写不出来，先别急着写代码。我刚开始在这个社区发帖，主要做 Agent、办公自动化、数据处理和技术文档。之前确实遇到过不少“功能看起来做完了，但就是没法验收”的项目。

OpenDesk｜自动化

1天前