AI 已经能把整块开发委托接过去#
先做一个基于近期趋势的推演：2026 年 6 月 10 日，Anthropic 发布了 Claude Fable 5——第一个面向公众的 Mythos 级模型。看完介绍，我的第一反应是：某种程度上，软件开发是不是已经结束了？
这不是夸张。这一代模型已经可以在智能体环境里连续工作数天：自己规划方案、自己写测试验证、对照目标检查产出、不断修正，直到交付一个完整的结果。在编程基准上，它解决问题的比例比上一代旗舰又高出了十个百分点。大型代码迁移、复杂系统实现这类过去需要团队数周的工作，现在可以整块委托出去。
「写代码」这件事的价值，正在以肉眼可见的速度下降。
真正的问题是人该站在哪里#
但坐不住之后，真正的问题浮出来了，而且不止一个。
第一个困惑：如果写代码不再稀缺，人的位置在哪里？ 我们和 AI 之间，到底该是一种什么样的协作关系？
第二个困惑：就算想清楚了定位，我该怎么调整自己，去适应模型的工作方式？ 工具变了，但我的工作习惯还是旧的——一句一句地问，一行一行地看。
第三个困惑最具体，也最折磨人：信息涌入。 当 AI 一次性交付几千行代码、几十页文档时，我发现自己根本消化不过来。大量信息瞬间灌进来，我反而做不出任何判断和决策——接受还是退回？好还是不好？我说不上来。我盯着屏幕发懵，比写不出代码更不安。
困惑到这一步，我做了一件有点好笑的事——我把这些问题原样抛给了 Fable 5，问它：以后我该怎么办？它给了一堆建议，有些有用，有些像正确的废话。但这个过程本身，反而让我摸到了一些答案。
手写代码在贬值，判断在升值#
软件开发没有结束，结束的是其中一个环节#
先回答第一个困惑。「软件开发结束了」这个判断，更准确的版本是：手写代码这个环节的价值在快速下降，但开发的其他环节反而更重要了。
有几件事，再强的模型也替你做不了：
决定做什么。 模型擅长把清晰的目标变成可运行的系统，但「用户真正的痛点是什么」「这个功能值不值得做」，这些判断需要对业务和组织的理解。需求定义的质量，现在直接决定产出的质量——输入质量决定输出质量，只是现在输出得更快了。
验收和担责。 AI 可以交付一个「看起来完成」的项目，但它不为结果负责。上线出问题谁负责？架构决策五年后会不会变成债务？这些拍板必须由人来做。
设定品味和边界。 同一个需求，AI 能给出一百种实现。哪种符合团队的长期方向，哪种是过度设计，这种判断来自经验。
所以人的角色正在发生一次根本性的迁移：从「产出者」，变成「定义者、审查者和决策者」。 这不是降级，而是升维——它要求的能力其实更高。
这不是第一次，也不会是最后一次#
汇编到高级语言，高级语言到框架，框架到云服务——每一次「写代码变容易」，都没有让工程师消失，而是让能做的东西的规模变大了。这一次的变化幅度确实更大，初级岗位的形态、团队的结构都可能重组，但方向是一致的：稀缺的能力上移了。
回顾这些历史案例，每次抽象升级后，稀缺能力都会集中到更上游的几个方向：定义目标、设定标准、做出判断。
想明白这一点，第二个困惑就有了框架：适应模型的工作方式，本质上就是刻意练习那些「上移后变得稀缺」的能力。 我把它们归纳为五项。
和模型协作，真正需要练的不是提示词#
1. 写上下文，而不是写指令。 模型的产出上限由它知道的信息决定。把你脑子里的隐性知识显性化——项目背景、约束条件、历史决策的原因、什么算「好」。这同时也在训练你自己：很多人发现自己写不清需求，是因为本来就没想清。
2. 把任务切成可验证的单元。 「优化一下这个模块」是坏任务，「把响应时间降到 200ms 以下，保持现有测试通过」是好任务。有了明确的验收标准，模型可以自己验证、自己迭代，你只需要看结果。
3. 适应异步、并行的节奏。 新的工作方式不是一问一答，而是同时委托几个任务出去，自己去做别的，回来批量审查。你的瓶颈从「产出速度」变成了「审查速度和决策速度」。
4. 快速阅读与评估。 这是针对「信息涌入」困惑的解法，也是我自己最需要补的课。关键的认知转变是：信息淹没你，不是因为你读得不够快，而是因为你没有带着问题去读。 审查的本质是回答问题，不是消化全文。
5. 先想后问。 AI 的第一个答案，往往是「平均意义上合理」的答案，不一定是你的场景下的最优解。先自己形成预判，再去和 AI 讨论——当你的预判和它的答案出现分歧时，那个分歧点恰恰是价值最高的地方：要么你发现了它的盲区，要么它发现了你的。
知道不等于做到，每一项都要练到有体感#
道理讲完，落地靠练。以下是每项能力的具体练习方法和自查标准。
把脑子里的东西写出来#
为每个长期项目维护一份上下文文档，在每次协作前更新。委托任务前自检：一个完全不了解项目的新同事拿到这段描述，能不能不问问题就开工？每周复盘一次 AI 理解偏差的案例，把「我没说清」的部分补进文档。
达标信号：AI 的第一版产出就大体符合预期，返工率明显下降。
把模糊需求变成可验证的目标#
委托前先写验收标准：什么算完成，怎么验证。用「15 分钟原则」控制粒度——单次委托的产出物，应该能让你在 15 分钟内审完，审不完就是切太大了。练习把模糊需求翻译成可测量目标。
达标信号：委托前你就能说出「我将如何判断这个任务做好了」。
同时推进多件事，而不是排队等#
每天开始时列出可并行的任务，批量发出，再去做需要深度思考的事，定时回来批量审查。回到一个任务时，先花一分钟重建「我当时委托了什么、验收标准是什么」，再看产出。
达标信号：一天能流畅推进三个以上并行任务，切换时不迷失。
审查不是消化全文，是回答问题#
这是对抗信息涌入的完整流程：
第一步，先定问题再看内容。打开产出之前，写下要验证的三个问题，比如「边界情况处理对不对」「最大的风险点在哪」「有没有偏离我给的约束」，然后带着问题扫读，只在相关处停留。
第二步，让 AI 做结构化自述。不要让它「总结一下」，而是要求：「列出你做的三个关键决策和理由」「哪些地方你不确定」「如果这个方案会失败，最可能败在哪」。这样你审查的是决策点，而不是几千行细节——决策对了，细节可以抽查。
第三步，分层读。第一遍只看结构和接口，限时五分钟，建立地图，不许陷入任何细节；第二遍只深入高风险区域：权限、并发、错误处理、和外部系统的边界；其余抽查。
第四步，控制涌入量。如果产出大到无法判断，那是上游的任务切分出了问题。初期宁可切小，随着判断力增长再放大委托粒度。
达标信号：面对一份新产出，10-15 分钟内能给出明确判断——接受、退回，或者需要深查哪里。
先有自己的答案，再去看 AI 的#
给自己立一条纪律：任何问题先想 30 秒，形成初步判断，再去问 AI。把 AI 当对手盘，主动追问「为什么不用 X 方案」「这个方案在什么情况下会是错的」。每次预判和答案不一致时，搞清楚盲区在谁那边——两种结果都是收获。
达标信号：你越来越能预判 AI 答案的大致方向，并能指出它的具体不足。
技巧会过时，判断力不会#
最后想说的一点，可能也是最重要的一点。
AI 的迭代速度决定了，具体的技巧——提示词模板、某个工具的用法——会不断过时。追着技巧跑是追不完的，也没有必要。真正值得长期投资的，是这五项能力背后的本质：表达清楚、定义标准、快速判断、独立思考。 不管模型再怎么变，这些都不会贬值。
最危险的不是不写代码，而是不再理解你交付的东西。
工具在变快，而我们要练的，是变深。