局部工作与岗位实例
计算机 · 软件维护与验证：职责与岗位样本
这些材料说明一个局部工作场景，不代表本领域职业目录。具体岗位仅代表所列组织、地区、资历和核查时点。
查看更广泛的职业与方向 →下面是两个编辑职责样例；它们可以同时属于一个岗位，不是本领域仅有的两条职业路线。
职责方向 · 编辑参照
软件维护与修复
喜欢追查现象、读旧代码并交付能回滚的修复；评价对象是被接收的变更。
日常做什么
- 复现用户问题并定位代码与依赖
- 实现补丁、补回归、解释未覆盖行为
- 与支持、审阅者协调并跟进实际接收
AI进展影响哪部分
- 在仓库、复现条件和验收可用时，可委派Agent连续定位、修改、执行检查并修正，交付一包待接收的变更
- 开工前确认问题未被解决；将审阅响应、失败恢复和完整复核时间纳入交付
你需要承担的贡献
- 把模糊反馈变成可检查的变更契约
- 解释为何原行为保持、何时回退，回应审阅问题
展开进入条件、作品证据与来源
进入条件与能力证据
- 能读懂一种项目主语言和依赖
- 会复现错误、Git分支和测试
- 按岗位核对Linux/云基础设施、语言和协作经验
适合准备的作品或记录
- 一份真实或明确标为练习的issue→复现失败→补丁→回归→审阅记录
- 标清本人定位、修改和接收贡献，以及Agent运行与被拒绝的错误建议
覆盖边界与来源
- C03不验证大型迁移、值班或客户沟通的全部能力
- 没有个人材料时不能判断你是否适合
AI参与的修复PR为什么未合并？ ↗ · 核查 2026-10-16原文定位与适用范围
§2.1–2.3，表1，§3.2。AIDEV-POP中8106个修复PR及326个关闭未合并样本
观察研究，项目/代理分配不随机；合并不等于同质量节省人时，未合并不全是技术失败。
原始公开 2026-01-29 · 本站观察 2026-10-16 · active
职责方向 · 编辑参照
工程质量与验证
喜欢设计反例、诊断不稳定测试并帮助团队判断能否接收变更。
日常做什么
- 为需求和历史事故设计检查
- 诊断回归、环境差异和难复现问题
- 给出可执行的接收或补验依据
AI进展影响哪部分
- AI可以阅读变更、设计测试候选、运行检查并按失败继续审查，输出可定位的问题和覆盖范围
- 验证器本身也要检查：正确替代实现能否通过，关键缺陷能否被拒收
你需要承担的贡献
- 找出“能运行却没有解决问题”的变更
- 维护独立反例和可靠的测试环境，说明残余风险
展开进入条件、作品证据与来源
进入条件与能力证据
- 能写可维护的测试并读产品实现
- 能区分测试失效、环境问题和真实缺陷
- 具体岗位可能要求分布式系统、性能与生产经验
适合准备的作品或记录
- 一组能在旧实现失败、修复后通过的独立测试
- 一次包含触发条件、影响、复现与修订结果的审查记录
覆盖边界与来源
- 这是职责方向，不是统一岗位名称
- Pro V2是评测维护参考，不证明此类人才需求上升
SWE-Bench Pro V2版本修订 ↗ · 核查 2026-10-16原文定位与适用范围
Update September 22, 2026。发布方对公开split及隔离评测协议的修订说明
官方声明，本轮未复跑审计；V1和V2任务与协议不同，不能直接连成绩计算进步。
原始公开 2026-09-22 · 本站观察 2026-10-16 · active
02 · 从方向走到具体岗位
核查一份真实岗位的完整要求
每份样本只代表这家公司的这份职位。招聘状态以原站为准；先核对地区、级别与职责，再决定是否了解或申请。
Canonical · Home based – Worldwide；具体雇佣资格需核对核查时可见申请入口
级别：要求职业软件工程经验，未写统一职级 · 发布：原页未明确 · 观察：2026-10-16 · 核查：2026-10-16
核查时一手页面仍显示申请入口；没有提交申请或验证招聘方实际招募进度。
岗位复核周期14天；超期保留有日期的职责样本，申请前核查原站。 本样本已到期待复核。
职责与要求
- 处理开源基础设施问题、回移补丁、与上游协作
- 审阅代码并和支持/产品团队沟通
- 职业软件工程经验；Linux经验以及Ceph/OpenStack/Kubernetes等至少一种云技术的较强经验。
- 在Linux上使用Python/Go/C/C++至少一种语言的较强开发经验，能够调试并使用Git。
- JD列出突出学业表现；申请表要求说明高中数学/母语成绩依据与大学成绩，也明确允许无大学学历者填写no degree。
- 需参与国际线下活动；申请表具体询问每年2–4次、每次1–2周的承诺。
结合自己材料，要核对什么
- “较强经验”和学业材料要求分别有哪些证据？无学历通道不代表其他筛选条件已豁免。
- 你的Linux/云与调试经历能对应哪份实际工作记录？
- 能满足地点、出行及申请原创要求吗？
- 若只有脚本练习，先找更符合经验的岗位，不把本样本当默认推荐。
这份样本未证明什么
- 这里只摘出与方向选择有关的要求，属于精选摘要，不是完整JD；申请前应逐项阅读官方职位与申请表。
- JD明确要求申请用自己的文字，AI生成申请内容会被取消资格；本站只能帮助理解要求，不能代写该申请。
- 2026-10-16申请入口可见；发布日期、名额及全部地区雇佣条件未知。
需要核对个人适配时，把岗位原文交给你的 Agent，复用已有经历与约束继续判断。
本期方法补充与相关工作资料
本期方法补充，怎样帮助我的判断？
当前阅读建议；整理 2026-10-21。与上方按原始发布日期筛选的进展分开，不改变历史窗口。
求职者：用可复现失败、修复和回归记录说明贡献，避免仅提交生成结果。
求职者：先选贴近目标职责的一项工作，准备能核查本人判断与验收的作品。
这是方法与准备材料，尚未证明本人的能力、团队收益或新增岗位需求。可以保持原决定。
AI已能参与完整代码交付循环；明确规则与可运行环境是最实用起点。当前仓库的表现仍需自己的补丁和回归证据。
让原本可复现的错误消失，同时保持已有行为。
仓库和复现条件明确时，可委派Agent完成补丁与回归循环，再按行为证据接收。
接收标准：原错误被真实捕获
在既有系统内交付一段符合用户行为、数据、权限与资源约束的可运行功能，连同可独立验收的实现和集成证据。
行为契约、真实依赖和独立验收齐备时，可整包委派到“可接收的功能实现”；本例的后端导出需满足实际数据、权限和资源验收，再按团队发布权限采纳。
接收标准：新增功能在真实系统中满足契约
在合并前找出会影响用户或系统的真实问题，并说明审查覆盖。
可让AI并行检查差异、定位疑点和构造复现；关键发现需核实，接收不能只看“无问题”。
接收标准：每条问题可重现或严格定位
交付可在目标浏览器完成真实用户任务的界面变更，附持久状态、视觉差异和可访问性证据。
可整包委派已定义交互的实现与浏览器迭代；以真实状态变化接收，键盘和辅助技术另留明确检查。
接收标准：任务确实完成
未来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 · 已到期待复查
本页局部样例 Markdown ↓
发现问题？提交纠错 →