今天怎样委派
限定条件下整包委派
SWT-Bench直接把复现测试前后运行分开，并区分复现脚本与全套测试。把验收器当交付对象可以合并测试生成/环境诊断/回归，而不强迫先写大量映射实现的测试。
W-C12 · 条件能力评估
验收器与测试资产交付：能拒绝错误，也能接受合法替代
交付可运行的行为测试/复现与风险覆盖说明，使它捕获已知错误而不把正确实现误判为失败。
现在的用法
可委派Agent从行为到测试/复现再校准；先证明检查能区分正反控制，再拿它接收功能或发布。
SWT-Bench公开给出仓库级复现测试、gold patches和执行日志，能检查错误前失败与修复后通过。
开始前满足这些条件
- 固定基线、一个正确/合法替代、一个有实际错误的版本及环境/数据；避免仅复制被测实现逻辑。
- 提供稳定启动、测试隔离、依赖/时钟/并发控制、日志与允许的运行成本。
本站记录：本次只核查公开材料和任务契约；未在本站运行该任务、工具或模型。
用你已有的上下文继续
交给我的 Agent
带走当前公开资料，让你的 Agent 结合已有背景继续分析。也可以读完就结束。
查看可复制的内容
我正在了解：验收器与测试资产交付：能拒绝错误，也能接受合法替代 交付可运行的行为测试/复现与风险覆盖说明，使它捕获已知错误而不把正确实现误判为失败。 请读取这项工作的输入、条件和验收，结合当前授权与环境完成我提出的交付。先说明可执行范围和阻塞；保留失败、重试与独立接收记录，不把示例当作本次已运行结果。 公开资料： 当前任务与验收资料：https://edgeofwork.com/work-units/W-C12.md?version=2026-10-21.workunits.2 区分职业资料、研究结果、工具声明和编辑推断；读取资料给出的日期、版本与范围。需要时补充原始来源。使用自己的自然报告或对话继续，无需把个人材料和分析回填网站。
当前判断与直接依据
工具今天能否获得
开源测试资产可检查；没有运行新的模型生成测试。
SWT-Bench ↗ · 2026-10-20公开仓库HEAD 330a649a764fab2fadaea632776eeae87272f74b；实际运行另固定依赖/镜像/模型
开源；容器、仓库与模型调用预算另备
哪些具体证据支持判断
可检查产物
SWT-Bench公开给出仓库级复现测试、gold patches和执行日志，能检查错误前失败与修复后通过。
SWT-Bench 官方实现 ↗
支持：提供直接测试任务资产。
定位：Overview；Gold validation；evaluation logs
范围限制：复现脚本模式不包含全套回归；语料不覆盖全部产品风险。
判断限制：复现脚本模式不包含全套回归；语料不覆盖全部产品风险。
有条件的编辑推断
可让AI交付并校准验收器，先用真实正反控制和合理替代测试它，再用它判断其他Agent产物。
SWT-Bench 官方实现 ↗
支持：支持按实际执行结果检查测试。
定位：Unit Test mode vs Reproduction Script mode
范围限制：不能由已知控制表现推出未知缺陷检出率。
判断限制：不能由已知控制表现推出未知缺陷检出率。
输入变化会怎样改变结论
端到端与真实环境
浏览器、设备、DB或硬件行为重要。
采用范围：脚本可委派，但必须与目标环境实际状态连接。
验收变化：采用W-C04/C05/C07/C10环境不变量，Mock边界显式记录。
非功能与对抗输入
性能、负载、权限或并发条件主导风险。
采用范围：冻结负载/故障/对抗控制后分阶段接收。
验收变化：预算与阈值不能事后修改；检查负控制和副作用。
回归与发布
测试来自修复或持续交付。
采用范围：交付发布差距与证据，不能只给总通过数。
验收变化：历史错误重放、flaky隔离、关键风险未覆盖与版本差异。
前沿已经展示到哪里
公开有仓库级测试生成与gold控制；它的覆盖变化不等于业务查全率，真实浏览器/移动/硬件验收还需环境。
未知下一步怎样验证
用一组真实缺陷、正确修复和不同正确实现盲测，冻结需求后让Agent生成检查，再由独立运行核对拒绝/接收、稳定性与诊断质量。
未来什么信号会扩大或缩小边界
- 独立新缺陷被捕获，正确和合理替代被接收，flaky成本可控，可考虑扩大相近输入范围。
- 测试只迎合某种写法、环境偶然通过或关键错误漏检，应收窄或暂停相应采用。
交付什么
请求：给用户/系统应满足的结果、重要不变量、历史缺陷与受影响路径；明确无法自动判定的体验或专业条件。
单元、集成、端到端和非功能按风险选取；不把测试条数、覆盖率或CI绿当作系统质量。复杂环境检查结合对应任务包。
- 行为与风险
- 给用户/系统应满足的结果、重要不变量、历史缺陷与受影响路径；明确无法自动判定的体验或专业条件。
- 独立控制
- 固定基线、一个正确/合法替代、一个有实际错误的版本及环境/数据；避免仅复制被测实现逻辑。
- 可运行反馈
- 提供稳定启动、测试隔离、依赖/时钟/并发控制、日志与允许的运行成本。
接收产物
- 可重放测试/复现脚本、测试数据与环境说明
- 正确/错误/合法替代控制结果和失败诊断
- 风险到检查的覆盖映射、遗漏、flaky原因及发布差距
怎样验收
1. 确实区分错误
同一检查在已知错误版本失败、修复/合法替代通过，失败原因对应需求。
拒收例子：为某种代码写法锁死断言，合法替代也失败。
2. 不靠环境偶然通过
重复重放、清空状态、变顺序，明确超时/依赖与并发；记录不稳定失败。
拒收例子：测试共享脏数据库或sleep碰巧通过。
3. 覆盖与发布结论相称
按关键风险、权限/数据/环境路径给剩余风险，使用独立缺陷控制挑战测试。
拒收例子：覆盖率100%就认定没有遗漏或安全问题。
一个具体例子
输入：付款重复回调造成双记账，正确替代可用事务或唯一键。
预期交付：两种正确实现通过，双记账和缺权限的实现失败；附隔离数据和事件回放。
容易出错：只检查某函数被调用一次，错过真实账本副作用。
工作步骤怎样重组
原来的组织方式
QA按用例写脚本，开发修环境，业务最后点验。
现在的组织方式
Agent可自主构造输入、启动环境、生成检查并用控制修订；程序反复运行，人按风险判断何种证据足够。
保留的判断、新增的工作与失败接管
仍需做好
- 确定质量风险和发布容忍；验收器的语义与不可自动判断范围需独立核对。
新增职责
- 按关键风险、权限/数据/环境路径给剩余风险，使用独立缺陷控制挑战测试。
人的责任：确定质量风险和发布容忍；验收器的语义与不可自动判断范围需独立核对。
失败处理：发现验收器错误先修正并重跑双方控制；环境失败单列，不把失败转跳过后宣布通过。
尚待补足
- 尚缺本产品独立真实缺陷、正确与合法替代控制，以及flaky/确认时间记录。
这对个人和团队意味着什么
职业与岗位
软件质量、测试工程
可重放测试/复现脚本、测试数据与环境说明
用一组真实缺陷、正确修复和不同正确实现盲测，冻结需求后让Agent生成检查，再由独立运行核对拒绝/接收、稳定性与诊断质量。
查看相关职业与方向 →团队与分工
SWT-Bench直接把复现测试前后运行分开，并区分复现脚本与全套测试。把验收器当交付对象可以合并测试生成/环境诊断/回归，而不强迫先写大量映射实现的测试。
Agent可自主构造输入、启动环境、生成检查并用控制修订；程序反复运行，人按风险判断何种证据足够。
在真实授权任务核对产物、失败、返工与接收时间，再据此配置工具、环境和人员。
查看工作分工与组织案例 →依据具体支持了什么
SWT-Bench 官方实现
提供直接测试任务资产。
未覆盖：复现脚本模式不包含全套回归；语料不覆盖全部产品风险。
原文定位、日期与职业来源关系
- SWT-Bench 官方实现 ↗
NeurIPS2024；仓库持续更新 · 定位：README：Overview；Unit Test vs Reproduction Script；gold validation
缺陷前失败、修复后通过的测试生成评测；复现脚本模式不跑全套测试；不能把覆盖率当检出率或业务正确性。
核查 2026-10-20 · 下次复查 2027-01-20
未来3–5年：2029–2031
2029–2031：从单份修改到持续交付的软件Agent
整包应用案例、真实修复接收和运行流程优化，是更长软件任务可委派的正面信号。以下是本站据此提出的条件情景，不是这些研究给出的日期预测。
当前建议回答今天怎样交付；未来3–5年指2029–2031。编程的完整交付与数学的开放问题成果，支持认真准备更广泛自主工作的强情景。本站把AGI视作跨领域、能适应新任务且可靠达成复杂目标的讨论对象；这些进展是方向证据，尚不能确认某个AGI定义已满足或必在某年发生。三种情景均给出可观察信号、职责变化与现在行动，不把今天的局限或人的现有分工写成永久边界。
基准情景：完整修改成为常用交付
在上下文与测试较成熟的系统中，Agent承接功能、修复和回归的一体交付，维护者从逐步编写转向目标、异常与接收；审查的一部分继续自动化。
现在的行动：现在沉淀真实行为契约、失败样本和环境；按净交付周期衡量收益，不以代码量替代。
成立信号与职责变化
- 未见仓库和变更类型仍保持可验收交付
- 返工、接收和线上恢复成本随使用改善
- 环境/上下文变化能被检测并更新
工程岗位更常覆盖需求、系统取舍与运行结果；初级培养需从只写代码升级为理解与验证完整修改。
加速情景：软件成为按目标持续运行的系统
若长链恢复、跨仓库迁移和自动验证持续进步，Agent可在权限与预算内规划、实现、迁移和维护较大系统；人可用更少逐步干预探索新产品，团队边界可能重组。
现在的行动：把工具和职责做成可替换接口；试验更大交付，但按实际触发信号扩围，并安排成员转向新的业务机会。
成立信号与职责变化
- 跨多系统、数周目标能在真实变化后继续交付
- 独立评估能发现自生成测试漏掉的重要错误
- 完整人工介入和故障成本持续下降，且系统可迁移到新业务
稀缺工作可能转向选目标、产品机会、资源和影响取舍；不能预设人工代码审查永远是主要瓶颈。
受限情景：编码快，集成与组织仍慢
模型产物更强，但遗留系统、隐性需求、权限和恢复成本使自主交付扩展较慢；固定程序与AI协作长期并存。
现在的行动：优先修复反复出现的集成障碍；保持可回退的部署和岗位安排，避免依据榜单单独裁定编制。
成立信号与职责变化
- 未知依赖和需求变动仍引发大幅返工
- 审查和事故处理抵消生成提速
- 同一Agent换系统后需要重新铺上下文
系统知识、集成和沟通能力仍有高价值；工具投入首先服务复现、测试和资料。
持续观察什么，以及情景的研究依据
- 实际未见仓库的完整交付与维护记录
- 跨月净人工时间、回滚与事故情况
- 任务/环境/模型版本变化后的迁移表现
- 把长时间应用开发交付给Agent ↗
2026-03-24 · 定位：规划/生成/评价分工、实际应用操作及评价者限制
展示围绕可用应用的实现、操作评价与修正循环，支持以用户行为验收功能。；作者工程案例；未复现演示应用，不能推出任意项目可靠率或多Agent必优。
核查 2026-10-19 · 下次复查 2026-10-26 · 已到期待复查
- AI参与的修复PR：哪些被项目接收，哪些没有 ↗
2026-01-29 · 定位：§2样本、表1、§3.2失败原因
五类Agent参与的8106个修复PR中5267已合并、2113关闭未合并、726仍开放；提供修复交付与项目接收的观察。；非随机样本，Agent配置与项目不同；合并不等同全部正确或净省时，不用于本站成功率。
核查 2026-10-19 · 下次复查 2026-10-26 · 已到期待复查
- Harness²：固定执行模型，改进运行流程 ↗
2026-10-09 · 定位：§2.2、§3.1表1、附录B/D
WorkBuddy-Bench Code上的平均检查得分变化及工具/上下文/检查流程的优化方法。；检查项均分不是项目通过率；经验流内相关，候选与编辑成本另计；未验证本站任务。
核查 2026-10-19 · 下次复查 2026-10-26 · 已到期待复查
- Anthropic内部的工作与职责变化 ↗
2026-10-16 · 定位：Bottlenecks and process；采用非随机限制
单公司现场观察到Agent组织、上下文维护和注意力分配成为新的工作。；公司业务及采用选择特殊；产出代理量不等于完整业务价值，不外推行业岗位数量。
核查 2026-10-19 · 下次复查 2026-10-26 · 已到期待复查
- 任务时间跨度：软件任务趋势及其适用范围 ↗
未标注（最后更新2026-09-08） · 定位：页首维护状态；Methodological Details；FAQ
在给定软件类任务分布上，按人类专家任务时长描述模型可完成难度，适合观察长链能力趋势。；此页已停止主动更新；时间跨度不是Agent自主运行时长，不直接对应行业自动化或AGI日期。
核查 2026-10-19 · 下次复查 2026-10-26 · 已到期待复查
岗位深度研究 · 独立资料版本 2026-10-24.studies.5
把这项工作放回完整工作链
AI 产品经理：从反馈到产品交付 →
从客户证据、产品判断到需求、验收、观察和AI治理，理解AI如何改变工作连接与人工活动。
部分工作或方法关联；专题任务不是正式职业来源任务，也不把一个单元的全部证据传播为岗位成绩。
AI 软件工程师：前端与后端完整交付 →
从需求、前后端实现到质量、发布和运行，比较AI、成熟库与托管服务怎样改变可交付范围与责任。
部分工作或方法关联；专题任务不是正式职业来源任务，也不把一个单元的全部证据传播为岗位成绩。