在传统软件工程中积累的经验，面对 LLM 时似乎失效了。
不是因为我们不够努力，而是因为 Agent 开发存在四个结构性困境。这篇文章分享我用两套闭环来驯服这些困境的方法——一套感性的，一套理性的。
Agent 开发的四大困境
困境一："Vibe-Based" 开发
改了一个 Prompt，在 Playground 里跑了 3 个 Case，感觉（Vibe）不错，于是提交代码。
痛点："感觉"不可量化。面对概率性输出的模型，没有量化指标，上线就是赌博。
困境二："打地鼠"式维护
为了修复 Bad Case A，在 Prompt 里加了一句补丁，结果原本正常的 Case B 和 C 突然坏了。
痛点：Prompt 之间存在微妙的语义干扰。缺乏全量回归机制，导致 Prompt 越改越臃肿，越改越不敢动。
困境三："数据荒"
大家都知道"数据驱动"好，但第一批数据从哪来？产品没上线，没有用户日志。手写 50 条 JSON 测试数据？耗时且难以覆盖边缘场景。
痛点："冷启动"极其困难，优化无从谈起。
困境四：职责的"模糊地带"
- 产品经理：习惯输出确定性的功能逻辑，难以定义"概率输出"的验收标准
- 测试：习惯基于固定的 Input/Output 编写用例，面对语义模糊的数据缺乏测试资产
- 开发：被迫在代码里猜业务逻辑，既当写 Prompt 的运动员，又当看 Log 的裁判
这不是任何人的失职，而是旧的协作模式无法适配 AI 的迭代模式。
用一个"地狱难度"项目来验证
为了证明接下来分享的方法不是纸上谈兵，我用了一个真实的高难度场景来验证：构建企业级的结构化长期记忆系统。
这个系统需要 AI 从混乱的口语对话中，提取出像数据库 WAL 日志一样严谨的记忆变更指令——包含 Create（创建）、Archive（归档）、Invalidate（作废）等操作。
"地狱难度"体现在三个方面：
容错率极低。 Prompt 错一个词，把"作废"理解成"归档"，业务状态机就可能失效。
语义推理极难。 需要处理时空错位（"下周一"要转为绝对日期）、毒性泛化（"方案 A 风险高"是指哪个项目的方案 A？）、人性博弈（公开场合的"场面话"vs 私下的"真话"）。
无法"差不多就行"。 如果连这种极端场景都能跑通，那常规的 RAG 或对话任务就绰绰有余了。
路径一：感性闭环——与 AI 零代码共创
核心心法：把产品定义喂给 AI，让它教你怎么写 Prompt。
"鸡和蛋"的破解
"产品还没上线，没用户日志，没法做数据。"——这是错的。
你的 Schema 定义和业务规则，就是数据的来源。不需要等用户给你数据。
阶段一：顶层设计
四个关键技巧：
1. 先问方案，后给想法。 避免模型的迎合效应。不要说"我想用 X 方案，你觉得行吗？"，而是说"请做我的军师，推荐 3 个方案并分析优缺点"。
2. 标准先行。 用"业务契约"代替口头语言，强制对齐输入输出标准。先定义好 Schema 和约束条件，再让 AI 生成。
这两个技巧不矛盾——先问方案是发散，定标准是收敛。先确定方向，再约束边界。
3. 警惕"顺风局"。 AI 跟你共创了很多东西，它也想证明自己是对的。你需要主动让它"泼冷水"——要求它站在对立面找风险。
4. 角色扮演。 让 AI 扮演不同角色（用户、老板、竞争对手），模拟真实场景的攻防。
阶段二：场景仿真
模式先行——让 AI 枚举所有可能的业务场景模式，确保数据集覆盖业务逻辑的全集。
挖掘负向场景——不仅要知道"该做什么"，还要定义"不该做什么"。教会模型识别"这条信息不应该被记录"。
小批次生成——每次只让 AI 生成一个场景下的 5 种情况。避免因上下文过长导致质量下降。
AI 左右互搏——让 AI review 自己生成的内容，识别逻辑漏洞。
阶段三：资产固化
上下文即 Prompt——让 AI 把整个讨论过程"结晶"为可执行的 Prompt，包含所有历史决策细节。
追问"为什么"——验证模型是"真懂"还是"蒙对"。给它一个具体错误案例，让它解释背后的逻辑。
到这里，你已经通过零代码的方式，获得了一份Prompt + 数据集 + 评估标准。
路径二：理性闭环——工程化救赎
核心心法：自动化优化的价值不在于"奇迹"，而在于"度量"和"止损"。
从感性到理性
第一条路径帮我们完成了"从 0 到 1 的创造"，但它无法承担"从 1 到 100 的验证"。
零代码共创的 Prompt 在当前样本下可能表现不错，但这往往是"过拟合"的假象。为了证明系统是鲁棒的，我们需要切换到工程化验证。
核心引入两个流程：
- 评测（Evaluation）——上线前的全量体检
- 自动提示词优化（APO）——让算法代替人工去"试错"
什么是 APO
回想第一条路径的协作过程：你发现 AI 答错了 → 你告诉 AI "这里不对" → AI 改写 Prompt → 你再次验证。
本质上，这是一个"人脑驱动"的优化循环。
APO 就是把这个循环交给算法。算法拿 Prompt 去跑全量测试数据，发现分数低了，自动尝试改写 Prompt，然后再次跑分。
可观测性是关键
最初我直接在 DSPy 上执行这两个流程，但在实操中撞上了"可观测性"的墙——全程在终端进行，Log 刷屏，归因分析效率低到令人发指。
破局方案：DSPy + Langfuse。将评测过程实时投射到 Langfuse 的可视化界面上。
工作流变成了：拉取 Langfuse 数据 → 本地跑 DSPy 优化 → 结果回写 Langfuse Trace → 在 UI 上可视化归因。
两套闭环的关系
- 路径一产出的是"从 0 到 1 的创造"——Prompt、数据集、评估标准
- 路径二消费这些资产，完成"从 1 到 100 的验证"——自动化测试、优化、归因
- 两条路径形成闭环：路径二发现的问题反馈给路径一，路径一修正后再交给路径二验证
回到四大困境
| 困境 | 解决方案 |
|---|---|
| Vibe-Based 开发 | 路径二的全量评测替代"感觉" |
| 打地鼠维护 | APO 自动回归，避免修一个坏一片 |
| 数据荒 | 路径一的零代码共创生成数据集 |
| 职责模糊 | 产品负责路径一（定义），测试/开发负责路径二（验证） |
如果做一个简单的聊天机器人，这些问题可能还能忍受。但如果你要构建一个逻辑极其严密的复杂系统，这种"手工作坊"模式跑不通。
两套闭环不是万能药，但它们至少让 Agent 开发从"赌运气"变成了"可度量"。