AI 未夺走饭碗，却彻底重塑了写代码的方式

把接口文档直接塞进 AI 输入框，它自动生成的测试用例不仅能覆盖常规场景，还能根据需求细节自动构建边界条件——比如对着「幂等性键必须是 transaction_id 而不是 order_id」这条隐含约束，AI 会在用例中故意用 order_id 来测试幂等性是否被正确处理，让你不再手动抠出「重复支付风险」的关键场景。

AI 生成的逻辑确实有很多隐藏的坑点，比如前几天拆解支付回调时，AI 给出的幂等性键写成了 order_id 而非 transaction_id，跑通测试后才发现差点酿成了线上事故。这说明即使代码看起来结构正确，也需要在明确需求规范的基础上，用 接口契约（如 TypeScript 定义 + Zod schema）和故意刁钻的测试用例（并发、重试、脏数据）来验证其可靠性。比如，我会先定义一个 PaymentCallbackTask 的接口模板，明确输入输出要求和约束，然后让 AI 根据这个契约生成代码，再通过 transaction_id 这样的关键字进行幂等性验证。这样既避免了“眼看着对、跑起来错”的问题，也能确保生成的代码在边界条件下的稳定性。

写 prompt 简直是玄学，为了对齐一个边界条件我得试 5 遍，心态崩了。前几天帮同事看 PR 时猛然发觉：自己竟有两个月没完整手写过一段业务逻辑。不是摸鱼，是 Cursor 配合 Claude Sonnet 4 把「落地细节」全包圆了。现在的日常成了——对着需求文档拆任务、给 AI 立接口契约、跑通生成代码的测试、再把边界情况塞回 prompt 里。AI 真没抢走我的饭碗，但把「写代码」这活儿彻底改了样。

这转变挺耐人寻味。过去我是「造轮子」的，如今更像「验轮子」的。代码量掉了七成，可读代码、改 prompt、追幻觉的工夫却翻了三倍。上周重构支付回调，AI 一口气吐出三百行，乍看顺眼，跑集成测试才发现它把幂等性键写成了 order_id 而非 transaction_id，差点酿成线上事故。这种「眼看着对、跑起来错」的坑，眼下还得靠人兜底。

我现在的作业流长这样：

• 拆解需求：把模糊需求拆成确定性的接口签名加验收标准，存成 Markdown 丢给 AI
• 契约在前：先定 TypeScript 接口、Zod schema、数据库迁移脚本，再放 AI 填实现
• 对抗测试：写一组故意刁钻的用例（并发、重试、脏数据），看 AI 能扛几轮
• Prompt 入库：把每轮修改的 prompt 当代码一样进 Git，方便回溯哪版最稳

// 现在给 AI 的任务模板大概长这样
interface PaymentCallbackTask {
  input: {
    rawPayload: unknown;
    idempotencyKey: string; // 必须是 transaction_id
  };
  output: {
    status: 'success' | 'duplicate' | 'invalid';
    orderId: string;
  };
  constraints: [
    "幂等性键仅使用 transaction_id",
    "重复回调返回 duplicate 不抛错",
    "签名校验失败返回 invalid",
    "所有外部调用需带超时和重试"
  ];
}

最直观的体感是：「会不会写代码」不再是门槛，「能不能把模糊需求变成可验证的规格」才是硬本事。过去招人看 LeetCode，现在我更想看候选人给一段烂代码写多少条能跑通的测试，或者面对 AI 幻觉时怎么定位、怎么改 prompt 纠偏。

有同行问会不会焦虑。实话讲，刚开始真有点——毕竟敲键盘的痛快劲儿没了。但后来发现，实现成本趋近零时，系统设计、架构取舍、技术债治理、跨