AI代理还是手写代码？三个问题定生死

我见过一个团队花三周写规则引擎，结果一个提示词五分钟搞定。也见过有人把简单增删改查硬塞给代理，账单烧穿，调试地狱。工具越丰富，选择越致命。

这不是取代开发者，是选对扳手

Claude Code、OpenCode、各种代理框架陆续成熟，"要不要上AI"从闲聊变成架构决策。选错的真实代价：时间、钱、可靠性。

作者提了三个问题，按顺序问。答案自然浮现。

第一问：失败时会发生什么？

这是根本分野。

代理出错，可能是幻觉、格式错乱、理解偏差。代码出错，是崩溃、死循环、数据损坏。两种失败模式完全不同，修复成本也不同。

如果任务允许"再试一次"——比如生成营销文案、草拟邮件回复——代理的容错空间很大。用户看到三版草稿选其一，没人受伤。

如果任务是扣款、库存扣减、权限变更，一次错误就是事故。这时候你需要代码的确定性：同一输入，永远同一输出，可审计、可回滚。

作者的原话：「Think about failure modes」。不是问"会不会错"，是问"错了能不能承受"。

这个判断直接决定后续所有选择。

第二问：输入是什么形态？

结构化数据 vs 非结构化混乱，工具偏好截然相反。

代码喜欢干净：JSON、数据库行、API响应。正则、解析器、类型系统，都是为规整输入设计的。给代码一堆格式标准的订单数据，它能飞。

但真实世界满是噪音：客户邮件里的口语化需求、扫描件里的手写备注、聊天记录里的碎片信息。这时候代理的阅读理解能力碾压传统解析。

作者举了具体场景：「emails, documents, chat logs, support tickets」。代理在这些地方"often succeed where regex and parsers fail"。

不是代理更聪明，是它能容忍模糊。代码的严格性在这里变成负担。

有个实用信号：如果你发现自己要写第17个正则特例来处理"但是"、"不过"、"另外"这类转折词，停。这是代理的舒适区。

第三问：需求会变多快？

维护负担的源头，往往是一开始没想清楚。

代码的刚性是双刃剑。需求稳定时，优化后的代码跑得又快又省。需求每周一变时，重构成本让人崩溃。

代理的弹性在这里发光。改需求？改提示词。作者的原话：「updating a prompt is faster than refactoring code」。几行自然语言 vs 重写模块、补测试、担心回归。

创业公司、创新项目、探索性业务，需求稳定性天然差。这时候代理的快速迭代是生存优势。

但注意：这种"快"是有代价的。提示词改多了，行为漂移难以追踪。作者没明说，但 checklist 里留了后手——「Do I have debugging/observability needs?」复杂需求偏向代码，部分原因就在这里。

真实决策：不是二选一，是拼接

最有力量的应用，往往战略性地混用两种方法。

作者给了一个模式：「Agent → Validation/Transformation → Code Service」。代理负责理解混乱输入，中间层清洗校验，代码服务处理核心逻辑。

这个结构解耦了不确定性与确定性。代理的创造性用在它擅长的模糊地带，代码的可靠性守住不能出错的底线。

举个例子：客服工单系统。代理读邮件，提取"客户要退款"这个意图和关键信息；校验层确认金额、订单号格式合法；代码执行实际的退款流程、库存回滚、通知触发。

哪一环出错，影响范围可控。代理幻觉最多导致提取错误，进不了校验层；代码层的操作有完整审计。

代理的甜蜜点：四类场景

作者明确列出了代理"unbeatable value"的场景：

第一，原型验证。「build a working prototype in hours instead of days」。不是偷懒，是用最小成本测试概念是否成立。验证通过再投入工程化，避免在错误方向上精雕细琢。

第二， messy human-generated data。前面提过，不重复。

第三，需求高频变动。创业公司和创新项目的常态。

第四，非开发者自助。「enable non-developers to automate simple tasks」。作者给的例子很具体：「When I get an email from X with attachment Y, save it to folder Z and notify team」。不需要写代码，自然语言描述规则，代理执行。

第四点常被低估。它扩展了"谁可以自动化"的边界，而不只是"怎么自动化"。

代码的不可替代：四类硬边界

代理 hype 再热，有些场景代码仍是唯一选择。

性能关键。「microseconds matter or you need to handle thousands of requests per second」。编译优化、内存布局、并发模型，这些代理抽象层给不了。

确定性要求。「Financial calculations, game physics, cryptographic operations」。作者强调「bit-perfect reproducibility」。不是"差不多"，是每一位都一致。代理的概率本性与此冲突。

高频重复。「Tasks that run millions of times with nearly identical inputs」。代码的优化空间在这里累积成巨大收益。代理的每次调用都是推理成本，规模上去后账单惊人。

调试需求。「Debugging, profiling, and optimizing require visibility and control」。代理的黑箱特性让深度优化困难。你需要知道每一步发生了什么，而不仅是输入输出对。

开工前的八项检查

作者给了一个可直接用的 checklist，八个问题：

☑️ 主要是理解还是创造？（理解→偏向代理）

☑️ 出错的代价多大？（低代价→更适配代理）

☑️ 需求稳定吗？（不稳定→更适配代理）

☑️ 需要确定性输出吗？（需要→偏向代码）

☑️ 性能关键吗？（关键→偏向代码）

☑️ 数据结构化还是非结构化？（非结构化→偏向代理）

☑️ 需求会频繁变更吗？（会→更适配代理）

☑️ 调试和可观测性需求复杂吗？（复杂→偏向代码）

这八个问题没有标准答案，但问完，偏哪边应该清楚了。

注意作者的措辞：「Understanding → agent bias」，「Yes → code bias」。用的是"偏向"，不是"必须"。实际决策是连续谱，不是开关。

一个被忽略的细节：团队能力

原文没提，但 checklist 的设计隐含了这一点。调试/可观测性需求复杂时偏向代码，前提是团队真有代码调试的能力。如果团队全是提示工程专家，硬上复杂代码可能是另一种灾难。

反过来，如果团队没有代理运维经验——监控幻觉率、管理上下文窗口、设计降级策略——贸然把代理推到核心路径，同样危险。

工具选择背后是组织能力的匹配。这是框架没写但决策者该想的第九个问题。

为什么现在必须建立这个框架

代理工具的生产就绪（production-ready）改变了游戏规则。以前"要不要试试AI"是实验心态，现在是架构决策，影响系统拓扑、成本结构、团队分工。

没有判断框架的团队，容易两极分化：要么恐惧回避，错过代理能创造的效率；要么盲目追捧，把代理塞进所有缝隙，制造技术债。

作者的三个问题、八项检查，本质是强制结构化思考。不是给你答案，是逼你面对真实约束：失败成本、输入形态、变化速度。

这些约束不会因为你喜欢或讨厌AI而改变。

实用建议：从 checklist 开始

下次立项，别先讨论"用哪个模型"。把八个问题打印出来，团队一起填。分歧最大的那项，就是风险点。

如果失败成本和需求稳定性打架——比如高频变动的金融计算——优先考虑失败成本。确定性是硬约束，变化速度可以用流程缓解（更频繁的提示词评审、更严格的输出校验）。

如果输入结构和性能要求冲突——比如要实时处理非结构化日志——考虑分层：轻量代理做初步分类，代码处理聚合计算，必要时再加一层代理做异常解读。

没有银弹，只有显式权衡。

作者最后没给总结金句，但 checklist 本身就是行动指南。打印它，用三次，你会形成自己的直觉。这比任何"最佳实践"都可靠。