1024聊AI编程，很容易把话题带到“谁会被替代”。对正在交付软件的人，更有用的问题是：哪些判断必须有人负责，哪些工作适合交给工具，出了问题怎样找到证据。
把决定范围留给具体的人
Agent可以起草实现方案，但本次是否允许改协议、是否接受兼容性破坏、是否能碰生产数据，需要有明确的负责人。把“请自主完成”写进提示词，无法消除这些决定的后果。
我会给任务保留三个短字段：目标行为、不可改变的约束、交还条件。例如“给超时错误增加可识别分类；不改变成功返回结构；发现调用方依赖字符串判断时先停止”。这比“写得专业一些”更容易执行，也方便审查。
生成能力不等于证明能力
代码生成擅长填补局部实现，却可能同时生成一套与错误实现相互配合的测试。复核时应先从需求列出反例，再看测试是否真的覆盖，而不是被整齐的绿色输出说服。
GitHub对云端coding agent的介绍包含运行测试、提交修改和保留工作记录。这些记录让复核更容易，但审核人仍需要检查环境、断言和权限。一个成功退出的命令，只证明那条命令在那个环境成功退出。
最近Go团队开放了2026年开发者调查，公告明确征集开发体验和工具使用反馈，结果计划在之后发布。这种把问题、样本和结论分开的习惯，也值得用在AI工具评价里：使用感受可以先记，整体收益要等证据积累。
工程师的价值落在什么地方
至少有四类判断值得持续练习：识别需求冲突；设计失败路径；判断证据是否足够；把限制解释给协作者。这些能力需要读代码，也需要理解业务和运行环境。它们不会因为生成速度变快就自动出现。
可以从一个很小的练习开始：下一次接受AI补丁时，写下一个最担心的失败场景、一条支持接受的证据，以及一项尚未验证的边界。如果三句都写不出来，补丁可能还没有准备好进入主干。
本文讨论的是工作方法，没有声称完成某个仓库的生产验收，也没有拿厂商发布推算个人效率。工具不断更新，负责判断的人仍需要能够解释“为什么现在可以合并”。
参考
- GitHub：Copilot在GitHub上的工作方式
- Go官方：2026年开发者调查公告
