这是掘金最近一篇阅读量过万的程序员长文，作者的判断很直接：评估 AI 编程任务时，「能不能做」是错误的问题，「边界在哪」才是正确的问题。

这是什么

作者给出四个判断维度：规则是否明确、结果是否容易验证、出错后是否容易回滚、出错代价是否可控。四个「是」越多，越适合让 AI 先做；越少，越需要人来把关。

据此他把任务分成三类：可直接委托（写测试、整理日志、生成文档初稿）；AI 分析、人决策（接口重构、性能调优）；只能开发者负责（业务规则、权限与金额、生产环境配置）。文章还附了一段可直接复制使用的提示词（Prompt）模板，用来在每次任务开始前明确分工。

值得注意的是，这套四问法——规则、验证、回滚、代价——并不只属于程序员。任何涉及把工作交给 AI 的场景，都可以用这四问做第一道过滤。

行业怎么看

技术社区反应两极。

支持者认为，这切中了企业 AI 落地的真痛点——不是模型不够强，而是没人敢为结果负责。硅谷工程团队最近也提出类似判断：「AI 责任边界」是 2026 年企业部署的核心议题，比模型选型更难解决。

反对意见更值得听。一位资深架构师在评论中指出，这套框架本质上是「瀑布式思维」（即先把需求全部定义清楚再动手的传统开发模式）的延续，把任务拆成清晰输入输出再让 AI 填空。但现实中大量工作是「边做边定义需求」，AI 的优势恰恰在模糊地带。强行套用四问，反而会限制 AI 在需求探索阶段的价值。

我们的判断：框架本身有用，但前提是需求已经清晰。如果你的需求还在被 AI 的输出反向塑造（比如用 AI 探索产品形态），这套框架就不够用——需要另设一套「AI 探索期」的协作规则。

对普通人的影响

对企业 IT：别再问「团队能不能用 AI 写代码」，先问「哪些环节放手、哪些必须留人」。四问框架可以直接搬进采购评估表，比单纯比模型参数更实际。

对个人职场：即使不写代码，逻辑也通用。规则清楚的事（整理纪要、写报告初稿）可委托；涉及金额、合同、人事决定的事，必须人来拍板，AI 只能列选项。

对消费市场：直接影响有限。但若 AI 编程在企业内普及，软件定制成本会分化——小批量快速验证的工具会变便宜，大型核心系统的开发门槛反而变高，因为后者需要的「判断」更稀缺、更贵。