座席需要控制流程，而不是更多提示
当大多数团队还在热衷于用更复杂的提示词(Prompt)来驱动大模型时，来自Hacker News的一线工程实践者们正在分享一个反直觉的洞见：AI在生产环境中的正确打开方式，不是让它直接“动手”，而是让它扮演一个更聪明的“阅读员”。这个观点来自一篇引发广泛讨论的帖文，其核心主张是，在CRUD（增删改查）应用中，AI最宝贵的价值在于取代那个“R”（读取、分类、理解），而不是直接去执行“CUD”。“If you want to use that same new AI based ‘R’ endpoint to auto fill forms that‘s cool, but it should never mutate anything for a customer before a human reviews it.”（如果你想用这个基于AI的“R”端点来自动填写表单，那很酷，但在人类审核之前，它绝不应篡改任何客户数据。）这句话直接点出了当前AI落地中的核心风险：将不可控的非确定性输出直接接入生产API，无异于一场豪赌。
确定性外壳下的非确定性决策：一个经检验的有效模式
这一理念并非纸上谈兵。一位来自硬件控制团队的开发者分享了他的真实案例：他们将一份人工编写的规格文档转化为TSV格式，然后让Claude编写解析器。这个过程经历了超过150次迭代，才最终让解析器处理了所有边缘情况，并生成结构化的JSON中间输出。这只是在读取环节。真正精妙的设计在于整个流水线：它作为Github Actions的一部分运行，只有当内部库校验器失败时，才会调用Claude。此时，一个Markdown文件会被发送给Claude，要求它分析故障原因并提出修改方案、创建Pull Request，随后必须经过人工审查、返工才能合并。整个系统的智力成本还不到350美元。
这位开发者进一步精辟地总结了这个模式：“deterministic agentic flows -> non-deterministic decision making -> deterministic tools”（确定性智能体流程 -> 非确定性决策 -> 确定性工具）。这意味着，外部框架是确定性的、可预期的，它将非确定性的AI决策夹在中间，形成一道安全边界。AI只负责在边界内做“决策”（如建议、分类），而最终执行“动作”的则必须是人类或经过严格测试的确定性代码。
从“提示工程”到“流程工程”：AI落地的新范式
这一套实践揭示了一个更深层的问题：AI应用的成功不在于提示词写得多漂亮，而在于如何设计一个安全、可控的“流程”。很多团队陷入一个误区，试图通过越来越长的提示词来让大模型完成“长程任务”(long-horizon tasks)。但正如原作者所言，“llm -> prompt + 确定性代码编码为技能 -> result”，如果我们能在非确定性的大模型之外，用确定性的智能体循环(agentic loop)来封装它，那么AI的能力就会被严格约束在一个安全的“沙盒”里。它最强大的地方，不是自动操作，而是像一位不知疲倦的“高级助理”——自动填充表单、提出建议、编写草案，而最终是否按下“提交”按钮的裁决权，必须牢牢掌握在人类座席手中。
对于行业而言，这意味着我们需要停止迷信“完全自动化”的终极幻觉。真正稳健的AI应用架构，与其说是用AI取代人，不如说是用AI武装人，在“智能读取”与“人工控制”之间寻找一个优雅的平衡点。未来，那些最优秀的AI产品，很可能不是“最聪明的”，而是“最守规矩的”。
