近期，我为 IBM Bob 内部开发了一款名为“任务查看器”的社区辅助插件。尽管该工具非关键生产组件，但对我而言，这是一次关于“代码委托边界”的真实实验：在将实现工作交给编程智能体时，究竟能放手多少？这取决于执行者还需掌握哪些知识。熟悉系统的开发者可能仅需检查结果，而初学者则需通过部分实现来构建认知。
即便编码工作全权委托智能体，我仍坚持手动审查功能与设计。当真正需要检索信息时，界面交互是否符合预期？信息呈现是否清晰？这些看似微小的问题，即便在小型应用中，也需投入时间深思。
验证陷阱：屏幕数字不等于正确逻辑
为确保数据显示准确，我为“任务查看器”编写了大量 UI 测试，以便在应用变更时重复校验。然而，计算逻辑的正确性是另一回事。屏幕上的数字无法自证其真，我必须针对底层数据运行 SQL 查询，回溯至原始记录以验证数学逻辑。
这一过程涉及深层理解：需明确结果含义、参与计算的记录范围，并建立期望值进行比对。幸运的是，团队协助我厘清了若干复杂的数据关系，否则仅凭个人难以推导。这种信心的建立耗时费力，需检查行为、界定数据含义并解决未知问题，这些都纳入我对“可委托编码量”的评估体系。
这也解释了为何“智能体完成 80% 工作”的说法日益难以解读。虽然界面初具雏形，看似剩余工作量不大，但在找到验证方法前，基于错误记录的计算可能看起来完全合理。纠正偏差前，必须先发现认知与应用行为间的分歧点。智能体虽可协助调查，但其生成的代码量无法预示排查所需的时间成本。
数据洞察：审计成本抵消部分效率红利
DORA 对谷歌 1,110 名软件工程师的分析显示，代码生成节省的时间部分被审计和验证消耗，尽管整体生产力仍有提升。若比较效率，必须计入达到“可用状态”所需的总时间。若忽略人类版本的检查步骤，或在智能体宣告完成时即刻停止计时，都会导致对代理式开发成本的误判——使其显得异常昂贵或廉价。
前期投入的验证努力可使后续变更更易接受。一旦 UI 测试覆盖核心行为，或针对少量记录验证过的计算转化为回归测试，这些思考成果即可复用。但前提是期望值必须正确：若应用与测试共享同一错误理解，频繁运行测试只会不断确认错误。
对于“任务查看器”，我的信心部分源于同事对数据关系的解读。仅关注检查耗时，会忽略对话中传递的知识价值；正如仅看生成代码会忽略检查环节一样。接受变更所需的信心，往往依赖于团队成员对系统不同维度的共同理解。
技能形成：AI 是捷径还是障碍？
当开发者尚在了解系统时，实现过程本身就是构建认知的途径。追踪从数据库到屏幕的值流，能促使他们追问记录选择逻辑及应用处理方式。若智能体包办全程，开发者虽获得可用功能，却错失了解答这些关键问题的机会。同一任务，对资深工程师是合理委托，对初学者则是重要的学习契机。
Shen 和 Tamkin 关于 AI 影响技能形成的研究指出，在一项涉及 52 名开发人员学习陌生 Python 库的随机实验中，获 AI 协助者在即时理解能力评估中得分较低。尽管积极参与 AI 互动者展现出更好的学习成果，但短期练习无法完全映射长期职业发展。这提醒我们：评估任务价值时，不应仅看功能是否交付，更要看开发者从中获得了什么。
决策框架：基于验证难度与学习目标分配自主权
我们可在启动智能体前划定自主权边界：哪些部分由其自行处理，哪些需开发人员亲力亲为。限制自主权的原因之一，是缺乏令人信服的结果验证方法；另一原因则是为了培养特定技能。即便智能体能产出可接受代码，故意保留部分实现给开发人员，往往是更优选择。
决策关键在于两点：团队需付出多少努力确立结果的正确性？开发人员需通过此任务学习什么？若某功能对资深同事易于验证，而实施者仍需理解原理以承担未来维护责任，则应调整委托比例。我们无需将每次常规变更都变为练习，但应有选择地保留那些能促进未来理解的任务。
表 1 展示了针对特定任务或开发人员的适用策略。“易于验证”意味着存在可信的评估方法。若不确定测试断言内容，通过的测试套件并无意义。当检查困难或方法未知时，首要步骤是在领域专家帮助下缩小不确定性，而非将整项任务甩给缺乏经验的开发者。
以新员工为 Java 应用添加“仅显示开放问题”过滤器为例。智能体可生成请求参数、查询条件及界面更改。对熟悉系统者，这是合理委托；但对学习者，需厘清“开放”状态定义、记录选择位置及团队测试期望。与同事探讨这些问题，是融入团队协作的关键。
在此场景中，开发人员应在请求智能体实现前，先追踪现有请求并编写首个测试。假设列表分页显示 20 个问题，测试数据包含 20 个关闭问题和 5 个开放问题。选择过滤器后应仅显示那 5 个开放问题。若应用在浏览器端先加载 20 条再过滤，屏幕将为空。通过与同事探讨这种差异，开发人员得以理解过滤与分页的发生位置。在调查预期问题缺失原因时，智能体可协助处理陌生的框架代码。
一旦开发人员能解释行为并拥有捕捉错误的测试，智能体便可接管更多周边实现。后续按负责人过滤的请求，则成为运用所学知识的契机。他们在审查期间的解释，为团队决定下一次变更的委托比例提供依据。首次任务也让新员工积累了需求提问及协作讨论的经验。
资深工程师在不熟悉领域同样应限制智能体自主权。尽管我擅长编写查询，但仍需依赖“任务查看器”的数据背景支持。当任务触及未理解的系统部分时，重新评估移交内容是合理的。团队可通过改进测试和分享知识降低验证门槛，随后也可选择保留学习机会，因为另一成员未来可能需要这种理解。
若要求开发人员通过任务学习，需给予其跟随应用行为及与人讨论的时间。若仅以功能交付速度评判结果，将阻碍其保留学习步骤，并将检查负担转嫁给资深同事，剥夺其他人发展共享知识的机会。
在任务开始前，开发人员与支持同事应就智能体分工、人为介入原因及后续调整理由达成一致。以状态过滤器为例，这意味着允许开发人员在智能体介入前，有时间追踪请求并编写测试。随着理解深入，再动态调整分工。
对于“任务查看器”，因具备结果检查方法及同事支持，我可委托大部分编码工作。随着智能体承担更多任务，我们应持续创造此类条件：更好的检查机制可降低验收工作量，而投入时间学习则能赋予开发者判断能力。有时，即便智能体能完成首个测试和调查，也应故意留给人。当期望某人承担下一次变更责任时，给予其理解本次变更的机会，应纳入委托程度的决策考量。