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