让 AI 智能体写代码，也让它选技术栈吗？开发者的四个控制点

让工具补全一段 Python 代码，语言通常已经选好了。把任务改成“写个查询 API 的脚本”，语言、依赖、运行方式就可能一起进入待选范围。

这正是“智能体成为新造王者”这一观点讨论的变化：如果开发者没有预先限定实现细节，智能体提出的方案可能成为默认选择，进而影响哪些语言、框架或服务被采用。代码生成之外，技术方案的建议权也进入了委托范围。

这是对决策权变化的条件性判断，不是对智能体能力、普及程度或开发岗位增减的证明。不同任务也未必采用同一种人机分工。下面用一个假设的 API 脚本任务展开，四个控制点都是编辑提出的实践建议，不是原文已经验证有效的措施。

假设你要从一个只读 API 获取分页记录，导出包含 `id`、`timestamp`、`amount` 的 CSV，供后续分析使用。这个例子不对应任何真实团队，也不代表某款工具的实际表现。

只说“把数据导出来”，会留下不少空白：导出当前页还是全部页面？时间保留原值还是统一格式？遇到缺失字段，是跳过还是报错？这些会影响数据含义，不能全部留给实现阶段自行决定。

可以先给出共同任务说明：

在同一目标下，再比较两种委托方式：

两者的差别不只是提示词长短。第二种委托增加了一个需要人工确认的阶段：先选方案，再实施。如果直接接受生成结果，这个确认步骤就容易被跳过。

开放智能体技术选型，不等于所有方案都适合当前项目。一个能独立运行的脚本，仍可能与团队的部署环境、依赖规则或维护能力冲突。

对假设任务，可以把约束分成两层：

如果智能体建议增加第三方库，不要只接受“更简单”“更现代”这样的理由。要求它解释：标准库在哪个具体环节不够合适？新依赖解决了什么问题？谁负责更新？目标环境是否允许安装？

复核后的决定可能是接受新依赖，也可能是保留原方案。关键是留下理由：为什么这项选择适合当前约束。智能体给出的解释仍需核对，尤其是库的功能、版本兼容性和许可证，不能把生成文本本身当作证据。

“开发者是否仍掌握主动权”，还取决于能否选择模型，以及能否控制模型周围的执行环境。这是讨论开发者角色时容易被忽略的条件。

模型、编程工具和执行权限应分开检查。即使可以切换模型，也不意味着可以修改工具的文件访问范围；反过来，不能切换模型，也可能仍能限制命令执行和合并权限。具体能力要以当前工具的设置及文档为准。

对正在使用 AI 智能体编程的读者，先检查三个问题：

在数据处理方式未核实前，不要把真实密钥或敏感数据用于这个练习。

如果工具允许比较模型，可以让候选模型完成同一组模拟任务，记录是否遵守依赖限制、是否遗漏分页、能否根据测试失败修正代码。比较时保持输入和权限一致，避免把更宽的执行权限误认为更好的判断能力。

一次小测试不能证明某个模型全面更强。它能提供的，是在当前任务中选择模型的可观察依据。

脚本跑完，只说明某次执行没有以明显错误结束。合并前仍要检查结果是否符合任务要求，以及实现有没有越过授权边界。

针对上述假设任务，可以直接使用这份验收清单：

测试本身也要复核。如果代码和测试都由同一个智能体生成，二者可能共享同一项误解。可以人工补充一个没有在实现提示中展开的边界用例，例如第二页返回重复记录，检查脚本是否真的按要求报错。

执行前确认权限，合并前阅读差异。如果工具自动添加了依赖、修改构建配置或扩大文件改动范围，应暂停审查，而不是因为测试通过就继续。

对准备美国 Software Engineer 或 Backend Software Engineer 岗位项目讨论的学习者，这个练习可以留下三份简短记录：原始约束、选型理由和验收结果。讲清楚自己批准了什么、拒绝了什么、用什么证据确认结果，比单纯展示生成的代码更能说明你的技术判断。